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
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
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 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 < 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