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 Yury.Selivanov, brett.cannon, georg.brandl, jkloth, larry, loewis, rhettinger, serhiy.storchaka, taleinat, vajrasky, zach.ware
Date 2014-08-01.01:19:47
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1406855988.67.0.0359615918701.issue20341@psf.upfronthosting.co.za>
In-reply-to
Content
FWIW, Martin agreed with me at EuroPython that "nullable int" is the proper name.  So does Wikipedia:

    http://en.wikipedia.org/wiki/Nullable_type


As for "repeat_new": like I said, I don't intend to check in this change when checking in nullable ints.  (I really just used it because I was doing the work on a plane and just didn't feel like finding a different example.)  I'm simply not interested in picking a fight about it.

However, this is using the general approach endorsed by Guido:

    https://mail.python.org/pipermail/python-dev/2014-January/131673.html

And indeed, see thread for further specific discussion of repeat_new.


I feel the position of "these have been in Python for years, they're fine" misses the point.  Builtins never had signatures before.  Now that they can have signatures, the design decision of writing builtins with non-Pythonic signatures has come home to roost.  How can the signature for itertools.repeat() convey that "times" is an optional parameter without it having a default value?

I view giving all builtins in Python valid signatures as a worthwhile goal unto itself.  So ISTM that allowing "times" to accept None to mean "repeat forever" is reasonable: it makes the function more Pythonic, and it means it can have a meaningful signature.  But if this goal doesn't interest you, I can see why you'd think this was a waste of time.
History
Date User Action Args
2014-08-01 01:19:48larrysetrecipients: + larry, loewis, brett.cannon, georg.brandl, rhettinger, taleinat, jkloth, Yury.Selivanov, zach.ware, serhiy.storchaka, vajrasky
2014-08-01 01:19:48larrysetmessageid: <1406855988.67.0.0359615918701.issue20341@psf.upfronthosting.co.za>
2014-08-01 01:19:48larrylinkissue20341 messages
2014-08-01 01:19:47larrycreate