Martin v. Löwis wrote:
> Nicolas Fleury wrote:
>
>>Well, I'm using the alternatives.
>
> Perhaps not to the full power.
Not perhaps, surely;) Who does anyway;)
> So you don't want to write the makeArrayType function, right?
>
> How about this:
>
> # declaration
> class Array(object):
> __t
Nicolas Fleury wrote:
> Well, I'm using the alternatives.
Perhaps not to the full power.
> __arrayTypes = {}
> def makeArrayType(arg1, arg2=someDefault):
> if (arg1, arg2) in __arrayTypes:
> return __arrayTypes[arg1, arg2]
> renamed_arg1 = arg1
> renamed_arg2 = arg2
> clas
On Mon, 08 Aug 2005 21:24:15 -0400, Nicolas Fleury <[EMAIL PROTECTED]> wrote:
>Bengt Richter wrote:
>> On Mon, 08 Aug 2005 16:18:50 -0400, Nicolas Fleury <[EMAIL PROTECTED]> wrote:
>>>I wrote the PEP to see if was the only one that would benefit from
>>>generic types *before* having optional stat
Bengt Richter wrote:
> On Mon, 08 Aug 2005 16:18:50 -0400, Nicolas Fleury <[EMAIL PROTECTED]> wrote:
>>I wrote the PEP to see if was the only one that would benefit from
>>generic types *before* having optional static typing in the language.
>>
>>It seems I'm the only one;)
>>
>>According to blog
On Tue, 09 Aug 2005 00:14:25 GMT, [EMAIL PROTECTED] (Bengt Richter) wrote:
[...]
>Here is a decorator object to set up function call dispatch according to type.
>It only uses positional arguments, but could be fleshed out, I think.
>Not tested beyond what you see ;-)
>
>< typedispatcher.py >---
On Mon, 08 Aug 2005 16:18:50 -0400, Nicolas Fleury <[EMAIL PROTECTED]> wrote:
>Bengt Richter wrote:
>> On Sun, 07 Aug 2005 21:41:33 -0400, Nicolas Fleury <[EMAIL PROTECTED]> wrote:
>>>I mean should angle brackets <> like in C++, or another operator, be
>>>used instead?
>>
>> I am getting the fee
Bengt Richter wrote:
> On Sun, 07 Aug 2005 21:41:33 -0400, Nicolas Fleury <[EMAIL PROTECTED]> wrote:
>>I mean should angle brackets <> like in C++, or another operator, be
>>used instead?
>
> I am getting the feeling that your PEP is about a means to do something
> C++-like
> in python, not nece
On Sun, 07 Aug 2005 21:41:33 -0400, Nicolas Fleury <[EMAIL PROTECTED]> wrote:
>Bengt Richter wrote:
[...]
>> But here the problem is not in the __getitem__ method:
>>
>> >>> c.__getitem__(kw='key word arg')
>> (<__main__.C object at 0x02EF498C>, (), {'kw': 'key word arg'})
>>
>> It's just that
Kay Schluehr wrote:
> I have to admit that i don't actually understand what you want? The
> problems you try to solve seem trivial to me but it's probably my fault
> and i'm misreading something. You might be correct that your PEP may be
> interesting only if "optional static typing" will be introd
On 8 Aug 2005 02:26:40 -0700, Kay Schluehr <[EMAIL PROTECTED]> wrote:
>
>I have to admit that i don't actually understand what you want?
Me neither. I don't see the point of this.
--
Email: zen19725 at zen dot co dot uk
--
http://mail.python.org/mailman/listinfo/python-list
Nicolas Fleury schrieb:
> Kay Schluehr wrote:
> > def makeClass(cls_name, **kw):
> > return type(cls_name,(), kw)
> >
> MyObject = makeClass("MyObject",a=8)
> MyObject
>
> As said to Bengt, a place is needed to write the class definition.
> There's no need for metaclass in that case:
Kay Schluehr wrote:
> def makeClass(cls_name, **kw):
> return type(cls_name,(), kw)
>
MyObject = makeClass("MyObject",a=8)
MyObject
As said to Bengt, a place is needed to write the class definition.
There's no need for metaclass in that case:
def makeType(a, b, c=someDefault):
Nicolas Fleury wrote:
> It is necessary to maintain a
> dictionary of types (to avoid redundacy) and simple things like:
>
> def makeType(someArgument):
> class MyObject:
> someArgument = someArgument
> return MyObject
>
> are not allowed.
def makeClass(cls_name, **kw):
ret
Bengt Richter wrote:
> I don't understand why you wouldn't give the function arg a different name
> in the first place instead of via a temporary intermediary binding, e.g.,
>
> def makeType(someArgument_alias):
> class MyObject:
> someArgument = someArgument_alias
> return
Bengt Richter wrote:
>>__specialize__ Special Member Function.
>
> By "Member Function" do you mean anything different from "method"?
No, I should have written method. C++ habit.
>>The first element of this proposal is the addition of the
>>__specialize__ special member function. The _
On Sun, 07 Aug 2005 17:20:25 -0400, Nicolas Fleury <[EMAIL PROTECTED]> wrote:
>Martin v. Löwis wrote:
>> -1. I don't see the point of this PEP. Apparently, you want to define
>> parametrized types - but for what purpose? I.e. what are the specific
>> use cases for the proposed syntax, and why do y
On Sun, 07 Aug 2005 16:22:11 -0400, Nicolas Fleury <[EMAIL PROTECTED]> wrote:
>Hi everyone, I would to know what do you think of this PEP. Any comment
>welcomed (even about English mistakes).
>
>PEP: XXX
>Title: Specialization Syntax
>Version: $Revision: 1.10 $
>Last-Modified:
Martin v. Löwis wrote:
> -1. I don't see the point of this PEP. Apparently, you want to define
> parametrized types - but for what purpose? I.e. what are the specific
> use cases for the proposed syntax, and why do you need to change the
> language to support these use cases? I very much doubt that
Nicolas Fleury wrote:
> Hi everyone, I would to know what do you think of this PEP. Any comment
> welcomed (even about English mistakes).
-1. I don't see the point of this PEP. Apparently, you want to define
parametrized types - but for what purpose? I.e. what are the specific
use cases for the p
Hi everyone, I would to know what do you think of this PEP. Any comment
welcomed (even about English mistakes).
PEP:XXX
Title: Specialization Syntax
Version:$Revision: 1.10 $
Last-Modified: $Date: 2003/09/22 04:51:49 $
Author: Nicolas Fleury
Status: Draft
Type: S
20 matches
Mail list logo
