Steve Holden wrote:
Tim Delaney wrote:
BTW, one of my test cases involves multiple super calls in the same
method - there is a *very* large performance improvement by
instantiating it once.
And how does speed deteriorate for methods with no uses of super at
all (which will, I suspect, be
Jim Jewett wrote:
On 4/29/07, Tim Delaney [EMAIL PROTECTED] wrote:
I've been intending to write up a PEP for fixing super, but I
haven't had time to get to it.
Calvin Spealman has the most recent draft. I hope he will incorporate
this into his draft.
Sorry about this - wasn't receiving
Guido van Rossum wrote:
1. When a method is defined, the class is bound to it via an
attribute
(which in my version is called func_class).
In Py3k all the func_XXX attrs are renamed __XXX__, so this would be
__class__; but that's a name reserved for something else, so it would
need to be
Greg Ewing wrote:
Steven Bethard wrote:
* Greg Ewing - counteach(), countall()
* Guido - counts() is fine
I'm happy with counts() too -- I only suggested the
others in case counts() wasn't acceptable for some
reason. If Guido likes it, that's good enough for
me.
I think I'd prefer
Guido van Rossum wrote:
If you want, I can make a decision. But I will only do that if I hear
from both sides of the debate that they are willing to accept my
choice even if it favors the other party. Can I hear agreement to
that?
From me - definitely.
I put my position forward (anti this
Delaney, Timothy (Tim) wrote:
From me - definitely.
Damned Outlook, reformatting sent emails! That statement was obviously
from me ...
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Phillip J. Eby wrote:
In addition to being made in the face of controversy and opposition,
this
change is an alteration to *documented and tested* behavior and thus
cannot reasonably be considered a mere bug fix.
FWIW, I support Phillip on this. There can be no question that the old
Michael Foord wrote:
There was code posted that used the (almost entirely sane) pattern :
new_filename = os.path.splitext(old_filename)[1] + '.bak'
That was broken but is now fixed. It follows the entirely natural
assumption that filename without an extension would not have the
filename
Martin v. Löwis wrote:
It's not just that people disliked the behavior. The majority of
those
that commented agreed that the current behavior is incorrect. Some
also
observed that the online documentation was underspecified, and indeed
allowed for that change. So this is a bug fix, even
Guido van Rossum wrote:
On 2/15/07, Raymond Hettinger [EMAIL PROTECTED] wrote:
* Add a pure python named_tuple class to the collections module.
I've been using the class for about a year and found that it greatly
improves the usability of tuples as records.
[EMAIL PROTECTED] wrote:
Hm, but why would they still have to be tuples? Why not just
have a generic 'record' class?
Tim Hmm - possibilities. record definitely has greater
connotations Tim of heterogeneous elements than tuple, which
would put paid to the Tim constant
Greg Ewing wrote:
Oleg Broytmann wrote:
Given that they say a camel is a horse designed by a committee
BTW, camels are very suited for their environments...
The quote is actually a camel is a *racehorse* designed by a
committee. Camels are very good at surviving in the desert, but not
Benji York wrote:
Collin Winter wrote:
On 2/12/07, Brett Cannon [EMAIL PROTECTED] wrote:
I actually kind of like that. The connection to pointer indirection
meshes well with the idea of indirectly figuring out what attribute
to access at runtime.
There's a connection, but I'd say it's
Ben North wrote:
c.5 uses which would have to stay as getattr because they
are calls of a variable named getattr whose default
value is the builtin getattr;
Have you checked if these are intended to bring the getattr name into
local scope for fast lookup,
Martin v. Löwis wrote:
For Python 2.5, for compatibility, it probably has to remain
where it is, and only PyTraceBack_Here should stop using it.
As a consequence, a generator .send() makes exceptions
occur in the current thread, not in the thread where the
generator was created.
What do
Martin v. Löwis wrote:
Greg Ewing schrieb:
I think I'd be happy with having to do that explicitly.
I expect the vast majority of Python programs don't
need to track changes to the set of importable modules
during execution. The exceptions would be things like
IDEs, and they could do a cache
[EMAIL PROTECTED] wrote:
Steve By these statistics I think the answer to the original
question Steve is clearly no in the general case.
As someone else (Guido?) pointed out, the literal case isn't all that
interesting. I modified floatobject.c to track a few interesting
floating
M.-A. Lemburg wrote:
Perhaps we ought to add an exception to the dict lookup mechanism
and continue to silence UnicodeErrors ?!
I'd definitely consider a UnicodeError to be an indication that two
objects are not equal. At the very least, in the context of a dictionary
lookup.
Tim Delaney
Larry Hastings wrote:
I run the following script:
--
from subprocess import *
Popen(ls -l)
--
(yeah, I have ls.exe on Windows)
Under Python 2.4.2, this simply dumped the results of ls.exe to the
terminal--sorry, to the command shell.
Under Python 2.5, both beta 1 and beta 2, it dumps
Title: Message
Hah - just found it. I even remember reading it...
I'll
update the SF tracker (1526203) with your analysis.
Tim
Delaney
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Kevin Jacobs [EMAIL PROTECTED]Sent: Thursday, 13
Michael Hudson wrote:
Benji York [EMAIL PROTECTED] writes:
Nick Coghlan wrote:
Perhaps ImportWarning should default to being ignored, the same way
PendingDeprecationWarning does?
Then -Wd would become 'the one obvious way' to debug import problems
+1
I'm not sure what this would
Guido van Rossum wrote:
I wonder if there should be two default clauses, or some other
syntactic way to indicate whether we expect all x to be hashable?
switch expr:
case 1:
statements
case 2:
statements
else:
statements
Thomas Wouters wrote:
If 2.5 warns and does the old thing, the upgrade path is easy and
defendable. This is also why there are future statements -- I
distinctly recall making the same argument back then :-) The cost of
continuing the misfeatures in struct for one release does not weigh
up to
Thomas Wouters wrote:
On 5/22/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Tim If there's no functionality changes, what would be the
problem with Tim putting it in post-alpha?
It still represents new code that may introduce new bugs. In theory
(and
generally in practice for
Edward Loper wrote:
It might be useful in some cases to have a keyword argument to
sort/sorted that says to ignore exceptions arising from comparing
elements, and leaves the ordering of non-comparable values undefined.
Why? Far better to use a key (or cmp if you really want) that imposes a
Josiah Carlson wrote:
for line in lines:
line = line.rstrip()
...
Exactly the use case I was thinking of (and one I used yesterday BTW).
I'm -1 on *dis*allowing reusing a name bound in a for loop in any
construct i.e. +1 for the status quo.
Tim Delaney
Greg Ewing wrote:
for x in stuff:
for x in otherstuff:
dosomethingelse(x)
would be a SyntaxError because the inner loop
is trying to use x while it's still in use by the
outer loop.
So would this also be a SyntaxError?
for x in stuff:
x = somethingelse
Tim
Guido van Rossum wrote:
http://python.org/sf/1477281
(You can call it 'oldtimer-repellant' if you want to use it to
convince people there isn't any *real* backward-compatibility issue.)
I'd worry that it'll cause complaints when the warning is incorrect
and a certain directory is being
Guido van Rossum wrote:
The difference is that if you find a valid module package later on the
path, you'll still get warnings.
This is the bit I don't like about it. Currently the warnings are
displayed as the packages are found. I'd be quite happy with the
warnings if they were suppressed
Nick Coghlan wrote:
(An idea that just occurred to me in writing this email is managed
context. That's a lot less clumsy, and fits with the context manager
idea.
+1
Context expressions
In response to a comment Aahz made, I tweaked the language
reference to explicitly refer to the
Tim Peters wrote:
I might see if I can work up a patch over the easter long weekend if
no one beats me to it. What files should I be looking at (it would
be my first C-level python patch)?
Blegh - my parents came to visit ...
Tim Delaney
___
Neal Norwitz wrote:
I partially reverted my fix from last night. It appears to work for
both Guido's original problem and Phillip's subsequent problem. YMMV.
It would be great if someone could review all the PyMem_* and
PyObject_* allocs and frees to ensure consistency.
Definitely seems
Anthony Baxter wrote:
On behalf of the Python development team and the Python
community, I'm happy to announce the first alpha release
of Python 2.5.
I noticed in PEP 356 Open Issues StopIteration should propagate from
context managers that there's a still a question (from Jim Jewett)
about
Trent Mick wrote:
I wonder if it would be possible to write a reaper script that used
some combination of EnumWindows, SendKeys, the Performance Monitoring
APIs (Pdh* function) and some elbow grease to click these crash
dialogs away.
I've found for this type of thing AutoIt
Discovered a couple of minor errors in pcbuild.sln and pythoncore.vsproj
while working out how to compile 2.5 on Windows using the VS C++ Toolkit
for the bug day (no Visual Studio at home). FWIW, I eventually ended up
using Nant (using the solution task).
Nant couldn't build 2.5 without the fixes
Guido van Rossum wrote:
I can't confirm right now (at work, need to install 2.5) but I'm also
wondering what will happen if KeyboardInterrupt or SystemExit is
raised from inside the generator when it's being closed via
__exit__. I suspect a RuntimeError will be raised, whereas I think
these
Discovered this while playing around with the 2.5 released end of last
week.
Given:
@contextmanager
def gen():
print '__enter__'
yield
print '__exit__'
with gen():
raise StopIteration('body')
I would expect to get the StopIteration exception raised. Instead it's
suppressed by
Georg Brandl wrote:
Tim Peters wrote:
[/F]
so, how did it go? a status report / summary would be nice, I
think ?
19 bugs, 9 patches (which were mostly created to fix one of the bugs).
Not much, but better than nothing and there has been quite a
participation
from newbies.
I've just
Anthony Baxter wrote:
My only concern about this is that it wouldn't be possible for other
authors to provide 3rd party packages as (for instance) db.mysqldb
because of the way package importing works. And I'd prefer
'database.sqlite' rather than 'db.sqlite'.
Perhaps dbapi2.sqlite?
Tim
Steven Elliott wrote:
The important difference between builtins and globals is that with
builtins both the compiler and the runtime can enumerate all
references
to builtins in a single consistent way. That is True can always be
builtin #3 and len can always be builtin #17, or whatever.
Raymond Hettinger wrote:
Your example simply highlights the consequences of one of Python's
most basic, original design choices (using getitem for both sequences
and mappings). That choice is now so fundamental to the language
that it cannot possibly change.
Hmm - just a thought ...
Since
Greg Ewing wrote:
I don't quite see the point here. Inside a bytes object,
they would be stored 1 byte per byte. Nobody is suggesting
that they would take up more than that just because
a_bytes_object[i] happens to return an int.
Speaking of which, I suspect it'll be a lot more common to
Raymond Hettinger wrote:
Speaking of which, I suspect it'll be a lot more common to need
integer objects in the full range [0, 255] than it is now.
Perhaps we should extend the pre-allocated integer objects to cover
the full byte range.
+1
Want me to raise an SF request?
Tim Delaney
Delaney, Timothy (Tim) wrote:
Perhaps we should extend the pre-allocated integer objects to cover
the full byte range.
+1
Want me to raise an SF request?
Done. Item # 1436243.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http
Greg Ewing wrote:
In other words, just because A inherits from B in
Python isn't meant to imply that an A is a drop-in
replacement for a B.
Hmm - this is interesting. I'm not arguing Liskov violations or anything
...
However, *because* Python uses duck typing, I tend to feel that
subclasses
Martin v. Löwis wrote:
Delaney, Timothy (Tim) wrote:
However, *because* Python uses duck typing, I tend to feel that
subclasses in Python *should* be drop-in replacements. If it's not a
drop-in replacement, then it should probably not subclass, but just
use duck typing (probably by wrapping
Guido van Rossum wrote:
Over lunch with Alex Martelli, he proposed that a subclass of dict
with this behavior (but implemented in C) would be a good addition to
the language. It looks like it wouldn't be hard to implement. It could
be a builtin named defaultdict. The first, required, argument
M J Fleming wrote:
+1
I definately agree with the 0c664 octal literal. Seems rather more
intuitive.
And importantly, sounds like Oc 664 ;)
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
Andrew Koenig wrote:
I definately agree with the 0c664 octal literal. Seems rather more
intuitive.
I still prefer 8r664.
The more I look at this, the worse it gets. Something beginning with
zero (like 0xFF, 0c664) immediately stands out as unusual. Something
beginning with any other digit
Martin v. Löwis wrote:
So as for dealing with it somehow: I would make ctypes a dynamically
loaded module (ctypes.pyd), so administrators could remove it, and
I could also make it a separate option in the Windows installer,
so administrators could reject to install it.
I like this solution.
Guido van Rossum wrote:
On 1/10/06, Thomas Heller [EMAIL PROTECTED] wrote:
I would like to suggest to include ctypes into core Python, starting
with the 2.5 release.
On the one hand I agree that this is a useful module, popular, mature
etc.
On the other hand it breaks one of the most
Guido van Rossum wrote:
As was pointed out on c.l.py, the `dl` module suffers the exact same
problem (I don't know myself, as I've never used it). There are no
warnings about this in the `dl` module documentation.
Good point. I think there should be such warnings though.
Added
Fredrik Lundh wrote:
if you check my original post, you'll find code for a new list helper
function, which would solve this in a convenient way.
Yep - I thought I'd seen something like this, but couldn't find it
(eventually found it by searching for Lundh ;). That's exactly what I
was thinking
Noam,
There's a simple solution to all this - write a competing PEP. One of
the two competing PEPs may be accepted.
FWIW, I'm +1 on PEP 351 in general, and -1 on what you've proposed.
PEP 351 is simple to explain, simple to implement and leaves things
under the control of the developer. I think
Reinhold Birkenfeld wrote:
And we have solved the map, filter and reduce are going away! Let's
all weep together problem with one strike!
I'm not sure if you're wildly enthusiastic, or very sarcastic.
I'm not sure which I should be either ...
The thought does appeal to me - especially
Greg Ewing wrote:
class C:
foo = overridable_property('foo', The foo property)
def get_foo(self):
...
def set_foo(self, x):
...
This has the advantage that the accessor methods can be
overridden in subclasses with the expected effect.
This is a
Guido van Rossum wrote:
To which Tim Delaney responded, have a look at my response here:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/408713
I looked at that, and now I believe it's actually *better* to mention
the property name twice, at least compared to Tim' s approach.
I
Paul Du Bois wrote:
On 10/10/05, Nick Coghlan [EMAIL PROTECTED] wrote:
cmd, *args = input.split()
These examples also have a reasonable implementation using list.pop(),
albeit one that requires more typing. On the plus side, it does not
violate
DRY and is explicit about the error
Delaney, Timothy (Tim) wrote:
args = input.split()
try:
cmd = arg.pop()
^^^ args ...
except IndexError:
cmd = ''
Can't even get it right myself - does that prove a point? wink
Tim Delaney
___
Python
Guido van Rossum wrote:
Congratulations gracefully accepted.
Whilst I'm not personally fond of the syntax, congratulations. Whilst I
don't feel this is a big step in the evolution of the language, it shuts
up a *very* frequently asked question (and opens up a new one ;)
Tim Delaney
Fred L. Drake, Jr. wrote:
On Tuesday 20 September 2005 17:49, Guido van Rossum wrote:
I realize that this was a deliberate feature, and that it exists in
2.4 as well as in 2.4.1 and will in 2.4.2; yet, I'm not sure I
*like*
I wasn't paying any attention at the time, so I don't know
James Y Knight wrote:
Just to be clear, I do not want nor expect this. I wish to be able to
specifically modify code with full knowledge of what has changed in
Py3.0 such that it will work with both Py2.X and Py3.0.
If you want these things to work in 2.x and 3.0, just use
iter(dict_instance)
Michael Chermside wrote:
We could satisfy both people if in Python 2.x we introduced a
built-in function named print30 (for Python 3.0) with the intended
new behavior. People could start coding now using the print30
builtin. When Python 3.0 was released, 'print' would no longer be
a keyword,
Guido van Rossum wrote:
How stable is Pyrex? Would you be willing to integrate it thoroughly
with the Python source tree, to the point of contributing the code to
the PSF? (Without giving up ownership or responsibility for its
maintenance.)
+100
I would be *strongly* in favour of this.
Fredrik Lundh wrote:
the problem isn't the time it takes to unpack the return value, the
problem is that it takes time to create the substrings that you don't
need.
I'm actually starting to think that this may be a good use case for
views of strings i.e. rather than create 3 new strings,
Shane Hathaway wrote:
Ron Adam wrote:
For cases where single values are desired, attribues could work.
Slicing:
line = line.partition(';').head
line = line.partition('#').head
But it gets awkward as soon as you want more than one.
sep, port =
Andrew Durdin wrote:
Just to put my spoke in the wheel, I find the difference in the
ordering of return values for partition() and rpartition() confusing:
head, sep, remainder = partition(s)
remainder, sep, head = rpartition(s)
This is the confusion - you've got the terminology wrong.
Michael Chermside wrote:
Raymond writes:
That suggests that we need a variant of split() that has been
customized for typical find/index use cases. Perhaps introduce a
new pair of methods, partition() and rpartition()
+1
My only suggestion is that when you're about to make a truly
Raymond Hettinger wrote:
Yes, there is a precise spec and yes it always returns three strings.
Movitation and spec:
http://mail.python.org/pipermail/python-dev/2005-August/055764.html
Ah - thanks. Missed that in the mass of emails.
My major issue is with the names - partition() doesn't
Raymond Hettinger wrote:
Heh! Maybe AttributeError and NameError should be renamed to
TypoError ;-) Afterall, the only time I get these exceptions is
when the fingers press different buttons than the brain requested.
You misspelled TyopError ;)
Tim Delaney
Tim Peters wrote:
[Martin v. Löwis]
I would agree. However, there still is the debate of hosting the
repository elsehwere. Some people (Anthony, Guido, Tim) would prefer
to pay for it, instead of hosting it on svn.python.org.
Not this Tim.
Not this one either. I haven't actually used any
Joseh Martins wrote:
I´m a beginner in python dev..
Well, i need to implement a external ping command and get the results
to view the output. How can I do that?
Per example, i need to ping and IP address and need to know if the
host is down or up.
python-dev is for discussion of the
Nick Coghlan wrote:
+-- Exception (formerly StandardError)
+-- AttributeError
+-- NameError
+-- UnboundLocalError
+-- RuntimeError
+-- NotImplementedError
Time to wade in ...
I've actually been wondering if NotImplementedError should actually be a
subclass
Well, I'm convinced. My votes go to context management protocol and
@contextmanager. Simple, descriptive and specific in meaning yet wide
enough to cover pretty much all the cases we care about.
I think we should state in the docs that the most common usage is to set
up a specific context and
Raymond Hettinger wrote:
These names should be changed to __beginwith__ and __endwith__. The
Alternatively:
__begincontext__ / __endcontext__
__enterwith__ / __exitwith__
__entercontext__ / __exitcontext__
__begin_with__ / __end_with__
__begin_context__ / __end_context__
__enter_with__ /
Phillip J. Eby wrote:
Expand your mind. :) Resource can include whatever objects you
want it
to -- or no objects at all. A resource can be conceptual - like for
example the user's attention, or the contents of a status bar or log
message, or the timing/profiling of an activity. I think
Justin wrote:
When I used py2exe to create executable file, cephes module missing
error occurred.
I have installed python 2.3 and scientific and numeric python.
Can anybody suggest me how to resolve the problem?
python-dev is for development *of* python, not *with* python. Please
direct
Gary Robinson wrote:
It's been around 7 years since I've used C, I've forgotten virtually
everything I may have known about gdb, I've never worked with the
C-python API before... meanwhile there is intense time pressure to get
the next release of our product (http://www.goombah.com) ready. So
78 matches
Mail list logo
