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 deve
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
[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 t
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 som
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
> > convenien
> "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 woul
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
> > l
> "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
all
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
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
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 explic
[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 representa
[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
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
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
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 ol
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.
>> 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 v
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
"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
> "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
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
> Ti
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 necessar
[EMAIL PROTECTED] wrote:
> How would this work? One of the advantages of the current string is
> that the underlying data is NUL-terminated, so when passing strings
> to C routines no copying is required.
I didn't say it would be easy. Just that it's about the first cases
where I've seen there c
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 maili
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 underl
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
>> 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
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
> 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 process
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 exce
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 *mo
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
_
Fredrik Lundh wrote:
> the problem isn't the time it takes to unpack the return value, the
> problem is that it takes time to create the substrings that you don't
> need.
I'm actually starting to think that this may be a good use case for
views of strings i.e. rather than create 3 new strings, e
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 ge
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 functio
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]
>
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
"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
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).
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, .
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,
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
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 bigge
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
> >(*) 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
> > 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
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
[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
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 keywor
<[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-
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
> paralleli
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).
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
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
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
>> 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
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 g
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
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 retur
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
> 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
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:
>
> hos
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 ge
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 fo
65 matches
Mail list logo
