Re: [Python-Dev] Add aware local time support to datetime module
On Wed, Aug 4, 2010 at 19:46, Alexander Belopolsky
wrote:
> [I've got no response from python-ideas, so I am forwarding to python-dev.]
>
> With addition of fixed offset timezone class and the timezone.utc
> instance [0], it is easy to get UTC time as an aware datetime
> instance:
>
datetime.now(timezone.utc)
> datetime.datetime(2010, 8, 3, 14, 16, 10, 670308,
> tzinfo=datetime.timezone.utc)
>
> However, if you want to keep time in your local timezone, getting an
> aware datetime is almost a catch 22. If you know your timezone UTC
> offset, you can do
>
EDT = timezone(timedelta(hours=-4))
datetime.now(EDT)
> datetime.datetime(2010, 8, 3, 10, 20, 23, 769537,
> tzinfo=datetime.timezone(datetime.timedelta(-1, 72000)))
>
> but the problem is that there is no obvious or even correct way to
> find local timezone UTC offset. [1]
>
> In a comment on issue #5094 ("datetime lacks concrete tzinfo
> implementation for UTC"), I proposed to address this problem in a
> localtime([t]) function that would return current time (or time
> corresponding to the optional datetime argument) as an aware datetime
> object carrying local timezone information in a tzinfo set to an
> appropriate timezone instance. This solution is attractive by its
> simplicity, but there are several problems:
>
> 1. An aware datetime cannot carry all information that system
> localtime() supplies in a time tuple. Specifically, the is_dst flag
> is lost. This is not a problem for most applications as long as
> timezone UTC offset and timezone name are available, but may be an
> issue when interoperability with the time module is required.
>
> 2. Datetime's tzinfo interface was designed with the idea that
> <2010-11-06 12:00 EDT> + <1 day> = <2010-11-07 12:00 EST>, not
> <2010-11-07 12:00 EDT>. It other words, if I have lunch with someone
> at noon (12:00 EDT) on Saturday the day before first Sunday in
> November, and want to meet again "at the same time tomorrow", I mean
> 12:00 EST, not 24 hours later. With localtime() returning datetime
> with tzinfo set to fixed offset timezone, however, localtime() +
> timedelta(1) will mean exactly 24 hours later and the result will be
> expressed in an unusual for the given location timezone.
>
> An alternative approach is the one recommended in the python manual.
> [3] One could implement a LocalTimezone class with utcoffset(),
> tzname() and dst() extracting information from system mktime and
> localtime calls. This approach has its own shortcomings:
>
> 1. While adding integral number of days to datetimes in business
> setting, it is natural to expect automatic timezone adjustments, it is
> not as clearcut when adding hours or minutes.
>
> 2. The tzinfo.utcoffset() interface that expects *standard* local time
> as an argument is confusing to many users. Even the "official"
> example in the python manual gets it wrong. [4]
>
> 3. datetime(..., tzinfo=LocalTimezone()) is ambiguous during the
> "repeated hour" when local clock is set back in DST to standard time
> transition.
>
> As far as I can tell, the only way to resolve the last problem is to
> add is_dst flag to the datetime object, which would also be the
> only way to achieve full interoperability between datetime objects and
> time tuples. [5]
>
> The traditional answer to call for improvement of timezone support in
> datetime module has been: "this is upto 3rd parties to implement."
> Unfortunately, stdlib is asking 3rd parties to implement an impossible
> interface without giving access to the necessary data. The
> impossibility comes from the requirement that dst() method should find
> out whether local time represents DST or standard time while there is
> an hour each year when the same local time can be either. The missing
> data is the system UTC offset when it changes historically. The time
> module only gives access to the current UTC offset.
>
> My preference is to implement the first alternative - localtime([t])
> returning aware datetime with fixed offset timezone. This will solve
> the problem of python's lack of access to the universally available
> system facilities that are necessary to implement any kind of aware
> local time support.
For all of the reasons you give above, I think it's a bad idea. :-)
You need a proper time zone database to solve these issues, like pytz.
Which incidentally solves the ambiguity problem as well. so the
solution is pytz. :-)
What pytz doesn't have (but dateutil.tz does) is a timezone object
that uses the operating systems local timezone data, like
/etc/localzone on unix. That could be interesting to include,
possibly. Having a fixed time zone offset object for the localtime
seems a bad idea. The problem it solves is easy to get around, but the
problems created are not.
--
Lennart Regebro, Colliberty: http://www.colliberty.com/
Python, Zope, Plone blog: http://regebro.wordpress.com/
Telephone: +33 661 58 14 64
___
Python-Dev ma
Re: [Python-Dev] mingw support?
Am 08.08.2010 03:27, schrieb Greg Ewing: > Nick Coghlan wrote: > >> This used to be more of an issue because MS didn't provide a decent >> free compiler for their platform. These days (since the release of >> Visual Studio Express), we expect that people willing to use (or >> support) a closed OS can cope with also using the free-as-in-beer >> closed compiler provided by the vendor of that OS. > > The problem with the MS "free" compilers is that it's only a > *temporary* freedom. They have a habit of withdrawing older > versions when newer ones become available. Together with their > other obnoxious habit of changing the C runtime in incompatible > ways with every release, the result is that extensions for > versions of Python older than N years can no longer be compiled > with any legally-available free MS compiler. However, this is out of scope for the question at hand. Compiling extensions with mingw is fairly well supported, and people contribute small patches when it breaks. The OP was asking for compilation of Python itself with mingw, for which this MS policy hasn't caused problems - I do have all the compilers available to me that I need to do that. Indeed, MSDN subscribers can still access older compiler versions for quite some time after Microsoft stopped otherwise distributing the product. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw support?
-On [20100808 02:23], Nick Coghlan ([email protected]) wrote: >This used to be more of an issue because MS didn't provide a decent >free compiler for their platform. These days (since the release of >Visual Studio Express), we expect that people willing to use (or >support) a closed OS can cope with also using the free-as-in-beer >closed compiler provided by the vendor of that OS. You don't even need VS Express. Install Windows SDK 7.1 and the compilers are supplied with it. Less clutter if you prefer the command line. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Without a soul there can be no understanding between the heart and the mind. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw support?
On Mon, Aug 9, 2010 at 1:55 AM, Jeroen Ruigrok van der Werven wrote: > -On [20100808 02:23], Nick Coghlan ([email protected]) wrote: >>This used to be more of an issue because MS didn't provide a decent >>free compiler for their platform. These days (since the release of >>Visual Studio Express), we expect that people willing to use (or >>support) a closed OS can cope with also using the free-as-in-beer >>closed compiler provided by the vendor of that OS. > > You don't even need VS Express. > > Install Windows SDK 7.1 and the compilers are supplied with it. Less clutter > if you prefer the command line. MS may have improved the tools they release with the SDK to the point where they can build a VS solution file (I haven't tried that in years). Historically (i.e. before the first express version of Visual Studio), there were a lot of hoops to jump through to get something that could handle the complete build chain. It was painful enough back when I first started hacking on the Python core that I gave up and just switched to developing on Linux instead. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw support?
-On [20100808 18:29], Nick Coghlan ([email protected]) wrote: >MS may have improved the tools they release with the SDK to the point >where they can build a VS solution file (I haven't tried that in >years). From my quick glance of what the current SDK installs that does to seem to be the case. I have not tried it myself (yet). -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B You yourself, as much as anybody in the entire universe, deserve your love and affection... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw support?
On 8/7/2010 3:55 PM, [email protected] wrote: Dear list, I was wondering whether there would ever be support for python to be build by the mingw compiler suite. I found a few patches in the internet but there were disagreeing comments on whether they are functional or not. So I would like to ask the list whether there are any technical reasons that this is so. The sociological problem is that currently not enough advocates of using a free-as-in-thought compiler both can and will provide enough free-as-in-beer volunteer time to deal with the sociological and technical problems. That could change someday. I suspect that the persons who first ported Python to MSDOS simply used what they were used to using, perhaps in their paid job. And I am sure that is still true of at least some of the people doing Windows support today. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Was Tracker Summary sent Fri Aug 6?\
The usual Friday Summary of Python Trackers Issues did not appear on Gmane. Was one generated? Or did it just fail to make it to gmane? I use to to review new issues, so even late would be better than never. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Was Tracker Summary sent Fri Aug 6?\
Am 08.08.2010 22:03, schrieb Terry Reedy: > The usual Friday Summary of Python Trackers Issues did not appear on > Gmane. Was one generated? Sending it failed due to a hard disk problem. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Return code when there's a problem at shutdown
Hello, In issue #5319, the poster complains that redirecting stdout to a misbehaving (pseudo-)file such as /dev/full should produce a non-zero error code when the IO error happens at shutdown (when calling flush() on stdout). Is it a reasonable expectation? What would you think of making the change? (it would require giving a return value to Py_Finalize(), which currently returns nothing) Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r83860 - python/branches/py3k/Python/_warnings.c
2010/8/8 victor.stinner : > Author: victor.stinner > Date: Mon Aug 9 00:12:45 2010 > New Revision: 83860 > > Log: > Issue #9425: fix setup_context() for non-ascii filenames Test? -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw support?
Terry Reedy: > I suspect that the persons who first ported Python to MSDOS simply used what > they were used to using, perhaps in their paid job. And I am sure that is > still true of at least some of the people doing Windows support today. Some Windows developers actually prefer Visual Studio, including me. MingW has become less attractive in recent years by the difficulty in downloading and installing a current version and finding out how to do so. Some projects have moved on to the TDM packaging of MingW. http://tdm-gcc.tdragon.net/ Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return code when there's a problem at shutdown
On 8/8/2010 5:49 PM, Antoine Pitrou wrote: Hello, In issue #5319, the poster complains that redirecting stdout to a misbehaving (pseudo-)file such as /dev/full should produce a non-zero error code when the IO error happens at shutdown (when calling flush() on stdout). I think is worth noting that in the artificial example, python2.5 -c 'print((1, 2, 3))' > /dev/full || echo error status the redirection occurs outside (before) the program operation. Is it a reasonable expectation? What would you think of making the change? It depends on whether or not one considers shutdown operations as part of the program operation. I could argue this either way. In the above example, I could say that Python did what it promised to do -- print something to the stdout stream, and that failure on flushing was outside its purview. I could also say that if one wants the flush to be considered part of the program operation, one should put it in the program explicitly instead of depending on implicit operations after the program ended. (it would require giving a return value to Py_Finalize(), which currently returns nothing) I have the impression that finalization sometimes generates bogus errors due the order of operations. If so returning something would require distinguishing between 'proper' and 'bogus' errors. How easy would that be. If non-trivial, I would go back to "If you want shutdown errors reported, put them in the program explicitly." -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r83869 - in python/branches/py3k: Doc/library/socket.rst Doc/whatsnew/3.2.rst Lib/ssl.py Lib/test/test_socket.py Misc/NEWS Modules/socketmodule.c
On Mon, 9 Aug 2010 01:24:50 +0200 (CEST) antoine.pitrou wrote: > Author: antoine.pitrou > Date: Mon Aug 9 01:24:50 2010 > New Revision: 83869 > > Log: > Issue #8524: Add a forget() method to socket objects, so as to put the > socket into the closed state without closing the underlying file > descriptor. Benjamin suggested to call this detach() instead. What do you think? Thanks Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r83869 - in python/branches/py3k: Doc/library/socket.rst Doc/whatsnew/3.2.rst Lib/ssl.py Lib/test/test_socket.py Misc/NEWS Modules/socketmodule.c
On 8/8/10 7:48 PM, Antoine Pitrou wrote: On Mon, 9 Aug 2010 01:24:50 +0200 (CEST) antoine.pitrou wrote: Author: antoine.pitrou Date: Mon Aug 9 01:24:50 2010 New Revision: 83869 Log: Issue #8524: Add a forget() method to socket objects, so as to put the socket into the closed state without closing the underlying file descriptor. Benjamin suggested to call this detach() instead. What do you think? detach() is the name I've seen most often for this. For example, that's what MFC uses: http://msdn.microsoft.com/en-us/library/7zhdchw8(VS.80).aspx -- Eric. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return code when there's a problem at shutdown
On Sun, 08 Aug 2010 18:49:50 -0400 Terry Reedy wrote: > > In the above example, I could say that Python did what it promised to do > -- print something to the stdout stream, and that failure on flushing > was outside its purview. > > I could also say that if one wants the flush to be considered part of > the program operation, one should put it in the program explicitly > instead of depending on implicit operations after the program ended. Good point. It isn't very hard to call stdout.flush() yourself if you are using stdout as a data stream, and want the user to be notified of errors. Similarly, if deallocating a file object produces an error during the interpreter's lifetime, the error is printed out on stderr and then ignored. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r83831 - in python/branches/release31-maint/Lib: subprocess.py test/test_subprocess.py
On 08/08/2010 11:31 PM, Eric Smith wrote:
On 8/8/10 12:18 PM, tim.golden wrote:
Modified: python/branches/release31-maint/Lib/subprocess.py
==
--- python/branches/release31-maint/Lib/subprocess.py (original)
+++ python/branches/release31-maint/Lib/subprocess.py Sun Aug 8 18:18:18 2010
@@ -829,7 +829,7 @@
startupinfo.dwFlags |= _subprocess.STARTF_USESHOWWINDOW
startupinfo.wShowWindow = _subprocess.SW_HIDE
comspec = os.environ.get("COMSPEC", "cmd.exe")
-args = comspec + " /c " + args
+args = comspec + " /c " + '"%s"' % args
if (_subprocess.GetVersion()>= 0x8000 or
os.path.basename(comspec).lower() == "command.com"):
# Win9x, or using command.com on NT. We need to
If args is a tuple, this fails with a TypeError. I realize args
shouldn't be a tuple, but that's not a great failure if it is. I think
this would be better written as:
args = '{} /c "{}"'.format(compspec, args)
Thanks, Eric. I'll rework.
TJG
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
