date:20110308


With a branch you can easily view the full patch, making a branch
strictly more general.


I just asked this before: how *exactly* do you do that?

Regards,
Martin
___
Python-Dev mailing list
[email protected]
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


However, as Michael points out, you can have your tools generate the
patch.  For example, it shouldn't be too hard to add a dynamic patch
generator to Roundup (although I haven't thought about the UI or the
CPU burden).


For Mercurial, that's more difficult than you might expect. There is "hg 
incoming -p", but it has the nasty problem that it may produce

multiple patches for a single file.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
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


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)


I can't make this work. I'm using hg 1.6.4, which does have revsets and
(including ancestor). Still, with this command, I get

martin@mira:~/work/3k$ LANG=C hg -R tmp.bundle diff 
-r'ancestor(.,default)' -r default

abort: unknown revision 'ancestor(.,default)'!

Regards,
Martin
___
Python-Dev mailing list
[email protected]
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


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


I think I would be opposed to adding a launcher to 2.7. It also
wouldn't be necessary - if it was released with 3.3, then it could
still do version switching for 2.7.

If it's called "python.exe", I wonder what it should do when given a
file that doesn't carry version information.


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


I certainly have script files that I double-click. However, those happen
to be batch files, not Python. If I would do scripting in Python (which
I don't do much these days), I would like to be able to double-click
them. I always write my scripts so that they don't give exceptions :-)

Actually, the one Python script I run regularly is msi.py, and I
currently launch it in a terminal window, because I need to run it with
c:\python25\python.exe, which double-clicking won't do for me. If I
could double-click it, I would like that more (there is also the issue
that the script needs the VS envvars set, so I'd need to find a solution
to that, also).

Regards,
Martin
___
Python-Dev mailing list
[email protected]
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


Am 08.03.2011 01:00, schrieb Michael Foord:

On 07/03/2011 23:52, Greg Ewing wrote:

Michael Foord wrote:


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


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


So long as '.py' and '.pyw' are set in the PATHEXT environment variable.
(Which again the Python installer doesn't do by default.)


Running foo.py works fine with the current installers (just try to see
for yourself). You don't need PATHEXT for that.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
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-08 Thread Gertjan Klein

Michael Foord wrote:

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

A launcher might be difficult to integrate into the Python installer, as
there can, by definition, only be one. What if I install a new version
of Python and then uninstall it? Will the launcher be uninstalled as
well? Will it be reverted to a previous version, and if so, which?

I am actually working on such a launcher for myself right now. The main
problem I am trying to solve is doubleclicking a .py or .pyw file and
having it run in the Python version it is intended for. From the command
line, I want "something.py arg1 ... argn" to do the right thing as well.
I don't care much for fixing "python something.py arg1 ... argn", as I
personally rarely need to pass options to Python. I may look into that
later, though.

My launcher parses the first line of the script for something that
starts with "#!" and contains "python". It tries to match
that with a list of installed Python versions obtained from the
registry, falling back to a configurable default if no such line is
found.

As to performance of such a solution: I'm writing this in Python (2.5,
as its MSVCRT is easier to include in an exe) and converting it to an
executable with py2exe. The extra startup time is manageble on my
system. Using Python to write this in makes it much easier to experiment
with adding features. Once the dust has settled I may attempt to rewrite
it in C.

Anyway, I believe that such a launcher should not be part of Python
itself at first; an external program makes it easier to figure out what
works well.

As to adding Python to the Windows path: I'd be mildly annoyed if the
installer offered that option, and seriously annoyed if it defaulted
that option to "yes".

Gertjan.

___
Python-Dev mailing list
[email protected]
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

On 08.03.2011 10:03, "Martin v. Löwis" wrote:
>> 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)
> 
> I can't make this work. I'm using hg 1.6.4, which does have revsets and
> (including ancestor). Still, with this command, I get
> 
> martin@mira:~/work/3k$ LANG=C hg -R tmp.bundle diff 
> -r'ancestor(.,default)' -r default
> abort: unknown revision 'ancestor(.,default)'!

ISTM that "hg diff" doesn't accept revsets in 1.6.

Georg


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

[Python-Dev] v2.7 tag

2011-03-08 Thread Stefan Krah

Hi,

I can't update to v2.7 in the new cpython repository:

$ hg up v2.7
abort: unknown revision 'v2.7'!


Am I missing something here? My goal is to get the same directory state
as from this command:

svn co http://svn.python.org/projects/python/tags/r27


Stefan Krah


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

Re: [Python-Dev] v2.7 tag

2011-03-08 Thread Dirkjan Ochtman

On Tue, Mar 8, 2011 at 10:45, Stefan Krah  wrote:
> Hi,
>
> I can't update to v2.7 in the new cpython repository:
>
> $ hg up v2.7
> abort: unknown revision 'v2.7'!
>
> Am I missing something here? My goal is to get the same directory state
> as from this command:
>
> svn co http://svn.python.org/projects/python/tags/r27

Did you by any chance use hg clone -rv2.7? That's a common gotcha:
that will only clone the repository up to but not including the
tagging changeset (the tip in the clone will be the tagged changeset),
meaning a subsequent update to the tag will fail.

Cheers,

Dirkjan
___
Python-Dev mailing list
[email protected]
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-08 Thread Adrian Buehlmann

On 2011-03-08 09:38, "Martin v. Löwis" wrote:
>> However, as Michael points out, you can have your tools generate the
>> patch.  For example, it shouldn't be too hard to add a dynamic patch
>> generator to Roundup (although I haven't thought about the UI or the
>> CPU burden).
> 
> For Mercurial, that's more difficult than you might expect. There is "hg 
> incoming -p", but it has the nasty problem that it may produce
> multiple patches for a single file.

I didn't follow/understand closely/completely what your problems is, but
I wouldn't be surprised if mercurial's 'incoming' command has its
limitations (it's most likely intentional, since remote inspection is
limited on purpose and frowned upon by design).

In general, you have to have all the changesets in a local repo to enjoy
the full power of mercurial's history inspection tools.

Maybe the following trick could be interesting for you:

If you don't want to do an outright pull from a (possibly dubious)
remote repo into your precious local repo yet, you can instead
"superimpose" a separate overlay bundle file on your local repo.

Example (initial step):

  $ cd cpython
  $ hg -q incoming --bundle in.hg
  68322:8947c47a9fef
  68323:a7e0cff05597
  68324:88bbc574cfb0
  68325:c43d685e1533
  68326:a69ef22b60e3
  68327:770d45d22a40

Now, you have a mercurial bundle file named "in.hg" which contains all
these incoming changes, but -- of course -- the changes haven't yet been
added to the repo.

The interesting thing is, you can now superimpose this bundle on your
repo, which has the effect that the aggregate is treated as if the
changes had already been pulled.

Continuing my example, let's now specify the bundle "in.hg" as an
*overlay* by using the option -R/--repository [1]:

  $ hg -R in.hg log -r tip
  changeset:   68327:770d45d22a40
  branch:  2.7
  tag: tip
  parent:  68321:d9cc58f93d72
  user:Benjamin Peterson <...>
  date:Mon Mar 07 22:50:37 2011 -0600
  summary: transform izip_longest #11424

The fun thing with overlay bundles is: you have the full power of all
mercurial history inspection commands as if the changesets had already
been added to your repo.

As an added extra bonus, you can later unbundle the bundle into your
repo without another network round trip -- assuming you are pleased with
what you've seen coming in:

  $ hg unbundle in.hg
  adding changesets
  adding manifests
  adding file changes
  added 6 changesets with 6 changes to 3 files
  (run 'hg update' to get a working copy)

BTW, we regularly use overlay bundles under the hood of TortoiseHg.

[1]
'hg help -v' says:
global options:
 -R --repository REPOrepository root directory or name of overlay
 bundle file
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] v2.7 tag


Am 08.03.2011 10:49, schrieb Dirkjan Ochtman:

On Tue, Mar 8, 2011 at 10:45, Stefan Krah  wrote:

Hi,

I can't update to v2.7 in the new cpython repository:

$ hg up v2.7
abort: unknown revision 'v2.7'!

Am I missing something here? My goal is to get the same directory state
as from this command:

svn co http://svn.python.org/projects/python/tags/r27


Did you by any chance use hg clone -rv2.7?


No: the cpython repository simply does not contain a tag called 'v2.7'. 
Not sure why not; v2.7rc1 and v2.7.1 are present.


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

[Python-Dev] git mirror [Re: CPython hg transition complete]

2011-03-08 Thread Ralf Schmitt

Georg Brandl  writes:

> I'm very happy to announce that the core Python repository switch
> to Mercurial is complete and the new repository at
> http://hg.python.org/cpython/ is now officially open for cloning,
> and for commits by those who had commit access to SVN.

I've setup a git mirror of that repository on github:
https://github.com/schmir/python

Cheers,
- Ralf
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] v2.7 tag

On 08.03.2011 10:57, "Martin v. Löwis" wrote:
> Am 08.03.2011 10:49, schrieb Dirkjan Ochtman:
>> On Tue, Mar 8, 2011 at 10:45, Stefan Krah  wrote:
>>> Hi,
>>>
>>> I can't update to v2.7 in the new cpython repository:
>>>
>>> $ hg up v2.7
>>> abort: unknown revision 'v2.7'!
>>>
>>> Am I missing something here? My goal is to get the same directory state
>>> as from this command:
>>>
>>> svn co http://svn.python.org/projects/python/tags/r27
>>
>> Did you by any chance use hg clone -rv2.7?
> 
> No: the cpython repository simply does not contain a tag called 'v2.7'. 
> Not sure why not; v2.7rc1 and v2.7.1 are present.

I just fixed this.  The revision that added the "v2.7" tag was the last
commit on legacy-trunk, and as such an extra head that didn't get pulled
into the "working" repo when we pruned the full-history repo.

The 2.7.1rc1 tag was also wrongly called "2.7rc1"; that was a copy-paste
error in the tagmap used while converting.

Georg

___
Python-Dev mailing list
[email protected]
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-08 Thread Adrian Buehlmann

On 2011-03-08 10:53, Adrian Buehlmann wrote:
> On 2011-03-08 09:38, "Martin v. Löwis" wrote:
>>> However, as Michael points out, you can have your tools generate the
>>> patch.  For example, it shouldn't be too hard to add a dynamic patch
>>> generator to Roundup (although I haven't thought about the UI or the
>>> CPU burden).
>>
>> For Mercurial, that's more difficult than you might expect. There is "hg 
>> incoming -p", but it has the nasty problem that it may produce
>> multiple patches for a single file.
> 
> I didn't follow/understand closely/completely what your problems is, but
> I wouldn't be surprised if mercurial's 'incoming' command has its
> limitations (it's most likely intentional, since remote inspection is
> limited on purpose and frowned upon by design).
> 
> In general, you have to have all the changesets in a local repo to enjoy
> the full power of mercurial's history inspection tools.
> 
> Maybe the following trick could be interesting for you:
> 
> If you don't want to do an outright pull from a (possibly dubious)
> remote repo into your precious local repo yet, you can instead
> "superimpose" a separate overlay bundle file on your local repo.

OOPS. I failed to notice that this has already been proposed in the
thread "combined hg incoming patch".

Sorry for the noise.
___
Python-Dev mailing list
[email protected]
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 Tue, 08 Mar 2011 09:38:27 +0100
"Martin v. Löwis"  wrote:
> > However, as Michael points out, you can have your tools generate the
> > patch.  For example, it shouldn't be too hard to add a dynamic patch
> > generator to Roundup (although I haven't thought about the UI or the
> > CPU burden).
> 
> For Mercurial, that's more difficult than you might expect. There is "hg 
> incoming -p", but it has the nasty problem that it may produce
> multiple patches for a single file.

If you use named branches it's trivial, and it's suggested in the
devguide in
http://docs.python.org/devguide/committing.html#long-term-development-of-features

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
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-08 Thread Stephen J. Turnbull

"Martin v. Löwis" writes:

 > > However, as Michael points out, you can have your tools generate the
 > > patch.  For example, it shouldn't be too hard to add a dynamic patch
 > > generator to Roundup (although I haven't thought about the UI or the
 > > CPU burden).

 > For Mercurial, that's more difficult than you might expect. There is "hg 
 > incoming -p", but it has the nasty problem that it may produce
 > multiple patches for a single file.

Doesn't "hg diff -r 'ancestor(branch,default)::branch'", where "branch"
is the unmerged branch you would like to inspect, do the right thing?

The revision function ancestor() gives the most recent common ancestor
of two revisions.

hg --version 
Mercurial Distributed SCM (version 1.8)
___
Python-Dev mailing list
[email protected]
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-08 Thread Ned Deily

After a little investigation, I think what is currently proposed in the 
PEP is fine for OS X and other systems which use the Unix makefile 
altinstall and install targets, as far as it goes.  However, for 
completeness, I think the PEP should also cover (most of) the other 
files that are installed in the "bin" directory besides python; those 
are idle, pydoc, and python-config, and 2to3.  To allow a clean eventual 
transition to Python 3 as the default, 2.7.2 should be changed to 
install the new hard links: python2, idle2, pydoc2, and python2-config.  

Currently, there are no overlapping filenames in the bin directory 
between Py2 and Py3 installs except for 2to3.  2to3 is a bit of a 
special case since it is common between Py2 and Py3; however the version 
of 2to3 itself differs between releases.  As of now, if the standard 
Makefiles are used, the user will get 2to3 from the Python release for 
which a "make install" (or for Python 2.x, a "make altinstall" as well) 
has most recently been executed.  That might not be the most recent 
version of 2to3, say, if an older Py2 release is installed after a newer 
Py3 one.  That's not good practice.  But that is also outside the scope 
of the PEP.

What is currently added to the installation bin directory for 2.7 and 
3.2 is summarized in the table below followed by the proposed changes.  
Note, the bin directory is typically /usr/bin on Unix-y systems; for Mac 
OS X framework builds, each Python minor version has its own bin 
directory within the same base Python framework.

  2.73.2
--- ------ ---
alt insalt ins
--- ------ ---
 Y   Y  Y   2to3
Y   Y   2to3-3.2
Y   2to3 (symlink to 2to3-3.2)
 Y   Y  idle
Y   Y   idle3.2
Y   idle3 (symlink to idle3.2)
 Y   Y  pydoc
Y   Y   pydoc3.2
Y   pydoc3 (symlink to pydoc3.2)
 Y  python (hardlink to python2.7)
 Y  python-config (symlink to python2.7-config)
 Y   Y  python2.7
 Y   Y  python2.7-config
Y   python3 (hardlink to python3.2m)
Y   python3-config (symlink to python3.2-config)
Y   Y   python3.2 (hardlink to python3.2m)
Y   python3.2-config (symlink to python3.2m-config)
Y   Y   python3.2m
Y   Y   python3.2m-config
 Y   Y  smtpd.py

 +  python2 (hardlink to python2.7)
 ?  idle2 (hardlink to idle)
 ?  pydoc2 (hardlink to pydoc)
 ?  python2-config (hardlink to python-config)
 X  2to3-2 (no need for 2 versions)


alt =  installed by "make altinstall"
ins =  installed by "make install"
Y = installed
m = optional combination of "d", "m", "u"
+ = currently in PEP 394
? = should be added to PEP 394
X = should not be added

-- 
 Ned Deily,
 [email protected]

___
Python-Dev mailing list
[email protected]
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.

On Tue, 08 Mar 2011 12:23:54 +0100
local  wrote:
> +
> +VERBS = r'(?:\b(?Pclose[sd]?|closing|fixe[sd]|fixing|fix)\s+)?'
> +ISSUE_PATTERN = re.compile(r'%s(?:#|\bissue|\bbug)\s*(?P[0-9]+)'
> +   % VERBS, re.I)

This should only match numbers with 4 and 5 figures IMO.
Otherwise things like "this is priority #1" in commit messages will
spam issue number 1 (assuming it exists).

Also, I'm not sure trying to match too many verbs is useful. Things are
clearer and more predictible if we mandate a single form, perhaps only
at the last line of the commit message. We don't want false positives
(such as messages about closed files, etc.).

Regards

Antoine.

___
Python-Dev mailing list
[email protected]
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-08 Thread Michael Urman

On Tue, Mar 8, 2011 at 03:33, "Martin v. Löwis"  wrote:
> If it's called "python.exe", I wonder what it should do when given a
> file that doesn't carry version information.

I would expect it to follow the guidance of the Unix PEP as much as
possible. IIRC this means it would launch the highest 2.x version of
Python on the system. If there is no 2.x version, it would launch the
highest known version (presumably 3.x) for now. I would expect this
behavior for any unversioned name of the launcher (e.g. python.exe or
pystart.exe).

> Actually, the one Python script I run regularly is msi.py, and I
> currently launch it in a terminal window, because I need to run it with
> c:\python25\python.exe, which double-clicking won't do for me. If I
> could double-click it, I would like that more (there is also the issue
> that the script needs the VS envvars set, so I'd need to find a solution
> to that, also).

It's implicit scope creep, but perhaps the launcher could be
configured to provide certain environment tweaks, either for all
versions of Python, or specific for each version. A more extreme scope
creep could allow this information to be stored in the .py file, but
that seems backwards to me.

To think a bit further on how the launcher should resolve the version,
We should probably first see if the #! line works as an executable
with optional single argument. This would allow someone to specify
overrides like:

   #! D:\Checkout\...\python

If the file doesn't exist, fall back to scanning for python[.exe] with
or without a version (in order to support scripts with
/usr/bin/python* or /usr/bin/env python*). If it has a version follow
the version as closely as possible (map 2 to latest 2.x, 3 to latest
3.x, etc.). If it doesn't have a version, find the latest 2.x or
latest any version as above, per the most recent relevant PEP. Open
question is what to do if the script clearly requests version 2.6 but
only 2.5, 2.7 and 3.2 are installed, or requests 2.x but only 3.x is
installed; I could see erroring out as "refus[ing] the temptation to
guess".

-- 
Michael Urman
___
Python-Dev mailing list
[email protected]
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-08 Thread Michael Urman

On Tue, Mar 8, 2011 at 03:40, Gertjan Klein  wrote:
> A launcher might be difficult to integrate into the Python installer, as
> there can, by definition, only be one. What if I install a new version
> of Python and then uninstall it? Will the launcher be uninstalled as
> well? Will it be reverted to a previous version, and if so, which?

As long as component rules are maintained (the same components with
same GUIDs install the same files in the same locations) and they are
marked shared, Windows Installer will handle everything for us. If the
files have versions the way Windows Installer can process them, it
will even keep the highest version of the file in place.

-- 
Michael Urman
___
Python-Dev mailing list
[email protected]
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.

On 08.03.2011 14:19, Antoine Pitrou wrote:
> On Tue, 08 Mar 2011 12:23:54 +0100
> local  wrote:
>> +
>> +VERBS = r'(?:\b(?Pclose[sd]?|closing|fixe[sd]|fixing|fix)\s+)?'
>> +ISSUE_PATTERN = re.compile(r'%s(?:#|\bissue|\bbug)\s*(?P[0-9]+)'
>> +   % VERBS, re.I)
> 
> This should only match numbers with 4 and 5 figures IMO.
> Otherwise things like "this is priority #1" in commit messages will
> spam issue number 1 (assuming it exists).
> 
> Also, I'm not sure trying to match too many verbs is useful. Things are
> clearer and more predictible if we mandate a single form, perhaps only
> at the last line of the commit message. We don't want false positives
> (such as messages about closed files, etc.).

Please go ahead: I'm not attached to any of the details.

Georg

___
Python-Dev mailing list
[email protected]
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-08 Thread Barry Warsaw

On Mar 08, 2011, at 12:01 PM, Stephen J. Turnbull wrote:

>Barry Warsaw writes:
>
> > I hear this complaint [about branches being no help in reviewing] 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.

Actually, the complaint I've commonly heard from hg and git users is that they
want local, intermediate history to be collapsed into one revision/changeset
when merging into the target branch.

Daniel's example shows that the benefits of branches for review is not limited
to Bazaar+Launchpad users .  I do agree that it's a new workflow for
Python.

>I think it's up to the advocates of branch-based review to improve the
>tools, and I think it's worth it.  Now, if only I can find some
>time...

Continuing to use patch-based reviews for Python is fine, and I think as we
all adjust to the Mercurial conversion, new and more efficient ways of working
will evolve over time.

-Barry

signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
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-08 Thread Daniel Stutzbach

On Tue, Mar 8, 2011 at 12:34 AM, "Martin v. Löwis" wrote:

> With a branch you can easily view the full patch, making a branch
>> strictly more general.
>>
>
> I just asked this before: how *exactly* do you do that?
>

I confess: I'm not sure exactly how to do it in hg.  I know it's easy in
git; I assume it's easy in hg.  I did some searching but was unable to come
up with the right incantation.

-- 
Daniel Stutzbach
___
Python-Dev mailing list
[email protected]
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-08 Thread Brendan Cully

On 2011-03-08, at 1:03 AM, Martin v. Löwis wrote:

>> 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)
> 
> I can't make this work. I'm using hg 1.6.4, which does have revsets and
> (including ancestor). Still, with this command, I get
> 
> martin@mira:~/work/3k$ LANG=C hg -R tmp.bundle diff -r'ancestor(.,default)' 
> -r default
> abort: unknown revision 'ancestor(.,default)'!

It looks like that was fixed a week after 1.6.4 was released, here:

http://hg.intevation.org/mercurial/crew/rev/2063d36b406e

It should work in 1.7.
___
Python-Dev mailing list
[email protected]
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-08 Thread Reliable Domains

On 3/7/2011 2:18 PM, 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.

The launcher need not be called "python.exe", and maybe it would be
better called #@launcher.exe (or similar, depending on its exact
function details).

For launching from the command line, if various versions python binaries
or batch files are on the PATH, then appropriate explicit python invocation

python foo.py # Just like Unix
python2 foo.py
python3 foo.py

should launch the specified version (where python may be somewhat
ambiguous) but

foo.py # with the help of a launcher this could be just like Unix too

would implicitly use the launcher, as would launching it from the GUI.

There are two problems here, explicit command-line invocation, and
GUI/assoc invocation. A launcher need not, and probably should not, do
anything for explicit python invocation, but would only solve the
implicit and GUI type of invocations.

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

[Python-Dev] Failed issue tracker submission

2011-03-08 Thread Python tracker



You are not a registered user.

Unknown address: [email protected]
Return-Path: 
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: from mail.python.org (mail.python.org [82.94.164.166])
by psf.upfronthosting.co.za (Postfix) with ESMTPS id 3751A1C882
for ; Tue,  8 Mar 2011 20:32:20 +0100 (CET)
Received: from albatross.python.org (localhost [127.0.0.1])
by mail.python.org (Postfix) with ESMTP id E997CEE982
for ; Tue,  8 Mar 2011 20:32:19 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901;
t=1299612739; bh=Bm/2p8PHDn+4WE7m0+s+IN5vXbdlXyuJIaBOBx3pZx0=;
h=Date:Message-Id:Content-Type:MIME-Version:
 Content-Transfer-Encoding:From:To:Subject;
b=LoV7iLjY9Iw+vYf3SFnuqChBT6nSZ671M1ZJEJunosSATE+6JlkWjt/GZh7qXXRnO
 58wWGG6wv/ydMfpGFKuFgW8fjq4jrLZp76xB59v6jRh4qwWs3ejJLZvkg3r8PAkbJy
 OuwQoxgPaDqUpO+U1jEsdDH49hutOtfMTEyUX2aw=
Received: from localhost (HELO mail.python.org) (127.0.0.1)
  by albatross.python.org with SMTP; 08 Mar 2011 20:32:19 +0100
Received: from dinsdale.python.org (svn.python.org [IPv6:2001:888:2000:d::a4])
(using TLSv1 with cipher AES256-SHA (256/256 bits))
(No client certificate requested)
by mail.python.org (Postfix) with ESMTPS
for ; Tue,  8 Mar 2011 20:32:19 +0100 (CET)
Received: from localhost
([127.0.0.1] helo=dinsdale.python.org ident=hg)
by dinsdale.python.org with esmtp (Exim 4.72)
(envelope-from )
id 1Px2dn-0002Pv-SP
for [email protected]; Tue, 08 Mar 2011 20:32:19 +0100
Date: Tue, 08 Mar 2011 20:32:19 +0100
Message-Id: 
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Mercurial robot 
To: [email protected]
Subject: [issue2771]

Changeset b92334d06445 by Antoine Pitrou :
Issue #2771: fixing frobnicator\nI hope this works
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Failed issue tracker submission

2011-03-08 Thread Python tracker


An unexpected error occurred during the processing
of your message. The tracker administrator is being
notified.
Return-Path: 
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: from mail.python.org (mail.python.org [82.94.164.166])
by psf.upfronthosting.co.za (Postfix) with ESMTPS id 401941CCBB
for ; Tue,  8 Mar 2011 20:37:51 +0100 (CET)
Received: from albatross.python.org (localhost [127.0.0.1])
by mail.python.org (Postfix) with ESMTP id 07431F50E
for ; Tue,  8 Mar 2011 20:37:51 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901;
t=1299613071; bh=Bm/2p8PHDn+4WE7m0+s+IN5vXbdlXyuJIaBOBx3pZx0=;
h=Date:Message-Id:Content-Type:MIME-Version:
 Content-Transfer-Encoding:From:To:Subject;
b=c2EwRcbLb6xyNVyGuEYgXsFXucMs8eDjr+gNZxI8n4qptSKtw1oDYcSQ/crFbP/3/
 rXpiXCZpBqzTqCpSm3OCFU1LMOKMp2NSb1TGVHPtnPNba6DsIljrSB0ChpQjNFzmDi
 hrahhvjF+xdlyFaRi9zH8hUtbgqUSJ5JFtrZ5PtU=
Received: from localhost (HELO mail.python.org) (127.0.0.1)
  by albatross.python.org with SMTP; 08 Mar 2011 20:37:51 +0100
Received: from dinsdale.python.org (svn.python.org [IPv6:2001:888:2000:d::a4])
(using TLSv1 with cipher AES256-SHA (256/256 bits))
(No client certificate requested)
by mail.python.org (Postfix) with ESMTPS
for ; Tue,  8 Mar 2011 20:37:50 +0100 (CET)
Received: from localhost
([127.0.0.1] helo=dinsdale.python.org ident=hg)
by dinsdale.python.org with esmtp (Exim 4.72)
(envelope-from )
id 1Px2j8-0002xv-RP
for [email protected]; Tue, 08 Mar 2011 20:37:50 +0100
Date: Tue, 08 Mar 2011 20:37:50 +0100
Message-Id: 
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Mercurial robot 
To: [email protected]
Subject: [issue2771]

Changeset b92334d06445 by Antoine Pitrou :
Issue #2771: fixing frobnicator\nI hope this works
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Failed issue tracker submission

2011-03-08 Thread Python tracker


An unexpected error occurred during the processing
of your message. The tracker administrator is being
notified.
Return-Path: 
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: from mail.python.org (mail.python.org [82.94.164.166])
by psf.upfronthosting.co.za (Postfix) with ESMTPS id 2BCB01CF45
for ; Tue,  8 Mar 2011 20:38:20 +0100 (CET)
Received: from albatross.python.org (localhost [127.0.0.1])
by mail.python.org (Postfix) with ESMTP id E3164F50E
for ; Tue,  8 Mar 2011 20:38:19 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901;
t=1299613099; bh=Bm/2p8PHDn+4WE7m0+s+IN5vXbdlXyuJIaBOBx3pZx0=;
h=Date:Message-Id:Content-Type:MIME-Version:
 Content-Transfer-Encoding:From:To:Subject;
b=cZuu5TUJ+2EKtvuJRRg8z6d0Kg91LmwDAkiJDfLyZgnVmR9qIt6WH3yT51E9BVJYS
 iGsyAfzvyldNq4ckKUN/xZk4I1DpWiQIpWGEvKZ0EqXfuCSU/4jVbfQh6IfbMFj2Ll
 /CybOdJt6JqDvqDOH5bK+A37djNgw6uKFUvQ+yvg=
Received: from localhost (HELO mail.python.org) (127.0.0.1)
  by albatross.python.org with SMTP; 08 Mar 2011 20:38:19 +0100
Received: from dinsdale.python.org (svn.python.org [IPv6:2001:888:2000:d::a4])
(using TLSv1 with cipher AES256-SHA (256/256 bits))
(No client certificate requested)
by mail.python.org (Postfix) with ESMTPS
for ; Tue,  8 Mar 2011 20:38:19 +0100 (CET)
Received: from localhost
([127.0.0.1] helo=dinsdale.python.org ident=hg)
by dinsdale.python.org with esmtp (Exim 4.72)
(envelope-from )
id 1Px2jb-0002yL-Qw
for [email protected]; Tue, 08 Mar 2011 20:38:19 +0100
Date: Tue, 08 Mar 2011 20:38:19 +0100
Message-Id: 
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: [email protected]
To: [email protected]
Subject: [issue2771]

Changeset b92334d06445 by Antoine Pitrou :
Issue #2771: fixing frobnicator\nI hope this works
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Let's get PEP 380 into Python 3.3

2011-03-08 Thread rndblnch

Greg Ewing  canterbury.ac.nz> writes:

> 
> Guido van Rossum wrote:
> > Ok. Will you hvae time to port your patches to 3.3?
> 
> I'm not sure -- I'll see what I can do.
> 

If this can help, I've "ported" the patch YieldFrom-Python3.1.2-rev5.patch
against current cpython tip.
What I've done:
- cloned current http://hg.python.org/cpython/ tip
- replaced tabs by 4 spaces in YieldFrom-Python3.1.2-rev5.patch and applied
result to tip
- manually applied failed hunks
- built and tested resulting python (configure/make/make test smoothly pass)
- successfully ran "yield from" samples with resulting binary
Resulting patch obtained by running "hg diff" is available here:


This patch includes graminit.[ch] modification since those files are versioned,
but I guess they are not necessary since they seem to be generated.

Hope this helps.

renaud

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

Re: [Python-Dev] Failed issue tracker submission


Ouch. I fear this message may be repeated several times :/
Sorry for the spam, if that happens...

Regards

Antoine.


On Tue, 08 Mar 2011 19:32:20 +
Python tracker  wrote:
> 
> 
> You are not a registered user.
> 
> Unknown address: [email protected]
> 


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

Re: [Python-Dev] Failed issue tracker submission

2011-03-08 Thread skip


>> You are not a registered user.

>> Unknown address: [email protected]

I should point out that I approved this message, mostly so whoever has
thinks set up to send messages to the meta tracker as python-dev can fix the
problem.

Skip
___
Python-Dev mailing list
[email protected]
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-08 Thread Terry Reedy


On 3/7/2011 9:31 PM, Reliable Domains wrote:


The launcher need not be called "python.exe", and maybe it would be
better called #@launcher.exe (or similar, depending on its exact
function details).


I do not know that the '#@' part is about, but pygo would be short and 
expressive.


--
Terry Jan Reedy

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

Re: [Python-Dev] small commit emails nit


Well, after a couple of days with the "cpython" prefix stripped, I have
to say that I find it much less practical than it was before. Any other
opinions?

Regards

Antoine.



On Mon, 7 Mar 2011 01:11:24 +1000
Nick Coghlan  wrote:

> On Mon, Mar 7, 2011 at 12:56 AM, Antoine Pitrou  wrote:
> > On Mon, 7 Mar 2011 00:52:08 +1000
> > Nick Coghlan  wrote:
> >>
> >> I'm actually OK with the status quo, but if we were going to change
> >> it, I would continue to leave (default) out.
> >>
> >> Completely unqualified = cpython default
> >> Only branch name = cpython branch
> >> Only repository name = other repository default
> >> repository name and branch name = other repository branch
> >
> > Well, I'm not sure, but the regularity of the "cpython" prefixes makes
> > it easier to distinguish cpython commits from non-cpython ones IMO.
> 
> It's a mental pattern matching thing - word layout is noticed before
> word content.
> 
> So the suggested scheme:
> 
> [python-checkins] Lorem ipsum dolor sit amet
> [python-checkins] (3.1): Lorem ipsum dolor sit amet
> [python-checkins] devguide: Lorem ipsum dolor sit amet
> [python-checkins] devguide (hg_migration): Lorem ipsum dolor sit amet
> 
> provides more distinctive subject lines than the current:
> 
> [python-checkins] cpython: Lorem ipsum dolor sit amet
> [python-checkins] cpython (3.1): Lorem ipsum dolor sit amet
> [python-checkins] devguide: Lorem ipsum dolor sit amet
> [python-checkins] devguide (hg_migration): Lorem ipsum dolor sit amet
> 
> What we have isn't bad, but I agree with Benjamin that it could be better.
> 
> Cheers,
> Nick
> 
> -- 
> Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Failed issue tracker submission

2011-03-08 Thread skip


Antoine> Ouch. I fear this message may be repeated several times :/
Antoine> Sorry for the spam, if that happens...

Do you want me to reject or discard future messages to python-dev from
roundup-admin?

Skip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Failed issue tracker submission

Le mardi 08 mars 2011 à 14:51 -0600, [email protected] a écrit :
> Antoine> Ouch. I fear this message may be repeated several times :/
> Antoine> Sorry for the spam, if that happens...
> 
> Do you want me to reject or discard future messages to python-dev from
> roundup-admin?

Hopefully there won't be any more (I've fixed the issue by creating an
appropriate Roundup user).

I think it's better not to discard them, in case it starts failing
again.

Regards

Antoine.


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

Re: [Python-Dev] small commit emails nit

2011-03-08 Thread Ethan Furman


Antoine Pitrou wrote:

Well, after a couple of days with the "cpython" prefix stripped, I have
to say that I find it much less practical than it was before. Any other
opinions?


I would rather have it back.

~Ethan~
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] small commit emails nit

On 08.03.2011 21:29, Antoine Pitrou wrote:
> 
> Well, after a couple of days with the "cpython" prefix stripped, I have
> to say that I find it much less practical than it was before. Any other
> opinions?

>From me, only the same opinion :)

Georg


___
Python-Dev mailing list
[email protected]
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.

On Tue, 08 Mar 2011 15:07:29 -0500
Terry Reedy  wrote:
> 
> > +If "closes" or "fixes" (with alternative verb forms like "fixing"
> > +allowed too) is prepended, the issue is automatically closed as
> > +"fixed".
> 
> Fix may be too broad. "This patch fixes the first part of the issue."

Ok, it has been removed. Only "closes" and derivatives trigger closing
now.

Regards

Antoine.




___
Python-Dev mailing list
[email protected]
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.

On 08.03.2011 21:07, Terry Reedy wrote:
> 
>> +If "closes" or "fixes" (with alternative verb forms like "fixing"
>> +allowed too) is prepended, the issue is automatically closed as
>> +"fixed".
> 
> Fix may be too broad. "This patch fixes the first part of the issue."

Well, you'd have to write "This patch fixes #12345 (the first part)".

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

Georg

___
Python-Dev mailing list
[email protected]
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


Am 08.03.2011 11:30, schrieb Stephen J. Turnbull:

"Martin v. Löwis" writes:

  >  >  However, as Michael points out, you can have your tools generate the
  >  >  patch.  For example, it shouldn't be too hard to add a dynamic patch
  >  >  generator to Roundup (although I haven't thought about the UI or the
  >  >  CPU burden).

  >  For Mercurial, that's more difficult than you might expect. There is "hg
  >  incoming -p", but it has the nasty problem that it may produce
  >  multiple patches for a single file.

Doesn't "hg diff -r 'ancestor(branch,default)::branch'", where "branch"
is the unmerged branch you would like to inspect, do the right thing?


What would I specify as "branch" if all I have is 
"http://bitbucket.com/turnbull/foo";, and know that it must be the 
default branch?


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

Re: [Python-Dev] small commit emails nit

2011-03-08 Thread Benjamin Peterson

2011/3/8 Antoine Pitrou :
>
> Well, after a couple of days with the "cpython" prefix stripped, I have
> to say that I find it much less practical than it was before. Any other
> opinions?

"cpy" maybe?



-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
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


Am 08.03.2011 11:19, schrieb Antoine Pitrou:

On Tue, 08 Mar 2011 09:38:27 +0100
"Martin v. Löwis"  wrote:

However, as Michael points out, you can have your tools generate the
patch.  For example, it shouldn't be too hard to add a dynamic patch
generator to Roundup (although I haven't thought about the UI or the
CPU burden).


For Mercurial, that's more difficult than you might expect. There is "hg
incoming -p", but it has the nasty problem that it may produce
multiple patches for a single file.


If you use named branches it's trivial, and it's suggested in the
devguide in
http://docs.python.org/devguide/committing.html#long-term-development-of-features


That requires a local repository, right? Plus it requires knowing the 
branch name, which makes it difficult for automated patch generation.


Regards,
Martin
___
Python-Dev mailing list
[email protected]
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?


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.


I was not aware I could turn on deprecation warning for use of the C API.
How can I do that?


Not sure that you can. When I said "could have known", I meant "by 
reading the documentation".


Regards,
Martin
___
Python-Dev mailing list
[email protected]
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


martin@mira:~/work/3k$ LANG=C hg -R tmp.bundle diff -r'ancestor(.,default)' -r 
default
abort: unknown revision 'ancestor(.,default)'!


It looks like that was fixed a week after 1.6.4 was released, here:

http://hg.intevation.org/mercurial/crew/rev/2063d36b406e

It should work in 1.7.


Ah ok, it does indeed.

Thanks,
Martin
___
Python-Dev mailing list
[email protected]
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-08 Thread Barry Scott


On 7 Mar 2011, at 09:33, Martin v. Löwis wrote:

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

I was not aware I could turn on deprecation warning for use of the C API.
How can I do that?

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

O.k. I see that now. I searched for the API call that vanished and came up
empty. I did not think to search for cobject or read the porting section.

BTW the link on http://www.python.org/download/releases/3.2/
to what's new points to the 3.3a0 whats new page.

Barry

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

[Python-Dev] GSoC mentors: projects list is up


If you want to see a project done in this year's GSoC,
please add it to

http://wiki.python.org/moin/SummerOfCode/2011

Python 3 related projects are preferred.

Students will look at this page for ideas what kinds of projects to 
propose; the earlier you add an idea, the more likely is it that you

get good proposals from good students.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
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-08 Thread Éric Araujo

Hi,

Le 08/03/2011 19:04, Daniel Stutzbach a écrit :
>>> With a branch you can easily view the full patch, making a branch
>>> strictly more general.
>> I just asked this before: how *exactly* do you do that?
> I confess: I'm not sure exactly how to do it in hg.  I know it's easy in
> git; I assume it's easy in hg.
The tools do not share the same design choices, so assuming there’s a
Merrcurial equivalent to something that’s possibly advanced git usage is
risked.

> I did some searching but was unable to come up with the right incantation.
What’s the command you use with git?  Maybe someone will find the
Mercurial one.

Regards
___
Python-Dev mailing list
[email protected]
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-08 Thread Éric Araujo

Hi,

First, thank you for stepping up again to work on the code review
integration.

> It seems that the dev guide recommends to use the --git option in hg
> diff.

From “hg help diffs”:

While this standard format [unified diff] is often enough, it does
not encode the following information:

- executable status and other permission bits
- copy or rename information
- changes in binary files
- creation or deletion of empty files

I’m of the opinion that hg diffs should always use the extended git
format, given their usefulness.  A tool working with hg diffs that does
not support this format is broken IMO.

Regards
___
Python-Dev mailing list
[email protected]
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-08 Thread Guido van Rossum

On Tue, Mar 8, 2011 at 9:32 PM, Éric Araujo  wrote:
> I’m of the opinion that hg diffs should always use the extended git
> format, given their usefulness.  A tool working with hg diffs that does
> not support this format is broken IMO.

Can you please contribute changes to Rietveld to support that format then?

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
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 3/8/2011 12:02 PM, Terry Reedy wrote:

On 3/7/2011 9:31 PM, Reliable Domains wrote:


The launcher need not be called "python.exe", and maybe it would be
better called #@launcher.exe (or similar, depending on its exact
function details).


I do not know that the '#@' part is about, but pygo would be short and 
expressive.




If my proposal to make a line starting with #@ to be used instead of the 
Unix #! (#@ could be on the first or second line, to allow 
cross-platform scripts to use both, and Windows only scripts to not have 
#!), then #@launcher.exe (and #@launcherw.exe I suppose) would reflect 
the functionality of the launcher, which need not be tightly tied to 
Python, if it uses a separate line.  But the launcher should probably 
not be the thing invoked from the command line, only implicitly when 
running scripts by naming them as the first thing on the command line.


I'm of the opinion that attempting to parse a Unix #! line, and intuit 
what would be the equivalent on Windows is unnecessarily complex and 
error prone, and assumes that the variant systems are configured using 
the same guidelines (which the Python community may espouse, but may not 
be followed by all distributions, sysadmins, or users).  That's why I 
propose a different line for Windows... it is as simple as the 
long-proven Unix #! line, but imposes no restrictions on or requirements 
that there be a #! line; it has more flexibility in that it could invoke 
different versions or provide different options on Unix and Windows if 
necessary for some environments.


#!/usr/bin/env python2.6 -B
#@c:\python26\python2.6.exe

or

#!/usr/bin/python2.5
#@"C:\Program Files (x86)\IronPython 2.6 for .NET 4.0\ipy.exe"

Now that I've had this idea, one might want to create other "2nd 
character" codes after the Unix #! line... one could have


#! Unix command processor
#@ Windows command processor
#$ OS/2 command processor
#% Alternate Windows command processor.

One could even port it to Unix:

#!/usr/bin/#@launcher
#@c:\python2.6\python.exe
#^/usr/bin/python2.5
#&/usr/bin/mono/IronPython2.6 for .NET 4.0/ipy.exe
#  I made up the line above, having no knowledge of Mono, but I think 
you get the idea


Choice of command line would be an environment variable, I suppose, that 
the launcher would look at, or if none, then a system-specific default.  
It would have to search forward in the file until it finds the 
appropriate prefix or a line not starting with #, or starting with "# " 
or "##", at which point it would give up.


___
Python-Dev mailing list
[email protected]
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-08 Thread Toshio Kuratomi

On Tue, Mar 08, 2011 at 06:43:19PM -0800, Glenn Linderman wrote:
> On 3/8/2011 12:02 PM, Terry Reedy wrote:
> 
> On 3/7/2011 9:31 PM, Reliable Domains wrote:
> 
> 
> The launcher need not be called "python.exe", and maybe it would be
> better called #@launcher.exe (or similar, depending on its exact
> function details).
> 
> 
> I do not know that the '#@' part is about, but pygo would be short and
> expressive.
> 
> 
> 
> If my proposal to make a line starting with #@ to be used instead of the Unix
> #! (#@ could be on the first or second line, to allow cross-platform scripts 
> to
> use both, and Windows only scripts to not have #!
>
You'd need to allow for it to be on the third line as well.  pep-0263
has already taken the second line if it's in a script that has a Unix
shebang.


> ), then #@launcher.exe (and #
> @launcherw.exe I suppose) would reflect the functionality of the launcher,
> which need not be tightly tied to Python, if it uses a separate line.  But the
> launcher should probably not be the thing invoked from the command line, only
> implicitly when running scripts by naming them as the first thing on the
> command line.
> 
> I'm of the opinion that attempting to parse a Unix #! line, and intuit what
> would be the equivalent on Windows is unnecessarily complex and error prone,
> and assumes that the variant systems are configured using the same guidelines
> (which the Python community may espouse, but may not be followed by all
> distributions, sysadmins, or users).
>
I do not have a Windows system so I don't have a horse in this race but if
the argument is to avoid complexity, be careful that your proposed solution
isn't more complex than what you're avoiding.  ie::

> Now that I've had this idea, one might want to create other "2nd character"
> codes after the Unix #! line... one could have
> 
> #! Unix command processor
> #@ Windows command processor
> #$ OS/2 command processor
> #% Alternate Windows command processor.
> 
> One could even port it to Unix:
> 
> #!/usr/bin/#@launcher
> #@c:\python2.6\python.exe
> #^/usr/bin/python2.5
> #&/usr/bin/mono/IronPython2.6 for .NET 4.0/ipy.exe
> #  I made up the line above, having no knowledge of Mono, but I think you get
> the idea
> 
> Choice of command line would be an environment variable, I suppose, that the
> launcher would look at, or if none, then a system-specific default.  It would
> have to search forward in the file until it finds the appropriate prefix or a
> line not starting with #, or starting with "# " or "##", at which point it
> would give up.
> 
-Toshio


pgpkYA49vPaay.pgp
Description: PGP signature
___
Python-Dev mailing list
[email protected]
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 3/8/2011 8:02 PM, Toshio Kuratomi wrote:

On Tue, Mar 08, 2011 at 06:43:19PM -0800, Glenn Linderman wrote:

On 3/8/2011 12:02 PM, Terry Reedy wrote:

 On 3/7/2011 9:31 PM, Reliable Domains wrote:


 The launcher need not be called "python.exe", and maybe it would be
 better called #@launcher.exe (or similar, depending on its exact
 function details).


 I do not know that the '#@' part is about, but pygo would be short and
 expressive.



If my proposal to make a line starting with #@ to be used instead of the Unix
#! (#@ could be on the first or second line, to allow cross-platform scripts to
use both, and Windows only scripts to not have #!


You'd need to allow for it to be on the third line as well.  pep-0263
has already taken the second line if it's in a script that has a Unix
shebang.


Thanks for your feedback Toshio...

Indeed!  I've been using Python 3 and UTF-8 encoding only long enough, I 
forgot about pep-0263, although I'd been aware of it before...  Now I 
only port back to Python 2 for stuff I have to run on my web host, which 
runs Python 2.6, and those are all ASCII files by design.




), then #@launcher.exe (and #
@launcherw.exe I suppose) would reflect the functionality of the launcher,
which need not be tightly tied to Python, if it uses a separate line.  But the
launcher should probably not be the thing invoked from the command line, only
implicitly when running scripts by naming them as the first thing on the
command line.

I'm of the opinion that attempting to parse a Unix #! line, and intuit what
would be the equivalent on Windows is unnecessarily complex and error prone,
and assumes that the variant systems are configured using the same guidelines
(which the Python community may espouse, but may not be followed by all
distributions, sysadmins, or users).


I do not have a Windows system so I don't have a horse in this race but if
the argument is to avoid complexity, be careful that your proposed solution
isn't more complex than what you're avoiding.  ie::


Yep, even after I wrote the below, I thought about not sending that 
part, for exactly that reason.


But after slightly investigating the other Python implementations, I 
realized even more strongly that interpreting the Unix #! line is very 
limiting:


1) it requires the same version to exist on both Unix and Windows, which 
may often, but not always, be true.


2) it either hard-codes an alternative path name in the launcher, or 
hard-codes an algorithm to do lookups in the registry to find the 
alternative path names.  Neither of these are very friendly to 
alternative Python implementations.


3) people concerned with keeping scripts and modules compatible with 
alternative implementations might have more than one implementation on 
their system.


So the complexity I'm avoiding is the "hard-coding" sort of complexity.  
The complexity I propose adds flexibility that the hard-coding would be 
hard-pressed to achieve.



Now that I've had this idea, one might want to create other "2nd character"
codes after the Unix #! line... one could have

#! Unix command processor
#@ Windows command processor
#$ OS/2 command processor
#% Alternate Windows command processor.

One could even port it to Unix:

#!/usr/bin/#@launcher
#@c:\python2.6\python.exe
#^/usr/bin/python2.5
#&/usr/bin/mono/IronPython2.6 for .NET 4.0/ipy.exe
#  I made up the line above, having no knowledge of Mono, but I think you get
the idea

Choice of command line would be an environment variable, I suppose, that the
launcher would look at, or if none, then a system-specific default.  It would
have to search forward in the file until it finds the appropriate prefix or a
line not starting with #, or starting with "# " or "##", at which point it
would give up.
For PEP-0263 compliance, modify the terminator to be a line not starting 
with #, or a line starting with "##".  This may cause reduced 
performance for scripts starting with large block comments without 
having the searched-for execution code... but only in the case where the 
searched-for execution code is not present.



___
Python-Dev mailing list
[email protected]
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-08 Thread Mark Hammond


On 9/03/2011 1:43 PM, Glenn Linderman wrote:

I'm of the opinion that attempting to parse a Unix #! line, and intuit
what would be the equivalent on Windows is unnecessarily complex and
error prone, and assumes that the variant systems are configured using
the same guidelines (which the Python community may espouse, but may not
be followed by all distributions, sysadmins, or users). That's why I
propose a different line for Windows... it is as simple as the
long-proven Unix #! line, but imposes no restrictions on or requirements
that there be a #! line; it has more flexibility in that it could invoke
different versions or provide different options on Unix and Windows if
necessary for some environments.

#!/usr/bin/env python2.6 -B
#@c:\python26\python2.6.exe

or

#!/usr/bin/python2.5
#@"C:\Program Files (x86)\IronPython 2.6 for .NET 4.0\ipy.exe"


I don't think that buys us much.  A script with "#!/usr/bin/env python" 
could be distributed with an expectation it will work across various 
different machines (and possibly even different operating systems).  A 
script with "c:\..." could not be distributed and expected to work 
reliably anywhere.  ie, any script with a #! line (or even a #@ line) 
with a fully qualified Windows path can only be expected to work on a 
single machine - so there is no need to support both #! and #@ as the 
script is not even cross-machine portable, let alone cross-platform 
portable.


The only way to expect a #! line to work across machines would be to 
have a "virtual" path - eg just "python2.6" without any path specifier 
at all.  In that case, I see no problem with reusing the #! from *nix 
systems and treating "/usr/bin" etc as a "virtual" specifier on Windows. 
 If people find a need on Windows to add a fully-qualified path to this 
line (whatever the spelling), they are implicitly saying this script 
works only on the current machine.


IOW, as soon as someone has:

#!/usr/bin/env python2.6 -B
#@c:\python26\python2.6.exe

in their script, the script is targeted at exactly 1 specific machine, 
so why not just reuse the #! syntax?  OTOH, if an existing script has:


#!/usr/bin/env python2.6 -B

They are attempting to declare in a portable way that Python 2.6 is 
necessary - so why force them to add a #@ line to make it work on 
Windows when the #! line is the only clue Windows needs to make it work 
automagically?


Cheers,

Mark
___
Python-Dev mailing list
[email protected]
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


I’m of the opinion that hg diffs should always use the extended git
format, given their usefulness.  A tool working with hg diffs that does
not support this format is broken IMO.


IMO, it's "hg diff --git" that's broken, as it doesn't include the base 
revision (other formats, such as "hg export", do).


Regards,
Martin
___
Python-Dev mailing list
[email protected]
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 3/8/2011 9:06 PM, Mark Hammond wrote:

On 9/03/2011 1:43 PM, Glenn Linderman wrote:

I'm of the opinion that attempting to parse a Unix #! line, and intuit
what would be the equivalent on Windows is unnecessarily complex and
error prone, and assumes that the variant systems are configured using
the same guidelines (which the Python community may espouse, but may not
be followed by all distributions, sysadmins, or users). That's why I
propose a different line for Windows... it is as simple as the
long-proven Unix #! line, but imposes no restrictions on or requirements
that there be a #! line; it has more flexibility in that it could invoke
different versions or provide different options on Unix and Windows if
necessary for some environments.

#!/usr/bin/env python2.6 -B
#@c:\python26\python2.6.exe

or

#!/usr/bin/python2.5
#@"C:\Program Files (x86)\IronPython 2.6 for .NET 4.0\ipy.exe"


I don't think that buys us much.  A script with "#!/usr/bin/env 
python" could be distributed with an expectation it will work across 
various different machines (and possibly even different operating 
systems).  A script with "c:\..." could not be distributed and 
expected to work reliably anywhere.  ie, any script with a #! line (or 
even a #@ line) with a fully qualified Windows path can only be 
expected to work on a single machine - so there is no need to support 
both #! and #@ as the script is not even cross-machine portable, let 
alone cross-platform portable.


Standard installation paths are accepted by about 99% of the users, so 
embedding standard installation paths can work well for that batch of 
users.  Of course, Windows changes the standard path periodically, so 
that it different from versions prior to and including WinXP versus 
versions after WinXP.  And they had no standard before WinNT (or if they 
did, few followed it).  Your comment does point out a possible need for 
multiple standard installation paths just for different versions of 
Windows, though :(


Also, corporate environments are generally quite standardized, so 
scripts developed within and for a corporation (or modified for use 
within a corporation) could quite successfully use such.


You do make a good point, though, that Unix-based environments have more 
standardization in their diversity than Windows does.  Back when I wrote 
Unix code, though, there were plenty of system utility programs that had 
different default paths on different Unix platforms.  /usr/bin/env can 
cover some of that, but is also somewhat of a security hole.




The only way to expect a #! line to work across machines would be to 
have a "virtual" path - eg just "python2.6" without any path specifier 
at all.  In that case, I see no problem with reusing the #! from *nix 
systems and treating "/usr/bin" etc as a "virtual" specifier on 
Windows.  If people find a need on Windows to add a fully-qualified 
path to this line (whatever the spelling), they are implicitly saying 
this script works only on the current machine.


IOW, as soon as someone has:

#!/usr/bin/env python2.6 -B
#@c:\python26\python2.6.exe

in their script, the script is targeted at exactly 1 specific machine, 
so why not just reuse the #! syntax?  OTOH, if an existing script has:


#!/usr/bin/env python2.6 -B

They are attempting to declare in a portable way that Python 2.6 is 
necessary - so why force them to add a #@ line to make it work on 
Windows when the #! line is the only clue Windows needs to make it 
work automagically?


Your premise that using a standard installation path in #@ restricts the 
script to be targeted to one machine is fallacious, so the conclusions 
are also.  You also missed the fact that the -B parameter was deemed 
necessary in the above for the Unix machine(s) of interest, but not 
needed for Windows, which a single line cannot impart (although that is 
an admittedly contrived example of potentially different option 
syntax).  And the use of  cpython on Unix and IronPython on Windows may 
be appropriate for some corporate environments.  A lot of the Unix 
discussion mentioned things like "curable by the sysadmin" like in 
regards to the links... a sysadmin implies a corporate environment, and 
a locked-down path structure.


Of course, /usr/bin/env  is already a "launcher" type facility, specific 
to Unix, to mask variations between systems, and to overcome the fact 
that Unix itself will not walk the PATH to find a non-fully-qualified name.


The #! line is clearly is NOT "the only clue Windows needs to make it 
work automagically" or we wouldn't be having this discussion at all.  
And it is not at all clear if a Windows machine contains Jython, 
IronPython, and Cython which one should be launched by a launcher.  You 
could, of course, argue that python-dev is only concerned with CPython, 
and the launcher can be specific to CPython, and that argument might 
carry the day, but the CPython registry lookup necessary to make that 
happen doesn't help the users of alt

[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-08 Thread Stefan Behnel


"Martin v. Löwis", 08.03.2011 23:47:

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.


I was not aware I could turn on deprecation warning for use of the C
API. How can I do that?


Not sure that you can. When I said "could have known", I meant "by
reading the documentation".


I can confirm that the Cython project was as surprised of the PyCapsule 
change in Python 3.2 as (I guess) most other users, and I would claim that 
we are a project with one of the highest probabilities of being impacted by 
C-API changes.


Maybe the "what's new" document could at least include a link to the 
relevant python-dev discussion/decision, so that fewer people have to ask back?


Actually, why not put up a web page of "upcoming changes" somewhere, that 
lists major decisions with user impact that were taken on python-dev? 
Including a link to the relevant discussion and decision. Often enough, 
decisions are taken inside of huge mailing list threads that get off-topic 
before someone has "the right idea" and everyone who's still there to 
listen agrees. Even for people lurking around on python-dev, it's easy 
enough to miss these moments.


A publicly visible list of those decisions would

a) make it easier for non-core developers to follow important changes on 
python-dev


b) allow potentially impacted people to bring up their POV more quickly, 
e.g. during the alpha cycle of a deprecation release rather than the 
following release, as in this case


c) document the decision taking process by listing the relevant mailing 
list threads


d) help in writing the "what's new" documents

Stefan

___
Python-Dev mailing list
[email protected]
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-08 Thread Stephen J. Turnbull

"Martin v. Löwis" writes:

 > > Doesn't "hg diff -r 'ancestor(branch,default)::branch'", where "branch"
 > > is the unmerged branch you would like to inspect, do the right thing?
 > 
 > What would I specify as "branch" if all I have is 
 > "http://bitbucket.com/turnbull/foo";, and know that it must be the 
 > default branch?

Dunno offhand; I'm a git person.  Here I was specifically addressing
the "multiple patches per file" issue.

What I do in practice is git-like:

hg branch turnbull-foo
hg pull http://bitbucket.com/turnbull/foo
hg commit -m "Temporary turnbull-foo."
hg diff -r 'ancestor(,default)::'
hg branch default

Then if the code is good I merge it and close the branch, if the code
sucks I close the branch, if it needs improvement I keep the branch
until a decision is made.  I haven't thought about automating the
clean up operations, probably you can just close the branch.  Also,
for cases with multiple accesses to the same remote, I'm not sure
whether use of "hg branch --force" would be appropriate or not.

There's probably a way to get around the accumulation of branches and
revision data, but I don't need it (the few people who submit branches
generally submit good code that can be integrated) so I haven't looked
for it.  One obvious approach would be to do this in a separate repo
used only for this purpose and throw it away occasionally, and create
a new one as a clone of the public repo.

___
Python-Dev mailing list
[email protected]
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-08 Thread Mark Hammond


On 9/03/2011 5:05 PM, Glenn Linderman wrote:


Standard installation paths are accepted by about 99% of the users, so
embedding standard installation paths can work well for that batch of
users. Of course, Windows changes the standard path periodically, so
that it different from versions prior to and including WinXP versus
versions after WinXP. And they had no standard before WinNT (or if they
did, few followed it). Your comment does point out a possible need for
multiple standard installation paths just for different versions of
Windows, though :(


The python installer ignores "Program Files" - as much as anything I'm 
concerned about the drive letter - IIUC, Python will default to 
installing on the system drive, which may not be C:


...


Your premise that using a standard installation path in #@ restricts the
script to be targeted to one machine is fallacious, so the conclusions
are also.


Sorry - I should have said "some machines with Python installed by the 
installer".  Contrast this to the option of looking up the registry and 
you have "all machines with Python installed by the installer".  I'm not 
going to quibble about the percentages in the first category as I have 
no data to guide me, but I'm reasonably confident about the "all" in the 
second.


...


The #! line is clearly is NOT "the only clue Windows needs to make it
work automagically" or we wouldn't be having this discussion at all.


Sorry - I should have been clear - I meant "the only clue a windows 
specific Python launcher needs".


> And

it is not at all clear if a Windows machine contains Jython, IronPython,
and Cython which one should be launched by a launcher.


I think it is reasonably clear: it would be the same version which would 
be launched on most *nix systems.  Are there any systems where 
"/usr/bin/python" would use Jython, for example?



You could, of
course, argue that python-dev is only concerned with CPython, and the
launcher can be specific to CPython, and that argument might carry the
day, but the CPython registry lookup necessary to make that happen
doesn't help the users of alternate implementations a bit, forcing each
of them to implement their own launcher as well...


I'd have no problem with the Windows launcher supporting other 
implementations - I expect something like "/usr/bin/jython" would be 
reasonable.  How we locate the installed jython is indeed an interesting 
problem, but I'd guess it is surmountable - especially if we can get the 
buy-in of these alternate implementations for their future releases.



#!/usr/bin/env python2.6
#@"C:\Program Files\Env.exe" ipy2.6.3.exe


As above, the C: assumes Windows is installed on C: - that may be 
common, but not universal.  Further, a 64bit machine would probably want 
"\Program Files (x86)" (which is becoming more and more common)




in .py files and

#!/usr/bin/env python2.6
#@"C:\Program Files\Env.exe" ipy2.6.3w.exe

in .pyw files.


I'm slightly skeptical about that - .pyw files are surely rare on *nix 
systems and as we've discussed, pyw files are generally not meant to be 
cmd-line scripts.  IOW, I'm skeptical scripts exist which are meant to 
work with '/usr/bin/env python2.6' on *nix and pythonw.exe on windows.


...


So no matter what is done, it won't solve world hunger. Probably that's
why Windows users have been left high and dry for years in this
regard... there is no "system" Python on it, out of the box, so the only
users are those that are smart enough to download and install and
configure things, and those who use a Python embedded into an
application, at the cost of a Python installation per application,
because there has been no "system" Python, and because Windows users are
not perceived to be capable of, or willing to bother with, downloading
and installing various requisite dependencies.

The resulting vacuum has been filled by people with different points of
view, because there has been no technique implemented, none declared to
be "best", and anarchy and variant workarounds have abounded.


I'm glad solving world hunger is out of scope for this :)  I understand 
your position but my personal opinion is that simple support for #! is 
more desirable.  I'd be happy to go with the consensus though...


Cheers,

Mark
___
Python-Dev mailing list
[email protected]
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 08.03.2011 23:47, "Martin v. Löwis" wrote:
>>> 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.
>>
>> I was not aware I could turn on deprecation warning for use of the C API.
>> How can I do that?
> 
> Not sure that you can. When I said "could have known", I meant "by 
> reading the documentation".

Well, it looks like the CObject functions actually emitted
PendingDeprecationWarnings when used:

http://hg.python.org/cpython/file/16f8f359db9c/Objects/cobject.c#l12

Georg

___
Python-Dev mailing list
[email protected]
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 09.03.2011 06:44, "Martin v. Löwis" wrote:
>> I’m of the opinion that hg diffs should always use the extended git
>> format, given their usefulness.  A tool working with hg diffs that does
>> not support this format is broken IMO.
> 
> IMO, it's "hg diff --git" that's broken, as it doesn't include the base 
> revision (other formats, such as "hg export", do).

You might want to bring that up on mercurial-devel then.

Georg


___
Python-Dev mailing list
[email protected]
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