On Mar 16, 2010, at 9:41 AM, Guido van Rossum wrote:
I'd say if you're not going to forward-port this to Python 3, it
shouldn't go into Python 2 -- in that case it would make more sense to
me to back-port the exception-raising behavior.
Python 3 doesn't need it because it is possible to
On Tue, Mar 2, 2010 at 15:55, Florent Xicluna florent.xicl...@gmail.com
wrote:
Hello,
I would like to open a discussion on the meaning of deprecation warnings in
2.7.
I assume, but I may be wrong, that 2.7 will be the last version in the 2.x
branch. With this assumption, we should
On Feb 9, 2010, at 9:54 PM, anatoly techtonik wrote:
Is it possible to make exploits out of crashers?
The crashers involve creating convoluted python code,
but then if you're in a position to execute arbitrary
Python code, then you don't have to resort to any
tricks to do something nasty
+1
On Feb 2, 2010, at 10:08 AM, Barry Warsaw wrote:
I'm thinking about doing a Python 2.6.5 release soon. I've added the
following dates to the Python release schedule Google calendar:
2009-03-01 Python 2.6.5 rc 1
2009-03-15 Python 2.6.5 final
This allows us to spend some time on 2.6.5
On Jan 30, 2010, at 4:00 PM, Barry Warsaw wrote:
Abstract
This PEP describes an extension to Python's import mechanism which
improves sharing of Python source code files among multiple installed
different versions of the Python interpreter.
+1
It does this by
allowing many
On Jan 27, 2010, at 11:38 AM, Martin v. Löwis wrote:
Lists are indeed used *everywhere* and *vast* quantities, which is
why optimizations on list operations are worthwhile to pursue.
Unfortunately, the proposed change is a pessimisation, not an
optimisation. We probably shouldn't discuss
Are you free to chat about this in IRC?
I completely unconvinced that there are use cases for
wanting face random access to the i-th element of a large deque
that is changing sizes on each end. The meaning of the
20th index changes as the data moves. It becomes pointless
to store indices to
On Jan 27, 2010, at 2:56 PM, Steve Howell wrote:
--- On Wed, 1/27/10, Raymond Hettinger raymond.hettin...@gmail.com wrote:
From: Raymond Hettinger raymond.hettin...@gmail.com
Subject: Re: [Python-Dev] patch to make list.pop(0) work in O(1) time
To: Martin v. Löwis mar...@v.loewis.de
Cc
On Jan 27, 2010, at 3:55 PM, Maciej Fijalkowski wrote:
FWIW, deque indexing for small deques is already O(1)
and somewhat fast. You only get O(n) degradation
(with a small contant factor) on large deques.
Hi.
For small dequeues (smaller than a constant), you have to have O(1)
Ah, but that applies for *large* lists. Adding 8 bytes to
each list
object applies to *all* lists. I betcha that many programs
use many
tiny lists.
Even most tiny-ish lists are wasting memory, though, according to this
sequence:
4, 8, 16, 25, ...
That is only is they are being
On Jan 25, 2010, at 11:22 AM, Steve Howell wrote:
I am interested in creating a patch to make deleting elements from the front
of Python list work in O(1) time by advancing the ob_item pointer.
+1 on doing whatever experiments you feel like doing
-1 on putting something like this in the core
On Jan 25, 2010, at 12:36 PM, Steve Howell wrote:
Deque does not support all the operations that list does. It is also roughly
twice as slow for accessing elements (I've measured it).
ISTM that apps that want to insert or pop from the front of list are also apps
that don't care about
[Jacob Kaplan-Moss]
I've already started on a patch to make comments an option that
package maintainers could turn on or off, but I don't want to waste
any more time fighting this code unless I have some assurance it'll be
checked in.
I support your efforts.
Raymond
[Guido van Rossum]
. We used to have releases once a year and
we got really big serious feedback from our biggest users that the
release cycle was going too fast. We discussed it amply and agreed on
a minimum time of 18 months between releases.
If the language moratorium goes into effect,
[MvL]
I personally think that decoupling the releases would be best, i.e.
not start thinking about 3.2 for another 6 months.
[Benjamin]
The problem with that is that there is a period of time where 2.x has
features which 3.x doesn't. My preference is to move back the whole
schedule 6
[Stefan Krah]
in a (misguided) bugreport (http://bugs.python.org/issue7279) I was
questioning the reasons for allowing NaN comparisons with == and !=
rather than raising InvalidOperation.
Do you have any actual use case issues or are these theoretical musings?
I ask only because a good use
[GvR]
I haven't seen substantial opposition against the PEP -- in fact I
can't recall any, and many people have explicitly posted in support of
it. So unless opposition suddenly appears in the next few days, I'll
move it to the Accepted state next Monday.
But it would have been so much fun to
[Chris Bergstresser]
Clearly, I'll need to write up the PEP.
Why not write a short, fast get_first() function for your utils directory and
be done with it?
That could work with sets, mappings, generators, and other containers and
iterators.
No need to fatten the set/frozenset API for
[me]
Why not write a short, fast get_first() function for your utils directory and
be done with it?
That could work with sets, mappings, generators, and other containers and
iterators.
No need to fatten the set/frozenset API for something so trivial and so rarely
needed.
Forgot to post the
[Steven D'Aprano]
Anyway, given the level of opposition to the suggestion, I'm no longer
willing to carry the flag for it. If anyone else -- perhaps the OP --
feels they want to take it any further, be my guest.
[geremy condra]
I've said before that I'd like there to be one, standard way of
[Michael Foord]
What will it take to *start* the port? (Or is it already underway?) For many projects I fear that it is only the impending
obsolescence (real rather than theoretical) of Python 2 that will convince projects to port.
FWIW, I do not buy into the several premises that have arisen
Personally, I have found it useful in doco I write to have a section on
Common Tasks, with recommended/suggested examples of how to do them and
short rationale for the chosen method. It seems to me that if .pick()
is frequently desired and None of the standard solutions are obvious
or easily
[Guido van Rossum]
I'm -0 on backporting nonlocal to 2.7. I could be +0 if we added from
__future__ import nonlocal_keyword (or some such phrasing) to enable
it.
With the from __future__ option, what keeps you from being
a full +1 on nonlocal? Is there something that makes it a better
As I said: Python 2 support is not only about supporting old versions of Python,
but also supporting users of Python2-only modules. So 2.7 support will
for the most part be a case not of supporting Python versions, but
Python *users*. And contrary to what Antoine said, that *is* a good
reason to
[Steven D'Aprano]
The suggested
semantics for set.get() with no arguments, as I understand them, are:
(1) it will only fail if the set is empty;
Just like next() except that next() gives you the option to supply a default
and can be used on any iterator (perhaps iter(s) or itertools.cycle(s)
[Chris Bergstresser]
Still, I think my
point stands--it's a clear extrapolation from the existing dict.get().
Not really. One looks-up a key and supplies a default value if not found.
The other, set.get(), doesn't have a key to lookup.
A dict.get() can be meaningfully used in a loop
[geremy condra]
Was it ever decided whether this would fall under the moratorium?
Decided isn't the right word:
http://mail.python.org/pipermail/python-dev/2009-October/093373.html
FWIW, I'm a strong -1 on both proposals.
Just add a short get_one() function and a get_equivalent() recipe
to
[John Arbash Meine]
So 'for x in s: break' is about 2x faster than next(iter(s)) and 3x
faster than (iter(s).next()).
The first version uses direct calls for the for-loop opcodes.
The other two have to do functions/method look-up and
make a pure python function call (neither is very fast).
Chris Bergstresser]
I like the proposed set.get() method, personally.
Sets have been implemented in many languages, but I've only
seen one that implemented this functionality (the arb function
in SETL). For the most part, it seems that this is an uncommon need.
Also consider that
[GvR]
I still wish we could go back in time and unify sets and dicts, if
only to find out how that experiment would turn out.
I'm curious about the outcome of another experiment along those lines.
Is anyone seeing uptake for the set methods on mapping views in Py3.x?
I haven't seen any code
I'm curious about the outcome of another experiment along those lines.
Is anyone seeing uptake for the set methods on mapping views in Py3.x?
Next version of Graphine will use them heavily for graph
merges and set operations on graphs.
That's great! Thanks for the data point.
I look
[Mark Dickinson]
- string to float *and* float to string conversions are both guaranteed
correctly rounded in 3.x: David Gay's code implements the conversion
in both directions, and having correctly rounded string - float
conversions is essential to ensure that eval(repr(x)) recovers x
[Glyph Lefkowitz ]
This reasoning definitely makes sense to me; with all the
dependency-migration
issues 3.x could definitely use some carrots. However, I don't think I agree
with it,
because this doesn't feel like a big new feature, just some behavior which
has changed.
The
[Christian Tanzer]
How do you suppose that maintainers could ever do the transition from
%- to {}-formatting manually?
[Guido van Rossum]
This is pretty much the situation with integer division (you can only
recognize it by running the code),
Do you think there may be some possible
[Steven Bethard]
. Just saying ok, switch your format strings
from % to {} didn't work in Python 3.0 for various good reasons, and
I can't imagine it will work in Python 4.0 unless we have a transition
plan.
Do the users get any say in this?
I imagine that some people are heavily invested in
[Terry Reedy]
I would agree, for instance, that an auto-translation
tool is needed.
We should get one written. ISTM, every %-formatting
string is directly translatable to an equivalent {}-formatting string.
Raymond
___
Python-Dev mailing list
The positional parameter would also mean dicttemplate, and
would be deprecated (eventually requiring a keyword-only
parameter).
Although I hate the name 'dicttemplate', this seems like the best solution
to me. Maybe it's good that 'dicttemplate' is so ugly though so that people
will naturally
[Terry Reedy]
However it is done, I think someone (like new Python programmers) should
be able to program in Python3, and use everything in the stdlib, without
ever learning % formatting -- and that I should be able to forget about
it ;-).
+10 on the goal.
If that were possible, it would
[Sridhar Ratnakumar]
2.6.3rc1 builds fine on Linux x86/x86_64, MacOSX 10.4 ppc/x86, Windows
32bit/64bit, HP-UX, AIX and Solaris just like 2.6.2 did.
Did the test suite pass too?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
I don't know -- this is (from what Peter told me) a common use case so
he (and presumably others) would from time to time have to write
extra code to keep track of that IP address in a new app.
[MvL]
I, and probably others, would really, REALLY like to see one such
common use case. I do
On Sep 17, 2009, at 10:59 AM, Brett Cannon wrote:
On Thu, Sep 17, 2009 at 10:38, Georg Brandl g.bra...@gmx.net wrote:
R. David Murray schrieb:
I floated a proposal on stdlib-sig to create a file named
Misc/maintainers.rst. The purpose of this file is to collect
knowledge
about who knows
And I sort of disagree with saying it's naturally left- or right-
aligned; as numbers are naturally (decimal) dot-aligned (if you use dot
to separate the whole and fractional part of your number).
How about, naturally aligned by place value.
Raymond
I concur. Numbers are naturally right aligned.
On Sep 7, 2009, at 2:46 PM, Eric Smith wrote:
The default string formatting alignment for all types, according to
PEP 3101, is left aligned. Issue 6857 (http://bugs.python.org/issue6857
) points out that for numeric types (int, float, and
On Sep 1, 2009, at 2:54 PM, Benjamin Peterson wrote:
2009/9/1 Brett Cannon br...@python.org:
On Tue, Sep 1, 2009 at 07:21, Benjamin
Petersonbenja...@python.org wrote:
2009/8/31 xiaobing jiang s7v7nisla...@gmail.com:
My idea is: here, the two functions (or maybe classes) should
have the
I was just wondering if a bytecode for a superinstruction of the common
sequence:
6 POP_TOP
7 LOAD_CONST 0 (None)
10 RETURN_VALUE
might be worth it.
[Collin Winter]
I doubt it. You'd save a bit of stack manipulation, but since this
will only appear at the end of a function, I'd be
[Antoine Pitrou]
I also think it would be a nice addition.
(but someone has to propose a patch :-))
I agree with Martin's reasons for rejecting the feature request
(see the bug report for his full explanation). IIRC, the compose()
idea had come-up and been rejected in previous discussions
[Scott David Daniels]
I find I have a need in randomized testing for a shorter version
of getstate, even if it _is_ slower to restore. When running
exhaustive tests, a failure report should show the start state
of the generator. Unfortunately, our current state includes a
625-element array.
On behalf of the Python development team, I'm thrilled to announce the first
production release of Python 3.1.
Sweet!
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Not sure why we need yet another pep on the subject. Just update PEP 5 if
needed.
Also, I think there is a certain amount of wishful thinking here. Ideally, we could approve a tiny PEP with just a few bullet
points and it would eliminate the need for all of the complicated decision making
I don't consider changing a DeprecationWarning to a
PendingDeprecationWarning resurrecting its target.
Seems like resurrection to me. Pending warnings are hidden
by default, so someone has to go look for it (and no one does this).
The problem with the nested() construct is not so much that
it
FWIW, I think resurrecting contextlib.nested() is a bad idea.
Part of the justification for the new with-statement syntax was
that nested() doesn't have a way to finalize the constructors
if one of them fails. It is a pitfall for the unwary. And now
that we have the new with-statement syntax,
[Matthew Wilkes]
Oh, I didn't mean they should use proprietary software, just that in
my experience the kind of people who are active in open source are
quite anti-war, green, etc. There are notable exceptions, but I know
people who worry that their work will have military applications,
[David A. Barrett]
I propose adding the key parameter
to the bisect.bisect routines. This
would allow it to be used on lists with
an ordering other than the one natural
to the contained objects.
Algorithmically, the bisect routines are the wrong place to do key lookups.
If you do many calls
How about we just continue to improve both branches, doing forward or backports
as appropriate. No need to develop a policy of crippling one branch on the
theory that it will make the other seem more attractive.
Besides, if 2.7 and 3.2 get released within a few months of each other, any
[GvR]
Whoa. Are you all suddenly trying to turn Python into a democracy?
Arthur: I am your king!
Woman: Well I didn't vote for you!
Arthur: You don't vote for kings.
Woman: Well how'd you become king then?
[Angelic music plays...]
Arthur: The Lady of the Lake, her arm clad in the purest
[GvR]
Benjamin, what would be involved in removing it? I suppose there's the
module itself, some unit tests, and some docs. (I'm not asking you to
remove it yet -- but I'm asking to look into the consequences, so that
we can be sure to do the right thing before releasing 3.1 final.)
[Benjamin
We could remove it, but then what we have wouldn't really be a release
candidate anymore, so the release would get delayed.
Not true. There is a second release candidate scheduled on June 13th.
Removing the module involves doing svn remove on two files and
updating Misc/NEWS. Yesterday, there
In http://bugs.python.org/issue3959 , Clay McClure is raising some objections to the new ipaddr.py module. JP Calderone shares his
concerns. I think they were the only commenters not directly affiliated with one of the competing projects. The issues they've
raised seem serious, but I don't
it would make more sense to me if it
stayed fixed at 56 sig digits for numbers larger than 1e50.
So I agree with this, even if the default # of sig digits were less.
Several reasons to accept Mark's proposal:
* It matches what C does and many languages tend to copy the
C standards
Does anyone have any ideas about what to do with issue 5830 and handling the
problem in a general way (not just for sched)?
The basic problem is that decorate/compare/undecorate patterns no longer work when the primary sort keys are equal and the secondary
keys are unorderable (which is now
Would it make sense to provide a default ordering whenever the types are
the same?
This doesn't work when they are not the same :-)
_ ~
@ @
\_/
Instead, you could make the decorating a bit more sophisticated:
decorated = [(key, id(value), value) for key, value in blah(values)]
or
I would discourage use of the decorate/sort/undecorate pattern,
and encourage use of the key= argument. Or, if you really need
to decorate into a tuple, still pass a key= argument.
The bug report was actually about the sched module which used
heapq to prioritize tuples consisting of times,
[Antoine Pitrou]
Besides, Bob doesn't really seem to care about
porting to py3k (he hasn't said anything about it until now, other than that he
didn't feel competent to do it).
His actual words were: I will need some help with 3.0 since I am not well versed in the changes to the C API or
We're in the process of forward-porting the recent (massive) json updates to
3.1, and we are also thinking of dropping remnants of support of the bytes type
in the json library (in 3.1, again). This bytes support almost didn't work at
all, but there was a lot of C and Python code for it
[Tennessee Leeuwenburg ]
Now, I know that sets aren't ordered, but...
foo = set([1,2,3,4,5])
bar = [1,2,3,4,5]
foo.pop() will reliably return 1
while bar.pop() will return 5
discuss :)
If that's what you need:
http://code.activestate.com/recipes/576694/
Raymond
+1 for removing constant folding for floats (besides conversion
of -literal). There are just too many things to worry about:
FPU rounding mode and precision, floating-point signals and flags,
effect of compiler flags, and the potential benefit seems small.
If you're talking about the
[Nick Coghlan]
It doesn't quite work the way RDM desribed it - he missed a step.
Thanks for the clarification. We ought to write-out the process somewhere in a
FAQ.
It may also be instructive to step through the recipe that answers the OP's
original request,
The measurements are just a distractor. We all already know that the hook is
being added to a critical path. Everyone will pay a cost for a feature that
few people will use. This is a really bad idea. It is not part of a thorough,
thought-out framework of container hooks (something that
on the subject bug you, I'll happily
withdraw from the thread. I don't aspire to be a
source of negativity. I just happen to think this
proposal isn't a good idea.
Raymond
- Original Message -
From: Guido van Rossum gu...@python.org
To: Raymond Hettinger pyt...@rcn.com
Cc: Thomas Wouters
It seems weird to me that Collin's group can be working
so hard just to get a percent or two improvement in
specific cases for pickling while python-dev is readily
entertaining a patch that slows down the entire language.
[Antoine Pitrou]
I think it's really more than a percent or two:
Iterators can implement a method called __length_hint__ that provides a hint
to certain internal routines (such as list.extend) so they can operate more
efficiently. As far as I can tell, __length_hint__ is currently
undocumented. Should it be?
This has been discussed, and no, it is a
John Ehresman wrote:
* To what extent should non-debugger code use the hook? At one end of
the spectrum, the hook could be made readily available for non-debug use
and at the other end, it could be documented as being debug only,
disabled in python -O, not exposed in the stdlib to python
Agreed, and more importantly, I have yet to be convinced that those NULL
checks introduce a measurable slowdown. Daniel, have you tried
measuring the performance difference with only the NULL checks removed?
I think it highly unlikely that there is a performance difference.
These tend to
4% on a micro-micro-benchmark is hardly compelling...
I concur! This is utterly insignificant and certainly does
not warrant removing the checks.
-1 on these sort of fake optimizations. We should focus
on algorithmic improvements and eliminating redundant
work and whatnot. Removing checks
Does anyone remember the reason that most of the named methods were omitted from the ABC for mutablesets and sets? The update()
method in particular would be nice to have.
RAymond
___
Python-Dev mailing list
Python-Dev@python.org
4% on a micro-micro-benchmark is hardly compelling...
I concur! This is utterly insignificant and certainly does
not warrant removing the checks.
-1 on these sort of fake optimizations. We should focus
on algorithmic improvements and eliminating redundant
work and whatnot. Removing checks
Another thought: it would be nice is pydoc were built-out with
an alternate html generator that emitted clean, simple html
with the appropriate div/span tags so that CSS can be used
to control formatting. Right now, all of the formatting and
color coding is in-line. If you don't like the
As a project maintainer I wouldn't want an intern being the most familiar
person with our Py3 migration, I'd rather students stick with new features
or optimization and coordinate the migration process as a group-wide effort.
Without help, it is going to take a long time to get many
[Benjamin Peterson]
It seems Andrew will be doing What's new in Python 2.7? again, but
we don't seem to have a volunteer to do the 3.1 version? Would anyone
like to volunteer?
I'll pick-up this responsibility.
Raymond
___
Python-Dev mailing list
Does anyone think it was not a good idea to put in-place operations in the operator module? For some objects, they don't map() as
well as their regular counterparts. Some in-place operations rely on the interpreter to take care of the actual assignment. I've
not yet seen good use cases for
Right. Since Python doesn't have a notation like operator + for
turning operators into functions, the operator module provides this
functionality. Better safe than sorry.
It doesn't really expose this functionality because some of the functionality
is buried in ceval.c and is not exposed by
Maybe someone somewhere has some interesting use for
these in-place operator function. I hope so.
It could be important if you want apply it to mutable objects, i.e.
where the assignment doesn't do anything.
I give up. My original question was whether anyone thought these
were a good
[Martin v. Löwis]
I would object to their removal, though,
because it would hurt my sense of symmetry.
I wasn't going to propose removal. If everyone had
agreed that the operator in-place functions were
problematic, I was going to suggest moving their
docs to a second page and documenting
[Lie Ryan]
How about having a country code field, e.g. en-us would format according
to US locale, in to India, ch to China, etc... that way the format
string would become very simple (although the lib maintainer would need
to know customs from all over the world). Then have a special country
and Eric Smith
---
PEP: XXX
Title: Format Specifier for Thousands Separator
Version: $Revision$
Last-Modified: $Date$
Author: Raymond Hettinger python at rcn.com
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 12-Mar-2009
Fixed typo in the example with spaces and commas.
Discussion draft at: http://www.python.org/dev/peps/pep-0378/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
The current formatting mini-language provisions left/right/center alignment, prefixes for 0b 0x 0o, and rules on when to show the
plus-sign. I think it would be far more useful to provision a simple way of specifying a thousands separator.
Financial users in particular find the locale approach
[James Y Knight]
You might be interested to know that in India, the commas don't come
every 3 digits. In india, they come every two digits, after the first
three. Thus one billion = 1,00,00,00,000. How are you gonna represent
*that* in a formatting mini-language? :)
It is not the goal to
[Guido van Rossum]
I suggest moving this to python-ideas and
writing a proper PEP.
Okay, it's moved.
Will write up a PEP, do research on what other languages
do and collect everyone's ideas on what to put in the shed.
(hundreds and ten thousands grouping, various choices of
decimal
[Nick Coghlan]
What about decimal-in-C, by the way? Is anyone still working on it?
I'm seeking funding for the project. If it is forthcoming, I intend to do
a pure C version that simply implements the spec and then adds
wrappers for the pure python interface. That will save the cost
of
[Mart Sõmermaa]
To provide total ordering without __cmp__ one has to implement all of
__lt__, __gt__, __le__, __ge__, __eq__ and __ne__. However, in all
but a few cases it suffices only to provide a real implementation for
e.g. __lt__ and define all the other methods in terms of it as follows:
:
[Raymond Hettinger]
FWIW, I'm working on a solution for the problem using class decorators.
The idea is that it would scan a class and fill-in missing methods based
on the ones already there. That way, any one of the four ordering
relations can be provided as a starting point and we won't have
On behalf of the Python development team and the Python community, I'm
happy to announce the first alpha release of Python 3.1.
Are there any plans for a Windows installer?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
You might also want to collect a list of serious changes that you
want in this release;
Bob Ippolito has a good sized patch to update the json module
and improve its performance.
http://bugs.python.org/issue4136
Raymond
___
Python-Dev
You might also want to collect a list of serious changes that you
want in this release;
I'm making minor updates to the decimal module to match the 1.68 version of the
spec.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
I'm making minor updates to the decimal module to match the 1.68 version of the
spec.
Looks like most was already done. Just needs some doc fixes.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
This is precisely the reason why I want Python to continue including its
batteries. If we give that up, it will not come back, and users get
frustrated that they have to collect stuff from many places, and that
the stuff doesn't fit together completely.
I concur.
Raymond
[MvL]
At this point, I do request that the patch is reverted completely
(i.e. that the documentation is restored), and that the qualification
not reliable! is removed from the doc strings of the methods, as
it is factually incorrect.
I would be happy to restore the documentation. You want
[MvL]
At this point, I do request that the patch is reverted completely
(i.e. that the documentation is restored), and that the qualification
not reliable! is removed from the doc strings of the methods, as
it is factually incorrect.
I would be happy to restore the documentation. You want
[Benjamin Peterson]
On behalf of the Python development team and the Python community, I'm
happy to announce the first alpha release of Python 3.1.
Thanks for the good work.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
501 - 600 of 1337 matches
Mail list logo
