Re: [Python-Dev] Re: webbrowser.py
Hello! On Mon, Mar 28, 2005 at 06:31:29PM -0300, Rodrigo Dias Arruda Senra wrote: > Outstanding work Oleg. I read it through and wouldn't change a bit. > I have revised: libwebbrowser.tex.patch and webbrowser.py.patch. > They are Ok regarding grammar, TeX and ... whatever . > I recommend to apply both files. Thank you very much! > However, I would withdraw the third file -- webbrowser wrapper script, since > the same > functionality can be accomplished with: > > python -m webbrowser http://www.python.org Oh, that's an idea! I haven't thought about it because I didn't switched to python 2.4 yet - commercial programs that I'm developing are based on 2.3. I copied the "webbrowser script" idea from pydoc/pydoc.py. Fred, now it's your turn. Please review http://python.org/sf/754022 and decide what to do with all that. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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] BRANCH FREEZE for 2.4.1 final, 2005-03-30 00:00 UTC
The release24-maint branch is FROZEN from 00:00 UTC, 2005-03-30 (in about 11 hours from now). As usual, unless you're in the set (Anthony, MvL, Fred), please hold off on checkins to the branch until I send a message unfreezing it. Once we've had the appropriate brown-paper-bag time delay, the branch will be unfrozen for 2.4.2 in about 6 months time. -- 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] Re: [Python-checkins] python/dist/src/Python thread_pthread.h, 2.53, 2.53.4.1
Martin v. Löwis wrote: Andrew MacIntyre wrote: This change has broken the build on FreeBSD 4.x for me: gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes - I. -I./Include -DPy_BUILD_CORE -o Python/thread.o Python/thread.c In file included from Python/thread.c:101: Python/thread_pthread.h:19: syntax error *** Error code 1 This should be fixed now, please try again and report whether it works. It does. It would be really nice if you could try to analyse such problems deeper in the future. I would have if I'd had the time; sorry that I didn't state that. All I really intended was to alert Anthony to a problem on a widely used but non-primary target platform, so that he could make a decision about whether to worry about it or not for the 2.4.1 release. I had intended (but again didn't state) to follow this up at the earliest opportunity (which probably would have been this evening). In this case, it would have helped if you had reported that _POSIX_SEMAPHORES is defined as #define _POSIX_SEMAPHORES so that the #if line expands to #if == -1 The standard solution in this case is to write #if (_POSIX_SEMAPHORES+0) == -1 First time I can recall seeing that sort of situation - which I guess shows my lack of serious cross-platform C programming experience. Thanks for the fix and taking the time to explain. Regards, Andrew. - Andrew I MacIntyre "These thoughts are mine alone..." E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370 [EMAIL PROTECTED] (alt) |Belconnen ACT 2616 Web:http://www.andymac.org/ |Australia ___ 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] Re: webbrowser.py
Rodrigo Dias Arruda Senra wrote: > | > On Thu, Mar 24, 2005 at 11:36:41AM -0300, Rodrigo Dias Arruda Senra > wrote: > | > > Edit libwebbrowser.tex as you see fit, then send it to me > | > > and I'll TeXify it back to you. > | > > | >Uploaded to http://python.org/sf/754022 . I am not a native English > | > speaker, and this is the first time I've edited a TeX file. Please > | > correct my grammar, spelling, TeX, whatever... > > Outstanding work Oleg. I read it through and wouldn't change a bit. > I have revised: libwebbrowser.tex.patch and webbrowser.py.patch. > They are Ok regarding grammar, TeX and ... whatever . > I recommend to apply both files. FWIW, same judgement from me. Reinhold -- Mail address is perfectly valid! ___ 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] Re: webbrowser.py
On Tue, Mar 29, 2005 at 06:46:09PM +0200, Reinhold Birkenfeld wrote: > Rodrigo Dias Arruda Senra wrote: > > Outstanding work Oleg. I read it through and wouldn't change a bit. > > I have revised: libwebbrowser.tex.patch and webbrowser.py.patch. > > They are Ok regarding grammar, TeX and ... whatever . > > I recommend to apply both files. > > FWIW, same judgement from me. Thank you! Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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] Re: comprehension abbreviation (was: Adding any() and all())
Steve Holden <[EMAIL PROTECTED]> wrote: [...] > Having to write > > [x for x in seq] > > to produce a copy of a list doesn't seem that outrageous to me, and I > don't find the predicate-less case of your proposal that convincing: > > [x in seq] > > seems somehow too terse. And is already valid Python syntax; producing a list of a boolean (if x is bound), a TypeError (if seq is a dictionary, x is bound, and x isn't hashable), or a NameError (if x is not bound). If I recall, changing the meaning of valid Python syntax is to be frowned upon, and the suggestion should be tossed out the window strictly because of that reason. As for "for x" or its equivalent, being too much additional overhead to type in list comprehensions, I think maybe we are getting too picky for our own good. - Josiah ___ 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] Re: comprehension abbreviation (was: Adding any() and all())
I thought I had been clear already, but since this thread keeps going maybe I need to reiterate that there's zero chance that this syntax proposal (or anything like it) will be accepted. You all are of course free to continue to discuss it, but as I've explained before it just isn't worth 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
[Python-Dev] using SCons to build Python
Has anyone ever considered using SCons to build Python? SCons is a great build tool written in Python that provides some Autoconf-like functionality (http://www.scons.org). It seems like this type of self-hosting would be a great testament to the power of Python as well as helping to reinforce the strength of SCons as a next generation build tool. Thanks, Adam ___ 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] Re: webbrowser.py
Hi! On Thu, Mar 24, 2005 at 11:36:41AM -0300, Rodrigo Dias Arruda Senra wrote: > Edit libwebbrowser.tex as you see fit, then send it to me > and I'll TeXify it back to you. Uploaded to http://python.org/sf/754022 . I am not a native English speaker, and this is the first time I've edited a TeX file. Please correct my grammar, spelling, TeX, whatever... Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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] 64-bit sequence and buffer protocol
I'm posting to this list to again generate open discussion on the problem in current Python that an int is used in both the Python sequence protocol and the Python buffer protocol. The problem is that a C-int is typically only 4 bytes long while there are many applications (mmap for example), that would like to access sequences much larger than can be addressed with 32 bits. There are two aspects to this problem: 1) Some 64-bit systems still define an C-int as 4 bytes long (so even in-memory sequence objects could not be addressed using the sequence protocol). 2) Even 32-bit systems have occasion to sequence a more abstract object (perhaps it is not all in memory) which requires more than 32 bits to address. These are the solutions I've seen: 1) Convert all C-ints to Py_LONG_LONG in the sequence and buffer protocols. 2) Add new C-API's that mirror the current ones which use Py_LONG_LONG instead of the current int. 3) Change Python to use the mapping protocol first (even for slicing) when both the mapping and sequence protocols are defined. 4) Tell writers of such large objects to not use the sequence and/or buffer protocols and instead use the mapping protocol and a different "bytes" object (that currently they would have to implement themselves and ignore the buffer protocol C-API). What is the opinion of people on this list about how to fix the problem. I believe Martin was looking at the problem and had told Perry Greenfield he was "fixing it." Apparently at the recent PyCon, Perry and he talked and Martin said the problem is harder than he had initially thought. It would be good to document what some of this problems are so that the community can assist in fixing this problem. -Travis O. ___ 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] New PyPI broken package editing
Martin v. Löwis sagte: > Walter Dörwald wrote: >> I'm not sure if this is the right approach. > > I think the approach is right, but the implementation is wrong. > >> The encoding I specify in >> setup.py should be independent of the encoding used between distutils and >> PyPI to communicate on the wire. I.e. the author >> (and maintainer) argument should always be unicode. > > "should" is a correct description. It should allow Unicode strings, which it > then should encode to UTF-8 during transmission. > The matter of fact is that the register command as released in 2.4 (and > 2.4.1) doesn't. OK, that's the problem. >> When str is passed, this is treated >> as any other str in a unicode context, it is decoded using the default >> encoding. This would fix another problem: It would >> make it nearly impossible to send a request to PyPI with the wrong >> encoding, because any encoding problems are sorted out >> completely on the client side. > > distutils should *not* assume that byte strings are in the default encoding. > It is fair to assume they are in ASCII; They should be the same. If not, the installation is broken (or at least scripts that rely on this break anywhere else). > if the > administrator has changed the default encoding, then this cannot possibly > affect all the setup.py files out there. Also, it > is a fact that the > deployed versions of the register command just send byte strings > in setup.py as-is, without trying to do any kind of recoding. >> In any case, PyPI now requires that the form submission uses UTF-8, and >> refuses anything else. So it *is* impossible to send, > say, > Latin-1; whether the client makes that happen by properly encoding Unicode > strings or whether they are in setup.py in the > first place does not matter. So can I have one setup.py for both Python 2.4 and Python 2.5 that does the correct thing when creating a Windows installer for Python 2.4 (I've used Unicode strings for that until now) and using the upload command with Python CVS (which seems to require a byte string now)? I'd like to avoid having to use version checks in setup.py. > [...] Bye, Walter Dörwald ___ 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] Pickling instances of nested classes
Currently instances of nested classes can't be pickled. For old style classes
unpickling fails to find the class:
>>> import cPickle
>>> class Foo:
...class Bar:
... pass
...
>>> cPickle.loads(cPickle.dumps(Foo.Bar()))
Traceback (most recent call last):
File "", line 1, in ?
AttributeError: 'module' object has no attribute 'Bar'
For new style classes, pickling itself fails:
>>> class Foo(object):
...class Bar(object):
... pass
...
>>> cPickle.loads(cPickle.dumps(Foo.Bar()))
Traceback (most recent call last):
File "", line 1, in ?
cPickle.PicklingError: Can't pickle : attribute lookup
__main__.Bar failed
I think this should be fixed (see below for use cases). There's an old bug
report open for this (http://www.python.org/sf/633930).
Classes would need access to their fully qualified name (starting from the
module level) (perhaps in a new class attribute __fullname__?) and the pickle
machinery would have to use this name when storing class names instead of
__name__.
The second part should be easy to implement. The first part is harder. It can't
be done by changing meta classes, because classes are created "inside out", i.e.
in:
class Foo:
class Bar:
class Baz:
pass
when Baz class is created, the Bar class hasn't been assigned a name yet.
Another problem is that it should only be done for classes *defined* inside
other classes, i.e. in
class Foo:
pass
class Bar:
Baz = Foo
Foo should remain unchanged.
For this I guess the parser would have to be changed to somehow keep a stack of
currently "open" class definitions, so the __fullname__ attribute (or dict
entry) can be set once a new class statement is encountered.
Of course the remaining interesting question is if this change is worth it and
if there are use cases for it. Possible use cases require that:
1) There's a collection of name objects in the scope of a class.
2) These objects are subclasses of other (nested or global) classes.
3) There are instances of those classes.
There are two use cases that immediately come to mind: XML and ORMs.
For XML: 1) Those classes are the element types and the nested classes
are the attributes. 2) Being able to define those attributes as separate
classes makes it possible to implement custom functionality (e.g. for
validation or for handling certain attribute types like URLs, colors etc.)
and 3) Those classes get instantiated when an XML tree is created or parsed.
A framework that does this (and my main motivation for writing this :)) is
XIST (see http://www.livinglogic.de/Python/xist/).
For the ORM case: Each top level class defines a table and the nested
classes are the fields, i.e. something like this:
class person(Table):
class firstname(Varchar):
"The person's first name"
null = False
class lastname(Varchar):
"The person's last name"
null = False
class password(Varchar):
"Login password"
def validate(self, value):
if not any(c.islower() for c in value) and \
not any(c.isupper() for c in value) and \
not any(c.isdigit() for c in value):
raise InvalidField("password requires a mix of
upper and lower"
"case letters and digits")
Instances of these classes are the records read from the database. A framework
that does something similar to this (although AFAIK fields are not nested
classes is SQLObject (http://sqlobject.org/)
So is this change wanted? useful? implementable with reasonable effort? Or
just not worth it?
Bye,
Walter Dörwald
___
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] using SCons to build Python
On Sun, Mar 27, 2005, Adam MacBeth wrote: > > Has anyone ever considered using SCons to build Python? SCons is a > great build tool written in Python that provides some Autoconf-like > functionality (http://www.scons.org). It seems like this type of > self-hosting would be a great testament to the power of Python as well > as helping to reinforce the strength of SCons as a next generation > build tool. Unfortunately, this leads to a bootstrapping problem. :-( It might be worthwhile investigating moving parts of CPython's build process to SCons, but core Python needs to stick with make. If you want to push this idea forward, you'll probably need to create a proof-of-concept. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death." --GvR ___ 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] using SCons to build Python
On Mar 29, 2005, at 5:15 PM, Aahz wrote: On Sun, Mar 27, 2005, Adam MacBeth wrote: Has anyone ever considered using SCons to build Python? SCons is a great build tool written in Python that provides some Autoconf-like functionality (http://www.scons.org). It seems like this type of self-hosting would be a great testament to the power of Python as well as helping to reinforce the strength of SCons as a next generation build tool. Unfortunately, this leads to a bootstrapping problem. :-( It might be worthwhile investigating moving parts of CPython's build process to SCons, but core Python needs to stick with make. If you want to push this idea forward, you'll probably need to create a proof-of-concept. I think it would also be important for SCons to gain more traction amongst the Python community before it filters into the core. All of the Python extensions I use, and the ones I write myself, are built using distutils. I'm not really fond of distutils, but last I looked at SCons it didn't seem like a big enough win for mostly-Python-projects.. The fact that it uses 1.5.2-isms, where distutils has (in theory) moved beyond that, makes it even less of a sell to me. -bob ___ 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] New PyPI broken package editing
Walter Dörwald wrote: So can I have one setup.py for both Python 2.4 and Python 2.5 that does the correct thing when creating a Windows installer for Python 2.4 (I've used Unicode strings for that until now) and using the upload command with Python CVS (which seems to require a byte string now)? I'd like to avoid having to use version checks in setup.py. Well, the upload command doesn't look at the metadata. It is the register command which does, and it indeed requires utf-8 at the moment. This can be fixed, of course, but not for already-released versions. 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
Re: [Python-Dev] using SCons to build Python
Adam MacBeth <[EMAIL PROTECTED]> writes: > Has anyone ever considered using SCons to build Python? Well, er, there's an obvious problem here somewhere... > SCons is a great build tool written in Python that provides some > Autoconf-like functionality (http://www.scons.org). It seems like > this type of self-hosting would be a great testament to the power of > Python as well as helping to reinforce the strength of SCons as a > next generation build tool. As an active Python developer, I'd like some less fluffy benefits than that. Cheers, mwh -- 34. The string is a stark data structure and everywhere it is passed there is much duplication of process. It is a perfect vehicle for hiding information. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html ___ 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] 64-bit sequence and buffer protocol
Travis Oliphant wrote: What is the opinion of people on this list about how to fix the problem. I believe Martin was looking at the problem and had told Perry Greenfield he was "fixing it." Apparently at the recent PyCon, Perry and he talked and Martin said the problem is harder than he had initially thought. It would be good to document what some of this problems are so that the community can assist in fixing this problem. I have put a patch on http://sourceforge.net/tracker/index.php?func=detail&aid=1166195&group_id=5470&atid=305470 which solves this problem (eventually); this is the pre-PyCon version; I'll update it to the post-PyCon version later this month. I'll also write a PEP with the proposed changes. > 1) Convert all C-ints to Py_LONG_LONG in the sequence and buffer protocols. This would be bad, since it would cause an overhead on 32-bit systems. Instead, I propose to change all C ints holding indexes and sizes to Py_ssize_t. > 2) Add new C-API's that mirror the current ones which use Py_LONG_LONG > instead of the current int. I'll propose a type flag, where each type can indicate whether it expects indexes and sizes as int or as Py_ssize_t. However, there are more issues. In particular, PyArg_ParseTuple needs to change to expect a different index type for selected "i" arguments; it also needs to change to possibly store a different type into the length of a "s#" argument. This altogether doesn't support types that exceed 2**31 elements even on an 32-bit system (or 2**63 elements on a 64-bit system); authors of such types would have to follow the advise > 4) Tell writers of such large objects to not use the sequence and/or >buffer protocols and instead use the mapping protocol and a different >" bytes" object (that currently they would have to implement themselves >and ignore the buffer protocol C-API). 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
Re: [Python-Dev] Pickling instances of nested classes
Walter Dörwald wrote: So is this change wanted? useful? implementable with reasonable effort? Or just not worth it? I think it is just not worth it. This means I won't attempt to implement it. I think I defined originally the __module__ attribute for classes to support better pickling (and defined it to be a string to avoid cycles); we considered the nested classes case at the time and concluded "oh well, don't do that then". 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
Re: [Python-Dev] Pickling instances of nested classes
Walter Dörwald wrote:
For XML: 1) Those classes are the element types and the nested classes
are the attributes. 2) Being able to define those attributes as separate
classes makes it possible to implement custom functionality (e.g. for
validation or for handling certain attribute types like URLs, colors etc.)
and 3) Those classes get instantiated when an XML tree is created or parsed.
A framework that does this (and my main motivation for writing this :)) is
XIST (see http://www.livinglogic.de/Python/xist/).
For the ORM case: Each top level class defines a table and the nested
classes are the fields, i.e. something like this:
class person(Table):
class firstname(Varchar):
"The person's first name"
null = False
class lastname(Varchar):
"The person's last name"
null = False
class password(Varchar):
"Login password"
def validate(self, value):
if not any(c.islower() for c in value) and \
not any(c.isupper() for c in value) and \
not any(c.isdigit() for c in value):
raise InvalidField("password requires a mix of upper
and lower"
"case letters and digits")
Instances of these classes are the records read from the database. A framework
that does something similar to this (although AFAIK fields are not nested
classes is SQLObject (http://sqlobject.org/)
So is this change wanted? useful? implementable with reasonable effort? Or
just not worth it?
notice that in this cases often metaclasses are involved or could easely
be, so if pickling would honor __reduce__ or __reduce_ex__ on
metaclasses (which right now it doesn't treating their instances as
normal classes) one could roll her own solution without the burden for
the language of implementing pickling of nested classes in general, so I
think that would make more sense, to add support to honor
__reduce__/__reduce_ex__ for metaclasses.
___
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] using SCons to build Python
On Sun, 2005-03-27 at 20:55, Adam MacBeth wrote: > Has anyone ever considered using SCons to build Python? SCons is a > great build tool written in Python that provides some Autoconf-like > functionality (http://www.scons.org). It seems like this type of > self-hosting would be a great testament to the power of Python as well > as helping to reinforce the strength of SCons as a next generation > build tool. SCons is cool and all -- I use it as a build tool for some of our products -- but it has a lot of quirks and takes a lot of getting used to. The autoconf-based build that we have now works well enough (for *nix) so IMO, switching to SCons is effort that would be better spent elsewhere. I don't see lots of upside to switching. -Barry signature.asc Description: This is a digitally signed message part ___ 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] Re: comprehension abbreviation (was: Adding any() andall())
"Steve Holden" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Having to write > > [x for x in seq] > > to produce a copy of a list doesn't seem that outrageous to me, Except for (currently) leaving the last value of sequence bound to 'x' after making the copy, how is the above different from list(seq)? 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
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 297 open (+11) / 2812 closed (+11) / 3109 total (+22) Bugs: 871 open ( +1) / 4900 closed (+33) / 5771 total (+34) RFE : 175 open ( +0) / 150 closed ( +0) / 325 total ( +0) New / Reopened Patches __ Decimal interaction with __rop__ (2005-03-19) http://python.org/sf/1166602 opened by Facundo Batista Fix _tryorder in webbrowser.py (2005-03-20) http://python.org/sf/1166780 opened by Rodrigo Dias Arruda Senra Fix handling of large octal literals (2005-03-20) CLOSED http://python.org/sf/1166879 opened by Nick Coghlan locale.getdefaultencoding: LANGUAGE not correctly parsed (2005-03-20) http://python.org/sf/1166938 opened by Matthias Klose locale.getdefaultencoding: precedence of LANGUAGE / LANG (2005-03-20) http://python.org/sf/1166948 opened by Matthias Klose locale: 'utf' is not a known encoding (2005-03-20) http://python.org/sf/1166957 opened by Matthias Klose asdl_c.py fix for long lines (2005-03-20) CLOSED http://python.org/sf/1167117 opened by John Ehresman Tar file symbolic link bug fix (2005-03-20) CLOSED http://python.org/sf/1167128 opened by Ellers a fix for doctest crash when it is ran on itself (2005-03-20) CLOSED http://python.org/sf/1167316 opened by Ilya Sandler [AST] Generator expressions (2005-03-22) http://python.org/sf/1167628 opened by Nick Coghlan ast for decorators (2005-03-21) http://python.org/sf/1167709 opened by John Ehresman distutils.dir_utils.mkpath to support unicode (2005-03-21) http://python.org/sf/1167716 opened by John M. Camara Add current dir when running try_run test program (2005-03-22) http://python.org/sf/1168055 opened by Michiel de Hoon tarfile.py: set sizes of non-regular files to zero. (2005-03-22) http://python.org/sf/1168594 opened by Lars Gustäbel Handle ungzipped man pages in rpm builds correctly (2005-03-23) http://python.org/sf/1169193 opened by Robin Green [ast branch] unicode literal fixes (2005-03-25) http://python.org/sf/1170272 opened by John Ehresman Method for cell objects to access contents (2005-03-24) http://python.org/sf/1170323 opened by paul cannon Newline in error output of py_compile.compile (2005-03-26) http://python.org/sf/1171150 opened by paul cannon bug fix for islice() in docs (2005-03-27) CLOSED http://python.org/sf/1171417 opened by Pernici Mario Patch for [ 1170331 ] Error in base64.b32decode (2005-03-27) http://python.org/sf/1171487 opened by logistix Fix compile/link when using Darwin 8 (2005-03-28) CLOSED http://python.org/sf/1171735 opened by Bob Ippolito Fix compile/link when using Darwin 8 (2005-03-28) CLOSED http://python.org/sf/1171767 opened by Bob Ippolito long long support for array module (2005-03-29) http://python.org/sf/1172711 opened by Oren Tirosh Patches Closed __ [AST] Fix handling of large octal literals (2005-03-20) http://python.org/sf/1166879 closed by bcannon asdl_c.py fix for long lines (2005-03-20) http://python.org/sf/1167117 closed by bcannon Tar file symbolic link bug fix (2005-03-20) http://python.org/sf/1167128 closed by loewis ast-branch: msvc project sync (2003-05-23) http://python.org/sf/742621 closed by bcannon ast-branch: hacks so asdl_c.py generates compilable code (2005-01-14) http://python.org/sf/1102710 closed by bcannon a fix for doctest crash when it is ran on itself (2005-03-21) http://python.org/sf/1167316 closed by tim_one urllib2 .getheaders attribute error (2005-02-06) http://python.org/sf/1117588 closed by fdrake the quotes page on the Web site links to something broken (2005-03-14) http://python.org/sf/1163314 closed by jjinux add set/getattr interface to tkFont.Font objects (2003-07-01) http://python.org/sf/764221 closed by loewis bug fix for islice() in docs (2005-03-27) http://python.org/sf/1171417 closed by rhettinger Fix compile/link when using Darwin 8 (2005-03-28) http://python.org/sf/1171735 closed by etrepum Fix compile/link when using Darwin 8 (2005-03-28) http://python.org/sf/1171767 closed by etrepum New / Reopened Bugs ___ IterableUserDict not in docs (2005-03-19) http://python.org/sf/1166582 opened by Kent Johnson The readline module can cause python to segfault (2005-03-19) http://python.org/sf/110 opened by Yariv Ido [ast branch] fatal error when compiling test_bool.py (2005-03-19) CLOSED http://python.org/sf/1166704 opened by John Ehresman [ast branch] fatal error when compiling test_bool.py (2005-03-20) http://python.org/sf/1166714 opened by John Ehresman Fails assertion in winsig.c under VC 8.0 (2005-03-21) http://python.org/sf/1167262 opened by Timothy Fitz Error "exec"ing
Re: [Python-Dev] Re: comprehension abbreviation (was: Adding any() andall())
On Mar 29, 2005, at 17:41, Terry Reedy wrote: ... "Steve Holden" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Having to write [x for x in seq] to produce a copy of a list doesn't seem that outrageous to me, Except for (currently) leaving the last value of sequence bound to 'x' after making the copy, how is the above different from list(seq)? Well, it's less concise, and over an order of magnitude slower: Nimue:~/pypy alex$ python2.4 -mtimeit -s'seq=range(1000)' '[x for x in seq]' 1000 loops, best of 3: 312 usec per loop Nimue:~/pypy alex$ python2.4 -mtimeit -s'seq=range(1000)' 'list(seq)' 1 loops, best of 3: 24.3 usec per loop I fail to see any advantages to compensate for these minuses. Alex ___ 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
