Re: [Python-Dev] Python 3 design principles
Oren Tirosh wrote: > Python 3 will most probably make big changes in the internal > implementation and the C API. Perhaps it will even be generated from > PyPy. Don't you think the current Python 3 "visions" becomes rather pointless with the raise of PyPy and interpreter extensions that are developed polymorphically? If the distinction between a user defined package and a language extension becomes more or less irrelevant who needs a language design committee for it's control? If someone takes the Python core in order to implement static typing it might be happen and run in a separate object space. But than, I'm almost sure, it won't be an ill-defined concept like "optional static typing" but Hindley-Milnor ( or a generalization ) which restricts dynamicity but enables type safety and static control otherwise. The idea of forking a language with a new release and thereby deevaluating older code seems somewhat archaic to me. Or the other way round: archaic materials and media like papyrus and scripture enabled communication across centurys changing slightly evolutionary and continously. Form this point of view PL development is still in a state of modernistic, youthfull irresponsibility. > I don't think keeping the common subset will really stand in the way > of making big improvements. The proposed 3.x changes that break it > seem more like nitpicking to me than significant improvements. So it seems. Kay ___ 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()
Greg Ewing wrote: >> .piece() can be both a verb and a noun > > Er, pardon? I don't think I've ever heard 'piece' used > as a verb in English. Can you supply an example sentence? Main Entry: 2 piece Function: transitive verb Inflected Form(s): pieced; piec·ing 1 : to repair, renew, or complete by adding pieces : PATCH 2 : to join into a whole -- often used with together - piec·er noun ___ 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] String views (was: Re: Proof of the pudding:str.partition())
[EMAIL PROTECTED] wrote: > As a Python programmer I'd get back what look like three strings: "http", > ":", and "//www.python.org/". If each of them was a view onto part of the > original string, only the last one would truly refer to a NUL-terminated > sequence of characters. If I then wanted to see what scheme's value > compared to, the string's comparison method would have to recognize that > it > wasn't truly NUL-terminated, copy it, call strncmp() or whatever > underlying > routine is used for string comparisons. (Maybe string comparisons are > done > inline. I'm sure there are some examples where the underlying C string > routines are called.) Python strings are character buffers with a known length, not null-terminated C strings. the CPython implementation guarantees that the character buffer has a trailing NULL character, but that's mostly to make it easy to pass Python strings directly to traditional C API:s. (string views are nothing new in Python. the original Unicode string implementation supported this, but that was partially removed during integration. the type still uses a separate buffer to hold the characters, though (unlike 8-bit strings that store the characters in the string object itself)) ___ 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 3 design principles
Greg Ewing wrote: > Charles Cazabon wrote: > >> Perhaps py3k could have a py2compat module. Importing it could have the >> effect of (for instance) putting compile, id, and intern into the global >> namespace, making print an alias for writeln, > > There's no way importing a module could add something that > works like the old print statement, unless some serious > magic is going on... You'd have to enclose print arguments in parentheses. Of course, the "trailing comma" form would be lost. Reinhold -- Mail address is perfectly valid! ___ 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()
Greg Ewing <[EMAIL PROTECTED]> wrote: > > Josiah Carlson wrote: > > > A bit of free thought brings me to the (half-baked) idea that if string > > methods accepted any object which conformed to the buffer interface; > > mmap, buffer, array, ... instances could gain all of the really > > convenient methods that make strings the objects to use in many cases. > > Not a bad idea, but they couldn't literally be string methods. > They'd have to be standalone functions like we used to have in > the string module before it got mercilessly deprecated. :-) > > Not sure what happens to this when the unicode/bytearray future > arrives, though. Treating a buffer of bytes as a character > string isn't going to be so straightforward then. Here's my thought: One could modify string methods to check the type of the input (string, unicode, or other). That check turns on a flag for whether the method returns are string, unicode, or buffers. One uses PyObject_AsBuffer() methods to pull the char* and length for any input offering the buffer protocol. Now here's the fun part: One makes the methods aware of the type of the self parameter. One sets the 'split' method for the buffer object to be 'string_split', etc. Unicode does indeed get tricky, how does one handle buffers of unicode objects? Right now, you get the raw pointer and underlying length ( len (buffer(u'hello')) == 10 ). If there was a unicode buffer (perhaps ubuffer), that would work, but I'm not sure I really like it. I notice much of the discussion on 'string views', which to me seems like another way of saying 'buffer', and if there is a 'string view', there would necessarily need to be a 'unicode view'. As for the bytes type, from what I understand, they should directly support buffers without issue. - Josiah ___ 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] Revising RE docs
> "Greg" == Greg Ewing <[EMAIL PROTECTED]> writes: Greg> Stephen J. Turnbull wrote: >> But you could have string objects (or a derivative) grow a >> "compiled_regexp" attribute internally. Greg> That would make the core dependent on the re module, which I Greg> think would be a bad idea. Probably. Greg> Personally I like the way the compilation step is made at Greg> least somewhat explicit. Regular expressions are not Greg> strings; a string is just one way of representing a regular Greg> expression. There could potentially be other representations Greg> that compile to the same re object. I guess I agree, but I would put the emphasis elsewhere. Something like, think of the call to compile() as a declaration that this string (or other representation) represents a regular expression. The actual compilation is an accidental side effect: it could be postponed to the first call of .match() or .search(). So I guess I would prefer a nomenclature like r = re.RegExp (string) over r = re.compile (string) Not a big deal though. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ 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 3 design principles
On 9/1/05, Robert Kern <[EMAIL PROTECTED]> wrote: > Oren Tirosh wrote: > > > While a lot of existing code will break on 3.0 it is still generally > > possible to write code that will run on both 2.x and 3.0: use only the > > "proper" forms above, do not assume the result of zip or range is a > > list, use absolute imports (and avoid static types, of course). I > > already write all my new code this way. > > > > Is this "common subset" a happy coincidence or a design principle? > > I think it's because those are the most obvious things right now. The > really radical stuff won't come up until active development on Python > 3000 actually starts. And it will, so any "common subset" will probably > not be very large. Static typing is radical stuff and doesn't hurt the common subset since it's optional. Making unicode the default is pretty radical and can be done without breaking the common subset (with the help of little tweaks like allowing str() to return unicode now like int() can return longs). Iterators and new-style classes were pretty radical changes that were managed elegantly and meet an an even stronger requirement than the common subset - they were achieved with full backward compatibility. Python 3 will most probably make big changes in the internal implementation and the C API. Perhaps it will even be generated from PyPy. I don't think keeping the common subset will really stand in the way of making big improvements. The proposed 3.x changes that break it seem more like nitpicking to me than significant improvements. Python is terrific. I find nothing I really want to change. Remove old cruft and add some brand new stuff, yes. But nothing to change. Oren ___ 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()
> "Greg" == Greg Ewing <[EMAIL PROTECTED]> writes: Greg> Er, pardon? I don't think I've ever heard 'piece' used as a Greg> verb in English. Can you supply an example sentence? "I'll let the reader piece it together." More closely related, I've heard/seen "piece out" used for task allocation (from "piecework", maybe), and my dictionary claims you can use it in the sense of adding more pieces or filling in missing pieces. Not the connotations we want. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ 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()
Greg Ewing wrote: > LD "Gus" Landis wrote: > >>.piece() can be both a verb and a noun > > > Er, pardon? I don't think I've ever heard 'piece' used > as a verb in English. Can you supply an example sentence? "After Java splintered in 20XX, diehard fans desperately pieced together the remaining fragments." Shane ___ 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()
LD "Gus" Landis wrote: > .piece() can be both a verb and a noun Er, pardon? I don't think I've ever heard 'piece' used as a verb in English. Can you supply an example sentence? (And no, "Piece, man!" doesn't count. :-) Greg ___ 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] Revising RE docs
Stephen J. Turnbull wrote: > But you could have string objects (or a derivative) grow a > "compiled_regexp" attribute internally. That would make the core dependent on the re module, which I think would be a bad idea. Personally I like the way the compilation step is made at least somewhat explicit. Regular expressions are not strings; a string is just one way of representing a regular expression. There could potentially be other representations that compile to the same re object. Greg ___ 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] String views
[EMAIL PROTECTED] wrote: > Ah, I forgot the data is part of the PyString object itself, not stored as a > separate char* array. Without a char* in the object it's kind of hard to do > views. That wouldn't be a problem if substrings were a separate subclass of basestring with their own representation. That's probably a good idea anyway, since you wouldn't want slicing to return substrings by default -- it should be something you have to explicitly ask for. Greg ___ 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] String views
[EMAIL PROTECTED] wrote: > If I then wanted to see what scheme's value > compared to, the string's comparison method would have to recognize that it > wasn't truly NUL-terminated, copy it, call strncmp() or whatever underlying > routine is used for string comparisons. Python string comparisons can't be using anything that relies on nul-termination, because Python strings can contain embedded nuls. Possibly it uses memcmp(), but that takes a length. You have a point when it comes to passing strings to other C routines, though. For those that don't have a variant which takes a maximum length, the substring type might have to keep a cached nul-terminated copy created on demand. Then the copying overhead would only be incurred if you did happen to pass a substring to such a routine. Greg ___ 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()
Josiah Carlson wrote: > A bit of free thought brings me to the (half-baked) idea that if string > methods accepted any object which conformed to the buffer interface; > mmap, buffer, array, ... instances could gain all of the really > convenient methods that make strings the objects to use in many cases. Not a bad idea, but they couldn't literally be string methods. They'd have to be standalone functions like we used to have in the string module before it got mercilessly deprecated. :-) Not sure what happens to this when the unicode/bytearray future arrives, though. Treating a buffer of bytes as a character string isn't going to be so straightforward then. Greg ___ 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] Alternative imports (Re: Python 3 design principles)
Oren Tirosh wrote: > Writing programs that run on both 2.x and 3 may require ugly > version-dependent tricks like: > > try: > compile > except NameError: > from sys import compile Just had a weird thought. What if you could write from sys or __builtin__ import compile which would be equivalent to try: from sys import compile except ImportError: from __builtin__ import compile Greg ___ 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 3 design principles
Charles Cazabon wrote: > Perhaps py3k could have a py2compat module. Importing it could have the > effect of (for instance) putting compile, id, and intern into the global > namespace, making print an alias for writeln, There's no way importing a module could add something that works like the old print statement, unless some serious magic is going on... Greg ___ 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] String views (was: Re: Proof of the pudding: str.partition())
James> I suspect this would be a pessimization most of the time, as it James> would require keeping a list of pointers to all the views James> referencing the string object. I'm skeptical about performance as well, but not for that reason. A string object can have a referent field. If not NULL, it refers to another string object which is INCREFed in the usual way. At string deallocation, if the referent is not NULL, the referent is DECREFed. If the referent is NULL, ob_sval is freed. Skip ___ 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()
>> for some use cases, a naive partition-based solution is going to be a >> lot slower >> than the old find+slice approach, no matter how you slice, index, or >> unpack the >> return value. The index+slice approach will still be available for such cases. I am sure we will see relative speed versus string size benchmarks. Terry J. Reedy ___ 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()
Hi,
FTR, I was not implying the $PIECE() was an answer at all, but only
suggesting it as an alternative name to .partition(). .piece() can be
both a verb and a noun as can .partition(), thus overcoming Nick's
objection to a "noun"ish thing doing the work of a "verb"ish thing.
Also, IIRC, I did say it would need to be "Pythonified". I pointed to the
official definition of $PIECE() merely to show that it was more than a
.split() as it has (sort of) some of the notion of a slice.
Phillip, I think, as I presented the $PIECE() thing, you were totally
justified to recoil in horror. That said, it would be nice if there were
a way to "save" the result of the .partition() result in a way that would
not require duplicating the .partition() call (as has been suggested)
making things like:
... s.partition(":").head, s.partition(":").tail
unnecessary. One could get accustomed to the
_,_,tail = s.partition(...)
style I suppose, but it seems a bit "different", IMO. Also, it seems
that the interference with i18n diminishes the appeal of that style.
Cheers,
--ldl
On 8/30/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> ...
> No, just to point out that you can make up whatever semantics you want, but
> the semantics you show above are *not* the same as what are shown at the
> page the person who posted about $PIECE cited, and on whose content I based
> my reply:
>
> http://www.jacquardsystems.com/Examples/function/piece.htm
>
> If you were following those semantics, then the code you presented above is
> buggy, as host.piece(':',1,2) would return the original string!
>
> Of course, since I know nothing of MUMPS besides what's on that page, it's
> entirely possible I've misinterpreted that page in some hideously subtle
> way -- as I pointed out in my original post regarding $PIECE. I like to
> remind myself and others of the possibility that I *could* be wrong, even
> when I'm *certain* I'm right, because it helps keep me from appearing any
> more arrogant than I already do, and it also helps to keep me from looking
> too stupid in those cases where I turn out to be wrong. Perhaps you might
> find that approach useful as well.
>
> In any case, to avoid confusion, you should probably specify the semantics
> of your piece() proposal in Python terms, so that those of us who don't
> know MUMPS have some possibility of grasping the inner mysteries of your
> proposal.
>
--
LD Landis - N0YRQ - from the St Paul side of Minneapolis
___
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] stat() return value (was: Re: Proof of thepudding: str.partition())
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On 8/31/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> I think that would be a good idea. Return an honest-to-goodness stat >> object >> and also strip the "st_" prefixes removed from the attributes. There's >> no >> namespace collision problems from which the prefixes protect us. > > +1 on dropping the sequence. Good. Another addition to PEP 3000. I was hoping this would not require a long-winded and possibly boring justification for something I suspect (without checking the archives) was in the back of some minds when the attributes were added. > -0 on dropping the st_ prefix; these are conventional and familiar to > all UNIX developers and most C programmers, and help with grepping > (and these days, Googling :). Terry J. Reedy ___ 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] Revising RE docs
> "Michael" == Michael Chermside <[EMAIL PROTECTED]> writes: Michael> (2) is what we have today, but I would prefer (1) to Michael> gently encourage people to use the precompiled objects Michael> (which are distinctly faster when re-used). Didn't Fredrik Lundh strongly imply that implicitly compiled objects are cached? That's a pretty big speed up right there. Sure, the precompiled objects are faster because you don't have to find them. But you could have string objects (or a derivative) grow a "compiled_regexp" attribute internally. Then if you have a random regexp you think you might have used elsewhere, just intern it. (NB, wild guess, here, I don't know enough about current implementation to know if this is a reasonable extension.) Michael> Does anyone else think we ought to swap that around in Michael> the documentation? I'm not trying to assign more work to Michael> Fred... but if there were a python-dev consensus that Michael> this would be desirable, then perhaps someone would be Michael> encouraged to supply a patch. +1. I won't have time for some weeks, but I'd already flagged Barry's post for later consideration. I hope that doesn't stop somebody else from picking up the ball, though. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ 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] String views (was: Re: Proof of the pudding: str.partition())
On Aug 31, 2005, at 10:21 PM, [EMAIL PROTECTED] wrote: > > Tim> One of the big disadvantages of string views is that they > need to > Tim> keep the original object around, no matter how big it is. > But in > Tim> the case of partition, much of the time the original string > Tim> survives for at least a similar period to the partitions. > > Not necessarily. Presumably a string view would reference another > string > object's data buffer. A possible optimization would be to convert > from a > view to a normal string once the original strings' refcount dropped > to one, > particularly if the view's size was substantially smaller than that > of the > original string. I suspect this would be a pessimization most of the time, as it would require keeping a list of pointers to all the views referencing the string object. James ___ 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] String views (was: Re: Proof of the pudding: str.partition())
Tim> One of the big disadvantages of string views is that they need to Tim> keep the original object around, no matter how big it is. But in Tim> the case of partition, much of the time the original string Tim> survives for at least a similar period to the partitions. Not necessarily. Presumably a string view would reference another string object's data buffer. A possible optimization would be to convert from a view to a normal string once the original strings' refcount dropped to one, particularly if the view's size was substantially smaller than that of the original string. Skip ___ 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] String views (was: Re: Proof of the pudding: str.partition())
[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 could be a real advantage to using string views. And I don't even know that. One of the big disadvantages of string views is that they need to keep the original object around, no matter how big it is. But in the case of partition, much of the time the original string survives for at least a similar period to the partitions. 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] String views (was: Re: Proof of the pudding: str.partition())
Skip> OTOH, maybe that would work. Perhaps we should try it. Ah, I forgot the data is part of the PyString object itself, not stored as a separate char* array. Without a char* in the object it's kind of hard to do views. Skip ___ 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] String views (was: Re: Proof of the pudding: str.partition())
Tim> I'm actually starting to think that this may be a good use case for
Tim> views of strings i.e. rather than create 3 new strings, each
Tim> "string" is a view onto the string that was partitioned.
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. Suppose I executed
scheme, _, rest = "http://www.python.org/".partition(':')
As a Python programmer I'd get back what look like three strings: "http",
":", and "//www.python.org/". If each of them was a view onto part of the
original string, only the last one would truly refer to a NUL-terminated
sequence of characters. If I then wanted to see what scheme's value
compared to, the string's comparison method would have to recognize that it
wasn't truly NUL-terminated, copy it, call strncmp() or whatever underlying
routine is used for string comparisons. (Maybe string comparisons are done
inline. I'm sure there are some examples where the underlying C string
routines are called.)
OTOH, maybe that would work. Perhaps we should try it.
Skip
___
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] stat() return value (was: Re: Proof of the pudding: str.partition())
On 8/31/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I think that would be a good idea. Return an honest-to-goodness stat object > and also strip the "st_" prefixes removed from the attributes. There's no > namespace collision problems from which the prefixes protect us. +1 on dropping the sequence. -0 on dropping the st_ prefix; these are conventional and familiar to all UNIX developers and most C programmers, and help with grepping (and these days, Googling :). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] stat() return value (was: Re: Proof of the pudding: str.partition())
>> In the case of stat() there is no reason other than historic for the >> results to be returned in any particular order, Terry> Which is why I wonder whether the sequence part should be dropped Terry> in 3.0. I think that would be a good idea. Return an honest-to-goodness stat object and also strip the "st_" prefixes removed from the attributes. There's no namespace collision problems from which the prefixes protect us. Skip ___ 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()
Reinhold Birkenfeld writes: > And it's horrible, for none of the other string methods accept a RE. I suppose it depends on your perspective as to what exactly is horrible. I tend to think it's too bad that none of the other string methods accept appropriate RE patterns. Strings are thought of as "core", whereas RE, a relatively new part of the stdlib, isn't. But it's OK -- it just gives the system more Java-ness, where you have lots of little modules, each of which does something slightly different. > There are languages which give REs too much weight by philosophy > (hint, hint), but Python isn't one of them. Interestingly, Python programmers > suffer less from the "help me, my RE doesn't work" problem. Yes, but perhaps the causative bug in those "other" languages is the confusion between string *literals* and RE *literals*, which isn't a problem in the idiom I suggested. Or perhaps if RE was more helpful in Python, Python programmers would indeed suffer from the same problem. Bill ___ 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] setdefault's second argument
> To save you from following that link, to this day I still mentally > translate "setdefault" to "getorset" whenever I see it. I read these out of order (so didn't see the giveaway getorsetandget) and spent some time wondering what an "orset" was. I figured it must be some obscure CS/text processing/numeric/literary term that suited this usage. So obscure that google's define couldn't find me a definition. set[with]default is maybe a terrible name, but it does have some things going for it ;) =Tony.Meyer ...perhaps it was the similarity to corset...but surely I'm too young to have "corset" spring to mind before "or set"... ___ 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] import exceptions
On 8/31/05, Neal Norwitz <[EMAIL PROTECTED]> wrote: > Is there any reason to import exceptions? It's only done in 4 places: > Lib/asyncore.py, Lib/shutil.py, Lib/idlelib/PyShell.py, and > Lib/test/test_exceptions.py. I can understand the one in test, but > should the other 3 be removed since exceptions are builtin? I'm guessing this is a remnant from a transitional period around Python 1.5. Let's get rid of it. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] python/dist/src/Lib/test test_re.py, 1.45.6.3, 1.45.6.4
On 8/31/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Log Message: > ... the tests aren't run by default because I wanted to minimize > upheaval to the 2.3 test suite What is the reasoning behind this? It seems to me that if a (passing) test is being added, maintenance releases are the *most* important places to run them. On the other hand, I've also seen Raymond check (regression) tests into only development, so it seems to be a conscious choice. *I* just don't understand it. -jJ ___ 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] import exceptions
Is there any reason to import exceptions? It's only done in 4 places: Lib/asyncore.py, Lib/shutil.py, Lib/idlelib/PyShell.py, and Lib/test/test_exceptions.py. I can understand the one in test, but should the other 3 be removed since exceptions are builtin? n ___ 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()
Steve Holden <[EMAIL PROTECTED]> wrote: > > 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. > > > Indeed, and therefore the performance of rpartition is likely to get > worse as the length of the input strung increases. I don't like to think > about all those strings being created just to be garbage-collected. Pity > the poor CPU ... :-) > > > for some use cases, a naive partition-based solution is going to be a lot > > slower > > than the old find+slice approach, no matter how you slice, index, or unpack > > the > > return value. > > > Yup. Then it gets down to statistical arguments about the distribution > of use cases and input lengths. If we had a type that represented a > substring of an existing string it might avoid the stress, but I'm not > sure I see that one flying. What about buffer()? Tack on some string methods and you get a string slice-like instance with very low memory requirements. Add on actual comparisons of buffers and strings, and you can get nearly everything desired with very low memory overhead. A bit of free thought brings me to the (half-baked) idea that if string methods accepted any object which conformed to the buffer interface; mmap, buffer, array, ... instances could gain all of the really convenient methods that make strings the objects to use in many cases. If one wanted to keep string methods returning strings, and other objects with the buffer protocol which use string methods returning buffer objects, that seems reasonable (and probably a good idea). - Josiah P.S. Pardon me if the idea is pure insanity, I haven't been getting much sleep lately, and just got up from a nap that seems to have clouded my judgement (I just put milk in my juice...). ___ 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] Design Principles
On Wed, Aug 31, 2005, Raymond Hettinger wrote: > > FWIW, after this is over, I'll put together a draft list of these > principles. The one listed above has served us well. An early draft of > itertools.ifilter() had an invert flag. The toolset improved when that > was split to a separate function, ifilterfalse(). > > Other thoughts: > > Tim's rule on algorithm selection: We read Knuth so you don't have to. > > Raymond's rule on language proposals: Assertions that construct X is > better than an existing construct Y should be backed up by a variety of > side-by-side comparisons using real-world code samples. > > I'm sure there are plenty more if these in the archives. Nice! Also a pointer to the Zen of Python. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ The way to build large Python applications is to componentize and loosely-couple the hell out of everything. ___ 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:
> Phillip J. Eby wrote:
>
>
>>Yep, subscripting and slicing are more than adequate to handle *all* of
>>those use cases, even the ones that some people have been jumping through
>>odd hoops to express:
>>
>>before = x.partition(sep)[0]
>>found = x.partition(sep)[1]
>>after = x.partition(sep)[2]
>>
>>before, found = x.partition("foo")[:2]
>>found, after = x.partition("foo")[1:]
>>before, after = x.partition("foo")[::2]
>>
>>Okay, that last one is maybe a little too clever. I'd personally just use
>>'__' or 'DONTCARE' or something like that for the value(s) I didn't care
>>about, because it actually takes slightly less time to unpack a 3-tuple
>>into three function-local variables than it does to pull out a single
>>element of the tuple, and it's almost twice as fast as taking a slice and
>>unpacking it into two variables.
>
>
> you're completely missing the point.
>
> 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.
>
Indeed, and therefore the performance of rpartition is likely to get
worse as the length of the input strung increases. I don't like to think
about all those strings being created just to be garbage-collected. Pity
the poor CPU ... :-)
> for some use cases, a naive partition-based solution is going to be a lot
> slower
> than the old find+slice approach, no matter how you slice, index, or unpack
> the
> return value.
>
Yup. Then it gets down to statistical arguments about the distribution
of use cases and input lengths. If we had a type that represented a
substring of an existing string it might avoid the stress, but I'm not
sure I see that one flying.
>
>>So, using three variables is both faster *and* easier to read than any of
>>the variations anybody has proposed, including the ones I just showed above.
>
>
> try again.
>
The collective brainpower that's been exercised on this one enhancement
already must be phenomenal, but the proposal still isn't perfect.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
___
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 3 design principles
On Aug 31, 2005, at 5:00 PM, Robert Kern wrote: > IMO, if we are going to restrict Python 3000 enough to protect that > "common subset," then there's not enough payoff to justify breaking > *any* backwards compatibility. If my current codebase[1] isn't > going to > be supported in Python 3000, I'm going to want the Python > developers to > use that opportunity to the fullest advantage to make a better > language. I disagree fully. As a maintainer in the Twisted project I very much hope that it is possible to adapt the code such that it will work on Python 3 while still maintaining compatibility with Python 2.X. Otherwise, it will be impossible to make the transition to Python 3 without either maintaining two forks of the codebase (I doubt that'll happen) or abandoning all users still on Python 2. And that surely won't happen either, for a while. Maybe by the time Python 3.1 or 3.2 comes out it'll be possible to completely abandon Python 2. I'm perfectly happy to see backwards-incompatible changes in Python 3, as long as they do not make it completely impossible to write code that can run on both Python 3 and Python 2.X. This suggests a few things to me: a) new features should be added to the python 2.x series first wherever possible. b) 3.0 should by and large by simply a feature-removal release, removing support for features already marked as going away by the end of the 2.x series and which have replacements. c) don't make any radical syntax changes which make it impossible to write code that can even parse in both versions. d) for all backwards-incompatible-change proposals, have a section dedicated to compatibility and migration of old code that explains both how to modify old code to do things purely the new way, _and_ how to modify code to work under both the old and new ways. Strive to make this as simple as possible, but if totally necessary, it may be reasonable to suggest writing a wrapper function which changes behavior based on python version/existence of new methods. James ___ 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] Design Principles
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > FWIW, after this is over, I'll put together a draft list of these > principles. The one listed above has served us well. An early draft of > itertools.ifilter() had an invert flag. The toolset improved when that > was split to a separate function, ifilterfalse(). > > Other thoughts: > > Tim's rule on algorithm selection: We read Knuth so you don't have to. > > Raymond's rule on language proposals: Assertions that construct X is > better than an existing construct Y should be backed up by a variety of > side-by-side comparisons using real-world code samples. > > I'm sure there are plenty more if these in the archives. This would make a good information PEP to point people to when they ask 'Why ...' and the answer goes back to one of these principles. Terry J. Reedy ___ 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 3 design principles
Oren Tirosh wrote: > While a lot of existing code will break on 3.0 it is still generally > possible to write code that will run on both 2.x and 3.0: use only the > "proper" forms above, do not assume the result of zip or range is a > list, use absolute imports (and avoid static types, of course). I > already write all my new code this way. > > Is this "common subset" a happy coincidence or a design principle? I think it's because those are the most obvious things right now. The really radical stuff won't come up until active development on Python 3000 actually starts. And it will, so any "common subset" will probably not be very large. IMO, if we are going to restrict Python 3000 enough to protect that "common subset," then there's not enough payoff to justify breaking *any* backwards compatibility. If my current codebase[1] isn't going to be supported in Python 3000, I'm going to want the Python developers to use that opportunity to the fullest advantage to make a better language. [1] By which I mean the sum total of the code that I use not just code that I've personally written. I am a library-whore. -- Robert Kern [EMAIL PROTECTED] "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter ___ 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 3 design principles
Am 31-Aug 05, Charles Cazabon <[EMAIL PROTECTED]> schrieb: > Perhaps py3k could have a py2compat module. Importing it could have the > effect of (for instance) putting compile, id, and intern into the global > namespace, making print an alias for writeln, alias the standard library > namespace, ... ? from __past__ import python2 Grüße, Collin Winter ___ 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 3 design principles
On 8/31/05, Oren Tirosh <[EMAIL PROTECTED]> wrote: > > Writing programs that run on both 2.x and 3 may require ugly > version-dependent tricks like: > > try: > compile > except NameError: > from sys import compile Note we can ease this process a little by making a copy without removing, e.g., adding compile to sys now without removing it. As programs support only Python 2.5+, they could use sys.compile and wouldn't need to resort to the try/except above. I realize this is only a marginal improvement. However, if we don't start making changes, we will be stuck maintain suboptimal behaviour forever. n ___ 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()
Bill Janssen wrote:
>> >(*) Regular Expressions
>>
>> This can be orthogonally added to the 're' module, and definitely should
>> not be part of the string method.
>
> Sounds right to me, and it *should* be orthogonally added to the 're'
> module coincidentally simultaneously with the change to the string
> object :-).
>
> I have to say, it would be nice if
>
>"foo bar".partition(re.compile('\s'))
>
> would work. That is, if the argument is an re pattern object instead
> of a string, it would be nice if it were understood appropriately,
> just for symmetry's sake. But it's hardly necessary.
And it's horrible, for none of the other string methods accept a RE.
In Python, RE functionality is in the re module and nowhere else, and this
is a Good Thing. There are languages which give REs too much weight by
philosophy
(hint, hint), but Python isn't one of them. Interestingly, Python programmers
suffer less from the "help me, my RE doesn't work" problem.
Reinhold
--
Mail address is perfectly valid!
___
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 3 design principles
Oren Tirosh <[EMAIL PROTECTED]> wrote: > > Not all proposed changes remove redundancy or add completely new > things. Some of them just change the way certain things must be done. > For example: > * Moving compile, id, intern to sys > * Replacing print with write/writeln > And possibly the biggest change: > * Reorganize the standard library to not be as shallow > > I'm between +0 and -1 on these. I don't find them enough of an > improvement to break this "common subset" behavior. It's not quite the > same as strict backward compatibility and I find it worthwhile to try > to keep it. > > Writing programs that run on both 2.x and 3 may require ugly > version-dependent tricks like: > > try: > compile > except NameError: > from sys import compile Perhaps py3k could have a py2compat module. Importing it could have the effect of (for instance) putting compile, id, and intern into the global namespace, making print an alias for writeln, alias the standard library namespace, ... ? Charles -- --- Charles Cazabon <[EMAIL PROTECTED]> GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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] Python 3 design principles
Most of the changes in PEP 3000 are tightening up of "There should be one obvious way to do it.": * Remove multiple forms of raising exceptions, leaving just "raise instance" * Remove exec as statement, leaving the compatible tuple/call form. * Remove <>, ``, leaving !=, repr etc. Other changes are to disallow things already considered poor style like: * No assignment to True/False/None * No input() * No access to list comprehension variable And there is also completely new stuff like static type checking. While a lot of existing code will break on 3.0 it is still generally possible to write code that will run on both 2.x and 3.0: use only the "proper" forms above, do not assume the result of zip or range is a list, use absolute imports (and avoid static types, of course). I already write all my new code this way. Is this "common subset" a happy coincidence or a design principle? Not all proposed changes remove redundancy or add completely new things. Some of them just change the way certain things must be done. For example: * Moving compile, id, intern to sys * Replacing print with write/writeln And possibly the biggest change: * Reorganize the standard library to not be as shallow I'm between +0 and -1 on these. I don't find them enough of an improvement to break this "common subset" behavior. It's not quite the same as strict backward compatibility and I find it worthwhile to try to keep it. Writing programs that run on both 2.x and 3 may require ugly version-dependent tricks like: try: compile except NameError: from sys import compile or perhaps try: import urllib except ImportError: from www import urllib Should the "common subset" be a design principle of Python 3? Do compile and id really have to be moved from __builtins__ to sys? Could the rearrangement of the standard library be a bit less aggressive and try to leave commonly used modules in place? Oren ___ 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()
> >(*) Regular Expressions
>
> This can be orthogonally added to the 're' module, and definitely should
> not be part of the string method.
Sounds right to me, and it *should* be orthogonally added to the 're'
module coincidentally simultaneously with the change to the string
object :-).
I have to say, it would be nice if
"foo bar".partition(re.compile('\s'))
would work. That is, if the argument is an re pattern object instead
of a string, it would be nice if it were understood appropriately,
just for symmetry's sake. But it's hardly necessary.
Presumably in the re module, there would be a function like
re.partition("\s", "foo bar")
for one-shot usage, or the expression
re.compile('\s').partition("foo bar")
Bill
___
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] Design Principles
> > While I'm at it, why not propose that for py3k that > > .rfind/.rindex/.rjust/.rsplit disappear, and .find/.index/.just/.split > grow an > > optional "fromright" (or equivalent) optional keyword argument? > > This violates one of my design principles: don't add boolean options > to an API that control the semantics in such a way that the option > value is (nearly) always a constant. Instead, provide two different > method names. > > The motivation for this rule comes partly for performance: parameters > are relatively expensive, and you shouldn't make the method test > dynamically for a parameter value that is constant for the call site; > and partly from readability: don't bother the reader with having to > remember the full general functionality and how it is affected by the > various flags; also, a Boolean positional argument is a really poor > clue about its meaning, and it's easy to misremember the sense > reversed. > > PS. This is a special case of a stronger design principle: don't let > the *type* of the return value depend on the *value* of the arguments. > > PS2. As with all design principles, there are exceptions. But they > are, um, exceptional. index/rindex is not such an exception. FWIW, after this is over, I'll put together a draft list of these principles. The one listed above has served us well. An early draft of itertools.ifilter() had an invert flag. The toolset improved when that was split to a separate function, ifilterfalse(). Other thoughts: Tim's rule on algorithm selection: We read Knuth so you don't have to. Raymond's rule on language proposals: Assertions that construct X is better than an existing construct Y should be backed up by a variety of side-by-side comparisons using real-world code samples. I'm sure there are plenty more if these in the archives. Raymond ___ 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] Proof of the pudding: str.partition()
Michael Chermside wrote (but I reordered):
>Simplicity and elegence are two of the reasons that this
> is such an excellent proposal, let's not lose them.
> Raymond's original definition for partition() did NOT support
> any of the following:
> (*) Regular Expressions
While this is obviously more powerful, and an analogue should
probably go in re ... it doesn't belong in strings. I don't want to
have to explain why
"www.python.org".part('.')
acts strangely (forget to escape the period).
> (*) Ways to generate just 1 or 2 of the 3 values if some are
> not going to be used
> (*) Clever use of indices to avoid copying strings
> (*) Behind-the-scenes tricks to allow repeated re-partitioning
> to be faster than O(n^2)
I think these may be useful behind the scenes, but the API should
not expose them unless they are made more general.
For instance, the compiler could recognize that junk variables (or
variable names matching a certain pattern?) don't really have to be
created -- and that would be useful for more than string splitting.
Doing it as a special case here just leads to a backwards compatibility
wart later.
-jJ
___
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] Alternative name for str.partition()
[In http://mail.python.org/pipermail/python-dev/2005-August/055880.html ]
Andrew Durdin wrote:
> one of the "fixed stdlib" examples that Raymond
> posted actually uses rpartition and partition in two consecutive lines
Even with that leadin, even right next to each other, it took me a bit of
time to see the difference between rest.rpartition and rest.partition.
> rest, _, query = rest.rpartition('?')
> script, _, rest = rest.partition('/')
Shortening the names helps, because a single letter matters more.
> rest, _, query = rest.rpart('?')
> script, _, rest = rest.part('/')
A different-looking word (such as Greg's suggestion) might be even
better, if the word also works on its own.
> rest, _, query = rest.rsplit_at('?')
> script, _, rest = rest.split_at('/')
-jJ
___
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()
Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 8/31/05, Charles Cazabon <[EMAIL PROTECTED]> wrote: > > > While I'm at it, why not propose that for py3k that > > .rfind/.rindex/.rjust/.rsplit disappear, and .find/.index/.just/.split > > grow an optional "fromright" (or equivalent) optional keyword argument? > > This violates one of my design principles: Ah, excellent response. Are your design principles written down anywhere? I didn't see anything on your essays page about them, but I'd like to learn at the feet of the BDFL. > don't add boolean options to an API that control the semantics in such a way > that the option value is (nearly) always a constant. Instead, provide two > different method names. Hmmm. I really dislike the additional names, but ... > The motivation for this rule comes partly for performance: parameters > are relatively expensive, and you shouldn't make the method test > dynamically for a parameter value that is constant for the call site; I can see this. > and partly from readability: don't bother the reader with having to > remember the full general functionality and how it is affected by the > various flags; This I don't think is so bad. It's analogous to providing the "reverse" parameter to sorted et al, and I don't think that's particularly hard to remember. It would also be rarely used; I use find/index tens of times more often than I use rfind/rindex, and I presume it would be the same for a hypothetical .part/.rpart. > also, a Boolean positional argument is a really poor clue about its meaning, > and it's easy to misremember the sense reversed. I totally agree. I therefore borrowed the time machine and modified my proposal to suggest it should be a keyword argument, not a positional one :). > PS. This is a special case of a stronger design principle: don't let > the *type* of the return value depend on the *value* of the arguments. Hmmm. In all of these cases, the type of the return value is constant. Only the value would change based on the value of the arguments. ... ? Charles -- --- Charles Cazabon <[EMAIL PROTECTED]> GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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()
<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > >>> 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". > >Terry> One could see that as a special-case back-compatibility kludge >Terry> that maybe should disappear in 3.0. > > Back compatibility with what? os.stat without attributes. 'that' referred to its current 'sequence with attributes' return. > I'm -1 on the notion of generating groups or attributes. We agree. A back-compatibility kludge is not a precedent to be emulated. >In the case of stat() there is no reason other than historic > for the results to be returned in any particular order, Which is why I wonder whether the sequence part should be dropped in 3.0. Terry J. Reedy ___ 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()
On 8/31/05, Charles Cazabon <[EMAIL PROTECTED]> wrote: > I would think that perhaps an optional second argument to the method that > controls whether it searches from the start (default) or end of the string > might be nicer than having two separate methods, even though that would lose > parallelism with the current .find/.index. > > While I'm at it, why not propose that for py3k that > .rfind/.rindex/.rjust/.rsplit disappear, and .find/.index/.just/.split grow an > optional "fromright" (or equivalent) optional keyword argument? This violates one of my design principles: don't add boolean options to an API that control the semantics in such a way that the option value is (nearly) always a constant. Instead, provide two different method names. The motivation for this rule comes partly for performance: parameters are relatively expensive, and you shouldn't make the method test dynamically for a parameter value that is constant for the call site; and partly from readability: don't bother the reader with having to remember the full general functionality and how it is affected by the various flags; also, a Boolean positional argument is a really poor clue about its meaning, and it's easy to misremember the sense reversed. PS. This is a special case of a stronger design principle: don't let the *type* of the return value depend on the *value* of the arguments. PS2. As with all design principles, there are exceptions. But they are, um, exceptional. index/rindex is not such an exception. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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()
Michael Chermside <[EMAIL PROTECTED]> wrote: > >(*) An rpartition() function that searches from the right > > ...except that I understand why he included it and am convinced > by the arguments (use cases can be demonstrated and people would > expect it to be there and complain if it weren't). I would think that perhaps an optional second argument to the method that controls whether it searches from the start (default) or end of the string might be nicer than having two separate methods, even though that would lose parallelism with the current .find/.index. While I'm at it, why not propose that for py3k that .rfind/.rindex/.rjust/.rsplit disappear, and .find/.index/.just/.split grow an optional "fromright" (or equivalent) optional keyword argument? Charles -- --- Charles Cazabon <[EMAIL PROTECTED]> GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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()
Phillip J. Eby wrote:
> Yep, subscripting and slicing are more than adequate to handle *all* of
> those use cases, even the ones that some people have been jumping through
> odd hoops to express:
>
> before = x.partition(sep)[0]
> found = x.partition(sep)[1]
> after = x.partition(sep)[2]
>
> before, found = x.partition("foo")[:2]
> found, after = x.partition("foo")[1:]
> before, after = x.partition("foo")[::2]
>
> Okay, that last one is maybe a little too clever. I'd personally just use
> '__' or 'DONTCARE' or something like that for the value(s) I didn't care
> about, because it actually takes slightly less time to unpack a 3-tuple
> into three function-local variables than it does to pull out a single
> element of the tuple, and it's almost twice as fast as taking a slice and
> unpacking it into two variables.
you're completely missing the point.
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.
for some use cases, a naive partition-based solution is going to be a lot slower
than the old find+slice approach, no matter how you slice, index, or unpack the
return value.
> So, using three variables is both faster *and* easier to read than any of
> the variations anybody has proposed, including the ones I just showed above.
try again.
___
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?)
Nick Coghlan wrote: > Ron Adam wrote: > >>I don't feel there is a need to avoid numbers entirely. In this case I >>think it's the better way to find the n'th seperator and since it's an >>optional value I feel it doesn't add a lot of complication. Anyway... >>It's just a suggestion. > > > Avoid overengineering this without genuine use cases. Raymond's review of the > standard library shows that the basic version of str.partition provides > definite readability benefits and also makes it easier to write correct code > - > enhancements can wait until we have some real experience with how people use > the method. > > Cheers, > Nick. The use cases for nth items 1 and -1 are the same ones for partition() and rpartition. It's only values greater or less than those that need use cases. (I'll try to find some.) True, a directional index enhancement could be added later, but not considering it now and then adding it later would mean rpartition() would become redundant and/or an argument against doing it later. As it's been stated fairly often, it's hard to remove something once it's put in. So it's prudent to consider a few alternative forms and rule them out, rather than try to change things later. Cheers, Ron ___ 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()
At 04:55 AM 8/31/2005 -0700, Michael Chermside wrote:
>Raymond's original definition for partition() did NOT support any
>of the following:
>
>(*) Regular Expressions
This can be orthogonally added to the 're' module, and definitely should
not be part of the string method.
>(*) Ways to generate just 1 or 2 of the 3 values if some are
>not going to be used
Yep, subscripting and slicing are more than adequate to handle *all* of
those use cases, even the ones that some people have been jumping through
odd hoops to express:
before = x.partition(sep)[0]
found = x.partition(sep)[1]
after = x.partition(sep)[2]
before, found = x.partition("foo")[:2]
found, after = x.partition("foo")[1:]
before, after = x.partition("foo")[::2]
Okay, that last one is maybe a little too clever. I'd personally just use
'__' or 'DONTCARE' or something like that for the value(s) I didn't care
about, because it actually takes slightly less time to unpack a 3-tuple
into three function-local variables than it does to pull out a single
element of the tuple, and it's almost twice as fast as taking a slice and
unpacking it into two variables.
So, using three variables is both faster *and* easier to read than any of
the variations anybody has proposed, including the ones I just showed above.
>(*) Clever use of indices to avoid copying strings
>(*) Behind-the-scenes tricks to allow repeated re-partitioning
>to be faster than O(n^2)
Yep, -1 on these.
>The absence of these "features" is a GOOD thing. It makes the
>behavior of partition() so simple and straightforward that it is
>easily documented and can be instantly understood by a competent
>programmer. I *like* keeping it simple. In fact, if anything, I'd
>give UP the one fancy feature he chose to include:
>
>(*) An rpartition() function that searches from the right
>
>...except that I understand why he included it and am convinced
>by the arguments (use cases can be demonstrated and people would
>expect it to be there and complain if it weren't).
I'd definitely like to keep rpartition. For example, splitting an HTTP
url's hostname from its port should be done with rpartition, since you can
have a 'username:password@' part before the host, and because the host can
be a bracketed bracketed IPv6 host address with colons in it.
>Simplicity and elegence are two of the reasons that this is such
>an excellent proposal,
+1.
___
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()
>> 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". Terry> One could see that as a special-case back-compatibility kludge Terry> that maybe should disappear in 3.0. Back compatibility with what? Since partition doesn't exist now there is nothing to be backward compatible with is there? I'm -1 on the notion of generating groups or attributes. In other cases (regular expressions, stat() results) there are good reasons to provide them. The results of a regular expression match are variable, depending on how many groups the user defines in his pattern. In the case of stat() there is no reason other than historic for the results to be returned in any particular order, so having named attributes makes the results easier to work with. The partition method has neither. It always returns a fixed tuple of three elements whose order is clearly based on the physical relationship of the three pieces of the string that have been partitioned. I think Raymond's original formulation is the correct one. Always return a three-element tuple of strings, nothing more. Use '_' or 'dummy' if there is some element you're not interested in. Skip ___ 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] Switching re and sre
FYI: In a discussion on the Python security response list, Guido suggested that the sre.py and re.py modules should be switched. Currently re.py just imports the contents of sre.py -- once it supported both sre and the PCRE-based pre.py -- and sre.py contains the actual code. Now that pre.py is gone, we can move the actual code into re.py and make sre.py just import re.py, so that any user code that actually imports sre will still work. I'll make this change today. --amk ___ 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()
Raymond's original definition for partition() did NOT support any of the following: (*) Regular Expressions (*) Ways to generate just 1 or 2 of the 3 values if some are not going to be used (*) Clever use of indices to avoid copying strings (*) Behind-the-scenes tricks to allow repeated re-partitioning to be faster than O(n^2) The absence of these "features" is a GOOD thing. It makes the behavior of partition() so simple and straightforward that it is easily documented and can be instantly understood by a competent programmer. I *like* keeping it simple. In fact, if anything, I'd give UP the one fancy feature he chose to include: (*) An rpartition() function that searches from the right ...except that I understand why he included it and am convinced by the arguments (use cases can be demonstrated and people would expect it to be there and complain if it weren't). Simplicity and elegence are two of the reasons that this is such an excellent proposal, let's not lose them. We have existing tools (like split() and the re module) to handle the tricky problems. -- Michael Chermside ___ 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?)
Le mardi 30 août 2005 à 12:29 -0500, [EMAIL PROTECTED] a écrit :
> Just group your re:
>
> >>> import re
> >>>
> >>> re.split("ab", "abracadabra")
> ['', 'racad', 'ra']
> >>> re.split("(ab)", "abracadabra")
> ['', 'ab', 'racad', 'ab', 'ra']
>
> and you get it in the return value. In fact, re.split with a grouped re is
> very much like Raymond's str.partition method without the guarantee of
> returning a three-element list.
Thanks! I guess I should have read the documentation carefully instead
of assuming re.split() worked like in some other language (namely, PHP).
Regards
Antoine.
___
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?
I wrote:
[Andrew Durdin:]
> > IOW, I expected "www.python.org".partition("python") to return exactly
> > the same as "www.python.org".rpartition("python")
>
> Yow. Me too, and indeed I've been skimming this thread without
> it ever occurring to me that it would be otherwise.
And, on re-skimming the thread, I think that was always the plan.
So that's OK, then. :-)
--
g
___
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?
> 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)
>
> My first expectation for rpartition() was that it would return exactly
> the same values as partition(), but just work from the end of the
> string.
>
> IOW, I expected "www.python.org".partition("python") to return exactly
> the same as "www.python.org".rpartition("python")
Yow. Me too, and indeed I've been skimming this thread without
it ever occurring to me that it would be otherwise.
> Anyway, I'm definitely +1 on partition(), but -1 on rpartition()
> returning in "reverse order".
+1.
--
g
___
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()
Ron Adam wrote:
> I'm not familiar with piece, but it occurred to me it might be useful to
> get attributes groups in some way. My first (passing) thought was to do...
>
> host, port = host.partition(':').(head, sep)
>
> Where that would be short calling a method to return them:
>
> host, port = host.partition(':').getattribs('head','sep')
note, however, that your first syntax doesn't work in today's python
(bare names are always evaluated in the current scope, before any calls
are made)
given that you want both the pieces *and* a way to see if a split was
made, the only half-reasonable alternatives to "I can always ignore the
values I don't need" that I can think of are
flag, part1, part2, ... = somestring.partition(sep, count=2)
or
flag, part1, part2, ... = somestring.piec^H^H^Hartition(sep, group, group,
...)
where flag is true if the separator was found, and the number of parts
returned corresponds to either count or the number of group indices
(the latter is of course the external influence that cannot be named,
but with an API modelled after RE's group method).
___
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?)
Ron Adam wrote: > I don't feel there is a need to avoid numbers entirely. In this case I > think it's the better way to find the n'th seperator and since it's an > optional value I feel it doesn't add a lot of complication. Anyway... > It's just a suggestion. Avoid overengineering this without genuine use cases. Raymond's review of the standard library shows that the basic version of str.partition provides definite readability benefits and also makes it easier to write correct code - enhancements can wait until we have some real experience with how people use the method. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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?)
Josiah Carlson a écrit : > Pierre Barbier de Reuille <[EMAIL PROTECTED]> wrote: > > 0.5 > > So, subtracting that .5 seconds from all the cases gives us... > > 0.343 seconds for .find's comparison > 0.313 seconds for .index's exception handling when an exception is not > raised > 3.797 seconds for .index's exception handling when an exception is > raised. Well, when I did benchmark that (two years ago) the difference was, AFAIR, much greater ! But well, I just have to adjust my internal data sets ;) Pierre > > In the case of a string being found, .index is about 10% faster than > .find . In the case of a string not being found, .index's exception > handlnig mechanics are over 11 times slower than .find's comparison. > > [...] > > - Josiah > -- Pierre Barbier de Reuille INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP Botanique et Bio-informatique de l'Architecture des Plantes TA40/PSII, Boulevard de la Lironde 34398 MONTPELLIER CEDEX 5, France tel : (33) 4 67 61 65 77fax : (33) 4 67 61 56 68 ___ 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
