Re: [Python-Dev] PEP 30XZ: Simplified Parsing
Mark Hammond wrote: > Please add my -1 to the chorus here, for the same reasons already expressed. Another -1 here - while I agree there are benefits to removing backslash continuations and string literal concatenation, I don't think they're significant enough to justify the hassle of making it happen. Regards, 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] best practices stdlib: purging xrange
Hi Anthony, 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. The first step is to focus the question on the places where replacing xrange() with range() can really make no difference at all, as far as we can see. This is not the case of "nearly all" the uses of xrange() from the stdlib - but it's still the case of a number of them: ''.join(chr(x) for x in xrange(256)) # at global module level or: for i in xrange(self.firstweekday, self.firstweekday + 7): I personally think that replacing these with range() is a clean-up, but I also know that not everybody agrees to that. So: should we, or should we not, replace xrange() with range() as a matter of clean-up when the difference between the two is really completely irrelevant? A bientot, Armin. ___ 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/8/07, Armin Rigo <[EMAIL PROTECTED]> wrote: > 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. > > The first step is to focus the question on the places where replacing > xrange() with range() can really make no difference at all, as far as we > can see. This is not the case of "nearly all" the uses of xrange() from > the stdlib - but it's still the case of a number of them: > > ''.join(chr(x) for x in xrange(256)) # at global module level > > or: > > for i in xrange(self.firstweekday, self.firstweekday + 7): > > I personally think that replacing these with range() is a clean-up, but > I also know that not everybody agrees to that. So: should we, or should > we not, replace xrange() with range() as a matter of clean-up when the > difference between the two is really completely irrelevant? I'm all for that -- personally, I wouldn't have written xrange() in the first place in such cases! -- --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] best practices stdlib: purging xrange
On May 8, 2007, at 8:49 AM, Armin Rigo wrote: > 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. > > I personally think that replacing these with range() is a clean-up, > but > I also know that not everybody agrees to that. So: should we, or > should > we not, replace xrange() with range() as a matter of clean-up when the > difference between the two is really completely irrelevant? But doesn't doing this now this make the conversion to Py3 *harder*? If 2to3 is going to rewrite xrange() as range(), and range() to list (range()), then moving towards xrange where possible would actually be preferable, wouldn't it? Or is there no plan to run 2to3 on the stdlib? James ___ 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] svn logs
Hello there. Does anyone know why getting the SVN logs for a project is so excruciatingly slow? Is this an inherent SVN problem or are the python.org servers simply overloaded? It takes something like 10 minutes for me to get the log messages window up for the root of a branch. Cheers, Kristján ___ 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 ))
Guido van Rossum wrote:
> [+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).
>
I'm having a hard time understanding why bytes literals would be a good
thing. OK, displays require the work of creating a new object (since
bytes types will be mutable) but surely a mutable literal is always
going to make programs potentially hard to read.
If you want a representation of a bytes object in your program text
doesn't that always (like other mutable types) have to represent the
same value, creating new objects as necessary if previously-created
objects could have been mutated.
What am I missing here?
regards
Steve
--
Steve Holden+1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
-- Asciimercial -
Get on the web: Blog, lens and tag your way to fame!!
holdenweb.blogspot.comsquidoo.com/pythonology
tagged items: del.icio.us/steve.holden/python
All these services currently offer free registration!
-- Thank You for Reading
___
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] svn logs
On Tue, May 08, 2007 at 03:33:22PM +, Kristj?n Valur J?nsson wrote: >Does anyone know why getting the SVN logs for a project is so >excruciatingly slow? > >Is this an inherent SVN problem or are the python.org servers simply >overloaded? I believe it's because there are multiple requests required to get the whole thing, but I don't know the details. You'll notice that svn annotate is also really slow. One thing you can do to help is to specify a range of revisions you'd like to see. This has been the case with just about every remote repository I've ever accessed. Dustin ___ 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] svn logs
Part of the problem might be that we are using an old version of svn (1.1) AFAIK. IIRC these operations were sped up in later versions. n -- On 5/8/07, Kristján Valur Jónsson <[EMAIL PROTECTED]> wrote: > > > > > Hello there. > > Does anyone know why getting the SVN logs for a project is so excruciatingly > slow? > > Is this an inherent SVN problem or are the python.org servers simply > overloaded? > > It takes something like 10 minutes for me to get the log messages window up > for the root > > of a branch. > > > > Cheers, > > Kristján > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/nnorwitz%40gmail.com > > ___ 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
> Just curious why 2to3 would not replace range() with list(range())? In most usages of range(), using the 3.0 range() will work just as well, and be more efficient. If I wanted to write code that works in both versions (which I understand is not the 2to3 objective), then I would use range(). If I worry about creating a list in 2.x, I would write try: xrange except NameError: xrange=range at the top of the file. Regards, Martin ___ 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] \code or \constant in tex markup
Which is correct?
$ egrep '(False|True)' Doc/lib/*.tex | grep -c \\constant{
74
$ egrep '(False|True)' Doc/lib/*.tex | grep -c \\code{
204
$ egrep 'None' Doc/lib/*.tex | grep -c \\code{
512
$ egrep 'None' Doc/lib/*.tex | grep -c \\constant{
83
n
___
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
