date:20110316

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), but got tripped up by the
behavioural changes between the earlier RFCs and RFC 3986 regarding
the way ".." is handled.

Even in test_urlparse, a bunch of the normative tests from RFC 3986
are commented out because they fail (by design) when run through
urllib.parse.urljoin. Some of the additional tests also fail because
our urljoin implementation has a whitelist of schemas that support
relative references, whereas 3986 expects relative references to work
for unknown schemas as well.

There's actually quite a few more terminology changes as well (as
Senthil pointed out in his email), but it was specifically the failing
test cases for urljoin semantics that bit me again yesterday.

The problem is that it is quite a lot of work to get fully general URI
parsing to work correctly, but the overlap with legacy URL parsing is
large enough that many (most?) use cases in practice work just fine
with the older RFC semantics.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 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 think we need to keep "topic of wider interest" in mind when
deciding whether or not to write up a PEP, even if the change isn't
particularly controversial amongst the core developers. We made a
similar mistake with the zipfile and directory execution changes.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2011-03-16 Thread Senthil Kumaran

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
___
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] public visibility of python-dev decisions "before it's too late"

2011-03-16 Thread Ronald Oussoren


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 to
> people switching from 2 to 3 and jumping several releases
> into the 3.x line.

You need to update the source of extensions anyway when switching from 2.x to 
3.x, this additional change is a minor one.

Ronald

___
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] 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 not have been necessary.


Yes, I think we need to keep "topic of wider interest" in mind when
deciding whether or not to write up a PEP, even if the change isn't
particularly controversial amongst the core developers. We made a
similar mistake with the zipfile and directory execution changes.


PEP 5 actually requires that backwards-incompatible changes must be 
defined in a PEP. This wasn't done in this case; I agree it should have.


I guess it's not too late to write this PEP, even though that's after 
the fact.


Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 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, including the reasoning
>>> for
>>> it to get done, I think this whole discussion would not have been
>>> necessary.
>>
>> Yes, I think we need to keep "topic of wider interest" in mind when
>> deciding whether or not to write up a PEP, even if the change isn't
>> particularly controversial amongst the core developers. We made a
>> similar mistake with the zipfile and directory execution changes.
>
> PEP 5 actually requires that backwards-incompatible changes must be defined
> in a PEP. This wasn't done in this case; I agree it should have.
>
> I guess it's not too late to write this PEP, even though that's after the
> fact.

The rationale and initial implementation of the new API are here:
http://bugs.python.org/issue5630

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.

An after the fact PEP would probably be valuable, as it could document
the rationale for the removal, as well as pointing to resources to
help folks in Lennart's situation that need to support both
PyCObject-only and PyCapsule-only versions of Python from the same C
code base. Perhaps Larry would be willing to write it up if we asked?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2011-03-16 Thread Ronald Oussoren

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 warnings: GCC has an __attribute__ option to mark C 
functions as deprecated. Is that something we should use for C API's that are 
deprecated?

As an example:

int old_code (void) __attribute__((__deprecated__));

Will warn when the function is called:

t.c:12: warning: ‘old_code’ is deprecated (declared at t.c:6)

This would obviously have to be wrapped in a macro that expands to nothing on 
compilers other than GCC.

Ronald
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] hooks: 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 meaning to close the issue :)

Sorry to bother you. What would be the exact wording?. What "variants"
means?.

Yesterday I committed a changeset with a commit message of "Close issue
#8600: test_gdb failures because innocuous warnings", and it didn't
automatically close the issue :).

Sorry for being so picky ;-).

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/

"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYDJ2plgi5GaxT1NAQJ7WQQAl0gM0F4GPdY0O3K2qH4/GJc8fqDx6pRJ
rz4DwVbYRZes3JCwWNCYvK7tJ3B2c39RLi6f4yL5xVP2MDdYT3fu4uBUaSky4a7x
jevns2KraRJVxQbkqwn0agV6CyDhKoffOzHKDg20k1Q+R0/JX3cwrQGDB9QtJuMR
xkIgbhZloF4=
=syPU
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 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 meaning to close the issue :)

Sorry to bother you. What would be the exact wording?. What "variants"
means?.

Yesterday I committed a changeset with a commit message of "Close issue
#8600: test_gdb failures because innocuous warnings", and it didn't
automatically close the issue :).

Sorry for being so picky ;-).

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/

"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYDMNZlgi5GaxT1NAQL3bAP/aey6/n0Hx59PsOW0t6v0+eOBcWGZ4r6R
20pvuYa2GJ4GUd6rTcOmIXBdwyfLe9K2r+2hYkSbn4Xg2RrAltXnPEhFuSOKRYfD
/v5S4YuwGa3QL7uiKe5qUn7u91KJzLb3vlAqq0TCzJxwLvZq5YeTB1iSXOZ3NoM8
xx/+mHpcUHI=
=eDnU
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 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 deprecation in 2.7, as you can see in
 and mailing list archives.

In (external module) pybsddb
 I support Python 2.3, 2.4,
2.5, 2.6, 2.7, 3.1, 3.2 and 3.x. Having to deal with CObject/Capsule was
an undesired pain, but the actual support has been painless.

What problems are you finding trying to support both CObject and Capsule?.

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYDNvplgi5GaxT1NAQIZ+gP8Dtv1EBIUTYYujlY/QcjmmyY+rdXwgZq6
tSJnHsonvaBkG34yY+YM/jw54wA0GFRApvHNtXo6r1AS0Gwei6+Ypb5iGGxdsWmB
SdaZhhcEfmaP1u+5Jaq9P3Nco9LfhgxC3ahT/M8uYsGzpC6U4zgh3yjIY08Y1MAp
h5cRmF2L6CI=
=8MSH
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2011-03-16 Thread Benjamin Peterson

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 "close #12345" without
>> actually meaning to close the issue :)
>
> Sorry to bother you. What would be the exact wording?. What "variants"
> means?.

Matching this re. :) (?:\b(?Pclose[sd]?|closing|)\s+)?



-- 
Regards,
Benjamin
___
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] public visibility of python-dev decisions "before it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)

2011-03-16 Thread Larry Hastings



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


PyCObject_AsVoidPtr emitted a PendingDeprecationWarning in 3.1.  I was 
surprised when it was removed completely in trunk shortly after the 
release of 3.1.  I thought it was supposed to get promoted to 
DeprecationWarning in 3.2 and then removed in 3.3.  But I'm not totally 
familiar with the policy subtleties of CPython, and the CObject API had 
enough flaws that I was happy to see it gone, so I kept a still tongue.



On 03/14/2011 06:30 PM, Lennart Regebro wrote:

But if I move the PyCObject API to the PyCapsule
API, the zope packages will **only work on Python 2.7 and 3.2**. This
is obviously not an option. If I do *not* switch, I can't support
Python 3.2. That's bad.


Sorry I didn't see your email until just now; I've been tuning out 
python-dev for a while.  Nick Coghlan brought this matter to my 
attention just this morning.


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.


Are you still at PyCon?  I'm in the core / hg room, and I'd be happy to 
help you get this code working for both 2.6 and 3.2.



**We can't deprecate an API in one version and drop the API in the
next. This is not acceptable. The deprecation period must be much
longer!**


The one-year deprecation period seems to be in keeping with PEP 5, which 
states


   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.



Let's make no bones about this: The PyCObject API should *not* have
been removed in 3.2. In fact, the removal should be reversed, and
3.2.1 should be released ASAP, making 3.2 a moot and unsupported
version.


I'm not a release manager for Python but I suspect this is unlikely.


Nick has convinced me that I should create the world's first "temporal 
inversion" PEP, discussing the justification for adding the Capsule API 
and (eventually) removing the CObject API.  I expect the PEP to discuss 
coping strategies on how to simultaneously support 2.6 and 3.2.  I'm 
enjoying PyCon too much to write the PEP this week, but I expect I can 
have a draft up next week.


Personally I'm hoping the PEP will be rejected ;)


/larry/
___
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] 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
> think always weighed the python-dev-summaries task down).
> 
> Ditto for python-ideas -- it would be nice if it was the same person
> but doesn't have to be.
> 
> This might be an opportunity for increasing diversity.

+1. I would love to see this. Too bad I don't have the time myself to
keep up with python-dev & python-ideas... Forwarding the request to
python-es mailing list. Crossing fingers.

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYDSJZlgi5GaxT1NAQIEvwP+MWHZbY+xMhl27K7hC2fPH7QJsz55H0Xb
7FIWSApqdJXL5Uzu+VbGN4IKK7GBCGHXS8t/vTOXcePeqZRnTGIgxVth8NnxcK3M
O9+VJIyGaqMghb0BEgSaaryfiZNfbI0mKwAouzgzQsvP2uyX/kzCHQCnxdDsNTWo
mxLbKVicaRw=
=aA2c
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 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 in 2.7.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2011-03-16 Thread Armin Ronacher


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 encoding").
These are two pretty unrelated problems but both are problems 
nonetheless.  The filename encoding should not be guessed from the 
environment variables as those are from the connecting client.  The 
default encoding for file contents also should not be platform 
dependent.  It *will* lead to people thinking it works when in practice 
it will break if they move their code to a remote server and SSH into it 
and then trigger the code execution.


I argue that the first is just wrong (filename encoding guessing) and 
the latter is dangerous (file content encoding being platform dependent).


virtualenv itself is already fixed and explicitly tells it to read with 
UTF-8 encoding.



Regards,
Armin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] New contributors at the PyCon sprint

2011-03-16 Thread Brian Curtin

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 huge
and I wanted to introduce and thank a number of people for coming out.

Scott Wilson
Denver Coneybeare
Jeff Ramnani
Alicia Arlen
Michael Henry
Natalia Bidart
Matias Bordese
Robbie Clemons
Evan Dandrea
Jonathan Hartley
Piotr Kaspyrzyk
Brandon Craig Rhodes

There were a few others from which I didn't get their name, but thanks to
everyone for your contributions!

http://wiki.python.org/moin/Pycon2011Sprint has a listing of what the new
contributors have been working on, including the issues that have been
submitted.

Additionally, I did a small write-up (with a picture!) of what everyone has
been up to:
http://blog.briancurtin.com/2011/03/16/pycon-2011-cpython-sprint-newcomers/
___
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] Low-Level Encoding Behavior on Python 3

2011-03-16 Thread Stefan Behnel


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 file names (aka "filesystem encoding").

These are two pretty unrelated problems but both are problems nonetheless.
The filename encoding should not be guessed from the environment variables
as those are from the connecting client. The default encoding for file
contents also should not be platform dependent. It *will* lead to people
thinking it works when in practice it will break if they move their code to
a remote server and SSH into it and then trigger the code execution.

I argue that the first is just wrong (filename encoding guessing) and the
latter is dangerous (file content encoding being platform dependent).


Antoine was arguing that it's not the fault of CPython that virtualenv 
expects it to correctly guess the encoding of a file it wants to read. It 
tries an educated guess based on the current environment setup, and if 
that's not correctly configured, it's the user's fault. As you indicated 
yourself, it does work most of the time. That's all you should expect from 
a default.




virtualenv itself is already fixed and explicitly tells it to read with
UTF-8 encoding.


That's the right way to deal with encoded file content.

Stefan

___
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] 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
> wouldn't be a backward compatibility issue :-) Whether it's worth
> doing, I'll leave to those who would be doing the work to judge...

I would +1 to reintroducing "cmp". Mapping my mental "cmp" to a "key"
is something I must think about everyday. When I have a 200 element
list, I don't mind about the "O(nlog(n))" nature of "cmp", instead of
"O(n)" of key.

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYDhJJlgi5GaxT1NAQKcXQP+IX5bSb3aSNsfzu/vjNY41CNI/1CJ+r3q
vxPbi7ut1ZvXVyiMo2b+jVC1rxNVitf0pQXyQ4skv9Tiq3+L8eYbOts7hbmDB7Aw
sNPWYuvjLmTrX2lsgdQyjbiVK0lHJjzYn8+pvKqy7Tt47+sNiL/07FmM6CHj2fiU
N/vspNCa6rs=
=Zc90
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Module version variable

2011-03-16 Thread Alexander Belopolsky

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 if there is any
recommended mechanism for maintaining module versions.

Some modules define __version__ which has a special meaning at least
for pydoc and possibly some third party tools.  In many cases it is
never updated and its format and meaning varies from module to module.
 (For example, decimal module stores the version of the spec rather
than the version of the module in __version__.)

In several instances, __version__ is set to "$Revision$" in an
apparent attempt to leverage VCS to keep it up to date, but this does
not seem to work after hg transition.  For example,

$  ./python.exe -m pydoc pydoc
..
VERSION
$Revision$

The other affected modules are pickle and tarfile.

Do you have an advise on how these issues should be handled?
___
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] 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 done: you have a class
attribute containing a list of things, and you want it
to be "additive" with respect to inheritance -- i.e. it
contains the items specified in a particular class plus
all those specified in its base classes.

This can obviously be arranged using appropriate metaclass
hackery, but I'm wondering whether it could be provided
using some mechanism that can be applied orthogonally
to any class attribute.



Right, I recently came across a similar usecase where a class needed to 
extend an object defined in a base class. What we *wanted* to do was the 
following:


class Foo(object):
 thing = Thing()

class Bar(Foo):
thing.baz = 3

This doesn't work for obvious reasons. One potential solution was 
re-assigning 'thing' on Bar as well and using a metaclass to merge them.


I think we ended up doing this, which is *slightly* 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://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Module version variable

2011-03-16 Thread Barry Warsaw

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 anywhere
>in the module.  I would simply delete it, but I wonder if there is any
>recommended mechanism for maintaining module versions.
>
>Some modules define __version__ which has a special meaning at least
>for pydoc and possibly some third party tools.  In many cases it is
>never updated and its format and meaning varies from module to module.
> (For example, decimal module stores the version of the spec rather
>than the version of the module in __version__.)
>
>In several instances, __version__ is set to "$Revision$" in an
>apparent attempt to leverage VCS to keep it up to date, but this does
>not seem to work after hg transition.  For example,
>
>$  ./python.exe -m pydoc pydoc
>..
>VERSION
>$Revision$
>
>The other affected modules are pickle and tarfile.
>
>Do you have an advise on how these issues should be handled?

MvL and I had a discussion about this at the sprint.  I am planning on writing
an informational PEP that proposes __version__ as a standard convention.  I'd
like to be able to do:

>>> import foo
>>> foo.__version__

It won't be mandatory (thus the informational PEP), but it should be
formalized as the preferred way to introspect a module for its version
number.  I think there should be ways to spell this easily if the information
is provided to packaging/distutils2 so that it can basically always be kept up
to date without violating DRY.

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2011-03-16 Thread Georg Brandl

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 the issue :)
> 
> Sorry to bother you. What would be the exact wording?. What "variants"
> means?.

Those I mentioned in my original email to python-committers.

> Yesterday I committed a changeset with a commit message of "Close issue
> #8600: test_gdb   failures because innocuous warnings", and it didn't
> automatically close the issue :).
> 
> Sorry for being so picky ;-).

Well, the hook recognizes "closes" as a prefix of either "issue 12345" or
"#12345", but not a combination of both.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 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 out of date and this variable is not used anywhere
in the module.  I would simply delete it, but I wonder if there is any
recommended mechanism for maintaining module versions.

Some modules define __version__ which has a special meaning at least
for pydoc and possibly some third party tools.  In many cases it is
never updated and its format and meaning varies from module to module.
(For example, decimal module stores the version of the spec rather
than the version of the module in __version__.)

In several instances, __version__ is set to "$Revision$" in an
apparent attempt to leverage VCS to keep it up to date, but this does
not seem to work after hg transition.  For example,

$  ./python.exe -m pydoc pydoc
..
VERSION
$Revision$

The other affected modules are pickle and tarfile.

Do you have an advise on how these issues should be handled?

MvL and I had a discussion about this at the sprint.  I am planning on writing
an informational PEP that proposes __version__ as a standard convention.  I'd
like to be able to do:

 >>>  import foo
 >>>  foo.__version__

It won't be mandatory (thus the informational PEP), but it should be
formalized as the preferred way to introspect a module for its version
number.  I think there should be ways to spell this easily if the information
is provided to packaging/distutils2 so that it can basically always be kept up
to date without violating DRY.

+1

There is a minor difficulty with distutils2 which needs to be able to 
install from setup.cfg without executing code. This means it can't look 
in package.__version__ to get the version number (potentially requiring 
you to maintain __version__ both in your package and your setup.cfg).

The suggestion is that the version metadata should be created at package 
build time, defaulting to package.__version__. The rationale is that it 
is ok to execute code at build time if it removes the need for 
information duplication or for executing code at install time.

Also note that there is a proposed api for getting version 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/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk

--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 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 
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 variable is not used anywhere
in the module.  I would simply delete it, but I wonder if there is any
recommended mechanism for maintaining module versions.

Some modules define __version__ which has a special meaning at least
for pydoc and possibly some third party tools.  In many cases it is
never updated and its format and meaning varies from module to module.
  (For example, decimal module stores the version of the spec rather
than the version of the module in __version__.)

In several instances, __version__ is set to "$Revision$" in an
apparent attempt to leverage VCS to keep it up to date, but this does
not seem to work after hg transition.  For example,

$  ./python.exe -m pydoc pydoc
..
VERSION
 $Revision$

The other affected modules are pickle and tarfile.

Do you have an advise on how these issues should be handled?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk



--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[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 branch different from default, replace 'default' in both 
places with the branch name.


I'd be curious for people to try this out and report whether it works 
correctly. You'll need a Mercurial release supporting revsets.


Here is the theory of operation: The diff needs to be either from
the oldest of the commits (in case no merges have been made from 
cpython), or from cpython's code in that was last merged. So:


- merge() gives all changesets that are merges
- branch(default) gives all changesets on the default branch
- 'merge() and branch(default)' gives all merges to the default
  branch
- max(merge() and branch(default)) gives the most recent merge
  to the default branch
- p2(max(merge() and branch(default))) is the second parent,
  which will be the upstream version of cpython that got last
  merged
- outgoing() gives all changes in the local repository not
  in cpython
- min(outgoing()) gives the first local change made
- p1(min(outgoing())) gives revision that was the starting
  point for the local modifications
- max(p1(...) or p2(...)) determines which of the two is
  later.

Having the revision of cpython to compare against is the
difficult part; the other revision must be default's head,
which is always called 'default'.

Enjoy,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 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"
> >
> 
> unittest also has an outdated (and unmaintained) version number 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.

The email package has an internal version (which changes no more often
than CPython's, but may change slower).  Existing code in the field
tests this version attribute, so I don't think it should be deleted.

The same may or may not be true of unittest, but if it hasn't been
maintained its present utility is questionable so it may be just as
well to delete it.

--
R. David Murray  www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 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())) or p2(max(merge() and branch(default'
> -r default
>
> If it's a branch different from default, replace 'default' in both places
> with the branch name.
>
> I'd be curious for people to try this out and report whether it works
> correctly. You'll need a Mercurial release supporting revsets.

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.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Module version variable

2011-03-16 Thread Raymond Hettinger


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:
>>> 
>>> _ver = "turtle 1.1b- - for Python 3.1   -  4. 5. 2009"
>>> 
>> 
>> unittest also has an outdated (and unmaintained) version number 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.
> 
> The email package has an internal version (which changes no more often
> than CPython's, but may change slower).  Existing code in the field
> tests this version attribute, so I don't think it should be deleted.

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.

There are probably other cases where the version number is useful.


Raymond

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 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- - for Python 3.1   -  4. 5. 2009"


unittest also has an outdated (and unmaintained) version number 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.

The email package has an internal version (which changes no more often
than CPython's, but may change slower).  Existing code in the field
tests this version attribute, so I don't think it should be deleted.

The same may or may not be true of unittest, but if it hasn't been
maintained its present utility is questionable so it may be just as
well to delete it.


If you're actively maintaining the version info and are using it for api 
versioning then great. For unittest it is truly useless and much better 
not to have it.


Deprecating a module attribute is basically impossible (twisted has some 
code that makes it possible by subclassing the ModuleType I believe) so 
I will probably just delete it.


All the best,

Michael


--
R. David Murray  www.bitdance.com



--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 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 included the release; I think
I had the same issue with 1.6.4.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 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 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
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.

The email package has an internal version (which changes no more often
than CPython's, but may change slower).  Existing code in the field
tests this version attribute, so I don't think it should be deleted.

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.

There are probably other cases where the version number is useful.



That's entirely fair enough, although that's not really a *module 
version number* so isn't what I was referring to. The sqlite module also 
carries version information about the version of sqlite it works with 
which is another valid use case (sqlite *also* has a module version 
number I believe, because it is externally maintained).


In the case of the unittest version number it goes back to when unittest 
*was* originally maintained externally.


As general practise is to use __version__ for module version info I 
think it would be bad (misleading) if any module (including standard 
library) reused this name for storing information that *wasn't* a module 
version but some related version info.


All the best,

Michael


Raymond




--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 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.


Apparently shortly after Debian/Ubuntu included the release; I think
I had the same issue with 1.6.4.


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

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Please retract my committer rights

2011-03-16 Thread Thomas Heller


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 mercurial yet).  Plus I'm still using 2.6 or even 2.5 with my own
Python projects.

Goodbye.

Thanks,
Thomas

___
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] Please retract my committer rights

2011-03-16 Thread Raymond Hettinger


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 to contribute anymore (I have not even started to
> learn mercurial yet).  Plus I'm still using 2.6 or even 2.5 with my own
> Python projects.
> 
> Goodbye.

You will be missed.
Thanks for all your efforts.


Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Generating patch files

2011-03-16 Thread Ned Deily

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 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 taint Python?

-- 
 Ned Deily,
 n...@acm.org

___
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] New contributors at the PyCon sprint

2011-03-16 Thread Terry Reedy


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, as shown by regressions due to 
lack thereof. So there is no argument about whether a good patch should 
go in.



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 huge and I wanted to introduce and thank a number of people for
coming out.

Scott Wilson
Denver Coneybeare
Jeff Ramnani
Alicia Arlen
Michael Henry
Natalia Bidart
Matias Bordese
Robbie Clemons
Evan Dandrea
Jonathan Hartley
Piotr Kaspyrzyk
Brandon Craig Rhodes


Please let them know if they do not read pydev that we are not a closed 
club and that push rights are a reasonable aspiration within a year 
after 20 patch submissions or so (and not necessary all accepted).


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2011-03-16 Thread Doug Hellmann


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. There's no requirement to be complete (which I
>> think always weighed the python-dev-summaries task down).
>> 
>> Ditto for python-ideas -- it would be nice if it was the same person
>> but doesn't have to be.
>> 
>> This might be an opportunity for increasing diversity.
> 
> +1. I would love to see this. Too bad I don't have the time myself to
> keep up with python-dev & python-ideas... Forwarding the request to
> python-es mailing list. Crossing fingers.

Jesus, if anyone expresses interest in helping out please have them contact me 
directly, off list.

Thanks,
Doug

___
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] Please retract my committer rights

2011-03-16 Thread Alexander Belopolsky

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
ctypes package, which in my opinion was a hugely successful addition.

Thanks for all your hard work!
___
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] Module version variable

2011-03-16 Thread Alexander Belopolsky

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 spec
is important, shouldn't it be called something else? Note that
__version__ value appears in pydoc as the version the module, and it
is confusing to have it refer to something else. This fact is only
mentioned in a comment inside the module and cannot be found either in
module docstrings or reST documentation.

Note that in a similar situation, another module, unicodedata defines
unidata_version variable which is properly documented:

http://docs.python.org/library/unicodedata.html?highlight=unicodedata#unicodedata.unidata_version

I think this is a better approach. (It would be even better if it was
called "ucd_version" or "unicode_version", but "unidata_version" is
good enough.)

I also question the utility of maintaining IBM draft version in the
decimal module. Note that the current version 1.70 is described as
follows:

Changes in Version 1.70 (25 Mar 2009)

The document is now formatted using OpenOffice (generated from GML),
for improved PDF files with bookmarks, hot links, etc. There are no
technical changes. See http://speleotrove.com/decimal/dachange.html

On the other hand, spot checking the changes from other versions I
immediately found that at least one change introduced in the previous
version, 1.68, was not implemented:

"The normalize operation has been renamed reduce to avoid confusion
with normal numbers."

It may actually be more useful to refer to the appropriate version of
IEEE 754 standard. Or if no strict compliance with any particular
standard or version of specification is promised, not record spec
version in the module at all.

Given that decimal.__version__ has not changed since it was
introduced, I doubt there is a lot of code out there that relies on
it.
___
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] Module version variable

2011-03-16 Thread Eric Smith


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 in my first post.   If the version number of the spec
is important, shouldn't it be called something else?


I agree, especially if we need to issue a new version of the library 
that implements the same spec. We couldn't upgrade __version__, since 
it's used for the spec. There'd be no way to know (by inspection) if the 
version of the library fixed a spec compliance issue.


Eric.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Hg: inter-branch workflow

2011-03-16 Thread Raymond Hettinger

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 brings back the ghost of svnmerge but it 
much more restrictive:
* it is pretty much required for every patch on a non-default branch
* you have to decide in advance how far it should be backported because only 
forward porting is supported
* it means you can't just fix one branch without having also decided how the 
change should be applied to other branches (if we look at the tracker, you can 
see that it is very common for the resolution on different branches to be done 
at different times)

I think we would be better off treating the branches as independent.  If I need 
to apply a patch to two of them, that's what I would do (in any order, at any 
time, or with or without modifications).

As far as I can tell the only benefits to the cross-linking are that it reduces 
the chance that a patch will be applied to an older branch but not forward 
ported.

I've been enjoying most of my experiences with mercurial, but as soon we start 
needing rebases, null merges, merges followed by null reverts, then we might as 
well be using git.  The version control system is supposed to make our lives 
easier, not introduce more workflow requirements.

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 get 
simple checkins done.


Raymond



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2011-03-16 Thread Facundo Batista

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 get simple checkins done.

+1 to keep it as simple as possible, at least until we get more time
using it and know better which added complexity pays off.

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] 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 a dummy merge.

hg backout also further emphasises the benefits of working in feature
branches - I was able to revert the default branch in my sandbox to
match upstream by backing out a single changeset.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 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 recommended bugfixes
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.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2011-03-16 Thread Greg Ewing


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 in a form that's easy to
include in their projects?

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hg: 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.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2011-03-16 Thread Antoine Pitrou


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 this style.  It brings back the ghost of svnmerge but 
> it much more restrictive:

Well, you might not have liked svnmerge, but most other devs preferred
using it instead of porting patches by hand.
I think the same argument goes for "hg merge".

> (if we look at the tracker, you can see that it is very common for the 
> resolution on different branches to be done at different times)

That's not my experience.
Often, when the resolution on other branches is deferred, it means the
committer has actually forgotten about it.

It doesn't really make sense in practice to defer such resolution: you
want the issue to be fresh in your head when committing patches; you
don't want to have to context-switch everything back into your head,
read the discussion again, try to remember the subtleties, etc. Doing
the different branches at different times makes you lose more of your
time, cumulated, and also increases the risk of doing something wrong.

> As far as I can tell the only benefits to the cross-linking are that it 
> reduces the chance that a patch will be applied to an older branch but not 
> forward ported.

Well, no. The main benefit is ease of merging, by definition ;)

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 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 given that easy merging between branches is one of the big 
advantages of a dvcs.


Unfortunately if some developers decide they won't merge their changes 
that puts the burden of doing it on all the other developers (with more 
pain if the patches have been applied to different branches 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,

Michael Foord


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 brings back the ghost of svnmerge but it 
much more restrictive:
* it is pretty much required for every patch on a non-default branch
* you have to decide in advance how far it should be backported because only 
forward porting is supported
* it means you can't just fix one branch without having also decided how the 
change should be applied to other branches (if we look at the tracker, you can 
see that it is very common for the resolution on different branches to be done 
at different times)

I think we would be better off treating the branches as independent.  If I need 
to apply a patch to two of them, that's what I would do (in any order, at any 
time, or with or without modifications).

As far as I can tell the only benefits to the cross-linking are that it reduces 
the chance that a patch will be applied to an older branch but not forward 
ported.

I've been enjoying most of my experiences with mercurial, but as soon we start 
needing rebases, null merges, merges followed by null reverts, then we might as 
well be using git.  The version control system is supposed to make our lives 
easier, not introduce more workflow requirements.

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 get 
simple checkins done.


Raymond



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk



--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Module version variable

2011-03-16 Thread Tres Seaver

-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 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 spec
>> is important, shouldn't it be called something else?
> 
> I agree, especially if we need to issue a new version of the library 
> that implements the same spec. We couldn't upgrade __version__, since 
> it's used for the spec. There'd be no way to know (by inspection) if the 
> version of the library fixed a spec compliance issue.

I'm not even sure why you would want __version__ in 99% of modules:  in
the ordinary cases, a module's version should be either the Python
version (for a module shipped in the stdlib), or the release of the
distribution which shipped it.  Free-standing, separately-distributed
modules are a huge anomaly

ISTM that other cases (version of a spec targeted by the module, or of
the underlying C library it wraps), need their own attribute.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2BRkwACgkQ+gerLs4ltQ7ZnACcDNxH/pR5jb0ycNK/i3LlvsDF
AxYAnAvnPQT5iMkAONSTFYVYM5tlazYw
=2eBY
-END PGP SIGNATURE-

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 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 taint Python?


Perhaps. So I'll see whether I can make use of the command line only, first.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Generating patch files

2011-03-16 Thread Stephen J. Turnbull

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 get something out of using a Python-based DVCS...
>
> 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.'

> Would distributing a script that called the API in any way taint Python?

Yes, if used to build or run Python.

No, if used to develop Python.
___
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] 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 pull/hg commit/hg push/ may
> provide a cleaner history than doing a dummy merge.

Having tried this, I advise against anyone else trying it. I seem to
have got my local repo into a state where it thinks I have already
merged something from 3.2 to default when I really haven't.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 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 evaluation of the command line arguments was added.


Apparently shortly after Debian/Ubuntu included the release; I think
I had the same issue with 1.6.4.


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.


It turns out that 1.6 doesn't have the min() revset function, so I give 
up on that - the recipe can only work in 1.7 and later.


Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 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/MercurialApi
> > http://mercurial.selenic.com/wiki/License
> >
> > Would distributing a script that called the API in any way taint Python?
> 
> Perhaps. So I'll see whether I can make use of the command line only, first.

As long as we aren't distributing mercurial itself, I don't see
how a script could be a problem.  But, then, IANAL.

--
R. David Murray  www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 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 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 a dummy merge.
> 
> Having tried this, I advise against anyone else trying it. I seem to
> have got my local repo into a state where it thinks I have already
> merged something from 3.2 to default when I really haven't.

The good thing about dummy merges is that you do the merge in your local
clone, and if you don't like it you can do a revert or a rollback. That
way, it is risk free and you can experiment locally before pushing.

Since rebase is in HG core these days, I am getting comfy with "hg pull
- --rebase". But I find rewriting history too scary when merging between
branches and complicated changeset graphs. I want to be able to drop a
bad conflict merging and try again, in a safe way.

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYGBMJlgi5GaxT1NAQIl2wQAllNQiQfjHygDDoGEGm+9wUAxtaGLvSkB
na/MmFTgXSXn4og7K5JVmTesc1KXHJjF+a3Kb2oDu9A3IRbjipEIc4qWpnwTlPBW
skmAMXhwLR+Y9y+nXo2ry9R71SvIa7u1RGihrPWBnnIHzlgWKPwr93BPdYygSb4g
uQJ4QGIVudU=
=LSJh
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 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 revert it, and then
> > commit both.  There is not much payoff to this style.  It brings
> > back the ghost of svnmerge but it much more restrictive:
> 
> Well, you might not have liked svnmerge, but most other devs preferred
> using it instead of porting patches by hand.
> I think the same argument goes for "hg merge".

+10.  And I've done quite a few commits here at the sprints.  I'd *really*
hate to have had to patch each branch by hand.  If I'd had to do that
I'm sure I wouldn't have bothered with 3.1.  As it is, once I applied
the patch once to 3.1, doing the merges was a piece of cake.  Patching
2.7, on the other hand, is a pain.

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 amounts to
having to do an additional set of merges.  (In my case I do a strip and
restart my merge dance, but I'm not sure I should recommend that since
altering history is considered dangerous :)

Even this week, with all the commit activity surrounding the sprints,
I have only had to deal with a push race twice out of 16 patches.
I expect to hit it only very rarely in normal development work.

Alternatively, Ezio at least follows the policy of doing a pull
-u/commit/push in the first branch, and then doing pull -u/merge/push
in the next branch.  You are even less likely to hit a push race by
following that technique, since the time between the pull -u and the
push is minimized.

--
R. David Murray  www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hg: 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 branch",
I keep a firefox tab open in the issue, as a "reminder". It bugs me a
lot. And that is the point.

Most of the time, I push all the changesets for all branches in a single
operation. The (mainly) only time I could push a single branch is if I
want to try the patch in the buildbots first, before applying to all
relevant branches. And I try to avoid it, because I know some other
people are going to have issues when doing their own merges trying not
to merge my changeset themselves, specially newbies (the +1 head thing).

I agree that half the changesets are merges now. But that is an artifact
of our commit culture (create a patch, commit inmediatelly). Another
approach would be to spend some time writing patches, committing locally
and doing a giant merge & push at the end of the week :-).

(DIGRESS: If buildbots could download & test a remote arbitrary HG
repository, it would be a big improvement for this, and a galaxy-size
security hazard :-p... Although now any "pusher" can break-in any
buildbot machine simply pushing some ugly test code, of modified
"configure" script.

Uhm... Maybe a wiki about how to set up a "chroot" buildslave would be
something to think about... Any info about this?)

The good thing about merging so frequently is that mergin is easy,
painless and every committer must go thru it for her own patches,
instead of putting that responsability on somebody else. "hg log" can be
a bit unusual for us, but pretty moot. we are getting used to it, yet.

No forgeting up-porting changesets is a massive improvement with the
late svnmerge practice (nobody cared about automatic merging, but
merging by hand anyway, cherrypicking revisions).

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYGG55lgi5GaxT1NAQLEDwP+L3AsqeXMpgEOKJFW6gqs0ahjbqF61Ao5
zThKWqXQoAyDm+21bT8aJR3Ogrix+dI37PrTRa6B8L+S2tDh3PdG984tOUOsGUvp
KNa+GSNai1OotfLUebBhCvGlPAapQnWK9xoELYjO8Lo7YTkfWspXGv5e3exIQQJp
AmunpKy1I3U=
=gS+8
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 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 amounts to
> having to do an additional set of merges.  (In my case I do a strip and
> restart my merge dance, but I'm not sure I should recommend that since
> altering history is considered dangerous :).

Could you possibly describe your current approach, marking it with a
huge "NOT SAFE; AT YOUR OWN RISK" banner?. I wonders how other people
manage this.

I too do a "pull" before doing the merge, but I don't push each merge
separatelly but I do the all the merges locally and then do an unique
push. Than can take some time, moreover if I run the complete testsuite
in all changed branches. Resolving a "+1 head" here is tricky, if I
*WANT* the other developer to manage her own merging by herself. As it
should.

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYGJ65lgi5GaxT1NAQII3wP/fiHkDs5xFP9hK/3tWxFSrovdSoOOTzKT
py7J2P1Ys1nQAw9ylfDiq6oFPGuc22pSqBrO2MgLlGs1a5i9XBSDhA6yCvRW6i4C
CoPMmVXigEeZXpEBGpYWtjSO7pIvPQxPCjMH6zlHWwD+jg6RhqBQrz/yacKQdNzw
7auugDVYyD0=
=uAdh
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 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-based DVCS...

Beware, mercurial API is not stable. That is, it can change anytime.
Paradoxically, the stable "API" is the commandline, IIRC.

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYGKsZlgi5GaxT1NAQLEegP9GlKeCi5FRICOXUe2gjQbEWQ3lI44V3ae
+XjGf1FqS5kWgGLM+DlpHZuOB8pQo80ZZFpxOY3MzVi/SCBm8i+SfjGDdS9QQS7X
Y6i7duZ7ubbHls6hnN9weHB6MXBCA+GQQQg8oMSnGiUdXLLBkUzhY+/pXb688wpE
dxFneCjN6W8=
=Xpds
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 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 bits GDB be able to debug a 64 bits
>> python?. If not, gdb test should compare "platform.architecture()" (for
>> python and gdb in the system) and run only when they are the same.
> 
> that would be too restrictive, as an 64bit gdb is able to handle 32bit
> binaries too.
> 
>> If
>> this should work, I would open a bug and maybe spend some time with it.
>>
>> But before thinking about investing time, I would like to know if this
>> mix is actually expected or not to work.
>>
>> If not, I would consider to install a 64 bits GDB too and do some tricks
>> (like using an "/usr/local/bin/gdb" script wrapper to choose 32/64
>> "real" gdb version) to actually execute "test_gdb" in both buildslaves
>> (they are running in the same physical machine).
> 
> yes, and then you should be able to use this gdb for both 32 and 64bit
> builds. No need for a wrapper (Such a gdb is available in the gdb64
> package on Debian/Ubuntu).
> 
>   Matthias

I compiled GDB 64 bits to debug both 32 and 64 bits binaries. There are
some thread debugging issues when debugging 32 bits, but we can live
with them for now.

Details in .

Thanks for the suggestion, Matthias.

Closing old threads...

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYGMPZlgi5GaxT1NAQLDNwP/Rswr2jZvxBoif98dIS7bwk/OA+uIB18k
p3dNs71cGAV4emcuz+e+fMS138WXwN5c1epo5QrAQ9eQTr0KoJIo6bBaFKHzg03m
RFNIEF4bpB4VvtSvTlIZYHQayecJGHRZxEewEzW9+562ZFa79qvhaYEPxAEVh6jT
6kvt0pQoAIw=
=v9N0
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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