Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #99091 > unrolled thread

Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?)

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Laura Creighton <lac@openend.se> - 2015-11-19 21:18 +0100
    Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Marko Rauhamaa <marko@pacujo.net> - 2015-11-19 22:57 +0200
      Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Laura Creighton <lac@openend.se> - 2015-11-19 23:41 +0100
        Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-20 14:00 +0000
      Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Steven D'Aprano <steve@pearwood.info> - 2015-11-20 11:33 +1100
        Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-25 09:14 +0100
          Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Steven D'Aprano <steve@pearwood.info> - 2015-11-25 21:52 +1100
            Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-25 13:25 +0100
            Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-25 13:20 +0000
              Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Ned Batchelder <ned@nedbatchelder.com> - 2015-11-25 07:13 -0800
                Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Laura Creighton <lac@openend.se> - 2015-11-25 16:59 +0100
                  Multiplication [was Re: Late-binding of function defaults] Steven D'Aprano <steve@pearwood.info> - 2015-11-26 05:09 +1100
                    Re: Multiplication [was Re: Late-binding of function defaults] Laura Creighton <lac@openend.se> - 2015-11-25 19:45 +0100
                    Re: Multiplication [was Re: Late-binding of function defaults] Marko Rauhamaa <marko@pacujo.net> - 2015-11-25 23:04 +0200
                Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Arie van Wingerden <xapwing@gmail.com> - 2015-11-25 17:12 +0100
                Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Chris Angelico <rosuav@gmail.com> - 2015-11-26 03:29 +1100
                Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-25 17:18 +0000
                  Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-25 11:03 -0700
                    Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-25 18:48 +0000
                  Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-11-25 20:50 +0000
                    Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-25 21:56 +0000
                      Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Marko Rauhamaa <marko@pacujo.net> - 2015-11-26 00:16 +0200
                        Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-25 22:41 +0000
                          Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Steven D'Aprano <steve@pearwood.info> - 2015-11-26 11:31 +1100
                            Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-26 01:23 +0000
                              Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Ned Batchelder <ned@nedbatchelder.com> - 2015-11-25 17:52 -0800
                                Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Ben Finney <ben+python@benfinney.id.au> - 2015-11-26 16:08 +1100
                                Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-11-26 06:39 +0000
                                Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-26 09:31 +0100
                                Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-26 12:53 +0000
                                  Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Chris Angelico <rosuav@gmail.com> - 2015-11-27 00:15 +1100
                                    Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-26 14:40 +0000
                                      Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) MRAB <python@mrabarnett.plus.com> - 2015-11-26 16:14 +0000
                                    Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-26 22:27 +0000
                                      Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Chris Angelico <rosuav@gmail.com> - 2015-11-27 10:07 +1100
                                      Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Random832 <random832@fastmail.com> - 2015-11-26 19:15 -0500
                                      Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Chris Angelico <rosuav@gmail.com> - 2015-11-27 11:48 +1100
                                      Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) MRAB <python@mrabarnett.plus.com> - 2015-11-27 01:15 +0000
                                  Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) MRAB <python@mrabarnett.plus.com> - 2015-11-26 16:16 +0000
                                  Re: Late-binding of function defaults (was Re: What is a function   parameter =[] for?) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-11-27 10:48 +1300
                                Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Steven D'Aprano <steve@pearwood.info> - 2015-11-27 12:46 +1100
                                  Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-27 02:01 +0000
                              Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Marko Rauhamaa <marko@pacujo.net> - 2015-11-26 08:41 +0200
                              Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Steven D'Aprano <steve@pearwood.info> - 2015-11-27 12:09 +1100
                                Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-27 10:31 +0000
                                  Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Marko Rauhamaa <marko@pacujo.net> - 2015-11-27 13:30 +0200
                Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Ben Finney <ben+python@benfinney.id.au> - 2015-11-26 06:57 +1100
                  Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Marko Rauhamaa <marko@pacujo.net> - 2015-11-25 23:00 +0200
              Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Emile van Sebille <emile@fenx.com> - 2015-11-25 10:56 -0800
              Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Steven D'Aprano <steve@pearwood.info> - 2015-11-26 13:01 +1100
            Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Chris Angelico <rosuav@gmail.com> - 2015-11-26 00:24 +1100
            Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-25 15:17 +0100
            Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Emile van Sebille <emile@fenx.com> - 2015-11-25 10:51 -0800
        Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Chris Angelico <rosuav@gmail.com> - 2015-11-25 19:32 +1100
          Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Marko Rauhamaa <marko@pacujo.net> - 2015-11-25 10:43 +0200
            Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Steven D'Aprano <steve@pearwood.info> - 2015-11-25 21:58 +1100
          Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-25 12:35 +0000
            Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Marko Rauhamaa <marko@pacujo.net> - 2015-11-25 15:06 +0200
              Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-25 13:37 +0000
                Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Marko Rauhamaa <marko@pacujo.net> - 2015-11-25 15:53 +0200
                  Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-25 14:34 +0000
                    Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-11-25 13:32 -0500
                    Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Steven D'Aprano <steve@pearwood.info> - 2015-11-26 11:53 +1100
                      Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Marko Rauhamaa <marko@pacujo.net> - 2015-11-26 08:52 +0200
                        Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Chris Angelico <rosuav@gmail.com> - 2015-11-26 18:14 +1100
                          Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Marko Rauhamaa <marko@pacujo.net> - 2015-11-26 10:27 +0200
                            Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Chris Angelico <rosuav@gmail.com> - 2015-11-26 19:34 +1100
                              Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Marko Rauhamaa <marko@pacujo.net> - 2015-11-26 12:54 +0200
                                Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Chris Angelico <rosuav@gmail.com> - 2015-11-26 22:04 +1100
                                  Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Marko Rauhamaa <marko@pacujo.net> - 2015-11-26 13:23 +0200
                                    Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Chris Angelico <rosuav@gmail.com> - 2015-11-26 22:35 +1100
                                      Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Marko Rauhamaa <marko@pacujo.net> - 2015-11-26 14:03 +0200
                                    Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Steven D'Aprano <steve@pearwood.info> - 2015-11-27 12:43 +1100
                            Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-26 09:45 +0100
                            Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-11-27 10:20 +1300
                              Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Marko Rauhamaa <marko@pacujo.net> - 2015-11-26 23:36 +0200
                            Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Steven D'Aprano <steve@pearwood.info> - 2015-11-27 12:23 +1100
                        Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-11-26 11:17 +0000
              Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Chris Angelico <rosuav@gmail.com> - 2015-11-26 00:44 +1100
              Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Ben Finney <ben+python@benfinney.id.au> - 2015-11-26 06:55 +1100
              Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Random832 <random832@fastmail.com> - 2015-11-26 00:52 +0000
              Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-25 20:01 -0700
              Semantics of collection types (was: Late-binding of function defaults (was Re: What is a function parameter =[] for?)) Ben Finney <ben+python@benfinney.id.au> - 2015-11-26 16:04 +1100
            Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Chris Angelico <rosuav@gmail.com> - 2015-11-26 00:35 +1100
          Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Larry Hudson <orgnut@yahoo.com> - 2015-11-25 22:44 -0800
        Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-25 10:13 +0100

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#99492

On 25/11/2015 20:50, Mark Lawrence wrote:
> On 25/11/2015 17:18, BartC wrote:

> Can you please let us know what you're taking, what it costs and where
> we can get it, as we would also like to live in cloud cuckoo land,
> provided that The Price Is Right™.

And I would really like to know what your problem is.

I'm interested in language design because that's what I've done on and 
off for over 30 years. And I'm discussing some design decisions in Python.

> Although credit where credit is due, you are one of the most successful
> trolls to con this list in years.  I must offer my congratulations.

If you think I'm a 'troll' then that's your business. But I'm not 
holding a gun to your head and forcing you to read my posts.

[toc] | [prev] | [next] | [standalone]

#99497

BartC <bc@freeuk.com>:

> I'm interested in language design because that's what I've done on and
> off for over 30 years. And I'm discussing some design decisions in
> Python.

That *is* a fun ambition, useful or not.

However, while I'm very choosy and critical when it comes to my
programming tools, I'm extremely happy with the programming language
options that are freely available. It would be very difficult to beat
the existing options with expressive power or elegance.

You seem to have been surprised with some advanced concepts and idioms
in this discussion. Really, apart from its indentation syntax, Python
offers no unique or even rare software engineering concepts (Python's
emphasis duck-typing comes close to being distinctive). You'll find
equivalents in quite many languages, and in active, money-making uses.

> I'm not holding a gun to your head and forcing you to read my posts.

Follow your own advice.


Marko

[toc] | [prev] | [next] | [standalone]

#99501

On 25/11/2015 22:16, Marko Rauhamaa wrote:
> BartC <bc@freeuk.com>:
>
>> I'm interested in language design because that's what I've done on and
>> off for over 30 years. And I'm discussing some design decisions in
>> Python.
>
> That *is* a fun ambition, useful or not.

(At the moment, it's mostly fun. But in the past I actually needed the 
languages to do my job (designing microprocessor hardware). The 
scripting languages came a bit later, to go with my 3D graphics 
applications.)

> You seem to have been surprised with some advanced concepts and idioms
> in this discussion. Really, apart from its indentation syntax, Python
> offers no unique or even rare software engineering concepts (Python's
> emphasis duck-typing comes close to being distinctive). You'll find
> equivalents in quite many languages, and in active, money-making uses.

Maybe you're too familiar with it. But the idea of /executing/ the 
function and other definitions in a file, instead of they just being 
there, is novel.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#99513

On Thu, 26 Nov 2015 09:41 am, BartC wrote:

> Maybe you're too familiar with it. But the idea of executing the
> function and other definitions in a file, instead of they just being
> there, is novel.


It really, truly isn't. Your viewpoint is clouded by too much immersion in
crippled languages. *Old and obsolete versions* of crippled languages.
Dynamic creation of functions goes back to the 1950s.

Functions in Python are *first class values*, just like ints, strings, lists
etc. That means functions can be passed around as arguments, assigned to
variables, returned from functions, and created on the fly as needed. This
is not an innovation from Python -- Python rarely, if ever, innovates. By
the time any feature hits Python (yes, even significant indentation) it has
typically been proven in at least one other language.

Languages with first class functions include Perl, Javascript, Lua, PHP,
Tcl/Tk, Io, Go, Rust, Maple, Mathematica, Smalltalk, Swift, and varied mix
of old (Smalltalk and Perl) and new (Rust and Swift).

It is almost unthinkable to imagine a functional programming language
without this feature, and sure enough Scala, Haskell, ML, Clojure, and
Scheme have it -- as does Lisp, which is the second oldest high level
language in existence. Only Fortran is older.

Delphi (a variant on Pascal/Algol) has supported them since 2009. C++, C#
and Objective C have support for first class functions. Even Java 8 and
above includes this feature.

In 2015, it's hard to think of any non-obsolete, non-toy language which
doesn't treat functions as first-class values, including creating them on
the fly. Fortran and C perhaps.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#99518

On 26/11/2015 00:31, Steven D'Aprano wrote:
> On Thu, 26 Nov 2015 09:41 am, BartC wrote:
>
>> Maybe you're too familiar with it. But the idea of executing the
>> function and other definitions in a file, instead of they just being
>> there, is novel.
>
>
> It really, truly isn't. Your viewpoint is clouded by too much immersion in
> crippled languages. *Old and obsolete versions* of crippled languages.
> Dynamic creation of functions goes back to the 1950s.
>
> Functions in Python are *first class values*, just like ints, strings, lists
> etc. That means functions can be passed around as arguments, assigned to
> variables, returned from functions, and created on the fly as needed. This
> is not an innovation from Python -- Python rarely, if ever, innovates. By
> the time any feature hits Python (yes, even significant indentation) it has
> typically been proven in at least one other language.
>
> Languages with first class functions include Perl, Javascript, Lua, PHP,
> Tcl/Tk, Io, Go, Rust, Maple, Mathematica, Smalltalk, Swift, and varied mix
> of old (Smalltalk and Perl) and new (Rust and Swift).
>
> It is almost unthinkable to imagine a functional programming language
> without this feature, and sure enough Scala, Haskell, ML, Clojure, and
> Scheme have it -- as does Lisp, which is the second oldest high level
> language in existence. Only Fortran is older.
>
> Delphi (a variant on Pascal/Algol) has supported them since 2009. C++, C#
> and Objective C have support for first class functions. Even Java 8 and
> above includes this feature.
>
> In 2015, it's hard to think of any non-obsolete, non-toy language which
> doesn't treat functions as first-class values, including creating them on
> the fly. Fortran and C perhaps.

It's funny then that the vast majority of top-level function definitions 
I see in Python (and import and class statements too) are decidedly static.

The names are declared, but the names are rarely bound to anything else. 
Functions are just called the same boring way they are in C.

/They might as well be static definitions/.

(In fact, all this dynamic set-up, while it makes for an elegant and 
consistent language, probably also makes it unnecessarily harder to 
accelerate.)

Clearly a huge amount of programming can be done without having to deal 
with first-class functions (or constructing functions at run-time; that 
sounds fun). (Or without using OOP, another thing I can't stand.)

Some people just don't want to be functional programmers. It is elitist 
to try and make out it that it is that important.

If lots of languages now have functional features, it's more likely to 
be a case of keeping up with the Joneses.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#99519

On Wednesday, November 25, 2015 at 8:23:36 PM UTC-5, BartC wrote:
> On 26/11/2015 00:31, Steven D'Aprano wrote:
> > On Thu, 26 Nov 2015 09:41 am, BartC wrote:
> >
> >> Maybe you're too familiar with it. But the idea of executing the
> >> function and other definitions in a file, instead of they just being
> >> there, is novel.
> >
> >
> > It really, truly isn't. Your viewpoint is clouded by too much immersion in
> > crippled languages. *Old and obsolete versions* of crippled languages.
> > Dynamic creation of functions goes back to the 1950s.
> >
> > Functions in Python are *first class values*, just like ints, strings, lists
> > etc. That means functions can be passed around as arguments, assigned to
> > variables, returned from functions, and created on the fly as needed. This
> > is not an innovation from Python -- Python rarely, if ever, innovates. By
> > the time any feature hits Python (yes, even significant indentation) it has
> > typically been proven in at least one other language.
> >
> > Languages with first class functions include Perl, Javascript, Lua, PHP,
> > Tcl/Tk, Io, Go, Rust, Maple, Mathematica, Smalltalk, Swift, and varied mix
> > of old (Smalltalk and Perl) and new (Rust and Swift).
> >
> > It is almost unthinkable to imagine a functional programming language
> > without this feature, and sure enough Scala, Haskell, ML, Clojure, and
> > Scheme have it -- as does Lisp, which is the second oldest high level
> > language in existence. Only Fortran is older.
> >
> > Delphi (a variant on Pascal/Algol) has supported them since 2009. C++, C#
> > and Objective C have support for first class functions. Even Java 8 and
> > above includes this feature.
> >
> > In 2015, it's hard to think of any non-obsolete, non-toy language which
> > doesn't treat functions as first-class values, including creating them on
> > the fly. Fortran and C perhaps.
> 
> It's funny then that the vast majority of top-level function definitions 
> I see in Python (and import and class statements too) are decidedly static.
> 
> The names are declared, but the names are rarely bound to anything else. 
> Functions are just called the same boring way they are in C.
> 
> /They might as well be static definitions/.
> 
> (In fact, all this dynamic set-up, while it makes for an elegant and 
> consistent language, probably also makes it unnecessarily harder to 
> accelerate.)
> 
> Clearly a huge amount of programming can be done without having to deal 
> with first-class functions (or constructing functions at run-time; that 
> sounds fun). (Or without using OOP, another thing I can't stand.)
> 
> Some people just don't want to be functional programmers. It is elitist 
> to try and make out it that it is that important.
> 
> If lots of languages now have functional features, it's more likely to 
> be a case of keeping up with the Joneses.

I almost started to explain about how yes, Python is often written in
conservative static ways. I was going to mention that a little dynamic
nature goes a long way, and is never far from the surface in even the
simplest Python programs.

But I won't, because I'm not sure you're really interested.  There's a
pattern here of people trying to explain Python to you, and eventually,
after many words, getting to some kind of shared understanding, only
for you to shrug it all off as a fad, or pocket-lining, or needless
complexity.

For someone who claims to be interested in language design, you're
remarkably dismissive of pretty much the entire industry.  I don't think
it's worth the effort to try to change your mind.

--Ned.

[toc] | [prev] | [next] | [standalone]

#99528

Ned Batchelder <ned@nedbatchelder.com> writes:

> For someone who claims to be interested in language design, you're
> remarkably dismissive of pretty much the entire industry. I don't
> think it's worth the effort to try to change your mind.

+1.

BartC, when you want to join us in discussions on good faith – that is,
honestly wanting to learn Python rather than dogmatically persisting in
your misperceptions dogmatically onto it – we'll still be here, making
happy use of Python the way it is.

-- 
 \       “Facts are meaningless. You could use facts to prove anything |
  `\                that's even remotely true!” —Homer, _The Simpsons_ |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#99529

On 26/11/2015 05:08, Ben Finney wrote:
> Ned Batchelder <ned@nedbatchelder.com> writes:
>
>> For someone who claims to be interested in language design, you're
>> remarkably dismissive of pretty much the entire industry. I don't
>> think it's worth the effort to try to change your mind.
>
> +1.
>
> BartC, when you want to join us in discussions on good faith – that is,
> honestly wanting to learn Python rather than dogmatically persisting in
> your misperceptions dogmatically onto it – we'll still be here, making
> happy use of Python the way it is.
>

Ben and Ned, I'd like to thank both of you for these comments as they 
are put far more eloquently and diplomatically than I would ever manage.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#99540

Op 26-11-15 om 02:52 schreef Ned Batchelder:
> I almost started to explain about how yes, Python is often written in
> conservative static ways. I was going to mention that a little dynamic
> nature goes a long way, and is never far from the surface in even the
> simplest Python programs.
>
> But I won't, because I'm not sure you're really interested.  There's a
> pattern here of people trying to explain Python to you, and eventually,
> after many words, getting to some kind of shared understanding, only
> for you to shrug it all off as a fad, or pocket-lining, or needless
> complexity.
>
> For someone who claims to be interested in language design, you're
> remarkably dismissive of pretty much the entire industry.  I don't think
> it's worth the effort to try to change your mind.

I agree. I still think the regulars tend to react in a too defensive way
when someone rather new dares to find fault with some python aspects. But
if someone comes here and can't get over their bizarre first impression of 
some python aspects then there is not much reason to continue the discussion
with them either.

-- 
Antoon.

[toc] | [prev] | [next] | [standalone]

#99569

On 26/11/2015 01:52, Ned Batchelder wrote:
> On Wednesday, November 25, 2015 at 8:23:36 PM UTC-5, BartC wrote:
>> On 26/11/2015 00:31, Steven D'Aprano wrote:

>>> It really, truly isn't. Your viewpoint is clouded by too much immersion in
>>> crippled languages. *Old and obsolete versions* of crippled languages.
>>> Dynamic creation of functions goes back to the 1950s.

>> It's funny then that the vast majority of top-level function definitions
>> I see in Python (and import and class statements too) are decidedly static.

> I almost started to explain about how yes, Python is often written in
> conservative static ways. I was going to mention that a little dynamic
> nature goes a long way, and is never far from the surface in even the
> simplest Python programs.
>
> But I won't, because I'm not sure you're really interested.  There's a
> pattern here of people trying to explain Python to you, and eventually,
> after many words, getting to some kind of shared understanding, only
> for you to shrug it all off as a fad, or pocket-lining, or needless
> complexity.

I'm sorry if I've been misunderstood.

I simply stated that Python's approach was novel. Steven D'Aprano then 
responded by belittling my view, and effectively trashing every language 
I've ever used.

But as it happens I do think features like first class functions are 
overrated (and probably the software underpinning the hardware we're all 
using is written in the very languages he despises). I don't think a 
language is worthless without such a feature.

 > For someone who claims to be interested in language design, you're
 > remarkably dismissive of pretty much the entire industry.  I don't think
 > it's worth the effort to try to change your mind.

I did say somewhere in this thread or the other one, that I liked 
Python's model well enough that I tried to emulate it in my own 
language. That's not being dismissive! (It don't work because the 
languages are too different internally; I'll have to save it for a 
separate, higher-level language.)

Also, as an implementer, you can understand that I might view certain 
features differently from other people. Dynamic features do make it 
harder to implement things efficiently, and you have to decide whether 
it's worthwhile for the 1% of the time they might be used.

------------------------------------------

FWIW here is that list of features that are different between Python and 
my language, or that work a different way, or that I think could be a 
useful addition. (Although Python's internal workings make many 
impractical.)

http://pastebin.com/JrVTher6

This is not an attempt to compare the complete languages as they are for 
different purposes (mine is more low-level, simpler, smaller and 
designed to make it easier to create an efficient byte-code interpreter 
for it).

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#99577

On Thu, Nov 26, 2015 at 11:53 PM, BartC <bc@freeuk.com> wrote:
> FWIW here is that list of features that are different between Python and my
> language, or that work a different way, or that I think could be a useful
> addition. (Although Python's internal workings make many impractical.)
>
> http://pastebin.com/JrVTher6
>
> This is not an attempt to compare the complete languages as they are for
> different purposes (mine is more low-level, simpler, smaller and designed to
> make it easier to create an efficient byte-code interpreter for it).

"I think Python now has hex, octal and binary literals. X allows any
base from 2 to 16: 2x10101 is binary, while 4x101 is quaternary (ie.
20)."

Do you mean that 4x101 means 1*(4*4) + 0*(4) + 1? If so, it would be
17, not 20. Is this a typo in the document, or am I misunderstanding
your syntax?

#14 and #15: Are you assuming that a character is a byte and that
diacritical-free English is the only language in the world? Case
insensitivity is a *pain* when you try to be language-agnostic; for
instance, the case-folding rules of English state that U+0069 LATIN
SMALL LETTER I and U+0049 LATIN CAPITAL LETTER I are identical, but
Turkish would upper-case the first to U+0130 LATIN CAPITAL LETTER I
WITH DOT ABOVE and lower-case the second to U+0131 LATIN SMALL LETTER
DOTLESS I. German has U+00DF LATIN SMALL LETTER SHARP S (also called
eszett), which traditionally upper-cases to "SS", which lower-cases to
"ss".

ChrisA

[toc] | [prev] | [next] | [standalone]

#99579

On 26/11/2015 13:15, Chris Angelico wrote:
> On Thu, Nov 26, 2015 at 11:53 PM, BartC <bc@freeuk.com> wrote:
>> FWIW here is that list of features that are different between Python and my
>> language, or that work a different way, or that I think could be a useful
>> addition. (Although Python's internal workings make many impractical.)
>>
>> http://pastebin.com/JrVTher6
>>
>> This is not an attempt to compare the complete languages as they are for
>> different purposes (mine is more low-level, simpler, smaller and designed to
>> make it easier to create an efficient byte-code interpreter for it).
>
> "I think Python now has hex, octal and binary literals. X allows any
> base from 2 to 16: 2x10101 is binary, while 4x101 is quaternary (ie.
> 20)."
>
> Do you mean that 4x101 means 1*(4*4) + 0*(4) + 1? If so, it would be
> 17, not 20. Is this a typo in the document, or am I misunderstanding
> your syntax?

Just a mistake. The example had been 4x100 which is 16, but I changed it 
to 4x101 for a bit less confusion, which as you say is 17 not 20 which 
is 4x110.

(Although not used much, I have used quaternary here for example:

   4x3032_3233_2323

The digits represent the number of extra days more than 28 in each 
month, from Jan to Dec.)


-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#99587

On 2015-11-26 14:40, BartC wrote:
> On 26/11/2015 13:15, Chris Angelico wrote:
>> On Thu, Nov 26, 2015 at 11:53 PM, BartC <bc@freeuk.com> wrote:
>>> FWIW here is that list of features that are different between Python and my
>>> language, or that work a different way, or that I think could be a useful
>>> addition. (Although Python's internal workings make many impractical.)
>>>
>>> http://pastebin.com/JrVTher6
>>>
>>> This is not an attempt to compare the complete languages as they are for
>>> different purposes (mine is more low-level, simpler, smaller and designed to
>>> make it easier to create an efficient byte-code interpreter for it).
>>
>> "I think Python now has hex, octal and binary literals. X allows any
>> base from 2 to 16: 2x10101 is binary, while 4x101 is quaternary (ie.
>> 20)."
>>
>> Do you mean that 4x101 means 1*(4*4) + 0*(4) + 1? If so, it would be
>> 17, not 20. Is this a typo in the document, or am I misunderstanding
>> your syntax?
>
> Just a mistake. The example had been 4x100 which is 16, but I changed it
> to 4x101 for a bit less confusion, which as you say is 17 not 20 which
> is 4x110.
>
> (Although not used much, I have used quaternary here for example:
>
>     4x3032_3233_2323
>
> The digits represent the number of extra days more than 28 in each
> month, from Jan to Dec.)
>
Smalltalk uses "r" (for "radix") rather than "x", and can handle any 
base from 2 to 36.

[toc] | [prev] | [next] | [standalone]

#99605

On 26/11/2015 13:15, Chris Angelico wrote:
> On Thu, Nov 26, 2015 at 11:53 PM, BartC <bc@freeuk.com> wrote:

>> http://pastebin.com/JrVTher6

> #14 and #15: Are you assuming that a character is a byte and that
> diacritical-free English is the only language in the world?

I don't think that need be the assumption. Any UTF8 string that fits 
within 8 bytes could also be represented by an integer value.

> Case
> insensitivity is a *pain* when you try to be language-agnostic; for
> instance, the case-folding rules of English state that U+0069 LATIN
> SMALL LETTER I and U+0049 LATIN CAPITAL LETTER I are identical, but
> Turkish would upper-case the first to U+0130 LATIN CAPITAL LETTER I
> WITH DOT ABOVE and lower-case the second to U+0131 LATIN SMALL LETTER
> DOTLESS I. German has U+00DF LATIN SMALL LETTER SHARP S (also called
> eszett), which traditionally upper-cases to "SS", which lower-cases to
> "ss".

I use Windows which is also case insensitive with regard to filenames 
and such. How does it solve those problems? How about web-site names, 
email addresses and Google searches?

Within a program source code (where you have mainly technical users), 
you can just impose some restrictions on keywords and identifiers 
otherwise there are plenty of problems even without case switching, if 
you want to allow Unicode here.


-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#99606

On Fri, Nov 27, 2015 at 9:27 AM, BartC <bc@freeuk.com> wrote:
> On 26/11/2015 13:15, Chris Angelico wrote:
>>
>> On Thu, Nov 26, 2015 at 11:53 PM, BartC <bc@freeuk.com> wrote:
>
>
>>> http://pastebin.com/JrVTher6
>
>
>> #14 and #15: Are you assuming that a character is a byte and that
>> diacritical-free English is the only language in the world?
>
>
> I don't think that need be the assumption. Any UTF8 string that fits within
> 8 bytes could also be represented by an integer value.

Okay, so you're making UTF-8 your visible string representation.
That's better than assuming character==byte, but it still has the case
insensitivity problem.

>> Case
>> insensitivity is a *pain* when you try to be language-agnostic; for
>> instance, the case-folding rules of English state that U+0069 LATIN
>> SMALL LETTER I and U+0049 LATIN CAPITAL LETTER I are identical, but
>> Turkish would upper-case the first to U+0130 LATIN CAPITAL LETTER I
>> WITH DOT ABOVE and lower-case the second to U+0131 LATIN SMALL LETTER
>> DOTLESS I. German has U+00DF LATIN SMALL LETTER SHARP S (also called
>> eszett), which traditionally upper-cases to "SS", which lower-cases to
>> "ss".
>
>
> I use Windows which is also case insensitive with regard to filenames and
> such. How does it solve those problems? How about web-site names, email
> addresses and Google searches?

Windows: I'm not sure, and frankly, I don't trust it. A quick test
showed a couple of failures:

C:\Users\Rosuav\Desktop>dir /b TE*
teßting
C:\Users\Rosuav\Desktop>dir /b TESST*
File Not Found

C:\Users\Rosuav\Desktop>dir /b ParıldıYOR*
Parıldıyor Parts & Pieces
C:\Users\Rosuav\Desktop>dir /b PARILDIYOR*
File Not Found

It might be case insensitive only for ASCII.

(Note: This test was done on Windows 7, because that's the VM I had
handy. Things might be different on newer Windowses, but I can't
check.

Web site names: Presumably you mean DNS. It started out as an
ASCII-only protocol, and grew a number of gross hacks to support
"internationalized domain names". I'm not sure where the case
insensitivity is applied; but it doesn't matter too much, because
conflicts can be resolved at registration. Also, you'll generally see
IDNs in country-specific TLDs, so there'll be only one language (or a
small family of languages) used, reducing the likelihood of
collisions.

Google searches are (deliberately) a LOT more sloppy than just case
sensitivity. You can search for something without diacriticals and get
back results with diacriticals; you can transpose letters, omit
letters, have extra letters, and it'll generally figure out what you
want. This is absolutely awesome for a search engine, but equally
horrifying for name lookups in a program.

None of these is something I'd recommend following.

> Within a program source code (where you have mainly technical users), you
> can just impose some restrictions on keywords and identifiers otherwise
> there are plenty of problems even without case switching, if you want to
> allow Unicode here.

I would strongly support ASCII-only *language keywords*. You don't
have many of them (compared to the number of identifiers in a
program), and everyone has to type them. But for identifiers, Python 3
defines character validity based on Unicode categories, and performs
NFKC normalization on all names. That's pretty straight-forward. No
case sensitivity hassles, no messy non-transitive equalities, it's
easy.

ChrisA

[toc] | [prev] | [next] | [standalone]

#99607

Chris Angelico <rosuav@gmail.com> writes:
> Windows: I'm not sure, and frankly, I don't trust it. A quick test
> showed a couple of failures:
> 
> It might be case insensitive only for ASCII.

Windows uses a simple WCHAR->WCHAR (lower->upper) mapping for case
comparison. it doesn't handle those cases, but it does handle all BMP
characters that have a simple case equivalent within the BMP as of the
unicode version that Microsoft supported when the disk was formatted.

It's unfair to pick the two worst examples that you know offhand and
declare that this means "only for ASCII". Pick any latin-1 (etc)
diacritic, any letter of the greek and cyrillic alphabet, and it'll
handle them just fine.

OSX fails the same cases, incidentally.

[toc] | [prev] | [next] | [standalone]

#99608

On Fri, Nov 27, 2015 at 11:15 AM, Random832 <random832@fastmail.com> wrote:
> Chris Angelico <rosuav@gmail.com> writes:
>> Windows: I'm not sure, and frankly, I don't trust it. A quick test
>> showed a couple of failures:
>>
>> It might be case insensitive only for ASCII.
>
> Windows uses a simple WCHAR->WCHAR (lower->upper) mapping for case
> comparison. it doesn't handle those cases, but it does handle all BMP
> characters that have a simple case equivalent within the BMP as of the
> unicode version that Microsoft supported when the disk was formatted.
>
> It's unfair to pick the two worst examples that you know offhand and
> declare that this means "only for ASCII". Pick any latin-1 (etc)
> diacritic, any letter of the greek and cyrillic alphabet, and it'll
> handle them just fine.
>

I picked a couple of test cases, found them to not do the case
insensitivity special cases, and concluded that I don't understand
Windows' file system case folding (with the possibility that it's an
ASCII-only case fold).

Anyway, it's still not something I would recommend; if you want true
case folding, you need to go the whole way - and it still has
problems.

ChrisA

[toc] | [prev] | [next] | [standalone]

#99610

On 2015-11-27 00:15, Random832 wrote:
> Chris Angelico <rosuav@gmail.com> writes:
>> Windows: I'm not sure, and frankly, I don't trust it. A quick test
>> showed a couple of failures:
>>
>> It might be case insensitive only for ASCII.
>
> Windows uses a simple WCHAR->WCHAR (lower->upper) mapping for case
> comparison. it doesn't handle those cases, but it does handle all BMP
> characters that have a simple case equivalent within the BMP as of the
> unicode version that Microsoft supported when the disk was formatted.
>
Interesting, on Windows 10, "dir" on the command line treats
"TEßTING.txt" and "teßting.txt" as equivalent, whereas a file dialog
treats "TEßTING.txt", "teßting.txt" and "TESSTING.txt" as equivalent.

They don't treat "ParıldıYOR.txt" and "PARILDIYOR.txt" as equivalent,
which doesn't surprise me.

> It's unfair to pick the two worst examples that you know offhand and
> declare that this means "only for ASCII". Pick any latin-1 (etc)
> diacritic, any letter of the greek and cyrillic alphabet, and it'll
> handle them just fine.
>
> OSX fails the same cases, incidentally.
>

[toc] | [prev] | [next] | [standalone]

#99588

On 2015-11-26 12:53, BartC wrote:
> On 26/11/2015 01:52, Ned Batchelder wrote:
>> On Wednesday, November 25, 2015 at 8:23:36 PM UTC-5, BartC wrote:
>>> On 26/11/2015 00:31, Steven D'Aprano wrote:
>
>>>> It really, truly isn't. Your viewpoint is clouded by too much immersion in
>>>> crippled languages. *Old and obsolete versions* of crippled languages.
>>>> Dynamic creation of functions goes back to the 1950s.
>
>>> It's funny then that the vast majority of top-level function definitions
>>> I see in Python (and import and class statements too) are decidedly static.
>
>> I almost started to explain about how yes, Python is often written in
>> conservative static ways. I was going to mention that a little dynamic
>> nature goes a long way, and is never far from the surface in even the
>> simplest Python programs.
>>
>> But I won't, because I'm not sure you're really interested.  There's a
>> pattern here of people trying to explain Python to you, and eventually,
>> after many words, getting to some kind of shared understanding, only
>> for you to shrug it all off as a fad, or pocket-lining, or needless
>> complexity.
>
> I'm sorry if I've been misunderstood.
>
> I simply stated that Python's approach was novel. Steven D'Aprano then
> responded by belittling my view, and effectively trashing every language
> I've ever used.
>
[snip]
Well, it's not /that/ new.

Both Forth and PostScript define functions by execution.

[toc] | [prev] | [next] | [standalone]

#99604 — Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?)

BartC wrote:
> I simply stated that Python's approach was novel. Steven D'Aprano then 
> responded by belittling my view, and effectively trashing every language 
> I've ever used.

He pointed out that many other dynamic languages construct
functions on the fly the same way that Python does, going
all the way back to the earliest Lisp implementations. If
you think that Python invented that idea, then either you
haven't studied any of those languages, or you didn't
realise that's what they were doing. If your view was
"belittled" in any way, it's only because you said something
that is objectively wrong.

> But as it happens I do think features like first class functions are 
> overrated (and probably the software underpinning the hardware we're all 
> using is written in the very languages he despises). I don't think a 
> language is worthless without such a feature.

I think Steven went off on a bit of a tangent there.
First-classness of functions doesn't really have anything
to do with whether they're constructed statically or
dynamically. C lets you pass pointers to functions around,
for example, but I don't think anyone would describe C
as executing function definitions at run time.

While a language isn't worthless without first-class
functions, such a language tends to feel rather limited
if you're used to having them. Think of any API that
involves passing in callback functions, and what you
would have to do if you didn't have that ability.

Anyhow, the whole issue of static vs. dynamic function
creation is itself tangential to what started all this.
I think Laura Creighton has it right: Python provides
exactly *one* way to delay evaluation of code: put it
in the body of a function. That's a very simple rule,
and I think maintaining that simplicity is a good
thing.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.lang.python

csiph-web