Instead, there should be a clear decision to deprecate or not. If
that
entails a comp.lang.python.announce notice and comment period, so be
it.
Once a decision is made, document it, add a warning, and wait.
Ok, that might be reasonable.
Please word the PEP accordingly.
Once a couple
Acceptance for Py2.4 partially hinges on how quickly third party apps
have their binaries updated.
I wonder if there is anything we can do to help.
Raymond
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Tuure Laurinolli
Sent: Tuesday, December 07,
The Dec 12th check-ins break tests on WinME:
test_glob.py
Traceback (most recent call last):
File test_glob.py, line 78, in test_glob_one_directory
eq(self.glob('a*'), map(self.norm, ['a', 'aab', 'aaa']))
File test_glob.py, line 67, in assertSequencesEqual_noorder
So how about a slogan like Code it Fast, with Python, or Python:
Code
Fast -- one which emphasizes the (easily defended) claim that
development
time is shorter with Python, but which at the same time manages to
associate the word fast with Python.
I always liked: Python, the language that
The Wiki entry seems to reinforce the impression that bugged Guido to
begin with. It provides a bunch of but ... explanations about why
Python's speed isn't that important. Python is slow, but speed of
development is far more important.
I felt the same way when reading it. Also, it seemed
FWIW, the tests at issue pass on WinXP for me today w/ current CVS.
Tests pass here too.
Raymond
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
[Armin]
Crash. Which means that there is no way in 2.4.0 to marshal an object
in the
old version format as a string -- you'd have to work around by
writing a real
file and reading it back :-(
[Aahz]
Brown bag time?
Perhaps a rather quick Py2.4.1 would be in order.
Ideally, it should
Raymond Hettinger wrote:
Perhaps a rather quick Py2.4.1 would be in order.
Ideally, it should include other important fixes:
[...]
* Fix for off-by-one bug in urllib.URLopener.retrieve
http://www.python.org/sf/810023
(assigned to me)
Is http://www.python.org/sf/1062060
[Reinhold Birkenfeld]
just felt a little bored and tried to review a few (no-brainer) patches.
Thanks, please assign to me and I'll apply them.
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
[Guido van Rossum]
Let's get rid of unbound methods.
+1
[Jim Fulton]
duck typing?
Requiring a specific interface instead of a specific type.
[Guido]
Does anyone think this is a bad idea?
[Jim]
It *feels* very disruptive to me, but I'm probably wrong.
We'll still need unbound
suggest posting it as an ASPN recipe
and then announcing it on comp.lang.python. That ought to generate some
good feedback based on other people's real world issues with
struct.unpack().
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev
manual adaption practices
should change. For example, if I need a file-like interface to a
string, I currently wrap it with StringIO. How will that change it the
future? By an explicit adapt/conform pair? Or by strings knowing how
to conform to file-like requests?
Raymond Hettinger
that they are providing.
Using optional arguments may not be the most elegant or extensible
approach. Perhaps a registry table or adapter attributes would fare
better.
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http
[Guido van Rossum]
There's one other problem that Phillip tries to tackle in his
proposal: how to implement the rich version of an interface if all
you've got is a partial implementation (e.g. you might have readline()
but you need readlines()). I think this problem is worthy of a
solution,
[Anthony Baxter]
I didn't see any replies to the last post, so I'll ask again with a
better subject line - as I said last time, as far as I'm aware, I'm
not aware of anyone having done a fix for the issue Tim identified
( http://www.python.org/sf/1069160 )
So, my question is: Is this
[Anthony Baxter]
I'm
not aware of anyone having done a fix for the issue Tim identified
( http://www.python.org/sf/1069160 )
[Raymond Hettinger]
Any chance of this getting fixed before 2.4.1 goes out in February?
[Timbot]
It probably won't be fixed by me. It would be better if a Unix
I agree that METH_O and METH_NOARGS are near
optimal wrt to performance. But if we could have one METH_UNPACKED
instead of 3 METH_*, I think that would be a win.
. . .
Sorry, I meant eliminated w/3.0.
So, leave METH_O and METH_NOARGS alone. They can't be dropped until 3.0
and they can't
[James Y Knight]
Basically, I'd like to see them be given a binding somewhere, and
have
their claimed module agree with that, but am not particular as to
where. Option #2 seemed to be rejected last time, and option #1 was
given approval, so that's what I wrote a patch for. It sounds like
[Neal]
I think I implemented this once. I'll try to see if I can find a
patch. It wasn't too difficult, but I'm not sure if the patch was
clean.
If the opportunity arises, another worthwhile peepholer buildout would
be to recognize if-elif chains that can be transformed to a single
lookup
Modified Files:
Tag: release23-maint
test_copy.py
Log Message:
fix bug 1114776
Don't forget release24-maint.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Any objections to replacing the likes of types.IntType and
types.ListType with int and list?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
(self, key)
Raymond Hettinger
___
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
[Nick Coghlan]
If itertools was a hybrid module, the handy 3-4 liners could go in the Python
section, with the heavy lifting done by the underlying C module. The Python
equivalents to the current C code could also be placed in the hybrid module
(as
happens with some of the other hybrid
Let's keep the really long-running tests out
of the regular test suite.
For test_subprocess, consider adopting the technique used by
test_decimal. When -u decimal is not specified, a small random
selection of the resource intensive tests are run. That way, all of the
tests eventually get run
frozenset version of the
patch, so I would like to get feedback on whether you guys think it is
worth it.
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
I'm unclear why the list in for x in [1,2,3] or if x not in
[1,2,3]
can't fairly easily be recognized as a constant and just be placed in
the
constants array.
That part got done (at least for the if-statement).
The question is whether the type transformation idea should be carried a
step
Wouldn't it help a lot more if the compiler would detect that
(1,2,3) is immutable and convert it into a constant at
compile time ?!
Yes. We've already gotten it to that point:
. . .
Cool. Does that work for all tuples in the program ?
It is limited to just tuples of constants
I'm very glad you introduced the optimization of building small
constant tuples at compile-time. IMO, that was a pure win.
It's been out in the wild for a while now with no issues. I'm somewhat
happy with it.
the transformation isn't semantically correct on the
face of it.
Well that's
Where are the attempts to speed up function/method calls? That's an
area where we could *really* use a breakthrough...
At one time you had entertained treating some of the builtin calls as
fixed. Is that something you want to go forward with? It would entail
a from __future__ and transition
Paul Moore wrote:
Personally, I'd rather see partial as it stands, with its current
limitations, included. The alternative seems to be a potentially long
discussion, petering out without conclusion, and the whole thing
missing Python 2.5. (I know that's a long way off, but this already
But this all reminds me of the discussion
over itemgetter/attrgetter. They also special-case particular uses of
lambda, and in those cases the stated benefits were speed and
(arguably) readability (I still dislike the names, personally).
I wouldn't use those as justification for partial().
Along the way, they should assess whether
it is as applicable as expected, whether the existing limitations
are
problematic, and whether performance is an issue.
Ah, so you question the specification, not the implementation of it.
My only issue with the PEP is that it seemed much more
[Martin]
It seems to me that the patch will be committed shortly, assuming
somebody corrects the remaining flaws in the implementation. I could
do that, but I would prefer if somebody contributed an updated patch.
Done.
Raymond
___
Python-Dev
[Peter Harris]
I look forward to the day when I can just use it.
You PEP is marked as final. The code has been checked in to CVS and
will be in Py2.5.
Congrats,
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http
A recent question on c.l.p pointed out that the 2.4 Decimal
implementation
raises TypeError directly for operator arguments it doesn't
understand,
instead
of returning NotImplemented.
Obviously, this creates problems for anyone trying to define a class
that
'plays
nicely' with Decimal
Nick Coghlan writes:
I'm actually half-tempted to suggest that [map, filter and reduce]
should be
aliased in the functional module for 2.5 (in addition to being in
builtins -
ala
the contents of the exceptions module).
Well, I think it's a good idea, so I'll formally propose it! Let's
SF bug #1155938: Missing None check for __init__().
Won't this break working (but erroneous) code? If so,
should it be applied to the 2.4 branch?
Hmm, more than one poster found the error message to be helpful in
detecting buggy code. The non-None return value was a pretty good
indicator
(soldierdata, key=attrgetter('unit', 'rank', 'proficiency'))
Raymond Hettinger
___
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
Michael Chermside suggested:
import warnings
def deprecated(func):
This is a decorator which can be used to mark functions
as deprecated. It will result in a warning being emmitted
when the function is used.
def newFunc(*args, **kwargs):
If I read the proposal correctly, order would be determined by when
the
key was first encountered. Presumably, that would mean that the
related
value would also be the first encountered (not overridden by
later-added
keys as dictated by your business requirements).
Hm Guess
ordereddict sees it.
Raymond Hettinger
___
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
See my blog:
http://www.artima.com/forums/flat.jsp?forum=106thread=98196
Do we even need a PEP or is there a volunteer who'll add any() and
all()
for me?
I'll volunteer for this one.
Will leave it open for discussion for a bit so that folks can voice any
thoughts on the design.
Raymond
implementation of and and
or.
Returning the last element is not evil; it's just weird, unexpected, and
non-obvious. Resist the urge to get tricky with this one.
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http
BTW I definitely expect having to defend removing
map/filter/reduce/lambda with a PEP; that's much more controversial
because it's *removing* something and hence by definition breaking
code.
I suspect that lambda will be the only bone of contention. The reduce()
function can be moved to the
[Alex]
If you're considering revisions to sum's design, my suggestion would
be
to find a way to let the user tell sum to use a more accurate approach
when summing floats.
FWIW, when accuracy is an issue, I use:
sum(sorted(data, key=abs))
Raymond
[Alex]
FWIW, when accuracy is an issue, I use:
sum(sorted(data, key=abs))
...and you may still lose a LOT of accuracy that way:-(.
Raymond, you technically reviewed the 2nd ed Cookbook -- don't you
recall the sidebar about why partials are the RIGHT way to do
summations? I was SO
(), key=abs), 0.0)
The implementation can be tweaked to consume the error term right away
so the queue won't grow by more than few pending items. Also, the speed
can be boosted by localizing frexp, exp2sum.pop, and queue.append.
Raymond Hettinger
the queue can be expected to grow to about half the length
of the original iterable by the time the original iterable is
exhausted.
x = z
mant, exp = frexp(x)
exp2sum[exp] = x
return sum(sorted(exp2sum.itervalues(), key=abs), 0.0)
The implementation
[GvR]
- Before anybody asks, I really do think the reason this is
requested
at all is really just to save typing; there isn't the avoid double
evaluation argument that helped acceptance for assignment operators
(+= etc.), and I find redability is actually improved with 'for'.
{Neil
through nested iterables (similar to
what os.walk does for directories). The one wrinkle is having a
stoplist argument to specify types that should be considered atomic
eventhough they might be iterable (strings for example).
Raymond Hettinger
___
Python-Dev
[Tim]
For contrast, here's one that doesn't use frexp(), and is probably
faster because of that; internally, len(sums) probably won't exceed 5
in real life (but could get as large as 2K for pathological inputs,
spanning fp's full dynamic range):
def summer4(iterable):
sums = [0.0]
I'm happy to announce the release of Python 2.4.1 (final).
Woohoo!
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
he can help manage outstanding bugs and patches.
Raymond Hettinger
___
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
[Raymond Hettinger]
Does anyone know what has become of the following developers and
perhaps
have their current email addresses?
[Tim Peters]
How about we exploit that if someone is a Python developer on SF, they
necessarily have an SF email address ($(SFNAME)@users.sourceforge.net,
like
, x)
Traceback (most recent call last):
File pyshell#12, line 2, in -toplevel-
raise Boom(Value must be a five, x)
Boom: ('Value must be a five', 10)
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
[Nick Coghlan]
Are context diffs still favoured for patches?
The patch submission guidelines [1] still say that, but is it actually
true
these days? I personally prefer unified diffs, but have been
generating
context
diffs because of what the guidelines say.
Submit whichever is the most
*/
_PyUnicode_Fini();
#endif
Raymond Hettinger
___
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
.
Likewise, I suspect that exposing the stack will create more pitfalls
and risks than it could provide in benefits. Dealing with a stack of
functions is likely to be clumsy at best.
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
I haven't heard back from Greg Stein, Jim Fulton, or Paul Prescod.
If anyone can get in touch with them, that would be great.
I suspect that Jim may want to keep the commit privileges active
and that Paul and Greg are done with commits for the time being.
Raymond Hettinger
Thanks for the note.
Let me know if you need to be switched on again at some point.
Raymond Hettinger
-Original Message-
From: Paul Prescod [mailto:[EMAIL PROTECTED]
Sent: Saturday, April 30, 2005 4:39 PM
To: Raymond Hettinger
Cc: python-dev@python.org
Subject: Re: [Python-Dev
I just made a first reading of the PEP and want to clarify my
understanding of how it fits with existing concepts.
Is it correct to say that continue parallel's its current meaning and
returns control upwards (?outwards) to the block iterator that called
it?
Likewise, is it correct that yield is
[Raymond]
Likewise, is it correct that yield is anti-parallel to the current
meaning? Inside a generator, it returns control upwards to the
caller.
But inside a block-iterator, it pushes control downwards (?inwards)
to
the block it controls.
[Guido van Rossum]
I have a hard time
In contrast, the new use of yield differs in that the suspended
frame
transfers control from the encloser to the enclosed.
Why does your notion of who encloses whom suddenly reverse when you go
from a for-loop to a block-statement? This all feels very strange to
me.
After another reading
it's not infeasible to add a close() method to
generators as a shortcut for this:
def close(self):
try:
self.__exit__(StopIteration)
except StopIteration:
break
else:
# __exit__() didn't
raise RuntimeError(or
I think that realization is important. It would be great to have a
section of the PEP that focuses on separability and matching
features to
benefits. Start with above observation that the proposed examples
can
be achieved with generators driving the block statement.
Good idea. I'm
in the standard library should be the last
evolutionary step, not the first.
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python
I'd be willing to break these off into a separate PEP if people
think
it's a good idea. I've seen very few complaints about any of these
pieces of the proposal. If possible, I'd like to see these things
approved now, so that the discussion could focus more directly on
the
*hate* it!
Sounds reasonable.
Choices:
- submit a patch adding a __copy__ method to functions,
- submit a patch for the copy module, or
- submit a feature request, assign to me, and wait.
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev
-was, under the covers, a (optential) looping construct. This
+was, under the covers, a (potential) looping construct. This
I'm glad I didn't fix this one.
I thought he meant to use optional.
Raymond Hettinger
___
Python-Dev mailing list
Raymond Hettinger
___
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
What's the advantage of using two calls to getcontext() vs. saving the
context in a local variable?
I prefer saving the context in a local variable but that is just a
micro-optimization. The presentation with multiple calls to
getcontext() was kept just to match the style of the original --
work with a copy.
oldcontext = decimal.getcontext()
newcontext = oldcontext.copy()
newcontext.prec += 2
yield None
decimal.setcontext(oldcontext)
This approach defends against various kinds of unruly behavior by the
yield target.
Raymond Hettinger
I think you're missing a decimal.setcontext(newcontext) before the
yield..
Right.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
+def sin(x):
+Return the sine of x as measured in radians.
+do with_extra_precision():
+i, lasts, s, fact, num, sign = 1, 0, x, 1, x, 1
+while s != lasts:
+lasts = s
+i += 2
+
Should this maybe just be added to PEP 342? To me, PEP 342 has
always
seemed incomplete without ways to throw() and close(), but that
could
easily be just me. In any case I'd expect the implementation of
'next(arg)' to have some overlap with the implementation of
'throw()'.
Maybe, but
Okay. Maybe we should just update PEP 325, then?
-1.
Keep this separate.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
[Raymond Hettinger]
Are the value and traceback arguments optional as they are with the
current raise statement? If they are optional, what would the
default
be? I think the preferred choice is to have the call to the throw
method be the anchor point. That makes sense in a traceback so
So at this point it seems your proposal is just nailing down
specifics
for
the open parts of PEP 325.
Or PEP 288? That has throw() (albeit with a different signature). I
could do without the attributes though (PEP 342 provides a much better
solution IMO).
If either of those PEP
Not sure what the right answer is, but I wanted to stick my oar in
to
say that I think that Decimal has not been in the field long enough or
widely-enough used that we should feel that the API has been set in
stone. If there's agreement that a mistake was made, let's fix it!
There is not
BTW I think that close() and __del__() should raise an exception when
the throw(GeneratorExit) call doesn't end up either re-raising
GeneratorExit or raising StopIteration. The framework for calling
__del__() takes care of handling this exception (by printing and then
ignoring it). Raymond
[Tim suggesting that I'm clueless and dazzled by sparkling lights]
There seems to be an unspoken wow that's cool! kind of belief
that because Python's Decimal representation is _potentially_
unbounded, the constructor should build an object big enough to
hold any argument exactly (up to the
I sense a religious fervor about this so go ahead and do whatever you
want.
Please register my -1 for the following reasons:
a.) It re-introduces representation error into a module that worked so
hard to overcome that very problem. The PEP explicitly promises that a
transformation from a
Addenda:
j.) The same rules would need to apply to all forms of the Decimal
contructor, so Decimal(someint) would also need to truncate/round if it
has more than precision digits -- likewise with Decimal(fromtuple) and
Decimal(fromdecimal). All are problematic. Integer conversions are
expected
Does it really need to be argued interminably that deviating from a
standard is a Big Deal?
The word deviate inaccurately suggests that we do not have a compliant
method which, of course, we do. There are two methods, one context
aware and the other context free. The proposal is to change
[Michael Chermside]
Frankly, I have no idea WHAT purpose is served by passing a context
to the decimal constructor... I didn't even realize it was allowed!
Quoth the docs for the Decimal constructor:
The context precision does not affect how many digits are stored. That
is determined
[Guido]
You know that, but Raymond seems confused. From one of his posts
(point
(k)):
[Raymond]
Throughout the implementation, the code calls the Decimal
constructor to create intermediate values. Every one of those calls
would need to be changed to specify a context.
[Facundo]
The
It looks like if you pass in a context, the Decimal constructor still
ignores that context:
import decimal as d
d.getcontext().prec = 4
d.Decimal(1.234567890123456789012345678901234567890123456789,
d.getcontext())
Decimal(1.234567890123456789012345678901234567890123456789)
Some of the private email I've received indicates a need for a decimal
FAQ that would shorten the module's learning curve.
A discussion draft follows.
Raymond
---
Q. It is cumbersome to type decimal.Decimal('1234.5'). Is there a way
to
permissions.
When you have a patch that is really to apply,
upload it to the tracker and assign to me.
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
Let's start out with CVS tracker permissions.
When you have a patch that is really to apply,
upload it to the tracker and assign to me.
really -- ready
___
Python-Dev mailing list
Python-Dev@python.org
As the process of deprecating old bugs evolves, the following
categories got empty:
Python 2.1.1
Python 2.1.2
Python 2.2.1
Python 2.2.1 candidate
Python 2.2.2
That's great news.
The SF interface doesn't allow to delete old categories, but maybe we
could ask SF
If Raymond would rather defer to me, I can give it a shot in a revised
version of PEP 343,
Thanks, that would be great. The decimal conversation used up a lot of
my available cycles.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
Old age and a missing OP is not sufficient reason to close a bug.
But if closing a bug is an effective way of kicking things into life
again...
I'm seeing this effect in a lot of bugs I closed as old ones.
That means they shouldn't have been closed and that we almost lost a valid
I've seen some systems that solve this problem by allowing users to
vote
for favorite bugs... then you can tell the important bugs because
they
are more likely to have lots of votes. As I see it, Facundo is using a
variant of that system. He is asking whether there is *ONE PERSON* out
there
(code, av[1], flags)
if av[2]:
The times two operation also occurs twice in nearby code. Are those
also incorrect?
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
.
Raymond Hettinger
___
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
- throw() is a term taken from Java C++.
This was intended. There was much discussion about this for PEP 288 and
this was more or less a concensus choice. The term is already
associated with exceptions in other languages and it captures the
concept of the raise occurring somewhere else (what
I'm horsing around with recognizing switch-like if statements like:
if x == 1:
print 1
elif x == 2:
print 2
else:
print unknown
in the compiler and generating O(1) code. x can be any expression,
but
must be precisely the same in each elif clause,
By the way, whatever happened to and while?
That is making something hard and weird out of something simple.
There were no shortage of odd suggestions to force the condition line
to appear lower in the block than the starting line. All of them
smelled of rotten eggs -- they just don't fit the
[BJörn Lindqvist]
I would like to have do-while's like this:
do:
body
until cond
But I'm sure that has problems too.
That looks nice to me.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
1 - 100 of 1337 matches
Mail list logo
