Mailman 3 April 2015 - Python-Dev

Re: [Python-Dev] Status on PEP-431 Timezones
by Isaac Schwabacher April 9, 2015

April 9, 2015

On 15-04-08, Alexander Belopolsky wrote: > > On Wed, Apr 8, 2015 at 6:52 PM, Isaac Schwabacher <ischwabacher(a)wisc.edu <ischwabacher(a)wisc.edu>> wrote: > > > > > So "storing the offset" and "storing a flag" are not two alternative solutions to the same problem- these > > > are two solutions to two different problems. > > > > I'm viewing a time zone as a map from UTC to local time; for example, America/Chicago is a time zone. I'm not … [View More]proposing storing the offset as an alternative to storing the *time zone*, I'm proposing it as an alternative to storing whether a given time is DST or not. > > When you are proposing to store something, you also need to specify where you are proposing to store it. In the current design, local time information is stored in the datetime object and the rules that govern UTC to local mapping (and back) are stored in the tzinfo object. The implementors of concrete tzinfo subclasses are supposed to have access to time zone rules and implement utcoffset(dt), together with dst(dt) and tzname(dt) methods. > > Storing isdst in the datetime object would allow utcoffset(dt) to distinguish between 1:30AM before clock change and 1:30AM after. Where do you propose to store the offset? I propose to add an offset field to datetime.datetime. It should be set precisely when the tz field is set, and it should contain either a timedelta or an integer number of (possibly fractional) seconds, depending on what color the bikeshed gets painted. This is, IIUC, precisely where Lennart is proposing to store the is_dst flag. I just looked through the datetime documentation, and it looks like the currently blessed way of creating an aware datetime from a naive local datetime and a tzinfo is datetime.replace, which is too low level to handle the job. This method will either need to grow some validation, or there will need to be a tzinfo.localize(localtime, is_dst) method as well. > If you store it in dt, why would you need the tzinfo? You can't do arithmetic without a time zone. Which is to say, if you try to do arithmetic without a time zone, you're implicitly doing it in a fixed offset time zone. So there's no way to disambiguate between "2013-11-03 01:30:00-0500 America/Chicago" + "1 hour" = "2013-11-03 01:30:00-0600 America/Chicago" and "2013-11-03 01:30:00-0500 America/New_York" + "1 hour" = "2013-11-03 02:30:00-0500 America/New_York". > > We really don't care whether a time is DST or not; > > You may not care about it, but current tzinfo interface and tzinfo.fromutc(dt) method do. Whatever new features are added to the standard library, they cannot break existing uses. This means that whatever concrete tzinfo implementations we add to stdlib, they must provide an implementation of tzinfo.dst(dt) method. I don't really mean we don't care; I mean that it's not close to orthogonal to the other things we care about in the way that local time and UTC time are. You'll never ask for *just* the DST flag. So making you look up in zoneinfo whether a given (localtime, offset, tzinfo) triple represents DST or STD is not as onerous, because if you used the other representation, you'd still be looking in zoneinfo for some other piece of information that the user asked for at the same time. So we implement the datetime.astimezone() > > So our times would look like "2013-11-03 01:30:00-0500 America/Chicago" and an hour later, "2013-11-03 01:30:00-0600 America/Chicago". And all of that information is stored in the datetime object. > > I don't think this is what most people would expect > > $ TZ=America/Chicago date > Wed Apr 8 18:26:01 CDT 2015 > > or > > $ TZ=America/Chicago date +"%c %z" > Wed 08 Apr 2015 06:27:09 PM CDT -0500 > > and not have location as a part of their timestamps. > Regardless, whatever the proposal to add timezones to stdlib will end up being, it must include the ability to implement an equivalent of UNIX date command shown above. Sorry, I meant that to show off the internal representation, rather than intending it as the literal string representation. But I *do* think that the right representation of a time zone-aware time is (localtime, offset, tzinfo), and the __repr__ should reflect that. Anyone who wants "CDT" instead of "-0500 America/Chicago" is talking to a human instead of a computer and should use strftime. ijs [View Less]

2 2

Re: [Python-Dev] Status on PEP-431 Timezones
by Isaac Schwabacher April 9, 2015

April 9, 2015

On 15-04-08, Alexander Belopolsky wrote: > > On Wed, Apr 8, 2015 at 3:57 PM, Isaac Schwabacher <ischwabacher(a)wisc.edu <ischwabacher(a)wisc.edu>> wrote: > > > > On 15-04-08, Lennart Regebro wrote: > > > === Stdlib option 2: A datetime _is_dst flag === > > > > > > By having a flag on the datetime instance that says "this is in DST or not" > > > the timezone implementation can be kept simpler. > > > > Storing the … [View More]offset itself instead of a flag makes things conceptually cleaner. > > It is important to distinguish two notions that unfortunately both called a "time zone." For lack > of better terms, let me define "named offsets" and "locations" as follows: > > A "named offset" is an abbreviation such as UTC, EST, MSK, MSD which (at any given time) > corresponds to a fixed offset from UTC. Since at different historical times, the same abbreviation > such as MSK may correspond to a different offset, you cannot always derive one from another > and extended struct tm provides fields for both: tm_gmtoff and tm_zone. > > A location is a name of geographical entity such as America/New_York which follows the sametimekeeping rules. > > > The isdst flag is necessary when you know the location and local time and want to find out the > corresponding UTC time. In many locations, there is one our every year when knowing local > time is not enough because the same local time corresponds to two different UTC times. > > > This happens in the US when we move the clock back one hour some day in the Fall. UTC time > marches on, but local time repeats the same hour. So in order to know what 01:30 AM is in New York, > you also need to know whether it is before we moved the clocks back or after. > > So "storing the offset" and "storing a flag" are not two alternative solutions to the same problem- these > are two solutions to two different problems. I'm viewing a time zone as a map from UTC to local time; for example, America/Chicago is a time zone. I'm not proposing storing the offset as an alternative to storing the *time zone*, I'm proposing it as an alternative to storing whether a given time is DST or not. We really don't care whether a time is DST or not; we care about the local time and the offset, and we need the time zone because otherwise we can't relate our time to other times. So our times would look like "2013-11-03 01:30:00-0500 America/Chicago" and an hour later, "2013-11-03 01:30:00-0600 America/Chicago". And all of that information is stored in the datetime object. > .. > > On 15-04-08, Alexander Belopolsky wrote: > > > With datetime, we also have a problem that POSIX APIs don't have to deal with: local time > > > arithmetics. What is t + timedelta(1) when t falls on the day before DST change? How would > > > you set the isdst flag in the result? > > > > It's whatever time comes 60*60*24 seconds after t in the same time zone, because the timedelta class isn't expressive enough to represent anything but absolute time differences (nor should it be, IMO). > > This is not what most uses expect. The expect > > datetime(y, m, d, 12, tzinfo=New_York) + timedelta(1) > > to be > > datetime(y, m, d+1, 12, tzinfo=New_York) The current definition of datetime.timedelta doesn't allow any reasonable definition of datetime(2013, 11, 3, 23, 30, tz=zoneinfo('America/Chicago')) - datetime(2013, 11, 3, 0, 30, tz=zoneinfo('America/Chicago')) other than timedelta(1) because the seconds field is not allowed to be more than 60*60*24. ijs [View Less]

4 4

PEP 8 update
by Guido van Rossum April 8, 2015

April 8, 2015

I've taken the liberty of adding the following old but good rule to PEP 8 (I was surprised to find it wasn't already there since I've lived by this for ages): - Be consistent in return statements. Either all return statements in a function should return an expression, or none of them should. If any return statement returns an expression, any return statements where no value is returned should explicitly state this as return None, and an explicit return statement should be … [View More]

7 8

Build is broken for me after updating
by Neil Girdhar April 7, 2015

April 7, 2015

Ever since I updated, I am getting: In file included from Objects/dictobject.c:236:0: Objects/clinic/dictobject.c.h:70:26: fatal error: stringlib/eq.h: No such file or directory #include "stringlib/eq.h" But, Objects/stringlib/eq.h exists. Replacing the include with "Objects/stringlib/eq.h" seems to make this error go away, but others follow. Would anyone happen to know why this is happening? Neil

1 0

Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)
by PJ Eby April 6, 2015

April 6, 2015

On Thu, Apr 2, 2015 at 1:42 PM, PJ Eby <pje(a)telecommunity.com> wrote: > If the PEP 487 metaclass library, > however, were to just port some bits of my code to Python 3 this could > be a done deal already and available in *all* versions of Python 3, > not just the next one. Just for the heck of it, here's an actual implementation and demo of PEP 487, that I've tested with 3.1, 3.2, and 3.4 (I didn't have a copy of 3.3 handy): https://gist.github.com/pjeby/… [View More]

6 21

Re: [Python-Dev] [Python-checkins] Daily reference leaks (e10ad4d4d490): sum=333
by Brett Cannon April 4, 2015

April 4, 2015

Anyone know what is causing the deque leakage? On Sat, Apr 4, 2015, 04:48 <solipsis(a)pitrou.net> wrote: > results for e10ad4d4d490 on branch "default" > -------------------------------------------- > > test_collections leaked [0, -4, 0] references, sum=-4 > test_collections leaked [0, -2, 0] memory blocks, sum=-2 > test_deque leaked [91, 91, 91] references, sum=273 > test_deque leaked [21, 21, 21] memory blocks, sum=63 > test_functools leaked [0, 0, 3] memory … [View More]

3 2

Socket timeout: reset timeout at each successful syscall?
by Victor Stinner April 4, 2015

April 4, 2015

Hi, I reworked the socket and ssl modules to better handle signals (to implement the PEP 475, retry on EINTR). These changes require to recompute timeout because syscalls are calling in a loop until it doesn't with EINTR (or EWOULDBLOCK or EGAIN). Most socket methods exit when the underlying syscall succeed. The problem is that the socket.sendall() method may require multiple syscalls. In this case, does the timeout count for the total time or only for a single syscall? Asked differently: … [View More]

3 4

Installing Python from the source code on Windows
by Narsu April 4, 2015

April 4, 2015

Hi Python I'm working on a game project,using c++ as main language, and using python as script.I've built the Python from the source code on Windows, and when I invoked method Py_Initialize my program exited. After some tests I realized as long as I move the Python-2.7.9/Lib file to my program file, it works fine. Please help me out . Thank you for your time. Narsu‍

2 1

Summary of Python tracker Issues
by Python tracker April 3, 2015

April 3, 2015

ACTIVITY SUMMARY (2015-03-27 - 2015-04-03) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 4838 (+19) closed 30782 (+50) total 35620 (+69) Open issues with patches: 2252 Issues opened (52) ================== #23466: PEP 461: Inconsistency between str and bytes formatting of int http://bugs.python.org/issue23466 reopened by ethan.furman #23752: … [View More]

1 0

version of freshly built 2.7 python
by Ethan Furman April 3, 2015

April 3, 2015

I just built the latest version of Python 2.7 on my development machine -- or so I thought. When I invoke it, I get: Python 2.7.6+ (2.7:1beb3e0507fa, Apr 2 2015, 17:57:53) Why am I not seeing 2.7.9? -- ~Ethan~

4 5