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
On Sun, Dec 5, 2010 at 8:56 AM, raymond.hettinger
python-check...@python.org 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
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
-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 p.f.mo...@gmail.com wrote:
On 4 December 2010 18:14, Gregory P. Smith g...@krypto.org wrote:
On Sat, Dec 4, 2010 at 3:45 AM, Antoine Pitrou
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
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__ =
On Sat, 4 Dec 2010 23:17:49 +
Paul Moore p.f.mo...@gmail.com wrote:
On 4 December 2010 23:07, Paul Moore p.f.mo...@gmail.com 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
Am 05.12.2010 15:20, schrieb Antoine Pitrou:
On Sat, 4 Dec 2010 23:17:49 +
Paul Moore p.f.mo...@gmail.com wrote:
On 4 December 2010 23:07, Paul Moore p.f.mo...@gmail.com wrote:
Is there an issue on Windows? If not, and given how different FD
inheritance is on Windows, I'd argue that in
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
2010/12/5 Łukasz Langa luk...@langa.pl:
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
On 5 December 2010 14:20, Antoine Pitrou solip...@pitrou.net 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
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
Vinay ... the deprecation of ConfigParser for 3.2
What's the rush? It's been deprecated, not removed.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Sun, Dec 5, 2010 at 4:45 AM, Tres Seaver tsea...@palladion.com 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/05/2010 01:06 PM, s...@pobox.com 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
On Sun, 5 Dec 2010 11:08:43 -0800
Gregory P. Smith g...@krypto.org 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
On Sun, Dec 5, 2010 at 11:12 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Sun, 5 Dec 2010 11:08:43 -0800
Gregory P. Smith g...@krypto.org 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
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
On Sun, 05 Dec 2010 22:48:49 +0100
Martin v. Löwis mar...@v.loewis.de 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
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
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
On Sun, Dec 5, 2010 at 14:14, Antoine Pitrou solip...@pitrou.net wrote:
On Sun, 05 Dec 2010 22:48:49 +0100
Martin v. Löwis mar...@v.loewis.de 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
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
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
On 12/5/2010 10:03 AM, s...@pobox.com 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
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
On Mon, Dec 6, 2010 at 8:25 AM, Victor Stinner
victor.stin...@haypocalc.com 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
On Mon, Dec 6, 2010 at 7:48 AM, Martin v. Löwis mar...@v.loewis.de 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
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
Am 06.12.2010 05:36, schrieb Nick Coghlan:
On Mon, Dec 6, 2010 at 7:48 AM, Martin v. Löwis mar...@v.loewis.de 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
Nick Coghlan ncoghlan at gmail.com writes:
On Mon, Dec 6, 2010 at 7:48 AM, Martin v. Löwis martin at 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
On Mon, Dec 6, 2010 at 5:28 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Am 06.12.2010 05:36, schrieb Nick Coghlan:
On Mon, Dec 6, 2010 at 7:48 AM, Martin v. Löwis mar...@v.loewis.de wrote:
I'd like to tighten PEP 11, and declare a policy that systems
older than ten years at the point of a
32 matches
Mail list logo