Re: [Python-Dev] New poll about a macro for safe reference replacing
On 16.12.15 16:12, Serhiy Storchaka wrote: Please put your vote (a floating number from -1 to 1 including) for every of proposed name. You also can propose new name. Thank you all for your votes. Results of the poll: Py_SETREF: +5 = +5 (Victor, Steve, Yury, Brett, Nick) +0 (Ryan, Martin) Py_REPLACE_REF: +2.5 = +2.5 (Ryan, Victor, Steve, Martin) -0 (Nick) Py_REPLACE: +0 = +1 (Martin) -1 (Ryan) +0 (Nick) Py_RESET: 0 = +1 (Ryan) -1 (Martin) Py_DECREF_REPLACE: -2 = +1 (Ryan, Martin) -3 (Victor, Steve, Nick) Py_SET_POINTER, Py_SET_ATTR: -5 (Ryan, Victor, Steve, Martin, Nick) Therefore Py_SETREF is the winner. But I want also to remember objections against it formulated in previous discussion. 1) By analogy with Py_INCREF and Py_DECREF that increment and decrement the reference counter of the object, Py_SETREF looks as it *sets* the reference counter of the object. 2) By analogy with PyList_SET_ITEM, PyTuple_SET_ITEM, PyCell_SET, etc, it is not expected that Py_SETREF decrement the refcounter of the old value before overwriting it. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New poll about a macro for safe reference replacing
On 21 December 2015 at 23:46, Serhiy Storchaka wrote: > On 16.12.15 16:12, Serhiy Storchaka wrote: >> >> Please put your vote (a floating number from -1 to 1 including) for >> every of proposed name. You also can propose new name. > > > Thank you all for your votes. > > Results of the poll: > > Py_SETREF: +5 = +5 (Victor, Steve, Yury, Brett, Nick) +0 (Ryan, Martin) > > Py_REPLACE_REF: +2.5 = +2.5 (Ryan, Victor, Steve, Martin) -0 (Nick) > > Py_REPLACE: +0 = +1 (Martin) -1 (Ryan) +0 (Nick) > > Py_RESET: 0 = +1 (Ryan) -1 (Martin) > > Py_DECREF_REPLACE: -2 = +1 (Ryan, Martin) -3 (Victor, Steve, Nick) > > Py_SET_POINTER, Py_SET_ATTR: -5 (Ryan, Victor, Steve, Martin, Nick) > > Therefore Py_SETREF is the winner. > > But I want also to remember objections against it formulated in previous > discussion. > > 1) By analogy with Py_INCREF and Py_DECREF that increment and decrement the > reference counter of the object, Py_SETREF looks as it *sets* the reference > counter of the object. > > 2) By analogy with PyList_SET_ITEM, PyTuple_SET_ITEM, PyCell_SET, etc, it is > not expected that Py_SETREF decrement the refcounter of the old value before > overwriting it. Avoiding those misleading associations is a good argument in favour of Py_REPLACE over Py_SETREF - they didn't occur to me before casting my votes, and I can definitely see them causing confusion in the future. So perhaps the combination that makes the most sense is to add Py_REPLACE (uses Py_DECREF on destination) & Py_XREPLACE (uses Py_XDECREF on destination) to the existing Py_CLEAR? Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)
Guido van Rossum writes: > I'm sure that one often catches people by surprise. However, I don't > think we can fix that one without also fixing the values of the > attributes -- in that example days is -1 and seconds is 86340 (which > will *also* catch people by surprise). And changing that would be > much, much harder for backwards compatibility reasons-- we'd have to > set days to 0 and seconds to -60, and suddenly we have a much murkier > invariant, instead of the crisp > > 0 <= microseconds < 100 > 0 <= seconds < 60 I don't really see it as murky: 0 <= abs(microseconds) < 100 0 <= abs(seconds) < 60 (days <= 0) == (seconds <= 0) == (microseconds <= 0) (days >= 0) == (seconds >= 0) == (microseconds >= 0) The latter are more easily phrased in english as "all nonzero attributes have the same sign". I think the current behavior is rather as if -1.1 were represented as "-2+.9". The attributes probably can't be fixed without breaking backwards compatibility, though. How about "-timedelta(0, 60)"? ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)
We're now thoroughly in python-ideas land. On Mon, Dec 21, 2015 at 7:39 AM, Random832 wrote: > Guido van Rossum writes: > > I'm sure that one often catches people by surprise. However, I don't > > think we can fix that one without also fixing the values of the > > attributes -- in that example days is -1 and seconds is 86340 (which > > will *also* catch people by surprise). And changing that would be > > much, much harder for backwards compatibility reasons-- we'd have to > > set days to 0 and seconds to -60, and suddenly we have a much murkier > > invariant, instead of the crisp > > > > 0 <= microseconds < 100 > > 0 <= seconds < 60 > > I don't really see it as murky: > > 0 <= abs(microseconds) < 100 > 0 <= abs(seconds) < 60 > (days <= 0) == (seconds <= 0) == (microseconds <= 0) > (days >= 0) == (seconds >= 0) == (microseconds >= 0) > > The latter are more easily phrased in english as "all nonzero > attributes have the same sign". I think the current behavior is > rather as if -1.1 were represented as "-2+.9". The attributes > probably can't be fixed without breaking backwards > compatibility, though. How about "-timedelta(0, 60)"? > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New poll about a macro for safe reference replacing
Was Py_MOVEREF (or MOVE_REF) ever suggested? Those are valid objections, and now they're raised I remember them from last time. But I don't think they're a huge concern - setting a ref count directly doesn't seem useful anyway, and the compiler/IDE will let you know pretty quick if you put an integer vs a PyObject* there. Cheers, Steve Top-posted from my Windows Phone -Original Message- From: "Nick Coghlan" Sent: 12/22/2015 2:39 To: "Serhiy Storchaka" Cc: "[email protected]" Subject: Re: [Python-Dev] New poll about a macro for safe reference replacing On 21 December 2015 at 23:46, Serhiy Storchaka wrote: > On 16.12.15 16:12, Serhiy Storchaka wrote: >> >> Please put your vote (a floating number from -1 to 1 including) for >> every of proposed name. You also can propose new name. > > > Thank you all for your votes. > > Results of the poll: > > Py_SETREF: +5 = +5 (Victor, Steve, Yury, Brett, Nick) +0 (Ryan, Martin) > > Py_REPLACE_REF: +2.5 = +2.5 (Ryan, Victor, Steve, Martin) -0 (Nick) > > Py_REPLACE: +0 = +1 (Martin) -1 (Ryan) +0 (Nick) > > Py_RESET: 0 = +1 (Ryan) -1 (Martin) > > Py_DECREF_REPLACE: -2 = +1 (Ryan, Martin) -3 (Victor, Steve, Nick) > > Py_SET_POINTER, Py_SET_ATTR: -5 (Ryan, Victor, Steve, Martin, Nick) > > Therefore Py_SETREF is the winner. > > But I want also to remember objections against it formulated in previous > discussion. > > 1) By analogy with Py_INCREF and Py_DECREF that increment and decrement the > reference counter of the object, Py_SETREF looks as it *sets* the reference > counter of the object. > > 2) By analogy with PyList_SET_ITEM, PyTuple_SET_ITEM, PyCell_SET, etc, it is > not expected that Py_SETREF decrement the refcounter of the old value before > overwriting it. Avoiding those misleading associations is a good argument in favour of Py_REPLACE over Py_SETREF - they didn't occur to me before casting my votes, and I can definitely see them causing confusion in the future. So perhaps the combination that makes the most sense is to add Py_REPLACE (uses Py_DECREF on destination) & Py_XREPLACE (uses Py_XDECREF on destination) to the existing Py_CLEAR? Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40python.org ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)
On Sun, Dec 20, 2015 at 2:28 PM, Chris Angelico wrote: > > Would there be value in changing the repr to use keyword arguments? > this thread got long, but it sounds like that won't be worth the backwards compatibility... > Worse, help(datetime.timedelta) in 3.6 doesn't document the > constructor at all. There's no mention of __init__ at all, __new__ has > this useless information: > but this seems to have gotten lost in the shuffle. and aside from there being three data descriptors, there's nothing to > suggest that you construct these things with timedelta(days, seconds, > microseconds). Definitely no indication that you can use other keyword > args. > > Is this something worth fixing, or is it acceptable to drive people to > fuller documentation than help()? > Absolutlye worht fixing! maybe it' sjsut my weird workflow, but I find it very, very useful to use iPython's ? : In [10]: datetime.timedelta? Docstring: Difference between two datetime values.File: ~/miniconda2/lib/python2.7/lib-dynload/datetime.so Type: type and there are a LOT of next-to worthless docstrings in the stdlib -- it would be nice to clean them all up. Is there any reason not to, other than someone having to do the work? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)
Would you be able to submit a patch to address the docstring issues? --Guido (mobile) On Dec 21, 2015 2:09 PM, "Chris Barker" wrote: > On Sun, Dec 20, 2015 at 2:28 PM, Chris Angelico wrote: > >> >> Would there be value in changing the repr to use keyword arguments? >> > > this thread got long, but it sounds like that won't be worth the backwards > compatibility... > > >> Worse, help(datetime.timedelta) in 3.6 doesn't document the >> constructor at all. There's no mention of __init__ at all, __new__ has >> this useless information: >> > > but this seems to have gotten lost in the shuffle. > > and aside from there being three data descriptors, there's nothing to >> suggest that you construct these things with timedelta(days, seconds, >> microseconds). Definitely no indication that you can use other keyword >> args. >> >> Is this something worth fixing, or is it acceptable to drive people to >> fuller documentation than help()? >> > > Absolutlye worht fixing! maybe it' sjsut my weird workflow, but I find it > very, very useful to use iPython's ? : > > In [10]: datetime.timedelta? > Docstring: Difference between two datetime values.File: > ~/miniconda2/lib/python2.7/lib-dynload/datetime.so > Type: type > > and there are a LOT of next-to worthless docstrings in the stdlib -- it > would be nice to clean them all up. > > Is there any reason not to, other than someone having to do the work? > > -Chris > > > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R(206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > [email protected] > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)
I still think the repr change to use keywords has a good chance for 3.6. --Guido (mobile) On Dec 21, 2015 2:09 PM, "Chris Barker" wrote: > On Sun, Dec 20, 2015 at 2:28 PM, Chris Angelico wrote: > >> >> Would there be value in changing the repr to use keyword arguments? >> > > this thread got long, but it sounds like that won't be worth the backwards > compatibility... > > >> Worse, help(datetime.timedelta) in 3.6 doesn't document the >> constructor at all. There's no mention of __init__ at all, __new__ has >> this useless information: >> > > but this seems to have gotten lost in the shuffle. > > and aside from there being three data descriptors, there's nothing to >> suggest that you construct these things with timedelta(days, seconds, >> microseconds). Definitely no indication that you can use other keyword >> args. >> >> Is this something worth fixing, or is it acceptable to drive people to >> fuller documentation than help()? >> > > Absolutlye worht fixing! maybe it' sjsut my weird workflow, but I find it > very, very useful to use iPython's ? : > > In [10]: datetime.timedelta? > Docstring: Difference between two datetime values.File: > ~/miniconda2/lib/python2.7/lib-dynload/datetime.so > Type: type > > and there are a LOT of next-to worthless docstrings in the stdlib -- it > would be nice to clean them all up. > > Is there any reason not to, other than someone having to do the work? > > -Chris > > > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R(206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > [email protected] > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)
On Dec 21, 2015, at 14:07, Chris Barker wrote: > > and there are a LOT of next-to worthless docstrings in the stdlib -- it would > be nice to clean them all up. > > Is there any reason not to, other than someone having to do the work? Is this just a matter of _datetimemodule.c (and various other things in the stdlib) not being (completely) argclinicified? Or is there something hairy about this type (and various other things in the stdlib) that makes them still useless even with argclinic? ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New poll about a macro for safe reference replacing
On 21/12/2015 21:57, Steve Dower wrote: Was Py_MOVEREF (or MOVE_REF) ever suggested? Those are valid objections, and now they're raised I remember them from last time. But I don't think they're a huge concern - setting a ref count directly doesn't seem useful anyway, and the compiler/IDE will let you know pretty quick if you put an integer vs a PyObject* there. Cheers, Steve Or Py_SAFEREF or SAFE_REF? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)
>> and there are a LOT of next-to worthless docstrings in the stdlib -- it >> would be nice to clean them all up. >> >> Is there any reason not to, other than someone having to do the work? And yes, I'd be willing to submit a patch. > Is this just a matter of _datetimemodule.c (and various other things in the > stdlib) not being (completely) argclinicified? But clearly I'll need some help knowing where to add the docs... -CHB > Or is there something hairy about this type (and various other things in the > stdlib) that makes them still useless even with argclinic? ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
