Lennart Regebro, 16.03.2011 00:04:
On Tue, Mar 15, 2011 at 18:56, Nick Coghlan wrote:
why not just consider this another
instance of the 2.x/3.x incompatibility? That's what it is after all.
Apparently not, as the code already ran under Python 3.1.
Personally, I would expect that breaking
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.
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
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 installations
On Tue, Mar 15, 2011 at 11:34 PM, Guido van Rossum gu...@python.org 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
On Wed, Mar 16, 2011 at 3:20 AM, Stefan Behnel stefan...@behnel.de 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
On Wed, Mar 16, 2011 at 6:35 PM, ezio.melotti
python-check...@python.org 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
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 rude shocks
Am 16.03.11 08:06, schrieb Nick Coghlan:
On Wed, Mar 16, 2011 at 3:20 AM, Stefan Behnelstefan...@behnel.de 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
On Wed, Mar 16, 2011 at 9:11 AM, Martin v. Löwis mar...@v.loewis.de wrote:
Am 16.03.11 08:06, schrieb Nick Coghlan:
On Wed, Mar 16, 2011 at 3:20 AM, Stefan Behnelstefan...@behnel.de
wrote:
I still consider this is mostly a communication issue. If this change had
been properly written up,
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 deprecation
-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 meaning to
-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 meaning to
-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
2011/3/16 Jesus Cea j...@jcea.es:
-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
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.)
-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
think
I strongly opposed CObject deprecation in 2.7, as you can see in
http://bugs.python.org/issue9675 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
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
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
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
-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
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
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
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 used
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 meaning to close
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 out
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
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
On Wed, 16 Mar 2011 13:33:20 -0400, Michael Foord fuzzy...@voidspace.org.uk
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
On Wed, Mar 16, 2011 at 1:49 PM, Martin v. Löwis mar...@v.loewis.de 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
On Mar 16, 2011, at 11:33 AM, R. David Murray wrote:
On Wed, 16 Mar 2011 13:33:20 -0400, Michael Foord fuzzy...@voidspace.org.uk
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
On 16/03/2011 14:33, R. David Murray wrote:
On Wed, 16 Mar 2011 13:33:20 -0400, Michael Foordfuzzy...@voidspace.org.uk
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
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
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 Foordfuzzy...@voidspace.org.uk
wrote:
On 16/03/2011 12:39, Alexander Belopolsky wrote:
I was editing the turtle module (for issue11571, if you are
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.
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
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 be able
In article 4d810f84.5060...@v.loewis.de,
Martin v. Löwis mar...@v.loewis.de 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...
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
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 tidbits.
On Wed, Mar 16, 2011 at 3:44 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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
On Wed, Mar 16, 2011 at 3:00 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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
On 3/16/2011 5:54 PM, Alexander Belopolsky wrote:
On Wed, Mar 16, 2011 at 3:00 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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
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
On Wed, Mar 16, 2011 at 7:00 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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
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
On Wed, Mar 16, 2011 at 7:00 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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
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
On Wed, Mar 16, 2011 at 7:15 PM, Nick Coghlan ncogh...@gmail.com 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 |
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 payoff to
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
-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
raymond.hettin...@gmail.com wrote:
..
The version number in the decimal module refers to the version
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
On Thu, Mar 17, 2011 at 5:00 AM, Ned Deily n...@acm.org wrote:
In article 4d810f84.5060...@v.loewis.de,
Martin v. Löwis mar...@v.loewis.de 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
On Wed, Mar 16, 2011 at 7:09 PM, Nick Coghlan ncogh...@gmail.com 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
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 evaluation
On Wed, 16 Mar 2011 20:47:10 -0400, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
mar...@v.loewis.de 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.'
-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 ncogh...@gmail.com 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
On Thu, 17 Mar 2011 00:20:26 +0100, Antoine Pitrou solip...@pitrou.net 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
-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
-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
-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-based
-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 bits GDB
On Thu, 17 Mar 2011 05:11:23 +0100, Jesus Cea j...@jcea.es 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
65 matches
Mail list logo
