Mailman 3 July 2010 - Python-Dev

Compiling Free Cad on Rhel5
by Vikas Mahajan 28 Jul '10

28 Jul '10

Hello to all......Today I was trying to install FreeCAD 0.10 from its source code. I am using RHEL5. I have firstly installed python2.6.5 from source and also tested it. Python is working fine. But when I try to compile FreeCAD 0.10, I got following configure error : #./configure --with-python-include=/usr/local/include/python2.6 --with-python-lib=/usr/local/lib/python2.6 --------------------------------------------------------------------------------------------------------------------------------------------------------- checking for a Python interpreter with version >= 2.5... python checking for python... /usr/local/bin/python checking for python version... 2.6 checking for python platform... linux2 checking for python script directory... ${prefix}/lib/python2.6/site-packages checking for python extension module directory... ${exec_prefix}/lib/python2.6/site-packages checking Python.h usability... yes checking Python.h presence... yes checking for Python.h... yes checking for libpython2.6... no configure: error: **** Cannot find Python2.6 devel files. **** ---------------------------------------------------------------------------------------------------------------------------------------------------------- I also searched internet for python-devel source code but was unable to find any such pacage. Please help me to resolve this python error. Thanks Vikas Mahajan

4 4

View tracker patches with ViewVC?
by Terry Reedy 28 Jul '10

28 Jul '10

To review a patch on the tracker, I have to read and try to make sense of the raw diff file. Sometimes that is easy, sometimes not. *After* a patch is applied, I can click the revxxxx link and then the 'text changed' link and see a nice, colored, side-by-side web-pace view created by ViewVC. Is there any way a 'view' button could be added, along with the current edit and remove buttons, to produce the same web page and make it easier to review patches *before* commitment? -- Terry Jan Reedy

8 19

Define a place for code review in Python workflow
by anatoly techtonik 27 Jul '10

27 Jul '10

http://bugs.python.org/issue9376 This issue discussed docs on the proper way to create diff on windows (as it is doesn't have the tool) for sending the patch. The current proper way is to use "svn diff" which will be replaced with "hg diff". I proposed using Rietveld like: > python -m easy_install review > python -m review But Brian said using Rietveld at all is not a good idea, and didn't want to answer what should be done for it to become good idea. Probably Brian is too busy, that's why I'd like to ask people here. What do you need or expect to happen to start using code review in Python workflow? == Intro == Small introduction for insiders not familiar with outsider's problem of maintaining patches in tracker. Please forgive the tone I write about things I dislike, but I am not devoting my life to earn a title of polite bastard (this one is obligatory disclaimer I find it still doesn't work for all people, so expect some irrelevant flame in follow-ups). Ok, for an outsider like me "svn diff" 'best practice' suxx greatly, because in non-ideal conditions (and it is about 90% of cases) patches are often needed to be edited, and reuploaded. There are usually too few insiders to review you patch, and they are usually too busy to edit a small typo, and they also deny that they need an online tool to see if patch applies clearly, so if your patch doesn't apply clearly you will be asked to check where the problem is. The "svn diff" upload story continues time after time. The problem of too few insiders is that there are too few of them, and in case your patch is somehow complicated it can enjoy some years of loneliness. During this time not only the code can change, but the codebase itself can move to some other place. Some of the few are devoting great time to review new contributions and everything could be fine, but.. there is still a big time lapse, big enough that your patches start to overlap.. Trying to get out of this maintenance nightmare you will start learning Mercurial, then Mercurial Queues, then you go some weeks practicing or.. you will just give up right away, because time is more valuable than money. If you're an insider, you can propose to review patches in ViewVC, but it is just plain wrong. Just because. Just because there are tools that do the job better. Even if they have awful usability interface. That can be improved though. By stealing templates from Gerrit. == How Rietveld helps to save time == Assuming that Python has "easy_install" packaging solution bundled by default (which it doesn't of course): > python -m easy_install review This is run once to install the Rietveld script that is used from command like like: > python -m review and allows you to: 1. Create issue for patch review on Rietveld site 2. Run "svn diff" 3. Upload the patch 4. Supply comment for the patch everything above in one step. To upload an updated patch, you just do: > python -m review -i XXXXX -m "log of fixes made in comparison with previous patch" Everybody can go to Rietveld site to view either patch or the whole file code _with_ the patch. Everybody can add comments _directly_ near patch lines. Everybody receives notifications about new code review comments. As code comments are hard to keep offtopic, the signal to noise ration appears to be is quite high. The patch upload script is designed in a way that every project can tune it for their needs and place into the root of source code. "review" project at PyPI.is uploaded from source at http://bitbucket.org/techtonik/pypi-rietveld - it can be tuned to address needs specific for Python development. What do you need to start using code review for contributed Python patches? Why you wouldn't recommend this practice to outsiders? -- anatoly t.

5 6

Readability of hex strings (Was: Use of coding cookie in 3.x stdlib)
by anatoly techtonik 27 Jul '10

27 Jul '10

I find "\xXX\xXX\xXX\xXX..." notation for binary data totally unreadable. Everybody who uses and analyses binary data is more familiar with plain hex dumps in the form of "XX XX XX XX...". I wonder if it is possible to introduce an effective binary string type that will be represented as h"XX XX XX" in language syntax? It will be much easier to analyze printed binary data and copy/paste such data as-is from hex editors/views. On Mon, Jul 19, 2010 at 9:45 AM, Guido van Rossum <guido(a)python.org> wrote: > Sounds like a good idea to try to remove redundant cookies *and* to > remove most occasional use of non-ASCII characters outside comments > (except for unittests specifically trying to test Unicode features). > Personally I would use \xXX escapes instead of spelling out the > characters in shlex.py, for example. > > Both with or without the coding cookies, many ways of displaying text > files garble characters outside the ASCII range, so it's better to > stick to ASCII as much as possible. > > --Guido > > On Mon, Jul 19, 2010 at 1:21 AM, Alexander Belopolsky > <alexander.belopolsky(a)gmail.com> wrote: >> I was looking at the inspect module and noticed that it's source >> starts with "# -*- coding: iso-8859-1 -*-". I have checked and there >> are no non-ascii characters in the file. There are several other >> modules that still use the cookie: >> >> Lib/ast.py:# -*- coding: utf-8 -*- >> Lib/getopt.py:# -*- coding: utf-8 -*- >> Lib/inspect.py:# -*- coding: iso-8859-1 -*- >> Lib/pydoc.py:# -*- coding: latin-1 -*- >> Lib/shlex.py:# -*- coding: iso-8859-1 -*- >> Lib/encodings/punycode.py:# -*- coding: utf-8 -*- >> Lib/msilib/__init__.py:# -*- coding: utf-8 -*- >> Lib/sqlite3/__init__.py:#-*- coding: ISO-8859-1 -*- >> Lib/sqlite3/dbapi2.py:#-*- coding: ISO-8859-1 -*- >> Lib/test/bad_coding.py:# -*- coding: uft-8 -*- >> Lib/test/badsyntax_3131.py:# -*- coding: utf-8 -*- >> >> I understand that coding: utf-8 is strictly redundant in 3.x. There >> are cases such as Lib/shlex.py where using encoding other than utf-8 >> is justified. (See >> http://svn.python.org/view?view=rev&revision=82560). What are the >> guidelines for other cases? Should redundant cookies be removed? >> Since not all editors respect the -*- cookie, I think the answer >> should be "yes" particularly when the cookie is setting encoding other >> than utf-8. >> _______________________________________________ >> 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 (python.org/~guido) > _______________________________________________ > 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/techtonik%40gmail.com >

4 3

marking os.system() as deprecated in the docs
by Chris Rebert 27 Jul '10

27 Jul '10

Hello, I'd like to propose formally marking os.system() as deprecated in the docs for next release of Python (v3.2 ?). The docs for os.system() /already/ include the following paragraph, which is basically tantamount to calling system() deprecated and very much resembles the deprecation notes for the os.popen*() family. """ The subprocess module provides more powerful facilities for spawning new processes and retrieving their results; using that module is preferable to using this function. Use the subprocess module. Check especially the Replacing Older Functions with the subprocess Module section. """ I'm merely suggesting slapping a formal ".. deprecated::" tag & box around this paragraph to make system()'s status more obvious. I am ***not*** suggesting the function be scheduled for removal or anything like that. I figure since this would be a substantive change (the docs currently don't outright say "deprecated"), it would need dev approval, hence this message. I've already written the absolutely /trivial/ docs patch. So, any objections? Cheers, Chris

6 6

Do any of the 4 multiprocessing methods work using shared memory?
by Kevin Ar18 27 Jul '10

27 Jul '10

Brief Summary: Can I share Python objects between multiple processes using shared memory (using the multiprocessing module)? In particular, do Queues or Pipes work using shared memory? Details: * I have several processes each on a separate CPU core (so they run in parallel). * I want to share certain Python objects between the processes using shared memory (I can handle the locking myself -- only one process can access a variable or object at a time, so there is no conflict anyways). * I strongly prefer that it be shared memory because I do not want to incur the costs of having to copy data back and forth between the processes. I am aware of the multiprocessing module. It offers: Queues Pipes Shared Memory Map Server Process So, let me ask a few questions about those 4 items: Queues & Pipes These handle Python objects and variables.... However, my question is do they use shared memory or do they require copying the data or some other method that is more costly than shared memory? Shared Memory Map Does not support Python objects or variables -- thus no good to me. Server Process Looks like it requires another process that incurs extra processing just to handle the data exchange -- which, if true, is bad for me. Does this use shared memory? or does it require copying data back and forth between processes? _________________________________________________________________ The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multiaccount&ocid=PID28…

2 1

Set the namespace free!
by Bartosz Tarnowski 27 Jul '10

27 Jul '10

Hello, guys. Python has more and more reserved words over time. It becomes quite annoying, since you can not use variables and attributes of such names. Suppose I want to make an XML parser that reads a document and returns an object with attributes corresponding to XML element attributes: > elem = parse_xml("<element param='boo'/>") > print elem.param boo What should I do then, when the attribute is a reserver word? I could use trailing underscore, but this is quite ugly and introduces ambiguity. > elem = parse_xml("<element for='each'/>") > print elem.for_ #????? > elem = parse_xml("<element for_='each'/>") > print elem.for__ #????? My proposal: let's make a syntax change. Let all reserved words be preceded with some symbol, i.e. "!" (exclamation mark). This goes also for standard library global identifiers. !for boo in foo: !if boo is !None: !print(hoo) !else: !return !sorted(woo) This would allow the user to declare any identifier with any name: for = with(return) + try What do you think of it? It is a major change, but I think Python needs it. -- haael

17 25

Fwd: Readability of hex strings (Was: Use of coding cookie in 3.x stdlib)
by anatoly techtonik 27 Jul '10

27 Jul '10

Don't you think it is a bad idea to require people to subscribe to post to python-ideas of redirected there? -- anatoly t. ---------- Forwarded message ---------- From: <python-ideas-owner(a)python.org> Date: Mon, Jul 26, 2010 at 11:24 PM Subject: Re: [Python-Dev] Readability of hex strings (Was: Use of coding cookie in 3.x stdlib) To: techtonik(a)gmail.com You are not allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at python-ideas-owner(a)python.org. ---------- Forwarded message ---------- From: anatoly techtonik <techtonik(a)gmail.com> To: Alexandre Vassalotti <alexandre(a)peadrop.com> Date: Mon, 26 Jul 2010 23:24:15 +0300 Subject: Re: [Python-Dev] Readability of hex strings (Was: Use of coding cookie in 3.x stdlib) On Mon, Jul 26, 2010 at 9:42 PM, Alexandre Vassalotti <alexandre(a)peadrop.com> wrote: > [+Python-ideas -Python-Dev] > > import binascii > def h(s): > return binascii.unhexlify("".join(s.split())) > > h("DE AD BE EF CA FE BA BE") The idea is to make "print f.read(50)" usable. Your current solution is: -Beautiful is better than ugly. -Explicit is better than implicit. -Simple is better than complex. Complex is better than complicated. Flat is better than nested. -Sparse is better than dense. -Readability counts. Special cases aren't special enough to break the rules. -Although practicality beats purity. Errors should never pass silently. ... -- anatoly t. > -- Alexandre > > On Mon, Jul 26, 2010 at 11:29 AM, anatoly techtonik <techtonik(a)gmail.com> wrote: >> I find "\xXX\xXX\xXX\xXX..." notation for binary data totally >> unreadable. Everybody who uses and analyses binary data is more >> familiar with plain hex dumps in the form of "XX XX XX XX...". >> >> I wonder if it is possible to introduce an effective binary string >> type that will be represented as h"XX XX XX" in language syntax? It >> will be much easier to analyze printed binary data and copy/paste such >> data as-is from hex editors/views. >> >> On Mon, Jul 19, 2010 at 9:45 AM, Guido van Rossum <guido(a)python.org> wrote: >>> Sounds like a good idea to try to remove redundant cookies *and* to >>> remove most occasional use of non-ASCII characters outside comments >>> (except for unittests specifically trying to test Unicode features). >>> Personally I would use \xXX escapes instead of spelling out the >>> characters in shlex.py, for example. >>> >>> Both with or without the coding cookies, many ways of displaying text >>> files garble characters outside the ASCII range, so it's better to >>> stick to ASCII as much as possible. >>> >>> --Guido >>> >>> On Mon, Jul 19, 2010 at 1:21 AM, Alexander Belopolsky >>> <alexander.belopolsky(a)gmail.com> wrote: >>>> I was looking at the inspect module and noticed that it's source >>>> starts with "# -*- coding: iso-8859-1 -*-". I have checked and there >>>> are no non-ascii characters in the file. There are several other >>>> modules that still use the cookie: >>>> >>>> Lib/ast.py:# -*- coding: utf-8 -*- >>>> Lib/getopt.py:# -*- coding: utf-8 -*- >>>> Lib/inspect.py:# -*- coding: iso-8859-1 -*- >>>> Lib/pydoc.py:# -*- coding: latin-1 -*- >>>> Lib/shlex.py:# -*- coding: iso-8859-1 -*- >>>> Lib/encodings/punycode.py:# -*- coding: utf-8 -*- >>>> Lib/msilib/__init__.py:# -*- coding: utf-8 -*- >>>> Lib/sqlite3/__init__.py:#-*- coding: ISO-8859-1 -*- >>>> Lib/sqlite3/dbapi2.py:#-*- coding: ISO-8859-1 -*- >>>> Lib/test/bad_coding.py:# -*- coding: uft-8 -*- >>>> Lib/test/badsyntax_3131.py:# -*- coding: utf-8 -*- >>>> >>>> I understand that coding: utf-8 is strictly redundant in 3.x. There >>>> are cases such as Lib/shlex.py where using encoding other than utf-8 >>>> is justified. (See >>>> http://svn.python.org/view?view=rev&revision=82560). What are the >>>> guidelines for other cases? Should redundant cookies be removed? >>>> Since not all editors respect the -*- cookie, I think the answer >>>> should be "yes" particularly when the cookie is setting encoding other >>>> than utf-8. >>>> _______________________________________________ >>>> 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 (python.org/~guido) >>> _______________________________________________ >>> 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/techtonik%40gmail.com >>> >> _______________________________________________ >> 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/alexandre%40peadrop.com >> >

3 2

:program: markup in .rst documentation
by Eli Bendersky 27 Jul '10

27 Jul '10

While fixing the :option: markup in the library docs (http://bugs.python.org/issue9312), another question came up: In a few places, documenting a program execution with options was made with: :program:`python regrtest.py` :option:`test_spam.py` Since my patch had the :option: markup removed, this became: :program:`python regrtest.py test_spam.py` However, according to Éric Araujo's comment, due to the intention of the :program: markup this should actually just say: ``python regrtest.py test_spam.py`` Which way to choose? I will update my patch to reflect this. Eli

6 7

Re: [Python-Dev] IDLE contributors and committers
by Steve Holden 27 Jul '10

27 Jul '10

On 7/17/2010 7:33 AM, Antoine Pitrou wrote: > > Hello, > > On Sun, 11 Jul 2010 02:05:22 +0300 > Tal Einat <taleinat(a)gmail.com> wrote: >> >> I would like to propose removing IDLE from the standard library. >> >> I have been using IDLE since 2002 and have been doing my best to help >> maintain and further develop IDLE since 2005. > > I haven't seen any conclusive statement or action to this thread. > Without being an IDLE user myself (for good reason), I think that if > IDLE should stay, active contributors such as Tal should be given commit > access and enough free rein to maintain and improve it. > > Otherwise there's no reason to continue claiming that IDLE is important > while discouraging such people's contributions. The current situation, > where several core developers support IDLE's continued inclusion but > none actually cares for the issues and patches in the tracker, is > schizophrenic. > > Regards > > Antoine. +1 There's no reason why Tal should be obstructed in his goal of making IDLE at least acceptable again. It's fairly obvious thaat there aren't any committers who have both the inclination /and/ the time to do this, so adding Tal (and other interested parties) as a developer makes a lot of sense. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010 http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/

12 19

Python-Dev July 2010