The PS: at the top of Misc/ACKS says:
PS: In the standard Python distribution, this file is encoded in UTF-8
and the list is in rough alphabetical order by last names.
However, the last 3 names in the list don't appear to be part of that
alphabetical order. Is this somehow intentional, or just a
The key point here is that it is *rough* alphabetic order. IMO, sorting
accented characters along with their unaccented versions would be fine
as well, and be more practical. In general, it's not possible to provide
a correct alphabetic order. For example, in German, 'ö' sorts after
'o',
Hi,
Our Hg repo has some useful hooks on commit messages that allow to
specify which issue to notify for commits, and which issue to close.
AFAIU, it's currently documented only in the code of the hook
(http://hg.python.org/hooks/file/tip/hgroundup.py).
I think adding a short description into
Our Hg repo has some useful hooks on commit messages that allow to
specify which issue to notify for commits, and which issue to close.
AFAIU, it's currently documented only in the code of the hook
(http://hg.python.org/hooks/file/tip/hgroundup.py).
I think adding a short description into
http://hg.python.org/cpython/rev/87ecfd5cd5d1
changeset: 73541:87ecfd5cd5d1
branch: 2.7
parent: 73529:c3b063c82ae5
user: Eli Benderskyeli...@gmail.com
date: Mon Nov 14 01:02:20 2011 +0200
summary:
Normalize the keyword arguments documentation notation in re.rst.
Hi there,
I was doing some experiments with the buffer interface of bytearray today,
for the purpose of quickly reading a file's contents into a bytearray which
I can then modify. I decided to do some benchmarking and ran into
surprising results. Here are the functions I was timing:
def
On Thu, Nov 24, 2011 at 20:29, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 24 Nov 2011 20:15:25 +0200
Eli Bendersky eli...@gmail.com wrote:
Oops, readinto takes the same time as copying. This is a real shame,
because readinto in conjunction with the buffer interface was supposed
On Fri, Nov 25, 2011 at 00:02, Matt Joiner anacro...@gmail.com wrote:
What if you broke up the read and built the final string object up. I
always assumed this is where the real gain was with read_into.
Matt, I'm not sure what you mean by this - can you suggest the code?
Also, I'd be happy to
On Thu, 24 Nov 2011 20:53:30 +0200
Eli Bendersky eli...@gmail.com wrote:
Sure. Updated the default branch just now and built:
$1 -m timeit -s'import fileread_bytearray'
'fileread_bytearray.justread()'
1000 loops, best of 3: 1.14 msec per loop
$1 -m timeit -s'import
Eli, the use pattern I was referring to is when you read in chunks,
and and append to a running buffer. Presumably if you know in advance
the size of the data, you can readinto directly to a region of a
bytearray. There by avoiding having to allocate a temporary buffer for
the read, and
However, the original question remains - on the 100MB file also, although
in 2.7 readinto is 35% faster than readandcopy(), on 3.2 it's about the
same speed (even a few % slower). That said, I now observe with Python
3.3
the same speed as with 2.7, including the readinto() speedup - so it
On Fri, Nov 25, 2011 at 14:02, Matt Joiner anacro...@gmail.com wrote:
I was under the impression this is already in 3.3?
Sure, but 3.3 wasn't released yet.
Eli
P.S. Top-posting again ;-)
___
Python-Dev mailing list
Python-Dev@python.org
On Sat, Dec 10, 2011 at 00:43, Matt Joiner anacro...@gmail.com wrote:
I second this. The doco is very bad.
It would be constructive to open issues for specific problems in the
documentation. I'm sure this won't be hard to fix. Documentation should not
be the roadblock for using a library.
Eli
On Fri, Dec 16, 2011 at 11:00, Stefan Krah ste...@bytereef.org wrote:
Victor Stinner victor.stin...@haypocalc.com wrote:
Do you know simple task to start contributing to Python? Something
useful and not boring if possible :-) There is the easy tag on the bug
tracker, but many issues have a
A then-related question is whether Python 3.3 should be compiled with
Visual
Studio 11. I'd still be in favor of that, provided Microsoft manages to
release
that soon enough.
Martin, I assume you mean the Express version of Visual Studio 11 here,
right?
Eli
The section is still available in the cpython repo, and I'm waiting to
remove it because it's better to have some redirections in place from
the current urls to the new ones. I've prepared a small set of
RewriteRules (attached): I don't know the actual setup of apache for
docs.p.o but at
2012/1/15 Łukasz Langa luk...@langa.pl
Gentlemen, www.python.org is down at the moment.
Well, it's back now: http://www.downforeveryoneorjustme.com/python.org
Eli
___
Python-Dev mailing list
Python-Dev@python.org
Eli
---
PEP: 408
Title: Standard library __preview__ package
Version: $Revision$
Last-Modified: $Date$
Author: Nick Coghlan ncogh...@gmail.com,
Eli Bendersky eli...@gmail.com
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2012-01-07
Python
Assuming the module is then promoted to the the standard library proper in
release ``3.X+1``, it will be moved to a permanent location in the library::
import example
And importing it from ``__preview__`` will no longer work.
Why not leave it accessible through __preview__ too?
I
Something along the lines of :
if sys.version_info[:2] == (3, X):
from __preview__ import example
else:
raise ImportError( 'Package example is only available as preview in
Python version 3.X. Please check the documentation of your version of
Python to see if and how you can
On Fri, Jan 27, 2012 at 17:34, Benjamin Peterson benja...@python.org wrote:
2012/1/27 Eli Bendersky eli...@gmail.com:
Criteria for graduation
-
I think you also need Criteria for being placed in __preview__. Do
we just toss everything someone suggests in?
I hoped
No, potentially wrong in cases where the APIs are different. Even with the
try...except ImportError dance around StringIO / cStringIO there are some
API differences. But for a lot of use cases it works fine (simplejson and
json aren't *identical*, but it works for most people).
Okay,
On Sat, Jan 28, 2012 at 07:41, Stephen J. Turnbull step...@xemacs.org wrote:
Eli Bendersky writes:
My point is that if our users accept *this*, in the stable stdlib, I
see no reason they won't accept the same happening between __preview__
and a graduated module, when they (hopefully
On Sun, Jan 29, 2012 at 17:34, Andrea Crotti andrea.crott...@gmail.com wrote:
I have a newbie question about CPython.
Looking at the C code I noted that for example in tupleobject.c there is
only one include
#include Python.h
Python.h actually includes everything as far as I can I see so:
-
On Fri, Feb 3, 2012 at 22:14, Ethan Furman et...@stoneleaf.us wrote:
Good news! PEP 409 has been accepted!
Not so good news: There is no one assigned to Issue 6210 to review the
patches... any volunteers?
http://bugs.python.org/issue6210
Hi Ethan,
I've just looked at PEP 409 online
On Fri, Dec 9, 2011 at 10:02, Stefan Behnel stefan...@behnel.de wrote:
Hi everyone,
I think Py3.3 would be a good milestone for cleaning up the stdlib support
for XML. Note upfront: you may or may not know me as the maintainer of lxml,
the de-facto non-stdlib standard Python XML tool. This
What should change?
a) The stdlib documentation should help users to choose the right tool right
from the start. Instead of using the totally misleading wording that it uses
now, it should be honest about the performance characteristics of MiniDOM
and should actively suggest that those who
On one hand I agree that ET should be emphasized since it's the better
API with a much faster implementation. But I also understand Martin's
point of view that minidom has its place, so IMHO some sort of
compromise should be reached. Perhaps we can recommend using ET for
those not
Hello,
Here's a note from What's new in Python 3.0:
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
On Wed, Feb 8, 2012 at 06:41, Fred Drake fdr...@acm.org wrote:
On Tue, Feb 7, 2012 at 11:31 PM, Eli Bendersky eli...@gmail.com wrote:
Besides, in
http://mail.python.org/pipermail/python-dev/2011-December/114812.html
Stefan Behnel said [...] Today, ET is *only* being maintained in the
stdlib
On Wed, Feb 8, 2012 at 06:15, Nick Coghlan ncogh...@gmail.com wrote:
On Wed, Feb 8, 2012 at 1:59 PM, Eli Bendersky eli...@gmail.com wrote:
Is there a good reason why xml.etree.ElementTree /
xml.etree.cElementTree did not receive this treatment?
See PEP 360, which lists Externally Maintained
On Wed, Feb 8, 2012 at 07:10, Fred Drake fdr...@acm.org wrote:
On Tue, Feb 7, 2012 at 11:46 PM, Eli Bendersky eli...@gmail.com wrote:
The initial proposal of changing *the stdlib
import facade* for xml.etree.ElementTree to use the C accelerator
(_elementtree) by default.
I guess this is one
The facade can be added to xml/etree/ElementTree.py since that's the
only documented module. It can attempt to do:
from _elementtree import *
(which is what cElementTree.py) does, and on failure, just go on doing
what it does now.
Basically, cElementTree (actually the accelerator module)
On Wed, Feb 8, 2012 at 11:36, Dirkjan Ochtman dirk...@ochtman.nl wrote:
On Wed, Feb 8, 2012 at 08:37, Stefan Behnel stefan...@behnel.de 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
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 in the
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
On Fri, Feb 10, 2012 at 10:32, Florent florent.xicl...@gmail.com wrote:
2012/2/10 Eli Bendersky eli...@gmail.com
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
On Fri, Feb 10, 2012 at 11:43, Martin v. Löwis mar...@v.loewis.de 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
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
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 really can't
-- Forwarded message --
From: Fredrik Lundh fred...@pythonware.com
Date: Fri, Feb 10, 2012 at 13:16
Subject: Re: maintenance of the ElementTree / cElementTree packages in
the Python standard library
To: Eli Bendersky eli...@gmail.com
Hi Eli, thanks for reaching out. I'll get
in the Python standard library
Version: $Revision$
Last-Modified: $Date$
Author: Nick Coghlan ncogh...@gmail.com,
Eli Bendersky eli...@gmail.com
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 2012-02-10
Python-Version: 3.3
Post-History: 2012-02-10
Abstract
snip
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
On Fri, Feb 10, 2012 at 20:33, Brett Cannon br...@python.org 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
On Fri, Feb 10, 2012 at 22:13, Jim J. Jewett jimjjew...@gmail.com 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
On Fri, Feb 10, 2012 at 23:56, Terry Reedy tjre...@udel.edu 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
On Sat, Feb 11, 2012 at 03:38, Jesse Noller jnol...@gmail.com 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
On Sat, Feb 11, 2012 at 08:27, Nick Coghlan ncogh...@gmail.com wrote:
On Sat, Feb 11, 2012 at 1:14 PM, Eli Bendersky eli...@gmail.com 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
Eli, quite frankly no :(
The stock answer put it on the main page at python.org if actually
followed up in all cases would result in something unreadable, as the page
would be too noisy and displayed in something like Palatino size 1 (if there
is such a thing).
I'm just crossing my fingers
Since there appeared to be an overall positive response for making
this change in Python 3.3, and since there isn't longer any doubt
about the ownership of the package *in Python's stdlib* (see
http://mail.python.org/pipermail/python-dev/2012-February/116389.html),
I've opened issue 13988 on
The change was committed to the default branch. In 3.3, import
xml.etree.ElementTree will automatically use the _elementtree accelerator,
if available, and will fall back to a Python implementation otherwise. The
documentation of ElementTree has also been updated to reflect this fact.
An
Currently in 3.3 the whole cElementTree module is:
# Deprecated alias for xml.etree.ElementTree
from xml.etree.ElementTree import *
Would it be alright to issue a DeprecationWarning if this module is
imported? Then hopefully a couple of releases after 3.3 we can just dump
it.
I'd still like to know who is in charge of the etree package now. I know
that I'm not, so I just don't have any opinion on the technical question
of using the accelerator module (it sounds like a reasonable idea, but
it also sounds like something that may break existing code). If the
On Fri, Feb 17, 2012 at 05:50, Nick Coghlan ncogh...@gmail.com wrote:
On Fri, Feb 17, 2012 at 2:09 AM, eli.bendersky
python-check...@python.org wrote:
diff --git a/Lib/test/test_xml_etree_c.py b/Lib/test/test_xml_etree_c.py
--- a/Lib/test/test_xml_etree_c.py
+++
On Mon, Feb 20, 2012 at 01:12, Martin v. Löwis mar...@v.loewis.de wrote:
The change of backing ElementTree by cElementTree has already been
implemented in the default branch (3.3) by Florent Xicluna with careful
review from me and others. etree has an extensive (albeit a bit clumsy)
set
On Tue, Feb 21, 2012 at 00:51, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Feb 21, 2012 at 1:55 AM, mar...@v.loewis.de wrote:
Basically, if something is just documented as being callable without
subclassing or instance checks being mentioned as supported in the
docs, it can be
On Tue, Feb 21, 2012 at 03:59, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Feb 21, 2012 at 11:39 AM, Eli Bendersky eli...@gmail.com wrote:
So the two choices here are either change the documentation or the C
implementation to actually make Element a class. The first is of course
simpler
I'm happy to stand up as an example of someone who uses a custom Element
class. My specific use case is loading the project Gutenberg database,
which is a 210MB XML file. I created a custom Element class which I use
for the top-level element (a custom element_factory passed to
TreeBuilder
I can't fathom why someone would do it though, since bar tiny
differences (like this one) cET is just a faster ET and it's available
practically everywhere with CPython. I mean, is it really important to
be able to subclass ET.Element? What goal does it serve?
Statements like this make
On Sat, Feb 25, 2012 at 12:20, Martin v. Löwis mar...@v.loewis.de wrote:
I find that strange, especially for an expert Python dev. I, a newbie,
find it far friendlier (and easier for a new programmer to grasp).
Maybe it's because I use it all the time, and you don't?
That is most likely
Indeed, that note was written before we decided that getting rid of
% formatting altogether would be a bad idea.
It would be better to update it to say something like:
The formatting operations described here are modelled on C's printf()
syntax. They only support formatting of certain
It probably wouldn't be very difficult to make element_new() the tp_new
of Element_Type, and expose that type as Element.
That would settle the issue nicely and avoid compatibility concerns :)
Regards
I guess it's not as simple as that. element_new doesn't quite have the
signature required
On Sun, Feb 26, 2012 at 12:33, pmon mail pmon.m...@gmail.com wrote:
Hi
I have found myself in the following troubling situation.
I'm running the following code on a Python 2.6.5 on Linux x86:
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
Type help, copyright,
- The formatting operations described here are obsolete and may go away
in future
- versions of Python. Use the new :ref:`string-formatting` in new code.
+ The formatting operations described here are modelled on C's printf()
+ syntax. They only support formatting of certain
On Sun, Feb 26, 2012 at 15:09, Paul Moore p.f.mo...@gmail.com wrote:
On 26 February 2012 12:34, Eli Bendersky eli...@gmail.com wrote:
On Sun, Feb 26, 2012 at 12:33, pmon mail pmon.m...@gmail.com wrote:
Documentation clearly states that the 'L' is a 4 byte integer.
Is this a bug? I'm I
It would be nice to call it something else than printf-style
formatting. While it is certainly modelled on printf(), knowledge of C
or printf is not required to understand %-style formatting, nor even to
appreciate it.
+1. The section is already titled old string formatting operations so if
Rationale
=
A frozendict mapping cannot be changed, but its values can be mutable
(not hashable). A frozendict is hashable and so immutable if all
values are hashable (immutable).
The wording of the above seems very unclear to me.
Do you mean A frozendict has a constant set
The frozenset type covers a niche case that is nice-to-have but
*rarely* used. Many experienced Python users simply forget
that we have a frozenset type. We don't get bug reports or
feature requests about the type. When I do Python consulting
work, I never see it in a client's codebase.
I have updated PEP 411, following the input from this discussion. The
updated PEP is at: http://hg.python.org/peps/file/default/pep-0411.txt
Changes:
- Specified that a package may remain provisional for longer than a single
minor release
- Shortened the suggested documentation notice, linking
Hello,
I find a strange discrepancy in Python with regards to slice
subscripting of objects, at the C API level. I mean things like
obj[start:end:step].
I'd expect slice subscripts to be part of the sequence interface, and
yet they are not. In fact, they are part of the mapping interface. For
This doesn't align well with the documentation, in at least two places.
snip
Another place is in http://docs.python.org/dev/reference/datamodel.html:
object.__getitem__(self, key)
Called to implement evaluation of self[key]. For sequence types,
the accepted keys should be integers and
On Sat, Mar 3, 2012 at 11:24, Stefan Behnel stefan...@behnel.de wrote:
Eli Bendersky, 03.03.2012 09:36:
I find a strange discrepancy in Python with regards to slice
subscripting of objects, at the C API level. I mean things like
obj[start:end:step].
I'd expect slice subscripts to be part
I'd expect slice subscripts to be part of the sequence interface, and
yet they are not. In fact, they are part of the mapping interface. For
example, the list object has its slice get/set methods assigned to a
PyMappingMethods struct. So does a bytes object, and pretty much every
other object
On Sat, Mar 3, 2012 at 19:58, Guido van Rossum gu...@python.org wrote:
On Sat, Mar 3, 2012 at 4:20 AM, Antoine Pitrou solip...@pitrou.net wrote:
I'd expect slice subscripts to be part of the sequence interface, and
yet they are not. In fact, they are part of the mapping interface. For
example,
Thomas Wouters, 03.03.2012 21:59:
Why even have separate tp_as_sequence and tp_as_mapping anymore? That
particular distinction never existed for Python types, so why should it
exist for C types at all? I forget if there was ever a real point to it,
but all it seems to do now is create
This fix should be applied to the documentation as well.
On Tue, Mar 6, 2012 at 08:59, larry.hastings python-check...@python.org wrote:
http://hg.python.org/cpython/rev/d8f68195210e
changeset: 75448:d8f68195210e
user: Larry Hastings la...@hastings.org
date: Mon Mar 05 22:59:13
On Tue, Mar 13, 2012 at 05:07, R. David Murray rdmur...@bitdance.com wrote:
I don't like any of the suggested wordings. I have no problem with
us recommending other modules, but most of the Python libraries are
perfectly functional (not leaky or some other pejorative), they just
aren't as
On Tue, Mar 13, 2012 at 05:25, C. Titus Brown c...@msu.edu wrote:
On Tue, Mar 13, 2012 at 05:22:45AM +0200, Eli Bendersky wrote:
On Tue, Mar 13, 2012 at 05:07, R. David Murray rdmur...@bitdance.com wrote:
I don't like any of the suggested wordings. ?I have no problem with
us recommending
On Tue, Mar 13, 2012 at 06:43, Guido van Rossum gu...@python.org wrote:
On Mon, Mar 12, 2012 at 9:23 PM, Brian Curtin br...@python.org wrote:
Downloads don't mean the code is good. Voting is gamed. I really don't
think there's a good automated solution to tell us what the
high-quality
Rather than indicating apathy on the party of third party developers, this
might be a sign that core Python is unapproachable or not worth the effort.
For instance I have several one line patches languishing, I can't imagine
how disappointing it would be to have significantly larger patches
Hi,
[Terry suggested in http://bugs.python.org/issue13782 to raise this
dilemma to python-dev. I concur.]
The Element class in ElementTree
(http://docs.python.org/py3k/library/xml.etree.elementtree.html) has
some methods for adding new children: append, insert and extend.
Currently the
, with a recommendation on the requirement the PEP should
make of provisional modules (process details).
Eli
PEP: 411
Title: Provisional packages in the Python standard library
Version: $Revision$
Last-Modified: $Date$
Author: Nick Coghlan ncogh...@gmail.com,
Eli
On Sun, Mar 25, 2012 at 08:34, Georg Brandl g.bra...@gmx.net wrote:
Here's another try, mainly with default browser font size, more contrast and
collapsible sidebar again:
http://www.python.org/~gbrandl/build/html2/
I've also added a little questionable gimmick to the sidebar (when you
On Sat, Mar 24, 2012 at 13:53, Lennart Regebro rege...@gmail.com wrote:
On Fri, Mar 23, 2012 at 10:51, Eli Bendersky eli...@gmail.com wrote:
The PEP received mostly positive feedback. The only undecided point is
where to specify that the package is provisional. Currently the PEP
mandates
On Sun, Mar 25, 2012 at 21:25, Georg Brandl g.bra...@gmx.net wrote:
On 25.03.2012 21:11, Steven D'Aprano wrote:
Georg Brandl wrote:
Thanks everyone for the overwhelmingly positive feedback. I've committed
the
new design to 3.2 and 3.3 for now, and it will be live for the 3.3 docs
I think the PEP is almost ready for approval. Congratulations! A few comments:
- I'd leave some wiggle room for the docs owner (Georg) about the
exact formulation of the text blurb included for provisional modules
and the glossary entry; I don't want the PEP to have the last word
here.
I've marked it up as Approved. Thanks, and congrats!
Thanks!
Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Tue, Mar 27, 2012 at 05:34, Guido van Rossum gu...@python.org wrote:
On Mon, Mar 26, 2012 at 8:23 PM, Eli Bendersky eli...@gmail.com wrote:
I think the PEP is almost ready for approval. Congratulations! A few
comments:
- I'd leave some wiggle room for the docs owner (Georg) about
On Fri, Mar 30, 2012 at 21:30, Benjamin Peterson benja...@python.orgwrote:
+def test_cyclic_gc(self):
+class ShowGC:
+def __init__(self, flaglist):
+self.flaglist = flaglist
+def __del__(self):
+
Quoting from
http://www.python.org/dev/peps/pep-0008/#other-recommendations
(with elision):
Use spaces around arithmetic operators:
No:
i=i+1
submitted +=1
x = x*2 - 1
hypot2 = x*x + y*y
c = (a+b) * (a-b)
End quote.
I agree that this could be
* PEP 3144: IP Address manipulation library
This is pretty close to approval. Peter's addressed all the
substantive comments that were made regarding the draft API, and he's
going to provide an update to the PEP shortly that should get it into
a state where I can mark it as Approved.
On Tue, May 1, 2012 at 16:43, Benjamin Peterson benja...@python.org wrote:
2012/5/1 Eli Bendersky eli...@gmail.com:
Will this package go through the provisional state mandated by PEP 411 ?
I don't see PEP 411 requiring any module to go through its process.
You're right, it doesn't require
As per PEP 3108, we were supposed to merge profile/cProfile into one
unified module. I initially championed the change, but other things got in
the way and I have never got to the point of a useful patch. I posted some
code and outlined an approach how the merge could be done. However, there
On Sun, Jun 3, 2012 at 6:01 AM, Benjamin Peterson benja...@python.org wrote:
2012/6/2 solip...@pitrou.net:
results for d9b7399d9e45 on branch default
test_smtplib leaked [154, 154, 154] references, sum=462
Can other people reproduce this one? I
On Sun, May 20, 2012 at 10:38 AM, Nick Coghlan ncogh...@gmail.com wrote:
When writing the docs for types.new_class(), I discovered that the
description of the class creation process in the language reference
was not only hard to follow, it was actually *incorrect* when it came
to describing
Can you add a testcase for this?
On Mon, Jun 4, 2012 at 9:01 PM, richard.oudkerk
python-check...@python.org wrote:
http://hg.python.org/cpython/rev/3baeb5e13dd2
changeset: 77348:3baeb5e13dd2
user: Richard Oudkerk shibt...@gmail.com
date: Mon Jun 04 18:59:07 2012 +0100
On Tue, Jun 5, 2012 at 10:18 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Jun 5, 2012 at 1:24 PM, Eli Bendersky eli...@gmail.com wrote:
if an explicit metaclass is given and it is not an instance of
type(), then it is used directly as the metaclass
Could you elaborate on this point
Hi pydev,
I was looking at the memory allocation strategy of dict, out of
curiosity, and noted that Objects/dictnotes.txt is out of date as far
as the parameters go. It says about PyDict_STARTSIZE:
* PyDict_STARTSIZE. Starting size of dict (unless an instance dict).
Currently set to 8.
I was looking at the memory allocation strategy of dict, out of
curiosity, and noted that Objects/dictnotes.txt is out of date as far
as the parameters go. It says about PyDict_STARTSIZE:
* PyDict_STARTSIZE. Starting size of dict (unless an instance dict).
Currently set to 8. Must
1 - 100 of 444 matches
Mail list logo
