[Python-Dev] Re: [maintenance doc updates]
Hello, Fred L. Drake wrote: > The maintenance version of the documentation has been updated: > > http://www.python.org/dev/doc/maint24/ Very good. The download links under http://docs.python.org/download.html doesn't work any more. (packages not there) But 2.4.1 is not yet released, so I will only remind this not criticise. bye by Wolfgang ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] RELEASED Python 2.4.1 (final)
> I'm happy to announce the release of Python 2.4.1 (final). Woohoo! Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] RELEASED Python 2.4.1 (final)
On behalf of the Python development team and the Python community, I'm happy to announce the release of Python 2.4.1 (final). Python 2.4.1 is a bug-fix release. See the release notes at the website (also available as Misc/NEWS in the source distribution) for details of the bugs squished in this release. Python 2.4.1 should be a completely painless upgrade from Python 2.4 - no new features have been added. For more information on Python 2.4.1, including download links for various platforms, release notes, and known issues, please see: http://www.python.org/2.4.1/ Highlights of this new release include: - Bug fixes. According to the release notes, several dozen bugs have been fixed, including a fix for the SimpleXMLRPCServer security issue (PSF-2005-001). Highlights of the previous major Python release (2.4) are available from the Python 2.4 page, at http://www.python.org/2.4/highlights.html Enjoy the new release, Anthony Anthony Baxter [EMAIL PROTECTED] Python Release Manager (on behalf of the entire python-dev team) pgpMCj4iJZ5nA.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org 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
Hello! Jim Jewett have sent me information about remote features of Opera, so I downloaded Opera for Linux and w32 and tested them. On Linux Opera support remote functionality almost identical to Mozilla. I added a new Opera controller. On w32 remote commands are ignored, so GenericBrowser still is used. The updated patches were uploaded to http://python.org/sf/754022 . This, I hope, is the last touch. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: [Python-checkins] python/dist/src/Modules readline.c, 2.82, 2.83
[EMAIL PROTECTED] writes: > Update of /cvsroot/python/python/dist/src/Modules > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv10274 > > Modified Files: > readline.c > Log Message: > Fixes for > > [ 110 ] The readline module can cause python to segfault > > It seems to me that the code I'm rewriting here attempted to call any > user-supplied hook functions using the thread state of the thread that > called the hook-setting function, as opposed to that of the thread > that is currently executing. This doesn't work, in general. > > Fix this by using the PyGILState API (It wouldn't be that hard to > define a dummy version of said API when #ifndef WITH_THREAD, would > it?). > > Also, check the conversion to integer of the return value of a hook > function for errors (this problem was mentioned in the ipython bug > report linked to in the above bug). Oh, and I forgot to say: this should go into realease24-maint when that opens again. Cheers, mwh -- You're going to have to remember that I still think of Twisted as a big multiplayer game, and all this HTTP stuff is just kind of a grotty way to display room descriptions. -- Glyph Lefkowitz ___ Python-Dev mailing list Python-Dev@python.org 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 wrote:
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,
OK.
and it indeed requires utf-8 at the
moment. This can be fixed, of course,
The register command in 2.4 (and current CVS) simply does a
value = str(value)
in post_to_server() so the encoded bytes sent depend on the
default encoding. Would it be sufficient to change this to
value = unicode(value).encode("utf-8")
Another solution might be to include the encoding in the Content-type
header of the request. IMHO the best solution would be to do both:
Always use UTF-8 as the encoding and include this in the Content-type
header in the request. PyPI should honor this encoding when it finds
it and should fall back to whatever it used before if it doesn't.
but not for already-released
versions.
True, but I can live with that as long as I can use the same setup.py
for bdist_windist and register under Python 2.4 and upload under
Python CVS.
Bye,
Walter Dörwald
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: RELEASED Python 2.4.1 (final)
Terry> The page http://www.python.org/download/ needs to be added to the Terry> list of things updated with a new release. Terry, I'll let others take care of that list (I don't know where it's kept). In the meantime, I updated the download page to reference 2.4.1. Skip ___ Python-Dev mailing list Python-Dev@python.org 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:
The register command in 2.4 (and current CVS) simply does a
value = str(value)
in post_to_server() so the encoded bytes sent depend on the
default encoding. Would it be sufficient to change this to
value = unicode(value).encode("utf-8")
Indeed. I think this can go into 2.4.2.
Another solution might be to include the encoding in the Content-type
header of the request. IMHO the best solution would be to do both:
Always use UTF-8 as the encoding and include this in the Content-type
header in the request. PyPI should honor this encoding when it finds
it and should fall back to whatever it used before if it doesn't.
Yeah, well :-) Content-type in form upload is a mess, as you certainly
know. It should be honored, but commonly isn't. This, in turn, causes
browsers to ignore it.
PyPI uses the CGI module. It currently decodes anything that doesn't
have a filename attribute to UTF-8, causing rejection of anything
that doesn't send UTF-8. This could be fixed/extended, but I think that
would be best done in the CGI module, for consumption by any application
that uses form upload. For example, doing
cgi.FieldStorage(..., encoding="UTF-8")
should cause
a) decoding of every field that has an encoding= in its content
type
b) decoding of every field that is not a file to UTF-8. It is a
file if it
I) has a filename, or
II) cannot be decoded to the target decoding
For backwards compatibility, a) can only be enabled if the CGI
application explicitly tells what encoding it expects.
I'd like to state "contributions are welcome", although others
may think differently.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
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: There's been a problem with your request exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 92: ordinal not in range(128) That should be fixed now, please try again. Please report further errors you find to sf.net/projects/pypi. Suggestions/RFEs could go to the PyPI tracker, or here to python-dev. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org 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 wrote: Walter Dörwald wrote: There's been a problem with your request exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 92: ordinal not in range(128) That should be fixed now, please try again. Works perfectly, thanks! > [...] Bye, Walter Dörwald ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] @decoration of classes
Nick Coghlan wrote: ># A decorator that does not alter its argument >def register(callable): > # Register the callable somewhere > ... > return callable > ># Decorated factory function >@register >def factory(): > pass > ># Post-decorated class >class factory: > pass >register(factory) > ># Metaclass >class RegisteredType(type): > def __init__(self, name, bases, dict): >super(self, RegisteredType).__init__(self, name, bases, dict) >register(self) > >class factory: > __metaclass__ = RegisteredType > ># Class decorator (not currently possible) >@register >class factory: > pass class factory: @register def __call__(self): pass Just as an additional data point - obviously not applicable in all cases. Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] @decoration of classes
Michael Chermside wrote: So I'm inclined to use different tools for modifying functions and modifying classes because the ways you want to modify them are different, and decorators are "tuned" to what people normally want to do with functions (like simple wrapping) while metaclasses are "tuned" to what people normally want to do with classes (like support for inheritance. The area where I can see an overlap is in those decorators which, rather than altering the behaviour of the function itself, serve to register it with an external framework of some description. At the moment, a factory function that is actually implemented as a function can be registered with such a system using an @decorator. If you use the __new__/__init__ methods of a class as your factory, however, you need to either post-decorate the class or create a metaclass that performs the registration. It would be nice if decorators that worked for any callable (like the registration example) could be easily used with classes as well as standard functions. (The adaptation PEP's adapter registry is an actual situation that comes to mind) # A decorator that does not alter its argument def register(callable): # Register the callable somewhere ... return callable # Decorated factory function @register def factory(): pass # Post-decorated class class factory: pass register(factory) # Metaclass class RegisteredType(type): def __init__(self, name, bases, dict): super(self, RegisteredType).__init__(self, name, bases, dict) register(self) class factory: __metaclass__ = RegisteredType # Class decorator (not currently possible) @register class factory: pass PJE's example of moving the decoration near the top of the class definition without allowing class decoration contains an important caveat: it requires that the decorators be written to support doing that. Allowing class decoration means any appropriate decorators can be used, unmodified, to affect classes as well as functions. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] @decoration of classes
At 10:05 AM 3/31/05 +1000, Nick Coghlan wrote: PJE's example of moving the decoration near the top of the class definition without allowing class decoration contains an important caveat: it requires that the decorators be written to support doing that. Allowing class decoration means any appropriate decorators can be used, unmodified, to affect classes as well as functions. Yeah, but that can be trivially worked around using a 'decorate' function, e.g.: from protocols.advice import addClassAdvisor def decorate(*decorators): decorators = list(decorators)[::-1] def callback(cls): for dec in decorators: cls = cls(dec) return cls addClassAdvisor(callback) class SomeClass: decorate(dec1,dec2,...) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] @decoration of classes
Delaney, Timothy C (Timothy) wrote: class factory: @register def __call__(self): pass Just as an additional data point - obviously not applicable in all cases. Yep, and it's obviously possible to do that now with just function decorators. Getting my head around what that actually *does* is a little trickier, though (as near as I can tell, it will register a standalone function named __call__, with nothing linking it to the containing class). What a class decorator allows is the registration of the whole process of invoking the metaclass and hence __new__ and __init__ as a single unit. Anyway, I don't particularly feel the lack of class decorators, but I thought I should mention this (perhaps small) category of non-transforming decorators as a situation where class decoration would make more sense to me than using a metaclass. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] BRANCH UNFROZEN
Ok, 2.4.1 seems good, so the release24-maint branch is unfrozen for bugfixes. We'll aim for a 2.4.2 around August/September, assuming no critical bugs come up before then... -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
