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
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 function.
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
proposal
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 because the
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
compiler still has to figure
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
compiler still has to figure out how
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 what
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 up
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:
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 of
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
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...
/F
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
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 Option 2 is
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. For example:
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
old-fashioned
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
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.
Well,
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 the only
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
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
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
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 expressions
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 constants.
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
PEP also
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, 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, define
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
process,
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 expression
in switch call you could just call the switch -- no new syntax
needed. Your example
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
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* the for
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:
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
used in
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
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
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:
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
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
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 be
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
of
40 matches
Mail list logo
