On Mon, 28 Sep 2009 06:59:32 am Steven Bethard wrote:
> Why aren't getopt and optparse enough?
[snip]
As a newbie, I found optparse intimidating because it provided so many
features. I expect argparse will be the same, only more so.
(Disclaimer: I haven't used argparse, I'
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
o RFCs. For example, ipaddr accepts '192.168.1.1/24' as a
network definition because this is a very common way of describing an
address + netmask despite the fact that 192.168.1.1 is actually an IP
address on the network 192.168.1.0/24. ..."
which nicely explains why (3) is not used,
On Tue, 29 Sep 2009 12:28:39 am Steven Bethard wrote:
> Ok, sounds like there are a number of supporters for keeping getopt
> around and just deprecating optparse. For those who'd like to keep
> getopt around, I have a few questions:
>
> * Would you be opposed to
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 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
egatives and don't remember to give credit where
credit is due.
Hopefully we can reach consensus, or at least understanding, on the
remaining issue(s).
--
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
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
many more lines, I prefer it over
> optparse/argparse: this code has only a single function call,
> whereas the argparse version has three function calls to remember.
> The actual processing uses standard Python data structures which
> I don't need to look up in the documentat
udies into a
single comparison paradoxically shows that treatment B is better!
The mediant is fascinating (to maths geeks at least) and important, and
you need denormalized fractions.
--
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@pytho
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 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
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 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
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 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 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) ==
API. If the external API depends on the caller using %
explicitly, then this approach may not work.)
> 2) A long time later...deprecate str.__mod__;
How long? I hope that's not until I'm dead and buried.
--
Steven D'Aprano
___
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
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 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 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 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 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 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 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 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 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 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 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
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 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
There's no reason to treat SystemExit as special in this regard.
optparse, for example, calls sys.exit(), which operates by raising
SystemExit. Ordinary SystemExit, not a special module-specific
subclass.
--
Steven D'Aprano
___
Python-Dev mai
On Sun, 4 Oct 2009 01:41:36 am Steven Bethard wrote:
> 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 librar
tion raises
ValueError. The fact that you are catching an exception implies that
the function might raise that exception. A comment like:
"Catching SystemExit because parse_args() throws SystemExit on parser
errors."
is up them with comments like thi
On Sun, 4 Oct 2009 05:35:04 am André Malo wrote:
> * Steven D'Aprano wrote:
> > You don't need a comment warning that you are catching SystemExit
> > because parse_args raises SystemExit, any more than you need a
> > comment saying that you are catching ValueError b
t in case someday in the indefinite future
there comes a need to add extra information to the exception falls foul
of You Ain't Gonna Need It. Keep it simple -- if, someday, such a need
becomes apparent, then subclass.
--
Steven D'Aprano
___
ight be hard on a PDA or
mobile phone, but on a PC with a keyboard and mouse?
(I have a vague recollection that Lotus Notes inserts the quoted message
*after* you've done editing your reply, so Notes users should be
forgiven. Not to mention pitied.)
--
Steven D'Aprano
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 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
s the Rule of Least
Astonishment. I thought I understood Python's object model and it's
rules of inheritance, but not only do double-underscore attributes
follow a different rule for inheritance than other attributes, but
__doc__ follo
x = some_set.pop(False)
>
> and am thinking about providing a patch against setobject.c
> (preferring the .get() solution being a stripped down pop()).
-1 on .pop(flag)
+0 on .get()
--
Steven D'Aprano
___
Python-Dev mailing list
Pyt
o 3.1,
and with the overwhelming approval for a moratorium on changes to
built-ins, it is likely to just sit in the tracker, forgotten, until
2013 or later. How likely is it that the patch will still be
applicable?
--
Steven D'Aprano
___
Python-De
ONST 0 (None)
20 RETURN_VALUE
The difference is likely to be this:
for x in s: break
retrieves the first (only) element of the set, then immediately breaks
out of the loop. This is very different from:
for x in s: pass
which retrieves t
ack of get() in sets and frozensets is sounding more and more to me
like the victory of purity over practicality.
--
Steven D'Aprano
___
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
tand that conclusion. According to your tests, your
implementation of get() is as fast as "for x in set: break", and it's
certainly much, much more readable and straightforward.
--
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@p
On Fri, 23 Oct 2009 11:47:22 pm Nick Coghlan wrote:
> Yuvgoog Greenle wrote:
> > On Fri, Oct 23, 2009 at 1:09 PM, Steven D'Aprano
wrote:
> >> Is there any point? Even if accepted, it's too late to make it
> >> into 3.1, and with the overwhelming approval for
On Sat, 24 Oct 2009 10:26:27 am Ben Finney wrote:
> Steven D'Aprano writes:
> > On Sat, 24 Oct 2009 06:04:12 am Terry Reedy wrote:
> > > fwiw, I think the use case for this is sufficiently rare that it
> > > does not need a separate method just for this purpose.
&g
On Sat, 24 Oct 2009 02:02:48 pm Ben Finney wrote:
> Steven D'Aprano writes:
> > On Sat, 24 Oct 2009 10:26:27 am Ben Finney wrote:
> > > Steven D'Aprano writes:
> > > > The lack of get() in sets and frozensets is sounding more and
> > > > mor
On Sat, 24 Oct 2009 05:04:33 pm Stephen J. Turnbull wrote:
> Steven D'Aprano writes:
>
> > I'm not being tongue-in-cheek or sarcastic. My question was
> serious -- > if there is a moratorium, is there any reason to bother
> submitting > patches for functi
could be O(1).
(2) The second one is apparently a common need (although I personally
have never needed it), forcing people to re-invent the wheel, sometimes
incorrectly or inefficiently, e.g.:
def get(aset):
for element in aset:
pass
return element
--
Steven D'Apran
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 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&#
ufficiently pure. As soon as
you allow iteration over sets, you have allowed retrieval.
--
Steven D'Aprano
___
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
moratorium. How would the addition of `yield from` delay or prevent
people using set methods on mapping views?
If a proposed feature directly competes with a feature in 3.x, then it
might delay usage of the 3.x feature -- but if that were the case, the
proposal would almost certainly be rejected
On Tue, 27 Oct 2009 10:09:14 am Guido van Rossum wrote:
> On Mon, Oct 26, 2009 at 4:06 PM, Antoine Pitrou
wrote:
> > Steven D'Aprano pearwood.info> writes:
> >> I don't understand that rationale. Let's take a concrete example.
> >> The new `yield fro
Willi Richart implemented these
behaviours.
http://bugs.python.org/issue7212
--
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
-calls
> semantics is self-evident and non-magical as compared to a straight
> for-loop or next(it)?
I'm going to sit on the fence on that and say "maybe".
> ISTM, that when streams have non-destructive getters with
> self-advancing pointers, they also have a seek() funct
rpose is to
return an arbitrary item each time it is called. If two threads get the
same element, that's not a problem; if one thread misses an element
because another thread grabbed it first, that's not a problem either.
If people prefer a random element instead,
is not a
problem that needs solving.
> > No. Since sets are unordered, there's no way to seek to a specific
> > element.
>
> I think people will realize that in fact *these* sets are ordered and
> they will demand a seek function for various practical purposes.
We can
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
bviously there is disagreement on whether or not pick() is a
fundamental operation or not. As Raymond points out, it is uncommon in
other languages. But Wikipedia lists it as fundamental, and it is not
just Python users who ask for it:
http://st
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 Wed, 4 Nov 2009 10:10:30 am Guido van Rossum wrote:
> On Tue, Nov 3, 2009 at 2:46 PM, Steven D'Aprano
wrote:
> > Since I was the person who decided that "arbitrary" meant "give a
> > different result each time", I should answer that.
> You're
On Wed, 4 Nov 2009 11:54:47 am Greg Ewing wrote:
> Steven D'Aprano wrote:
> > I don't know how expensive it is to create a set iterator,
>
> Not expensive enough to justify burdening the set type with
> extra functionality that will be extremely rarely used.
As my
n Unladen Swallow is a fork (sorry - I mean branch) of
> CPython rather than a separate implementation.
I don't know how mature or active it is, so it may not count as either
major or complete, but there's also CLPython:
http://common-lisp.net/projec
rator. If another thread modifies the original set
after the set_iterator is created but before the return, you would get
a mysterious and almost impossible to debug RuntimeError.
--
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev
-- that's effectively just 3.2. But Guido has
suggested it could last to 3.3. Could it last beyond that? 3.4? Until
some distant future Python-4000?
At the very least, I believe, any moratorium should have a clear end
date. A clear end date will be a powerful counter to the impressio
ationale for this PEP is to give alternative
implementations the chance to catch up with CPython.
Given your statement that CLPython is quite complete on the language
level, but missing standard library features, how do you think the
moratorium will help
On Sun, 8 Nov 2009 11:14:59 am Steven D'Aprano wrote:
> At the very least, I believe, any moratorium should have a clear end
> date. A clear end date will be a powerful counter to the impression
> that Python the language is moribund. It says, this is an exceptional
> pause, not
ORE_FAST 0 (value)
3 13 LOAD_FAST0 (value)
16 RETURN_VALUE
>> 17 POP_BLOCK
>> 18 LOAD_CONST 0 (None)
21 RETURN_VALUE
Is it possible for another thread to be called between the GET_ITE
somehow gives you the right to demand control over what others say
about your software.
I don't suppose that this rant of yours has something to do with the
comment posted today?
http://pypi.python.org/pypi/spypam/1.0
--
Steven D'Aprano
__
might not trust a module that has no reviews or ratings.
As a user, I'd be more likely to trust a module with no reviews/ratings
than one where the author disabled reviews/ratings. The first
says "nobody hated it enough to complain", the second one says "the
author is try
On Fri, 13 Nov 2009 04:27:48 am Ludvig Ericson wrote:
> On 12 nov 2009, at 14:38, Steven D'Aprano wrote:
> > On Thu, 12 Nov 2009 08:44:32 pm Ludvig Ericson wrote:
> >> Why are there comments on PyPI? Moreso, why are there comments
> >> which I cannot control as
g Ericson, had (as of
last night) two comments, one positive, one negative.
This admittedly tiny sample doesn't suggest to me that PyPI is suffering
from the problem of biased ratings.
--
Steven D'Aprano
___
Python-Dev mailing list
Python-
can't even agree on the
validity of benchmarks!
This is open source. The power of the bazaar, remember? I'm amazed at
how many people are not just disinterested in, but actively hostile, to
even *useful* comments from users. That's fine. If you, the package
author, don't care
27;t.
I think the std library could possibly be organised better, but just
because something isn't useful to me right now, doesn't mean it isn't
useful to someone, and may be useful to me tomorrow.
--
Steven D'Aprano
___
Python-Dev
ut for the life of me, I can't understand the 1/3 of the votes that
have been cast in favour of prohibiting comments for everybody, even
those who want comments.
--
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http://mai
three choices for allowing comments, two for disallowing.
--
Steven D'Aprano
___
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
s, with two-thirds in favour of allowing
them.
--
Steven D'Aprano
___
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
On Sat, 14 Nov 2009 10:19:17 am Steven D'Aprano wrote:
> On Sat, 14 Nov 2009 09:17:40 am Jacob Kaplan-Moss wrote:
> > This "poll" business is just smoke and mirrors, anyway -- notice
> > the way the "no comments" votors are split among three choices,
>
ple like Paul, but because the alternatives -- easy
comment spam, people voting multiple times -- are worse than some
proportion of users being unable to vote.
--
Steven D'Aprano
___
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
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 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
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 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 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 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 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 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 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 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
it.
Thank you.
--
Steven D'Aprano
___
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
ell, and FWIW, I personally agree with this
> convention.
What's the justification for that convention? It seems wrong to me.
If you expand out hypot and substitute a=inf and b=nan, you get:
>>> math.sqrt(inf*inf + nan*nan)
nan
which agrees with my pencil-and-paper calculatio
On Wed, 17 Feb 2010 10:06:01 am Mark Dickinson wrote:
> On Tue, Feb 16, 2010 at 10:46 PM, Steven D'Aprano
>
>
> > What's the justification for that convention? It seems wrong to me.
>
> It's difficult to do better than to point to Kahan's writings. See
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
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 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
7;re all adults here. I do recall a
poster on comp.lang.python pulling his hair out over a customer who was
too big to fire, but who had the obnoxious habit of making random
so-called "fixes" to the poster's .py files, so perhaps byte-code only
distribution isn't all bad.
tion is extensive and rapidly changing,
so I think it would be better to have the current implementation page
be fairly minimal but link to the wiki for more details:
http://wiki.python.org/moin/implementation
http://www.python.org/dev/implementations/
--
Steven D'Aprano
_
description given. I imagine there
will be recipes on ActiveState quite quickly, and if there isn't, that
would be good evidence that demand for the feature is low.
--
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.
1101 - 1200 of 1900 matches
Mail list logo
