Re: [Python-Dev] Pre-pre PEP for 'super' keyword
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 in the majority)? Zero - in those cases, no super instance is instantiated. There is a small one-time cost when the class is constructed in the reference implementation (due to the need to parse the bytecode to determine if if 'super' is used) but in the final implementation that information will be gathered during compilation. Tim Delaney ___ 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
Re: [Python-Dev] [Python-3000] Pre-pre PEP for 'super' keyword
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 python-dev at home, so didn't realise Calvin had released the PEP. I think the current PEP draft is way too complicated - I don't think there's any need for descriptors, etc. I think we can make things work in the following way: 1. When a method is defined, the class is bound to it via an attribute (which in my version is called func_class). 2. Every non-static method has an implicit cell variable called 'super'. This would preferably not be able to be rebound. I also think it would be beneficial if the first parameter to the method couldn't be rebound (point 7 in my original email in this thread). 3. When a method is entered, the 'super' cell variable is populated by a call equivalent to: super = __builtin__.super(func_class, first_parameter) This would result in 'super' being a constant object, within the scope of the currently-executing method. 'keyword' was perhaps too strong - I was thinking this would only need to be done if 'super' were actually used, which would be easier to determine if 'super' actually were a keyword. This could still be done by not emitting the above call unless the 'super' cell variable were ever actually used. I've done bytecode-hacky stuff to do the equivalent of the above (as much as I've been able to), but a real implementation would just emit the correct bytecode (or java bytecode, or whatever) in the compiled code object. The issue of super() vs. super.__call__() ambiguity - I'll need to look at that when I get home. I'm a strong -1 against super() automatically passing the parameters that were passed to the currently-executing method. Tim Delaney ___ 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
Re: [Python-Dev] [Python-3000] Pre-pre PEP for 'super' keyword
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 something else. E.g. __containing_class__. Yep - I've just used a placeholder name. Also, this would have to be done when the class is defined; when the method is being defined the class doesn't exist yet. Good point. Change that to at the first opportunity ;) 2. Every non-static method has an implicit cell variable called 'super'. I think you're using 'cell' in a different sense than it is normally used in Python's implementation. What you are looking for is called a local variable (I deduce this from your initialization of the cell with something computed from the first argument). Actually, I think I'm using the terminology correctly - I'm talking about an entry in co_cellvars. Given the following class: class A(object): def f(self): super = super_factory() def inner(): return 'A' + super.f() print inner() the use of 'super' in both A.f and A.f.inner will produce an entry in A.f.func_code.co_cellvars and A.f.inner.func_code.co_freevars. What I'm proposing is that the `super = super_factory()` line be implicit in this case, resulting in the following code behaving identically: class A(object): def f(self): def inner(): return 'A' + super.f() print inner() The issue of super() vs. super.__call__() ambiguity - I'll need to look at that when I get home. Sounds irrelevant -- if super is equivalent to __builtin__.__super__(class, firstarg) then super never gets called; the only thing ever done to it (in the normal course of things) is to request an attribute of it. Sorry - this is related to my proposal that the following two bits of code behave the same: class A(object): def f(self, *p, **kw): super.f(*p, **kw) class A(object): def f(self, *p, **kw): super(*p, **kw) But as has been pointed out, this creates an ambiguity with: class A(object): def f(self, *p, **kw): super.__call__(*p, **kw) so I want to see if I can resolve it. super(ThisClass).method(...) # ??? The third exists so that you can create an unbound super instance which is useful for the oft-misunderstood autosuper example in my descrintro essay: http://www.python.org/download/releases/2.2.3/descrintro/#metaclass_exam ples . But since the latter is the hack that we're trying to replace with a proper implementation here, I suspect we can get away with only supporting the first two forms (and the third form is still supported using __builtin__.__super__). Yep - that's my thought as well. I think it would be very rare to need super(ThisClass), although it makes some sense that that would be what super means in a static method ... Tim Delaney ___ 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
Re: [Python-Dev] function for counting items in a sequence
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 tally as less ambiguous, but counts works too. Tim Delaney ___ 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
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 change, partly because it only addressed one of the special cases), and then stayed out of it. Happy mulling! Tim Delaney ___ 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
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 behaviour was expected. IMO this is just gratuitous breakage. The only fix that shold be made is to the splitext documentation to match the docstring. A change to the documented behaviour should require a __future__ import for at least one version. That's even assuming that the change is desireable (I don't believe so). We have multiple anecdotes of actual, existing code that *will* break with this change. So far I haven't seen any actual code posted that is currently broken by the existing behaviour. Tim Delaney ___ 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
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 put in the extension half of the tuple. Well, I'd argue the sanity of it, but you're right - it was posted. The documentation (not the docstring) actually says : splitext( path) Split the pathname path into a pair (root, ext) such that root + ext == path, and ext is empty or begins with a period and contains at most one period. Even the docstring only states that either part may be empty, hardly documenting what is clearly a misfeature. splitext(p) Split the extension from a pathname. Extension is everything from the last dot to the end. ^ Return (root, ext), either part may be empty. That's pretty explicit. Tim Delaney ___ 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
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 though the old test case explicitly tested for the presence of the bug, and even though the doc string explicitly documented the old behavior. They were all consistent, but they were consistently wrong. The patch special-cases one edge case where an extension does not indicate the type of the file, but metadata on a particular platform. Here's a couple of other edge cases that are not addressed by the patch: On Mac OS (including Mac OS X) you can have a file without an extension, where the type is specified in the metadata. However, such a file could also happen to contain a dot in the file name: splitext(Version 1.2) - (Version 1, 2) Also, quite often you have multiple extensions: splitext(file.tar.gz) - (file.tar, gz) To me, the extension there is tar.gz. Basically, changing the behaviour of splitext() is simply trying to make it do what I mean (DWIM). But it's never going to DWIM. I think the best we can do is have a simple, unambiguous rule, with no exceptions - which is what the existing behaviour does. Tim Delaney ___ 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
Re: [Python-Dev] Py2.6 ideas
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. http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/500261 Hm, but why would they still have to be tuples? Why not just have a generic 'record' class? Hmm - possibilities. record definitely has greater connotations of heterogeneous elements than tuple, which would put paid to the constant arguments that a tuple is really just an immutable list. list - primarily intended for homogeneous elements record - primarily intended for heterogeneous elements, elements are (optionally?) named and have mutable and immutable versions of each. Maybe the current list syntax would then continue to create a mutable list, and the current tuple syntax would create an immutable record (with no element names) i.e. the current tuple. Tim Delaney ___ 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
Re: [Python-Dev] Py2.6 ideas
[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 arguments that a tuple is really just an immutable list. (What do you mean by ... put paid ...? It doesn't parse for me.) Based on posts the current thread in c.l.py with the improbable subject f---ing typechecking, lots of people refuse to believe tuples are anything other than immutable lists. Sorry - put paid to means to finish ... http://www.phrases.org.uk/meanings/293200.html That thread is a perfect example why I think a record type should be standard in python, and tuple should be deprecated (and removed in 3.0). Instead, have mutable and immutable lists, and mutable and immutable records. You could add a mutable list and an immutable list (resulting always in a new mutable list I think). You could *not* add two records together (even if neither had named elements). Cheers, Tim Delaney ___ 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
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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 so good at winning a horse race (not camel race). Which is the point of the saying. Speaking of which, have you ever seen a camel race? Those things go *fast* ... I think we're getting way too off-topic now ;) Tim Delaney ___ 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
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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 the wrong one. In C, x-y
dereferences x, while in Python, x-y would dereference y. That's
just begging for trouble.
Then the syntax should obviously be x-y.
I'd actually gone through this process myself, and concluded that I
wouldn't be happy with either.
x-y: is currently invalid syntax, but has *very* strong connotations
from C. Whilst I'm happy to consider things that deviate from other
languages' use, this one is just too strong.
x-y is currently valid syntax, and gives (to mee) the wrong
impression that y is that thing that's going to be modified.
Of all the proposals I've seen, I think I like x.{y} best. The use of
{} has connotations of interpolation and they're the only braces that
currently don't have meaning as x{} (and probably never will).
I do worry that giving syntax to getattr/setattr/delattr will encourage
the use of dynamic attributes, when they are a fairly advanced feature.
OTOH, when you're using advanced features, you want the code to be as
readable as possible, and I think this will improve readability over
using getattr/setattr/delattr.
So I think I've changed to +0.5.
Tim Delaney
___
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
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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, or to force a binding to the builtin gettattr at compile time (two common (ab)uses of default arguments)? If they are, they would be better served by the new syntax. Overall, +1 on obj.(attr_name) -0 on obj.(attr_name, default_value) Tim Delaney ___ 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
Re: [Python-Dev] Eliminating f_tstate
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 you think? That's the behaviour I would expect. There is nothing I can find in either the Python docs nor PEP 342 to suggest that interactions with generators happen on anything except the current thread. Anything else IMO is a bug, and should be a candidate for 2.5.1. Tim Delaney ___ 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
Re: [Python-Dev] Importing .pyc in -O mode and vice versa
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 flush before reloading a module, etc. That would be a change in behavior, of course. Currently, you can put a file on disk and import it immediately; that will stop working. I'm pretty sure that there are a number of applications that rely on this specific detail of the current implementation (and not only IDEs). Would it be reasonable to always do a stat() on the directory, reloading if there's been a change? Would this be reliable across platforms? Tim Delaney ___ 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
Re: [Python-Dev] Caching float(0.0)
[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 point values:
static unsigned int nfloats[5] = {
0, /* -1.0 */
0, /* 0.0 */
0, /* +1.0 */
0, /* everything else */
0, /* whole numbers from -10.0 ... 10.0 */
};
PyObject *
PyFloat_FromDouble(double fval)
{
register PyFloatObject *op;
if (free_list == NULL) {
if ((free_list = fill_free_list()) == NULL)
return NULL;
}
if (fval == 0.0) nfloats[1]++;
else if (fval == 1.0) nfloats[2]++;
else if (fval == -1.0) nfloats[0]++;
else nfloats[3]++;
if (fval = -10.0 fval = 10.0 (int)fval == fval) {
nfloats[4]++;
}
This doesn't actually give us a very useful indication of potential
memory savings. What I think would be more useful is tracking the
maximum simultaneous count of each value i.e. what the maximum refcount
would have been if they were shared.
Tim Delaney
___
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
Re: [Python-Dev] unicode hell/mixing str and unicode as dictionary keys
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 ___ 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
[Python-Dev] FW: Bug? Certainly a new *behavior* from subprocess in 2.5 on Win32
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 the results to the command shell, but *also* prints this: Exception exceptions.AttributeError: 'NoneType' object has no attribute 'append' in bound method Popen.__del__ of subprocess.Popen object at 0x00C04EB0 ignored Calling Popen() with a stdout = subprocess.PIPE does not throw this exception. I've asked Larry to raise this on SourceForge, but with the SF email problems I thought I'd better forward it here. Looks like there's a bug in Popen.__del__ in 2.5. I'm not in a position to have a look right now. Tim Delaney ___ 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
Re: [Python-Dev] Behavior change in subprocess.py
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 July 2006 12:33 AMTo: python-dev@python.orgSubject: [Python-Dev] Behavior change in subprocess.pyDuring my testing of Python 2.5b2, I've found something that may be worthy of discussion. I suspect that recent GC and finalization changes have altered the behavior of the Popen object in subprocess.py. I am now getting many many many finalization warnings in my code like: Exception exceptions.AttributeError: "'NoneType' object has no attribute 'append'" in bound method Popen.__del__ of subprocess.Popen object at 0x2b910950 ignoredIs this a bug or a feature? Personally, I'd like to see these messages silenced, since it is being generated during interpreter shutdown. The following patch does the trick for me: --- /usr/local/lib/python2.5/subprocess.py 2006-07-11 14:11:59.0 -0400+++ subprocess.py 2006-07-12 10:17:09.0 -0400@@ -613,7 +613,7 @@ return # In case the child hasn't been waited on, check if it's done. self.poll(_deadstate=sys.maxint)- if self.returncode is None:+ if self.returncode is None and _active is not None: # Child is still running, keep us alive until we can wait on it. _active.append(self)Note that popen.py does something similar, though I am not convinced that the test is right or if it is doing something more subtle: def __del__(self): # In case the child hasn't been waited on, check if it's done. self.poll(_deadstate=sys.maxint) if self.sts 0: if _active: # Child is still running, keep us alive until we can wait on it. _active.append(self) Regards,-Kevin ___ 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
Re: [Python-Dev] ImportWarning flood
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 achieve -- people who don't know enough about Python to add __init__.py files aren't going to know enough to make suppressed-by-default warnings not suppressed. The change was prompted by developers (specifically, Google developers). Developers should be able to put -Wd in their automated build scripts. The more I think about it, the more I like the idea of saying something when an import fails only because of a missing __init__.py file. I guess I should try to implement it... This is by far and away my preference as well (stating which directories may have been importable if they had __init__.py in the exception) but it was shot down in the original discussion. Tim Delaney ___ 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
Re: [Python-Dev] Switch statement
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 except KeyError: statements finally: statements switch expr: case 1: statements case 2: statements else: statements except KeyError: statements finally: statements :) Seriously, I think I'd rather be explicit and just have KeyError propagate. If someone is expecting occasional unhashable values, they can just wrap it in try/except. try: switch expr: case 1: statements case 2: statements else: statements except KeyError: statements finally: statements The first syntax though does have the advantage that it could catch only KeyErrors raised from the switch statement. That could be easily handled by a separate SwitchKeyError exception (inheriting from KeyError). Tim Delaney ___ 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
Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64
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 the cost of breaking compatibility unwarned. This really sounds to me like a __future__ import would be useful to get the fixed behaviour. Tim Delaney ___ 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
Re: [Python-Dev] [Python-checkins] r46043 - peps/trunk/pep-0356.txt
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 Python), once you move into the beta stage all you do is fix bugs. Note that the problem isn't 'post-alpha', it's 'post-beta' -- new features (especially minor or long-agreed-upon) are fine up until beta1 ;) Isn't beta post-alpha? wink I did of course mean once we were out of the alpha stage. If they're purely performance changes (no new functionality) then there's no problem with putting it in during beta - IMO even if it introduces new bugs (so long as those bugs are gone by the time 2.5 goes final). Beta is feature set frozen. Tim Delaney ___ 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
Re: [Python-Dev] total ordering.
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 total (or at least consistent) ordering. Otherwise sorting is random. Tim Delaney ___ 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
Re: [Python-Dev] elimination of scope bleeding ofiteration variables
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 ___ 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
Re: [Python-Dev] elimination of scope bleeding ofiteration variables
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 Delaney ___ 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
Re: [Python-Dev] Dropping __init__.py requirement for subpackages
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 skipped intentionally. E.g. the string directory that someone had. Getting a warning like this can be just as upsetting to newbies! I really think it would be more useful having an ImportError containing a suggestion than having a warning. Anyone who knows it's bogus can just ignore it. I'd probably make it that all directories that could have been imports get listed. FWIW I was definitely a kneejerk -1. After reading all the messages in this thread, I think I'm now a non-kneejerk -1. It seems like gratuitous change introducing inconsistency for minimal benefit - esp. if there is a notification that a directory *could* have been a package on import failure. I think it's a useful feature of Python that it's simple to distinguish a package from a non-package. Tim Delaney ___ 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
Re: [Python-Dev] Dropping __init__.py requirement for subpackages
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 until there is an actual ImportError - at which time they'll be displayed. But occasionally those will be useful too -- when you are trying to create a package that happens to have the same name as a standard library package or module, it's a lot easier to debug the missing __init__.py if you get a warning about it instead of having to figure out that the foo you imported is not the foo you intended. I suspect that more often any warnings when there is a successful import will be spurious. But testing in the field will reveal that. So I say alpha 3 should have Thomas' patch as is, and it can be changed afterwards if necessary. Thomas' patch does this automatically -- you get a warning for each directory that is weighed and found too light. Not exactly - you'll get warnings for directories earlier in sys.path than a matching package. Potential packages later in the path won't be warned about. If you're trying to resolve import problems, it's just as likely that the package you really want is later in sys.path than earlier. Obviously in the case that you get an ImportError this goes away. Is it also useful to distinguish a subpackage from a non-subpackage? Possibly. Perhaps it would be useful to have `is_package(dirname)`, `is_rootpackage(dirname)` and `is_subpackage(dirname)` functions somewhere (pkgutils?). Then the tools objections go away, and whatever mechanism is necessary to determine this (e.g. is_rootpackage checks if the directory is importable via sys.path) can be implemented. Anyway, the warning is more compatible and just as helpful so we'll go with that. Fair enough. Tim Delaney ___ 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
Re: [Python-Dev] Updated context management documentation
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 expression in the with statement as a context expression. The result of the context expression must then be a context manager in order for the with statement to operate correctly. +1 Dealing with decimal.ContextManager (decimal.ManagedContext would definitely look better. . .) +1 Dealing with contextlib.contextmanager As recently suggested (by Terry, IIRC), I renamed this to contextlib.contextfactory, as the decorator creates a factory function for producing with statement context objects. +1 Dealing with contextlib.GeneratorContextManager I renamed this to contextlib.GeneratorContext. The fact that it's in the contextlib module provides sufficient context to indicate that this is a with statement context object, so I could avoid the clumsy naming that was needed in the decimal module. Might still be better to name this as contextlib.ManagedGeneratorContext (or contextlib.GeneratorManagedContext, but I think the former works better). This has been a long, tiring set of threads, but I think the end result is an improvement (particularly contextlib.contextfactory). Tim Delaney ___ 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
Re: [Python-Dev] pdb segfaults in 2.5 trunk?
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 ___ 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
Re: [Python-Dev] pdb segfaults in 2.5 trunk?
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 to me that it would be worthwhile in debug mode adding a field specifying which memory allocator was used, and checking for mismatches in the deallocators. I know this has been suggested before, but with number of mismatches being found now it seems like it should be put into place. I'm sure it will cause buildbot to go red ... ;) 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)? Tim Delaney ___ 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
Re: [Python-Dev] RELEASED Python 2.5 (alpha 1)
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 whether the fix is correct. We'll need to get confirmation from PJE, but I'm pretty sure this can be removed from open issues - returning False from __exit__ will result in the original exception being re-raised. Tim Delaney ___ 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
Re: [Python-Dev] current 2.5 status
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 http://www.autoitscript.com/autoit3/ works well. An example that might be applicable: I've got an HTML bandwidth monitor I wrote that retrieves data from my router and my ISP using XMLHTTP. Sometimes it takes a long time to come back and the script pops up a dialog with A script is making IE run slow (or something to that effect - forget the exact error message). I've got an AutoIt script which waits until that windows appears, closes it, closes the bandwidth monitor, starts it back up, then goes back to waiting. The script is about 10 lines long. AutoIt scripts can also be saved (and redistributed) as a standalone app (approx 120kB in size). So part of setting up a Windows buildbot slave could be to add such a script to run at startup. However, if there's some way of doing it without installing extra stuff on the slave, that would be preferable. Tim Delaney ___ 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
[Python-Dev] SF #1462700 - Errors in PCbuild
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 - basically, _ctypes_test didn't have any dependencies, and so was being built first. And the GUIDs for pythoncore were different between pcbuild.sln and pythoncore.vsproj. I've attached the fix to the bug report. Tim Delaney ___ 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
Re: [Python-Dev] SF #1462485 - StopIteration raised in body of 'with' statement suppressed
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 should pass through. I see no reason for this with the current code. Perhaps a previous version of contextlib.py had this problem? Nah - that was me mis-remembering the contextlib code. They're handled properly. Tim Delaney ___ 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
[Python-Dev] SF #1462485 - StopIteration raised in body of 'with' statement suppressed
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 the @contextmanager decorator.
I think we should only suppress the exception if it's *not* the
exception passed into gen.throw() i.e. it's raised by the generator.
Does this sound like the correct behaviour? I've attached tests and a
fix implementing this to the bug report.
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 should pass
through.
Tim Delaney
___
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
Re: [Python-Dev] Bug Day on Friday, 31st of March
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 added 1462485 and 1462700 to be assessed for commit. So make that 11 patches (although technically not finished on the day :) Tim Delaney ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 Delaney ___ 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
Re: [Python-Dev] Making builtins more efficient
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. __slots__ for modules? Tim Delaney ___ 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
Re: [Python-Dev] operator.is*Type
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 we're adding the __index__ magic method, why not have a __getindexed__ method for sequences. Then semantics of indexing operations would be something like: if hasattr(obj, '__getindexed__'): return obj.__getindexed__(val.__index__()) else: return obj.__getitem__(val) Similarly __setindexed__ and __delindexed__. This would allow distinguishing between sequences and mappings in a fairly backwards-compatible way. It would also enforce that only indexes can be used for sequences. The backwards-incompatibility comes in when you have a type that implements __getindexed__, and a subclass that implements __getitem__ e.g. if `list` implemented __getindexed__ then any `list` subclass that overrode __getitem__ would fail. However, I think we could make it 100% backwards-compatible for the builtin sequence types if they just had __getindexed__ delegate to __getitem__. Effectively: class list (object): def __getindexed__(self, index): return self.__getitem__(index) Tim Delaney ___ 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
Re: [Python-Dev] s/bytes/octet/ [Was:Re: bytes.from_hex() [Was: PEP 332 revival in coordination with pep 349?]]
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 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. Tim Delaney ___ 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
Re: [Python-Dev] s/bytes/octet/ [Was:Re: bytes.from_hex() [Was: PEP332 revival in coordination with pep 349?]]
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 ___ 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
Re: [Python-Dev] s/bytes/octet/ [Was:Re: bytes.from_hex() [Was:PEP332 revival in coordination with pep 349?]]
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://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] defaultdict proposal round three
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 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). Subclassing implies a stronger relationship to me. Which is why I think I prefer using a wrapper for a default dict, rather than a subclass. Tim Delaney ___ 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
Re: [Python-Dev] defaultdict proposal round three
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). Inheritance is more about code reuse than about polymorphism. Oh - it's definitely no hard-and-fast rule. owever, I have found that *usually* people (including myself) only subclass when they want an is-a relationship, whereas duck typing is behaves-like. In any case, Guido has produced a patch, and the tone of his message sounded like a Pronouncement ... Tim Delaney ___ 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
Re: [Python-Dev] Proposal: defaultdict
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 to the constructor should be the default value. Remaining arguments (even keyword args) are passed unchanged to the dict constructor. Feedback? On behalf of everyone who has answered this question on c.l.py, may I say WOOHOO! FWIW, my usual spelling is: try: v = d[key] except: v = d[key] = value which breaks the principle of write it once. Tim Delaney ___ 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
Re: [Python-Dev] Octal literals
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 http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
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 doesn't. This just looks like noise to me. I found the suffix version even worse, but they're blown out of the water anyway by the fact that FFr16 is a valid identifier. Tim Delaney ___ 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
Re: [Python-Dev] Include ctypes into core Python?
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. Of course, Thomas (author of both py2exe and ctypes) may like the ability to have ctypes built into python.dll ... Tim Delaney ___ 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
Re: [Python-Dev] Include ctypes into core Python?
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 fundamental Python guidelines: if you get a core dump (segfault etc.) it's a bug in Python or in a 3rd party extension, not in *your* Python code. An exception would have to be made for any code that uses ctypes, as it is usually trivial to cause core dumps with ctypes (I'd venture it's hard to avoid them ;-). I don't expect this to count against including ctypes; but I do want it to be dealt with somehow! 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. I can't see how it would be possible to guarantee that such a module could not cause crashes. I'm of the opinion that having a big red warning at the top of the module documentation that this is a contributed module, and incorrect use could cause segmentation faults/crashes, etc would be sufficient. Tim Delaney ___ 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
Re: [Python-Dev] Include ctypes into core Python?
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 documentation patch 1402224: http://sourceforge.net/tracker/index.php?func=detailaid=1402224group_i d=5470atid=305470 May need a little more work on the wording. I can't see how it would be possible to guarantee that such a module could not cause crashes. And I'm not asking for that. I'm of the opinion that having a big red warning at the top of the module documentation that this is a contributed module, and incorrect use could cause segmentation faults/crashes, etc would be sufficient. Works for me. Sounds like we agree on everything :) Maybe I should start channelling ... wink. Tim Delaney ___ 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
Re: [Python-Dev] ast-objects branch created
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 of. However, I'm also thinking that it's worthwhile to have aliases that state that this is being done for memory management - hence the idea of _PyArena_ADD (and probably _PyArena_REMOVE, which would have to do an identity removal). I'm taking some leave over Christmas/New Year, so I might have a look at some other parts of the python codebase and see if there are other areas that might benefit from using lists as arenas like this. Tim Delaney ___ 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
Re: [Python-Dev] apparent ruminations on mutable immutables (was:PEP 351, the freeze protocol)
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 there are still some issues to be resolved, but the basic premise is exactly what I would want of a freeze protocol. Tim Delaney ___ 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
Re: [Python-Dev] a different kind of reduce...
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 func.partial(args). I don't see any advantage to func.map(args) over func(*args), and it loses functionality in comparison with map(func, args) (passing the function as a separate reference). Tim Delaney ___ 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
Re: [Python-Dev] Definining properties - a use case for class decorators?
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 point I was going to bring up.
The only wart is the necessity of mentioning the property
name twice, once on the lhs and once as an argument.
I haven't thought of a good solution to that, yet.
Have a look at my comment to Steven Bethard's recipe:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/408713
Tim Delaney
___
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
Re: [Python-Dev] Definining properties - a use case for classdecorators?
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 never said it was a *good* approach - just *an* approach ;) Tim Delaney ___ 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
Re: [Python-Dev] Extending tuple unpacking
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 cases. args = input.split() try: cmd = input.pop(0) except IndexError: cmd = '' I'd say you violated it right there ... (should have been):: args = input.split() try: cmd = arg.pop() except IndexError: cmd = '' FWIW, I've been +1 on * unpacking since I first saw the proposal, and have yet to see a convincing argument against it other than people wanting to stick the * anywhere but at the end. Perhaps I'll take the stdlib challenge (unfortunately, I have to travel this weekend, but I'll see if I can make time). Tim Delaney ___ 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
Re: [Python-Dev] Extending tuple unpacking
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-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
Re: [Python-Dev] Conditional Expression Resolution
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 ___ 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
Re: [Python-Dev] bool(iter([])) changed between 2.3 and 2.4
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 what was discussed. Some discussion here just now leads me to believe that at least two of us here (including myself) think iterators shouldn't have length at all: they're *not* containers and shouldn't act that way. In any case, it's simple to get the 2.3 behaviour back - just add __nonzero__. I think that could validly be considered a bugfix. Tim Delaney ___ 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
Re: [Python-Dev] PEP 3000 and iterators
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) and list(dict_instance) as appropriate. Tim Delaney ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
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, and both 'print' and 'print30' would be built-ins that both refered to the same function. -1000 It's ugly, and it doesn't help the transition whatsoever IMO. We *definitely* don't want a print30 function hanging around in Python 3.0 for backwards compatibility with the miniscule number of people who used it in Python 2.x. The simplest solution is (as already stated):: from __future__ import __print_function__ Tim Delaney ___ 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
Re: [Python-Dev] reference counting in Py3K
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. Apart from anything else, it would greatly lower the bar for people wanting to add to the standard library. And if much of the stdlib were eventually rewritten in Pyrex it would be even better. Tim Delaney ___ 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
Re: [Python-Dev] Proof of the pudding: str.partition()
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, each string is a view onto the string that was partitioned. Most of the use cases I've seen, the partitioned bits are discarded almost as soon as the original string, and often the original string persists beyond the partitioned bits. Tim Delaney ___ 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
Re: [Python-Dev] Proof of the pudding: str.partition()
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 = host.partition(':').head, host.partition(':').sep
You can do both: make partition() return a sequence with attributes,
similar to os.stat(). However, I would call the attributes before,
sep, and after.
+0
I thought the same thing. I don't see a lot of use cases for it, but it
could be useful. I don't see how it could hurt.
Tim Delaney
___
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
Re: [Python-Dev] Remove str.find in 3.0?
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.
before, sep, after = s.partition('?')
('http://www.python.org', '', '')
before, sep, after = s.rpartition('?')
('', '', 'http://www.python.org')
Tim Delaney
___
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
[Python-Dev] partition() (was: Remove str.find in 3.0?)
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
inspired suggestion like this one, that you use a new subject
header. It will make it easier for the Python-Dev summary
authors and for the people who look back in 20 years to ask
That str.partition() function is really swiggy! It's everywhere
now, but I wonder what language had it first and who came up with
it?
+1
This is very useful behaviour IMO.
Have the precise return values of partition() been defined?
Specifically, given:
'a'.split('b')
we could get back:
('a', '', '')
('a', None, None)
Similarly:
'ab'.split('b')
could be either:
('a', 'b', '')
('a', 'b', None)
IMO the most useful (and intuitive) behaviour is to return strings in
all cases.
My major issue is with the names - partition() doesn't sound right to
me. split() of course sounds best, but it has additional stuff we don't
necessarily want. However, I think we should aim to get the idea
accepted first, then work out the best name.
Tim Delaney
___
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
Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
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 sound right to me. FWIW, I am VERY happy with the name partition(). It has a long and delightful history in conjunction with the quicksort algorithm where it does something very similar to what we're doing here: I guessed that the motivation came from quicksort. My concern is that partition is not something that most users would associate with strings. I know I certainly wouldn't (at least, not immediately). The behaviour is obvious from the name, but I don't feel the name is obvious from the behaviour. If I were explaining the behaviour of partition() to someone, the words I would use are something like: partition() splits a string into 3 parts - the bit before the first occurrance of the separator, the separator, and the bit after the separator. If the separator isn't in the string at all then the entire string is returned as the bit before and the returned separator and bit after are empty strings. I'd probably also explain that if the separator is the very last thing in the string the bit after would be an empty string, but that is fairly intuitive in any case IMO. It's a pity split() is already taken - but then, you would want split() to do more in any case (specifically, split multiple times). Tim Delaney ___ 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
Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
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 ___ 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
Re: [Python-Dev] PEP 347: Migration to Subversion
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 of the various systems that much (work is ClearCase) so I have no opinions whatsoever. It's interesting reading though. Tim Delaney ___ 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
Re: [Python-Dev] Python + Ping
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 development *of* python, not development *with* python. This question should be posted to the python-list@python.org discussion list (or comp.lang.python newsgroup - they're the same thing) or possibly even the tutor@python.org mailing list. Tim Delaney ___ 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
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
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 of AttributeError. Everywhere I can think of where I would want to catch NotImplementedError, I would also want to catch AttributeError. My main question is whether I would want the reverse to also be true - anywhere I want to catch AttributeError, I would want to catch NotImplementedError. Perhaps instead it should be the other way around - AttributeError inherits from NotImplementedError. This does make some kind of sense - the attribute hasn't been implemented. Both seem to have some advantages, but neither really feels right to me. Thoughts? Anyway, I came to this via another thing - NotImplementedError doesn't play very well with super(). In many ways it's worse to call super().method() that raises NotImplementedError than super().method() where the attribute doesn't exist. In both cases, the class calling super() needs to know whether or not it's at the end of the MRO for that method - possible to find out in most cases that would raise AttributeError, but impossible for a method that raises NotImplementedError. The only way I can think of to deal with this is to do a try: except (AttributeError, NotImplementedError) around every super() attribute call. This seems bad. Tim Delaney ___ 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
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
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 restore the context to what it was before the with statement at the end of the with statement. Any other use should contain dire warnings ;) This works for the HTML tags - the original context is being outside the html tag - and the additional explanation is sufficient warning IMO. Tim Delaney ___ 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
Re: [Python-Dev] 'With' context documentation draft (was Re:Terminology for PEP 343
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__ / __exit_with__ __enter_context__ / __exit_context__ :) Tim Delaney ___ 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
Re: [Python-Dev] Terminology for PEP 343
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 maybe you're Well, HR considers me to be a resource ... ;) Personally, I'm very happy with considering anything a with statement manages as a resource. Tim Delaney ___ 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
Re: [Python-Dev] cephes module missing
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 your questions to python-list@python.org (or via the newsgroup comp.lang.python). Tim Delaney ___ 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
Re: [Python-Dev] Possible C API problem?
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 it's just not practical for me to take that on myself now. I'm hoping to get some help from other pythonistas where someone will say -- yes, it's getting a bus error for so-and-so reason, and if you do it this other way, you'll be fine... Well, it appears you have a workaround (METH_VARARGS) so I'd suggest using that for now, and raise a bug report at SourceForge http://sourceforge.net/tracker/?group_id=5470atid=105470. Tim Delaney ___ 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
