[Python-Dev] Deadline for PythonFOSDEM 2016 is today.
Just inform you that the deadline for the CfP of the PythonFOSDEM will finish this evening. If you have a last talk to submit, please do it. Call For Proposals == This is the official call for sessions for the Python devroom at FOSDEM 2016. FOSDEM is the Free and Open source Software Developers' European Meeting, a free and non-commercial two-day week-end that offers open source contributors a place to meet, share ideas and collaborate. FOSDEM is in Brussels in Belgium on 30th January. It's the biggest event in Europe with +5000 hackers, +400 speakers. For this edition, Python will be represented by its Community. If you want to discuss with a lot of Python Users, it's the place to be! Important dates === * Submission deadlines: 2015-12-20 * Acceptance notifications: 2015-12-24 Practical = * The duration for talks will be 30 minutes, including presentations and questions and answers. * Presentation can be recorded and streamed, sending your proposal implies giving permission to be recorded. * A mailing list for the Python devroom is available for discussions about devroom organisation. You can register at this address: https://lists.fosdem.org/listinfo/python-devroom How to submit = All submissions are made in the Pentabarf event planning tool at https://penta.fosdem.org/submission/FOSDEM16 When submitting your talk in Pentabarf, make sure to select the Python devroom as the Track. Of course, if you already have a user account, please reuse it. Questions = Any questions, please sned an email to info AT python-fosdem DOT org Thank you for submitting your sessions and see you soon in Brussels to talk about Python. If you want to keep informed for this edition, you can follow our twitter account @PythonFOSDEM. * FOSDEM 2016: https://fosdem.org/2016 * Python Devroom: http://python-fosdem.org * Twitter: https://twitter.com/PythonFOSDEM Thank you so much, Stephane -- Stéphane Wirtel - http://wirtel.be - @matrixise ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Asynchronous context manager in a typical network server
On 18.12.2015 22:09, Guido van Rossum wrote:
I guess we could make the default arg to sleep() 1e9. Or make it None
and special-case it. I don't feel strongly about this -- I'm not sure
how baffling it would be to accidentally leave out the delay and find
your code sleeps forever rather than raising an error (since if you
don't expect the infinite default you may not expect this kind of
behavior). But I do feel it's not important enough to add a new
function or method.
Why still guessing the best surrogate for infinity?
Seems like python is just missing int('inf'). :/
Best,
Sven
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Asynchronous context manager in a typical network server
On Fri, Dec 18, 2015 at 4:09 PM, Guido van Rossum wrote: > >> It's 11 days. Which is pretty reasonable server uptime. >> > > Oops, blame the repr() of datetime.timedelta. I'm sorry I so rashly > thought I could do better than the OP. > A helpful trivia: a year is approximately π times 10 million seconds. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)
On Mon, Dec 21, 2015 at 9:02 AM, Alexander Belopolsky wrote: > On Fri, Dec 18, 2015 at 4:09 PM, Guido van Rossum wrote: >>> >>> >>> It's 11 days. Which is pretty reasonable server uptime. >> >> >> Oops, blame the repr() of datetime.timedelta. I'm sorry I so rashly >> thought I could do better than the OP. > > > A helpful trivia: a year is approximately π times 10 million seconds. Sadly doesn't help here, as the timedelta for a number of years looks like this: >>> datetime.timedelta(days=365*11) datetime.timedelta(4015) Would there be value in changing the repr to use keyword arguments? Positional arguments might well not correspond to the way they were created, and unless you happen to know what the fields mean, they're a little obscure: >>> datetime.timedelta(weeks=52,minutes=1488) datetime.timedelta(365, 2880) Worse, help(datetime.timedelta) in 3.6 doesn't document the constructor at all. There's no mention of __init__ at all, __new__ has this useless information: | __new__(*args, **kwargs) from builtins.type | Create and return a new object. See help(type) for accurate signature. and aside from there being three data descriptors, there's nothing to suggest that you construct these things with timedelta(days, seconds, microseconds). Definitely no indication that you can use other keyword args. Is this something worth fixing, or is it acceptable to drive people to fuller documentation than help()? ChrisA ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)
On Sun, Dec 20, 2015 at 2:28 PM, Chris Angelico wrote: > On Mon, Dec 21, 2015 at 9:02 AM, Alexander Belopolsky > wrote: > > On Fri, Dec 18, 2015 at 4:09 PM, Guido van Rossum > wrote: > >>> > >>> > >>> It's 11 days. Which is pretty reasonable server uptime. > >> > >> > >> Oops, blame the repr() of datetime.timedelta. I'm sorry I so rashly > >> thought I could do better than the OP. > > > > > > A helpful trivia: a year is approximately π times 10 million seconds. > > Sadly doesn't help here, as the timedelta for a number of years looks like > this: > > >>> datetime.timedelta(days=365*11) > datetime.timedelta(4015) > > Would there be value in changing the repr to use keyword arguments? > Positional arguments might well not correspond to the way they were > created, and unless you happen to know what the fields mean, they're a > little obscure: > > >>> datetime.timedelta(weeks=52,minutes=1488) > datetime.timedelta(365, 2880) > > Worse, help(datetime.timedelta) in 3.6 doesn't document the > constructor at all. There's no mention of __init__ at all, __new__ has > this useless information: > > | __new__(*args, **kwargs) from builtins.type > | Create and return a new object. See help(type) for accurate > signature. > > and aside from there being three data descriptors, there's nothing to > suggest that you construct these things with timedelta(days, seconds, > microseconds). Definitely no indication that you can use other keyword > args. > > Is this something worth fixing, or is it acceptable to drive people to > fuller documentation than help()? > That fix occurred to me too. However, I didn't propose it, since it's always a little easy to blame one's own mistakes on the software. Still, I can't be the only one to ever have been fooled by this, and it is definitely pretty arcane knowledge what the positional arguments to timedelta(). I'm just curious on the backward compatibility impact. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)
On Sun, Dec 20, 2015 at 3:05 PM, Emanuel Barry wrote: > From: [email protected] > > > I'm just curious on the backward compatibility impact. > > I'm just curious on the number of programs depending on the repr() of any > object at all in production (not counting tests). I could be wrong, but it > seems foolish to rely on that, especially since this is something that we > *can* change on an (almost) arbitrary basis. IMO, the repr() is meant to > aid the programmer - not specifying keyword arguments here does quite the > opposite of that :) > Not sure if you meant that as a rhetorical question or sarcastically. While you're right that ideally changing the repr() of an object shouldn't affect production work, in practice it can break any number of things, for example over-specified unit tests or poor integrations that end up parsing the string (perhaps in a different language than Python). We've encountered such issues many times in the past (for example, massive doctest breakage when we randomized the string hash) so we have to at least consider the possibility. In this case I expect there will be little effect, but it doesn't hurt asking around -- who knows what someone reading this remembers (besides asking pedantic questions :-). -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)
On Sun, Dec 20, 2015 at 5:28 PM, Chris Angelico wrote: > > A helpful trivia: a year is approximately π times 10 million seconds. > > Sadly doesn't help here, as the timedelta for a number of years looks like > this: > > >>> datetime.timedelta(days=365*11) > datetime.timedelta(4015) > > The original issue was how long is a million seconds. The bit of trivia that I suggested helps to establish that it cannot be a multiple of years. > Would there be value in changing the repr to use keyword arguments? > I don't think translating from seconds to years will be any simpler with any alternative repr, but I would really like to see a change in the repr of negative timedeltas: >>> timedelta(minutes=-1) datetime.timedelta(-1, 86340) And str() is not much better: >>> print(timedelta(minutes=-1)) -1 day, 23:59:00 The above does not qualify as a human readable representation IMO. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)
From: [email protected] Date: Sun, 20 Dec 2015 14:33:46 -0800 To: [email protected] Subject: Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server) CC: [email protected] > I'm just curious on the backward compatibility impact. I'm just curious on the number of programs depending on the repr() of any object at all in production (not counting tests). I could be wrong, but it seems foolish to rely on that, especially since this is something that we *can* change on an (almost) arbitrary basis. IMO, the repr() is meant to aid the programmer - not specifying keyword arguments here does quite the opposite of that :) > > -- > --Guido van Rossum (python.org/~guido) -Emanuel ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/vgr255%40live.ca ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)
Half-rhetorical half-genuine; you know better than me the history of breakage due to such changes, anyway. I can't really think of anything you haven't, so I'll just sit back. From: [email protected] Date: Sun, 20 Dec 2015 15:15:25 -0800 Subject: Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server) To: [email protected] CC: [email protected]; [email protected] On Sun, Dec 20, 2015 at 3:05 PM, Emanuel Barry wrote: From: [email protected] > I'm just curious on the backward compatibility impact. I'm just curious on the number of programs depending on the repr() of any object at all in production (not counting tests). I could be wrong, but it seems foolish to rely on that, especially since this is something that we *can* change on an (almost) arbitrary basis. IMO, the repr() is meant to aid the programmer - not specifying keyword arguments here does quite the opposite of that :) Not sure if you meant that as a rhetorical question or sarcastically. While you're right that ideally changing the repr() of an object shouldn't affect production work, in practice it can break any number of things, for example over-specified unit tests or poor integrations that end up parsing the string (perhaps in a different language than Python). We've encountered such issues many times in the past (for example, massive doctest breakage when we randomized the string hash) so we have to at least consider the possibility. In this case I expect there will be little effect, but it doesn't hurt asking around -- who knows what someone reading this remembers (besides asking pedantic questions :-). -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)
On Mon, Dec 21, 2015 at 12:00 PM, Alexander Belopolsky
wrote:
> On Sun, Dec 20, 2015 at 5:28 PM, Chris Angelico wrote:
>>
>> > A helpful trivia: a year is approximately π times 10 million seconds.
>>
>> Sadly doesn't help here, as the timedelta for a number of years looks like
>> this:
>>
>> >>> datetime.timedelta(days=365*11)
>> datetime.timedelta(4015)
>>
>
> The original issue was how long is a million seconds. The bit of trivia
> that I suggested helps to establish that it cannot be a multiple of years.
Ah, true. Still, it would deal with the confusion here, which I think
is what Guido was referring to:
>>> datetime.timedelta(seconds=100)
datetime.timedelta(11, 49600)
It's eleven somethings and some loose change. What if it came out like
this, instead?
>>> datetime.timedelta(seconds=100)
datetime.timedelta(days=11, seconds=49600)
Much more obviously eleven and a half days.
>> Would there be value in changing the repr to use keyword arguments?
>
>
> I don't think translating from seconds to years will be any simpler with any
> alternative repr...
A timedelta can't actually cope with years, per se, but for
back-of-the-envelope calculations, 1000 days = 3 years (and round
down).
>>> datetime.timedelta(seconds=1e9)
datetime.timedelta(11574, 6400)
A billion seconds is thirty-odd years. That's about as good as
timedelta's ever going to do for us. Changing the repr won't change
this at all, except that it'll be obvious that the 11K figure is
measured in days.
> but I would really like to see a change in the repr of
> negative timedeltas:
>
timedelta(minutes=-1)
> datetime.timedelta(-1, 86340)
>
> And str() is not much better:
>
print(timedelta(minutes=-1))
> -1 day, 23:59:00
>
> The above does not qualify as a human readable representation IMO.
There are two plausible ways of describing negative intervals.
1) Show the largest unit in negative, and all others in positive.
2) Take the absolute value, generate a repr, and then stick a hyphen in front.
If Python picks the former, you can easily request the latter:
ZERO = datetime.timedelta(0)
def display(td):
if td < 0: return "-"+repr(-td)
return repr(td)
The converse isn't as easy. And both formats maintain certain
invariants; the second has invariants regarding the magnitude of the
delta (a movement of less than one day will never include the word
'day'), but the first has the rather useful invariant that arithmetic
on datetimes doesn't affect units smaller than those changed:
>>> td = datetime.timedelta(minutes=75)
>>> td + datetime.timedelta(days=1)
datetime.timedelta(1, 4500)
>>> td + datetime.timedelta(days=-1)
datetime.timedelta(-1, 4500)
Also, it's consistent with the way Python handles modulo arithmetic
elsewhere. If you think of a timedelta as a number of microseconds,
the partitioning into days and seconds follows the normal rules for
divmod with 86400 and 100.
Yes, it looks a little strange in isolation, but I think it's
justifiable for the .days, .seconds, .microseconds attributes. Should
repr switch the display around? Perhaps, but I'm highly dubious.
Should str? That's a bit more plausible - but since both formats are
justifiable, I'd be more inclined to separate it out; or maybe do this
in __format__ as an alternative formatting style:
>>> class timedelta(datetime.timedelta):
... def __format__(self, fmt):
... if fmt == "-" and self.total_seconds() < 0:
... return "-" + str(-self)
... return str(self)
...
>>> td=timedelta(minutes=-1)
>>> f"Default: {td} By magnitude: {td:-}"
'Default: -1 day, 23:59:00 By magnitude: -0:01:00'
ChrisA
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)
On Sun, Dec 20, 2015 at 5:00 PM, Alexander Belopolsky < [email protected]> wrote: > > On Sun, Dec 20, 2015 at 5:28 PM, Chris Angelico wrote: > >> > A helpful trivia: a year is approximately π times 10 million seconds. >> >> Sadly doesn't help here, as the timedelta for a number of years looks >> like this: >> >> >>> datetime.timedelta(days=365*11) >> datetime.timedelta(4015) >> >> > The original issue was how long is a million seconds. The bit of trivia > that I suggested helps to establish that it cannot be a multiple of years. > But it's entirely arbitrary, which makes it not that easy to remember. > Would there be value in changing the repr to use keyword arguments? >> > > I don't think translating from seconds to years will be any simpler with > any alternative repr, > Well it would have saved me an embarrassing moment -- I typed `datetime.timedelta(seconds=1e6)` at the command prompt and when the response came as `datetime.timedelta(11, 49600)` I mistook that as 11 years (I was in a hurry and trying hard not to have to think :-). > but I would really like to see a change in the repr of negative timedeltas: > > >>> timedelta(minutes=-1) > datetime.timedelta(-1, 86340) > > And str() is not much better: > > >>> print(timedelta(minutes=-1)) > -1 day, 23:59:00 > > The above does not qualify as a human readable representation IMO. > 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 < 100 0 <= seconds < 60 (There is no such invariant for days -- they hold the sign bit.) In essence, you'd have to look at all three attributes to figure out on which side of 0 is was (or think of the right way to do it, which is to compare to timedelta(0)). I might still go for it, if it wasn't too late by over a decade (as Tim says). -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [OT] Without thinking! [was: Change the repr for datetime.timedelta]
Guido van Rossum writes: > (I was in a hurry and trying hard not to have to think :-). That makes me feel much better! There *are* things that *aren't* obvious, even to those born Dutch! :-) Happy Holidays! ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)
[Alexander Belopolsky] >> ... >> but I would really like to see a change in the repr of negative >> timedeltas: >> >> >>> timedelta(minutes=-1) >> datetime.timedelta(-1, 86340) >> >> And str() is not much better: >> >> >>> print(timedelta(minutes=-1)) >> -1 day, 23:59:00 >> >> The above does not qualify as a human readable representation IMO. [Guido] > 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 < 100 > 0 <= seconds < 60 > > (There is no such invariant for days -- they hold the sign bit.) > > In essence, you'd have to look at all three attributes to figure out on > which side of 0 is was (or think of the right way to do it, which is to > compare to timedelta(0)). I might still go for it, if it wasn't too late by > over a decade (as Tim says). Seems timedelta is over-specified, yes? For example, those invariants apply to CPython's internal representation, but have no direct effect on the set of representable timedeltas, and the constructor couldn't care less about them (other than to bash its inputs into those ranges; BTW, note that the invariant on `seconds` is actually < 86400, not < 60); e.g., >>> datetime.timedelta(days=1, seconds=100, microseconds=-3847384738473) datetime.timedelta(-32, 3815, 261527) So perhaps it would be better to document the practical truth ;-) That is, a timedelta is an integer number of microseconds in range(-86399136, 8640) and all the rest is just more-or-less artificial complication due to choosing to _represent_ that range in a funky mixed-radix days/seconds/microseconds format. For >>> print(timedelta(minutes=-1)) I'd like to see: -00:01:00 But I wouldn't change repr() - the internal representation is fully documented, and it's appropriate for repr() to reflect documented internals as directly as possible. Spelling out the units with keyword days/seconds/microseconds arguments would be fine, though. If I had it to do over, I'd _require_ keyword arguments on timedelta(). I don't know how often I've seen, e.g., timedelta(1), and didn't remember that "the first" argument is fortnights ;-) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)
On Sun, Dec 20, 2015 at 9:00 PM, Guido van Rossum wrote: > but I would really like to see a change in the repr of negative timedeltas: >> >> >>> timedelta(minutes=-1) >> datetime.timedelta(-1, 86340) >> >> And str() is not much better: >> >> >>> print(timedelta(minutes=-1)) >> -1 day, 23:59:00 >> >> The above does not qualify as a human readable representation IMO. >> > > 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 > I don't see why we have to change td.days for say td = timedelta(minutes=-1) if we change its repr to "timedelta(minutes=-1)". For me an important invariant is td == eval(repr(td)) which will be preserved. > -- 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 < 100 > 0 <= seconds < 60 > > (There is no such invariant for days -- they hold the sign bit.) > > In essence, you'd have to look at all three attributes to figure out on > which side of 0 is was (or think of the right way to do it, which is to > compare to timedelta(0)). I might still go for it, if it wasn't too late by > over a decade (as Tim says). > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)
On Sun, Dec 20, 2015 at 10:25 PM, Tim Peters wrote: > For > > >>> print(timedelta(minutes=-1)) > > I'd like to see: > > -00:01:00 > > But I wouldn't change repr() - the internal representation is fully > documented, and it's appropriate for repr() to reflect documented > internals as directly as possible. > Note that in the case of float repr, the consideration of user convenience did win over "reflect documented internals as directly as possible." ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)
[Tim] >> But I wouldn't change repr() - the internal representation is fully >> documented, and it's appropriate for repr() to reflect documented >> internals as directly as possible. [Alex] > Note that in the case of float repr, the consideration of user convenience > did win over "reflect documented internals as directly as possible." ? Nothing is documented about float internals, beyond "whatever a platform C double is" in CPython. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)
On Sun, Dec 20, 2015 at 7:25 PM, Alexander Belopolsky < [email protected]> wrote: > > On Sun, Dec 20, 2015 at 9:00 PM, Guido van Rossum > wrote: > >> but I would really like to see a change in the repr of negative >>> timedeltas: >>> >>> >>> timedelta(minutes=-1) >>> datetime.timedelta(-1, 86340) >>> >>> And str() is not much better: >>> >>> >>> print(timedelta(minutes=-1)) >>> -1 day, 23:59:00 >>> >>> The above does not qualify as a human readable representation IMO. >>> >> >> 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 >> > > I don't see why we have to change td.days for say td = > timedelta(minutes=-1) if we change its repr to "timedelta(minutes=-1)". > For me an important invariant is td == eval(repr(td)) which will be > preserved. > Then please just trust me. If the repr() shows different numbers than the attributes things are worse than now. People will casually look at the repr() and assume they've seen what the attributes will return, and spend hours debugging code that relies on that incorrect assumption. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [RELEASED] Python 3.4.4 is now available
On behalf of the Python development community and the Python 3.4 release team, I'm pleased to announce the availability of Python 3.4.4. Python 3.4.4 is the last version of Python 3.4.4 with binary installers, and the end of "bugfix" support. After this release, Python 3.4.4 moves into "security fixes only" mode, and future releases will be source-code-only. You can see what's changed in Python 3.4.4 (as compared to previous versions of 3.4) here: https://docs.python.org/3.4/whatsnew/changelog.html#python-3-4-4 And you can download Python 3.4.4 here: https://www.python.org/downloads/release/python-344/ Windows and Mac users: please read the important platform-specific "Notes on this release" section near the end of that page. One final note. 3.4.4 final marks the end of an era: it contains the last Windows installers that will be built by Martin von Loewis. Martin has been the Windows release "Platform Expert" since the Python 2.4 release cycle started more than twelve years ago--in other words, for more than half of Python's entire existence! On behalf of the Python community, and particularly on behalf of the Python release managers, I'd like to thank Martin for his years of service to the community, and for the care and professionalism he brought to his role. It was a pleasure working with him, and we wish him the very best in his future projects. We hope you enjoy Python 3.4.4! Happy holidays, //arry/ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
