Hi,
On Mon, Jun 26, 2006 at 12:23:00PM -0700, Guido van Rossum wrote:
> Feedback (also about misrepresentation of alternatives I don't favor)
> is most welcome, either to me directly or as a followup to this post.
So my 2 cents, particularly about when things are computed and ways to
control that
> yeah, but what are they? integers? strings? names without an associated
> value?
> how do you create new labels? where are they stored? who keeps track of
> them?
In this scheme, dispatch tables can be considered to be reverse-lookup
namespaces. Where a regular namespace is used to look
> >> what's a "label" ?
> >
> > In your example, RED, GREEN, and BLUE. colours provides a mapping
> > from values to labels/cases, and the switch statement provides a
> > mapping from labels/cases to code. Sorry about introducing a new term
> > without saying anything about it.
>
> yeah, but what
Eric Sumner wrote:
>> what's a "label" ?
>
> In your example, RED, GREEN, and BLUE. colours provides a mapping
> from values to labels/cases, and the switch statement provides a
> mapping from labels/cases to code. Sorry about introducing a new term
> without saying anything about it.
yeah, but
> >> You mean something like this?:
> >>
> >>switch x in colours:
> >> case RED:
> >> # whatever
> >> case GREEN:
> >> # whatever
> >> case BLUE:
> >> # whatever
> >>
> >> I think Guido's right. It doesn't solve the underlying problem because the
> >> c
Eric Sumner wrote:
>> You mean something like this?:
>>
>>switch x in colours:
>> case RED:
>> # whatever
>> case GREEN:
>> # whatever
>> case BLUE:
>> # whatever
>>
>> I think Guido's right. It doesn't solve the underlying problem because the
>> compi
On 6/29/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> You mean something like this?:
>
>switch x in colours:
> case RED:
> # whatever
> case GREEN:
> # whatever
> case BLUE:
> # whatever
>
> I think Guido's right. It doesn't solve the underlying problem
Eric Sumner wrote:
>>> Forget subroutines for a moment - the main point of the thread was the
>>> idea that the dispatch table was built explicitly rather than
>>> automatically - that instead of arguing over first-use vs.
>>> function-definition, we let the user decide. I'm sure that my specific
>
Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> By 'current namespace' I really do mean locals() - the cell objects
>> themselves
>> would be local variables from the point of view of the currently
>> executing code.
>
> This is wrong. Cells are *parameters* implicitly passed
> in by the calling f
Talin wrote:
> The case -> sub mapping doesn't need to be defined every time - that's
> the point, you as the programmer decide when and how to construct the
> dictionary,
Then you seem to be proposing a variation on the constant-only
case option, with a more convoluted control flow.
--
Greg
_
Nick Coghlan wrote:
> By 'current namespace' I really do mean locals() - the cell objects themselves
> would be local variables from the point of view of the currently executing
> code.
This is wrong. Cells are *parameters* implicitly passed
in by the calling function. They may temporarily be
re
> > Forget subroutines for a moment - the main point of the thread was the
> > idea that the dispatch table was built explicitly rather than
> > automatically - that instead of arguing over first-use vs.
> > function-definition, we let the user decide. I'm sure that my specific
> > proposal isn't t
On 6/28/06, Talin <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Let's just drop the switchable subroutine proposal. It's not viable.
>
> Perhaps not - but at the same time, when discussing new language
> features, let's not just limit ourselves to what other languages have
> done already
Guido van Rossum wrote:
> Let's just drop the switchable subroutine proposal. It's not viable.
>
Perhaps not - but at the same time, when discussing new language
features, let's not just limit ourselves to what other languages have
done already.
Forget subroutines for a moment - the main point
Let's just drop the switchable subroutine proposal. It's not viable.
On 6/28/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> Talin <[EMAIL PROTECTED]> wrote:
> > Josiah Carlson wrote:
> > > Talin <[EMAIL PROTECTED]> wrote:
> > >
> > >>My version of this is to add to Python the notion of a simple
Talin <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > Talin <[EMAIL PROTECTED]> wrote:
> >
> >>My version of this is to add to Python the notion of a simple
> >>old-fashioned subroutine - that is, a function with no arguments and no
> >>additional scope, which can be referred to by name.
On 6/28/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I think we all agree
> > that side effects of case expressions is one way how we can deduce the
> > compiler's behind-the-scenes tricks (even School Ib is okay with
> > this). So I don't accept this as proof that Opti
Looks like this doesn't help at all when pre-computing the dispatch
dict based on named constants. So this is a no-go.
I should add that ABC had such named subroutines (but not for
switching); I dropped them to simplify things. They're not an
intrinsically undesirable or even unnecessary thing IMO
Guido van Rossum wrote:
>> Is it unacceptable - or impractical - to break the addition of switch
>> to python in two (minor version separated) steps ?
>
> But what's the point? We have until Python 3000 anyway.
except that we may want to "reserve" the necessary keywords in 2.6...
__
Nick Coghlan wrote:
> There certainly isn't anything in the code above to suggest to a reader that
> the condition attempting to guard evaluation of the switch statement might not
> do its job.
that's why the evaluation model used in the case statement needs to be explicit.
that applies to the "
Josiah Carlson wrote:
> Talin <[EMAIL PROTECTED]> wrote:
>
>>My version of this is to add to Python the notion of a simple
>>old-fashioned subroutine - that is, a function with no arguments and no
>>additional scope, which can be referred to by name. For example:
>
>
> I don't like the idea of
Guido van Rossum wrote:
> I think we all agree
> that side effects of case expressions is one way how we can deduce the
> compiler's behind-the-scenes tricks (even School Ib is okay with
> this). So I don't accept this as proof that Option 2 is better.
OK, I worked out a side effect free example o
Talin <[EMAIL PROTECTED]> wrote:
> My version of this is to add to Python the notion of a simple
> old-fashioned subroutine - that is, a function with no arguments and no
> additional scope, which can be referred to by name. For example:
I don't like the idea of an embedded subrutine for a few
Guido van Rossum wrote:
> On 6/27/06, Ron Adam <[EMAIL PROTECTED]> wrote:
>
>>So modeling the switch after dictionary dispatching more directly where
>>the switch is explicitly defined first and then used later might be good
>>both because it offers reuse in the current scope and it can easily be
Ron Adam wrote:
> In this instance the switch would be redefined 10 times. The ending
> switch would be:
>
> switch S:
>case 10: print 42
Silly mistake correction... :)
switch S:
case 9: print 42
___
Python-Dev mailing
Guido van Rossum wrote:
>> What was intended probably would be more closely related to constructing
>> a switch with BASICS gosub command.
>
> I understand now.
>
> But I have a question: if I write
>
> for i in range(10):
>switch S:
> case i: print 42
>
> (i.e. the switch is *inside
> But what's the point? We have until Python 3000 anyway.
Ah, my mistake. In my enthusiasm, I foolishly got the time frames of
peps 3103 & 275 mixed up.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
U
On 6/27/06, Ron Adam <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > It looks like your proposal is to change switch into a command that
> > defines a function of one parameter. Instead of the "do
> > in " call you could just call the switch -- no new syntax
> > needed. Your example above
Guido van Rossum wrote:
> On 6/27/06, Ron Adam <[EMAIL PROTECTED]> wrote:
>> I use dict base dispatching in a number of my programs and like it with
>> the exception I need to first define all the code in functions (or use
>> lambda) even if they are only one line. So it results in a three step
>>
On 6/27/06, Ron Adam <[EMAIL PROTECTED]> wrote:
> I use dict base dispatching in a number of my programs and like it with
> the exception I need to first define all the code in functions (or use
> lambda) even if they are only one line. So it results in a three step
> process, define functions, d
> Given that variant, my reasons for preferring Option 2 over Option 3 are:
> - the semantics are the same at module, class and function level
> - the order of execution roughly matches the order of the source code
> - it does not cause any surprises when switches are inside conditional logic
On 6/27/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I've written a new PEP, summarizing (my reaction to) the recent
> > discussion on adding a switch statement. While I have my preferences,
> > I'm trying to do various alternatives justice in the descriptions. The
> >
On 6/27/06, Robin Bryce <[EMAIL PROTECTED]> wrote:
> > PEP 3103, When to Freeze the Dispatch Dict/Option 1
>
> 2 things resonated with me for Raymond's proposal and the follow up:
>
> - It seemed agnostic to almost all of the independently contentious issues.
Except for the need to use named const
On 6/26/06, K.S.Sreeram <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I think we need a PEP for const/static/only/cached/precomputed or
> > whatever people like to call it.
>
> fredrik's got a micro pep at http://online.effbot.org
>
> > Once we have (say) static, I think making the case
Guido van Rossum wrote:
> For a real example from C++, read "Double Checked Locking is Broken":
> http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
> (I first heard about this from Scott Meyers at the '06 ACCU conference
> in Oxford; an earlier version of his talk is also onlin
Guido van Rossum wrote:
> I've written a new PEP, summarizing (my reaction to) the recent
> discussion on adding a switch statement. While I have my preferences,
> I'm trying to do various alternatives justice in the descriptions. The
> PEP also introduces some standard terminology that may be help
> PEP 3103, When to Freeze the Dispatch Dict/Option 1
2 things resonated with me for Raymond's proposal and the follow up:
- It seemed agnostic to almost all of the independently contentious issues.
- "is defined tightly enough to allow room for growth and elaboration over
time" [Raymond]. In par
Guido van Rossum wrote:
> I think we need a PEP for const/static/only/cached/precomputed or
> whatever people like to call it.
fredrik's got a micro pep at http://online.effbot.org
> Once we have (say) static, I think making the case expressions static
> by default would still cover all useful ca
On 6/26/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > Most school I proponents (perhaps you're the only exception) have
> > claimed that optimization is desirable, but added that it would be
> > easy to add hash-based optimization. IMO it's not so easy in the light
>
Guido van Rossum wrote:
> Most school I proponents (perhaps you're the only exception) have
> claimed that optimization is desirable, but added that it would be
> easy to add hash-based optimization. IMO it's not so easy in the light
> of various failure modes of hash(). (A possible solution would
On 6/26/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> On Mon, 26 Jun 2006, Guido van Rossum wrote:
> > Most school I proponents (perhaps you're the only exception) have
> > claimed that optimization is desirable, but added that it would be
> > easy to add hash-based optimization. IMO it's not so eas
On Mon, 26 Jun 2006, Guido van Rossum wrote:
> Most school I proponents (perhaps you're the only exception) have
> claimed that optimization is desirable, but added that it would be
> easy to add hash-based optimization. IMO it's not so easy in the light
> of various failure modes of hash(). (A pos
On 6/26/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> On Mon, 26 Jun 2006, Guido van Rossum wrote:
> > Can you please edit the PEP yourself to add this? That will be most
> > efficient.
>
> I've done so, and tried to clarify the next line to match (see below).
>
> > With school I, if you want to
>
On Mon, 26 Jun 2006, Guido van Rossum wrote:
> Can you please edit the PEP yourself to add this? That will be most efficient.
I've done so, and tried to clarify the next line to match (see below).
> With school I, if you want to
> optimize using a hash table (as in PEP 275 Solution 1) you have to
On 6/26/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> On Mon, 26 Jun 2006, Guido van Rossum wrote:
> > I've written a new PEP, summarizing (my reaction to) the recent
> > discussion on adding a switch statement. While I have my preferences,
> > I'm trying to do various alternatives justice in the de
On Mon, 26 Jun 2006, Guido van Rossum wrote:
> I've written a new PEP, summarizing (my reaction to) the recent
> discussion on adding a switch statement. While I have my preferences,
> I'm trying to do various alternatives justice in the descriptions.
Thanks for writing this up!
The section that
I've written a new PEP, summarizing (my reaction to) the recent
discussion on adding a switch statement. While I have my preferences,
I'm trying to do various alternatives justice in the descriptions. The
PEP also introduces some standard terminology that may be helpful in
future discussions. I'm p
47 matches
Mail list logo
