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
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).
/F
___
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] 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] 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] 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
[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()
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
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] 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()
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. /F ___ 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()
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()
[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()
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
[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
[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] 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
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] 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] 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
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
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] 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
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] 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
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] 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] 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()
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] 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
[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] 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] 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] 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 nounish thing doing the work of a verbish 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] 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] 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] 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] 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
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] 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] 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] 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()
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] 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] 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
