[Python-Dev] Re: Should set objects maintain insertion order too?

On 12/16/19 10:32 PM, Tim Peters wrote: [Larry] Python is the language where speed, correctness, and readability trump performance every time. Speed trumping performance didn't make any sense ;-) Sorry, that /was/ super unclear!  I honestly meant speed of /development/. D'oh, //arry/ __

[Python-Dev] Re: Should set objects maintain insertion order too?

[Larry] > Didn't some paths also get slightly slower as a result of maintaining > insertion order when mixing insertions and deletions? I paid no attention at the time. But in going from "compact dict" to "ordered dict", deletion all by itself got marginally cheaper. The downside was the nee

[Python-Dev] Re: Parameters of str(), bytes() and bytearray()

The docstring is left not fixed.     str(object='') -> str     str(bytes_or_buffer[, encoding[, errors]]) -> str I noticed this too; the doc and docstring should be made to agree with each other and the code. While exploring the actual behavior, I discovered that while the presence of e

[Python-Dev] Re: Should set objects maintain insertion order too?

[Tim] >> If it's desired that "insertion order" be consistent across runs, >> platforms, and releases, then what "insertion order" _means_ needs to >> be rigorously defined & specified for all set operations. This was >> comparatively trivial for dicts, because there are, e.g., no >> commutative b

[Python-Dev] Re: Should set objects maintain insertion order too?

On 12/16/19 7:43 PM, Tim Peters wrote: [Petr Viktorin ] Here's one (very simplified and maybe biased) view of the history of dicts: * 2.x: Dicts are unordered, please don't rely on the order. * 3.3: Dict iteration order is now randomized. We told you not to rely on it! * 3.6: We now use an opt

[Python-Dev] Re: Should set objects maintain insertion order too?

On 12/16/19 6:30 PM, Tim Peters wrote: If it's desired that "insertion order" be consistent across runs, platforms, and releases, then what "insertion order" _means_ needs to be rigorously defined & specified for all set operations. This was comparatively trivial for dicts, because there are, e

[Python-Dev] Re: Parameters of str(), bytes() and bytearray()

On Mon, Dec 16, 2019 at 12:04 PM Serhiy Storchaka wrote: > 16.12.19 18:35, Guido van Rossum пише: > > On Sun, Dec 15, 2019 at 6:09 AM Serhiy Storchaka > > wrote: > > > > 1. Forbids calling str() without object if encoding or errors are > > specified. It is ver

[Python-Dev] Re: Should set objects maintain insertion order too?

[Petr Viktorin ] > ... > Originally, making dicts ordered was all about performance (or rather > memory efficiency, which falls in the same bucket.) It wasn't added > because it's better semantics-wise. As I tried to flesh out a bit in a recent message, the original "compact dict" idea got all the

[Python-Dev] Re: Should set objects maintain insertion order too?

[Raymond] > ... > * The ordering we have for dicts uses a hash table that indexes into a > sequence. > That works reasonably well for typical dict operations but is unsuitable for > set > operations where some common use cases make interspersed additions > and deletions (that is why the LRU cache

[Python-Dev] Re: Should set objects maintain insertion order too?

[Tim] > BTW, what should > > {1, 2} | {3, 4, 5, 6, 7} > > return as ordered sets? Beats me.; [Larry] > The obvious answer is {1, 2, 3, 4, 5, 6, 7}. Why? An obvious implementation that doesn't ignore performance entirely is: def union(smaller, larger): if len(larger) < len(small

[Python-Dev] Re: Should set objects maintain insertion order too?

On 12/16/19 10:59 AM, Tim Peters wrote: BTW, what should {1, 2} | {3, 4, 5, 6, 7} return as ordered sets? Beats me.; The obvious answer is {1, 2, 3, 4, 5, 6, 7}.  Which is the result I got in Python 3.8 just now ;-)  But that's just a side-effect of how hashing numbers works, the impl

[Python-Dev] Re: Should set objects maintain insertion order too?

On Mon, Dec 16, 2019, 7:35 PM David Cuthbert wrote: > On Mon 12/16/19, 9:59 AM, "David Mertz" wrote: > If some improved implementation of sets had the accidental side effects of > making them ordered, I would still not want that to become a semantic > guarantee. > > Eek… No accidental side effec

[Python-Dev] Re: Should set objects maintain insertion order too?

On Mon 12/16/19, 9:59 AM, "David Mertz" mailto:me...@gnosis.cx>> wrote: Admittedly, I was only lukewarm about making an insertion-order guarantee for dictionaries too. But for sets I feel more strongly opposed. Although it seems unlikely now, if some improved implementation of sets had the acc

[Python-Dev] Re: Should set objects maintain insertion order too?

That looks quite interesting. It looks like compact dict optimization applied to set. I had the same idea :-) If it reduces the memory footprint, keep insertion order and has low performance overhead, I would be an interesting idea! Victor Le lun. 16 déc. 2019 à 07:56, Inada Naoki a écrit : > >

[Python-Dev] Re: GitHub Actions enabled (was: Travis CI for backports not working)

On Mon, Dec 16, 2019 at 11:11 AM Steve Dower wrote: > On 13Dec2019 0959, Brett Cannon wrote: > > Steve Dower wrote: > >> If people are generally happy to move PR builds/checks to GitHub > >> Actions, I'm happy to merge https://github.com/zooba/cpython/pull/7 > >> into > >> our active branches (wi

[Python-Dev] Re: Parameters of str(), bytes() and bytearray()

16.12.19 18:35, Guido van Rossum пише: On Sun, Dec 15, 2019 at 6:09 AM Serhiy Storchaka > wrote: 1. Forbids calling str() without object if encoding or errors are specified. It is very unlikely that this can break a real code, so I propose to make it an er

[Python-Dev] GitHub Actions enabled (was: Travis CI for backports not working)

On 13Dec2019 0959, Brett Cannon wrote: Steve Dower wrote: If people are generally happy to move PR builds/checks to GitHub Actions, I'm happy to merge https://github.com/zooba/cpython/pull/7 into our active branches (with probably Brett's help) and disable Azure Pipelines? I'm personally up fo

[Python-Dev] Re: Should set objects maintain insertion order too?

[Guido] > ... > the language should not disappoint them, optimization opportunities be damned. I would like to distinguish between two kinds of "optimization opportunities": theoretical ones that may or may not be exploited some day, and those that CPython has _already_ exploited. That is, we do

[Python-Dev] Re: Adding a toml module to the standard lib?

Specifically the work to reach 1.0 is tracked in https://github.com/toml-lang/toml/projects/1 and I too think we should wait until 1.0 comes out for the exact reasons Victor laid out. I will also mention that https://github.com/pradyunsg who is a core dev of pip and very active PyPA member is o

[Python-Dev] Re: Should set objects maintain insertion order too?

I can’t think of a time when I’ve really needed sets to maintain insertion order, but thinking about it from a user’s perspective, it’s a natural leap from ordered dicts to ordered sets. At least I don’t immediately think about sets as their mathematical equivalent, but as sets were originally

[Python-Dev] Re: Parameters of str(), bytes() and bytearray()

On Mon, Dec 16, 2019 at 4:06 AM Serhiy Storchaka wrote: > 15.12.19 16:30, David Mertz пише: > > I bet someone in the world has written code like: > > > > foo = str(**dynamic_args()) > > > > And therefore, disabling "silly" combinations of arguments will break > > their code occasionally. > > Do y

[Python-Dev] Re: Should set objects maintain insertion order too?

On Sun, Dec 15, 2019 at 11:28 PM Raymond Hettinger < raymond.hettin...@gmail.com> wrote: > * The corresponding mathematical concept is unordered and it would be > weird to impose such as order. > I'm with Raymond in not wanting sets to maintain insertion (or any) order. Even though I don't doubt

[Python-Dev] Re: Should set objects maintain insertion order too?

On 16Dec2019 0417, Petr Viktorin wrote: Originally, making dicts ordered was all about performance (or rather memory efficiency, which falls in the same bucket.) It wasn't added because it's better semantics-wise. Here's one (very simplified and maybe biased) view of the history of dicts: * 2.

[Python-Dev] Re: Should set objects maintain insertion order too?

I don't know if this works the same for sets, but for dicts, this is the semantics that everyone has wanted for a long time. It makes doctests (and similar things) easier to write, reduces a source of nondeterministic failure, and removes a wart that everyone had to learn: >>> {"foo": 1, "bar": 2,

[Python-Dev] Re: Parameters of str(), bytes() and bytearray()

On Sun, Dec 15, 2019 at 6:09 AM Serhiy Storchaka wrote: > Currently str() takes up to 3 arguments. All are optional and > positional-or-keyword. All combinations are valid: > > str() > str(object=object) > str(object=buffer, encoding=encoding) > str(object=buffer, errors=errors) > str(object=buff

[Python-Dev] Re: Should set objects maintain insertion order too?

On 2019-12-16 06:00, Larry Hastings wrote: [...] These are all performance concerns.  As I mentioned previously in this thread, in my opinion we should figure out what semantics we want for the object, then implement those, and only after that should we worry about performance.  I think we sh

[Python-Dev] Re: Parameters of str(), bytes() and bytearray()

Kyle Stanley wrote: > or making *object* a positional only argument. Typo: I meant "positional only parameter", not "argument". On Mon, Dec 16, 2019 at 4:39 AM Kyle Stanley wrote: > > Inada Naoki wrote: > > If we find it broke some software, we can step back to regular > > deprecation workflow.

[Python-Dev] Re: Parameters of str(), bytes() and bytearray()

Inada Naoki wrote: > If we find it broke some software, we can step back to regular > deprecation workflow. > Python 3.9 is still far from beta yet. That's why I'm +1 on these proposals. IMO, since this would be changing a builtin function, we should at least use a version+2 deprecation cycle (in

[Python-Dev] Re: Parameters of str(), bytes() and bytearray()

On Mon, Dec 16, 2019 at 6:25 PM Inada Naoki wrote: > > +1 for 1 and 2. > If we find it broke some software, we can step back to regular deprecation workflow. Python 3.9 is still far from beta yet. That's why I'm +1 on these proposals. -- Inada Naoki __

[Python-Dev] Re: Parameters of str(), bytes() and bytearray()

On Sun, Dec 15, 2019 at 11:07 PM Serhiy Storchaka wrote: > > I propose several changes: > > 1. Forbids calling str() without object if encoding or errors are > specified. It is very unlikely that this can break a real code, so I > propose to make it an error without a deprecation period. > > 2. Ma

[Python-Dev] Re: Parameters of str(), bytes() and bytearray()

Serhiy Storchaka wrote: > It is not more confusing that returning "". By > default str() returns the same as repr(), unless we made the object > having other string representation. Yeah, I suppose not. But that does raise of question of why bytes objects were made to have a specific form of string

[Python-Dev] Re: Parameters of str(), bytes() and bytearray()

16.12.19 10:34, Eric V. Smith пише: On 12/16/2019 3:05 AM, Kyle Stanley wrote: Chris Angelico wrote: > ANY object can be passed to str() in order to get some sort of valid > printable form. The awkwardness comes from the fact that str() > performs double duty - it's both "give me a printable for

[Python-Dev] Re: Parameters of str(), bytes() and bytearray()

Eric V. Smith wrote: > Debugging. I sometimes do things like: print('\n'.join(str(thing) for thing in lst)), or various variations on this. This is especially useful > when maybe something in the list is a bytes object where I was expecting a string. > > I'm not saying it's the best practice, but c

[Python-Dev] Re: Parameters of str(), bytes() and bytearray()

15.12.19 16:30, David Mertz пише: I bet someone in the world has written code like: foo = str(**dynamic-args()) And therefore, disabling "silly" combinations of arguments will break their code occasionally. Do you have real world examples? ___ Pyth

[Python-Dev] Re: Parameters of str(), bytes() and bytearray()

16.12.19 02:55, Kyle Stanley пише: I'd much prefer to see something like this: >>> str(b'\xc3\xa1') ... TypeError: bytes argument without an encoding Is there some use case for returning "b'\\xc3\\xa1'" from this operation that I'm not seeing? To me, it seems equally, if not more confusing and

[Python-Dev] Re: Should set objects maintain insertion order too?

16.12.19 04:48, Larry Hastings пише: As of 3.7, dict objects are guaranteed to maintain insertion order.  But set objects make no such guarantee, and AFAIK in practice they don't maintain insertion order either.  Should they? I do have a use case for this. In one project I maintain a "ready" l

[Python-Dev] Re: Parameters of str(), bytes() and bytearray()

On 12/16/2019 3:05 AM, Kyle Stanley wrote: Chris Angelico wrote: > ANY object can be passed to str() in order to get some sort of valid > printable form. The awkwardness comes from the fact that str() > performs double duty - it's both "give me a printable form of this > object" and "decode these

[Python-Dev] Re: Parameters of str(), bytes() and bytearray()

On 12/16/2019 12:05 AM, Kyle Stanley wrote: Chris Angelico wrote: > ANY object can be passed to str() in order to get some sort of valid > printable form. The awkwardness comes from the fact that str() > performs double duty - it's both "give me a printable form of this > object" and "decode thes

[Python-Dev] Re: Parameters of str(), bytes() and bytearray()

Chris Angelico wrote: > ANY object can be passed to str() in order to get some sort of valid > printable form. The awkwardness comes from the fact that str() > performs double duty - it's both "give me a printable form of this > object" and "decode these bytes into text". While it does make sense