On Mon, Dec 16, 2019 at 1:33 PM Guido van Rossum wrote:
>
> Actually, for dicts the implementation came first.
>
I had tried to implement the Ordered Set. Here is the implementation.
https://github.com/methane/cpython/pull/23
Regards,
___
Python-Dev m
On 12/15/19 8:25 PM, Raymond Hettinger wrote:
On Dec 15, 2019, at 6:48 PM, Larry Hastings wrote:
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 don
Actually, for dicts the implementation came first.
On Sun, Dec 15, 2019 at 19:50 Larry Hastings wrote:
>
> That's not a reason why we shouldn't do it. Python is the language where
> speed, correctness, and readability trump performance every time. We
> should decide what semantics we want, the
> On Dec 15, 2019, at 6:48 PM, Larry Hastings wrote:
>
> 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 don't think they should.
Several tho
That's not a reason why we shouldn't do it. Python is the language
where speed, correctness, and readability trump performance every time.
We should decide what semantics we want, then do that, period. And
anyway, it seems like some genius always figures out how to make it fast
sooner or l
[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.
If they ever appear to, it's an accident you shouldn't rely on.
> Should they?
>From Raymond, 22
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" list
of jobs; I need to iterate over
On Mon, Dec 16, 2019 at 12:00 PM Kyle Stanley wrote:
> On a related note though, I'm not a fan of this behavior:
> >>> str(b'\xc3\xa1')
> "b'\\xc3\\xa1'"
>
> Passing a bytes object to str() without specifying an encoding seems like a
> mistake, I honestly don't see how this ("b'\\xc3\\xa1'") woul
Serhiy Storchaka wrote:
> 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.
+1, I suspect that nobody would intentionally pass an argument to the
encoding
I personally think we shouldn't worry about it. I *try* to use an autoconf
version at least as recent as what was used for the current file, but
beyond that it is unlikely anything depends on autoconf distroisms within
our own in tree configure.
Forcing humans to do weird tricks (always guaranteed
It appears that Julia has decided that the TOML spec is stable enough
to include a parser in the standard library:
https://github.com/JuliaLang/Pkg.jl/issues/1011
I've had good experiences with the `toml` Package for Python:
https://github.com/uiri/toml.git
It has an MIT license.
The TOML specif
Nick Coghlan wrote:
> > A tool like
> > mypy will catch this for you.
> > Perhaps I should raise this as a mypy issue then?
> Aye, a typechecker failing to catch this situation would definitely be a
> reasonable issue to raise.
Roger that, I've raised this on mypy: https://github.com/python/mypy/i
On Fri., 13 Dec. 2019, 5:26 pm mental na via Python-Dev, <
python-dev@python.org> wrote:
> Guido van Rossum wrote:
> > This is most definitely a language issue, not just a CPython issue -- the
> > rules around hashability and (im)mutability are due to the language
> > definition, not the whim of a
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.
On Sun, Dec 15, 2019, 9:09 AM Serhiy Storchaka wrote:
> Currently str() takes up to 3 arguments. All are optional and
> p
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=buffer, encoding=encoding, errors=errors)
str(encoding=encoding)
str(errors
On Sun, 8 Dec 2019 at 23:58, Nick Coghlan wrote:
> Does anyone have any recommendations for dealing with this? My current
> plan is to revert back to the configure script from master, run
> autoreconf, and then use `git add -p` to only add in the desired
> changes, leaving everything else as it wa
15.12.19 12:27, Steven D'Aprano пише:
Since list.sort guarantees that it will only use the `<` less than
operator, should we make the same guarantee for sorted, min and/or max?
Perhaps. And also for heapq and maybe some other functions. Do you mind
to create a PR?
It is common to make generi
On Sat, Dec 14, 2019 at 04:20:43PM +0200, Serhiy Storchaka wrote:
> 14.12.19 15:29, Steven D'Aprano пише:
> >I might be misinterpreting the evidence, but sorting works on objects
> >that define `__gt__` without `__lt__`.
[...]
> The `<` operator try to use `__lt__`, but if it is not defined falls
18 matches
Mail list logo
