[Python-Dev] Python 2.7b1 and argparse's version action

[Tobias Herp]

Hi, all,

(I don't know whether the first attempt to post this went through; I
could'nt find it, so I retry.  My apologies for any inconvenience...)

I noticed that Python 2.7 beta 1 now contains the argparse module, which
might be a good thing.  The code has been cleaned up, too, compared to
the current version 1.1.

But there is still one issue with argparse; to tell the story from the
beginning:

The ArgumentParser class uses uses '-v' as a default short option for
the 'tell me the program version' facility.  Since this is commonly used
for verbosity, and the vast majority of *X commandline tools use '-V'
instead (if they bother to accompany '--version' with a short option at
all).  Therefore I submitted an issue report at

.

To put it short:
*Argparse should simply do this like optparse does already.*
I.e., use '--version', '--help' and '-h' by default, but not '-v'.

Subsequently I spent a hard time arguing.
(Perhaps it was somewhat distracting that I proposed a way of postponing
the creation of the help and version options and to provide them with
the short options which are left unused e.g. for hosts (database
clients), human readability (ls, du, etc.) or verbosity; Steven had
stated it might break backward compatibility if the '-v' option string
for version output would be dropped which might be relied on by other
programs which parse the output.  IMO, however, anyone should be beaten
who relies on '-v' giving the version while '--version' has been present
all the time.  The Zen of Python, 2nd aphorism: "Explicit is better than
implicit")

What happened was the following:
Completely unnecessarily, the 'version' constructor argument is now
deprecated.  This fact doesn't solve any problem I can think of; the
only effect is to make programming more cumbersome, and it is /one more/
difference to optparse.

The 'version' argument is a perfectly reasonable way to provide a script
with a simple version information feature.  Of course, it should only
define the '--version' argument; it *must not* define '-v' for this
purpose, since this is commonly used for verbosity, and '-V' is widely
used to accompany '--version'.  I have lots of scripts which use
optparse, and every single one uses the version argument.  I consider
this a matter of good style.

The deprecation of the 'version' argument press-gangs people to replace
it by
  parser.add_argument('--version', action='version',
  version='',# the only common part
  help="show program's version number and exit")
in every single script (which violates the DRY principle, by the way).

Of course, if a more fancy version information is needed, e.g. reporting
the versions of all imported modules, it is perfectly possible to just
omit the version argument during creation
and build a special 'version' action.  No deprecation warnings are
needed for this.

*Before Python 2.7 reaches productivity stage*, IMNSHO the following
changes should be applied to argparse.py:

- removal of the deprecation warnings
- removal of the default usage of '-v'
  with the version information facility

This is a very simple thing to do; I'd happily provide a patch.
(The only complicated task might be to make the unit tests reflect the
change;  but for a start, 7 lines of the test_main function could be
dropped.)

Just for the records, this is what optparse does:
- it defines -h and --help for the help (unless suppressed)
- it defines --version for the version (if version argument given)
This is how it should be (regarding the version, at least).
This is how the vast majority of *x tools looks like.
No reason to change this behaviour.

What do you think?

-- 

Cheers, Tobias
___
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 2.7b1 and argparse's version action

[Nick Coghlan]

Tobias Herp wrote:
> *Before Python 2.7 reaches productivity stage*, IMNSHO the following
> changes should be applied to argparse.py:
> 
> - removal of the deprecation warnings
> - removal of the default usage of '-v'
>   with the version information facility
> 
> This is a very simple thing to do; I'd happily provide a patch.
> (The only complicated task might be to make the unit tests reflect the
> change;  but for a start, 7 lines of the test_main function could be
> dropped.)
> 
> Just for the records, this is what optparse does:
> - it defines -h and --help for the help (unless suppressed)
> - it defines --version for the version (if version argument given)
> This is how it should be (regarding the version, at least).
> This is how the vast majority of *x tools looks like.
> No reason to change this behaviour.
> 
> What do you think?

I can see Steven's argument from an argparse point of view, but I think
he is taking backwards compatibility to an unhealthy extreme.

Deprecating a perfectly valid option *just* because someone might be
relying on -v instead of -V as the shorthand for version? A phrase
involving babies and bathwater comes to mind...

I would be a lot happier if argparse as a standard library module just
followed optparse's lead here (i.e. defined '--version' only and punted
on the shorthand form).

To deal with this in a backwards compatible way while remaining on the
path to more conventional behaviour, I suggest the following:

1. For Python 2.7, deprecate *just* the "-v" default behaviour for the
version. This means "--version" and "-v" will be set to invoke different
actions when the version argument is supplied (the latter will trigger a
deprecation warning if supplied, while the former will work normally).

2. For Python 3.2, don't create the "-v" shorthand at all (i.e. only
create "--version").

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

[Python-Dev] Keyword-only arguments in 2.x

[George Sakkis]

Hi all,

what's the status of backporting PEP 3102 ? It was supposed to go into
2.6 and it seems it won't be in 2.7 either. There is an updated patch
in the tracker [1] that applies cleanly on the latest trunk and passes
all relevant tests, so unless there has been a decision against
backporting it, would it be possible to push it for 2.7 ? I think this
is a very useful PEP and it would be great to have it in 2.x too.

George

[1] http://bugs.python.org/issue1745
___
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 2.7b1 and argparse's version action

[Ben Finney]

Nick Coghlan  writes:

> I would be a lot happier if argparse as a standard library module just
> followed optparse's lead here (i.e. defined '--version' only and punted
> on the shorthand form).
>
> To deal with this in a backwards compatible way while remaining on the
> path to more conventional behaviour, I suggest the following:
>
> 1. For Python 2.7, deprecate *just* the "-v" default behaviour for the
> version. This means "--version" and "-v" will be set to invoke different
> actions when the version argument is supplied (the latter will trigger a
> deprecation warning if supplied, while the former will work normally).
>
> 2. For Python 3.2, don't create the "-v" shorthand at all (i.e. only
> create "--version").

+1

As someone who uses the existing ‘optparse’ behaviour to implement a
number of Unix command-line programs, the above all makes more sense for
‘argparse’ in the standard library if we're expecting it to be a smooth
upgrade.

-- 
 \  “Natural catastrophes are rare, but they come often enough. We |
  `\   need not force the hand of nature.” —Carl Sagan, _Cosmos_, 1980 |
_o__)  |
Ben Finney

___
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] Python 2.7b1 and argparse's version action

[Tobias Herp]

Hi, all,

I noticed that Python 2.7 beta 1 now contains the argparse module, which
might be a good thing.  The code has been cleaned up, too, compared to
the current version 1.1.

But there is still one issue with argparse; to tell the story from the
beginning:

The ArgumentParser class uses uses '-v' as a default short option for
the 'tell me the program version' facility.  Since this is commonly used
for verbosity, and the vast majority of *X commandline tools use '-V'
instead (if they bother to accompany '--version' with a short option at
all).  Therefore I submitted an issue report at

.

To put it short:
*Argparse should simply do this like optparse does already.*
I.e., use '--version', '--help' and '-h' by default, but not '-v'.

Subsequently I spent a hard time arguing.
(Perhaps it was somewhat distracting that I proposed a way of postponing
the creation of the help and version options and to provide them with
the short options which are left unused e.g. for hosts (database
clients), human readability (ls, du, etc.) or verbosity; Steven had
stated it might break backward compatibility if the '-v' option string
for version output would be dropped which might be relied on by other
programs which parse the output.  IMO, however, anyone should be beaten
who relies on '-v' giving the version while '--version' has been present
all the time.  The Zen of Python, 2nd aphorism: "Explicit is better than
implicit")

What happened was the following:
Completely unnecessarily, the 'version' constructor argument is now
deprecated.  This fact doesn't solve any problem I can think of; the
only effect is to make programming more cumbersome, and it is /one more/
difference to optparse.

The 'version' argument is a perfectly reasonable way to provide a script
with a simple version information feature.  Of course, it should only
define the '--version' argument; it *must not* define '-v' for this
purpose, since this is commonly used for verbosity, and '-V' is widely
used to accompany '--version'.  I have lots of scripts which use
optparse, and every single one uses the version argument.  I consider
this a matter of good style.

The deprecation of the 'version' argument press-gangs people to replace
it by
  parser.add_argument('--version', action='version',
  version='',# the only common part
  help="show program's version number and exit")
in every single script (which violates the DRY principle, by the way).

Of course, if a more fancy version information is needed, e.g. reporting
the versions of all imported modules, it is perfectly possible to just
omit the version argument during creation
and build a special 'version' action.  No deprecation warnings are
needed for this.

*Before Python 2.7 reaches productivity stage*, IMNSHO the following
changes should be applied to argparse.py:

- removal of the deprecation warnings
- removal of the default usage of '-v'
  with the version information facility

This is a very simple thing to do; I'd happily provide a patch.
(The only complicated task might be to make the unit tests reflect the
change;  but for a start, 7 lines of the test_main function could be
dropped.)

Just for the records, this is what optparse does:
- it defines -h and --help for the help (unless suppressed)
- it defines --version for the version (if version argument given)
This is how it should be (regarding the version, at least).
This is how the vast majority of *x tools looks like.
No reason to change this behaviour.

What do you think?

-- 

Cheers, Tobias
___
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 2.7b1 and argparse's version action

[Tobias Herp]

Ben Finney schrieb:
> Nick Coghlan  writes:
> 
>> I would be a lot happier if argparse as a standard library module just
>> followed optparse's lead here (i.e. defined '--version' only and punted
>> on the shorthand form).
>>
>> To deal with this in a backwards compatible way while remaining on the
>> path to more conventional behaviour, I suggest the following:
>>
>> 1. For Python 2.7, deprecate *just* the "-v" default behaviour for the
>> version. This means "--version" and "-v" will be set to invoke different
>> actions when the version argument is supplied (the latter will trigger a
>> deprecation warning if supplied, while the former will work normally).
>>
>> 2. For Python 3.2, don't create the "-v" shorthand at all (i.e. only
>> create "--version").
> 
> +1
> 
> As someone who uses the existing ‘optparse’ behaviour to implement a
> number of Unix command-line programs, the above all makes more sense for
> ‘argparse’ in the standard library if we're expecting it to be a smooth
> upgrade.

Guys, thanks for your feedback.

Let me see; the suggestion involves the '-v' being set in Python 2.7 by
default, but to another action, which yields a DeprecationWarning /and/
performs the version action, right?

The drawback would be: The '-v' wouldn't be available for other uses.
But I use it all the time (for verbosity).

I don't see why we shouldn't drop the '-v' altogether; where Python
standard libraries are concerned, argparse is a new module, and no
compatibility can be broken; people will expect this to follow the
optparse habits.

Programs developed against former versions of argparse will continue to
work, too; there will just not be a (non-standard) short option
generated, but the long option '--version' will be still there.
Honestly, how frequently do you query program versions?

Unfortunately adding a new '-V' default action /could/ break existing
programs, since people might have worked around the former default; thus
we couldn't do this.

Let's get rid of the default '-v' /now/.  This is clean, this is easy,
it won't break anything (with the possible exception of "prog -v"
version output parsers who deserve no better), and we would be done with it.

-- 
Tobias
___
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] Fwd: Broken link to download (Mac OS X)

[Ronald Oussoren]

On 14 Apr, 2010, at 23:37, Michael Foord wrote:

> On 14/04/2010 23:32, Greg Ewing wrote:
>> Michael Foord wrote:
>>> Building Python requires, I believe, the XCode development tools to be 
>>> installed. Even then, building a full version of Python - with *all* the C 
>>> extensions that are part of a Python release - is not a trivial task.
>> 
>> What's non-trivial about it? I usually find that the normal
>> "./configure; make; make install" sequence works fine without
>> any further intervention.
>> 
>> If you want a framework installation you have to read the
>> README and use a couple of extra options, but it still works
>> very smoothly.
>> 
> A build on my machine produces output similar to:
> 
> 
> Python build finished, but the necessary bits to build these modules were not 
> found:
> _bsddb dl gdbm
> imageoplinuxaudiodev  ossaudiodev
> readline   spwd   sunaudiodev
> To find the necessary bits, look in setup.py in detect_modules() for the 
> module's name.
> 
> 
> Failed to build these modules:
> _tkinter
> 
> Obviously many of those are not meant to be built and I usually build Python 
> for running the test suite - so I don't care about not having Tkinter. A new 
> user of Python would most certainly care about not having Tkinter.


What's the OS version? Do you have a copy of Tcl/Tk in /Library/Frameworks? 

Ronald



smime.p7s
Description: S/MIME cryptographic 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] Fwd: Broken link to download (Mac OS X)

[Ronald Oussoren]

On 15 Apr, 2010, at 0:12, Zvezdan Petkovic wrote:

> On Apr 14, 2010, at 4:40 PM, Martin v. Löwis wrote:
> 
>>> I think you just need to supply to configure
>>> 
>>> MACOSX_DEPLOYMENT_TARGET=10.4
>>> 
>>> and have the appropriate SDK installed with Xcode.
>> 
>> Wouldn't that break 10.3 compatibility (seel below)?
> 
> 
> I was replying to your point about 10.4 build.
> Naturally, if you want a 10.3 build you'd pass 10.3 as the target and would 
> have to have appropriate Xcode SDK installed.

You don't have to install an SDK to be able to build binaries that run on older 
versions. The reason the binary installer gets build with the 10.4u SDK is that 
the default compiler on OSX 10.4 cannot build universal binaries without that 
SDK.

> 
> 
 Unfortunately, Apple manages to break compatibility and portability
 with every release, which makes this particular build task s
 tricky. You have to make all kinds of decisions and compromises
 where are really difficult to keep track of.
>>> 
>>> 
>>> Hmm.  Apple provided compatibility SDK and documented it.
>>> 
>>> The only compromise I see in this build process right now is that we
>>> are building a Panther (10.3) compatible installer, while Mac OS X is
>>> a certified UNIX starting with 10.5.
>> 
>> I think there are more issues. People want a fat binary that supports
>> AMD64 along with x86, yet building such a binary requires an SDK that
>> won't support PPC anymore - right?
> 
> Yes.

No. It is possible to build a binary that supports ppc, ppc64, x86 and x86_64, 
and that's even possible using a single additional configure switch. That 
binary will require OSX 10.5 to run though due to using symbols that aren't 
available on earlier versions of OSX (thanks to the better UNIX API 
compatibility in 10.5).

PPC64 is not supported on OSX 10.6 though.

> 
> x86_64, i386, and ppc are supported even in the Xcode supplied with the 
> latest Mac OS X 10.6.  Only ppc64 is not.  So, ppc is not an issue.
> 
> The problem is that enforcing backward compatibility with 10.3 and 10.4 makes 
> 64-bit Intel architecture not feasible.
> 
> You are right, it is a compromise.
> We are making more users happy by providing a 32-bit installer for a wider 
> range of OS releases.
> 
> However, if we want a more modern certified UNIX, 64-bit installer, then 
> we'll have to draw a line and stop supporting older OS releases.
> 
> Just as we stop supporting older releases of Python.

I want to provide 2 installers for Python 2.7 and 3.2:

1) The current 32-bit only installer that runs on OSX 10.3 or later

2) An installer that supports ppc, x86 and x86_64 and requires OSX 10.5 or later

The latter would be the one that most users would want to use. Note that the 
second installer does not support ppc64 and three reasons: (1) PPC64 is a dead 
end on OSX, (2) libffi has issues on darwin/ppc64 that probably affect ctypes 
and (3) I do not have regular access to ppc64 machines and can therefore not 
provide any support for that platform.

Ronald



smime.p7s
Description: S/MIME cryptographic 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] Fwd: Broken link to download (Mac OS X)

[Ronald Oussoren]

On 15 Apr, 2010, at 6:36, Martin v. Löwis wrote:

> Greg Ewing wrote:
>> Michael Foord wrote:
>>> Building Python requires, I believe, the XCode development tools to be
>>> installed. Even then, building a full version of Python - with *all*
>>> the C extensions that are part of a Python release - is not a trivial
>>> task.
>> 
>> What's non-trivial about it? 
> 
> Building a DMG file, in a way that the output will actually work on most
> other systems.

That *is* trivial: use Mac/BuildScript/build-installer.py on OSX 10.5.  Making 
sure that unrelated changes don't accidently break the OSX build can be 
non-trivial though...

That doesn't work with the py3k trunk at the moment, I just noticed that 
framework builds are broken there. I've filed issue #8441 for that and am 
working on a fix.

Ronald
> 
> 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/ronaldoussoren%40mac.com



smime.p7s
Description: S/MIME cryptographic 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] MSDN licenses available for python-dev

[anatoly techtonik]

Twisted folks will surely appreciate any help and may be able to
contribute back.
http://twistedmatrix.com/trac/wiki/Windows

-- 
anatoly t.



On Fri, Apr 16, 2010 at 4:01 PM, Brian Curtin  wrote:
> Hi python-dev,
>
> The recent threads on builds/installers for Mac and Windows reminded me of
> Steve Holden's push to get the python-dev team equipped via a connection
> with the Microsoft Open Source Technology Center. The OSTC team provides
> Microsoft Developer Network licenses to open source projects to assist them
> in better supporting Windows.
>
> I've talked with Steve (who passed the task to me) and the Microsoft folks,
> and they are happy to provide more licenses if needed. If you are interested
> in getting a copy of MSDN, please contact me off-list. I'll provide you with
> a code that you'll put into their site, then around a week later you should
> get your subscription.
>
> The snippet below is taken from prior correspondence with the OSTC team in
> regards to who can receive the licenses:
>
> """
> For the purposes of providing MSDN licenses to an open source development
> community, I consider anyone who writes, builds, tests or documents software
> to be a "developer who contributes" to the project. (In fact, having started
> out as a test engineer, I would take exception to anyone who claimed only
> people who write code are "developers" :-) We do ask that requests are for
> people who are active contributors and not just minor/occasional
> participants.
> """
>
> If this applies to you and you are interested, let me know.
>
> Brian Curtin
>
> ___
> 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/techtonik%40gmail.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Keyword-only arguments in 2.x

[Martin v. Löwis]

> what's the status of backporting PEP 3102 ? 

It looks like it won't happen.

> It was supposed to go into
> 2.6 and it seems it won't be in 2.7 either. 

Correct - and therefore, it won't be backported at all.

> There is an updated patch
> in the tracker [1] that applies cleanly on the latest trunk and passes
> all relevant tests, so unless there has been a decision against
> backporting it, would it be possible to push it for 2.7 ?

No - 2.7 has already seen its first beta release, so no new features are
acceptable (except by release manager decision or BDFL pronouncement).

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] MSDN licenses available for python-dev

[exarkun]

On 02:56 pm, techto...@gmail.com wrote:

Twisted folks will surely appreciate any help and may be able to
contribute back.
http://twistedmatrix.com/trac/wiki/Windows


Extra Windows and VS licenses would certainly be helpful for Twisted 
development, and might lead indirectly to CPython/Windows improvements. 
Is this the kind of use for which it is appropriate to request an MSDN 
license via the PSF?


Jean-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] Fwd: Broken link to download (Mac OS X)

[Martin v. Löwis]

Ronald Oussoren wrote:
> On 15 Apr, 2010, at 6:36, Martin v. Löwis wrote:
> 
>> Greg Ewing wrote:
>>> Michael Foord wrote:
 Building Python requires, I believe, the XCode development tools to be
 installed. Even then, building a full version of Python - with *all*
 the C extensions that are part of a Python release - is not a trivial
 task.
>>> What's non-trivial about it? 
>> Building a DMG file, in a way that the output will actually work on most
>> other systems.
> 
> That *is* trivial: use Mac/BuildScript/build-installer.py on OSX 10.5. 

Hmm. When I tried it (on some 2.5 release), it took me two days until it
produced something.

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] Fwd: Broken link to download (Mac OS X)

[Ronald Oussoren]

On 18 Apr, 2010, at 17:17, Martin v. Löwis wrote:

> Ronald Oussoren wrote:
>> On 15 Apr, 2010, at 6:36, Martin v. Löwis wrote:
>> 
>>> Greg Ewing wrote:
 Michael Foord wrote:
> Building Python requires, I believe, the XCode development tools to be
> installed. Even then, building a full version of Python - with *all*
> the C extensions that are part of a Python release - is not a trivial
> task.
 What's non-trivial about it? 
>>> Building a DMG file, in a way that the output will actually work on most
>>> other systems.
>> 
>> That *is* trivial: use Mac/BuildScript/build-installer.py on OSX 10.5. 
> 
> Hmm. When I tried it (on some 2.5 release), it took me two days until it
> produced something.

It should be much improved in 2.6 and later, please file a bug if it doesn't 
work for you.

Ronald
> 
> Regards,
> Martin



smime.p7s
Description: S/MIME cryptographic 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] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))

[Martin v. Löwis]

> We can certainly start by just trying to automate the execution of
> build-installer, something I suspect can be completely controlled from
> the master side, and then uploading the resulting dmg file.  I'd be
> happy to help coordinate any experiments offline if you're interested.

Sure!

> I do currently have a DMG built for 2.7 Beta 1, if it would be useful.

As I said before: if you would plan to do this on a regular basis, for
all upcoming releases, that would certainly be a good thing.

Having just a single DMG file for some beta release doesn't really help,
as testing results for that binary might not transfer to the next one
(if the next one comes from a different environment again).

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] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))

[Ronald Oussoren]

On 18 Apr, 2010, at 17:20, Martin v. Löwis wrote:

>> We can certainly start by just trying to automate the execution of
>> build-installer, something I suspect can be completely controlled from
>> the master side, and then uploading the resulting dmg file.  I'd be
>> happy to help coordinate any experiments offline if you're interested.
> 
> Sure!
> 
>> I do currently have a DMG built for 2.7 Beta 1, if it would be useful.
> 
> As I said before: if you would plan to do this on a regular basis, for
> all upcoming releases, that would certainly be a good thing.
> 
> Having just a single DMG file for some beta release doesn't really help,
> as testing results for that binary might not transfer to the next one
> (if the next one comes from a different environment again).

I will provide installers for 2.7 starting from beta2,

Ronald

> 
> 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/ronaldoussoren%40mac.com



smime.p7s
Description: S/MIME cryptographic 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] MSDN licenses available for python-dev

[Brian Curtin]

On Sun, Apr 18, 2010 at 10:16,  wrote:

> On 02:56 pm, techto...@gmail.com wrote:
>
>> Twisted folks will surely appreciate any help and may be able to
>> contribute back.
>> http://twistedmatrix.com/trac/wiki/Windows
>>
>
> Extra Windows and VS licenses would certainly be helpful for Twisted
> development, and might lead indirectly to CPython/Windows improvements. Is
> this the kind of use for which it is appropriate to request an MSDN license
> via the PSF?
>
> Jean-Paul
>

To my knowledge, no. I'm only handling PSF-specific subscriptions so I
wouldn't be comfortable giving them out for developers of Twisted or any
other project. However, I would encourage those projects to contact the OSTC
directly to start up a relationship.

Since you are active and fit the criteria for CPython, I can give you a
subscription and I know of no restrictions on what it's used for outside of
CPython.

Brian
___
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] bbreport

[Florent Xicluna]

> Does it really need trunk?  I've been running it under 2.6 without
> problems, but I probably haven't explored all the options fully.
>

Now it works on 2.6 (or 2.5+pysqlite).

Regards,

-- 
Florent
___
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 2.7b1 and argparse's version action

[Steven Bethard]

On Sun, Apr 18, 2010 at 3:31 AM, Tobias Herp  wrote:
> To put it short:
> *Argparse should simply do this like optparse does already.*
> I.e., use '--version', '--help' and '-h' by default, but not '-v'.
[snip]
> What happened was the following:
> Completely unnecessarily, the 'version' constructor argument is now
> deprecated.
[snip]
> The deprecation of the 'version' argument press-gangs people to replace
> it by
>  parser.add_argument('--version', action='version',
>                      version='',    # the only common part
>                      help="show program's version number and exit")

What Tobias has conveniently omitted is that there was not much
agreement on what the default behavior of the version flag should be.
Things that were proposed:

* Use both -v and --version
* Use both -V and --version
* Use just --version
* Print out just the version string
* Print out program name with the version string

I put up a poll and asked people for feedback on some of the alternatives:

http://www.vizu.com/res/Grab-bag/argparse/poll-results.html?n=192933

And it was far from a consensus. Given the lack of consensus, the many
different options people thought were the "right" way to do things,
and the fact that the action='version' approach allows people to
customize the flags to whatever they want, I stick by my decision to
deprecate the constructor argument and redirect people to the more
flexible add_argument approach. In the face of ambiguity, refuse the
temptation to guess.

In general, I should say that I'm not opposed to changing the behavior
in Python trunk, even if it causes a bit of backwards incompatibility.
But I'd really like a consensus about the correct behavior, and so far
I have not seen that.

Steve
-- 
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
___
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 2.7b1 and argparse's version action

[Steven Bethard]

On Sun, Apr 18, 2010 at 4:03 AM, Nick Coghlan  wrote:
> To deal with this in a backwards compatible way while remaining on the
> path to more conventional behaviour, I suggest the following:
>
> 1. For Python 2.7, deprecate *just* the "-v" default behaviour for the
> version. This means "--version" and "-v" will be set to invoke different
> actions when the version argument is supplied (the latter will trigger a
> deprecation warning if supplied, while the former will work normally).

It's not clear how you would do this. If you can suggest a patch, I'd
be happy to consider it. However, and the moment, you get "-v" and
"--version" by simply specifying ArgumentParser(..., version="XXX").
So how do you deprecate just the "-v"?

All I can imagine you mean is to issue a deprecation warning whenever
a user of the script provides "-v" at the command line, but that seems
sketchy to me - we'd be deprecating features of someone's
*application*, not features of the argparse *library*.

Steve
-- 
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
___
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] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))

[David Bolen]

"Martin v. Löwis"  writes:

>> I do currently have a DMG built for 2.7 Beta 1, if it would be useful.
>
> As I said before: if you would plan to do this on a regular basis, for
> all upcoming releases, that would certainly be a good thing.

No argument - just figured I'd offer to get past the near term
resource issue, presuming that having a beta installer available is
better than not, even with some build-environment difference risk.

I could probably commit to a longer term too, but it sounds like
Ronald is still on board for that.  I've also been a little hesitant
since there's clearly a lot of effort that has been put into the Mac
build stuff and I didn't want to be the inexperienced bull in the
china shop compared to those who have been doing it for a while.

I'm happy to stick with the buildbot side of things for now, and
remain willing to assist in any changes to better match the buildbot
builds to the final distribution process for more aligned testing.

-- David

___
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] Fwd: Broken link to download (Mac OS X)

[David Bolen]

Ronald Oussoren  writes:

> On 18 Apr, 2010, at 17:17, Martin v. Löwis wrote:
>
>> Ronald Oussoren wrote:
>>>
>>> That *is* trivial: use Mac/BuildScript/build-installer.py on OSX 10.5. 
>> 
>> Hmm. When I tried it (on some 2.5 release), it took me two days until it
>> produced something.
>
> It should be much improved in 2.6 and later, please file a bug if it
> doesn't work for you.

For what it's worth, the trunk currently takes ~25 minutes on my
relatively modest Mini, when run in parallel with some buildbot stuff,
and with third-party sources already downloaded.  More or less evenly
split among third-party packages, the interpreter itself, and then
docs/framework/disk image creation.

-- David

___
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 2.7b1 and argparse's version action

[Tobias Herp]

Steven Bethard schrieb:
> On Sun, Apr 18, 2010 at 3:31 AM, Tobias Herp  wrote:
>> To put it short:
>> *Argparse should simply do this like optparse does already.*
>> I.e., use '--version', '--help' and '-h' by default, but not '-v'.
> [snip]
>> What happened was the following:
>> Completely unnecessarily, the 'version' constructor argument is now
>> deprecated.
> [snip]
>> The deprecation of the 'version' argument press-gangs people to replace
>> it by
>>  parser.add_argument('--version', action='version',
>>  version='',# the only common part
>>  help="show program's version number and exit")
> 
> What Tobias has conveniently omitted is that there was not much
> agreement on what the default behavior of the version flag should be.

Well, the mail was quite long already, and the issue-tracker issue was
linked.

> Things that were proposed:
> 
> * Use both -v and --version

This is very unusual. I don't know of a single example other than
existing argparse.  Incompatible to existing optparse usage.

> * Use both -V and --version

A very common combination; many programs which support --version
accompany it with -V.
However, if we'd add '-V' to the default option strings, we would likely
break existing programs which worked around the so-far default.

> * Use just --version

IMO the only way, and the way optparse does it.

> * Print out just the version string
> * Print out program name with the version string

If this is an issue:  With optparse, the version argument value is
printed, which is often something like '%prog '+VERSION
(for argparse, '%(prog)s '+VERSION or '%%(prog)s %s' % VERSION).
This way, the decision is left to the programmer.
Completely agreeable, as far as I'm concerned.

> I put up a poll [...]
> 
> Given the lack of consensus, the many
> different options people thought were the "right" way to do things,
> and the fact that the action='version' approach allows people to
> customize the flags to whatever they want, I stick by my decision to
> deprecate the constructor argument ...

A. Very. Bad. Idea.

> ... and redirect people to the more flexible add_argument approach.

It is ok to /allow/ people to customize the flags to whatever they want.
It is /not/ ok to /force/ them to do so, if there is a perfectly
reasonable solution which allows them to stick with their habits.
And there is one: drop the '-v' default.  The only way (see above).

> In the face of ambiguity, refuse the temptation to guess.

No guessing is needed (and the ZoP aphorism is not applicable here: this
is not about guessing what the user might have meant.  Besides, if the
user specifies '--version', [s]he /very/ likely wants some info about
the program version; giving '-v' can have been done looking forward to
--verbose output (ok, nothing bad will happen, but it mismatches user
expectations).

> In general, I should say that I'm not opposed to changing the behavior
> in Python trunk, even if it causes a bit of backwards incompatibility.

A /very little/ bit.
When fetching stdout to get the program version, it is much more
reasonable to rely on '--version' than on '-v'.  This is /the/ option
string which is best supported by far.

> But I'd really like a consensus about the correct behavior, and so far
> I have not seen that.

We'll have one ;-)

-- 
Tobias
___
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 2.7b1 and argparse's version action

[Tobias Herp]

Steven Bethard schrieb:
> On Sun, Apr 18, 2010 at 4:03 AM, Nick Coghlan  wrote:
>> To deal with this in a backwards compatible way while remaining on the
>> path to more conventional behaviour, I suggest the following:
>>
>> 1. For Python 2.7, deprecate *just* the "-v" default behaviour for the
>> version. This means "--version" and "-v" will be set to invoke different
>> actions when the version argument is supplied (the latter will trigger a
>> deprecation warning if supplied, while the former will work normally).
> 
> [...]
> 
> All I can imagine you mean is to issue a deprecation warning whenever
> a user of the script provides "-v" at the command line, but that seems
> sketchy to me - we'd be deprecating features of someone's
> *application*, not features of the argparse *library*.

It would raise warnings when the option is /used/ (rather than defined;
such warnings address programmers, though), and it wouldn't free '-v'
for other uses.

I agree that this would be more complicated than necessary.
It would be better to just drop the default usage of '-v'.
This way we wouldn't need a deprecation procedure either.

-- 
Tobias
___
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] bbreport

[Victor Stinner]

Le samedi 17 avril 2010 20:41:10, Victor Stinner a écrit :
> Ezio and Florent are developing a tool called bbreport to collect buildbot
> results and generate short reports to the command line. (...)

I realized that most issues come from Windows and Mac. Can't we just turn off 
these buildbots?

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

Re: [Python-Dev] Python 2.7b1 and argparse's version action

[Steven Bethard]

On Sun, Apr 18, 2010 at 2:35 PM, Tobias Herp  wrote:
> Steven Bethard schrieb:
>> On Sun, Apr 18, 2010 at 3:31 AM, Tobias Herp  wrote:
>>> *Argparse should simply do this like optparse does already.*
>>> I.e., use '--version', '--help' and '-h' by default, but not '-v'.
>> [snip]
>>> The deprecation of the 'version' argument press-gangs people to replace
>>> it by
>>>  parser.add_argument('--version', action='version',
>>>                      version='',    # the only common part
>>>                      help="show program's version number and exit")
>>
>> What Tobias has conveniently omitted is that there was not much
>> agreement on what the default behavior of the version flag should be.
[snip a bunch of Tobias's opinions on what the default should be]
>>
>> But I'd really like a consensus about the correct behavior, and so far
>> I have not seen that.
>
> We'll have one ;-)

I hope you can understand that I don't consider your personal opinion
alone as a consensus. As I said, I'm willing to change the defaults
and even break backwards compatibility a bit in Python trunk[1] but I
need to a see a consensus from a variety of developers that
"--version" is the right answer, and not "-V/--version", etc. Note
that even though I agree with you that "-v/--version" is probably not
the best choice, in the poll[2] 11% of people still wanted this. So
it's not a simple decision.

By the way, we could simplify the typical add_argument usage by adding
"show program's version number and exit" as the default help for the
'version' action. Then you should just write:

parser.add_argument('--version', action='version', version='')

Steve

[1] Assuming the release manager will allow it.
[2] http://www.vizu.com/res/Grab-bag/argparse/poll-results.html?n=192933
-- 
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
___
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 2.7b1 and argparse's version action

[Antoine Pitrou]

Steven Bethard  gmail.com> writes:
> 
> I
> need to a see a consensus from a variety of developers that
> "--version" is the right answer, and not "-V/--version", etc.

Both are ok for me. "-v" as a shortcut for "--version" looks wrong, though. "-v"
is almost always used for verbosity these days.

> Note
> that even though I agree with you that "-v/--version" is probably not
> the best choice, in the poll[2] 11% of people still wanted this.

This strikes me as a small minority.

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] Python 2.7b1 and argparse's version action

[Nick Coghlan]

Steven Bethard wrote:
> By the way, we could simplify the typical add_argument usage by adding
> "show program's version number and exit" as the default help for the
> 'version' action. Then you should just write:
> 
> parser.add_argument('--version', action='version', version=' version>')

With that change, I would have no problem with the current argparse
behaviour (since doing it this way makes it very easy for people to add
a "-V" shortcut if they want one).

Cheers,
Nick.

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

Re: [Python-Dev] Python 2.7b1 and argparse's version action

[Michael Foord]

On 19/04/2010 00:52, Antoine Pitrou wrote:

Steven Bethard  gmail.com>  writes:
   

I
need to a see a consensus from a variety of developers that
"--version" is the right answer, and not "-V/--version", etc.
 

Both are ok for me. "-v" as a shortcut for "--version" looks wrong, though. "-v"
is almost always used for verbosity these days.
   
Adding -V *could* be incompatible with existing users using it for 
something else. A default '--version' seems like a sensible solution to me.


Michael

   

Note
that even though I agree with you that "-v/--version" is probably not
the best choice, in the poll[2] 11% of people still wanted this.
 

This strikes me as a small minority.

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/fuzzyman%40voidspace.org.uk
   



--
http://www.ironpythoninaction.com/

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

Re: [Python-Dev] bbreport

[Nick Coghlan]

Victor Stinner wrote:
> Le samedi 17 avril 2010 20:41:10, Victor Stinner a écrit :
>> Ezio and Florent are developing a tool called bbreport to collect buildbot
>> results and generate short reports to the command line. (...)
> 
> I realized that most issues come from Windows and Mac. Can't we just turn off 
> these buildbots?

o.O?

Remember there's no tone of voice in email... smileys matter when joking :)

Cheers,
Nick.

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

Re: [Python-Dev] Python 2.7b1 and argparse's version action

[Steven Bethard]

On Sun, Apr 18, 2010 at 3:57 PM, Nick Coghlan  wrote:
> Steven Bethard wrote:
>> By the way, we could simplify the typical add_argument usage by adding
>> "show program's version number and exit" as the default help for the
>> 'version' action. Then you should just write:
>>
>>     parser.add_argument('--version', action='version', version='> version>')
>
> With that change, I would have no problem with the current argparse
> behaviour (since doing it this way makes it very easy for people to add
> a "-V" shortcut if they want one).

Probably this should happen regardless of the outcome of the
constructor argument. The only reason it wasn't already there is that
I hadn't thought of it. ;-)

Steve
-- 
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
___
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 2.7b1 and argparse's version action

[Steven Bethard]

On Sun, Apr 18, 2010 at 3:52 PM, Antoine Pitrou  wrote:
> Steven Bethard  gmail.com> writes:
>> Note
>> that even though I agree with you that "-v/--version" is probably not
>> the best choice, in the poll[2] 11% of people still wanted this.
>
> This strikes me as a small minority.

Agreed, but it's also the current behavior, and has been since the
beginning of argparse. Note that no one complained about it until
Tobias filed the issue in Nov 06, 2009.

Steve
-- 
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
___
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 2.7b1 and argparse's version action

[Eric Smith]

Steven Bethard wrote:

By the way, we could simplify the typical add_argument usage by adding
"show program's version number and exit" as the default help for the
'version' action. Then you should just write:

parser.add_argument('--version', action='version', version='')


I like this the best. I don't like argparse adding arguments for me.

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

Re: [Python-Dev] Python 2.7b1 and argparse's version action

[Nick Coghlan]

Steven Bethard wrote:
> On Sun, Apr 18, 2010 at 3:57 PM, Nick Coghlan  wrote:
>> Steven Bethard wrote:
>>> By the way, we could simplify the typical add_argument usage by adding
>>> "show program's version number and exit" as the default help for the
>>> 'version' action. Then you should just write:
>>>
>>> parser.add_argument('--version', action='version', version='>> version>')
>> With that change, I would have no problem with the current argparse
>> behaviour (since doing it this way makes it very easy for people to add
>> a "-V" shortcut if they want one).
> 
> Probably this should happen regardless of the outcome of the
> constructor argument. The only reason it wasn't already there is that
> I hadn't thought of it. ;-)

Crazy thought... would it make sense to have the following implicitly
use "--version" as the option flag:

  parser.add_argument(action='version', version='')

There are two things about the explicit '--version' that bother me:
1. It reduces the automatic provision of "standard" option spellings
2. The repetition in reading/writing 'version' 3 times is kind of annoying

(Probably a bad idea, since adding "-V" would mean having to add
"--version" as well, but figured it was worth mentioning).

Cheers,
Nick.

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

Re: [Python-Dev] Python 2.7b1 and argparse's version action

[Tobias Herp]

Eric Smith schrieb:
> Steven Bethard wrote:
>> By the way, we could simplify the typical add_argument usage by adding
>> "show program's version number and exit" as the default help for the
>> 'version' action. Then you should just write:
>>
>> parser.add_argument('--version', action='version', version='> version>')
> 
> I like this the best. I don't like argparse adding arguments for me.

There is no reason why you shouldn't get it.  You could always (and with
optparse as well as argparse) omit the version argument and build or
build not the version argument yourself.

Or a special add_version_option (hey, it's really an /option/) or
add_version_argument method, which would work without if statements and
could be overridden in subclasses.

But note that
- many optparse programs use the version argument
- many other programmers find this feature very convenient
- dropping or deprecating this is a totally unnecessary change
  (I have not read a single real reason /why/ this should be done).

-- 
Tobias
___
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 2.7b1 and argparse's version action

[Tobias Herp]

Steven Bethard schrieb:
> On Sun, Apr 18, 2010 at 3:52 PM, Antoine Pitrou  wrote:
>> Steven Bethard  gmail.com> writes:
>>> Note
>>> that even though I agree with you that "-v/--version" is probably not
>>> the best choice, in the poll[2] 11% of people still wanted this.
>>
>> This strikes me as a small minority.
> 
> Agreed, but it's also the current behavior, ...

The current /broken, non-standard/ behaviour.

For keeping a current status quo, this is an even worse poll.  Very
likely some of these voted for this choice because they were afraid of
changes (unnecessarily, as explained before).

> ... and has been since the beginning of argparse.

It's not my fault that in the beginning apparently nobody cared about
existing conventions.

> Note that no one complained about it until
> Tobias filed the issue in Nov 06, 2009.

This is not an argument at all.

I have collected lots of examples of widely used programs and their
options. The only example of '-v', '--verbose' is argparse.
It is vital we meet user expectations, and that we support developers in
producing programs that do so.

-- 
Tobias

___
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 2.7b1 and argparse's version action

[Tobias Herp]

Steven Bethard schrieb:
> On Sun, Apr 18, 2010 at 2:35 PM, Tobias Herp  wrote:
>> Steven Bethard schrieb:
>>> On Sun, Apr 18, 2010 at 3:31 AM, Tobias Herp  wrote:
 *Argparse should simply do this like optparse does already.*
 I.e., use '--version', '--help' and '-h' by default, but not '-v'.
>>> [snip]
 The deprecation of the 'version' argument press-gangs people to replace
 it by
  parser.add_argument('--version', action='version',
  version='',# the only common part
  help="show program's version number and exit")
>>>
>>> What Tobias has conveniently omitted is that there was not much
>>> agreement on what the default behavior of the version flag should be.
> [snip a bunch of Tobias's opinions on what the default should be]
>>>
>>> But I'd really like a consensus about the correct behavior, and so far
>>> I have not seen that.
>>
>> We'll have one ;-)
> 
> I hope you can understand that I don't consider your personal opinion
> alone as a consensus.

Be careful.  There have been other personal opinions, and there are very
many *X programs which form a standard which should be followed, and
this is a /very strong/ argument, IMO.

What you conveniently omitted is that I collected a lot of examples and
commented the choices (part of which were part of your poll).
Unfortunately you completely ignored these very prosaic arguments.

By the way, I just had a look at your poll (currently 81 votes).
Correct me if I'm wrong, but...
- AFAICS, you didn't provide your audience with any background
  information, e.g.
  - how optparse does it (and migration should be as easy as possible,
right?)
  - the existing de-facto standard "--version [-V]"
- the choice which reflects my proposal got the most votes
  (46.9% currently)
- 42.0% voted for dropping the version argument, which is a minority
  (bzw., do you really think the 46.9%
  would like the version argument to be deprecated?!)
  which apparently didn't consider the optparse migration/analogy issue.

Furthermore, nobody who dislikes the version feature is forced to use it.
If 60% had voted for removal of a feature which is important and
convenient for 40%, would you remove it?  Really?
IMO, removal of a feature which is used by 40% is out of the question;
and if removal is, deprecation is as well.

Back to the actual numbers: dropping the argument is impossible (/and so
is deprecation/); drop the 42.0%.
Take the remaining numbers: 46.9% voted for the change, and 11.1%
against it.

Do you take your own poll seriously?

-- 
Tobias
___
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 2.7b1 and argparse's version action

[Nick Coghlan]

Tobias Herp wrote:
> Be careful.  There have been other personal opinions, and there are very
> many *X programs which form a standard which should be followed, and
> this is a /very strong/ argument, IMO.

If the "version=" argument were to only provide "--version", how would
you conveniently add a "-V" shorthand?

This is trivial with the add_argument approach, but less straightforward
with a "version=" argument to the parser constructor.

People that want "-v" to mean verbosity in 2.x can also trivially pass
"conflict_handler='resolve'" to override the implicitly created version
shorthand.

Would it be more convenient if argparse had never deviated from the GNU
and optparse command line conventions in this respect? Sure it would be.
But given that it did, a 'version' action that makes it trivial to
choose the details of your version flags is a decent alternative
approach to a now-ambiguous version argument to the parser constructor
(especially once the default help string for the option is added).

Note there are two changes I believe should be made to the argparse
documentation for 2.7 though:
- the '--version' example should either not use a shorthand, or should
use the conventional '-V'
- this issue needs to be mentioned in the section on migrating from
optparse.

Cheers,
Nick.

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

Re: [Python-Dev] Python 2.7b1 and argparse's version action

[Cameron Simpson]

On 18Apr2010 22:52, Antoine Pitrou  wrote:
| Steven Bethard  gmail.com> writes:
| > I
| > need to a see a consensus from a variety of developers that
| > "--version" is the right answer, and not "-V/--version", etc.
| 
| Both are ok for me. "-v" as a shortcut for "--version" looks wrong, though.
| "-v" is almost always used for verbosity these days.

My view is the same.
-- 
Cameron Simpson  DoD#743
http://www.cskk.ezoshosting.com/cs/

By dint of railing at idiots one runs the risk of becoming idiotic oneself.
- Gustave Flaubert
___
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 2.7b1 and argparse's version action

[Steve Holden]

Tobias Herp wrote:
> Steven Bethard schrieb:
>> On Sun, Apr 18, 2010 at 2:35 PM, Tobias Herp  wrote:
>>> Steven Bethard schrieb:
 On Sun, Apr 18, 2010 at 3:31 AM, Tobias Herp  wrote:
> *Argparse should simply do this like optparse does already.*
> I.e., use '--version', '--help' and '-h' by default, but not '-v'.
 [snip]
> The deprecation of the 'version' argument press-gangs people to replace
> it by
>  parser.add_argument('--version', action='version',
>  version='',# the only common part
>  help="show program's version number and exit")
 What Tobias has conveniently omitted is that there was not much
 agreement on what the default behavior of the version flag should be.
>> [snip a bunch of Tobias's opinions on what the default should be]
 But I'd really like a consensus about the correct behavior, and so far
 I have not seen that.
>>> We'll have one ;-)
>> I hope you can understand that I don't consider your personal opinion
>> alone as a consensus.
> 
> Be careful.  There have been other personal opinions, and there are very
> many *X programs which form a standard which should be followed, and
> this is a /very strong/ argument, IMO.
> 
> What you conveniently omitted is that I collected a lot of examples and
> commented the choices (part of which were part of your poll).
> Unfortunately you completely ignored these very prosaic arguments.
> 
> By the way, I just had a look at your poll (currently 81 votes).
> Correct me if I'm wrong, but...
> - AFAICS, you didn't provide your audience with any background
>   information, e.g.
>   - how optparse does it (and migration should be as easy as possible,
> right?)
>   - the existing de-facto standard "--version [-V]"
> - the choice which reflects my proposal got the most votes
>   (46.9% currently)
> - 42.0% voted for dropping the version argument, which is a minority
>   (bzw., do you really think the 46.9%
>   would like the version argument to be deprecated?!)
>   which apparently didn't consider the optparse migration/analogy issue.
> 
> Furthermore, nobody who dislikes the version feature is forced to use it.
> If 60% had voted for removal of a feature which is important and
> convenient for 40%, would you remove it?  Really?
> IMO, removal of a feature which is used by 40% is out of the question;
> and if removal is, deprecation is as well.
> 
> Back to the actual numbers: dropping the argument is impossible (/and so
> is deprecation/); drop the 42.0%.
> Take the remaining numbers: 46.9% voted for the change, and 11.1%
> against it.
> 
> Do you take your own poll seriously?
> 
When was this ever a democracy?

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
See PyCon Talks from Atlanta 2010  http://pycon.blip.tv/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS:http://holdenweb.eventbrite.com/

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

Re: [Python-Dev] Python 2.7b1 and argparse's version action

[Ian Bicking]

On Sun, Apr 18, 2010 at 6:24 PM, Steven Bethard wrote:

> On Sun, Apr 18, 2010 at 3:52 PM, Antoine Pitrou 
> wrote:
> > Steven Bethard  gmail.com> writes:
> >> Note
> >> that even though I agree with you that "-v/--version" is probably not
> >> the best choice, in the poll[2] 11% of people still wanted this.
> >
> > This strikes me as a small minority.
>
> Agreed, but it's also the current behavior, and has been since the
> beginning of argparse. Note that no one complained about it until
> Tobias filed the issue in Nov 06, 2009.
>

I encountered this problem within minutes of first using argparse.  Of
course I'm very familiar with optparse and the standard optparse
instantiation flies off my fingers without thinking.  But then there's going
to be a lot more people with that background using argparse once it is in
the standard library -- people who don't really care about argparse or
optparse but just want to use the standard thing.  I don't see any reason
why argparse can't simply do exactly what optparse did.  There's nothing
wrong with it.  It's what many people expect.  We should just defer to
tradition when the choice isn't important (it's getting to be a very bike
shed thread).

Somewhat relatedly, what is the plan for past and future argparse releases?
Michael Foord for instance is releasing unittest improvements in parallel
under the name unittest2.  I believe there is strong disfavor with releasing
packages that overlap with the standard library, so continuing to release
argparse under the name argparse will cause problems.  I would hate to see
release complications or confusions keep argparse from seeing future
development.

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

Re: [Python-Dev] Python 2.7b1 and argparse's version action

[Barry Warsaw]

On Apr 18, 2010, at 07:30 PM, Eric Smith wrote:

>Steven Bethard wrote:
>> By the way, we could simplify the typical add_argument usage by adding
>> "show program's version number and exit" as the default help for the
>> 'version' action. Then you should just write:
>> 
>> parser.add_argument('--version', action='version', version='> version>')
>
>I like this the best. I don't like argparse adding arguments for me.

I concur.  This gives me all the flexibility I need to make my programs accept
exactly the arguments I want and print exactly the information I want to
present.

-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 2.7b1 and argparse's version action

[Ben Finney]

Tobias Herp  writes:

> Steven Bethard schrieb:
> > On Sun, Apr 18, 2010 at 3:52 PM, Antoine Pitrou  wrote:
> >> Steven Bethard  gmail.com> writes:
> >>> Note that even though I agree with you that "-v/--version" is
> >>> probably not the best choice, in the poll[2] 11% of people still
> >>> wanted this.
> >>
> >> This strikes me as a small minority.
> > 
> > Agreed, but it's also the current behavior, ...
>
> The current /broken, non-standard/ behaviour.

I think that is overstating your case.

Steven is pointing out the fact that “default to ‘-v’ and ‘--version’”
is the current behaviour for argparse. It's also a fact that argparse,
as a third-party library, has an existing user base, and changing this
behaviour incompatibly is not something to do lightly.

To call this behaviour “broken” is a stretch too far, IMO. It does break
compatibility with optparse, but it's not *inherently* broken as the
above would imply.

Nor is there really a standard for this behaviour to be measured
“non-standard”. At best, there is a strong convention among Unix
command-line programs of ‘--version’ for a version action and ‘-v’ for
enabling verbose output. But that convention is not normative, so it's
too much to call it a standard IMO.

> I have collected lots of examples of widely used programs and their
> options. The only example of '-v', '--verbose' is argparse.

I'm not sure what programs you're talking about (argparse is a library,
not a program that can be run by itself), but in a brief search of my
system I've found several programs that use ‘-v’ for a version action,
including among others:

* Info-ZIP's ‘zip’ and ‘unzip’
* GNU ‘fdisk’
* Vim's ‘xxd’
* W3C's ‘tidy’

These are certainly widely deployed, although they may not be widely
familiar.

I do agree that such programs are a small minority, but it's overstating
your case to call them “non-standard”, since there's no standard for
this, or “broken”, since they demonstrably work fine. Rather, they buck
what is certainly a firm convention to avoid ‘-v’ for a version option.

I'm certainly in favour of preserving that convention by avoiding use of
‘-v’ for version. I would rather, though, that the discussion remain
aware of facts and not descend into hyperbole.

-- 
 \“Perchance you who pronounce my sentence are in greater fear |
  `\   than I who receive it.” —Giordano Bruno, burned at the stake by |
_o__)  the Catholic church for the heresy of heliocentrism, 1600-02-16 |
Ben Finney

___
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 2.7b1 and argparse's version action

[Steve Holden]

Cameron Simpson wrote:
> On 18Apr2010 22:52, Antoine Pitrou  wrote:
> | Steven Bethard  gmail.com> writes:
> | > I
> | > need to a see a consensus from a variety of developers that
> | > "--version" is the right answer, and not "-V/--version", etc.
> | 
> | Both are ok for me. "-v" as a shortcut for "--version" looks wrong, though.
> | "-v" is almost always used for verbosity these days.
> 
> My view is the same.

I don't expect -v to be one or the other, and I certainly don't expect
the rest of the world to want to confirm to what the Python community
decides.

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
See PyCon Talks from Atlanta 2010  http://pycon.blip.tv/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS:http://holdenweb.eventbrite.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.7b1 and argparse's version action

[Ron Adam]

On 04/18/2010 05:57 PM, Nick Coghlan wrote:

Steven Bethard wrote:

By the way, we could simplify the typical add_argument usage by adding
"show program's version number and exit" as the default help for the
'version' action. Then you should just write:

 parser.add_argument('--version', action='version', version='')


With that change, I would have no problem with the current argparse
behaviour (since doing it this way makes it very easy for people to add
a "-V" shortcut if they want one).



+1   This sounds good to me also.


Note that the python interpreter uses -V and --version.

r...@gutsy:~$ python3.1 -V
Python 3.1.2
r...@gutsy:~$ python3.1 --version
Python 3.1.2

And -v is used as follows:

-v : verbose (trace import statements); also PYTHONVERBOSE=x
 can be supplied multiple times to increase verbosity

Ron





___
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 2.7b1 and argparse's version action

[Ron Adam]

On 04/18/2010 06:35 PM, Nick Coghlan wrote:

Steven Bethard wrote:

On Sun, Apr 18, 2010 at 3:57 PM, Nick Coghlan  wrote:

Steven Bethard wrote:

By the way, we could simplify the typical add_argument usage by adding
"show program's version number and exit" as the default help for the
'version' action. Then you should just write:

 parser.add_argument('--version', action='version', version='')

With that change, I would have no problem with the current argparse
behaviour (since doing it this way makes it very easy for people to add
a "-V" shortcut if they want one).


Probably this should happen regardless of the outcome of the
constructor argument. The only reason it wasn't already there is that
I hadn't thought of it. ;-)


Crazy thought... would it make sense to have the following implicitly
use "--version" as the option flag:

   parser.add_argument(action='version', version='')

There are two things about the explicit '--version' that bother me:
1. It reduces the automatic provision of "standard" option spellings


I think any non standard spellings will either be on purpose or be caught 
fairly quickly.  And in either case I can't imagine it having an impact on 
the rest of the program, so I wouldn't worry about this too much.




2. The repetition in reading/writing 'version' 3 times is kind of annoying


Ahh, but it isn't the same exact 'version' each time.  One is an input 
specifier string, one is an action key, and the last is a value name.




(Probably a bad idea, since adding "-V" would mean having to add
"--version" as well, but figured it was worth mentioning).


I agree. Even though it may seem redundant when writing it, it's both clear 
and explicit when reading it even if you aren't very familiar with how 
argparse works, or have just returned from a really long and fun vacation. ;-)


Ron





___
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 2.7b1 and argparse's version action

[Martin v. Löwis]

> - many optparse programs use the version argument
> - many other programmers find this feature very convenient
> - dropping or deprecating this is a totally unnecessary change
>   (I have not read a single real reason /why/ this should be done).

You actually brought up a good reason yourself:

In the face of ambiguity, refuse the temptation to guess.

If you ask "give me a version argument", the question is "how is it
spelled?". IIUC, you originally complained that the spelling of argparse
(i.e. -v/--version) is not good, and that a different spelling should be
used. So it's ambiguous, in which case the feature shouldn't be provided
in the first place.

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 2.7b1 and argparse's version action

[Steven Bethard]

On Sun, Apr 18, 2010 at 4:35 PM, Nick Coghlan  wrote:
> Steven Bethard wrote:
>> On Sun, Apr 18, 2010 at 3:57 PM, Nick Coghlan  wrote:
>>> Steven Bethard wrote:
 By the way, we could simplify the typical add_argument usage by adding
 "show program's version number and exit" as the default help for the
 'version' action. Then you should just write:

     parser.add_argument('--version', action='version', version='>>> version>')
>>> With that change, I would have no problem with the current argparse
>>> behaviour (since doing it this way makes it very easy for people to add
>>> a "-V" shortcut if they want one).
>>
>> Probably this should happen regardless of the outcome of the
>> constructor argument. The only reason it wasn't already there is that
>> I hadn't thought of it. ;-)
>
> Crazy thought... would it make sense to have the following implicitly
> use "--version" as the option flag:
>
>  parser.add_argument(action='version', version='')

It would be possible, but not simple. The main drawback is that it
would have to be done in the parser code, and not in the VersionAction
class where all the other version behavior is. I think it's not a huge
gain over supplying the option strings, particularly if you're
following, say, the Python executable conventions:

  parser.add_argument('-V', action='version', version='')

Steve
-- 
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
___
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 2.7b1 and argparse's version action

[Steven Bethard]

On Sun, Apr 18, 2010 at 6:40 PM, Nick Coghlan  wrote:
> Note there are two changes I believe should be made to the argparse
> documentation for 2.7 though:
> - the '--version' example should either not use a shorthand, or should
> use the conventional '-V'
> - this issue needs to be mentioned in the section on migrating from
> optparse.

Thanks for pointing these out. I'll make a note to fix these when I
fix the default help value.

Steve
-- 
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
___
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 2.7b1 and argparse's version action

[Steven Bethard]

On Sun, Apr 18, 2010 at 7:02 PM, Ian Bicking  wrote:
> Somewhat relatedly, what is the plan for past and future argparse releases?

I currently don't have any plans to make releases outside of the main
Python releases. Perhaps if there's great demand for it, I'll
reconsider, but as it is, I haven't had as much time as I would like
for argparse, and managing two different types of releases is probably
unrealistic for me at the moment.

Steve
-- 
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
___
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] Bug? syslog.openlog using ident "python" by default.

[Sean Reifschneider]

I've implemented this and put the patch in Issue8451:

   http://bugs.python.org/issue8451

I'm happy with how it is now, including documentation, but would like some
review.

Thanks,
Sean
-- 
Sean Reifschneider, Member of Technical Staff 
tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability



signature.asc
Description: OpenPGP digital 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