On Sat, Feb 11, 2012 at 08:27, Nick Coghlan wrote:
> On Sat, Feb 11, 2012 at 1:14 PM, Eli Bendersky wrote:
>> Mark, do you have a concrete idea of how it can be made more prominent?
>
> Mark didn't know about it because the core-mentorship list didn't
> exist yet in the timeframe he's talking abo
Eric Snow wrote:
On Fri, Feb 10, 2012 at 8:10 PM, Eli Bendersky wrote:
On Fri, Feb 10, 2012 at 22:13, Jim J. Jewett wrote:
Eli Bendersky wrote (in
http://mail.python.org/pipermail/python-dev/2012-February/116393.html ):
A package will be marked provisional by including the
following paragra
On Sat, Feb 11, 2012 at 1:39 PM, Eric Snow wrote:
> Is there more to it than having a simple __provisional__ attribute on
> the module and/or a list at sys.provisional_modules?
Yes. As soon as we touch functional code, it because something to be
tested and the process overhead on our end is notic
On Sat, Feb 11, 2012 at 1:14 PM, Eli Bendersky wrote:
> Mark, do you have a concrete idea of how it can be made more prominent?
Mark didn't know about it because the core-mentorship list didn't
exist yet in the timeframe he's talking about :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.
On Fri, Feb 10, 2012 at 8:10 PM, Eli Bendersky wrote:
> On Fri, Feb 10, 2012 at 22:13, Jim J. Jewett wrote:
>>
>> Eli Bendersky wrote (in
>> http://mail.python.org/pipermail/python-dev/2012-February/116393.html ):
>>
>>> A package will be marked provisional by including the
>>> following paragrap
On Sat, Feb 11, 2012 at 03:38, Jesse Noller wrote:
> I've been trying to publicize it on twitter, my blog, google plus and
> elsewhere.
>
> help welcome.
>
It also appears in the first paragraph of "Contributing" in the dev
guide - which is pointed to by the main page at python.org (Core
Develop
On Fri, Feb 10, 2012 at 23:56, Terry Reedy wrote:
> On 2/10/2012 9:06 AM, Eli Bendersky wrote:
>
>> Whenever the Python core development team decides that a new package
>> should be
>> included into the standard library, but isn't entirely sure about whether
>> the
>> package's API is optimal, the
On Fri, Feb 10, 2012 at 22:13, Jim J. Jewett wrote:
>
> Eli Bendersky wrote (in
> http://mail.python.org/pipermail/python-dev/2012-February/116393.html ):
>
>> A package will be marked provisional by including the
>> following paragraph as a note at the top of its
>> documentation page:
>
> I real
On Fri, Feb 10, 2012 at 20:33, Brett Cannon wrote:
> Other than the misspelling of "maintenante" instead of "maintenance", LGTM.
>
Fixed that and another typo (thanks 'aspell' :-] )
Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
A protagonist writes:
> -- Forwarded message --
> From: Fredrik Lundh
As a not-directly-concerned third party who's been lurking, it seems
to me like people are in way too much of a rush to "get things done".
Sending direct mail, addressing the precise question[1] seems to have
Jim J. Jewett wrote:
Eli Bendersky wrote (in
http://mail.python.org/pipermail/python-dev/2012-February/116393.html ):
A package will be marked provisional by including the
following paragraph as a note at the top of its
documentation page:
I really would like some marker available from withi
I've been trying to publicize it on twitter, my blog, google plus and
elsewhere.
help welcome.
On Friday, February 10, 2012 at 8:27 PM, Mark Lawrence wrote:
> Hi all,
>
> I'd never heard of this until some Dutch geezer whose name I'm now
> forgotten pointed me to it. Had I known about it
Hi all,
I'd never heard of this until some Dutch geezer whose name I'm now
forgotten pointed me to it. Had I known about it a couple of years ago
it would have saved a lot of people a lot of grief. Please could it be
given a bit of publicity.
--
Cheers.
Mark Lawrence.
p.s. The Dutch geez
On Sat, Feb 11, 2012 at 11:23 AM, PJ Eby wrote:
> What's the downside in that case? You're trying to import something that
> just changed in the last fraction of a second... why?
I don't know if it's normal in the Python world, but these sorts of
race conditions occur most annoyingly when a sin
On Feb 10, 2012 3:38 PM, "Brett Cannon" wrote:
> On Fri, Feb 10, 2012 at 15:07, PJ Eby wrote:
>> On Fri, Feb 10, 2012 at 1:05 PM, Brett Cannon wrote:
>>> First is that if this were used on Windows or OS X (i.e. the OSs we
support that typically have case-insensitive filesystems), then this
appro
On Fri, Feb 10, 2012 at 1:13 PM, Jim J. Jewett wrote:
>
> Eli Bendersky wrote (in
> http://mail.python.org/pipermail/python-dev/2012-February/116393.html ):
>
>> A package will be marked provisional by including the
>> following paragraph as a note at the top of its
>> documentation page:
>
> I re
2012/2/10 "Martin v. Löwis" :
>> 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.
>
> Indeed, and that precedent should be enough reason *not* to include a
> "locale" encoding. The "mbcs" encodi
On 2/10/2012 9:06 AM, Eli Bendersky wrote:
Whenever the Python core development team decides that a new package should be
included into the standard library, but isn't entirely sure about whether the
package's API is optimal, the package can be included and marked as
"provisional".
In the next
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/10/2012 04:42 PM, Brett Cannon wrote:
> On Fri, Feb 10, 2012 at 16:29, Tres Seaver
> wrote:
>
>> On 02/10/2012 03:38 PM, Brett Cannon wrote:
>>> Changes in any fashion to the directory. Do filesystems
>>> atomically update the mtime of a direct
On Fri, Feb 10, 2012 at 16:29, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 02/10/2012 03:38 PM, Brett Cannon wrote:
> > Changes in any fashion to the directory. Do filesystems atomically
> > update the mtime of a directory when they commit a change? Otherwise
> > w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/10/2012 03:38 PM, Brett Cannon wrote:
> Changes in any fashion to the directory. Do filesystems atomically
> update the mtime of a directory when they commit a change? Otherwise
> we have a potential race condition.
Hmm, maybe I misundersand y
On Fri, Feb 10, 2012 at 15:07, PJ Eby wrote:
> On Fri, Feb 10, 2012 at 1:05 PM, Brett Cannon wrote:
>
>>
>>
>> On Thu, Feb 9, 2012 at 17:00, PJ Eby wrote:
>>
>>> I did some crude timeit tests on frozenset(listdir()) and trapping
>>> failed stat calls. It looks like, for a Windows directory the
Eli Bendersky wrote (in
http://mail.python.org/pipermail/python-dev/2012-February/116393.html ):
> A package will be marked provisional by including the
> following paragraph as a note at the top of its
> documentation page:
I really would like some marker available from within Python
itself.
On Fri, Feb 10, 2012 at 1:05 PM, Brett Cannon wrote:
>
>
> On Thu, Feb 9, 2012 at 17:00, PJ Eby wrote:
>
>> I did some crude timeit tests on frozenset(listdir()) and trapping failed
>> stat calls. It looks like, for a Windows directory the size of the 2.7
>> stdlib, you need about four *failed*
Other than the misspelling of "maintenante" instead of "maintenance", LGTM.
On Fri, Feb 10, 2012 at 09:06, Eli Bendersky wrote:
> Hi all,
>
> Following the intensive and fruitful discussion of the (now rejected)
> PEP 408 (
> http://mail.python.org/pipermail/python-dev/2012-January/115850.html),
On Thu, Feb 9, 2012 at 17:00, 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://mail.sc
ACTIVITY SUMMARY (2012-02-03 - 2012-02-10)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open3246 ( -2)
closed 22523 (+57)
total 25769 (+55)
Open issues wit
> """A common pattern in Python 2.x is to have one version of a module
> implemented in pure Python, with an optional accelerated version
> implemented as a C extension; for example, pickle and cPickle. This
> places the burden of importing the accelerated version and falling
> back on the pure Py
On Fri, Feb 10, 2012 at 9:26 PM, Eli Bendersky wrote:
> -- Forwarded message --
> From: Fredrik Lundh
> Date: Fri, Feb 10, 2012 at 13:16
> Subject: Re: maintenance of the ElementTree / cElementTree packages in
> the Python standard library
> To: Eli Bendersky
>
>
> Hi Eli, thanks
Hi all,
Following the intensive and fruitful discussion of the (now rejected)
PEP 408 (http://mail.python.org/pipermail/python-dev/2012-January/115850.html),
we've drafted PEP 411 to summarize the conclusions with regards to the
process of marking packages provisional. Note that this is an
informa
2012/2/10 Nick Coghlan :
>
> Most orphan modules in the stdlib aren't like that - yes, their APIs
> stagnate (because nobody feels they have the authority and/or
> expertise to make potentially controversial decisions), but for many
> of them, that's not a particularly bad thing.
You're right, and
On Fri, Feb 10, 2012 at 7:37 PM, "Martin v. Löwis" wrote:
> Notice that the last time something like this came up (bsddb), it
> actually resulted in a removal of the respective package from the
> standard library.
bsddb was a *very* different case - it was actively causing buildbot
stability prob
In article ,
Ned Deily wrote:
> However, this may all be a moot point now as I've subsequently proposed
> a patch to Distutils to smooth over the problem by checking for the case
> of gcc-4.2 being required but not available and, if so, automatically
> substituting clang instead. (http://bugs
-- Forwarded message --
From: Fredrik Lundh
Date: Fri, Feb 10, 2012 at 13:16
Subject: Re: maintenance of the ElementTree / cElementTree packages in
the Python standard library
To: Eli Bendersky
Hi Eli, thanks for reaching out. I'll get back to you with a more
"formal" reply lat
"Martin v. Löwis", 10.02.2012 11:32:
>> What happens now? Do we give up on touching it until Fredrik Lundh
>> decides on a come-back or some person who is willing to commit 5 years
>> is found? Or do we just *keep* maintaining it in the stdlib as we do
>> with other modules, fixing bugs, tests, doc
>> What happens now? Do we give up on touching it until Fredrik Lundh
>> decides on a come-back or some person who is willing to commit 5 years
>> is found? Or do we just *keep* maintaining it in the stdlib as we do
>> with other modules, fixing bugs, tests, documentation and so on?
>
> If we reall
"Martin v. Löwis", 10.02.2012 10:37:
>> Given that it was two months ago that I started the "Fixing the XML
>> batteries" thread (and years since I brought up the topic for the first
>> time), it seems to be hard enough already to get anyone on python-dev
>> actually do something for Python's XML s
> How does this differ from any other module in stdlib that may not have
> a single designated owner, but which at the same time *is* being
> maintained by the core developers as a group? ISTM that requiring a
> five-year commitment is just going to scare any contributors away - is
> that what we w
Hello Fredrik,
Recently a discussion came up on the python-dev mailing list regarding
continued maintenance of the ElementTree & cElementTree packages which
are part of the standard library, and which were originally
contributed by you.
There currently exists an unclear situation with respect to
On Fri, Feb 10, 2012 at 11:43, "Martin v. Löwis" wrote:
>> IMHO it's no longer a question of "wanting" to take ownership.
>> According to Florent, this has already happened to some extent.
>
> "Ownership to some extent" is not a useful concept. Either you have
> ownership, or you don't.
>
>> I don
> 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.
Indeed, and that precedent should be enough reason *not* to include a
"locale" encoding. The "mbcs" encoding has caused much user confusion
over
Eli Bendersky, 10.02.2012 10:06:
> On Fri, Feb 10, 2012 at 10:32, Florent wrote:
>> 2012/2/10 Eli Bendersky
>>>
>>> Thanks for the input, Florent. So, to paraphrase, there already are
>>> code changes in the stdlib version of ET/cET which are not upstream.
>>> You made it explicit about the te
> IMHO it's no longer a question of "wanting" to take ownership.
> According to Florent, this has already happened to some extent.
"Ownership to some extent" is not a useful concept. Either you have
ownership, or you don't.
> I don't mind sending Fredrik an email as you detailed. Any suggested
>
PyPy 1.8 - business as usual
We're pleased to announce the 1.8 release of PyPy. As habitual this
release brings a lot of bugfixes, together with performance and memory
improvements over the 1.7 release. The main highlight of the release
is
> That makes me consider it the reality that "today, ET is only being
> maintained in the stdlib".
I think different people will have different perceptions of reality here.
In my interaction with Fredrik Lundh, I got the impression that he might
consider code still maintained even if he didn't to
On Fri, Feb 10, 2012 at 10:32, Florent wrote:
> 2012/2/10 Eli Bendersky
>> >
>>
>> Thanks for the input, Florent. So, to paraphrase, there already are
>> code changes in the stdlib version of ET/cET which are not upstream.
>> You made it explicit about the tests, so the question is only left for
Victor Stinner writes:
> > 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
2012/2/10 Eli Bendersky
> >
>
> Thanks for the input, Florent. So, to paraphrase, there already are
> code changes in the stdlib version of ET/cET which are not upstream.
> You made it explicit about the tests, so the question is only left for
> the modules themselves. Is that right?
>
The port o
48 matches
Mail list logo
