Re: [Python-3000] PEP - string.format
Talin wrote:
> No responses? I'm surprised...
>
> (I assume the PEP editor is on vacation, since I haven't gotten a response
> from that channel either.)
A couple of days isn't really that long for Py3k stuff, and py-dev has been
pretty busy for the last few days :)
[...]
> Or if you just want me to drop it, I can do that as well...just do so
> politely and I will take no offense :) (I'm a pretty hard person to
> offend.)
Keep plugging away - this is important, IMO, and I think we can do better than
the status quo.
> PEP: xxx Title: Advanced String Formatting Version: $Revision$
[...]
> In any case, string.Template will not be discussed here,
> except to say that the this proposal will most likely have some overlapping
> functionality with that module.
string.Template will either be subsumed by the new mechanism, become an
implementation detail of the new mechanism, or else be specialised even
further towards il8n use cases. As you say, not something we should get hung
up on at this point (although my expectation is that it is the last that will
happen - the needs of il8n templating and general debug printing are quite
different).
> The '%' operator is primarily limited by the fact that it is a binary
> operator, and therefore can take at most two arguments. One of those
> arguments is already dedicated to the format string, leaving all other
> variables to be squeezed into the remaining argument.
As Ian noted, the special treatment of tuples and dictionaries makes this even
worse (I'm one of those that tends to always use a tuple as the right operand
rather than having to ensure that I'm not passing a tuple or dictionary)
[...]
> The second method, 'fformat', is identical to the first, except that it
> takes an additional first argument that is used to specify a 'custom
> formatter' object, which can override the normal formatting rules for
> specific fields:
>
> "More on {0}, {1}, and {c}".fformat( formatter, a, b, c=d )
>
> Note that the formatter is *not* counted when numbering fields, so 'a' is
> still considered argument number zero.
I don't like this. Formatting with a different formatter should be done as a
method on the formatter object, not as a method on the string.
However, there may be implementation strategies to make this easier, such as
having str.format mean (sans caching):
def format(*args, **kwds):
# Oh for the ability to write self, *args = args!
self = args[0]
args = args[1:]
return string.Formatter(self).format(*args, **kwds)
Then custom formatters would be invoked via:
MyFormatter("More on {0}, {1}, and {c}").format(a, b, c=d)
And defined via inheritance from string.Formatter. Yes, this is deliberately
modelled on the way string.Template works :)
There may be some alternative design decisions to be made in the subclassing
API, such as supporting methods on the formatter object that process each
field in isolation:
def format_field(self, field, fmt_spec, fmt_args, fmt_kwds):
# field is x.partition(':')[0], where x is the text between the braces
# fmt is x.partition(':')[2] or None if x.partition(':')[1] is false
# fmt_args and fmt_kwds are the arguments passed to the
# Formatter's format() method
val = self.get_value(self, field, fmt_args, fmt_kwds)
return self.format_value(self, val, fmt_spec)
def get_value(self, field, fmt_args, fmt_kwds):
try:
pos = int(field)
except ValueError:
return fmt_kwds[field]
return fmt_args[pos]
def format_value(self, value, fmt_spec):
return value.__format__(fmt_spec)
For example, if a string.Template equivalent had these methods, they might
look like:
def get_value(self, field, fmt_args, fmt_kwds):
return fmt_kwds[field]
def format_value(self, value, fmt_spec):
if format_spec is not None:
raise ValueError("field formatting not supported")
return value
Another example would be a pretty-printer variant that pretty-printed types
rather than using their normal string representation.
[...]
> Brace characters ('curly braces') are used to indicate a replacement field
> within the string:
I like this, since it provides OOWTDI, rather than "use this way if it's not
ambiguous, this other way if it's otherwise unparseable".
[...]
> Braces can be escaped using a backslash:
>
> "My name is {0} :-\{\}".format( 'Fred' )
So "My name is 0} :-\{\}".format('Fred') would be an error? I like that - it
means you get an immediate exception if you inadvertently leave out a brace,
regardless of whether you leave out the left brace or the right brace.
[...]
> The conversion specifier consists of a sequence of zero or more characters,
> each of which can consist of any printable character except for a
> non-escaped '}'.
Why "conversion specifier" instead of "format specifier"?
> The format() method does not attempt to interpret the
> conversion specifiers i
Re: [Python-3000] Changing the import machinery
Guido van Rossum wrote: > > I'm afraid I disagree. PEP 302 actually has some tremendous advantages > > over a pure objects-on-sys.path approach: > > > > * Strings can be put in any configuration file, and used in .pth files > > > > * Strings can be put in environment variables (like PYTHONPATH). > > > > * Strings can be printed out, with all their contents showing and nothing > > hidden > > > > In short, strings are better for humans. > > I think I like this. I wonder if there's a parallel with my preference > for strings as paths instead of path objects... And strings as exceptions, and Tcl instead of Python ? ;-) Sorry, but I don't buy this argument at all. Of course you need a way to map from external path descriptions (PYTHONPATH, registry entries, etc) to sys.path contents, but ruling that the things you're manipulating *inside* a Python program must be strings so you "can print them out with all their contents showing and nothing hidden" doesn't strike me as very Pythonic. The target audience for this is Python programmers, after all, and Python programmers know how to inspect Python objects -- as long as they can find them, which isn't the case with today's extended import design, which *hides* lots of stuff in *separate* semi-secret registries. If you put all this back on the path, it'll be a lot easier to find and manipulate. I could quote the "If the implementation is hard to explain, it's a bad idea." zen here, but I'll quote Sean McGrath's 20th python zen instead: "Things should be as complex as necessary but not more complex." and offer a "let's get back to the basics and add stuff, instead of assuming that the status quo is complex and complicated because it has to be" solution. Here's an outline, off the top of my head: 1. sys.path can contain strings or import handlers 2. Strings work as today; as paths that a builtin import handler uses to look for packages or modules (flyweight-style). 3. Import handlers are duck-typed objects that implement a simplified version of the PEP 302 protocol. Handlers map dotted module paths to resources, where a resource can be a Python module, a Python package (a module container), or some other resource. Handlers are responsible for creating and populating module objects; whatever they return is stored in sys.modules and bound to the import target. I'm 50/50 on making the import machinery fully type agnostic; that is, allowing the import handler to return *any* kind of object also for ordinary imports. Importing e.g. PIL images and pre- parsed XML resources and Cheetah templates makes perfect sense to me. 4. A support library provides the following mechanisms: - An import handler for builtin/frozen objects (with corresponding hooks on the C API site, so that apps can register things to be treated as builtins). - An import handler for the standard library (*all of it*, minus site-packages!) - An import handler for directory names (used for string path items) - A registry for path specifier syntaxes - A parser for external path descriptions, which uses the registry to map from path components to import handlers - (possibly) Some helpers for user-provided import handlers (to be factored out from such handlers, rather than be designed up front) 5. Remove PTH support, and possibly also a lot of the site- packages related stuff in site.py. I'm 50/50 on *requiring* code to specify what non-core libraries they want to use, before they can import them. I'm also 50/50 on making some additions to the import statement syntax, to make some operations easier (import ... using handler), but I'll leave that for another post. This would cleanly address every deployment scenario and custom importer that I've used with a (near) mininum of core support, and frankly, I fail to see any potential use case that cannot be handled by this mechanism (simply because a handler can do *anything* behind the scenes, without requiring more support from the core import machinery). And it'll let us remove tons of "hard to explain" code from the core. ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Brainstorming: literal construction hooks
It's an interesting idea; it's been brought up before but nobody AFAIK has ever implemented it. I like the scoping requirement. I suggest you try to implement it and see how well it works. You probably also want to be able to hook list, tuple and dict displays (perhaps by supplying an alternative factory function). Good lock! --Guido On 4/22/06, Michael Urman <[EMAIL PROTECTED]> wrote: > This idea isn't fully fleshed out, but I wanted to air it to see if it > took wind or fell flat. Please forgive inaccuracies between lexing and > parsing. > > It's about being able to override what a given literal is turned into. > It would only take effect in a limited scope, either per module, per > compile/exec, or something similar. When a literal of a registered > token type is parsed, its string would be passed to the provided > function and whose return value would be used for the object. The > following example, when registered, would be used to turn all float > literals into decimal instances. > > def float_literal(literal): > return decimal.Decimal(literal) > > More simply decimal.Decimal could be registered as the literal > constructor if just the literal's string is used. Alternative > signatures could allow a single function to handle multiple token > types, or could make applying modifications to normal types simpler, > but would prevent the obvious use of decimal.Decimal as above. I see > token_type and value (as normally parsed) as obvious candidates for > this. > > This could be used for people who want to create auto-substituting > string literals (which I dislike for I18N reasons) without having to > shoehorn its own syntax into the language. > > There's a lot of holes to this story, including at least how these > functions are registered, and which additional arguments (if any) are > necessary. Shall we try to fill these holes in? > > Michael > -- > Michael Urman http://www.tortall.net/mu/blog > ___ > Python-3000 mailing list > Python-3000@python.org > http://mail.python.org/mailman/listinfo/python-3000 > Unsubscribe: > http://mail.python.org/mailman/options/python-3000/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Futures in Python 3000
Thanks for the discussions on the hows-and-whys of futures and asynchronous approaches in Python... they have been enlightening. [OT stuff below] Michael Chermside wrote: > It is a FUNDAMENTAL PRECONDITION of Py3K that it will BE the existing > CPython codebase, with a few changes and some cruft removed. We are > NOT going to re-write from the ground up. If you don't know why, go > read "http://www.joelonsoftware.com/articles/fog69.html";. I found myself agreeing with that essay when I first read it, but hindsight shows us that it was only half-right. It is very unlikely that Firefox could have become the platform it is today had they not completely re-engineered the architecture. Joel's points stand in that from-scratch rewrites are generally disastrous for *companies* which underestimate the length of time involved (almost a given), but because open-source projects do not need to be financially viable in the short run, they can afford much longer gestation periods (and often with superior results). Disclaimer, the above should not be construed as having anything to do with an opinion of whether Py3K should be written from scratch or not. When I asked about Py3K's intended reuse of the existing implementation, it was out of curiousity. ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Futures in Python 3000
Greg Ewing wrote: > BTW, if you *really* want to understand continuations, you > need to carry out the following exercise: Write a Scheme > interpreter in Scheme, doing it in a continuation-passing > style. [1] > > You'll find that it's possible to do this using a subset > of Scheme that doesn't itself have continuations, yet it > will be trivially easy to make it so that your interpreter > implements a Scheme that does. > > If you carry out this exercise successfully, and make it > actually work, at some point along the way you will have > a Zen-like flash of insight, and will suddenly understand > exactly what a continuation is and how it works. > > (The other possibility is that you will still be none the > wiser. If this happens, you will never understand > continuations. Give up programming language implementation > and become a potato farmer. :-) Thanks for the suggestion, Greg. Methinks I'll just go get myself hammered on some vodka... a much easier way to get the same kind of headache... ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Type Comparisons with Godel Numbers
On 4/22/06, Talin <[EMAIL PROTECTED]> wrote: > Greg Ewing canterbury.ac.nz> writes: > > > Giovanni Bajo wrote: > > > > > Another (similar) way would be to let the user pay for the high > > > typechecking > > > price in normal cases *but* provide a list[int] class, which is a list > > > decorated with typechecks on modification operations. We could have > > > list[int|float]() to construct a list which can hold either ints or > > > floats. > > > > This is worth thinking about. Recently when pondering the > > question of when it would or would not be appropriate to > > put in type assertions to help catch bugs, I concluded > > that it makes the most sense to do so when building a > > data structure, but not when just passing things around > > between calls. > > This makes total sense to me. You don't check the type of each > entry of the list - you check the type of the list itself. This is > pretty much the way statically typed languages work. > > This means that you can't pass a regular list to a function > that expects a "list of ints". So its an extra step to convert > the list to the proper type. As long as the syntax isn't too > hard to type, that shouldn't be a problem, and this way the > user knows that they are paying the cost for the conversion. > "Explicit is better than implicit". No. This is the kind of thing that would very quickly turn "optional" typing into *mandatory* typing. One library package adds type declarations. Now all packages that use it are required to either add type declarations or explicit conversions or checks. The cost of repeated explicit conversions/checks strongly suggests that adding type declaration is the better choice -- and now you have a ripple effect (similar to the way 'const' declarations, once added, cascade in C or C++ code). Soon enough the entire library uses type declarations and now all user code is faced with the same choice. All style guides will strongly suggest type declarations. And we end up with Java without curly braces. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Changing the import machinery
Ian Bicking wrote: > Maybe you wouldn't have to mix it all together... if sys.path, > sys.meta_path, and sys.modules (and maybe some other stuff I don't know > of) were really instance variables of some ModuleEnvironment object, and > you could instantiate a new ModuleEnvironment that was specific to > templates. Probably to be filed under crazy ideas. Not really all that crazy. . . . Think about it - the import mechanism is a bunch of related functions for finding and loading modules. Currently, those are all stored as module level functions, which forces their shared state to be global for the entire interpeter. What's the conventional solution for dealing with a set of functions which need to share complex state? Now, suppose that there was, in sys, the moral equivalent of: sys.importer = imp.Importer() sys.path, sys.meta_path, sys.path_hooks, sys.path_importer_cache and sys.modules would then all be attributes of the Importer object. If sys was changed to be a class rather than a module, then the top-level attributes could be retained as properties accessing sys.importer. Applications wanting to tightly control sys.path would simply replace sys.importer with a different importer object. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PEP - string.format
On 4/22/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: >Removing string %-formatting would be a backwards compatibility nightmare. > I doubt there's a Python program on the planet that would continue working if > it was removed (I know most of mine would break in verbose mode). Even those > which continued to work would likely break if all commented out debugging > messages were uncommented. The same is true for some other changes considered, e.g. the new I/O stack, all-unicode strings, and dict views. Py3k exists to *break* backwards compatibility. A format() method added to strings could be added to 2.6. Defining format() in terms of % would be a long-term disaster IMO. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Futures in Python 3000
Andy Sy wrote: > > It is a FUNDAMENTAL PRECONDITION of Py3K that it will BE the existing > > CPython codebase, with a few changes and some cruft removed. We are > > NOT going to re-write from the ground up. If you don't know why, go > > read "http://www.joelonsoftware.com/articles/fog69.html";. > > I found myself agreeing with that essay when I first read it, but > hindsight shows us that it was only half-right. It is very unlikely > that Firefox could have become the platform it is today had they not > completely re-engineered the architecture. > > Joel's points stand in that from-scratch rewrites are generally disastrous > for *companies* which underestimate the length of time involved (almost a > given), but because open-source projects do not need to be financially > viable in the short run, they can afford much longer gestation periods > (and often with superior results). given the amount of money that flows into the Mozilla Foundation from various sources (mostly Google), I don't think you can draw any conclusions from the Firefox project wrt. software engineering. (other than "given a large number of volunteers, and large amounts of money from corporate sponsors, and being politically correct in geek and web design circles, you can grab a small chunk of a huge market" ;-) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Pronouncement on parameter lists
> I already have a rough draft PEP and implementation for a > __signature__ object from a couple of months ago (sparked my thinking > on __introspects__). I will go ahead and start another email thread > with the PEP so that details can get hashed out on that separately. I was wondering if maybe there could be a dict-like thing for the keyword arguments that also supports __setitem__. I'm not sure whether functions/methods currently count as immutable, but it would be nice if there would be a kind of partial() equivalent to deal with setting default arguments on functions (so you can have one function and spawn several functions off of that have other defaults). OTOH, I can't really come up with use cases (but that might be because I'm not too bright today), so this might be a case of YAGNI, but I think it would be a nice parallel to the partial() functionality. Regards, Manuzhai ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Type Comparisons with Godel Numbers
> Guido van Rossum wrote: > If I have some utterly dynamic > code that comes up with a list of a million ints, and then I pass > that > as an argument to a function that requests the argument type is > list[int], > > you wrap it in something that checks elements for intness > as you access them. [...] Yes you are right. I see some sub-cases. If the value structure is immutable, then as it is constructed you could calculate the Godel strings bottom-up. Even this effectively doubles the work of the runtime since it has to calculate the value _and_ the type information. All this additional calculation just in case a type check might be needed. So not good. And this is the best case. If the data structure is mutable like list[int] then then attempting to keep the Godel strings up-to-date means re-calculating the entire string every time an element changes, again just in case a type check is needed. Last case, what about recursive types? Chances are an algorithm needs to keep track of nodes visited, further adding to the workload. The "Lingua Franca IDL" distributed system was happy to bear this runtime load because of the large-grained method calls over a network. (http://citeseer.ist.psu.edu/27902.html) However within the same executable the costs will be too high. So yes, this idea doesn't tackle the hard problem of the cost of run-time type checking of dynamic data. Is this intractable? I don't see how it can be lightened up unless 'nominal subtyping' aka 'inheritance subtyping' is used. But that is not Pythonic since we want duck typing or 'structural subtyping'. ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Type Comparisons with Godel Numbers
On Sat, 22 Apr 2006 03:12 am, Jim Jewett wrote: > On 4/20/06, Birch, Bill <[EMAIL PROTECTED]> wrote: > > Type comparison operators would only need a deep > > inspection of the types when the godel strings don't match. > > If most comparisons will be an exact match (not a subtype) > > the lookup should be faster. > > If you're assuming that, then just checking whether > > obj.__class__ is requirement.allowed_class > > should be pretty hard to beat... OK that will work for atomic types. But if obj.__class__ is it does not tell us what is _in_ the list. We want to know it's list[any] or list[int] ot list[str] etc. ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Limit Type Checks to Interfaces (was Type Comparisons with Godel Numbers)
On Sat, 22 Apr 2006 06:39 pm, Guido van Rossum wrote: > > No. This is the kind of thing that would very quickly turn "optional" > typing into *mandatory* typing. One library package adds type > declarations. Now all packages that use it are required to either add > type declarations or explicit conversions or checks. The cost of > repeated explicit conversions/checks strongly suggests that adding > type declaration is the better choice -- and now you have a ripple > effect (similar to the way 'const' declarations, once added, cascade > in C or C++ code). Soon enough the entire library uses type > declarations and now all user code is faced with the same choice. All > style guides will strongly suggest type declarations. And we end up > with Java without curly braces. recapping: What exactly is list[int]? - list[int] is shorthand for type(list[0]) <: int and type(list[1]) <: int and type(list[2]) <: int ... where "t1 <: t2" means t1 is a structural subtype of t2 otherwise stated as: for any natural number n, list[n] <: int which is essentially an un-typed viewpoint. So we add the type variable to the runtime object. Luca Cardelli's paper on the typed lambda calculus has a lot to say about adding types (http://research.microsoft.com/Users/luca/Papers/OnUnderstanding.A4.pdf) If I understand the math right, we can expressed this as a bounded universal quantifier? all[a <: int] list[a] You would have to construct it specifically with the type attribute: var = list[int] # py3k var[0] = 42 # OK var[1] = "foo" # run-time type error Java arrays work this way. quote "More formally: an assignment to an element of an array whose type is A[], where A is a reference type, is checked at run-time to ensure that the value assigned can be assigned to the actual element type of the array, where the actual element type may be any reference type that is assignable to A." see (http://java.sun.com/docs/books/jls/second_edition/html/arrays.doc.html) The implications of this for the programmer are that type errors would be found closer to the source. But, as was pointed out there will be a proliferation of listOf(T) constructors. And a proliferation of performance soaks. so... In my experience deep type checking at runtime is really useful, common, but rarely called type checking. Normally we to write it manually (and call it "input validation" or "checking preconditions"). Usually on major system boundaries. Especially in distributed systems. I would be happy to pay the cost of run-time type checking if I could invoke it explicitly. Then I could choose where the performance hit happens and how often. But how can dynamic type checks be made obvious and explicit syntactically? Maybe with an annotation: @enforce_types def func(x: t1, y: t2) -> t3: ...body... or with an explicit check: def func(x, y) : if not x, y <: t1, t2: throw "mate, you have a type error" Perhaps we could limit type definitions to interfaces only, and allow preconditions and postconditions there. This would be simple to grasp. If you implement an interface, you'll be paying the cost of runtime type checks. After all the whole point of interfaces in Python is to enforce compliance with a standard. Remember this is not Java, we already have multiple inheritance. ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Type Comparisons with Godel Numbers
On Sat, 22 Apr 2006 06:39 pm, Guido van Rossum wrote: ... > > No. This is the kind of thing that would very quickly turn "optional" > typing into *mandatory* typing. One library package adds type > declarations. Now all packages that use it are required to either add > type declarations or explicit conversions or checks. The cost of > repeated explicit conversions/checks strongly suggests that adding > type declaration is the better choice -- and now you have a ripple > effect (similar to the way 'const' declarations, once added, cascade > in C or C++ code). Soon enough the entire library uses type > declarations and now all user code is faced with the same choice. All > style guides will strongly suggest type declarations. And we end up > with Java without curly braces. recapping: What exactly is list[int]? - list[int] is shorthand for type(list[0]) <: int and type(list[1]) <: int and type(list[2]) <: int ... where "t1 <: t2" means t1 is a structural subtype of t2 otherwise stated as: for any natural number n, list[n] <: int which is essentially an un-typed viewpoint. So we add the type variable to the runtime object. Luca Cardelli's paper on the typed lambda calculus has a lot to say about adding types (http://research.microsoft.com/Users/luca/Papers/OnUnderstanding.A4.pdf) If I understand the math right, we can expressed this as a bounded universal quantifier? all[a <: int] list[a] You would have to construct it specifically with the type attribute: var = list[int] # py3k var[0] = 42 # OK var[1] = "foo" # run-time type error Java arrays work this way. quote "More formally: an assignment to an element of an array whose type is A[], where A is a reference type, is checked at run-time to ensure that the value assigned can be assigned to the actual element type of the array, where the actual element type may be any reference type that is assignable to A." see (http://java.sun.com/docs/books/jls/second_edition/html/arrays.doc.html) The implications of this for the programmer are that type errors would be found closer to the source. But, as was pointed out there will be a proliferation of listOf(T) constructors. And a proliferation of performance soaks. so... In my experience deep type checking at runtime is really useful, common, but rarely called type checking. Normally we to write it manually (and call it "input validation" or "checking preconditions"). Usually on major system boundaries. Especially in distributed systems. I would be happy to pay the cost of run-time type checking if I could invoke it explicitly. Then I could choose where the performance hit happens and how often. But how can dynamic type checks be made obvious and explicit syntactically? Maybe with an annotation: @enforce_types def func(x: t1, y: t2) -> t3: ...body... or with an explicit check: def func(x, y) : if not x, y <: t1, t2: throw "mate, you have a type error" Perhaps we could limit type definitions to interfaces only, and allow preconditions and postconditions there. This would be simple to grasp. If you implement an interface, you'll be paying the cost of runtime type checks. After all the whole point of interfaces in Python is to enforce compliance with a standard. Remember this is not Java, we already have multiple inheritance. ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Type Expressions
On 22/04/06, Paul Svensson <[EMAIL PROTECTED]> wrote:
> At the risk of hypergeneralization... If *arg means "put the rest of the
> positional arguments in arg", then if we simply allow arg to be a tuple...
>
> def foo(*(a, b)): ... # disallow keyword args.
> def foo(a, b, *(), x, y): ... # disallow positional args after b.
> def foo(*(a, b), x, y): ... # a, b _must_ be positional; x, y keyword.
>
> That () = () is currently a syntax error might be considered a reason to
> use the lone star spelling instead of *(), but I find the tuple more obvious.
This is close (ish) to the "def [positional-only arguments](mixed
arguments){keyword-only arguments}" syntax I floated earlier, which
Guido then promptly rejected. It looks like we won't get a way to
force an argument to be given positionally, as he's also already
voiced a distaste for nested bracketing in argument lists.
--Sam
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PEP - string.format
Guido van Rossum wrote: > On 4/22/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: >>Removing string %-formatting would be a backwards compatibility nightmare. >> I doubt there's a Python program on the planet that would continue working if >> it was removed (I know most of mine would break in verbose mode). Even those >> which continued to work would likely break if all commented out debugging >> messages were uncommented. > > The same is true for some other changes considered, e.g. the new I/O > stack, all-unicode strings, and dict views. > > Py3k exists to *break* backwards compatibility. A format() method > added to strings could be added to 2.6. Defining format() in terms of > % would be a long-term disaster IMO. That (adding .format() in 2.6) occurred to me, but I dismissed it for some reason. It can't have been a very good reason though, since I sure can't remember what it was. In which case, Talin's PEP should probably suggest this as the implementation strategy - python3warn and the instrumented python build can do their best to pick up usage of % formatting, and we can add .format() to 2.6 so that forward compatible code can be written in later 2.x releases. Now that I think about it, simply having python3warn pick up all uses of % in a print statement should pick up many of the uses of string formatting. (Not all, obviously, but a lot of them) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] New built-in function: bin()
Ian Bicking wrote: > Guido van Rossum wrote: >> This has been brought up many times before. The value of bin() is >> really rather minimal except when you're just learning about binary >> numbers; and then writing it yourself is a useful exercise. >> >> I'm not saying that bin() is useless -- but IMO its (small) value >> doesn't warrant making, maintaining and documenting a new built-in >> function. > > And for some reason no one wants to propose it for any particular stdlib > module... binascii.a2b_bin and binascii.b2a_bin might actually make sense. . . Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Brainstorming: literal construction hooks
Michael Urman wrote: > There's a lot of holes to this story, including at least how these > functions are registered, and which additional arguments (if any) are > necessary. Shall we try to fill these holes in? Answering without checking the source (which is undoubtedly a bad idea), but this sounds like something else that could be addressed if it was possible to either register an alternate AST compiler for a scope, or else get hold of an AST and recompile it. (The former works for modules and functions, the latter works only for functions) Even if it was only a matter of some additional keyword arguments to compile and/or exec, it could at least be of benefit for plugin code or an interactive interpreter loop. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PEP - string.format
On 4/22/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > That (adding .format() in 2.6) occurred to me, but I dismissed it for some > reason. It can't have been a very good reason though, since I sure can't > remember what it was. > > In which case, Talin's PEP should probably suggest this as the implementation > strategy - python3warn and the instrumented python build can do their best to > pick up usage of % formatting, and we can add .format() to 2.6 so that forward > compatible code can be written in later 2.x releases. > > Now that I think about it, simply having python3warn pick up all uses of % in > a print statement should pick up many of the uses of string formatting. (Not > all, obviously, but a lot of them) There's a different approach to discovering future incompatibilities than parsing the source code. I had originally forgotten about this approach even though I'd used the very thing myself years ago! It was pointed out to my by an audience member during my preview of my Python 3000 talk at the ACCU Silicon Valley chapter. I added a brief description to PEP 3000. The approach is to run your app (or a high-coverage test suite) with an instrumented Python 2.x interpreter which spits out warnings (or some other log) for run-time events that are known to break in Python 3.0. I did this years ago to find all instances of int/int in the standard library. It is trivial to do this for things like discovering string formatting. I believe it can also be used to discover cases where the result of dict.keys() etc. is used beyond iteration (we modify keys() to return a subclass of list that spits out a warning for all forms of access except __iter__()). This approach is complementary to the source code inspection approach; we should plan to use both in conjunction to get the maximally successful conversion (either automatic translation or at least automatic indication of issues to be changed). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Brainstorming: literal construction hooks
On 4/22/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Michael Urman wrote: > > There's a lot of holes to this story, including at least how these > > functions are registered, and which additional arguments (if any) are > > necessary. Shall we try to fill these holes in? > > Answering without checking the source (which is undoubtedly a bad idea), but > this sounds like something else that could be addressed if it was possible to > either register an alternate AST compiler for a scope, or else get hold of an > AST and recompile it. (The former works for modules and functions, the latter > works only for functions) > > Even if it was only a matter of some additional keyword arguments to compile > and/or exec, it could at least be of benefit for plugin code or an interactive > interpreter loop. Hm... Using the AST seems overkill for this (unless you want to do it without modifying the Python interpreter in any way). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] New built-in function: bin()
That makes more sense than a builtin. Note that oct() and hex() return something that's a valid Python literal. There are no binary literals (nor should there be IMO). On 4/22/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Ian Bicking wrote: > > Guido van Rossum wrote: > >> This has been brought up many times before. The value of bin() is > >> really rather minimal except when you're just learning about binary > >> numbers; and then writing it yourself is a useful exercise. > >> > >> I'm not saying that bin() is useless -- but IMO its (small) value > >> doesn't warrant making, maintaining and documenting a new built-in > >> function. > > > > And for some reason no one wants to propose it for any particular stdlib > > module... > > binascii.a2b_bin and binascii.b2a_bin might actually make sense. . . > > Cheers, > Nick. > > -- > Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia > --- > http://www.boredomandlaziness.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Brainstorming: literal construction hooks
Guido van Rossum wrote: > On 4/22/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: >> Michael Urman wrote: >>> There's a lot of holes to this story, including at least how these >>> functions are registered, and which additional arguments (if any) are >>> necessary. Shall we try to fill these holes in? >> Answering without checking the source (which is undoubtedly a bad idea), but >> this sounds like something else that could be addressed if it was possible to >> either register an alternate AST compiler for a scope, or else get hold of an >> AST and recompile it. (The former works for modules and functions, the latter >> works only for functions) >> >> Even if it was only a matter of some additional keyword arguments to compile >> and/or exec, it could at least be of benefit for plugin code or an >> interactive >> interpreter loop. > > Hm... Using the AST seems overkill for this (unless you want to do it > without modifying the Python interpreter in any way). Strawman. . . from ast import Compiler from decimal import Decimal class MyCompiler(Compiler): def build_float(self, literal): return Decimal(literal) # Pass this to compile or exec via an ast_compiler argument # It may even be possible to permit it as an argument to __import__ The basic idea would be to have a compiler object that delegated compilation operations to the internal AST compiler, but gave subclasses the ability to easily override certain aspects of the process - like processing different kinds of literal. No matter what, permitting these kinds of hooks is going to require alterations to the process of compiling the AST to the bytecode - and subclassing is an excellent way of allowing some aspects of an implementation to be overridden while leaving other aspects alone. This is just an idea, as I doubt I'd ever use the ability no matter how it was implemented :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Brainstorming: literal construction hooks
On 4/22/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> No matter what, permitting these kinds of hooks is going to require
> alterations to the process of compiling the AST to the bytecode - and
> subclassing is an excellent way of allowing some aspects of an implementation
> to be overridden while leaving other aspects alone.
Oops, I have to concur.
I was thinking that it could all be done later, at run-time. That
makes sense for things like [...] and {...} but doesn't really work
for floating point or even string literals -- you can't afford the
overhead of calling a default hook for each literal at run-time, and
passing the default value to the hook doesn't work in the case of
floats or strings.
Unfortunately a compile-time hook is much more painful to add to the
language because it means adding new syntax just to specify the hooks.
:-(
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Brainstorming: literal construction hooks
Guido van Rossum wrote: > It's an interesting idea; it's been brought up before but nobody AFAIK > has ever implemented it. I like the scoping requirement. can we add support for XML literals while we're at it? http://effbot.org/zone/idea-xml-literal.htm ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Brainstorming: literal construction hooks
> can we add support for XML literals while we're at it? > > http://effbot.org/zone/idea-xml-literal.htm The reason the literals aren't returned as ElementTree Elements is because ElementTree didn't exist back then, right? Because that particular integration would make a lot of sense. Regards, Manuzhai ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Brainstorming: literal construction hooks
On 4/22/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > > It's an interesting idea; it's been brought up before but nobody AFAIK > > has ever implemented it. I like the scoping requirement. > > can we add support for XML literals while we're at it? > > http://effbot.org/zone/idea-xml-literal.htm Javascript has an ECMA standardized extension that supports this (ECMA-357 or E4X). Groovy has a different approach that doesn't blend the two syntaxes, but rather gives you more native syntax for constructing DOM trees (or event streams; it wasn't clear from the description I saw today). That makes perhaps more sense; it avoids the lexical ambiguities and a parentheses-based syntax is easier to type than XML. Maybe this example (which I am making up) suffices: frag1 = element["some content"] frag2 = element["some content", child(attribute='value')["spam & egg"]] -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Brainstorming: literal construction hooks
On 4/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > It's an interesting idea; it's been brought up before but nobody AFAIK > has ever implemented it. I like the scoping requirement. I suggest you > try to implement it and see how well it works. I'll look into that now that I know it's not a discard idea. > You probably also want to be able to hook list, tuple and dict > displays (perhaps by supplying an alternative factory function). Maybe I've not been awake long enough, but I don't see what I'd want to hook here that isn't already done using a subclass with an overrided __str__ or __repr__ method. On 4/22/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > class MyCompiler(Compiler): > def build_float(self, literal): > return Decimal(literal) > > # Pass this to compile or exec via an ast_compiler argument > # It may even be possible to permit it as an argument to __import__ I definitely like the look of this for the complie/exec usage, but it definitely makes for a more annoying general usage. I'm not sure about the __import__ way, as it smells of spooky effects, but might be a good practical back door to bring a submodule in line. For in-module effect, maybe some special import could pull in a compiler class instance used only for the current module, allowing its build_xyz methods be replaced. from __ast__ import compiler compiler.build_float = Decimal# on an instance, so no 'self' parameter If something like that sounds reasonable for usage, I'll start looking into how it looks for implementation. (Probably a big ball of mud! And sounds like it depends on the python-side interface to the ast - I've lost track if that's solidified yet.) :) Michael -- Michael Urman http://www.tortall.net/mu/blog ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] XML literals
Le samedi 22 avril 2006 à 16:17 +0100, Guido van Rossum a écrit : > Groovy has a different approach that doesn't blend the two syntaxes, > but rather gives you more native syntax for constructing DOM trees (or > event streams; it wasn't clear from the description I saw today). That > makes perhaps more sense; it avoids the lexical ambiguities and a > parentheses-based syntax is easier to type than XML. Maybe this > example (which I am making up) suffices: > > frag1 = element["some content"] > > frag2 = element["some content", > child(attribute='value')["spam & egg"]] You might want to take a look at CDuce. It is a functional language dedicated to transformation of XML documents. It has a powerful typing system (including structural pattern matching), and also features a clever syntax for representing XML fragments in-code. Here is a simplified example from the tutorial : let parents : ParentBook = [ [ "Clara" [ [ "Pål André" [] ] ] "[EMAIL PROTECTED]" "314-1592654" ] [ "Bob" "271828" "66260" ] ] http://www.cduce.org/tutorial.html Regards Antoine. ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Brainstorming: literal construction hooks
"Guido van Rossum" <[EMAIL PROTECTED]> wrote: > > On 4/22/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > > Guido van Rossum wrote: > > > > > It's an interesting idea; it's been brought up before but nobody AFAIK > > > has ever implemented it. I like the scoping requirement. > > > > can we add support for XML literals while we're at it? > > > > http://effbot.org/zone/idea-xml-literal.htm > > Javascript has an ECMA standardized extension that supports this > (ECMA-357 or E4X). > > Groovy has a different approach that doesn't blend the two syntaxes, > but rather gives you more native syntax for constructing DOM trees (or > event streams; it wasn't clear from the description I saw today). That > makes perhaps more sense; it avoids the lexical ambiguities and a > parentheses-based syntax is easier to type than XML. Maybe this > example (which I am making up) suffices: > > frag1 = element["some content"] > > frag2 = element["some content", > child(attribute='value')["spam & egg"]] Nevow.stan has a very similar method for generating *ML with (attribute='value')[content], but I've personally found that using only function-call semantics to create children and attributes for *ML in Python is much more convenient; allowing one to use any of the following and get a reasonable method for *ML object re-use: (attribute='value')(content) (content)(attribute='value') (content, attribute='value') A working system for handling this kind of *ML generation is available in the ASPN Python Cookbook here (the non-closing tags portion may not be correct for any *ML, even HTML): http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440563 - Josiah ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Brainstorming: literal construction hooks
On 4/22/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: > Nevow.stan has a very similar method for generating *ML with > (attribute='value')[content], but I've personally found that using only > function-call semantics to create children and attributes for *ML in > Python is much more convenient; allowing one to use any of the following > and get a reasonable method for *ML object re-use: > (attribute='value')(content) > (content)(attribute='value') > (content, attribute='value') That makes sense, so forget the crazy idea of overloading __getitem__. The problem with any of these is that you either have to import (or define, etc.) an object for each element that you want to name, so you can write foo(x=1) to mean (this is what my own parsexml module does, see SF 1337648); or you have to use a helper function or object, e.g. T.foo(x=1) as in the recipe below. > A working system for handling this kind of *ML generation is available > in the ASPN Python Cookbook here (the non-closing tags portion may not > be correct for any *ML, even HTML): > http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440563 Cool. Unfortunately, all of these schemes break down if you have non-identifier characters in attribute or element names, or if you want to use namespaces, or if you want to insert entity references, XML comments, or other funky stuff like DTDs or processing elements. (I'm sure all of these can be hacked in one way or another but by the time you've covered all that ground it won't be as pretty, and the relative advantage over blending XML syntax is diminished.) Also, an important aspect of JavaScript's E4X standard is a standard object model. I believe they use a standard DOM style API. In Python unfortunately we have many different object models for XML -- minidom, ElementTree, and I believe the XML-sig has its own standard (4Suite?). I could handle multiple implementations (quack!) but we'd have to pick an API -- AFAIK ElementTree and the DOM API are incompatible. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
[Python-3000] Open Issues for string.format PEP
Here's a condensed list of the open issues that have been raised by people so far: (Well, edited somewhat - I'm including 'major' issues, not minor nits -- we can discuss those once the major issues are settled.) 1) Whether to drop the optional parts of the proposal: -- support for field expressions (was: locals() support) -- support for direct access to current scope (was: locals() support) 2) Should this PEP be targeted at Python 2.6 or 3.0? 3) Role and usage of custom formatters: "string".fformat( formatter, ... ) vs. MyFormat( "string" ).format( ... ) (note: I want to make it clear that the purpose of custom formatters is to override the formatting on a *per-field basis*, but at the same time the custom formatter should have access to the surrounding context.) 4) Should there be a way to pass in a dict argument without flattening it via **args? 5) Should the implementation attempt to detect unused arguments? I'd like to get some sense of the answers before the next revision of the PEP. -- Talin ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Brainstorming: literal construction hooks
Guido van Rossum wrote: > Unfortunately, all of these schemes break down if you have > non-identifier characters in attribute or element names, or if you > want to use namespaces, or if you want to insert entity references, > XML comments, or other funky stuff like DTDs or processing elements. a useful design should support non-identifier characters, name- spaces, and comments/processing instructions, but should other- wise work on the infoset level (i.e. CDATA sections and entities doesn't have to be part of this). not sure about DTD:s; they're a whole can of works... (but I'm sure E4X etc can provide some ideas here). > Also, an important aspect of JavaScript's E4X standard is a standard > object model. I believe they use a standard DOM style API. In Python > unfortunately we have many different object models for XML -- minidom, > ElementTree, and I believe the XML-sig has its own standard (4Suite?). > I could handle multiple implementations (quack!) but we'd have to pick > an API -- AFAIK ElementTree and the DOM API are incompatible. why do you think I posted this to the "literal construction hooks" thread ? ;-) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Open Issues for string.format PEP
On 4/22/06, Talin <[EMAIL PROTECTED]> wrote: > 1) Whether to drop the optional parts of the proposal: >-- support for field expressions (was: locals() support) >-- support for direct access to current scope (was: locals() support) I'd skip this. KISS etc. > 2) Should this PEP be targeted at Python 2.6 or 3.0? Both equally. We could implement it in the 3.0 branch first. > 3) Role and usage of custom formatters: > >"string".fformat( formatter, ... ) > > vs. > >MyFormat( "string" ).format( ... ) > > (note: I want to make it clear that the purpose of custom formatters is to > override the formatting on a *per-field basis*, but at the same time the > custom formatter should have access to the surrounding context.) I think a single format() method with a standard signature makes more sense. That way you can abstract the choice of formatter out. > 4) Should there be a way to pass in a dict argument without flattening it via > **args? Questionable. TOOWTDI; OTOH the flattening could be expensive. If we can figure out a way to optimize away the flattening as long as the callee is implemented in C, I'm in favor of dropping **kwds. > 5) Should the implementation attempt to detect unused arguments? I think so; the % operator is very strict about this and it's useful in debugging. > I'd like to get some sense of the answers before the next revision of the PEP. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
[Python-3000] Minor hitch writing the Function Signature PEP
I realized that the "Keyword-Only Arguments" and the "Function Signature" proposals could be written as two separate PEPs, since there is only minimal interaction between the two. However, I started writing some use case examples for the Function Signature PEP, and ran into a slight snag. My use case was to add preconditions to a function, where the precondition refers to specific arguments by name: @precondition( y=NotNegative ) def power( x, y ): ... ...where 'NotNegative' is a function which simply does an assert( value >= 0 ). The general idea is that 'precondition' would take a **kwds argument, and for each key, it would look up the correspondingly named argument in the function signature. It would then create a wrapper function which would validate each argument against its corresponding precondition before calling the real function. Sounds simple enough, right? Well the problem is that decorator functions don't have access to the machinery that binds input arguments for formal parameters. So the wrapper function has a hard time knowing which input arguments will be bound to which formal params, without having to duplicate the runtime's algorithm to do this. In order to be a generic wrapper, the wrapper will have the form: def wrapper( *args, **kwargs ): ... So where is 'y' in all of that? It could be the second argument in *args; it could be the first argument in *args if x is passed in as a keyword argument; or it could be in the **kwargs dict. I'm not saying that solving this is impossible; what I am saying is that its: -- slow -- makes the example very complicated and hard to understand. And, as we all know, if its hard to understand then its probably wrong. -- Talin ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Minor hitch writing the Function Signature PEP
On 4/22/06, Talin <[EMAIL PROTECTED]> wrote: > Well the problem is that decorator functions don't have access to the > machinery > that binds input arguments for formal parameters. So the wrapper function has > a > hard time knowing which input arguments will be bound to which formal params, > without having to duplicate the runtime's algorithm to do this. > > In order to be a generic wrapper, the wrapper will have the form: > > def wrapper( *args, **kwargs ): >... > > So where is 'y' in all of that? It could be the second argument in *args; it > could be the first argument in *args if x is passed in as a keyword argument; > or > it could be in the **kwargs dict. [Wild idea alert!] Maybe the signature object could have a "bind" method sig.bind(args, kwargs) which returns a dictionary mapping argument names to values? In effect, this exposes the internal mechanism for reuse. Paul. ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Minor hitch writing the Function Signature PEP
On 4/22/06, Paul Moore <[EMAIL PROTECTED]> wrote: > On 4/22/06, Talin <[EMAIL PROTECTED]> wrote: > > Well the problem is that decorator functions don't have access to the > > machinery > > that binds input arguments for formal parameters. So the wrapper function > > has a > > hard time knowing which input arguments will be bound to which formal > > params, > > without having to duplicate the runtime's algorithm to do this. > > > > In order to be a generic wrapper, the wrapper will have the form: > > > > def wrapper( *args, **kwargs ): > >... > > > > So where is 'y' in all of that? It could be the second argument in *args; it > > could be the first argument in *args if x is passed in as a keyword > > argument; or > > it could be in the **kwargs dict. > > [Wild idea alert!] > > Maybe the signature object could have a "bind" method > >sig.bind(args, kwargs) > > which returns a dictionary mapping argument names to values? In > effect, this exposes the internal mechanism for reuse. I don't see why the signature object has to be created for every function automatically; I don't see it being a constantly needed thing. If something like a signature built-in was created it could be called on objects as needed to create the signature object as well as bind it to __signature__ for future use to avoid duplicated work. This would allow a decorator to assign to the decorator the signature object from the wrapped function:: def decorator(func): def wrapper(*args, **kwargs): # ... stuff wrapper.__signature__ = signature(func) return wrapper Or something along those lines. I am on vacation right now but I am still planning on digging up my signature PEP which covers all of this. -Brett ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PEP - string.format
Talin wrote:
>> Thus you can't nest formatters, e.g., {0:pad(23):xmlquote}, unless the
>> underlying object understands that. Which is probably unlikely.
>
> At this point, I'm thinking not, although I could be convinced otherwise.
> Remember, that you can accomplish all of the same things by processing the
> input
> arguments; The conversion specifiers are a convenience.
>
> Also, in your model, there would be a distinction between the first specifier
> (which converts the object to a string), and subsequent ones (which modify the
> string). My complexity senses are tingling...
I would assume that any formatting can produce any object, and only at
the end will the object (if necessary) be converted to a string with str().
>> 3) Otherwise, check the internal formatter within
>> string.format that contains knowledge of certain builtin
>> types.
>>
>> If it is a language change, could all those types have __format__
>> methods added? Is there any way for the object to accept or decline to
>> do formatting?
>
> Good question. I suspect that it may be impractical to add __format__ to all
> built-in types, so we should plan to allow a fallback to an internal
> formatter.
Yeah, on further thought while this would be possible for py3k, some
form of this could be usefully done as a module before that.
>> 4) Otherwise, call str() or unicode() as appropriate.
>>
>> Is there a global repr() formatter, like %r? Potentially {0:repr} could
>> be implemented the same way by convention, including in object.__format__?
>
> Good idea. (Should there be a *global* custom formatter? Plugins? Subject of a
> separate PEP I think.)
I don't think there should be any modifiable global formatter. As an
implementation detail there may be one, but one module shouldn't be able
to change the way formatting works for everyone.
But repr() is something of a special case, because it's so widely
applicable.
>> The formatter should examine the type of the object and the
>> specifier string, and decide whether or not it wants to handle
>> this field. If it decides not to, then it should return False
>> to indicate that the default formatting for that field should be
>> used; Otherwise, it should call builder.append() (or whatever
>> is the appropriate method) to concatenate the converted value
>> to the end of the string, and return True.
>>
>> Well, I guess this is the use case, but it feels a bit funny to me. A
>> concrete use case would be appreciated.
>
> The main use case was that the formatter might need to examine the part of the
> string that's already been built. For example, it can't handle expansion of
> tabs
> unless it knows the current column index. I had originally planned to pass
> only
> the column index, but that seemed too special-case to me.
Hmm... so the tab-aligning formatter would look for tab alignment
formatting specifications? An actual implementation of a tab aligning
custom formatter would probably make this easier to think about.
>> A fairly high degree of convenience for relatively small risk can
>> be obtained by supporting the getattr (.) and getitem ([])
>> operators. While it is certainly possible that these operators
>> can be overloaded in a way that a maliciously written string could
>> exploit their behavior in nasty ways, it is fairly rare that those
>> operators do anything more than retargeting to another container.
>> On other other hand, the ability of a string to execute function
>> calls would be quite dangerous by comparison.
>>
>> It could be a keyword option to enable this. Though all the keywords
>> are kind of taken. This itself wouldn't be an issue if ** wasn't going
>> to be used so often.
>
> The keywords are all taken - but there are still plenty of method names
> available :) That's why "fformat" has a different method name, so that we can
> distinguish the custom formatter parameter from the rest of the params.
>
> Unfortunately, this can't be used too much, or you get a combinatorial
> explosion
> of method names:
>
>string.format
>string.fformat
>string.format_dict
>string.fformat_dict
>...
Yeah... that's not so pretty ;). Things like .update() and even %
handle both cases without too much ambiguity.
>> One other thing that could be done to make the debugging case
>> more convenient would be to allow the locals() dict to be omitted
>> entirely. Thus, a format function with no arguments would instead
>> use the current scope as a dictionary argument:
>>
>> print "Error in file {p.file}, line {p.line}".format()
>>
>> An alternative would be to dedicate a special method name, other
>> than 'format' - say, 'interpolate' or 'lformat' - for this
>> behavior.
>>
>> It breaks some conventions to have a method that looks into the parent
>> frame; but the use cases are very stron
Re: [Python-3000] Changing the import machinery
On 4/22/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > > > I'm afraid I disagree. PEP 302 actually has some tremendous advantages > > > over a pure objects-on-sys.path approach: > > > > > > * Strings can be put in any configuration file, and used in .pth files > > > > > > * Strings can be put in environment variables (like PYTHONPATH). > > > > > > * Strings can be printed out, with all their contents showing and nothing > > > hidden > > > > > > In short, strings are better for humans. > > > > I think I like this. I wonder if there's a parallel with my preference > > for strings as paths instead of path objects... > > And strings as exceptions, and Tcl instead of Python ? ;-) > > Sorry, but I don't buy this argument at all. Of course you need a > way to map from external path descriptions (PYTHONPATH, registry > entries, etc) to sys.path contents, but ruling that the things you're > manipulating *inside* a Python program must be strings so you "can > print them out with all their contents showing and nothing hidden" > doesn't strike me as very Pythonic. > > The target audience for this is Python programmers, after all, and > Python programmers know how to inspect Python objects -- as long as > they can find them, which isn't the case with today's extended import > design, which *hides* lots of stuff in *separate* semi-secret > registries. If you put all this back on the path, it'll be a lot > easier to find and manipulate. > > I could quote the "If the implementation is hard to explain, it's a > bad idea." zen here, but I'll quote Sean McGrath's 20th python zen > instead: > > "Things should be as complex as necessary but not more complex." > > and offer a "let's get back to the basics and add stuff, instead of > assuming that the status quo is complex and complicated because it has > to be" solution. Here's an outline, off the top of my head: > > 1. sys.path can contain strings or import handlers > > 2. Strings work as today; as paths that a builtin import handler > uses to look for packages or modules (flyweight-style). > > 3. Import handlers are duck-typed objects that implement a > simplified version of the PEP 302 protocol. Handlers map dotted > module paths to resources, where a resource can be a Python > module, a Python package (a module container), or some other > resource. Handlers are responsible for creating and populating > module objects; whatever they return is stored in sys.modules and > bound to the import target. > > I'm 50/50 on making the import machinery fully type agnostic; that > is, allowing the import handler to return *any* kind of object > also for ordinary imports. Importing e.g. PIL images and pre- > parsed XML resources and Cheetah templates makes perfect sense > to me. > I say go agnostic. No need to force a specific return type if the import handler knows what it is doing. We are all consenting adults, after all. > 4. A support library provides the following mechanisms: > > - An import handler for builtin/frozen objects (with > corresponding hooks on the C API site, so that apps can > register things to be treated as builtins). > > - An import handler for the standard library (*all of > it*, minus site-packages!) > > - An import handler for directory names (used for string path > items) > > - A registry for path specifier syntaxes > > - A parser for external path descriptions, which uses the > registry to map from path components to import handlers > > - (possibly) Some helpers for user-provided import handlers > (to be factored out from such handlers, rather than be > designed up front) > All sounds good. Basically anything needed for getting a handler for string and zip files probably could be factored out and put here. > 5. Remove PTH support, and possibly also a lot of the site- > packages related stuff in site.py. I'm 50/50 on *requiring* code > to specify what non-core libraries they want to use, before they > can import them. I'm also 50/50 on making some additions to the > import statement syntax, to make some operations easier (import > ... using handler), but I'll leave that for another post. > I don't know about the requirement stuff, but I would not mind seeing .pth files go (but that is partially because I rewrote that code when I partially cleaned up site.py at PyCon years ago and I am still bitter =) . As for specifying external dependencies, if we added a global namespace that wouldn't be an issue since it could be detected by the import machinery automatically. And having something like ``from foo.bar import baz using fancy_import_handler`` seems reasonable, although not necessary. > This would cleanly address every deployment scenario and custom > importer that I've used with a (near) mininum of core support,
[Python-3000] rough draft signature PEP
[I am posting to python-3000 since this is where the parameter list ideas are being discussed, but this is probably generic enough to eventually make it into the 2.x line] Here is a rough draft of a PEP I wrote last summer after I had Guido come for lunch at Google when I was interning there (i.e., a little old =) . Someone (I think Philip) had suggested something like this back then but it didn't go any farther. I liked the idea and I asked Guido at lunch if he was okay for it; he was. So I wrote the following PEP along with a Python implementation (attached, along with test cases). It is still a rough draft since I am on vacation on top of visiting my dad for his birthday and thus cannot put a ton of time into this at the moment, so don't consider this a final version in any way. There is already a list of things to consider and I am sure there are some things discussed during the new parameter list ideas that could stand to be worked in. I am quite happy to work on finishing this PEP so that Talin can focus on the parameter list PEP. So just comment away and I will work on incorporating them as time permits. -Brett -- PEP: XXX Title: Introducing the __signature__ Attribute Version: $Revision: 1.5 $ Last-Modified: $Date: 2005/06/07 13:17:37 $ Author: Brett Cannon <[EMAIL PROTECTED]> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: XX-XXX- Post-History: XXX * Break abstract into Abstract and Rationale * write signature() function - maybe not in built-ins; inspect instead? * look up object identity (issue|crisis) as reference * automatically apply signature when decorator called? * make more general by having an attribute that points to original object being wrapped that introspection checks first? - __wrapping__ - __identity__ - __introspect__ - __metadata__ Abstract Decorators were introduced to Python in version 2.4 . Their introduction provided a syntactically easy way to "decorate" functions and methods. The ease of use has allowed the use of functions that wrap other functions and methods to become more prevalent in Python code. Unfortunately, one side-effect of the increased use of decorators is the loss of introspection on the function being wrapped. Most decorators are not meant to be directly noticed by someone using the code; decorators are meant to be heard, not seen. But when a decorator is used on a function or method that returns a new function that wraps the original, introspection will occur on the wrapping function, not the wrapped one. :: def yell(func): def wrapper(*args, **kwargs): print "Hi!" return func(*args, **kwargs) return wrapper @yell def wrapped_one_arg(x): pass def unwrapped_one_arg(x): pass if __name__ == '__main__': from inspect import getargspec print getargspec(wrapped_one_arg) == getargspec(unwrapped_one_arg) To help deal with this phenomenon, the __signature__ attribute is being proposed. It is to be an optional attribute on objects where introspection of function parameters may be performed. It contains an instance of the Signature class that represents all relevant data that one might want to know about the call signature of a function or method. This allows one to assign to a wrapping function's __signature__ attribute an instance of the Signature class that represents the wrapped function or method, thus allowing introspection on the wrapping function to reflect the call signature of the wrapped function. The Signature also works for classes (representing the call signature for instantiation) and instances (for the ``__call__`` method of an instance). A built-in, aptly named ``signature``, is also being proposed. When passed an object that meets the proper requirements, it will either return a new instance of the Signature class or the pre-existing object for the object passed in. Types of Argument Parameters Python has a fairly rich set of function parameter possibilities. To start, there are required arguments; ``def positional(x): pass``. These types of parameters require an argument be passed in for them. Next, there are default arguments; ``def defaults(x=42): pass``. They have a default value assigned to them if no argument is passed in for that parameter. They are optional, though, unlike required arguments. Lastly, there are excess arguments; ``def excess(*args, **kwargs): pass``. There are two types of excess arguments. One type is an excess positional argument (``*args``). When this type of parameter is present all positional arguments provided during the call are collected into a tuple and assigned to the excess positional argument. The other type of parameter is an excess keyword argument. All keyword arguments that are not directly assigned to an existing keyword parameter are collected in
[Python-3000] Removing __getslice__ et al.
A long-standing part of Py3K is removing 'old style slices' (meaning the __get/set/delslice__ methods and the sq_slice/sq_ass_slice sequence-struct functions, but not slice objects.) I started removing them, only to find out that it's damned inconvenient to make all slicing go through tp_as_mapping->mp_subscript, for two reasons: - Many classes don't behave as mapping at all, so the mp_subscript function (and the whole tp_as_mapping struct) would be added just for the benefit of accepting slices, which is really a sequence thing, not a mapping thing. - There's actually a PyMapping_Check that relies on sq_slice: a type is a mapping type when it has tp_as_mapping->mp_subscript but not tp_as_sequence->sq_slice. I'm not sure how to express that if there is no special method for slicing. So, I imagine we need a special (C level) hook for slicing after all, just one that always takes a slice object (or tuple of slice-objects-or-tuples-of-same. Oh, and/or Ellipsis. Did I forget anything? :) Either that, or a set of conveniency functions (which we already have, for the most part) and a mapping/sequence-agnostic getitem/subscript. But if we do that, we need a new way of implementing PyMapping_Check. (While on the subject, howmuch of the C API dealing with slices should be adjusted? There's PySequence_GetSlice() that takes Py_ssize_t's, which is (IMHO) pretty convenient for C code, but it'd have to create a slice object behind the scenes. And maybe creating a slice object manually isn't that much effort, after all.) -- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Brainstorming: literal construction hooks
Michael Urman wrote: > For in-module effect, maybe some special import could pull in a > compiler class instance used only for the current module, allowing its > build_xyz methods be replaced. > > from __ast__ import compiler > compiler.build_float = Decimal# on an instance, so no 'self' parameter > > If something like that sounds reasonable for usage, I'll start looking > into how it looks for implementation. (Probably a big ball of mud! And > sounds like it depends on the python-side interface to the ast - I've > lost track if that's solidified yet.) :) I deliberately left out the in-module effect, because Python compiles the whole module before executing any of it. Having in-module code trying to hook activities that happen before hand is challenging to say the least (that said, 'from __future__ import ...' statements have a double life as normal code and compiler directives, so it's obviously not impossible) OTOH, if you can get something working for the compile/exec/__import__ use cases, then a metapath entry can be used to experiment with applying it auto-magically on module import (and poking around inside the module to figure out what modifications to make). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Brainstorming: literal construction hooks
Guido van Rossum wrote:
> On 4/22/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> No matter what, permitting these kinds of hooks is going to require
>> alterations to the process of compiling the AST to the bytecode - and
>> subclassing is an excellent way of allowing some aspects of an implementation
>> to be overridden while leaving other aspects alone.
>
> Oops, I have to concur.
>
> I was thinking that it could all be done later, at run-time. That
> makes sense for things like [...] and {...} but doesn't really work
> for floating point or even string literals -- you can't afford the
> overhead of calling a default hook for each literal at run-time, and
> passing the default value to the hook doesn't work in the case of
> floats or strings.
>
> Unfortunately a compile-time hook is much more painful to add to the
> language because it means adding new syntax just to specify the hooks.
> :-(
This is why I'm suggesting Michael look at the exec/compile plugin execution
use case first - then we have control code that runs without the hooks that
can ask for other code to be compiled *with* the hooks. (similar to the way
the compile statement can already force the use of certain __future__
directives)
I think doing that cleanly is a big task in itself, but if it works out, we'll
have a much better idea of what compiler directives might be needed so a
module or function could request a particular compiler.
For example, we may decide that hooking individual bits and pieces from within
the module is right out, but provide a general "from
__compiler__.my.pkg.namespace import MyCompiler" directive that tells the
compiler "retrieve my.pkg.namespace.MyCompiler from the list of registered
compilers and use it to compile this module rather than the standard compiler".
It would then be up to the application to ensure the appropriate compiler was
available before importing the module. If you tried to import such a module
before the appropriate compiler has been registered then you'd get an
ImportError.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Removing __getslice__ et al.
Thomas Wouters wrote: > > A long-standing part of Py3K is removing 'old style slices' (meaning the > __get/set/delslice__ methods and the sq_slice/sq_ass_slice sequence-struct > functions, but not slice objects.) I started removing them, only to find > out that it's damned inconvenient to make all slicing go through > tp_as_mapping->mp_subscript, for two reasons: > > - Many classes don't behave as mapping at all, so the mp_subscript function > (and the whole tp_as_mapping struct) would be added just for the benefit of > accepting slices, which is really a sequence thing, not a mapping thing. These types already provide tp_as_sequence->sq_item. Why would they want to provide tp_as_mapping->mp_subscript as well? > - There's actually a PyMapping_Check that relies on sq_slice: a type is a > mapping type when it has tp_as_mapping->mp_subscript but not > tp_as_sequence->sq_slice. I'm not sure how to express that if there is no > special method for slicing. How about changing it to check tp_as_sequence->sq_item instead? (that will still work for dictionaries - they only define tp_as_sequence because there isn't a slot to hook "__contains__" in the tp_as_mapping structure) On a slightly different note, we should fix the definition of sequence vs mapping so that PySequence_Check and PyMapping_Check work for arbitrary Python classes. For example, a flag "__sequence__ = True" that type() checked when constructing the class. If the flag was missing, both tp_as_mapping->mp_subscript and tp_as_sequence->sq_item would be filled in with __getitem__ (as they are now). If the flag was present and false, only tp_as_mapping would be filled in. If the flag was present and true, only tp_as_sequence would be filled in. > (While on the subject, howmuch of the C API dealing with slices should be > adjusted? There's PySequence_GetSlice() that takes Py_ssize_t's, which is > (IMHO) pretty convenient for C code, but it'd have to create a slice object > behind the scenes. And maybe creating a slice object manually isn't that > much effort, after all.) I think we should leave abstract.h alone - Getting rid of __getslice__ at the Python level is a good thing, but simply fixing these API functions to "do the right thing" is easier than breaking all the code that currently uses them. Should we add a convenience function PySlice_FromIndices to the slice API that accepts Py_ssize_t's rather than PyObjects? Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] rough draft signature PEP
Brett Cannon python.org> writes: > [I am posting to python-3000 since this is where the parameter list > ideas are being discussed, but this is probably generic enough to > eventually make it into the 2.x line] > > Here is a rough draft of a PEP I wrote last summer after I had Guido > come for lunch at Google when I was interning there (i.e., a little > old =) . Someone (I think Philip) had suggested something like this > back then but it didn't go any farther. I liked the idea and I asked > Guido at lunch if he was okay for it; he was. > > So I wrote the following PEP along with a Python implementation > (attached, along with test cases). It is still a rough draft since I > am on vacation on top of visiting my dad for his birthday and thus > cannot put a ton of time into this at the moment, so don't consider > this a final version in any way. There is already a list of things to > consider and I am sure there are some things discussed during the new > parameter list ideas that could stand to be worked in. I am quite > happy to work on finishing this PEP so that Talin can focus on the > parameter list PEP. So just comment away and I will work on > incorporating them as time permits. Sounds good. A couple of comments: 1) I a still confused (see the "minor hitch" thread) as to how the signature information can be used without either duplicating the interpreter's parameter-binding algorithm, or somehow giving access to it. In other words, having access to signature information isn't very useful unless there is a straightforward and efficient way to map incoming arguments to specific signature slots. Because the decorators execute *before* this step normally happens, they can't just look and see which particular slot an argument got assigned to, they have to calculate it. The actual-to-formal mapping that's used in the interpreter itself can't be directly exposed, because it's not data driven (apparently - this is one of the parts of the intepreter that I don't understand yet.) A duplicate implementation suffers from two drawbacks: First, any implementation will need to be kept in sync with the interpreter. Second, the data structure that the mapping algorithm has to deal with (i.e. the signature object) is going to be in a form that is less efficient (i.e. since it needs to be constructable via Python code, it can't be a simple C structure like argument_ty.) 2) I noticed in your PEP that you followed the same mental model as is currently used in the compiler, which is that *args and **args are treated as special cases. In other words, the description of a function's arguments consists of an array of "regular" arguments, plus a couple of "special" argument fields. My mental model is a little different, as I tend to see the argument as a single list, where arguments have different modifiers, where * and ** are modifiers. In other word, my model follows more closely (IMHO) the way that arguments are read by the programmer. To show the difference between the two models, lets create an algorithm that populates the parameter slots from a set of input arguments. For simplicity, lets just consider positional arguments, including varargs arguments. In the case where the varargs is considered a separate slot: i = 0 while i < numInputArgs: if i <= regularSlotCount: slot[ i ] = args[ i ] i += 1 if i < numInputArgs: slot[ i ] = args[ i: ] In the case where there's a single list: i = 0 s = 0 while i < numInputArgs: if modifiers[ s ] == VARARGS: slot[ s ].append( args[ i ] ) else: slot[ s ] = args[ i ] s += 1 i += 1 (Note that neither of these functions is intended to be optimal.) I'm not saying that my model is necessarily better. Its just how I think about it. The only advantage that I would claim is that it more readily allows for future kinds of "special" arguments, by extending the meaning of the 'modifier' attribute. Here's what I had written in the PEP: Specification The specification defines a new function object attribute, __signature__, which contains a tuple containing a list of parameter descriptions. Each parameter description will be a tuple containing the following elements: [0] - The string name of the parameter. [1] - The Python type of the parameter, if a type has been specified. If none has been specified, this field will contain None. [2] - The parameter modifier (see below.) [3] - The default value of the parameter, if there is one. If there is no default value, then the 4th field will be absent - in other words, it will be a 3-tuple rather than a 4-tuple. This allows discrimination between a parameter whose default is 'None', and a parameter with no default. The second argument, containing the Python type, will always contain None until such time as a conve
