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 signatur
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 overloadi
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
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.
>>
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/)
__
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 mi
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
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 aband
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 mappi
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 d
>> 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
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, b
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
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
>
"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
__
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
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 __it
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 pe
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
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 backward
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.
> I
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 custo
22 matches
Mail list logo