homepage

This issue tracker has been migrated to GitHub , and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author larry
Recipients Mark.Shannon, amaury.forgeotdarc, benjamin.peterson, brett.cannon, dmalcolm, ilblackdragon, jcea, larry, mark.dickinson, vstinner
Date 2013年03月31日.19:29:49
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1364758189.59.0.0992026014456.issue17206@psf.upfronthosting.co.za>
In-reply-to
Content
For the record: I care. Generally speaking CPython is a lovingly
crafted source tree, and the choices its architects made are nearly
always sensible and well-reasoned. When I see things like this, things
that seem kind of dumb on first glance, I worry that we're missing
something.
It could be that it did have a sensible reason fifteen years ago, like
some bone-headed compiler generated awful code--and the macros *are*
used everywhere, so maybe performance genuinely suffered. Or maybe
the macros were originally intended to be usable as rvalues; it looks
like Py_INCREF still permits that, and changing it to be a statement
could be considered a breaking API change.
But we can't let ourselves become hidebound and superstitious. I see
no reason why a local temporary variable shouldn't be fine here, and
perhaps in all the macros Mark cites. So don't get me wrong, I'm +1.
(The documentation on Py_INCREF makes no mention of whether it's legal
as an rvalue, and all the examples use it as a statement. Perhaps we
should document it explicitly so for 3.4.)
History
Date User Action Args
2013年03月31日 19:29:49larrysetrecipients: + larry, brett.cannon, jcea, amaury.forgeotdarc, mark.dickinson, vstinner, benjamin.peterson, dmalcolm, Mark.Shannon, ilblackdragon
2013年03月31日 19:29:49larrysetmessageid: <1364758189.59.0.0992026014456.issue17206@psf.upfronthosting.co.za>
2013年03月31日 19:29:49larrylinkissue17206 messages
2013年03月31日 19:29:49larrycreate

AltStyle によって変換されたページ (->オリジナル) /