date:20110307


I ported the code review support on bugs.python.org to hg,
and reactivated it. Review "issues" are created automatically
if the attached file is recognized as a patch that applies
cleanly. The roundup issue's nosy list is synchronized with the
rietveld issue's cc list, so comments get mailed to the nosy
list.

If there are any problems with that installation, please report
them to the meta tracker.

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] [Python-checkins] r88709 - in python/branches/py3k: Misc/NEWS Objects/unicodeobject.c

Hi,

> Author: victor.stinner
> Date: Wed Mar  2 02:03:14 2011
> New Revision: 88709
> Log: Issue #8923: cache str.encode() result
> 
> When a string is encoded to UTF-8 in strict mode, the result is cached into 
> the
> object. Examples: str.encode(), str.encode('utf-8'), PyUnicode_AsUTF8String()
> and PyUnicode_AsEncodedString(unicode, "utf-8", NULL).

I don’t really understand this message (especially “cached into the
object”) :)  Maybe in the Misc/NEWS entry you could also add a line to
explain to users the reason/goal/benefit of this change?

Regards
___
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] PyCObject_AsVoidPtr removed from python 3.2 - is this documented?

2011-03-07 Thread Nick Coghlan

On Mon, Mar 7, 2011 at 6:36 PM, John Arbash Meinel
 wrote:
>
> Especially since, AIUI, deprecations are suppressed by default now.

True, but developers are expected to run their tests with them enabled.

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] PyCObject_AsVoidPtr removed from python 3.2 - is this documented?


Am 07.03.2011 10:14, schrieb Nick Coghlan:

On Mon, Mar 7, 2011 at 6:36 PM, John Arbash Meinel
  wrote:


Especially since, AIUI, deprecations are suppressed by default now.


True, but developers are expected to run their tests with them enabled.


I think everything here is as it should be. People who really cared
about forwards compatibility could have known, but factually, most
people don't care enough. Those then learn for the first time that
some feature was deprecated after it is actually removed. They then
ask why it is removed, and somebody will tell them.

The OP is actually wrong that this isn't documented in "what's new";
there is an item about it in the "porting to 3.2" section.

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] PyCObject_AsVoidPtr removed from python 3.2 - is this documented?

2011-03-07 Thread Stefan Behnel


John Arbash Meinel, 07.03.2011 09:36:

On 3/7/2011 3:56 AM, Terry Reedy wrote:

On 3/6/2011 6:09 PM, Barry Scott wrote:

I see that PyCObject_AsVoidPtr has been removed from python 3.2.
The 3.2 docs do not seem to explain this has happened and what
to replace it with.

I searched the 3.2 docs and failed to find PyCObject_AsVoidPtr.
I looked at the whats new page and the API PEP. Did I miss
where this is documented?


Georg recently reaffirmed on a tracker issue that when something is
removed from the code, it is removed from the docs also. So the place to
look for a deprecation notice and replacement suggestion is in the last
release where present.



It might be interesting to just have a stub entry with:

   PyCObject_AsVoidPtr (This was deleted in 3.2, last available in [3.1])

Might end up being too cluttered, but certainly helps the people who hit
the problem.


-1. When you do a search for the function on docs.python.org, you will see 
where it's being documented. Then, click on the latest version that has it 
and find the deprecation notice.


Searching will also likely let you run into the "What's new" documents that 
mention its deprecation and removal.


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] [PEPs] Support the /usr/bin/python2 symlink upstream

2011-03-07 Thread Paul Moore

On 7 March 2011 01:18, Mark Hammond  wrote:
> That said though, I'm only -0 on python2.exe/python3.exe - I don't think it
> will hurt, but also don't think it will help that much in practice. It may
> also turn out to be unnecessary should a "complete" solution be implemented
> - eg, a "python launcher" which (a) read the shebang lines and (b) allowed
> something like "python -3" on the command-line would render both python3.exe
> and requests to have multiple installed Python versions on the PATH
> redundant.

That sounds like a fairly cool idea. So if I follow what you're
suggesting, we'd have a single python.exe, probably installed in
system32, which did the necessary command line juggling and shebang
parsing, then simply redirected to the appropriate Python interpreter?
Presumably that launcher would be pretty version independent, so (a)
the one that gets installed with Python 3.3 would support older
versions even though they didn't include the launcher themselves, (b)
overwriting the launcher when a new version of Python is installed
wouldn't be too big a deal, and (c) it could be released as a
standalone package for people with only older versions of Python
installed?

I like this idea. If I had the spare time (I don't :-() I'd work on this myself.

+1 from me.

Paul.
___
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] [PEPs] Support the /usr/bin/python2 symlink upstream

2011-03-07 Thread Mark Hammond


On 7/03/2011 9:33 PM, Paul Moore wrote:

That sounds like a fairly cool idea. So if I follow what you're
suggesting, we'd have a single python.exe, probably installed in
system32, which did the necessary command line juggling and shebang
parsing, then simply redirected to the appropriate Python interpreter?
Presumably that launcher would be pretty version independent, so (a)
the one that gets installed with Python 3.3 would support older
versions even though they didn't include the launcher themselves, (b)
overwriting the launcher when a new version of Python is installed
wouldn't be too big a deal, and (c) it could be released as a
standalone package for people with only older versions of Python
installed?


Yup - although I think a pythonw.exe launcher would be needed too (for 
the same reasons we need python.exe and pythonw.exe today)



I like this idea. If I had the spare time (I don't :-() I'd work on this myself.

+1 from me.


Cool - I may have a go at this over the next few weekends... :)

Cheers,

Mark
___
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] r88709 - in python/branches/py3k: Misc/NEWS Objects/unicodeobject.c

2011-03-07 Thread Victor Stinner

Le lundi 07 mars 2011 à 10:05 +0100, Éric Araujo a écrit :
> Hi,
> 
> > Author: victor.stinner
> > Date: Wed Mar  2 02:03:14 2011
> > New Revision: 88709
> > Log: Issue #8923: cache str.encode() result
> > 
> > When a string is encoded to UTF-8 in strict mode, the result is cached into 
> > the
> > object. Examples: str.encode(), str.encode('utf-8'), 
> > PyUnicode_AsUTF8String()
> > and PyUnicode_AsEncodedString(unicode, "utf-8", NULL).
> 
> I don’t really understand this message (especially “cached into the
> object”) :)  Maybe in the Misc/NEWS entry you could also add a line to
> explain to users the reason/goal/benefit of this change?

If you call str.encode() twice: the first call stores the result in a
cache, and the second call just reuse the cache. The benefit is that the
second call is much faster.

The cache is an internal attribute of the Unicode object (str type).

Do you have a suggestion to rephrase the Misc/NEWS entry?

PS: The Unicode object did already use this cache, but not always (eg.
not for str.encode() or str.encode('utf-8')).

Victor

___
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] [PEPs] Support the /usr/bin/python2 symlink upstream

2011-03-07 Thread Tim Golden


On 07/03/2011 10:49, Mark Hammond wrote:

On 7/03/2011 9:33 PM, Paul Moore wrote:

That sounds like a fairly cool idea. So if I follow what you're
suggesting, we'd have a single python.exe, probably installed in
system32, which did the necessary command line juggling and shebang
parsing, then simply redirected to the appropriate Python interpreter?
Presumably that launcher would be pretty version independent, so (a)
the one that gets installed with Python 3.3 would support older
versions even though they didn't include the launcher themselves, (b)
overwriting the launcher when a new version of Python is installed
wouldn't be too big a deal, and (c) it could be released as a
standalone package for people with only older versions of Python
installed?


Yup - although I think a pythonw.exe launcher would be needed too (for
the same reasons we need python.exe and pythonw.exe today)


I like this idea. If I had the spare time (I don't :-() I'd work on
this myself.

+1 from me.


Agreed all round. In the highly unlikely event that I find
some time I too might have a play with the idea. The devil
will undoubtedly be in the details. I've implemented
a Pure-python version of this before, but found it unacceptably
slow for anything but ad-hoc use. Still, it was useful for
that :)

TJG
___
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] Unable to build old version from hg.python.org

2011-03-07 Thread Vinay Sajip

I want to maintain several working copies, as sometimes I have to make bugfix
changes across several revisions. Since we are supposed to use forward-porting,
I tried to set up a 2.5 clone, but building from it fails with a "Fatal Python
error: subversion keywords missing".

What I did (in ~/projects/python):

hg clone ssh://h...@hg.python.org/cpython default
hg clone default 2.5
cd 2.5
hg update 2.5
./configure
make

Failing command:
-
gcc -pthread  -Xlinker -export-dynamic -o python \
Modules/python.o \
libpython2.5.a -lpthread -ldl  -lutil   -lm  
libpython2.5.a(posixmodule.o): In function `posix_tmpnam':
/home/vinay/projects/python/2.5/./Modules/posixmodule.c:6858: warning: the use
of `tmpnam_r' is dangerous, better use `mkstemp'
libpython2.5.a(posixmodule.o): In function `posix_tempnam':
/home/vinay/projects/python/2.5/./Modules/posixmodule.c:6813: warning: the use
of `tempnam' is dangerous, better use `mkstemp'
case $MAKEFLAGS in \
*-s*)  CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG 
-g
-fwrapv -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; \
*)  CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g 
-fwrapv
-O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py build;; \
esac
Fatal Python error: subversion keywords missing
Aborted
-

BTW, this is happening on my Ubuntu Jaunty machine which I have been using for
many months with the Subversion repository.

Am I doing something wrong?

Regards,

Vinay Sajip

___
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] Support the /usr/bin/python2 symlink upstream

2011-03-07 Thread Ronald Oussoren

On 4 Mar, 2011, at 19:56, R. David Murray wrote:

> On Fri, 04 Mar 2011 15:50:01 +, Ronald Oussoren  
> wrote:
>> On 04 Mar, 2011,at 02:21 PM, Nick Coghlan  wrote:
>> 
>> For *nix, I think there is a simple way forward that is an improvement
>> over where things stand now. For Windows, I don't think we can do much
>> better than the status quo and for Mac OS X... I think Apple will do
>> whatever Apple feel like doing :)
>> 
>> Apple will generally follow what we decide to do for the base install.
>> 
>> Anyway, I'd say that OSX should do the same as Unix platforms here and 
>> support
>> '#!/usr/bin/env python2'. Adding another symlink is fairly trivial.
> 
> FYI, Ronald, the text version of your emails looses all quoting
> information.  It would be nice if you could use standard email
> quoting (leading '>' characters).

Sorry about this, I keep forgetting how crummy the webmail interface of 
mobileme is in that regard.

> 
>> P.S. I'm a bit confused about this discussion though, wouldn't adding 
>> python2 to
>> the installation be a feature change and as such not something that can be 
>> done
>> in a maintenance branch?
> 
> The purpose of the "no new features" rule is to prevent the situation
> where a piece of code written for X.X.2 fails to run on X.X.1 because
> it relies on a feature introduced in X.X.2.  In this situation, we
> *already* have failures because scripts using /usr/bin/python2 that
> run on one distro won't run on a different distro where that symlink
> isn't defined.  In this case I don't think the "no new features" rule
> can be applied blindly, because the feature has *already been introduced*
> by third parties.  What we are attempting to do is make it *more* likely
> that things will work in the future.

This is a new feature for the cannonical distribution, no release on python.org 
will install a binary named 'python2'. Adding one now will result in a clear 
change in behaviour: "#!/usr/bin/env python2" will work in 2.7.2 while it won't 
work with 2.7.1. That it happens to work right now with some python 
distributions doesn't mean this isn't a new feature, it's just another instance 
where the linux distribution maintainers think they know better than the 
developers.

> 
> You can argue that having /usr/bin/python2 installed by 2.7.2 means
> that code written for 2.7.2 that relies on it won't run on a vanilla
> user-install of 2.7.1 or 2.7.  But how likely is that scenario compared
> to the scenario where a script written for another distro fails to run
> because /usr/bin/python2 doesn't exist?  I think the balance of the
> argument comes down in favor of making the change, personally.

That depends on the distributions that have /usr/bin/python2 and change 
/usr/bin/python to be python3. IIRC the discussion only mentioned Arch Linux 
and Gentoo, which are AFAIK not major distributions. I'm personally unlikely to 
run into a distribution that has a broken /usr/bin/python anytime soon, most 
linux code I write runs on enterprise distributions and those aren't known for 
being frontrunners with changes like this ;-)

BTW. I'm +0 on the change, having python2 can be useful and while this is a new 
feature it doesn't require major changes when backporting scripts to previous 
patchlevels.

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] Unable to build old version from hg.python.org

2011-03-07 Thread Vinay Sajip

OK, I see issue 11421 on the tracker.

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

> For non-Windows, get people to run "make patchcheck".
The non-non-Windows equivalent should be something like “./python.exe
Tools/scripts/patchcheck.py” (I don’t remember if the leading ./ is
required).

FTR, what the make target is a bit more complicated:
“$(RUNSHARED) ./$(BUILDPYTHON) $(srcdir)/Tools/scripts/patchcheck.py”

Cheers
___
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] PyCObject_AsVoidPtr removed from python 3.2 - is this documented?

On Mon, 7 Mar 2011 19:14:55 +1000
Nick Coghlan  wrote:
> On Mon, Mar 7, 2011 at 6:36 PM, John Arbash Meinel
>  wrote:
> >
> > Especially since, AIUI, deprecations are suppressed by default now.
> 
> True, but developers are expected to run their tests with them enabled.

Where do we actually document this?


___
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] Official Roadmap (Re: Let's get PEP 380 into Python 3.3)

Hi,

> Roadmap is not a strict plan for release. It helps people
> *self-organize into teams* around specific feature or bugs.
I think the tracker is used to this effect with success.

> Yes, there can (or even should) be a way for everybody with Python
> account to vote on items in the Roadmap
Doing something is a good way to vote.  For example, on #2504, a number
of people added “+1” comments, but when I tried to move the patch
forward and asked for tests and reviews, nobody replied.  Votes without
commitment take time away from developers and don’t help with the work.

On the other hand, it is useful to get the feel of the community to know
what bugs or features are really desired by our users.  If someone tried
to create and maintain a roadmap, I’d be interested in the results.

Regards
___
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] Unable to build old version from hg.python.org

On Mon, 7 Mar 2011 11:40:04 + (UTC)
Vinay Sajip  wrote:
> I want to maintain several working copies, as sometimes I have to make bugfix
> changes across several revisions. Since we are supposed to use 
> forward-porting,
> I tried to set up a 2.5 clone,

Vinay, 2.5 has been long closed for bug fixes. You should target 2.7.

Thanks

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] PyCObject_AsVoidPtr removed from python 3.2 - is this documented?

2011-03-07 Thread Arfrever Frehtes Taifersar Arahesis

2011-03-07 10:33:17 Martin v. Löwis napisał(a):
> Am 07.03.2011 10:14, schrieb Nick Coghlan:
> > On Mon, Mar 7, 2011 at 6:36 PM, John Arbash Meinel
> >   wrote:
> >>
> >> Especially since, AIUI, deprecations are suppressed by default now.
> >
> > True, but developers are expected to run their tests with them enabled.
> 
> I think everything here is as it should be.

IMHO cobject.h should have been declaring deprecated functions with 
Py_DEPRECATED,
which would cause build-time deprecation warnings.

-- 
Arfrever Frehtes Taifersar Arahesis

signature.asc
Description: This is a digitally signed message part.
___
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] Official Roadmap (Re: Let's get PEP 380 into Python 3.3)

2011-03-07 Thread Westley Martínez

On Mon, 2011-03-07 at 15:54 +0100, Éric Araujo wrote:
> Hi,
> 
> > Roadmap is not a strict plan for release. It helps people
> > *self-organize into teams* around specific feature or bugs.
> I think the tracker is used to this effect with success.
> 
> > Yes, there can (or even should) be a way for everybody with Python
> > account to vote on items in the Roadmap
> Doing something is a good way to vote.  For example, on #2504, a number
> of people added “+1” comments, but when I tried to move the patch
> forward and asked for tests and reviews, nobody replied.  Votes without
> commitment take time away from developers and don’t help with the work.
> 
> On the other hand, it is useful to get the feel of the community to know
> what bugs or features are really desired by our users.  If someone tried
> to create and maintain a roadmap, I’d be interested in the results.
> 
> Regards
> ___
> 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/anikom15%40gmail.com

+1 for voting

___
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] Codereview on bugs.python.org ready for testing again


Martin> I ported the code review support on bugs.python.org to hg, and
Martin> reactivated it. Review "issues" are created automatically if the
Martin> attached file is recognized as a patch that applies cleanly. The
Martin> roundup issue's nosy list is synchronized with the rietveld
Martin> issue's cc list, so comments get mailed to the nosy list.

What should I be looking for?  For example, this issue:

http://bugs.python.org/issue11205

contains a patch but I don't see anything which looks like "create a
review".

Thx,

Skip

___
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] Unable to build old version from hg.python.org


Vinay> I want to maintain several working copies, as sometimes I have to
Vinay> make bugfix changes across several revisions. Since we are
Vinay> supposed to use forward-porting, I tried to set up a 2.5 clone,
Vinay> but building from it fails with a "Fatal Python error: subversion
Vinay> keywords missing".

I encountered the same problem.  My "solution" was to manually expand the
$HeadURL$ string at the top of posixmodule.c as it would have been expanded
by Subversion.  I then committed that locally.

Skip
___
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] Codereview on bugs.python.org ready for testing again

2011-03-07 Thread Brian Curtin

On Mon, Mar 7, 2011 at 09:15,  wrote:

>
>Martin> I ported the code review support on bugs.python.org to hg, and
>Martin> reactivated it. Review "issues" are created automatically if the
>Martin> attached file is recognized as a patch that applies cleanly. The
>Martin> roundup issue's nosy list is synchronized with the rietveld
>Martin> issue's cc list, so comments get mailed to the nosy list.
>
> What should I be looking for?  For example, this issue:
>
>http://bugs.python.org/issue11205
>
> contains a patch but I don't see anything which looks like "create a
> review".

The review was already created. Look to the left of the Remove button.
___
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] Support the /usr/bin/python2 symlink upstream

On Mar 04, 2011, at 12:00 PM, Toshio Kuratomi wrote:

>Actually, my post was saying that these two can be decoupled.  ie: It's
>possible to not have /usr/bin/python while still allowing users to type
>python at a shell prompt and get the interpreter.
>
>This is done by either redefining the PATH to include the directory that the
>interpreter named "python" is in or by creating an alias for python to the
>proper interpreter.

I personally would prefer aliasing rather than $PATH manipulation.

-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] Unable to build old version from hg.python.org

2011-03-07 Thread Vinay Sajip

Antoine Pitrou  pitrou.net> writes:

> 
> Vinay, 2.5 has been long closed for bug fixes. You should target 2.7.
> 

I understand that - I was only doing it as a forward-porting exercise as per
your suggestion on another thread about merge flow:

- on one hand: 2.5 -> 2.6 -> 2.7 (if you still want to maintain 2.5)
- on the other hand: 3.1 -> 3.2 -> default

As it happens, the fix I'm doing won't apply to 2.5 anyway, so it doesn't 
matter.

Regards,

Vinay Sajip

___
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] Unable to build old version from hg.python.org


>> Vinay, 2.5 has been long closed for bug fixes. You should target 2.7.

But it wasn't a bug in 2.5 per se, it was a bug introduced by the migration
from Subversion to Mercurial.  Perhaps Mercurial could be trained to expand
the $HeadURL$ string appropriately.  Failing that, I don't see any great
harm in expanding that string and checking it in, simply to avoid this
problem in the future.  I'm sure there are plenty of developers maintaining
external code which is still supposed to be 2.5-compatible.

Skip
___
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] Official Roadmap (Re: Let's get PEP 380 into Python 3.3)

2011-03-07 Thread Guido van Rossum

On Mon, Mar 7, 2011 at 6:59 AM, Westley Martínez  wrote:
> +1 for voting

Can we call it something else though? "Voting" reminds me too much of
situations where people who don't do anything get to say what they
want others to do. That doesn't sit well in a volunteer-run open
source project.

But it makes total sense to have e.g. the users of the language
express their needs or desires in a way that can guide volunteers
looking for a project in their selection of the most important goals.
For this some kind of "poll" makes sense -- the outcome is not binding
and the assumption is that only a small representation of users
express an opinion, but polls (when used properly) can still be very
useful.

As long as other forms of feedback aren't suppressed of frowned upon
-- not every need can conveniently be expressed in a binary choice.

-- 
--Guido van Rossum (python.org/~guido)
___
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 diff

2011-03-07 Thread Tres Seaver

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/06/2011 11:32 PM, "Martin v. Löwis" wrote:
> Am 07.03.2011 03:43, schrieb Stephen J. Turnbull:
>> "Martin v. Löwis" writes:
>>   >  Am 07.03.2011 02:24, schrieb Stephen J. Turnbull:
>>   >  >  "Martin v. Löwis" writes:
>>   >  >>   It seems that the dev guide recommends to use the --git option 
>> in hg
>>   >  >>   diff. I'm working on the Rietveld integration, and found that 
>> this
>>   >  >>   option makes things worse: the regular diff includes the base 
>> revision
>>   >  >>   of the patch; hg diff --git doesn't.
>>   >  >
>>   >  >  Does the regular diff work acceptably for the kinds of changes that
>>   >  >  diff --git was designed to be an improvement for?
>>   >
>>   >  I don't know. What are the kinds of changes that diff --git was designed
>>   >  for?
>>
>> I don't know exactly how much of git diffcore has been implemented in
>> hg diff --git.  However, git's diff handles renames and copies
>> correctly and pleasantly, including swapping file names (ie, renaming
>> a to b and b to a simultaneously), and can change file modes.
>>
>> That kind of change is rather unpleasant to deal with in a traditional
>> diff format.  Eg, renames are represented as deleting all the lines
>> from one file and re-adding them as a new file.
> 
> Ok, so the next question is what constitutes an acceptable 
> representation. I find the original approach to diff completely
> acceptable, also considering that people rarely rename files,
> and if they do, they typically don't put patches into a bug tracker.

If we can get to a mode where non-committers can push to a "fork" on
hg.python.org, we can dodge the patch format issue by having folks post
"pull requests" for that fork instaed.

For the repoze and pylons projects, we have found the quality and
quantity of patches went up *significantly* when we made it easy for
somebody who doesn't work on the code all the time to use this workflow
(fork to a public repo, clone, hack, commit, push, request a pull).


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/

iEYEARECAAYFAk11C4cACgkQ+gerLs4ltQ78JwCfSwyPfJHu1C7q25o54EIoOS7L
UrQAoIgNlPmes31eHEIQo1hEkoXxCbL2
=/+0X
-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 diff

On Mar 07, 2011, at 11:44 AM, Tres Seaver wrote:

>If we can get to a mode where non-committers can push to a "fork" on
>hg.python.org, we can dodge the patch format issue by having folks post
>"pull requests" for that fork instaed.
>
>For the repoze and pylons projects, we have found the quality and
>quantity of patches went up *significantly* when we made it easy for
>somebody who doesn't work on the code all the time to use this workflow
>(fork to a public repo, clone, hack, commit, push, request a pull).

+1.  'Branches' are better than patches.

-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] [PEPs] Support the /usr/bin/python2 symlink upstream

2011-03-07 Thread Sridhar Ratnakumar


On Sunday, March 6, 2011 at 9:53 AM, Brian Curtin wrote: 
> On Sun, Mar 6, 2011 at 11:41, Michael Foord  wrote:
> - Hide quoted message -
> > I would like to see us create version specific (i.e. python32.exe / 
> > python32w.exe) binaries (or links if we drop support for earlier versions 
> > of Windows or some filesystems - I'm agnostic on that issue) *plus* a 
> > python3.exe / python3w.exe with "last install wins" (as it is for currently 
> > for file associations).
> > 
> 
> I don't have an ActiveState install on this machine, but I know they have 
> been adding some form of version specific binaries for a while, so maybe they 
> can comment on what they chose and how they chose it, and how people are 
> using it. Are Sridhar or Trent on here?
> 
 ActivePython for Windows includes the following binaries on Windows: 

* python.exe
* python3.2.exe
* python3.xe 
(plus the `pythonw` versions)

python3.2.exe is better than python32.exe because that matches the invocation 
(eg: "python3.2 -m foo") on Unix.

Similarly for 2.x (python2.exe / python2.7.exe).

All of this is particularly useful if the installer adds Python directory to 
%PATH% (which is the case for ActivePython, but not the one from python.org).

-srid ___
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 diff

On Mon, 7 Mar 2011 12:04:18 -0500
Barry Warsaw  wrote:
> On Mar 07, 2011, at 11:44 AM, Tres Seaver wrote:
> 
> >If we can get to a mode where non-committers can push to a "fork" on
> >hg.python.org, we can dodge the patch format issue by having folks post
> >"pull requests" for that fork instaed.
> >
> >For the repoze and pylons projects, we have found the quality and
> >quantity of patches went up *significantly* when we made it easy for
> >somebody who doesn't work on the code all the time to use this workflow
> >(fork to a public repo, clone, hack, commit, push, request a pull).
> 
> +1.  'Branches' are better than patches.

How do you review a branch?


___
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 diff

On Mar 07, 2011, at 06:31 PM, Antoine Pitrou wrote:

>On Mon, 7 Mar 2011 12:04:18 -0500
>Barry Warsaw  wrote:
>> On Mar 07, 2011, at 11:44 AM, Tres Seaver wrote:
>> 
>> >If we can get to a mode where non-committers can push to a "fork" on
>> >hg.python.org, we can dodge the patch format issue by having folks post
>> >"pull requests" for that fork instaed.
>> >
>> >For the repoze and pylons projects, we have found the quality and
>> >quantity of patches went up *significantly* when we made it easy for
>> >somebody who doesn't work on the code all the time to use this workflow
>> >(fork to a public repo, clone, hack, commit, push, request a pull).
>> 
>> +1.  'Branches' are better than patches.
>
>How do you review a branch?

You can merge it locally and look at the diff.  Or use Rietveld if that's
supported.  But the reason a branch is better is because it's easier to track
the submitter's changes in response to your review comments, and it's easier
to make changes to their branch and push an update for *them* to see.

It's easier to have a ongoing conversation about a branch than a patch.

-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] [Python-checkins] (2.6): Issue #11424: Fix bug in determining child loggers.

Hello,

> changeset:   68315:b9d76846bb1c
> branch:  2.6
> parent:  68264:50166a4bcfc6
> user:Vinay Sajip 
> date:Mon Mar 07 15:02:11 2011 +
> summary:
>   Issue #11424: Fix bug in determining child loggers.

This does not look like a security bug, and is therefore not suitable
for 2.6.

Hook authors: including the local revision number in the -checkins
messages is misleading and possibly harmful.

Regards
___
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 diff

2011-03-07 Thread Thomas Wouters

On Mon, Mar 7, 2011 at 10:04, Barry Warsaw  wrote:

> On Mar 07, 2011, at 06:31 PM, Antoine Pitrou wrote:
>
> >On Mon, 7 Mar 2011 12:04:18 -0500
> >Barry Warsaw  wrote:
> >> On Mar 07, 2011, at 11:44 AM, Tres Seaver wrote:
> >>
> >> >If we can get to a mode where non-committers can push to a "fork" on
> >> >hg.python.org, we can dodge the patch format issue by having folks
> post
> >> >"pull requests" for that fork instaed.
> >> >
> >> >For the repoze and pylons projects, we have found the quality and
> >> >quantity of patches went up *significantly* when we made it easy for
> >> >somebody who doesn't work on the code all the time to use this workflow
> >> >(fork to a public repo, clone, hack, commit, push, request a pull).
> >>
> >> +1.  'Branches' are better than patches.
> >
> >How do you review a branch?
>
> You can merge it locally and look at the diff.  Or use Rietveld if that's
> supported.  But the reason a branch is better is because it's easier to
> track
> the submitter's changes in response to your review comments, and it's
> easier
> to make changes to their branch and push an update for *them* to see.
>
> It's easier to have a ongoing conversation about a branch than a patch.

While I agree that *maintaining* the patch is easier in a branch, I don't
agree that it's necessarily easier to review it: in Rietveld (by design!)
subsequent uploads look very much like changes in a branch. The only
difference with peeking directly in the branch is that it requires an
explicit upload by the patch-owner, which actually has its upsides as well
(no need for Rietveld to 'poll' changes, an explicit 'ok, updated according
to feedback' report, no irrelevant intermediate changes to get confused at.)
There's one thing Rietveld always has a bit of trouble representing, that
being merges with another branch, but it's hard to imagine a clearer way to
represent it without conflating the whole thing, and frankly it does a
better job of it than 'hg diff' in the branch itself :-)

-- 
Thomas Wouters 

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
___
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 diff


On 07/03/2011 18:32, Thomas Wouters wrote:



On Mon, Mar 7, 2011 at 10:04, Barry Warsaw > wrote:


On Mar 07, 2011, at 06:31 PM, Antoine Pitrou wrote:

>On Mon, 7 Mar 2011 12:04:18 -0500
>Barry Warsaw mailto:ba...@python.org>> wrote:
>> On Mar 07, 2011, at 11:44 AM, Tres Seaver wrote:
>>
>> >If we can get to a mode where non-committers can push to a
"fork" on
>> >hg.python.org , we can dodge the patch
format issue by having folks post
>> >"pull requests" for that fork instaed.
>> >
>> >For the repoze and pylons projects, we have found the quality and
>> >quantity of patches went up *significantly* when we made it
easy for
>> >somebody who doesn't work on the code all the time to use this
workflow
>> >(fork to a public repo, clone, hack, commit, push, request a
pull).
>>
>> +1.  'Branches' are better than patches.
>
>How do you review a branch?

You can merge it locally and look at the diff.  Or use Rietveld if
that's
supported.  But the reason a branch is better is because it's
easier to track
the submitter's changes in response to your review comments, and
it's easier
to make changes to their branch and push an update for *them* to see.

It's easier to have a ongoing conversation about a branch than a
patch.


While I agree that *maintaining* the patch is easier in a branch, I 
don't agree that it's necessarily easier to review it: in Rietveld (by 
design!) subsequent uploads look very much like changes in a branch.


With the right tools reviewing branches

The only difference with peeking directly in the branch is that it 
requires an explicit upload by the patch-owner, which actually has its 
upsides as well (no need for Rietveld to 'poll' changes, an explicit 
'ok, updated according to feedback' report, no irrelevant intermediate 
changes to get confused at.) There's one thing Rietveld always has a 
bit of trouble representing, that being merges with another branch, 
but it's hard to imagine a clearer way to represent it without 
conflating the whole thing, and frankly it does a better job of it 
than 'hg diff' in the branch itself :-)


--
Thomas Wouters mailto:tho...@python.org>>

Hi! I'm a .signature virus! copy me into your .signature file to help 
me spread!



___
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] [Python-checkins] (2.6): Issue #11424: Fix bug in determining child loggers.

On Mon, 07 Mar 2011 19:29:51 +0100
Éric Araujo  wrote:
> Hello,
> 
> > changeset:   68315:b9d76846bb1c
> > branch:  2.6
> > parent:  68264:50166a4bcfc6
> > user:Vinay Sajip 
> > date:Mon Mar 07 15:02:11 2011 +
> > summary:
> >   Issue #11424: Fix bug in determining child loggers.
> 
> This does not look like a security bug, and is therefore not suitable
> for 2.6.
> 
> Hook authors: including the local revision number in the -checkins
> messages is misleading and possibly harmful.

We're using the stock template output from Mercurial (the one you get
when typing "hg log -v -r ").  Another issue is
that the "files" section in merges doesn't show all affected
files.  Patches welcome (the hooks are in hg.python.org/hooks).

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 diff

On Mon, 7 Mar 2011 13:04:11 -0500
Barry Warsaw  wrote:

> On Mar 07, 2011, at 06:31 PM, Antoine Pitrou wrote:
> 
> >On Mon, 7 Mar 2011 12:04:18 -0500
> >Barry Warsaw  wrote:
> >> On Mar 07, 2011, at 11:44 AM, Tres Seaver wrote:
> >> 
> >> >If we can get to a mode where non-committers can push to a "fork" on
> >> >hg.python.org, we can dodge the patch format issue by having folks post
> >> >"pull requests" for that fork instaed.
> >> >
> >> >For the repoze and pylons projects, we have found the quality and
> >> >quantity of patches went up *significantly* when we made it easy for
> >> >somebody who doesn't work on the code all the time to use this workflow
> >> >(fork to a public repo, clone, hack, commit, push, request a pull).
> >> 
> >> +1.  'Branches' are better than patches.
> >
> >How do you review a branch?
> 
> You can merge it locally and look at the diff.  Or use Rietveld if that's
> supported.  But the reason a branch is better is because it's easier to track
> the submitter's changes in response to your review comments, and it's easier
> to make changes to their branch and push an update for *them* to see.

I agree with Thomas' answer here: while a branch makes it easier to
maintain a patch (but you can also use e.g. Mercurial Queues), it
doesn't make it easier to *review*.  You are assuming that I, as a
reviewer, want to know about the history of changesets that led to the
patch, but I don't: I want to read the patch as a cohesive whole, and I
couldn't care less about the various typo fixes, style changes,
performance tweaks that were checked in all along.

So, I'd rather have the submitter post a patch, than generate it
myself. Meaning that if I have to generate it myself, I might be too
lazy (or overworked) and not do a review at all.

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 diff


On 07/03/2011 18:35, Michael Foord wrote:

On 07/03/2011 18:32, Thomas Wouters wrote:



On Mon, Mar 7, 2011 at 10:04, Barry Warsaw > wrote:


On Mar 07, 2011, at 06:31 PM, Antoine Pitrou wrote:

>On Mon, 7 Mar 2011 12:04:18 -0500
>Barry Warsaw mailto:ba...@python.org>> wrote:
>> On Mar 07, 2011, at 11:44 AM, Tres Seaver wrote:
>>
>> >If we can get to a mode where non-committers can push to a
"fork" on
>> >hg.python.org , we can dodge the patch
format issue by having folks post
>> >"pull requests" for that fork instaed.
>> >
>> >For the repoze and pylons projects, we have found the quality and
>> >quantity of patches went up *significantly* when we made it
easy for
>> >somebody who doesn't work on the code all the time to use
this workflow
>> >(fork to a public repo, clone, hack, commit, push, request a
pull).
>>
>> +1.  'Branches' are better than patches.
>
>How do you review a branch?

You can merge it locally and look at the diff.  Or use Rietveld
if that's
supported.  But the reason a branch is better is because it's
easier to track
the submitter's changes in response to your review comments, and
it's easier
to make changes to their branch and push an update for *them* to see.

It's easier to have a ongoing conversation about a branch than a
patch.


While I agree that *maintaining* the patch is easier in a branch, I 
don't agree that it's necessarily easier to review it: in Rietveld 
(by design!) subsequent uploads look very much like changes in a branch.


With the right tools reviewing branches



Dammit, meant to cancel that email not send. Anyway, with the right 
tools reviewing a branch is trivially easy as it will *show* you a diff. 
This is what launchpad does for bzr merge proposals and how we do code 
reviews. It's great. :-)


Michael

The only difference with peeking directly in the branch is that it 
requires an explicit upload by the patch-owner, which actually has 
its upsides as well (no need for Rietveld to 'poll' changes, an 
explicit 'ok, updated according to feedback' report, no irrelevant 
intermediate changes to get confused at.) There's one thing Rietveld 
always has a bit of trouble representing, that being merges with 
another branch, but it's hard to imagine a clearer way to represent 
it without conflating the whole thing, and frankly it does a better 
job of it than 'hg diff' in the branch itself :-)


--
Thomas Wouters mailto:tho...@python.org>>

Hi! I'm a .signature virus! copy me into your .signature file to help 
me spread!



___
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 blessinghttp://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/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] hg diff

On Mar 07, 2011, at 07:44 PM, Antoine Pitrou wrote:

>I agree with Thomas' answer here: while a branch makes it easier to
>maintain a patch (but you can also use e.g. Mercurial Queues), it
>doesn't make it easier to *review*.  You are assuming that I, as a
>reviewer, want to know about the history of changesets that led to the
>patch, but I don't: I want to read the patch as a cohesive whole, and I
>couldn't care less about the various typo fixes, style changes,
>performance tweaks that were checked in all along.

I hear this complaint a lot from hg and git users, so maybe it's just the
nature of the tools.  In which case, I'm fine with whatever works better for
Python.

-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] [PEPs] Support the /usr/bin/python2 symlink upstream

2011-03-07 Thread Ethan Furman


Tim Golden wrote:

On 07/03/2011 10:49, Mark Hammond wrote:

On 7/03/2011 9:33 PM, Paul Moore wrote:

That sounds like a fairly cool idea. So if I follow what you're
suggesting, we'd have a single python.exe, probably installed in
system32, which did the necessary command line juggling and shebang
parsing, then simply redirected to the appropriate Python interpreter?
Presumably that launcher would be pretty version independent, so (a)
the one that gets installed with Python 3.3 would support older
versions even though they didn't include the launcher themselves, (b)
overwriting the launcher when a new version of Python is installed
wouldn't be too big a deal, and (c) it could be released as a
standalone package for people with only older versions of Python
installed?


Yup - although I think a pythonw.exe launcher would be needed too (for
the same reasons we need python.exe and pythonw.exe today)


I like this idea. If I had the spare time (I don't :-() I'd work on
this myself.

+1 from me.


Agreed all round. 


+1 here also.  This seems a sensible solution to the 'Windows Problem'.  ;)

~Ethan~
___
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] PyCObject_AsVoidPtr removed from python 3.2 - is this documented?

2011-03-07 Thread Terry Reedy


On 3/7/2011 9:47 AM, Antoine Pitrou wrote:

On Mon, 7 Mar 2011 19:14:55 +1000
Nick Coghlan  wrote:

On Mon, Mar 7, 2011 at 6:36 PM, John Arbash Meinel
  wrote:


Especially since, AIUI, deprecations are suppressed by default now.


True, but developers are expected to run their tests with them enabled.


Where do we actually document this?


Should be, and maybe is, in the nice new dev guide.

Also, the doc for unittest.TextTestRunner says "By default this runner 
shows DeprecationWarning, PendingDeprecationWarning, and ImportWarning 
even if they are ignored by default." The idea (discussed here) is that 
developers of a module should see warnings when testing, even if users 
of the module do not. I am not sure whether above applies when running 
through unittest.main, but it should.


--
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] [Python-checkins] r88709 - in python/branches/py3k: Misc/NEWS Objects/unicodeobject.c

2011-03-07 Thread Terry Reedy


On 3/7/2011 5:54 AM, Victor Stinner wrote:


I don’t really understand this message (especially “cached into the
object”) :)  Maybe in the Misc/NEWS entry you could also add a line to
explain to users the reason/goal/benefit of this change?


If you call str.encode() twice: the first call stores the result in a
cache, and the second call just reuse the cache. The benefit is that the
second call is much faster.

The cache is an internal attribute of the Unicode object (str type).

Do you have a suggestion to rephrase the Misc/NEWS entry?


(Without reading the entire entry,) something like:
'More consistently cached as an internal attribute of the str object for 
possible later reuse.'



--
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] PyCObject_AsVoidPtr removed from python 3.2 - is this documented?


On 07/03/2011 19:45, Terry Reedy wrote:

On 3/7/2011 9:47 AM, Antoine Pitrou wrote:

On Mon, 7 Mar 2011 19:14:55 +1000
Nick Coghlan  wrote:

On Mon, Mar 7, 2011 at 6:36 PM, John Arbash Meinel
  wrote:


Especially since, AIUI, deprecations are suppressed by default now.


True, but developers are expected to run their tests with them enabled.


Where do we actually document this?


Should be, and maybe is, in the nice new dev guide.

Also, the doc for unittest.TextTestRunner says "By default this runner 
shows DeprecationWarning, PendingDeprecationWarning, and ImportWarning 
even if they are ignored by default." The idea (discussed here) is 
that developers of a module should see warnings when testing, even if 
users of the module do not. I am not sure whether above applies when 
running through unittest.main, but it should.


I believe it does apply through unittest.main() - Ezio would know best 
as he implemented this feature though.


All the best,

Michael

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

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.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] hg pull failed

2011-03-07 Thread Terry Reedy


On 3/7/2011 2:16 AM, Georg Brandl wrote:

On 07.03.2011 00:16, Terry Reedy wrote:



But would it work


??

 to just pull once into default from the central

repository (slow) and then pull from there (fast) into maintenance
clones? I expect to nearly always be only working on issues that affect
default.


Pulling just a few changes into local clones from remote should always be fast.


On my current older WinXP machine, the startup time to do anything with 
the svn repository was about 10 secs. Long enough to be a drag, not long 
enough to do much else ;-). Maybe it will be faster with *nix or newer 
Windows, hg, and newer machine (all of which I plan to get).


--
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] [Python-checkins] (2.6): Issue #11424: Fix bug in determining child loggers.

2011-03-07 Thread Georg Brandl

On 07.03.2011 19:29, Éric Araujo wrote:
> Hello,
> 
>> changeset:   68315:b9d76846bb1c
>> branch:  2.6
>> parent:  68264:50166a4bcfc6
>> user:Vinay Sajip 
>> date:Mon Mar 07 15:02:11 2011 +
>> summary:
>>   Issue #11424: Fix bug in determining child loggers.
> 
> This does not look like a security bug, and is therefore not suitable
> for 2.6.
> 
> Hook authors: including the local revision number in the -checkins
> messages is misleading and possibly harmful.

In this case, it's not really a local revision number, but the revision
number in the authoritative upstream repository.

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] PyCObject_AsVoidPtr removed from python 3.2 - is this documented?

On Mon, 07 Mar 2011 14:45:57 -0500
Terry Reedy  wrote:
> On 3/7/2011 9:47 AM, Antoine Pitrou wrote:
> > On Mon, 7 Mar 2011 19:14:55 +1000
> > Nick Coghlan  wrote:
> >> On Mon, Mar 7, 2011 at 6:36 PM, John Arbash Meinel
> >>   wrote:
> >>>
> >>> Especially since, AIUI, deprecations are suppressed by default now.
> >>
> >> True, but developers are expected to run their tests with them enabled.
> >
> > Where do we actually document this?
> 
> Should be, and maybe is, in the nice new dev guide.

The dev guide is for development *of* Python, not *with* 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] [PEPs] Support the /usr/bin/python2 symlink upstream


On 07/03/2011 05:19, Mark Hammond wrote:

[snip...]

(B) declare the Python version in the content of the script file. This
cures most of the ripple effects of the above, but requires a "launcher"
or "wrapper" program to be designed, implemented, and installed. There
are a variety of subsolutions for different ways of declaring the 
version.




Without putting too much thought into it, I think a simple scheme 
could work where the path must either be "/usr/bin/python[23]?" or a 
fully-qualified path to a Python executable.  IIUC, this should allow 
most scripts to have a shebang line that "does the right thing" on 
*nix and Windows systems while still offering maximum flexibility on 
Windows.




"/usr/bin/env python" is popular too, and it would be nice to support 
the new aliases (or binaries) being created by the pep (python2 / python3).


Michael


By default, for Python, the wrapper would get associated only with .py
files.


There would probably also need to be the same for ".pyw", but it would 
be almost identical to the .py handling.


Cheers,

Mark
___
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] [PEPs] Support the /usr/bin/python2 symlink upstream


On 07/03/2011 17:21, Sridhar Ratnakumar wrote:


On Sunday, March 6, 2011 at 9:53 AM, Brian Curtin wrote:

On Sun, Mar 6, 2011 at 11:41, Michael Foord>wrote:

- Hide quoted message -
I would like to see us create version specific (i.e. python32.exe / 
python32w.exe) binaries (or links if we drop support for earlier 
versions of Windows or some filesystems - I'm agnostic on that 
issue) *plus* a python3.exe / python3w.exe with "last install wins" 
(as it is for currently for file associations).
I don't have an ActiveState install on this machine, but I know they 
have been adding some form of version specific binaries for a while, 
so maybe they can comment on what they chose and how they chose it, 
and how people are using it. Are Sridhar or Trent on here?

ActivePython for Windows includes the following binaries on Windows:

* python.exe
* python3.2.exe
* python3.xe
(plus the `pythonw` versions)

python3.2.exe is better than python32.exe because that matches the 
invocation (eg: "python3.2 -m foo") on Unix.


Similarly for 2.x (python2.exe / python2.7.exe).

All of this is particularly useful if the installer adds Python 
directory to %PATH% (which is the case for ActivePython, but not the 
one from python.org).


Sounds ideal. :-)

Michael



-srid



--
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] [PEPs] Support the /usr/bin/python2 symlink upstream


On 07/03/2011 01:18, Mark Hammond wrote:

[snip...]
That said though, I'm only -0 on python2.exe/python3.exe - I don't 
think it will hurt, but also don't think it will help that much in 
practice. It may also turn out to be unnecessary should a "complete" 
solution be implemented - eg, a "python launcher" which (a) read the 
shebang lines and (b) allowed something like "python -3" on the 
command-line would render both python3.exe and requests to have 
multiple installed Python versions on the PATH redundant.




A python launcher as you describe is a *great* idea.

A few concerns:

* we're missing an opportunity to do something easy (Martin is happy to 
modify the installer and says it is easy) for something that may or may 
not happen


* will you call it python.exe? will it be installed by the python 
installer?


- I doubt calling it python.exe will fly, but I'm not sure. If so 
what will you call what is currently 'python.exe'? - if not then "python 
foo.py" on the command line will *still* not work...


- it will still have to be installed on the PATH, but I guess 
System32 will do for that - users without admin rights will still have 
to modify their PATH manually and place it somewhere else


* we're (yet again) making instructions for running stuff on Windows 
*different* to other platforms (and making tutorials written for other 
pythons "not work" in certain ways)


* as I work with multiple platforms it would be really nice if the same 
invocations worked across all of them - whilst I say again that I really 
like the idea of the launcher it doesn't conflict with the other 
suggestions (creating multiple binaries) and as you (Mark) say it 
wouldn't hurt...


So why not do both? We could create the extra binaries to bring Python 
on Windows inline with the unix conventions for command line 
invocations, and the new launcher can follow on as a nice addition.


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


All the best,

Michael Foord


Cheers,

Mark



--
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] [PEPs] Support the /usr/bin/python2 symlink upstream

2011-03-07 Thread Paul Moore

On 7 March 2011 20:33, Michael Foord  wrote:
> So why not do both? We could create the extra binaries to bring Python on
> Windows inline with the unix conventions for command line invocations, and
> the new launcher can follow on as a nice addition.

I was assuming that the exes in the installation directories would
include version-specific ones (bringing Windows in line with Unix
behaviour) and the python.exe launcher would be in system32 (making
python foo.py work on the command line) and would redirect to the
"default" python for the box (or a specific one, if -2, -3, -2.7 or
whatever flags were specified).

The launcher could also (as per Mark's suggestion) interpret a shebang
line in the script, so that scripts could specify their required
version without needing a different command,or multiple
version-specific extensions.

So yes, let's do both. That's certainly what I expected.
Paul.
___
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] combined hg incoming patch


I'd like to experiment with adding Rietveld support for reviewing
remote repositories. For that, I'd need to create a single patch
(programmatically) that covers all incoming changes. 'hg incoming -p'
mostly works, but it may provide multiple patches for a single file,
which I think would harm the review (since some changes may be 
superseded in a separate patch).


So I would need to compute the most recent revision in both 
repositories, and then create a diff between the default head

of the remote repository and that base revision.

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] Obsolete content at http://www.python.org/dev/* ?

2011-03-07 Thread Ned Deily

With the transition to the new devguide, references to the main page of 
the old dev section of the website, http://www.python.org/dev/, redirect 
to http://docs.python.org/devguide/, the main page of the new guide.  
However, many links to some obsoleted sections of the old dev section 
are out in the wild (and showing up prominently in Google searches) and 
the webserver still seems to be serving up those obsolete links even 
though they appear to have been deleted from the www repo, for instance, 
the old links previously under Core Development on the left margin bar:

http://www.python.org/dev/faq/
http://www.python.org/dev/setup/
http://www.python.org/dev/tools/
etc

I was going to suggest that the webserver be changed to redirect all 
/dev/* references to /devguide/ but then I noticed that's it not that 
simple as there are other valid links still under /dev:

http://www.python.org/dev/buildbot/
http://www.python.org/dev/peps/
http://www.python.org/dev/pydotorg/
http://www.python.org/dev/searchplugin/

So I think there are two issues here:
1. deleted webpages cached by the webserver
2. adding redirects from /dev/{faq|setup|tools| et al } to 
docs.python.org/devguide

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

[Python-Dev] PyCon blogging?

Anybody here (or elsewhere) with plans to blog at PyCon for those of us not
going?

Thx,

Skip

___
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] PyCon blogging?

2011-03-07 Thread Brian Curtin

On Mon, Mar 7, 2011 at 15:45,  wrote:

> Anybody here (or elsewhere) with plans to blog at PyCon for those of us not
> going?
>
> Thx,
>
> Skip

I've been writing a lot lately for the PyCon blog so I might as well keep
that up. I'll try to write something up for the language summit, and I
imagine I could do some sort of daily summary as well.
___
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] combined hg incoming patch

2011-03-07 Thread Brendan Cully

On 2011-03-07, at 1:03 PM, Martin v. Löwis wrote:

> I'd like to experiment with adding Rietveld support for reviewing
> remote repositories. For that, I'd need to create a single patch
> (programmatically) that covers all incoming changes. 'hg incoming -p'
> mostly works, but it may provide multiple patches for a single file,
> which I think would harm the review (since some changes may be superseded in 
> a separate patch).
> 
> So I would need to compute the most recent revision in both repositories, and 
> then create a diff between the default head
> of the remote repository and that base revision.

You might like the rdiff extension, which does essentially this.

http://mercurial.selenic.com/wiki/RdiffExtension

___
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] [PEPs] Support the /usr/bin/python2 symlink upstream

2011-03-07 Thread James Y Knight

On Mar 7, 2011, at 3:49 PM, Paul Moore wrote:
> The launcher could also (as per Mark's suggestion) interpret a shebang
> line in the script, so that scripts could specify their required
> version without needing a different command,or multiple
> version-specific extensions.

Note that, on Unix, "python file.py" doesn't choose the correct version of 
python to run by looking at a shebang, it just runs the version of python 
installed as "python". Only "./file.py" looks at the shebang (assuming that 
file is marked executable). 

Is the proposal to make python.exe do that on windows? That is a rather 
significant difference from the unix behavior.
___
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] combined hg incoming patch


Am 07.03.2011 23:09, schrieb Brendan Cully:

On 2011-03-07, at 1:03 PM, Martin v. Löwis wrote:


I'd like to experiment with adding Rietveld support for reviewing
remote repositories. For that, I'd need to create a single patch
(programmatically) that covers all incoming changes. 'hg incoming -p'
mostly works, but it may provide multiple patches for a single file,
which I think would harm the review (since some changes may be superseded in a 
separate patch).

So I would need to compute the most recent revision in both repositories, and 
then create a diff between the default head
of the remote repository and that base revision.


You might like the rdiff extension, which does essentially this.

http://mercurial.selenic.com/wiki/RdiffExtension


I've looked at it, and it does something different. It computes the diff 
between the local tip and the remote tip. What I want is a diff between 
the common ancestor between the two, and the remote tip.


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] Support the /usr/bin/python2 symlink upstream

2011-03-07 Thread Nick Coghlan

On Tue, Mar 8, 2011 at 1:30 AM, Barry Warsaw  wrote:
> On Mar 04, 2011, at 12:00 PM, Toshio Kuratomi wrote:
>
>>Actually, my post was saying that these two can be decoupled.  ie: It's
>>possible to not have /usr/bin/python while still allowing users to type
>>python at a shell prompt and get the interpreter.
>>
>>This is done by either redefining the PATH to include the directory that the
>>interpreter named "python" is in or by creating an alias for python to the
>>proper interpreter.
>
> I personally would prefer aliasing rather than $PATH manipulation.

Toshio's suggestion wouldn't work anyway - the "/usr/bin/env python"
idiom will pick up a "python" alias no matter where it lives on $PATH.

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] [PEPs] Support the /usr/bin/python2 symlink upstream

On 07/03/2011 22:18, James Y Knight wrote:

On Mar 7, 2011, at 3:49 PM, Paul Moore wrote:

The launcher could also (as per Mark's suggestion) interpret a shebang
line in the script, so that scripts could specify their required
version without needing a different command,or multiple
version-specific extensions.

Note that, on Unix, "python file.py" doesn't choose the correct version of python to run by looking
at a shebang, it just runs the version of python installed as "python". Only "./file.py"
looks at the shebang (assuming that file is marked executable).

Is the proposal to make python.exe do that on windows? That is a rather
significant difference from the unix behavior.

By default "python.exe" is not on the path in windows, so unless the
current directory is the python install (or you have manually changed
your path) "python foo.py" does *nothing*. That is a *very* big
difference from unix behaviour.

The proposal is (apparently) to create another executable called
"python.exe" that is put on the path by the installer (if the user has
the right permissions to do this).

I believe the intention is that "python foo.py" *will* then lookup the
shebang to run the "right" version of python, defaulting to the last
installed version of python (I assume).

All the best,

Michael Foord

___
Python-Dev mailing list
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] combined hg incoming patch

2011-03-07 Thread Brendan Cully

On 2011-03-07, at 2:18 PM, Martin v. Löwis wrote:

> Am 07.03.2011 23:09, schrieb Brendan Cully:
>> On 2011-03-07, at 1:03 PM, Martin v. Löwis wrote:
>> 
>>> I'd like to experiment with adding Rietveld support for reviewing
>>> remote repositories. For that, I'd need to create a single patch
>>> (programmatically) that covers all incoming changes. 'hg incoming -p'
>>> mostly works, but it may provide multiple patches for a single file,
>>> which I think would harm the review (since some changes may be superseded 
>>> in a separate patch).
>>> 
>>> So I would need to compute the most recent revision in both repositories, 
>>> and then create a diff between the default head
>>> of the remote repository and that base revision.
>> 
>> You might like the rdiff extension, which does essentially this.
>> 
>> http://mercurial.selenic.com/wiki/RdiffExtension
> 
> I've looked at it, and it does something different. It computes the diff 
> between the local tip and the remote tip. What I want is a diff between the 
> common ancestor between the two, and the remote tip.

Ah right. Well, I think this shell should work (with hg new enough to have 
revsets):

hg in --bundle tmp.bundle
hg diff -r 'outgoing(.)' -R tmp.bundle

___
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] PyCon blogging?

2011-03-07 Thread Nick Coghlan

On Tue, Mar 8, 2011 at 7:45 AM,   wrote:
> Anybody here (or elsewhere) with plans to blog at PyCon for those of us not
> going?

Since I'll likely forget it myself otherwise, I'll probably be posting
stuff about the language summit and the sprints:
http://www.boredomandlaziness.org

How much I post will depend on how much downtime I end up with, though.

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] What does the "m" mean for the Mac OS X include folder?

2011-03-07 Thread Barry Scott


On 7 Mar 2011, at 01:46, Ned Deily wrote:

> In article <5ab965c9-7d5f-41b6-a5e9-2b881e92a...@barrys-emacs.org>,
> Barry Scott  wrote:
>> There is a break with convention for the include folder name:
>> 
>> /Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/
>> 
>> What does the "m" mean?
> 
> The "m" means that the Python was configured and built with pymalloc.
> 
> This change was introduced by Issue9807 "deriving configuration 
> information for different builds with the same prefix" which is an 
> adjunct to PEP 3149 "ABI version tagged .so files".  As described in the 
> PEP, the idea is to allow the installation of multiple build variants on 
> one system, for instance, a set of debug shared libraries (with flag 
> "d") alongside the normal optimized libraries.  This was extended in 
> Issue9807 to cover the corresponding Include files.   On current Debian 
> installs of python3.2, for instance, one sees:
> 
> $ ls -ld /usr/include/python3.2*
> lrwxrwxrwx [...] /usr/include/python3.2 -> python3.2mu
> drwxr-xr-x [...] /usr/include/python3.2mu
> 
> ("u" means "wide-unicode".)
> 
> For OS X framework builds, the unversioned convenience link is not 
> created:
> 
> $ cd /Library/Frameworks/Python.framework/Versions/3.2
> $ ls -l
> lrwxr-xr-x [...] Headers@ -> include/python3.2m
> -r-xrwxr-x [...] Python*
> drwxrwxr-x [...] Resources/
> drwxrwxr-x [...] bin/
> drwxrwxr-x [...] include/
> drwxrwxr-x [...] lib/
> drwxrwxr-x [...] share/
> $ ls -ld ./include/python3.2*
> drwxrwxr-x [...] ./include/python3.2m/
> 
> Perhaps it should.  And the implications of the multiple build variants 
> feature for OS X frameworks build have probably not yet been fully 
> considered.  However, there are now multiple ways to find the proper 
> location of the include files and library files, both in 
> platform-independent and framework-specific (note the "Headers" link) 
> ways.  And they all seem to produce the correct results.
> 
> $ bin/python3.2
 import sysconfig
 sysconfig.get_path('include')
> '/Library/Frameworks/Python.framework/Versions/3.2-release_10.6/include/p
> ython3.2m'
> ^D
> $ bin/python3-config --include
> -I/Library/Frameworks/Python.framework/Versions/3.2-release_10.6/include/
> python3.2m 
> -I/Library/Frameworks/Python.framework/Versions/3.2-release_10.6/include/
> python3.2m
> 
> (So good you get it twice in the same line.)
> 
> In some ways, this issue falls into a bit of a black hole.  For other 
> Unix-y platforms, the PSF (python.org) does not provide binaries or 
> installers so issues like installation locations are to some extent at 
> the discretion of the various distributors (Debian, Fedora, et al).  For 
> Mac OS X and Windows, the PSF also plays the role of binaries/installer 
> distributor so some things specific to those installers may need to be 
> documented outside of the standard Python documentation set (or properly 
> noted).
> 
> Feel free to open an issue if you feel something should be changed (code 
> or documentation).

Thanks for this full explanation.

I can use the Headers link and that will make it possible to do the same thing
for compiling against all versions from 2.4 to 3.2.

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/archive%40mail-archive.com

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

2011-03-07 Thread Mark Hammond


On 8/03/2011 7:33 AM, Michael Foord wrote:

A python launcher as you describe is a *great* idea.

A few concerns:

* we're missing an opportunity to do something easy (Martin is happy to
modify the installer and says it is easy) for something that may or may
not happen


Don't let my -0 stop anyone :)


* will you call it python.exe? will it be installed by the python
installer?

- I doubt calling it python.exe will fly, but I'm not sure. If so what
will you call what is currently 'python.exe'? - if not then "python
foo.py" on the command line will *still* not work...


Calling it python.exe would make the most sense for people who don't 
look behind the curtain, but I agree it could potentially be confusing 
for people.  Further, we would need to ensure we didn't create an 
infinite loop where the launcher python.exe found a python.exe it 
thought was an appropriate sub-process, but where it turns out it is 
actually another launcher.


Having it installed by the Python installer also makes sense to me but 
I'd be very interested in Martin's take on this (and also on everything 
else we are discussing here).



* we're (yet again) making instructions for running stuff on Windows
*different* to other platforms (and making tutorials written for other
pythons "not work" in certain ways)


Actually, I'd argue we are making them more similar as we would be 
honoring a shebang line and allowing the exact same mechanism be used to 
denote the major version of Python needed.



* as I work with multiple platforms it would be really nice if the same
invocations worked across all of them - whilst I say again that I really
like the idea of the launcher it doesn't conflict with the other
suggestions (creating multiple binaries) and as you (Mark) say it
wouldn't hurt...

So why not do both? We could create the extra binaries to bring Python
on Windows inline with the unix conventions for command line
invocations, and the new launcher can follow on as a nice addition.

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


The distutils scripts are a good point.  To be honest, apart from the 
"file association" issue, I can't see much advantage in doing both - if 
all Python directories end up on your path such that "python3 foo.py" 
magically works, then the launcher script is adding complexity without 
bringing much to the table.  Further, I'm somewhat skeptical that the 
file associations are used by that many people in the real world - 
currently when you double-click on a script you get a temp console 
created, and should a traceback be raised, you get to see it for about 
2ms before the console is destroyed.  Some people may be .pyw to avoid 
that, but then their script has to go to extraordinary lengths to 
display such errors in a UI of some kind.  I suspect most people just 
find it more convenient to launch such scripts from a console.  Maybe a 
quick poll on python-list would be reasonable...


Cheers,

Mark
___
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] [PEPs] Support the /usr/bin/python2 symlink upstream


On 07/03/2011 22:48, Mark Hammond wrote:

On 8/03/2011 7:33 AM, Michael Foord wrote:

A python launcher as you describe is a *great* idea.

A few concerns:

* we're missing an opportunity to do something easy (Martin is happy to
modify the installer and says it is easy) for something that may or may
not happen


Don't let my -0 stop anyone :)


Will you be at PyCon this year?




* will you call it python.exe? will it be installed by the python
installer?

- I doubt calling it python.exe will fly, but I'm not sure. If so what
will you call what is currently 'python.exe'? - if not then "python
foo.py" on the command line will *still* not work...


Calling it python.exe would make the most sense for people who don't 
look behind the curtain, but I agree it could potentially be confusing 
for people.  Further, we would need to ensure we didn't create an 
infinite loop where the launcher python.exe found a python.exe it 
thought was an appropriate sub-process, but where it turns out it is 
actually another launcher.




Sounds like fun. :-)

Having it installed by the Python installer also makes sense to me but 
I'd be very interested in Martin's take on this (and also on 
everything else we are discussing here).



Ditto.


* we're (yet again) making instructions for running stuff on Windows
*different* to other platforms (and making tutorials written for other
pythons "not work" in certain ways)


Actually, I'd argue we are making them more similar as we would be 
honoring a shebang line and allowing the exact same mechanism be used 
to denote the major version of Python needed.


Well, except (as pointed out a few minutes ago) that *isn't* what unix 
does ("python foo.py" does not honour the shebang). It gets us to 
something that works reliably though so I still like the idea.



* as I work with multiple platforms it would be really nice if the same
invocations worked across all of them - whilst I say again that I really
like the idea of the launcher it doesn't conflict with the other
suggestions (creating multiple binaries) and as you (Mark) say it
wouldn't hurt...

So why not do both? We could create the extra binaries to bring Python
on Windows inline with the unix conventions for command line
invocations, and the new launcher can follow on as a nice addition.

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


The distutils scripts are a good point.  To be honest, apart from the 
"file association" issue, I can't see much advantage in doing both - 
if all Python directories end up on your path such that "python3 
foo.py" magically works, then the launcher script is adding complexity 
without bringing much to the table.  Further, I'm somewhat skeptical 
that the file associations are used by that many people in the real 
world - currently when you double-click on a script you get a temp 
console created, and should a traceback be raised, you get to see it 
for about 2ms before the console is destroyed.  Some people may be 
.pyw to avoid that, but then their script has to go to extraordinary 
lengths to display such errors in a UI of some kind.  I suspect most 
people just find it more convenient to launch such scripts from a 
console.  Maybe a quick poll on python-list would be reasonable...


The launcher program could thrive without *having* to be part of a 
standard Python install. Offering it separately makes sense even if it 
*is* included. If we do both then users can vote with their feet.


Personally I suspect that many people, particularly new programmers, 
will appreciate the launcher but more advanced developers will want more 
precise control (and similarity to unix for command line invocations).


I agree with you about file associations. They are useful for .pyw 
programs (like IDLE), but not for scripts.


All the best,

Michael



Cheers,

Mark



--
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] PyCObject_AsVoidPtr removed from python 3.2 - is this documented?

2011-03-07 Thread Greg Ewing


I'm wondering whether one major release is enough of a
deprecation period in the current situation. Many people
haven't started using 3.x in earnest yet, and by the
time they do, several major releases will have already
gone by.

--
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] [PEPs] Support the /usr/bin/python2 symlink upstream

2011-03-07 Thread Greg Ewing


Mark Hammond wrote:


Yup - although I think a pythonw.exe launcher would be needed too


Couldn't the launcher look at the extension of the file being
launched to decide about this?

--
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] PyCObject_AsVoidPtr removed from python 3.2 - is this documented?

2011-03-07 Thread Joao S. O. Bueno

On Mon, Mar 7, 2011 at 8:05 PM, Greg Ewing  wrote:
> I'm wondering whether one major release is enough of a
> deprecation period in the current situation. Many people
> haven't started using 3.x in earnest yet, and by the
> time they do, several major releases will have already
> gone by.

That, IMHO, makes it less severe to drop things being marked as
deprecated after just one
major release . This way, most changes can take place before people
migrate to 3.x, and
get all the news at once when they do.

  js
 -><-

>
> --
> 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/jsbueno%40python.org.br
>
___
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] combined hg incoming patch

2011-03-07 Thread Brendan Cully

On 2011-03-07, at 2:30 PM, Brendan Cully wrote:

> On 2011-03-07, at 2:18 PM, Martin v. Löwis wrote:
> 
>> Am 07.03.2011 23:09, schrieb Brendan Cully:
>>> On 2011-03-07, at 1:03 PM, Martin v. Löwis wrote:
>>> 
 I'd like to experiment with adding Rietveld support for reviewing
 remote repositories. For that, I'd need to create a single patch
 (programmatically) that covers all incoming changes. 'hg incoming -p'
 mostly works, but it may provide multiple patches for a single file,
 which I think would harm the review (since some changes may be superseded 
 in a separate patch).
 
 So I would need to compute the most recent revision in both repositories, 
 and then create a diff between the default head
 of the remote repository and that base revision.
>>> 
>>> You might like the rdiff extension, which does essentially this.
>>> 
>>> http://mercurial.selenic.com/wiki/RdiffExtension
>> 
>> I've looked at it, and it does something different. It computes the diff 
>> between the local tip and the remote tip. What I want is a diff between the 
>> common ancestor between the two, and the remote tip.
> 
> Ah right. Well, I think this shell should work (with hg new enough to have 
> revsets):
> 
> hg in --bundle tmp.bundle
> hg diff -r 'outgoing(.)' -R tmp.bundle

Sorry, I didn't think that through. Revsets still have the power though:

hg -R tmp.bundle diff -r'ancestor(.,default)' -r default

(assuming your local repo is at the tip of default)

___
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] PyCObject_AsVoidPtr removed from python 3.2 - is this documented?

2011-03-07 Thread Brian Curtin

On Mon, Mar 7, 2011 at 17:05, Greg Ewing wrote:

> Many people haven't started using 3.x in earnest yet, and by the
> time they do, several major releases will have already gone by.


Sounds like motivation to me :)
___
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] [PEPs] Support the /usr/bin/python2 symlink upstream

2011-03-07 Thread Greg Ewing


Michael Foord wrote:

- I doubt calling it python.exe will fly, but I'm not sure. If so 
what will you call what is currently 'python.exe'? - if not then "python 
foo.py" on the command line will *still* not work...


However, if it's installed as the exe associated with the .py
and .pyw extensions, then simply 'foo.py' on the command line
*will* work, and will work better than it does now.

--
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] [PEPs] Support the /usr/bin/python2 symlink upstream