Re: Python for beginners or not? [was Re: syntax difference]

[Neil Cerutti]

On 2018-06-25, Alister  wrote:
> for i in range(len(list)): is a python anti-pattern it is almost a 100%
> guarantee that you are doing something wrong*
>
> *as with all rules of thumb there is probably at least 1
> exception that the python experts will now point out.

When you need look-ahead or similar inspection of more than the
current item. An alternative is a custom generator or iterator
that provides the window you need.

-- 
Neil Cerutti

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Bart]

On 27/06/2018 12:42, Peter J. Holzer wrote:

On 2018-06-27 11:11:37 +1200, Gregory Ewing wrote:

Bart wrote:

x = set(range(10_000_000))

This used up 460MB of RAM (the original 100M I tried exhausted the memory).

The advantage of Pascal-style sets is that that same set will occupy
only 1.25MB, as it is a bit-map.


That's true, but they're also extremely limited compared to
the things you can do with Python sets. They're really two
quite different things, designed for different use cases.

Compact sets of integers are possible in Python, but not
as a built-in type. This suggests that they're not needed
much


Also, when such sets are needed, a simple array of bits may not be
sufficient. For example, sets may be sparse, or they may have almost all
except a few bits set. In these cases a tree or RLE representation is
much smaller and faster. There are a number of such implementations
(Judy Arrays and Roaring Bitmaps come to mind[1]). Each has its
advantages and limitations, so its probably better to leave the choice
to the author.


From roaringbitmap.org:

"Bitsets, also called bitmaps, are commonly used as fast data 
structures. Unfortunately, they can use too much memory. To compensate, 
we often use compressed bitmaps."


So from one extreme to another: from the 300-400 bits per element used 
by Python's set type, to some presumably tiny fraction of a bit [on 
average] used in this scheme, as 1 bit per element is too much.


Is there no place at all for an ordinary, straightforward, uncompressed 
bit-set where each element takes exactly one bit? It does seem as though 
Python users have an aversion to simplicity and efficiency.


FWIW when I was working with actual image bitmaps, they were nearly 
always uncompressed when in memory. 1-bit-per-pixel images, for mono 
images or masks, would pack 8 pixels per byte. Compression would only be 
used for storage or transmission.


And the same with all the set types I've used.

However there is a slight difference with the concept of a 'set' as I 
used it, and as it was used in Pascal, compared with Python's set: there 
was the notion of the overall size of the set: the total number of 
elements, whether each was '1' or '0'.


So a set type that represented all ASCII codes would have a size of 128 
elements, indexed 0 to 127. So such a set initialised to ['A'..'Z'] and 
then inverted would give the set [0..64,91..127].


--
bart
--
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Peter J. Holzer]

On 2018-06-27 11:11:37 +1200, Gregory Ewing wrote:
> Bart wrote:
> >x = set(range(10_000_000))
> > 
> > This used up 460MB of RAM (the original 100M I tried exhausted the memory).
> > 
> > The advantage of Pascal-style sets is that that same set will occupy
> > only 1.25MB, as it is a bit-map.
> 
> That's true, but they're also extremely limited compared to
> the things you can do with Python sets. They're really two
> quite different things, designed for different use cases.
> 
> Compact sets of integers are possible in Python, but not
> as a built-in type. This suggests that they're not needed
> much

Also, when such sets are needed, a simple array of bits may not be
sufficient. For example, sets may be sparse, or they may have almost all
except a few bits set. In these cases a tree or RLE representation is
much smaller and faster. There are a number of such implementations
(Judy Arrays and Roaring Bitmaps come to mind[1]). Each has its
advantages and limitations, so its probably better to leave the choice
to the author.

hp

[1] Judy is a C library. Roaring bitmaps are a data structure which has
been implemented in several languages. I haven't checked whether
there are packages on pypi. Shouldn't be too hard to implement if
one needs it.

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Gregory Ewing]

Bart wrote:
I don't know whether there is a direct equivalent in Python (I thought 
somebody would point it out)


Not built-in, but a tiny bit of googling turns this up:

https://pypi.org/project/bitarray/

"This module provides an object type which efficiently represents an array of 
booleans. Bitarrays are sequence types and behave very much like usual lists. 
Eight bits are represented by one byte in a contiguous block of memory."


--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Gregory Ewing]

Bart wrote:

   x = set(range(10_000_000))

This used up 460MB of RAM (the original 100M I tried exhausted the memory).

The advantage of Pascal-style sets is that that same set will occupy 
only 1.25MB, as it is a bit-map.


That's true, but they're also extremely limited compared to
the things you can do with Python sets. They're really two
quite different things, designed for different use cases.

Compact sets of integers are possible in Python, but not
as a built-in type. This suggests that they're not needed
much -- if they were used a lot, they would have become
part of the stdlib by now.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Mark Lawrence]

On 26/06/18 12:39, Chris Angelico wrote:

On Tue, Jun 26, 2018 at 9:30 PM, Bart  wrote:

On 19/06/2018 11:33, Steven D'Aprano wrote:


On Tue, 19 Jun 2018 10:19:15 +0100, Bart wrote:




* Integer sets (Pascal-like sets)

Why do you need them if you have real sets?



I tried Python sets for the first time. They seemed workable but rather
clunky to set up. But here is one problem on my CPython:

x = set(range(10_000_000))

This used up 460MB of RAM (the original 100M I tried exhausted the memory).

The advantage of Pascal-style sets is that that same set will occupy only
1.25MB, as it is a bit-map.

While sets will not usually be that big, there might be lots of small sets
and they all add up.


Cool. Make me a bitset that can represent this Python set:

{-5, -4, 6, 10, 1.5, "spam", print}

ChrisA



Please stop feeding this troll, it's getting very tedious.

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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[Mark Lawrence]

From: Mark Lawrence 

On 25/06/18 17:15, jkn wrote:
> On Monday, June 25, 2018 at 4:23:57 PM UTC+1, Chris Angelico wrote:
>> On Mon, Jun 25, 2018 at 11:15 PM, jkn  wrote:
>>> (as well as pedanticism ;-o).
>>
>> Pedantry.
>>
>> ChrisA
>> (You know I can't let that one pass.)
>
> I was chanel[l]ing the TimBot, as any fule kno...
>

Ritten by a troo Molesworth fann.

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

Mark Lawrence

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[Mark Lawrence]

From: Mark Lawrence 

On 25/06/18 10:10, Alister via Python-list wrote:
> On Mon, 25 Jun 2018 11:36:25 +0400, Abdur-Rahmaan Janhangeer wrote:
>
>> i think he means like for a loop to iterate over a list you might do
>>
>> list = [1,2,3]
>> for i in range(len(list)):
>>  print(list[i])
>>
>>
>> but the you might as well go for the simpler :
>>
>>
>> for elem in list:
>>
>>   print(elem)
>>
>> Abdur-Rahmaan Janhangeer https://github.com/Abdur-rahmaanJ
>>
>>
>>
>
> for i in range(len(list)): is a python anti-pattern it is almost a 100%
> guarantee that you are doing something wrong*
>
> *as with all rules of thumb there is probably at least 1 exception that
> the python experts will now point out.
>
>

The exception is that if you really do need the index, you write:-

for i, elem in enumerate(list):

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

Mark Lawrence

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Mark Lawrence]

From: Mark Lawrence 

On 24/06/18 00:44, boB Stepp wrote:
> I imagine that the
> transition from version 2 to 3 was not undertaken halfheartedly, but
> only after much thought and discussion since it did break backwards
> compatibility.
>

So much so that a specific mailing list was set up just to discus the
transition, archives here https://mail.python.org/pipermail/python-3000/

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

Mark Lawrence

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Bart]

  To: boB Stepp
From: "Bart" 

  To: boB Stepp
From: Bart 

On 24/06/2018 16:37, boB Stepp wrote:
> On Sun, Jun 24, 2018 at 5:21 AM Bart  wrote:

> "... And of course, you would have to know how to use Python properly in
> idiomatic style.

No. I want to program in /my/ style, one more like the pseudo-code that was
mentioned elsewhere, and that is universally understood. Even if people here
don't think much of it.

(eg. https://pastebin.com/0EygJzFR, raw text:https://pastebin.com/raw/0EygJzFR)

   Why not choose this positive approach?  I think it
> would be a win-win for both you and Python."
>
> Just show you genuinely care about the language and the community.
> Use and understand the language as well as you can before jumping into
> criticisms.  Adopt the path of the humble learner, who does not know
> everything about Python.  Is this too much to ask?

Sorry, I tried a few replies but they all got too long and too much about me.
So I'll have to leave it.

I think people know enough about my ideas by now anyway.

--
bart

-+- BBBS/Li6 v4.10 Toy-3
 + Origin: Prism bbs (1:261/38)

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Bart]

  To: Chris Angelico
From: "Bart" 

  To: Chris Angelico
From: Bart 

On 24/06/2018 15:46, Chris Angelico wrote:
> On Sun, Jun 24, 2018 at 8:40 PM, Steven D'Aprano
>  wrote:
>> On Sun, 24 Jun 2018 11:18:37 +0100, Bart wrote:
>>
>>> I wonder why it is just me that constantly needs to justify his
>>> existence in this group?
>>
>> Because its just you who spends 90% of his time here complaining about
>> how Python does it wrong.
>
> ... and spends 95% of that time demonstrating his utter lack of
> understanding of how Python does it at all. It's wrong even though you
> don't understand how it actually works.

More like utter disbelief at how it works. Surely it cannot work like that
because it would be too inefficient? Apparently, yes it can...

And all to support extreme dynamism which is only really needed a tiny
proportion of the time (feel free to correct me).

I know I'm going to get flak for bringing this up this old issue, but remember
when you used to write a for-loop and it involved creating an actual list of N
integers from 0 to N-1 in order to iterate through them? Crazy.

But that has long been fixed - or so I thought. When I wrote, today:

for i in range(1): pass  # 100 million

on Python 2, it used up 1.8GB, up to the limit of my RAM, and it took several
minutes to regain control of my machine (and it never did finish). You don't
expect that in 2018 when executing a simple empty loop.

On Py 2 you have to use xrange for large ranges - that was the fix.

Somebody however must have had to gently and tactfully point out the issue. I'm
 afraid I'm not very tactful.

--
bart

-+- BBBS/Li6 v4.10 Toy-3
 + Origin: Prism bbs (1:261/38)

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[Rick Johnson]

  To: Steven D'Aprano
From: Rick Johnson 

On Monday, June 25, 2018 at 5:56:04 AM UTC-5, Steven D'Aprano wrote:

> Nearly everybody misses the fact that the Zen is a joke,
> not to be taken *too* seriously. A particularly subtle
> joke, but still a joke.

The Python Zen is not merely a joke. But it does outline the philosophy of a
Python programmer in a humorous and self- contradicting manner. So while you
shouldn't read the Zen as some sort of religious law, you shouldn't dismiss it
as a joke either. Like a Monty Python skit, the Zen exposes the hypocrisy of
reality and does so in a humorous way.

> Not satisfied with those two ways, Tim invented his own.
>
> https://bugs.python.org/issue3364

BS! If there is one skill that we pythonista's all share, it is an uncanny
ability to glaze over our obvious mistakes with beautiful, sweet lies.

"A bug???"

"Whaddya mean a bug?"

"That's not a bug!"

"It's a feature!"

"Here, allow me to explain..."

[...snip two hours of monologue...]

Alas!

If only we had followed our _true_ calling and became lawyers.

(at least we would have been forced to dress respectively) ;-)

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Rick Johnson]

  To: Steven D'Aprano
From: "Rick Johnson" 

  To: Steven D'Aprano
From: Rick Johnson 

On Sunday, June 24, 2018 at 10:05:14 AM UTC-5, Steven D'Aprano wrote: [...]
> Be fair. It's more like 50% of the time. Let's not dogpile
> onto Bart. He asked a question, I answered it, we don't all
> need to sink the boot in as well.

And why am i _not_ surprised to learn that Steven defines "community" as
kicking and dogpiling others 50% of the time.

Well, at least it wasn't 100%...

Eh? o_O

-+- BBBS/Li6 v4.10 Toy-3
 + Origin: Prism bbs (1:261/38)

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[Stefan Ram]

  To: Steven D'Aprano
From: "Stefan Ram" 

  To: Steven D'Aprano
From: r...@zedat.fu-berlin.de (Stefan Ram)

Steven D'Aprano  writes:
>It has been a long, long time since Python has been a "simple" language
>suitable for rank beginners, if it ever was. Python is not Scratch.

  Python is simpler insofar as you can write on a higher level
  than with C. Python has a GC and an intuitive syntax for
  lists, tuples and dictionaries.

  main.c

#include 
int main( void ){ printf( "%d\n", 6 * 6 ); }

  transcript

-694967296

  Above, a beginner has to take care to use Γ╗%dΓ½ and remember
  to change this to Γ╗%gΓ½ when necessary. He also needs to
  understand why the result is negative, and that the result
  is /implementation-dependent/. Surely,

|>>> print( 6 * 6 )
|36

  is easier to read, write, and understand.

  Still, one must not forget that learning Python encompasses
  all the hard work it takes to learn how to program in every
  language.

-+- BBBS/Li6 v4.10 Toy-3
 + Origin: Prism bbs (1:261/38)

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Bart]

  To: Ben Bacarisse
From: "Bart" 

  To: Ben Bacarisse
From: Bart 

On 24/06/2018 01:53, Ben Bacarisse wrote:
> Bart  writes:

>> Wow. (Just think of all the times you write a function containing a
>> neat bunch of local functions, every time it's called it has to create
>> a new function instances for each of those functions, even if they are
>> not used.)
>
> I am surprised that this surprises you, and equally surprised that you
> seem to think it's going to be in some way grossly inefficient.

Steven D'Aprano's reply suggests there /is/ some inefficiency which is why
[according to him] nested functions are rarely used that way.

--
bartc

-+- BBBS/Li6 v4.10 Toy-3
 + Origin: Prism bbs (1:261/38)

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Bart]

  To: boB Stepp
From: "Bart" 

  To: boB Stepp
From: Bart 

On 24/06/2018 00:44, boB Stepp wrote:
> On Sat, Jun 23, 2018 at 5:35 PM Bart  wrote:

>> I'm not a user...
>
> Then I am truly puzzled, Bart.  Why do you even bother to hang out on
> this list?  If you do not want to use Python and you do not want to
> improve Python's design and implementation, what is your point of
> being here?

I wonder why it is just me that constantly needs to justify his existence in
this group?

Does someone need to be that much of a user of a language in order to discuss
its design or its features or its efficiency, or how it compares with any
other? You can do that from without as well as from within.

Anyway I'm not here that often, I pop in from time to time when something
interesting comes that I feel I can comment about. And yes I sometimes do that
as a diversion because I enjoy this discussing this stuff. Why, is that
allowed?

As for why Python, it's the dynamic language I'm most familiar with, and I've
been following it since the 1990s.

Here's a small selection of threads I've posted in:

  Why not allow empty code blocks

  Python and the need for speed

  Building CPython

  What is a function parameter =[] for

  Considering migrating to Python from Visual Basic...

  How to read from a file to an arbitrary delimiter efficiently

  Python 2.x or 3.x, which is faster?

  The cost of Dynamism

  Case Statements  [15-Mar-2016]

The last is interesting. The OP there follows up with:

  "You have apparently mistaken me for someone who's worried.
  I don't use Python, I was just curious as to why a construct
  that is found, not only to be useful in 95% of other languages,
  but is generally considered more flexible and readable than the
  if-elif, was missing in Python.  (your link 'Switch Statement
  Code Smell' not withstanding)"

Many of the posters are explaining why Python doesn't have it, why they think
the feature is so poor, and ways to get around the lack of it. Mine defend the
feature.

You're saying I shouldn't be allowed to put an alternative point of view
because I don't use Python enough? I would say that because I
/implement/ such features all the time in other languages, that my
opinion is worthwhile.

But people do seem to like to wind me up, and I like to defend my corner, so
posts tend to proliferate.

--
bart.

-+- BBBS/Li6 v4.10 Toy-3
 + Origin: Prism bbs (1:261/38)

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Gregory Ewing]

  To: Bart
From: "Gregory Ewing" 

  To: Bart
From: Gregory Ewing 

Bart wrote:
> But 40 years
> ago it was just 'readln a,b,c'; it was just taken for granted.

The problem with something like that is that it's really only useful for
throwaway code. For any serious application, you need to deal with the
possibility of malformed input, producing helpful diagnostics, etc. And often
the input isn't going to be in such a uniform format that you know exactly what
 to expect next.

So it's debable whether it's a good idea to put something with such limited
applicability into the core language or standard library.

Handling input well is fundamentally much more complicated than producing
output. I don't think this is as "basic" as you make out.

--
Greg

-+- BBBS/Li6 v4.10 Toy-3
 + Origin: Prism bbs (1:261/38)

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Gregory Ewing]

  To: Bart
From: "Gregory Ewing" 

  To: Bart
From: Gregory Ewing 

Bart wrote:
> Wow. (Just think of all the times you write a function containing a neat
> bunch of local functions, every time it's called it has to create a new
> function instances for each of those functions, even if they are not used.)

Fortunately, function objects are small and cheap, essentially just a couple of
 object references. The overhead of creating one is probably about the same as
creating an empty list. If your function is complicated enough to benefit from
local functions, the cost is going to be swamped by the rest of the work being
done.

--
Greg

-+- BBBS/Li6 v4.10 Toy-3
 + Origin: Prism bbs (1:261/38)

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Bart]

  To: boB Stepp
From: "Bart" 

  To: boB Stepp
From: Bart 

On 23/06/2018 20:52, boB Stepp wrote:
> I've finally found time to examine this rather long, rambling thread.

>> There is a place for various levels of programming language. I'm saying that
Python which is always touted as a 'simple' language suitable for beginners, is
 missing a surprising number of basics.

> I still feel like a rank beginner, but on the Tutor list some
> disagree.

The first programming exercise I ever did involved asking for three numbers,
then determining whether those numbers could form the sides of a triangle.

Then [40 years ago], the easy part was reading the three numbers. Now that
would be the more challenging part.

This is one of the basics that is missing. Getting around it is not hard, but
it's some messing about and it's a distraction. But 40 years ago it was just
'readln a,b,c'; it was just taken for granted.

(It make seem quaint in these days of GUIs, gestures, and voice recognition to
be reading a line at a time, but you will need it still for text file i/o.)

> Anyway, so far Python has not lacked for anything I have needed so
> far.

I'd be surprised if Python lacked anything; there can't be anything that
someone has thought of that is either built-in or bolted on, if not always that
 elegantly or that efficiently.

However, imagine having to use a language which didn't have assignments as you
are used to, and that you would expect to exist. Then you might well remark
that it's missing something that you regard as a basic, while the proponents of
 that language point out that it doesn't stop you writing programs; it just
needs a different approach.

(I believe that you can write any program using just IF-GOTO statements and
ASSIGNMENT statements, and no other flow control (given suitable data-types and
 means of I/O). But if you wanted to try out an interesting experiment along
those lines (eg. transcribe any flowchart to code), a large number of
languages, including Python, make it hard because 'goto' is missing.)

> All I can say is I have yet to find much at all in Python cumbersome
> or bewildering.

No? How many ways are there in Python, including third party add-ons, of
working with record-like objects?

> As an aside to Bart, if you strongly feel that Python is missing a
> really useful feature, then why don't you do the usual thing, start a
> very specific thread about just that feature (Not just a collection of
> things you like in one of your languages.), and if you manage to
> persuade the community of its usefulness, then write up a PEP about
> it?  Just saying ... ~(:>))

I'm not a user. My interest is in design and implementation, especially of
interpreters, and especially of efficient ones. A lot of things that Python
could do with are made very difficult by the existing design of that language.
Being so dynamic has a lot to answer for.

So I don't envy the job of the people who really have to move the language
forward. That doesn't mean I can't argue with people who say that Python
doesn't really need (say) Switch. (I guess the Blub paradox works both ways...)

--
bart

-+- BBBS/Li6 v4.10 Toy-3
 + Origin: Prism bbs (1:261/38)

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Ben Bacarisse]

  To: Bart
From: "Ben Bacarisse" 

  To: Bart
From: Ben Bacarisse 

Bart  writes:

> On 23/06/2018 23:25, Ben Bacarisse wrote:
>> Bart  writes:
>>
>>> On 23/06/2018 21:13, Chris Angelico wrote:
 On Sat, Jun 23, 2018 at 10:41 PM, Bart  wrote:
>>>
> (At what point would that happen anyway; if you do this:
>>>
 NONE of your examples are taking copies of the function. They all are
 making REFERENCES to the same function. That is all.
>>>
>>> This is about your notion that invocations of the same function via
>>> different references, should maintain their own versions of the
>>> function's 'static' data.
>>>
>>> Since these references are created via the return g statement here:
>>>
>>>  def f():
>>>  def g():
>>>  
>>>  return g
>>>
>>> (say to create function references i and j like this:
>>>
>>>  i = f()
>>>  j = f()
>>> )
>>>
>>> I'm assuming that something special must be happening. Otherwise, how
>>> does f() know which reference it's being called via?
>>>
>>> What is different, what extra bit of information is provided when f()
>>> is invoked via i() or j()?
>>
>> f is not being invoked by either i() or j().  i = f() binds i to the
>> function returned by f.  That's a newly minted function.  In languages
>> like Python, executing def creates a function.
>
> Do you mean that if the same 'def' block is re-executed, it will
> create a different instance of the function? (Same byte-code, but a
> different set of everything else the function uses.)

Logically, yes.

> Wow. (Just think of all the times you write a function containing a
> neat bunch of local functions, every time it's called it has to create
> a new function instances for each of those functions, even if they are
> not used.)

I am surprised that this surprises you, and equally surprised that you seem to
think it's going to be in some way grossly inefficient.

--
Ben.

-+- BBBS/Li6 v4.10 Toy-3
 + Origin: Prism bbs (1:261/38)

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Ben Bacarisse]

  To: Bart
From: "Ben Bacarisse" 

  To: Bart
From: Ben Bacarisse 

Bart  writes:

> On 23/06/2018 21:13, Chris Angelico wrote:
>> On Sat, Jun 23, 2018 at 10:41 PM, Bart  wrote:
>
>>> (At what point would that happen anyway; if you do this:
>
>> NONE of your examples are taking copies of the function. They all are
>> making REFERENCES to the same function. That is all.
>
> This is about your notion that invocations of the same function via
> different references, should maintain their own versions of the
> function's 'static' data.
>
> Since these references are created via the return g statement here:
>
> def f():
> def g():
> 
> return g
>
> (say to create function references i and j like this:
>
> i = f()
> j = f()
> )
>
> I'm assuming that something special must be happening. Otherwise, how
> does f() know which reference it's being called via?
>
> What is different, what extra bit of information is provided when f()
> is invoked via i() or j()?

f is not being invoked by either i() or j().  i = f() binds i to the function
returned by f.  That's a newly minted function.  In languages like Python,
executing def creates a function.  In your example, i and j refer to different
functions.  If the function temporarily named g has "own" variables ("static"
in C), then each such function should have its own.  That was the point of the
example much further up.

The effect can simulated like this:

def make_counter():
def c():
c.x += 1
return c.x
c.x = 0
return c

i = make_counter()
j = make_counter()

print(i(), i(), j(), i())


--
Ben.

-+- BBBS/Li6 v4.10 Toy-3
 + Origin: Prism bbs (1:261/38)

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Bart]

  To: Ben Bacarisse
From: "Bart" 

  To: Ben Bacarisse
From: Bart 

On 23/06/2018 23:25, Ben Bacarisse wrote:
> Bart  writes:
>
>> On 23/06/2018 21:13, Chris Angelico wrote:
>>> On Sat, Jun 23, 2018 at 10:41 PM, Bart  wrote:
>>
 (At what point would that happen anyway; if you do this:
>>
>>> NONE of your examples are taking copies of the function. They all are
>>> making REFERENCES to the same function. That is all.
>>
>> This is about your notion that invocations of the same function via
>> different references, should maintain their own versions of the
>> function's 'static' data.
>>
>> Since these references are created via the return g statement here:
>>
>>  def f():
>>  def g():
>>  
>>  return g
>>
>> (say to create function references i and j like this:
>>
>>  i = f()
>>  j = f()
>> )
>>
>> I'm assuming that something special must be happening. Otherwise, how
>> does f() know which reference it's being called via?
>>
>> What is different, what extra bit of information is provided when f()
>> is invoked via i() or j()?
>
> f is not being invoked by either i() or j().  i = f() binds i to the
> function returned by f.  That's a newly minted function.  In languages
> like Python, executing def creates a function.

Do you mean that if the same 'def' block is re-executed, it will create a
different instance of the function? (Same byte-code, but a different set of
everything else the function uses.)

Wow. (Just think of all the times you write a function containing a neat bunch
of local functions, every time it's called it has to create a new function
instances for each of those functions, even if they are not used.)

Anyway just for regular statics, the following appears to work. Not ideal, but
simpler than some alternatives:

def f():
 if not hasattr(f,'x'): f.x=0
 f.x += 1
 return f.x

--
bart.

-+- BBBS/Li6 v4.10 Toy-3
 + Origin: Prism bbs (1:261/38)

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Bart]

  To: Chris Angelico
From: "Bart" 

  To: Chris Angelico
From: Bart 

On 23/06/2018 21:13, Chris Angelico wrote:
> On Sat, Jun 23, 2018 at 10:41 PM, Bart  wrote:

>> (At what point would that happen anyway; if you do this:

> NONE of your examples are taking copies of the function. They all are
> making REFERENCES to the same function. That is all.

This is about your notion that invocations of the same function via different
references, should maintain their own versions of the function's 'static' data.

Since these references are created via the return g statement here:

 def f():
 def g():
 
 return g

(say to create function references i and j like this:

 i = f()
 j = f()
)

I'm assuming that something special must be happening. Otherwise, how does f()
know which reference it's being called via?

What is different, what extra bit of information is provided when f() is
invoked via i() or j()?

--
bart

-+- BBBS/Li6 v4.10 Toy-3
 + Origin: Prism bbs (1:261/38)

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[jkn]

  To: Chris Angelico
From: jkn 

On Monday, June 25, 2018 at 4:23:57 PM UTC+1, Chris Angelico wrote:
> On Mon, Jun 25, 2018 at 11:15 PM, jkn  wrote:
> > (as well as pedanticism ;-o).
>
> Pedantry.
>
> ChrisA
> (You know I can't let that one pass.)

I was chanel[l]ing the TimBot, as any fule kno...

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[Alister]

  To: Mark Lawrence
From: Alister 

On Mon, 25 Jun 2018 11:42:27 +0100, Mark Lawrence wrote:

> On 25/06/18 10:10, Alister via Python-list wrote:
>> On Mon, 25 Jun 2018 11:36:25 +0400, Abdur-Rahmaan Janhangeer wrote:
>>
>>> i think he means like for a loop to iterate over a list you might do
>>>
>>> list = [1,2,3]
>>> for i in range(len(list)):
>>>  print(list[i])
>>>
>>>
>>> but the you might as well go for the simpler :
>>>
>>>
>>> for elem in list:
>>>
>>>   print(elem)
>>>
>>> Abdur-Rahmaan Janhangeer https://github.com/Abdur-rahmaanJ
>>>
>>>
>>>
>>>
>> for i in range(len(list)): is a python anti-pattern it is almost a 100%
>> guarantee that you are doing something wrong*
>>
>> *as with all rules of thumb there is probably at least 1 exception that
>> the python experts will now point out.
>>
>>
>>
> The exception is that if you really do need the index, you write:-
>
> for i, elem in enumerate(list):

I would not call that an exception, that is still the correct way to obtain the
 index during the loop




--
I saw a subliminal advertising executive, but only for a second.
-- Steven Wright

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[Chris Angelico]

From: Chris Angelico 

On Mon, Jun 25, 2018 at 11:15 PM, jkn  wrote:
> (as well as pedanticism ;-o).

Pedantry.

ChrisA
(You know I can't let that one pass.)

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[jkn]

  To: Paul Moore
From: jkn 

On Monday, June 25, 2018 at 12:17:29 PM UTC+1, Paul  Moore wrote:
> On 25 June 2018 at 11:53, Steven D'Aprano
>  wrote:
>
> > And the specific line you reference is *especially* a joke, one which
> > flies past nearly everyone's head:
> >
> > There should be one-- and preferably only one --obvious way to do it.
> >
> >
> > Notice the dashes? There are *two* traditional ways to use an pair of em-
> > dashes for parenthetical asides:
> >
> > 1. With no space--like this--between the parenthetical aside and the text;
> >
> > 2. With a single space on either side -- like this -- between the aside
> > and the rest of the text.
> >
> > Not satisfied with those two ways, Tim invented his own.
> >
> >
> > https://bugs.python.org/issue3364
> >
> >
> > (Good grief, its been nearly ten years since that bug report. I remember
> > it like it was yesterday.)
>
> Thank you for that bit of history! I never knew that (and indeed had
> missed that part of the joke). Tim's contributions to Python are
> always to be treasured :-)
>
> Paul

Goodness, I too had missed that particular (admittedly subtle) joke, and I have
 an interest in orthography and typesetting etc. (as well as pedanticism ;-o).

Yes, Tim Peters' contribution to python, and this newsgroup in days of yore,
were to be treasured. Luckily the wisdom and measured tone he and other early
pioneers modelled are (mostly) still with us here on comp.lang.python.

Jon N (here since 1999 or so...)

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[Grant Edwards]

From: Grant Edwards 

On 2018-06-25, Steven D'Aprano  wrote:

> And the specific line you reference is *especially* a joke, one which
> flies past nearly everyone's head:
>
>  There should be one-- and preferably only one --obvious way to do it.
>
> Notice the dashes? There are *two* traditional ways to use an pair
> of em- dashes for parenthetical asides:
>
> 1. With no space--like this--between the parenthetical aside and the text;
>
> 2. With a single space on either side -- like this -- between the aside
> and the rest of the text.
>
> Not satisfied with those two ways, Tim invented his own.
>
> https://bugs.python.org/issue3364

Brilliant!

I don't know how I missed that.  I'm not sure which would be more impressive:
that Tim thought up the joke as described, or that it was made up ex post
facto.  Either one is brilliant.

--
Grant Edwards   grant.b.edwardsYow! I once decorated my
  at   apartment entirely in ten
  gmail.comfoot salad forks!!

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[Steven D'Aprano]

From: Steven D'Aprano 

On Sun, 24 Jun 2018 10:46:09 -0700, Jim Lee wrote:

> On 06/24/2018 04:35 AM, Steven D'Aprano wrote:
>>
>> Indeed. That's one of the beauties of Python -- even when there's an
>> advanced way to do it, there's generally a simple way too.
>>
>>
> What happened to the Python maxim "There should be oneΓ ÷and preferably
> only oneΓ ÷obvious way to do it"?

What about it?

"There should be (at least) one (OBVIOUS WAY) to do it" does not preclude there
 being a million other non-obvious ways to do it. Even if we prefer only one
(OBVIOUS WAY).


Besides, its the Zen of Python. We should all know about Zen:

In the second scroll of Wen the Eternally Surprised a story
is written concerning one day when the apprentice Clodpool,
in a rebellious mood, approached Wen and spake thusly:
"Master, what is the difference between a humanistic, monastic
system of belief in which wisdom is sought by means of an
apparently nonsensical system of questions and answers, and a
lot of mystic gibberish made up on the spur of the moment?"
Wen considered this for some time, and at last said: "A fish!"
And Clodpool went away, satisfied.

-- (Terry Pratchett, "Thief of Time")



Nearly everybody misses the fact that the Zen is a joke, not to be taken
*too* seriously. A particularly subtle joke, but still a joke.

https://www.wefearchange.org/2010/06/import-this-and-zen-of-python.html


And the specific line you reference is *especially* a joke, one which flies
past nearly everyone's head:

There should be one-- and preferably only one --obvious way to do it.


Notice the dashes? There are *two* traditional ways to use an pair of em-
dashes for parenthetical asides:

1. With no space--like this--between the parenthetical aside and the text;

2. With a single space on either side -- like this -- between the aside and the
 rest of the text.

Not satisfied with those two ways, Tim invented his own.


https://bugs.python.org/issue3364


(Good grief, its been nearly ten years since that bug report. I remember it
like it was yesterday.)





--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing it everywhere."
 -- Jon Ronson

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[Paul Moore]

From: Paul Moore 

On 25 June 2018 at 11:53, Steven D'Aprano
 wrote:

> And the specific line you reference is *especially* a joke, one which
> flies past nearly everyone's head:
>
> There should be one-- and preferably only one --obvious way to do it.
>
>
> Notice the dashes? There are *two* traditional ways to use an pair of em-
> dashes for parenthetical asides:
>
> 1. With no space--like this--between the parenthetical aside and the text;
>
> 2. With a single space on either side -- like this -- between the aside
> and the rest of the text.
>
> Not satisfied with those two ways, Tim invented his own.
>
>
> https://bugs.python.org/issue3364
>
>
> (Good grief, its been nearly ten years since that bug report. I remember
> it like it was yesterday.)

Thank you for that bit of history! I never knew that (and indeed had missed
that part of the joke). Tim's contributions to Python are always to be
treasured :-)

Paul

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Bart]

  To: Steven D'Aprano
From: Bart 

On 25/06/2018 01:52, Steven D'Aprano wrote:
> On Sun, 24 Jun 2018 21:21:57 +0100, Bart wrote:
>
>> I've had half a dozen users
>
> Come back when you've had *half a million users* then we'll take your
> experiences seriously.

That being the case with Python (maybe even ten times as many), why would
anybody here care what I say about it?

So it doesn't a matter at all that you can do:

math.pi = "Hmm, Pie!"

because there are so many users who don't care.

(Actually I can't remember how many users I had. The language was freely
available as part of an application of which we sold thousands, and was
actually used to help its implementation.

There might have been a dozen people who used it to write add-on products as
well as others who tinkered with it. But it was not then a stand-alone
language; it was part of a 3D graphics app.)

> https://blog.pythonanywhere.com/67/
>
> https://stackoverflow.blog/2017/09/06/incredible-growth-python/
>
> For a language which does everything wrong, it must be doing something
> right.

Well, you certainly you get your money's worth in terms of features and
add-ons.

--
bart

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[Alister]

  To: Abdur-Rahmaan Janhangeer
From: Alister 

On Mon, 25 Jun 2018 11:36:25 +0400, Abdur-Rahmaan Janhangeer wrote:

> i think he means like for a loop to iterate over a list you might do
>
> list = [1,2,3]
> for i in range(len(list)):
> print(list[i])
>
>
> but the you might as well go for the simpler :
>
>
> for elem in list:
>
>  print(elem)
>
> Abdur-Rahmaan Janhangeer https://github.com/Abdur-rahmaanJ
>
>
>

for i in range(len(list)): is a python anti-pattern it is almost a 100%
guarantee that you are doing something wrong*

*as with all rules of thumb there is probably at least 1 exception that
the python experts will now point out.


--
Lend money to a bad debtor and he will hate you.

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[Abdur-Rahmaan Janhangeer]

From: Abdur-Rahmaan Janhangeer 

we must maybe fibd an example where both are pythonic but one is simpler unless
 my type of example was intented by @steve

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ


>

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[Jim Lee]

From: Jim Lee 



On 06/24/2018 04:35 AM, Steven D'Aprano wrote:
>
> Indeed. That's one of the beauties of Python -- even when there's an
> advanced way to do it, there's generally a simple way too.
>
>
What happened to the Python maxim "There should be oneΓ ÷and preferably only
oneΓ ÷obvious way to do it"?

-Jim

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[Abdur-Rahmaan Janhangeer]

From: Abdur-Rahmaan Janhangeer 

i think he means like for a loop to iterate over a list you might do

list = [1,2,3]
for i in range(len(list)):
print(list[i])


but the you might as well go for the simpler :


for elem in list:

 print(elem)

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ


>

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Steven D'Aprano]

From: Steven D'Aprano 

On Sun, 24 Jun 2018 21:21:57 +0100, Bart wrote:

> I've had half a dozen users

Come back when you've had *half a million users* then we'll take your
experiences seriously.

https://blog.pythonanywhere.com/67/

https://stackoverflow.blog/2017/09/06/incredible-growth-python/

For a language which does everything wrong, it must be doing something right.


--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing it everywhere."
 -- Jon Ronson

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Bart]

  To: Steven D'Aprano
From: Bart 

On 24/06/2018 20:02, Steven D'Aprano wrote:
> On Sun, 24 Jun 2018 19:37:33 +0100, Bart wrote:
>
>> I want to program in /my/ style
>
> Python is not Java, and Java is not Python either. Nor is it "Bart's
> Language", or C, or Forth, or Lisp, or bash.
>
> https://dirtsimple.org/2004/12/python-is-not-java.html
>
> https://dirtsimple.org/2004/12/java-is-not-python-either.html
>
>
> To get the best out of any language, you should try to program to its
> strengths, in the idioms that work, not insist on writing FooLanguage
> code in BarLanguage.

I like to write in clear code in a manner that anyone can follow (although I'm
mainly thinking about myself). That means not using idioms specific to a
language and hard to translate to anything else.

Why might someone want to use something like Python rather than, for example,
C? Here are some reasons:

* Clearer syntax less full of punctuation
* Simpler for-loops
* Module import system
* Much faster edit-run cycle
* Dynamic types to eliminate most variable declarations
* No need for forward declarations for functions
* First class string handling
* First class list handling
* Flexible arrays/lists (not strings as they are immutable)
* Namespaces
* Default and keyword parameters
* Can forget about using pointers

That would be plenty to get started with, and enough to make it worthwhile to
use the dynamic language provided its libraries and its performance are
suitable for the task.

But so far it has not been necessary to explicitly use a Pythonic style of
coding or any of its esoteric features.

> You'd probably be pretty frustrated if one of your users (ahem) insisted
> on duplicating the form and structure of their bash scripts in your
> language, and complaining bitterly about how your language sucks because
> it isn't bash.

I've had half a dozen users and I don't recall any particular problems nor any
complaints. The language, although cruder then, must still have been sweeter to
 use than what was typically available at the time.

--
bart

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[Stefan Ram]

  To: Stefan Ram
From: r...@zedat.fu-berlin.de (Stefan Ram)

r...@zedat.fu-berlin.de (Stefan Ram) writes:
>Still, one must not forget that learning Python encompasses
>all the hard work it takes to learn how to program in every
>language.

  "Beginner", however, is a very vague term. A good scientist
  or engineer who (for some reason) never programmed before
  (or, at least, not in Python) is a totally different kind
  of a "beginner" than a secretary, a garbage collector or
  a schoolchild. Quoting:

  Γ╗I've found that some of the best [Software ]developers
  of all are English majors. They'll often graduate with
  no programming experience at all, and certainly without
  a clue about the difference between DRAM and EPROM.

  But they can write. That's the art of conveying
  information concisely and clearly. Software development
  and writing are both the art of knowing what you're
  going to do, and then lucidly expressing your ideas.Γ½

http://praisecurseandrecurse.blogspot.com/2007/03/english-majors-as-programmers
.html

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[Abdur-Rahmaan Janhangeer]

From: Abdur-Rahmaan Janhangeer 

naaa it was not meant to be python ^^

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ


>
>

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Bart]

  To: Stefan Ram
From: "Bart" 

  To: Stefan Ram
From: Bart 

On 23/06/2018 14:32, Stefan Ram wrote:
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>> def f():
>> def g():
>> g.x += 1
>> return g.x
>> g.x = 0
>> return g
>
>Or, "for all g to share the same x":
>
>main.py
>
> def f():
>  def g():
>  f.x += 1
>  return f.x
>  return g
> f.x = 0

OK, problem solved: we just use attributes of function objects rather than
locally static variables (I didn't even know that was possible). These
apparently can be created, accessed and modified from anywhere in the program.

The only provisos are that functions with 'static' must be written as nested
functions and the name of the function must be returned via the enclosing
function in some setup code.

The initialising of the static is showed as happening in global space in your
example, but may be possible to move that to the enclosing function. (For
example, when the static data is a local table.)

However, here's a reminder of what the feature looks like implemented properly:

 def g()
 static x = 0
 x += 1
 return x

 print (g())

No set up of g needed. 'static' can be added to any existing function without
changing how its used. And it can be removed without having to dismantled all
the extra machinery.

/And/ the access to x inside g() can be a fast local lookup not an
attribute lookup (unless implemented on top of global variables).

--
bart

-+- BBBS/Li6 v4.10 Toy-3
 + Origin: Prism bbs (1:261/38)

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Stefan Ram]

  To: Stefan Ram
From: "Stefan Ram" 

  To: Stefan Ram
From: r...@zedat.fu-berlin.de (Stefan Ram)

r...@zedat.fu-berlin.de (Stefan Ram) writes:
>def f():
>def g():
>g.x += 1
>return g.x
>g.x = 0
>return g

  Or, "for all g to share the same x":

  main.py

def f():
def g():
f.x += 1
return f.x
return g
f.x = 0

g = f()
print( g() )
print( g() )
print( g() )

g1 = f()
print( g1() )
print( g1() )
print( g1() )

  transcript

1
2
3
4
5
6

-+- BBBS/Li6 v4.10 Toy-3
 + Origin: Prism bbs (1:261/38)

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Stefan Ram]

  To: Steven D'Aprano
From: "Stefan Ram" 

  To: Steven D'Aprano
From: r...@zedat.fu-berlin.de (Stefan Ram)

Steven D'Aprano  writes:
>def f():
>static x = 0
>def g():
>x += 1
>return x
>return g

  What one can do today:

  main.py

def g():
g.x += 1
return g.x
g.x = 0

print( g() )
print( g() )
print( g() )

  transcript

1
2
3

  main.py

def f():
def g():
g.x += 1
return g.x
g.x = 0
return g

g = f()
print( g() )
print( g() )
print( g() )

  transcript

1
2
3

-+- BBBS/Li6 v4.10 Toy-3
 + Origin: Prism bbs (1:261/38)

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Bart]

  To: Steven D'Aprano
From: "Bart" 

  To: Steven D'Aprano
From: Bart 

On 23/06/2018 04:51, Steven D'Aprano wrote:
> On Wed, 20 Jun 2018 14:18:19 +1000, Chris Angelico wrote:
>
>> Ah. Yeah, that would be a plausible feature to add to Python. But in C,
>> a static variable is basically the same thing as a global variable,
>> except that its name is scoped to the function. There is only one of it.
>> What happens in Python? For instance:
>>
>> def f():
>>  def g():
>>  static x = 0
>>  x += 1
>>  return x
>>  return g
>>
>> Does the static variable exist once for each instance of g()? If so,
>> it'll behave like a closure variable; if not, it'll behave like a
>> global. Either way, I'm pretty much certain that people will expect the
>> other.
>
> Yes, but given the normal execution model of Python, only one solution is
> valid. Since the function g is created fresh each time f is called, each
> one gets a fresh static x.
>
> If you want all the g's to share the same x, you would write:
>
> def f():
>  static x = 0
>  def g():
>  x += 1
>  return x
>  return g
>
>
> In this case, every invocation of f shares the same static x, and all the
> g's refer to that same x, using the ordinary closure mechanism. In the
> earlier case, each invocation of f creates a brand new g with its own x.
>
> Simple and elegant.
>
> This could at last get rid of that useful but ugly idiom:
>
>  def function(real, arguments, len=len, int=int, str=str):
>  ...
>
> if we allowed the "static" declaration to access the values from the
> surrounding scope:
>
>  def function(real, arguments):
>  static len=len, int=int, str=str
>
> But I think nicer than that would be a decorator:
>
>  @static(len=len, int=int, str=str)
>  def function(real, arguments):
>  ...
>
> which adds local variables len, int, str to the function, with the given
> values, and transforms all the bytecode LOAD_NAME len to LOAD_FAST len
> (or whatever).
>
> (We might need a new bytecode to SET_STATIC.)
>
> That would be a nice bytecode hack to prove the usefulness of the concept!

This is an example of a simple concept getting so out of hand that it will
either never be implemented, or the resulting implementation becomes
impractical to use.

This is what we're trying to do:

 def nextx():
 static x = 0
 x += 1
 return x

And this is the simplest equivalent code in current Python that will cater for
99% of uses:

 _nextx_x = 0

 def nextx():
 global _nextx_x
 _nextx_x += 1
 return _nextx_x

No nested functions. No generating new instances of functions complete with a
new set of statics each time you happen to refer to the name. (Which sounds to
me as useful as creating a new instance of an import when you copy its name,
complete with a separate set of its globals. Isn't this stuff what classes are
for?)

(At what point would that happen anyway; if you do this:

 g = nextx  # hypothetical version would static

it will create a new instance of 'nextx'. But it won't create one here, just
before () is applied:

 nextx() # ?

Or how about here:

 listoffunctions = (nextx1, nextx2, nextx3)

 listoffunctions[i]() # ?

)

--
bartc

-+- BBBS/Li6 v4.10 Toy-3
 + Origin: Prism bbs (1:261/38)

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Chris Angelico]

From: "Chris Angelico" 

From: Chris Angelico 

On Sat, Jun 23, 2018 at 1:51 PM, Steven D'Aprano
 wrote:
> On Wed, 20 Jun 2018 14:18:19 +1000, Chris Angelico wrote:
>
>> Ah. Yeah, that would be a plausible feature to add to Python. But in C,
>> a static variable is basically the same thing as a global variable,
>> except that its name is scoped to the function. There is only one of it.
>> What happens in Python? For instance:
>>
>> def f():
>> def g():
>> static x = 0
>> x += 1
>> return x
>> return g
>>
>> Does the static variable exist once for each instance of g()? If so,
>> it'll behave like a closure variable; if not, it'll behave like a
>> global. Either way, I'm pretty much certain that people will expect the
>> other.
>
> Yes, but given the normal execution model of Python, only one solution is
> valid. Since the function g is created fresh each time f is called, each
> one gets a fresh static x.
>
> If you want all the g's to share the same x, you would write:
>
> def f():
> static x = 0
> def g():
> x += 1
> return x
> return g
>
>
> In this case, every invocation of f shares the same static x, and all the
> g's refer to that same x, using the ordinary closure mechanism. In the
> earlier case, each invocation of f creates a brand new g with its own x.
>
> Simple and elegant.
>
> This could at last get rid of that useful but ugly idiom:
>
> def function(real, arguments, len=len, int=int, str=str):
> ...
>
> if we allowed the "static" declaration to access the values from the
> surrounding scope:
>
> def function(real, arguments):
> static len=len, int=int, str=str
>
> But I think nicer than that would be a decorator:
>
> @static(len=len, int=int, str=str)
> def function(real, arguments):
> ...
>
> which adds local variables len, int, str to the function, with the given
> values, and transforms all the bytecode LOAD_NAME len to LOAD_FAST len
> (or whatever).
>
> (We might need a new bytecode to SET_STATIC.)
>
> That would be a nice bytecode hack to prove the usefulness of the concept!
>

Okay, that makes sense. So in a way, static variables would be like closure
variables with an invisible outer function. These would be roughly equivalent:

def f():
static x = 0
x += 1
return x

def make_f():
x = 0
def f():
nonlocal x
x += 1
return x
return f
f = make_f()

I don't think LOAD_FAST is appropriate (those cells get disposed of when the
function returns), but transforming those lookups into closure lookups would be
 a reasonable way to do it I think.

For getting rid of the "len=len" trick, though, I would REALLY like to
transform those into LOAD_CONST. That'd be a fun bytecode hack all on its own.
In fact, I'm gonna have a shot at that. An "early bind these names" decorator.

ChrisA

-+- BBBS/Li6 v4.10 Toy-3
 + Origin: Prism bbs (1:261/38)

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Chris Angelico]

From: "Chris Angelico" 

From: Chris Angelico 

On Sat, Jun 23, 2018 at 2:16 PM, Chris Angelico  wrote:
> For getting rid of the "len=len" trick, though, I would REALLY like to
> transform those into LOAD_CONST. That'd be a fun bytecode hack all on
> its own. In fact, I'm gonna have a shot at that. An "early bind these
> names" decorator.

Well, that was easier than I expected. Which almost certainly means I haven't
properly solved the problem.

https://github.com/Rosuav/shed/blob/master/consts.py

Let's start finding all the edge cases that don't work, so I can work on fixing
 them :)

ChrisA

-+- BBBS/Li6 v4.10 Toy-3
 + Origin: Prism bbs (1:261/38)

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Static variables [was Re: syntax difference]

[Steven D'Aprano]

From: "Steven D'Aprano" 

From: Steven D'Aprano 

On Wed, 20 Jun 2018 14:18:19 +1000, Chris Angelico wrote:

> Ah. Yeah, that would be a plausible feature to add to Python. But in C,
> a static variable is basically the same thing as a global variable,
> except that its name is scoped to the function. There is only one of it.
> What happens in Python? For instance:
>
> def f():
> def g():
> static x = 0
> x += 1
> return x
> return g
>
> Does the static variable exist once for each instance of g()? If so,
> it'll behave like a closure variable; if not, it'll behave like a
> global. Either way, I'm pretty much certain that people will expect the
> other.

Yes, but given the normal execution model of Python, only one solution is
valid. Since the function g is created fresh each time f is called, each one
gets a fresh static x.

If you want all the g's to share the same x, you would write:

def f():
static x = 0
def g():
x += 1
return x
return g


In this case, every invocation of f shares the same static x, and all the g's
refer to that same x, using the ordinary closure mechanism. In the earlier
case, each invocation of f creates a brand new g with its own x.

Simple and elegant.

This could at last get rid of that useful but ugly idiom:

def function(real, arguments, len=len, int=int, str=str):
...

if we allowed the "static" declaration to access the values from the
surrounding scope:

def function(real, arguments):
static len=len, int=int, str=str

But I think nicer than that would be a decorator:

@static(len=len, int=int, str=str)
def function(real, arguments):
...

which adds local variables len, int, str to the function, with the given
values, and transforms all the bytecode LOAD_NAME len to LOAD_FAST len (or
whatever).

(We might need a new bytecode to SET_STATIC.)

That would be a nice bytecode hack to prove the usefulness of the concept!


--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing it everywhere."
 -- Jon Ronson

-+- BBBS/Li6 v4.10 Toy-3
 + Origin: Prism bbs (1:261/38)

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Richard Damon]

From: Richard Damon 

On 6/24/18 3:02 PM, Steven D'Aprano wrote:
> On Sun, 24 Jun 2018 19:37:33 +0100, Bart wrote:
>
>> I want to program in /my/ style
> Python is not Java, and Java is not Python either. Nor is it "Bart's
> Language", or C, or Forth, or Lisp, or bash.
>
> https://dirtsimple.org/2004/12/python-is-not-java.html
>
> https://dirtsimple.org/2004/12/java-is-not-python-either.html
>
>
> To get the best out of any language, you should try to program to its
> strengths, in the idioms that work, not insist on writing FooLanguage
> code in BarLanguage.
>
> Hammers are great tools. So are screwdrivers. But you wouldn't use a
> screwdriver to hammer nails, or hammer screws, would you?
>
> You'd probably be pretty frustrated if one of your users (ahem) insisted
> on duplicating the form and structure of their bash scripts in your
> language, and complaining bitterly about how your language sucks because
> it isn't bash.
>
>From what I have seen from Bart in other groups, Bart want to write in
'Bart' using existing languages and is frustrated that no one (but him)
has written a language exactly to his specs.

--
Richard Damon

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[Bart]

  To: Abdur-Rahmaan Janhangeer
From: Bart 

On 24/06/2018 19:36, Abdur-Rahmaan Janhangeer wrote:
> see for example
>
> https://en.m.wikipedia.org/wiki/Bresenham%27s_line_algorithm
>
> see the pseudocode, i was implementing some raster algos when i found
> myself aux anges
>
> so close to py. i guess it was written in prehistoric times with the author
> trying to simplify stuffs

I'm sorry, but that kind of code is a mish-mash of old Algol/Pascal-style
languages. I doubt it was meant to be Python.

Python doesn't have a monopoly on clear syntax.

This is the first example from that link (I've taken out comments):

  function line(x0, y0, x1, y1)
  real deltax := x1 - x0
  real deltay := y1 - y0
  real deltaerr := abs(deltay / deltax)
  real error := 0.0
  int y := y0
  for x from x0 to x1
  plot(x,y)
  error := error + deltaerr
  while error Γδ╪ 0.5 then
  y := y + sign(deltay) * 1
  error := error - 1.0

This has some problems: it's using 'function' when it doesn't return a value
(those languages used 'proc' or 'procedure' in that case). It doesn't give a
type for the parameters, and it uses while/then rather than the usual while/do.

So it's rather sloppy even for pseudo code. The only similarity with Python is
the lack of block delimiters, but then with later examples they /are/ used, for
 if-else-endif.

Below, the first block is that code tweaked to a static language of mine. The
second is the same code tweaked to Python.

It was less work to adapt it my syntax rather than Python. All versions however
 use a decidedly un-Pythonic style, which means the difference between the two
below isn't that great, even though they are different languages. But imagine
trying to adapt Pythonic code to work in the other language; it would be much
harder (apart from one being dynamic and the other not).

-
  proc line(int x0, y0, x1, y1)=
  real deltax := x1 - x0
  real deltay := y1 - y0
  real deltaerr := abs(deltay / deltax)
  real error := 0.0
  int y := y0
  int x
  for x := x0 to x1 do
  plot(x,y)
  error := error + deltaerr
  while error = 0.5 do
  y := y + sign(deltay) * 1
  error := error - 1.0
  end
  end
  end
--
def line(x0, y0, x1, y1):
  deltax = x1 - x0
  deltay = y1 - y0
  deltaerr = abs(deltay / deltax)
  error = 0.0
  y = y0
  for x in range(x0,x1+1):
  plot(x,y)
  error = error + deltaerr
  while error == 0.5:
  y = y + sign(deltay) * 1
  error = error - 1.0


--
bart

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Steven D'Aprano]

From: Steven D'Aprano 

On Sun, 24 Jun 2018 19:37:33 +0100, Bart wrote:

> I want to program in /my/ style

Python is not Java, and Java is not Python either. Nor is it "Bart's Language",
 or C, or Forth, or Lisp, or bash.

https://dirtsimple.org/2004/12/python-is-not-java.html

https://dirtsimple.org/2004/12/java-is-not-python-either.html


To get the best out of any language, you should try to program to its
strengths, in the idioms that work, not insist on writing FooLanguage code in
BarLanguage.

Hammers are great tools. So are screwdrivers. But you wouldn't use a
screwdriver to hammer nails, or hammer screws, would you?

You'd probably be pretty frustrated if one of your users (ahem) insisted on
duplicating the form and structure of their bash scripts in your language, and
complaining bitterly about how your language sucks because it isn't bash.



--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing it everywhere."
 -- Jon Ronson

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Terry Reedy]

From: Terry Reedy 

On 6/24/2018 11:39 AM, Bart wrote:

Bart, I agree that people should not dogpile onto you.  As with Rick, I read
your posts or not, depending on whether I feel like being entertained at the
moment, and usually move on without comment.

> I know I'm going to get flak for bringing this up this old issue,

"Getting flak" is apparently your goal.  This is called trolling.

> remember when you used to write a for-loop and it involved creating an
> actual list of N integers from 0 to N-1 in order to iterate through
> them? Crazy.

Yep.  We first fixed it in a backward compatible way, then in a code breaking
way.  The second fix got some rough and rude flak: "This is the end of
Python!!!"

> But that has long been fixed - or so I thought.

You thought right.

> When I wrote, today:

using an ancient version of Python,

>  Γ Γ  for i in range(1): passΓ Γ Γ Γ Γ  # 100 million
>
> on Python 2, it used up 1.8GB, up to the limit of my RAM, and it took
> several minutes to regain control of my machine (and it never did
> finish).
  > You don't expect that in 2018 when executing a simple empty loop.

And you don't get that when you use a 2018 version of Python, or even the newer
 2008 version (3.0.0).  Are you really unaware of that?
> On Py 2 you have to use xrange for large ranges - that was the fix.

Yep. This was the backward compatible fix.  So what is your point?

> Somebody however must have had to gently and tactfully point out the
> issue.

For all I know, the craziness of the original design may have prompted some
rough and rude comments *BEFORE IT WAS FIXED*.  Possibly ditto for the
clutziness of the fix -- *BEFORE THE FIX WAS FIXED*.

> I'm afraid I'm not very tactful.

The above seems politely worded to me.  It is just 20 and 10 years too late,
and completely pointless, unless 'flak' is your goal.

--
Terry Jan Reedy

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Antoon Pardon]

On 26-06-18 14:47, Bart wrote:
>
> [About bitsets]
>
> Here's the set of characters allowed in a C identifier (not using
> Python syntax):
>
>   cident = {'A'..'Z', 'a'..'z', '0'..'9', '_', '9'}
>
> The characters allowed in a hex constant:
>
>   {'0'..'9', 'A'..'F', 'a'..'f'}
>
> A set representing every Unicode character, except those which can be
> C identifiers:
>
>   {0..1_114_111} - cident
>
> The latter taking only 136KB rather than 64MB as it seemed to.
>
> I don't know whether there is a direct equivalent in Python (I thought
> somebody would point it out), apart from ways to construct similar
> functionality with bit-arrays (but then, every language can have such
> sets if you take the DIY approach).

Well that is technically correct but not the whole story. Few languages allow 
you to
blend in your DIY approach, so that from a users perspective it makes little 
difference
whether the datatype was provided by the language or the result of a DIY 
approach.

So if you want your bitsets, it isn't hard to provide them and you can use them 
like
ordinary python sets. I think that is a big positive point for a language.

-- 
Antoon Pardon


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Bart]

On 26/06/2018 12:39, Chris Angelico wrote:

On Tue, Jun 26, 2018 at 9:30 PM, Bart  wrote:

On 19/06/2018 11:33, Steven D'Aprano wrote:


On Tue, 19 Jun 2018 10:19:15 +0100, Bart wrote:




* Integer sets (Pascal-like sets)

Why do you need them if you have real sets?



I tried Python sets for the first time. They seemed workable but rather
clunky to set up. But here is one problem on my CPython:

x = set(range(10_000_000))

This used up 460MB of RAM (the original 100M I tried exhausted the memory).

The advantage of Pascal-style sets is that that same set will occupy only
1.25MB, as it is a bit-map.

While sets will not usually be that big, there might be lots of small sets
and they all add up.


Cool. Make me a bitset that can represent this Python set:

{-5, -4, 6, 10, 1.5, "spam", print}


Why? It's a set of integer values with a huge range of applications.

Here's the set of characters allowed in a C identifier (not using Python 
syntax):


  cident = {'A'..'Z', 'a'..'z', '0'..'9', '_', '9'}

The characters allowed in a hex constant:

  {'0'..'9', 'A'..'F', 'a'..'f'}

A set representing every Unicode character, except those which can be C 
identifiers:


  {0..1_114_111} - cident

The latter taking only 136KB rather than 64MB as it seemed to.

I don't know whether there is a direct equivalent in Python (I thought 
somebody would point it out), apart from ways to construct similar 
functionality with bit-arrays (but then, every language can have such 
sets if you take the DIY approach).


Steven asked why I need them when there are 'real' sets, and I answered 
that.



--
bart
--
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Chris Angelico]

On Tue, Jun 26, 2018 at 9:30 PM, Bart  wrote:
> On 19/06/2018 11:33, Steven D'Aprano wrote:
>>
>> On Tue, 19 Jun 2018 10:19:15 +0100, Bart wrote:
>
>
>> * Integer sets (Pascal-like sets)
>>
>> Why do you need them if you have real sets?
>
>
> I tried Python sets for the first time. They seemed workable but rather
> clunky to set up. But here is one problem on my CPython:
>
>x = set(range(10_000_000))
>
> This used up 460MB of RAM (the original 100M I tried exhausted the memory).
>
> The advantage of Pascal-style sets is that that same set will occupy only
> 1.25MB, as it is a bit-map.
>
> While sets will not usually be that big, there might be lots of small sets
> and they all add up.

Cool. Make me a bitset that can represent this Python set:

{-5, -4, 6, 10, 1.5, "spam", print}

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Bart]

On 19/06/2018 11:33, Steven D'Aprano wrote:

On Tue, 19 Jun 2018 10:19:15 +0100, Bart wrote:



* Integer sets (Pascal-like sets)

Why do you need them if you have real sets?


I tried Python sets for the first time. They seemed workable but rather 
clunky to set up. But here is one problem on my CPython:


   x = set(range(10_000_000))

This used up 460MB of RAM (the original 100M I tried exhausted the memory).

The advantage of Pascal-style sets is that that same set will occupy 
only 1.25MB, as it is a bit-map.


While sets will not usually be that big, there might be lots of small 
sets and they all add up.



Assuming that people who aren't you can even get it to compile. When I
tried, it wouldn't compile on my computer.


(It won't any more, as there is no C version. I've had it with that 
language.)


--
bart
--
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Steven D'Aprano]

On Mon, 25 Jun 2018 18:22:56 +, Grant Edwards wrote:

> On 2018-06-24, Steven D'Aprano  wrote:
> 
>> Building functions is cheap. Cheap is not free.
>>
>> Inner functions that aren't exposed to the outside cannot be tested in
>> isolation, you can't access them through help() interactively. Given
>> the choice between:
> 
> [...]
> 
>> so not expensive, but not free either. If using an inner function has
>> no advantages to you, why pay that tiny cost for no benefit?
> 
> The benefit of an inner function is that it makes it perfectly clear to
> the reader that that function is not used outside the function where it
> is defined.  It also makes it more difficult for other fuctions to muck
> things up by changing the binding of a global name.

You say "muck things up", I say "use mocks for testing".

You're right, I shouldn't have said *no* advantages, I should have said 
"few". (Although I did use the proviso, no advantages to *you* -- this is 
a personal trade-off each programmer must make.)

Inner functions are especially useful in languages like Pascal with 
compile-time correctness tests (a.k.a. static type checking). Python 
doesn't have those, so we rely far more on unit tests. My personal trade-
off is that with no way to test inner functions, I have to assume that 
they're buggy.

(Aside from those which are simple enough to be obviously correct, as 
opposed to those that have no obvious bugs.)

Inner functions are particularly insidious because they *look* like you 
can doctest them, but you can't. I once got badly bitten by a program I 
wrote which used doctests extensively. Every doctest passed, or at least 
so I thought, and yet the program was *badly* incorrect when I ran it.

Eventually I worked out that because the doctests were in inner 
functions, they weren't being run. My TDD was in vain -- I thought my 
tests were passing, but they weren't being run at all, and the inner 
functions were riddled with bugs.

So I've always been rather wary of using inner functions since then.


> IOW, you use a local function instead of a global one for the exact same
> reasons you use local "variables" instead of global ones.

Well, I dunno... functions aren't quite like variables. Variables are 
pretty boring things, they just take a value, whereas functions can be 
quite complex entities that *do stuff*. Functions ought to be tested.

You're also likely to have far fewer functions than variables, and far 
fewer likely name clashes. You might have a dozen variables called 
"total" but only one function called "calculate_total". It would be 
terribly hard to write a program with only global variables, but it is 
rather easy to write one with only global functions, and some languages 
don't offer the ability to next functions at all.


> In Python, functions are first class objects.  Binding a name to a
> function is no different than binding it to an integer, list, string, or
> dict.  Don't the global vs. local cost vs. benefit calculations apply
> equally well to function objects as they do to those other sorts of
> objects?

I've never measured it, but I would expect that, cheap as it is, 
constructing a new function each time you need to call it would be more 
expensive than looking up a pre-existing global function.


-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[boB Stepp]

On Mon, Jun 25, 2018 at 2:37 AM Mark Lawrence  wrote:
>
> On 24/06/18 00:44, boB Stepp wrote:
> > I imagine that the
> > transition from version 2 to 3 was not undertaken halfheartedly, but
> > only after much thought and discussion since it did break backwards
> > compatibility.
> >
>
> So much so that a specific mailing list was set up just to discus the
> transition, archives here https://mail.python.org/pipermail/python-3000/

Thanks for the link, Mark.  I was not aware of this archive.  It will
probably answer some things I have always wondered about.


-- 
boB
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Chris Angelico]

On Tue, Jun 26, 2018 at 6:04 AM, Grant Edwards
 wrote:
> On 2018-06-24, Steven D'Aprano  wrote:
>
>> That's nothing, there are languages where the standard way to write
>> a for loop is to call an external program that generates a stream of
>> numeric strings separated by spaces in a subprocess, and read the
>> strings from standard input as text.
>
> What language are you bashing now?
>

I swear, some people were just bourne funny...

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Grant Edwards]

On 2018-06-24, Steven D'Aprano  wrote:

> That's nothing, there are languages where the standard way to write
> a for loop is to call an external program that generates a stream of
> numeric strings separated by spaces in a subprocess, and read the
> strings from standard input as text.

What language are you bashing now?

;)

-- 
Grant Edwards   grant.b.edwardsYow! ANN JILLIAN'S HAIR
  at   makes LONI ANDERSON'S
  gmail.comHAIR look like RICARDO
   MONTALBAN'S HAIR!

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Marko Rauhamaa]

Grant Edwards :
> IOW, you use a local function instead of a global one for the exact
> same reasons you use local "variables" instead of global ones.
>
> In Python, functions are first class objects.  Binding a name to a
> function is no different than binding it to an integer, list, string,
> or dict.  Don't the global vs. local cost vs. benefit calculations
> apply equally well to function objects as they do to those other sorts
> of objects?

Precisely!

The most important reason to use inner functions or inner classes is
that it's cromulent for the task at hand, stylistically opportune or
optimal, not to use the word Pythonic.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Grant Edwards]

On 2018-06-24, Steven D'Aprano  wrote:

> Building functions is cheap. Cheap is not free.
>
> Inner functions that aren't exposed to the outside cannot be tested
> in isolation, you can't access them through help()
> interactively. Given the choice between:

[...]

> so not expensive, but not free either. If using an inner function
> has no advantages to you, why pay that tiny cost for no benefit?

The benefit of an inner function is that it makes it perfectly clear
to the reader that that function is not used outside the function
where it is defined.  It also makes it more difficult for other
fuctions to muck things up by changing the binding of a global name.

IOW, you use a local function instead of a global one for the exact
same reasons you use local "variables" instead of global ones.

In Python, functions are first class objects.  Binding a name to a
function is no different than binding it to an integer, list, string,
or dict.  Don't the global vs. local cost vs. benefit calculations
apply equally well to function objects as they do to those other sorts
of objects?

-- 
Grant Edwards   grant.b.edwardsYow! I'm a nuclear
  at   submarine under the
  gmail.compolar ice cap and I need
   a Kleenex!

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Bart]

  To: boB Stepp
From: Bart 

On 24/06/2018 16:37, boB Stepp wrote:
> On Sun, Jun 24, 2018 at 5:21 AM Bart  wrote:

> "... And of course, you would have to know how to use Python properly in
> idiomatic style.

No. I want to program in /my/ style, one more like the pseudo-code that was
mentioned elsewhere, and that is universally understood. Even if people here
don't think much of it.

(eg. https://pastebin.com/0EygJzFR, raw text:https://pastebin.com/raw/0EygJzFR)

   Why not choose this positive approach?  I think it
> would be a win-win for both you and Python."
>
> Just show you genuinely care about the language and the community.
> Use and understand the language as well as you can before jumping into
> criticisms.  Adopt the path of the humble learner, who does not know
> everything about Python.  Is this too much to ask?

Sorry, I tried a few replies but they all got too long and too much about me.
So I'll have to leave it.

I think people know enough about my ideas by now anyway.

--
bart

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[Abdur-Rahmaan Janhangeer]

From: Abdur-Rahmaan Janhangeer 

see for example

https://en.m.wikipedia.org/wiki/Bresenham%27s_line_algorithm

see the pseudocode, i was implementing some raster algos when i found myself
aux anges

so close to py. i guess it was written in prehistoric times with the author
trying to simplify stuffs

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ


>

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[Chris Angelico]

From: Chris Angelico 

On Mon, Jun 25, 2018 at 2:23 AM, Abdur-Rahmaan Janhangeer
 wrote:
> Python is rightly called executable pseudocode. i appreciated the fact that
> you can go on wikipaedia, find the pseudocode of algorithms remove curly
> braces and replace by py's more powerful  syntax and poof, suddenly it
> becomes too easy.

My pseudocode and Python code look extremely similar, but that's partly
*because* I know Python. But I do periodically have JavaScript students ask me
"Is that Python?" when what I've written is pseudocode.

ChrisA

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Chris Angelico]

From: Chris Angelico 

On Mon, Jun 25, 2018 at 1:02 AM, Steven D'Aprano
 wrote:
> On Mon, 25 Jun 2018 00:46:00 +1000, Chris Angelico wrote:
>
>> On Sun, Jun 24, 2018 at 8:40 PM, Steven D'Aprano
>>  wrote:
>>> On Sun, 24 Jun 2018 11:18:37 +0100, Bart wrote:
>>>
 I wonder why it is just me that constantly needs to justify his
 existence in this group?
>>>
>>> Because its just you who spends 90% of his time here complaining about
>>> how Python does it wrong.
>>
>> ... and spends 95% of that time demonstrating his utter lack of
>> understanding of how Python does it at all. It's wrong even though you
>> don't understand how it actually works.
>
> Be fair. It's more like 50% of the time.
>
> Let's not dogpile onto Bart. He asked a question, I answered it, we don't
> all need to sink the boot in as well.

Fair. Still, it does seem that most of the criticisms are based on ignorance,
not reasoned disagreement. For instance, I could argue that Python's model of
"variables are local if written to, otherwise they're looked up globally" is a
poor choice, because I have extensively used Python AND other (C-like) models.
Or I could argue that Python really ought to support "foo bar baz"/" " as a
syntax for string splitting, because I've used Python's way of doing things,
and have also used something that works differently. But I cannot argue that
Python should have mutable strings, because I've never used a modern language
that has them, so I don't know what the tradeoffs are. Thus you don't hear me
pushing for it.

ChrisA

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Steven D'Aprano]

From: Steven D'Aprano 

On Sun, 24 Jun 2018 16:39:19 +0100, Bart wrote:

> More like utter disbelief at how it works. Surely it cannot work like
> that because it would be too inefficient? Apparently, yes it can...

Apparently, no it doesn't, because the fact that Python is used by tens of
thousands of programmers for some mighty big, performance-critical, projects
proves that it isn't "too inefficient". Its efficient enough.

You want C, and all the headaches and buffer overflows and seg faults it gives,
 you know where to find it.


> I know I'm going to get flak for bringing this up this old issue,

And yet you're going to do it anyway.

> but
> remember when you used to write a for-loop and it involved creating an
> actual list of N integers from 0 to N-1 in order to iterate through
> them? Crazy.

That's nothing, there are languages where the standard way to write a for loop
is to call an external program that generates a stream of numeric strings
separated by spaces in a subprocess, and read the strings from standard input
as text.



--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing it everywhere."
 -- Jon Ronson

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[boB Stepp]

From: boB Stepp 

On Sun, Jun 24, 2018 at 5:21 AM Bart  wrote:
>
> On 24/06/2018 00:44, boB Stepp wrote:
> > On Sat, Jun 23, 2018 at 5:35 PM Bart  wrote:
>
> >> I'm not a user...
> >
> > Then I am truly puzzled, Bart.  Why do you even bother to hang out on
> > this list?  If you do not want to use Python and you do not want to
> > improve Python's design and implementation, what is your point of
> > being here?
>
> I wonder why it is just me that constantly needs to justify his
> existence in this group?

You snipped the unpleasant part of my paragraph: "... You *do* seem to generate
 a lot of ill will, I hope unintentionally..."

> Does someone need to be that much of a user of a language in order
> to discuss its design or its features or its efficiency, or how it
> compares with any other? You can do that from without as well as
> from within.

I don't dispute this.  But there are good ways to do this and there are bad
ways to do this.  You seem to fall into the latter category enough that at a
minimum you irritate people who care very deeply about Python, and, at worst,
outright enrage some.



> As for why Python, it's the dynamic language I'm most familiar
> with, and I've been following it since the 1990s.

And this gets to the crux of the matter.  If this is so, why is it that you
repeatedly demonstrate a lack of understanding of the very things you are
critiquing?  I cannot recall how many times you have been called out on this
point, but it is certainly not an uncommon event.  It is one thing to have
demonstrable technical understanding of one or more concepts, and critique
those concepts with valid, or at least, interesting points, but it is entirely
another thing to be criticizing (How you are often perceived.) something in
Python while at the same time demonstrating you don't really understand the
particular Pythonic implementation or usage you are criticizing. Don't you see
the difference?  Don't you see what it is that so riles people?  But things do
not have to be this way!  As I said later in my paragraph I have been
referencing:

"... But why not take a different, more helpful tack? You seem to have a lot of
 ideas.  If you really think they are applicable to improving the Python
language, why not take your ideas, one at a time, and have serious discussion,
perhaps better on Python-Ideas, on how Python can be meaningfully made better? 
 That would be a helpful approach which I think, if done with the intention of
helping Python to be the best language it can be (Within the constraints it has
 to operate within in practice.), then I would hope your potential
contributions would be positively received by the community..."

And:

"... And of course, you would have to know how to use Python properly in
idiomatic style.  Why not choose this positive approach?  I think it would be a
 win-win for both you and Python."

Just show you genuinely care about the language and the community. Use and
understand the language as well as you can before jumping into criticisms. 
Adopt the path of the humble learner, who does not know everything about
Python.  Is this too much to ask?



--
boB

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Rick Johnson]

  To: Steven D'Aprano
From: Rick Johnson 

On Sunday, June 24, 2018 at 10:05:14 AM UTC-5, Steven D'Aprano wrote: [...]
> Be fair. It's more like 50% of the time. Let's not dogpile
> onto Bart. He asked a question, I answered it, we don't all
> need to sink the boot in as well.

And why am i _not_ surprised to learn that Steven defines "community" as
kicking and dogpiling others 50% of the time.

Well, at least it wasn't 100%...

Eh? o_O

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[Abdur-Rahmaan Janhangeer]

From: Abdur-Rahmaan Janhangeer 

Python is rightly called executable pseudocode. i appreciated the fact that you
 can go on wikipaedia, find the pseudocode of algorithms remove curly braces
and replace by py's more powerful  syntax and poof, suddenly it becomes too
easy.

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ

>
>

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Steven D'Aprano]

From: Steven D'Aprano 

On Mon, 25 Jun 2018 00:46:00 +1000, Chris Angelico wrote:

> On Sun, Jun 24, 2018 at 8:40 PM, Steven D'Aprano
>  wrote:
>> On Sun, 24 Jun 2018 11:18:37 +0100, Bart wrote:
>>
>>> I wonder why it is just me that constantly needs to justify his
>>> existence in this group?
>>
>> Because its just you who spends 90% of his time here complaining about
>> how Python does it wrong.
>
> ... and spends 95% of that time demonstrating his utter lack of
> understanding of how Python does it at all. It's wrong even though you
> don't understand how it actually works.

Be fair. It's more like 50% of the time.

Let's not dogpile onto Bart. He asked a question, I answered it, we don't all
need to sink the boot in as well.

Nobody expects Bart to love Python, but if he wants to fit in here, in a Python
 group, he ought to either at least make an effort to understand the reasons
Python is what it is (and not just idiocy and bloat) and appreciate it for what
 it is, not for what it isn't. Or at least avoid trying to lecture us on why
we're doing it wrong.



--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing it everywhere."
 -- Jon Ronson

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Bart]

  To: Chris Angelico
From: Bart 

On 24/06/2018 15:46, Chris Angelico wrote:
> On Sun, Jun 24, 2018 at 8:40 PM, Steven D'Aprano
>  wrote:
>> On Sun, 24 Jun 2018 11:18:37 +0100, Bart wrote:
>>
>>> I wonder why it is just me that constantly needs to justify his
>>> existence in this group?
>>
>> Because its just you who spends 90% of his time here complaining about
>> how Python does it wrong.
>
> ... and spends 95% of that time demonstrating his utter lack of
> understanding of how Python does it at all. It's wrong even though you
> don't understand how it actually works.

More like utter disbelief at how it works. Surely it cannot work like that
because it would be too inefficient? Apparently, yes it can...

And all to support extreme dynamism which is only really needed a tiny
proportion of the time (feel free to correct me).

I know I'm going to get flak for bringing this up this old issue, but remember
when you used to write a for-loop and it involved creating an actual list of N
integers from 0 to N-1 in order to iterate through them? Crazy.

But that has long been fixed - or so I thought. When I wrote, today:

for i in range(1): pass  # 100 million

on Python 2, it used up 1.8GB, up to the limit of my RAM, and it took several
minutes to regain control of my machine (and it never did finish). You don't
expect that in 2018 when executing a simple empty loop.

On Py 2 you have to use xrange for large ranges - that was the fix.

Somebody however must have had to gently and tactfully point out the issue. I'm
 afraid I'm not very tactful.

--
bart

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Chris Angelico]

From: Chris Angelico 

On Sun, Jun 24, 2018 at 8:40 PM, Steven D'Aprano
 wrote:
> On Sun, 24 Jun 2018 11:18:37 +0100, Bart wrote:
>
>> I wonder why it is just me that constantly needs to justify his
>> existence in this group?
>
> Because its just you who spends 90% of his time here complaining about
> how Python does it wrong.

... and spends 95% of that time demonstrating his utter lack of understanding
of how Python does it at all. It's wrong even though you don't understand how
it actually works.

ChrisA

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Python for beginners or not? [was Re: syntax difference]

[Steven D'Aprano]

From: Steven D'Aprano 

On Sat, 23 Jun 2018 14:52:24 -0500, boB Stepp wrote:

[...]
>> There is a place for various levels of programming language. I'm saying
>> that Python which is always touted as a 'simple' language suitable for
>> beginners, is missing a surprising number of basics.
>
> I still feel like a rank beginner, but on the Tutor list some disagree.

It has been a long, long time since Python has been a "simple" language
suitable for rank beginners, if it ever was. Python is not Scratch.

https://scratch.mit.edu/


Right from version 1.0, Python has included some advanced features, even
mind-blowing features (metaclasses, a.k.a. "the killer joke"). We're now up to
version 3.6 (in production) and 3.7 (in beta) and Python includes some very
advanced modern[1] features, like syntactic support for asynchronous
programming, decorators, generators, coroutines and more.

Better to say that Python is *accessible* to beginners: you can do a lot of
good work in Python using simple constructs and imperative scripts, and most
importantly, the syntax generally doesn't get in your way. There's relatively
little boilterplate needed and a gentle learning curve.

Compare "Hello World" in Java and Python:

public class HelloWorld {
public static void main(String[] args) {
// Prints "Hello, World" to the terminal window.
System.out.println("Hello, World");
}
}


versus:

print("Hello, World")

The Python example requires the programmer to learn effectively three things
(print, parentheses, strings), compared to over a dozen for Java:

- classes; braces; parentheses; strings; methods;
  attribute access using dot; "public" declarations;
  "static" declarations; "void" declarations;
  type declarations; the existence of System;
  System.out; System.out.println; semicolons;
  the implicit calling of main.


Aside: there's an extensive, and yet still incomplete, list of Hello World
programs here http://helloworldcollection.de/ with some impressive examples.
Enjoy!


[...]
> As an aside we just had another round of software, OS and hardware
> upgrades.  Now I can use Python 2.7!

Yay! Welcome to the 2000s! Hope you will catch up to Python 3 by the 2020s :-)


> Because I read and study about new things as I take them up, I soon
> learned that I had only so far scratched the surface of Python's depths.
>  But despite knowing that Python had many more features to explore, both
> in the core language and the standard library, this never hindered me in
> writing my beginner-level programs.  I got things done, and I got them
> done fairly easily, and never felt burdened by all the "other stuff"
> that Python had to offer.

Indeed. That's one of the beauties of Python -- even when there's an advanced
way to do it, there's generally a simple way too.






[1] I say "modern", but in fact very little in computer science wasn't invented
 by Lisp in the 1950s, or if not Lisp, by CLU in the 1970s.

--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing it everywhere."
 -- Jon Ronson

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[Stefan Ram]

  To: Steven D'Aprano
From: r...@zedat.fu-berlin.de (Stefan Ram)

Steven D'Aprano  writes:
>It has been a long, long time since Python has been a "simple" language
>suitable for rank beginners, if it ever was. Python is not Scratch.

  Python is simpler insofar as you can write on a higher level
  than with C. Python has a GC and an intuitive syntax for
  lists, tuples and dictionaries.

  main.c

#include 
int main( void ){ printf( "%d\n", 6 * 6 ); }

  transcript

-694967296

  Above, a beginner has to take care to use Γ╗%dΓ½ and remember
  to change this to Γ╗%gΓ½ when necessary. He also needs to
  understand why the result is negative, and that the result
  is /implementation-dependent/. Surely,

|>>> print( 6 * 6 )
|36

  is easier to read, write, and understand.

  Still, one must not forget that learning Python encompasses
  all the hard work it takes to learn how to program in every
  language.

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Bart]

  To: Ben Bacarisse
From: Bart 

On 24/06/2018 01:53, Ben Bacarisse wrote:
> Bart  writes:

>> Wow. (Just think of all the times you write a function containing a
>> neat bunch of local functions, every time it's called it has to create
>> a new function instances for each of those functions, even if they are
>> not used.)
>
> I am surprised that this surprises you, and equally surprised that you
> seem to think it's going to be in some way grossly inefficient.

Steven D'Aprano's reply suggests there /is/ some inefficiency which is why
[according to him] nested functions are rarely used that way.

--
bartc

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Steven D'Aprano]

From: Steven D'Aprano 

On Sun, 24 Jun 2018 11:23:12 +0100, Bart wrote:

> On 24/06/2018 01:53, Ben Bacarisse wrote:
>> Bart  writes:
>
>>> Wow. (Just think of all the times you write a function containing a
>>> neat bunch of local functions, every time it's called it has to create
>>> a new function instances for each of those functions, even if they are
>>> not used.)
>>
>> I am surprised that this surprises you, and equally surprised that you
>> seem to think it's going to be in some way grossly inefficient.
>
> Steven D'Aprano's reply suggests there /is/ some inefficiency which is
> why [according to him] nested functions are rarely used that way.

Building functions is cheap. Cheap is not free.

Inner functions that aren't exposed to the outside cannot be tested in
isolation, you can't access them through help() interactively. Given the choice
 between:


# can't test eggs, can't re-use it
def func():
def eggs():
...
...

and:

# can test it, can re-use it
def _eggs():
...

def func():
...


most people go for the later simply because it is better development practice.
The very small performance penalty hardly comes into it.

For what its worth, the cost of assembling a basic function is comparable to
creating an empty dict:

[steve@ando ~]$ python3.5 -m timeit "lambda: None" 1000 loops, best of 3:
0.195 usec per loop [steve@ando ~]$ python3.5 -m timeit "{}" 100 loops,
best of 3: 0.212 usec per loop


so not expensive, but not free either. If using an inner function has no
advantages to you, why pay that tiny cost for no benefit?


--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing it everywhere."
 -- Jon Ronson

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Steven D'Aprano]

From: Steven D'Aprano 

On Sun, 24 Jun 2018 11:18:37 +0100, Bart wrote:

> I wonder why it is just me that constantly needs to justify his
> existence in this group?

Because its just you who spends 90% of his time here complaining about how
Python does it wrong.


--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing it everywhere."
 -- Jon Ronson

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Bart]

  To: boB Stepp
From: Bart 

On 24/06/2018 00:44, boB Stepp wrote:
> On Sat, Jun 23, 2018 at 5:35 PM Bart  wrote:

>> I'm not a user...
>
> Then I am truly puzzled, Bart.  Why do you even bother to hang out on
> this list?  If you do not want to use Python and you do not want to
> improve Python's design and implementation, what is your point of
> being here?

I wonder why it is just me that constantly needs to justify his existence in
this group?

Does someone need to be that much of a user of a language in order to discuss
its design or its features or its efficiency, or how it compares with any
other? You can do that from without as well as from within.

Anyway I'm not here that often, I pop in from time to time when something
interesting comes that I feel I can comment about. And yes I sometimes do that
as a diversion because I enjoy this discussing this stuff. Why, is that
allowed?

As for why Python, it's the dynamic language I'm most familiar with, and I've
been following it since the 1990s.

Here's a small selection of threads I've posted in:

  Why not allow empty code blocks

  Python and the need for speed

  Building CPython

  What is a function parameter =[] for

  Considering migrating to Python from Visual Basic...

  How to read from a file to an arbitrary delimiter efficiently

  Python 2.x or 3.x, which is faster?

  The cost of Dynamism

  Case Statements  [15-Mar-2016]

The last is interesting. The OP there follows up with:

  "You have apparently mistaken me for someone who's worried.
  I don't use Python, I was just curious as to why a construct
  that is found, not only to be useful in 95% of other languages,
  but is generally considered more flexible and readable than the
  if-elif, was missing in Python.  (your link 'Switch Statement
  Code Smell' not withstanding)"

Many of the posters are explaining why Python doesn't have it, why they think
the feature is so poor, and ways to get around the lack of it. Mine defend the
feature.

You're saying I shouldn't be allowed to put an alternative point of view
because I don't use Python enough? I would say that because I
/implement/ such features all the time in other languages, that my
opinion is worthwhile.

But people do seem to like to wind me up, and I like to defend my corner, so
posts tend to proliferate.

--
bart.

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Steven D'Aprano]

From: Steven D'Aprano 

On Sat, 23 Jun 2018 18:29:51 +0100, MRAB wrote:

> You can already do something similar like this:
>
> def f():
>   f.x += 1
>   return f.x
> f.x = 0
>
> [snip]

You can, but only as an illustration, not as a serious implementation.

The whole point of static local variables is that they are:

(1) Local variables, and hence FAST;

(2) fully encapsulated inside the function.

Using f.x fails on both accounts:

- it requires a global name lookup for "f" (hence slow);

- followed by an attribute lookup for "x" (hence even slower);

- f.x is not encapsulated inside the function. It requires initialisation
outside the function. The attribute f.x is easily visible to the caller.

(Technically, so probably would static variables, but only by inspecting the
function's internals. People know they're on thin-ice if they mess with them.
And if we really needed to, we could protect the static storage inside the
function from writing, if not reading, as we do with closures. f.x looks like
an ordinary attribute.)

I have used the f.x trick before, for things where speed was not critical, but
I've never really loved the idea, and it certainly cannot be used as a
replacement of the def func(arg, len=len, int=int) optimization trick.


--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing it everywhere."
 -- Jon Ronson

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Steven D'Aprano]

From: Steven D'Aprano 

On Sat, 23 Jun 2018 21:44:00 +0100, Bart wrote:

> Since these references are created via the return g statement here:
>
>  def f():
>  def g():
>  
>  return g
>
> (say to create function references i and j like this:
>
>  i = f()
>  j = f()
> )
>
> I'm assuming that something special must be happening. Otherwise, how
> does f() know which reference it's being called via?

You assume wrong.


> What is different, what extra bit of information is provided when f() is
> invoked via i() or j()?

For somebody who has been using Python for a few years now, and is constantly
telling us how we're doing it wrong, you sure are ignorant about the language
and how it works.

For somebody who has been programming for so long, you seem awfully unaware of
how dynamic languages with first-class functions and closures work.

No extra bit of information is provided. i refers to one function, j, refers to
 another function, and there is no overlap.

Each invocation of f() results in a brand new function being created,
dynamically, and assigned to the appropriate name.



--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing it everywhere."
 -- Jon Ronson

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Steven D'Aprano]

From: Steven D'Aprano 

On Sun, 24 Jun 2018 00:37:36 +0100, Bart wrote:

> Do you mean that if the same 'def' block is re-executed, it will create
> a different instance of the function? (Same byte-code, but a different
> set of everything else the function uses.)

That's not as slow as you think it is. Everything that can be is pre- prepared
and assembling them is pretty fast:

py> import dis
py> dis.dis(lambda x: lambda n: x*n)
  1   0 LOAD_CLOSURE 0 (x)
  3 BUILD_TUPLE  1
  6 LOAD_CONST   1 ( at
0xb78b6430, file "",
line 1>)
  9 LOAD_CONST   2 ('..')
 12 MAKE_CLOSURE 0
 15 RETURN_VALUE


How else can you get functions where the definition is not known until runtime,
 unless you assemble them at runtime?


> Wow. (Just think of all the times you write a function containing a neat
> bunch of local functions, every time it's called it has to create a new
> function instances for each of those functions, even if they are not
> used.)


That's why Pascal-style static nested functions are hardly ever used in Python.
 99% of nested functions are closures.




--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing it everywhere."
 -- Jon Ronson

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Gregory Ewing]

  To: Bart
From: Gregory Ewing 

Bart wrote:
> Wow. (Just think of all the times you write a function containing a neat
> bunch of local functions, every time it's called it has to create a new
> function instances for each of those functions, even if they are not used.)

Fortunately, function objects are small and cheap, essentially just a couple of
 object references. The overhead of creating one is probably about the same as
creating an empty list. If your function is complicated enough to benefit from
local functions, the cost is going to be swamped by the rest of the work being
done.

--
Greg

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[boB Stepp]

From: boB Stepp 

On Sat, Jun 23, 2018 at 5:35 PM Bart  wrote:
>
> On 23/06/2018 20:52, boB Stepp wrote:

> The first programming exercise I ever did involved asking for three
> numbers, then determining whether those numbers could form the sides of
> a triangle.
>
> Then [40 years ago], the easy part was reading the three numbers. Now
> that would be the more challenging part.
>
> This is one of the basics that is missing. Getting around it is not
> hard, but it's some messing about and it's a distraction. But 40 years
> ago it was just 'readln a,b,c'; it was just taken for granted.

I don't think there are any *basics* missing.  One of the differences between
then and now is that trying to live in a simpler ASCII/extended ASCII world is
no longer possible.  The Internet and
open source movements among other things have brought in more (most?) of the
world as participants in the programming endeavor.  The many peoples of this
world and their many, varied cultures is quite rich and complex, and they have
real needs to express their thoughts as naturally as they can.  I would contend
 that the basics are there, but the complexity of the data and ideas that need
to be dealt with these days is what makes the programming journey more
challenging but also more interesting than in the days of yore.  When I first
went to college in the seventies, it was all punch cards, main frames, a few
minicomputers, time sharing IBM selectrics, etc.  I would *not* want to go back
 to that!  I find today's challenges and opportunities much more fascinating!!

> > Anyway, so far Python has not lacked for anything I have needed so
> > far.
>
> I'd be surprised if Python lacked anything; there can't be anything that
> someone has thought of that is either built-in or bolted on, if not
> always that elegantly or that efficiently.

I am not qualified to speak to issues of Python's language design, but as a
user of Python I have yet to be disappointed.  But I imagine all languages,
including yours, have accumulated cruft that in retrospect the creators would
like to remove.  But the difference, as far as I can tell, between your
languages and Python is that Python has a huge number of active users with who
knows how many LOC in production environments, but your languages do not.  So
you have the benefit, as their creator and essentially sole user, to keep
polishing and refining your ideas.  The Python devs don't have that luxury. 
But they are obviously, even to me, constantly not only adding new
functionality, but trying to minimize the cruft as best they can without
compromising people's production code.  I imagine that the transition from
version 2 to 3 was not undertaken halfheartedly, but only after much thought
and discussion since it did break backwards compatibility.  But now having used
 both Python 2 (Which I still have to code in at work.) and 3, even I with my
limited knowledge and capabilities appreciate the positive benefits of the
changes.

> However, imagine having to use a language which didn't have assignments
> as you are used to, and that you would expect to exist. Then you might
> well remark that it's missing something that you regard as a basic,
> while the proponents of that language point out that it doesn't stop you
> writing programs; it just needs a different approach.

But the beauty of things as they are today, is that if someone has thought of
it, it is probably accessible and available to use.  Not only that, but one can
 cruise through the many different programming languages and see what others
have imagined and thought to be useful and grow one's knowledge and insight
much more easily than ever before.  And if I have a need that Python or any
other language I use does not address, I can surely find one online.

> (I believe that you can write any program using just IF-GOTO statements
> and ASSIGNMENT statements, and no other flow control (given suitable
> data-types and means of I/O). But if you wanted to try out an
> interesting experiment along those lines (eg. transcribe any flowchart
> to code), a large number of languages, including Python, make it hard
> because 'goto' is missing.)

I have done the "GOTO" thing ages ago.  I would not want to go back to that bad
 place.  There are too many better alternatives now for flow control.  With
today's hardware I don't think any benefit from any theoretical optimizations
would be of any benefit in practice.  As a person who does not have much time
for studying and writing programs, I have a hard enough time understanding what
 I wrote after a break from programming.  I would not want to put any more
stumbling blocks in my code for later maintainability, not to imagine having to
 do so for other people's code.

> > All I can say is I have yet to find much at all in Python cumbersome
> > or bewildering.
>
> No? How many ways are there in Python, including third party add-ons, of
> working with record-like objects?

If I am understanding you correctly 

Re: syntax difference

[Steven D'Aprano]

From: Steven D'Aprano 

On Sat, 23 Jun 2018 23:26:43 +0100, Bart wrote:

> Then [40 years ago], the easy part was reading the three numbers. Now
> that would be the more challenging part.

# Get three numbers, separated by spaces, with no error-recovery.
# If you try to read bad data, the process will fail.
n1, n2, n3 = [float(s) for s in input("Enter three numbers: ").split()]

No more verbose or difficult (certainly not "challenging") than:

var:
  # need to declare these otherwise how will readln
  # know if it is reading floats or ints or strings?
  n1, n2, n3: float
print("Enter three numbers: ")
n1, n2, n3 = readln()


If the use of a list comprehension is too advanced for a beginner in day one,
how about this:

n1 = float(input("Enter a number: ")) n2 = float(input("Enter a number: ")) n3
= float(input("Enter a number: "))



--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing it everywhere."
 -- Jon Ronson

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Gregory Ewing]

  To: Bart
From: Gregory Ewing 

Bart wrote:
> But 40 years
> ago it was just 'readln a,b,c'; it was just taken for granted.

The problem with something like that is that it's really only useful for
throwaway code. For any serious application, you need to deal with the
possibility of malformed input, producing helpful diagnostics, etc. And often
the input isn't going to be in such a uniform format that you know exactly what
 to expect next.

So it's debable whether it's a good idea to put something with such limited
applicability into the core language or standard library.

Handling input well is fundamentally much more complicated than producing
output. I don't think this is as "basic" as you make out.

--
Greg

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Chris Angelico]

From: Chris Angelico 

On Sun, Jun 24, 2018 at 9:37 AM, Bart  wrote:
> On 23/06/2018 23:25, Ben Bacarisse wrote:
>>
>> Bart  writes:
>>
>>> On 23/06/2018 21:13, Chris Angelico wrote:

 On Sat, Jun 23, 2018 at 10:41 PM, Bart  wrote:
>>>
>>>
> (At what point would that happen anyway; if you do this:
>>>
>>>
 NONE of your examples are taking copies of the function. They all are
 making REFERENCES to the same function. That is all.
>>>
>>>
>>> This is about your notion that invocations of the same function via
>>> different references, should maintain their own versions of the
>>> function's 'static' data.
>>>
>>> Since these references are created via the return g statement here:
>>>
>>>  def f():
>>>  def g():
>>>  
>>>  return g
>>>
>>> (say to create function references i and j like this:
>>>
>>>  i = f()
>>>  j = f()
>>> )
>>>
>>> I'm assuming that something special must be happening. Otherwise, how
>>> does f() know which reference it's being called via?
>>>
>>> What is different, what extra bit of information is provided when f()
>>> is invoked via i() or j()?
>>
>>
>> f is not being invoked by either i() or j().  i = f() binds i to the
>> function returned by f.  That's a newly minted function.  In languages
>> like Python, executing def creates a function.
>
>
> Do you mean that if the same 'def' block is re-executed, it will create a
> different instance of the function? (Same byte-code, but a different set of
> everything else the function uses.)
>
> Wow. (Just think of all the times you write a function containing a neat
> bunch of local functions, every time it's called it has to create a new
> function instances for each of those functions, even if they are not used.)

... do you even understand what closures are?

ChrisA

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Bart]

  To: boB Stepp
From: Bart 

On 23/06/2018 20:52, boB Stepp wrote:
> I've finally found time to examine this rather long, rambling thread.

>> There is a place for various levels of programming language. I'm saying that
Python which is always touted as a 'simple' language suitable for beginners, is
 missing a surprising number of basics.

> I still feel like a rank beginner, but on the Tutor list some
> disagree.

The first programming exercise I ever did involved asking for three numbers,
then determining whether those numbers could form the sides of a triangle.

Then [40 years ago], the easy part was reading the three numbers. Now that
would be the more challenging part.

This is one of the basics that is missing. Getting around it is not hard, but
it's some messing about and it's a distraction. But 40 years ago it was just
'readln a,b,c'; it was just taken for granted.

(It make seem quaint in these days of GUIs, gestures, and voice recognition to
be reading a line at a time, but you will need it still for text file i/o.)

> Anyway, so far Python has not lacked for anything I have needed so
> far.

I'd be surprised if Python lacked anything; there can't be anything that
someone has thought of that is either built-in or bolted on, if not always that
 elegantly or that efficiently.

However, imagine having to use a language which didn't have assignments as you
are used to, and that you would expect to exist. Then you might well remark
that it's missing something that you regard as a basic, while the proponents of
 that language point out that it doesn't stop you writing programs; it just
needs a different approach.

(I believe that you can write any program using just IF-GOTO statements and
ASSIGNMENT statements, and no other flow control (given suitable data-types and
 means of I/O). But if you wanted to try out an interesting experiment along
those lines (eg. transcribe any flowchart to code), a large number of
languages, including Python, make it hard because 'goto' is missing.)

> All I can say is I have yet to find much at all in Python cumbersome
> or bewildering.

No? How many ways are there in Python, including third party add-ons, of
working with record-like objects?

> As an aside to Bart, if you strongly feel that Python is missing a
> really useful feature, then why don't you do the usual thing, start a
> very specific thread about just that feature (Not just a collection of
> things you like in one of your languages.), and if you manage to
> persuade the community of its usefulness, then write up a PEP about
> it?  Just saying ... ~(:>))

I'm not a user. My interest is in design and implementation, especially of
interpreters, and especially of efficient ones. A lot of things that Python
could do with are made very difficult by the existing design of that language.
Being so dynamic has a lot to answer for.

So I don't envy the job of the people who really have to move the language
forward. That doesn't mean I can't argue with people who say that Python
doesn't really need (say) Switch. (I guess the Blub paradox works both ways...)

--
bart

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Ben Bacarisse]

  To: Bart
From: Ben Bacarisse 

Bart  writes:

> On 23/06/2018 23:25, Ben Bacarisse wrote:
>> Bart  writes:
>>
>>> On 23/06/2018 21:13, Chris Angelico wrote:
 On Sat, Jun 23, 2018 at 10:41 PM, Bart  wrote:
>>>
> (At what point would that happen anyway; if you do this:
>>>
 NONE of your examples are taking copies of the function. They all are
 making REFERENCES to the same function. That is all.
>>>
>>> This is about your notion that invocations of the same function via
>>> different references, should maintain their own versions of the
>>> function's 'static' data.
>>>
>>> Since these references are created via the return g statement here:
>>>
>>>  def f():
>>>  def g():
>>>  
>>>  return g
>>>
>>> (say to create function references i and j like this:
>>>
>>>  i = f()
>>>  j = f()
>>> )
>>>
>>> I'm assuming that something special must be happening. Otherwise, how
>>> does f() know which reference it's being called via?
>>>
>>> What is different, what extra bit of information is provided when f()
>>> is invoked via i() or j()?
>>
>> f is not being invoked by either i() or j().  i = f() binds i to the
>> function returned by f.  That's a newly minted function.  In languages
>> like Python, executing def creates a function.
>
> Do you mean that if the same 'def' block is re-executed, it will
> create a different instance of the function? (Same byte-code, but a
> different set of everything else the function uses.)

Logically, yes.

> Wow. (Just think of all the times you write a function containing a
> neat bunch of local functions, every time it's called it has to create
> a new function instances for each of those functions, even if they are
> not used.)

I am surprised that this surprises you, and equally surprised that you seem to
think it's going to be in some way grossly inefficient.

--
Ben.

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Ben Bacarisse]

  To: Bart
From: Ben Bacarisse 

Bart  writes:

> On 23/06/2018 21:13, Chris Angelico wrote:
>> On Sat, Jun 23, 2018 at 10:41 PM, Bart  wrote:
>
>>> (At what point would that happen anyway; if you do this:
>
>> NONE of your examples are taking copies of the function. They all are
>> making REFERENCES to the same function. That is all.
>
> This is about your notion that invocations of the same function via
> different references, should maintain their own versions of the
> function's 'static' data.
>
> Since these references are created via the return g statement here:
>
> def f():
> def g():
> 
> return g
>
> (say to create function references i and j like this:
>
> i = f()
> j = f()
> )
>
> I'm assuming that something special must be happening. Otherwise, how
> does f() know which reference it's being called via?
>
> What is different, what extra bit of information is provided when f()
> is invoked via i() or j()?

f is not being invoked by either i() or j().  i = f() binds i to the function
returned by f.  That's a newly minted function.  In languages like Python,
executing def creates a function.  In your example, i and j refer to different
functions.  If the function temporarily named g has "own" variables ("static"
in C), then each such function should have its own.  That was the point of the
example much further up.

The effect can simulated like this:

def make_counter():
def c():
c.x += 1
return c.x
c.x = 0
return c

i = make_counter()
j = make_counter()

print(i(), i(), j(), i())


--
Ben.

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Bart]

  To: Ben Bacarisse
From: Bart 

On 23/06/2018 23:25, Ben Bacarisse wrote:
> Bart  writes:
>
>> On 23/06/2018 21:13, Chris Angelico wrote:
>>> On Sat, Jun 23, 2018 at 10:41 PM, Bart  wrote:
>>
 (At what point would that happen anyway; if you do this:
>>
>>> NONE of your examples are taking copies of the function. They all are
>>> making REFERENCES to the same function. That is all.
>>
>> This is about your notion that invocations of the same function via
>> different references, should maintain their own versions of the
>> function's 'static' data.
>>
>> Since these references are created via the return g statement here:
>>
>>  def f():
>>  def g():
>>  
>>  return g
>>
>> (say to create function references i and j like this:
>>
>>  i = f()
>>  j = f()
>> )
>>
>> I'm assuming that something special must be happening. Otherwise, how
>> does f() know which reference it's being called via?
>>
>> What is different, what extra bit of information is provided when f()
>> is invoked via i() or j()?
>
> f is not being invoked by either i() or j().  i = f() binds i to the
> function returned by f.  That's a newly minted function.  In languages
> like Python, executing def creates a function.

Do you mean that if the same 'def' block is re-executed, it will create a
different instance of the function? (Same byte-code, but a different set of
everything else the function uses.)

Wow. (Just think of all the times you write a function containing a neat bunch
of local functions, every time it's called it has to create a new function
instances for each of those functions, even if they are not used.)

Anyway just for regular statics, the following appears to work. Not ideal, but
simpler than some alternatives:

def f():
 if not hasattr(f,'x'): f.x=0
 f.x += 1
 return f.x

--
bart.

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[boB Stepp]

From: boB Stepp 

I've finally found time to examine this rather long, rambling thread.

On Wed, Jun 20, 2018 at 5:46 AM  wrote:
>
> Yeah, people keep bringing that up when they run out of arguments.
>
> So, every programmer must always use the most advanced, most esoteric
features possible at every opportunity? Coding should only be for the elite?
>
> There is a place for various levels of programming language. I'm saying that
Python which is always touted as a 'simple' language suitable for beginners, is
 missing a surprising number of basics.

I still feel like a rank beginner, but on the Tutor list some disagree. 
Perhaps I feel this way because the more I try to study and research
programming/computer science topics, the more I realize how little I know and
how much remains to be learned, so I continue to feel like a beginner.  But I
am beginner enough that I can respond to the above points.

A handful of years ago at the job I do, I started to get tired of doing the
same basic things over and over, so I investigated what possibilities the
software I used on the OS it used had in order to automate these tasks.  Perl
proved to be available, but Python wasn't uniformly then, so I wrote some
programs in Perl.  I got it figured out and wrote some useful program in Perl,
but the language never did feel natural and easy to understand to me.

Later the OS and hardware got updated and I found Python was now fully
available in the 2.4 version.  I started writing new programs in Python and
found it quite easy to use and understand.  As I needed to, I started rewriting
 earlier programs I had done in Perl in Python instead, and was happier for it.
  As an aside we just had another round of software, OS and hardware upgrades. 
 Now I can use Python 2.7!

Because I read and study about new things as I take them up, I soon learned
that I had only so far scratched the surface of Python's depths.  But despite
knowing that Python had many more features to explore, both in the core
language and the standard library, this never hindered me in writing my
beginner-level programs.  I got things done, and I got them done fairly easily,
 and never felt burdened by all the "other stuff" that Python had to offer.

But I am continually grateful that this "other stuff" exists!  For instance,
recently I was working on a problem for home use that I was doing in Python 3
(Not that 3 vs. 2 matters here.).  I was concerned about loading potentially
really large files into RAM and not having enough memory for it.  Alan Gauld
suggested I try a generator approach.  I had not used these yet, though I was
aware of this feature's existence.  So I did some reading up on them, wrote
some code with my attempted implementation of them, submitted my efforts to the
 Tutor list for critique, and while I am sure I did not do a professional job
of things, I was quite happy with the result as it solved the problem I was
concerned about.  So even dipping my big toe into the "other stuff" proved an
enjoyable and understandable experience.  This has always been my experience
with Python.  When the time comes that I need something, I find it is there
either in the core language or the standard library, and it proves not
burdensome to learn the new feature(s).

This has been my beginner's journey with Python:  Easy to do useful stuff, easy
 to read and easy to understand.  When I need something _more_, I find it
already exists and proves relatively easy to understand *as long as* I am
willing to put in a bit of study.  And I don't think needing to put in a bit of
 study to learn how to use a new feature is unreasonable for me or anyone else.

Anyway, so far Python has not lacked for anything I have needed so far.  Of
course, I realize that if I need to do something closer to the machine level,
Python is probably not going to be the preferred go to tool, and even being a
beginner I have enough sense to realize this.  But then again, I would not be
too surprised if Python or a third party library did not already meet this
future, hypothetical need.

> That these are useful is demonstrated by the cumbersome add-ons that need to
be used to provide that functionality. Often in over the top ways and often in
a bewildering variety of ways in the case of records.

All I can say is I have yet to find much at all in Python cumbersome or
bewildering.

As to the original point of this thread concerning type-hints, I am aware of
them, once asked a bit on Tutor about them, but decided I am not ready to go
there yet.  But to (I hope.) help my learning of Python syntax, I am forcing
myself to *not* use linters, etc.  Once I feel that I have Python in my head
and in my fingers, then I will start using such sensible tools and will
probably reexamine type-hints.

As an aside to Bart, if you strongly feel that Python is missing a really
useful feature, then why don't you do the usual thing, start a very specific
thread about just that feature (Not just a collection of 

Re: Static variables [was Re: syntax difference]

[Bart]

  To: Chris Angelico
From: Bart 

On 23/06/2018 21:13, Chris Angelico wrote:
> On Sat, Jun 23, 2018 at 10:41 PM, Bart  wrote:

>> (At what point would that happen anyway; if you do this:

> NONE of your examples are taking copies of the function. They all are
> making REFERENCES to the same function. That is all.

This is about your notion that invocations of the same function via different
references, should maintain their own versions of the function's 'static' data.

Since these references are created via the return g statement here:

 def f():
 def g():
 
 return g

(say to create function references i and j like this:

 i = f()
 j = f()
)

I'm assuming that something special must be happening. Otherwise, how does f()
know which reference it's being called via?

What is different, what extra bit of information is provided when f() is
invoked via i() or j()?

--
bart

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Chris Angelico]

From: Chris Angelico 

On Sat, Jun 23, 2018 at 10:41 PM, Bart  wrote:
> This is an example of a simple concept getting so out of hand that it will
> either never be implemented, or the resulting implementation becomes
> impractical to use.
>
> This is what we're trying to do:
>
> def nextx():
> static x = 0
> x += 1
> return x
>
> And this is the simplest equivalent code in current Python that will cater
> for 99% of uses:
>
> _nextx_x = 0
>
> def nextx():
> global _nextx_x
> _nextx_x += 1
> return _nextx_x
>
> No nested functions. No generating new instances of functions complete with
> a new set of statics each time you happen to refer to the name. (Which
> sounds to me as useful as creating a new instance of an import when you copy
> its name, complete with a separate set of its globals. Isn't this stuff what
> classes are for?)
>
> (At what point would that happen anyway; if you do this:
>
> g = nextx  # hypothetical version would static
>
> it will create a new instance of 'nextx'. But it won't create one here, just
> before () is applied:
>
> nextx() # ?
>
> Or how about here:
>
> listoffunctions = (nextx1, nextx2, nextx3)
>
> listoffunctions[i]() # ?
>
> )

Clearly you have completely misunderstood the entire concept of Python's memory
 model, so I am not going to engage in debate with you on this. This is my ONLY
 post explaining this to you.

NONE of your examples are taking copies of the function. They all are
making REFERENCES to the same function. That is all.

Creating new functions is the job of 'def' and 'lambda'. Not assignment. So the
 concept of "multiple functions with the same name" comes from executing the
def statement more than once.

ChrisA

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[Mark Lawrence]

On 25/06/18 17:15, jkn wrote:

On Monday, June 25, 2018 at 4:23:57 PM UTC+1, Chris Angelico wrote:

On Mon, Jun 25, 2018 at 11:15 PM, jkn  wrote:

(as well as pedanticism ;-o).


Pedantry.

ChrisA
(You know I can't let that one pass.)


I was chanel[l]ing the TimBot, as any fule kno...



Ritten by a troo Molesworth fann.

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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[jkn]

On Monday, June 25, 2018 at 4:23:57 PM UTC+1, Chris Angelico wrote:
> On Mon, Jun 25, 2018 at 11:15 PM, jkn  wrote:
> > (as well as pedanticism ;-o).
> 
> Pedantry.
> 
> ChrisA
> (You know I can't let that one pass.)

I was chanel[l]ing the TimBot, as any fule kno...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[Alister via Python-list]

On Mon, 25 Jun 2018 11:42:27 +0100, Mark Lawrence wrote:

> On 25/06/18 10:10, Alister via Python-list wrote:
>> On Mon, 25 Jun 2018 11:36:25 +0400, Abdur-Rahmaan Janhangeer wrote:
>> 
>>> i think he means like for a loop to iterate over a list you might do
>>>
>>> list = [1,2,3]
>>> for i in range(len(list)):
>>>  print(list[i])
>>>
>>>
>>> but the you might as well go for the simpler :
>>>
>>>
>>> for elem in list:
>>>
>>>   print(elem)
>>>
>>> Abdur-Rahmaan Janhangeer https://github.com/Abdur-rahmaanJ
>>>
>>>
>>>
>>>
>> for i in range(len(list)): is a python anti-pattern it is almost a 100%
>> guarantee that you are doing something wrong*
>> 
>> *as with all rules of thumb there is probably at least 1 exception that
>> the python experts will now point out.
>> 
>> 
>> 
> The exception is that if you really do need the index, you write:-
> 
> for i, elem in enumerate(list):

I would not call that an exception, that is still the correct way to 
obtain the index during the loop




-- 
I saw a subliminal advertising executive, but only for a second.
-- Steven Wright
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[Chris Angelico]

On Mon, Jun 25, 2018 at 11:15 PM, jkn  wrote:
> (as well as pedanticism ;-o).

Pedantry.

ChrisA
(You know I can't let that one pass.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[Grant Edwards]

On 2018-06-25, Steven D'Aprano  wrote:

> And the specific line you reference is *especially* a joke, one which 
> flies past nearly everyone's head:
>
>  There should be one-- and preferably only one --obvious way to do it.
>
> Notice the dashes? There are *two* traditional ways to use an pair
> of em- dashes for parenthetical asides:
>
> 1. With no space--like this--between the parenthetical aside and the text;
>
> 2. With a single space on either side -- like this -- between the aside 
> and the rest of the text.
>
> Not satisfied with those two ways, Tim invented his own.
>
> https://bugs.python.org/issue3364

Brilliant!

I don't know how I missed that.  I'm not sure which would be more
impressive: that Tim thought up the joke as described, or that it was
made up ex post facto.  Either one is brilliant.

-- 
Grant Edwards   grant.b.edwardsYow! I once decorated my
  at   apartment entirely in ten
  gmail.comfoot salad forks!!

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[jkn]

On Monday, June 25, 2018 at 12:17:29 PM UTC+1, Paul  Moore wrote:
> On 25 June 2018 at 11:53, Steven D'Aprano
>  wrote:
> 
> > And the specific line you reference is *especially* a joke, one which
> > flies past nearly everyone's head:
> >
> > There should be one-- and preferably only one --obvious way to do it.
> >
> >
> > Notice the dashes? There are *two* traditional ways to use an pair of em-
> > dashes for parenthetical asides:
> >
> > 1. With no space--like this--between the parenthetical aside and the text;
> >
> > 2. With a single space on either side -- like this -- between the aside
> > and the rest of the text.
> >
> > Not satisfied with those two ways, Tim invented his own.
> >
> >
> > https://bugs.python.org/issue3364
> >
> >
> > (Good grief, its been nearly ten years since that bug report. I remember
> > it like it was yesterday.)
> 
> Thank you for that bit of history! I never knew that (and indeed had
> missed that part of the joke). Tim's contributions to Python are
> always to be treasured :-)
> 
> Paul

Goodness, I too had missed that particular (admittedly subtle) joke, and I have
an interest in orthography and typesetting etc. (as well as pedanticism ;-o).

Yes, Tim Peters' contribution to python, and this newsgroup in days of yore,
were to be treasured. Luckily the wisdom and measured tone he and other early
pioneers modelled are (mostly) still with us here on comp.lang.python.

Jon N (here since 1999 or so...)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[Mark Lawrence]

On 25/06/18 10:10, Alister via Python-list wrote:

On Mon, 25 Jun 2018 11:36:25 +0400, Abdur-Rahmaan Janhangeer wrote:


i think he means like for a loop to iterate over a list you might do

list = [1,2,3]
for i in range(len(list)):
 print(list[i])


but the you might as well go for the simpler :


for elem in list:

  print(elem)

Abdur-Rahmaan Janhangeer https://github.com/Abdur-rahmaanJ





for i in range(len(list)): is a python anti-pattern it is almost a 100%
guarantee that you are doing something wrong*

*as with all rules of thumb there is probably at least 1 exception that
the python experts will now point out.




The exception is that if you really do need the index, you write:-

for i, elem in enumerate(list):

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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[Paul Moore]

On 25 June 2018 at 11:53, Steven D'Aprano
 wrote:

> And the specific line you reference is *especially* a joke, one which
> flies past nearly everyone's head:
>
> There should be one-- and preferably only one --obvious way to do it.
>
>
> Notice the dashes? There are *two* traditional ways to use an pair of em-
> dashes for parenthetical asides:
>
> 1. With no space--like this--between the parenthetical aside and the text;
>
> 2. With a single space on either side -- like this -- between the aside
> and the rest of the text.
>
> Not satisfied with those two ways, Tim invented his own.
>
>
> https://bugs.python.org/issue3364
>
>
> (Good grief, its been nearly ten years since that bug report. I remember
> it like it was yesterday.)

Thank you for that bit of history! I never knew that (and indeed had
missed that part of the joke). Tim's contributions to Python are
always to be treasured :-)

Paul
-- 
https://mail.python.org/mailman/listinfo/python-list