[Python-ideas] Re: Additional meanings for "in" operator and ability to customize implementation

[Ethan Furman]

On 10/14/2019 12:54 AM, Andrew Barnert via Python-ideas wrote:

On Oct 13, 2019, at 22:54, Chris Angelico  wrote:



Mathematically, what's the difference between '1' and '1+0j' (or
'1+0i')?



Again, think of Python, but don’t take the analogy too far. You can use `1` 
almost anywhere you can use a float, and it will almost always mean the same 
thing as `1.0` when you do. But that doesn’t mean when you use it in 
`isinstance(1, float)` it’s the same as `1.0`. So, is `'1'` a valid way of 
representing the float `1.0`? Yes if you’re doing arithmetic, no if you’re 
doing type-switching.


Interesting you should say that as I just had an instance of needing to use 0.0 
instead of 0 (aka False) to correctly communicate with an ORM back-end that I 
wanted an integer column with a zero value, not a null.

--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7GRWAZERS4JEKDMNBQWPHWHJFM6IZSG6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP: add a `no` keyword as an alias for `not`

[Ethan Furman]

On 08/01/2019 01:06 PM, Daniel Okey-Okoro wrote:


[an idea]


Two things:

1) please do not cross-post.

2) a PEP is a very particular thing* -- please do not say you have one unless 
you do. ;)

--
~Ethan~


* https://www.python.org/dev/peps/pep-0001/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/LBBDETP6E3KWSXS3JZODY2DYGNH5GUBO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: for ... except, with ... except

[Ethan Furman]

On 07/29/2019 06:35 PM, Steven D'Aprano wrote:


3. syntax that solves a problem, but may mislead people to think
it solves a different problem until they learn better;


3.1 syntax that solves a problem, but is misleading to many who are
still confused after they "have learnt better"


I feel your pain: I don't understand async code when I see it either.


Neither do I, but I have no need to.  I do have a need to use for...else, and every time 
I do I have to think through the "this is a search loop" to get the right 
semantics (sorry for bringing that up again, but it's a great example).

If this "with...except" leads to more robust code then I think many would like 
to use it, but not if it's confusing as that would lead to less robust code.

--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6GXB4NWIQM4Q27JOIGKJT3GQUWFO72XO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: for ... except, with ... except

[Ethan Furman]

On 07/29/2019 12:24 PM, Dominik Vilsmeier wrote:


I think the focus shouldn't be on whether such syntax is possibly confusing or 
not because

a) People will always remember that's *either* one way or the other


No, they won't.


b) It's actually pretty easy to remember which way it is, by just considering 
that a syntax feature exists for scenarios that can't be easily solved 
otherwise.


They also exist for scenarios that are easily resolved, but also easily gotten 
wrong:

  x += 1

instead of

  x = x + 1

I can easily see

  for this in some_iter:
  ...
  except ValueError():
  ..

as being syntactic sugar for

  for this in some_iter:
  try:
  ...
  except ValueError():
  ...

as it can easily save several levels of indenting.

--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/AVZALGGMB26JYA7OTWV4M46EJ5ZF7EFG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: for ... except, with ... except

[Ethan Furman]

[redirecting back to the list]

On 07/27/2019 09:38 PM, James Lu wrote:

On Jul 27, 2019, at 12:44 PM, Ethan Furman wrote:



Sure, folks /know/ what it means, but it's a common bug because
it doesn't read as "if some_var is assigned 7" but as "if some_var
 is equal to 7".


That’s a straw man- a modern linter or compiler would catch that.
 Many editors have linters integrated inside. The way to disable it
 is to put parentheses around the assignment expesssion.


___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TKH234SZCXCOCK2OTJPRZTWROY672QFQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Cartesian Product on `__mul__`

[Ethan Furman]

On 07/27/2019 03:17 AM, Batuhan Taskaya wrote:


Its more clear and understandable than itertools.product for people from outside of 
a programming background. The simplicity is useful when we are working with 
multiple expressions at sametime. (cset(a & b) * cset(a | b))


So build that functionality into cset.  I believe that's what NumPy does.

--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GUXBAEWSHE75E7SP2PBRCVNNI7H5WQVF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: for ... except, with ... except

[Ethan Furman]

On 07/27/2019 01:19 AM, Serhiy Storchaka wrote:

26.07.19 23:57, Guido van Rossum пише:



However, I worry that when people see this syntax, they will think that the 
except clause is for handling exceptions in the loop body. (That's certainly 
what I assumed when I read just your subject line. :-)


And it's what I thought when I saw the psuedo-code.


I think people can make a mistake only when they see it for the first time. 
After you learn what this syntax means, you will not make this mistake the 
second time. The same applies to any other syntactic construction.


Sorry, but that mistake will be made many, many times by the same people.  It's taken me 
several years to sort out `for...else`, and even now I have to think "it's a search 
loop, adapt your algorithm".

Another classic example is allowing single-"=" assignment in tests:

  if some_var = 7:
  ...

Sure, folks /know/ what it means, but it's a common bug because it doesn't read as "if 
some_var is assigned 7" but as "if some_var is equal to 7".

--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WGIGILBBHKAQ4CJHMBLRBYPNNOM3ZERT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Ethan Furman]

On 07/26/2019 09:52 AM, Dan Sommers wrote:


There Is Only One Way To Do It.


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

There is very little in Python that can only be done one way.

--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/LLLBNAM2M5WNCHVCRICEG75K6AWX2DLE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP's shouldn't require a sponsor

[Ethan Furman]

On 07/25/2019 05:31 AM, Batuhan Taskaya wrote:


What i see is when you post the ideas channel and it is something
 that doesnt change much on the frontside people dont care. And
 when people dont care, they forgot. PEP reviewing process is way
 better than posting to ideas and try to convince people.


If someone posts a PEP to python-dev as the first step, they will be told to 
take it to ideas for discussion.

If someone wants to post a PEP-like document to python-ideas they are welcome 
to do so -- possibly the only thing lacking to make it an official PEP is the 
PEP number, but that can be added later once you've got the support of a 
core-dev.

However, writing a PEP-like document is a serious investment of energy and 
time, and most ideas can be discarded long before with minimal discussion.

--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RGYVJ33BNAN3VH4Q4ML72XTGMNTKMUS2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: A proposal (and implementation) to add assignment and LOAD overloading

[Ethan Furman]

On 06/26/2019 07:34 AM, Anders Hovmöller wrote:


I 100% agree that this proposal is a bad idea. But I do have to play Devils 
advocate here.

The the-code-is-understandable-at-face-value ship has already sailed.
 + doesn't mean add, it means calling a dunder function that can do anything.


True, it can do anything -- but if the thing it does is not related to 
combining two things together and returning the result, people will be 
surprised and consider it a bad function.  (Or they should.  ;-)


Foo.bar = 1 doesn't mean set bar to 1 but calling a dunder method.


But the `Foo.` tells us Magic May Be Happening, and we still expect something 
reasonable to occur -- perhaps a boundary check, maybe a cache lookup, perhaps 
a type change to an equal-but-different representation (1.0 instead of 1, for 
example), or even setting other dependent variables.

--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/M4TZ2XZZJFUDGPIWKXGN3JJ2B22JC3CQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Overloading assignment concrete proposal (Re: Re: Operator as first class citizens -- like in scala -- or yet another new operator?)

[Ethan Furman]

On 06/20/2019 01:25 PM, nate lust wrote:


 --> class Foo:
 ... def __init__(self, o):
 ...         self.o = o
 ...     def __setself__(self, v):
 ...         self.v = v
 ... 



 --> f = Foo(5)
 --> print(f)
 <__main__.Foo object at 0x7f486bb8d300>



 --> print(f.o)
 5



 >>> print(f.v)
 Traceback (most recent call last):
    File "", line 1, in 
 AttributeError: 'Foo' object has no attribute 'v'



 --> f = "hello world"
 --> print(f.v)
 hello world



 --> print(f)
 <__main__.Foo object at 0x7f486bb8d300>


Thank you for doing the work of a proof-of-concept (and to Andrew Barnert for 
his excellent write-up).  I think this shows exactly why it's a bad idea -- 
even though I knew what you were doing, having `f` not be a string after the 
assignment was extremely surprising.

-1

--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/AFPG55GOZI2U6FK6N2VXYPAQDIJ36ATM/
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add "default" kwarg to list.pop()

[Ethan Furman]

On 10/31/2018 02:29 PM, Chris Angelico wrote:


Exactly how a team of core devs can make unified
decisions is a little up in the air at the moment


I wouldn't worry too much about it.  I don't think we have ever made 
entirely unified decisions.


--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEPs: Theory of operation [was: Moving to another forum system ...]

[Ethan Furman]

On 09/22/2018 05:52 AM, Anders Hovmöller wrote:


And now you made it sound even worse [...]


Their use of the word "you" is "everybody who wants to write a PEP", not 
you "Anders Hovmöller" specifically.  (Isn't English a wonderful 
language?  *sigh* )


--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Moving to another forum system where moderation is possible

[Ethan Furman]

On 09/20/2018 07:48 AM, James Lu wrote:


Were there any productive parts to that conversation?


Out of 85 messages, there was 1 for sure, possibly three more.

In the 95 "Retire or reword the namesake of the Language" thread there were 2.

Obviously my opinion, but I hope everyone would agree that the signal-to-noise 
ratio of those two threads was low.

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Moving to another forum system where moderation is possible

[Ethan Furman]

On 09/20/2018 07:23 AM, Oleg Broytman wrote:

On Thu, Sep 20, 2018 at 09:05:33AM -0400, Mark E. Haase wrote:

On Thu, Sep 20, 2018 at 8:09 AM Oleg Broytman wrote:

On Thu, Sep 20, 2018 at 01:46:10PM +0400, Abdur-Rahmaan Janhangeer wrote:



i miss a +1 button


It's absence is a big advantage. We're not a social network with
"likes". We don't need a bunch of argumentless "voting"


It's difficult to keep track of all these disparate, unstructured votes


There is no need to track them.


GitHub added +1 and -1 buttons


GitHub is a social network so it's natural for them to add "likes".


(If I could have +1'ed Abdur-Rahmaan's e-mail, I wouldn't have written this
response.)


That message was rather bad in my not so humble opinion -- it was
just "I want my +1 button" without any argument. Your message is much
better as it have arguments. See, the absence of the button work!

We're proposing and *discussing* things here not "likes" each other.
Write your arguments or be silent.


The number of people who have the same argument is also a factor.  I would rather have the argument once with 15 +1s 
than 16 posts all saying the same thing.  A "like" on an argument means "I agree" -- which is valuable information to have.


--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Moving to another forum system where moderation is possible

[Ethan Furman]

On 09/18/2018 12:05 PM, Franklin? Lee wrote:

On Tue, Sep 18, 2018 at 2:37 PM Jonathan Goble wrote:



Perhaps not, but part of that might be because stopping an active

>> discussion on a mailing list can be hard to do, so one might not even
>> try. Some discussions, I suspect, may have gone on in circles long past
>> the point where they would have been locked on a forum. With forum
>> software, it becomes much easier, and would be a more effective tool to
>> terminate discussions that are going nowhere fast and wasting everyone's
>> time.

True.


But there's no evidence that such tools would help. Software
enforcement powers are only necessary if verbal enforcement isn't
enough. We need the current moderators (or just Brett) to say whether
they feel it isn't enough.


It isn't enough.


What people may really be clamoring for is a larger moderation team,
or a heavier hand. They want more enforcement, not more effective
enforcement.


More ineffective enforcement will be, um, ineffective.

Let's have a test.  I'm a moderator (from -List).  We're* working on avenues to improve the mailing tools and 
simultaneously testing other options.  I'm not seeing anything new in this thread that will impact that one way or 
another, so I'm asking for all of us to move on to other topics.


--
~Ethan~


* Various moderators from various lists.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Moving to another forum system where moderation is possible

[Ethan Furman]

On 09/17/2018 01:16 PM, James Lu wrote:


So... we’re going to be using discourse instead of Python-ideas mailing list?


No.  None of the mailing lists will be migrated at this time.  The plan is to get a test instance set up, tried for a 
while on a specific issue or two, and evaluate our experiences then.


We are also investigating ways to make the mailing lists themselves more 
manageable.

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Revert "RuntimeError: generator raised StopIteration"

[Ethan Furman]

On 09/17/2018 11:06 AM, Danilo J. S. Bellini wrote:


The idea is simple: restore the "next" built-in and the "StopIteration" 
propagation behavior from Python 3.6.


Unlikely to happen.  In 3.6 a deprecation warning started being issued for next inside generators that said it would 
raise a different exception in 3.7 [1].


--
~Ethan~


[1] PEP 479: https://docs.python.org/3/whatsnew/3.5.html#whatsnew-pep-479
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Keyword only argument on function call

[Ethan Furman]

On 09/12/2018 05:17 AM, Steven D'Aprano wrote:

> Indeed. Each time you call locals(), it returns a new dict with a

snapshot of the current local namespace. Because it all happens inside
the same function call, no external thread can poke inside your current
call to mess with your local variables.

But that's different from setting function.__params__ to passed in
arguments. By definition, each external caller is passing in its own set
of arguments. If you have three calls to the function:

 function(a=1, b=2)  # called by A
 function(a=5, b=8)  # called by B
 function(a=3, b=4)  # called by C

In single-threaded code, there's no problem here:

 A makes the first call;
 the interpreter sets function.__params__ to A's arguments;
 the function runs with A's arguments and returns;

 only then can B make its call;
 the interpreter sets function.__params__ to B's arguments;
 the function runs with B's arguments and returns;

 only then can C make its call;
 the interpreter sets function.__params__ to C's arguments;
 the function runs with C's arguments and returns


but in multi-threaded code, unless there's some form of locking, the
three sets can interleave in any unpredictable order, e.g.:

 A makes its call;
 B makes its call;
 the interpreter sets function.__params__ to B's arguments;
 the interpreter sets function.__params__ to A's arguments;
 the function runs with B's arguments and returns;
 C make its call;
 the interpreter sets function.__params__ to C's arguments;
 the function runs with A's arguments and returns;
 the function runs with C's arguments and returns.


We could solve this race condition with locking, or by making the pair
of steps:

 the interpreter sets function.__params__
 the function runs and returns

a single atomic step. But that introduces a deadlock: once A calls
function(), threads B and C will pause (potentially for a very long
time) waiting for A's call to complete, before they can call the same
function.

I'm not an expert on threaded code, so it is possible I've missed some
non-obvious fix for this, but I expect not. In general, solving race
conditions without deadlocks is a hard problem.


I believe the solution is `threading.local()`, and Python would 
automatically use it in these situations.


--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Keyword only argument on function call

[Ethan Furman]

On 09/10/2018 12:52 PM, Chris Barker via Python-ideas wrote:

I've spent this whole thread thinking: "who in the world is writing code 
with a lot of spam=spam arguments? If you are transferring that much 
state in a function call, maybe you should have a class that holds that 
state? Or pass in a **kwargs dict?



So still looking for a compelling use-case


In my day job I spend a lot of time writing/customizing modules for a 
framework called OpenERP (now Odoo*).  Those modules are all subclasses, 
and most work will require updating at least a couple parent metheds -- 
so most calls look something like:


  def a_method(self, cr, uid, ids, values, context=None):
...
super(self, parent).a_method(cr, uid, ids, values, context=context)

Not a perfect example as these can all be positional, but it's the type 
of code where this syntax would shine.


I think, however, that we shouldn't worry about a lead * to activate it, 
just use a leading '=' and let it show up anywhere and it follows the 
same semantics/restrictions as current positional vs keyword args:


  def example(filename, mode, spin, color, charge, orientation):
  pass

  example('a name', 'ro', =spin, =color, charge=last, =orientation)

So +0 with the above proposal.

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python dialect that compiles into python

[Ethan Furman]

On 09/07/2018 04:57 AM, Robert Vanden Eynde wrote:


Actually, I might start to write this lib, that looks fun.


You should also check out MacroPy:

  https://pypi.org/project/MacroPy/

Although I freely admit I don't know if does what you are talking about.

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python-ideas Digest, Vol 142, Issue 22

[Ethan Furman]

On 09/07/2018 12:09 PM, James Lu wrote:

[stuff]

James, the digest you replied to had four different topics, and I have no idea how many individual messages.  You didn't 
change the subject line, and you didn't trim the text you were not replying to.


Which thread/message were you replying to?

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Keyword only argument on function call

[Ethan Furman]

On 09/06/2018 07:05 AM, Anders Hovmöller wrote:

On Thursday, September 6, 2018 at 3:11:46 PM UTC+2, Steven D'Aprano wrote:

On Thu, Sep 06, 2018 at 12:15:46PM +0200, Anders Hovmöller wrote:



Wouldn't it be awesome if [...]


No.


Heh. I did expect the first mail to be uncivil :P


Direct disagreement is not uncivil, just direct.  You asked a yes/no question and got a yes/no answer.  D'Aprano's 
comments further down are also not uncivil, just explicative (not expletive ;) ) of his position.


As for your proposal, I agree with D'Aprano -- this is a lot machinery to support a use-case that doesn't feel 
compelling to me, and I do tend to name my variables the same when I can.


--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Pre-conditions and post-conditions

[Ethan Furman]

On 08/30/2018 01:49 PM, Marko Ristin-Kaufmann wrote:


classC(A):
 # C.some_func also inherits the contracts from A.
 #   It weakens the precondition:
 #   it operates either on sorted lists OR
 #   the lists that are shorter than 10 elements.
 #
 #  It strenghthens the postcondition:
 #   It needs to return an integer larger than
 #   the length of the input list AND
 #   the result needs to be divisible by 2.
 @icontract.post(lambdaresult: result %2==0)
 defsome_func(self, lst: List[int]) ->int:
 # ...


I think you forgot an @icontract.pre() here.

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Pre-conditions and post-conditions

[Ethan Furman]

On 08/29/2018 04:53 PM, Hugh Fisher wrote:

From: Marko Ristin-Kaufmann:



There seems to be evidence that design-by-contract is useful. Let me cite
Bertrand Meyer from his article "Why not program right?" that I already
mentioned before:


I don't think that being useful by itself should be enough. I think new features
should also be "Pythonic" and I don't see design by contract notation as a
good fit.


I don't see type annotation notation as a good fit, either, and yet we have it.  Seems to me that DbC would be just as 
useful as type annotations (and I find D'Aprano's example syntax very readable).



For design by contract, as others have noted Python assert statements
work fine for simple preconditions and postconditions.


And print statements work fine for simple debugging.  New features are not added for the simple cases, but the complex, 
or non-obviously correct, or the very useful cases.



Yes there's more to design by contract than simple assertions, but it's not
just adding syntax. Meyer often uses the special "old" construct in his post
condition examples, a trivial example being

 ensure count = old.count + 1


I can see where that could get expensive quickly.


How do we do that in Python? And another part of design by contract (at
least according to Meyer) is that it's not enough to just raise an exception,
but there must be a guarantee that it is handled and the post conditions
and/or invariants restored.


Well, we don't have to have exactly the same kind of DbC as Eiffel does.

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Should nested classes in an Enum be Enum members?

[Ethan Furman]

On 07/01/2018 06:03 AM, Ivan Levkivskyi wrote:> On 27 June 2018 at 15:46, Ethan 
Furman wrote:


[...]
So I'm asking the community:  What real-world examples can you offer for either 
behavior?  Cases where nested
classes should be enum members, and cases where nested classes should not be 
members.


I wanted few times to make an enum of enums. For example:

class  Method(Enum):
 Powell = 1
 Newton_CG = 2
 
 class Trust(Enum):
 Constr = 3
 Exact = 4
 

So that one can write:

minimize(..., method=Method.Powell)
minimize(..., method=Method.Trust.Exact)  # this currently fails


In such a case, would you want/expect for

--> list(Method)

to return

[, , ..., ]

?

--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Should nested classes in an Enum be Enum members?

[Ethan Furman]

On 06/27/2018 12:04 PM, Elazar wrote:
> בתאריך יום ד׳, 27 ביוני 2018, 11:59, מאת Guido van Rossum:

>> Sounds to me really strange that the nested class would become a member.
>> Probably because everything becomes a member unless it's a function
>> (maybe decorated)?
>

People working with sum types might expect the instances of the nested

> class to be instances of the enclosing class. So if the nested class is
> a namedtuple, you get a sum type. The only problem is that there's no
> way to express this subtype relationship in code.

I have no idea what you just said.  :(  Is there a link you can share that 
might explain it?

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Should nested classes in an Enum be Enum members?

[Ethan Furman]

On 06/27/2018 11:52 AM, Guido van Rossum wrote:


Sounds to me really strange that the nested class would become a member. 
Probably because everything becomes a member
unless it's a function (maybe decorated)?


Pretty much.  __dunders__, _sunders_, and descriptors do not get transformed.  
Everything else does.

--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Should nested classes in an Enum be Enum members?

[Ethan Furman]

Consider the following Enum definition:

  class Color(Enum):
  RED = 1
  GREEN = 2
  BLUE = 3
  @property
  def lower(self):
  return self.name.lower()
  def spam(self):
  return "I like %s eggs and spam!" % self.lower
  class SomeClass:
  pass

Which of the above Color attributes are enums, and which aren't?


.


.


.

Answer:

  - RED, GREEN, and BLUE are members

  - lower and spam() are not

  - SomeClass /is/ a member (but not its instances)


Question:

  Should `SomeClass` be an enum member?  When would it be useful to have an 
embedded class in an Enum be an enum member?


The only example I have seen so far of nested classes in an Enum is when folks want to make an Enum of Enums, and the 
nested Enum should not itself be an enum member.  Since the counter-example already works I haven't seen any requests 
for it.  ;)


So I'm asking the community:  What real-world examples can you offer for either behavior?  Cases where nested classes 
should be enum members, and cases where nested classes should not be members.


Thanks!

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] exception instantiation philosophy and practice [was: Let try-except check the exception instance]

[Ethan Furman]

On 05/31/2018 07:36 AM, Nick Coghlan wrote:


The exception machinery deliberately attempts to avoid instantiating exception 
objects whenever it can, but that gets
significantly more difficult if we always need to create the instance before we 
can decide whether or not the raised
exception matches the given exception handler criteria.


Why is this?  Doesn't the exception have to be instantiated at some point, even 
if just to print to stderr?

--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] OT: slowing rotation [was: High Precision datetime]

[Ethan Furman]

On 05/17/2018 12:13 PM, Tim Peters wrote:


Other things can cause the Earth's rotation to speed up temporarily
(like some major geological events), but they've only been able to
overcome factors acting to slow rotation for brief periods, and never
yet got near to overcoming them by a full second.


How long before the earth stops rotating?  When it does, will we be tide-locked with the sun, or will an earth day 
become an earth year?


Inquiring-minds-want-to-know'ly yrs;

--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Verbatim names (allowing keywords as names)

[Ethan Furman]

On 05/15/2018 08:03 PM, Carl Smith wrote:

On Tue, May 15, 2018 at 8:41 PM, Steven D'Aprano wrote:



I'd like to suggest we copy C#'s idea of verbatim identifiers, but using
a backslash rather than @ sign:

 \name

would allow "name" to be used as an identifier, even if it clashes with
a keyword.


I strongly disagree, but can't seem to get anyone  to bite.


Sometimes it's like that, and yes it is frustrating.


We want to be able to introduce a keyword that was formally a name, still
allow
it to be used as a name, still allow code that uses it as a keyword to
interoperate
​ ​
with code that uses it as a name, without changing the language
or implementation  too much.

​Ideally, Python would still not allow the keyword to be used as a name and a
keyword in the same file??


For me at least, this is a deal breaker.  My libraries tend to be single-file packages, so all my code is in one place 
-- only being able to use the keyname as one or the other in my multi-thousand line file does me no good.


--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Ethan Furman]

On 05/13/2018 10:57 PM, Greg Ewing wrote:

Rob Cliffe via Python-ideas wrote:



If you forbid redefining keywords, you remove the whole point of this proposal:


I mean the keywords that are in the language as of now.
There will never be a need to redefine those, since no
current code uses them as names.


Part of the point of the proposal is to be able to use existing keywords (at 
least, I thought it was).

--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Ethan Furman]

On 05/12/2018 11:41 PM, Tim Peters wrote:

[Tim, suggests changes to the Reference Manual's 4.2.1]

"""
An assignment expression binds the target, except in a function F
synthesized to implement a list comprehension or generator expression
(see XXX).  In the latter case, if the target is not in F's
environment (see section 4.2.2) , the target is bound in the block
containing F.
"""


Let me try that again ;-)  The notion of "environment" includes the
global scope, but that's not really wanted here.   "Environment" has
more of a runtime flavor anyway.  And since nobody will tell me
anything about class scope, I read the docs myself ;-)

And that's a problem, I think!  If a comprehension C is in class scope
S, apparently the class locals are _not_ in C's environment.  Since C
doesn't even have read access to S's locals, it seems to me bizarre
that ":=" could _create_ a local in S.


Python 3.7.0b3+ (heads/bpo-33217-dirty:28c1790, Apr  5 2018, 13:10:10)
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
--> class C:
...   huh = 7
...   hah = [i for i in range(huh)]
...
--> C.hah
[0, 1, 2, 3, 4, 5, 6]

Same results clear back to 3.3 (the oldest version of 3 I have).  Are the docs 
wrong?

Or maybe they just refer to functions:

--> class C:
...   huh = 7
...   hah = [i for i in range(huh)]
...   heh = lambda: [i for i in range(huh)]
...
--> C.hah
[0, 1, 2, 3, 4, 5, 6]
--> C.heh()
Traceback (most recent call last):
  File "test_class_comp.py", line 7, in 
print(C.heh())
  File "test_class_comp.py", line 4, in 
heh = lambda: [i for i in range(huh)]
NameError: global name 'huh' is not defined

So a class-scope comprehension assignment expression should behave as you 
originally specified.

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] High Precision datetime

[Ethan Furman]

On 05/10/2018 10:30 AM, Ed Page wrote:


Alternatives
- My company create our own datetime library
   - Continued fracturing of time ... ecosystem (datetime, arrow, pendulum, 
delorean, datetime64, pandas.Timestamp


Or, team up with one of those (if you can).

--
~Ethan~



___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572: about the operator precedence of :=

[Ethan Furman]

On 05/10/2018 09:29 AM, M.-A. Lemburg wrote:

On 10.05.2018 15:57, Guido van Rossum wrote:

On Thu, May 10, 2018 at 5:04 AM, M.-A. Lemburg wrote:



To a (former Pascal) programmer, a := 1 doesn't read like an
operator. It's an assignment expression. If embedded expressions
is where Python is heading, it should be made very clear where
the embedded expression starts and where it ends on a line.



The rules we've arrived at are about as straightforward as it gets: the RHS
of `:=` ends at the nearest comma or close parenthesis/bracket/brace.


That may be easy for a computer to parse, but it's not for
a programmer. It would be better to contain such expressions
inside a safe container which is clearly visible to a human
eye.

ohoh = a := (1, 2, 3), 4, a * 2


I have no problem reading that.


vs.

aha  = ((a := (1, 2, 3)), 4, a * 2)


The extra parens are unneeded line noise (at least for me).

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A "local" pseudo-function

[Ethan Furman]

On 04/29/2018 01:20 PM, Tim Peters wrote:


So, e.g.,

"""
a = 42

def showa():
 print(a)

def run():
 global a

 local a: # assuming this existed
 a = 43
 showa()
 showa()
"""

would print 43 and then 42.  Which makes "local a:" sound senseless on
the face of it ;-)  "shadow" would be a more descriptive name for what
it actually does.


Yeah, "shadow" would be a better name than "local", considering that it effectively temporarily changes what other 
functions see as global.  Talk about a debugging nightmare!  ;)


--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A "local" pseudo-function

[Ethan Furman]

On 04/28/2018 10:16 AM, Tim Peters wrote:


... but do realize that since PEP 572 dropped any
notion of sublocal scopes, that recurring issue remains wholly
unaddressed regardless.


If we need a sublocal scope, I think the most Pythonic* route to have it would 
be:

with sublocal():
blah blah

which would act just like local/global does now:

  - any assignment creates a new variable
- unless that variable has been declared global/nonlocal
  - plain reads (no assignment ever happens) refer to nonlocal/global/built-in
names

This has the advantages of:

 - no confusion about which variables are sublocal (acts like a new function 
scope)
 - no extra parens, assignments, expressions on "with sublocal():" line

Possible enhancements:

 - give sublocal block a name "with sublocal() as blahblah:" and then reuse 
that block
   again later ("with blahblah:") or maybe pass it to other functions...

Of course, as previously stated, this is orthogonal to PEP 572.

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A "local" pseudo-function

[Ethan Furman]

On 04/27/2018 07:37 PM, Tim Peters wrote:


Idea:  introduce a "local" pseudo-function to capture the idea of
initialized names with limited scope.



Note:  the thing I'm most interested in isn't debates, but in whether
this would be of real use in real code.


I keep going back and forth on the ":=" syntax as on the one hand I find the functionality very useful but on the other 
hand it's ugly and doesn't really read well.


However, I can say I am solidly

-1

on local, let, etc.:

- local() vs locals(): very similar words with disparate meanings
- more parens -- ugh
- sublocal: one more scope for extra complexity

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Change magic strings to enums

[Ethan Furman]

On 04/25/2018 03:15 AM, Ivan Levkivskyi wrote:

On 25 April 2018 at 11:03, Serhiy Storchaka wrote:



Creating a new function is very cheap -- just around 50 ns on my computer.

Creating a new class is over two orders costly -- around 7 us for an empty 
class on my computer.

Creating a new Enum class is much more costly -- around 40 us for an empty 
class (or 50 us for IntEnum) plus 7 us
per member.


Hm, this is what I wanted to know. I think by rewriting EnumMeta in C we can 
reduce the creation time of an Enum class
(almost) down to the creation time of a normal class, which may be a 4-5x 
speed-up. What do you think?


Someone else would have to take that on (a C version of EnumMeta) -- my C skills are not up to that task and I do not 
currently possess the time to get them there.


--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Change magic strings to enums

[Ethan Furman]

On 04/24/2018 10:32 AM, Antoine Pitrou wrote:


Also beware the import time cost of having a widely-used module like
"warnings" depend on the "enum" module and its own dependencies.


With all the recent changes to Python, I should go through and see which 
dependencies are no longer needed.

--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572: Assignment Expressions (post #4)

[Ethan Furman]

On 04/10/2018 10:32 PM, Chris Angelico wrote:


PEP: 572
Title: Assignment Expressions
Author: Chris Angelico 


Chris, I think you've gotten all the feedback you need.  Pick a symbol (I'd say either ":=" or "as"), and slap this 
puppy over onto python-dev.


--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Spelling of Assignment Expressions PEP 572 (was post #4)

[Ethan Furman]

On 04/16/2018 10:36 AM, Chris Angelico wrote:


Not after it got trimmed, no. Here's what I actually said in my original post:

while (read_next_item() -> items[i + 1 -> i]) is not None:
 print("%d/%d..." % (i, len(items)), end="\r")

Now, if THAT is your assignment target, are you still as happy as you
had been, or are you assuming that the target is a simple name?


I'm okay with it, although I'd still prefer "as".  But, really, as long as we 
get it* I'll be happy.

--
~Ethan~


* "it" being, of course, assignment-expressions.  :)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Spelling of Assignment Expressions PEP 572 (was post #4)

[Ethan Furman]

On 04/14/2018 08:08 PM, Nick Coghlan wrote:


New keyword based target first proposal:

 while (value from read_next_item()) is not None:
 ...


I could get behind this.

Current preferencs:

"as"  +1

"from"  +0.85

":=" +0.5

--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Spelling of Assignment Expressions PEP 572 (was post #4)

[Ethan Furman]

On 04/13/2018 05:02 AM, Jacco van Dorp wrote:


I must admit I like putting the expression first, though. Even if it's
just to make it harder to mix it up with normal assignment. Perhaps =>
could be used - it's a new token, unlike -> which is used to annotate
return values, it's not legal syntax now(so no backwards compatibility
issues), and used a for similar purposes in for example php when
declaring associative arrays.($arr = array("key"=>"value");). I'm not
convinced myself, though.


The problem with => is that it's the opposite of >= which means typos would not 
cause SyntaxError and be hard to spot.

--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572: Assignment Expressions (post #4)

[Ethan Furman]

On 04/12/2018 09:52 PM, Chris Angelico wrote:


foo := a > b   # does this capture 'a', or 'a > b'?
bar := c + d   # 'c' or 'c + d'?

I'm open to argument here, but my thinking is that these should
capture 'a' and 'c + d'.


I think := should act the same as = or there will be plenty of confusion.  If one wants to capture less then parenthesis 
can be used to narrow it down:


  (foo := a) > b

Looked at another way -- you already have the value named as 'a', so why would 
you also name it as 'foo'?

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572: Assignment Expressions (post #4)

[Ethan Furman]

On 04/10/2018 10:32 PM, Chris Angelico wrote:


Title: Assignment Expressions


Thank you, Chris, for doing all this!

---

Personally, I'm likely to only use this feature in `if` and `while` statements; if the syntax was easier to read inside 
longer expressions then I might use this elsewhere -- but as has been noted by others, the on-the-spot assignment 
creates asymmetries that further clutter the overall expression.


As Paul noted, I don't think parenthesis should be mandatory if the parser 
itself does not require them.

For myself, I prefer the EXPR as NAME variant for two reasons:

- puts the calculation first, which is what we are used to seeing in if/while 
statements; and
- matches already existing expression-level assignments (context managers, 
try/except blocks)

+0.5 from me.

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572: Assignment Expressions (post #4)

[Ethan Furman]

On 04/10/2018 10:32 PM, Chris Angelico wrote:


Migration path
==

The semantic changes to list/set/dict comprehensions, and more so to generator
expressions, may potentially require migration of code. In many cases, the
changes simply make legal what used to raise an exception, but there are some
edge cases that were previously legal and are not, and a few corner cases with
altered semantics.


s/previously legal and are not/previously legal and now are not/

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Move optional data out of pyc files

[Ethan Furman]

On 04/10/2018 10:54 AM, Zachary Ware wrote:

On Tue, Apr 10, 2018 at 12:38 PM, Chris Angelico  wrote:

A deployed Python distribution generally has .pyc files for all of the
standard library. I don't think people want to lose the ability to
call help(), and unless I'm misunderstanding, that requires
docstrings. So this will mean twice as many files and twice as many
file-open calls to import from the standard library. What will be the
impact on startup time?


What about instead of separate files turning the single file into a
pseudo-zip file containing all of the proposed files, and provide a
simple tool for removing whatever parts you don't want?


-O and -OO already do some trimming; perhaps going that route instead of having 
multiple files would be better.

--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

[Ethan Furman]

On 04/05/2018 05:37 PM, Steven D'Aprano wrote:

On Thu, Apr 05, 2018 at 05:31:41PM -0700, Ethan Furman wrote:



[snip unkind words]


Be fair. Strip out the last "from average = 0" and we have little that
isn't either in Python or is currently being proposed elsewhere.


Ugh.  Thanks for reminding me, Steven.

Peter, my apologies.  It's been a frustrating day for me and I shouldn't have 
taken it out on you.

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

[Ethan Furman]

On 04/05/2018 03:24 PM, Peter O'Connor wrote:


Well, whether you factor out the loop-function is a separate issue.  Lets say 
we do:

 smooth_signal = [average = compute_avg(average, x) for x in signal from 
average=0]

Is just as readable and maintainable as your expanded version, but saves 4 
lines of code.  What's not to love?


It is not readable and it is not Python (and hopefully never will be).

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

[Ethan Furman]

On 04/05/2018 09:52 AM, Peter O'Connor wrote:


[snip html code snippets]


Please don't use html markup.  The code was very difficult to read.

--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Fixing class scope brainstorm

[Ethan Furman]

On 03/27/2018 11:12 AM, Ivan Levkivskyi wrote:

On 27 March 2018 at 18:19, Guido van Rossum wrote:



Hm, so maybe we shouldn't touch lambda, but we can at least fix the scope 
issues for comprehensions and genexprs.


Removing the implicit function scope in comprehensions is something I wanted 
for long time.
It would not only "fix" the scoping, but will also fix the yield inside 
comprehensions.


Can we do it without leaking names?

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

[Ethan Furman]

On 03/25/2018 09:46 AM, Ethan Furman wrote:

On 03/24/2018 09:24 PM, Nick Coghlan wrote:


No, the fact that the expression defining the outermost iterable gets evaluated 
in the outer scope is behaviour that's
explicitly tested for in the regression test suite.

The language reference spells out that this is intentional for generator 
expressions, where it has the added benefit of
reporting errors in the outermost iterable expression at the point where the 
genexp is defined, rather than at the point
where it gets iterated over: 
https://docs.python.org/3/reference/expressions.html#generator-expressions

Independently of the pragmatic "getting them to work sensibly at class scope" 
motivation, comprehensions inherit those
semantics by way of the intended semantic equivalence between "[x for x in sequence]" and 
"list(x for x in sequence)".


Thank you (everyone!) for your patience.

Using the latest example from Angelico and myself:

--> d = 9
... def func(_iter):
... ... body of comprehension
--> func((d as e))

The sticking point is the `func((d as e))`, which to my mind should happen 
inside the comprehension, but needs to happen
outside -- and the reason it has to happen outside is so that the interpretor 
can verify that `d` actually exists;
however, I think we can have both:

--> def func(_iter):
... ...
... e = d
... ...
--> d
--> func()

This way, the assignment does not leak, but the referenced name is still looked 
up and verified to exist outside the
function call.

I don't know how easy/difficult that would be to implement.  At this point a 
simple confirmation that I understand and
that in theory the above would solve both issues is what I'm looking for.  Or, 
of course, the reasons why the above
would not, in theory, work.


Any insights here?  I would rather not say the same things in another thread if we can resolve this question here and be 
done with it.  :)


--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

[Ethan Furman]

On 03/24/2018 09:24 PM, Nick Coghlan wrote:


No, the fact that the expression defining the outermost iterable gets evaluated 
in the outer scope is behaviour that's
explicitly tested for in the regression test suite.

The language reference spells out that this is intentional for generator 
expressions, where it has the added benefit of
reporting errors in the outermost iterable expression at the point where the 
genexp is defined, rather than at the point
where it gets iterated over: 
https://docs.python.org/3/reference/expressions.html#generator-expressions

Independently of the pragmatic "getting them to work sensibly at class scope" 
motivation, comprehensions inherit those
semantics by way of the intended semantic equivalence between "[x for x in sequence]" and 
"list(x for x in sequence)".


Thank you (everyone!) for your patience.

Using the latest example from Angelico and myself:

--> d = 9
... def func(_iter):
... ... body of comprehension
--> func((d as e))

The sticking point is the `func((d as e))`, which to my mind should happen inside the comprehension, but needs to happen 
outside -- and the reason it has to happen outside is so that the interpretor can verify that `d` actually exists; 
however, I think we can have both:


--> def func(_iter):
... ...
... e = d
... ...
--> d
--> func()

This way, the assignment does not leak, but the referenced name is still looked up and verified to exist outside the 
function call.


I don't know how easy/difficult that would be to implement.  At this point a simple confirmation that I understand and 
that in theory the above would solve both issues is what I'm looking for.  Or, of course, the reasons why the above 
would not, in theory, work.


--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

[Ethan Furman]

On 03/24/2018 09:00 PM, Chris Angelico wrote:

On Sun, Mar 25, 2018 at 2:59 PM, Ethan Furman wrote:

On 03/24/2018 08:51 PM, Chris Angelico wrote:



Let's suppose we have assignment expressions. I'm going to use "(expr
as name)" syntax for this example.

a = [(1 as b) for c in (d as e) if (2 as f)]

Which of these six names is local to the comprehension and which can
leak? Due to the requirements of class scope, 'd' must be looked up in
the outer scope. That means that its corresponding 'as e' must also
land in the outer scope. [...]



Why?

d = 9
def func():
   e = d

d is looked up outside of func, but e is still local to func.


No, it's looked up inside func, and the value is found outside of
func. Consider:

d = 9
def func():
 e = d
 d = 1


That is invalid Python.


What's happening with a comprehension is more like:

d = 9
def func(_iter):
 ... body of comprehension
func((d as e))

which is looking it up _outside_ the function, then passing it as a parameter.


Looks like a buggy implementation detail.  Any assignments that happen inside a listcomp should be effective only inside 
the listcomp.


--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

[Ethan Furman]

On 03/24/2018 08:51 PM, Chris Angelico wrote:

On Sun, Mar 25, 2018 at 2:48 PM, Ethan Furman wrote:

On 03/24/2018 01:35 AM, Nick Coghlan wrote:


In comprehensions and generator expressions, we'd need to explain why
inline assignments in the outermost iterator
expression leak but those in filter expressions, inner iterator
expressions, and result expressions don't.


I don't understand -- could you give an example?


Let's suppose we have assignment expressions. I'm going to use "(expr
as name)" syntax for this example.

a = [(1 as b) for c in (d as e) if (2 as f)]

Which of these six names is local to the comprehension and which can
leak? Due to the requirements of class scope, 'd' must be looked up in
the outer scope. That means that its corresponding 'as e' must also
land in the outer scope. [...]


Why?

d = 9
def func():
  e = d

d is looked up outside of func, but e is still local to func.

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

[Ethan Furman]

On 03/24/2018 01:35 AM, Nick Coghlan wrote:


In comprehensions and generator expressions, we'd need to explain why inline 
assignments in the outermost iterator
expression leak but those in filter expressions, inner iterator expressions, 
and result expressions don't.


I don't understand -- could you give an example?

--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

[Ethan Furman]

On 03/24/2018 09:27 AM, Rob Cliffe via Python-ideas wrote:

On 24/03/2018 14:44, Steven D'Aprano wrote:

On Sat, Mar 24, 2018 at 07:12:49PM +1000, Nick Coghlan wrote:



For PEP 572, the most directly comparable example is code like this:

 # Any previous binding of "m" is lost completely on the next line
 m = re.match(...)
 if m:
 print(m.groups(0))

In order to re-use that snippet, you need to double-check the surrounding
code and make sure that you're not overwriting an "m" variable already used
somewhere else in the current scope.

>>

Yes. So what? I'm going to be doing that regardless of whether the
interpreter places this use of m in its own scope or not. The scope as
seen by the interpreter is not important.

>

Good for you.  But the proposed scoping rules are an extra safeguard for 
programmers who are less conscientious than
you, or for anyone (including you) who is short of time, or misses something.  
An extra level of protection against
introducing a bug is IMO a Good Thing.


But it's not a free thing.  Our cars have seat belts, not six-point restraints, and either way the best practice is to 
be aware of one's surroundings, not rely on the safeguards to protect us against carelessness.




To the extent that this proposal to add sub-function scoping encourages
people to do copy-paste coding without even renaming variables to
something appropriate for the function they're pasted into, I think this
will strongly hurts readability in the long run.

>

I think it will aid readability, precisely for the reason Nick gives: you need 
to make fewer checks whether variables
are or are not used elsewhere.


Extra levels of intermingled scope are extra complication (for humans, too!); extra complication does not (usually) help 
readability -- I agree with D'Aprano that this is not a helpful complication.


--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

[Ethan Furman]

On 03/24/2018 07:44 AM, Steven D'Aprano wrote:


I don't think we need sub-function scoping. I think it adds more
complexity that outweighs whatever benefit it gives.


+1

--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

[Ethan Furman]

On 03/23/2018 07:38 PM, Chris Angelico wrote:

On Sat, Mar 24, 2018 at 3:58 AM, Guido van Rossum wrote:

On Fri, Mar 23, 2018 at 9:34 AM, Christoph Groth wrote:



But wouldn't it be a good alternative to PEP 572 to *add* an assignment
operator that is an expression to Python, and is distinct from "=", for
example ":="?

>>

I also think it's fair to at least reconsider adding inline assignment, with
the "traditional" semantics (possibly with mandatory parentheses). This
would be easier to learn and understand for people who are familiar with it
from other languages (C++, Java, JavaScript).


Thank you; both of these have now been incorporated into the document.


I'm certainly hoping PEP 572 is rejected so we can have a follow-up PEP that only deals with the 
assignment-as-expression portion.


No offense intended, Chris!  :)  In fact, maybe you could write that one too, and then have an accepted PEP to your 
name?  ;)


--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Class autoload

[Ethan Furman]

On 03/03/2018 10:46 AM, Jamesie Pic wrote:


While i understand it would be harder to make it memory efficient, but this is 
python not go, and also this sort feature
could be easily optional, also, it might even help against circular import 
issues, whoever hasn't imported a module from
inside a function in their life may throw the first rock at my face (kidding)

Yes i know it's sad php has this feature and python does not and again i'm not 
proud to say this but it's true.


Not sad at all.  It's a misfeature that Python is better off without.

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

[Ethan Furman]

On 03/02/2018 11:11 PM, Nick Coghlan wrote:

On 3 March 2018 at 03:51, Ethan Furman wrote:



Ah, right.  Since the PEP primarily covers comprehensions, but then went on to 
discuss multi-line statements, I had
forgotten the comprehension part.  The answer is easy:  assignment expressions 
in comprehensions stay inside
comprehensions, just like other inner comprehension variables already do 
(function sub-scope, after all).  Thank you
for pointing that out.


That wasn't the point I was try to make: my attempted point was that I see allowing 
an expression like "print((f() as
x), x^2, x^3)" to overwrite the regular function local "x" as being just as 
unacceptable as "data = [x^2 for x in
sequence]" overwriting it, and we already decided that the latter was 
sufficiently undesirable that we were willing to
break backwards compatibility in order to change it.


I think I explained myself poorly.  I'm agreeing with you, and pointing out that the (var as expr) syntax /inside/ a 
comprehension would stay inside a comprehension, i.e. not leak out to locals(), just like your "x" above.


--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

[Ethan Furman]

On 03/02/2018 07:30 PM, Chris Angelico wrote:

On Sat, Mar 3, 2018 at 12:48 PM, Greg Ewing wrote:

Chris Angelico wrote:


It would NOT work for anything where the bool() of
the desired object doesn't exactly match the loop's condition.



while condition(x) where x = something():
   ...



And we're back to needing a new keyword. Though this is reasonably
plausible, so I could add it to the PEP (as another rejected
alternative) if there's support for it.


So what happens to rejected alternatives when the PEP itself is rejected?  ;)

--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

[Ethan Furman]

On 03/02/2018 12:47 PM, Robert Vanden Eynde wrote:


@Chris @Rohdri (@Jonathan below)

For morons like me who didn't know what "top-posting" was, I went on Wikipedia
(https://en.m.wikipedia.org/wiki/Posting_style 
).


You looked it up and researched it, so definitely NOT a moron.  ;)


I think newcomers to mailing list aren't supposed to know all those "de facto 
standard" (they never used mailing list
before ? And I'm 25 years old, not 12), so please don't tell "our mail client is 
bad, get a new one", I'm using gmail on
Android and gmail on Google.com, that's like, very standard.


Standard, maybe.  Good for basic email discussion, nevermind mailing lists?  
Nope  (My humble opinion, of course.)


But if you have other mail clients to suggest me, to configure my user 
interface, feel free to help me, but they will
always be people not knowing these good mailing practice (is using html mail a 
bad practice too ? It used to be).


The Python mailing lists are plain-text, so html-mail is not great.


That's why moving to MM3 so that newcomers can use tool a bit more familiar 
like a forum and will not make the same
"mistakes" (top posting, reply only to sender...) over and over again is a good 
thing. As someone said in their mail
comparing web-based to mail, mailing needs configuration.


Most things worth using require configuration/customization (cars, kitchens, 
and definitely software).

Thanks for persevering!

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

[Ethan Furman]

On 03/02/2018 09:34 AM, David Mertz wrote:


So right now, I can do these:

class bind(object):
 def __init__(self, *args):
 self.args = args
 def __enter__(self):
 return self.args[0] if len(self.args)==1 else self.args
 def __exit__(self, *args):
 pass

 >>> with bind(sqrt(2)) as _a:
... print(_a)
1.4142135623730951

 >>> with bind(sqrt(2), log(2)) as (a, b):
... print(a, b, a+b)
1.4142135623730951 0.6931471805599453 2.1073607429330403


This would cover 98% of the cases that I would want with the proposed 
statement-local name bindings.


Cool!  But what's the advantage over simple assignment?

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

[Ethan Furman]

On 03/02/2018 08:04 AM, Chris Angelico wrote:

On Sat, Mar 3, 2018 at 1:53 AM, Rhodri James wrote:

On 02/03/18 11:43, Chris Angelico wrote:



  # Compound statements usually enclose everything...
  if (re.match(...) as m):
  print(m.groups(0))
  print(m) # NameError


This (and the equivalent in while loops) is the big win in the PEP, in my
opinion.  The number of ugly loops I've had to write in Python because I
can't write "while (something_to_do() as event):"...  +1 on this.


  # Using a statement-local name
  stuff = [[(f(x) as y), x/y] for x in range(5)]


As Paul said, the asymmetry of this bothers me a lot.  It doesn't read
naturally to me. -1 on this.


Interesting. I fully expected to get a lot more backlash for the
if/while usage, but a number of people are saying that that's the only
(or the biggest) part of this proposal that they like.


This is the part of the PEP that I really like as well -- far more useful to me than the list-comp examples.  I could 
even be +0.5 if the "if/while/for" compound statements were kept and the comprehensions dropped -- but not with leading 
dots -- I would rather do $ than . .  Kind of like decorators, they shouldn't be used all that often.


--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

[Ethan Furman]

On 03/02/2018 03:43 AM, Chris Angelico wrote:


PEP: 572
Title: Syntax for Statement-Local Name Bindings
Author: Chris Angelico 


Looks nice, thanks for the updates!



Alternative proposals
=



6. Allowing ``(EXPR as NAME)`` to assign to any form of name.

This is exactly the same as the promoted proposal, save that the name is
bound in the same scope that it would otherwise have. Any expression can
assign to any name, just as it would if the ``=`` operator had been used.


Just to clarify:  "bound in the same scope" means exactly that -- if the (EXPR as NAME) is in a comprehension, then it 
is local /to that comprehension/  (emphasis because I didn't adequately convey that it my initial response to Nick).



Still -1 to the PEP as written.  (It would be positive for alternative 6. ;)

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

[Ethan Furman]

On 03/02/2018 02:47 AM, Nick Coghlan wrote:

On 2 March 2018 at 16:39, Ethan Furman wrote:

On 03/01/2018 09:08 PM, Nick Coghlan wrote:



Adding statement local variables into that mix *without* some form of syntactic 
marker would mean taking an already
complicated system, and making it even harder to reason about correctly 
(especially if statement locals interact
with nested scopes differently from the way other locals in the same scope do).


Seems like it would far easier and (IMHO) more useful to scale the proposal 
back from a statement scope to simple
expression assignment, and the variable is whatever scope it would have been if 
assigned to outside the expression
(default being local, but non-local or global if already declared as such).


Because that would put us back in the exact same problematic situation we had when 
"[x*x for x in sequence]" leaked the
iteration variable (only worse): no function locals would be safe, since 
arbitrary expressions could clobber them, not
just name binding operations (assignment, import statements, for loops, with 
statements, exception handlers, class and
function definitions).


Ah, right.  Since the PEP primarily covers comprehensions, but then went on to discuss multi-line statements, I had 
forgotten the comprehension part.  The answer is easy:  assignment expressions in comprehensions stay inside 
comprehensions, just like other inner comprehension variables already do (function sub-scope, after all).  Thank you for 
pointing that out.



Maybe somebody could explain why a statement-local limited scope variable is 
better than an ordinary well-understood
local-scope variable?  Particularly why it's better enough to justify more 
line-noise in the syntax.  I'm willing to
be convinced (not happy to, just willing ;) .


It breaks the expectation that only a well defined subset of statement can make 
changes to local name bindings.


We already use the keyword "as" to assign names, so there is nothing extra there -- the only change is that we can now 
use it in one more place.


Are those valid counter-arguments, or is there still something I am missing?

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

[Ethan Furman]

On 03/01/2018 09:08 PM, Nick Coghlan wrote:

On 1 March 2018 at 19:30, Paul Moore 

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

[Ethan Furman]

On 02/28/2018 01:48 PM, Robert Vanden Eynde wrote:


We are currently like a dozen of people talking about multiple sections of a 
single subject.

Isn't it easier to talk on a forum?


No.


*Am I the only one* who thinks mailing list isn't easy when lots of people 
talking about multiple subjects?


Maybe.


Of course we would put the link in the mailing list so that everyone can join.


Python Ideas is a mailing list.  This is where we discuss ideas for future versions of Python.  If you're using Google 
Groups or a lousy mail reader then I sympathize, but it's on you to use the appropriate tools.


--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

[Ethan Furman]

On 02/28/2018 12:16 PM, Alex Walters wrote:


For what its worth, I'm +1 on it.

I actually like that it would allow:

while (something() as var):
 something_else(var)

...without being a bug magnet.  The bug magnet isn't the assignment of a
name in the condition of a while loop, it's the fact that assignment is a
simple typo away from comparison.  This is not a simple typo away from
comparison (the operands are a different order, too).


I also like the above, but as a more general assignment-in-expression, not as a statement-local -- the difference being 
that there would be no auto-deletion of the variable, no confusion about when it goes away, no visual name collisions 
(aside from we have already), etc., etc.


Maybe I'll write yet-another-competing-PEP.  ;)

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

[Ethan Furman]

On 02/27/2018 02:27 PM, Chris Angelico wrote:


PEP: 572


Because:

   a = (2 as a)

does not evaluate to 2

and because some statements, such as 'for' and 'while' can cover many, many lines (leaving plenty of potential for 
confusion over which variable disappear at the end and which persist):


-1

I would love to see an expression assignment syntax, but 
Statement-Local-Name-Binding is confusing and non-intuitive.

Is there already a PEP about expression assignment?  If not, that would be a 
good one to write.

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

[Ethan Furman]

On 02/28/2018 02:43 AM, Chris Angelico wrote:

On Wed, Feb 28, 2018 at 8:04 PM, Robert Vanden Eynde wrote:



3) "C problem that an equals sign in an expression can now create a name
binding, rather than performing a comparison." The "=" does variable
assignement already, and there is no grammar problem of "=" vs "==" because
the "with" keyword is used in the expression, therefore "with a == ..." is a
SyntaxError whereas "where a = ..." is alright (See grammar in thektulu
implemention of "where").


Yes, but in Python, "=" does variable assignment *as a statement*. In
C, you can do this:

while (ch = getch())
 do_something_with(ch)

That's an assignment in an arbitrary condition, and that's a bug
magnet. You cannot do that in Python. You cannot simply miss out one
equals sign and have legal code that does what you don't want. With my
proposed syntax, you'll be able to do this:

while (getch() as ch):
 ...

There's no way that you could accidentally write this when you really
wanted to compare against the character.


Given the current (posted) proposal, wouldn't 'ch' evaporate before the ':' and 
be unavailable in the 'while' body?

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

[Ethan Furman]

On 02/27/2018 09:23 PM, Chris Angelico wrote:

On Wed, Feb 28, 2018 at 2:47 PM, Rob Cliffe via Python-ideas wrote:



And here's a thought: What are the semantics of
 a = (42 as a) # Of course a linter should point this out too
At first I thought this was also a laborious synonym for "a=42".  But then I
re-read your statement (the one I described above as crystal-clear) and
realised that its exact wording was even more critical than I had thought:
 "the new name binding will shadow the other name from the point where it
is evaluated until the end of the statement"
Note: "until the end of the statement".  NOT "until the end of the
expression".  The distinction matters.
If we take this as gospel, all this will do is create a temporary variable
"a", assign the value 42 to it twice, then discard it.  I.e. it effectively
does nothing, slowly.
Have I understood correctly?  Very likely you have considered this and mean
exactly what you say, but I am sure you will understand that I mean no
offence by querying it.


Actually, that's a very good point, and I had to actually go and do
that to confirm. You're correct that the "a =" part is also affected,
but there may be more complicated edge cases. Disassembly can help
track down what the compiler's actually doing:


def f():

... a = 1
... a = (2 as a)
... print(a)
...

dis.dis(f)

   2   0 LOAD_CONST   1 (1)
   2 STORE_FAST   0 (a)

   3   4 LOAD_CONST   2 (2)
   6 DUP_TOP
   8 STORE_FAST   1 (a)
  10 STORE_FAST   1 (a)
  12 DELETE_FAST  1 (a)

   4  14 LOAD_GLOBAL  0 (print)
  16 LOAD_FAST0 (a)
  18 CALL_FUNCTION1
  20 POP_TOP
  22 LOAD_CONST   0 (None)
  24 RETURN_VALUE

If you're not familiar with the output of dis.dis(), the first column
(largely blank) is line numbers in the source, the second is byte code
offsets, and then we have the operation and its parameter (if any).
The STORE_FAST and LOAD_FAST opcodes work with local names, which are
identified by their indices; the first such operation sets slot 0
(named "a"), but the two that happen in line 3 (byte positions 8 and
10) are manipulating slot 1 (also named "a"). So you can see that line
3 never touches slot 0, and it is entirely operating within the SLNB
scope.


dis.dis may be great, but so is running the function so everyone can see the 
output.  ;)

If I understood your explanation, `print(a)` produces `1` ?  That seems wrong -- the point of statement-local name 
bindings is twofold:


- give a name to a value
- evaluate to that value

Which is why your first example works:

stuff = [[(f(x) as y), y] for x in range(5)]

(f(x) as y), y

evaluates as f(x), and also assigns that result to y, so in

a = (2 as a)

there is a temporary variable 'a', which gets assigned 2, and the SLNB is evaluated as 2, which should then get assigned 
back to the local variable 'a'.  In other words, the final print from `f()` above should be 2, not 1.  (Slightly 
different names would help avoid confusion when referencing different locations of the PEP.)


--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Coming up with an alternative to PEP 505's None-aware operators

[Ethan Furman]

On 02/18/2018 05:57 PM, Nick Coghlan wrote:

On 17 February 2018 at 02:31, Ethan Furman wrote:

On 02/15/2018 11:55 PM, Nick Coghlan wrote:



However, while I think that looks nicer in general, we'd still have to
choose between two surprising behaviours:

* implicitly delete the statement locals after the statement where
they're set (which still overwrites any values previously bound to
those names, similar to what happens with exception clauses)



If we're overwriting locals anyway, don't delete it.  The good reason for
unsetting an exception variable doesn't apply here.


* skip deleting, which means references to subexpressions may last
longer than expected (and we'd have the problem where embedded
assignments could overwrite existing local variables)


Odds are good that we'll want/need that assignment even after the immediate
expression it's used in.  Let it stick around.


If we want to use a subexpression in multiple statements, then regular
assignment statements already work fine - breaking out a separate
variable assignment only feels like an inconvenience when we use a
subexpression twice in a single statement, and then don't need it any
further.

By contrast, if we have an implicit del immediately after the
statement for any statement local variables, then naming a
subexpression only extends its life to the end of the statement, not
to the end of the current function, and it's semantically explicit
that you *can't* use statement locals to name subexpressions that
*aren't* statement local.

The other concern I have with any form of statement local variables
that can overwrite regular locals is that we'd be reintroducing the
problem that comprehensions have in Python 2.x: unexpectedly rebinding
things in non-obvious ways. At least with an implicit "del" the error
would be more readily apparent, and if we disallow closing over
statement local variables (which would be reasonable, since closures
aren't statement local either), then we can avoid interfering with
regular locals without needing to introduce a new execution scope.


Good points.  I see two possibly good solutions:

- don't override existing local variables, implicit del after statement
- override existing local variables, no implicit del after statement

I like the first one better, as it mirrors list comprehensions and is simple to understand.  The second one is okay, and 
if significantly easier to implement I would be okay with.  It's the combination of:


- override existing local variables, implicit del after statement

that I abhor.  As I understand it, only try/except has that behavior -- and we have a really good reason for it, and 
it's the exception to the general rule, and...


Okay, after further thought I like the second one better.  List comps have the outside brackets as a reminder that they 
have their own scope, but these "statement local" variables only have internal parenthesis.  I still don't like the 
third option.


--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Coming up with an alternative to PEP 505's None-aware operators

[Ethan Furman]

On 02/15/2018 11:55 PM, Nick Coghlan wrote:

On 16 February 2018 at 12:19, rym...@gmail.com wrote:



I don't know...to me this looks downright ugly and an awkward special case.
It feels like it combines reading difficulty of inline assignment with the
awkwardness of a magic word and the ugliness of using ?. Basically, every
con of the other proposals combined...


Yeah, it's tricky to find a spelling that looks nice without being
readily confusable with other existing constructs (most notably
keyword arguments).

The cleanest *looking* idea I've come up with would be to allow
arbitrary embedded assignments to ordinary frame local variables using
the "(expr as name)" construct:


-1 to ?it

+1 to (name as expr)


However, while I think that looks nicer in general, we'd still have to
choose between two surprising behaviours:

* implicitly delete the statement locals after the statement where
they're set (which still overwrites any values previously bound to
those names, similar to what happens with exception clauses)


If we're overwriting locals anyway, don't delete it.  The good reason for
unsetting an exception variable doesn't apply here.


* skip deleting, which means references to subexpressions may last
longer than expected (and we'd have the problem where embedded
assignments could overwrite existing local variables)


Odds are good that we'll want/need that assignment even after the immediate
expression it's used in.  Let it stick around.

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Extending __format__ method in ipaddress

[Ethan Furman]

On 02/14/2018 02:29 PM, Eric Osborne wrote:


Nick Coghlan suggested I instead extend __format__, which is what the diffs in 
the current pull request do.  This
allows a great deal more flexibility: the current code takes 'b', 'n', or 'x' 
types, as well as the '#' option and
support for the '_' separator.  I realize now I didn't add 'o' but I certainly 
can for completeness.  I debated adding
rfc1924 encoding for IPv6 addresses but decided it was entirely too silly.

This is just a convenience function, but IMO fills a need.  Is this worth 
pursuing?


Seems like a good idea to me!

--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

[Ethan Furman]

On 01/17/2018 10:59 PM, Steven D'Aprano wrote:

On Thu, Jan 18, 2018 at 05:22:06PM +1100, Chris Angelico wrote:


I haven't yet seen any justification for syntax here. The nearest I've
seen is that this "ensure" action is more like:

try:
 cond = x >= 0
except BaseException:
 raise AssertionError("x must be positive")
else:
 if not cond:
 raise AssertionError("x must be positive")

Which, IMO, is a bad idea, and I'm not sure anyone was actually
advocating it anyway.


My understanding is that Sylvain was advocating for that.


Agreed.  Which, as has been pointed out, is an incredibly bad idea.

--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] make Connections iterable

[Ethan Furman]

On 01/09/2018 08:27 AM, Chris Angelico wrote:

On Tue, Jan 9, 2018 at 11:12 PM, Random832  wrote:

On Tue, Jan 9, 2018, at 05:46, Nick Coghlan wrote:

If you view them as comparable to subprocess pipes, then it can be
surprising that they're not iterable when using a line-oriented
protocol.

If you instead view them as comparable to socket connections, then the
lack of iteration support seems equally reasonable.


Sockets are files - there's no fundamental reason a stream socket using a 
line-oriented protocol (which is a common enough case), or a datagram socket, 
shouldn't be iterable. Why aren't they? Making sockets iterable would be a 
separate discussion, but I don't think this is necessarily an argument.



Only in POSIX. On other platforms, sockets are most definitely NOT
files. And datagram sockets don't really make sense to iterate over.

Part of the problem with even POSIX stream sockets (either TCP or Unix
domain) is what you do when there's nothing to read. Do you block,
waiting for a line? Do you raise StopIteration and then subsequently
become un-finished again (which, according to Python semantics, is a
broken iterator)?


This.  Although it is technically broken, this is how reading from the console works.  I believe that falls under 
practicality beats purity.  ;)


--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Decorator for creating enumeration?

[Ethan Furman]

On 12/10/2017 09:50 AM, Guido van Rossum wrote:


There's a third-party enum package. Maybe you can contribute an implementation 
of this idea there. If it becomes popular
maybe we can add it to the stdlib enum module.


The third-party library in question is aenum (enum34 isn't getting new functionality).  It can be found at 
https://bitbucket.org/stoneleaf/aenum .


--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Is there a reason some of the PyLong_As* functions don't call an object's __int__?

[Ethan Furman]

On 12/08/2017 04:33 AM, Erik Bray wrote:


More importantly not as many objects that coerce to int actually
implement __index__.  They probably *should* but there seems to be
some confusion about how that's to be used.


__int__ is for coercion (float, fraction, etc)

__index__ is for true integers

Note that if __index__ is defined, __int__ should also be defined, and return 
the same value.

https://docs.python.org/3/reference/datamodel.html#object.__index__

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a sorting protocol dunder method?

[Ethan Furman]

On 12/04/2017 10:01 AM, brent bejot wrote:


This is certainly a good pattern to use in the current and older versions, but 
I think we can all agree that defining
__key__ and calling "sorted(list_of_attrdicts)" has that syntactic sugar that 
is oh-so-sweet-and-tasty.


Actually, no, we do not all agree.  ;-)

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

[Ethan Furman]

On 11/28/2017 08:03 AM, Ivan Pozdeev via Python-ideas wrote:

On 28.11.2017 16:36, Nick Coghlan wrote:



   it doesn't need to be a statement any more

>

Another benefit of a statement vs function is only evaluating the error-related 
arguments when there's an error


The bulk of any processing in assert (or ensure()) should be the actual check -- if that fails, only state information 
should be included in the exception as anything more complicated runs the risk of also being wrong as the code is now in 
a failed state.  In other words, the "error-related arguments" will often be extremely cheap compared to the test itself.


--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Rewriting the "roundrobin" recipe in the itertools documentation

[Ethan Furman]

On 11/16/2017 05:56 AM, bunslow wrote:


I realize at the end of the day this is a pretty trivial and ultimately 
meaningless nit to pick,


Not at all -- documentation is extremely important.


but I've never
contributed before and have a variety of similar minor pain points in the 
docs/stdlib, and I'm trying to gauge 1) how
well this sort of minor QoL improvement is wanted, and 2) even if it is wanted, 
am I going about it the right way. If
the answers to both of these questions are positive regarding this particular 
case, then I'll look into making a BPO
issue and pull request on GitHub, which IIUC is the standard path for 
contributions.


I found your example much easier to understand.  Just include a note the the "roughly similar" python code is not 
performant in extreme situations; after all, it's there to aid understanding, not to be used.


--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Consider (one day) adding an inheritance order class precedence mechanism

[Ethan Furman]

On 11/15/2017 10:10 PM, Greg Ewing wrote:

Steven D'Aprano wrote:

These are not equivalent:

B < S, E
B < E, S


Not in general, but in many cases they will be, e.g. if
E and S have no method names in common. I think the OP is
implying that his case is one of those.

Maybe what's really wanted is a way to say "B inherits from
S and E, but it doesn't care what order they go in". Then
the MRO generating algorithm could in principle swap them
if it would result in a consistent MRO.

Or maybe the MRO generator could decide for itself if the
order of two base classes can be swapped by inspecting
their attributes to see if any of them clash?


If they don't have any clashing attributes, why does order matter?

--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Any chance on (slowly) deprecating `eval` and `exec` as builtins?

[Ethan Furman]

On 11/07/2017 03:12 PM, Soni L. wrote:


exec("def one(x):\n [r] = x\n return r")  # who says python doesn't have 
one-liners?

(ofc, some would argue you should use:

one = (lambda x: (lambda y: y)(*x))


Most would argue that

def one(x):
   [r] = x
   return r

is the appropriate code.

--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Moving typing out of the stdlib in Python 3.7?

[Ethan Furman]

On 11/06/2017 06:48 AM, brent bejot wrote:

On Mon, Nov 6, 2017 at 9:21 AM, Gyro Funch wrote:



Would this mean that other packages in the stdlib with development
cycles faster than those of python could use the same bundling
mechanism?


This is pretty much how I thought things worked for all built-in packages until 
this thread came up.  Is there any
reason to not do this for all of stdlib?


Yes.  Stability is probably the first (knowing what is support in a particular version).  Second would be that nearly 
all modules in the stdlib are stable and don't need frequent updates -- in fact, I suspect typing is the only exception.


--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Hello from a new lurker

[Ethan Furman]

On 11/01/2017 10:49 AM, brent bejot wrote:


The python-dev website said I should introduce myself before lurking around for 
a while.  So hi!  I've been using python
for 7 or so years now, live on the east coast of the U.S., grew up in Nebraska, 
and occasionally play the tuba and
table-top games (through rarely together).  I'm looking forward to hearing 
where the language is going and hope I can be
of use after I lurk in the shadows for a while.


Welcome!

Enjoy your time lurking.  When new ideas come up, feel free to comment if that 
idea will help or hinder you.

--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP draft: context variables

[Ethan Furman]

On 10/13/2017 03:30 PM, Yury Selivanov wrote:


At this time, we have so many conflicted examples and tangled
discussions on these topics, that I myself just lost what everybody is
implying by "this semantics isn't obvious to *me*".  Which semantics?
It's hard to tell.


For me, it's not apparent why __aenter__ and __aexit__ cannot be special-cased.  I would be grateful for a small 
code-snippet illustrating the danger.


--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP draft: context variables

[Ethan Furman]

On 10/13/2017 09:48 AM, Steve Dower wrote:

On 13Oct2017 0941, Yury Selivanov wrote:



Actually, capturing context at the moment of coroutine creation (in
PEP 550 v1 semantics) will not work at all.  Async context managers
will break.

class AC:
async def __aenter__(self):
 pass

^ If the context is captured when coroutines are instantiated,
__aenter__ won't be able to set context variables and thus affect the
code it wraps.  That's why coroutines shouldn't capture context when
created, nor they should isolate context.  It's a job of async Task.


Then make __aenter__/__aexit__ when called by "async with" an exception to the 
normal semantics?

It seems simpler to have one specially named and specially called function be 
special, rather than make the semantics
more complicated for all functions.


+1.  I think that would make it much more usable by those of us who are not 
experts.

--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Make map() better

[Ethan Furman]

On 09/15/2017 11:03 AM, Jason H wrote:

From: "Steven D'Aprano" 


>> Um... what's in it for *us*? What benefit do we get?
>

How that question is answered, depends on who is 'us'? If you're a bunch of

> python purist greybeards, then conceivably nothing.

How about refugees from other languages?  Your suggestions only make Python 
worse -- hardly a commendable course of action.

> The features I've requested are to ease newcomers who will undoubtedly have
> JS* experience.

The point of having different languages is to have different ways of doing things.  Certain mindsets do better with 
Python's ways, others do better with JS's ways.  That doesn't mean we should have the languages converge into the same 
thing.


Aside: your suggestion that anyone who likes the philosophy of Python and doesn't want to incorporate features from 
other languages that are contrary to it is just old and set in their ways is offensive.  Such assertions weaken your 
arguments and your reputation.


--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 550 v2

[Ethan Furman]

On 08/23/2017 08:41 AM, Guido van Rossum wrote:


If we're extending the analogy with thread-locals we should at least consider 
making each instantiation return a
namespace rather than something holding a single value.


+1

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 550 v2

[Ethan Furman]

On 08/16/2017 08:43 AM, Yury Selivanov wrote:


To be honest, I really like Execution Context and Local Context names.
I'm curious if other people are confused with them.


+1 confused  :/

--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 550 v2

[Ethan Furman]

On 08/17/2017 02:40 AM, Nick Coghlan wrote:

On 17 August 2017 at 04:38, Yury Selivanov wrote:



 ck.get_value() attempts to look up the value for that key in the
currently active execution context.
 If it doesn't find one, it then tries each of the execution
contexts in the currently active dynamic context.
 If it *still* doesn't find one, then it will set the default value
in the outermost execution context and then return that value.


For what it's worth, I find the term DynamicContext much easier to understand 
with relation to these concepts.

--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

[Ethan Furman]

On 07/26/2017 09:05 AM, Nick Coghlan wrote:

On 26 July 2017 at 11:05, Steven D'Aprano  wrote:



I don't see any way that this proposal can be anything by a subtle
source of bugs. We have two *incompatible* requirements:

- we want to define the order of the fields according to the
   order we give keyword arguments;

- we want to give keyword arguments in any order without
   caring about the field order.

We can't have both, and we can't give up either without being a
surprising source of annoyance and bugs.


I think the second stated requirement isn't a genuine requirement, as
that *isn't* a general expectation.


I have to agree with D'Aprano on this one.  I certainly do not *expect* keyword argument position to matter, and it 
seems to me the primary reason to make it matter was not for dicts, but because a class name space is implemented by dicts.


Tuples, named or otherwise, are positional first -- order matters.  Specifying

point = ntuple(y=2, x=-3)

and having point[0] == 3 is going to be bizarre.  This will be a source for 
horrible bugs.

--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] namedtuple redesign goals

[Ethan Furman]

On 07/23/2017 10:47 AM, Michel Desmoulin wrote:

> I'm not sure why everybody have such a grip on the type.

If I understand the goal of "a new namedtuple" correctly, it is not to come up with yet another namedtuple type -- it is 
to make the existing collections.namedtuple a faster experience, and possibly add another way to create such a thing.


This means that the "replacement" namedtuple MUST be backwards compatible with the existing collections.namedtuple, and 
keeping track of type is one of the things it does:


--> from collections import namedtuple
--> Point = namedtuple('Point', 'x y')
--> p1 = Point(3, 7)
--> p1.x
3
--> p1.y
7
--> isinstance(p1, Point)
True

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a new namedtuple

[Ethan Furman]

On 07/18/2017 09:09 AM, Guido van Rossum wrote:

On Tue, Jul 18, 2017 at 8:56 AM, Ethan Furman wrote:



I certainly don't expect the signature to change, but why is using a metaclass 
out?  The use (or not) of a metaclass
/is/ an implementation detail.


It is until you try to subclass with another metaclass -- then you have a 
metaclass conflict. If the namedtuple had no
metaclass this would not be a conflict. (This is one reason to love class 
decorators.)


Ah, so metaclasses are leaky implementation details.  Makes sense.

--
~Ethan~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a new namedtuple

[Ethan Furman]

On 07/17/2017 06:25 PM, Eric Snow wrote:

On Mon, Jul 17, 2017 at 6:01 PM, Ethan Furman wrote:



Guido has decreed that namedtuple shall be reimplemented with speed in mind.


FWIW, I'm sure that any changes to namedtuple will be kept as minimal
as possible.  Changes would be limited to the underlying
implementation, and would not include the namedtuple() signature, or
using metaclasses, etc.  However, I don't presume to speak for Guido
or Raymond. :)


I certainly don't expect the signature to change, but why is using a metaclass out?  The use (or not) of a metaclass 
/is/ an implementation detail.


--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a new namedtuple

[Ethan Furman]

On 07/17/2017 06:34 PM, Steven D'Aprano wrote:

On Mon, Jul 17, 2017 at 05:01:58PM -0700, Ethan Furman wrote:



Guido has decreed that namedtuple shall be reimplemented with speed in mind.

I haven't timed it (I'm hoping somebody will volunteer to be the bench mark
guru), I'll offer my NamedTuple implementation from my aenum [1] library.


With respect Ethan, if you're going to offer up NamedTuple as a faster
version of namedtuple, you should at least do a quick proof of
concept to demonstrate that it actually *is* faster.


I suck at benchmarking, so thank you for providing those quick-and-dirty hints.


Full bench marking
can wait, but you should be able to do at least something like:


python3 -m timeit --setup "from collections import namedtuple" \
 "K = namedtuple('K', 'a b c')"


546 usec


versus

python3 -m timeit --setup "from aenum import NamedTuple" \
 "K = NamedTuple('K', 'a b c')"


250 usec


So it seems to be faster!  :)

It is also namedtuple compatible, except for the _source attribute.

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/