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
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
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
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
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
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
> 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.
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
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
-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
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
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
> 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
> 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,
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
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
> 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
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
> 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
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
>>
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
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
> 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
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
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
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?
>>>
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
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
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
> 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
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
> 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
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
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
> 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
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
+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:
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
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
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
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
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
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
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
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
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
> 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
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
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
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
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
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.
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:
53 matches
Mail list logo