new string method in 2.5 (partition)

[Terry Reedy]

Re: new string method in 2.5 (partition)


"Bruno Desthuilliers" <bdesth.quelque chose@free.quel quepart.frwrote in
message news:4510425e$0 $12250$636a55ce @news.free.fr.. .

>Err... is it me being dumb, or is it a perfect use case for str.split ?

s.partition() was invented and its design settled on as a result of looking
at some awkward constructions in the standard library and other actual use
cases. Sometimes it replaces s.find or s.index instead of s.split. In
some cases, it is meant to be used within a loop. I was not involved and
so would refer you to the pydev discussions.

tjr

[MonkeeSage]

Re: new string method in 2.5 (partition)

s = "There should be one -- and preferably only one -- obvious way to
do it".partition(' only one')
print s[0]+'more than one'+s[2]

;)

Regards,
Jordan

[Irmen de Jong]

Re: new string method in 2.5 (partition)

Terry Reedy wrote:

"Bruno Desthuilliers" <bdesth.quelque chose@free.quel quepart.frwrote in
message news:4510425e$0 $12250$636a55ce @news.free.fr.. .

>Err... is it me being dumb, or is it a perfect use case for str.split ?

>
s.partition() was invented and its design settled on as a result of looking
at some awkward constructions in the standard library and other actual use
cases. Sometimes it replaces s.find or s.index instead of s.split. In
some cases, it is meant to be used within a loop. I was not involved and
so would refer you to the pydev discussions.

While there is the functional aspect of the new partition method, I was
wondering about the following /technical/ aspect:

Because the result of partition is a non mutable tuple type containing
three substrings of the original string, is it perhaps also the case
that partition works without allocating extra memory for 3 new string
objects and copying the substrings into them?
I can imagine that the tuple type returned by partition is actually
a special object that contains a few internal pointers into the
original string to point at the locations of each substring.
Although a quick type check of the result object revealed that
it was just a regular tuple type, so I don't think the above is true...

--Irmen

[Steve Holden]

Re: new string method in 2.5 (partition)

Irmen de Jong wrote:

Terry Reedy wrote:
>

>>"Bruno Desthuilliers" <bdesth.quelque chose@free.quel quepart.frwrote in
>>message news:4510425e$0 $12250$636a55ce @news.free.fr.. .
>>

>>>Err... is it me being dumb, or is it a perfect use case for str.split ?

>>
>>s.partition () was invented and its design settled on as a result of looking
>>at some awkward constructions in the standard library and other actual use
>>cases. Sometimes it replaces s.find or s.index instead of s.split. In
>>some cases, it is meant to be used within a loop. I was not involved and
>>so would refer you to the pydev discussions.

>
>
While there is the functional aspect of the new partition method, I was
wondering about the following /technical/ aspect:
>
Because the result of partition is a non mutable tuple type containing
three substrings of the original string, is it perhaps also the case
that partition works without allocating extra memory for 3 new string
objects and copying the substrings into them?
I can imagine that the tuple type returned by partition is actually
a special object that contains a few internal pointers into the
original string to point at the locations of each substring.
Although a quick type check of the result object revealed that
it was just a regular tuple type, so I don't think the above is true...
>

It's not.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

[Bruno Desthuilliers]

Re: new string method in 2.5 (partition)

John Salerno a écrit :

Bruno Desthuilliers wrote:
>

>Err... is it me being dumb, or is it a perfect use case for str.split ?

>
>
Hmm, I suppose you could get nearly the same functionality as using
split(':', 1), but with partition you also get the separator returned as
well.

Well, you already know it since you use it to either split() or
partition the string !-)

Not to say these two new methods are necessary useless - sometimes a
small improvement to an API greatly simplifies a lot of common use cases.

>There are IMVHO much exciting new features in 2.5 (enhanced
>generators, try/except/finally, ternary operator, with: statement etc...)

>
>
I definitely agree, but I figure everyone knows about those already.
There are also the startswith() and endswith() string methods that are
new

Err... 'new' ???

and seem neat as well.

[Gabriel Genellina]

Re: new string method in 2.5 (partition)

At Wednesday 20/9/2006 15:11, Irmen de Jong wrote:

>Because the result of partition is a non mutable tuple type containing
>three substrings of the original string, is it perhaps also the case
>that partition works without allocating extra memory for 3 new string
>objects and copying the substrings into them?
>I can imagine that the tuple type returned by partition is actually
>a special object that contains a few internal pointers into the
>original string to point at the locations of each substring.
>Although a quick type check of the result object revealed that
>it was just a regular tuple type, so I don't think the above is true...

Nope, a python string has both a length *and* a null terminator (for
ease of interfacing C routines, I guess) so you can't just share a substring.



Gabriel Genellina
Softlab SRL





_______________ _______________ _______________ _____
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!

http://www.yahoo.com.ar/respuestas

[Irmen de Jong]

Re: new string method in 2.5 (partition)

Gabriel Genellina wrote:

Nope, a python string has both a length *and* a null terminator (for
ease of interfacing C routines, I guess) so you can't just share a
substring.

Ofcourse, that makes perfect sense. Should have thought a little
bit further myself .... :)

--Irmen

[Fredrik Lundh]

Re: new string method in 2.5 (partition)

Irmen de Jong wrote:

Because the result of partition is a non mutable tuple type containing
three substrings of the original string, is it perhaps also the case
that partition works without allocating extra memory for 3 new string
objects and copying the substrings into them?

nope. the core string type doesn't support sharing, and given the
typical use cases for partition, I doubt it would be more efficient
than actually creating the new strings.

(note that partition reuses the original string and the separator,
where possible)

(and yes, you're not the first one who thought of this. check the
python-dev archives from May this year for more background).

</F>

[Lawrence D'Oliveiro]

Re: new string method in 2.5 (partition)

In message <mailman.354.11 58791333.10491. python-list@python.org >, Gabriel
Genellina wrote:

... a python string has both a length *and* a null terminator (for
ease of interfacing C routines ...

How does that work for strings with embedded nulls? Or are the C routines
simply fooled into seeing a truncated part of the string?

[Duncan Booth]

Re: new string method in 2.5 (partition)

Lawrence D'Oliveiro <ldo@geek-central.gen.new _zealandwrote:

In message <mailman.354.11 58791333.10491. python-list@python.org >, Gabriel
Genellina wrote:
>

>... a python string has both a length *and* a null terminator (for
>ease of interfacing C routines ...

>
How does that work for strings with embedded nulls? Or are the C routines
simply fooled into seeing a truncated part of the string?
>

If passed to a C library function it would mean that the C code would
generally only use up to the first embedded null. However the Python
standard library will usually check for nulls first so it can throw an
error:

>>with open('test.txt' , 'r') as f:

.... print f.read()
....
Hello world

>>with open('test.txt\ x00junk', 'r') as f:

.... print f.read()
....
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: file() argument 1 must be (encoded string without NULL
bytes), not str

>>>

What actually happens is that Python argument parsing code will reject
values with embedded nulls if asked to convert a parameter to a C string
('s', 'z', 'es', or 'et' formats), but will allow them if converting to a C
string and a length ('s#', 'z#', 'es#', or 'et#').

[Gabriel Genellina]

Re: new string method in 2.5 (partition)

At Friday 22/9/2006 04:53, Lawrence D'Oliveiro wrote:

... a python string has both a length *and* a null terminator (for
ease of interfacing C routines ...

>
>How does that work for strings with embedded nulls? Or are the C routines
>simply fooled into seeing a truncated part of the string?

This is for simple char* strings, ASCIIZ. If your C code can accept
embedded nulls, surely has made other provisions - like receiving the
buffer length as a parameter. If not, it will see only a truncated string.



Gabriel Genellina
Softlab SRL





_______________ _______________ _______________ _____
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!

http://www.yahoo.com.ar/respuestas