Re: [Python-Dev] Python-Dev Digest, Vol 149, Issue 38
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
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
hello everybody, I am new to this group. Always knew that you were good for a long time, but never really used your technology as such, because my father who passed away recently never wanted me to own a computer in his lifetime. He relented in 2003-04 (cannot remember exactly), due to my pestering him (he was a mechanical+electrical, village boy by background (farmers)) , but he bought me a HP Pavilion with two Intel CPU's (not dual-core) running MS Media Centre edition (full NTFS implemention was only released in this version & first in India). I took it to Australia with me & finally gave it away after it refused to run certain versions of Linux. Attached is my profile & I can assure you I will need lots of help to familiarise myself with your engine. regards, rajneesh tel :+61402350315 weblog : www.vishagotra.wordpress.com www.rns-thoughts.blogspot.com -------------------------------------------- On Tue, 22/12/15, python-dev-request@python.org <python-dev-request@python.org> wrote: Subject: Python-Dev Digest, Vol 149, Issue 38 To: python-dev@python.org Received: Tuesday, 22 December, 2015, 4:00 AM Send Python-Dev mailing list submissions to python-dev@python.org To subscribe or unsubscribe via the World Wide Web, visit https://mail.python.org/mailman/listinfo/python-dev or, via email, send a message with subject or body 'help' to python-dev-request@python.org You can reach the person managing the list at python-dev-owner@python.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Python-Dev digest..." Today's Topics: 1. Re: New poll about a macro for safe reference replacing (Nick Coghlan) 2. Re: Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server) (Random832) 3. Re: Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server) (Guido van Rossum) ---------------------------------------------------------------------- Message: 1 Date: Tue, 22 Dec 2015 01:37:48 +1000 From: Nick Coghlan <ncoghlan@gmail.com> To: Serhiy Storchaka <storchaka@gmail.com> Cc: "python-dev@python.org" <python-dev@python.org> Subject: Re: [Python-Dev] New poll about a macro for safe reference replacing Message-ID: <CADiSq7c5hB-G8mox1aLCvcZtBR7rq41Fmz8aAUf=1w6k5GT2WQ@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On 21 December 2015 at 23:46, Serhiy Storchaka <storchaka@gmail.com> wrote: formulated in previous the old value before
overwriting it.
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
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 | ncoghlan@gmail.com | Brisbane, Australia ------------------------------ Message: 2 Date: Mon, 21 Dec 2015 10:39:09 -0500 From: Random832 <random832@fastmail.com> To: python-dev@python.org Subject: Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server) Message-ID: <87h9jbdd5u.fsf@fastmail.com> Content-Type: text/plain Guido van Rossum <guido@python.org> writes: 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 < 1000000 0 <= seconds < 60
I don't really see it as murky: 0 <= abs(microseconds) < 1000000 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)"? ------------------------------ Message: 3 Date: Mon, 21 Dec 2015 07:47:03 -0800 From: Guido van Rossum <guido@python.org> To: Random832 <random832@fastmail.com> Cc: Python-Dev <python-dev@python.org> Subject: Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server) Message-ID: <CAP7+vJKRKCE7zRKXMKN-bchg6+9kE=GCeKPRskkKv9Yha0hMNA@mail.gmail.com> Content-Type: text/plain; charset="utf-8" We're now thoroughly in python-ideas land. On Mon, Dec 21, 2015 at 7:39 AM, Random832 <random832@fastmail.com> wrote:
Guido van Rossum <guido@python.org> 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 < 1000000 0 <= seconds < 60
I don't really see it as murky:
0 <= abs(microseconds) < 1000000 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 Python-Dev@python.org 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)
participants (1)
-
Rajneesh N. Shetty