On Mon, Feb 21, 2011 at 1:52 PM, Nick Coghlan 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 looked over
On Mon, Nov 1, 2010 at 2:57 PM, Guido van Rossum wrote:
> On Mon, Nov 1, 2010 at 7:53 AM, Michael Foord
> 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 to jus
On Mon, Nov 1, 2010 at 2:53 PM, Michael Foord 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
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 publ
On Tue, Sep 21, 2010 at 3:46 PM, Michael Foord
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 preposterous hypothesis?
Did Steve
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 should
On Wed, Apr 21, 2010 at 2:14 AM, Jon Ribbens
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 seems to be an accident
On Tue, Apr 20, 2010 at 11:55 AM, Neal Becker 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:
>
> --string
On Mon, Apr 19, 2010 at 12:51 PM, Michael Foord
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 backing.
> :-)
Yep, that
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
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 th
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 pr
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 stri
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
>> 've
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 &
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"
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
On Wed, Mar 24, 2010 at 10:08 AM, Brett Cannon wrote:
> On Wed, Mar 24, 2010 at 09:05, Steven Bethard
> wrote:
>> On Wed, Mar 24, 2010 at 1:42 AM, Amaury Forgeot d'Arc
>> wrote:
>> > I noticed that the newly added argparse module has an unusual
>> > li
On Wed, Mar 24, 2010 at 1:42 AM, Amaury Forgeot d'Arc
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 some questions
On Mon, Mar 8, 2010 at 7:40 AM, Steven Bethard wrote:
> On Sun, Mar 7, 2010 at 11:49 AM, Guido van Rossum wrote:
>> On Sun, Mar 7, 2010 at 4:29 AM, Neal Becker wrote:
>>> Brian Curtin wrote:
>>>
>>>> On Fri, Mar 5, 2010 at 12:51, Neal Becker wrote:
>
On Sun, Mar 7, 2010 at 11:49 AM, Guido van Rossum wrote:
> On Sun, Mar 7, 2010 at 4:29 AM, Neal Becker wrote:
>> Brian Curtin wrote:
>>
>>> On Fri, Mar 5, 2010 at 12:51, Neal Becker wrote:
>>>
I generally enjoy argparse, but one thing I find rather
ugly and unpythonic.
par
On Fri, Mar 5, 2010 at 10:51 AM, Neal Becker 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 can use:
On Sun, Feb 21, 2010 at 10:31 AM, Guido van Rossum wrote:
> On Sun, Feb 21, 2010 at 1:26 PM, Steven Bethard
> wrote:
>> So basically do what the PEP does now, except don't remove optparse in
>> Python 3.5? For reference, the current proposal is:
>>
>> * Py
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 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 already covers why
On Fri, Feb 19, 2010 at 7:50 AM, Brett Cannon 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?
--- The Hiphopopo
On Wed, Jan 13, 2010 at 9:40 AM, Ralf Schmitt wrote:
> "R. David Murray" writes:
>
>> Please review issue 2375 [1], which is an enhancement request to add a
>> PYTHON3PATH environment variable. Because we have elected to have both
>> a python and a python3 command, I think this is an issue worth
On Mon, Jan 11, 2010 at 4:11 PM, Barry Warsaw 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 Python 3 it's
On Sun, Dec 27, 2009 at 9:51 AM, anatoly techtonik wrote:
> On Tue, Dec 15, 2009 at 12:37 AM, Steven Bethard
> 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 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: ValueError:
>> unsu
On Mon, Dec 14, 2009 at 4:16 PM, sstein...@gmail.com
wrote:
>
> On Dec 14, 2009, at 2:37 PM, Antoine Pitrou wrote:
>
>> Michael Foord 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 -V as a common
On Mon, Dec 14, 2009 at 1:10 PM, Olemis Lang wrote:
> On Mon, Dec 14, 2009 at 3:46 PM, Nick Coghlan wrote:
>>> On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang wrote:
I thought that one of the following approaches would be considered :
1 - let optparse remain in stdlib (as is or not ...)
On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang 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 ?
Please read the
On Mon, Dec 14, 2009 at 11:35 AM, Olemis Lang 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
>>> that
On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking wrote:
> On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard
> 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 a scrip
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
* Br
On Tue, Nov 3, 2009 at 6:14 AM, Daniel Stutzbach
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 just wanted to say
again that th
On Tue, Nov 3, 2009 at 4:55 AM, Barry Warsaw 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 just adding a fe
On Sat, Oct 24, 2009 at 4:34 PM, Ben Finney wrote:
> Steven Bethard writes:
>
>> Discussion: sys.err and sys.exit
>>
>> There were some concerns that argparse by default always writes to
>> ``sys.err``
> […]
>
> Unless, I&#
se.
Steve
--
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
Status: Draft
Type: Standards Track
Content-Type: text/x-r
On Tue, Oct 20, 2009 at 7:44 PM, David Cournapeau wrote:
> On Wed, Oct 21, 2009 at 5:49 AM, Paul Moore wrote:
>> 2009/10/20 Chris Withers :
>> There are many (I believe) Windows users for whom bdist_wininst is
>> just what they want. For those people, where's the incentive to switch
>> in what yo
On Sun, Oct 11, 2009 at 9:52 AM, Paul Moore wrote:
> 2009/10/9 Michael Foord :
>> 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 people.
+1 on installing packages on Wind
On Sat, Oct 3, 2009 at 8:17 AM, Michael Foord wrote:
> Steven Bethard wrote:
>> On Sat, Oct 3, 2009 at 3:45 AM, Yuvgoog Greenle
>> wrote:
>>> I haven't checked if it's possible, but I suggest Argparse have it's
>>> own exception class that inherits
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 ac
On Sat, Oct 3, 2009 at 3:45 AM, Yuvgoog Greenle 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 because it would be
On Fri, Oct 2, 2009 at 11:56 AM, Raymond Hettinger 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 ha
On Fri, Oct 2, 2009 at 12:43 PM, Martin Geisler 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)
>
> too?
On Fri, Oct 2, 2009 at 2:34 AM, Antoine Pitrou wrote:
> Steven Bethard 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 be
On Thu, Oct 1, 2009 at 10:49 PM, Terry Reedy 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
> wrapper cla
On Thu, Oct 1, 2009 at 4:35 PM, Brett Cannon wrote:
> On Thu, Oct 1, 2009 at 15:19, Steven Bethard wrote:
>> On Thu, Oct 1, 2009 at 11:03 AM, Brett Cannon wrote:
>>> class braces_fmt(str):
>>>
>>> def __mod__(self, stuff):
>>> if isinsta
On Thu, Oct 1, 2009 at 11:03 AM, Brett Cannon 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 isinstance(stuff, coll
On Wed, Sep 30, 2009 at 1:17 PM, Andrew McNabb 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 supported, but it would
On Wed, Sep 30, 2009 at 8:50 AM, Barry Warsaw 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
>&g
On Wed, Sep 30, 2009 at 8:31 AM, Barry Warsaw wrote:
> On Sep 30, 2009, at 11:22 AM, Steven Bethard wrote:
>> On Wed, Sep 30, 2009 at 5:21 AM, Barry Warsaw wrote:
>>> On Sep 29, 2009, at 11:15 PM, Martin v. Löwis wrote:
>>>> I would propose that the format
On Wed, Sep 30, 2009 at 5:21 AM, Barry Warsaw 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 method
On Tue, Sep 29, 2009 at 10:04 PM, James Y Knight 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 % (1,2,3) ==
On Tue, Sep 29, 2009 at 8:15 PM, "Martin v. Löwis" wrote:
> Steven Bethard wrote:
>> Consider an example from the logging
>> docs:
>>
>> logging.Formatter("%(asctime)s - %(name)s - %(levelname)s - %(message)s")
>>
>> We'
On Tue, Sep 29, 2009 at 6:18 PM, Nick Coghlan 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. As the getop
On Tue, Sep 29, 2009 at 5:54 PM, Benjamin Peterson 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 {}-style formatting on
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:
logging.Formatter("%(a
On Tue, Sep 29, 2009 at 3:04 PM, Glenn Linderman 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 ha
On Tue, Sep 29, 2009 at 1:31 PM, Paul Moore wrote:
> 2009/9/28 Yuvgoog Greenle :
>> 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 interpreter).
>
> That one does wor
On Mon, Sep 28, 2009 at 8:44 PM, "Martin v. Löwis" 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: this
On Mon, Sep 28, 2009 at 12:22 PM, Brett Cannon wrote:
> On Mon, Sep 28, 2009 at 08:49, Steven Bethard
> wrote:
>> On Mon, Sep 28, 2009 at 8:27 AM, Steven D'Aprano wrote:
>>> On Tue, 29 Sep 2009 12:28:39 am Steven Bethard wrote:
>>>> * Would you like ar
On Mon, Sep 28, 2009 at 8:27 AM, Steven D'Aprano 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_argumen
On Mon, Sep 28, 2009 at 8:26 AM, Michael Foord
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
>> the example h
On Mon, Sep 28, 2009 at 4:09 AM, Neal Becker 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
> change.
I could
On Mon, Sep 28, 2009 at 6:03 AM, Jon Ribbens
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
>> > c programmers learning
On Sun, Sep 27, 2009 at 8:49 PM, Benjamin Peterson wrote:
> 2009/9/27 Steven Bethard :
>> On Sun, Sep 27, 2009 at 8:41 PM, Benjamin Peterson
>> wrote:
>>> 2009/9/27 Steven Bethard :
>>>> The first release where any real deprecation message would show up i
On Sun, Sep 27, 2009 at 9:09 PM, "Martin v. Löwis" 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 getopt superio
On Sun, Sep 27, 2009 at 8:41 PM, Benjamin Peterson wrote:
> 2009/9/27 Steven Bethard :
>> 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 to be over the
On Sun, Sep 27, 2009 at 8:08 PM, Benjamin Peterson wrote:
> 2009/9/27 Steven Bethard :
>> 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 plea
On Sun, Sep 27, 2009 at 5:51 PM, Antoine Pitrou 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 you elaborate? If
/
--
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
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 25-Sep-2009
Python-Version: 2.7 and 3.2
On Sun, Jun 21, 2009 at 1:36 PM, Jerry Chen 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 wrote:
> On Sun, Apr 19, 2009 at 2:06 AM, Nick Coghlan 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 supply a parameters dictionary. Th
On Sat, Apr 18, 2009 at 10:04 PM, Nick Coghlan wrote:
> Steven Bethard wrote:
>> On Sat, Apr 18, 2009 at 9:37 PM, Nick Coghlan wrote:
>>> Note that such an approach would then require an altaltinstall command
>>> in order to be able to install a specific ve
On Sat, Apr 18, 2009 at 9:37 PM, Nick Coghlan wrote:
> Steven Bethard wrote:
>> On Sat, Apr 18, 2009 at 8:14 PM, Benjamin Peterson
>> wrote:
>>> 2009/4/18 Nick Coghlan :
>>>> I see a few options:
>>>> 1. Abandon the "python" name for
On Sat, Apr 18, 2009 at 8:14 PM, Benjamin Peterson wrote:
> 2009/4/18 Nick Coghlan :
>> I see a few options:
>> 1. Abandon the "python" name for the 3.x series and commit to calling it
>> "python3" now and forever (i.e. actually make the decision that Mitchell
>> refers to).
>
> I believe this was
On Mon, Apr 13, 2009 at 1:14 PM, Mart Sõmermaa wrote:
> On Mon, Apr 13, 2009 at 8:23 PM, Steven Bethard
> wrote:
>> On Mon, Apr 13, 2009 at 2:29 AM, Mart Sõmermaa wrote:
>> > As for the duplicate handling, I've implemented a threefold strategy that
>> >
On Mon, Apr 13, 2009 at 2:29 AM, Mart Sõmermaa wrote:
>
>
> On Mon, Apr 13, 2009 at 12:56 AM, Antoine Pitrou
> wrote:
>>
>> Mart Sõmermaa gmail.com> writes:
>> >
>> > Proposal: add add_query_params() for appending query parameters to an
>> > URL to
>> urllib.parse and urlparse.
>>
>> Is there an
On Wed, Mar 25, 2009 at 7:08 AM, Paul Moore 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 I used was the
On Mon, Mar 16, 2009 at 11:06 AM, Guido van Rossum 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 for "with a
On Sun, Mar 15, 2009 at 10:50 AM, Michael Foord
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 flow exceptions
On Wed, Feb 25, 2009 at 4:24 AM, Nick Coghlan 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
> cmB().__enter__() r
On Mon, Feb 23, 2009 at 12:10 PM, tav 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 interpreter
> *
On Mon, Feb 23, 2009 at 04:02, Nick Coghlan 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 ext_names:
>e
On Fri, Feb 20, 2009 at 1:45 PM, Brett Cannon 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 _B()
> de
On Sat, Feb 21, 2009 at 1:11 PM, Paul Moore 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 protocol hasn't cha
On Wed, Feb 18, 2009 at 2:32 PM, Sebastian Rittau
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 decision that duck
On Wed, Feb 4, 2009 at 10:50 AM, Brett Cannon wrote:
> On Wed, Feb 4, 2009 at 10:43, Steven Bethard 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?
>>
>>
On Wed, Feb 4, 2009 at 10:25 AM, Brett Cannon wrote:
> On Wed, Feb 4, 2009 at 05:35, Hrvoje Niksic 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(), lst)
>>
>> Regarding t
On Wed, Jan 28, 2009 at 10:29 AM, "Martin v. Löwis" 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 default, the
On Fri, Jan 23, 2009 at 12:06 PM, "Martin v. Löwis" 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. ;-)
Steve
On Mon, Jan 19, 2009 at 7:10 AM, Gerald Britton
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) while n*n < 50)
>
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(unicod
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 pla
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 submit
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
>
> glob-style patterns or a callable (for complex cases) can be provided
> to filter out files or directories.
I'm not a big fan of the sequence-o
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" -
1 - 100 of 320 matches
Mail list logo
