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
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.
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
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,
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
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
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
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
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` "("
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
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,
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
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
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
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
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
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
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
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
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
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.
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
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
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
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:
-
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,
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
27 matches
Mail list logo