I think there's a general expectation that if you encode something
with one codec you will be able to decode it with the same codec.
That's not necessarily true for the locale encoding.
There is the same problem with the filesystem encoding
(sys.getfilesystemencoding()), which is the user
changeset: 74832:f8409b3d6449
user: Victor Stinner victor.stin...@haypocalc.com
date: Wed Feb 08 14:31:50 2012 +0100
summary:
PEP 410
Ah, even when written by a core dev, a PEP should still be at Accepted
before we check anything in. PEP 410 is still at Draft.
Never
francis wrote:
Hi Mark,
I've just cloned :
Repository: https://bitbucket.org/markshannon/cpython_new_dict
Do please try it on your machine(s).
that's a:
Linux random 3.1.0-1-amd64 #1 SMP Tue Jan 10 05:01:58 UTC 2012 x86_64
GNU/Linux
and I'm getting:
gcc -pthread -c
On 08/02/2012 15:16, Mark Shannon wrote:
Hi,
Version 2 is now available.
Version 2 makes as few changes to tunable constants as possible, and
generally does not change iteration order (so repr() is unchanged).
All tests pass (the only changes to tests are for sys.getsizeof() ).
Repository:
On Thu, Feb 9, 2012 at 7:32 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
changeset: 74832:f8409b3d6449
user: Victor Stinner victor.stin...@haypocalc.com
date: Wed Feb 08 14:31:50 2012 +0100
summary:
PEP 410
Ah, even when written by a core dev, a PEP should still
On Thu, 9 Feb 2012 08:43:02 +0200
Simon Cross hodgestar+python...@gmail.com wrote:
On Thu, Feb 9, 2012 at 2:35 AM, Steven D'Aprano st...@pearwood.info wrote:
Simon Cross wrote:
I think I'm -1 on a locale encoding because it refers to different
actual encodings depending on where and when
2012/2/9 Antoine Pitrou solip...@pitrou.net
I think there's a general expectation that if you encode something
with one codec you will be able to decode it with the same codec.
That's not necessarily true for the locale encoding.
As And pointed out, this is already the behaviour of the
With the difference that mbcs cannot change during execution.
It is possible to change the thread ANSI code page (CP_THREAD_ACP)
at runtime, but setting the system ANSI code page (CP_ACP) requires to
restart Windows.
I don't even know if it is possible to change it at all, except by
As And pointed out, this is already the behaviour of the mbcs codec
under Windows. locale would be the moral (*) equivalent of that under
Unix.
On Windows, the ANSI code page codec will be accessible using 3
different names: locale, mbcs and the real encoding name
patch
Description: Binary data
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Wed, Feb 8, 2012 at 20:28, PJ Eby p...@telecommunity.com wrote:
On Wed, Feb 8, 2012 at 4:08 PM, Brett Cannon br...@python.org wrote:
On Wed, Feb 8, 2012 at 15:31, Terry Reedy tjre...@udel.edu wrote:
For top-level imports, unless *all* are made lazy, then there *must* be
some
Victor Stinner writes:
There is the same problem [that encode-decode with the 'locale'
codec doesn't roundtrip reliably] with the filesystem encoding
(sys.getfilesystemencoding()),
-1 on a query to the OS that pretends to be a constant.
You see, it's not the same problem. The difference
On Wed, Feb 8, 2012 at 20:26, Nick Coghlan ncogh...@gmail.com wrote:
On Thu, Feb 9, 2012 at 2:09 AM, Antoine Pitrou solip...@pitrou.net
wrote:
I guess my point was: why is there a function call in that case? The
import statement could look up sys.modules directly.
Or the built-in
On Feb 9, 2012 9:58 AM, Brett Cannon br...@python.org wrote:
This actually depends on the type of ImportError. My current solution
actually would trigger an ImportError at the import statement if no finder
could locate the module. But if some ImportError was raised because of some
other issue
2012/2/8 Nick Coghlan ncogh...@gmail.com
On Wed, Feb 8, 2012 at 10:04 PM, Antoine Pitrou solip...@pitrou.net
wrote:
It's not frozen, it's actually maintained.
Indeed, it sounds like the most appropriate course (if we don't hear
otherwise from Fredrik) may be to just update PEP 360 to
On Thu, Feb 9, 2012 at 13:43, PJ Eby p...@telecommunity.com wrote:
On Feb 9, 2012 9:58 AM, Brett Cannon br...@python.org wrote:
This actually depends on the type of ImportError. My current solution
actually would trigger an ImportError at the import statement if no finder
could locate the
Hi Mark,
Bah... typo in assert statement.
My fault for not testing the debug build (release build worked fine).
Both builds working now.
Yeah, now is working and passes all tests also on my machine.
I've tried to run the test suite but I'm getting a SyntaxError:
(may be you know it's just the
In article 4f32df1e.40...@v.loewis.de,
Martin v. Lowis mar...@v.loewis.de wrote:
Am 05.02.2012 21:34, schrieb Ned Deily:
In article
20120205204551.horde.ncdeyvnncxdpltxvnkzi...@webmail.df.eu,
mar...@v.loewis.de wrote:
I understand that but, to me, it makes no sense to send out
On Thu, 9 Feb 2012 14:19:59 -0500
Brett Cannon br...@python.org wrote:
On Thu, Feb 9, 2012 at 13:43, PJ Eby p...@telecommunity.com wrote:
Again, the goal is fast startup of command-line tools that only use a
small subset of the overall framework; doing disk access for lazy imports
goes
On 2/9/2012 11:53 AM, Mike Meyer wrote:
On Thu, 9 Feb 2012 14:19:59 -0500
Brett Cannonbr...@python.org wrote:
On Thu, Feb 9, 2012 at 13:43, PJ Ebyp...@telecommunity.com wrote:
Again, the goal is fast startup of command-line tools that only use a
small subset of the overall framework; doing
On Fri, Feb 10, 2012 at 12:59 AM, Stephen J. Turnbull
step...@xemacs.org wrote:
If this is needed, it should be spelled os.getlocaleencoding() (or
sys.getlocaleencoding()?)
Or locale.getpreferredencoding(), even ;)
FWIW, I agree with Stephen on this one, but take that with the grain
of salt
On 2/9/2012 3:27 PM, Glenn Linderman wrote:
On 2/9/2012 11:53 AM, Mike Meyer wrote:
On Thu, 9 Feb 2012 14:19:59 -0500
Brett Cannonbr...@python.org wrote:
On Thu, Feb 9, 2012 at 13:43, PJ Ebyp...@telecommunity.com wrote:
Again, the goal is fast startup of command-line tools that only use a
In article rowen-ba4fcf.11522909022...@news.gmane.org,
Russell E. Owen ro...@uw.edu wrote:
One problem I've run into is that the 64-bit Mac python 2.7 does not
work properly with ActiveState Tcl/Tk. One symptom is to build
matplotlib. The results fail -- both versions of Tcl/Tk somehow get
If this is needed, it should be spelled os.getlocaleencoding() (or
sys.getlocaleencoding()?)
There is already a locale.getpreferredencoding(False) function which
give your the current locale encoding. The problem is that the current
locale encoding may change and so you have to get the new
On Thu, Feb 9, 2012 at 2:53 PM, Mike Meyer m...@mired.org wrote:
For those of you not watching -ideas, or ignoring the Python TIOBE
-3% discussion, this would seem to be relevant to any discussion of
reworking the import mechanism:
On Thu, 9 Feb 2012 17:00:04 -0500
PJ Eby p...@telecommunity.com wrote:
On Thu, Feb 9, 2012 at 2:53 PM, Mike Meyer m...@mired.org wrote:
For those of you not watching -ideas, or ignoring the Python TIOBE
-3% discussion, this would seem to be relevant to any discussion of
reworking the
On 2/9/12 10:15 PM, Antoine Pitrou wrote:
On Thu, 9 Feb 2012 17:00:04 -0500
PJ Ebyp...@telecommunity.com wrote:
On Thu, Feb 9, 2012 at 2:53 PM, Mike Meyerm...@mired.org wrote:
For those of you not watching -ideas, or ignoring the Python TIOBE
-3% discussion, this would seem to be relevant
francis wrote:
Hi Mark,
Bah... typo in assert statement.
My fault for not testing the debug build (release build worked fine).
Both builds working now.
Yeah, now is working and passes all tests also on my machine.
I've tried to run the test suite but I'm getting a SyntaxError:
(may be you
On Thu, Feb 9, 2012 at 5:34 PM, Robert Kern robert.k...@gmail.com wrote:
On 2/9/12 10:15 PM, Antoine Pitrou wrote:
On Thu, 9 Feb 2012 17:00:04 -0500
PJ Ebyp...@telecommunity.com wrote:
On Thu, Feb 9, 2012 at 2:53 PM, Mike Meyerm...@mired.org wrote:
For those of you not watching -ideas,
On Fri, Feb 10, 2012 at 1:05 AM, Brett Cannon br...@python.org wrote:
This would then be similar to the way main.c already works when it
interacts with runpy - simple cases are handled directly in C, more
complex cases get handed over to the Python module.
I suspect that if people want the
On 2/9/2012 7:19 PM, PJ Eby wrote:
Right. It was the part of the post that mentioned that all they sped up
was knowing which directory the files were in, not the actual loading of
bytecode. The thought then occurred to me that this could perhaps be
applied to normal importing, as a
On Wed, Feb 8, 2012 at 10:04 PM, Antoine Pitrou solip...@pitrou.net
wrote:
It's not frozen, it's actually maintained.
Indeed, it sounds like the most appropriate course (if we don't hear
otherwise from Fredrik) may be to just update PEP 360 to acknowledge
current reality (i.e. the most
That said, I think that the particular change discussed in this thread
can be made anyway, since it doesn't really modify ET's APIs or
functionality, just the way it gets imported from stdlib.
I would suggest that, assuming python-dev want to take ownership of
the module, one last-ditch
33 matches
Mail list logo
