[Python-Dev] Conflict between time docs and timeit
I see that the documentation for the time module has this to say about time.clock: On Unix, return the current processor time as a floating point number expressed in seconds. The precision, and in fact the very definition of the meaning of “processor time”, depends on that of the C function of the same name, but in any case, this is the function to use for benchmarking Python or timing algorithms. In contrast, timeit defaults to using time.time() under all operating systems other than Windows, and says: ...on Windows, clock() has microsecond granularity but time()'s granularity is 1/60th of a second; on Unix, clock() has 1/100th of a second granularity and time() is much more precise. Should timeit be changed, or the docs, or have I missed something? -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Documentation not being updated
A change that I made (a49bda5ff3d5) to the documentation 3 days ago does not appear to have propagated to http://docs.python.org/dev/library/multiprocessing.html Building the docs locally shows the change. Am I doing something wrong? Cheers Ross ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Documentation not being updated
On 18.03.2011 07:15, Ross Lagerwall wrote: A change that I made (a49bda5ff3d5) to the documentation 3 days ago does not appear to have propagated to http://docs.python.org/dev/library/multiprocessing.html Building the docs locally shows the change. Am I doing something wrong? Nope, that was me. Should be fixed now. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Generating patch files
I get unknown revision (listing the full expression text) when using
Mercurial 1.6.3 (default version in Ubuntu 10.10).
Based on Baptiste's approach, I propose the script below to compute a
patch. Please report whether it works for you.
Regards,
Martin
#!/bin/sh
base=`hg log --template {rev} -r'max(ancestors(default)-outgoing())'`
hg diff -r$base
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Conflict between time docs and timeit
On Fri, 18 Mar 2011 17:06:50 +1100 Steven D'Aprano st...@pearwood.info wrote: In contrast, timeit defaults to using time.time() under all operating systems other than Windows, and says: ...on Windows, clock() has microsecond granularity but time()'s granularity is 1/60th of a second; on Unix, clock() has 1/100th of a second granularity and time() is much more precise. Should timeit be changed, or the docs, or have I missed something? Well, time.clock() is less precise (in terms of timing granularity), but more accurate if the system if not otherwise idle - since it will report CPU time for the current process instead of total wall clock time, removing the direct contribution of other processes. That said, benchmarks on a loaded system are inaccurate anyway, because of other factors (such as cost of context switching, TLB and cache misses, concurrent memory access from several processes). I think a rule-of-thumb can be made: - for short-running benchmarks (a couple of seconds at most), use time.time() which will give increased precision - for longer-running benchmarks, use time.clock() (or the system's time command) which will avoid counting the runtime of other processes timeit is in the former case. (this is all about Unix, by the way) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective
On Fri, Mar 18, 2011 at 00:23, Terry Reedy tjre...@udel.edu wrote: People should retest their stuff with each micro (bugfix) release anyway. That would be creating an insane burden on library developers. Besides, I've so far not have things break between micro releases, it must be very unusual. That said, when running Python 2.7 with -3 in preparation for a port, you should of course use the latest version, that has the most warnings. //Lennart ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Please retract my committer rights
On Thu, Mar 17, 2011 at 7:28 PM, Terry Reedy tjre...@udel.edu wrote: On 3/17/2011 1:45 PM, Benjamin Peterson wrote: 2011/3/16 Thomas Hellerthel...@ctypes.org: I would like my committer rights to be retracted. I have been contributing to Python here and there for 10 years now, and it was a pleasant experience. Unfortunately, since about a year I have lots more things to do, and I won't be able to contribute anymore (I have not even started to learn mercurial yet). Plus I'm still using 2.6 or even 2.5 with my own Python projects. Thank you very much for you work. We'd always be happy to have you back. In the meanwhile, it would be nice to have another ctypes maintainer, as there are several open issues. There is certainly a opening for a new person with C experience. I'll ask doug hellmann if this is something we can do a blog post about on the PSF blog. Having another ctypes expert is pretty critical (everyone I know is using it) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Please retract my committer rights
On Mar 18, 2011, at 9:59 AM, Jesse Noller wrote: On Thu, Mar 17, 2011 at 7:28 PM, Terry Reedy tjre...@udel.edu wrote: On 3/17/2011 1:45 PM, Benjamin Peterson wrote: 2011/3/16 Thomas Hellerthel...@ctypes.org: I would like my committer rights to be retracted. I have been contributing to Python here and there for 10 years now, and it was a pleasant experience. Unfortunately, since about a year I have lots more things to do, and I won't be able to contribute anymore (I have not even started to learn mercurial yet). Plus I'm still using 2.6 or even 2.5 with my own Python projects. Thank you very much for you work. We'd always be happy to have you back. In the meanwhile, it would be nice to have another ctypes maintainer, as there are several open issues. There is certainly a opening for a new person with C experience. I'll ask doug hellmann if this is something we can do a blog post about on the PSF blog. Having another ctypes expert is pretty critical (everyone I know is using it) This does seem like a good use of the blog. The team is working on setting up the dev blog, and I expect to have something up soon. This can be our second post there (the first being an introduction). Is there a job description for a ctypes maintainer? Where should we send people for more details about this request? We would link to the dev guide and this mailing list, but is there something more specific? Doug ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Please retract my committer rights
On Thu, Mar 17, 2011 at 7:28 PM, Terry Reedy tjre...@udel.edu wrote: .. In the meanwhile, it would be nice to have another ctypes maintainer, as there are several open issues. There is certainly a opening for a new person with C experience. I am not ready to volunteer as maintainer, but if ctypes is not listed as my area of interest, it should be. Unfortunately, since Misc/maintainers.rst is gone, I am not sure how to edit maintainers list. I wonder if someone could replace Misc/maintainers.rst with a short document with the proper link and describing how to edit the list at the new location. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Please retract my committer rights
On Fri, 18 Mar 2011 10:18:06 -0400 Alexander Belopolsky alexander.belopol...@gmail.com wrote: On Thu, Mar 17, 2011 at 7:28 PM, Terry Reedy tjre...@udel.edu wrote: .. In the meanwhile, it would be nice to have another ctypes maintainer, as there are several open issues. There is certainly a opening for a new person with C experience. I am not ready to volunteer as maintainer, but if ctypes is not listed as my area of interest, it should be. Unfortunately, since Misc/maintainers.rst is gone, I am not sure how to edit maintainers list. Just modify experts.rst in http://hg.python.org/devguide/. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Please retract my committer rights
Doug Hellmann wrote: On Mar 18, 2011, at 9:59 AM, Jesse Noller wrote: Terry Reedy wrote: there are several open issues. There is certainly a opening for a new person with C experience. about on the PSF blog. Having another ctypes expert is pretty critical (everyone I know is using it) Is there a job description for a ctypes maintainer? Where should I am the only one who is finding the following phrases amusing?! - opening for a new person - another ctypes expert is pretty critical - job description - send people to.. -- Senthil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg: inter-branch workflow
On Thu, 17 Mar 2011 20:00:29 +0100, Jesus Cea j...@jcea.es wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/03/11 14:45, R. David Murray wrote: Not if the cpython repo is in a fully merged stated. And if it isn't, I will wait until it is. (The update notifications on the IRC channel help with monitoring this.) That is repository serialization. The point of HG is to avoid that :-). I don't think your second sentence is true. *Allowing* non-serialized repositories, yes; but I don't think our desire to have a relatively serialized main repository is somehow anti-mercurial :) We may change our mind at some point, of course. -- R. David Murray www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 395: Module Aliasing
Just now I was trapped by the Importing the main module twice problem for a while, and then I searched on web and go into here. It seems pretty good to fix this problem, since it is really difficult to find out this problem. Anyway, a module should not be initialized twice which results in that each of the objects defined in this module has TWO instances in separate modules. Accidentally people will mix up them together. -- Ray Allen Best wishes! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2011-03-11 - 2011-03-18) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open2723 (+14) closed 20655 (+115) total 23378 (+129) Open issues with patches: 1164 Issues opened (60) == #11452: test_trace not symlink install clean http://bugs.python.org/issue11452 reopened by sdaoden #11468: Improve unittest basic example in the doc http://bugs.python.org/issue11468 opened by ezio.melotti #11469: Fix resource warning in test_trailers http://bugs.python.org/issue11469 opened by brian.curtin.test #11470: Flag inappropriate uses of callable class attributes http://bugs.python.org/issue11470 opened by twouters #11471: If without else generates redundant jump http://bugs.python.org/issue11471 opened by eltoder #11472: upload command fails to read auth information from .pypirc http://bugs.python.org/issue11472 opened by jaraco #11473: upload command no longer accepts repository by section name http://bugs.python.org/issue11473 opened by jaraco #11474: url2pathname() handling of '/C|/' on Windows http://bugs.python.org/issue11474 opened by calvin #11477: Bug in code dispatching based on internal slots http://bugs.python.org/issue11477 opened by terry.reedy #11479: Add discussion of trailing slash in raw string to tutorial http://bugs.python.org/issue11479 opened by r.david.murray #11480: Cannot copy a class with a metaclass other than type http://bugs.python.org/issue11480 opened by durban #11481: The copy module already uses copyreg http://bugs.python.org/issue11481 opened by durban #11485: Default SDK value on MacOSX needs changing http://bugs.python.org/issue11485 opened by ronaldoussoren #11486: Add option to not install into /Applications http://bugs.python.org/issue11486 opened by ronaldoussoren #11487: build_installer.py should avoid relying on a young Python http://bugs.python.org/issue11487 opened by pitrou #11489: json.dumps not parsable by json.loads (on Linux only) http://bugs.python.org/issue11489 opened by Brian.Merrell #11491: dbm.open(..., flag=n) raises dbm.error if file exists and is http://bugs.python.org/issue11491 opened by denversc #11492: email.header.Header doesn't fold headers http://bugs.python.org/issue11492 opened by kitterma #11493: Add python.exe-gdb.py to .hgignore http://bugs.python.org/issue11493 opened by santa4nt #11494: Confusing error message from warnings.warn http://bugs.python.org/issue11494 opened by Gerrit.Holl #11504: test_subprocess failure http://bugs.python.org/issue11504 opened by pitrou #11505: string.py increased test coverage http://bugs.python.org/issue11505 opened by Alicia.Arlen #11506: b'' += gives SystemError instead of SyntaxError http://bugs.python.org/issue11506 opened by ncoghlan #11508: Virtual Interfaces cause uuid._find_mac to raise a ValueError http://bugs.python.org/issue11508 opened by kfrazier #11511: Proposal for exposing proxy bypass settings in ProxyHandler http://bugs.python.org/issue11511 opened by rswilson #11512: adding test suite for cgitb http://bugs.python.org/issue11512 opened by robquad #11513: chained exception/incorrect exception from tarfile.open on a n http://bugs.python.org/issue11513 opened by ev #11549: Rewrite peephole to work on AST http://bugs.python.org/issue11549 opened by eltoder #11551: test_dummy_thread.py test coverage improvement http://bugs.python.org/issue11551 opened by denversc #11552: Confusing error message when hook module cannot be loaded http://bugs.python.org/issue11552 opened by cournape #11553: Docs for: import, packages, site.py, .pth files http://bugs.python.org/issue11553 opened by gwideman #11557: Increase coverage in logging module http://bugs.python.org/issue11557 opened by nessita #11558: Raise a more helpful exception in email.message.Message.attach http://bugs.python.org/issue11558 opened by michael.henry #11561: coverage of Python regrtest cannot see initial import of lib http://bugs.python.org/issue11561 opened by brandon-rhodes #11563: test_urllibnet is triggering a ResourceWarning http://bugs.python.org/issue11563 opened by brett.cannon #11564: pickle not 64-bit ready http://bugs.python.org/issue11564 opened by nyevik #11566: hypot define in pyconfig.h clashes with g++'s cmath http://bugs.python.org/issue11566 opened by schmir #11568: docstring of select.epoll.register() is wrong http://bugs.python.org/issue11568 opened by thekorn #11571: Turtle window pops under the terminal on OSX http://bugs.python.org/issue11571 opened by belopolsky #11572: bring Lib/copy.py to 100% coverage http://bugs.python.org/issue11572 opened by brandon-rhodes #11573: Improve Unicode Documentation with Known Caveats http://bugs.python.org/issue11573 opened by aronacher #11574: Unicode Fallback Encoding on Python 3.3 http://bugs.python.org/issue11574 opened by
Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18/03/11 01:01, Larry Hastings wrote: In 2.7.1 PyCObject_FromVoidPtr() now calls PyErr_WarnPy3k(). This means it's been promoted to throwing DeprecationWarning! But that's also guarded with Py_Py3kWarningFlag so it's not active unless you ask for that too (as with -3 on the command-line, etc). I kind of remember doing this change myself. Since no 2.8 is planned, it seemed sensible to mark PyCObject as a py3k warning. PS: I am the maintainer of (externally developed lib) bsddb, but the 2.7.0 behaviour actually broke some other extensions out there (when used with warnings active). Details in the tracker, somewhere. I am offline now, can't use the browser. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTYOiYplgi5GaxT1NAQLtRgQAjdB1yvFmqJLGqqzEaCK+ll5jx277b751 RGshITBFUkd+OLVErP9nEKUMsHvr/nl7BIjhZotKH31g6Hl0KiuGPHHkPNKYGs4y 5XsHaZ2a9/qkgt1wa12gLsHmxsrIICGKPzcPUQs6GVJGBuppGtDkc18iODOCd6eC kkDcc/sFHUI= =mXiX -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Please retract my committer rights
On 3/18/2011 10:48 AM, Senthil Kumaran wrote: Doug Hellmann wrote: On Mar 18, 2011, at 9:59 AM, Jesse Noller wrote: Terry Reedy wrote: there are several open issues. There is certainly a opening for a new person with C experience. about on the PSF blog. Having another ctypes expert is pretty critical (everyone I know is using it) Is there a job description for a ctypes maintainer? Where should I am the only one who is finding the following phrases amusing?! - opening for a new person - another ctypes expert is pretty critical - job description - send people to.. Sorry, you humor is too subtle for me ;-). I find 42 unattended open ctypes issues a bit sad. IDLE is a bit worse, I think, but I plan on helping to make a dent on *that* in the next year. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Adding function checks to regex
Some of those who are relative new to regexes sometimes ask how to write a regex which checks that a number is in a range or is a valid date. Although this may be possible, it certainly isn't easy. From what I've read, Perl has a way of including code in a regex, but I don't think that's a good idea However, it occurs to me that there may be a case for being able to call a supplied function to perform such checking. Borrowing some syntax from Perl, it could look like this: def range_check(m): return 1 = int(m.group()) = 10 numbers = regex.findall(r\b\d+\b(*CALL), text, call=range_check) The regex module would match as normal until the (*CALL), at which point it would call the function. If the function returns True, the matching continues (and succeeds); if the function returns False, the matching backtracks (and fails). The function would be passed a match object. An extension, again borrowing the syntax from Perl, could include a tag like this: numbers = regex.findall(r\b\d+\b(*CALL:RANGE), text, call=range_check) The tag would be passed to the function so that it could support multiple checks. Alternatively, a tag could always be passed; if no tag is provided then None would be passed instead. There's also the additional possibility of providing a dict of functions instead and using the tag to select the function which should be called. I'd be interested in your opinions. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Please retract my committer rights
On 3/18/2011 10:17 AM, Doug Hellmann wrote: Is there a job description for a ctypes maintainer? I would say a knowledge of C and C implementations, a tolerance of OS idiosyncrasies, and an interest bridging C to Python and in particular the way ctpes does it. (I intentionally omitted general Python knowledge.) Where should we send people for more details about this request? The tracker: http://bugs.python.org/issue?@template=searchstatus=1 select Components: ctypes, enter, and take a look at some of the 42 (at the moment) issues. Or, also select Keyword: patch (17 issues now) to look at and possibly review some of the existing patches. For more help, post here. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
On Fri, Mar 18, 2011 at 1:38 PM, Guido van Rossum gu...@python.org wrote: But seriously, I think an additional function or additional flag in the current functions/method in the parse module is sufficient than going for another module. I vote for a new function, not a flag. (Others can explain my rule of thumb against flag arguments whose values are nearly always constants.) When I was last tinkering with this (i.e. when I wrote that proof of concept module for a fully RFC 3986 compliant parser), I actually replaced the urljoin name with resolve_uriref. So a minimal change to provide at least RFC 3986 joining semantics would be to add a resolve_uriref that provides the RFC 3986 join semantics, while urljoin would continue to follow the older RFCs. There are additional niceties in RFC 3986 that it would be good to provide, but that's when you start to get to the scale of a completely new URI parsing module. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective
On 03/18/2011 11:20 AM, Jesus Cea wrote: I kind of remember doing this change myself. Since no 2.8 is planned, it seemed sensible to mark PyCObject as a py3k warning. It's all fine by me, and yeah I think you did the change. I'm sure it wasn't me. PS: I am the maintainer of (externally developed lib) bsddb, but the 2.7.0 behaviour actually broke some other extensions out there (when used with warnings active). Details in the tracker, somewhere. I am offline now, can't use the browser. My point in bringing up bsddb was that it was the only remaining use of CObject that shipped with Python 2.7. Yes, certainly there were externally-maintained extensions that went to pieces when PyCObject_FromVoidPtr() started returning NULL. But internally, 2.7 switched entirely to capsules, except for bsddb. Cheers, /larry/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding function checks to regex
Probably best discussed on python-ideas... On Fri, Mar 18, 2011 at 4:04 PM, MRAB pyt...@mrabarnett.plus.com wrote: Some of those who are relative new to regexes sometimes ask how to write a regex which checks that a number is in a range or is a valid date. Although this may be possible, it certainly isn't easy. From what I've read, Perl has a way of including code in a regex, but I don't think that's a good idea However, it occurs to me that there may be a case for being able to call a supplied function to perform such checking. Borrowing some syntax from Perl, it could look like this: def range_check(m): return 1 = int(m.group()) = 10 numbers = regex.findall(r\b\d+\b(*CALL), text, call=range_check) The regex module would match as normal until the (*CALL), at which point it would call the function. If the function returns True, the matching continues (and succeeds); if the function returns False, the matching backtracks (and fails). The function would be passed a match object. An extension, again borrowing the syntax from Perl, could include a tag like this: numbers = regex.findall(r\b\d+\b(*CALL:RANGE), text, call=range_check) The tag would be passed to the function so that it could support multiple checks. Alternatively, a tag could always be passed; if no tag is provided then None would be passed instead. There's also the additional possibility of providing a dict of functions instead and using the tag to select the function which should be called. I'd be interested in your opinions. ___ Python-Dev mailing list Python-Dev@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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
On Fri, Mar 18, 2011 at 5:32 PM, Nick Coghlan ncogh...@gmail.com wrote: On Fri, Mar 18, 2011 at 1:38 PM, Guido van Rossum gu...@python.org wrote: But seriously, I think an additional function or additional flag in the current functions/method in the parse module is sufficient than going for another module. I vote for a new function, not a flag. (Others can explain my rule of thumb against flag arguments whose values are nearly always constants.) When I was last tinkering with this (i.e. when I wrote that proof of concept module for a fully RFC 3986 compliant parser), I actually replaced the urljoin name with resolve_uriref. So a minimal change to provide at least RFC 3986 joining semantics would be to add a resolve_uriref that provides the RFC 3986 join semantics, while urljoin would continue to follow the older RFCs. It's a bit long though -- users tend to flock to the shorter name. There are additional niceties in RFC 3986 that it would be good to provide, but that's when you start to get to the scale of a completely new URI parsing module. Really. Do they still call them URIs? :-) -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
On Mar 18, 2011, at 8:41 PM, Guido van Rossum wrote: Really. Do they still call them URIs? :-) Well, by RFC 398*7* they're calling them IRIs instead. 'irilib', perhaps? ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
On Fri, Mar 18, 2011 at 08:57:42PM -0400, Glyph Lefkowitz wrote: Well, by RFC 398*7* they're calling them IRIs instead. 'irilib', perhaps? ;-) Yes, and it involves huge lot of unicode character handling /parsing rules in Resource Indentifiers. 'irilib' sounds like a good plan. -- Senthil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg: inter-branch workflow
On Fri, Mar 18, 2011 at 5:00 AM, Jesus Cea j...@jcea.es wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/03/11 14:45, R. David Murray wrote: Not if the cpython repo is in a fully merged stated. And if it isn't, I will wait until it is. (The update notifications on the IRC channel help with monitoring this.) That is repository serialization. The point of HG is to avoid that :-). The easier merging in Hg means that it *is* easy to work offline, or even against separate clones. Trying to keep a clean history in the main repository so committer responsibilities are tracked correctly is still a reasonable goal. Moreover, you are supposing that the original committer will merge soon. What may actually be better for buildbot experimentation purposes is to allow us to request running a build-and-test cycle from branches in *any* of the repositories hosted on hg.python.org, rather than having to push experimental changes to the main line of development. (i.e. start moving towards more of a style of development where code doesn't land in the main repository until it has been vetted by the buildbots *first*). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Module version variable
Tres Seaver wrote: I'm not even sure why you would want __version__ in 99% of modules: in the ordinary cases, a module's version should be either the Python version (for a module shipped in the stdlib), or the release of the distribution which shipped it. It's useful to be able to find out the version of a module you're using at run time so you can cope with API changes. I had a case just recently where the behaviour of something in pywin32 changed between one release and the next. I looked for an attribute called 'version' or something similar to test, but couldn't find anything. +1 on having a standard place to look for version info. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Module version variable
On Fri, Mar 18, 2011 at 7:28 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Tres Seaver wrote: I'm not even sure why you would want __version__ in 99% of modules: in the ordinary cases, a module's version should be either the Python version (for a module shipped in the stdlib), or the release of the distribution which shipped it. It's useful to be able to find out the version of a module you're using at run time so you can cope with API changes. I had a case just recently where the behaviour of something in pywin32 changed between one release and the next. I looked for an attribute called 'version' or something similar to test, but couldn't find anything. +1 on having a standard place to look for version info. I believe __version__ *is* the standard (like __author__). IIRC it was proposed by Ping. I think this convention is so old that there isn't a PEP for it. So yes, we might as well write it down. But it's really nothing new. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective
On Fri, Mar 18, 2011 at 1:04 AM, Guido van Rossum gu...@python.org wrote: I don't want to be alarmist and I don't want to start another moratorium, but I do think that we need to be aware of people coming in sideways into Python 3 and missing the nice deprecations. So let's be conservative with deprecations in the Python 3 line for now. Adding new deprecations is probably OK, but we should definitely be very cautious about following through with *removal* of deprecated items. I was pondering the specific case of PyCapsule on the way home, and it actually took quite a series of events for it to blow up in Lennart's face the way it did at the sprints: 1. We really should have made a PEP about it at the time, but that didn't occur to anyone involved in the decision (I have vague recollections of contributing to those discussions, so I suspect a piece of the blame for that ends up in my own lap). 2. I believe PyCObject jumped directly from a PendingDeprecationWarning in 3.1 to removal in 3.2. That would have been less likely if we'd written a PEP to clearly spell out the deprecation timeline. 3. For whatever reason, nobody objected to the removal during post hoc python-checkins review. (While that manual filter catches a lot of mistakes, things can definitely slip through). 4. Anyone testing C extensions against the 3.2 alpha and beta releases must have either not used the PyCObject API in the first place, or else had already ported their code to use the PyCapsule API as necessary. 5. The parallel evolution of the 2.x and 3.x line meant that the first version of 2.x with the relevant warning was released only ~7 months or so before the version of 3.2 where the API was removed Backfilling with an after-the-fact PEP (as Larry now plans to do) will help make sure this particular change is less likely to come as a nasty surprise to anyone else, and will provide concrete porting advice for those that need to maintain compatibility with older Python versions that only offer the PyCObject API. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Please retract my committer rights
On Sat, Mar 19, 2011 at 12:48 AM, Senthil Kumaran orsent...@gmail.com wrote: I am the only one who is finding the following phrases amusing?! - opening for a new person - another ctypes expert is pretty critical - job description - send people to.. Come join python-dev - we have plenty of jobs that need filling, but we won't offer to pay you for any of them! :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Please retract my committer rights
On Thu, Mar 17, 2011 at 5:44 AM, Raymond Hettinger raymond.hettin...@gmail.com wrote: You will be missed. Thanks for all your efforts. Indeed! Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Please retract my committer rights
Hello Will it be okay to make you nosy on a bug report to ask for an expert opinion when the current developers need it? If yes, I’ll mark your name as “retired” in the experts file, if not I’ll remove it. Thanks for your contributions, and have fun in your next adventures! [Alexander] Unfortunately, since Misc/maintainers.rst is gone, I am not sure how to edit maintainers list. I wonder if someone could replace Misc/maintainers.rst with a short document with the proper link and describing how to edit the list at the new location. I’ve added a notice in 2.7 and 3.1, but the file is just gone in 3.2+. Is adding a note to Misc/README about the removals worth it? Regards ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Module version variable
On Fri, Mar 18, 2011 at 07:40:43PM -0700, Guido van Rossum wrote: On Fri, Mar 18, 2011 at 7:28 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Tres Seaver wrote: I'm not even sure why you would want __version__ in 99% of modules: in the ordinary cases, a module's version should be either the Python version (for a module shipped in the stdlib), or the release of the distribution which shipped it. It's useful to be able to find out the version of a module you're using at run time so you can cope with API changes. I had a case just recently where the behaviour of something in pywin32 changed between one release and the next. I looked for an attribute called 'version' or something similar to test, but couldn't find anything. +1 on having a standard place to look for version info. I believe __version__ *is* the standard (like __author__). IIRC it was proposed by Ping. I think this convention is so old that there isn't a PEP for it. So yes, we might as well write it down. But it's really nothing new. There is a section in PEP8 about __version__ but it serves a slightly different purpose there: Version Bookkeeping If you have to have Subversion, CVS, or RCS crud in your source file, do it as follows. __version__ = $Revision: 88433 $ # $Source$ These lines should be included after the module's docstring, before any other code, separated by a blank line above and below. Personally, I've never found a need to access the repository revision programatically from my pyhon applications but I have needed to access the API version so it would make sense to me to change the meaning of __version__. -Toshio pgpr66xyWCYYt.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg: inter-branch workflow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19/03/11 03:14, Nick Coghlan wrote: What may actually be better for buildbot experimentation purposes is to allow us to request running a build-and-test cycle from branches in *any* of the repositories hosted on hg.python.org, rather than having to push experimental changes to the main line of development. (i.e. start moving towards more of a style of development where code doesn't land in the main repository until it has been vetted by the buildbots *first*). This is a good suggestion. I kind of remember that when working in SVN you could request a particular build from a particular branch. If that was true, we should consider something similar with mercurial. I am offline and can't check, thought. In fact I am thinking about being able to push a patch to the buildbots and, if the patch applies cleanly to the branch tip, actually apply it, build test. That would be amazing, security aside :). - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTYQhWJlgi5GaxT1NAQJ23AP/dn2lqXgxeoYgsAZklkDR2hLqHJzYs8PT Y38sGpeUdDmJQ/k+vISUtlNsshLRDc7o88cL95wy1j10QNPSL43ehfz3+W6anAvB 6ELpvTePT/0rJzTcWQVgXSwAu50am4z9rcV7r2Q7EluLCKg3azXcARoCMFSZ/8Wp vMgbAGe3pwk= =5LvY -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] VM and Language summit info for those not at Pycon (and those that are!)
The short summary is that the Parrot VM is a very good semantic fit for Python (AFAICT, a better fit than it is for Perl 6, though I haven't done the feature-by-feature comparison). Thanks for the write-up. The point quoted above is especially useful, since I vaguely remembered reading that Parrot was not suited to Python’s semantics but now stand corrected. Regards ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg: inter-branch workflow
On Sat, Mar 19, 2011 at 1:22 PM, Jesus Cea j...@jcea.es wrote: This is a good suggestion. I kind of remember that when working in SVN you could request a particular build from a particular branch. If that was true, we should consider something similar with mercurial. I am offline and can't check, thought. In fact I am thinking about being able to push a patch to the buildbots and, if the patch applies cleanly to the branch tip, actually apply it, build test. That would be amazing, security aside :). Given how easy Antoine (I think) made it for us to create server side clones on hg.python.org, making a new clone, pushing a change to it over ssh, then triggering a build, would be almost as nice, but with the security of requiring registered public SSH keys on the server. I did just poke around on the buildbot pages, but couldn't find anything resembling the old buiild a branch form. MvL/Antoine/Georg, any ideas? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg: inter-branch workflow
I did just poke around on the buildbot pages, but couldn't find anything resembling the old buiild a branch form. MvL/Antoine/Georg, any ideas? Kelsey Hightower is already working on it. There is the buildbot 'try' feature, but there may be other options as well. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] VM and Language summit info for those not at Pycon (and those that are!)
On Sat, Mar 12, 2011 at 06:43, Nick Coghlan ncogh...@gmail.com wrote: I posted my rough notes and additional write-ups for Wednesday's VM summit and Thursday's language summit: http://www.boredomandlaziness.org/2011/03/python-vm-summit-rough-notes.html http://www.boredomandlaziness.org/2011/03/python-vm-summit-somewhat-coherent.html http://www.boredomandlaziness.org/2011/03/python-language-summit-rough-notes.html http://www.boredomandlaziness.org/2011/03/python-language-summit-highlights.html I believe Brian Curtin will also be posting a write-up for Thursday, but I don't know if that is online anywhere yet. I still owe a write-up from my 5 pages of notes, but being too busy to write it during PyCon might have a benefit: it's ammunition for the newly created dev blog that Doug got setup today. Just wanted to put that out there. I didn't forget! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Module version variable
On Fri, Mar 18, 2011 at 8:12 PM, Toshio Kuratomi a.bad...@gmail.com wrote: On Fri, Mar 18, 2011 at 07:40:43PM -0700, Guido van Rossum wrote: On Fri, Mar 18, 2011 at 7:28 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Tres Seaver wrote: I'm not even sure why you would want __version__ in 99% of modules: in the ordinary cases, a module's version should be either the Python version (for a module shipped in the stdlib), or the release of the distribution which shipped it. It's useful to be able to find out the version of a module you're using at run time so you can cope with API changes. I had a case just recently where the behaviour of something in pywin32 changed between one release and the next. I looked for an attribute called 'version' or something similar to test, but couldn't find anything. +1 on having a standard place to look for version info. I believe __version__ *is* the standard (like __author__). IIRC it was proposed by Ping. I think this convention is so old that there isn't a PEP for it. So yes, we might as well write it down. But it's really nothing new. There is a section in PEP8 about __version__ but it serves a slightly different purpose there: Version Bookkeeping If you have to have Subversion, CVS, or RCS crud in your source file, do it as follows. __version__ = $Revision: 88433 $ # $Source$ These lines should be included after the module's docstring, before any other code, separated by a blank line above and below. Ah, hm. Yes, that's way outdated. I don't think anyone believe in marking each file with its revision any more. I do distinctly recall __version__ being standardized for other purposes too, but I have no idea how to find that reference... It probably was well before 2000. Personally, I've never found a need to access the repository revision programatically from my pyhon applications but I have needed to access the API version so it would make sense to me to change the meaning of __version__. Agreed. I don't think that was the only allowed use of __version__ -- just the only mentioned use. (Note the conditional If you have to have Subversion, ... at the start of that paragraph in PEP 8.) -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] Daily reference leaks (979ae5972604): sum=30
The timing of these new refleaks being triggered by test_os and by test_posix is suspicious, making me think that #10812 is the likely culprit. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
