Re: [Python-Dev] Pre-pre PEP for 'super' keyword

2007-05-06 Thread Delaney, Timothy (Tim)
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 s

Re: [Python-Dev] [Python-3000] Pre-pre PEP for 'super' keyword

2007-04-29 Thread Delaney, Timothy (Tim)
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

Re: [Python-Dev] [Python-3000] Pre-pre PEP for 'super' keyword

2007-04-29 Thread Delaney, Timothy (Tim)
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 rec

Re: [Python-Dev] function for counting items in a sequence

2007-04-09 Thread Delaney, Timothy (Tim)
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

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

2007-03-18 Thread Delaney, Timothy (Tim)
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/pyth

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

2007-03-18 Thread Delaney, Timothy (Tim)
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 th

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

2007-03-14 Thread Delaney, Timothy (Tim)
"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 fi

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

2007-03-14 Thread Delaney, Timothy (Tim)
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 > fi

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

2007-03-14 Thread Delaney, Timothy (Tim)
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 beh

Re: [Python-Dev] New syntax for 'dynamic' attribute access

2007-02-15 Thread Delaney, Timothy (Tim)
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 d

Re: [Python-Dev] Py2.6 ideas

2007-02-15 Thread Delaney, Timothy (Tim)
[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 th

Re: [Python-Dev] Py2.6 ideas

2007-02-15 Thread Delaney, Timothy (Tim)
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

Re: [Python-Dev] New syntax for 'dynamic' attribute access

2007-02-12 Thread Delaney, Timothy (Tim)
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, bu

Re: [Python-Dev] New syntax for 'dynamic' attribute access

2007-02-11 Thread Delaney, Timothy (Tim)
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 fa

Re: [Python-Dev] Eliminating f_tstate

2007-01-22 Thread Delaney, Timothy (Tim)
"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. > > W

Re: [Python-Dev] Importing .pyc in -O mode and vice versa

2006-11-06 Thread Delaney, Timothy (Tim)
"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 coul

Re: [Python-Dev] Caching float(0.0)

2006-10-02 Thread Delaney, Timothy (Tim)
[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 > f

Re: [Python-Dev] unicode hell/mixing str and unicode as dictionary keys

2006-08-03 Thread Delaney, Timothy (Tim)
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 ___

Re: [Python-Dev] Behavior change in subprocess.py

2006-07-20 Thread Delaney, Timothy (Tim)
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

[Python-Dev] FW: Bug? Certainly a new *behavior* from subprocess in 2.5 on Win32

2006-07-20 Thread Delaney, Timothy (Tim)
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 be

Re: [Python-Dev] ImportWarning flood

2006-06-26 Thread Delaney, Timothy (Tim)
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

Re: [Python-Dev] Switch statement

2006-06-19 Thread Delaney, Timothy (Tim)
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

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

2006-05-29 Thread Delaney, Timothy (Tim)
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 > u

Re: [Python-Dev] PEP-xxx: Unification of for statement andlist-comp syntax

2006-05-22 Thread Delaney, Timothy (Tim)
Niko Matsakis wrote: > For what it's worth, I also favor the continue syntax Heiko compared > his code against. I also commonly do early tests and either break or continue, but my criteria is whether it makes the flow easier to understand. Sometimes it does, sometimes it doesn't. (on two lines of

Re: [Python-Dev] [Python-checkins] r46043 - peps/trunk/pep-0356.txt

2006-05-22 Thread Delaney, Timothy (Tim)
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 p

Re: [Python-Dev] [Python-checkins] r46043 - peps/trunk/pep-0356.txt

2006-05-21 Thread Delaney, Timothy (Tim)
Steve Holden wrote: > Will it be acceptable to add new (performance) changes between Alpha 3 > and beta 1, or would developers prefer to put a fourth alpha in to the > schedule? > > The intention is there should be no major functionality added by the > sprint, simply that performance should be im

Re: [Python-Dev] total ordering.

2006-05-11 Thread Delaney, Timothy (Tim)
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

Re: [Python-Dev] lambda in Python

2006-05-04 Thread Delaney, Timothy (Tim)
Guido van Rossum wrote: > Reminder: the best way to get rid of a troll is to ignore him. Indeed. Xah got past Spambayes for me because this time he posted on Python-dev - I doubt that he'll get past Spambayes again by doing that :) Should we add an explicit rule to the Python-dev spam filter for

Re: [Python-Dev] elimination of scope bleeding ofiteration variables

2006-05-02 Thread Delaney, Timothy (Tim)
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

Re: [Python-Dev] elimination of scope bleeding ofiteration variables

2006-05-01 Thread Delaney, Timothy (Tim)
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

Re: [Python-Dev] Dropping __init__.py requirement for subpackages

2006-04-26 Thread Delaney, Timothy (Tim)
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 u

Re: [Python-Dev] Dropping __init__.py requirement for subpackages

2006-04-26 Thread Delaney, Timothy (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

Re: [Python-Dev] Updated context management documentation

2006-04-25 Thread Delaney, Timothy (Tim)
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

Re: [Python-Dev] pdb segfaults in 2.5 trunk?

2006-04-17 Thread Delaney, Timothy (Tim)
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 ___ P

Re: [Python-Dev] pdb segfaults in 2.5 trunk?

2006-04-11 Thread Delaney, Timothy (Tim)
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 seem

Re: [Python-Dev] RELEASED Python 2.5 (alpha 1)

2006-04-05 Thread Delaney, Timothy (Tim)
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) abo

Re: [Python-Dev] current 2.5 status

2006-04-04 Thread Delaney, Timothy (Tim)
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

Re: [Python-Dev] SF #1462485 - StopIteration raised in body of 'with' statement suppressed

2006-04-03 Thread Delaney, Timothy (Tim)
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

[Python-Dev] SF #1462700 - Errors in PCbuild

2006-04-03 Thread Delaney, Timothy (Tim)
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 task). Nant couldn't build 2.5 without the fixes - basica

Re: [Python-Dev] Bug Day on Friday, 31st of March

2006-04-02 Thread Delaney, Timothy (Tim)
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 "newbie

[Python-Dev] SF #1462485 - StopIteration raised in body of 'with' statement suppressed

2006-04-02 Thread Delaney, Timothy (Tim)
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 th

Re: [Python-Dev] pysqlite for 2.5?

2006-03-29 Thread Delaney, Timothy (Tim)
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 D

Re: [Python-Dev] Making builtins more efficient

2006-03-12 Thread Delaney, Timothy (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 whate

Re: [Python-Dev] bytes.from_hex()

2006-03-02 Thread Delaney, Timothy (Tim)
Delaney, Timothy (Tim) wrote: > unicode.frombytes(cls, encoding) unicode.frombytes(encoding) ... Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.

Re: [Python-Dev] bytes.from_hex()

2006-03-02 Thread Delaney, Timothy (Tim)
Just van Rossum wrote: > My preference for bytes -> unicode -> bytes API would be this: > > u = unicode(b, "utf8") # just like we have now > b = u.tobytes("utf8") # like u.encode(), but being explicit > # about the resulting type +1 - I was going to write e

Re: [Python-Dev] operator.is*Type

2006-02-22 Thread Delaney, Timothy (Tim)
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 ... Si

Re: [Python-Dev] [ python-Feature Requests-1436243 ] Extend pre-allocated integers to cover [0, 255]

2006-02-22 Thread Delaney, Timothy (Tim)
SourceForge.net wrote: > Status: Closed > Resolution: Accepted And here I was, thinking I might actually work on this and submit a patch on the weekend ... Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/lis

Re: [Python-Dev] s/bytes/octet/ [Was:Re: bytes.from_hex() [Was:PEP332 revival in coordination with pep 349?]]

2006-02-21 Thread Delaney, Timothy (Tim)
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 __

Re: [Python-Dev] s/bytes/octet/ [Was:Re: bytes.from_hex() [Was: PEP332 revival in coordination with pep 349?]]

2006-02-21 Thread Delaney, Timothy (Tim)
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

Re: [Python-Dev] s/bytes/octet/ [Was:Re: bytes.from_hex() [Was: PEP 332 revival in coordination with pep 349?]]

2006-02-21 Thread Delaney, Timothy (Tim)
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

Re: [Python-Dev] defaultdict proposal round three

2006-02-20 Thread Delaney, Timothy (Tim)
"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, b

Re: [Python-Dev] defaultdict proposal round three

2006-02-20 Thread Delaney, Timothy (Tim)
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 subclasse

Re: [Python-Dev] Proposal: defaultdict

2006-02-16 Thread Delaney, Timothy (Tim)
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, argum

Re: [Python-Dev] Octal literals

2006-02-02 Thread Delaney, Timothy (Tim)
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

Re: [Python-Dev] Octal literals

2006-02-02 Thread Delaney, Timothy (Tim)
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/

Re: [Python-Dev] Include ctypes into core Python?

2006-01-11 Thread Delaney, Timothy (Tim)
"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 sol

Re: [Python-Dev] Include ctypes into core Python?

2006-01-10 Thread Delaney, Timothy (Tim)
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 docum

Re: [Python-Dev] Include ctypes into core Python?

2006-01-10 Thread Delaney, Timothy (Tim)
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

Re: [Python-Dev] ast-objects branch created

2005-12-09 Thread Delaney, Timothy (Tim)
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 thinkin

Re: [Python-Dev] ast-objects branch created

2005-12-07 Thread Delaney, Timothy (Tim)
"Martin v. Löwis" wrote: > Nick Coghlan wrote: >> As Fredrik pointed out a while back, the PyObject approach doesn't >> *have* to involve manual decref operations - PyObject's come with a >> ready made arena structure, in the form of PyList. > > That doesn't really work: PyList_Append (which you

Re: [Python-Dev] a different kind of reduce...

2005-11-01 Thread Delaney, Timothy (Tim)
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 fun

Re: [Python-Dev] apparent ruminations on mutable immutables (was:PEP 351, the freeze protocol)

2005-11-01 Thread Delaney, Timothy (Tim)
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

Re: [Python-Dev] Definining properties - a use case for classdecorators?

2005-10-16 Thread Delaney, Timothy (Tim)
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.

Re: [Python-Dev] Definining properties - a use case for class decorators?

2005-10-16 Thread Delaney, Timothy (Tim)
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.

Re: [Python-Dev] Extending tuple unpacking

2005-10-10 Thread Delaney, Timothy (Tim)
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? Tim Delaney _

Re: [Python-Dev] Extending tuple unpacking

2005-10-10 Thread Delaney, Timothy (Tim)
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

Re: [Python-Dev] Conditional Expression Resolution

2005-09-29 Thread Delaney, Timothy (Tim)
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 ___

Re: [Python-Dev] bool(iter([])) changed between 2.3 and 2.4

2005-09-20 Thread Delaney, Timothy (Tim)
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

Re: [Python-Dev] os.path.diff(path1, path2)

2005-09-19 Thread Delaney, Timothy (Tim)
Greg Ewing wrote: > Matthias Andreas Benkard wrote: > >> /home -> usr/home >> /usr >> /usr/home >> >> What does os.path.diff("/home/", "/usr/") yield? "../usr/", I would >> presume? But that's obviously wrong: > > IMO, the relpath method should just work textually on > the pathnames. It's up to

Re: [Python-Dev] PEP 3000 and iterators

2005-09-11 Thread Delaney, Timothy (Tim)
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_instanc

Re: [Python-Dev] reference counting in Py3K

2005-09-06 Thread Delaney, Timothy (Tim)
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. A

Re: [Python-Dev] Replacement for print in Python 3.0

2005-09-06 Thread Delaney, Timothy (Tim)
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

Re: [Python-Dev] String views (was: Re: Proof of the pudding: str.partition())

2005-08-31 Thread Delaney, Timothy (Tim)
[EMAIL PROTECTED] wrote: > How would this work? One of the advantages of the current string is > that the underlying data is NUL-terminated, so when passing strings > to C routines no copying is required. I didn't say it would be easy. Just that it's about the first cases where I've seen there c

Re: [Python-Dev] Proof of the pudding: str.partition()

2005-08-31 Thread Delaney, Timothy (Tim)
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, e

Re: [Python-Dev] Remove str.find in 3.0?

2005-08-30 Thread Delaney, Timothy (Tim)
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.

Re: [Python-Dev] Proof of the pudding: str.partition()

2005-08-30 Thread Delaney, Timothy (Tim)
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 =

Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)

2005-08-29 Thread Delaney, Timothy (Tim)
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 __

Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)

2005-08-29 Thread Delaney, Timothy (Tim)
Phillip J. Eby wrote: > +1 for partition(). Looks like I'm getting seriously outvoted here ... Still, as I said I don't think the name is overly important until the idea has been accepted anyway. How long did we go with people in favour of "resource manager" until "context manager" came up? Of c

Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)

2005-08-29 Thread Delaney, Timothy (Tim)
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

[Python-Dev] partition() (was: Remove str.find in 3.0?)

2005-08-29 Thread Delaney, Timothy (Tim)
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

Re: [Python-Dev] PEP 347: Migration to Subversion

2005-08-16 Thread Delaney, Timothy (Tim)
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 u

Re: [Python-Dev] Python + Ping

2005-08-10 Thread Delaney, Timothy (Tim)
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 t

Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0

2005-08-01 Thread Delaney, Timothy (Tim)
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 sub

Re: [Python-Dev] 'With' context documentation draft (was Re:Terminology for PEP 343

2005-07-06 Thread Delaney, Timothy (Tim)
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__ / __ex

Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343

2005-07-06 Thread Delaney, Timothy (Tim)
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 re

Re: [Python-Dev] Terminology for PEP 343

2005-07-04 Thread Delaney, Timothy (Tim)
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 t

Re: [Python-Dev] cephes module missing

2005-06-30 Thread Delaney, Timothy (Tim)
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

Re: [Python-Dev] Possible C API problem?

2005-06-27 Thread Delaney, Timothy (Tim)
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.