[Python-3000] Parameter types and multiple method dispatch
I've been thinking about the proposed "parameter types" feature of
Python 3000. And there are two aspects of the current proposal that I
find somewhat troubling.
Let me first review what the proposal is. The idea is that a new syntax
would be added to allow specification of a "function signature" -
essentially a way to annotate individual parameters and have those
annotations be accessible via the function object.
In addition, one of the key design points is that these annotations
would have no fixed meaning, but would instead simply be objects that
are interpreted in various contexts, including function decorators for
which the annotations might have special meaning.
I'm going to go out on a limb here and say that both of these concepts
are less useful than one would think, and are likely to create a host of
problems. I suspect that the proposed design will lead to difficulty of
interpretation, and conflicts between different but overlapping goals
within the design of a program.
The first difficulty has to do with the way in which the arguments are
represented, specifically the notion that each annotation is associated
with a specific formal parameter.
A python function declaration is a kind of mapping between input
arguments and formal parameters. As we know from reading the Python
language reference, this mapping is in many instances a non-trivial
transformation.
For example, if I have a function:
def X( a=2, b=3, *c, **d ):
...
and I call it with:
X( b=100, f=9 )
We end with with values of 'a=2, b=100, c=[], and d={f:9}. However,
those values can only be accessed from within the function body - there
is no way for a decorator or any other external code to know what those
values are. Even if the decorator 'wraps' the function, it only knows
what actual parameters were passed - it can't *directly* know the value
of a, b, c, and d, although it can attempt to *emulate* the mapping by
reimplementing the parameter assignment algorithm.
Now, normally decorators don't care about any of this - typically one
writes a wrapper that simply has the same function signature as the
method it wraps, and the code that calls the inner function is written
by the programmer to reverse the transformation, so that the wrapped
function can recieve the same arguments.
That technique is only useful, however, if the decorator is
custom-written for functions that have a specific signature. Truly
generic wrappers typically don't examine the arguments at all, they
simply pass *args and **kwargs without looking at them too closely.
However, in order to use type annotations, one needs to associate
between the actual arguments and the formal parameters - because the
annotations are keyed by the formal parameter they are attached to. One
way to do this is to simulate the mapping of arguments to formal
parameters within the decorator. Once you know which formal parameter a
given value is assigned to, you can then retrieve the annotation for
that parameter and apply it to the value.
However, there are a number of drawbacks to doing this - first, the
mapping algorithm isn't really that simple in the general case. Worse,
the assignment of arguments to formal parameters is a prime suspect in
the relative 'slowness' of Python function calls compared to other
language features - and in order for the decorator to figure out which
argument goes with which formal parameter, the decorator is now forced
to perform that same mapping *again*.
Worse still if there is more than one decorator on the function, say
adding multiple constraints, then each one has to perform this mapping step.
A different possibility is to attempt to do the mapping in reverse -
that is, for a given formal parameter (and its associated type
annotation), attempt to determine which input argument corresponds to
that parameter.
The problem with this notion is that the parameter mapping algorithm is
an iterative one - it would be difficult to come up with an algorithm
that does Python parameter assignment *in reverse*, that was guaranteed
to be correct for all possible edge cases.
All of this is fairly trivial for the simple cases (i.e. a function with
only positional arguments), but that assumes that the decorator has some
foreknowledge of the kinds of functions that it will decorate. The
problem is, you don't *need* type annotations for that kind of decorator
- because if the decorator already has _a priori_ knowledge of the
function, then usually it will know enough to know what the types of the
arguments are supposed to be!
Type annotations are more likely to be useful for truly generic
decorators which will take action based on an inspection of the
annotations. But the problem is that these are exactly the kind of
decorators for which the parameter mapping problem is most acute.
My second difficulty is with the notion that type annotations have no
fixed meaning. The problem here is
[Python-3000] Proposal: Metasyntax operator
A number of dynamic languages, such as Lisp, support the notion of an
'unevaluated' expression. In Lisp, a macro is simply a function that can
operate on the *syntax* of the expression before it is actually compiled
and interpreted.
A number of Python libraries attempt to use operator overloading to
achieve similar results. A good example is SQLObject's 'sqlbuilder'
module, which allows the user to construct SQL statements using regular
Python operators.
Typically these libraries work by creating a set of standard constants
(i.e. function names, symbols, etc.) and overloading all of the
operators to produce an expression tree rather than actually evaluating
the result. Thus, 'a + b', instead of producing the sum of a and b, will
instead produce something along the lines of '('+', a, b)'.
One weak area, however, is in the treatment of variables. This is
because you can't recover the name of a variable at runtime - the
variable name only exists in the compiler's imagination, and is
generally long gone by the time the program is actually executed.
There have been a number of attempts to get around this limitation. One
approach is to define a limited set of "standard" variables (X, Y, Z,
etc.) Unfortunately, this is quite limiting - having to pre-declare
variables is hardly 'Pythonic'.
The other is to wrap the variables in a class (such as "Variable('x')",
which is cumbersome. Various tricks with __getattr__ can also be done,
such as Variable.x and so on.
All of these are examples of "quoted" variables - which is another way
of saying that the variables are unevaluated, and that their syntactical
rather than semantic attributes are available to the program.
I'd like to propose a standard way to represent one of these syntactical
variables. The syntax I would like to see is '?x' - i.e. a question mark
followed by the variable name.
The reason for choosing the question mark is that this is exactly how
many languages - including expert systems and inference engines -
represent a substitution variable. The other reason, which was only of
minor consideration, is that the '?' is one of the few symbols in Python
whose meaning is not already assigned.
The actual meaning of ? would is very simple:
'?x' is equivalent to '__quote__("x")'
Where __quote__ is a user-defined symbol accessible from the current scope.
There will also be a standard, importable implementation of __quote__
which overloads all operators to create a simple AST. It is likely that
most code that does syntactic manipulation (such as sqlbuilder) could be
modified to use the standard AST created by the built-in quote class.
The reason for this is because the AST itself has no inherent meaning,
its only meaningful to the function that you pass it so. So the SQL
'select()' function could walk through the AST transforming it into SQL
syntax.
The quote operator has one other effect, which is that unlike regular
variables it can overload assignment:
?x = 3
Normally this would be an error, since ?x isn't an L-value. However the
interpretr notes the presence of the ? and allows the __assign__ method
to be called instead. A possible use for this would be to create
syntactical descriptions of keyword arguments that can be inspected at
runtime:
@overload(int,int,?x=int)
Now, one potential objection is what to do about conflicting definitions
of __quote__. My response is that it is up to the user to make sure that
__quote__ is defined to the correct class at the correct places in the
code, even if this means re-assigning it from time to time:
__quote__ = SQLVar
expr = Select( User.name, Where( ?name = 'Fred' ) )
__quote__ = MathVar
formula = ?a + ?b
(I should note that I don't expect this proposal to get very far.
However, its something I've been thinking about for a long time.)
-- Talin
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] callable()
Ronald Oussoren wrote: > On Jul 20, 2006, at 3:26 AM, Greg Ewing wrote: > >> Ronald Oussoren wrote: >> >>> Classic classes? >> I just checked, and it seems they've been fixed too: >> callable() and hasattr(obj, '__call_') give the same >> result -- true if and only if a __call__ method has >> been defined. > > But classic classes theirself are callable yet don't have a __call__ > attribute. Which really won't be a problem in Py3k :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] callable()
Guido van Rossum wrote: > On 7/18/06, Greg Ewing <[EMAIL PROTECTED]> wrote: >> Andrew Koenig wrote: >> >>> I am uncomfortable about exposing the implementation this way, if only >>> because it would require fixing the equivalence between callable() and >>> hasattr(obj, '__call__') for all time. >> I don't see anything bad about fixing that equivalence. >> I regard the fact that it *wasn't* fixed before as a >> language design bug that Py3k will hopefully fix. > > I seem to recall fixing it. Are there still callable objects without a > __call__ attribute? I don't know about __call__, but str and unicode don't have __iter__, list, tuple and dict do: Python 2.5b2 (r25b2:50512, Jul 20 2006, 13:27:27) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> list.__iter__ >>> tuple.__iter__ >>> dict.__iter__ >>> str.__iter__ Traceback (most recent call last): File "", line 1, in AttributeError: type object 'str' has no attribute '__iter__' >>> unicode.__iter__ Traceback (most recent call last): File "", line 1, in AttributeError: type object 'unicode' has no attribute '__iter__' Should that be fixed too? Servus, Walter ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] callable()
On 7/20/06, Walter Dörwald <[EMAIL PROTECTED]> wrote: > str and unicode don't have __iter__, list, tuple and dict do: [...] > Should that be fixed too? Yes, please. (In Python 2.6 if you can.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Parameter types and multiple method dispatch
At 01:08 AM 7/20/2006 -0700, Talin <[EMAIL PROTECTED]> wrote: >In addition, one of the key design points is that these annotations >would have no fixed meaning, but would instead simply be objects that >are interpreted in various contexts, including function decorators for >which the annotations might have special meaning. Actually, you've left out an important bit: the __typecheck__ function. Guido's original proposal called for __typecheck__(arg, type) to be called on each argument that has a type declaration, with the result replacing the argument value. The builtin __typecheck__ function would be a no-op, but you could change its meaning within a module. Given this definition for the semantics, none of the issues you raised are relevant. >I'm going to go out on a limb here and say that both of these concepts >are less useful than one would think, and are likely to create a host of >problems. I suspect that the proposed design will lead to difficulty of >interpretation, and conflicts between different but overlapping goals >within the design of a program. I think you're worrying too much. I've written decorators that create signature-specific wrapper functions by exec'ing a string to create the wrapping function. It's a bit tricky, but you might be able to create a helper library to make it easier. There are some annoyances, too, like not being able to have the line numbers make sense in the decorator itself. But, if Guido's __typecheck__ idea is in effect, none of that would be necessary in order to support type checking. Also, for overloaded methods based on argument types, this isn't really a problem either. To do fast dispatching you need to generate code anyway -- which as it turns out is *why* I've written decorators that create signature-specific wrappers. :) That is, the need to generate code exists even without having argument type declarations. Ergo, argument type declarations don't create any new problems; I was already generating custom wrappers to deal with other esoteric aspects of function signatures (like nested argument tuples, *args, and **kw). ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Proposal: Metasyntax operator
At 01:58 AM 7/20/2006 -0700, Talin <[EMAIL PROTECTED]> wrote:
>I'd like to propose a standard way to represent one of these syntactical
>variables. The syntax I would like to see is '?x' - i.e. a question mark
>followed by the variable name.
>
>The reason for choosing the question mark is that this is exactly how
>many languages - including expert systems and inference engines -
>represent a substitution variable. The other reason, which was only of
>minor consideration, is that the '?' is one of the few symbols in Python
>whose meaning is not already assigned.
>
>The actual meaning of ? would is very simple:
>
> '?x' is equivalent to '__quote__("x")'
>
>Where __quote__ is a user-defined symbol accessible from the current scope.
I'd like to just point out that having a syntax for AST literals, i.e.,
simply having something like `foo+bar*23` result in an AST, gives you a
better result in several ways:
1. No ugly symbols next to every name
2. "and", "or", "if", "for", "yield", and even lambda expressions can be
used without further chicanery
3. The AST can be constructed at compilation time
If we were going to have ?x mean something special, I'd want it to instead
be a *reverse* syntactic operation. For example, if backquotes denoted an
AST literal (and I know Guido's not going to allow that, but it's
convenient for an example), then ? would be an escape to reference a
*non-AST* expression to be inserted. E.g.::
`x + ?y`
Would mean "take the runtime value of Y and insert it as a child node of
the AST at the position shown".
Of course, for this to work you'd have to come up with a better AST literal
syntax than backquotes. About the only thing that comes to mind at the
moment is using the backslash, followed by an atom. So "\x" would be an
AST literal for the symbol "x", and "\(x+y)" would be an AST literal for x+y.
I seem to recall that at one time Guido suggested that this type of thing
should just use strings, however, and I don't know if that's still his
position.
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] callable()
Guido van Rossum wrote: >On 7/20/06, Walter Dörwald <[EMAIL PROTECTED]> wrote: > > >>str and unicode don't have __iter__, list, tuple and dict do: >> >> >[...] > > >>Should that be fixed too? >> >> > >Yes, please. (In Python 2.6 if you can.) > > > Why is the a defect? Have we abandoned the notion of SeqIter automatically wrapping any object with __getitem__()? IIRC, list and tuple have __iter__ simply as optimizations, it did not change their functionality. Raymond - >>> class X: def __getitem__(self, i): if i < 5: return i*5 raise IndexError >>> for i in X(): print i 0 5 10 15 20 ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Parameter types and multiple method dispatch
On 7/20/06, Talin <[EMAIL PROTECTED]> wrote: > However, in order to use type annotations, one needs to associate > between the actual arguments and the formal parameters - because the > annotations are keyed by the formal parameter they are attached to. One > way to do this is to simulate the mapping of arguments to formal > parameters within the decorator. Once you know which formal parameter a > given value is assigned to, you can then retrieve the annotation for > that parameter and apply it to the value. > > However, there are a number of drawbacks to doing this - first, the > mapping algorithm isn't really that simple in the general case. Worse, > the assignment of arguments to formal parameters is a prime suspect in > the relative 'slowness' of Python function calls compared to other > language features - and in order for the decorator to figure out which > argument goes with which formal parameter, the decorator is now forced > to perform that same mapping *again*. [snip] > A different possibility is to attempt to do the mapping in reverse - > that is, for a given formal parameter (and its associated type > annotation), attempt to determine which input argument corresponds to > that parameter. > > The problem with this notion is that the parameter mapping algorithm is > an iterative one - it would be difficult to come up with an algorithm > that does Python parameter assignment *in reverse*, that was guaranteed > to be correct for all possible edge cases. I've implemented both solutions before, and neither proved to be all that difficult (after actually reading the manual, that is ; ) Also, I'm not sure what you're considering to be 'the general case', but I remember from my own adventures in this area that the most frequent function types were "def foo(a, b, c)"-style functions, ie, functions with only positional arguments. In this case, the mapping becomes dead simple. > By saying that annotations have no fixed meaning, what we're really > saying is that there's no "standard interpretation" of these > annotations, and that's where IMHO the trouble lies. If there's no > standard interpretation, then everyone is going to interpret them > differently. A function with more than one independently-written > decorator is going to have problems, each decorator trying to pick out > the parts of the annotations that's meant for them and not the others. Guido and I went back and forth on this for a while, whether or not to include a "standard interpretation" with Python itself. We're counting on the shear complexity of implementing an annotation-interpreting library to keep the number of these libraries low and in the hands of people who know what they're doing. > It seems to me that a better solution is to allow the *decorators* to > have function signatures. For example: > > @overload(int,int) > def add(a,b): >... > > The advantage of this is twofold: [snip] > Second, it means that the mapping problem hasn't entirely gone away, but > has somewhat been reduced, because now the type annotations are > referring to the *wrapper function's* arguments, not the arguments of > the wrapped function. This means that the wrapper is now on the > 'inside', and can see all of the variables in their mapped configuration. Huh? Unless you have a raft of decorators for every possible permutation of function parameters, you've probably written that overload() decorator to have a signature of "def overload(*vargs)" or "def overload(*vargs, **kwargs)", in which case you still have to do the argument -> formal parameter mapping. > Of course, there is still the problem of passing the arguments to the > inner function - but that's no worse than the problem that decorators > have today. I don't understand; what kind of decorators do you write that have this problem? > For example, '@overload(int,int,a=int)' doesn't express the notion that a is > a keyword argument that should be constrained to an int value. It certainly can express that if you want it to. Just use **kwargs in the decorator to catch all keyword arguments and then treat them differently. Collin Winter ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] callable()
On 7/20/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > >On 7/20/06, Walter Dörwald <[EMAIL PROTECTED]> wrote: > >>str and unicode don't have __iter__, list, tuple and dict do: > >>Should that be fixed too? > >Yes, please. (In Python 2.6 if you can.) > Why is the a defect? Have we abandoned the notion of SeqIter > automatically wrapping any object with __getitem__()? Actually, the autowrapping was intended a backwards compatibility measure. We should make a conscious decision whether we should make it a permanent feature or not. (I also think that the two-argument form iter(function, sentinel) is not very successful or useful and might be dropped, but that's a separate issue.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] callable()
>> Why is this a defect? Have we abandoned the notion of SeqIter >> automatically wrapping any object with __getitem__()? > > > Actually, the autowrapping was intended a backwards compatibility > measure. > > We should make a conscious decision whether we should make it a > permanent feature or not. It sure simplified writing extensions. And it provided a convenient guarantee that all sequences are iterable. I don't see a downside to keeping it. > (I also think that the two-argument form > iter(function, sentinel) is not very successful or useful and might be > dropped, but that's a separate issue.) This functionality should be moved to itertools. That will clear-up the odd function signature for iter(). As it stands now, the function/sentinel form suffers from invisibility. Raymond ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] set literals
Raymond Hettinger wrote: > I'm curious as to whether people will find one-type-with-two-purposes > easier to learn that what we have now. My experience so far is that > sets have a near zero learning curve as they are currently implemented. And it's not just about ease of learning to use, but also about ease of understanding expressed code once it's written. Having sets as a separate data type makes reading code easier because I don't have to first determine the context to determine how it's being used. Ron ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] callable()
On 7/20/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > >> Why is this a defect? Have we abandoned the notion of SeqIter > >> automatically wrapping any object with __getitem__()? > > > > > > Actually, the autowrapping was intended a backwards compatibility > > measure. > > > > We should make a conscious decision whether we should make it a > > permanent feature or not. > > It sure simplified writing extensions. > And it provided a convenient guarantee that all sequences are iterable. > I don't see a downside to keeping it. Well, it will also make mappings pseudo-iterable; in Py3k I plan to completely get rid of the distinction between x[...] for mappings and for sequences, which exist in C but not at the Python level. I'd like to hear from others whether the default iter fallback ought to stay or go. > > (I also think that the two-argument form > > iter(function, sentinel) is not very successful or useful and might be > > dropped, but that's a separate issue.) > > This functionality should be moved to itertools. > That will clear-up the odd function signature for iter(). > As it stands now, the function/sentinel form suffers from invisibility. That doesn't matter much since there are very few uses for it. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Proposal: Metasyntax operator
I'd like to see this fall under the blanket "Python will not have
programmable syntax" rule in PEO 3099.
On 7/20/06, Talin <[EMAIL PROTECTED]> wrote:
> A number of dynamic languages, such as Lisp, support the notion of an
> 'unevaluated' expression. In Lisp, a macro is simply a function that can
> operate on the *syntax* of the expression before it is actually compiled
> and interpreted.
>
> A number of Python libraries attempt to use operator overloading to
> achieve similar results. A good example is SQLObject's 'sqlbuilder'
> module, which allows the user to construct SQL statements using regular
> Python operators.
>
> Typically these libraries work by creating a set of standard constants
> (i.e. function names, symbols, etc.) and overloading all of the
> operators to produce an expression tree rather than actually evaluating
> the result. Thus, 'a + b', instead of producing the sum of a and b, will
> instead produce something along the lines of '('+', a, b)'.
>
> One weak area, however, is in the treatment of variables. This is
> because you can't recover the name of a variable at runtime - the
> variable name only exists in the compiler's imagination, and is
> generally long gone by the time the program is actually executed.
>
> There have been a number of attempts to get around this limitation. One
> approach is to define a limited set of "standard" variables (X, Y, Z,
> etc.) Unfortunately, this is quite limiting - having to pre-declare
> variables is hardly 'Pythonic'.
>
> The other is to wrap the variables in a class (such as "Variable('x')",
> which is cumbersome. Various tricks with __getattr__ can also be done,
> such as Variable.x and so on.
>
> All of these are examples of "quoted" variables - which is another way
> of saying that the variables are unevaluated, and that their syntactical
> rather than semantic attributes are available to the program.
>
> I'd like to propose a standard way to represent one of these syntactical
> variables. The syntax I would like to see is '?x' - i.e. a question mark
> followed by the variable name.
>
> The reason for choosing the question mark is that this is exactly how
> many languages - including expert systems and inference engines -
> represent a substitution variable. The other reason, which was only of
> minor consideration, is that the '?' is one of the few symbols in Python
> whose meaning is not already assigned.
>
> The actual meaning of ? would is very simple:
>
> '?x' is equivalent to '__quote__("x")'
>
> Where __quote__ is a user-defined symbol accessible from the current scope.
>
> There will also be a standard, importable implementation of __quote__
> which overloads all operators to create a simple AST. It is likely that
> most code that does syntactic manipulation (such as sqlbuilder) could be
> modified to use the standard AST created by the built-in quote class.
> The reason for this is because the AST itself has no inherent meaning,
> its only meaningful to the function that you pass it so. So the SQL
> 'select()' function could walk through the AST transforming it into SQL
> syntax.
>
> The quote operator has one other effect, which is that unlike regular
> variables it can overload assignment:
>
> ?x = 3
>
> Normally this would be an error, since ?x isn't an L-value. However the
> interpretr notes the presence of the ? and allows the __assign__ method
> to be called instead. A possible use for this would be to create
> syntactical descriptions of keyword arguments that can be inspected at
> runtime:
>
> @overload(int,int,?x=int)
>
> Now, one potential objection is what to do about conflicting definitions
> of __quote__. My response is that it is up to the user to make sure that
> __quote__ is defined to the correct class at the correct places in the
> code, even if this means re-assigning it from time to time:
>
> __quote__ = SQLVar
> expr = Select( User.name, Where( ?name = 'Fred' ) )
> __quote__ = MathVar
> formula = ?a + ?b
>
> (I should note that I don't expect this proposal to get very far.
> However, its something I've been thinking about for a long time.)
>
> -- Talin
>
> ___
> Python-3000 mailing list
> [email protected]
> 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
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Proposal: Metasyntax operator
"Guido van Rossum" <[EMAIL PROTECTED]> wrote: > I'd like to see this fall under the blanket "Python will not have > programmable syntax" rule in PEO 3099. Would this also mean that you don't want people to be manipulating AST objects a'la Boo macros? - Josiah ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Proposal: Metasyntax operator
Josiah Carlson <[EMAIL PROTECTED]> wrote: > "Guido van Rossum" <[EMAIL PROTECTED]> wrote: > > I'd like to see this fall under the blanket "Python will not have > > programmable syntax" rule in PEO 3099. > > Would this also mean that you don't want people to be manipulating AST > objects a'la Boo macros? Nevermind, obvious no in reading your post. Move along people, nothing to see here. - Josiah ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] callable()
Walter Dörwald wrote: > I don't know about __call__, but str and unicode don't have __iter__, > list, tuple and dict do: That's probably because str and unicode don't do their own iteration, but rely on the fallback implementation. In which case it's perfectly correct for them not to have an __iter__ method. If you want to test whether something is iterable, it's not enough to test for __iter__ -- you also need to test for __len__ and __getitem__ as an alternative. Which means it might make sense to have an iterable() function which does that. -- Greg ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] callable()
On 7/20/06, Greg Ewing <[EMAIL PROTECTED]> wrote: Walter Dörwald wrote:> I don't know about __call__, but str and unicode don't have __iter__,> list, tuple and dict do:That's probably because str and unicode don't do theirown iteration, but rely on the fallback implementation. In which case it's perfectly correct for them not tohave an __iter__ method.If you want to test whether something is iterable, it'snot enough to test for __iter__ -- you also need totest for __len__ and __getitem__ as an alternative. Which means it might make sense to have an iterable()function which does that.--Greg___Python-3000 mailing list [email protected]://mail.python.org/mailman/listinfo/python-3000Unsubscribe: http://mail.python.org/mailman/options/python-3000/brett%40python.org ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Parameter types and multiple method dispatch
Phillip J. Eby wrote: > Guido's original proposal called for __typecheck__(arg, type) to > be called on each argument that has a type declaration, with the result > replacing the argument value. > > Given this definition for the semantics, none of the issues you raised are > relevant. I think some of it is still relevant, such as the concern about different parts of the same program fighting over the interpretation of the type annotations. I'm rather leery about the whole thing myself because of that. The idea of adding something in such a fundamental and intrusive way to the language when we don't even have a clear idea of what we're going to use it for smells very bad to me. I get the feeling that if anyone other than Guido suggested doing any such thing, he would tell them in no uncertain terms to go away and come back when they had a complete and concrete proposal... -- Greg ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] callable()
On 7/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: On 7/20/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:>> >> Why is this a defect? Have we abandoned the notion of SeqIter> >> automatically wrapping any object with __getitem__()? > >> >> > Actually, the autowrapping was intended a backwards compatibility> > measure.> >> > We should make a conscious decision whether we should make it a > > permanent feature or not.>> It sure simplified writing extensions.> And it provided a convenient guarantee that all sequences are iterable.> I don't see a downside to keeping it. Well, it will also make mappings pseudo-iterable; in Py3k I plan tocompletely get rid of the distinction between x[...] for mappings andfor sequences, which exist in C but not at the Python level. Woohoo!I'd like to hear from others whether the default iter fallback ought to stay or go.Eh, I have never had any direct need for it.-Brett ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] callable()
On 7/20/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > Walter Dörwald wrote: > > > I don't know about __call__, but str and unicode don't have __iter__, > > list, tuple and dict do: > > That's probably because str and unicode don't do their > own iteration, but rely on the fallback implementation. > In which case it's perfectly correct for them not to > have an __iter__ method. > > If you want to test whether something is iterable, it's > not enough to test for __iter__ -- you also need to > test for __len__ and __getitem__ as an alternative. > Which means it might make sense to have an iterable() > function which does that. And that's a problem, because if uses those to implement a mapping, it isn't reasonably iterable with just those. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] callable()
Guido van Rossum wrote: > Actually, the autowrapping was intended a backwards compatibility measure. But it seems like a perfectly good and useful feature in its own right to me. Why force every sequence to implement its own __iter__ if there is a default one that does the same as what your custom one would have done anyway? An alternative would be to give object an __iter__ method containing the default implementation. But then you've lost all ability to test for potential iterability, since everything has an __iter__ whether it works or not. So +1 from me on keeping the status quo wrt __iter__ in Py3k. -- Greg ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
