Here is my modified version of PEP 367. The reference implementation in it
is pretty long, and should probably be split out to somewhere else (esp.
since it can't fully implement the semantics).
Cheers,
Tim Delaney
PEP: 367
Title: New Super
Version: $Revision$
Last-Modified: $Date$
Author: Ca
Collin Winter wrote:
> PEP: 3133
[snip]
I'll probably have quite a few comments on this over the next few days.
First let me start off by saying I like the general approach of your PEP.
Let me kick off the bikeshed part of the discussion by saying that the
"role/performs" terminology is not my
> Asking Questions About Roles
Shouldn't there be some way to ``revoke'' roles?
How can we get a list of all roles played by an object?
Should there be a way to check ``loosely'' whether an object can
potentially play a given role? (i.e., checking whether an object
provides a give interface, atl
On 12/05/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Here's a new version of the ABC PEP. A lot has changed; a lot remains.
> I can't give a detailed overview of all the changes, and a diff would
> show too many spurious changes, but some of the highlights are:
As a general comment, I like t
On Sun, 13 May 2007 22:03:26 -0500, Michael Urman <[EMAIL PROTECTED]> wrote:
>On 5/13/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> The answer to all of this is the filesystem encoding, which is already
>> supported. Doesn't appear particularly difficult to me.
>
>Okay, that's fair. It seems r
On 11/05/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 5/11/07, Paul Moore <[EMAIL PROTECTED]> wrote:
> > Hmm. My view is that it *is* simple to explain, but unfortunately
> > Phillip's explanation in the PEP is not that simple explanation :-(
>
> [snip]
>
> > I would argue that the PEP could be
On 5/14/07, Paul Moore <[EMAIL PROTECTED]> wrote:
> > ABCs vs. Duck Typing
>
> This remains my key concern. The PEP nicely addresses the issue as far
> as core Python is concerned, but I'd be happier with some style
> recommendations for 3rd party frameworks clarifying that they should
> also avoid
On 5/14/07, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> On Sun, 13 May 2007 22:03:26 -0500, Michael Urman <[EMAIL PROTECTED]> wrote:
> >On 5/13/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >> The answer to all of this is the filesystem encoding, which is already
> >> supported. Doesn't ap
On 5/14/07, Paul Moore <[EMAIL PROTECTED]> wrote:
> However, it looks like
> there's a general feeling emerging that snipping certain sections
> would be enough. I'd agree with that - my personal feeling is that
> it'd be OK to remove all of the following sections:
>
> * "Before" and "After" Method
On 5/14/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Isn't normalization also going to be an issue with using non-ASCII in
> general? Does it mean that Python will have to use a normalization
> before comparing identifiers as equal? That's terrible, as it will
> vastly increase the amount need
On 5/13/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> I don't think this scenario is all that unlikely. A
> program is initially written by a Russian programmer
> who uses his own version of "a" as a variable name.
> Later an English-speaking programmer makes some
> changes, and uses an ascii "a". No
At 08:29 AM 5/14/2007 -0700, Guido van Rossum wrote:
>On 5/14/07, Paul Moore <[EMAIL PROTECTED]> wrote:
> > However, it looks like
> > there's a general feeling emerging that snipping certain sections
> > would be enough. I'd agree with that - my personal feeling is that
> > it'd be OK to remove al
On 5/14/07, Jason Orendorff <[EMAIL PROTECTED]> wrote:
> On 5/13/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > I don't think this scenario is all that unlikely. A
> > program is initially written by a Russian programmer
> > who uses his own version of "a" as a variable name.
> > Later an English-sp
"Jason Orendorff" <[EMAIL PROTECTED]> wrote:
>
> On 5/13/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > I don't think this scenario is all that unlikely. A
> > program is initially written by a Russian programmer
> > who uses his own version of "a" as a variable name.
> > Later an English-speaking
At 10:36 PM 5/13/2007 -0700, Collin Winter wrote:
>2. Querying instances ::
>
> if performs(my_elf, Thieving):
>...
-1 on using any function other than isinstance() for this.
Rationale: isinstance() makes the code smell of inspection more
obvious, where another function name makes i
On 5/14/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 08:29 AM 5/14/2007 -0700, Guido van Rossum wrote:
> >On 5/14/07, Paul Moore <[EMAIL PROTECTED]> wrote:
> > > However, it looks like
> > > there's a general feeling emerging that snipping certain sections
> > > would be enough. I'd agree wit
On 5/14/07, Jason Orendorff <[EMAIL PROTECTED]> wrote:
> On 5/14/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Isn't normalization also going to be an issue with using non-ASCII in
> > general? Does it mean that Python will have to use a normalization
> > before comparing identifiers as equal
On 14/05/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I'm not sure what language you would specifically like to see added to
> the PEP. "Recommendation for 3rd party frameworks: please don't use
> the stick approach." sounds a little strange. What's the point you're
> trying to get across?
So
At 05:23 PM 5/14/2007 +1000, Tim Delaney wrote:
>Determining the class object to use
>'''
>
>The exact mechanism for associating the method with the defining class is
>not
>specified in this PEP, and should be chosen for maximum performance. For
>CPython, it is sugge
At 06:01 PM 5/14/2007 +0100, Paul Moore wrote:
>On 14/05/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I'm not sure what language you would specifically like to see added to
> > the PEP. "Recommendation for 3rd party frameworks: please don't use
> > the stick approach." sounds a little strang
On 5/14/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Does the tokenizer do this for all string literals, too? Otherwise you
> could still get surprises with things like x.foo vs. getattr(x,
> "foo"), if the name foo were normalized but the string "foo" were not.
It does not; so yes, you could
First I'll try to explain why I don't like the sys._getframe() approach.
Phillip's current syntax is roughly:
def flatten(x): ... # this is the "base" function
@overload
def flatten(y: str): ...# this adds an overloaded version
The implementation of @overload needs to use sys._ge
On 5/13/07, Guillaume Proux <[EMAIL PROTECTED]> wrote:
> Is this a bijective translation ? How good is most people latin
> character reading ability among Hebrew speakers? From the beginning, I
> can tell from experience that Japanese people have great difficulties
> in reading english or even tra
On 5/13/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> test_compiler and test_transformer have been broken for a couple of
> months now I believe.
>
> Unless someone comes to the rescue of the compiler package soon, I'm
> tempted to remove it from the p3yk branch -- it doesn't seem to serve
> an
OK Brett, let 'er rip.
On 5/14/07, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> On 5/13/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > test_compiler and test_transformer have been broken for a couple of
> > months now I believe.
> >
> > Unless someone comes to the rescue of the compiler package
as an english-second-language programmer, i'd really like to be able
to have unicode identifiers -- but my gut feeling is -- it will open the
door for a tower of babel.
once we have chinese, french and hindi function names, i'd be very
difficult to interoperate with third party libs. imagine i wro
At 11:25 AM 5/14/2007 -0700, Guido van Rossum wrote:
>The implementation of @overload needs to use sys._getframe() to look
>up the name of the function ('flatten') in the surrounding namespace.
>I find this too fragile an approach; it means that I can't easily
>write another function that calls ove
At 09:41 AM 5/14/2007 -0700, Guido van Rossum wrote:
> > Note that in current Ruby, you can simulate generic functions
> > (single-dispatch only) via open classes as long as you use
> > sufficiently-unique method names. The fact that Matz wants to add
> > these qualifiers seems to suggest that sim
On 5/14/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> I don't see what the benefit is of making people implement their own
> versions of @before, @after, and @around, which then won't
> interoperate properly with others' versions of the same thing. Even
> if we leave in place the MethodList base
On 5/14/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> 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.
No, I haven't.
The most substantial use
On 5/14/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 11:25 AM 5/14/2007 -0700, Guido van Rossum wrote:
> >The implementation of @overload needs to use sys._getframe() to look
> >up the name of the function ('flatten') in the surrounding namespace.
> >I find this too fragile an approach; it me
On 5/14/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> I simply said the plan for Ruby was suggestive that method
> combination is worth looking into further, because in the case of
> Ruby, they already had single-dispatch generic functions, so the
> addition suggests combination is no longer cons
On 5/14/07, Arvind Singh <[EMAIL PROTECTED]> wrote:
> > Asking Questions About Roles
>
> Shouldn't there be some way to ``revoke'' roles?
No, roles are purely additive. Allowing role revocation is an easy
recipe for race conditions where one bit of code says type X does a
given role and another bi
"Jason Orendorff" <[EMAIL PROTECTED]> wrote:
> On 5/14/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > 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
On 5/13/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 5/13/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > PEP: 3133
> > Title: Introducing Roles
> [snip]
> > * Roles provide a way of indicating a object's semantics and abstract
> > capabilities. A role may define abstract methods, but onl
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're a much simpler way of
> expressing the same concept.
Ok, yo
On May 14, 2007, at 12:41 PM, Guido van Rossum wrote:
> OK, let me repeat this request than: real use cases! Point me to code
> that uses or could be dramatically simplified by adding all this.
> Until, then, before/after and everything beyond it is solidly in
> YAGNI-land.
Excerpted from a recen
On 5/14/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
OK Brett, let 'er rip.
Ripped in revision 55322.
-Brett
On 5/14/07, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> On 5/13/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > test_compiler and test_transformer have been broken for a coup
On 5/14/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
>
>
> On 5/14/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > OK Brett, let 'er rip.
>
> Ripped in revision 55322.
Woohoo!
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/
Collin Winter wrote:
> PEP: 3133
> Title: Introducing Roles
Everything included here is included in zope.interface. See in-line
comments below for the analogs.
[snip]
> Performing Your Role
>
>
> Static Role Assignment
> --
>
> Let's start out by defi
At 12:47 PM 5/14/2007 -0700, Guido van Rossum wrote:
>> >I realize that @overload is only a shorthand for @when(function). But
>> >I'd much rather not have @overload at all -- the frame inspection
>> >makes it really hard for me to explain carefully what happens without
>> >just giving the code tha
At 03:43 PM 5/14/2007 -0400, Jim Jewett wrote:
>On 5/14/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>I don't see what the benefit is of making people implement their own
>>versions of @before, @after, and @around, which then won't
>>interoperate properly with others' versions of the same thing.
At 12:51 PM 5/14/2007 -0700, Guido van Rossum wrote:
>On 5/14/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > I simply said the plan for Ruby was suggestive that method
> > combination is worth looking into further, because in the case of
> > Ruby, they already had single-dispatch generic functio
On 5/14/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 12:47 PM 5/14/2007 -0700, Guido van Rossum wrote:
> >> >I realize that @overload is only a shorthand for @when(function). But
> >> >I'd much rather not have @overload at all -- the frame inspection
> >> >makes it really hard for me to expla
On 5/14/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> However, with respect, I didn't go to all the trouble of implementing
> method combination in RuleDispatch just for the heck of it. (And it
> was considerable trouble, doing it the way CLOS implements it, until
> I figured out an approach mor
At 03:43 PM 5/14/2007 -0700, Guido van Rossum wrote:
> > Chaining using the first argument can be implemented using a bound
> > method object, which gets performance bonuses from the C eval loop
> > that partial() objects don't. (Of course, when RuleDispatch was
> > written, partial() objects didn
On 5/14/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 03:43 PM 5/14/2007 -0700, Guido van Rossum wrote:
> > > Chaining using the first argument can be implemented using a bound
> > > method object, which gets performance bonuses from the C eval loop
> > > that partial() objects don't. (Of cou
At 04:19 PM 5/14/2007 -0700, Guido van Rossum wrote:
>On 5/14/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>However, with respect, I didn't go to all the trouble of implementing
>>method combination in RuleDispatch just for the heck of it. (And it
>>was considerable trouble, doing it the way CLO
At 05:17 PM 5/14/2007 -0700, Guido van Rossum wrote:
>Other use cases that come to mind are e.g. APIs that you can pass
>either a Point object or two (or three!) floats. This is not a natural
>use case for argument default values, and it's not always convenient
>to require the user to pass a tuple
I refuse to continue this discussion until the PEP has been rewritten.
It's probably a much better use of your time to rewrite the PEP than
to argue with me in email too.
On 5/14/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 04:19 PM 5/14/2007 -0700, Guido van Rossum wrote:
> >On 5/14/07, Phi
On 5/14/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 05:17 PM 5/14/2007 -0700, Guido van Rossum wrote:
> >Other use cases that come to mind are e.g. APIs that you can pass
> >either a Point object or two (or three!) floats. This is not a natural
> >use case for argument default values, and it
On 5/14/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 04:19 PM 5/14/2007 -0700, Guido van Rossum wrote:
> >But can you at least share enough of the problem so others can look at
> >it and either suggest a solution or agree with your conclusion?
>
> Sure. Take a look at peak.rules.core (while
Found some evidence of usage of identifiers in Japanese while doing a
quick google search
All links below are in Japanese.
* Ruby has support for Japanese identifiers (which is not unexpected
when you know the origin country of Ruby)
http://www.ruby-lang.org/ja/man/?cmd=view;name=%CA%D1%BF%F4%A4%
At 05:51 PM 5/14/2007 -0700, Guido van Rossum wrote:
>On 5/14/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>At 05:17 PM 5/14/2007 -0700, Guido van Rossum wrote:
>> >Other use cases that come to mind are e.g. APIs that you can pass
>> >either a Point object or two (or three!) floats. This is not a
Phillip J. Eby wrote:
> If you have only strict precedence
> (i.e., methods with the same signature are ambiguous), you wind up in
> practice needing a way to disambiguate methods when you don't really
> care what order they're executed in
> ...
> And, the nature of
> these observer-ish use ca
At 01:42 PM 5/15/2007 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
> > If you have only strict precedence
> > (i.e., methods with the same signature are ambiguous), you wind up in
> > practice needing a way to disambiguate methods when you don't really
> > care what order they're executed in
>
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 believe me I tried :-). However, I think
Phillip J. Eby wrote:
> Meanwhile, I've been told repeatedly that TurboGears makes extensive
> use of RuleDispatch, and my quick look today showed they actually use
> a custom method combination, but I haven't yet tracked down where it
> gets used, or what the rationale for it is.
You want to l
> One example they give is
>
> ---
> i = revised(i);
> とか、
> i = RevisedByMarubatuMethod(i);
> とか、
> i = revised_by_marubatu_method(i);
>
> と書くよりは、
>
> i = ○×方式による補正を行う(i);
> ---
> And of
On 5/14/07, Talin <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Also, can we overload different-length signatures (like in C++ or
> > Java)? This is very common in those languages; while Python typically
> > uses default argument values, there are use cases that don't easily
> > fit in t
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):
> """This just defines the signature; no implementation here"""
Hello,
On 5/15/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> and comment their code ;). It would be nice to be able to find more
> examples in Java.
I believe that a lot of people do not know that you can use most
Unicode characters in Java identifiers. I did not know myself until
this discuss
62 matches
Mail list logo
