Maybe as an alternative to adding multiple divisors to divmod, some datetime.timedelta method this can be added for parsing seconds in a convenient way? Something like this:
Input:
import datetime as dt
delta = dt.timedelta(seconds=10861).decompose()
print(delta)
Output:
datetime.timedelta(hours=3, minutes=1, seconds=1)
Using str(delta) already does something very similar, but not quite.
I am sure that most of use cases are already covered by datetime.timedelta (and this is why the sequence of divmod() calls is now so rare). I was asking in case there are other cases Iām not aware of, but it seems theyāre all hypothetical, and thereās nothing that couldnāt be written as a sequence of 2-argument divmod() calls.
Therefore, I do not see the basis for this feature. Thank you all for the discussion.
Care to elaborate? How do you get timedelta to spit out hours and minutes?
For the record, I just encountered a situation where this would have been useful: working with hex color stored as ints, this proposal would allow writing
>>> color = 0x1c1805ff
>>> R, G, B, A = new_divmod(color, 0x100, 0x100, 0x100)
>>> hex(R), hex(G), hex(B), hex(A)
('0x1c, '0x18', '0x5', '0xff')
Thereās of course plenty of ways to achieve the same result, but I find this one pretty neat 
and it applies to all sequences stored as binary / hex numbers.
This looks like a job for the struct module,
Thereās already a number of ways to split and parse hex/binary sequences that Beat readability and comprehension of a sequencified divmod
Given that the example data is byteorder sensitive as well, I strongly question its usability/safety over tools already available in image/color processing libraries
Code golf creds are a bad reason for new apis
Actually itās the opposite. The divmod-based code is working fundamentally with numbers, and is NOT dependent on byte order; but if you were to pack that number into a structure and then unpack it, you would have to think about whether you used the correct byte order.
I donāt think the colorspace argument is particularly persuasive, thereās another way to write that that doesnāt do division and more closely maps with the underlying idea.
color = 0x1c1805ff
R, G, B, A = [(color >> k) & 0xff for k in range(24, -1, -8)]
Are there any cases where division is the actual intent that would be significantly improved in terms of clarity even with the prior concerns of order of division mattering?
Even easier:
>>> color = 0x1c1805ff
>>> R, G, B, A = color.to_bytes(4)
>>> hex(R), hex(G), hex(B), hex(A)
('0x1c', '0x18', '0x5', '0xff')
i based my assessment on the detail that the base example explicitly used hex notation to split out byte sized chunks of a number
which from my pov is very comparable reinterpreting a c integer as a char[4] to index elements
my major gripe is that the code does not in any way make the intent and the layout clear while libraries for dealing with colors already do that correct and explicitly
so for the given examples, the int object already has a perfect method for it - to_bytes and its using a sensible default for byte-order, so its not clear what your point is
It is comparable, but where reinterpreting an integer as a character array is byte-order sensitive, numeric operations are not. Packing into a structure, like you suggested, IS basically the same as reinterpreting as char array, and is therefore byte-order sensitive (which is why Pythonās struct module allows you to specify).