Mailman 3 February 2008 - Python-Dev

Use Python 3.0 syntax for except and raise?
by Christian Heimes 25 Feb '08

25 Feb '08

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. Thanks! Christian

7 7

Re: [Python-Dev] can't set attributes of built-in/extension type
by Neal Becker 25 Feb '08

25 Feb '08

There is some discussion on this subject, archived here: http://permalink.gmane.org/gmane.comp.python.general/560661 I wonder if anyone could shed some light on this subject? (Or, help me understand, what is the difference between a type that I create using python C api and a python class?)

4 5

Small RFEs and the Bug Tracker
by Facundo Batista 24 Feb '08

24 Feb '08

Hi! 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 [1] one, that ask for a factorial method in the integers. 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 [2]. 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! Regards, [1] http://bugs.python.org/issue2138 [2] http://www.python.org/dev/peps/pep-0042/ -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

20 86

Fwd: Mutex module
by Guido van Rossum 24 Feb '08

24 Feb '08

---------- 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 <facundobatista(a)gmail.com> wrote: > Hi! > > 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 > purposes.""" > > 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, > > [1] http://bugs.python.org/issue1746071 > [2] 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 > Python-Dev(a)python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) -- --Guido van Rossum (home page: http://www.python.org/~guido/)

2 2

Mutex module
by Facundo Batista 24 Feb '08

24 Feb '08

Hi! 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 purposes.""" 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, [1] http://bugs.python.org/issue1746071 [2] http://docs.python.org/dev/library/mutex.html -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

1 0

Re: [Python-Dev] [Python-checkins] r60919 - peps/trunk/pep-0008.txt
by Barry Warsaw 23 Feb '08

23 Feb '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 > > Modified: > peps/trunk/pep-0008.txt > Log: > 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 > character > 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 > characters. > - 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 > devices > + 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 > comments), > + 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 characters. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR72xlXEjvBPtnXfVAQKEdAP/f1xnvn6jw04yyhSZfqA6HdgnYnpnYPAl S4ixszL8phg6KRq8CD2ceskY8TocDg+GG6c//M+jihRRzXMXHW/1Lfp/6syqAd1d vkWaUffaSK4rReMiEG0EmFZmYwaJA660RU0YBnv1d1Idpexj4Y/kIgfgou9OkWDY iJO+efk93Xc= =qYfT -----END PGP SIGNATURE-----

11 16

Please sign up for the PyCon sprint if you are attending!
by Brett Cannon 23 Feb '08

23 Feb '08

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. -Brett

1 0

Unicode <--> UTF-8 in CPython extension modules
by John Dennis 23 Feb '08

23 Feb '08

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 clarification. Extension modules written in C receive strings from python via the PyArg_ParseTuple family. Most extension modules use the 's' or 's#' format parameter. 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? Summary: 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 not addressed. -- John Dennis <jdennis(a)redhat.com>

4 4

Re: [Python-Dev] Python 2.6 and 3.0
by Raymond Hettinger 23 Feb '08

23 Feb '08

[Barry] > I'd also like for us to consider doing regular monthly releases. +1

1 0

boilerplate.tex
by skip＠pobox.com 23 Feb '08

23 Feb '08

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? Skip

3 2