>> 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-di
>> On Wed, Feb 8, 2012 at 10:04 PM, Antoine Pitrou
>> 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 current
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 zipimport-s
On Fri, Feb 10, 2012 at 1:05 AM, Brett Cannon 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 case where
On Thu, Feb 9, 2012 at 5:34 PM, Robert Kern wrote:
> On 2/9/12 10:15 PM, Antoine Pitrou wrote:
>
>> On Thu, 9 Feb 2012 17:00:04 -0500
>> PJ Eby wrote:
>>
>>> On Thu, Feb 9, 2012 at 2:53 PM, Mike Meyer wrote:
>>>
>>> For those of you not watching -ideas, or ignoring the "Python TIOBE
-3%"
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 know
On 2/9/12 10:15 PM, Antoine Pitrou wrote:
On Thu, 9 Feb 2012 17:00:04 -0500
PJ Eby wrote:
On Thu, Feb 9, 2012 at 2:53 PM, Mike Meyer 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 i
On Thu, 9 Feb 2012 17:00:04 -0500
PJ Eby wrote:
> On Thu, Feb 9, 2012 at 2:53 PM, Mike Meyer 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:
> >
> > http:
On Thu, Feb 9, 2012 at 2:53 PM, Mike Meyer 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:
>
> http://mail.scipy.org/pipermail/numpy-discussion/2012-January/059801
> 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
In article ,
"Russell E. Owen" 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
> linked in.
The 64-bit OS X installer is built o
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 Cannon wrote:
On Thu, Feb 9, 2012 at 13:43, PJ Eby wrote:
Again, the goal is fast startup of command-line tools that only use a
small subset of the overall framework; d
On Fri, Feb 10, 2012 at 12:59 AM, Stephen J. Turnbull
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 that I could pr
On 2/9/2012 11:53 AM, Mike Meyer wrote:
On Thu, 9 Feb 2012 14:19:59 -0500
Brett Cannon wrote:
On Thu, Feb 9, 2012 at 13:43, PJ Eby 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 agains
On Thu, 9 Feb 2012 14:19:59 -0500
Brett Cannon wrote:
> On Thu, Feb 9, 2012 at 13:43, PJ Eby 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 against that goal.
> >
> Depends if
In article <4f32df1e.40...@v.loewis.de>,
"Martin v. Lowis" 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 trul
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 f
On Thu, Feb 9, 2012 at 13:43, PJ Eby wrote:
>
> On Feb 9, 2012 9:58 AM, "Brett Cannon" 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
2012/2/8 Nick Coghlan
> On Wed, Feb 8, 2012 at 10:04 PM, Antoine Pitrou
> 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.
On Feb 9, 2012 9:58 AM, "Brett Cannon" 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 during load then
On Wed, Feb 8, 2012 at 20:26, Nick Coghlan wrote:
> On Thu, Feb 9, 2012 at 2:09 AM, Antoine Pitrou
> 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 __import__ could still be written in
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 differenc
On Wed, Feb 8, 2012 at 20:28, PJ Eby wrote:
>
>
> On Wed, Feb 8, 2012 at 4:08 PM, Brett Cannon wrote:
>
>>
>> On Wed, Feb 8, 2012 at 15:31, Terry Reedy wrote:
>>
>>> For top-level imports, unless *all* are made lazy, then there *must* be
>>> some indication in the code of whether to make it laz
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
> 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
(sys.getfilesysteme
> 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
> reins
2012/2/9 Antoine Pitrou
> > 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 "mbcs" codec
>
On Thu, 9 Feb 2012 08:43:02 +0200
Simon Cross wrote:
> On Thu, Feb 9, 2012 at 2:35 AM, Steven D'Aprano 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 it's run, which seems
> >> surpris
On Thu, Feb 9, 2012 at 7:32 PM, Victor Stinner
wrote:
changeset: 74832:f8409b3d6449
user: Victor Stinner
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 che
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: h
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 -Wno-unused-resu
>>> changeset: 74832:f8409b3d6449
>>> user: Victor Stinner
>>> 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 mind, I ju
> 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 lo
33 matches
Mail list logo
