2012/2/8 Simon Cross :
> Is the idea to have:
>
> b"foo".decode("locale")
>
> be roughly equivalent to
>
> encoding = locale.getpreferredencoding(False)
> b"foo".decode(encoding)
>
> ?
Yes. Whereas:
b"foo".decode(sys.getfilesystemencoding())
is equivalent to
encoding = locale.getpreferredenc
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
surprising, and there's already a more explicit way to achieve the
same effect.
The documentation on .getpreferredencoding() says some scary things
about needing
On Wed, Feb 8, 2012 at 08:37, Stefan Behnel wrote:
> I didn't get a response from him to my e-mails since early 2010. Maybe
> others have more luck if they try, but I don't have the impression that
> waiting another two years gets us anywhere interesting.
>
> Given that it was two months ago that
On Wed, Feb 8, 2012 at 11:36, Dirkjan Ochtman wrote:
> On Wed, Feb 8, 2012 at 08:37, Stefan Behnel wrote:
>> I didn't get a response from him to my e-mails since early 2010. Maybe
>> others have more luck if they try, but I don't have the impression that
>> waiting another two years gets us anywh
On 2012-02-08 09:28, 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
surprising, and there's already a more explicit way to achieve the
same effect.
I'd agree that this is undesirable, and
On 8 February 2012 09:49, Eli Bendersky wrote:
>> I concur. It's important that we consider Fredrik's ownership of the
>> modules, but if he fails to reply to email and doesn't update his
>> repositories, there should be enough cause for python-dev to go on and
>> appropriate the stdlib versions o
On Wed, 8 Feb 2012 11:11:07 +
Paul Moore wrote:
> On 8 February 2012 09:49, Eli Bendersky wrote:
> >> I concur. It's important that we consider Fredrik's ownership of the
> >> modules, but if he fails to reply to email and doesn't update his
> >> repositories, there should be enough cause for
On Wed, Feb 8, 2012 at 10:04 PM, Antoine Pitrou wrote:
> On Wed, 8 Feb 2012 11:11:07 +
> Paul Moore wrote:
>> It's important to respect Fredrik's wishes and ownership, but we can't
>> leave part of the stdlib frozen and abandoned just because he's not
>> available any longer.
>
> It's not fro
On Tue, Feb 7, 2012 at 2:34 PM, wrote:
> results for 140f7de4d2a5 on branch "default"
>
>
> test_capi leaked [296, 296, 296] references, sum=888
This appears to have started shortly after Benjamin's _PyExc_Init
bltinmod refcounting change to fix Brett
>> 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 release of ElementTree is
> actually the one maintained by Florent i
2012/2/8 Nick Coghlan :
> On Tue, Feb 7, 2012 at 2:34 PM, wrote:
>> results for 140f7de4d2a5 on branch "default"
>>
>>
>> test_capi leaked [296, 296, 296] references, sum=888
>
> This appears to have started shortly after Benjamin's _PyExc_Init
> bltin
2012/2/8 Simon Cross :
> 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
> surprising, and there's already a more explicit way to achieve the
> same effect.
The following code is just an example to explain ho
On Wed, Feb 8, 2012 at 3:25 PM, Victor Stinner
wrote:
> Sorry, I don't understand what do you mean by "weird things". The
> "locale" codec doesn't touch the locale.
Sorry for being unclear. My question was about the following lines
from http://docs.python.org/library/locale.html#locale.getpreferr
On Wed, Feb 8, 2012 at 3:25 PM, Victor Stinner
wrote:
> The current locale is process-wide: if a thread changes the locale,
> all threads are affected. Some functions have to use the current
> locale encoding, and not the locale encoding read at startup. Examples
> with C functions: strerror(), st
On 8 February 2012 12:21, Nick Coghlan wrote:
> On Wed, Feb 8, 2012 at 10:04 PM, Antoine Pitrou wrote:
>> On Wed, 8 Feb 2012 11:11:07 +
>> Paul Moore wrote:
>>> It's important to respect Fredrik's wishes and ownership, but we can't
>>> leave part of the stdlib frozen and abandoned just becau
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: https://bitbucket.org/markshannon/cpython_n
On Tue, Feb 7, 2012 at 17:42, Antoine Pitrou wrote:
> On Tue, 7 Feb 2012 17:24:21 -0500
> Brett Cannon wrote:
> >
> > IOW you want the sys.modules case fast, which I will never be able to
> match
> > compared to C code since that is pure execution with no I/O.
>
> Why wouldn't continue using C c
On Tue, Feb 7, 2012 at 18:08, Antoine Pitrou wrote:
> On Tue, 7 Feb 2012 17:16:18 -0500
> Brett Cannon wrote:
> >
> > > > IOW I really do not look forward to someone saying "importlib is so
> much
> > > > slower at importing a module containing ``pass``" when (a) that never
> > > > happens, and
On Tue, Feb 7, 2012 at 21:27, PJ Eby wrote:
>
>
> On Tue, Feb 7, 2012 at 5:24 PM, Brett Cannon wrote:
>
>>
>> On Tue, Feb 7, 2012 at 16:51, PJ Eby wrote:
>>
>>> On Tue, Feb 7, 2012 at 3:07 PM, Brett Cannon wrote:
>>>
So, if there is going to be some baseline performance target I need to
>
Le mercredi 08 février 2012 à 11:01 -0500, Brett Cannon a écrit :
>
>
> On Tue, Feb 7, 2012 at 17:42, Antoine Pitrou
> wrote:
> On Tue, 7 Feb 2012 17:24:21 -0500
> Brett Cannon wrote:
> >
> > IOW you want the sys.modules case fast, which I will never
> be
On Tue, Feb 7, 2012 at 22:47, Nick Coghlan wrote:
> On Wed, Feb 8, 2012 at 12:54 PM, Terry Reedy wrote:
> > On 2/7/2012 9:35 PM, PJ Eby wrote:
> >> It's just that not everything I write can depend on Importing.
> >> Throw an equivalent into the stdlib, though, and I guess I wouldn't have
> >> t
On Tue, Feb 7, 2012 at 22:47, Nick Coghlan wrote
[SNIP]
> The fact that we have an undocumented PEP 302 based reimplementation
> of imports squirrelled away in pkgutil to make pkgutil and runpy work
> is sheer insanity (replacing *that* with importlib might actually be a
> good first step towar
On Tue, Feb 7, 2012 at 18:26, Alex Gaynor wrote:
> Brett Cannon python.org> writes:
>
>
> > IOW you want the sys.modules case fast, which I will never be able to
> match
> compared to C code since that is pure execution with no I/O.
> >
>
>
> Sure you can: have a really fast Python VM.
>
> Const
On Wed, Feb 8, 2012 at 11:09, Antoine Pitrou wrote:
> Le mercredi 08 février 2012 à 11:01 -0500, Brett Cannon a écrit :
> >
> >
> > On Tue, Feb 7, 2012 at 17:42, Antoine Pitrou
> > wrote:
> > On Tue, 7 Feb 2012 17:24:21 -0500
> > Brett Cannon wrote:
> > >
> > > I
On Wed, Feb 8, 2012 at 11:15, Brett Cannon wrote:
>
>
> On Tue, Feb 7, 2012 at 22:47, Nick Coghlan wrote
>
> [SNIP]
>
>
>> The fact that we have an undocumented PEP 302 based reimplementation
>> of imports squirrelled away in pkgutil to make pkgutil and runpy work
>> is sheer insanity (replacing
>> The current locale is process-wide: if a thread changes the locale,
>> all threads are affected. Some functions have to use the current
>> locale encoding, and not the locale encoding read at startup. Examples
>> with C functions: strerror(), strftime(), tzname, etc.
>
> Could a core part of Pyt
Hi,
I changed my email address (about a year ago) and updated my bug tracker
settings to my new address (late last year).
However, the code review tool still shows my old email address.
How do I change it?
Cheers,
Mark.
___
Python-Dev mailing list
Py
This may be a bug in the tracker, possibly related to
http://psf.upfronthosting.co.za/roundup/meta/issue402 - it
seems like changes to a user's details on bugs.python.org
are not propagated to the review tool.
Cheers,
Nadeem
___
Python-Dev mailing list
P
Proposed PEP for new dictionary implementation, PEP 410?
is attached.
Cheers,
Mark.
PEP: XXX
Title: Key-Sharing Dictionary
Version: $Revision$
Last-Modified: $Date$
Author: Mark Shannon
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 08-Feb-2012
Python-Version: 3.3 or 3.4
P
On 2/8/2012 11:13 AM, Brett Cannon wrote:
On Tue, Feb 7, 2012 at 22:47, Nick Coghlan
I'm not sure such an addition would help much with the base
interpreter start up time though - most of the modules we bring in are
because we're actually using them for some reason.
It wouldn't.
On Wed, 8 Feb 2012 11:07:10 -0500
Brett Cannon wrote:
> >
> > > > > So, if there is going to be some baseline performance target I need
> > to
> > > > hit
> > > > > to make people happy I would prefer to know what that (real-world)
> > > > > benchmark is and what the performance target is going t
On Wed, Feb 8, 2012 at 14:57, Terry Reedy wrote:
> On 2/8/2012 11:13 AM, Brett Cannon wrote:
>
>> On Tue, Feb 7, 2012 at 22:47, Nick Coghlan >
>
> I'm not sure such an addition would help much with the base
>>interpreter start up time though - most of the modules we bring in are
>>bec
On 2/8/2012 3:16 PM, Brett Cannon wrote:
On Wed, Feb 8, 2012 at 14:57, Terry Reedy
The intent of what I proposed it to be transparent for imports within
functions. It would be a minor optimization if anything, but it would
mean that there is a lazy mechanism in place.
For top-level imports,
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 truly
>>> broken releases. Besides, the hash collision attack is not exactly
>>>
> Some quick searching shows that there is at least hope Microsoft is on
> board with C++11x (not so surprising, their crown jewels are written
> in C++). We should at some point demand a C++ compiler for CPython
> and pick of subset of C++ features to allow use of but that is likely
> reserved fo
On Wed, Feb 8, 2012 at 15:31, Terry Reedy wrote:
> On 2/8/2012 3:16 PM, Brett Cannon wrote:
>
>> On Wed, Feb 8, 2012 at 14:57, Terry Reedy >Would the following work? Treat a function as a 'loop' in that it
>>may be executed repeatedly. Treat 'import x' in a function as what
>>it is, a
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
On 2/8/2012 2:18 PM, Mark Shannon wrote:
A pretty clear draft PEP.
Changes to repr() output and iteration order:
For most cases, this will be unchanged.
However for some split-table dictionaries the iteration order will
change.
Neither of these cons should be a problem.
Modules which meddle wi
Terry Reedy wrote:
On 2/8/2012 2:18 PM, Mark Shannon wrote:
A pretty clear draft PEP.
Changes to repr() output and iteration order:
For most cases, this will be unchanged.
However for some split-table dictionaries the iteration order will
change.
Neither of these cons should be a problem.
Mod
Just more info: changeset is: 74843:20702d1acf17
Cheers,
francis
___
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-archiv
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
I'm working with the LTTng (Linux Tracing) team and we came across a problem
with our user-space tracer and Python default behavior. We provide a libc
wrapper that instrument free() and malloc() with a simple ld_preload of that
lib.
Thi
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-result -g -O0 -Wall
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
surprising
Why is it surprising? Surely that's the whole point of a locale encoding: to
use the locale encoding, whatever that happens to b
Paul Moore wrote:
I would suggest that, assuming python-dev want to take ownership of
the module, one last-ditch attempt be made to contact Fredrik. We
should email him,
I wouldn't call email to be "last-ditch". I call email "first-ditch".
I would expect that a last-ditch attempt would includ
Could you file a bug at bugs.python.org, David, so we don't lose track of
this?
On Wed, Feb 8, 2012 at 18:03, David Goulet wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi everyone,
>
> I'm working with the LTTng (Linux Tracing) team and we came across a
> problem
> with our user-
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 lazy or not.
>>
>
> Not true; importlib would make it dead-si
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 C, and only defer
> to importlib when the module isn't found
On Thu, Feb 9, 2012 at 11:28 AM, PJ Eby wrote:
> The main two reasons you wouldn't want imports to *always* be lazy are:
>
> 1. Changing sys.path or other parameters between the import statement and
> the actual import
> 2. ImportErrors are likewise deferred until point-of-use, so conditional
> im
On Thu, Feb 9, 2012 at 7:52 AM, victor.stinner
wrote:
> http://hg.python.org/cpython/rev/f8409b3d6449
> 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
On Thu, Feb 9, 2012 at 2:48 PM, Nick Coghlan wrote:
> On Thu, Feb 9, 2012 at 7:52 AM, victor.stinner
> wrote:
>> http://hg.python.org/cpython/rev/f8409b3d6449
>> changeset: 74832:f8409b3d6449
>> user: Victor Stinner
>> date: Wed Feb 08 14:31:50 2012 +0100
>> summary:
>> PEP 410
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
>> surprising
>
>
> Why is it surprising? Surely that's the whole point of a
51 matches
Mail list logo
