Let's not change pprint.
On Fri, Dec 22, 2017 at 7:44 AM, Eric Fahlgren
wrote:
> On Thu, Dec 21, 2017 at 7:51 PM, Stephen J. Turnbull <
> turnbull.stephen...@u.tsukuba.ac.jp> wrote:
>
>> I understand the motivation to guarantee order, but it's a programmer
>> convenience
On Thu, Dec 21, 2017 at 7:51 PM, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> I understand the motivation to guarantee order, but it's a programmer
> convenience that has nothing to do with the idea of mapping, and the
> particular (insertion) order is very special and
Chris Barker writes:
> Nathaniel Smith has pointed out that eval(pprint(a_dict)) is
> supposed to return the same dict -- so documented behavior may
> already be broken.
Sure, but that's because we put shoes on a snake. Why anybody expects
no impediment to slithering, I don't know!
I
On Wed, Dec 20, 2017 at 03:23:16PM -0800, Chris Barker wrote:
> On Wed, Dec 20, 2017 at 2:31 AM, Steven D'Aprano
> wrote:
> > Even when it works, the guarantee is quite weak. For instance, even
> > the object type is not preserved:
> >
> > py> class MyDict(dict):
> > ...
On Mon, Dec 18, 2017 at 08:49:54PM -0800, Nathaniel Smith wrote:
> On Mon, Dec 18, 2017 at 7:58 PM, Steven D'Aprano wrote:
> > I have a script which today prints data like so:
[...]
> To make sure I understand, do you actually have a script like this, or
> is this
On Tue, 19 Dec 2017 17:32:52 -0800
Nathaniel Smith wrote:
>
> > In any case, there are so many ways
> > to spoil the first point for yourself that it's hardly worth treating as an
> > important constraint.
>
> I guess the underlying issue here is partly the question of what
On Tue, Dec 19, 2017 at 04:56:16PM -0800, Steve Dower wrote:
> On 19Dec2017 1004, Chris Barker wrote:
> >(though I assume order is still ignored when comparing dicts, so:
> >eval(pprint(a_dict)) == a_dict will still hold.
>
> Order had better be ignored when comparing dicts, or plenty of code
On 12/19/2017 5:32 PM, Nathaniel Smith wrote:
On Tue, Dec 19, 2017 at 4:56 PM, Steve Dower wrote:
On 19Dec2017 1004, Chris Barker wrote:
Nathaniel Smith has pointed out that eval(pprint(a_dict)) is supposed to
return the same dict -- so documented behavior may already
On Dec 19, 2017, at 20:32, Nathaniel Smith wrote:
> I guess the underlying issue here is partly the question of what the
> pprint module is for. In my understanding, it's primarily a tool for
> debugging/introspecting Python programs, and the reason it talks about
> "valid input
On Tue, Dec 19, 2017 at 4:56 PM, Steve Dower wrote:
> On 19Dec2017 1004, Chris Barker wrote:
>>
>> Nathaniel Smith has pointed out that eval(pprint(a_dict)) is supposed to
>> return the same dict -- so documented behavior may already be broken.
>
>
> Two relevant quotes
On 19Dec2017 1004, Chris Barker wrote:
Nathaniel Smith has pointed out that eval(pprint(a_dict)) is supposed to
return the same dict -- so documented behavior may already be broken.
Two relevant quotes from the pprint module docs:
>>> The pprint module provides a capability to “pretty-print”
On 19 December 2017 at 17:57, Steve Holden wrote:
> On Tue, Dec 19, 2017 at 4:49 PM, Stephen J. Turnbull
> wrote:
>>
>> Nathaniel Smith writes:
>>
>> > To make sure I understand, do you actually have a script like this, or
>> > is this
On Tue, Dec 19, 2017 at 8:14 AM, Barry Warsaw wrote:
> On Dec 18, 2017, at 22:37, Nathaniel Smith wrote:
>
> > Wait, what? Why would changing pprint (so that it accurately reflects
> > dict's new underlying semantics!) be a breaking change? Are you
> >
On Tue, Dec 19, 2017 at 4:49 PM, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> Nathaniel Smith writes:
>
> > To make sure I understand, do you actually have a script like this, or
> > is this hypothetical?
>
> I have a couple of doctests that assume that pprint will sort
Nathaniel Smith writes:
> To make sure I understand, do you actually have a script like this, or
> is this hypothetical?
I have a couple of doctests that assume that pprint will sort by key,
yes. It makes the tests look quite a bit nicer by pprinting the
output, and I get sorting (which
On Dec 18, 2017, at 22:37, Nathaniel Smith wrote:
> Wait, what? Why would changing pprint (so that it accurately reflects
> dict's new underlying semantics!) be a breaking change? Are you
> suggesting it shouldn't be changed in 3.7?
As others have pointed out, exactly because
On 19 December 2017 at 08:27, Nathaniel Smith wrote:
> On Mon, Dec 18, 2017 at 11:38 PM, Steve Dower wrote:
>> On 18Dec2017 2309, Steven D'Aprano wrote:
>>> [A LOT OF THINGS I AGREE WITH]
>> I agree completely with Steven's reasoning here, and it bothers
On Mon, Dec 18, 2017 at 11:38 PM, Steve Dower wrote:
> On 18Dec2017 2309, Steven D'Aprano wrote:
>> [A LOT OF THINGS I AGREE WITH]
> I agree completely with Steven's reasoning here, and it bothers me that
> what is an irrelevant change to many users (dict becoming ordered)
On 12/19/2017 2:38 AM, Steve Dower wrote:
On 18Dec2017 2309, Steven D'Aprano wrote:
[A LOT OF THINGS I AGREE WITH]
I agree completely with Steven's reasoning here, and it bothers me that
what is an irrelevant change to many users (dict becoming ordered) seems
to imply that all users of dict
On 18Dec2017 2309, Steven D'Aprano wrote:
> [A LOT OF THINGS I AGREE WITH]
I agree completely with Steven's reasoning here, and it bothers me that
what is an irrelevant change to many users (dict becoming ordered) seems
to imply that all users of dict have to be updated.
I have never needed
On Tue, Dec 19, 2017 at 6:09 PM, Steven D'Aprano wrote:
> I completely agree. We might argue that it was a mistake to sort dicts
> in the first place, or at least a mistake to *always* sort them without
> allowing the caller to provide a sort key. But what's done is done: the
On Mon, Dec 18, 2017 at 08:28:52PM -0800, Chris Barker wrote:
> On Mon, Dec 18, 2017 at 7:41 PM, Steven D'Aprano
> wrote:
>
> > > With arbitrary order, it made sense to sort, so as to always give the
> > same
> > > "pretty" representation. But now that order is "part of" the
On Mon, Dec 18, 2017 at 7:58 PM, Steven D'Aprano wrote:
> On Mon, Dec 18, 2017 at 07:37:03PM -0800, Nathaniel Smith wrote:
>> On Mon, Dec 18, 2017 at 7:02 PM, Barry Warsaw wrote:
>> > On Dec 18, 2017, at 21:11, Chris Barker wrote:
>>
On Mon, Dec 18, 2017 at 7:41 PM, Steven D'Aprano
wrote:
> > With arbitrary order, it made sense to sort, so as to always give the
> same
> > "pretty" representation. But now that order is "part of" the dict itself,
> > it seems prettyprint should present the preserved order
On Mon, Dec 18, 2017 at 07:37:03PM -0800, Nathaniel Smith wrote:
> On Mon, Dec 18, 2017 at 7:02 PM, Barry Warsaw wrote:
> > On Dec 18, 2017, at 21:11, Chris Barker wrote:
> >
> >> Will changing pprint be considered a breaking change?
> >
> > Yes,
On Mon, Dec 18, 2017 at 06:11:05PM -0800, Chris Barker wrote:
> Now that dicts are order-preserving, maybe we should change prettyprint:
>
> In [7]: d = {'one':1, 'two':2, 'three':3}
>
> In [8]: print(d)
> {'one': 1, 'two': 2, 'three': 3}
>
> order preserved.
>
> In [9]: pprint.pprint(d)
>
On Mon, Dec 18, 2017 at 7:02 PM, Barry Warsaw wrote:
> On Dec 18, 2017, at 21:11, Chris Barker wrote:
>
>> Will changing pprint be considered a breaking change?
>
> Yes, definitely.
Wait, what? Why would changing pprint (so that it accurately reflects
On Dec 18, 2017, at 21:11, Chris Barker wrote:
> Will changing pprint be considered a breaking change?
Yes, definitely.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Now that dicts are order-preserving, maybe we should change prettyprint:
In [7]: d = {'one':1, 'two':2, 'three':3}
In [8]: print(d)
{'one': 1, 'two': 2, 'three': 3}
order preserved.
In [9]: pprint.pprint(d)
{'one': 1, 'three': 3, 'two': 2}
order not preserved ( sorted, I presume? )
With
On Fri, Dec 15, 2017 at 9:47 PM, Guido van Rossum wrote:
> [...]
>
> stays ordered across deletions" part of the ruling is true in CPython 3.6.
>
> I don't know what guidance to give Eric, because I don't know what other
> implementations do nor whether Eric cares about
Cool, thanks! I'm curious why this was brought up at all then...
On Dec 15, 2017 3:36 PM, "Raymond Hettinger"
wrote:
>
>
> > On Dec 15, 2017, at 1:47 PM, Guido van Rossum wrote:
> >
> > On Fri, Dec 15, 2017 at 12:45 PM, Raymond Hettinger <
>
> On Dec 15, 2017, at 1:47 PM, Guido van Rossum wrote:
>
> On Fri, Dec 15, 2017 at 12:45 PM, Raymond Hettinger
> wrote:
>
> > On Dec 15, 2017, at 7:53 AM, Guido van Rossum wrote:
> >
> > Make it so. "Dict keeps insertion
On Fri, Dec 15, 2017 at 12:45 PM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
>
> > On Dec 15, 2017, at 7:53 AM, Guido van Rossum wrote:
> >
> > Make it so. "Dict keeps insertion order" is the ruling.
>
> On Twitter, someone raised an interesting question.
>
> Is
> On Dec 15, 2017, at 7:53 AM, Guido van Rossum wrote:
>
> Make it so. "Dict keeps insertion order" is the ruling.
On Twitter, someone raised an interesting question.
Is the guarantee just for 3.7 and later? Or will the blessing also cover 3.6
where it is already true.
On Dec 15, 2017 10:50, "Tim Peters" wrote:
[Eric Snow ]
> Does that include preserving order after deletion?
Given that we're blessing current behavior:
- At any moment, iteration order is from oldest to newest. So, "yes"
to your question.
-
[Eric Snow ]
> Does that include preserving order after deletion?
Given that we're blessing current behavior:
- At any moment, iteration order is from oldest to newest. So, "yes"
to your question.
- While iteration starts with the oldest, .popitem() returns the
On Fri, Dec 15, 2017 at 10:30 AM, Eric Snow
wrote:
> On Fri, Dec 15, 2017 at 8:53 AM, Guido van Rossum
> wrote:
> > Make it so. "Dict keeps insertion order" is the ruling. Thanks!
>
> Does that include preserving order after deletion?
Yes, that's
On Fri, Dec 15, 2017 at 8:53 AM, Guido van Rossum wrote:
> Make it so. "Dict keeps insertion order" is the ruling. Thanks!
Does that include preserving order after deletion?
-eric
___
Python-Dev mailing list
Python-Dev@python.org
On 15 December 2017 at 18:19, Serhiy Storchaka wrote:
> 15.12.17 17:53, Guido van Rossum пише:
>>
>> Make it so. "Dict keeps insertion order" is the ruling. Thanks!
>
> What should dict.popitem() return? The first item, the last item, or
> unspecified?
I'd say leave it as
Whatever it does in 3.6.
On Fri, Dec 15, 2017 at 10:19 AM, Serhiy Storchaka
wrote:
> 15.12.17 17:53, Guido van Rossum пише:
>
>> Make it so. "Dict keeps insertion order" is the ruling. Thanks!
>>
>
> What should dict.popitem() return? The first item, the last item, or
>
15.12.17 17:53, Guido van Rossum пише:
Make it so. "Dict keeps insertion order" is the ruling. Thanks!
What should dict.popitem() return? The first item, the last item, or
unspecified?
___
Python-Dev mailing list
Python-Dev@python.org
On 12/15/2017 11:55 AM, Guido van Rossum wrote:
On Fri, Dec 15, 2017 at 8:32 AM, Raymond Hettinger
> wrote:
> On Dec 15, 2017, at 7:53 AM, Guido van Rossum > wrote:
>
>
On Fri, Dec 15, 2017 at 8:32 AM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
>
> > On Dec 15, 2017, at 7:53 AM, Guido van Rossum wrote:
> >
> > Make it so. "Dict keeps insertion order" is the ruling. Thanks!
>
> Thank you. That is wonderful news :-)
>
> Would it be
> On Dec 15, 2017, at 7:53 AM, Guido van Rossum wrote:
>
> Make it so. "Dict keeps insertion order" is the ruling. Thanks!
Thank you. That is wonderful news :-)
Would it be reasonable to replace some of the OrderedDict() uses in the
standard library with dict()? For
Make it so. "Dict keeps insertion order" is the ruling. Thanks!
On Fri, Dec 15, 2017 at 2:30 AM, INADA Naoki wrote:
> > That's interesting information - I wasn't aware of the different
> > performance goals.
>
> FYI, performance characteristic of my POC implementation of
> That's interesting information - I wasn't aware of the different
> performance goals.
FYI, performance characteristic of my POC implementation of
OrderedDict based on dict order are:
* 50% less memory usage
* 15% faster creation
* 100% (2x) faster iteration
* 20% slower move_to_end
* 40%
On 15 December 2017 at 05:28, Raymond Hettinger
wrote:
> In contrast, I gave collections.OrderedDict a different design (later coded
> in C by Eric Snow). The primary goal was to have efficient maintenance of
> order even for severe workloads such at that imposed
> I support having regular dicts maintain insertion order but am opposed to
> Inada changing the implementation of collections.OrderedDict We can have
> the first without having the second.
>
> It seems like the two quoted paragraphs are in vociferous agreement.
The referenced tracker entry
On Dec 14, 2017 21:30, "Raymond Hettinger"
wrote:
> On Dec 14, 2017, at 6:03 PM, INADA Naoki wrote:
>
> If "dict keeps insertion order" is not language spec and we
> continue to recommend people to use OrderedDict to keep
> order, I want to
> On Dec 14, 2017, at 6:03 PM, INADA Naoki wrote:
>
> If "dict keeps insertion order" is not language spec and we
> continue to recommend people to use OrderedDict to keep
> order, I want to optimize OrderedDict for creation/iteration
> and memory usage. (See
Oh, I just found
https://mail.python.org/pipermail/python-dev/2017-November/150323.html so I
already know what you think: we should go with "dicts preserve insertion
order" rather than "dicts preserve insertion order until the first
deletion". I guess we should wait for Serhiy to confirm that he's
I'm in favor of stating that dict keeps order as part of the language spec.
However re-reading
https://mail.python.org/pipermail/python-dev/2017-November/150381.html
there's still a point of debate: should it be allowed if dict reorders
after deletion (presumably as a result of a rehash)? I'm in
Hi, folks.
TLDR, was the final decision made already?
If "dict keeps insertion order" is not language spec and we
continue to recommend people to use OrderedDict to keep
order, I want to optimize OrderedDict for creation/iteration
and memory usage. (See
08.11.17 04:33, Nick Coghlan пише:
On 8 November 2017 at 11:44, Nick Coghlan wrote:
2. So far, I haven't actually come up with a perturbed iteration
implementation that doesn't segfault the interpreter. The dict
internals are nicely laid out to be iteration friendly, but
It seems there must be at least two threads for each topic worth discussing
at all. Therefore I feel compelled to point to
https://mail.python.org/pipermail/python-dev/2017-November/150381.html,
where I state my own conclusion about dict order.
I know Paul Sokolovsky does not claim to speak for
On Wed, Nov 8, 2017 at 5:35 AM, Paul G wrote:
> If dictionary order is *not* guaranteed in the spec and the dictionary order
> isn't randomized (which I think everyone agrees is a bit messed up), it would
> probably be useful if you could enable "random order mode" in CPython,
> 2. Switches keyword args and class body execution namespaces over to
> odict so the test suite passes again
> 3. Measures the impact such a change would have on the benchmark suite
For now, odict use twice memory and 2x slower on iteration.
https://bugs.python.org/issue31265#msg301942
INADA
On 8 November 2017 at 11:44, Nick Coghlan wrote:
> 2. So far, I haven't actually come up with a perturbed iteration
> implementation that doesn't segfault the interpreter. The dict
> internals are nicely laid out to be iteration friendly, but they
> really do assume that
On Nov 7, 2017, at 16:15, Chris Barker - NOAA Federal
wrote:
> Actually, there is a LOT of code out there that expects reference counting. I
> know a lot of my code does. So if cPython does abandon it some day, there
> will be issues.
I see this all the time in code
On 8 November 2017 at 07:15, Paul Moore wrote:
> On 7 November 2017 at 20:35, Paul G wrote:
>> If dictionary order is *not* guaranteed in the spec and the dictionary order
>> isn't randomized (which I think everyone agrees is a bit messed up), it
>> would
> By the way, I only just realized I can delete a key to demonstrate
> non-order-preservation on py 3.6. So at least I know what to tell students
> now.
>
You can't. dict in Python 3.6 preserves insertion order even after
key deletion.
___
Python-Dev
This seems like overkill to me. By the same logic, we should add a
"delay garbage collection" mode, that allows people to test that their
code doesn't make unwarranted assumptions that a reference-counting
garbage collector is in use.
Actually, there is a LOT of code out there that expects
@ Paul Moore
> This seems like overkill to me. By the same logic, we should add a
> "delay garbage collection" mode, that allows people to test that their
> code doesn't make unwarranted assumptions that a reference-counting
> garbage collector is in use.
But you can get pretty fine-grained
On 7 November 2017 at 21:13, Chris Barker wrote:
> the "only until first deletion" part is really hard -- I hope we don't go
> that route. But I don't think insertion-order is non-obvious -- particularly
> with literals.
But I thought we *had* gone that route. Actually,
On Nov 7, 2017, at 12:35, Paul G wrote:
>
> If dictionary order is *not* guaranteed in the spec and the dictionary order
> isn't randomized (which I think everyone agrees is a bit messed up), it would
> probably be useful if you could enable "random order mode" in CPython, so
On 7 November 2017 at 20:35, Paul G wrote:
> If dictionary order is *not* guaranteed in the spec and the dictionary order
> isn't randomized (which I think everyone agrees is a bit messed up), it would
> probably be useful if you could enable "random order mode" in CPython, so
On Tue, Nov 7, 2017 at 7:21 AM, David Mertz wrote:
> But like Raymond, I make most of my living TEACHING Python.
>
and I make least of my living TEACHING Python ( :-) ),and:
> I feel like the extra order guarantee would make teaching slightly harder.
>
I can't understand how
If dictionary order is *not* guaranteed in the spec and the dictionary order
isn't randomized (which I think everyone agrees is a bit messed up), it would
probably be useful if you could enable "random order mode" in CPython, so you
can stress-test that your code isn't making any assumptions
On Nov 7, 2017 12:02 PM, "Barry Warsaw" wrote:
On Nov 7, 2017, at 09:39, Paul Sokolovsky wrote:
> So, the problem is that there's no "Python language spec”.
There is a language specification: https://docs.python.org/3/refe
rence/index.html
But there are
On Nov 7, 2017, at 09:39, Paul Sokolovsky wrote:
> So, the problem is that there's no "Python language spec”.
There is a language specification:
https://docs.python.org/3/reference/index.html
But there are still corners that are undocumented, or topics that are
On 07/11/17 04:05, David Mertz wrote:
I strongly opposed adding an ordered guarantee to regular dicts. If the
implementation happens to keep that, great. Maybe OrderedDict can be
rewritten to use the dict implementation. But the evidence that all
implementations will always be fine with this
Hello,
On Tue, 7 Nov 2017 14:40:07 +0900
INADA Naoki wrote:
> I agree with Raymond. dict ordered by default makes better developer
> experience.
>
> So, my concern is how "language spec" is important for minor (sorry
> about my bad vocabulary) implementation?
> What's
Hello,
On Tue, 7 Nov 2017 17:33:03 +1100
Steven D'Aprano wrote:
> On Mon, Nov 06, 2017 at 06:35:48PM +0200, Paul Sokolovsky wrote:
>
> > For MicroPython, it would lead to quite an overhead to make
> > dictionary items be in insertion order. As I mentioned, MicroPython
> >
On Nov 7, 2017, at 01:51, Petr Viktorin wrote:
>
> When I explained this in 3.5, dicts rearranging themselves seemed quite weird
> to the newcomers.
> This year, I'm not looking forward to saying that dicts behave "intuitively",
> but you shouldn't rely on that, because
On Nov 6, 2017, at 22:33, Steven D'Aprano wrote:
> I think it would be reasonable to say that builtin dicts only maintain
> insertion order for insertions, lookups, and changing the value. Any
> mutation which deletes keys may arbitrarily re-order the dict.
>
> If the user
On Nov 6, 2017 9:11 PM, "Raymond Hettinger"
wrote:
> On Nov 6, 2017, at 8:05 PM, David Mertz wrote:
> I strongly opposed adding an ordered guarantee to regular dicts. If the
implementation happens to keep that, great. Maybe OrderedDict can be
On 11/07/2017 09:00 AM, Wolfgang wrote:
> Hi,
>
> I have to admit sometimes I don't understand why small things produce so much
> mail traffic. :-)
>
> If I use a mapping like dict most of the time I don't care if it is ordered.
> If I need an ordering I use OrderedDict. In a library if I need a
Hello,
I agree with Wolfgang here. From what I gathered of the discussion, the
argument started from « It would be nice if dict litterals returned ordered
dicts instead of an unordered ones », which is mostly a good thing, as it
allows e.g. `OrderedDict({'spam': 'ham', 'sausages': 'eggs'})`
On Tue, 2017-11-07 at 16:39 +1000, Nick Coghlan wrote:
> And this is the key point for me: "choosing not to choose" is
> effectively the same as standardising the feature, as enough Python
> code will come to rely on CPython's behaviour that most alternative
> implementations will feel obliged to
On 7 November 2017 at 06:39, Nick Coghlan wrote:
> On 7 November 2017 at 09:23, Chris Barker wrote:
>> in short -- we don't have a choice (unless we add an explicit randomization
>> as some suggested -- but that just seems perverse...)
>
> And this is
On 11/07/2017 09:00 AM, Wolfgang wrote:
[...]
Also it is fine to teach people that dict (Mapping) is not ordered
but CPython has an implementation detail and it is ordered.
But if you want the guarantee use OrderedDict.
I don't think that is fine.
When I explained this in 3.5, dicts
Hi,
I have to admit sometimes I don't understand why small things produce so much
mail traffic. :-)
If I use a mapping like dict most of the time I don't care if it is ordered.
If I need an ordering I use OrderedDict. In a library if I need a dict to be
ordered most of the time there is a
On Tue, Nov 07, 2017 at 05:28:24PM +1000, Nick Coghlan wrote:
> On 7 November 2017 at 16:21, Steven D'Aprano wrote:
> > On Mon, Nov 06, 2017 at 08:05:07PM -0800, David Mertz wrote:
> >> Maybe OrderedDict can be
> >> rewritten to use the dict implementation. But the evidence
On 7 November 2017 at 16:21, Steven D'Aprano wrote:
> On Mon, Nov 06, 2017 at 08:05:07PM -0800, David Mertz wrote:
>> Maybe OrderedDict can be
>> rewritten to use the dict implementation. But the evidence that all
>> implementations will always be fine with this restraint
On 7 November 2017 at 09:23, Chris Barker wrote:
> in short -- we don't have a choice (unless we add an explicit randomization
> as some suggested -- but that just seems perverse...)
And this is the key point for me: "choosing not to choose" is
effectively the same as
On Mon, Nov 06, 2017 at 10:17:23PM -0200, Joao S. O. Bueno wrote:
> And also, forgot along the discussion, is the big disadvantage that
> other Python implementations would have a quite
> significant overhead on mandatory ordered dicts.
I don't think that is correct. Nick already did a survey,
On Mon, Nov 06, 2017 at 06:35:48PM +0200, Paul Sokolovsky wrote:
> For MicroPython, it would lead to quite an overhead to make
> dictionary items be in insertion order. As I mentioned, MicroPython
> optimizes for very low bookkeeping memory overhead, so lookups are
> effectively O(n), but
On Mon, Nov 06, 2017 at 08:05:07PM -0800, David Mertz wrote:
> I strongly opposed adding an ordered guarantee to regular dicts. If the
> implementation happens to keep that, great.
That's the worst of both worlds. The status quo is that unless we
deliberately perturb the dictionary order,
On 7 November 2017 at 03:27, Chris Jerdonek wrote:
> On Mon, Nov 6, 2017 at 4:11 AM Nick Coghlan wrote:
>> Getting from the "Works on CPython 3.6+ but is technically
>> non-portable" state to a fully portable correct implementation that
>> ensures a
I agree with Raymond. dict ordered by default makes better developer
experience.
So, my concern is how "language spec" is important for minor (sorry about my
bad vocabulary) implementation?
What's difference between "MicroPython is 100% compatible with
language spec" and
"MicroPython is almost
> On Nov 6, 2017, at 8:05 PM, David Mertz wrote:
>
> I strongly opposed adding an ordered guarantee to regular dicts. If the
> implementation happens to keep that, great. Maybe OrderedDict can be
> rewritten to use the dict implementation. But the evidence that all
>
On Mon, Nov 06, 2017 at 11:33:10AM -0800, Barry Warsaw wrote:
> If we did make the change, it’s possible we would need a way to
> explicit say that order is not preserved. That seems a little weird
> to me, but I suppose it could be useful.
Useful for what?
Given that we will hypothetically
I strongly opposed adding an ordered guarantee to regular dicts. If the
implementation happens to keep that, great. Maybe OrderedDict can be
rewritten to use the dict implementation. But the evidence that all
implementations will always be fine with this restraint feels poor, and we
have a
On Mon, Nov 06, 2017 at 12:18:17PM +0200, Paul Sokolovsky wrote:
> > I don't think that situation should change the decision,
>
> Indeed, it shouldn't. What may change it is the simple and obvious fact
> that there's no need to change anything, as proven by the 25-year
> history of the
On Mon, 6 Nov 2017 at 11:08 Paul Sokolovsky wrote:
> Hello,
>
> On Mon, 06 Nov 2017 17:58:47 +
> Brett Cannon wrote:
>
> []
>
> > > Why suddenly once in 25 years there's a need to do something to
> > > dict's, violating computer science background behind
On 6 November 2017 at 17:23, Paul G wrote:
> Is there a major objection to just adding in explicit syntax for
> order-preserving dictionaries? To some extent that seems like a reasonable
> compromise position in an "explicit is better than implicit" sense. A whole
> lot of
On Mon, Nov 6, 2017 at 11:23 AM, Paul G wrote:
> (Of course, given that CPython's implementation is order-preserving, a
> bunch of code is probably now being written that implicitly requires on
> this detail, but at least having syntax that makes that clear would give
> people
06.11.17 21:56, Paul Sokolovsky пише:
Btw, in all this discussion, I don't remember anyone mentioning sets. I
don't recall the way they're implemented in CPython, but they have
strong conceptual and semantic resemblance to dict's. So, what about
them, do they become ordered too?
No, sets are
Hello,
On Mon, 6 Nov 2017 11:33:10 -0800
Barry Warsaw wrote:
[]
> If we did make the change, it’s possible we would need a way to
> explicit say that order is not preserved. That seems a little weird
I recently was working on a more or less complex dataflow propagation
On Nov 6, 2017, at 11:23, Paul G wrote:
>
> Is there a major objection to just adding in explicit syntax for
> order-preserving dictionaries?
I don’t think new syntax is necessary. We already have OrderedDict, which to
me is a perfectly sensible way to spell “I need a
1 - 100 of 152 matches
Mail list logo