Re: [Python-Dev] Changing string constants to byte arrays in Py3k
>> So is having mutable bytes just a matter of calling them "byte >> displays" instead of "byte literals" or does that also require >> changing something in the back end? Martin> It's certainly also an issue of language semantics (i.e. changes Martin> to interpreter code). There are a number of options: Martin> 1. don't support creation of byte values through syntax. Instead, Martin>create bytes through a constructor function. I don't read the py3k mailing list. I presume the distinction between "display" and "literal" is old hat to those folks. I've never seen the term. Can someone explain it? Thx, Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Changing string constants to byte arrays in Py3k
[EMAIL PROTECTED] wrote: > >> So is having mutable bytes just a matter of calling them "byte > >> displays" instead of "byte literals" or does that also require > >> changing something in the back end? > > Martin> It's certainly also an issue of language semantics (i.e. changes > Martin> to interpreter code). There are a number of options: > Martin> 1. don't support creation of byte values through syntax. Instead, > Martin>create bytes through a constructor function. > > I don't read the py3k mailing list. I presume the distinction between > "display" and "literal" is old hat to those folks. I've never seen the > term. Can someone explain it? A literal refers to an immutable constant (i.e. 'assert 1 is 1' is allowed to be true) A display always creates a new mutable object (i.e. 'assert [] is []' is *required* to be false) The question is whether we have byte literals or displays in Py3k, and if we make them literals, whether it is still permissible for them to be mutable. Mutable objects pose all sorts of caching and aliasing problems that just don't come up with immutable objects like strings or numbers. For the work I do with low level hardware control, I suspect not having an immutable bytes variant to throw in a dictionary would be something of an inconvenience (that said, work only switched to Python 2.4 relatively recently, so I doubt Py3k will pose me any significant practical concerns on that front for quite some time :). I would personally like an interoperable bytes/frozenbytes pair (along the lines of set/frozenset) with a literal syntax to produce instances of the latter. However, I don't have a great deal of development time to devote to helping to make that happen. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Byte literals (was Re: [Python-checkins] Changing string constants to byte arrays ( r55119 - in python/branches/py3k-struni/Lib: codecs.py test/test_codecs.py ))
[+python-3000; replies please remove python-dev]
On 5/5/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> "Fred L. Drake, Jr." <[EMAIL PROTECTED]> wrote:
> >
> > On Saturday 05 May 2007, Aahz wrote:
> > > I'm with MAL and Fred on making literals immutable -- that's safe and
> > > lots of newbies will need to use byte literals early in their Python
> > > experience if they pick up Python to operate on network data.
> >
> > Yes; there are lots of places where bytes literals will be used the way str
> > literals are today. buffer(b'...') might be good enough, but it seems more
> > than a little idiomatic, and doesn't seem particularly readable.
> >
> > I'm not suggesting that /all/ literals result in constants, but bytes
> > literals
> > seem like a case where what's wanted is the value. If b'...' results in a
> > new object on every reference, that's a lot of overhead for a network
> > protocol implementation, where the data is just going to be written to a
> > socket or concatenated with other data. An immutable bytes type would be
> > very useful as a dictionary key as well, and more space-efficient than
> > tuple(b'...').
>
> I was saying the exact same thing last summer. See my discussion with
> Martin about parsing/unmarshaling. What I expect will happen with bytes
> as dictionary keys is that people will end up subclassing dictionaries
> (with varying amounts of success and correctness) to do something like
> the following...
>
> class bytesKeys(dict):
> ...
> def __setitem__(self, key, value):
> if isinstance(key, bytes):
> key = key.decode('latin-1')
> else:
> raise KeyError("only bytes can be used as keys")
> dict.__setitem__(self, key, value)
> ...
>
> Is it optimal? No. Would it be nice to have immtable bytes? Yes. Do
> I think it will really be a problem in parsing/unmarshaling? I don't
> know, but the fact that there now exists a reasonable literal syntax b'...'
> rather than the previous bytes([1, 2, 3, ...]) means that we are coming
> much closer to having what really is about the best way to handle this;
> Python 2.x str.
I don't know how this will work out yet. I'm not convinced that having
both mutable and immutable bytes is the right thing to do; but I'm
also not convinced of the opposite. I am slowly working on the
string/unicode unification, and so far, unfortunately, it is quite
daunting to get rid of 8-bit strings even at the Python level let
alone at the C level.
I suggest that the following exercise, to be carried out in the
py3k-struni branch, might be helpful: (1) change the socket module to
return bytes instead of strings (it already takes bytes, by virtue of
the buffer protocol); (2) change its makefile() method so that it uses
the new io.py library, in particular the SocketIO wrapper there; (3)
fix up the httplib module and perhaps other similar ones. Take copious
notes while doing this. Anyone up for this? I will listen! (I'd do it
myself but I don't know where I'd find the time).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 30XZ: Simplified Parsing
Mike Klaas <[EMAIL PROTECTED]> wrote: > On 5/4/07, Baptiste Carvello <[EMAIL PROTECTED]> wrote: > > > maybe we could have a "dedent" literal that would remove the first newline > > and > > all indentation so that you can just write: > > > > call_something( d''' > > first part > > second line > > third line > > ''' ) > > Surely > > from textwrap import dedent as d > > is close enough? Apart from it happening at run time rather than compile time. -- Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] best practices stdlib: purging xrange
I'd like to suggest that we remove all (or nearly all) uses of xrange from the stdlib. A quick scan shows that most of the usage of it is unnecessary. With it going away in 3.0, and it being informally deprecated anyway, it seems like a good thing to go away where possible. Any objections? Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] best practices stdlib: purging xrange
But why bother? The 2to3 converter can do this for you. In a sense using range() is more likely to produce broken results in 3.0: if your code depends on the fact that range() returns a list, it is broken in 3.0, and 2to3 cannot help you here. But if you use list(xrange()) today, the converter will turn this into list(range()) in 3.0 and that will continue to work correctly. --Guido On 5/7/07, Anthony Baxter <[EMAIL PROTECTED]> wrote: > I'd like to suggest that we remove all (or nearly all) uses of > xrange from the stdlib. A quick scan shows that most of the usage > of it is unnecessary. With it going away in 3.0, and it being > informally deprecated anyway, it seems like a good thing to go away > where possible. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 30XZ: Simplified Parsing
>> Surely >> >> from textwrap import dedent as d >> >> is close enough? Nick> Apart from it happening at run time rather than compile time. And as someone else pointed out, what if you don't want each chunk of text terminated by a newline? Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] best practices stdlib: purging xrange
On Tue, May 08, 2007 at 09:14:02AM +1000, Anthony Baxter wrote: > I'd like to suggest that we remove all (or nearly all) uses of > xrange from the stdlib. A quick scan shows that most of the usage > of it is unnecessary. With it going away in 3.0, and it being > informally deprecated anyway, it seems like a good thing to go away > where possible. > > Any objections? Punt it when it's no longer useful (py3k); xrange exists for a reason- most usage just needs to iterate over a range of numbers (xrange), not instantiate a list of the range, then iterate over said range (range). Don't much see the point in making stdlib more wasteful in runtime for an "informally deprecated" func that lots of folks in the real world still use. ~brian pgpgTz8LwpEji.pgp Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] best practices stdlib: purging xrange
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | But why bother? The 2to3 converter can do this for you. | | In a sense using range() is more likely to produce broken results in | 3.0: if your code depends on the fact that range() returns a list, it | is broken in 3.0, and 2to3 cannot help you here. But if you use | list(xrange()) today, the converter will turn this into list(range()) | in 3.0 and that will continue to work correctly. Just curious why 2to3 would not replace range() with list(range())? tjr ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] best practices stdlib: purging xrange
> I'd like to suggest that we remove all (or nearly all) uses of > xrange from the stdlib. A quick scan shows that most of the usage > of it is unnecessary. With it going away in 3.0, and it being > informally deprecated anyway, it seems like a good thing to go away > where possible. > >Any objections? -1 It isn't "informally deprecated". The xrange() builtin has different performance characteristics and is still needed in Py2.x. Only in Py3k where range() becomes lazy like will the need disappear. Seriously, we should make every effort to make sure that Py3k doesn't unnecessarily backpropagate into an otherwise very stable codebase. An unwarranted s/xrange/range/g would be just one more reason to not upgrade to Py2.6. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] best practices stdlib: purging xrange
On 5/7/07, Terry Reedy <[EMAIL PROTECTED]> wrote: > > "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > | But why bother? The 2to3 converter can do this for you. > | > | In a sense using range() is more likely to produce broken results in > | 3.0: if your code depends on the fact that range() returns a list, it > | is broken in 3.0, and 2to3 cannot help you here. But if you use > | list(xrange()) today, the converter will turn this into list(range()) > | in 3.0 and that will continue to work correctly. > > Just curious why 2to3 would not replace range() with list(range())? That's a good idea. But I'd like someone else to implement it... -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
