Re: [Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS

On 20/12/2010 13:47, Antoine Pitrou wrote: Le lundi 20 décembre 2010 à 13:00 +, Michael Foord a écrit : Ah man, we've *nearly* finished bikeshedding about the names of unittest assert methods so its time to move onto the names and order of the arguments. Really? Apparently someone de

Re: [Python-Dev] sqlite, DDL, and transactions

://bugs.python.org/ All the best, Michael Foord Attached patch addresses the issue. Patch is against 2.6.1, but looking at Trunk in svn, it seems like the patch is needed and would apply. One issue I could foresee is that this behavior might depend on the sqlite version in use (I'm on 3.6.10). T

Re: [Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS

well). The (actual, expected) pattern matches the way almost everyone I've ever seen write if statements and asserts: if x == 5: rather than if 5 == x: assert x == 5 rather than assert 5 == x It also matches functions like isinstance and issubclass. On the other hand it doesn'

Re: [Python-Dev] Fault handler updated, now disabled by default

for this. Another possibility would be providing a C-API to enable it and have the Python interpreter application call this, so that the functionality remains off by default for embedded interpreters but on for normal uses. All the best, Michael Victor

Re: [Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS

On 22/12/2010 02:26, Terry Reedy wrote: On 12/21/2010 7:17 AM, Michael Foord wrote: My first priority is that doc and code match. Close second is consistency (hence, ease of learning and use) between various AssertXs. Symmetrical diffs (element in first not in second, element in second not

[Python-Dev] Tools/unicode

n 3.2. I'm removing the "for Python 2.0" from the description, but I would rather remove the tool altogether. If someone knows if this tool is still used/useful then please let us know how the description should best be updated. If there are no replies I'll remove it.

Re: [Python-Dev] Tools/unicode

On 03/01/2011 15:39, Alexander Belopolsky wrote: On Mon, Jan 3, 2011 at 10:33 AM, Michael Foord wrote: .. If someone knows if this tool is still used/useful then please let us know how the description should best be updated. If there are no replies I'll remove it. If you are talking

Re: [Python-Dev] Tools/unicode

On 03/01/2011 16:19, M.-A. Lemburg wrote: Michael Foord wrote: On 03/01/2011 15:39, Alexander Belopolsky wrote: On Mon, Jan 3, 2011 at 10:33 AM, Michael Foord wrote: .. If someone knows if this tool is still used/useful then please let us know how the description should best be updated. If

Re: [Python-Dev] Possible optimization for LOAD_FAST ?

ly to a module is actually common for testing. In particular replacing the open function, but also other builtins, is often done temporarily to replace it with a mock. It seems like this optimisation would break those tests. Michael Caveat-of-doom: That code's very much a work-in-progress

Re: [Python-Dev] Possible optimization for LOAD_FAST ?

or testing purposes. Perhaps a sys variable, plus command line option and/or environment variable? Although testing in an environment deliberately different from production is a recipe for hard to diagnose bugs. Michael -Barry ___ Python-Dev mailing l

Re: [Python-Dev] Possible optimization for LOAD_FAST ?

en (python 2) however. I don't recall monkey patching anything other than open and raw_input myself but I *bet* there are people doing it for reasons they see as legitimate in tests. :-) Michael The only example I can think of might be the use of mocks for testing purposes,

Re: [Python-Dev] Possible optimization for LOAD_FAST ?

__.open and raw_input. https://www.google.com/codesearch?hl=en&lr=&q=%22patch%28%27__builtin__.%22+lang%3Apython+case%3Ayes :-) Michael Foord The only example I can think of might be the use of mocks for testing purposes, but even there I'd prefer to inject the mock into the module I

Re: [Python-Dev] [Python-checkins] devguide: Strip out all generic svn instructions from the FAQ. It's not only

d them when they ask the questions. It sounds like it's working! :-) All the best, Michael Foord The copy of the dev FAQ on the website has not been touched, so me cutting this stuff out so I know what has and has not been covered has no permanent impact. Plus having the devguide on

Re: [Python-Dev] Summary of Python tracker Issues

20138 (+80) total 22639 (+56) Nice work everyone. :-) At this rate we'll be down to zero open issues in only 2 years. ;-) 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

Re: [Python-Dev] API refactoring tracker field for Python4

en someone else adds themselves as nosy. 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 __

Re: [Python-Dev] API refactoring tracker field for Python4

see how many users are affected by an issue (or have declared that at least). Not sure if this sends you email, but I'm pretty sure it is different to subscribing to an issue - which is nice. Sometimes I care about an issue but can neither fix it myself nor want to receive every email fr

Re: [Python-Dev] API refactoring tracker field for Python4

On 07/01/2011 19:22, Guido van Rossum wrote: On Fri, Jan 7, 2011 at 11:15 AM, Michael Foord wrote: On 07/01/2011 19:11, Guido van Rossum wrote: On Fri, Jan 7, 2011 at 10:36 AM, Alexander Belopolsky wrote: -1 on the "star system" for the tracker The tracker on Google Code uses

Re: [Python-Dev] Summary of Python tracker Issues

20138 (+80) total 22639 (+56) Nice work everyone. :-) At this rate we'll be down to zero open issues in only 2 years. ;-) Michael Open issues with patches: 1045 Issues opened (40) == #4188: test_threading hang when running as verbose http://bugs.python.org/issu

Re: [Python-Dev] PEP 3333: wsgi_string() function

es-of-a-known-encoding are not really that important to the WSGI case.) I think the language moratorium was not the only objection to the inclusion of a third string type in Python (the "screwed string" - safe to treat neither as bytes nor as text). I recall objections in principle too

Re: [Python-Dev] devguide: Add an intermediate task of helping triage issues (not to be confused with the

to write an elaborate unit test reproducing, for example, a timing issue involving Unix signals and the IO stack ;) Fair enough. I will remove it. Well, *often* a test that exposes the issue can be written - and if so it is a useful exercise (surely). Michael __

Re: [Python-Dev] devguide: Add an intermediate task of helping triage issues (not to be confused with the

On 10/01/2011 19:31, Antoine Pitrou wrote: Le lundi 10 janvier 2011 à 19:26 +, Michael Foord a écrit : Fair enough. I will remove it. Well, *often* a test that exposes the issue can be written - and if so it is a useful exercise (surely). Yes, well, that's a matter of "usefu

Re: [Python-Dev] "unit test needed"

is a bug and for RFEs, it should be set when a decision to include cannot be made without an implementation. Agree. "Patch needed" applies if the patch is incomplete, and if it lacks tests then it is incomplete. Michael While there is no agreement on whether the bug is valid or whethe

Re: [Python-Dev] [Python-checkins] r87980 - in python/branches/py3k/Lib/importlib: _bootstrap.py abc.py

party developers are free to create whatever use cases they want for annotations) so annotations are being kept out of the standard library. Particularly given that they were untested and unused. All the best, Michael Foord -jJ On Wed, Jan 12, 2011 at 9:31 PM, raymond.hettinger wrote

Re: [Python-Dev] devguide: Cover how to (un-)apply a patch.

ands (of svn, Hg and bzr) are basically straightforward (and cross-platform). To me it is tinkering with the patch command that is arcane... 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

Re: [Python-Dev] devguide: Cover how to (un-)apply a patch.

hg and bzr. Using patch is not going to work on Windoze unless cygwin has been installed. Michael S ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/opti

Re: [Python-Dev] devguide: Cover how to (un-)apply a patch.

On 19/01/2011 19:47, Antoine Pitrou wrote: On Wed, 19 Jan 2011 19:20:01 +0100 Michael Foord wrote: On 19/01/2011 19:10, s...@pobox.com wrote: Antoine> Ok, thank you but... are you suggesting something or not? Yes. Keep the vcs command recommendations simple. At least mention idi

Re: [Python-Dev] Beta version of the new devguide

start off ignorant and work there way up. I think a lot of people assume that unless they know C they can't contribute to Python. I don't know where the best place is but it would be good to make it *clear* that this isn't true. All the best, Michael Foord As for CPython/Pyt

Re: [Python-Dev] Location of tests for packages

I. It generally makes a few things slightly harder for me but not much. If we make a general policy decision to move all package tests out of their packages and into Lib/test (and actually do it) then fine, but I'm not overjoyed with a unilateral decision that unittest is special in this r

Re: [Python-Dev] Location of tests for packages

es whatsoever to the tree (but it's Georg's decision, of course). What Antoine meant is that we could make the change for 3.2.1 and don't need to delay 3.2. Michael Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http:

Re: [Python-Dev] Finally fix installer to add Python to %PATH% on Windows

a few "python newbies" on Windows who are also surprised / frustrated on learning that "python" on the command line doesn't work after installing python. All the best, Michael Foord One of said trainers is running a course inside my company right now and the training

Re: [Python-Dev] fcmp() in test.support

ty over assertAlmostEqual, the above makes me think it should probably be removed altogether, or added to unittest if it's still deemed important. Yes, get rid of it. Michael Foord +/- ? Eli ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] [Python-checkins] devguide: Add a document discussing the development cycle typically followed for

tly plural (include several individual features that comprise new functionality) but can also be pluralised; several functionalities where each new functionality comprises plural features. I would say that Brett's wording reads correctly here. Michael +occur. Currently this branch is kno

Re: [Python-Dev] Python merge module

tall the main Python msi as part of a suite with your installer, whether you build that installer in WiX and burn, or not. Michael ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python merge module

g stable component IDs is a challenge since it's difficult > to version the files on disk. > > Not sure why Michael thinks that a private location merge module > would provide no benefits to the user of the merge module. I hadn't thought it through fully, but the preceding para

Re: [Python-Dev] devguide: Basic instructions on how to generate a patch with hg for non-committers.

won't do people any favours if we try to pretend that isn't the case. This is quite true. (And after a while, the same goes for creating your own extensions, BTW.) And from the description it sounds like rdiff will be very useful for our usecase. Micha

Re: [Python-Dev] devguide: Basic instructions on how to generate a patch with hg for non-committers.

On 07/02/2011 14:28, Antoine Pitrou wrote: On Mon, 07 Feb 2011 13:27:31 + Michael Foord wrote: On 07/02/2011 12:25, Georg Brandl wrote: Am 07.02.2011 00:21, schrieb Nick Coghlan: On Mon, Feb 7, 2011 at 6:53 AM, Brett Cannon wrote: I would rather not have new hg users have to install

Re: [Python-Dev] API bloat

they don't *have to*, but c extension compatibility is one of the biggest problems for users of alternative implementations. Hopefully the stable ABI will improve this situation for the future, but realistically its going to be a few years before it has an appreciable effect. Michael

Re: [Python-Dev] API bloat

worrying about an implementation detail of CPython. Actually the opposite. Users tend to be very unsympathetic when extensions they depend on don't work with alternative implementations (I speak from experience). Michael Cheers, Nick. -- http://www.voidspace.org.uk/ May you do good an

Re: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py

nsing" problem. :-) That's not sufficient (IIUC). The code *authors* (copyright owners) have to agree, and probably have to sign contributor agreements. :-) Twisted have gone through an IP management process already I believe, so it is certainly possible. Michael Regards Antoine. ___

Re: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py

*not* to be twisted, just because of the prominence of twisted within the python ecosystem. All the best, Michael Foord cheers James -- 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 t

Re: [Python-Dev] 3.2.0

ad to errors like the two above. How are those errors? Surely what matters is that the following *is* True: >>> (3, 2, 0) >= (3, 2) True >>> "3.2.0" >= "3.2" True I'm +1 for the change, but happy for it to happen for 3.3.0 given how close

Re: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2

right thing" and store binary data in Python 2 byte strings can't use Python 2 pickles from Python 3. It also means that only ascii data can be unpickled. A custom pickler / unpickler is suggested as the solution in this issue. All the best, Michael Foord I use the encoding "latin

Re: [Python-Dev] Finding buildbot failures

tages 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. Michael Thanks, Vinay Sajip ___ Python-Dev mailing list

Re: [Python-Dev] Finding buildbot failures

nd the buildbot docs) for ways to generate more complete reports or to integrate junitxml with builbot, but failed. Can you point me at anything? All the best, Michael Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/m

Re: [Python-Dev] Finding buildbot failures

itxml itself, so I'd probably go that way. However if you really need junitxml for something, there are tools for converting between subunit and junitxml. Thanks Jean-Paul. Michael Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org http:

Re: [Python-Dev] Mercurial conversion repositories

ppens". It will lead to odd conversations like: "is trunk the trunk?", "no trunk is what used to be trunk, default is now trunk". Renaming it "legacy-trunk" is no less precise, but more explicative. Michael Regards Antoine.

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

hould*), but we still need to decide whether we will add python2 / python3 binaries. Michael Foord Thanks, Kerrick Staley ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

time didn't come (if so, I'd agree). Python3 *is* unfortunately a new and incompatible programming language, Only partly true. It's a new version of an existing language that introduces backwards incompatible changes. It *isn't* a new language and I write code that happily runs under

Re: [Python-Dev] Improvements for Porting C Extension from 2 to 3

is responsible for... 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 __

Re: [Python-Dev] unittest.main() --catch parameter

by anyone. I don't understand this sentence, sorry. All the best, Michael Foord Usage: tests.py [options] [test] [...] Options: -h, --help Show this message -v, --verboseVerbose output -q, --quiet Minimal output -f, --failfast Stop on first failure -c, --c

Re: [Python-Dev] unittest.main() --catch parameter

On 03/03/2011 21:54, anatoly techtonik wrote: On Thu, Mar 3, 2011 at 10:44 PM, Michael Foord wrote: On 03/03/2011 20:31, anatoly techtonik wrote: I am looking at --help of test runner and asking the question: what is the use case for -c, --catch option? It catches keyboard interrupt and

Re: [Python-Dev] unittest.main() --catch parameter

On 04/03/2011 01:33, anatoly techtonik wrote: On Thu, Mar 3, 2011 at 11:58 PM, Michael Foord wrote: Without this option interrupting a test run with a ctrl-c kills the run and reports nothing. Seeing an unexpected failure or error during a long test run and having to wait to the end of the

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

n't modify those installers for our own distributions. All the best, Michael Foord [1] Activestate and Enthought in particular. Plus possibly others I'm not aware of. Cheers, Nick. PEP: 394 Title: The "python" command on Unix-Like Systems Version: $Revision: 88743 $ Last-

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

On 04/03/2011 13:21, Nick Coghlan wrote: On Fri, Mar 4, 2011 at 10:59 PM, Michael Foord wrote: Should any of this also apply to Mac OS X and Windows? Any platform that considers itself "unix-like" in this context can decide to follow it, we aren't fussy (e.g. Cygwin and the *n

Re: [Python-Dev] PEP 395: Module Aliasing

don't even include actual scripts in my packages any more, I just add the right goo to setup.py and let distutils DTRT: That (below) is not distutils it is setuptools. distutils just uses `scripts=[...]`, which annoyingly *doesn't* work with setuptools. Michael Foord

Re: [Python-Dev] PEP 395: Module Aliasing

On 04/03/2011 17:24, Barry Warsaw wrote: On Mar 04, 2011, at 05:35 PM, Michael Foord wrote: That (below) is not distutils it is setuptools. distutils just uses `scripts=[...]`, which annoyingly *doesn't* work with setuptools. Sure, but that'll all be moot when distutils2 is integ

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

thon3.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 o

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

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 b

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

led 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.void

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

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 &qu

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

thon3.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

Re: [Python-Dev] contributors survey?

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 kno

Re: [Python-Dev] Finding buildbot failures

ddressed? 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

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 Foord 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 relate

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

icky point is the contribution agreement, but I wouldn't expect trouble with my employer. Michael ___ 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: More miscellaneous review comments.

rather see a manual checklist than a suggestion to use "make patchcheck" (which I never use). I find it helpful. Why do you say it is a "poor tool"? Michael At least a manual checklist is able to explain you why the items are recommended. Regards Antoine. __

Re: [Python-Dev] Finding buildbot failures

On 05/03/2011 22:18, "Martin v. Löwis" wrote: 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

Re: [Python-Dev] devguide: More miscellaneous review comments.

On 06/03/2011 17:05, Antoine Pitrou wrote: On Sun, 06 Mar 2011 16:52:54 + Michael Foord wrote: On 06/03/2011 13:14, Antoine Pitrou wrote: On Sun, 6 Mar 2011 21:58:24 +1000 Nick Coghlan wrote: On Sun, Mar 6, 2011 at 7:37 PM, ned.deily wrote: http://hg.python.org/devguide/rev

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

On 06/03/2011 02:33, Mark Hammond wrote: 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 Hammond wrote: I think this discussion should be divorced from this PEP and taken up with the discussion about the PATH and the

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

ents and strong opponents (I think Mark being a strong proponent of such exclusion, and Michael being a strong opponent). Guido said he would like to see the PEP address Windows, although that requires *some* consensus. Paul Moore was +1 on Windows being included. Mark did accept that some o

Re: [Python-Dev] hg diff

On 07/03/2011 18:32, Thomas Wouters wrote: On Mon, Mar 7, 2011 at 10:04, Barry Warsaw > wrote: On Mar 07, 2011, at 06:31 PM, Antoine Pitrou wrote: >On Mon, 7 Mar 2011 12:04:18 -0500 >Barry Warsaw mailto:ba...@python.org>> wrote: >> On Mar 07, 2011, at

Re: [Python-Dev] hg diff

On 07/03/2011 18:35, Michael Foord wrote: On 07/03/2011 18:32, Thomas Wouters wrote: On Mon, Mar 7, 2011 at 10:04, Barry Warsaw <mailto:ba...@python.org>> wrote: On Mar 07, 2011, at 06:31 PM, Antoine Pitrou wrote: >On Mon, 7 Mar 2011 12:04:18 -0500 >Barry W

Re: [Python-Dev] PyCObject_AsVoidPtr removed from python 3.2 - is this documented?

n() - Ezio would know best as he implemented this feature though. 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.

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

ts to have a shebang line that "does the right thing" on *nix and Windows systems while still offering maximum flexibility on Windows. "/usr/bin/env python" is popular too, and it would be nice to support the new aliases (or binaries) being created by the pep (python2 /

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

On 07/03/2011 17:21, Sridhar Ratnakumar wrote: On Sunday, March 6, 2011 at 9:53 AM, Brian Curtin wrote: On Sun, Mar 6, 2011 at 11:41, Michael Foord<mailto:fuzzy...@voidspace.org.uk>>wrote: - Hide quoted message - I would like to see us create version specific (i.e. pyt

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

be *ended* by the creation of the installer. A typical install on a Unix-like system adds various other utilities to the path that merely adding the top-level of your Python install on Windows still doesn't add. In particular distutils installed scripts go into a subdirectory of your Pyth

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

ion is that "python foo.py" *will* then lookup the shebang to run the "right" version of python, defaulting to the last installed version of python (I assume). All the best, Michael Foord ___ Python-Dev mailing list P

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

On 07/03/2011 22:48, Mark Hammond wrote: On 8/03/2011 7:33 AM, Michael Foord wrote: A python launcher as you describe is a *great* idea. A few concerns: * we're missing an opportunity to do something easy (Martin is happy to modify the installer and says it is easy) for something that m

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

On 07/03/2011 23:52, Greg Ewing wrote: Michael Foord wrote: - I doubt calling it python.exe will fly, but I'm not sure. If so what will you call what is currently 'python.exe'? - if not then "python foo.py" on the command line will *still* not work... However,

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

st 3.x, etc.). If it doesn't have a version, find the latest 2.x or latest any version as above, per the most recent relevant PEP. Open question is what to do if the script clearly requests version 2.6 but only 2.5, 2.7 and 3.2 are installed, or requests 2.x but only 3.x is installed; I cou

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

ws Installer can process them, it will even keep the highest version of the file in place. -- Michael Urman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/op

Re: [Python-Dev] PEP 395: Module Aliasing

On 09/03/2011 16:30, P.J. Eby wrote: At 05:35 PM 3/4/2011 +, Michael Foord wrote: That (below) is not distutils it is setuptools. distutils just uses `scripts=[...]`, which annoyingly *doesn't* work with setuptools. Er, what? That's news to me. Could you file a bug report

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

On 07/03/2011 21:33, Glenn Linderman wrote: On 3/7/2011 4:00 PM, Michael Foord wrote: On 07/03/2011 23:52, Greg Ewing wrote: Michael Foord wrote: - I doubt calling it python.exe will fly, but I'm not sure. If so what will you call what is currently 'python.exe'? - if no

Re: [Python-Dev] pydoc for named tuples is missing methods

recognise the private methods isn't. 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.sqlit

[Python-Dev] Mercurial workflow: merging from 3.2

o 3.3 as these unmerged changesets appear as conflicts. If you do work in 3.2 (or earlier) please merge those changesets to default. 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 f

Re: [Python-Dev] pydoc for named tuples is missing methods

lightly* ugly but not too bad: class Bar(Foo): thing = Foo.thing thing.baz = 3 All the best, Michael Maybe this is another reason to have a hook somewhere in the standard class creation process that allows a descriptor to initialise itself with knowledge of its environment. -- http://w

Re: [Python-Dev] Module version variable

on info: pkgutil.get_version(module). Under the hood this looks for __version__ as one of the first places to find version info. All the best, Michael Foord -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/lis

Re: [Python-Dev] Module version variable

umber that I would like to remove. Standard library modules should be versioned by the release of Python they are packaged with (unless they are externally maintained I guess) and so should preferably *not* carry version info. All the best, Michael This is obviously out of date and this varia

Re: [Python-Dev] Module version variable

On 16/03/2011 14:33, R. David Murray wrote: On Wed, 16 Mar 2011 13:33:20 -0400, Michael Foord wrote: On 16/03/2011 12:39, Alexander Belopolsky wrote: I was editing the turtle module (for issue11571, if you are interested) when I noticed that it has the following line: _ver = "turtle

Re: [Python-Dev] Module version variable

On 16/03/2011 15:00, Raymond Hettinger wrote: On Mar 16, 2011, at 11:33 AM, R. David Murray wrote: On Wed, 16 Mar 2011 13:33:20 -0400, Michael Foord wrote: On 16/03/2011 12:39, Alexander Belopolsky wrote: I was editing the turtle module (for issue11571, if you are interested) when I

Re: [Python-Dev] Hg: inter-branch workflow

separately as developers merging their own changes now have to handle unrelated conflicts caused by someone else). What it should be possible for us to do is create scripts that will auto do the "reverse merge" for changes that shouldn't be forward ported. All the best, Mic

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

launcher do the 'right thing'. If there was general agreement, I'd be happy for the PEP to support that variation. Yes please. :-) Michael Cheers, Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/m

Re: [Python-Dev] VM and Language summit info for those not at Pycon (and those that are!)

n Cython? The Cython project would surely provide collective help through its user mailing list, code review, etc. Assuming its possible it sounds like an awesome project. Michael Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail

Re: [Python-Dev] Second draft: PEP397: Python launcher for Windows

le to *automatically* do the right thing for the 'w' variants.) All the best, Michael Most of the changes should not be too controversial, but of note: * I've added lots of discussion about the child-process issue and the wording now states, basically, that in-process is not feasible, but

Re: [Python-Dev] Second draft: PEP397: Python launcher for Windows

On 23/03/2011 14:52, Mike Driscoll wrote: On Tue, Mar 22, 2011 at 2:12 PM, Michael Foord wrote: On 22/03/2011 07:21, Mark Hammond wrote: Hi all, I've made some changes to the draft PEP and checked it into the PEP repository as PEP397. The reference implementation is currently

Re: [Python-Dev] new blog

t new features or interesting fixes), but I definitely don't have a Blogger account - and would like not to create one. (or does it work with Google accounts) Yep, a blogger account is a google account (and vice-versa). Michael Regard

Re: [Python-Dev] Second draft: PEP397: Python launcher for Windows

On 23/03/2011 01:30, Mark Hammond wrote: On 23/03/2011 6:12 AM, Michael Foord wrote: On 22/03/2011 07:21, Mark Hammond wrote: Hi all, I've made some changes to the draft PEP and checked it into the PEP repository as PEP397. The reference implementation is currently being tracked at

Re: [Python-Dev] Trimming "make quicktest"

e buildbottest". -j doesn't pass on several of the flags to its subprocesses (e.g. warning settings I believe), so it shouldn't be the default. It's still very useful though. All the best, Michael Regards Antoine. ___ Python-Dev

Re: [Python-Dev] Python 3.3 release schedule posted

king on a PEP but it stalled waiting for the transition to mercurial and I don't know if he is volunteering to pick up the PEP again now that has happened. All the best, Michael Foord cheers, Georg ___ Python-Dev mailing list Python-Dev@python.

Re: [Python-Dev] I plan to push faulthandler into Python 3.3 in one week

right). If you have already signed a contributor agreement then there is no need for further discussion of how your contributions are licensed for inclusion in Python, that is already dealt with. All the best, Michael Foord Regards, Martin ___ Python-D

<    5   6   7   8   9   10   11   12   13   14   >