Re: [Python-Dev] Propose rejection of PEP 303 -- Extend divmod() for Multiple Divisors
About PEP 303, I use divmod for lots (and lots) of things, but I've got no real use for an extended divmod() either. -1: it would be low-use, confusing clutter. [Barry] > Interesting. Just yesterday I wrote a simple stopwatch-like timer > script and I found that I needed three divmod calls to convert from > seconds into a datetime.time object. You don't need any divmods for that ... ... > Actually, no, because datetime.time(seconds=50227) throws an exception. That's right: the time class models a time of day, not "seconds from Barry's implied midnight epoch" (or something like that). What you wanted was a timedelta instead. Converting that to a time is then simplicity itself : >>> print (datetime(1, 1, 1) + timedelta(seconds=50227)).time() 13:57:07 You have to go thru a datetime object first because time objects don't support arithmetic either. That isn't all bad. By going thru a datetime first, it's clear what happens if the number of seconds you feed in exceeds a day's worth. You can check for that or ignore it then, depending on what your app wants (it may or may not be "an error", depending on the app). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Propose rejection of PEP 303 -- Extend divmod() for Multiple Divisors
Raymond Hettinger wrote: >>Plus, it fails the "not every 3-line function has to be a builtin" >>guideline: > > > Not to pick, but I hope this doesn't become a recurring refrain. That > isn't a real guideline, it's more of a snipe. It also runs counter to > Zen about proposals not being complex and being easy to explain. I guess I really mean "the use case is obscure enough that simply writing the 5-line function is better than cluttering the API of a builtin", but that doesn't have quite the same ring to it ;) > There > are tons of exceptions. Guido's new any() and all() replace only a > single line. The sorted() builtin was very successful and it only > replaced a couple of lines. The key= argument is also successful but > replaces a simple, three-line Schwarzian transform. Reading DictMixin > shows that most dictionary methods are trivially expressed in terms of a > few primitives; however, we've learned that the mapping API is > excellent, expressive, and useful (except for setdefault which I've > grown to hate ;-). IOW, the quip is food for thought but not > necessarily either a positive or negative point about a proposal. That's basically what I meant - and what I take the phrase to mean when someone else uses it. If something is simple to write, but the use case is obscure, then that's an argument *against* making it a builtin, since half the time you'll have the function written before you remember there's a builtin for it. On the other hand, if the use case is common enough, rewriting it every time you need it is just a pain. The 'not every . . .' comment just tries to say all that using only ten words. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Propose rejection of PEP 303 -- Extend divmod() for Multiple Divisors
On Fri, 2005-06-17 at 05:57, Raymond Hettinger wrote: > This PEP has been open for two and half years without generating > discussion or support. Interesting. Just yesterday I wrote a simple stopwatch-like timer script and I found that I needed three divmod calls to convert from seconds into a datetime.time object. This PEP might have come in handy there, but OTOH, I'm not so sure that's enough justification to accept the PEP. > Its primary case (converting cumulative seconds into a tuple days, > hours, minutes, and seconds) is a bit wanting because it doesn't > generalize to months and years. That need is already met in a more > robust and flexible way by date and time specific modules. Actually, no, because datetime.time(seconds=50227) throws an exception. But in my specific case, I didn't find the need for three divmod calls nearly as frustrating as the lack of a datetime.time.fromseconds() call. > More importantly, the gain in succinctness is offset by a loss of > clarity. Consider: > >dist, inches = divmod(dist, 12) >yards, feet = divmod(dist, 3) > > versus a proposed: > >yards, feet, inches = divmod(dist, 3, 12) > > The latter form makes it difficult to visually confirm the correct > number of target variables. Likewise, it is not at all obvious that the > order of the 3 and 12 are correct. I agree. My three divmod solution is perfectly readable and simple to write. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Propose rejection of PEP 303 -- Extend divmod() for Multiple Divisors
Raymond Hettinger wrote: > Executive summary: cute, but unpersuasive and unnecessary, not worth > the time to code, test, document, maintain, and explain. Plus, it fails the "not every 3-line function has to be a builtin" guideline: def extended_divmod(numerator, *denominators): remainders = [] for denominator in reversed(denominators): numerator, remainder = divmod(numerator, denominator) remainders.insert(0, remainder) return tuple(remainders) OK, 5 lines. Anyway, not very hard to write for anyone with a genuine use case - and, like you, I've never used divmod for anything other than extracting digits (or groups of digits) from numbers. I also don't buy the 'tedious and easy to get wrong each time you need it' justification in the PEP. Getting the argument order to the extended divmod wrong seems to be even easier. For each of the cited use cases, a well-named function, or a proper class seems like a much cleaner solution. e.g. class Declination(object): def __init__(self, value): try: # Copy a duck-typed declination self.degrees = value.degrees self.minutes = value.minutes self.seconds = value.seconds except AttributeError: try: # Allow any three-value sequence self.degrees, self.minutes, self.seconds = value except TypeError: # Divide a number value, self.seconds = divmod(value, 60) value, self.minutes = divmod(value, 60) value, self.degrees = divmod(value, 360) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
