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 :
> >>> The name of the stub
> >>> p
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. Mayb
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 ``pkg_stubs`` for type stubs for the package named
>>> ``pkg``. The nor
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, but if you're trying to
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 using Python
>> data st
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 the transformation from
> what y
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
https://mail.python.org/mailman/listinfo/
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 applications" since:
>>
>> - we
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` "(" [`arg
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 reversib
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, 20
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 adopt
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 the
>> feedback and suggestions of Nick Cogh
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 Implementation):
> If an annotation was already a
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 packaging tooling.
>
> Th
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 preserved
> verbatim.
--
-
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
(change
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 in this case the
> gen
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 bu
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 summary. You finally
co
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. linters, static
> analysers
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
inspirati
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 `list
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 really only like
>> > 'string_annotations' so let's go with th
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:
- type
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, let me know if I am wrong.
>>
> It was discussed at
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
"default::DeprecationWarning:__main__
27 matches
Mail list logo
