On 10/8/07, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
>
>
> - add missing methods to PyBytes (for list, see the PEP and compare to
> > what's already there)
>
>
Committed revision 58493. (closes issue1261).
fwiw - On py3k head on the x86 ubuntu feisty box i used to do the commit the
following t
Luke Stebbing wrote:
> I expect something spelled "lower" to try and transform an object
> in-place, period. Too bad changing it to "lowered" would be such a
> royal pain.
Yes, those methods should probably have been called
"lowered", "captitalized", etc. from the beginning, but
the time machine w
Jim Jewett wrote:
> I thought that was the reason to return self instead of None.
That would be even more misleading, because you would get
no warning that you had called a mutating method when you
thought you were calling a non-mutating one.
This is the reason that all the existing mutating meth
ByteSequence.
On 10/15/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 10/15/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 10/15/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > There's one thing that I forgot to add to PEP 3137. It's the removal
> > > of the basestring type. I thin
On 10/15/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 10/15/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > There's one thing that I forgot to add to PEP 3137. It's the removal
> > of the basestring type. I think this is a reasonable thing to do.
> > Christian Heimes has a patch that do
Jim Jewett wrote:
> On 10/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
>>On 10/12/07, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
>>
>>>Should the mutable PyBytes_ (buffer) objects implement
>>>the following methods inplace and return an additional reference to self?
If they're to work in
> Anyways I'll be done with my patch to add the copying versions of the
> methods later today. Stay tuned.
>
The PyBytes methods from PEP3137 have been implemented. Review as desired.
http://bugs.python.org/issue1261
If its good as is, let me know and I can check that in if you don't want to
while trying to figure out what to update the common method docstrings to
say I've come up with terms such as 'byte string' or 'byte buffer' but none
of those are extra appealing to me to turn into an ABC name. other
thoughts?
On 10/15/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On 10/15/
On 10/15/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> There's one thing that I forgot to add to PEP 3137. It's the removal
> of the basestring type. I think this is a reasonable thing to do.
> Christian Heimes has a patch that does this cleanly. Anyone objecting,
> please speak up now!
And, q
There's one thing that I forgot to add to PEP 3137. It's the removal
of the basestring type. I think this is a reasonable thing to do.
Christian Heimes has a patch that does this cleanly. Anyone objecting,
please speak up now!
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_
[EMAIL PROTECTED] wrote:
> Nick> I wouldn't mind seeing some iteration-in-C bit-bashing operations
> Nick> in there eventually...
>
> Nick>data = bytes([x & 0x1F for x in orig_data])
>
> This begins to make it look what you want is array.array or nump.array.
> Python's arrays don't
I am not going to explain this further if you still don't get it.
These functions should not modify their argument, and return a copy of
the same type as the original.
I'm fine with new APIs that perform similar things in-place.
--Guido
On 10/15/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 10
On 10/15/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> So would returning a different object. I expect a mutation operation
> on an explicitly mutable object to mutate the object, instead of
> creating something new.
>
> If it returns a new one, I can imagine doing something like:
>
> obj.inqueu
On 10/15/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 10/15/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > On 10/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > On 10/12/07, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> > > > > > - add missing methods to PyBytes (for list, see the P
On 10/15/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> If returning the original (but mutated) buffer is a problem, then
> there is already a problem, because someone else could already mutate
> the original.
>
> (Also note that for duck-typing, it should be OK if the new result
> object is always im
On 10/15/07, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> On 10/15/07, Terry Reedy <[EMAIL PROTECTED]> wrote:
> > ...I would think that being able to edit in place would be a reason
> > to use a buffer rather than (immutable) bytes.
> I agree, thats a benefit of a mutable object. But I think th
On 10/15/07, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
>
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> | > > > As I work on these.. Should the mutable PyBytes_ (buffer) objects
> implement
> | > > > the following methods inplace and return an additional refere
> > >> Also what about .replace() and .translate()?
> > >
> > >> If they are not done in place should they return a new buffer
> (PyBytes_)
> > >> object or a bytes (PyString_) object? [i'd say a buffer (PyBytes_)]
> > >
> > > They should return the same type as 'self'.
> >
> > My preference would
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| > > > As I work on these.. Should the mutable PyBytes_ (buffer) objects
implement
| > > > the following methods inplace and return an additional reference to
self?
| >
| > > > .capitalize(), .center(), .expandtabs
Doh, the answer is in the PEP. Please ignore the other mail :)
http://www.python.org/dev/peps/pep-3137/#constructors
Christian
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://m
Correct. Sorry. Here's an improved table that I'm also adding to the PEP:
C name | 2.xrepr | 3.0a1 repr | 3.0a2 repr
-+-++---
PyUnicode| unicode u"" | str "" | str ""
PyString | str "" | str8 s"" |
On 10/15/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> C name| 2.x | 3.0a1 | 3.0a2 |
> --+--++-+
> PyUnicode | unicode u"" | str "" | str "" |
> PyString | str "" | str8 s"" | bytes
On 10/15/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> I'm working on the renaming of str8 -> bytes and bytes -> buffer.
> PyBytes (old bytes, new buffer) can take a string together with an
> encoding and an optional error argument:
>
>
> >>> bytes(source="abc", encoding="ascii", errors="replac
I'm working on the renaming of str8 -> bytes and bytes -> buffer.
PyBytes (old bytes, new buffer) can take a string together with an
encoding and an optional error argument:
>>> bytes(source="abc", encoding="ascii", errors="replace")
b'abc'
>>> str(b"abc", encoding="ascii")
'abc'
IMO this should
On 10/15/07, Joel Bender <[EMAIL PROTECTED]> wrote:
> Speaking from the protocol encoding/decoding view, and one where a
> buffer is very similar to a list of small integers...
>
> >> Also what about .replace() and .translate()?
> >
> >> If they are not done in place should they return a new buffer
Speaking from the protocol encoding/decoding view, and one where a
buffer is very similar to a list of small integers...
>> Also what about .replace() and .translate()?
>
>> If they are not done in place should they return a new buffer (PyBytes_)
>> object or a bytes (PyString_) object? [i'd sa
On 10/15/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 10/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 10/12/07, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> > > > > - add missing methods to PyBytes (for list, see the PEP and compare to
> > > > > what's already there)
>
> > > As I wo
On 10/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 10/12/07, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> > > > - add missing methods to PyBytes (for list, see the PEP and compare to
> > > > what's already there)
> > As I work on these.. Should the mutable PyBytes_ (buffer) objects im
28 matches
Mail list logo
