> Author: alexandre.vassalotti
> Date: Tue May 6 21:48:38 2008
> New Revision: 62778
> Added fast alternate io.BytesIO implementation and its test suite.
> Removed old test suite for StringIO.
> Modified truncate() to imply a seek to given argument value.
Thanks for your great work! But what about the trunk? :] Can you port
your code to the trunk before the alpha gets out?
Bill Janssen wrote:
> The HTTP client-side library calls "makefile" on the socket, then
> closes it, then passes the file returned from "makefile" on to
> application code to work with.
Seems to me we really need two different APIs for
doing a makefile()-like operation, depending on
whether you're expecting to get a copy of the
file descriptor or not.
-----BEGIN PGP SIGNED MESSAGE-----
This is a reminder that the LAST planned alpha releases of Python 2.6
and 3.0 are scheduled for next Wednesday, 07-May-2008. Please be
diligent over the next week so that none of your changes break
Python. The stable buildbots look moderately okay, let's see what we
can do about getting them all green:
We have a few showstopper bugs, and I will be looking at these more
carefully starting next week.
Time is running short to get any new features into Python 2.6 and
3.0. The release after this one is scheduled to be the first beta
release, at which time we will institute a feature freeze. If your
feature doesn't make it in by then, you'll have to wait until
2.7/3.1. If there is something that absolutely must go into 2.6/3.0
be sure that there is a bug issue open for it and that the Priority is
set to 'release blocker'. I may reduce it to critical for the next
alpha, but we'll review all the release blocker and critical issues
for the first 2.6 and 3.0 beta releases.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
-----END PGP SIGNATURE-----
While trying to use urllib in python 2.5.1 to HTTP GET content from
various web sites, I've run into a problem with urllib.quote
(and .quote_plus): they don't accept unicode strings.
I see that this is an issue that has been discussed before:
see this thread: http://mail.python.org/pipermail/python-dev/2006-July/067248.html
especially this post: http://mail.python.org/pipermail/python-dev/2006-July/067335.html
While I don't really want to re-open a can of worms, it seems that the
current implementation of urllib.quote and urllib.quote_plus is
painfully incompatible with how the web (circa 2008) actually works.
While the standards may say there is no official way to represent
unicode strings in URLs, in practice the world uses UTF-8 quite
heavily. For example, I found the following URLs in Google pretty
quickly by looking for percent encoded utf-8 encoded accented e's.
While in theory UTF-8 is not a standard, sites like Last.fm, Facebook
and Wikipedia seem to have embraced it (as have pretty much all other
major web sites). As with HTML, there is what the standard says and
what the actual browsers have to accept in order to work in the real
urllib.urlencode already converts unicode characters to their UTF-8
representation before percent encoding them. Why not urllib.quote and
Thanks for any thoughts on this,
Just a friendly reminder that this weekend is the Python sprint weekend! Look forward to seeing everyone on #python-dev irc.freenode.net over the course of the weekend!
On 16 Apr, 18:52, Trent Nelson wrote:
> Following on from the success of previous sprint/bugfix weekends and
> sprinting efforts at PyCon 2008, I'd like to propose the next two
> Global Python Sprint Weekends, taking place on the following dates:
> * May 10th-11th (four days after 2.6a3 and 3.0a5 are released)
> * June 21st-22nd (~week before 2.6b2 and 3.0b2 are released)
> It seems there are a few of the Python User Groups keen on meeting
> up in person and sprinting collaboratively, akin to PyCon, which I
> highly recommend. I'd like to nominate Saturday across the board
> as the day for PUGs to meet up in person, with Sunday geared more
> towards an online collaboration day via IRC, where we can take care
> of all the little things that got in our way of coding on Saturday
> (like finalising/preparing/reviewing patches, updating tracker and
> documentation, writing tests ;-).
> For User Groups that are planning on meeting up to collaborate,
> please reply to this thread on python-dev(a)python.org and let every-
> one know your intentions!
> As is commonly the case, #python-dev on irc.freenode.net will be
> the place to be over the course of each sprint weekend; a large
> proportion of Python developers with commit access will be present,
> increasing the amount of eyes available to review and apply patches.
> For those that have an idea on areas they'd like to sprint on and
> want to look for other developers to rope in (or just to communicate
> plans in advance), please also feel free to jump on this thread via
> python-dev@ and indicate your intentions.
> For those that haven't the foggiest on what to work on, but would
> like to contribute, the bugs tracker at http://bugs.python.org is
> the best place to start. Register an account and start searching
> for issues that you'd be able to lend a hand with.
> All contributors that submit code patches or documentation updates
> will typically get listed in Misc/ACKS.txt; come September when the
> final release of 2.6 and 3.0 come about, you'll be able to point at
> the tarball or .msi and exclaim loudly ``I helped build that!'',
> and actually back it up with hard evidence ;-)
> Bring on the pizza and Red Bull!
I just made another attempt to use ctypes to wrap a library, and am
facing the same problem I had the last time: the documentation doesn't
really work. I'm wondering if we have any projects underway to
Why does sock.close() not actually close sock?
If I run the code
sock = socket.socket()
I would expect that a system call is done to actually close the socket
and free the file descriptor. But that does not happen. Look at the
code in socket.py. It merely replaces the socket instance with a dummy
instance so that all subsequent calls on the sock object fail, but it
does nothing else!
The register and upload commands have a --repository option that
allows to use them with any server. You can register and upload a
package to any server that has the right set of web services. They
also work with a configuration file called .pypirc
Unfortunately there is no inline option to define the
username/password. This has to be defined in .pypirc.
But this file does not allow having different sets of
username/password, so in reality it is not possible to play with
#1858 provides a patch for this 
I have submitted it in January, after some discussion in catalog-sig
and distutils-sig, that led to a proposal 
I am looking for a final reviewer, to decide if the new .pypirc is
considered suitable, and maybe have it integrated in the 2.6.
This new format will be used in the Plone community to interact with
plone.org and the cheeseshop , (with a third party package
at this time, that implements the patch)
Tarek Ziadé | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
Some of you may have seen a video recorded in November 2006 where I
showed off Mondrian, a code review tool that I was developing for
Google (http://www.youtube.com/watch?v=sMql3Di4Kgc). I've always hoped
that I could release Mondrian as open source, but it was not to be:
due to its popularity inside Google, it became more and more tied to
proprietary Google infrastructure like Bigtable, and it remained
limited to Perforce, the commercial revision control system most used
What I'm announcing now is the next best thing: an code review tool
for use with Subversion, inspired by Mondrian and (soon to be)
released as open source. Some of the code is even directly derived
from Mondrian. Most of the code is new though, written using Django
and running on Google App Engine.
I'm inviting the Python developer community to try out the tool on the
web for code reviews. I've added a few code reviews already, but I'm
hoping that more developers will upload at least one patch for review
and invite a reviewer to try it out.
To try it out, go here:
Please use the Help link in the top right to read more on how to use
the app. Please sign in using your Google Account (either a Gmail
address or a non-Gmail address registered with Google) to interact
more with the app (you need to be signed in to create new issues and
to add comments to existing issues).
Don't hesitate to drop me a note with feedback -- note though that
there are a few known issues listed at the end of the Help page. The
Help page is really a wiki, so feel free to improve it!
--Guido van Rossum (home page: http://www.python.org/~guido/)