Re: [Python-Dev] Boost Software License
Le Sun, 27 Jan 2013 21:30:23 +0100, Stefan Behnel a écrit : > Serhiy Storchaka, 27.01.2013 17:52: > > Is Boost Software License [1] compatible with Python license? Can I > > steal some code from Boost library [2]? > > > > [1] http://www.boost.org/LICENSE_1_0.txt > > [2] http://www.boost.org/ > > Depends on what you want to do with it after stealing it. > > Assuming you want to add it to CPython, two things to consider: > > - Isn't Boost C++ code? > > - Usually, people who contribute code to CPython must sign a > contributors agreement. As far as I understand it, that would be > those who wrote it, not those who "stole" it from them. That's the only potentially contentious point. Otherwise, the boost license looks like a fairly ordinary non-copyleft free license, and therefore should be compatible with the PSF license. That said, we already ship "non-contributed" code such as zlib, expat or libffi; and even in the core you can find such code such as David Gay's dtoa.c. 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
[Python-Dev] PEP 431 Updates
I sent this out the 15th, but it seems to have gotten lost since I
have reports that it didn't show up and I got no feedback.
So here goes again, a new version of PEP 431.
http://www.python.org/dev/peps/pep-0431/
//Lennart
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 not specify which:
>>> dt.astimezone(zoneinfo('UTC'))
datetime.datetime(2012, 10, 28, 1, 0, tzinfo=)
Re: [Python-Dev] PEP 431 Updates
Hi, Le Mon, 28 Jan 2013 11:01:05 +0100, Lennart Regebro a écrit : > This function takes a name string that must be a string specifying a > valid zoneinfo time zone, i.e. "US/Eastern", "Europe/Warsaw" or > "Etc/GMT". Will non-ambiguous shorthands such as "Warsaw" and "GMT" be accepted? > The ``is_dst`` parameter can be ``False`` (default), ``True``, or > ``None``. > > ``False`` will specify that the given datetime should be interpreted > as not happening during daylight savings time, i.e. that the time > specified is after the change from DST. > > ``True`` will specify that the given datetime should be interpreted > as happening during daylight savings time, i.e. that the time > specified is before the change from DST. > > ``None`` will raise an ``AmbiguousTimeError`` exception if the time > specified was during a DST change over. It will also raise a > ``NonExistentTimeError`` if a time is specified during the "missing > time" in a change to DST. NonExistentTimeError can also be raised for is_dst=True and is_dst=False, no? Or am I misunderstanding the semantics? 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] PEP 431 Updates
On Mon, Jan 28, 2013 at 11:26 AM, Antoine Pitrou wrote: > Will non-ambiguous shorthands such as "Warsaw" and "GMT" be accepted? pytz accepts GMT, so that will work. Otherwise no. > NonExistentTimeError can also be raised for is_dst=True and > is_dst=False, no? Or am I misunderstanding the semantics? No, it will only be raised when is_dst=None. The flag is there to say what timezone the resulting time should be if it is ambiguous or missing. It is true that the times that don't exist will also not exist even if you set the flag. 2012-03-25 02:30 is a time that don't exist in Europe/Warsaw, flag or not. But it will not raise an error if you set the flag to False or True, for reasons of backwards compatibility as well as ease of handling. People don't expect that certain times don't exist, and will generally not check for those exceptions. Therefore, the normal behavior is to not raise an error, but happily keep dealing with the time as if it does exist. Only of you explicitly set it to "None" will you get an error. //Lennart ___ 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 431 Updates
On Sat, Jan 26, 2013 at 10:38 AM, Nick Coghlan wrote: > 2. Under "New class DstTzInfo" > > This will be a subclass of "tzinfo" rather than "zoneinfo" (which is > not a class). Given that this is a *concrete* subclass, you may want > to consider the name "DstTimezone", which would be slightly more > consistent with the existing "timezone" fixed offset subclass. > (Incidentally, *grumble* at all the existing classes in that module > without capitalized names...) Which probably mean it actually rather should be called tztimezone or something. > 6. Under "New collections" > > Why both lists and sets? Because pytz did it. But yes, you are right, an ordered set is a better solution. Baseing it on OrderedDict seems like a hack, though. I could implement a custom orderedset, of course. //Lennart ___ 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 431 Updates
On Mon, Jan 28, 2013 at 10:06 PM, Lennart Regebro wrote: > On Sat, Jan 26, 2013 at 10:38 AM, Nick Coghlan wrote: >> 2. Under "New class DstTzInfo" >> >> This will be a subclass of "tzinfo" rather than "zoneinfo" (which is >> not a class). Given that this is a *concrete* subclass, you may want >> to consider the name "DstTimezone", which would be slightly more >> consistent with the existing "timezone" fixed offset subclass. >> (Incidentally, *grumble* at all the existing classes in that module >> without capitalized names...) > > Which probably mean it actually rather should be called tztimezone or > something. "dsttimezone", "dst_timezone", "timezonedst" or "timezone_dst" are probably the possibilities most consistent with the current naming scheme. Of those "dst_timezone" is probably the best of a fairly bad bunch. >> 6. Under "New collections" >> >> Why both lists and sets? > > Because pytz did it. But yes, you are right, an ordered set is a > better solution. Baseing it on OrderedDict seems like a hack, though. > I could implement a custom orderedset, of course. Sets themselves have an honourable history of just being a thin wrapper around dictionaries with all the values set to None (although they're not implemented that way any more). Whether you create an actual OrderedSet class, or just expose the result of calling keys() on an OrderedDict instance is just an implementation detail, though. 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] PEP 431 Updates
Le Mon, 28 Jan 2013 22:31:29 +1000, Nick Coghlan a écrit : > > >> 6. Under "New collections" > >> > >> Why both lists and sets? > > > > Because pytz did it. But yes, you are right, an ordered set is a > > better solution. Baseing it on OrderedDict seems like a hack, > > though. I could implement a custom orderedset, of course. > > Sets themselves have an honourable history of just being a thin > wrapper around dictionaries with all the values set to None (although > they're not implemented that way any more). Whether you create an > actual OrderedSet class, or just expose the result of calling keys() > on an OrderedDict instance is just an implementation detail, though. Why the complication? Just expose a regular set and let users call sorted() if that's what they want. I'm -1 on datetime shipping its own container subclass just for the sake of looking clever. 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] PEP 431 Updates
On Mon, Jan 28, 2013 at 10:52 PM, Antoine Pitrou wrote: > Le Mon, 28 Jan 2013 22:31:29 +1000, > Nick Coghlan a écrit : >> >> >> 6. Under "New collections" >> >> >> >> Why both lists and sets? >> > >> > Because pytz did it. But yes, you are right, an ordered set is a >> > better solution. Baseing it on OrderedDict seems like a hack, >> > though. I could implement a custom orderedset, of course. >> >> Sets themselves have an honourable history of just being a thin >> wrapper around dictionaries with all the values set to None (although >> they're not implemented that way any more). Whether you create an >> actual OrderedSet class, or just expose the result of calling keys() >> on an OrderedDict instance is just an implementation detail, though. > > Why the complication? Just expose a regular set and let users call > sorted() if that's what they want. > I'm -1 on datetime shipping its own container subclass just for the > sake of looking clever. I was going by the fact that pytz decided to expose both, and it isn't clear whether the "fast containment test" or "lexically ordered iteration" should be the base behaviour if you're going to rely on sorted() or set() to convert between the two. Since OrderedDict can provide both, creating one internally and just exposing keys() makes sense to me (perhaps via types.MappingProxyType to make it read-only). If people really don't like using OrderedDict that way, I think the other two potentially sensible options are either using an ordinary set, or else adding collections.OrderedSet. I agree adding a new ordered set type hidden within datetime would be a poor idea. 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] Boost Software License
I would check with the PSF's lawyers. That's what they're there for. Developers shouldn't be giving legal advice. On Mon, Jan 28, 2013 at 1:44 AM, Antoine Pitrou wrote: > Le Sun, 27 Jan 2013 21:30:23 +0100, > Stefan Behnel a écrit : >> Serhiy Storchaka, 27.01.2013 17:52: >> > Is Boost Software License [1] compatible with Python license? Can I >> > steal some code from Boost library [2]? >> > >> > [1] http://www.boost.org/LICENSE_1_0.txt >> > [2] http://www.boost.org/ >> >> Depends on what you want to do with it after stealing it. >> >> Assuming you want to add it to CPython, two things to consider: >> >> - Isn't Boost C++ code? >> >> - Usually, people who contribute code to CPython must sign a >> contributors agreement. As far as I understand it, that would be >> those who wrote it, not those who "stole" it from them. > > That's the only potentially contentious point. > Otherwise, the boost license looks like a fairly ordinary non-copyleft > free license, and therefore should be compatible with the PSF license. > > That said, we already ship "non-contributed" code such as zlib, expat > or libffi; and even in the core you can find such code such as David > Gay's dtoa.c. > > 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/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ 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] 32 bit to 64 bit migration of C-API(Python)
Hi Nick, Thanks a lot for your quick responce Thanks Abhishek Goswami Bangalore Phone No -07829580867/9962270999 Skype : abhishekgoswami1 From: Nick Coghlan To: abhishek goswami Cc: "[email protected]" Sent: Sunday, 27 January 2013 11:46 AM Subject: Re: [Python-Dev] 32 bit to 64 bit migration of C-API(Python) On Sun, Jan 27, 2013 at 3:42 PM, abhishek goswami wrote: > Hi, > I am working in Python-C ApI (Integrated Project). The Project has migrated > to 64 bit machine from 32 bit machine. Every thing was working fine in 32 > bit machine. > But we getting following error in 64 bit machine. > " Python int too large to convert to C long". Hi Abhishek, python-dev is for the development *of* CPython, rather than development *with* CPython (including the C API). More appropriate places for this question are the general python-list mailing list or the C API special interest group. However, from the sounds of it, you are running into trouble with the fact that on a 64-bit machine, Python stores many internal values as "Py_ssize_t" (which is always 8 bytes on a 64 bit machine), rather than a C int or long. PEP 353 [1] describes the background for this change, which allows Python containers to exploit the full size of the address space on 64-bit systems. C API functions that may be of interest in that context include: http://docs.python.org/2/c-api/number.html#PyNumber_AsSsize_t http://docs.python.org/2/c-api/int.html#PyInt_FromSsize_t http://docs.python.org/2/c-api/int.html#PyInt_AsSsize_t http://docs.python.org/2/c-api/long.html#PyLong_FromSsize_t http://docs.python.org/2/c-api/long.html#PyLong_AsSsize_t As well as the "n" format character for argument processing http://docs.python.org/2/c-api/arg.html#parsing-arguments-and-building-values [1] http://www.python.org/dev/peps/pep-0353/ Regards, 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] PEP 433: Choose the default value of the new cloexec parameter
"R. David Murray" writes: > On Sun, 27 Jan 2013 21:56:06 +0100, Ralf Schmitt wrote: >> "R. David Murray" writes: >> >> > On Sun, 27 Jan 2013 19:42:59 +0100, Ralf Schmitt >> > wrote: >> >> Guido van Rossum writes: >> >> >> >> > It's like calling socket.settimeout(0.1) and then complaining that >> >> > urllib.urlopen() raises exceptions >> >> >> >> but that's not what's happening. you'll see urllib.urlopen raising >> >> exceptions and only afterwards realize that you called into some third >> >> party library code that decided to change the timeout. >> > >> > What is stopping some some third party library code from calling >> > socket.settimeout(0.1)? >> >> Nothing. That's the point. You just wonder why urlopen fails when the >> global timeout has been changed by that third party library. > > Oh, you were agreeing with Guido? I guess I misunderstood. no. I think it's rather surprising if your code depends on some global variable that might change by calling into some third party code. ___ 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: Choose the default value of the new cloexec parameter
Yeah, so the answer to all this is that 3rd party libraries know better than to mess with global settings. On Mon, Jan 28, 2013 at 1:27 PM, Ralf Schmitt wrote: > "R. David Murray" writes: > > > On Sun, 27 Jan 2013 21:56:06 +0100, Ralf Schmitt > wrote: > >> "R. David Murray" writes: > >> > >> > On Sun, 27 Jan 2013 19:42:59 +0100, Ralf Schmitt > wrote: > >> >> Guido van Rossum writes: > >> >> > >> >> > It's like calling socket.settimeout(0.1) and then complaining that > >> >> > urllib.urlopen() raises exceptions > >> >> > >> >> but that's not what's happening. you'll see urllib.urlopen raising > >> >> exceptions and only afterwards realize that you called into some > third > >> >> party library code that decided to change the timeout. > >> > > >> > What is stopping some some third party library code from calling > >> > socket.settimeout(0.1)? > >> > >> Nothing. That's the point. You just wonder why urlopen fails when the > >> global timeout has been changed by that third party library. > > > > Oh, you were agreeing with Guido? I guess I misunderstood. > > no. I think it's rather surprising if your code depends on some global > variable that might change by calling into some third party code. > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ 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: Choose the default value of the new cloexec parameter
"R. David Murray" writes: > On Sun, 27 Jan 2013 21:56:06 +0100, Ralf Schmitt wrote: >> "R. David Murray" writes: >> >> > On Sun, 27 Jan 2013 19:42:59 +0100, Ralf Schmitt >> > wrote: >> >> Guido van Rossum writes: >> >> >> >> > It's like calling socket.settimeout(0.1) and then complaining that >> >> > urllib.urlopen() raises exceptions >> >> >> >> but that's not what's happening. you'll see urllib.urlopen raising >> >> exceptions and only afterwards realize that you called into some third >> >> party library code that decided to change the timeout. >> > >> > What is stopping some some third party library code from calling >> > socket.settimeout(0.1)? >> >> Nothing. That's the point. You just wonder why urlopen fails when the >> global timeout has been changed by that third party library. > > Oh, you were agreeing with Guido? I guess I misunderstood. no. I think it's rather surprising if your code depends on some global variable that might change by calling into some third party code. ___ 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: Choose the default value of the new cloexec parameter
Guido van Rossum writes: > Yeah, so the answer to all this is that 3rd party libraries know better > than to mess with global settings. Right. But why make it configurable at runtime then? If you're changing the value, then you're the one probably breaking third party code. ___ 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 431 Updates
On 28/01/13 23:52, Antoine Pitrou wrote: Le Mon, 28 Jan 2013 22:31:29 +1000, Nick Coghlan a écrit : 6. Under "New collections" Why both lists and sets? Because pytz did it. But yes, you are right, an ordered set is a better solution. Baseing it on OrderedDict seems like a hack, though. I could implement a custom orderedset, of course. Sets themselves have an honourable history of just being a thin wrapper around dictionaries with all the values set to None (although they're not implemented that way any more). Whether you create an actual OrderedSet class, or just expose the result of calling keys() on an OrderedDict instance is just an implementation detail, though. Why the complication? Just expose a regular set and let users call sorted() if that's what they want. An OrderedSet is not a sorted set. An OrderedSet, like an OrderedDict, remembers *insertion order*, it does not automatically sort the keys. So if datetime needs an ordered set, and I have no opinion on whether or not it really does, calling sorted() on a regular set is not the solution. -- Steven ___ 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 431 Updates
On Mon, Jan 28, 2013 at 11:17 PM, Steven D'Aprano wrote: > On 28/01/13 23:52, Antoine Pitrou wrote: >> >> Le Mon, 28 Jan 2013 22:31:29 +1000, >> Nick Coghlan a écrit : >>> >>> > 6. Under "New collections" > > Why both lists and sets? Because pytz did it. But yes, you are right, an ordered set is a better solution. Baseing it on OrderedDict seems like a hack, though. I could implement a custom orderedset, of course. >>> >>> >>> Sets themselves have an honourable history of just being a thin >>> wrapper around dictionaries with all the values set to None (although >>> they're not implemented that way any more). Whether you create an >>> actual OrderedSet class, or just expose the result of calling keys() >>> on an OrderedDict instance is just an implementation detail, though. >> >> >> Why the complication? Just expose a regular set and let users call >> sorted() if that's what they want. > > > An OrderedSet is not a sorted set. > > An OrderedSet, like an OrderedDict, remembers *insertion order*, it does > not automatically sort the keys. So if datetime needs an ordered set, and > I have no opinion on whether or not it really does, calling sorted() on a > regular set is not the solution. I think the use case for needing really quick checks if a string is in the list of recognized timezone is rather unusual. What is usually needed is a sorted list of valid time zone names. I'll drop the set. //Lennart ___ 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: Choose the default value of the new cloexec parameter
Sigh. This is getting exasperating. There's other code that might want to change this besides 3rd party library code. E.g. app configuration code. On Mon, Jan 28, 2013 at 1:56 PM, Ralf Schmitt wrote: > Guido van Rossum writes: > > > Yeah, so the answer to all this is that 3rd party libraries know better > > than to mess with global settings. > > Right. But why make it configurable at runtime then? If you're changing > the value, then you're the one probably breaking third party code. > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ 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: Choose the default value of the new cloexec parameter
Guido van Rossum writes: > > On Mon, Jan 28, 2013 at 1:56 PM, Ralf Schmitt wrote: > >> Guido van Rossum writes: >> >> > Yeah, so the answer to all this is that 3rd party libraries know better >> > than to mess with global settings. >> >> Right. But why make it configurable at runtime then? If you're changing >> the value, then you're the one probably breaking third party code. > > Sigh. This is getting exasperating. There's other code that might want to > change this besides 3rd party library code. E.g. app configuration code. So, third party library code should know better, while at the same time it's fine to mess with global settings from app configuration code. That does not make sense. ___ 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: Choose the default value of the new cloexec parameter
On 01/28/2013 04:17 PM, Ralf Schmitt wrote: Guido van Rossum writes: On Mon, Jan 28, 2013 at 1:56 PM, Ralf Schmitt wrote: Guido van Rossum writes: Yeah, so the answer to all this is that 3rd party libraries know better than to mess with global settings. Right. But why make it configurable at runtime then? If you're changing the value, then you're the one probably breaking third party code. Sigh. This is getting exasperating. There's other code that might want to change this besides 3rd party library code. E.g. app configuration code. So, third party library code should know better, while at the same time it's fine to mess with global settings from app configuration code. That does not make sense. Library code should not be relying on globals settings that can change. Library code should be explicit in its calls so that the current value of a global setting is irrelevant. ~Ethan~ P.S. Unless, of course, the library is meant to work with that global, and can work correctly with all of the global's valid settings. ___ 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: Choose the default value of the new cloexec parameter
> Library code should not be relying on globals settings that can change. > Library code should be explicit in its calls so that the current value of a > global setting is irrelevant. That's one of the problems I've raised with this global flag since the beginning: it's useless for libraries, including the stdlib (and, as a reminder, this PEP started out of a a bug report against socket inheritance in socketserver). And once again, it's an hidden global variable, so you won't be able any more to tell what this code does: """ r, w = os.pipe() if os.fork() == 0: os.close(w) os.execve(['myprog']) """ Furthermore, if the above code is part of a library, and relies upon 'r' FD inheritance, it will break if the user sets the global cloexec flag. And the fact that a library relies upon FD inheritance is an implementation detail, the users shouldn't have to wonder whether enabling a global flag (in their code, not in a library) will break a given library: the only alternative for such code to continue working would be to pass cloexec=True explicitly to os.pipe()... The global socket.settimeout() is IMO a bad idea, and shouldn't be emulated. So I'm definitely -1 against any form of tunable value (be it a sys.setdefaultcloexec(), an environment variable or command-line flag), and still against changing the default value. But I promise that's the last time I'm bringing those arguments up, and I perfectly admit that some people want it as much as I don't want it :-) cf ___ 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: Choose the default value of the new cloexec parameter
On Tue, 29 Jan 2013 01:17:35 +0100 Ralf Schmitt wrote: > Guido van Rossum writes: > > > > > On Mon, Jan 28, 2013 at 1:56 PM, Ralf Schmitt wrote: > > > >> Guido van Rossum writes: > >> > >> > Yeah, so the answer to all this is that 3rd party libraries know better > >> > than to mess with global settings. > >> > >> Right. But why make it configurable at runtime then? If you're changing > >> the value, then you're the one probably breaking third party code. > > > > Sigh. This is getting exasperating. There's other code that might want to > > change this besides 3rd party library code. E.g. app configuration code. > > So, third party library code should know better, while at the same time > it's fine to mess with global settings from app configuration code. Yes, it's fine, because an application developer can often control (or at least study) the behaviour of all the code involved. It's the same story as with logging configuration and similar process-wide settings. Libraries shouldn't mess with it but the top-level application definitely can (and should, even). (and if you think many third-party libraries call fork()+exec() as part as their normal duty, then I've got a bridge to sell you) 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
