Re: [Python-Dev] PEP 561 rework

2017-11-12 Thread Ethan Smith
On Sun, Nov 12, 2017 at 8:07 PM, Nathaniel Smith wrote: > On Sun, Nov 12, 2017 at 11:21 AM, Ethan Smith wrote: > > > > > > On Sun, Nov 12, 2017 at 9:53 AM, Jelle Zijlstra < > jelle.zijls...@gmail.com> > > wrote: > >> > >> 2017-11-12 3:40 GMT-08:00 Ethan Smith

Re: [Python-Dev] Disallow ambiguous syntax f(x for x in [1],)

2017-11-12 Thread Serhiy Storchaka
13.11.17 02:00, Guido van Rossum пише: It's hard to keep those two in sync, since the actual Grammar file is constrained by being strictly LL(1)... Can you get someone else to review the implementation? I haven't change the grammar, just have changed checks in the CST to AST transformer.

Re: [Python-Dev] PEP 561 rework

2017-11-12 Thread Nathaniel Smith
On Sun, Nov 12, 2017 at 11:21 AM, Ethan Smith wrote: > > > On Sun, Nov 12, 2017 at 9:53 AM, Jelle Zijlstra > wrote: >> >> 2017-11-12 3:40 GMT-08:00 Ethan Smith : >>> The name of the stub >>> package >>> MUST follow the scheme

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

2017-11-12 Thread Nathaniel Smith
On Sun, Nov 12, 2017 at 1:24 AM, Nick Coghlan wrote: > This change will lead to DeprecationWarning being displayed by default for: > > * code executed directly at the interactive prompt > * code executed directly as part of a single-file script Technically it's orthogonal,

Re: [Python-Dev] Standardise the AST (Re: PEP 563: Postponed Evaluation of Annotations)

2017-11-12 Thread Nick Coghlan
On 13 November 2017 at 10:26, Guido van Rossum wrote: > [Greg] >> Proponents of Lisp point to the advantages of easily >> being able to express Lisp programs using Lisp data >> structures. There would also be benefits in having a >> standard way to represent Python programs

Re: [Python-Dev] Standardise the AST (Re: PEP 563: Postponed Evaluation of Annotations)

2017-11-12 Thread Guido van Rossum
On Sun, Nov 12, 2017 at 2:39 PM, Greg Ewing wrote: > Guido van Rossum wrote: > >> The PEP answers that clearly (under Implementation): >> >> > If an annotation was already a string, this string is preserved >> > verbatim. >> > > This bothers me, because it means

Re: [Python-Dev] Disallow ambiguous syntax f(x for x in [1],)

2017-11-12 Thread Guido van Rossum
It's hard to keep those two in sync, since the actual Grammar file is constrained by being strictly LL(1)... Can you get someone else to review the implementation? ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

2017-11-12 Thread Nick Coghlan
On 13 November 2017 at 03:10, Serhiy Storchaka wrote: > 12.11.17 11:24, Nick Coghlan пише: >> >> The PEP also proposes repurposing the existing FutureWarning category >> to explicitly mean "backwards compatibility warnings that should be >> shown to users of Python

Re: [Python-Dev] Disallow ambiguous syntax f(x for x in [1],)

2017-11-12 Thread Serhiy Storchaka
12.11.17 18:57, Guido van Rossum пише: Sounds good to me. Thanks! Here is an implementation: https://bugs.python.org/issue32012. I have found that formally trailing comma after generator expression is not allowed by the grammar defined in the language reference: call: `primary` "("

[Python-Dev] Standardise the AST (Re: PEP 563: Postponed Evaluation of Annotations)

2017-11-12 Thread Greg Ewing
Guido van Rossum wrote: The PEP answers that clearly (under Implementation): > If an annotation was already a string, this string is preserved > verbatim. This bothers me, because it means the transformation from what you write in the source and the object you get at run time is not

Re: [Python-Dev] Analog of PEP 448 for dicts (unpacking in assignment with dict rhs)

2017-11-12 Thread Ben Usman
Anyway, considering that this has been discussed a lot in the original post in 2016, I suggest stopping any further discussions here to avoid littering dev mailing list. Sorry for starting the thread in the first place and thank you, Jelle, for pointing me to the original discussion. On Nov 12,

Re: [Python-Dev] Analog of PEP 448 for dicts (unpacking in assignment with dict rhs)

2017-11-12 Thread Ben Usman
Sounds like that happens quite often. Yep, I totally agree with your point, I think I mentioned something like this in the post as a possible partial solution: a drop-in replacement for an ugly list compression people seem to be using now to solve the problem. It's easy to implement, but the

Re: [Python-Dev] PEP 561 rework

2017-11-12 Thread Ethan Smith
On Sun, Nov 12, 2017 at 9:53 AM, Jelle Zijlstra wrote: > > > 2017-11-12 3:40 GMT-08:00 Ethan Smith : > >> Hello, >> >> I re-wrote my PEP to have typing opt-in be per-package rather than >> per-distribution. This greatly simplifies things, and thanks to

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

2017-11-12 Thread Koos Zevenhoven
On Nov 12, 2017 19:10, "Guido van Rossum" wrote: On Sun, Nov 12, 2017 at 4:14 AM, Koos Zevenhoven wrote: > So actually my question is: What should happen when the annotation is > already a string literal? > The PEP answers that clearly (under

Re: [Python-Dev] PEP 561 rework

2017-11-12 Thread Jelle Zijlstra
2017-11-12 3:40 GMT-08:00 Ethan Smith : > Hello, > > I re-wrote my PEP to have typing opt-in be per-package rather than > per-distribution. This greatly simplifies things, and thanks to the > feedback and suggestions of Nick Coghlan, it is entirely compatible with > older

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

2017-11-12 Thread Guido van Rossum
On Sun, Nov 12, 2017 at 4:14 AM, Koos Zevenhoven wrote: > So actually my question is: What should happen when the annotation is > already a string literal? > The PEP answers that clearly (under Implementation): > If an annotation was already a string, this string is

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

2017-11-12 Thread Serhiy Storchaka
12.11.17 11:24, Nick Coghlan пише: The PEP also proposes repurposing the existing FutureWarning category to explicitly mean "backwards compatibility warnings that should be shown to users of Python applications" since: - we don't tend to use FutureWarning for its original nominal purpose

Re: [Python-Dev] Disallow ambiguous syntax f(x for x in [1],)

2017-11-12 Thread Guido van Rossum
Sounds good to me. On Sun, Nov 12, 2017 at 7:17 AM, Serhiy Storchaka wrote: > Initially generator expressions always had to be written inside > parentheses, as documented in PEP 289 [1]. The additional parenthesis could > be omitted on calls with only one argument, because

Re: [Python-Dev] Analog of PEP 448 for dicts (unpacking in assignment with dict rhs)

2017-11-12 Thread Mario Corchero
Do you mean making getitems call itemgetter? At the moment we can already do with itemgetter: from operator import itemgetter a,b = itemgetter("a", "b")(d) > I tend to post this every time the topic comes up, but: it's highly > unlikely we'll get syntax for this when we don't even have a

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

2017-11-12 Thread Antoine Pitrou
On Sun, 12 Nov 2017 19:24:12 +1000 Nick Coghlan wrote: > I've written a short(ish) PEP for the proposal to change the default > warnings filters to show DeprecationWarning in __main__: > https://www.python.org/dev/peps/pep-0565/ Thank you for writing this. This is a nice

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

2017-11-12 Thread Guido van Rossum
On Sun, Nov 12, 2017 at 1:24 AM, Nick Coghlan wrote: > In Python 2.7 and Python 3.2, the default warning filters were updated to > hide > DeprecationWarning by default, such that deprecation warnings in > development > tools that were themselves written in Python (e.g.

Re: [Python-Dev] Analog of PEP 448 for dicts (unpacking in assignment with dict rhs)

2017-11-12 Thread Serhiy Storchaka
12.11.17 12:06, Nick Coghlan пише: So if folks would like dict unpacking syntax, then a suitable place to start would be a proposal for a "getitems" builtin that allowed operations like: b, a = getitems(d, ("b", "a")) operator.itemgetter and operator.attrgetter may provide some

[Python-Dev] Disallow ambiguous syntax f(x for x in [1],)

2017-11-12 Thread Serhiy Storchaka
Initially generator expressions always had to be written inside parentheses, as documented in PEP 289 [1]. The additional parenthesis could be omitted on calls with only one argument, because in this case the generator expression already is written inside parentheses. You could write just

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

2017-11-12 Thread Koos Zevenhoven
On Sun, Nov 12, 2017 at 7:07 AM, Guido van Rossum wrote: > On Fri, Nov 10, 2017 at 11:02 PM, Nick Coghlan wrote: > >> On 11 November 2017 at 01:48, Guido van Rossum wrote: >> > I don't mind the long name. Of all the options so far I

[Python-Dev] PEP 561 rework

2017-11-12 Thread Ethan Smith
Hello, I re-wrote my PEP to have typing opt-in be per-package rather than per-distribution. This greatly simplifies things, and thanks to the feedback and suggestions of Nick Coghlan, it is entirely compatible with older packaging tooling. The main idea is there are two types of packages: -

Re: [Python-Dev] Analog of PEP 448 for dicts (unpacking in assignment with dict rhs)

2017-11-12 Thread Nick Coghlan
On 11 November 2017 at 16:22, Jelle Zijlstra wrote: > 2017-11-10 19:53 GMT-08:00 Ben Usman : >> I was not able to find any PEPs that suggest this (search keywords: >> "PEP 445 dicts", "dictionary unpacking assignment", checked PEP-0), >> however,

[Python-Dev] PEP 565: Show DeprecationWarning in __main__

2017-11-12 Thread Nick Coghlan
I've written a short(ish) PEP for the proposal to change the default warnings filters to show DeprecationWarning in __main__: https://www.python.org/dev/peps/pep-0565/ The core proposal itself is just the idea in https://bugs.python.org/issue31975 (i.e. adding