[Python-Dev] Should libpython.a go in eprefix?
Hi all, This issue: http://bugs.python.org/issue9807 from a couple of years ago seems to have changed the LIBPL build variable from pointing to a directory inside EPREFIX, to a directory in PREFIX. This doesn't seem ideal as LIBPL is populated with platform specific files such as libpython.a. I'm wondering if this was intentional, or an oversight? It seems to dramatically lessen the utility of providing an --exec-prefix to configure. Thanks, Ben ___ 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] PEP 433: Add cloexec argument to functions creating file descriptors
On 01/14/2013 01:44 PM, Greg Ewing wrote: I think "protect" is *far* too vague. We don't want something so neutral that it gives no clue at all about its meaning. My shoot-from-the-hip name suggestion: "sterile". (Does not produce offspring.) When a process and a file descriptor love each other *very much*... //arry/ ___ 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] PEP-431 updated.
OK, here is the third major incarnation of PEP-431.
I think it addresses all the concerns brought to light so far.
https://raw.github.com/regebro/tz-pep/master/pep-04tz.txt
Is there a simpler way of doing this than thus "cut and paste"
updating? Is there a way to make pull requests to hg.python.org, for
example?
PEP: 431
Title: Time zone support improvements
Version: $Revision$
Last-Modified: $Date$
Author: Lennart Regebro
BDFL-Delegate: Barry Warsaw
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 11-Dec-2012
Post-History: 11-Dec-2012, 28-Dec-2012
Abstract
This PEP proposes the implementation of concrete time zone support in the
Python standard library, and also improvements to the time zone API to deal
with ambiguous time specifications during DST changes.
Proposal
Concrete time zone support
--
The time zone support in Python has no concrete implementation in the
standard library outside of a tzinfo baseclass that supports fixed offsets.
To properly support time zones you need to include a database over all time
zones, both current and historical, including daylight saving changes.
But such information changes frequently, so even if we include the last
information in a Python release, that information would be outdated just a
few months later.
Time zone support has therefore only been available through two third-party
modules, ``pytz`` and ``dateutil``, both who include and wrap the "zoneinfo"
database. This database, also called "tz" or "The Olsen database", is the
de-facto standard time zone database over time zones, and it is included in
most Unix and Unix-like operating systems, including OS X.
This gives us the opportunity to include the code that supports the zoneinfo
data in the standard library, but by default use the operating system's copy
of the data, which typically will be kept updated by the updating mechanism
of the operating system or distribution.
For those who have an operating system that does not include the zoneinfo
database, for example Windows, the Python source distribution will include a
copy of the zoneinfo database, and a distribution containing the latest
zoneinfo database will also be available at the Python Package Index, so it
can be easily installed with the Python packaging tools such as
``easy_install`` or ``pip``. This could also be done on Unices that are no
longer receiving updates and therefore have an outdated database.
With such a mechanism Python would have full time zone support in the
standard library on any platform, and a simple package installation would
provide an updated time zone database on those platforms where the zoneinfo
database isn't included, such as Windows, or on platforms where OS updates
are no longer provided.
The time zone support will be implemented by making the ``datetime`` module
into a package, and adding time zone support to ``datetime`` based on Stuart
Bishop's ``pytz`` module.
Getting the local time zone
---
On Unix there is no standard way of finding the name of the time zone that is
being used. All the information that is available is the time zone
abbreviations, such as ``EST`` and ``PDT``, but many of those abbreviations
are ambiguous and therefore you can't rely on them to figure out which time
zone you are located in.
There is however a standard for finding the compiled time zone information
since it's located in ``/etc/localtime``. Therefore it is possible to create
a local time zone object with the correct time zone information even though
you don't know the name of the time zone. A function in ``datetime`` should
be provided to return the local time zone.
The support for this will be made by integrating Lennart Regebro's
``tzlocal`` module into the new ``datetime`` module.
For Windows it will look up the local Windows time zone name, and use a
mapping between Windows time zone names and zoneinfo time zone names provided
by the Unicode consortium to convert that to a zoneinfo time zone.
The mapping should be updated before each major or bugfix release, scripts
for doing so will be provided in the ``Tools/`` directory.
Ambiguous times
---
When changing over from daylight savings time (DST) the clock is turned back
one hour. This means that the times during that hour happens twice, once
without DST and then once with DST. Similarly, when changing to daylight
savings time, one hour goes missing.
The current time zone API can not differentiate between the two ambiguous
times during a change from DST. For example, in Stockholm the time of
2012-11-28 02:00:00 happens twice, both at UTC 2012-11-28 00:00:00 and also
at 2012-11-28 01:00:00.
The current time zone API can not disambiguate this and therefore it's
unclear which time should be returned::
# This could be either 00:00 or 01:00 UTC:
>>> dt = datetime(2012, 10, 28, 2, 0, tzinfo=zoneinfo('Europe/Stockholm'))
# But we can no
Re: [Python-Dev] PEP-431 updated.
On Tue, Jan 15, 2013 at 4:07 PM, Lennart Regebro wrote: > OK, here is the third major incarnation of PEP-431. > > I think it addresses all the concerns brought to light so far. > > https://raw.github.com/regebro/tz-pep/master/pep-04tz.txt > > > Is there a simpler way of doing this than thus "cut and paste" > updating? Is there a way to make pull requests to hg.python.org, for > example? Easier how? If you mean mail python-dev then no since people need the ability to do inline commenting on the mailing list. If you mean update the PEP editors, clone the hg repo and send us a patch. -Brett > > > > > PEP: 431 > Title: Time zone support improvements > Version: $Revision$ > Last-Modified: $Date$ > Author: Lennart Regebro > BDFL-Delegate: Barry Warsaw > Status: Draft > Type: Standards Track > Content-Type: text/x-rst > Created: 11-Dec-2012 > Post-History: 11-Dec-2012, 28-Dec-2012 > > > Abstract > > > This PEP proposes the implementation of concrete time zone support in the > Python standard library, and also improvements to the time zone API to deal > with ambiguous time specifications during DST changes. > > > Proposal > > > Concrete time zone support > -- > > The time zone support in Python has no concrete implementation in the > standard library outside of a tzinfo baseclass that supports fixed offsets. > To properly support time zones you need to include a database over all time > zones, both current and historical, including daylight saving changes. > But such information changes frequently, so even if we include the last > information in a Python release, that information would be outdated just a > few months later. > > Time zone support has therefore only been available through two third-party > modules, ``pytz`` and ``dateutil``, both who include and wrap the "zoneinfo" > database. This database, also called "tz" or "The Olsen database", is the > de-facto standard time zone database over time zones, and it is included in > most Unix and Unix-like operating systems, including OS X. > > This gives us the opportunity to include the code that supports the zoneinfo > data in the standard library, but by default use the operating system's copy > of the data, which typically will be kept updated by the updating mechanism > of the operating system or distribution. > > For those who have an operating system that does not include the zoneinfo > database, for example Windows, the Python source distribution will include a > copy of the zoneinfo database, and a distribution containing the latest > zoneinfo database will also be available at the Python Package Index, so it > can be easily installed with the Python packaging tools such as > ``easy_install`` or ``pip``. This could also be done on Unices that are no > longer receiving updates and therefore have an outdated database. > > With such a mechanism Python would have full time zone support in the > standard library on any platform, and a simple package installation would > provide an updated time zone database on those platforms where the zoneinfo > database isn't included, such as Windows, or on platforms where OS updates > are no longer provided. > > The time zone support will be implemented by making the ``datetime`` module > into a package, and adding time zone support to ``datetime`` based on Stuart > Bishop's ``pytz`` module. > > > Getting the local time zone > --- > > On Unix there is no standard way of finding the name of the time zone that is > being used. All the information that is available is the time zone > abbreviations, such as ``EST`` and ``PDT``, but many of those abbreviations > are ambiguous and therefore you can't rely on them to figure out which time > zone you are located in. > > There is however a standard for finding the compiled time zone information > since it's located in ``/etc/localtime``. Therefore it is possible to create > a local time zone object with the correct time zone information even though > you don't know the name of the time zone. A function in ``datetime`` should > be provided to return the local time zone. > > The support for this will be made by integrating Lennart Regebro's > ``tzlocal`` module into the new ``datetime`` module. > > For Windows it will look up the local Windows time zone name, and use a > mapping between Windows time zone names and zoneinfo time zone names provided > by the Unicode consortium to convert that to a zoneinfo time zone. > > The mapping should be updated before each major or bugfix release, scripts > for doing so will be provided in the ``Tools/`` directory. > > > Ambiguous times > --- > > When changing over from daylight savings time (DST) the clock is turned back > one hour. This means that the times during that hour happens twice, once > without DST and then once with DST. Similarly, when changing to daylight > savings time, one hour goes missing. > > The current time zone API can not diff
[Python-Dev] DLLs folder on Windows
Hi! I'm curious how dlls from the DLLs folder on Windows are being loaded? As they are not placed in the same folder where python.exe resides I guess they must be loaded by giving the path explicitly but I'm not sure. I'm asking because there's no DLLs folder being created when creating virtualenv and I suspect it should be. This is a followup to my question "Why doesn't virtualenv create DLLs folder?" (http://stackoverflow.com/q/6657541/95735) and to the virtualenv's issue 87 - "Problems creating virtualenv on Windows when Python is not installed for all users.". Regards, Piotr Dobrogost ___ 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] DLLs folder on Windows
On 1/15/2013 6:21 PM, Piotr Dobrogost wrote: I'm curious how dlls from the DLLs folder on Windows are being loaded? As they are not placed in the same folder where python.exe resides I guess they must be loaded by giving the path explicitly but I'm not sure. They are in .../DLLs, which is in sys.path before .../Lib. I don't know about virtualenv. (Usage questions should go to python-list.) -- 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
