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

On 24/01/2011 19:46, Raymond Hettinger wrote: Right now, the tests for the unittest package are under the package directory instead of Lib/test where we have most of the other tests. There are some other packages that do the same thing, each for their own reason. I think we should develop a st

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

On 24/01/2011 23:14, "Martin v. Löwis" wrote: This isn't a critical issue (nothing is broken) but we're a week from another release candidate, so the new Py3.2 package organization (unittest was flat in Py3.1 and its test were under Lib/test) is about to become a de-facto decision that will be ha

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

On 02/02/2011 11:04, Sandro Tosi wrote: On Wed, Jan 26, 2011 at 23:20, brett.cannon wrote: +The in-development branch is where new functionality and semantic changes new functionalities (dunno if it's plural in english or not)? It's an odd one. Functionality can be implicitly plural (include

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

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 an extension just to get a simple workflow going. I may still keep my Rdiff-based FAQ entry around as an

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

On 09/02/2011 14:00, Benjamin Peterson wrote: 2011/2/9 Mark Shannon: OK, so UnicodeError_xxx is important for codecs, but surely this sort of argument could be made for lots of things. Don't forget that for each function added to the API, all other implementations have to support it forever. Th

Re: [Python-Dev] API bloat

On 09/02/2011 13:59, Nick Coghlan wrote: [snip...] And, since the C API has never been anywhere near as tightly controlled as the language definition, alternative implementations are going to garner more sympathy if they restrict their concerns to the growth of the stable ABI rather than worrying

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

On 13/02/2011 14:23, Antoine Pitrou wrote: On Sun, 13 Feb 2011 19:18:52 +1000 Nick Coghlan wrote: If there is an essential subset of the API that the Twisted devs think would be a suitable replacement for asyncore, while providing a more straightforward migration path into Twisted itself, then

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

On 25/02/2011 18:10, Vinay Sajip wrote: What's the easiest way of finding which tests failed on buildbot builds? I mean, is there anything easier than using the Web interface to browse to failing builds and then looking at the stdio output in a browser? That's one of the big advantages that Jen

Re: [Python-Dev] Finding buildbot failures

On 25/02/2011 19:00, exar...@twistedmatrix.com wrote: On 06:47 pm, fuzzy...@voidspace.org.uk wrote: On 25/02/2011 18:10, Vinay Sajip wrote: What's the easiest way of finding which tests failed on buildbot builds? I mean, is there anything easier than using the Web interface to browse to failin

Re: [Python-Dev] Finding buildbot failures

On 26/02/2011 13:46, exar...@twistedmatrix.com wrote: On 01:16 pm, fuzzy...@voidspace.org.uk wrote: On 25/02/2011 19:00, exar...@twistedmatrix.com wrote: On 06:47 pm, fuzzy...@voidspace.org.uk wrote: On 25/02/2011 18:10, Vinay Sajip wrote: What's the easiest way of finding which tests failed o

Re: [Python-Dev] Mercurial conversion repositories

On 26/02/2011 14:44, Antoine Pitrou wrote: Le dimanche 27 février 2011 à 00:42 +1000, Nick Coghlan a écrit : On Sat, Feb 26, 2011 at 7:29 PM, "Martin v. Löwis" wrote: I think people should simply get used to the idea that "default" is /the/ main branch in Mercurial (*). It's even easier to rem

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

On 02/03/2011 14:04, James Y Knight wrote: On Mar 2, 2011, at 8:23 AM, Sandro Tosi wrote: On Wed, Mar 2, 2011 at 13:56, Piotr Ożarowski wrote: [Sandro Tosi, 2011-03-02] On Wed, Mar 2, 2011 at 10:01, Piotr Ożarowski wrote: I co-maintain with Matthias a package that provides /usr/bin/python

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

On 03/03/2011 13:45, Benjamin Peterson wrote: 2011/3/3 Sümer Cip: 1) define PyModuleDef 2) change PyString_AS_STRING calls to _PyUnicode_AsString Aside: Please don't use private APIs in Python extensions. Esp. the above Unicode API is likely going to be phased out. You're better off, using Py

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

On 04/03/2011 17:45, Kerrick Staley wrote: > Right, but on Mac OS X we do put a "python3" on the path but not a "python2". We also > create "python2.x" and "python3.x" variants. The PEP makes a recommendation for all *nix platform, which includes Mac OS X. I was not aware that Apple preinstall

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

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

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] devguide: More miscellaneous review comments.

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/ad3278cfc5f6 changeset: 376:ad3278cfc5f6 user:Ned Deily date:Sun Mar 06 01:37:13 2011 -0800 su

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

On 06/03/2011 21:36, "Martin v. Löwis" wrote: I should've mentioned that I'd like a consensus (or a lack of protest) on the changes related to these snippets: [...] -"Exclusions of MS Windows" I think you won't get consensus on that: there are strong proponents and strong opponents (I think

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?

On 07/03/2011 19:45, Terry Reedy wrote: On 3/7/2011 9:47 AM, Antoine Pitrou wrote: On Mon, 7 Mar 2011 19:14:55 +1000 Nick Coghlan wrote: On Mon, Mar 7, 2011 at 6:36 PM, John Arbash Meinel wrote: Especially since, AIUI, deprecations are suppressed by default now. True, but developers are

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

On 07/03/2011 05:19, Mark Hammond wrote: [snip...] (B) declare the Python version in the content of the script file. This cures most of the ripple effects of the above, but requires a "launcher" or "wrapper" program to be designed, implemented, and installed. There are a variety of subsolutions

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] 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

On 15/03/2011 07:59, Nick Coghlan wrote: On Tue, Mar 15, 2011 at 6:20 PM, Eric Smith wrote: The field names are not always under direct control of the developer, such as when they are database column names. Not that using _replace completely gets rid of this problem, but I agree with Raymond's

[Python-Dev] Mercurial workflow: merging from 3.2

Hey all, I realise that we're still getting used to the workflows, but there are currently unmerged changesets (in test_peepholer and friends) on the 3.2 branch that seem to have been applied *separately* to 3.3. This causes problems for anyone else who wants to merge changes from 3.2 to 3.3 a

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

On 15/03/2011 19:57, Greg Ewing wrote: Nick Coghlan wrote: The challenge here is how it would interact with inheritance. pydoc couldn't use normal attribute lookup, it would have to walk the MRO manually, This is an instance of a pattern that I've encountered a few times in things that I've d

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

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 1.1b- - for Python 3.1 - 4. 5. 2009" unittest also has an outdated (and unmaintained) version number that I

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

On 20/03/2011 09:58, Mark Hammond wrote: On 20/03/2011 8:36 PM, Terry Reedy wrote: On 3/20/2011 3:22 AM, Glenn Linderman wrote: On 3/19/2011 7:38 PM, Mark Hammond wrote: [snip] As both a writer and reader, I would like to just add, for instance, #! python3 (or 3.3 or whatever) and have the la

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

On 21/03/2011 17:47, Stefan Behnel wrote: Stefan Behnel, 21.03.2011 11:58: Guido van Rossum, 21.03.2011 03:46: Have you tried replacing selected stdlib modules with their Cython-optimized equivalents in some of the NumPy/SciPy distros? (E.g. what about Enthought's Python distros?) Depending on

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

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 http://bugs.python.org/issue11629. Hey Mark, One way of supporting alternative implementa

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

On 23/03/2011 17:26, Antoine Pitrou wrote: Le mercredi 23 mars 2011 à 13:19 -0400, Doug Hellmann a écrit : On Mar 23, 2011, at 10:03 AM, Antoine Pitrou wrote: On Mon, 21 Mar 2011 21:50:53 -0400 Doug Hellmann wrote: We are nearly ready to launch the new blog for python-dev. Is any core dev a

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"

On 23/03/2011 18:42, Antoine Pitrou wrote: On Wed, 23 Mar 2011 14:29:22 -0400 David Bolen wrote: Nick Coghlan writes: On Thu, Mar 24, 2011 at 12:36 AM, Antoine Pitrou wrote: You mean in the "-j" option itself or in "make test"? I was actually suggesting that -j be the *default* in regrtes

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

Re: [Python-Dev] dependency injection for testing [was Python 3.3 release schedule posted]

se within our own tests would be a better solution in my opinion. All the best, Michael Foord I proposed this on the list like a year ago. Somebody else said he was planning a PEP... not done yet, I guess. Digging the archive: <http://mail.python.org/pipermail/python-dev/2010-Apri

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

On 24/03/2011 02:06, Jesus Cea wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23/03/11 20:56, Georg Brandl wrote: For 3.3, I'd like to revive the tradition of listing planned large-scale changes in the PEP. I want to integrate dependence injection in the stdlib, specially in libs crea

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

user basis. A single global location (for shared installs) or a single per-user location for per-user installs would seem to be sensible if the config file route is chosen. All the best, Michael Foord ___ Python-Dev mailing list Python-Dev@

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

On 24/03/2011 03:02, Mark Hammond wrote: On 24/03/2011 1:20 PM, Michael Foord wrote: On 24/03/2011 00:44, Dj Gilcrease wrote: On Wed, Mar 23, 2011 at 8:14 PM, Mark Hammond wrote: If you guys (or anyone) would like to agree on some precise rules for both the location of the config file and its

Re: [Python-Dev] Proposal for Python 3.3: dependence injection

On 24/03/2011 17:46, Andrew McNabb wrote: On Thu, Mar 24, 2011 at 10:12:18AM -0700, Guido van Rossum wrote: On Thu, Mar 24, 2011 at 9:46 AM, Benjamin Peterson wrote: I want to test the dev community interest in modifying the stdlib to ease dependence injection. I, for one, am -1. Code shouldn

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

On 28/03/2011 11:35, Nick Coghlan wrote: On Mon, Mar 28, 2011 at 8:13 PM, Paul Moore wrote: For people in the "clean history" school, I'd recommend looking at mq for your personal use. But it's definitely an advanced feature of Mercurial, so it may be better to understand core Mercurial (and at

[Python-Dev] Security implications of pep 383

otherwise read in and decoded from an assumed-utf8 source with surrogate escaping, the surrogate escape decoded names will not match the properly decoded blacklisted names. All the best, Michael Foord -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for

Re: [Python-Dev] Issue 11715: building Python from source on multiarch Debian/Ubuntu

On 01/04/2011 11:46, Georg Brandl wrote: Am 31.03.2011 19:35, schrieb Éric Araujo: I would like to apply this patch (or its moral equivalent) to all active, affected branches of Python, meaning 2.5 through 2.7, and 3.1 through 3.3, as soon as possible. Without this, it will be very difficult fo

Re: [Python-Dev] Issue 11715: building Python from source on multiarch Debian/Ubuntu

On 01/04/2011 13:07, Antoine Pitrou wrote: On Fri, 01 Apr 2011 07:57:53 -0400 Eric Smith wrote: On 4/1/2011 6:46 AM, Georg Brandl wrote: Am 31.03.2011 19:35, schrieb Éric Araujo: I would like to apply this patch (or its moral equivalent) to all active, affected branches of Python, meaning 2.5

Re: [Python-Dev] Issue 11715: building Python from source on multiarch Debian/Ubuntu

On 01/04/2011 13:32, Georg Brandl wrote: Am 01.04.2011 13:57, schrieb Michael Foord: On 01/04/2011 11:46, Georg Brandl wrote: Am 31.03.2011 19:35, schrieb Éric Araujo: I would like to apply this patch (or its moral equivalent) to all active, affected branches of Python, meaning 2.5 through

Re: [Python-Dev] Issue 11715: building Python from source on multiarch Debian/Ubuntu

sion there either. :-) (Other than no *need* to bother, which doesn't answer the question of what if developers *want* to fix errors in the docs - and I'm in favour of *permitting* but not requiring it.) All the best, Michael Foord Regards -- http://www.voidspace.org.uk/ May you

Re: [Python-Dev] Issue 11715: building Python from source on multiarch Debian/Ubuntu

On 01/04/2011 14:49, Éric Araujo wrote: As far as I can tell there was no clear decision there either. :-) Not my understanding: http://mail.python.org/pipermail/python-dev/2010-August/103351.html That was about whether the release manager should backport doc fixes from 2.7 to the 2.6 branch

Re: [Python-Dev] Policy for making changes to the AST

On 04/04/2011 18:05, fwierzbi...@gmail.com wrote: As a re-implementor of ast.py that tries to be node for node compatible, I'm fine with #1 but would really like to have tests that will fail in test_ast.py to alert me! A lot of tools that work with Python source code use ast - so even though

Re: [Python-Dev] [Python-checkins] cpython: Revert the Lib/test/test_bigmem.py changes from commit 17891566a478 (and a

On 25 March 2011 17:09, Antoine Pitrou wrote: > On Fri, 25 Mar 2011 17:44:26 +0100 > Éric Araujo wrote: > > Hi, > > > > > changeset: 68921:11dc3f270594 > > > user:Thomas Wouters > > > date:Fri Mar 25 11:42:37 2011 +0100 > > > summary: > > > Revert the Lib/test/test_bigmem.py

Re: [Python-Dev] Supporting Visual Studio 2010

On 04/04/2011 23:21, Antoine Pitrou wrote: On Mon, 04 Apr 2011 23:40:33 +0200 "Martin v. Löwis" wrote: - users have expressed concerns that they constantly need to upgrade VS releases when developing for Python. Isn't that kind of a misguided argument? It's not Python who decides the lifecy

Re: [Python-Dev] Supporting Visual Studio 2010

On 05/04/2011 00:12, Scott Dial wrote: On 4/4/2011 6:43 PM, Michael Foord wrote: Won't that still be an issue despite the stable ABI? Extensions on Windows should be linked to the same version of MSVCRT used to compile Python - and every time we switch version of Visual Studio it is us

Re: [Python-Dev] PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements

On 05/04/2011 20:57, Raymond Hettinger wrote: [snip...] [Brett] (sorry, Raymond, for picking on heapq, but is was what bit the PyPy people most recently =). No worries, it wasn't even my code. Someone donated it. The was a discusion on python-dev and collective agreement to allow it to have s

Re: [Python-Dev] PEP 396, Module Version Numbers

On 06/04/2011 15:26, Nick Coghlan wrote: On Wed, Apr 6, 2011 at 6:22 AM, Glenn Linderman wrote: With more standardization of versions, should the version module be promoted to stdlib directly? When Tarek lands "packaging" (i.e. what distutils2 becomes in the Python 3.3 stdlib), the standardise

Re: [Python-Dev] PEP 396, Module Version Numbers

On 07/04/2011 12:10, Michael Foord wrote: On 06/04/2011 15:26, Nick Coghlan wrote: On Wed, Apr 6, 2011 at 6:22 AM, Glenn Linderman wrote: With more standardization of versions, should the version module be promoted to stdlib directly? When Tarek lands "packaging" (i.e. what

Re: [Python-Dev] PEP 396, Module Version Numbers

On 07/04/2011 12:59, Nick Coghlan wrote: On Thu, Apr 7, 2011 at 9:10 PM, Michael Foord wrote: I really dislike this way of specifying the version. For a start it is really ugly. More importantly it means the version information is *only* available if the package has been installed by

Re: [Python-Dev] Test cases not garbage collected after run

execution? (Any failure tracebacks etc stored by the TestResult would also have to not keep the test alive.) My only concern would be backwards compatibility due to the change in behaviour. All the best, Michael Foord Thanks, Fabio ___ Python-De

Re: [Python-Dev] Test cases not garbage collected after run

On 07/04/2011 20:18, Robert Collins wrote: On Fri, Apr 8, 2011 at 4:49 AM, Michael Foord wrote: You mean that the test run keeps the test instances alive for the whole test run so instance attributes are also kept alive. How would you solve this - by having calling a TestSuite (which is how a

Re: [Python-Dev] [GSoC] Developing a benchmark suite (for Python 3.x)

://lists.ironpython.com/listinfo.cgi/users-ironpython.com All the best, Michael Foord ___ 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

Re: [Python-Dev] funky buildbot problems again...

On 07/04/2011 21:31, Bill Janssen wrote: My Intel Snow Leopard 2 build slave has gone into outer-space again. [snip...] So it's been spinning its wheels for 3 days. Sure looks like the connection attempt is failing, for some reason. I'm using the stock Twisted that comes with Snow Leopard -- tr

Re: [Python-Dev] [GSoC] Developing a benchmark suite (for Python 3.x)

xclude Psyco, if it was still alive?) Well, sure - but within the scope of a GSOC project limiting it to "core python" seems like a more realistic goal. Adding cython later shouldn't be an issue if someone is willing to do the work. All the best, Michael Foord Regards Antoi

Re: [Python-Dev] [GSoC] Developing a benchmark suite (for Python 3.x)

On 08/04/2011 00:36, Anthony Scopatz wrote: On Thu, Apr 7, 2011 at 6:11 PM, Michael Foord mailto:fuzzy...@voidspace.org.uk>> wrote: On 07/04/2011 22:41, Antoine Pitrou wrote: On Thu, 07 Apr 2011 17:32:24 -0400 Tres Seavermailto:tsea...@palladion.com>

Re: [Python-Dev] Test cases not garbage collected after run

On 08/04/2011 02:10, Robert Collins wrote: On Fri, Apr 8, 2011 at 8:12 AM, Michael Foord wrote: On 07/04/2011 20:18, Robert Collins wrote: On Fri, Apr 8, 2011 at 4:49 AM, Michael Foord wrote: You mean that the test run keeps the test instances alive for the whole test run so instance

Re: [Python-Dev] [GSoC] Developing a benchmark suite (for Python 3.x)

7;t think doing this work should be part of the gsoc proposal. Considering it as a use case could be included in the infrastructure work though. All the best, Michael Foord Obviously, we'd have to integrate a build of the latest Cython development sources as well, but it's not like i

Re: [Python-Dev] Code highlighting in tracker

e way there with heuristics). Of course as always someone would have to do the work... On the other hand switching to *permitting* restructured-text submissions for tracker comments, with syntax highlighting for literal blocks (::), would be nice. :-) All the best, Michael Foord E

Re: [Python-Dev] AST Transformation Hooks for Domain Specific Languages

On 8 April 2011 12:29, Nick Coghlan wrote: > A few odds and ends from recent discussions finally clicked into > something potentially interesting earlier this evening. Or possibly > just something insane. I'm not quite decided on that point as yet (but > leaning towards the latter). > > The essen

Re: [Python-Dev] Bug? Can't rebind local variables after calling pdb.set_trace()

't receive fixes for issues like this. All the best, Michael Foord -- Djoume Salvetti Director of Development T:416.601.1999 x 249 www.trapeze.com <http://www.trapeze.com> twitter: trapeze 175 Bloor St. E., South Tower, Suite 900 Toronto, ON M4W 3R8 ___

<    3   4   5   6   7   8   9   10   11   >