Re: [Python-Dev] [Python-checkins] pymigr: The peps repo is the only other one that seems relevant
The peps repo is the only other one that seems relevant Actually, the stackless people also requested that their repository gets converted. 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] PEP 395: Module Aliasing
On Fri, Mar 04, 2011 at 12:56:16PM -0500, Fred Drake wrote: On Fri, Mar 4, 2011 at 12:35 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: That (below) is not distutils it is setuptools. distutils just uses `scripts=[...]`, which annoyingly *doesn't* work with setuptools. Right; distutils scripts are just sad. OTOH, entry-point based scripts are something setuptools got very, very right. Probably not perfect, but... I've not yet needed anything different in practice. Some of them can be annoying as hell when dealing with a system that also installs multiple versions of a module. But one could argue that's the fault of setuptools' version handling rather than the entry-points handling. -Toshio pgpUBRcxfWp3n.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] PEP 395: Module Aliasing
On Sat, Mar 5, 2011 at 3:08 AM, Toshio Kuratomi a.bad...@gmail.com wrote: Some of them can be annoying as hell when dealing with a system that also installs multiple versions of a module. But one could argue that's the fault of setuptools' version handling rather than the entry-points handling. Agreed; I don't use setuptools to manage versions of packages. I've found zc.buildout much nicer to work with, and entirely predictable when applied properly. -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
Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream
On 05/03/2011 07:02, Nick Coghlan wrote: On Sat, Mar 5, 2011 at 10:47 AM, Mark Hammondmhamm...@skippinet.com.au wrote: I think this discussion should be divorced from this PEP and taken up with the discussion about the PATH and the last installed wins issue Martin mentions - only all of them taken together will fix this issue - not that I personally consider it particularly broken - more like sub-optimal :) I updated the draft PEP, explicitly bringing Mac OS X and Cygwin within the scope of the recommendation, and excluding PYTHON* environment variable considerations and Windows-related proposals. The Windows section does include a hit-list that may serve as a useful starting point if someone else felt like starting a Windows specific PEP, though. The issues are relevant to Windows (there are *other* issues as well but that doesn't mean that the same issue doesn't apply). Guido also said he would like to see Windows addressed. I'll be happy to try and come to some consensus with Martin (and others) on what we *can* do for Windows (as similar to the other platforms as possible would be my goal) and provide appropriate text for the PEP. I don't think it would be good (or necessary) to split this into a separate PEP. PyCon (sprints or language summit) would be a good place to talk about this. I believe the only remaining decision to be made is whether we actually change the make install command and the Mac OS X installers for Python 2.7.2, or leave them alone and tell the distro folks to fix it on their side of the fence. My own vote is a +1 for both, since changing make install is fairly easy, and Ronald indicated earlier in the thread that not only is the change to the Mac OS X installer pretty trivial, but that Apple are likely to follow the lead of whatever our default installer does. Martin has also indicated that making appropriate changes to the Windows installer would not be difficult if we agree that changing the 2.7 maintenance branch in this way is appropriate. All the best, Michael Foord Full PEP: http://www.python.org/dev/peps/pep-0394/ Diff to previous version: http://svn.python.org/view/peps/trunk/pep-0394.txt?r1=88743r2=88753 Cheers, Nick. -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] .hgignore (was: Mercurial conversion repositories)
On Fri, 04 Mar 2011 13:01:02 -0800, Santoso Wijaya santoso.wij...@gmail.com wrote: As a mercurial user, I thank you for this effort! One question, where/how do I send suggestion to what to add into .hgignore file? In particular, I found these dynamically generated files after a build in Windows (3.2) that probably should be entered as .hgignore entries: ? PC/python_nt_d.h ? PC/pythonnt_rc_d.h I, on the other hand, would like to see .rej and .orig removed from the ignore list. I don't like having these polluting my working directory, and 'hg status' is the easiest way to find them (if they aren't ignored). Or if there's some way to configure my personal .hgrc to ignore those particular ignore lines, that would be fine too :) -- 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] .hgignore (was: Mercurial conversion repositories)
On 6 March 2011 00:44, R. David Murray rdmur...@bitdance.com wrote: On Fri, 04 Mar 2011 13:01:02 -0800, Santoso Wijaya santoso.wij...@gmail.com wrote: As a mercurial user, I thank you for this effort! One question, where/how do I send suggestion to what to add into .hgignore file? In particular, I found these dynamically generated files after a build in Windows (3.2) that probably should be entered as .hgignore entries: ? PC/python_nt_d.h ? PC/pythonnt_rc_d.h I, on the other hand, would like to see .rej and .orig removed from the ignore list. I don't like having these polluting my working directory, and 'hg status' is the easiest way to find them (if they aren't ignored). Or if there's some way to configure my personal .hgrc to ignore those particular ignore lines, that would be fine too :) If those were to be removed from .hgignore then there would be a high likelihood of someone doing hg addremove and inadvertently tracking them. The purpose of .hgignore is to prevent inadventently tracking files that shouldn't be tracked. hg status -i will list all ignored files that are present in your working directory. For other options, hg help status. Tim Delaney ___ 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] [PEPs] Support the /usr/bin/python2 symlink upstream
On Sat, Mar 5, 2011 at 11:37 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: I don't think it would be good (or necessary) to split this into a separate PEP. PyCon (sprints or language summit) would be a good place to talk about this. Sure. With a PEP to record decisions this time, we shouldn't get a repeat of the last naming discussion where I believe the only remaining decision to be made is whether we actually change the make install command and the Mac OS X installers for Python 2.7.2, or leave them alone and tell the distro folks to fix it on their side of the fence. My own vote is a +1 for both, since changing make install is fairly easy, and Ronald indicated earlier in the thread that not only is the change to the Mac OS X installer pretty trivial, but that Apple are likely to follow the lead of whatever our default installer does. Martin has also indicated that making appropriate changes to the Windows installer would not be difficult if we agree that changing the 2.7 maintenance branch in this way is appropriate. True, it's only the more exotic ideas (like trying to do something about the PYTHON* variables or file associations) that become an issue. Simply supporting having a python3 version and a python2 version on PATH at the same time could work by duplicating the main executables (using python2w and python3w for the non-console variants), with the sysadmin effectively choosing the preferred version of the installed versions based on the directory order in PATH. 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] [PEPs] Support the /usr/bin/python2 symlink upstream
On Sun, Mar 6, 2011 at 12:22 AM, Nick Coghlan ncogh...@gmail.com wrote: On Sat, Mar 5, 2011 at 11:37 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: I don't think it would be good (or necessary) to split this into a separate PEP. PyCon (sprints or language summit) would be a good place to talk about this. Sure. With a PEP to record decisions this time, we shouldn't get a repeat of the last naming discussion where ... people forgot precisely which decisions were made and their rationale. Oops :) 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] [PEPs] Support the /usr/bin/python2 symlink upstream
On 05/03/2011 14:22, Nick Coghlan wrote: [snip...] Martin has also indicated that making appropriate changes to the Windows installer would not be difficult if we agree that changing the 2.7 maintenance branch in this way is appropriate. True, it's only the more exotic ideas (like trying to do something about the PYTHON* variables or file associations) that become an issue. Right. But those are issues *anyway* and are orthogonal to this particular one. (And in the case of PYTHON* environment variables not restricted to windows and not addressed by this PEP for any platform.) Simply supporting having a python3 version and a python2 version on PATH at the same time could work by duplicating the main executables (using python2w and python3w for the non-console variants), with the sysadmin effectively choosing the preferred version of the installed versions based on the directory order in PATH. Yes. I would also like to see python27.exe and python32.exe (etc) but that may be a step too far (although Martin was open to it we'll have to see what final agreement we come to). All the best, Michael Cheers, Nick. -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] [PEPs] Support the /usr/bin/python2 symlink upstream
On 05/03/2011 00:47, Mark Hammond wrote: On 5/03/2011 8:21 AM, Martin v. Löwis wrote: ... As for Windows support: we currently don't install a python3.exe binary, let alone python2.exe or pythonw2.exe (or is that python2w.exe?). I'll adjust the installer if the PEP asks me to. For the reasons discussed, I'm -0 on the change (i.e. double-clicking .py will continue to launch the most-recently installed Python, rather than the right one, and setting PYTHONPATH will continue to break installations). I agree with the -0 - I simply don't think it will, in practice, make anyone's life much easier. To run python2 and python3 based scripts in the same environment already requires some manual work by the machine owner (both directories will need to be added to the path) so the additional burden of some other steps (eg, .bat files, doskey alaises etc) doesn't seem that great. There is also a small risk of confusion - people may believe python.exe and python2.exe/python3.exe have different purposes and be confused about when to use which. In order to follow the most basic of Python tutorials new users do have to manually add their Python install to the PATH. This is unfortunate and should be addressed as a separate issue. I don't see this as a good reason for not taking additional steps to support multiple versions side-by-side on Windows. Having python2.x / python3.x binaries isn't as confusing for users on other platforms I don't see why it should be on Windows. If we add versioned binaries then users manually adding their Python install to the PATH see a benefit; they can specify the version of Python without additional work on their part. If we later add support for automatically adding Python installs to the PATH (optionally - preferably on by default) then all users who use the command line see a benefit. All the best, Michael Foord I think this discussion should be divorced from this PEP and taken up with the discussion about the PATH and the last installed wins issue Martin mentions - only all of them taken together will fix this issue - not that I personally consider it particularly broken - more like sub-optimal :) Cheers, Mark ___ 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] Support the /usr/bin/python2 symlink upstream
On 04/03/2011 21:35, Martin v. Löwis wrote: I don't think duplicating python.exe as python2.exe or python3.exe would be very much work at all, if we decide it is a good thing. Sure it doesn't resolve all the myriad problems of Python on Windows but I don't think that is a good reason not to consider it. Up to Martin on this one though and again depends if we just make recommendations or actually change Python 2.7. Changing the installer should be easy - there is a DuplicateFile table in MSI (*) for this kind of installation task. I'd still like the PEP to tell me whether it's python3w.exe or pythonw3.exe (and yes, that's bikeshedding - so somebody just tell me). python3w.exe It would also be good if the PEP took a position on providing pythonXY.exe binaries on Windows (with the related question of whether it's python32w.exe, python3.2w.exe, pythonw32.exe or pythonw3.2.exe) I would really like to see this. We do it on other platforms, it is useful there, it would be useful on Windows for the same reasons. All the best, Michael Foord Regards, Martin (*) http://msdn.microsoft.com/en-us/library/aa368335(v=vs.85).aspx -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] hg pull failed
Yesterday I cloned the hg cpython repository and made several local copies for various maintenance releases. This morning I tried to hg pull my cpython repo to get any changes (not really expecting any), but got this output: % hg pull pulling from http://hg.python.org/cpython searching for changes abort: repository is unrelated What did I do wrong? Thx, Skip ___ 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] .hgignore (was: Mercurial conversion repositories)
On Sun, 06 Mar 2011 00:54:39 +1100, Tim Delaney timothy.c.dela...@gmail.com wrote: If those were to be removed from .hgignore then there would be a high likelihood of someone doing hg addremove and inadvertently tracking them. The purpose of .hgignore is to prevent inadventently tracking files that shouldn't be tracked. Ah, well, I don't like that UI. The purpose for me of .hgignore (and similar ignore files) is to make the status command show any files that have been modified or aren't normal build/run products. I'd rather add and remove files individually by hand (except when adding or removing a directory). I also want a --strict option for the commit command that refuses to commit if there are unignored unadded or missing files. (--strict is the bzr spelling; I don't care about the spelling :) hg status -i will list all ignored files that are present in your working directory. For other options, hg help status. hg status -i is useless because there are a *lot* of ignored files in a working directory where python has been built. I'd have to do a distclean first, which would mean I'd have to do a rebuild after...and all of that just takes too long :) I guess I have some hg hacking in my future, unless someone has already written extensions for this stuff. -- 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] hg pull failed
On 05.03.2011 17:14, s...@pobox.com wrote: Yesterday I cloned the hg cpython repository and made several local copies for various maintenance releases. This morning I tried to hg pull my cpython repo to get any changes (not really expecting any), but got this output: % hg pull pulling from http://hg.python.org/cpython searching for changes abort: repository is unrelated What did I do wrong? Yesterday's repository was still the test repository, now it's the real one. You'll need to clone again. 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] rXXX links in the bug tracker after the migration to Mercurial
On 04.03.2011 22:56, Antoine Pitrou wrote: On Fri, 04 Mar 2011 22:45:24 +0100 Martin v. Löwis mar...@v.loewis.de wrote: It's not really needed; but since it works with 6+ hex digits there might be false positives. I searched the messages, and it turns out that primarily long numbers would give false positives: Python 1.6a2 (#7, Apr 24 2000, 23:02:54) [GCC pgcc-2.91.66 19990314 minidom (as the proposed documentation in patch 101821 explains) does Closed as Duplicate; see bug 435026 for details. It's an the test is extended to 200 objects on my machine IRIX rattler 6.5 10120734 IP32 hash(DNSSEC) == 8704052292078464 [New Thread 2305843009213881680 (LWP 23166)] So I guess mandating square brackets is reasonable - alternatively, mandating a fixed length could have worked as well, I guess. The two forms used in hg's output are 10-digit and 40-digit ids (the latter only with --debug, IIUC). The only reason to use another form (especially shorter) is if you type the changeset id by hand rather than paste it, which must not be very common. And if there are false positives from time to time, well they'll just link to 404s (unknown ids). I don't think that's an important issue. OK, I changed the code to only allow 12 (not 10) or 40 hex digits, but without parentheses. 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] .hgignore (was: Mercurial conversion repositories)
On Sat, Mar 5, 2011 at 5:54 AM, Tim Delaney timothy.c.dela...@gmail.comwrote: If those were to be removed from .hgignore then there would be a high likelihood of someone doing hg addremove and inadvertently tracking them. The purpose of .hgignore is to prevent inadventently tracking files that shouldn't be tracked. If the goal is to prevent something from being committed, shouldn't the check go in a pre-commit hook instead? -- Daniel Stutzbach ___ 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] .hgignore (was: Mercurial conversion repositories)
On Sat, 5 Mar 2011 08:36:04 -0800 Daniel Stutzbach stutzb...@google.com wrote: On Sat, Mar 5, 2011 at 5:54 AM, Tim Delaney timothy.c.dela...@gmail.comwrote: If those were to be removed from .hgignore then there would be a high likelihood of someone doing hg addremove and inadvertently tracking them. The purpose of .hgignore is to prevent inadventently tracking files that shouldn't be tracked. If the goal is to prevent something from being committed, shouldn't the check go in a pre-commit hook instead? Well, it's more user-friendly to help hg addremove work as expected, rather than add hooks down the line to forbid pushing any mistakes. 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
[Python-Dev] CPython hg transition complete
I'm very happy to announce that the core Python repository switch to Mercurial is complete and the new repository at http://hg.python.org/cpython/ is now officially open for cloning, and for commits by those who had commit access to SVN. The developers' guide at http://docs.python.org/devguide/ has been updated to talk about Mercurial and should be enough to get anyone started with a clone. We'll work on extracting active feature branches into separate clones next; please let us know which branches these are (we already know of py3k-cdecimal, pep-3151 and pep-382). To make new feature branches (ie. clones) that are to be available at hg.python.org, best use the server side clone feature that is available at http://hg.python.org/cpython/ in order to create the new repository. To look up SVN revisions, use hg.python.org/lookup/rX. The tracker has also been updated to link to hg.python.org for files and revisions. For the future, it will recognize hg changeset hashes as well (without brackets, see the recent thread). The buildbots should also now be building from the hg repositories. Please let me know if you notice any disruptions, or anything else that needs fixing, or any other question. Also please redirect praise to Antoine Pitrou and Dirkjan Ochtman who did most of the actual work. 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] Support the /usr/bin/python2 symlink upstream
On 5 March 2011 15:09, Michael Foord fuzzy...@voidspace.org.uk wrote: On 04/03/2011 21:35, Martin v. Löwis wrote: It would also be good if the PEP took a position on providing pythonXY.exe binaries on Windows (with the related question of whether it's python32w.exe, python3.2w.exe, pythonw32.exe or pythonw3.2.exe) I would really like to see this. We do it on other platforms, it is useful there, it would be useful on Windows for the same reasons. +1. And I'm OK with python3w and python32w as a colour for the bikeshed... Paul. ___ 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] rXXX links in the bug tracker after the migration to Mercurial
On Fri, Mar 4, 2011 at 11:56 PM, Antoine Pitrou solip...@pitrou.net wrote: On Fri, 04 Mar 2011 22:45:24 +0100 Martin v. Löwis mar...@v.loewis.de wrote: It's not really needed; but since it works with 6+ hex digits there might be false positives. I searched the messages, and it turns out that primarily long numbers would give false positives: Python 1.6a2 (#7, Apr 24 2000, 23:02:54) [GCC pgcc-2.91.66 19990314 minidom (as the proposed documentation in patch 101821 explains) does Closed as Duplicate; see bug 435026 for details. It's an the test is extended to 200 objects on my machine IRIX rattler 6.5 10120734 IP32 hash(DNSSEC) == 8704052292078464 [New Thread 2305843009213881680 (LWP 23166)] So I guess mandating square brackets is reasonable - alternatively, mandating a fixed length could have worked as well, I guess. The two forms used in hg's output are 10-digit and 40-digit ids (the latter only with --debug, IIUC). The only reason to use another form (especially shorter) is if you type the changeset id by hand rather than paste it, which must not be very common. To me this sounds like it is common, but this practice should be abandoned at all costs, which is not too user friendly. =) Both 10-digit ids and 40-digits ids can be autolinked provided that they have at least one hexadecimal letter. The probability of getting all digits in 10-digit sequence is less than 1%. But for manual typing I'd still prefer to have square bracket type of links. -- anatoly t. ___ 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
On 03/05/2011 01:14 AM, Nick Coghlan wrote: On Sat, Mar 5, 2011 at 2:40 PM, Ron Adamr...@ronadam.com wrote: Fixing direct execution inside packages +1 on both of these. I don't see any major problems with these. Any minor issues can be worked out. I suggest separating these two items out into their own PEP, and doing them first. This first draft includes everything I *want* to do. If I have to scale the proposal back to get it accepted because I can't convince enough other people it's a good idea... well, even Guido isn't immune to that part of the PEP process (cf. PEP 340). It wouldn't be the first PEP to have a Rejected Ideas section, and I'm sure it wouldn't be the last. Right, All of the reasons are good and some solution should be implemented for each of the issues you pointed out. The PEP process will help us figure out the best way to do that. I definitely intend to implement this in a few different pieces, though - the order of the 4 different fixes in the PEP also summarises what I consider to be a reasonable development strategy as well. Sounds good. I haven't formed a good opinion on the last 2 items yet which was why I didn't comment on them. This morning I did have some interesting thoughts.* *It seems I'm starting to wake up with python code in my head. (Is that good?) In some cases, it's outside of the box solutions, but not always good ones. shrug ;-) Anyway... this mornings fuzzy python thoughts were along the lines of... On one hand, Python tries to make it so each objects source/parent info is reachable from the object when possible. The nice thing about that is, it can be used to create a tree of where everything is. That doesn't work *easily* at the module level due to modules being external OS entities that can be reused in different contexts. On the other hand, a modules import order is somewhat more dynamic compared to class inheritance order, so would it be better to have that info in a separate place rather than with each module? Adding a second references to the '__main__' module begins to blur the purpose of sys.modules from being a place to keep imported modules to a place that also has some ordering information. (Practicality over purity?, Or an indication of what direction to go in?) And, if you ask for keys, items, or values, you will need to filter out '__main__' to avoid the double reference. So I was thinking, what if we make sys.modules a little smarter. The negative of that is, it would no longer be a simple dictionary object. First idea ... Add a __main__ attribute to sys.modules to hold the name of the main module. Override modules.__setitem__, so it will catch '__main__' and set modules.__main__ to the name of the module, and put the module in under its real name instead of '__main__'. Override modules.__getitem__, so it will catch '__main__' and return self[self.__main__]. Then keys(), values(), and items(), will not have the doubled main module references in them. The name of the main module is easy to get. ie... sys.modules.__main__ sys.modules[__name__] will still return the correct module if __name__ == __main__. Second (more ambitious and less thought out) idea ... Extend sys.modules so it is actually is a tree structure. The '__main__' module would be at the top of the tree. Cheers, Ron ___ 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] contributors survey?
On 02/03/2011 16:05, R. David Murray wrote: On Wed, 02 Mar 2011 13:10:04 +, Mark Smithmark.sm...@practicalpoetry.co.uk wrote: The following is going to sound bitter... I was fired with enthusiasm for working on Python after the sprints at EuroPython last year. I submitted 3 (I think) patches for pulldom - a test suite (it has 0% code coverage at present), documentation for the module (there isn't any at present), and a patch deprecating a function that is broken. They're all still open, and the patches are getting staler by the month. The point of this level of detail is: I was new to the project; I submitted some relatively uncomplicated patches that trivially, visibly, and (mostly) uncontroversially improve Python - one of them was a /documentation/ patch. Then nothing happened, apart from the odd comment from people who commented on the tickets - and I responded to their queries. So now I'm of the opinion that it's not worth submitting patches to the Python project at all, because they'll never be accepted. I'll dedicate my time to something else instead. Mercurial /will/ make it easier to contribute code, but if it doesn't get accepted into a release branch, then that makes no real difference to me. Seriously guys - fix the issue lifecycle; I'll come back. This is really valuable feedback. Thanks Mark. After running a core sprint at PyOhio I realized that one thing that is *seriously* needed is more followup after a sprint (and probably after bug days as well). I didn't gather the information at the sprint that I would have needed to do that followup (who exactly did submit patches during the sprint and which patches?). I'd like to suggest that we collect such information one way or another for the PyCon sprint, and pay special attention to those patches in the weeks following PyCon. Yes. There is little point in putting effort (and money) into finding new contributors if we can't retain them and don't make use of the work they do. Mark - if the patches you provided are still outstanding can you let us know what the issue numbers are? All the best, Michael Foord The other issue with the pulldom patches, Mark, is that unfortunately you fell into one of the black holes: I don't think there are any active committers who know much, if anything, about pulldom. As with everything else, it comes down to lack of people hours. People pay attention to what interests them, and some attention to other stuff, and there aren't enough people for that some attention to other stuff to cover all the patches that are submitted. There are probably ways to improve patch lifecycle management, but I don't think there is any *fix* other than more people. So, doing followup after sprints/bug days to help keep contributor enthusiasm going and get some of them converted into committers is perhaps the best fix we could apply. Of course, doing that followup requires people-time... -- 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] Finding buildbot failures
On 28/02/2011 21:59, Martin v. Löwis wrote: That's one of the big advantages that Jenkins (nee Hudson) has over buildbot - drilling down into individual test failures through the web ui. Your test run needs to generate appropriate xml for that to work though. Buildbot can do this too. It can even do it without xml, although it does need *some* parseable format, which I think the Python test suite is a long way from. That would be a great improvement to the Python buildbot infrastructure. So would you be willing to contribute the necessary changes? To whom was this addressed? If to me I have the desire but lack the skill. If Jean-Paul is willing / able to help and is around for the pycon sprints then it would be a good opportunity. All the best, Michael Foord Regards, Martin -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] Support the /usr/bin/python2 symlink upstream
On 3/5/2011 12:44 PM, Paul Moore wrote: On 5 March 2011 15:09, Michael Foordfuzzy...@voidspace.org.uk wrote: On 04/03/2011 21:35, Martin v. Löwis wrote: It would also be good if the PEP took a position on providing pythonXY.exe binaries on Windows (with the related question of whether it's python32w.exe, python3.2w.exe, pythonw32.exe or pythonw3.2.exe) I would really like to see this. We do it on other platforms, it is useful there, it would be useful on Windows for the same reasons. +1. And I'm OK with python3w and python32w as a colour for the bikeshed... Except for the the spelling of color ;-) I agree. Let 'w' always be the last suffix. With that settled, there is the issue of Start menu shortcuts. I thought we had agreed to put version specific labels on them so we would not have, for instance, identical 'IDLE (Python GUI)' items in the frequently used list. I guess that got lost without a PEP to put it on. Now there is? -- 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] Support the /usr/bin/python2 symlink upstream
On 05/03/2011 18:52, Terry Reedy wrote: On 3/5/2011 12:44 PM, Paul Moore wrote: On 5 March 2011 15:09, Michael Foordfuzzy...@voidspace.org.uk wrote: On 04/03/2011 21:35, Martin v. Löwis wrote: It would also be good if the PEP took a position on providing pythonXY.exe binaries on Windows (with the related question of whether it's python32w.exe, python3.2w.exe, pythonw32.exe or pythonw3.2.exe) I would really like to see this. We do it on other platforms, it is useful there, it would be useful on Windows for the same reasons. +1. And I'm OK with python3w and python32w as a colour for the bikeshed... Except for the the spelling of color ;-) I agree. Let 'w' always be the last suffix. Yep. (Me too, me too.) With that settled, there is the issue of Start menu shortcuts. I thought we had agreed to put version specific labels on them so we would not have, for instance, identical 'IDLE (Python GUI)' items in the frequently used list. I guess that got lost without a PEP to put it on. Now there is? Whilst there is much we would (and possibly should) do, other issues for the Windows installer are out of scope for this PEP. Let's just deal with the issue at hand. :-) All the best, Michael -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] .hgignore (was: Mercurial conversion repositories)
On Mar 5, 2011, at 8:44 AM, Antoine Pitrou wrote: On Sat, 5 Mar 2011 08:36:04 -0800 Daniel Stutzbach stutzb...@google.com wrote: On Sat, Mar 5, 2011 at 5:54 AM, Tim Delaney timothy.c.dela...@gmail.comwrote: If those were to be removed from .hgignore then there would be a high likelihood of someone doing hg addremove and inadvertently tracking them. The purpose of .hgignore is to prevent inadventently tracking files that shouldn't be tracked. If the goal is to prevent something from being committed, shouldn't the check go in a pre-commit hook instead? Well, it's more user-friendly to help hg addremove work as expected, rather than add hooks down the line to forbid pushing any mistakes. I concur. Raymond ___ 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] Vagaries of their in English (was Re: Support the /usr/bin/python2 symlink upstream)
I'm sorry, but I can't just get used to it, nor do I think it's the least bad of all available options. I'll just summarise briefly what the incorrect ways of addressing this problem are, and why: * he or she and his or her are cumbersome constructions introduced by politically correct zealots who are trying to politicise something that's not political. It's grammatically acceptable, but cumbersome and pointless. Please avoid doing this. If you really absolutely have to bow to the pressure of politically correct idiocy though, this might be the best choice since at least it's grammatically sound. * they and their are plural, and should never be used in the singular. This has become the leading contender thanks to the same politically correct zealots named above (and also because it's not cumbersome), but that makes it no less wrong. Please don't do this. Ever. In addition to being pointlessly (and annoyingly) politicised, it's grammatically incorrect. The correct way to address this problem (that is, how it had always been addressed before politically correct zealots started butchering the language) is for the speaker to assume that the person of unknown gender is the same gender as they are. In other words, if a woman is speaking or writing, she should use she and her, and if a man is speaking or writing, he should use he and his. This is the correct usage, and always has been. In the event that it is necessary to avoid giving the wrong impression about gender, it might be necessary to make a different substitution. For example, it you've witnessed a hit and run, but only saw the car and not the driver, and you're trying to tell the police what you saw, you don't want to give the impression that you know the gender of the driver when you don't. Thus, instead of saying and then *he* took off down Maple street. or and then *they* took off down Maple street. (which also would give the possibly erroneous impression that multiple people were in the car), you should say something like and then *the car* took off... or and then *the driver* took off... As this relates to Python and it's documentation (which I'll assume is where this is discussion originated, not having read the originating thread), given that there are multiple authors, some male and some female, we should just standardise on either he or she (or, if you prefer: the programmer). I don't care which one, as long as it's used consistently throughout. But please, please, whatever you do, don't use they and their to refer to a singular. Out of all the possible options that's the one that's actually *wrong*. Far from being the least bad of all available options, it's actually the worst of all available options. ___ 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] CPython hg transition complete
On Sat, Mar 5, 2011 at 12:39 PM, Georg Brandl g.bra...@gmx.net wrote: I'm very happy to announce that the core Python repository switch to Mercurial is complete and the new repository at http://hg.python.org/cpython/ is now officially open for cloning, and for commits by those who had commit access to SVN. The developers' guide at http://docs.python.org/devguide/ has been updated to talk about Mercurial and should be enough to get anyone started with a clone. We'll work on extracting active feature branches into separate clones next; please let us know which branches these are (we already know of py3k-cdecimal, pep-3151 and pep-382). To make new feature branches (ie. clones) that are to be available at hg.python.org, best use the server side clone feature that is available at http://hg.python.org/cpython/ in order to create the new repository. To look up SVN revisions, use hg.python.org/lookup/rX. The tracker has also been updated to link to hg.python.org for files and revisions. For the future, it will recognize hg changeset hashes as well (without brackets, see the recent thread). The buildbots should also now be building from the hg repositories. Please let me know if you notice any disruptions, or anything else that needs fixing, or any other question. Also please redirect praise to Antoine Pitrou and Dirkjan Ochtman who did most of the actual work. Georg Thanks to all of you for doing this. ___ 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] Finding buildbot failures
On Sat, 05 Mar 2011 18:26:29 + Michael Foord fuzzy...@voidspace.org.uk wrote: On 28/02/2011 21:59, Martin v. Löwis wrote: That's one of the big advantages that Jenkins (nee Hudson) has over buildbot - drilling down into individual test failures through the web ui. Your test run needs to generate appropriate xml for that to work though. Buildbot can do this too. It can even do it without xml, although it does need *some* parseable format, which I think the Python test suite is a long way from. That would be a great improvement to the Python buildbot infrastructure. So would you be willing to contribute the necessary changes? To whom was this addressed? If to me I have the desire but lack the skill. It shouldn't be difficult to acquire the skills. Buildbot is pure Python (even its configuration file). 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] CPython hg transition complete
Georg Brandl: I'm very happy to announce that the core Python repository switch to Mercurial is complete and the new repository at http://hg.python.org/cpython/ is now officially open for cloning, OK, I just performed a clone OK. It seems wrong to me that the *.vcproj and *.vsprops files in PCBuild use Unix line ends. These extensions are marked BIN in .hgeol. This machine does not have VS 2008 installed so I can't really check if that is OK. Just in case it is not all files, here are two with this issue cpython\PCbuild\kill_python.vcproj cpython\PCbuild\debug.vsprops Neil ___ 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] CPython hg transition complete
On Sun, 6 Mar 2011 08:51:01 +1100 Neil Hodgson nyamaton...@gmail.com wrote: Georg Brandl: I'm very happy to announce that the core Python repository switch to Mercurial is complete and the new repository at http://hg.python.org/cpython/ is now officially open for cloning, OK, I just performed a clone OK. It seems wrong to me that the *.vcproj and *.vsprops files in PCBuild use Unix line ends. These extensions are marked BIN in .hgeol. This machine does not have VS 2008 installed so I can't really check if that is OK. It mimicks their settings in the SVN repository, so it should be ok. Thanks for reporting this. 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] Finding buildbot failures
Am 05.03.2011 19:26, schrieb Michael Foord: On 28/02/2011 21:59, Martin v. Löwis wrote: That's one of the big advantages that Jenkins (nee Hudson) has over buildbot - drilling down into individual test failures through the web ui. Your test run needs to generate appropriate xml for that to work though. Buildbot can do this too. It can even do it without xml, although it does need *some* parseable format, which I think the Python test suite is a long way from. That would be a great improvement to the Python buildbot infrastructure. So would you be willing to contribute the necessary changes? To whom was this addressed? If to me I have the desire but lack the skill. I honestly believe that you do have the skill, but perhaps lack the knowledge (and yes, I meant to suggest that you work on this). I'd be also willing to help you getting started, especially assuming you would want to sprint on that during PyCon. 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] CPython hg transition complete
Antoine Pitrou: It mimicks their settings in the SVN repository, so it should be ok. It doesn't match how they are checked out by svn since they have the property svn:eol-style set to 'native'. Therefore these files are checked out by svn with Windows \r\n line ends. Neil ___ 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] CPython hg transition complete
Le dimanche 06 mars 2011 à 09:27 +1100, Neil Hodgson a écrit : Antoine Pitrou: It mimicks their settings in the SVN repository, so it should be ok. It doesn't match how they are checked out by svn since they have the property svn:eol-style set to 'native'. Therefore these files are checked out by svn with Windows \r\n line ends. Some of these files (MSVC project files) had that property, but some hadn't. I had to make them all consistent so that the .hgeol file work fine. 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] Support the /usr/bin/python2 symlink upstream
With that settled, there is the issue of Start menu shortcuts. I thought we had agreed to put version specific labels on them so we would not have, for instance, identical 'IDLE (Python GUI)' items in the frequently used list. I guess that got lost without a PEP to put it on. Now there is? That would be a bug tracker level issue. I know that I'm bad at wording things (not having English as my native language), so I need somebody to tell me every little detail (preferably by means of a patch). The bug tracker is the right place for that. Agreements on python-dev are quickly forgotten. 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] CPython hg transition complete
Am 05.03.2011 23:33, schrieb Antoine Pitrou: Le dimanche 06 mars 2011 à 09:27 +1100, Neil Hodgson a écrit : Antoine Pitrou: It mimicks their settings in the SVN repository, so it should be ok. It doesn't match how they are checked out by svn since they have the property svn:eol-style set to 'native'. Therefore these files are checked out by svn with Windows \r\n line ends. Some of these files (MSVC project files) had that property, but some hadn't. I had to make them all consistent so that the .hgeol file work fine. Actually, the status that they had was deliberate. The vcproj files can be in native EOL mode, and should have CRLF when checked out on Windows. The solution file must have CRLF always. The vcproj files where not in binary mode in subversion since that wouldn't allow for easy textual diffs. 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] hg pull failed
Am 05.03.2011 17:14, schrieb s...@pobox.com: Yesterday I cloned the hg cpython repository and made several local copies for various maintenance releases. This morning I tried to hg pull my cpython repo to get any changes (not really expecting any), but got this output: % hg pull pulling from http://hg.python.org/cpython searching for changes abort: repository is unrelated What did I do wrong? Since Georg didn't actually answer the question: you started using the infrastructure before it was ready. Interestingly, I remember you making the same mistake when we switched to Subversion: you continued to use the test repository, and then found that subversion complains :-) 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] Vagaries of their in English (was Re: Support the /usr/bin/python2 symlink upstream)
Daniel A. Welty wrote: * they and their are plural, and should never be used in the singular. Thank you for sharing your option here, but you are not a linguist and you are simply wrong. At least two people in this thread have already linked to Wikipedia's article on singular-they, which has extensive discussion about its validity, complete with references, as well as more accessible discussions written by professional language experts like Michael Quinion or Geoffrey Pullum. In case you missed them the first few times, here they are again: http://en.wikipedia.org/wiki/Singular_they http://www.worldwidewords.org/qa/qa-the2.htm http://itre.cis.upenn.edu/~myl/languagelog/archives/005423.html (corrected broken link given earlier) http://motivatedgrammar.wordpress.com/2009/09/10/singular-they-and-the-many-reasons-why-its-correct/ http://english.stackexchange.com/questions/192/is-it-correct-to-use-their-instead-of-his-or-her As for your prescription for solving this problem: is for the speaker to assume that the person of unknown gender is the same gender as they are. As *they* are? Thank you for your accidental demonstration that the use of singular they is a natural and unobjectionable part of English language. -- 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
Re: [Python-Dev] CPython hg transition complete
To minimize differences from previous behaviour, it is probably best to mimic svn more closely by changing .hgeol to either have all the project files as native or allow fall through to the default ** = native. Another possibility is to set Visual Studio project files to CRLF but this is less compatible with how svn has been used. The advantage to explicit CRLF is that if you clone onto a Unix system and then share that disk with Windows or create an archive that is expanded on Windows (in binary mode) then you have the expected line ends. Similarly for sharing from Windows to Unix where the main problem is that bash can be upset by CRLF line ends since it assumes that the CR is part of the line and if the line ends with a file name (like cat .profile\r) will treat the CR as part of the file name. Neil ___ 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] CPython hg transition complete
On Sun, 6 Mar 2011 10:27:14 +1100 Neil Hodgson nyamaton...@gmail.com wrote: To minimize differences from previous behaviour, it is probably best to mimic svn more closely by changing .hgeol to either have all the project files as native or allow fall through to the default ** = native. If it's only cosmetic, I think anyone can commit and push the desired changes. (there doesn't seem to be any report of breakage of the build process under Windows) 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] CPython hg transition complete
Another possibility is to set Visual Studio project files to CRLF but this is less compatible with how svn has been used. The advantage to explicit CRLF is that if you clone onto a Unix system and then share that disk with Windows or create an archive that is expanded on Windows (in binary mode) then you have the expected line ends. Similarly for sharing from Windows to Unix where the main problem is that bash can be upset by CRLF line ends since it assumes that the CR is part of the line and if the line ends with a file name (like cat .profile\r) will treat the CR as part of the file name. I recall that there were problems with subversion when we didn't use native (but I think we used binary before that, and never tried CRLF). It may be that the problems don't exist anymore, so I recommend that we try fresh with CRLF, and reconsider if something actually breaks. What is the recommended merge flow if I want to make this change to all branches? 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] Vagaries of their in English (was Re: Support the /usr/bin/python2 symlink upstream)
On Sun, 2011-03-06 at 10:25 +1100, Steven D'Aprano wrote: Daniel A. Welty wrote: * they and their are plural, and should never be used in the singular. Thank you for sharing your option here, but you are not a linguist and you are simply wrong. At least two people in this thread have already linked to Wikipedia's article on singular-they, which has extensive discussion about its validity, complete with references, as well as more accessible discussions written by professional language experts like Michael Quinion or Geoffrey Pullum. In case you missed them the first few times, here they are again: http://en.wikipedia.org/wiki/Singular_they http://www.worldwidewords.org/qa/qa-the2.htm http://itre.cis.upenn.edu/~myl/languagelog/archives/005423.html (corrected broken link given earlier) http://motivatedgrammar.wordpress.com/2009/09/10/singular-they-and-the-many-reasons-why-its-correct/ http://english.stackexchange.com/questions/192/is-it-correct-to-use-their-instead-of-his-or-her As for your prescription for solving this problem: is for the speaker to assume that the person of unknown gender is the same gender as they are. As *they* are? Thank you for your accidental demonstration that the use of singular they is a natural and unobjectionable part of English language. Is playing gotcha REALLY necessary? I believe singular they should not be used in formal writing. So what if you use it in an email? ___ 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] hg merge flow
How should patches be applied to the cpython repository if they land in more than one branch? More specifically, assuming I want to patch all of 2.7, 3.1, 3.2, and default - how do I apply the patches and how do I merge? 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] CPython hg transition complete
On Sun, 06 Mar 2011 00:37:32 +0100 Martin v. Löwis mar...@v.loewis.de wrote: What is the recommended merge flow if I want to make this change to all branches? - on one hand: 2.5 - 2.6 - 2.7 (if you still want to maintain 2.5) - on the other hand: 3.1 - 3.2 - default 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
[Python-Dev] hg diff
It seems that the dev guide recommends to use the --git option in hg diff. I'm working on the Rietveld integration, and found that this option makes things worse: the regular diff includes the base revision of the patch; hg diff --git doesn't. So I would rather like people not to use the --git option. 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] hg merge flow
On Sun, 06 Mar 2011 00:44:03 +0100 Martin v. Löwis mar...@v.loewis.de wrote: How should patches be applied to the cpython repository if they land in more than one branch? More specifically, assuming I want to patch all of 2.7, 3.1, 3.2, and default - how do I apply the patches and how do I merge? (reposting my answer from another thread) - on one hand: 2.5 - 2.6 - 2.7 (if you still want to maintain 2.5) - on the other hand: 3.1 - 3.2 - default Whether you start with 2.x or 3.x is unimportant. 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] Vagaries of their in English (was Re: Support the /usr/bin/python2 symlink upstream)
Westley Martínez wrote: I believe singular they should not be used in formal writing. So what if you use it in an email? If you, personally, dislike it, then don't use it. But if you (generic you) say that it is grammatically incorrect to do so, then you are simply *wrong*. Some things are a matter of taste and individual opinion, but the validity of singular-they is not one of them. And if you (generic you) insist that a grammatical feature which goes back to Chaucer in written English, most likely a thousand years in spoken English, and that is used by the King James Bible, is politically correct zealotry created by feminists, well, that's just laughable. This is off-topic and we've put enough noise on the dev list about this. If anyone wishes to continue a serious, good-faith discussion, I'm happy to talk off-list. -- 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
Re: [Python-Dev] PEP 395: Module Aliasing
On Sun, Mar 6, 2011 at 4:11 AM, Ron Adam r...@ronadam.com wrote: Adding a second references to the '__main__' module begins to blur the purpose of sys.modules from being a place to keep imported modules to a place that also has some ordering information. (Practicality over purity?, Or an indication of what direction to go in?) And, if you ask for keys, items, or values, you will need to filter out '__main__' to avoid the double reference. So I was thinking, what if we make sys.modules a little smarter. The negative of that is, it would no longer be a simple dictionary object. First idea ... Add a __main__ attribute to sys.modules to hold the name of the main module. Override modules.__setitem__, so it will catch '__main__' and set modules.__main__ to the name of the module, and put the module in under its real name instead of '__main__'. Override modules.__getitem__, so it will catch '__main__' and return self[self.__main__]. Then keys(), values(), and items(), will not have the doubled main module references in them. The name of the main module is easy to get. ie... sys.modules.__main__ sys.modules[__name__] will still return the correct module if __name__ == __main__. That's quite an interesting idea - I hadn't even considered the implications of double counting the affected module when iterating over sys.modules in some fashion. That said, dropping `__main__` from the iteration might confuse existing code, so it may be better to have the lookup go the other way (i.e. define __missing__ on the dict subclass and return sys.modules['__main__'] if the key matches sys.modules.__main__). 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] hgeol
I am trying to fix the hgeol settings for the vcproj files, with little success so far. I created http://hg.python.org/sandbox/hgeol/ which merely changes the .hgeol file. Now, if you enable the eol extension, and check this branch out, you immediately get a report (from hg status) that you have modified all these files. That is surprising, since you didn't change any file at all. So how can I fix this properly: so that all files have CRLF, but are still attributed to whoever last modified them, rather than having them attributed to me? 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] hgeol
Martin v. Löwis: So how can I fix this properly: so that all files have CRLF, but are still attributed to whoever last modified them, rather than having them attributed to me? I don't think this is possible from the current state. It may be possible to change the conversion process to 'rewrite history' to produce clean annotations. On other projects, I've just changed the files and accepted a degraded history. Neil ___ 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] hgeol
On 3/5/2011 7:37 PM, Martin v. Löwis wrote: I am trying to fix the hgeol settings for the vcproj files, with little success so far. I created http://hg.python.org/sandbox/hgeol/ which merely changes the .hgeol file. Now, if you enable the eol extension, and check this branch out, you immediately get a report (from hg status) that you have modified all these files. That is surprising, since you didn't change any file at all. So how can I fix this properly: so that all files have CRLF, but are still attributed to whoever last modified them, rather than having them attributed to me? I'm not sure it's possible. If you look at Antoine's changes to Lib/email/test/data/msg_26.txt in 2.7 earlier today where he changed the line endings, it appears he changed every line so it will be attributed to him. Eric. ___ 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] hooks: Hopefully fix the issue where notification of merges to buildbot
For the record, the reason these emails look a bit strange (and appear
to be pushed by Dirkjan (sorry)) is that they were done directly on the
server with the settings of the local user hg.
Regards
Antoine.
On Sun, 06 Mar 2011 02:36:25 +0100
dirkjan.ochtman python-check...@python.org wrote:
http://hg.python.org/hooks/rev/d2aca4834bb9
[0;33mchangeset: 48:d2aca4834bb9[0m
user:Antoine Pitrou solip...@pitrou.net
date:Sun Mar 06 02:36:25 2011 +0100
summary:
Hopefully fix the issue where notification of merges to buildbot
wouldn't notify all changed files (because they are copied from
the second parent). Untested still.
files:
hgbuildbot.py
diff --git a/hgbuildbot.py b/hgbuildbot.py
--- a/hgbuildbot.py
+++ b/hgbuildbot.py
@@ -84,9 +84,18 @@
manifest, user, (time, timezone), files, desc, extra =
repo.changelog.read(node)
parents = [p for p in repo.changelog.parents(node) if p != nullid]
branch = extra['branch']
-# merges don't always contain files, but at least one file is
required by buildbot
-if len(parents) 1 and not files:
-files = [merge]
+if len(parents) 1:
+# Explicitly compare current with its first parent (otherwise
+# some files might be forgotten if they are copied as-is from
the
+# second parent).
+modified, added, removed, deleted = repo.status(rev, p[0])[:4]
+files = set()
+for l in (modified, added, removed, deleted):
+files.extend(l)
+files = sorted(files)
+if not files:
+# dummy merge, but at least one file is required by buildbot
+files.append(Misc/merge)
# add artificial prefix if configured
files = [prefix + f for f in files]
changes.append({
--
Repository URL: http://hg.python.org/hooks
___
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] Vagaries of their in English (was Re: Support the /usr/bin/python2 symlink upstream)
Enough already. If anyone still disagrees, they can discuss it in the comments page on wikipedia (http://en.wikipedia.org/wiki/Talk:Singular_they). Seriously, this is off-topic for python-dev. -- --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] [PEPs] Support the /usr/bin/python2 symlink upstream
On 6/03/2011 12:37 AM, Michael Foord wrote: On 05/03/2011 07:02, Nick Coghlan wrote: On Sat, Mar 5, 2011 at 10:47 AM, Mark Hammondmhamm...@skippinet.com.au wrote: I think this discussion should be divorced from this PEP and taken up with the discussion about the PATH and the last installed wins issue Martin mentions - only all of them taken together will fix this issue - not that I personally consider it particularly broken - more like sub-optimal :) I updated the draft PEP, explicitly bringing Mac OS X and Cygwin within the scope of the recommendation, and excluding PYTHON* environment variable considerations and Windows-related proposals. The Windows section does include a hit-list that may serve as a useful starting point if someone else felt like starting a Windows specific PEP, though. The issues are relevant to Windows (there are *other* issues as well but that doesn't mean that the same issue doesn't apply). Guido also said he would like to see Windows addressed. What issues specifically? If I look at the current PEP language, it refers to the default version of the Python interpreter and all new code that needs to invoke the Python interpreter. Neither of these apply in any meaningful way to Windows. It could be argued that the latter could include .bat files which use Python but that sounds like a theoretical problem (ie, I haven't heard much noise about that) where PEP394 is addressing an observed practical problem. On Windows it seems to be just about 'python2' and 'python3' doing the correct thing in a default command prompt, which while desirable ignores the broader issues (eg, the file associations and anything else windowsy and not driven by the command-prompt) I'll be happy to try and come to some consensus with Martin (and others) on what we *can* do for Windows (as similar to the other platforms as possible would be my goal) and provide appropriate text for the PEP. IIUC, the PEP language is referring to links which point to a specific version of Python and that there is no suggestion a 'python3' will live in the Python 3 binary tree. If that is correct and assuming we don't want to investigate using links on Windows, I'd suggest the best analogy to the *nix situation could be simply for the installers to generate python2.bat and python3.bat files and put them in System32 with a last installed wins policy. The fact this doesn't help users installing Python just for me is fine too from the POV of matching *nix systems - a user installing a private Python build on *nix also doesn't get the python2 and python3 conveniences, nor the automatic PATH convenience. But in practice I expect this would *not* be OK - which just highlights the risks of trying to generalize a specific observed problem on one OS to others. Cheers, Mark ___ 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] Devguide: Can I make commits from machines other than the one I generated the keys on?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In http://docs.python.org/devguide/faq.html#can-i-make-commits-from-machines-other-than-the-one-i-generated-the-keys-on I would rather prefer to promote the -A parameter to SSH (to use the local SSH agent be used from the remote development machine) instead of uploading private keys. - -- 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/ iQCVAwUBTXMFXplgi5GaxT1NAQJz1wP/d9sE3aJT8T9da5v7rBUcQY+7W5TupxvH 5hwvYnTgaTELH6AkxG45/yQzuP3OLppxquKlbQvLAMSpK/463UL7ip2xyihNGgo6 kAaRh0HaHal1JqosvXIs2tMj/qT7fZ61i5yW09fRFBg+fMWm1LE8kthqFfPujyNO zLYjpCO853Y= =VZI1 -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] Vagaries of their in English (was Re: Support the /usr/bin/python2 symlink upstream)
On Sun, 2011-03-06 at 11:18 +1100, Steven D'Aprano wrote: Westley Martínez wrote: I believe singular they should not be used in formal writing. So what if you use it in an email? If you, personally, dislike it, then don't use it. But if you (generic you) say that it is grammatically incorrect to do so, then you are simply *wrong*. Some things are a matter of taste and individual opinion, but the validity of singular-they is not one of them. And if you (generic you) insist that a grammatical feature which goes back to Chaucer in written English, most likely a thousand years in spoken English, and that is used by the King James Bible, is politically correct zealotry created by feminists, well, that's just laughable. This is off-topic and we've put enough noise on the dev list about this. If anyone wishes to continue a serious, good-faith discussion, I'm happy to talk off-list. For the record, I never said anything about politically correct zealotry. ___ 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
On 03/05/2011 06:33 PM, Nick Coghlan wrote: On Sun, Mar 6, 2011 at 4:11 AM, Ron Adamr...@ronadam.com wrote: Adding a second references to the '__main__' module begins to blur the purpose of sys.modules from being a place to keep imported modules to a place that also has some ordering information. (Practicality over purity?, Or an indication of what direction to go in?) And, if you ask for keys, items, or values, you will need to filter out '__main__' to avoid the double reference. So I was thinking, what if we make sys.modules a little smarter. The negative of that is, it would no longer be a simple dictionary object. First idea ... Add a __main__ attribute to sys.modules to hold the name of the main module. Override modules.__setitem__, so it will catch '__main__' and set modules.__main__ to the name of the module, and put the module in under its real name instead of '__main__'. Override modules.__getitem__, so it will catch '__main__' and return self[self.__main__]. Then keys(), values(), and items(), will not have the doubled main module references in them. The name of the main module is easy to get. ie... sys.modules.__main__ sys.modules[__name__] will still return the correct module if __name__ == __main__. That's quite an interesting idea - I hadn't even considered the implications of double counting the affected module when iterating over sys.modules in some fashion. That said, dropping `__main__` from the iteration might confuse existing code, so it may be better to have the lookup go the other way (i.e. define __missing__ on the dict subclass and return sys.modules['__main__'] if the key matches sys.modules.__main__). ... if the key matches sys.modules.__missing__ Works for me. ;-) We can find a better name than __missing__ later. (minor detail) Cheers, Ron ___ 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
On Sun, Mar 6, 2011 at 2:54 PM, Ron Adam r...@ronadam.com wrote: ... if the key matches sys.modules.__missing__ Works for me. ;-) We can find a better name than __missing__ later. (minor detail) __missing__ is a dict method. I was merely noting it would make more sense to override that rather than __setitem__ to avoid slowing down normal lookups in sys.modules. However, I'll still advocate the simple approach (two entries) for now. Assuming uniqueness of values in a dictionary is invalid in general, so code assuming it for sys.modules is arguably already incorrect. Definitely a point deserving of more discussion in the PEP, though. 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] Devguide: Can I make commits from machines other than the one I generated the keys on?
On Sat, Mar 5, 2011 at 7:54 PM, Jesus Cea j...@jcea.es wrote: In http://docs.python.org/devguide/faq.html#can-i-make-commits-from-machines-other-than-the-one-i-generated-the-keys-on I would rather prefer to promote the -A parameter to SSH (to use the local SSH agent be used from the remote development machine) instead of uploading private keys. Using agent forwarding with ssh gives the machine you log into full access to _all_ of your local ssh keys rather than just the python svn one required. I'd rather not recommend that to people. Any serious user of ssh will know the feature exists and when to prefer its use. -gps ___ 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
