Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

Eric Smith, 16.03.2011 04:12: On 3/15/2011 10:58 PM, Lennart Regebro wrote: On Tue, Mar 15, 2011 at 22:42, Guido van Rossum wrote: Fortunately there may not be any more such cases since no new major versions of Python 2 will be released. So I'm not sure what an update of PEP 5 will buy us. Th

[Python-Dev] Low-Level Encoding Behavior on Python 3

Hi everybody, We (me and Carl Meyer) did some experimentation with encoding behavior on Python 3. Carl did some hacking on getting virtualenv running on Python 3 and it turned out that his version of virtualenv did not work on Python 3 on my server either. So none of the virtulenv installati

Re: [Python-Dev] Low-Level Encoding Behavior on Python 3

Hi, > We (me and Carl Meyer) did some experimentation with encoding behavior > on Python 3. Carl did some hacking on getting virtualenv running on > Python 3 and it turned out that his version of virtualenv did not work > on Python 3 on my server either. So none of the virtulenv installation

Re: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?

On Tue, Mar 15, 2011 at 11:34 PM, Guido van Rossum wrote: > > Can you be specific? What is different between those RFCs? I finally got around to trying to backport some of the additional urljoin tests from http://bugs.python.org/issue1500504 (specifically, the additional ones Mike Brown provided)

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

On Wed, Mar 16, 2011 at 3:20 AM, Stefan Behnel wrote: > I still consider this is mostly a communication issue. If this change had > been properly written up, preferably in a PEP, including the reasoning for > it to get done, I think this whole discussion would not have been necessary. Yes, I thin

Re: [Python-Dev] [Python-checkins] cpython (2.7): #11565: Fix several typos. Patch by Piotr Kasprzyk.

On Wed, Mar 16, 2011 at 6:35 PM, ezio.melotti wrote: >  #11565: Fix several typos. Patch by Piotr Kasprzyk. Woo. cool. :) For a moment I got scared if Piotr was a spam bot or spellcheck bot. Yes, having correct spelling definitely helps. -- Senthil _

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

On 15 Mar, 2011, at 19:31, Greg Ewing wrote: > Martin v. Löwis wrote: > >> "There must be at least a one-year transition period between the >> release of the transitional version of Python and the release >> of the backwards incompatible version. > > I still think this is going to result in rud

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

Am 16.03.11 08:06, schrieb Nick Coghlan: On Wed, Mar 16, 2011 at 3:20 AM, Stefan Behnel wrote: I still consider this is mostly a communication issue. If this change had been properly written up, preferably in a PEP, including the reasoning for it to get done, I think this whole discussion would

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

On Wed, Mar 16, 2011 at 9:11 AM, "Martin v. Löwis" wrote: > Am 16.03.11 08:06, schrieb Nick Coghlan: >> >> On Wed, Mar 16, 2011 at 3:20 AM, Stefan Behnel >>  wrote: >>> >>> I still consider this is mostly a communication issue. If this change had >>> been properly written up, preferably in a PEP,

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

On 16 Mar, 2011, at 9:56, Nick Coghlan wrote: > > Interestingly, there is no definite time frame on the deprecation > warnings in that discussion. It was just the standard "deprecation in > X.Y means removal in X.Y+1" that lead to 3.2 no longer providing the > PyCObject API. Speaking of deprecat

Re: [Python-Dev] hooks: Add roundup integration hook.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/03/11 22:16, Georg Brandl wrote: > But in any case, by popular demand "fix" is now removed, and only > "close" and its variants actually closes the issue -- since there > is not much chance that you can write "close #12345" without > actually mea

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/03/11 22:16, Georg Brandl wrote: > But in any case, by popular demand "fix" is now removed, and only > "close" and its variants actually closes the issue -- since there > is not much chance that you can write "close #12345" without > actually mea

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 15/03/11 16:01, Lennart Regebro wrote: >> Python 2.6's API wasn't removed in 2.7. It remains available. > > But not in 3.2. And the new API appeared in 2.7. That is a deprecation > period of seven and a half months. I strongly opposed CObject depr

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

2011/3/16 Jesus Cea : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 08/03/11 22:16, Georg Brandl wrote: >> But in any case, by popular demand "fix" is now removed, and only >> "close" and its variants actually closes the issue -- since there >> is not much chance that you can write "clos

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)

On 03/09/2011 01:15 AM, Stefan Behnel wrote: I can confirm that the Cython project was as surprised of the PyCapsule change in Python 3.2 as (I guess) most other users, I was a bit surprised by it too, and I wrote the Capsule object. (Well, hacked up CObject to give it a new API.) PyCObjec

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/03/11 22:50, Guido van Rossum wrote: > I propose we try to find an "embedded blogger" who participates in > python-dev but is focused on making regular blog posts about the > interesting tidbits. There's no requirement to be complete (which I > t

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

I strongly opposed CObject deprecation in 2.7, as you can see in and mailing list archives. Interestingly enough, Lennart would have preferred a longer deprecation period, not a shorter one. So he would have been even more upset had the deprecation not be done

Re: [Python-Dev] Low-Level Encoding Behavior on Python 3

Hi, On 3/16/11 3:48 AM, Antoine Pitrou wrote: I may be mistaken, but you seem to conflate two things: encoding of file names, and encoding of file contents. I guess that virtualenv chokes on the file contents, but most of your argument seems related to encoding of file names (aka "filesystem enc

[Python-Dev] New contributors at the PyCon sprint

Hi all, As I'm sure you're all aware, the PyCon sprints are going on right now and will run for two more days. As a result, you may have noticed an increased number of patches over the last few days -- many of these were from first-time contributors. The turnout for the CPython sprint has been hug

Re: [Python-Dev] Low-Level Encoding Behavior on Python 3

Armin Ronacher, 16.03.2011 16:57: On 3/16/11 3:48 AM, Antoine Pitrou wrote: I may be mistaken, but you seem to conflate two things: encoding of file names, and encoding of file contents. I guess that virtualenv chokes on the file contents, but most of your argument seems related to encoding of f

Re: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/03/11 13:14, Paul Moore wrote: > None of my real code is affected either way, but it seems to me that > the removal of the comparison function option was (sadly) a case of > purity being allowed to beat practicality. Luckily, adding it back > wou

[Python-Dev] Module version variable

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" This is obviously out of date and this variable is not used anywhere in the module. I would simply delete it, but I wonder

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 Mar 16, 2011, at 12:39 PM, 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" > >This is obviously out of date and this variable is not use

Re: [Python-Dev] hooks: Add roundup integration hook.

Am 16.03.2011 15:31, schrieb Jesus Cea: > On 08/03/11 22:16, Georg Brandl wrote: >> But in any case, by popular demand "fix" is now removed, and only >> "close" and its variants actually closes the issue -- since there >> is not much chance that you can write "close #12345" without >> actually mean

Re: [Python-Dev] Module version variable

On 16/03/2011 12:53, Barry Warsaw wrote: On Mar 16, 2011, at 12:39 PM, 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" This is obviously ou

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

[Python-Dev] Generating patch files

I think I figured out how to generate a single patch for a clone that has all its changes on the default branch, comparing it with cpython's default branch. The command to generate the patch is hg diff -r'max(p1(min(outgoing())) or p2(max(merge() and branch(default' -r default If it's a br

Re: [Python-Dev] Module version variable

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 1.1b- - for Python 3.1 - 4. 5. 2009"

Re: [Python-Dev] Generating patch files

On Wed, Mar 16, 2011 at 1:49 PM, "Martin v. Löwis" wrote: > I think I figured out how to generate a single patch for > a clone that has all its changes on the default branch, > comparing it with cpython's default branch. The command to generate > the patch is > > hg diff -r'max(p1(min(outgoing()))

Re: [Python-Dev] Module version variable

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 noticed that it has the following line: >>

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 1.1b- -

Re: [Python-Dev] Generating patch files

I get "unknown revision" (listing the full expression text) when using Mercurial 1.6.3 (default version in Ubuntu 10.10). That version apparently supports revsets, but I'm not sure when the runtime evaluation of the command line arguments was added. Apparently shortly after Debian/Ubuntu includ

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 noticed

Re: [Python-Dev] Generating patch files

Am 16.03.11 15:20, schrieb "Martin v. Löwis": I get "unknown revision" (listing the full expression text) when using Mercurial 1.6.3 (default version in Ubuntu 10.10). That version apparently supports revsets, but I'm not sure when the runtime evaluation of the command line arguments was added.

[Python-Dev] Please retract my committer rights

I would like my committer rights to be retracted. I have been contributing to Python here and there for 10 years now, and it was a pleasant experience. Unfortunately, since about a year I have lots more things to do, and I won't be able to contribute anymore (I have not even started to learn mer

Re: [Python-Dev] Please retract my committer rights

On Mar 16, 2011, at 12:36 PM, Thomas Heller wrote: > I would like my committer rights to be retracted. > > I have been contributing to Python here and there for 10 years now, > and it was a pleasant experience. > > Unfortunately, since about a year I have lots more things to do, and > I won't b

Re: [Python-Dev] Generating patch files

In article <4d810f84.5060...@v.loewis.de>, "Martin v. Löwis" wrote: > Before you upgrade: give me some time to come up with a script that > uses Mercurial API instead to compute the revset and then invoke the > diff command. > > We must get something out of using a Python-based DVCS... Note the

Re: [Python-Dev] New contributors at the PyCon sprint

On 3/16/2011 12:10 PM, Brian Curtin wrote: Hi all, As I'm sure you're all aware, the PyCon sprints are going on right now and will run for two more days. As a result, you may have noticed an Yes. Emphasizing improved test coverage was a great idea. It is relatively easy and definitely needed,

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)

On Mar 16, 2011, at 11:07 AM, Jesus Cea wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 11/03/11 22:50, Guido van Rossum wrote: >> I propose we try to find an "embedded blogger" who participates in >> python-dev but is focused on making regular blog posts about the >> interesting

Re: [Python-Dev] Please retract my committer rights

On Wed, Mar 16, 2011 at 3:44 PM, Raymond Hettinger wrote: > > On Mar 16, 2011, at 12:36 PM, Thomas Heller wrote: > >> I would like my committer rights to be retracted. .. > You will be missed. > Thanks for all your efforts. > +1 In case anyone did not recognize Thomas by name, he contributed the

Re: [Python-Dev] Module version variable

On Wed, Mar 16, 2011 at 3:00 PM, Raymond Hettinger wrote: .. > The version number in the decimal module refers to the version of the > spec that is being complied with.  I would like that version number > to remain in the module. I mentioned this in my first post. If the version number of the s

Re: [Python-Dev] Module version variable

On 3/16/2011 5:54 PM, Alexander Belopolsky wrote: On Wed, Mar 16, 2011 at 3:00 PM, Raymond Hettinger wrote: .. The version number in the decimal module refers to the version of the spec that is being complied with. I would like that version number to remain in the module. I mentioned this i

[Python-Dev] Hg: inter-branch workflow

I think devguide's suggested interbranch workflow introduces too much complexity for too little payoff. If I need to make a fix to 3.2, I can't just fix it. I would need to also merge the changeset into 3.3 and then revert it, and then commit both. There is not much payoff to this style. It

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

On Wed, Mar 16, 2011 at 7:00 PM, Raymond Hettinger wrote: > I don't think the more complex workflow if worth it.  Mercurial is very user > friendly right out of the box will simple commands.  But as soon as you > require the branches to be inter-linked, you've made it much more difficult > to

[Python-Dev] Useful page in the Hg book

As I'm sure there will be plenty of erring as we get used to Hg: http://hgbook.red-bean.com/read/finding-and-fixing-mistakes.html For simple cases of attempting to push a single commit that gets rejected by the server, hg rollback/hg pull/hg commit/hg push/ may provide a cleaner history than doing

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

On Wed, Mar 16, 2011 at 7:00 PM, Raymond Hettinger wrote: > I think devguide's suggested interbranch workflow introduces too much > complexity for too little payoff. Raymond, We had this discussion many, many times before the transition. This *is* the way every single experienced Hg user has re

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

Larry Hastings wrote: The PyCapsule API is very much like the CObject API. In fact, in Python 3.1 CObject was actually implemented on top of PyCapsule. It should be very easy to support both APIs. Perhaps the code for the 3.1 implementation could be pulled out and made available to people i

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

On Wed, Mar 16, 2011 at 7:15 PM, Nick Coghlan wrote: > be handled. We're already deviating from common Hg practices in many > errors, please at least *try* this one for a few months before > throwing up your hands in disgust. s/errors/areas/ Cheers, Nick. -- Nick Coghlan   |   ncogh...@gmail.c

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

Hello, > I think devguide's suggested interbranch workflow introduces too much > complexity for too little payoff. > > If I need to make a fix to 3.2, I can't just fix it. I would need to also > merge the changeset into 3.3 and then revert it, and then commit both. There > is not much payof

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

On 16/03/2011 19:00, Raymond Hettinger wrote: I think devguide's suggested interbranch workflow introduces too much complexity for too little payoff. The ability to merge between branches is a high payoff. *Having* to apply patches separately to all branches is also a nuisance, particularly g

Re: [Python-Dev] Module version variable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/16/2011 06:15 PM, Eric Smith wrote: > On 3/16/2011 5:54 PM, Alexander Belopolsky wrote: >> On Wed, Mar 16, 2011 at 3:00 PM, Raymond Hettinger >> wrote: >> .. >>> The version number in the decimal module refers to the version of the >>> spec tha

Re: [Python-Dev] Generating patch files

Note the Mercurial project warns that use of the Mercurial API 'is a strong indication that you're creating a "derived work" subject to the GPL.' http://mercurial.selenic.com/wiki/MercurialApi http://mercurial.selenic.com/wiki/License Would distributing a script that called the API in any way ta

Re: [Python-Dev] Generating patch files

On Thu, Mar 17, 2011 at 5:00 AM, Ned Deily wrote: > In article <4d810f84.5060...@v.loewis.de>, >  "Martin v. Löwis" wrote: >> Before you upgrade: give me some time to come up with a script that >> uses Mercurial API instead to compute the revset and then invoke the >> diff command. >> >> We must

Re: [Python-Dev] Useful page in the Hg book

On Wed, Mar 16, 2011 at 7:09 PM, Nick Coghlan wrote: > As I'm sure there will be plenty of erring as we get used to Hg: > http://hgbook.red-bean.com/read/finding-and-fixing-mistakes.html > > For simple cases of attempting to push a single commit that gets > rejected by the server, hg rollback/hg p

Re: [Python-Dev] Generating patch files

Am 16.03.11 15:29, schrieb "Martin v. Löwis": Am 16.03.11 15:20, schrieb "Martin v. Löwis": I get "unknown revision" (listing the full expression text) when using Mercurial 1.6.3 (default version in Ubuntu 10.10). That version apparently supports revsets, but I'm not sure when the runtime evalu

Re: [Python-Dev] Generating patch files

On Wed, 16 Mar 2011 20:47:10 -0400, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= wrote: > > Note the Mercurial project warns that use of the Mercurial API 'is a > > strong indication that you're creating a "derived work" subject to the > > GPL.' > > > > http://mercurial.selenic.com/wiki/MercurialAp

Re: [Python-Dev] Useful page in the Hg book

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/03/11 02:39, Nick Coghlan wrote: > On Wed, Mar 16, 2011 at 7:09 PM, Nick Coghlan wrote: >> As I'm sure there will be plenty of erring as we get used to Hg: >> http://hgbook.red-bean.com/read/finding-and-fixing-mistakes.html >> >> For simple case

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

On Thu, 17 Mar 2011 00:20:26 +0100, Antoine Pitrou wrote: > > I think devguide's suggested interbranch workflow introduces too > > much complexity for too little payoff. > > > > If I need to make a fix to 3.2, I can't just fix it. I would need > > to also merge the changeset into 3.3 and then re

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/03/11 00:20, Antoine Pitrou wrote: > That's not my experience. > Often, when the resolution on other branches is deferred, it means the > committer has actually forgotten about it. I agree with this impression. Personally when I have a "pending

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/03/11 04:41, R. David Murray wrote: > Dealing with a null merge when someone else has committed between the > time I started the merge dance (I always pull just before I start that) > and the time I push is not that hard either. It pretty much a

Re: [Python-Dev] Generating patch files

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16/03/11 20:29, "Martin v. Löwis" wrote: > Before you upgrade: give me some time to come up with a script that > uses Mercurial API instead to compute the revset and then invoke the > diff command. > > We must get something out of using a Python-ba

Re: [Python-Dev] Question about GDB bindings and 32/64 bits

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28/11/10 16:46, Matthias Klose wrote: > On 26.11.2010 05:11, Jesus Cea wrote: >> I have installed GDB 7.2 32 bits and 32 bits buildslaves are green. >> Nevertheless 64 bits buildslaves are failing test_gdb. >> >> Is there any expectation that a 32 b

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

On Thu, 17 Mar 2011 05:11:23 +0100, Jesus Cea wrote: > On 17/03/11 04:41, R. David Murray wrote: > > Dealing with a null merge when someone else has committed between the > > time I started the merge dance (I always pull just before I start that) > > and the time I push is not that hard either. I

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

On Wed, Mar 16, 2011 at 10:14 PM, R. David Murray wrote: > On Thu, 17 Mar 2011 05:11:23 +0100, Jesus Cea wrote: > > On 17/03/11 04:41, R. David Murray wrote: > > > Dealing with a null merge when someone else has committed between the > > > time I started the merge dance (I always pull just before