Re: [Python-Dev] [python-committers] Reminder: 12 weeks to 3.7 feature code cutoff

On Fri, Nov 3, 2017 at 11:30 PM, Nick Coghlan wrote: > On 4 November 2017 at 09:52, Jelle Zijlstra wrote: >> >> 2017-11-03 16:44 GMT-07:00 Joao S. O. Bueno : >>> >>> This just popped up in Brython's issue tracker discussion: >>> >>> """ >>> Pierre Quentel >>> >>> 04:57 (16 hours ago) >>> to bryt

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Nov 4, 2017, at 11:35, Guido van Rossum wrote: > > This sounds reasonable -- I think when we introduced this in 3.6 we were > worried that other implementations (e.g. Jython) would have a problem with > this, but AFAIK they've reported back that they can do this just fine. So > let's just d

Re: [Python-Dev] Remove typing from the stdlib

On Fri, 3 Nov 2017 at 17:59 Lukasz Langa wrote: > > > On 3 Nov, 2017, at 4:01 PM, Victor Stinner > wrote: > > > > The question is if you would only need or > pip install typing>. > > > > If typing is removed from the stdlib, you can still use it in your > > application. It's "just" another dep

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

Yup. At least such code will not break in 3.5. In general if you write code using a newer version you should expect arbitrary breakage when trying to run it under older versions. There is no compatibility guarantee in that direction for anything anyways. I don't see this as a reason to not put th

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

I'm not entirely sure I understand the full set of reasoning for this - I couldn't really tell what the problem with OrderedDict is from the link Stefan provided. It seems to me like a kind of huge change for the language to move from arbitrary-ordered to guaranteed-ordered dict. The problem I s

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Sun, Nov 05, 2017 at 01:14:54PM -0500, Paul G wrote: > I'm not entirely sure I understand the full set of reasoning for this - I > couldn't really tell what the problem with OrderedDict is from the link > Stefan provided. It seems to me like a kind of huge change for the language > to move fr

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

> Scientific applications want something like > >{'a': 10, 'b': "foo", 'c': {'this': b'123'}} > > as an ordered initializer for unboxed or typed (or both) data. In general, > if dicts are ordered, they can be used for example as initializers for > (nested) C structs. I can understand why you

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

04.11.17 19:30, Stefan Krah пише: would it be possible to guarantee that dict literals are ordered in v3.7? The issue is well-known and the workarounds are tedious, example: https://mail.python.org/pipermail/python-ideas/2015-December/037423.html If the feature is guaranteed now, people

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

05.11.17 20:39, Stefan Krah пише: On Sun, Nov 05, 2017 at 01:14:54PM -0500, Paul G wrote: 2. Someone invents a new arbitrary-ordered container that would improve on the memory and/or CPU performance of the current dict implementation I would think this is very unlikely, given that the previou

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Sun, Nov 05, 2017 at 09:01:40PM +0200, Serhiy Storchaka wrote: > Do you suggest to make dictionary displays producing OrderedDict > instead of dict? No, this is essentially a language spec doc issue that would guarantee the ordering properties of the current dict implementation. Stefan Krah

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Sun, Nov 05, 2017 at 09:09:37PM +0200, Serhiy Storchaka wrote: > 05.11.17 20:39, Stefan Krah пише: > >On Sun, Nov 05, 2017 at 01:14:54PM -0500, Paul G wrote: > >>2. Someone invents a new arbitrary-ordered container that would improve on > >>the memory and/or CPU performance of the current dict

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

05.11.17 21:20, Stefan Krah пише: On Sun, Nov 05, 2017 at 09:01:40PM +0200, Serhiy Storchaka wrote: Do you suggest to make dictionary displays producing OrderedDict instead of dict? No, this is essentially a language spec doc issue that would guarantee the ordering properties of the current di

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

05.11.17 21:30, Stefan Krah пише: On Sun, Nov 05, 2017 at 09:09:37PM +0200, Serhiy Storchaka wrote: 05.11.17 20:39, Stefan Krah пише: On Sun, Nov 05, 2017 at 01:14:54PM -0500, Paul G wrote: 2. Someone invents a new arbitrary-ordered container that would improve on the memory and/or CPU perfor

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Sun, Nov 05, 2017 at 09:35:38PM +0200, Serhiy Storchaka wrote: > 05.11.17 21:20, Stefan Krah пише: > >On Sun, Nov 05, 2017 at 09:01:40PM +0200, Serhiy Storchaka wrote: > >>Do you suggest to make dictionary displays producing OrderedDict > >>instead of dict? > > > >No, this is essentially a langu

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Sun, 5 Nov 2017 21:06:12 +0100 Stefan Krah wrote: > On Sun, Nov 05, 2017 at 09:35:38PM +0200, Serhiy Storchaka wrote: > > 05.11.17 21:20, Stefan Krah пише: > > >On Sun, Nov 05, 2017 at 09:01:40PM +0200, Serhiy Storchaka wrote: > > >>Do you suggest to make dictionary displays producing Orde

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

I think the question of whether any specific implementation of dict could be made faster for a given architecture or even that the trade-offs made by CPython are generally the right ones is kinda beside the point. It's certainly feasible that an implementation that does not preserve ordering cou

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

+1 from me too. On 04.11.2017 21:55, Jim Baker wrote: +1, as Guido correctly recalls, this language guarantee will work well with Jython when we get to the point of implementing 3.7+. On Sat, Nov 4, 2017 at 12:35 PM, Guido van Rossum > wrote: This sounds reasona

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

Isn't ordered dict also useful for **kwargs? If it turns out that there's a dict implementation that's faster by not preserving order, collections.UnorderedDict could be added. There could also be specialized implementations that pre-size the dict (cf: C++ unordered_map::reserve), etc., etc. But t

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

> If it turns out that there's a dict implementation that's faster by not > preserving order, collections.UnorderedDict could be added. > There could also be specialized implementations that pre-size the dict (cf: > C++ unordered_map::reserve), etc., etc. > But these are all future things, which mi

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On 6 November 2017 at 07:50, Peter Ludemann via Python-Dev < python-dev@python.org> wrote: > Isn't ordered dict also useful for **kwargs? > **kwargs is already specified as insertion ordered as of Python 3.6. https://www.python.org/dev/peps/pep-0468/ Tim Delaney ___

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On 6 November 2017 at 06:09, Serhiy Storchaka wrote: > 05.11.17 20:39, Stefan Krah пише: > >> On Sun, Nov 05, 2017 at 01:14:54PM -0500, Paul G wrote: >> >>> 2. Someone invents a new arbitrary-ordered container that would improve >>> on the memory and/or CPU performance of the current dict impleme

Re: [Python-Dev] Remove typing from the stdlib

> On Nov 3, 2017, at 9:15 AM, Victor Stinner wrote: > > 2017-11-03 15:36 GMT+01:00 Guido van Rossum : >> Maybe we should remove typing from the stdlib? >> https://github.com/python/typing/issues/495 > > I'm strongly in favor on such move. > > My experience with asyncio in the stdlib is that us

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

Since there is voting going on, -1 on changing the guarantees of `dict`. If ordering is important, OrderedDict is more explicit and more obvious to the over reading the code, even if the underlying implementation is identical. Good luck teaching people about why Python went from OrderedDict to

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

> On Nov 4, 2017, at 7:04 PM, Nick Coghlan wrote: > > When I asked Damien George about this for MicroPython, he indicated > that they'd have to choose between guaranteed order and O(1) lookups > given their current dict implementation. That surprised me a bit > (since PyPy and CPython both *save

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Nov 5, 2017 2:41 PM, "Paul Ganssle" wrote: I think the question of whether any specific implementation of dict could be made faster for a given architecture or even that the trade-offs made by CPython are generally the right ones is kinda beside the point. It's certainly feasible that an imple

Re: [Python-Dev] [python-committers] Reminder: 12 weeks to 3.7 feature code cutoff

On 6 November 2017 at 02:02, Yury Selivanov wrote: > On Fri, Nov 3, 2017 at 11:30 PM, Nick Coghlan wrote: >> The current lack of DeprecationWarnings in 3.6 is a fairly major >> oversight/bug, though: > > There's no oversight. We had PendingDeprecationWarning for > async/await names in 3.5, and D

[Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On the 12-weeks-to-3.7-feature-freeze thread, Jose Bueno & I both mistakenly though the async/await deprecation warnings were missing from 3.6. They weren't missing, we'd just both forgotten those warnings were off by default (7 years after the change to the default settings in 2.7 & 3.2). So my

Re: [Python-Dev] Remove typing from the stdlib

On 4 November 2017 at 02:46, Eric V. Smith wrote: > On 11/3/2017 12:15 PM, Victor Stinner wrote: >> >> Hi, >> >> 2017-11-03 15:36 GMT+01:00 Guido van Rossum : >>> >>> Maybe we should remove typing from the stdlib? >>> https://github.com/python/typing/issues/495 > > >> The typing module is not used

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

Big +1 from me. The whole point of DeprecationWarnings is to be visible so that they are resolved faster. The current behaviour allows them to go unnoticed for the majority of Python users. Yury On Sun, Nov 5, 2017 at 9:05 PM, Nick Coghlan wrote: > On the 12-weeks-to-3.7-feature-freeze thread,

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Sun, Nov 05, 2017 at 09:20:12PM -0500, Yury Selivanov wrote: > Big +1 from me. The whole point of DeprecationWarnings is to be > visible The whole point of DeprecationWarnings is to be visible to developers while in reality they will be visible to users -- and what the users would do with

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

> On Nov 5, 2017, at 4:31 PM, Nathaniel Smith wrote: > > CPython does in practice provide ordering guarantees for dicts, and this > solves a whole bunch of pain points: it makes json roundtripping work better, > it gives ordered kwargs, it makes it possible for metaclasses to see the > order

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Mon, Nov 6, 2017 at 4:54 AM, Serhiy Storchaka wrote: ... > > I didn't try to implement this. But the current implementation requires > periodical reallocating if add and remove items. The following loop > reallocates the dict every len(d) iterations, while the size of the dict is > not changed,

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On 6 November 2017 at 06:50, Peter Ludemann via Python-Dev wrote: > Isn't ordered dict also useful for **kwargs? 3.6 already made this semantic change for **kwargs and class execution namespaces - it just left the door open to having implementations meet those requirements by way of substituting

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On 6 November 2017 at 09:43, Raymond Hettinger wrote: > On Nov 4, 2017, at 7:04 PM, Nick Coghlan wrote: >> I don't think that situation should change the decision, but I do >> think it would be helpful if folks that understand CPython's dict >> implementation could take a look at MicroPython's di

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

> On 5 Nov, 2017, at 6:29 PM, Oleg Broytman wrote: > > On Sun, Nov 05, 2017 at 09:20:12PM -0500, Yury Selivanov > wrote: >> Big +1 from me. The whole point of DeprecationWarnings is to be >> visible > > The whole point of DeprecationWarnings is to be visible to > developers while in reality

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 6 November 2017 at 12:29, Oleg Broytman wrote: > On Sun, Nov 05, 2017 at 09:20:12PM -0500, Yury Selivanov > wrote: >> Big +1 from me. The whole point of DeprecationWarnings is to be >> visible > >The whole point of DeprecationWarnings is to be visible to > developers while in reality the

Re: [Python-Dev] Remove typing from the stdlib

> On 4 Nov, 2017, at 3:39 AM, Paul Moore wrote: > > Lukasz Langa said: >> So, the difference is in perceived usability. It's psychological. > > Please, let's not start the "not in the stdlib isn't an issue" debate > again. If I concede it's a psychological issue, will you concede that > the fac

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 6 November 2017 at 13:05, Nick Coghlan wrote: > As part of this though, I'd suggest amending the documentation for > DeprecationWarning [1] to specifically cover how to turn it off > programmatically (`warnings.simplefilter("ignore", > DeprecationWarning)`), at the command line (`python -W > i

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Nov 5, 2017, at 18:05, Nick Coghlan wrote: > So my proposal is simple (and not really new): let's revert back to > the way things were in 2.6 and earlier, with DeprecationWarning being > visible by default +1 > As part of this though, I'd suggest amending the documentation for > DeprecationW

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

> On 4 Nov, 2017, at 11:43 AM, Peter Ludemann via Python-Dev > wrote: > > If type annotations are treated like implicit lambdas, then that's a first > step to something similar to Lisp's "special forms". A full generalization of > that would allow, for example, logging.debug to not evaluate i

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

> On 4 Nov, 2017, at 6:32 PM, Nick Coghlan wrote: > > The PEP's current attitude towards this is "Yes, it will break, but > that's OK, because it doesn't matter for the type annotation use case, > since static analysers will still understand it". Adopting such a > cavalier approach towards backw

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 6 November 2017 at 14:14, Barry Warsaw wrote: > On Nov 5, 2017, at 18:05, Nick Coghlan wrote: > >> So my proposal is simple (and not really new): let's revert back to >> the way things were in 2.6 and earlier, with DeprecationWarning being >> visible by default > > +1 > >> As part of this thou

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

On 6 November 2017 at 14:40, Lukasz Langa wrote: > On 4 Nov, 2017, at 6:32 PM, Nick Coghlan wrote: >> The only workaround I can see for that breakage is that instead of >> using strings, we could instead define a new "thunk" type that >> consists of two things: > >> 1. A code object to be run wit

Re: [Python-Dev] [python-committers] Reminder: 12 weeks to 3.7 feature code cutoff

-committers and some individuals dropped from address list. Nick Coghlan writes: > Gah, seven years on from Python 2.7's release, I still get caught by > that. I'm tempted to propose we reverse that decision and go back to > enabling them by default :P > > If app devs don't want their users

Re: [Python-Dev] [python-committers] Reminder: 12 weeks to 3.7 feature code cutoff

On 6 November 2017 at 16:00, Stephen J. Turnbull wrote: > -committers and some individuals dropped from address list. > > Nick Coghlan writes: > > > Gah, seven years on from Python 2.7's release, I still get caught by > > that. I'm tempted to propose we reverse that decision and go back to > >

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

Nick Coghlan writes: > Hence the proposed documentation change: the responsibility for > silencing these warnings (for both their own code and for their > dependencies) should rest with *application* developers, How do you propose to handle users with legacy apps that they can't or their organ

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

> On 5 Nov, 2017, at 9:55 PM, Nick Coghlan wrote: > > Python's name resolution rules are already ridiculously complicated, > and PEP 563 is proposing to make them *even worse*, purely for the > sake of an optional feature primarily of interest to large enterprise > users. Solving forward refere

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 6 November 2017 at 16:26, Stephen J. Turnbull wrote: > Nick Coghlan writes: > > > Hence the proposed documentation change: the responsibility for > > silencing these warnings (for both their own code and for their > > dependencies) should rest with *application* developers, > > How do you pr

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

06.11.17 04:05, Nick Coghlan пише: On the 12-weeks-to-3.7-feature-freeze thread, Jose Bueno & I both mistakenly though the async/await deprecation warnings were missing from 3.6. They weren't missing, we'd just both forgotten those warnings were off by default (7 years after the change to the de

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

I still find this unfriendly to users of Python scripts and small apps who are not the developers of those scripts. (Large apps tend to spit out so much logging it doesn't really matter.) Isn't there a better heuristic we can come up with so that the warnings tend to be on for developers but off f

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

On 6 November 2017 at 16:36, Lukasz Langa wrote: > > On 5 Nov, 2017, at 9:55 PM, Nick Coghlan wrote: > > Python's name resolution rules are already ridiculously complicated, > and PEP 563 is proposing to make them *even worse*, purely for the > sake of an optional feature primarily of interest to

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

06.11.17 05:01, INADA Naoki пише: FYI, Raymond's original compact dict (moving last item to slot used for deleted item) will break OrderedDict. So it's not easy to implement than it looks. OrderedDict uses linked list to keep which slot is used for the key. Moving last item will break it. It me

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

06.11.17 09:09, Guido van Rossum пише: I still find this unfriendly to users of Python scripts and small apps who are not the developers of those scripts. (Large apps tend to spit out so much logging it doesn't really matter.) Isn't there a better heuristic we can come up with so that the warn