Re: [Python-Dev] gc ideas -- sparse memory
"Martin v. Löwis" writes: > > Why is useful to expose an identity hash? AFAICS it is *only* useful > > in building an identity hash table. If so, why not just provide id() > > or the is operator or both and be done with it? > > That's precisely James' point: Java provides the identity hash > *instead* of the id() function (i.e. it does not have an equivalent > of id()). Doing so gives greater liberties in implementing Java. Yes, we understand that it makes the implementer's job easier. *Why bother having an identity hash at all?* Having taken away id() and provided maximum leisure to the implementer via def identity_hash(object): return 42 is there *any* benefit left for the user/developer? All I see is costs: costs in implementation, costs in debugging. And AFAICS this is a problem that can be solved once and reused by everybody who needs id(); why does every developer need to write his own id() function? ___ 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] r87066 - python/branches/py3k/Doc/whatsnew/3.2.rst
On Sun, Dec 5, 2010 at 8:56 AM, raymond.hettinger wrote: > +.. seealso:: > + > + :pep:`384` - PYC Repository Directories > + PEP written by Martin von Loewis. > + The PEP title here should be "Defining a Stable ABI" (I noticed a later checkin fixing the PEP 3148 see-also title, but I didn't see anything for this one). 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
[Python-Dev] Repo frozen for 3.2
I've just been notified via being added to the nosy list of http://bugs.python.org/issue10627 about the deprecation of ConfigParser for 3.2. I presume I was added to this list because logging.config uses ConfigParser, but logging.config doesn't use any interpolation features so I could easily change all usages to SafeConfigParser; should I do it now (before the 3.2 beta is cut) or hold off for now? Regards, Vinay Sajip ___ 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] r87010 - in python/branches/py3k: Doc/library/subprocess.rst Lib/subprocess.py Lib/test/test_subprocess.py
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/04/2010 03:13 PM, Gregory P. Smith wrote: > On Sat, Dec 4, 2010 at 11:28 AM, Paul Moore wrote: > >> On 4 December 2010 18:14, Gregory P. Smith wrote: >>> >>> >>> On Sat, Dec 4, 2010 at 3:45 AM, Antoine Pitrou >> wrote: On Sat, 4 Dec 2010 10:10:44 +0100 (CET) gregory.p.smith wrote: > Author: gregory.p.smith > Date: Sat Dec 4 10:10:44 2010 > New Revision: 87010 > > Log: > issue7213 + issue2320: Cause a DeprecationWarning if the close_fds > argument is > not passed to subprocess.Popen as the default value will be changing >> in > a > future Python to the safer and more often desired value of True. That doesn't seem to be a good idea under Windows, is it? (“Note that on Windows, you cannot set *close_fds* to true and also redirect the standard handles by setting *stdin*, *stdout* or *stderr*.”) >>> >>> Regardless of what platform you are on I think the warning makes sense, >> it >>> was just worded too strongly. It is asking people to be explicit with >>> close_fds. Explicitly setting close_fds=False when that is desired is >> good. >>> I modified the docs and warning message to just say that the default >>> close_fds behavior will change in the future without specifying exactly >> what >>> it will be. It could make sense for the default to be a soft-True on >>> windows that changes behavior if any of the std handles are set if that >>> matches what users expect and find easiest. We may want to reconsider >> its >>> entire future in the face of the new pass_fds parameter, etc. Those are >> 3.3 >>> decisions. >> >> This sounds like omitting the close_fds parameter is now considered >> ill-advised, if not outright wrong. That's silly - I certainly never >> specify close_fds, expecting the module to do the correct thing if I >> don't know/care enough to say. I use Popen as a convenience function, >> so ignoring low-level details is the whole point in my opinion (and >> close_fds *is* a low-level detail for what I do, on Windows). >> >> At the very least, the whole of the section "Replacing Older Functions >> with the subprocess Module" (with a couple of small exceptions) is in >> need of updating, as it is recommending bad practice (not specifying >> close_fds) at the moment... >> >> OK, I'm exaggerating a touch here. But can someone point me at the >> discussion of this change? Or if there hasn't been one, can we have >> one (i.e., to start the ball rolling, can someone justify the change, >> please). >> >> Paul. >> > > Making the change was intended to force the discussion. I'm glad that > worked. :) > > I don't like the thought of requiring people to specify close_fds either but > the default is a bad one (see http://bugs.python.org/issue7213 and > http://bugs.python.org/issue2320) so we should change it. > > The real question is how should we go about doing the change? This warning > asking people to always specify close_fds=True is heavy handed. Other > places in the stdlib and docs no doubt still need to be updated to reflect > it, etc. > > > Options that seem worthy of debate: > > A) The DeprecationWarning that exists in py3k as of today. > > B) Remove the DeprecationWarning, simply document that people should be > explicit about it if they care at all and that the default will change in > 3.3. > > C) Never change close_fds behavior. we're stuck with it for life. > > D) Deprecate close_fds so that it becomes a legacy no-op. the new pass_fds > flag could evolve into this. this will break existing code that depends on > close_fds one way or another. > > > I'm in 100% agreement that forcing people to pass close_fds in makes the API > less friendly (granted, people already find it unfriendly but why make it > worse?). > > Option B seems the most friendly to me. +1 from me. People who don't care about the 'close_fds' behavior one way or the other shouldn't get a warning which only helps the tiny (I assert) minority who a) *do* care but b) don't pass the flag explicitly. Tres.. - -- === Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkz7iU4ACgkQ+gerLs4ltQ4SJgCfePUImv5OSHzzZ4QJvzUz1oYJ LhAAoKRut3AfGkS23hghQx9pd3D0WF3p =y8hn -END PGP SIGNATURE- ___ 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] Repo frozen for 3.2
Reposted for reference what originally only went to Vinay. Wiadomość napisana przez Vinay Sajip w dniu 2010-12-05, o godz. 12:36: > I've just been notified via being added to the nosy list of > > http://bugs.python.org/issue10627 > > about the deprecation of ConfigParser for 3.2. I presume I was added to this > list because logging.config uses ConfigParser, but logging.config doesn't use > any interpolation features so I could easily change all usages to > SafeConfigParser; should I do it now (before the 3.2 beta is cut) or hold off > for now? > Hold off, just like distutils2 etc. :) I finished the deprecation patch too late and so #10627 was created literally hours (if not minutes) before the freeze. Sorry for that. On a related note, if you're sure logging users don't use any interpolation, you can also use SafeConfigParser(interpolation=None) so then all values become raw by default (e.g. people can use Python string formatting directives, % signs etc.). We can discuss this later on when the time comes for that. -- Best regards, Łukasz Langa tel. +48 791 080 144 WWW http://lukasz.langa.pl/ ___ 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] Unanswered reactions to python-checkins
Hello, Three messages sent in reaction to python-checkins email have not got any reply so far, so I’m resending them. Regards Nick, in reaction to the reprlib.recursive_repr commit: >> > +# Can't use functools.wraps() here because of bootstrap issues >> > +wrapper.__module__ = getattr(user_function, '__module__') >> > +wrapper.__doc__ = getattr(user_function, '__doc__') >> > +wrapper.__name__ = getattr(user_function, '__name__') >> > +return wrapper > Perhaps add __wrapped__ as well? > > (I assume that, similar to _collections before it was made a builtin, > the bootstrap issue is that _functools is an extension module rather > than builtin, but reprlib is needed when building the extension > modules?) Me, about a zlib-related change in Misc/NEWS: > +zlib > + > + > +The :mod:`zlib` extension is built using an included copy of the zlib > +sources unless the zlib version found on the system is too old to be > +used for the build:: > > Unless or if? Building with an included copy *if* the system one is too > old makes sense to me, not the contrary. Am I not seeing something? Me, about a change to winsound.PlaySound: > Extension Modules > - > > +- Issue #6317: Now winsound.PlaySound only accepts unicode. > + > - Issue #6317: Now winsound.PlaySound can accept non ascii filename. I think the new entry should have replaced the older: “only accepts” trumps “can accept“. ___ 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] r87010 - in python/branches/py3k: Doc/library/subprocess.rst Lib/subprocess.py Lib/test/test_subprocess.py
On Sat, 4 Dec 2010 23:17:49 + Paul Moore wrote: > On 4 December 2010 23:07, Paul Moore wrote: > > Is there an issue on Windows? If not, and given how different FD > > inheritance is on Windows, I'd argue that in the absence of bug > > reports, there's no need to change behaviour on Windows. > > Actually, from the error message I just got: > > ValueError: close_fds is not supported on Windows platforms if you > redirect stdin/stdout/stderr > > So on Windows, for the issues mentioned (both of which involve > redirected stdin/out/err), leaving the current default appears to be > not only advisable, but required. > > I suspect an os-dependent default would be ugly to document... How about a best-effort behaviour? Setting close_fds to True would only close fds where possible (i.e., not under Windows when piping either of stdin, stdout, stderr). 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] r87010 - in python/branches/py3k: Doc/library/subprocess.rst Lib/subprocess.py Lib/test/test_subprocess.py
Am 05.12.2010 15:20, schrieb Antoine Pitrou: > On Sat, 4 Dec 2010 23:17:49 + > Paul Moore wrote: >> On 4 December 2010 23:07, Paul Moore wrote: >> > Is there an issue on Windows? If not, and given how different FD >> > inheritance is on Windows, I'd argue that in the absence of bug >> > reports, there's no need to change behaviour on Windows. >> >> Actually, from the error message I just got: >> >> ValueError: close_fds is not supported on Windows platforms if you >> redirect stdin/stdout/stderr >> >> So on Windows, for the issues mentioned (both of which involve >> redirected stdin/out/err), leaving the current default appears to be >> not only advisable, but required. >> >> I suspect an os-dependent default would be ugly to document... > > How about a best-effort behaviour? Setting close_fds to True would only > close fds where possible (i.e., not under Windows when piping either of > stdin, stdout, stderr). That sounds reasonable. Georg ___ 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] Unanswered reactions to python-checkins
On 2010/12/05 23:19, Éric Araujo wrote: Me, about a change to winsound.PlaySound: Extension Modules - +- Issue #6317: Now winsound.PlaySound only accepts unicode. + - Issue #6317: Now winsound.PlaySound can accept non ascii filename. I think the new entry should have replaced the older: “only accepts” trumps “can accept“. This is two difference thing. Ordinary winsound.PlaySound accepted both bytes and str, but cannot accept non ascii filename. Now it accepts only str, but can accept non ascii filename. I can read "can accept" as "can accept str, but also bytes", but this is not true. ___ 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] Repo frozen for 3.2
2010/12/5 Łukasz Langa : > On a related note, if you're sure logging users don't use any interpolation, > you can also use SafeConfigParser(interpolation=None) so then all values > become raw by default (e.g. people can use Python string formatting > directives, % signs etc.). We can discuss this later on when the time comes > for that. This is the hard part, though. So long as the users decide whether to use the interpolation features, it has to be treated as an API compatibility issue. The interpolation syntax is a feature of the language being parsed more than a code-level feature. It's actually a good thing logging is using the ancient ConfigParser, since the interpolation handling is so broken there's unlikely to be any affected uses of '%' in working configurations. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] r87010 - in python/branches/py3k: Doc/library/subprocess.rst Lib/subprocess.py Lib/test/test_subprocess.py
On 5 December 2010 14:20, Antoine Pitrou wrote: > How about a best-effort behaviour? Setting close_fds to True would only > close fds where possible (i.e., not under Windows when piping either of > stdin, stdout, stderr). Is that plausible? I thought that it's possible to close fds, but doesn't necessarily do the right thing. If it's possible to do this, I'd be OK with it, but if it could cause problems just as subtle as the ones we already have, I don't see the benefit. Paul. ___ 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] r87010 - in python/branches/py3k: Doc/library/subprocess.rst Lib/subprocess.py Lib/test/test_subprocess.py
Glenn> On 12/4/2010 3:07 PM, Paul Moore wrote:
>> The original goal was for subprocess to replace os.system, os.popen,
>> os.spawn, etc. That's never quite happened because subprocess is just
>> a little bit too conceptually complex for those basic tasks.
Glenn> Is that way? I didn't find it particularly hard to learn, given
Glenn> the "cheat sheet" of techniques for doing the replacements.
For 99% of my usage (I suspect for most other peoples' as well, at least on
Unix-y systems), this is all I need:
for line in os.popen("some pipeline"):
do_stuff(line)
No cheat sheet necessary. I don't see how subprocess could have made that
common idiom any simpler. Maybe it's better at doing esoteric stuff,
however that falls into the 1% where a simple os.popen isn't adequate.
Skip
___
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] Repo frozen for 3.2
Vinay> ... the deprecation of ConfigParser for 3.2 What's the rush? It's been deprecated, not removed. Skip ___ 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] r87010 - in python/branches/py3k: Doc/library/subprocess.rst Lib/subprocess.py Lib/test/test_subprocess.py
On Sun, Dec 5, 2010 at 4:45 AM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 12/04/2010 03:13 PM, Gregory P. Smith wrote: > > > > Making the change was intended to force the discussion. I'm glad that > > worked. :) > > > > I don't like the thought of requiring people to specify close_fds either > but > > the default is a bad one (see http://bugs.python.org/issue7213 and > > http://bugs.python.org/issue2320) so we should change it. > > > > The real question is how should we go about doing the change? This > warning > > asking people to always specify close_fds=True is heavy handed. Other > > places in the stdlib and docs no doubt still need to be updated to > reflect > > it, etc. > > > > > > Options that seem worthy of debate: > > > > A) The DeprecationWarning that exists in py3k as of today. > > > > B) Remove the DeprecationWarning, simply document that people should be > > explicit about it if they care at all and that the default will change in > > 3.3. > > > > C) Never change close_fds behavior. we're stuck with it for life. > > > > D) Deprecate close_fds so that it becomes a legacy no-op. the new > pass_fds > > flag could evolve into this. this will break existing code that depends > on > > close_fds one way or another. > > > > > > I'm in 100% agreement that forcing people to pass close_fds in makes the > API > > less friendly (granted, people already find it unfriendly but why make it > > worse?). > > > > Option B seems the most friendly to me. > > +1 from me. People who don't care about the 'close_fds' behavior one > way or the other shouldn't get a warning which only helps the tiny (I > assert) minority who a) *do* care but b) don't pass the flag explicitly. > > Sleeping on the issue some more and pondering it... Is there any _good_ reason not to just make the close_fds default change in 3.2 today? No warning (since they're never seen by most people anyways). Document it in Misc/NEWS and whatsnew.rst. The most common use case is likely the simpler one where close_fds is not specified because the caller doesn't care, not because they are relying on the default being False. Another reason why I think changing it today is okay: This is Python 3.x. It has not yet seen wide adoption. It isn't likely to see wide adoption until 3.2. People migrating code to 3.2 are more likely to be migrating from 2.x than from 3.1. 2to3 can have a fixer added to specify close_fds=False on subprocess calls. Consider this option B-prime. -gps ___ 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] Repo frozen for 3.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/05/2010 01:06 PM, [email protected] wrote: > > Vinay> ... the deprecation of ConfigParser for 3.2 > > What's the rush? It's been deprecated, not removed. Having modules in the stdlib ship trigger (not raise) DeprecationWarnings is bad housekeeping / "broken window" stuff: it leads application developers to ignore them. Tres. - -- === Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkz749YACgkQ+gerLs4ltQ6WyACcDrHkqRVYl11ctTJ5AswTK51Q evMAni7X2BdCbkyXzX7vLQCNMzoMj1yg =Ui6Y -END PGP SIGNATURE- ___ 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] r87010 - in python/branches/py3k: Doc/library/subprocess.rst Lib/subprocess.py Lib/test/test_subprocess.py
On Sun, 5 Dec 2010 11:08:43 -0800 "Gregory P. Smith" wrote: > Sleeping on the issue some more and pondering it... > > Is there any _good_ reason not to just make the close_fds default change in > 3.2 today? No warning (since they're never seen by most people anyways). > Document it in Misc/NEWS and whatsnew.rst. Yes, it will break many scripts under Windows. That's the core of the issue, really. I agree under Unix it makes sense to change the default. 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] r87010 - in python/branches/py3k: Doc/library/subprocess.rst Lib/subprocess.py Lib/test/test_subprocess.py
On Sun, Dec 5, 2010 at 11:12 AM, Antoine Pitrou wrote: > On Sun, 5 Dec 2010 11:08:43 -0800 > "Gregory P. Smith" wrote: > > Sleeping on the issue some more and pondering it... > > > > Is there any _good_ reason not to just make the close_fds default change > in > > 3.2 today? No warning (since they're never seen by most people anyways). > > Document it in Misc/NEWS and whatsnew.rst. > > Yes, it will break many scripts under Windows. > That's the core of the issue, really. I agree under Unix it makes > sense to change the default. > Sorry, yes, I was ignoring windows in the above statement. I only want the change in default on unix, windows has different needs. > > 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/greg%40krypto.org > ___ 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 11: Dropping support for ten year old systems
I'd like to tighten PEP 11, and declare a policy that systems older than ten years at the point of a feature release are not supported anymore by default. Older systems where support is still maintained need to be explicitly listed in the PEP, along with the name of the responsible maintainer (I think this would currently only cover OS2/EMX which is maintained by Andrew MacIntyre). Support for such old platforms can then be removed from the codebase immediately, no need to go through a PEP 11 deprecation cycle. As a consequence, I would then like to remove support for Solaris versions older than Solaris 8 (released in January 2000, last updated by Sun in 2004) from the configure script for 3.2b2. A number of other tests in configure.in could probably also be removed, although I personally won't touch them before 3.2. The other major system affected by this would be Windows 2000, for which we already decided to not support it anymore. Opinions? 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] PEP 11: Dropping support for ten year old systems
On Sun, 05 Dec 2010 22:48:49 +0100 "Martin v. Löwis" wrote: > I'd like to tighten PEP 11, and declare a policy that systems > older than ten years at the point of a feature release are not > supported anymore by default. Older systems where support is still > maintained need to be explicitly listed in the PEP, along with > the name of the responsible maintainer (I think this would currently > only cover OS2/EMX which is maintained by Andrew MacIntyre). > > Support for such old platforms can then be removed from the codebase > immediately, no need to go through a PEP 11 deprecation cycle. Seconded! > The other major system affected by this would be Windows 2000, for which > we already decided to not support it anymore. Is there any 2000-specific code (as opposed to XP-compatible)? 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] transform() and untransform() methods, and the codec registry
On Saturday 04 December 2010 09:31:04 you wrote: > Alexander Belopolsky writes: > > In fact, once the language moratorium is over, I will argue that > > str.encode() and byte.decode() should deprecate encoding argument and > > just do UTF-8 encoding/decoding. Hopefully by that time most people > > will forget that other encodings exist. (I can dream, right?) > > It's just a dream. There's a pile of archival material, often on R/O > media, out there that won't be transcoded any more quickly than the > inscriptions on Tutankhamun's tomb. Not only, many libraries expect use bytes arguments encoded to a specific encoding (eg. locale encoding). Said differenlty, only few libraries written in C accept wchar* strings. The Linux kernel (or many, or all, UNIX/BSD kernels) only manipulate byte strings. The libc only accept wide characters for a few operations. I don't know how to open a file with an unicode path with the Linux libc: you have to encode it... Alexander: you should first patch all UNIX/BSD kernels to use unicode everywhere, then patch all libc implementations, and then all libraries (written in C). After that, you can have a break. Victor ___ 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] gc ideas -- sparse memory
Martin v. Löwis wrote: The hole C API would break if objects would move in memory. Since they have to stay at fixed addresses, it's easy enough to use the address as ID. Yes. Some of the discussion here seems to be assuming that the reason Python doesn't move objects is so that it can use the address as a unique ID. But it's the other way around. -- Greg ___ 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 11: Dropping support for ten year old systems
On Sun, Dec 5, 2010 at 14:14, Antoine Pitrou wrote: > On Sun, 05 Dec 2010 22:48:49 +0100 > "Martin v. Löwis" wrote: >> I'd like to tighten PEP 11, and declare a policy that systems >> older than ten years at the point of a feature release are not >> supported anymore by default. Older systems where support is still >> maintained need to be explicitly listed in the PEP, along with >> the name of the responsible maintainer (I think this would currently >> only cover OS2/EMX which is maintained by Andrew MacIntyre). >> >> Support for such old platforms can then be removed from the codebase >> immediately, no need to go through a PEP 11 deprecation cycle. > > Seconded! Thirded! -Brett > >> The other major system affected by this would be Windows 2000, for which >> we already decided to not support it anymore. > > Is there any 2000-specific code (as opposed to XP-compatible)? > > 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/brett%40python.org > ___ 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 11: Dropping support for ten year old systems
>> The other major system affected by this would be Windows 2000, for which >> we already decided to not support it anymore. > > Is there any 2000-specific code (as opposed to XP-compatible)? Yes: a number of APIs didn't exist in W2k, so we currently use LoadLibrary/GetProcAddress to call them. These can be replaced with regular calls. _WINNT (or whatever the macro is called) then needs to be bumped accordingly. 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] PEP 11: Dropping support for ten year old systems
On 12/5/2010 4:48 PM, "Martin v. Löwis" wrote: I'd like to tighten PEP 11, and declare a policy that systems older than ten years at the point of a feature release are not supported anymore by default. Older systems where support is still maintained need to be explicitly listed in the PEP, along with the name of the responsible maintainer (I think this would currently only cover OS2/EMX which is maintained by Andrew MacIntyre). Support for such old platforms can then be removed from the codebase immediately, no need to go through a PEP 11 deprecation cycle. As a consequence, I would then like to remove support for Solaris versions older than Solaris 8 (released in January 2000, last updated by Sun in 2004) from the configure script for 3.2b2. A number of other tests in configure.in could probably also be removed, although I personally won't touch them before 3.2. The other major system affected by this would be Windows 2000, for which we already decided to not support it anymore. WinXP (released August 2001) should be supported a lot longer than another year ;-) . It is still supported and installed on new systems. -- 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] r87010 - in python/branches/py3k: Doc/library/subprocess.rst Lib/subprocess.py Lib/test/test_subprocess.py
On 12/5/2010 10:03 AM, [email protected] wrote: Glenn> On 12/4/2010 3:07 PM, Paul Moore wrote: >> The original goal was for subprocess to replace os.system, os.popen, >> os.spawn, etc. That's never quite happened because subprocess is just >> a little bit too conceptually complex for those basic tasks. Glenn> Is that way? I didn't find it particularly hard to learn, given Glenn> the "cheat sheet" of techniques for doing the replacements. For 99% of my usage (I suspect for most other peoples' as well, at least on Unix-y systems), this is all I need: for line in os.popen("some pipeline"): do_stuff(line) No cheat sheet necessary. I don't see how subprocess could have made that common idiom any simpler. Maybe it's better at doing esoteric stuff, however that falls into the 1% where a simple os.popen isn't adequate. Skip So it couldn't make it any simpler. For your 99% usage, the question is, does it make it harder? And the answer is, at least a little bit... you have to type more... import subprocess for line in subprocess.Popen("cmd", shell=True, stdout=PIPE).stdout: do_stuff(line) Sad. It does seem like some wrapper functions could have been provided to make the easy cases at least as easy as they were before... My 99% case involves web servers and CGI-type interfaces. And subprocess doesn't provide quite enough to handle the job. It is a bit more complex than your pipeline case, and subprocess does allow the job to be done, and allows it to be done better than popen or popen2 could ever do it. But the helper functions I suggest in the issue would make it lots easier. And probably, it would be nice to include starting the threads within the helper functions, too. ___ 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 11: Dropping support for ten year old systems
> The other major system affected by this would be Windows 2000, for which >> we already decided to not support it anymore. >> > > WinXP (released August 2001) should be supported a lot longer than another > year ;-) . It is still supported and installed on new systems. > Good catch. Windows XP, according to reports online has somewhere between 50-75% marketshare of all personal computers in the world. The Vista fiasco has created a large void which is only now starting to get filled with Windows 7, but it will yet take a long time to dethrone XP. Eli ___ 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] transform() and untransform() methods, and the codec registry
On Mon, Dec 6, 2010 at 8:25 AM, Victor Stinner wrote: > Not only, many libraries expect use bytes arguments encoded to a specific > encoding (eg. locale encoding). Said differenlty, only few libraries written > in > C accept wchar* strings. > > The Linux kernel (or many, or all, UNIX/BSD kernels) only manipulate byte > strings. The libc only accept wide characters for a few operations. I don't > know how to open a file with an unicode path with the Linux libc: you have to > encode it... > > Alexander: you should first patch all UNIX/BSD kernels to use unicode > everywhere, then patch all libc implementations, and then all libraries > (written in C). After that, you can have a break. Slightly less ambitious is to get them all to agree to standardise on UTF-8 as the encoding mechanism (which is actually in the process of happening, it just has a long way to go). However, as a glue language, it is part of Python's role to help manage the transition from legacy encodings to UTF-8, so it will be a very long time before the idea of removing support for the encoding argument becomes even remotely feasible. 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 11: Dropping support for ten year old systems
On Mon, Dec 6, 2010 at 7:48 AM, "Martin v. Löwis" wrote: > I'd like to tighten PEP 11, and declare a policy that systems > older than ten years at the point of a feature release are not > supported anymore by default. Older systems where support is still > maintained need to be explicitly listed in the PEP, along with > the name of the responsible maintainer (I think this would currently > only cover OS2/EMX which is maintained by Andrew MacIntyre). > > Support for such old platforms can then be removed from the codebase > immediately, no need to go through a PEP 11 deprecation cycle. > > As a consequence, I would then like to remove support for Solaris > versions older than Solaris 8 (released in January 2000, last updated > by Sun in 2004) from the configure script for 3.2b2. A number of other > tests in configure.in could probably also be removed, although I > personally won't touch them before 3.2. > > The other major system affected by this would be Windows 2000, for which > we already decided to not support it anymore. > > Opinions? I would prefer to be guided by vendor EOL dates rather than our own arbitrary 10 year limit. The EOL guide I would suggest is "Is the vendor still fixing bugs in that release?". For Solaris 8, the answer to that question is no (Phase 1 EOL support ended in October: http://www.sun.com/service/eosl/eosl_solaris.html) For Windows 2000, the answer is no (Extended Support ended in July: http://support.microsoft.com/lifecycle/?p1=7274) For Windows XP, the answer is yes (Extended Support doesn't end until April 2014: http://windows.microsoft.com/en-us/windows/products/lifecycle#section_2) Since the "Is the vendor still patching it?" guideline gives the "right" answer for the 3 systems mentioned in this thread, it will likely do a better job of covering anomalies like XP than a flat year limit would. 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 11: Dropping support for ten year old systems
On 2010/12/06 6:48, "Martin v. Löwis" wrote: The other major system affected by this would be Windows 2000, for which we already decided to not support it anymore. Opinions? I'm +1/2 for supporting Windows 2000... ___ 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 11: Dropping support for ten year old systems
Am 06.12.2010 05:36, schrieb Nick Coghlan: > On Mon, Dec 6, 2010 at 7:48 AM, "Martin v. Löwis" wrote: >> I'd like to tighten PEP 11, and declare a policy that systems >> older than ten years at the point of a feature release are not >> supported anymore by default. Older systems where support is still >> maintained need to be explicitly listed in the PEP, along with >> the name of the responsible maintainer (I think this would currently >> only cover OS2/EMX which is maintained by Andrew MacIntyre). >> >> Support for such old platforms can then be removed from the codebase >> immediately, no need to go through a PEP 11 deprecation cycle. >> >> As a consequence, I would then like to remove support for Solaris >> versions older than Solaris 8 (released in January 2000, last updated >> by Sun in 2004) from the configure script for 3.2b2. A number of other >> tests in configure.in could probably also be removed, although I >> personally won't touch them before 3.2. >> >> The other major system affected by this would be Windows 2000, for which >> we already decided to not support it anymore. >> >> Opinions? > > I would prefer to be guided by vendor EOL dates rather than our own > arbitrary 10 year limit. The EOL guide I would suggest is "Is the > vendor still fixing bugs in that release?". If available, perhaps. Not all system vendors have such a policy, or it may not be easy to find. If that is part of the policy, I'd like to add the specific systems where we use this approach along with the URLs that list the policies in the PEP. As a counter-example, I think the only way to phase out support for old OpenBSD releases is that we set a date. If this policy is applied to Debian also, we may get unhappy users, since Debian releases get out of love fairly quickly. OTOH, supporting old Linux releases really isn't that much of a 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
Re: [Python-Dev] PEP 11: Dropping support for ten year old systems
Nick Coghlan gmail.com> writes: > On Mon, Dec 6, 2010 at 7:48 AM, "Martin v. Löwis" v.loewis.de> wrote: > > I'd like to tighten PEP 11 > > Opinions? > > I would prefer to be guided by vendor EOL dates rather than our own > arbitrary 10 year limit. The EOL guide I would suggest is "Is the > vendor still fixing bugs in that release?". > > Since the "Is the vendor still patching it?" guideline gives the > "right" answer for the 3 systems mentioned in this thread, it will > likely do a better job of covering anomalies like XP than a flat year > limit would. +1 I think Nick has a point. If the vendor is willing to patch/support said version, then I think it would be worthwhile for the Python community to provide support EOL dates of prominent Linux distribution : RHEL: https://access.redhat.com/support/policy/updates/errata/ Ubuntu: http://en.wikipedia.org/wiki/List_of_Ubuntu_releases#Version_timeline (http://www.ubuntu.com/products/ubuntu/release-cycle seems to be down) SuSe http://support.novell.com/lifecycle/ I do foresee a possible side-effect regarding Fedora as "maintained for approximately 13 months", because "Release X is supported until one month after the release of Release X+2." http://fedoraproject.org/wiki/LifeCycle Considering the nature of the Fedora project, dropping unsupported fedora distributions may or may not be helpful for Pyhton and it's users. Also, it is not clear what to do about distributions/OSs without any official EOL or life cycles. ___ 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 11: Dropping support for ten year old systems
On Mon, Dec 6, 2010 at 5:28 PM, "Martin v. Löwis" wrote: > Am 06.12.2010 05:36, schrieb Nick Coghlan: >> On Mon, Dec 6, 2010 at 7:48 AM, "Martin v. Löwis" wrote: >>> I'd like to tighten PEP 11, and declare a policy that systems >>> older than ten years at the point of a feature release are not >>> supported anymore by default. Older systems where support is still >>> maintained need to be explicitly listed in the PEP, along with >>> the name of the responsible maintainer (I think this would currently >>> only cover OS2/EMX which is maintained by Andrew MacIntyre). >>> >>> Support for such old platforms can then be removed from the codebase >>> immediately, no need to go through a PEP 11 deprecation cycle. >>> >>> As a consequence, I would then like to remove support for Solaris >>> versions older than Solaris 8 (released in January 2000, last updated >>> by Sun in 2004) from the configure script for 3.2b2. A number of other >>> tests in configure.in could probably also be removed, although I >>> personally won't touch them before 3.2. >>> >>> The other major system affected by this would be Windows 2000, for which >>> we already decided to not support it anymore. >>> >>> Opinions? >> >> I would prefer to be guided by vendor EOL dates rather than our own >> arbitrary 10 year limit. The EOL guide I would suggest is "Is the >> vendor still fixing bugs in that release?". > > If available, perhaps. Not all system vendors have such a policy, > or it may not be easy to find. If that is part of the policy, I'd > like to add the specific systems where we use this approach along > with the URLs that list the policies in the PEP. > > As a counter-example, I think the only way to phase out support > for old OpenBSD releases is that we set a date. I would be fine with an EOL based policy for single-vendor platforms (specifically Solaris and Windows) and a date-based policy for everything else. 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
