Re: [Python-Dev] Celebrating issue #10000
On Fri, Oct 1, 2010 at 1: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. > Happy birthday, bugs ! :) ___ Python-Dev mailing list [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 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. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] 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 [email protected] 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 wrote: > On Thu, Sep 23, 2010 at 7:31 PM, Ender Wiggin 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 | [email protected] | Brisbane, Australia > ___ Python-Dev mailing list [email protected] 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 [email protected] 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 : > 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 [email protected] 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 [email protected] 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 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.".
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
[email protected]
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 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.".
>
>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
[email protected]
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 : > 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 [email protected] 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 Sat, Oct 2, 2010 at 2:31 AM, Barry Warsaw wrote: > 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. A system like that, which still trusts committers to make the call that rubber stamping is appropriate, sounds significantly more workable to me than one which required review even for trivial changes. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] 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
On Sat, Oct 2, 2010 at 5:17 AM, Arnon Yaari wrote: > 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 actually agree with that rejection. You appear to be thinking of hex coding solely as a data display format, when it is also used fairly often as a data interchange format (usually embedded inside a larger formatting scheme rather than standalone). For data interchange, you want the hex values as ASCII-encoded bytes, for display to the user, you want it as a string. The conversion of the binascii API to Py3k took a data interchange view of the world, bytes.fromhex is more user I/O oriented. > I would like to hear your thoughts about the backward compatibility issue in > patch 9996, and getting patch 9951 commited. Thanks. The 9951 patch looks pretty good on a quick read through. I put some specific feedback on the tracker. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] 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 Sat, Oct 2, 2010 at 10:36 AM, Benjamin Peterson wrote: > 2010/10/1 Barry Warsaw : >> 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. I agree with Benjamin here - making import.c handle the situation properly seems like a much better option (and import.c isn't *quite* as ugly as it was before Victor started cleaning it up to handle Unicode paths properly). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] 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 Sat, Oct 2, 2010 at 10:24 AM, Antoine Pitrou wrote:
> On Fri, 1 Oct 2010 20:06:57 -0400
> Barry Warsaw 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?
Ordinary users won't be building Python from source. Developers won't
care so long as we clearly document the sundry suffixes and describe
them in the README (or in a PEP, with a pointer from the README).
>> ...
>> 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.".
Having some characters on the end to flag different kinds of custom
build seems like it fits within the .so naming conventions I'm aware
of, but I'm sure the *nix packaging folks will pipe up if Barry starts
wandering too far afield in this area.
> 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.
Having multiple parallel "altinstall" installations be genuinely
non-interfering out of the box certainly seems like a desirable
feature to me.
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
