Greg> If a Python function is clearly wrapping a C function, one doesn't
Greg> expect to be able to pass strings with embedded NULs to it.
Skip> Isn't that just floating an implementation detail up to the
Skip> programmer (who may well not be POSIX- or Unix-aware)?
Fredrik> s
[EMAIL PROTECTED] wrote:
> Greg> If a Python function is clearly wrapping a C function, one doesn't
> Greg> expect to be able to pass strings with embedded NULs to it.
>
> Isn't that just floating an implementation detail up to the programmer (who
> may
> well not be POSIX- or Unix-aware)
[EMAIL PROTECTED] wrote:
>Greg> If a Python function is clearly wrapping a C function, one doesn't
>Greg> expect to be able to pass strings with embedded NULs to it.
>
> Isn't that just floating an implementation detail up to the programmer (who
> may
> well not be POSIX- or Unix-aware)?
[EMAIL PROTECTED] wrote:
> Greg> If a Python function is clearly wrapping a C function, one doesn't
> Greg> expect to be able to pass strings with embedded NULs to it.
>
> Isn't that just floating an implementation detail up to the programmer (who
> may
> well not be POSIX- or Unix-aware)
Greg> If a Python function is clearly wrapping a C function, one doesn't
Greg> expect to be able to pass strings with embedded NULs to it.
Isn't that just floating an implementation detail up to the programmer (who may
well not be POSIX- or Unix-aware)?
___
Steve Holden wrote:
> Since Python strings *can* contain embedded NULs, doesn't that rather
> poo on the idea of passing pointers to their data to C functions as
> things stand?
If a Python function is clearly wrapping a C function,
one doesn't expect to be able to pass strings with
embedded NU
[EMAIL PROTECTED] wrote:
>Fredrik> Python strings are character buffers with a known length, not
>Fredrik> null-terminated C strings. the CPython implementation
>Fredrik> guarantees that the character buffer has a trailing NULL
>Fredrik> character, but that's mostly to make it eas
> "Steve" == Steve Holden <[EMAIL PROTECTED]> writes:
Steve> Since Python strings *can* contain embedded NULs, doesn't
Steve> that rather poo on the idea of passing pointers to their
Steve> data to C functions as things stand?
I think it's a "consenting adults" issue.
Ie, C progr
Greg Ewing wrote:
> [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.
>
>
>
[EMAIL PROTECTED] wrote:
> >> 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 i
>> 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 DECRE
Fredrik> Python strings are character buffers with a known length, not
Fredrik> null-terminated C strings. the CPython implementation
Fredrik> guarantees that the character buffer has a trailing NULL
Fredrik> character, but that's mostly to make it easy to pass Python
Fredrik>
Tim Delaney writes:
> 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.
Michael Chermside wri
On 8/31/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> [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
Tim Delaney writes:
> 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.
Why do you say that?
[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
[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
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.
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
24 matches
Mail list logo
