Re: [Python-Dev] We should be using a tool for code reviews
Georg Brandl g.bra...@gmx.net writes: Am 30.09.2010 10:22, schrieb Dirkjan Ochtman: On Wed, Sep 29, 2010 at 20:32, Guido van Rossum gu...@python.org wrote: I would like to recommend that the Python core developers start using a code review tool such as Rietveld or Reviewboard. I don't really care which tool we use (I'm sure there are plenty of pros and cons to each) but I do think we should get out of the stone age and start using a tool for the majority of our code reviews. Rambling thoughts about some of the things mentioned in this thread. I think hg-review looks interesting, though it may not (yet) have the level of sophistication of Rietveld. (Public test instance at http://review.stevelosh.com/.) It might be interesting to integrate Rietveld uploads in a Mercurial extension, particularly if it gets integrated with mq somehow. That would be totally awesome! The Go (the language) project has a Mercurial extension that integrates Rietveld. It seems to provide a few commands for both directions: uploading changelists to a review server and for the reviewer downloading from the server and applying the changelists to a working copy. I never used this extension myself so I can't tell anything about the workflow introduced by these commands. The sources for this extension are here: http://code.google.com/p/go/source/browse/lib/codereview/codereview.py Andi 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] Celebrating issue #10000
On Fri, Oct 1, 2010 at 1:50 AM, Martin v. Löwis mar...@v.loewis.de wrote: Amaury just filed issue #1 yesterday; as counting started with 1000, we are now into 9000 roundup issues. Happy birthday, bugs ! :) ___ 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] Branching without losing your build products [was: We should be using a tool for code reviews]
On Oct 01, 2010, at 01:09 PM, Stephen J. Turnbull wrote: Barry Warsaw writes: I should note that I don't particularly like colocated/named branches. I personally much prefer separate directories for each feature or bug I'm working on. It helps me keep track of what I'm doing. I have a fast machine so recompiling all of Python is no big deal. Note that once you have a branch with all of Python built, for any of hg, git, bzr you may prefer to clone the branch/repo with cp -r or rsync rather than $VCS clone. The reason for doing it with $VCS clone is to get a pristine workspace without any cruft like editor backups or build products. If you *want* a crufty workspace (and in this case some people do), a recursive copy is a better tool. Yep, absolutely agree. I also use 'cp -a' or 'rsync -avz' when I want that crufty workspace transfered to another (local) machine. In general though, when I'm working on feature or bug branches, I want a pristine working directory. -Barry signature.asc 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] Celebrating issue #10000
On Oct 01, 2010, at 01:50 AM, Martin v. Löwis wrote: Amaury just filed issue #1 yesterday; as counting started with 1000, we are now into 9000 roundup issues. I have become quite fond of roundup over the years, and would like to thank Ka-Ping Yee, Richard Jones, and Erik Forsberg for getting us here. There are many contributions to this infrastructure, both from individuals and software projects, but I'd like to single out two of them which have I also appreciate very much: the folks at Upfront Hosting have helped a lot to keep the system running, and the PostgreSQL database has really validated it's own claim of being the world's most advanced open source database. Agreed! Roundup has been a joy to use. Martin is to be profusely thanked too for all of his ongoing work on our python.org resources. -Barry signature.asc 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
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2010-09-24 - 2010-10-01) 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 stats: open2548 (+45) closed 19241 (+50) total 21789 (+67) Open issues with patches: 1072 Issues opened (45) == #9899: tkinter test_font fails on OS X with Aqua Tk http://bugs.python.org/issue9899 reopened by pitrou #9941: Unify trace and profile interfaces http://bugs.python.org/issue9941 opened by belopolsky #9942: Allow memory sections to be OS MERGEABLE http://bugs.python.org/issue9942 opened by hunteke #9943: TypeError message became less helpful in Python 2.7 http://bugs.python.org/issue9943 opened by gjb1002 #9948: findCaller is slow and loses case information on Windows http://bugs.python.org/issue9948 opened by aronacher #9949: os.path.realpath on Windows does not follow symbolic links http://bugs.python.org/issue9949 opened by stutzbach #9951: introduce bytes.hex method http://bugs.python.org/issue9951 opened by wiggin15 #9955: multiprocessing.Pipe segmentation fault when recv of unpicklab http://bugs.python.org/issue9955 opened by Zbynek.Winkler #9957: SpooledTemporayFile.truncate should take size parameter http://bugs.python.org/issue9957 opened by rfk #9960: test_structmembers fails on s390x (bigendian 64-bit): int/Py_s http://bugs.python.org/issue9960 opened by dmalcolm #9962: GzipFile doesn't have peek() http://bugs.python.org/issue9962 opened by pitrou #9964: Test failures with -OO http://bugs.python.org/issue9964 opened by michael.foord #9965: Loading malicious pickle may cause excessive memory usage http://bugs.python.org/issue9965 opened by alexandre.vassalotti #9967: encoded_word regular expression in email.header.decode_header( http://bugs.python.org/issue9967 opened by tkikuchi #9968: Let cgi.FieldStorage have named uploaded file http://bugs.python.org/issue9968 opened by phep #9969: tokenize: add support for tokenizing 'str' objects http://bugs.python.org/issue9969 opened by meador.inge #9971: Optimize BufferedReader.readinto http://bugs.python.org/issue9971 opened by stutzbach #9972: PyGILState_XXX missing in Python builds without threads http://bugs.python.org/issue9972 opened by dalcinl #9973: Sometimes buildbot fails to cleanup working copy http://bugs.python.org/issue9973 opened by ocean-city #9974: tokenizer.untokenize not invariant with line continuations http://bugs.python.org/issue9974 opened by Brian.Bossé #9975: Incorrect use of flowinfo and scope_id in IPv6 sockaddr tuple http://bugs.python.org/issue9975 opened by vnebehaj #9976: Make TestCase._formatMessage public http://bugs.python.org/issue9976 opened by mattheww #9977: TestCase.assertItemsEqual's description of differences http://bugs.python.org/issue9977 opened by mattheww #9978: test_os failures on XP-4 buildbot http://bugs.python.org/issue9978 opened by pitrou #9980: str(float) failure http://bugs.python.org/issue9980 opened by Kiriakos.Vlahos #9981: let make_buildinfo use a temporary directory on windows http://bugs.python.org/issue9981 opened by krisvale #9985: difflib.SequenceMatcher has slightly buggy and undocumented ca http://bugs.python.org/issue9985 opened by marienz #9986: PDF files of python docs have text missing http://bugs.python.org/issue9986 opened by amberj #9988: test_warnings fails with PYTHONFSENCODING=latin-1 on UNIX/BSD http://bugs.python.org/issue9988 opened by haypo #9989: ctypes bitfield problem http://bugs.python.org/issue9989 opened by stutzbach #9990: PyMemoryView_FromObject alters the Py_buffer after calling PyO http://bugs.python.org/issue9990 opened by kermode #9991: xmlrpc client ssl check faulty http://bugs.python.org/issue9991 opened by jniehof #9992: Command line arguments are not correctly decodedif localeand http://bugs.python.org/issue9992 opened by haypo #9993: shutil.move fails on symlink source http://bugs.python.org/issue9993 opened by jniehof #9995: setup.py register sdist upload requires pass to be saved http://bugs.python.org/issue9995 opened by techtonik #9996: binascii should convert unicode strings http://bugs.python.org/issue9996 opened by wiggin15 #9997: function named 'top' gets unexpected namespace/scope behaviour http://bugs.python.org/issue9997 opened by iivvoo #9998: find_library should search LD_LIBRARY_PATH on linux http://bugs.python.org/issue9998 opened by jniehof #: test_shutil cross-file-system tests are fragile (may not test http://bugs.python.org/issue opened by r.david.murray #1: mark more tests as CPython specific http://bugs.python.org/issue1 opened by amaury.forgeotdarc #10001: ~Py_buffer.obj field is undocumented, though not hidden http://bugs.python.org/issue10001 opened by kermode #10002: Installer doesn't install on Windows Server 2008 DataCenter R2 http://bugs.python.org/issue10002 opened by joblack #10003:
Re: [Python-Dev] We should be using a tool for code reviews
On Sep 30, 2010, at 01:46 PM, Brett Cannon wrote: Once we have a good workflow in place we would have to start shifting our development culture towards requiring a review of code no matter who the author is (which I support doing). I should note one other thing, in reference to my previous posting about reviews. Launchpad does have a backdoor for getting changes in without formal review. It's called rubber stamping and shows up in commit messages, e.g.: $VCS commit -m[rs=me] Fix trivial misspelling in comment You can also get a rubber stamp from a reviewer: Alice: can you review my branch that fixes all incorrect uses of it's? Bob: If that's your only change, I trust you. rs=me Alice: $VCS commit -m[rs=bob] The Grammar Nanny strikes again Usually rubber stamps are reserved for cases where the fix really is trivial, or a change is large but mechanical, or when no reviewer can be found for a time-sensitive fix (very rare). You at least need to record the rubber stamp in the commit message, and be prepared to defend it if it trips up someone's post-commit eyeball filter. -Barry signature.asc 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] We should be using a tool for code reviews
On Fri, Oct 1, 2010 at 12:31 PM, Barry Warsaw ba...@python.org wrote: I should note one other thing, in reference to my previous posting about reviews. Launchpad does have a backdoor for getting changes in without formal review. It's called rubber stamping and shows up in commit messages, This makes a lot of sense; having to branch get spelling corrections in docs or comments would be a *huge* pain, and not provide value. -Fred -- Fred L. Drake, Jr. fdrake at acm.org A storm broke loose in my mind. --Albert Einstein ___ 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] PPC Leopard build slave going down for an upgrade
I'm replacing the PPC Leopard build slave with a dual 2GHz G5 machine... Bill ___ 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] Problems with hex-conversion functions
Hello again. I submitted two patches to resolve the issues from my first post. Patch 9951 - implement bytes.hex (http://bugs.python.org/issue9951) Patch 9996 - fix input and output of binascii functions ( http://bugs.python.org/issue9996) Fix #1 - patch 9951 implements bytes.hex Fix #2 - this is not fixed for now, no deprecation Fix #3 - this is not fixed for now. I will probably submit another patch if patch 9996 is accepted (create shared conversion functions to be used by both binascii and bytes, maybe) Fix #4 - patch 9996 makes binascii behave correctly in this conversion Fix #5 - same as #4 (strict input and output) As you can see, patch 9996 was rejected and I was referred to this mailing list to continue the discussion. I would like to hear your thoughts about the backward compatibility issue in patch 9996, and getting patch 9951 commited. Thanks. On Fri, Sep 24, 2010 at 12:04 AM, Nick Coghlan ncogh...@gmail.com wrote: On Thu, Sep 23, 2010 at 7:31 PM, Ender Wiggin wiggi...@gmail.com wrote: Sorry for the late reply. I would really like to see this fixed. Or we [...] deprecate binascii.(un)hexlify(). ... binascii is the legacy approach here, so if anything was to go, those functions would be it ... I'm not entirely convinced binascii is the legacy approach. What makes this module legacy? Because the binascii functions predate the bytes type, and we added the bytes methods knowing full well that the hexlify/unhexlify functions already existed. On the contrary, I'm pretty sure modularity is better than sticking all the functionality in the core. As was written in this issue: http://psf.upfronthosting.co.za/roundup/tracker/issue3532 If you wanted to produce base-85 (say), then you can extend the functionality of bytes by providing a function that does that, whereas you can't extend the existing bytes type. This example shows that hex is actually getting a special treatment by having builtin methods associated with the bytes type. Why don't we add .base64 methods? Or even .zlib? After all, these options were present in Python 2.x using the encode method of string. In my opinion, having modules to deal with these types of conversions is better, and this is why I suggested sticking to binascii. This *is* a matter of opinion, but python-dev's collective opinion was already expressed in the decision to include these methods in the bytes API. Base 16 *is* given special treatment by many parts of Python, precisely because it *is* special: it's the most convenient way to express binary numbers in a vaguely human readable format. No other coding even comes close to that level of importance in computer science. If no one else is willing to do it (that would be a little disappoiting) Why would it be disappointing? While it's untidy, nothing's actually broken and there are ways for programmers to do everything they want to do. I (and many others here) already have a pretty long list of things I'd like to improve/fix but haven't got around to yet, so it isn't uncommon for things to have to wait awhile before someone looks at them. As Terry said though, there *are* ways to expedite that process (In this case, providing a patch that adds a .hex method in accordance with PEP 358, or, as a more ambitious, extensible alternative, consider updating the hex builtin to support the PEP 3118 API, which would allow it to automatically provide a hex dump of any object that exposes a view of a contiguous sequence of data bytes). 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
[Python-Dev] We should be using a tool for code reviews
Sorry I am not replying to the original thread with the same name. I've been working on an HG extension for helping with Rietveld code reviews. The main reason is so that Rietveld can remember state (what issue id is being used) and handle the uploading and downloading to Rietveld. The version I wrote is a little primitive and was written before I fully understood how to use HG. At any rate, I would be interested in participating in creating an hg-codereview extension. -- - Rafe ___ 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] r85152 - tracker/instances/python-dev/config.ini.template
2010/10/1 martin.v.loewis python-check...@python.org: Author: martin.v.loewis Date: Sat Oct 2 00:57:26 2010 New Revision: 85152 Log: Add django settings to template. Modified: tracker/instances/python-dev/config.ini.template Modified: tracker/instances/python-dev/config.ini.template == --- tracker/instances/python-dev/config.ini.template (original) +++ tracker/instances/python-dev/config.ini.template Sat Oct 2 00:57:26 2010 @@ -381,3 +381,7 @@ # each recipient as a CC address. # Default: single email_sending = multiple + +[django] +# generate on a per-instance basis +secret_key = 'e...@4s$*(idwm5-87teftxlksckmy8$tyo7(tm!n-5x)zeuheex' I assume the secrecy of this is rather irrelevant? -- Regards, Benjamin ___ 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] issue 9807 - a glitch in coexisting builds of different types
I am continuing my quest to be able to install multiple versions and builds of Python simultaneously, so that they all nicely coexist. E.g. you could have a normal build of Python 3.2 and a --with-wide-unicode --with-pydebug build both installed and all packages with extensions would get built and loaded for the proper binary, etc. (Caveat: I'm only intending to do the following work for configure-based builds.) I'm tracking most of this work in this bug: http://bugs.python.org/issue9807 I have a Bazaar branch from py3k which is pretty close to working, and I've put my work so far up for review on Rietveld (see the bug comments for details). I've hit a snag though and I'm not sure what the best way out is. I'm hoping one of you have some better ideas. First, let me set up the scenario. Let's say I build py3k like this: % ./configure --prefix=/tmp/python make altinstall % make distclean % ./configure --prefix=/tmp/python --with-wide-unicode --with-pydebug \ make altinstall With my branch, you'll end up with this in /tmp/python: bin/python3.2m - the normal build binary bin/python3.2dmu - the wide+pydebug build binary bin/python3.2m-config bin/python3.2dmu-config ... lib/libpython3.2.so.1.0.m lib/libpython3.2.so.1.0.dmum lib/python3.2m/config/Makefile lib/python3.2dmu/config/Makefile ... include/python3.2m/pyconfig.h include/python3.2dmu/pyconfig.h and of course lots more. This essentially segregates the build-specific bits and pieces according to the $SOABI_QUALIFIER flags (build-flags) calculated in the configure script. This, along with the work for PEP 3149 gives us very nice coexistence without too much duplication. I.e. lib/python3.2/site-packages/foo-0.0-py3.2-plat.egg can contain a shared .py file for all the builds, and .so files with PEP 3149 tags that distinguish between the various build flags. Ah, but now here's the problem I'm stuck on. Let's say I build the foo module, which has an _foo extension for both the 3.2m and 3.2dmu builds. Everything gets installed correctly, and you'll see: lib/python3.2/site-packages/foo-...egg/_foo.cpython-32m.so lib/python3.2/site-packages/foo-...egg/_foo.cpython-32dmu.so If you now run bin/python3.2dmu and try to import _foo, the right thing happens (foreshadowing) assuming that the directory listing for the foo.egg is alphabetical. But what happens if you run bin/python3.2m and import _foo? Yeah, well, even though there's a _foo.cpython-32m.so sitting right there waiting for you to load it, what actually happens is that Python tries to dynload _foo.cpython-32dmu.so and crashes miserably. Why did it do that? The reason is that the import.c logic that uses the struct filedescr tables built from _PyImport_DynLoadFiletab are just not smart enough to handle this case. All it knows about are suffix, and for backwards compatibility, we have dynload_shlib.c matching both .SOABI.so *and* bare .so. So when it's searching the directories for .cpython-32m.so files, it finds the .cpython-32dmu.so first based on the bare .so match. I can think of a couple of ways out, none of which are totally satisfying. Probably the easiest out is to change the PEP 3149 naming so that the files don't end in .so. E.g. use this instead: foo.cpython-32dmu-so foo.cpython-32m-so or similar. I think that'd be a fairly straightforward change, but it might break some useful assumptions (we'd still fall back to .so of course). Other ideas: - make import.c smarter so that you can match against other than just the suffix. probably a lot of work. - extend struct filedescr to add callbacks into dynload_shlib.c for file matching. this callback would reject .SOABI.so files where the SOABI doesn't match. again a lot of work and more expensive due to tests more complicated than simple strcmps. - scan filesystem for .SOABI.so before .so. you lose locality of reference and probably has lots of other really nasty semantic disturbances. ;) - remove match on bare .so. not good for non-distutils based build processes. Do you have any other ideas? If not, what would your preference from the above be? Right now I think I'd go with changing the PEP 3149 naming scheme to not end in .so (i.e. option #1). Cheers, -Barry signature.asc 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] issue 9807 - a glitch in coexisting builds of different types
On Fri, 1 Oct 2010 20:06:57 -0400
Barry Warsaw ba...@python.org wrote:
With my branch, you'll end up with this in /tmp/python:
bin/python3.2m - the normal build binary
bin/python3.2dmu - the wide+pydebug build binary
bin/python3.2m-config
bin/python3.2dmu-config
Do users really want to see such idiosyncratic suffixes?
...
lib/libpython3.2.so.1.0.m
lib/libpython3.2.so.1.0.dmum
Ditto here. This seems to break well-known conventions.
If I look at /usr/lib{,64} on my machine, I can't see a single
shared libary file that ends neither in .so nor .so.some digits.
Before trying to find a solution to your problem, I think it would be
nice to get a consensus that this is really a desired feature.
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] issue 9807 - a glitch in coexisting builds of different types
On Oct 02, 2010, at 02:24 AM, Antoine Pitrou wrote:
On Fri, 1 Oct 2010 20:06:57 -0400
Barry Warsaw ba...@python.org wrote:
With my branch, you'll end up with this in /tmp/python:
bin/python3.2m - the normal build binary
bin/python3.2dmu - the wide+pydebug build binary
bin/python3.2m-config
bin/python3.2dmu-config
Do users really want to see such idiosyncratic suffixes?
Do note that make install will symlink all that away, so you'll still end up
with a single python3 and python3-config pointing to the last one you
installed.
...
lib/libpython3.2.so.1.0.m
lib/libpython3.2.so.1.0.dmum
Ditto here. This seems to break well-known conventions.
If I look at /usr/lib{,64} on my machine, I can't see a single
shared libary file that ends neither in .so nor .so.some digits.
Before trying to find a solution to your problem, I think it would be
nice to get a consensus that this is really a desired feature.
-Barry
signature.asc
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] issue 9807 - a glitch in coexisting builds of different types
2010/10/1 Barry Warsaw ba...@python.org: I can think of a couple of ways out, none of which are totally satisfying. Probably the easiest out is to change the PEP 3149 naming so that the files don't end in .so. E.g. use this instead: foo.cpython-32dmu-so foo.cpython-32m-so -1 Doesn't that break not only Python's convention for extensions on shared modules but also any *nix shared object? or similar. I think that'd be a fairly straightforward change, but it might break some useful assumptions (we'd still fall back to .so of course). Other ideas: - make import.c smarter so that you can match against other than just the suffix. probably a lot of work. Although it would be more work, I think this is the most correct option. -- Regards, Benjamin ___ 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
