Re: [Python-Dev] argparse ugliness
On 7 Mar 2010, at 19:49, Guido van Rossum wrote:
> How would you write the example instead then?
Boolean flags are a common enough case that I'd be inclined to add a wrapper
method, so you could just say:
parser.add_bool_argument('--plot')
As you can always fall back to the more general add_argument() call, the
wrapper could just handle the usual case (default false, presence of option
sets flag to True). So the signature would be pretty simple - something like:
def add_bool_argument(self, help=None, dest=None):
Mark Russell
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 246, redux
I strongly prefer *not* to have A->B and B->C automatically used to construct A->C. Explicit is better than implicit, if in doubt don't guess, etc etc. So I'd support: - As a first cut, no automatic transitive adaptation - Later, and only if experience shows there's a need for it, add a way to say "this adaptor can be used as part of a transitive chain" Mark Russell ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] redux: fractional seconds in strptime
On Fri, 2005-01-14 at 09:36, Skip Montanaro wrote: > Actually, time.strptime() returns a struct_time object. Would it be > possible to extend %S to parse floats then add a microseconds (or whatever) > field to struct_time objects that is available by attribute only? +1 for adding a microseconds field to struct_time, but I'd also like to see an integer-only way of parsing fractional seconds in time.strptime. Using floating point makes it harder to support exact comparison of timestamps (an issue I recently ran into when writing unit tests for code storing timestamps in a database). My vote is for %N producing a microseconds field. Mark Russell ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Updated Monkey Typing pre-PEP
On Thu, 2005-01-20 at 11:07, Guido van Rossum wrote: > I'd also like to explore ways of creating partial interfaces on the > fly. For example, if we need only the read() and readlines() methods > of the file protocol, maybe we could declare that as follows:: > > def foo(f: file['read', 'readlines']): ... > > I find the quoting inelegant, so maybe this would be better:: > > file[file.read, file.readlines] Could you not just have a builtin which constructs an interface on the fly, so you could write: def foo(f: interface(file.read, file.readlines)): ... For commonly used subsets of course you'd do something like: IInputStream = interface(file.read, file.readlines) def foo(f: IInputStream): ... I can't see that interface() would need much magic - I would guess you could implement it in python with ordinary introspection. Mark Russell ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for Better Control of Nested Lexical Scopes
On 21 Feb 2006, at 19:25, Jeremy Hylton wrote:
> If I recall the discussion correctly, Guido said he was open to a
> version of nested scopes that allowed rebinding.
PEP 227 mentions using := as a rebinding operator, but rejects the
idea as it would encourage the use of closures. But to me it seems
more elegant than some special keyword, especially is it could also
replace the "global" keyword. It doesn't handle things like "x += y"
but I think you could deal with that by just writing "x := x + y".
BTW I do think there are some cases where replacing a closure with a
class is not an improvement. For example (and assuming the existence
of :=):
def check_items(items):
had_error = False
def err(mesg):
print mesg
had_error := True
for item in items:
if too_big(item):
err("Too big")
if too_small(item):
err("Too small")
if had_error:
print "Some items were out of range"
Using a class for this kind of trivial bookkeeping just adds
boilerplate and obscures the main purpose of the code:
def check_items(items):
class NoteErrors (object):
def __init__(self):
self.had_error = False
def __call__(self, mesg):
print mesg
self.had_error = True
err = NoteErrors()
for item in items:
if too_big(item):
err("Too big")
if too_small(item):
err("Too small")
if err.had_error:
print "Some items were out of range"
Any chance of := (and removing "global") in python 3K?
Mark Russell
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for Better Control of Nested Lexical Scopes
On 21 Feb 2006, at 21:13, Ian Bicking wrote: > By rebinding operator, does that mean it is actually an operator? > I.e.: > ># Required assignment to declare?: >chunk = None >while chunk := f.read(1000): >... No, I think that "x := y" should be a statement not an expression (i.e. just like "x = y" apart from the treatment of bindings). I'd be inclined to require that the target of := be already bound, if only to prevent people randomly using ":=" in places where it's not required. In a new language I would probably also make it an error to use = to do rebinding (i.e. insist on = for new bindings, and := for rebindings). But that's obviously not reasonable for python. Mark Russell ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Terminology for PEP 343
On Thu, 2005-06-30 at 22:41, Raymond Hettinger wrote: > With 343 accepted, we can now add __enter__() and __exit__() methods to > objects. > > What term should describe those objects in the documentation? Their raison d'etre is to bracket user code with setup and teardown methods, so how about the term "bracketing object"? Mark Russell ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On Tue, 2005-08-02 at 11:00, Nick Coghlan wrote: > With this hierarchy, the recommended parent class for application errors > becomes Error, ... And presumably Error could also be the recommended exception for quick'n'dirty scripts. Mark Russell ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding a conditional expression in Py3.0
On Wed, 2005-09-21 at 11:10, Michael Hudson wrote: > My problem with this syntax is that it can be hard to read: > > return if self.arg is None then default else self.arg > > looks worryingly like > > return NAME NAME.NAME NAME NAME NAME NAME NAME NAME.NAME > > to me. I think that requriing parens helps a lot with the list-of-names problem - it nicely delimits the conditional expression for human readers: return (if self.arg is None then default else self.arg) In particular it breaks up the misleading grouping "return if". Mark Russell ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 10 Feb 2006, at 12:45, Nick Coghlan wrote:An alternative would be to call it "__discrete__", as that is the key characteristic of an indexing type - it consists of a sequence of discrete values that can be isomorphically mapped to the integers. Another alternative: __as_ordinal__. Wikipedia describes ordinals as "numbers used to denote the position in an ordered sequence" which seems a pretty precise description of the intended result. The "as_" prefix also captures the idea that this should be a lossless conversion.Mark Russell___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
