On Mon, Feb 21, 2011 at 1:52 PM, Nick Coghlan ncogh...@gmail.com wrote:
As the subject line asks, is there anything preventing the following
PEPs from being marked Final?
SA 389 argparse - New Command Line Parsing Module Bethard
Sorry for taking forever to get back to this. So
I think the easiest and most sensible way to address
http://bugs.python.org/issue9353 is to simply remove the __all__
definition from argparse - everything that doesn't start with an
underscore in the module is already meant to be exposed.
But then I wonder - is __all__ considered part of the
On Mon, Nov 1, 2010 at 2:53 PM, Michael Foord fuzzy...@voidspace.org.uk wrote:
On 01/11/2010 14:48, Steven Bethard wrote:
I think the easiest and most sensible way to address
http://bugs.python.org/issue9353 is to simply remove the __all__
definition from argparse - everything that doesn't
On Mon, Nov 1, 2010 at 2:57 PM, Guido van Rossum gu...@python.org wrote:
On Mon, Nov 1, 2010 at 7:53 AM, Michael Foord fuzzy...@voidspace.org.uk
wrote:
On 01/11/2010 14:48, Steven Bethard wrote:
But then I wonder - is __all__ considered part of the public API of a
module? Or is it okay
On Tue, Sep 21, 2010 at 3:46 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
I agree. Don't feel strongly about it though. (I'm sure Strunk and White
would disapprove.)
No doubt.
http://chronicle.com/article/50-Years-of-Stupid-Grammar/25497
;-)
Steve
--
Where did you get that
Before I go and add about 30 open issues to the Python tracker, I
figured I should ask. What's the normal process for the bug trackers
of modules that move to the standard library? I have a few feature
requests, etc. for argparse, and I was planning to just copy them over
to the Python bug tracker
Sorry I haven't had time to get around to the argparse issues. I
should have time this weekend. I need a release manager call on one of
the issues though. Two things I assume are fine to fix at this stage:
* In the documentation, the '--version' example should either not use
a shorthand, or
On Wed, Apr 21, 2010 at 2:14 AM, Jon Ribbens
jon+python-...@unequivocal.co.uk wrote:
On Wed, Apr 21, 2010 at 03:53:16AM -0400, Eric Smith wrote:
I agree the new behavior is desirable. And I also think it should be the
default, although I feel less strongly about that.
But since this behavior
On Tue, Apr 20, 2010 at 11:55 AM, Neal Becker ndbeck...@gmail.com wrote:
I've noticed argparse ambiguity handling has changed a bit over last few
revisions.
I have cases where 1 valid input is a prefix of another:
e.g.:
'--string'
'--string2'
With the most recent 1.1, the behavior is:
On Mon, Apr 19, 2010 at 12:51 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
On 19/04/2010 21:19, Scott Dial wrote:
Is consensus superficial?
No, but it isn't always possible or necessary. In general the maintainer of
a module should make the best decision, not the one with the most
On Sun, Apr 18, 2010 at 3:31 AM, Tobias Herp tobias.h...@gmx.de 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
On Sun, Apr 18, 2010 at 4:03 AM, Nick Coghlan ncogh...@gmail.com 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
On Sun, Apr 18, 2010 at 3:57 PM, Nick Coghlan ncogh...@gmail.com 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
On Sun, Apr 18, 2010 at 3:52 PM, Antoine Pitrou solip...@pitrou.net wrote:
Steven Bethard steven.bethard at 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
On Sun, Apr 18, 2010 at 4:35 PM, Nick Coghlan ncogh...@gmail.com wrote:
Steven Bethard wrote:
On Sun, Apr 18, 2010 at 3:57 PM, Nick Coghlan ncogh...@gmail.com wrote:
Steven Bethard wrote:
By the way, we could simplify the typical add_argument usage by adding
show program's version number
On Sun, Apr 18, 2010 at 6:40 PM, Nick Coghlan ncogh...@gmail.com 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
On Sun, Apr 18, 2010 at 7:02 PM, Ian Bicking i...@colorstudy.com 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
On Wed, Mar 24, 2010 at 1:42 AM, Amaury Forgeot d'Arc
amaur...@gmail.com wrote:
I noticed that the newly added argparse module has an unusual
licence header, included below. This is the only file in the Python tree
that contains an explicit reference to the Apache License,
and this leads me to
On Sun, Mar 7, 2010 at 11:49 AM, Guido van Rossum gu...@python.org wrote:
On Sun, Mar 7, 2010 at 4:29 AM, Neal Becker ndbeck...@gmail.com wrote:
Brian Curtin wrote:
On Fri, Mar 5, 2010 at 12:51, Neal Becker ndbeck...@gmail.com wrote:
I generally enjoy argparse, but one thing I find rather
On Mon, Mar 8, 2010 at 7:40 AM, Steven Bethard steven.beth...@gmail.com wrote:
On Sun, Mar 7, 2010 at 11:49 AM, Guido van Rossum gu...@python.org wrote:
On Sun, Mar 7, 2010 at 4:29 AM, Neal Becker ndbeck...@gmail.com wrote:
Brian Curtin wrote:
On Fri, Mar 5, 2010 at 12:51, Neal Becker ndbeck
On Fri, Mar 5, 2010 at 10:51 AM, Neal Becker ndbeck...@gmail.com wrote:
I generally enjoy argparse, but one thing I find rather
ugly and unpythonic.
parser.add_argument ('--plot', action='store_true')
Specifying the argument 'action' as a string is IMO ugly.
If it really bothers you, you
Thanks all for the updates. Sorry I can't make it to PyCon this year!
On Sun, Feb 21, 2010 at 1:30 AM, Eric Smith e...@trueblade.com wrote:
There was also a quick discussion on maybe implementing optparse using
argparse, then getting rid of the existing optparse.
I think the PEP pretty much
On Sun, Feb 21, 2010 at 10:31 AM, Guido van Rossum gu...@python.org wrote:
On Sun, Feb 21, 2010 at 1:26 PM, Steven Bethard steven.beth...@gmail.com
wrote:
So basically do what the PEP does now, except don't remove optparse in
Python 3.5? For reference, the current proposal is:
* Python 2.7
On Fri, Feb 19, 2010 at 7:50 AM, Brett Cannon br...@python.org wrote:
My notes from the session I led:
+ argparse
- Same issues brought up.
For those of us not at PyCon, what were the issues?
Steve
--
Where did you get that preposterous hypothesis?
Did Steve tell you that?
---
On Mon, Jan 11, 2010 at 4:11 PM, Barry Warsaw ba...@python.org wrote:
As an example, the one library I've already ported used a metaclass. I don't
see any way to specify that the metaclass should be used in a portable way.
In Python 2.6 it's:
class Foo:
__metaclass__ = Meta
and in
On Sun, Dec 27, 2009 at 9:51 AM, anatoly techtonik techto...@gmail.com wrote:
On Tue, Dec 15, 2009 at 12:37 AM, Steven Bethard
steven.beth...@gmail.com wrote:
If you're only concerned about 2.X, then yes, optparse will *never* be
removed from 2.X. There will be a deprecation note in the 2.X
On Tue, Dec 15, 2009 at 4:33 AM, Neal Becker ndbeck...@gmail.com wrote:
Ian Bicking wrote:
If argparse doesn't do this, then I think at least it should give good
error messages for all cases where these optparse-isms remain. For
instance, now if you include %prog in your usage you get:
So there wasn't really any more feedback on the last post of the
argparse PEP other than a typo fix and another +1.
http://www.python.org/dev/peps/pep-0389/
Can I get a pronouncement? Here's a summary of the responses. (Please
correct me if I misinterpreted anyone.)
* Floris Bruynooghe +1
*
On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking i...@colorstudy.com wrote:
On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard
steven.beth...@gmail.com wrote:
So there wasn't really any more feedback on the last post of the
argparse PEP other than a typo fix and another +1.
I just converted
On Mon, Dec 14, 2009 at 11:35 AM, Olemis Lang ole...@gmail.com wrote:
On Mon, Dec 14, 2009 at 2:11 PM, Michael Foord
On 14/12/2009 19:04, Ian Bicking wrote:
Another thing I just noticed is that argparse using -v for version
where optparse does not (it only adds --version); most of my scripts
On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang ole...@gmail.com wrote:
I thought that one of the following approaches would be considered :
- let optparse remain in stdlib (as is or not ...)
- re-implement optparse (i.e. a module having the same name ;o) using
argparse
isn't it ?
On Mon, Dec 14, 2009 at 1:10 PM, Olemis Lang ole...@gmail.com wrote:
On Mon, Dec 14, 2009 at 3:46 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang ole...@gmail.com wrote:
I thought that one of the following approaches would be considered :
1 - let
On Mon, Dec 14, 2009 at 4:16 PM, sstein...@gmail.com
sstein...@gmail.com wrote:
On Dec 14, 2009, at 2:37 PM, Antoine Pitrou wrote:
Michael Foord fuzzyman at voidspace.org.uk writes:
I also use -v for verbose in a few scripts (including options to
unittest when run with python -m). I've seen
On Tue, Nov 3, 2009 at 4:55 AM, Barry Warsaw ba...@python.org wrote:
I'd like to read some case studies of people who have migrated applications
from 2.6 to 3.0.
For what it's worth, it was pretty easy to migrate argparse:
http://code.google.com/p/argparse/source/detail?r=12
It was mostly
On Tue, Nov 3, 2009 at 6:14 AM, Daniel Stutzbach
dan...@stutzbachenterprises.com wrote:
It's pretty easy to make Python source that works under 2.6 and 3.x. It's
basically impossible to make Python source that works under 2.4/2.5 and
3.x.
This keeps getting quoted later in the thread so I
--
PEP: 389
Title: argparse - new command line parsing module
Version: $Revision: 75674 $
Last-Modified: $Date: 2009-10-24 12:01:49 -0700 (Sat, 24 Oct 2009) $
Author: Steven Bethard steven.beth...@gmail.com
Status: Draft
Type: Standards Track
Content
On Sat, Oct 24, 2009 at 4:34 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Steven Bethard steven.beth...@gmail.com writes:
Discussion: sys.err and sys.exit
There were some concerns that argparse by default always writes to
``sys.err``
[…]
Unless, I'm
On Tue, Oct 20, 2009 at 7:44 PM, David Cournapeau courn...@gmail.com wrote:
On Wed, Oct 21, 2009 at 5:49 AM, Paul Moore p.f.mo...@gmail.com wrote:
2009/10/20 Chris Withers ch...@simplistix.co.uk:
There are many (I believe) Windows users for whom bdist_wininst is
just what they want. For those
On Sun, Oct 11, 2009 at 9:52 AM, Paul Moore p.f.mo...@gmail.com wrote:
2009/10/9 Michael Foord fuzzy...@voidspace.org.uk:
Many Windows users would be quite happy if the standard mechanism for
installing non-source distributions on Windows was via the wininst binaries.
+1 I'm one of those
On Sat, Oct 3, 2009 at 3:45 AM, Yuvgoog Greenle ubershme...@gmail.com wrote:
I haven't checked if it's possible, but I suggest Argparse have it's
own exception class that inherits from SystemExit and that exception
would be thrown.
ParseError, or something similar.
I suggest this just
I thought it might be useful for those who don't have time to read a
million posts to have a summary of what's happened in the formatting
discussion.
The basic problem is that many APIs in the standard library and
elsewhere support only %-formatting and not {}-formatting, e.g.
logging.Formatter
On Sat, Oct 3, 2009 at 8:17 AM, Michael Foord fuzzy...@voidspace.org.uk wrote:
Steven Bethard wrote:
On Sat, Oct 3, 2009 at 3:45 AM, Yuvgoog Greenle ubershme...@gmail.com
wrote:
I haven't checked if it's possible, but I suggest Argparse have it's
own exception class that inherits from
On Thu, Oct 1, 2009 at 10:49 PM, Terry Reedy tjre...@udel.edu wrote:
As someone who likes .format() and who already uses such bound methods to
print, such as in
emsg = format
...
if c: print(emsg(arg, barg))
I find this **MUCH** preferable to the ugly and seemingly unnecessary
On Fri, Oct 2, 2009 at 2:34 AM, Antoine Pitrou solip...@pitrou.net wrote:
Steven Bethard steven.bethard at gmail.com writes:
But it's not much of a transition plan. Or are you suggesting:
The question is why we want a transition plan that will bother everyone with
no
tangible benefits
On Fri, Oct 2, 2009 at 12:43 PM, Martin Geisler m...@lazybytes.net wrote:
I hate calling methods on string literals, I think it looks very odd to
have code like this:
Displaying {0} of {1} revisions.format(x, y)
Will we be able to write this as
Displaying {0} of {1} revisions % (x, y)
On Fri, Oct 2, 2009 at 11:56 AM, Raymond Hettinger pyt...@rcn.com wrote:
[Steven Bethard]
Just saying ok, switch your format strings
from % to {} didn't work in Python 3.0 for various good reasons, and
I can't imagine it will work in Python 4.0 unless we have a transition
plan.
Do the users
On Thu, Oct 1, 2009 at 11:03 AM, Brett Cannon br...@python.org wrote:
So I created this last night:
import collections
class braces_fmt(str):
def __mod__(self, stuff):
if isinstance(stuff, tuple):
return self.__class__(self.format(*stuff))
elif
On Thu, Oct 1, 2009 at 4:35 PM, Brett Cannon br...@python.org wrote:
On Thu, Oct 1, 2009 at 15:19, Steven Bethard steven.beth...@gmail.com wrote:
On Thu, Oct 1, 2009 at 11:03 AM, Brett Cannon br...@python.org wrote:
class braces_fmt(str):
def __mod__(self, stuff):
if isinstance
On Tue, Sep 29, 2009 at 10:04 PM, James Y Knight f...@fuhm.net wrote:
It'd possibly be helpful if there were builtin objects which forced the
format style to be either newstyle or oldstyle, independent of whether % or
format was called on it.
E.g.
x = newstyle_formatstr({} {} {})
x %
On Wed, Sep 30, 2009 at 5:21 AM, Barry Warsaw ba...@python.org wrote:
On Sep 29, 2009, at 11:15 PM, Martin v. Löwis wrote:
I would propose that the format argument gets an argument name,
according to the syntax it is written in. For PEP 3101 format,
I would call the argument format (like the
On Wed, Sep 30, 2009 at 8:31 AM, Barry Warsaw ba...@python.org wrote:
On Sep 30, 2009, at 11:22 AM, Steven Bethard wrote:
On Wed, Sep 30, 2009 at 5:21 AM, Barry Warsaw ba...@python.org wrote:
On Sep 29, 2009, at 11:15 PM, Martin v. Löwis wrote:
I would propose that the format argument gets
On Wed, Sep 30, 2009 at 8:50 AM, Barry Warsaw ba...@python.org wrote:
On Sep 30, 2009, at 11:39 AM, Steven Bethard wrote:
Thanks for the clarification. I generally like this approach, though
it's not so convenient for argparse which already takes format strings
like this::
parser
On Wed, Sep 30, 2009 at 1:17 PM, Andrew McNabb amcn...@mcnabbs.org wrote:
From my cursory reading of the documentation, it looks like argparse can
only add subparsers for subcommands. Is there any way to add subparsers
based on options instead (as iptables does)?
Currently this is not
On Tue, Sep 29, 2009 at 1:31 PM, Paul Moore p.f.mo...@gmail.com wrote:
2009/9/28 Yuvgoog Greenle ubershme...@gmail.com:
1. There is no chance of the script killing itself. In argparse and optparse
exit() is called on every parsing error (btw because of this it sucks to
debug parse_args in an
On Tue, Sep 29, 2009 at 3:04 PM, Glenn Linderman v+pyt...@g.nevcal.com wrote:
On approximately 9/29/2009 1:57 PM, came the following characters from the
keyboard of Steven Bethard:
If you're not using argparse to write command line applications, then
I don't feel bad if you have to do a tiny
There's a lot of code already out there (in the standard library and
other places) that uses %-style formatting, when in Python 3.0 we
should be encouraging {}-style formatting. We should really provide
some sort of transition plan. Consider an example from the logging
docs:
On Tue, Sep 29, 2009 at 5:54 PM, Benjamin Peterson benja...@python.org wrote:
* Provide a flag to Formatter which controls whether new or old
formatting is used. Emit a warning when it's not true.
So then the transition strategy is something like:
version N: Add formatting flag which uses
On Tue, Sep 29, 2009 at 6:18 PM, Nick Coghlan ncogh...@gmail.com wrote:
Keeping getopt around *and* including a add_getopt_arguments method in
argparse is probably the best of both worlds, in that it allows for
relatively straightforward evolution of an application:
1. Start with getopt
2.
On Tue, Sep 29, 2009 at 8:15 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Steven Bethard wrote:
Consider an example from the logging
docs:
logging.Formatter(%(asctime)s - %(name)s - %(levelname)s - %(message)s)
We'd like to support both this style as well as the following style
On Sun, Sep 27, 2009 at 8:49 PM, Benjamin Peterson benja...@python.org wrote:
2009/9/27 Steven Bethard steven.beth...@gmail.com:
On Sun, Sep 27, 2009 at 8:41 PM, Benjamin Peterson benja...@python.org
wrote:
2009/9/27 Steven Bethard steven.beth...@gmail.com:
The first release where any real
On Mon, Sep 28, 2009 at 6:03 AM, Jon Ribbens
jon+python-...@unequivocal.co.uk wrote:
On Mon, Sep 28, 2009 at 09:38:20AM +0100, Floris Bruynooghe wrote:
On Mon, Sep 28, 2009 at 06:59:45AM +0300, Yuvgoog Greenle wrote:
-1 for deprecating getopt. getopt is super-simple and especially useful for
On Mon, Sep 28, 2009 at 4:09 AM, Neal Becker ndbeck...@gmail.com wrote:
If the plan is to migrate from optparse to argparse, this could be made a
bit easier. If it weren't for the fact that some names are different in
argparse than optparse, I believe many optparse usages could port with no
On Mon, Sep 28, 2009 at 8:26 AM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
m h wrote:
Perhaps this is OT, but since command line parsing is part of
configuration, I figure I'd throw it out there. My scripts often have
configuration that the command line can override and I loosely follow
On Mon, Sep 28, 2009 at 8:27 AM, Steven D'Aprano st...@pearwood.info wrote:
On Tue, 29 Sep 2009 12:28:39 am Steven Bethard wrote:
* Would you like argparse to grow an add_getopt_arguments method (as
in my other post)?
0
* If argparse grew an add_getopt_arguments, would you still want
On Mon, Sep 28, 2009 at 12:22 PM, Brett Cannon br...@python.org wrote:
On Mon, Sep 28, 2009 at 08:49, Steven Bethard steven.beth...@gmail.com
wrote:
On Mon, Sep 28, 2009 at 8:27 AM, Steven D'Aprano st...@pearwood.info wrote:
On Tue, 29 Sep 2009 12:28:39 am Steven Bethard wrote:
* Would you
On Mon, Sep 28, 2009 at 8:44 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Let's take ``getopt.getopt(sys.argv[1:], a:b, [alpha=, beta])``
As Yuvgoog Greenle says, the canonical getopt way is to write
[snip getopt code]
Even though this is many more lines, I prefer it over
optparse/argparse:
/
--
PEP: 389
Title: argparse - new command line parsing module
Version: $Revision: 75097 $
Last-Modified: $Date: 2009-09-27 12:42:40 -0700 (Sun, 27 Sep 2009) $
Author: Steven Bethard steven.beth...@gmail.com
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 25-Sep-2009
Python
On Sun, Sep 27, 2009 at 5:51 PM, Antoine Pitrou solip...@pitrou.net wrote:
I am neutral on the idea of adding argparse. However, I'm -1 on deprecating
optparse. It is very widely used (tons of scripts use it), and ok for many
uses;
deprecating it is totally unhelpful and gratuitous.
Could
On Sun, Sep 27, 2009 at 8:08 PM, Benjamin Peterson benja...@python.org wrote:
2009/9/27 Steven Bethard steven.beth...@gmail.com:
If you think getopt and optparse should stick around in 3.X, why is
that? If you think there are things that getopt and optparse do better
than argparse, could you
On Sun, Sep 27, 2009 at 8:41 PM, Benjamin Peterson benja...@python.org wrote:
2009/9/27 Steven Bethard steven.beth...@gmail.com:
The first release where any real deprecation message would show up is
Python 3.4, more than 3 years away. If you think 3 years isn't long
enough for people
On Sun, Sep 27, 2009 at 9:09 PM, Martin v. Löwis mar...@v.loewis.de wrote:
If you think getopt and optparse should stick around in 3.X, why is
that? If you think there are things that getopt and optparse do better
than argparse, could you please give some examples?
I personally consider
On Sun, Jun 21, 2009 at 1:36 PM, Jerry Chenj...@3rdengine.com wrote:
QUICK EXAMPLES
{} {} {} @ (1, 2, 3)
'1 2 3'
foo {qux} baz @ {qux: bar}
'foo bar baz'
One of the main complaints of a binary operator in PEP 3101 was the
inability to mix named and unnamed arguments:
On Sun, Apr 19, 2009 at 1:38 AM, Mart Sõmermaa mrts.py...@gmail.com wrote:
On Sun, Apr 19, 2009 at 2:06 AM, Nick Coghlan ncogh...@gmail.com wrote:
That said, I'm starting to wonder if an even better option may be to
just drop the kwargs support from the function and require people to
always
On Sat, Apr 18, 2009 at 9:37 PM, Nick Coghlan ncogh...@gmail.com wrote:
Steven Bethard wrote:
On Sat, Apr 18, 2009 at 8:14 PM, Benjamin Peterson benja...@python.org
wrote:
2009/4/18 Nick Coghlan ncogh...@gmail.com:
I see a few options:
1. Abandon the python name for the 3.x series
On Sat, Apr 18, 2009 at 10:04 PM, Nick Coghlan ncogh...@gmail.com wrote:
Steven Bethard wrote:
On Sat, Apr 18, 2009 at 9:37 PM, Nick Coghlan ncogh...@gmail.com wrote:
Note that such an approach would then require an altaltinstall command
in order to be able to install a specific version
On Mon, Apr 13, 2009 at 2:29 AM, Mart Sõmermaa mrts.py...@gmail.com wrote:
On Mon, Apr 13, 2009 at 12:56 AM, Antoine Pitrou solip...@pitrou.net
wrote:
Mart Sõmermaa mrts.pydev at gmail.com writes:
Proposal: add add_query_params() for appending query parameters to an
URL to
On Mon, Apr 13, 2009 at 1:14 PM, Mart Sõmermaa mrts.py...@gmail.com wrote:
On Mon, Apr 13, 2009 at 8:23 PM, Steven Bethard steven.beth...@gmail.com
wrote:
On Mon, Apr 13, 2009 at 2:29 AM, Mart Sõmermaa mrts.py...@gmail.com wrote:
As for the duplicate handling, I've implemented a threefold
On Wed, Mar 25, 2009 at 7:08 AM, Paul Moore p.f.mo...@gmail.com wrote:
I use Python for systems admin scripts, Windows services, and database
management. In my experience (and I agree, it's only one, limited, use
case) availability of download-and-run bdist_wininst installers for
every package
On Mon, Mar 16, 2009 at 11:06 AM, Guido van Rossum gu...@python.org wrote:
Moreover, since the main use case seems to be fixing a corner case of
the nested() context manager, perhaps the effort towards changing the
language would be better directed towards supporting with a, b: as a
shorthand
On Sun, Mar 15, 2009 at 10:50 AM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
Brett Cannon wrote:
Without knowing what StatementSkipped is (just some singleton? If so why
not just used SkipStatement instance that was raised?) and wondering if we
are just going to continue to adding control
On Wed, Feb 25, 2009 at 4:24 AM, Nick Coghlan ncogh...@gmail.com wrote:
An interesting discrepancy [1] has been noted when comparing
contextlib.nested (and contextlib.contextmanager) with the equivalent
nested with statements.
Specifically, the following examples behave differently if
On Mon, Feb 23, 2009 at 04:02, Nick Coghlan ncogh...@gmail.com wrote:
For example, a version that allows any number of extension modules to be
suppressed when importing a module (defaulting to the Foo/_Foo naming):
import sys
def import_python_only(mod_name, *ext_names):
if not
On Mon, Feb 23, 2009 at 12:10 PM, tav t...@espians.com wrote:
Hey all,
As an attempt to convince everyone of the merits of my functions-based
approach to security, I've come up with a simple challenge. I've
attached it as safelite.py
The challenge is simple:
* Open a fresh Python
On Fri, Feb 20, 2009 at 1:45 PM, Brett Cannon br...@python.org wrote:
But there is another issue with this: the pure Python code will never call
the extension code because the globals will be bound to _pypickle and not
_pickle. So if you have something like::
# _pypickle
def A(): return
On Sat, Feb 21, 2009 at 1:11 PM, Paul Moore p.f.mo...@gmail.com wrote:
PS Just for my own information, am I correct in thinking that it is
*only* Bazaar in the (D)VCS world that has this problem, to any real
extent? I know old Mercurial clients can interact with newer servers
(ie, the wire
On Wed, Feb 18, 2009 at 2:32 PM, Sebastian Rittau
srit...@jroger.in-berlin.de wrote:
Hi!
I am curious why the following will not work in Python:
class foo(object):
def bar(self):
print self.attr
class duck(object):
attr = 3.14
foo.bar(duck())
Is it a design
On Wed, Feb 4, 2009 at 10:25 AM, Brett Cannon br...@python.org wrote:
On Wed, Feb 4, 2009 at 05:35, Hrvoje Niksic hrvoje.nik...@avl.com wrote:
Andrew Bennetts wrote:
A patch to add operator.caller(*args, **kwargs) may be a good idea. Your
example would then be:
map(operator.caller(),
On Wed, Feb 4, 2009 at 10:50 AM, Brett Cannon br...@python.org wrote:
On Wed, Feb 4, 2009 at 10:43, Steven Bethard steven.beth...@gmail.com wrote:
Not sure I follow you here. It's not the __init__ that allows you to
do ``x()``, it's the fact that the class declares a __call__, right?
class C
On Wed, Jan 28, 2009 at 10:29 AM, Martin v. Löwis mar...@v.loewis.de wrote:
Notice that the determination of the specific encoding used is fairly
elaborate:
- if IO is to a terminal, Python tries to determine the encoding of
the terminal. This is mostly relevant for Windows (which uses,
by
On Fri, Jan 23, 2009 at 12:06 PM, Martin v. Löwis mar...@v.loewis.de wrote:
import random
print(random.choice('svn', 'bzr', 'hg', 'git'))
Nice! So it's bzr, as my machine just told me (after adding
the square brackets).
Wow, that decision was a lot easier than I thought it would be.
On Mon, Jan 19, 2009 at 7:10 AM, Gerald Britton
gerald.brit...@gmail.com wrote:
PEP: 3142
Title: Add a while clause to generator expressions
[snip]
numbers in that range. Allowing for a while clause would allow
the redundant tests to be short-circuited:
g = (n for n in range(100)
On Mon, Sep 29, 2008 at 6:07 AM, Victor Stinner
[EMAIL PROTECTED] wrote:
The default behaviour should be to use unicode and raise an error if
conversion to unicode fails. It should also be possible to use bytes using
bytes arguments and optional arguments (for getcwd).
- listdir(unicode) -
On Mon, Aug 25, 2008 at 11:30 AM, Barry Warsaw [EMAIL PROTECTED] wrote:
On Aug 25, 2008, at 1:13 PM, Guido van Rossum wrote:
Several people at Google seem to have independently discovered that
despite all of the platform-independent goodness in subprocess.py, you
still need to be platform
On Tue, Apr 22, 2008 at 1:56 AM, Tarek Ziadé [EMAIL PROTECTED] wrote:
On Mon, Apr 21, 2008 at 2:25 AM, Steven Bethard [EMAIL PROTECTED] wrote:
On Sun, Apr 20, 2008 at 4:15 PM, Tarek Ziadé [EMAIL PROTECTED] wrote:
I have submitted a patch for review here:
http://bugs.python.org/issue2663
On Wed, Apr 9, 2008 at 4:48 PM, Paul Moore [EMAIL PROTECTED] wrote:
On 09/04/2008, Phillip J. Eby [EMAIL PROTECTED] wrote:
It would be, if .eggs were a packaging format, rather than a binary
distribution/runtime format.
Remember eggs are to Python as jars are to Java -- a Java .jar
On Thu, Apr 3, 2008 at 3:09 PM, Terry Reedy [EMAIL PROTECTED] wrote:
Tim Golden [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| [re tests which fail because something's holding a file
| open with SHARE_DELETE]
There are a couple of things one can do in a directory's
On Tue, Apr 1, 2008 at 12:42 AM, Neal Norwitz [EMAIL PROTECTED] wrote:
The Windows buildbots are still failing because some tests keep files
opened. This causes subsequent tests which use the same file to fail.
Here is a recent run which had a failure early on:
On Tue, Apr 1, 2008 at 10:20 AM, Facundo Batista
[EMAIL PROTECTED] wrote:
2008/4/1, Tim Golden [EMAIL PROTECTED]:
If this is the thing to do, presumably test_support should
grow a remove_file which does something of this sort?
+1 (I was thinking exactly that).
+1 here too. That looks
On Sat, Mar 22, 2008 at 2:58 PM, Martin v. Löwis [EMAIL PROTECTED] wrote:
Steven Bethard wrote:
Right now, test_py3kwarn only runs if the test suite is run using the
-3 command line flag to Python. So for most regrtest runs (e.g. the
buildbots) this test will never be run
On Sun, Mar 23, 2008 at 3:02 PM, Martin v. Löwis wrote:
[talking about running the buildbots using the -3 flag to issue Py3K warnings]
Yes. I don't think it should be turned on regularly in the tests until
they regularly are quiet under -3.
So the plan is to silence all Py3K warnings in the
1 - 100 of 270 matches
Mail list logo
