[Python-Dev] Re: Should set objects maintain insertion order too?
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 mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/SGDD47GTMS7OGIEZTLLXEYHABL5OS4EN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Should set objects maintain insertion order too?
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't think they should. Several thoughts: * The corresponding mathematical concept is unordered and it would be weird to impose such as order. I disagree--I assert it's no more or less weird than imposing order on dicts, which we eventually decided to do. * You can already get membership testing while retaining insertion ordering by running dict.fromkeys(seq). I'm not sure where you're going with this. The argument "you can do this with other objects" didn't preclude us from, for example, adding ordering to the dict object. We already had collections.OrderedDict, and we decided to add the functionality to the dict object. * Set operations have optimizations that preclude giving a guaranteed order (for example, set intersection loops over the smaller of the two input sets). * To implement ordering, set objects would have to give-up their current membership testing optimization that exploits cache locality in lookups (it looks at several consecutive hashes at a time before jumping to the next random position in the table). * 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 still uses a cheaply updated doubly-linked list rather that deleting and reinserting dict entries). 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 should decide the question "should set objects maintain insertion order?" literally without any consideration about performance implications. * This idea has been discussed a couple times before and we've decided not to go down this path. I should document prominently because it is inevitable that it will be suggested periodically because it is such an obvious thing to consider. Please do! In the email quoted by Tim Peters earlier in the thread, you stated that set objects "lose their flexibility" if they maintain order. Can you be more specific about what you meant by that? //arry/ p.s. To be clear, I'm not volunteering to add this feature to the set object implementation--that's above my pay grade. But I'm guessing that, if we decided we wanted these semantics for the dict object, someone would volunteer to implement it. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GLK5RRARJYZKHWR6FDG2MAJJFCL6ZMIC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Should set objects maintain insertion order too?
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, then do that, period. And anyway, it > seems like some genius always figures out how to make it fast sooner or > later ;-) > > I can believe that, given the current implementation, sets might give up > some of their optimizations if they maintained insertion order. But I > don't understand what "flexibility" they would lose. Apart from being > slower, what would set objects give up if they maintained insertion order? > Are there operations on set objects that would no longer be possible? > > > */arry* > > > On 12/15/19 6:58 PM, Tim Peters wrote: > > [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 Dec 2017: > https://twitter.com/raymondh/status/944454031870607360 > """ > Sets use a different algorithm that isn't as amendable to retaining > insertion order. Set-to-set operations lose their flexibility and > optimizations if order is required. Set mathematics are defined in > terms of unordered sets. In short, set ordering isn't in the immediate > future. > """ > > Which is more an answer to "will they?" than "should they?" ;-) > > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/U72GJCRHC7QBLNM7XCEKHEWUDGKUJVEZ/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile) ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/E6RYOYTRZAWD4W46RCYWCYOOK4CQ6GD4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Should set objects maintain insertion order too?
> 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 thoughts: * The corresponding mathematical concept is unordered and it would be weird to impose such as order. * You can already get membership testing while retaining insertion ordering by running dict.fromkeys(seq). * Set operations have optimizations that preclude giving a guaranteed order (for example, set intersection loops over the smaller of the two input sets). * To implement ordering, set objects would have to give-up their current membership testing optimization that exploits cache locality in lookups (it looks at several consecutive hashes at a time before jumping to the next random position in the table). * 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 still uses a cheaply updated doubly-linked list rather that deleting and reinserting dict entries). * This idea has been discussed a couple times before and we've decided not to go down this path. I should document prominently because it is inevitable that it will be suggested periodically because it is such an obvious thing to consider. Raymond ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6CO2CZS4CPP6MSJKRZXXQYFLY5T3UVDU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Should set objects maintain insertion order too?
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 later ;-) I can believe that, given the current implementation, sets might give up some of their optimizations if they maintained insertion order. But I don't understand what "flexibility" they would lose. Apart from being slower, what would set objects give up if they maintained insertion order? Are there operations on set objects that would no longer be possible? //arry/ On 12/15/19 6:58 PM, Tim Peters wrote: [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 Dec 2017: https://twitter.com/raymondh/status/944454031870607360 """ Sets use a different algorithm that isn't as amendable to retaining insertion order. Set-to-set operations lose their flexibility and optimizations if order is required. Set mathematics are defined in terms of unordered sets. In short, set ordering isn't in the immediate future. """ Which is more an answer to "will they?" than "should they?" ;-) ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/U72GJCRHC7QBLNM7XCEKHEWUDGKUJVEZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Should set objects maintain insertion order too?
[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 Dec 2017: https://twitter.com/raymondh/status/944454031870607360 """ Sets use a different algorithm that isn't as amendable to retaining insertion order. Set-to-set operations lose their flexibility and optimizations if order is required. Set mathematics are defined in terms of unordered sets. In short, set ordering isn't in the immediate future. """ Which is more an answer to "will they?" than "should they?" ;-) ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/WMIZRFJZXI3CD5YMLOC5Z3LXVXD7HM4R/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Should set objects maintain insertion order too?
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 it, but I also want fast lookup because I soemtimes remove jobs when they're subsequently marked "not ready". The existing set object would work fine here, except that it doesn't maintain insertion order. That means multiple runs of the program with the same inputs may result in running jobs in different orders, and this instability makes debugging more difficult. I've therefore switched from a set to a dict with all keys mapped to None, which provides all the set-like functionality I need. ISTM that all the reasons why dicts should maintain insertion order also apply to sets, and so I think we should probably do this. Your thoughts? //arry/ p.s. My dim recollection is that the original set object was a hacked-up copy of the dict object removing the ability to store values. So there's some precedent for dicts and sets behaving similarly. (Note: non-pejorative use of "hacked-up" here, that was a fine way to start.) ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/AEKCBGCKX23S4PMA5YNDHFJRHDL4JMKY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Parameters of str(), bytes() and bytearray()
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'") would even be useful
> in any capacity. I would expect this to instead raise a TypeError, similar to
> passing a string to bytes() without specifying an encoding:
> >>> bytes('á')
> ...
> TypeError: string argument without an encoding
>
> 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 pointless
> than returning an empty string from str(errors='strict') or some other
> combination of *errors* and *encoding* kwargs without passing an object.
>
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". With an actual bytes
object, I always prefer b.decode(...) to str(b, encoding=...). But the
one-arg form of str() needs to be able to represent a bytes object in
some way, just as it can represent an int, a Fraction, or a list.
ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/ZP7SXIDQOQVKUF66NVZPS3O4FN3A6DWA/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Parameters of str(), bytes() and bytearray()
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 and/or errors parameter(s) without specifying an object. Returning
an empty string from this seems like it would cover up bugs rather than be
useful in any capacity.
Serhiy Storchaka wrote:
> 2. Make the first parameter of str(), bytes() and bytearray()
> positional-only.
+1, I don't think I've ever seen a single instance of code that passes the
first parameter, *object*, as a kwarg: str(object=obj). As long as the
other two parameters, *encoding* and *error*, remain keyword arguments, I
think this would make sense.
Serhiy Storchaka wrote:
> 3. Make encoding required if errors is specified in str(). This will
> reduce the number of possible combinations, makes str() more similar to
> bytes() and bytearray() and simplify the mental model: if encoding is
> specified, then we decode, and the first argument must be a bytes-like
> object, otherwise we convert an object to a string using __str__.
Hmm, I think this one might require some further consideration. But I will
say that the implicit behavior is not very obvious.
Isn't overly clear, implicit 'utf-8' conversion:
>>> str(b'\xc3\xa1', errors='strict')
'á'
Makes sense, and is highly explicit:
>>> str(b'\xc3\xa1', encoding='utf-8', errors='strict')
'á'
This is also fine ('strict' is a very reasonable default for *errors*)
>>> str(b'\xc3\xa1', encoding='utf-8')
'á'
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'") would even be
useful in any capacity. I would expect this to instead raise a TypeError,
similar to passing a string to bytes() without specifying an encoding:
>>> bytes('á')
...
TypeError: string argument without an encoding
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
pointless than returning an empty string from str(errors='strict') or some
other combination of *errors* and *encoding* kwargs without passing an
object.
On Sun, Dec 15, 2019 at 9:10 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=buffer, encoding=encoding, errors=errors)
> str(encoding=encoding)
> str(errors=errors)
> str(encoding=encoding, errors=errors)
>
> The last three are especially surprising. If you do not specify an
> object, str() ignores values of encoding and errors and returns an empty
> string.
>
> bytes() and bytearray() are more limited. Valid combinations are:
>
> bytes()
> bytes(source=object)
> bytes(source=string, encoding=encoding)
> bytes(source=string, encoding=encoding, errors=errors)
>
> 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. Make the first parameter of str(), bytes() and bytearray()
> positional-only. Originally this feature was an implementation artifact:
> before 3.6 parameters of a C implemented function should be either all
> positional-only (if used PyArg_ParseTuple), or all keyword (if used
> PyArg_ParseTupleAndKeywords). So str(), bytes() and bytearray() accepted
> the first parameter by keyword. We already made similar changes for
> int(), float(), etc: int(x=42) no longer works.
>
> Unlikely str(object=object) is used in a real code, so we can skip a
> deprecation period for this change too.
>
> 3. Make encoding required if errors is specified in str(). This will
> reduce the number of possible combinations, makes str() more similar to
> bytes() and bytearray() and simplify the mental model: if encoding is
> specified, then we decode, and the first argument must be a bytes-like
> object, otherwise we convert an object to a string using __str__.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/YMIGWRUERUG66CKRJXDXNPCIDHRQJY6V/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubs
[Python-Dev] Re: Handling cross-distro variations when running autoreconf?
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 to fail) to keep this in some I'll defined state or another seems odd given anyone can rerun autoconf (as the F package apparently does?) themselves if an issue with it ever comes up. We only check it in and ship it in source tarballs as a convenience. -- blame half the typos on my phone. On Sun, Dec 15, 2019, 5:33 AM Nick Coghlan wrote: > 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 was on master. > > I didn't end up using this plan. Instead, I copied the configure > script *output* from master, and then used "git add -p" to revert the > changes that arose solely from running autoreconf on a non-Debian > system, while keeping the intentional changes from the PR. > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/5T4UY6WON6ZTLAG36ELAYX4K6UDTVXGE/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5HK7I6RIIWNZIH7TJTRNFVXAUFMMFT2N/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Adding a toml module to the standard lib?
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 specification site includes tests: https://github.com/toml-lang/toml/tree/master/tests fwiw, Alan Isaac ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4VUJR62ZZCLFYLJKB4ZJO5YXS7JD3TZS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Emit a SyntaxWarning for unhashables literals in hashable dependant literals.
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/issues/8150 ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/QRTJRL6OSRC2BH3FIHBAWZGZBZQ4MURW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Emit a SyntaxWarning for unhashables literals in hashable dependant literals.
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 an implementer. > > I was not aware of this, I assumed it was a implementation issue because > I knew CPython's dicts use a hash table implementation and there are other > ways to implement a mapping data structure i.e. via trees. > > Guido could you provide a link to the language definition that dictates > these > rules about hashability and (im)mutability? > https://docs.python.org/3/reference/datamodel.html#object.__hash__ Many of the special method descriptions spell out the semantic requirements of well-behaved objects (and we then abide by those requirements when implementing builtin types and standard library modules) > > 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. We'd never check for it in the compiler, as it wouldn't be worth the additional state tracking needed for even the local type inference you suggest. Cheers, Nick. > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4TPAYXZXBWO23Q4BBN4IJM7XNQBCNU75/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Parameters of str(), bytes() and bytearray()
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 > 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=errors) > str(encoding=encoding, errors=errors) > > The last three are especially surprising. If you do not specify an > object, str() ignores values of encoding and errors and returns an empty > string. > > bytes() and bytearray() are more limited. Valid combinations are: > > bytes() > bytes(source=object) > bytes(source=string, encoding=encoding) > bytes(source=string, encoding=encoding, errors=errors) > > 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. Make the first parameter of str(), bytes() and bytearray() > positional-only. Originally this feature was an implementation artifact: > before 3.6 parameters of a C implemented function should be either all > positional-only (if used PyArg_ParseTuple), or all keyword (if used > PyArg_ParseTupleAndKeywords). So str(), bytes() and bytearray() accepted > the first parameter by keyword. We already made similar changes for > int(), float(), etc: int(x=42) no longer works. > > Unlikely str(object=object) is used in a real code, so we can skip a > deprecation period for this change too. > > 3. Make encoding required if errors is specified in str(). This will > reduce the number of possible combinations, makes str() more similar to > bytes() and bytearray() and simplify the mental model: if encoding is > specified, then we decode, and the first argument must be a bytes-like > object, otherwise we convert an object to a string using __str__. > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/YMIGWRUERUG66CKRJXDXNPCIDHRQJY6V/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/XE52X7M6KOTG5JVLKOICH5PHOBZI4MAD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Parameters of str(), bytes() and bytearray()
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=errors) str(encoding=encoding, errors=errors) The last three are especially surprising. If you do not specify an object, str() ignores values of encoding and errors and returns an empty string. bytes() and bytearray() are more limited. Valid combinations are: bytes() bytes(source=object) bytes(source=string, encoding=encoding) bytes(source=string, encoding=encoding, errors=errors) 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. Make the first parameter of str(), bytes() and bytearray() positional-only. Originally this feature was an implementation artifact: before 3.6 parameters of a C implemented function should be either all positional-only (if used PyArg_ParseTuple), or all keyword (if used PyArg_ParseTupleAndKeywords). So str(), bytes() and bytearray() accepted the first parameter by keyword. We already made similar changes for int(), float(), etc: int(x=42) no longer works. Unlikely str(object=object) is used in a real code, so we can skip a deprecation period for this change too. 3. Make encoding required if errors is specified in str(). This will reduce the number of possible combinations, makes str() more similar to bytes() and bytearray() and simplify the mental model: if encoding is specified, then we decode, and the first argument must be a bytes-like object, otherwise we convert an object to a string using __str__. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/YMIGWRUERUG66CKRJXDXNPCIDHRQJY6V/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Handling cross-distro variations when running autoreconf?
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 was on master. I didn't end up using this plan. Instead, I copied the configure script *output* from master, and then used "git add -p" to revert the changes that arose solely from running autoreconf on a non-Debian system, while keeping the intentional changes from the PR. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5T4UY6WON6ZTLAG36ELAYX4K6UDTVXGE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Documenting sorted/min/max prerequisites
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 generic algorithms only depending on '<' and '==' (all standard C++ algorithms do this). But in any case it is better to implement all relation operators if you implement one. I do not know a case when you implement only '<'. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HQHJZX5P6PI7HKEPMSSNKT3XSMIYSEV4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Documenting sorted/min/max prerequisites
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 > back to `__gt__`. Thanks Serhiy, that makes sense. The docs for special methods say that `__gt__` is the reflected version of `__lt__`. Which brings me back to my original question: 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? It would be odd if the guarantee applies to list.sort but not sorted. -- Steven ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/TI3ETKHVRC3IHN2IPZDP5MR2AMMYNMNZ/ Code of Conduct: http://python.org/psf/codeofconduct/
