Mailman 3 November 2009 - Python-Dev

Status of the Buildbot fleet and related bugs
by R. David Murray 16 Nov '09

16 Nov '09

The buildbot waterfall is much greener now. Thanks to all who have contributed to making it so (and it hasn't just been Mark and Antoine and I, though we've been the most directly active (and yes, Mark, you did contribute several fixes!)). The 'stable builders' fleet is green now except for: (1) issue 7269: occasional 2.6/trunk bsddb3 failures on windows (2) issue 6748: random 3.1/3.x failures on most buidbots. (3) the klose-debian-ppc builder being offline Of these, (2) is by _far_ the biggest issue, and the one that causes the most flap (success-failure-success). And flap is the thing that most harms the buildbot usefulness. Anyone who wants to debug this on a platform where it is consistently reproducible please email me your public key and I'll give you a shell account on my buildbot (Antoine already has one). In the 'unstable' builder fleet, Antoine's new builder seems to be stable across the board, while mine fails consistently on 3.1 and 3.x because of the test_telnetlib bug. Thomas Heller's OS X buildbot is consistently having lots of test failures (the same ones each time I've checked). The master claims the klose-debian-alpha buildbot doesn't know about branches, which is odd since it was working not too long ago. The remaining buildslaves appear to have been offline for some time. Open issues here are: (1) issue 3864: FreeBSD testing hangs consistently. According to the ticket this is a FreeBSD bug fixed in 6.4, so an OS upgrade on the buildslave would probably solve it. (2) issue 4970: consistent signal 32 error on the norwitz-x86 Gentoo buildslave in 3.1 and 3.x. This may be due to the box running an old threading library, but it does make one wonder what changed in 3.x that exposed it. Another issue that I've seen on the buildbots but that doesn't seem to be showing up right now (is it fixed?) is issue 7251, which Mark is working on. So, overall I think the buildbot fleet is in good shape, and if we can nail issue 6748 I think it will be back to being an important resource for sanity checking our checkins. By the way, Georg set up the IRC interface on the #python-dev channel, so you can hang out there if you want to get realtime reports of which buildbots have going from success to failure and vice versa. --David

12 22

global statements outside functions/methods should raise SyntaxError
by Ezio Melotti 16 Nov '09

16 Nov '09

Python currently accepts global statements at the top level: >>> global foo >>> Beside being a meaningless operation, this might lead unexperienced user to make mistakes like: >>> foo = 5 >>> global foo # make foo global >>> def func(): ... print foo # access the global foo ... >>> func() 5 >>> # it works! "global foo" should raise a SyntaxError, similarly to what already happens with "return": >>> return foo File "<stdin>", line 1 SyntaxError: 'return' outside function I opened an issue on the tracker (http://bugs.python.org/issue7329) and Benjamin suggested to discuss this here. The test he mentioned is in test_global.py: def test4(self): prog_text_4 = """\ global x x = 2 """ # this should work compile(prog_text_4, "<test string>", "exec") It just says that "it should work" but it doesn't say /why/. Any thoughts?

7 6

Using itertools in modules that are part of the build chain (Re: [Python-checkins] r76264 - python/branches/py3k/Lib/tokenize.py)
by Nick Coghlan 16 Nov '09

16 Nov '09

benjamin.peterson wrote: > Modified: python/branches/py3k/Lib/tokenize.py > ============================================================================== > --- python/branches/py3k/Lib/tokenize.py (original) > +++ python/branches/py3k/Lib/tokenize.py Sat Nov 14 17:27:26 2009 > @@ -377,17 +377,12 @@ > The first token sequence will always be an ENCODING token > which tells you which encoding was used to decode the bytes stream. > """ > + # This import is here to avoid problems when the itertools module is not > + # built yet and tokenize is imported. > + from itertools import chain This is probably a bad idea - calling tokenize.tokenize() from a thread started as a side effect of importing a module will now deadlock on the import lock if the module import waits for that thread to finish. We tell people not to do that (starting and then waiting on threads as part of module import) for exactly this reason, but it is also the reason we avoid embedding import statements inside functions in the standard library (not to mention encouraging third party developers to also avoid embedding import statements inside functions). This does constrain where we can use itertools - if we want carte blanche to use it anywhere in the standard library, even those parts that are imported as part of the build chain, we'll need to bite the bullet and make it a builtin module rather than a separately built extension module. Cheers, Nick. P.S. The problem is easy to demonstrate on the current Py3k branch: 1. Put this in a module file in your py3k directory (e.g. "deadlock.py"): ----------- import threading import tokenize f = open(__file__, 'rU') def _deadlocks(): tokenize.tokenize(f.readline) t = threading.Thread(target=_deadlocks) t.start() t.join() ----------- 2. Then run: ./python -c "import deadlock" It will, as advertised, deadlock and you'll need to use Ctrl-Brk or kill -9 to get rid of it. (Note that preventing this kind of thing is one of the major reasons why direct execution and even the -m switch *don't* hang onto the import lock while running the __main__ module) -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia ---------------------------------------------------------------

3 3

Modules that run other scripts
by Nick Coghlan 15 Nov '09

15 Nov '09

I'm in the process of adding a "run_path" function to the runpy module that allows Python code to execute scripts using the same rules as the CPython command line (i.e. accepting both source and compiled Python files in addition to zipfiles, directories and other valid sys.path entries containing a __main__.py file). After that I was considering looking at the standard library to see which modules can be used to execute other scripts (e.g. pdb, profile) and determine what would be involved in updating them to support the same flexibility as the main command line (possibly including adding their own "-m" option to run modules by name rather than file path location). For that second part: 1. Is it even worth doing at this stage? I'm not sure to what degree the new command line flexibility has even been adopted by third party application packagers, so I have no idea how large the pool of potential users might be. Should I instead wait until we start seeing complaints that these tools can't be used with script references that the main command line will handle quite happily? 2. Aside from runpy itself, pdb and profile are the only examples that spring to mind when I try to think of standard library modules that execute other Python scripts. Are there any others that I'm missing? (Even if we decide not to do anything at this stage, collating such a list may still be handy for future reference) Regards, Nick. P.S. pdb in particular may be messy to update, since the interaction between the way it provides exception post-mortem debugging support and the way the runpy module tries to avoid mutating the application's own __main__ module will likely require careful handling. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia ---------------------------------------------------------------

2 2

Re: [Python-Dev] PyPI front page
by P.J. Eby 14 Nov '09

14 Nov '09

At 08:33 PM 11/12/2009 -0500, Ian Bicking wrote: >On Thu, Nov 12, 2009 at 7:52 PM, Antoine Pitrou ><<mailto:solipsis@pitrou.net>solipsis(a)pitrou.net> wrote: >Ben Finney <ben+python <at> <http://benfinney.id.au>benfinney.id.au> writes: > > > > There's a problem with the poll's placement: on the front page of the > > PyPI website. > >Speaking of which, why is it that ><http://pypi.python.org/pypi>http://pypi.python.org/pypi and ><http://pypi.python.org/pypi/>http://pypi.python.org/pypi/ (note the >ending slash) return different contents >(the latter being very voluminous)? I always mistake one for the other when >entering the URL directly. > > >easy_install replied on the behavior of /pypi/ (it uses the long >list to do case-insensitive searches).Â Someone changed it, >easy_install broke, and a compromise was to keep /pypi/ the way it >was (but not /pypi). > >Probably this could be removed, as the /simple/ index is already >case-insensitive, so easy_install shouldn't have to hit /pypi/ at all. This was changed over a year ago; easy_install *does* use /simple by default. I would guess enough people are upgraded by now that PyPI need no longer continue to support it.

1 0

Re: [Python-Dev] PyPI comments and ratings, *really*?
by Steven D'Aprano 14 Nov '09

14 Nov '09

On Fri, 13 Nov 2009 04:27:48 am Ludvig Ericson wrote: > On 12 nov 2009, at 14:38, Steven D'Aprano wrote: > > On Thu, 12 Nov 2009 08:44:32 pm Ludvig Ericson wrote: > >> Why are there comments on PyPI? Moreso, why are there comments > >> which I cannot control as a package author on my very own > >> packages? That's just absurd. > > > > No, what's absurd is thinking that the act of publishing software > > somehow gives you the right to demand control over what others say > > about your software. > > ... on my own package's page. It's your package. It's the community's page about your package. I think of PyPI as a community-owned noticeboard. Its primary purpose is to allow the community to find good packages -- the benefit to the community is why it exists, not the benefit to the author of the package. In my opinion, the community is best served by a good comment/review system, one which avoids the worst trolling, and allows authors the right of reply, but does not allow authors to censor inconvenient but honest reviews. -- Steven D'Aprano

5 6

External module tests skipping on Windows build slaves?
by David Bolen 14 Nov '09

14 Nov '09

While working with the Windows (and now Windows 7) build slaves I've been noticing that a number of "unexpected" test skips are occurring, mostly for external modules like ssl, bz2, tk, etc... However, I know for a fact that those libraries are being fetched and built, so I was a little perplexed that they were being skipped for testing. I don't think it's a regression due to the recent slave work, but something that may have been happening for a while, if not always. Some manual testing I did would seem to indicate that there's a problem related to loading the right MS CRT when loading these modules. But they seem to reference both debug and non-debug versions, so even if I copy the CRT DLLs (from the SxS tre) into pcbuild manually, then I get a CRT assertion about a bad initialization. I suspect this wouldn't be a problem when everything is built in release mode. I would have sworn they used to get run, but now I'm not so sure. Perhaps I'm remembering older Python releases with VS.NET 2003, since the MSVC9 versions of the CRT and the SXS stuff was new with VS 2008 I think. Does anyone happen to know if these tests have ever run recently on the Windows build slaves? -- David

1 1

Re: [Python-Dev] Python-Dev Digest, Vol 76, Issue 114
by wa2n39＠gmail.com 14 Nov '09

14 Nov '09

Please don't send me again this email ------Pesan Asli------ Dari:python-dev-request@python.org Pengirim:python-dev-bounces+wa2n39=gmail.com@python.org Ke:python-dev@python.org Balas Ke:python-dev@python.org Perihal:Python-Dev Digest, Vol 76, Issue 114 Terkirim:13 Nov 2009 03:00 Send Python-Dev mailing list submissions to python-dev(a)python.org To subscribe or unsubscribe via the World Wide Web, visit http://mail.python.org/mailman/listinfo/python-dev or, via email, send a message with subject or body 'help' to python-dev-request(a)python.org You can reach the person managing the list at python-dev-owner(a)python.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Python-Dev digest..." Today's Topics: 1. Re: standard libraries don't behave like standard 'libraries' (Masklinn) ---------------------------------------------------------------------- Message: 1 Date: Fri, 13 Nov 2009 11:50:49 +0100 From: Masklinn <masklinn(a)masklinn.net> To: Python-Dev <python-dev(a)python.org> Subject: Re: [Python-Dev] standard libraries don't behave like standard 'libraries' Message-ID: <45186ACD-29BA-4D5E-9ADB-25632021A539(a)masklinn.net> Content-Type: text/plain; charset=us-ascii On 13 Nov 2009, at 11:36 , Anand Balachandran Pillai wrote: > I think the recent postings on "CPAN for Python" in this list also stems > from similar thoughts. No. The CPAN for Python messages (in and out of the list) are about third-party packages and a better way to manage (and a better experience of installing) those. Think Ruby, it has a significant stdlib (though not as extensive as Python's), but it also has gems (and the `gem` CLI util). Or Haskell, which also has a significant stdlib (GHC does anyway) but also has cabal and cabal-install. ------------------------------ _______________________________________________ Python-Dev mailing list Python-Dev(a)python.org http://mail.python.org/mailman/listinfo/python-dev End of Python-Dev Digest, Vol 76, Issue 114 ******************************************* Sent from my BlackBerry® powered by Sinyal Kuat INDOSAT

1 0

decimal.py: == and != comparisons involving NaNs
by Stefan Krah 14 Nov '09

14 Nov '09

Hi, in a (misguided) bugreport (http://bugs.python.org/issue7279) I was questioning the reasons for allowing NaN comparisons with == and != rather than raising InvalidOperation. I think two main issues emerge from the brief discussion: 1. Should the comparison operators follow the 'compare' function from the standard? The standard says: "An implementation may use this operation [compare] under the covers to implement a closed set of comparison operations (greater than, equal, etc.) if desired. It need not, in this case, expose the compare operation itself." So, I'd say that this supports following 'compare' as closely as possible. In fact the operators <, <=, >, >= already follow 'compare-signal' in their behavior (they raise for any NaN operand). 2. What is the use of == and != outside the decimal scope? Mark mentions that Python uses == to test for set and dict memberships, but that you cannot put decimal NaNs into sets: 'TypeError: Cannot hash a NaN value' I want to add that Decimal('NaN') == Decimal('NaN') gives False, which should somewhat limit the uses of == for NaNs outside the decimal realm anyway. Are there cases where == and != are actually needed to give a result for NaNs? Stefan Krah

9 21

Summary of Python tracker Issues
by Python tracker 13 Nov '09

13 Nov '09

ACTIVITY SUMMARY (11/06/09 - 11/13/09) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2491 open (+27) / 16645 closed (+14) / 19136 total (+41) Open issues with patches: 993 Average duration of open issues: 684 days. Median duration of open issues: 442 days. Open Issues Breakdown open 2455 (+27) pending 35 ( +0) Issues Created Or Reopened (42) _______________________________ test_debuglevel from test_telnetlib.py fails 11/06/09 CLOSED http://bugs.python.org/issue6748 reopened r.david.murray patch, buildbot json module apparently fails regression found at http://json.org 11/06/09 CLOSED http://bugs.python.org/issue7274 created DougShawhan CoverageResult fails to merge input file with non-empty callers 11/06/09 http://bugs.python.org/issue7275 created glinsvad patch UnboundLocalError scoping problem with nested functions 11/06/09 CLOSED http://bugs.python.org/issue7276 created olau online docs out-of-sync with sources and distributed .chm files 11/07/09 CLOSED http://bugs.python.org/issue7277 created gagenellina decimal.py: New instance vs. new reference 11/07/09 CLOSED http://bugs.python.org/issue7278 created skrah decimal.py: == and != comparisons involving NaNs 11/07/09 CLOSED http://bugs.python.org/issue7279 created skrah PCBuild instruction says to use nasmw.exe but it no longer exist 11/07/09 http://bugs.python.org/issue7280 created blep patch copysign() with NaN arguments on OpenSolaris 11/07/09 CLOSED http://bugs.python.org/issue7281 created skrah RLocks leak references when used in raw threads 11/08/09 CLOSED http://bugs.python.org/issue7282 created pitrou patch test_site failure when .local/lib/pythonX.Y/site-packages hasn't 11/08/09 http://bugs.python.org/issue7283 created pitrou optparse - display version in usage by default 11/08/09 http://bugs.python.org/issue7284 created techtonik multiprocessing module, example code error 11/08/09 http://bugs.python.org/issue7285 created hsmtkk patch odd exec() behavior or documentation 11/08/09 http://bugs.python.org/issue7286 created pmawhorter import hook demo does not work 11/08/09 http://bugs.python.org/issue7287 created blep Detect improper leading whitespace in C files for Vim 11/08/09 http://bugs.python.org/issue7288 created brett.cannon easy bad import in redemo.py script in v3.1 11/08/09 CLOSED http://bugs.python.org/issue7289 created alan.gauld(a)btinternet.com Update 'how do I set a global variable' faq entry 11/09/09 CLOSED http://bugs.python.org/issue7290 created r.david.murray patch urllib2 cannot handle https with proxy requiring auth 11/09/09 http://bugs.python.org/issue7291 created tsujikawa patch Multiprocessing Joinable race condition? 11/09/09 http://bugs.python.org/issue7292 created jonathan test_msvc9compiler test_reg_class failure on new Windows box 11/09/09 http://bugs.python.org/issue7293 created db3l MSDN URL in subprocess.py is incorrect 11/09/09 CLOSED http://bugs.python.org/issue7294 created eric.smith easy test_tarfile uses a hardcoded file name 11/09/09 CLOSED http://bugs.python.org/issue7295 created pitrou patch OverflowError: signed integer is greater than maximum on mips64 11/09/09 http://bugs.python.org/issue7296 created jasper --spam-- 11/10/09 CLOSED http://bugs.python.org/issue7297 created brandon.dixon reversed(range(x, -1, -1)) is empty when x > 1 11/10/09 http://bugs.python.org/issue7298 created ledave123 patch setup.py install doesn't honor PYTHONUSERBASE 11/10/09 http://bugs.python.org/issue7299 created doko patch, patch Unicode arguments in str.format() 11/10/09 http://bugs.python.org/issue7300 created doerwalter Add environment variable $PYTHONWARNINGS 11/10/09 http://bugs.python.org/issue7301 created barry Wrong link to Python Language Mapping Specification 11/10/09 http://bugs.python.org/issue7302 created efrerich pkgutil lacks documentation for useful functions 11/10/09 http://bugs.python.org/issue7303 created englabenny email.message.Message.set_payload and as_string given charset 'u 11/10/09 http://bugs.python.org/issue7304 created r.david.murray urllib2.urlopen() segfault using SSL on Solaris 11/11/09 http://bugs.python.org/issue7305 created rtarnell Patch - skip winsound tests if no default sound is configured 11/11/09 http://bugs.python.org/issue7306 created brian.curtin patch test_distutils failure under Windows 7 11/11/09 CLOSED http://bugs.python.org/issue7307 created pitrou Named group regex error 11/11/09 CLOSED http://bugs.python.org/issue7308 created pythonmeister crasher in str(Exception()) 11/12/09 http://bugs.python.org/issue7309 created arigo Unhelpful __repr__() in os.environ 11/12/09 http://bugs.python.org/issue7310 created kjohnson Bug on regexp of HTMLParser 11/12/09 http://bugs.python.org/issue7311 created pluskid Run some tests in a loop until failure 11/12/09 http://bugs.python.org/issue7312 created pitrou patch 2to3 fails when source file starts with BOM 11/13/09 http://bugs.python.org/issue7313 created gagenellina test_multiprocessing hangs on Windows 7 64 bit 11/13/09 http://bugs.python.org/issue7314 created krisvale 64bit Issues Now Closed (31) ______________________ CGIHTTPRequestHandler.run_cgi() does not run on Windows if sys.e 769 days http://bugs.python.org/issue1235 orsenthil patch Management of KeyboardInterrupt in cmd.py 710 days http://bugs.python.org/issue1294 gvanrossum patch RLock's are SLOW 530 days http://bugs.python.org/issue3001 pitrou patch Real segmentation fault handler 406 days http://bugs.python.org/issue3999 Rhamphoryncus patch No universal newline support for compile() when using bytes 337 days http://bugs.python.org/issue4628 benjamin.peterson Auto-detect indentation in C source in vimrc 223 days http://bugs.python.org/issue5611 brett.cannon patch Subclassing property doesn't preserve the auto __doc__ behavior 195 days http://bugs.python.org/issue5890 moriyoshi patch, needs review test_codecs fails when ran after test_zipimport and test_mailbox 114 days http://bugs.python.org/issue6551 pitrou patch test_debuglevel from test_telnetlib.py fails 0 days http://bugs.python.org/issue6748 jackdied patch, buildbot round(x) gives wrong result for large odd integers 34 days http://bugs.python.org/issue7070 mark.dickinson easy Add looping capability to regrtest 29 days http://bugs.python.org/issue7134 pitrou importlib/_bootstrap.py write_bytecode raises an IOError if it c 16 days http://bugs.python.org/issue7187 brett.cannon patch test_multiprocessing crashes under Windows when run in verbose m 18 days http://bugs.python.org/issue7197 pitrou patch 2to3 execfile conversion changes behavior 1 days http://bugs.python.org/issue7268 gagenellina patch Tests for synchronization primitives 0 days http://bugs.python.org/issue7270 pitrou patch Typo in turtle module documentation. 1 days http://bugs.python.org/issue7271 georg.brandl json module apparently fails regression found at http://json.org 2 days http://bugs.python.org/issue7274 DougShawhan UnboundLocalError scoping problem with nested functions 3 days http://bugs.python.org/issue7276 r.david.murray online docs out-of-sync with sources and distributed .chm files 0 days http://bugs.python.org/issue7277 r.david.murray decimal.py: New instance vs. new reference 1 days http://bugs.python.org/issue7278 rhettinger decimal.py: == and != comparisons involving NaNs 1 days http://bugs.python.org/issue7279 mark.dickinson copysign() with NaN arguments on OpenSolaris 2 days http://bugs.python.org/issue7281 mark.dickinson RLocks leak references when used in raw threads 2 days http://bugs.python.org/issue7282 pitrou patch bad import in redemo.py script in v3.1 0 days http://bugs.python.org/issue7289 benjamin.peterson Update 'how do I set a global variable' faq entry 2 days http://bugs.python.org/issue7290 r.david.murray patch MSDN URL in subprocess.py is incorrect 0 days http://bugs.python.org/issue7294 eric.smith easy test_tarfile uses a hardcoded file name 2 days http://bugs.python.org/issue7295 pitrou patch --spam-- 0 days http://bugs.python.org/issue7297 rhettinger test_distutils failure under Windows 7 1 days http://bugs.python.org/issue7307 amaury.forgeotdarc Named group regex error 0 days http://bugs.python.org/issue7308 mark.dickinson 'compile' built-in function failures when missing EOL 1293 days http://bugs.python.org/issue1479099 benjamin.peterson Top Issues Most Discussed (10) ______________________________ 19 Enable short float repr() on Solaris/x86 208 days open http://bugs.python.org/issue5792 10 RLock's are SLOW 530 days closed http://bugs.python.org/issue3001 7 reversed(range(x, -1, -1)) is empty when x > 1 3 days open http://bugs.python.org/issue7298 7 test_multiprocessing dictionary changed size errors and hang 40 days open http://bugs.python.org/issue7060 6 OverflowError: signed integer is greater than maximum on mips64 4 days open http://bugs.python.org/issue7296 6 CGIHTTPRequestHandler.run_cgi() does not run on Windows if sys. 769 days closed http://bugs.python.org/issue1235 5 Management of KeyboardInterrupt in cmd.py 710 days closed http://bugs.python.org/issue1294 4 Run some tests in a loop until failure 1 days open http://bugs.python.org/issue7312 4 copysign() with NaN arguments on OpenSolaris 2 days closed http://bugs.python.org/issue7281 4 test_debuglevel from test_telnetlib.py fails 0 days closed http://bugs.python.org/issue6748

1 0

standard libraries don't behave like standard 'libraries'
by Sriram Srinivasan 13 Nov '09

13 Nov '09

> Sriram, > > Please take this discussion to catalog-sig - python-dev isn't the place > (the fact that many of us didn't immediately know the *right* place for > the discussion indicates where PyPI sits on our personal active level of > interest). > > You should find more interested (and knowledgable) folks and catalog-sig. > > Regards, > Nick. > sorry for posting the link in a lone post, i must have posted it with my previous post, and the theme is how to make the standard libraries state-of-the-art and i many feel it must be in py-dev as it is directly connected with the development of python. As it required some comparison, i compared pypi with the ruby's *rubyforge*. in fact what i found astonishing is that there are a lot of libraries (3rd party) available in packaged forms. which is a very good sign, the problem is there is no sorted out list for libraries and software in pypi. *rubyforge* is like a pypi for *libraries* (standard and 3rd party) i guess some misplaced topics such as [Python-Dev] PyPI comments and ratings, *really*? , [Python-Dev] PyPI front page are also getting alarming responses in the py-dev list. including yours, ;) As Anand says requiring a new update of battery v1.5 requires update of python/flashlight which only occurs every release is the manin senario. I would also like to add that what if a company doesn't need the batteries that you give at the first place, they have developed their own batteries and want to use them(or use some from the default with theit own), also wants to use the same flashlight/python system? - it would be *easy* only if the batteries included had a feature of being removed. -- Regards, Sriram

1 0

Fwd: standard libraries don't behave like standard 'libraries'
by Sriram Srinivasan 13 Nov '09

13 Nov '09

Sriram, > > Please take this discussion to catalog-sig - python-dev isn't the place > (the fact that many of us didn't immediately know the *right* place for > the discussion indicates where PyPI sits on our personal active level of > interest). > > You should find more interested (and knowledgable) folks and catalog-sig. > > Regards, > Nick. > sorry for posting the link in a lone post, i must have posted it with my previous post, and the theme is how to make the standard libraries state-of-the-art and i many feel it must be in py-dev as it is directly connected with the development of python. As it required some comparison, i compared pypi with the ruby's *rubyforge*. in fact what i found astonishing is that there are a lot of libraries (3rd party) available in packaged forms. which is a very good sign, the problem is there is no sorted out list for libraries and software in pypi. *rubyforge* is like a pypi for *libraries* (standard and 3rd party) i guess some misplaced topics such as [Python-Dev] PyPI comments and ratings, *really*? , [Python-Dev] PyPI front page are also getting alarming responses in the py-dev list. including yours, ;) As Anand says requiring a new update of battery v1.5 requires update of python/flashlight which only occurs every release is the manin senario. I would also like to add that what if a company doesn't need the batteries that you give at the first place, they have developed their own batteries and want to use them(or use some from the default with theit own), also wants to use the same flashlight/python system? - it would be *easy* only if the batteries included had a feature of being removed. -- Regards, Sriram.

1 0

Re: [Python-Dev] PyPI comments and ratings, *really*?
by Henning von Bargen 13 Nov '09

13 Nov '09

mode = "python-dev reader" Please excuse me if I'm wrong here, but I think python-dev just isn't the right place to discuss this topic, because it's about 3rd party packages and it's got nothing to do with the development *of the python language itself*, but generated a lot of traffic. mode = "package developer" I personally added a PyPI entry for my open source project just because it's there and it's a more or less standard, like CPAN in the Perl world, so I hoped others would perhaps find it there. On the other hand, if I am searching for software myself, I don't look at PyPI - I just use G**gle. I don't think PyPI needs any new features. For the "developer's social web" that support the feature, there are other good places, for example take a look at http://www.ohloh.net Henning

2 1

PEP 382 status
by Tarek Ziadé 13 Nov '09

13 Nov '09

Hi, I was wondering what's the status of PEP 382. Is anyone (MvL?) is going to start to work on its implementation for Python 2.7/3.2 inclusion ? Regards Tarek

4 3

FYI: LWN article on 2.x, 3.x, and the moratorium
by A.M. Kuchling 12 Nov '09

12 Nov '09

FYI: I've written an article for Linux Weekly News on the moratorium & related issues. The article is subscribers-only for a week, but here's a free link: http://lwn.net/SubscriberLink/361266/ef88bdbed5369800/ If you find this sort of thing useful/interesting, please consider subscribing to LWN. --amk

2 1

Is this a bug of the HTMLParser?
by Zhang Chiyuan 12 Nov '09

12 Nov '09

Hi all, I'm using BeautifulSoup to parsing an HTML page and find it refused to parse the page. By looking at the backtrace, I found it is a problem with the python built-in HTMLParser.py. In fact, the web page I'm parsing is with some Chinese characters. there is a tag like <img src=/foo/bar.png alt=中文> , note this is legacy html page where the attributes are not quoted. However, the regexp defined in HTMLParser.py is : attrfind = re.compile( r'\s*([a-zA-Z_][-.:a-zA-Z_0-9]*)(\s*=\s*' r'(\'[^\']*\'|"[^"]*"|[-a-zA-Z0-9./,:;+*%?!&$_#=~@]*))?') Note that the Chinese character (also any other non-english characters), so it fire an error parsing this. I'm not sure whether the HTML standard allow un-quoted non-ASCII characters in the attributes. If it allows, this seems to be a bug. and the regexp to better be [^>\s] IMHO. BTW: It seems something like : <script> var st = "<a></"; </script> can not be parsed. :-/ -- pluskid http://blog.pluskid.org

2 2

2.7/3.2 release schedule
by Benjamin Peterson 12 Nov '09

12 Nov '09

I've updated PEP 373 with my proposed release schedule: - 2.7/3.2 alpha 1 2009-12-05 - 2.7/3.2 alpha 2 2010-01-09 - 2.7/3.2 alpha 3 2010-02-06 - 2.7/3.2 alpha 4 2010-03-06 - 2.7/3.2 beta 1 2010-04-03 - 2.7/3.2 beta 2 2010-05-01 - 2.7/3.2 rc1 2010-05-29 - 2.7/3.2 rc2 2010-06-12 - 2.7/3.2 final 2010-06-26 -- Regards, Benjamin

8 15

IDLE as default Python editor (Was: [pygame] Python IDE for windoz)
by anatoly techtonik 12 Nov '09

12 Nov '09

Hello, Quite an interesting question recently popped up in pygame community that I'd like to ask to Python developers. How many of you use IDLE? What's wrong with it? >From my side I like the idea of having default Python editor that is small, fast, convenient and extensible/embeddable. IDLE is small and fast, but I feel really uncomfortable with its. The worst thing - I can't change it. Does anybody else feel the same to think if we could replace IDLE with something more maintainable by providing Scintilla bindings, for example? Regards, -- anatoly t. On Sat, Oct 10, 2009 at 8:15 PM, RB[0] <roebros(a)gmail.com> wrote: > Most? people just don't like it - personally it's all I use, Windows or > otherwise... > > On Sat, Oct 10, 2009 at 12:23 PM, Kris Schnee <kschnee(a)xepher.net> wrote: >> >> What's wrong with the built-in editor, IDLE? > >

9 11

[format] Restrict fill characters for numerical values
by Stefan Krah 11 Nov '09

11 Nov '09

Hi, I think http://www.python.org/dev/peps/pep-3101/ is too liberal with the choice of fill characters for numerical values. As far as I can see, this is quite legal: Python 2.7a0 (trunk:76132M, Nov 6 2009, 15:20:35) [GCC 4.1.3 20080623 (prerelease) (Ubuntu 4.1.2-23ubuntu3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from decimal import * >>> format(Decimal(4), "9<10") '4999999999' >>> format(Decimal(4), "9>10") '9999999994' >>> format(Decimal(4), "->2") '-4' >>> I propose to disallow digits and '+-' fill characters for numerical values, except for the combination '0, left-padding'. Actually, I'd prefer to allow only whitespace and '0, left-padding'. See also: http://bugs.python.org/issue6871 http://bugs.python.org/issue6902 Stefan Krah

2 4

Replacing IDLE
by anatoly techtonik 11 Nov '09

11 Nov '09

On Tue, Nov 10, 2009 at 12:10 AM, "Martin v. Löwis" <martin(a)v.loewis.de> wrote: >> >> Anatoly's question is actually a fair one for python-dev - we're the >> ones that *ship* Idle, so it is legitimate to ask our reasons for >> continuing to do so. > > OTOH, the second (or, rather, third) question (does anybody think it > should be replaced) is indeed on-topic for python-dev. That is the exact question I have in my mind. Sorry for not being able to state it clearly. I'll be more straightforward next time. > I didn't really answer that question before, so I do now: I have not > personally plans to replace it, and I'm skeptical wrt. anybody else's > plans unless there is specific code in existence that IDLE could be > replaced *with*. There are a lot of Python editors. It is unlikely that they implement all IDLE features, but I believe that 20% of IDLE features that is used by 80% of users are guaranteed by any editor out of the box. Assuming that they are more extensible than IDLE anyway. (I would say "perfection is achieved when there is nothing more to add...", but I promised to be straightforward). If we filter list of http://wiki.python.org/moin/PythonEditors by language/license/framework, we will be able to see if there is any suitable open source Python code to replace IDLE's. Then there will be another issue - all editors are based upon some frameworks - I didn't see any popular cross-platform GUI toolkits in Python, so we will inevitably face the need to replace Tkinter with other default GUI toolkit. Should we place an editor first and combine the list a of unique features of IDLE that we (as developers) will surely miss OR should we think what GUI framework will be more beneficial for Python users if shipped by default (keeping in mind that we might have to add missing features to whatever editor we choose later)? -- anatoly t.

8 14

Re: [Python-Dev] Python-Dev Digest, Vol 76, Issue 87
by wa2n39＠gmail.com 11 Nov '09

11 Nov '09

Stop email Sent from my BlackBerry® powered by Sinyal Kuat INDOSAT -----Original Message----- From: python-dev-request(a)python.org Date: Tue, 10 Nov 2009 23:09:45 To: <python-dev(a)python.org> Subject: Python-Dev Digest, Vol 76, Issue 87 Send Python-Dev mailing list submissions to python-dev(a)python.org To subscribe or unsubscribe via the World Wide Web, visit http://mail.python.org/mailman/listinfo/python-dev or, via email, send a message with subject or body 'help' to python-dev-request(a)python.org You can reach the person managing the list at python-dev-owner(a)python.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Python-Dev digest..." Today's Topics: 1. Re: 2.7/3.2 release schedule (Martin v. L?wis) 2. Re: 2.7/3.2 release schedule (Nick Coghlan) 3. Re: Reworking the GIL (Antoine Pitrou) 4. Re: Status of the Buildbot fleet and related bugs (Antoine Pitrou) 5. Re: Status of the Buildbot fleet and related bugs (Martin v. L?wis) 6. Re: 2.7/3.2 release schedule (Benjamin Peterson) 7. Re: 2.7/3.2 release schedule (Martin v. L?wis) ---------------------------------------------------------------------- Message: 1 Date: Tue, 10 Nov 2009 22:05:41 +0100 From: "Martin v. L?wis" <martin(a)v.loewis.de> To: Nick Coghlan <ncoghlan(a)gmail.com> Cc: Python Development <python-dev(a)python.org> Subject: Re: [Python-Dev] 2.7/3.2 release schedule Message-ID: <4AF9D5A5.5000707(a)v.loewis.de> Content-Type: text/plain; charset=UTF-8 >> PEP 3003 states that Python 3.2 will be released 18-24 months after >> Python 3.1. Python 3.1 was released on June 2009-06-27 [1], so >> theoretically Python 3.2 should be released not before 2010-12-19 [2]. > > The PEP 3003 text isn't allowing for the fact that 3.1 is "3.0 as it > should have been", so the starting point for the 18-24 month rule of > thumb is actually back when 3.0 was released in Dec 2008. This was > discussed a fair bit back when the decision was made to do the short > release cycle between 3.0 and 3.1 in order to address some of the more > glaring shortcomings of the 3.0 release. I agree with everybody else who said that a) there was *no* consensus that the release cycle for 3.2 should be shortened because of 3.1 being released early. I also remember the opposite. b) whatever past discussion may have been, it would be a mistake to release 3.2 earlier than 18 months after 3.1. Of course, 2.7 *could* be released by the proposed schedule; it just would have to be decoupled from 3.2 (just as 2.6 eventually got decoupled from 3.0). I personally think that decoupling the releases would be best, i.e. not start thinking about 3.2 for another 6 months. Regards, Martin ------------------------------ Message: 2 Date: Wed, 11 Nov 2009 07:16:50 +1000 From: Nick Coghlan <ncoghlan(a)gmail.com> To: "Martin v. L?wis" <martin(a)v.loewis.de> Cc: Python Development <python-dev(a)python.org> Subject: Re: [Python-Dev] 2.7/3.2 release schedule Message-ID: <4AF9D842.5000808(a)gmail.com> Content-Type: text/plain; charset=UTF-8 Martin v. L?wis wrote: >>> PEP 3003 states that Python 3.2 will be released 18-24 months after >>> Python 3.1. Python 3.1 was released on June 2009-06-27 [1], so >>> theoretically Python 3.2 should be released not before 2010-12-19 [2]. >> The PEP 3003 text isn't allowing for the fact that 3.1 is "3.0 as it >> should have been", so the starting point for the 18-24 month rule of >> thumb is actually back when 3.0 was released in Dec 2008. This was >> discussed a fair bit back when the decision was made to do the short >> release cycle between 3.0 and 3.1 in order to address some of the more >> glaring shortcomings of the 3.0 release. > > I agree with everybody else who said that > > a) there was *no* consensus that the release cycle for 3.2 should be > shortened because of 3.1 being released early. I also remember the > opposite. > > b) whatever past discussion may have been, it would be a mistake to > release 3.2 earlier than 18 months after 3.1. Fair enough - I didn't remember that discussion all that well, but assumed it had reached that consensus due to the lack of comment when Benjamin originally posted his proposed schedule. Your response and Guido's clearly indicate otherwise :) If that wasn't the consensus, then all the dates should slide back 6 months (i.e. no alphas until June 2010). (I actually prefer that since it gives me a chance to find a cleaner approach to the runpy.run_path problem, but didn't want to rehash a discussion I thought we had already had) > Of course, 2.7 *could* be released by the proposed schedule; it just > would have to be decoupled from 3.2 (just as 2.6 eventually got > decoupled from 3.0). That leads to a 2.x version with features that aren't yet available in a 3.x version though. I thought we weren't planning on doing that anymore. > I personally think that decoupling the releases would be best, i.e. > not start thinking about 3.2 for another 6 months. Or just have the timing be 18 months for 3.2 and 24 months for 2.7 (i.e. push the first alpha of both back to June next year). Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- ------------------------------ Message: 3 Date: Tue, 10 Nov 2009 21:26:24 +0000 (UTC) From: Antoine Pitrou <solipsis(a)pitrou.net> To: python-dev(a)python.org Subject: Re: [Python-Dev] Reworking the GIL Message-ID: <hdclq0$tov$1(a)ger.gmane.org> Content-Type: text/plain; charset=UTF-8 Hello again, I've now removed priority requests, tried to improve the internal doc a bit, and merged the changes into py3k. Afterwards, the new Windows 7 buildbot has hung in test_multiprocessing, but I don't know whether it's related. Regards Antoine. Guido van Rossum <guido <at> python.org> writes: > > > I would remove them -- if and when we find there's a need for > something like them I suspect it won't look like what you currently > have, so it's better not to complexificate your current patch with > them. (I would remove all traces, including the conditions passed into > the end macros.) > > >> My only suggestion so far: the description could use more explicit > >> documentation on the various variables and macros and how they > >> combine. > > > > Is it before or after > > http://mail.python.org/pipermail/python-checkins/2009- November/087482.html ? > > After. While that is already really helpful, not all the code is > easily linked back to paragraphs in that comment block, and some > variables are not mentioned by name in the block. > ------------------------------ Message: 4 Date: Tue, 10 Nov 2009 21:50:26 +0000 (UTC) From: Antoine Pitrou <solipsis(a)pitrou.net> To: python-dev(a)python.org Subject: Re: [Python-Dev] Status of the Buildbot fleet and related bugs Message-ID: <hdcn72$2rl$1(a)ger.gmane.org> Content-Type: text/plain; charset=UTF-8 Le Thu, 05 Nov 2009 22:53:27 -0500, R. David Murray a ?crit?: > The buildbot waterfall is much greener now. Thanks to all who have > contributed to making it so (and it hasn't just been Mark and Antoine > and I, though we've been the most directly active (and yes, Mark, you > did contribute several fixes!)). The buildbots still show occasional oddities. For example, right now in the page "http://www.python.org/dev/buildbot/3.x/", some results have disappeared (the columns for "AMD64 Ubuntu" builders have become empty). Moreover, some buildslaves have gone back in time (they are building r76188 after having built and tested r76195)... I swear the new GIL doesn't include a time machine. Regards Antoine. ------------------------------ Message: 5 Date: Tue, 10 Nov 2009 23:06:14 +0100 From: "Martin v. L?wis" <martin(a)v.loewis.de> To: Antoine Pitrou <solipsis(a)pitrou.net> Cc: python-dev(a)python.org Subject: Re: [Python-Dev] Status of the Buildbot fleet and related bugs Message-ID: <4AF9E3D6.2000807(a)v.loewis.de> Content-Type: text/plain; charset=UTF-8 >> The buildbot waterfall is much greener now. Thanks to all who have >> contributed to making it so (and it hasn't just been Mark and Antoine >> and I, though we've been the most directly active (and yes, Mark, you >> did contribute several fixes!)). > > The buildbots still show occasional oddities. For example, right now in > the page "http://www.python.org/dev/buildbot/3.x/", some results have > disappeared (the columns for "AMD64 Ubuntu" builders have become empty). Yes, I noticed it too. It will go away after some page reloads. > Moreover, some buildslaves have gone back in time (they are building > r76188 after having built and tested r76195)... I swear the new GIL > doesn't include a time machine. That's because I resubmitted these changes after restarting the master. Regards, Martin ------------------------------ Message: 6 Date: Tue, 10 Nov 2009 16:06:46 -0600 From: Benjamin Peterson <benjamin(a)python.org> To: Martin v. L?wis <martin(a)v.loewis.de> Cc: Nick Coghlan <ncoghlan(a)gmail.com>, Python Development <python-dev(a)python.org> Subject: Re: [Python-Dev] 2.7/3.2 release schedule Message-ID: <1afaf6160911101406t6da78accq8918eb4ceb1adca5(a)mail.gmail.com> Content-Type: text/plain; charset=UTF-8 2009/11/10 "Martin v. L?wis" <martin(a)v.loewis.de>: > I personally think that decoupling the releases would be best, i.e. > not start thinking about 3.2 for another 6 months. The problem with that is that there is a period of time where 2.x has features which 3.x doesn't. My preference is to move back the whole schedule 6 months. -- Regards, Benjamin ------------------------------ Message: 7 Date: Tue, 10 Nov 2009 23:09:42 +0100 From: "Martin v. L?wis" <martin(a)v.loewis.de> To: Benjamin Peterson <benjamin(a)python.org> Cc: Nick Coghlan <ncoghlan(a)gmail.com>, Python Development <python-dev(a)python.org> Subject: Re: [Python-Dev] 2.7/3.2 release schedule Message-ID: <4AF9E4A6.8070304(a)v.loewis.de> Content-Type: text/plain; charset=UTF-8 Benjamin Peterson wrote: > 2009/11/10 "Martin v. L?wis" <martin(a)v.loewis.de>: >> I personally think that decoupling the releases would be best, i.e. >> not start thinking about 3.2 for another 6 months. > > The problem with that is that there is a period of time where 2.x has > features which 3.x doesn't. My preference is to move back the whole > schedule 6 months. Ok, fine with me as well. FWIW, I don't see that (2.7 released before 3.2) as a problem (but I understand that others might, for what I would consider formal reasons). Regards, Martin ------------------------------ _______________________________________________ Python-Dev mailing list Python-Dev(a)python.org http://mail.python.org/mailman/listinfo/python-dev End of Python-Dev Digest, Vol 76, Issue 87 ******************************************

1 0

Re: [Python-Dev] Python-Dev Digest, Vol 76, Issue 83
by wa2n39＠gmail.com 11 Nov '09

11 Nov '09

Unreg ------Pesan Asli------ Dari:python-dev-request@python.org Pengirim:python-dev-bounces+wa2n39=gmail.com@python.org Ke:python-dev@python.org Balas Ke:python-dev@python.org Perihal:Python-Dev Digest, Vol 76, Issue 83 Terkirim:10 Nov 2009 03:00 Send Python-Dev mailing list submissions to python-dev(a)python.org To subscribe or unsubscribe via the World Wide Web, visit http://mail.python.org/mailman/listinfo/python-dev or, via email, send a message with subject or body 'help' to python-dev-request(a)python.org You can reach the person managing the list at python-dev-owner(a)python.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Python-Dev digest..." Today's Topics: 1. Re: Retrieve an arbitrary element from asetwithoutremoving it (Nick Coghlan) ---------------------------------------------------------------------- Message: 1 Date: Tue, 10 Nov 2009 20:51:19 +1000 From: Nick Coghlan <ncoghlan(a)gmail.com> To: "Martin v. L?wis" <martin(a)v.loewis.de> Cc: python-dev(a)python.org Subject: Re: [Python-Dev] Retrieve an arbitrary element from asetwithoutremoving it Message-ID: <4AF945A7.5090904(a)gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Martin v. L?wis wrote: >> I'm not sure, but isn't that thread-unsafe? > > You are right; it's thread-unsafe. > > I would fix it by catching the RuntimeError, and retrying. Given the > current GIL strategy (including proposed changes to it), it won't happen > two times in a row, so the number of retries would be bounded. It's also one of the major reasons for not sharing mutable containers between threads if you can avoid it (and serialising access to them if you can't) Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- ------------------------------ _______________________________________________ Python-Dev mailing list Python-Dev(a)python.org http://mail.python.org/mailman/listinfo/python-dev End of Python-Dev Digest, Vol 76, Issue 83 ****************************************** Sent from my BlackBerry® powered by Sinyal Kuat INDOSAT

1 0

raw binary data and 2to3
by skip＠pobox.com 10 Nov '09

10 Nov '09

SpamBayes has several files which contain raw 8-bit data embedded in string literals. Before I do manual work to make them parseable by 2to3 I thought I would ask if there was either a fixer available which I'm not getting by default or if there is an opportunity to add a new fixer to 2to3. The usage is pretty straightforward. For example, a string literal might contain the bytes for a GIF image: data = "GIF89a(..." Is there a potentially automated path from where the code is today to something Python 3 (and 2to3) will like? Skip

5 5

OpenSSL vulnerability
by Guido van Rossum 10 Nov '09

10 Nov '09

Now that a new SSL vulnerability is out (http://extendedsubset.com/?p=8) should we regenerate binary distributions that include copies of openssl (I think only the Windows MSIs) ? Does it affect any of our ssl APIs? -- --Guido van Rossum (python.org/~guido)

8 9

Retrieve an arbitrary element from a set without removing it
by Willi Richert 10 Nov '09

10 Nov '09

Hi, recently I wrote an algorithm, in which very often I had to get an arbitrary element from a set without removing it. Three possibilities came to mind: 1. x = some_set.pop() some_set.add(x) 2. for x in some_set: break 3. x = iter(some_set).next() Of course, the third should be the fastest. It nevertheless goes through all the iterator creation stuff, which costs some time. I wondered, why the builtin set does not provide a more direct and efficient way for retrieving some element without removing it. Is there any reason for this? I imagine something like x = some_set.get() or x = some_set.pop(False) and am thinking about providing a patch against setobject.c (preferring the .get() solution being a stripped down pop()). Before, I would like to know whether I have overlooked something or whether this can be done in an already existing way. Thanks, wr

39 151