Good evening everybody!
I like to run the 2to3 tool with raise and except fixers over the 2.6
sources. The raise fixer changes "raise Exception, msg" to "raise
Exception(msg)" and the except fixer replaces "except Exception, err" by
"except Exception as err". In my humble opinion the Python stdlib should
give proper examples how write good code.
During the migration period from the 2.x series to 3.x we have two
obvious ways to write code. Let's stick to the new and preferred way.
Oh and please use the new syntax for patches, too. It makes my job with
svnmerge a little bit easier.
Don't now if always, or in the last few months where I've been
following the issues more closely, but I found that are appearing a
lot of small RFEs in the tracker.
These normally are small but not trivial things. In most cases when I
read them I think "Mmm, yes... it won't hurt to have it, but it's not
so important, and definitively not my itch to scratch". See, for
example, this  one, that ask for a factorial method in the
Normally these RFEs stay there for a long time, unless they're clearly
negative, because they don't raise any discussion.
OTOH, we have a PEP for feature requests . I quote part of it:
This PEP was created to allow us to close bug reports that are really
feature requests. Marked as Open, they distract from the list of real
bugs (which should ideally be less than a page). Marked as Closed, they
tend to be forgotten. The procedure now is: if a bug report is really
a feature request, add the feature request to this PEP; mark the bug as
"feature request", "later", and "closed"; and add a comment to the bug
saying that this is the case (mentioning the PEP explicitly).
This is still valid? Should we start moving RFEs to this PEP and
closing their issues in the tracker?
Or should we try to get more discussion regarding these RFEs? Maybe,
for example, a weekly digest where the latests RFEs added are sent to
python-dev, so we can actually say "no way" and close them, or say
"nice" and *then* moving them to the PEP (this has the risk of nobody
saying anything, and to stay in the same position as before).
What do you think? Opinions?
Thank you very much!
---------- Forwarded message ----------
From: Guido van Rossum <guido(a)python.org>
Date: Sat, Feb 23, 2008 at 1:26 PM
Subject: Re: [Python-Dev] Mutex module
To: Facundo Batista <facundobatista(a)gmail.com>
According to the docstring it's only meant to be used with sched.py.
Please don't try to make it work with threads! Maybe this needs to be
moved into a "simulations" package in 3.0?
On Sat, Feb 23, 2008 at 1:22 PM, Facundo Batista
> In today's bug day, an Argentinian colleague called my attention over
> the issue 1746071.
> This issue is about mutex:
> """The mutex module defines a class that allows mutual-exclusion via
> acquiring and releasing locks. It does not require (or imply)
> threading or multi-tasking, though it could be useful for those
> The problem here is that mutex is NOT thread safe! Even when it says
> in the docs that it could be useful for threading!
> "Ok, let's make this mutex to be thread-safe", I thought, and my
> colleague reviewed the proposed patch, even finding and submitting a
> correction to it.
> But two points prevented me for further work here:
> - It has not test cases at all
> - It does something that could be easily done (today) using parts from
> the threading module.
> There're some comments in that issue that points towards a deprecation
> of this module.
> So, I'm asking here. Is it still working in 3k? What are the plans
> here? What do you think about this module? Is somebody using it?
> Thank you all! Regards,
>  http://bugs.python.org/issue1746071
>  http://docs.python.org/dev/library/mutex.html
> . Facundo
> Blog: http://www.taniquetil.com.ar/plog/
> PyAr: http://www.python.org/ar/
> Python-Dev mailing list
--Guido van Rossum (home page: http://www.python.org/~guido/)
--Guido van Rossum (home page: http://www.python.org/~guido/)
In today's bug day, an Argentinian colleague called my attention over
the issue 1746071.
This issue is about mutex:
"""The mutex module defines a class that allows mutual-exclusion via
acquiring and releasing locks. It does not require (or imply)
threading or multi-tasking, though it could be useful for those
The problem here is that mutex is NOT thread safe! Even when it says
in the docs that it could be useful for threading!
"Ok, let's make this mutex to be thread-safe", I thought, and my
colleague reviewed the proposed patch, even finding and submitting a
correction to it.
But two points prevented me for further work here:
- It has not test cases at all
- It does something that could be easily done (today) using parts from
the threading module.
There're some comments in that issue that points towards a deprecation
of this module.
So, I'm asking here. Is it still working in 3k? What are the plans
here? What do you think about this module? Is somebody using it?
Thank you all! Regards,
-----BEGIN PGP SIGNED MESSAGE-----
On Feb 21, 2008, at 11:21 AM, skip.montanaro wrote:
> Author: skip.montanaro
> Date: Thu Feb 21 17:21:15 2008
> New Revision: 60919
> Replace "looks ugly" with a hopefully more concrete explanation of
> why line
> wrapping is bad - it disrupts the visual structure of the code.
> Modified: peps/trunk/pep-0008.txt
> --- peps/trunk/pep-0008.txt (original)
> +++ peps/trunk/pep-0008.txt Thu Feb 21 17:21:15 2008
> @@ -77,10 +77,11 @@
> There are still many devices around that are limited to 80
> lines; plus, limiting windows to 80 characters makes it possible
> to have
> - several windows side-by-side. The default wrapping on such
> devices looks
> - ugly. Therefore, please limit all lines to a maximum of 79
> - For flowing long blocks of text (docstrings or comments),
> limiting the
> - length to 72 characters is recommended.
> + several windows side-by-side. The default wrapping on such
> + disrupts the visual structure of the code, making it more
> difficult to
> + understand. Therefore, please limit all lines to a maximum of 79
> + characters. For flowing long blocks of text (docstrings or
> + limiting the length to 72 characters is recommended.
Why should docstrings and comments be limited to 72 characters when
code is limited to 79 characters? I ask because there is an ongoing
debate at my company about this.
Personally, I see no justification for it, and further, it's a pita to
support automatically because tools like Emacs only have one auto-
wrapping variable (fill-column). Emacs doesn't know that it should
fill comments and docstrings different than code lines, so you have to
do a bunch of manual crud to support these guidelines.
I recommend removing the guideline of 72 characters, and just say
everything, code, comments, and docstrings should be no wider than 79
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
-----END PGP SIGNATURE-----
With the PyCon sprint approaching I would like all attendees to be
signed up on the wiki page for the sprint:
http://wiki.python.org/moin/PyCon2008/SprintSignups/Python . I am
going to be using that list to send out an email about what is exactly
expected of people in terms of setup ahead of time, etc.
And even if you do know what you are doing, I still would appreciate
people adding themselves so I can have a head count. That will let the
sprint coordinators make sure we have a space big enough for us.
I've uncovered what seems to me to a problem with python Unicode
string objects passed to extension modules. Or perhaps it's revealing
a misunderstanding on my part :-) So I would like to get some
Extension modules written in C receive strings from python via the
PyArg_ParseTuple family. Most extension modules use the 's' or 's#'
Many C libraries in Linux use the UTF-8 encoding.
The 's' format when passed a Unicode object will encode the string
according to the default encoding which is immutably set to 'ascii' in
site.py. Thus a C library expecting UTF-8 which uses the 's' format in
PyArg_ParseTuple will get an encoding error when passed a Unicode
string which contains any code points outside the ascii range.
Now my questions:
* Is the use of the 's' or 's*' format parameter in an extension
binding expecting UTF-8 fundamentally broken and not expected to
work? Instead should the binding be using a format conversion which
specifies the desired encoding, e.g. 'es' or 'es#'?
* The extension modules could successfully use the 's' or 's#' format
conversion in a UTF-8 environment if the default encoding was
UTF-8. Changing the default encoding to UTF-8 would in one easy
stroke "fix" most extension modules, right? Why is the default
encoding 'ascii' in UTF-8 environments and why is the default
encoding prohibited from being changed from ascii?
* Did Python 2.5 introduce anything which now makes this issue visible
whereas before it was masked by some other behavior?
Python programs which use Unicode string objects for their i18n and
which "link" to C libraries expecting UTF-8 but which have a CPython
binding which only uses 's' or 's#' formats programs seem to often
fail with encoding errors. However, I have yet to see a CPython
binding which does explicitly define it's encoding requirements. This
suggests to me I either do not understand the issue in it's entirety
or many CPython bindings in Linux UTF-8 environments are broken with
respect to their i18n handling and the problem is currently
John Dennis <jdennis(a)redhat.com>
This message has been popping up in the buildbot mails for several days:
> Conflict detected in commontex/boilerplate.tex. Doc build skipped.
I have no idea what it means. I don't see it within the core distribution.
Can someone take a look at this?