Guido van Rossum wrote:
> On 5/14/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>> More importantly, it seems to go against the grain of at least my
>> mental concept of Python call signatures, in which arguments are
>> inherently *named* (and can be passed using explicit names), with
>> only rare
Phillip J. Eby wrote:
> C++ and Java don't have tuples, do they?
No, but in C++ you could probably do something clever by
overloading the comma operator if you were feeling perverse
enough...
--
Greg
___
Python-3000 mailing list
[email protected]
Phillip J. Eby wrote:
> Imagine what would happen if the results of
> calling super() depended on what order your modules had been imported in!
Actually, something like this does happen with super.
You can't be sure which method super() will call when
you write it, because it depends on what othe
tomer filiba wrote:
>
> once we have chinese, french and hindi function names, i'd be very
> difficult to interoperate with third party libs. imagine i wrote my
> code using twisted-he, while my client has installed twisted-fr...
> kaboom?
Indeed if the authors of twisted suddenly go insane and d
Greg Ewing <[EMAIL PROTECTED]> wrote:
> Phillip J. Eby wrote:
> > Imagine what would happen if the results of
> > calling super() depended on what order your modules had been imported in!
>
> Actually, something like this does happen with super.
No, it doesn't.
The order of super-calls is alway
At 07:47 PM 5/14/2007 -0700, Talin wrote:
>Guido van Rossum wrote:
>>Next, I have a question about the __proceed__ magic argument. I can
>>see why this is useful, and I can see why having this as a magic
>>argument is preferable over other solutions (I couldn't come up with a
>>better solution, and
At 09:43 PM 5/14/2007 -0700, Guido van Rossum wrote:
>On 5/14/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > Or perhaps we could just say that if the main function is defined
> > with *args, we treat those arguments as positional? i.e.:
> >
> > @abstract
> > def range(*args):
> >
> @abstract
> def range(*args:3):
> ...
>
> then that would be best. I propose, therefore, that we require an
> integer annotation on the *args to enable positional dispatching.
I thought there was already a proposal to do something like this:
@abstract
def r
On 5/15/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 09:43 PM 5/14/2007 -0700, Guido van Rossum wrote:
> >On 5/14/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > > Or perhaps we could just say that if the main function is defined
> > > with *args, we treat those arguments as positional? i.
At 08:32 AM 5/15/2007 -0700, Guido van Rossum wrote:
>Not so good; I expect the overloads could be written by different
>authors or at least at different times. Why can't you dynamically
>update the dispatcher when an overloading with more arguments comes
>along?
You mean by changing its __code__?
On 5/15/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 08:32 AM 5/15/2007 -0700, Guido van Rossum wrote:
> >Not so good; I expect the overloads could be written by different
> >authors or at least at different times. Why can't you dynamically
> >update the dispatcher when an overloading with mo
At 09:40 AM 5/15/2007 -0700, Guido van Rossum wrote:
>It looks like you're focused ion an implementation that is both highly
>optimized and (technically) pure Python (using every trick in the
>book). Personally I would rather go for a a slower but simpler pure
>Python implementation
Actually, the
On 5/14/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 5/14/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > There really is no difference between roles and [EMAIL PROTECTED]
> > ABCs. From my point of view, though, roles win because they don't
> > require any changes to the interpreter; they'r
On 5/15/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> This is what I don't understand: ABCs require changing the VM, roles
> don't; all that change buys you is the ability to spell "performs()"
> as "isinstance()". Why are ABCs preferable, again?
Actually, if you didn't care about overloading isi
On 5/15/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 5/14/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > On 5/14/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > > You may like adding the extra complexity
> > > and indirection to the VM necessary to support
> > > issubclass()/isinstance() o
Christian Tanzer wrote:
> Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> > Phillip J. Eby wrote:
> >
> > > Imagine what would happen if the results of
> > > calling super() depended on what order your modules had been imported in!
> >
> > Actually, something like this does happen with super.
>
> This
At 12:19 PM 5/16/2007 +1200, Greg Ewing wrote:
>Christian Tanzer wrote:
> > Greg Ewing <[EMAIL PROTECTED]> wrote:
> >
> > > Phillip J. Eby wrote:
> > >
> > > > Imagine what would happen if the results of
> > > > calling super() depended on what order your modules had been
> imported in!
> > >
> >
On 5/11/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> - Overloading isinstance and issubclass is now a key mechanism rather
> than an afterthought; it is also the only change to C code required
>
> - Built-in (and user-defined) types can be registered as "virtual
> subclasses" (not related to v
Phillip J. Eby wrote:
> This is the driving force for having before and after methods: allowing
> independent hooks to be registered, while ensuring that they can't mess
> anything up (as long as they stick to their own business).
Some discipline is still required to make sure they do
stick to
Note that Phillip's hypothetical was about it depending on *the order
in which modules are imported*. Super has no such dependency -- it
just depends on the inheritance graph, which is much more
well-defined.
--Guido
On 5/15/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Christian Tanzer wrote:
> >
On 5/15/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 5/11/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > - Overloading isinstance and issubclass is now a key mechanism rather
> > than an afterthought; it is also the only change to C code required
> >
> > - Built-in (and user-defined) type
At 06:34 PM 5/15/2007 -0700, Guido van Rossum wrote:
> > Have I missed something? It would seem that when dealing with ABCs
> > that provide concrete methods, "isinstance(x, SomeABC) == True" is
> > useless.
>
>The intention is that you shouldn't register such cases. This falls
>under the consentin
Have you been able to find substantial Java source in which non-ascii
identifiers were used? I have been curious about its prevalence, but
wouldn't even know how to start searching for such code.
I've seen many (and written some) java and c# code use chinese identifiers,
and yes, most of that
On 5/14/07, Benji York <[EMAIL PROTECTED]> wrote:
> Collin Winter wrote:
> > PEP: 3133
> > Title: Introducing Roles
>
> Everything included here is included in zope.interface. See in-line
> comments below for the analogs.
Could you look at PEP 3119 and do a similar analysis? I expect that
the mai
Hello,
Just to let you know that a discussion on japanese python users group
is going on regarding this issue.
Most people feel like the PEP3131 would be a welcome addition.
-> some people point out the fact that special characters like the
greek letters would be great for all kind of maths calc
Guillaume Proux wrote:
> Hello,
>
> Just to let you know that a discussion on japanese python users group
> is going on regarding this issue.
>
> Most people feel like the PEP3131 would be a welcome addition.
> -> some people point out the fact that special characters like the
> greek letters would
One of the big advantage of japanese Input Methods. They can be
extended easily to fit your need.
I can type "siguma" on my laptop here and windows (same in Linux)
gives me the following choices
しぐま
シグマ
σ
Σ
cute no?
Guillaume
On 5/16/07, Neil Toronto <[EMAIL PROTECTED]> wrote:
> Guillaume Pro
27 matches
Mail list logo
