On Fri, Sep 21, 2018 at 02:10:00PM -0700, Guido van Rossum wrote:
> There's already a rejected PEP about a switch statement:
> https://www.python.org/dev/peps/pep-3103/. There's no point bringing this
> up again unless you have a new use case.
>
> There have been several promising posts to
> There have been several promising posts to python-ideas about the much
more powerful idea of a "match" statement
I actually even started working on a PEP about this (pattern matching), but
then decided to postpone it because it is unlikely that anything of this
size can be discussed/accepted in
There's already a rejected PEP about a switch statement:
https://www.python.org/dev/peps/pep-3103/. There's no point bringing this
up again unless you have a new use case.
There have been several promising posts to python-ideas about the much more
powerful idea of a "match" statement. Please
As Michael said, this belongs on python-ideas, but it's interesting. I'd
support it, though my input in that regard is worth approximately $0.00. ;)
It's the core devs and especially the eventual BDFL replacement whom you
would have to convince.
Without getting into an extended discussion here on
First, this sounds like it belongs on python-ideas, not python-dev.
Second, when you do send a message to python-ideas, it'll help to
accompany it with a realistic example usage that motivates your
proposal.
On Fri, Sep 21, 2018 at 11:18 AM wrote:
>
> Hi,
>
> A humble proposal for a switch-like
Hi,
A humble proposal for a switch-like statement syntax for Python:
- - -
switch blah in (100, 2, 30, 'bumm'):
dosomething1()
x = 88
case blah in (44, 55):
otherstuff(9)
case blah in (8):
boo()
else:
wawa()
- - -
So, let's use, and allow only *tuples*.
As early as possible, build a
On 6/26/06, Guido van Rossum [EMAIL PROTECTED] wrote:
I like Python's rules to be simple, and I
prefer to occasionally close off a potential optimization path in the
sake of simplicity.
(Almost) everyone agrees that the case expressions SHOULD be run-time
constants. The disagreements are
On 6/27/06, Jim Jewett [EMAIL PROTECTED] wrote:
On 6/26/06, Guido van Rossum [EMAIL PROTECTED] wrote:
I like Python's rules to be simple, and I
prefer to occasionally close off a potential optimization path in the
sake of simplicity.
(Almost) everyone agrees that the case expressions
On Tue, 27 Jun 2006, Jim Jewett wrote:
(Almost) everyone agrees that the case expressions SHOULD be run-time
constants. The disagreements are largely over what to do when this
gets violated.
I like your summary and understood most of it (options 1, 2, 3, 5, 6).
The only part i didn't
On 6/27/06, Jim Jewett [EMAIL PROTECTED] wrote:
Bad Case Option (5) -- ad hoc mixture
-
Pick an arbitrary set of rules, and follow it.
Guido is currently leaning towards this, with the rules being freeze
at definition, raise for unhashable, ignore later
In http://mail.python.org/pipermail/python-dev/2006-June/066475.html
Nick Coghlan wrote:
(Unlike Jim, I have no problems with restricting switch statements to
hashable objects and building the entire jump table at once - if what you want
is an arbitrary if-elif chain, then write one!)
I
On 6/26/06, Jim Jewett [EMAIL PROTECTED] wrote:
In http://mail.python.org/pipermail/python-dev/2006-June/066475.html
Nick Coghlan wrote:
(Unlike Jim, I have no problems with restricting switch statements to
hashable objects and building the entire jump table at once - if what you
want
On 6/24/06, Nick Coghlan [EMAIL PROTECTED] wrote:
[...] a syntactic nit that Eric Sumner pointed out. Since
it involves iteration over x to populate the jump table rather than doing a
containment test on x, using 'case in x' is misleading. It would be better
written as 'case *x'.
Then:
Phillip J. Eby wrote:
I don't see this as much of a problem, really: we can simply restrict
the optimization to well-known data types (homogenous switches using
integers or strings should cover 99.9% of all practical cases), and then
add an opcode that checks uses a separate dispatch object
Guido van Rossum wrote:
I'm currently leaning
towards making static expressions outside a function illegal and limit
switches outside a function to compile-time-constant expressions.
I'm not sure I like the idea of having things that
are illegal outside a function, because it can be a
nuisance
On 6/25/06, Greg Ewing [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
I'm currently leaning
towards making static expressions outside a function illegal and limit
switches outside a function to compile-time-constant expressions.
I'm not sure I like the idea of having things that
are
On 6/23/06, Edward C. Jones [EMAIL PROTECTED] wrote:
Python is a beautiful simple language with a rich standard library.
Python has done fine without a switch statement up to now. Guido left it
out of the original language for some reason (my guess is simplicity).
Why is it needed now? What
The current train of thought seems to be to handle a switch statement as
follows:
1. Define switch explicitly as a hash table lookup, with the hash table
built at function definition time
2. Allow expressions to be flagged as 'static' to request evaluation at
def-time
3. Have the
Josiah Carlson wrote:
This is a good thing, because if switch/case ends up functionally
identical to if/elif/else, then it has no purpose as a construct.
there's no shortage of Python constructs that are functionally identical
to existing constructs. as with all syntactic sugar, the emphasis
Guido van Rossum wrote:
just map
switch EXPR:
case E1:
...
case in E2:
...
else:
...
to
VAR = EXPR
if VAR == E1:
...
elif VAR in E2:
...
else:
...
where VAR is a temporary variable,
At 07:04 PM 6/24/2006 +0200, Fredrik Lundh wrote:
I don't see this as much of a problem, really: we can simply restrict
the optimization to well-known data types (homogenous switches using
integers or strings should cover 99.9% of all practical cases), and then
add an opcode that checks uses a
On Fri, 23 Jun 2006, Josiah Carlson wrote:
This is a good thing, because if switch/case ends up functionally
identical to if/elif/else, then it has no purpose as a construct.
This doesn't make sense as a rule.
Consider:
If x.y ends up functionally identical to getattr(x, 'y'),
then
Ka-Ping Yee [EMAIL PROTECTED] wrote:
On Fri, 23 Jun 2006, Josiah Carlson wrote:
This is a good thing, because if switch/case ends up functionally
identical to if/elif/else, then it has no purpose as a construct.
This doesn't make sense as a rule.
Consider:
If x.y ends up
Fredrik Lundh wrote:
Guido van Rossum wrote:
just map
switch EXPR:
case E1:
...
case in E2:
...
else:
...
to
VAR = EXPR
if VAR == E1:
...
elif VAR in E2:
...
else:
...
where VAR
Phillip J. Eby wrote:
1. case (literal|NAME) is the syntax for equality testing -- you can't
use an arbitrary expression, not even a dotted name.
That's too restrictive. I want to be able to write
things like
class Foods:
Spam = 1
Eggs = 2
Ham = 3
...
switch f:
Phillip J. Eby wrote:
I think I like it. I was confused by what Fredrik meant by const, but
your renaming it to static makes more sense to me;
footnote: I suggested static in my list of use cases; while const
makes sense in many cases, static makes more sense for things like this:
Guido van Rossum wrote:
That sounds like a good solution all around. I hope that others can
also find themselves in this.
(1) An expression of the form 'static' atom has the semantics of
evaluating the atom at the same time as the nearest surrounding
function definition. If there is no
Fredrik Lundh wrote:
I'd still prefer the explicit is better than implicit route, approach
switch/case (if added) is defined in terms of if/elif, and optimizations
are handled by the optimizer/code generator.
s/approach/where/
/F
___
Python-Dev
Fredrik Lundh wrote:
(now, if you're written implied 'break', I'm all for it)
note to self: the fact that it's a holiday doesn't mean that you should
post before you'd had enough coffee.
/F
___
Python-Dev mailing list
Python-Dev@python.org
Guido van Rossum [EMAIL PROTECTED] wrote:
(1) An expression of the form 'static' atom has the semantics of
evaluating the atom at the same time as the nearest surrounding
function definition. If there is no surrounding function definition,
'static' is a no-op and the expression is evaluated
On 6/22/06, Guido van Rossum [EMAIL PROTECTED] wrote:
...
(1) An expression of the form 'static' atom has the semantics of
evaluating the atom at the same time as the nearest surrounding
function definition. If there is no surrounding function definition,
'static' is a no-op and the
On 6/23/06, Josiah Carlson [EMAIL PROTECTED] wrote:
Guido van Rossum [EMAIL PROTECTED] wrote:
(1) An expression of the form 'static' atom has the semantics of
evaluating the atom at the same time as the nearest surrounding
function definition. If there is no surrounding function
On 6/23/06, Alex Martelli [EMAIL PROTECTED] wrote:
On 6/22/06, Guido van Rossum [EMAIL PROTECTED] wrote:
Independent from this, I wonder if we also need static names of the form
static name = expression
which would be similar to
name = static (expression)
but also prevents
Alex Martelli [EMAIL PROTECTED] wrote:
On 6/22/06, Guido van Rossum [EMAIL PROTECTED] wrote:
Independent from this, I wonder if we also need static names of the form
static name = expression
which would be similar to
name = static (expression)
but also prevents name from
Georg Brandl wrote:
M.-A. Lemburg wrote:
A nice side-effect would be that could easily use the
same approach to replace the often used default-argument-hack,
e.g.
def fraction(x, int=int, float=float):
return float(x) - int(x)
This would then read:
def fraction(x):
const int,
[delurking in response to the first really decisive message in the thread] ;-)
On 6/22/06, Guido van Rossum [EMAIL PROTECTED] wrote:
(1) An expression of the form 'static' atom has the semantics of
evaluating the atom at the same time as the nearest surrounding
function definition.
FWIW, +1.
Reading on in the thread it seems that there's agreement
on using static instead of const, to s/const/static
:-)
M.-A. Lemburg wrote:
Georg Brandl wrote:
M.-A. Lemburg wrote:
A nice side-effect would be that could easily use the
same approach to replace the often used default-argument-hack,
On 6/22/06, Guido van Rossum [EMAIL PROTECTED] wrote:
(3) A switch is implemented using a dict which is precomputed at the
same time its static expressions are precomputed. The switch
expression must be hashable. Overlap between different cases will
raise an exception at precomputation time.
Guido van Rossum [EMAIL PROTECTED] wrote:
On 6/23/06, Josiah Carlson [EMAIL PROTECTED] wrote:
Guido van Rossum [EMAIL PROTECTED] wrote:
Independent from this, I wonder if we also need static names of the form
static name = expression
which would be similar to
name =
At 07:51 PM 6/23/2006 +0200, M.-A. Lemburg wrote:
Furthermore, the compiler could do other optimizations on the
const declared names, such as optimizing away global lookups
and turning them into code object constants lookups.
Technically, they'd have to become LOAD_DEREF on cells set up by the
On 6/23/06, Eric Sumner [EMAIL PROTECTED] wrote:
On 6/22/06, Guido van Rossum [EMAIL PROTECTED] wrote:
(3) A switch is implemented using a dict which is precomputed at the
same time its static expressions are precomputed. The switch
expression must be hashable. Overlap between different
On 6/23/06, Josiah Carlson [EMAIL PROTECTED] wrote:
You later stated that decorators were the wrong way of handling it. I
believe that the...
static name = expression
...would require too many changes to what some regular python users have
come to expect from at least module namespaces.
Python is a beautiful simple language with a rich standard library.
Python has done fine without a switch statement up to now. Guido left it
out of the original language for some reason (my guess is simplicity).
Why is it needed now? What would be added next: do while or goto? The
urge to add
On 6/23/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
Hm. Did I miss something, or did we just solve builtin lookup
optimization? The only problem I see is that currently you can stick a new
version of 'len()' into a module from outside it, shadowing the
builtin. Under this scheme (of making
In http://mail.python.org/pipermail/python-dev/2006-June/066399.html, PJE wrote:
Python prefers to evaluate expressions in the order that they
appear in source code, ... first-time use preserves that
property; function definition time does not.
Guido wrote:
But first-time has the very big
In http://mail.python.org/pipermail/python-dev/2006-June/066409.html,
Guido wrote
(1) An expression of the form 'static' atom has the semantics of
evaluating the atom at the same time as the nearest surrounding
function definition.
(A) I prefer a term other than 'static'.
Looking at various
On 6/23/06, Jim Jewett [EMAIL PROTECTED] wrote:
In http://mail.python.org/pipermail/python-dev/2006-June/066399.html, PJE
wrote:
Python prefers to evaluate expressions in the order that they
appear in source code, ... first-time use preserves that
property; function definition time does
This post is too long for me to respond right now. I'm inviting others
to respond. I've got a feeling you're coming late to this discussion
and we're going around in circles.
--Guido
On 6/23/06, Jim Jewett [EMAIL PROTECTED] wrote:
In
On Fri, 2006-06-23 at 16:16 -0400, Edward C. Jones wrote:
Please keep Python simple.
+1 on this sentiment.
I use switch statements all the time in C, but I'd rather not see them
in Python - even though I'd use them if they were there! - purely to
keep the cognitive overhead low.
b
On 6/23/06, Guido van Rossum [EMAIL PROTECTED] wrote:
Here are a few examples showing my objections against first-use.
[Problem with nested scopes; today this usually shows up as (invalid)
bug reports about lambda, in which failure to bind a default
variable to itself causes it to take on the
On 6/23/06, Guido van Rossum [EMAIL PROTECTED] wrote:
No; in order to make it possible to use a single dict lookup for
dispatch, the set members are expanded into the dict key. If you have
a large contiguous range, you'll be better off (sometimes *much*
better) doing an explicit if/elif check
On Fri, 23 Jun 2006 13:38:35 -0700, Bryan O'Sullivan [EMAIL PROTECTED] wrote:
On Fri, 2006-06-23 at 16:16 -0400, Edward C. Jones wrote:
Please keep Python simple.
+1 on this sentiment.
I agree.
Jean-Paul
___
Python-Dev mailing list
Eric Sumner [EMAIL PROTECTED] wrote:
On 6/23/06, Guido van Rossum [EMAIL PROTECTED] wrote:
No; in order to make it possible to use a single dict lookup for
dispatch, the set members are expanded into the dict key. If you have
a large contiguous range, you'll be better off (sometimes
On 6/23/06, Josiah Carlson [EMAIL PROTECTED] wrote:
This is a good thing, because if switch/case ends up functionally
identical to if/elif/else, then it has no purpose as a construct. On
the other hand, because it is different from if/elif/else, and it is
different in such a way to make
On Jun 22, 2006, at 3:24 PM, Phillip J. Eby wrote:
Well, you can't def a dotted name, but I realize this isn't a
binding.
I have actually wanted to do that before. It would be nice if you
could. :)
James
___
Python-Dev mailing list
In that case, I would argue that the proposed syntax is misleading.
Regardless of how it is implemented, a switch statement is
conceptually a chain of if/elif statements. As such, the 'in'
keyword, if it is allowed at all, should behave like it does in if
statements, rather than it does
Guido van Rossum wrote:
That sounds like a good solution all around. I hope that others can
also find themselves in this.
(1) An expression of the form 'static' atom has the semantics of
evaluating the atom at the same time as the nearest surrounding
function definition. If there is no
Guido van Rossum wrote:
On 6/22/06, Nick Coghlan [EMAIL PROTECTED] wrote:
Talin wrote:
I don't get what the problem is here. A switch constant should have
exactly the bahavior of a default value of a function parameter. We
don't seem to have too many problems defining functions at the
Fredrik Lundh wrote:
Q: If a program calls the 'func' function below as 'func()'
and ONE and TWO are both integer objects, what does 'func'
^^
Nothing at all, because you didn't call it!
--
Greg
Ka-Ping Yee wrote:
Hmm, this is rather nice. I can imagine possible use cases for
switch x:
case 3: foo(x)
case is y: spam(x)
case == z: eggs(x)
Part of the readability advantage of a switch over an if/elif chain is
the semantic parallelism, which would make
Phillip J. Eby wrote:
switch x:
case == 1: foo(x)
Aesthetically, I don't like that.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Talin wrote:
I don't get what the problem is here. A switch constant should have
exactly the bahavior of a default value of a function parameter. We
don't seem to have too many problems defining functions at the module
level, do we?
Because in function definitions, if you put them inside
Phillip J. Eby wrote:
Maybe the real answer is to have a const declaration, not necessarily the
way that Fredrik suggested, but a way to pre-declare constants e.g.:
const FOO = 27
And then require case expressions to be either literals or constants. The
constants need not be
At 01:08 PM 6/22/2006 +0200, M.-A. Lemburg wrote:
Phillip J. Eby wrote:
Maybe the real answer is to have a const declaration, not necessarily
the
way that Fredrik suggested, but a way to pre-declare constants e.g.:
const FOO = 27
And then require case expressions to be either
On 6/22/06, Roger Miller [EMAIL PROTECTED] wrote:
Part of the readability advantage of a switch over an if/elif chain is
the semantic parallelism, which would make me question mixing different
tests in the same switch. What if the operator moved into the switch
header?
switch x ==:
Guido van Rossum wrote:
I've also been wondering whether the 'case' keyword is really necessary?
Would any ambiguities or other parsing problems arise if you wrote:
switch x:
1: foo(x)
2: bar(x)
It is debatable whether this is more or less readable, but it seemed
On 6/21/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 01:16 PM 6/21/2006 -0700, Guido van Rossum wrote:
Yeah, but if you have names for your constants it would be a shame if
you couldn't use them because they happen to be defined in the same
scope.
Maybe the real answer is to have a const
On 6/22/06, Greg Ewing [EMAIL PROTECTED] wrote:
Phillip J. Eby wrote:
switch x:
case == 1: foo(x)
Aesthetically, I don't like that.
Me neither.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev
On 6/22/06, Nick Coghlan [EMAIL PROTECTED] wrote:
Talin wrote:
I don't get what the problem is here. A switch constant should have
exactly the bahavior of a default value of a function parameter. We
don't seem to have too many problems defining functions at the module
level, do we?
Guido van Rossum wrote:
which simply means that expr will be evaluated at function definition
time, rather than at runtime. example usage:
var = expression
if var == constant sre.FOO:
...
elif var == constant sre.BAR:
...
elif var in constant
On 6/22/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
This hypothetical const would be a *statement*,
executed like any other statement. It binds a name to a value -- and
produces an error if the value changes. The compiler doesn't need to know
what it evaluates to at runtime; that's what
On 6/22/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
a constant (or perhaps better, const) primary would also be useful
in several other cases, including:
- as a replacement for default-argument object binding
- local dispatch tables, and other generated-but-static data structures
- explicit
On 6/22/06, Georg Brandl [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
I've also been wondering whether the 'case' keyword is really necessary?
Would any ambiguities or other parsing problems arise if you wrote:
switch x:
1: foo(x)
2: bar(x)
It is
Guido van Rossum wrote:
On 6/22/06, Georg Brandl [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
I've also been wondering whether the 'case' keyword is really necessary?
Would any ambiguities or other parsing problems arise if you wrote:
switch x:
1: foo(x)
At 09:37 AM 6/22/2006 -0700, Guido van Rossum wrote:
On 6/22/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
This hypothetical const would be a *statement*,
executed like any other statement. It binds a name to a value -- and
produces an error if the value changes. The compiler doesn't need to
On 6/22/06, Georg Brandl [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
On 6/22/06, Georg Brandl [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
I've also been wondering whether the 'case' keyword is really necessary?
Would any ambiguities or other parsing problems arise if you
Guido van Rossum wrote:
def foo(value):
const bar = fie.fum
if value == bar:
...
which would behave like
def foo(value, bar=fie.fum):
if value == bar:
...
but without the what if we pass in more than one argument? issue.
So
I think one of the problems I sometimes have in communicating with you is
that I think out stuff from top to bottom of an email, and sometimes
discard working assumptions once they're no longer needed. We then end up
having arguments over ideas I already discarded, because you find the
On 6/22/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
So the constant would be evaluated at function definition time? I find
that rather confusing.
well, I find the proposed magic behaviour of case at least as confusing...
It's not magic if it can be explained. def
On 6/22/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
I think one of the problems I sometimes have in communicating with you is
that I think out stuff from top to bottom of an email, and sometimes
discard working assumptions once they're no longer needed. We then end up
having arguments over
Guido van Rossum wrote:
Without const declarations none of this can work and
the at-function-definition-time freezing is the best, because most
predictable, approach IMO.
I you like this approach best, then how about using the same
approach as we have for function default argument values:
Guido van Rossum wrote:
well, I find the proposed magic behaviour of case at least as confusing...
It's not magic if it can be explained. def goes over all the cases
and evaluates them in the surrounding scope and freezes the meaning of
the cases that way as long as the function object
On Wed, 21 Jun 2006, Guido van Rossum wrote:
I worry (a bit) about this case:
y = 12
def foo(x, y):
switch x:
case y: print something
which to the untrained observer (I care about untrained readers much
more than about untrained writers!) looks like it would print
something
On 6/22/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
It's not magic if it can be explained. def goes over all the cases
and evaluates them in the surrounding scope and freezes the meaning of
the cases that way as long as the function object survives is not
magic.
M.-A. Lemburg wrote:
A nice side-effect would be that could easily use the
same approach to replace the often used default-argument-hack,
e.g.
def fraction(x, int=int, float=float):
return float(x) - int(x)
This would then read:
def fraction(x):
const int, float
return
On Wed, 21 Jun 2006, Guido van Rossum wrote:
(Note how I've switched to the switch-for-efficiency camp, since it
seems better to have clear semantics and a clear reason for the syntax
to be different from if/elif chains.)
I don't think switch-for-efficiency (at least if efficiency is the
On 6/22/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
[Phillip]
1. case (literal|NAME) is the syntax for equality testing -- you can't
use an arbitrary expression, not even a dotted name.
[Guido]
But dotted names are important! E.g. case re.DOTALL. And sometimes
compile-time constant
At 12:24 PM 6/22/2006 -0700, Guido van Rossum wrote:
OK, I think I see how this works. You pre-compute the expression at
def-time, squirrel it away in a hidden field on the function object,
and assign it to a local each time the statement is executed.
More precisely, I'd say that the computation
At 12:54 PM 6/22/2006 -0700, Guido van Rossum wrote:
Summarizing our disagreement, I think you feel that
freeze-on-first-use is most easily explained and understood while I
feel that freeze-at-def-time is more robust. I'm not sure how to get
past this point except by stating that you haven't
On 6/22/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 12:54 PM 6/22/2006 -0700, Guido van Rossum wrote:
Summarizing our disagreement, I think you feel that
freeze-on-first-use is most easily explained and understood while I
feel that freeze-at-def-time is more robust. I'm not sure how to get
On Wed, 21 Jun 2006, Phillip J. Eby wrote:
Well, EIBTI and all that:
switch x:
case == 1: foo(x)
case in S: bar(x)
It even lines up nicely. :)
Hmm, this is rather nice. I can imagine possible use cases for
switch x:
case 3: foo(x)
case is y:
Ka-Ping Yee wrote:
On Wed, 21 Jun 2006, Phillip J. Eby wrote:
Well, EIBTI and all that:
switch x:
case == 1: foo(x)
case in S: bar(x)
It even lines up nicely. :)
Hmm, this is rather nice. I can imagine possible use cases for
switch x:
case 3:
Greg Ewing wrote:
Phillip J. Eby wrote:
Actually, one could consider case expressions to be computed at function
definition time, the way function defaults are. That would solve the
problem of symbolic constants, or indeed any sort of expressions.
That's an excellent idea!
It's just
At 03:38 AM 6/21/2006 -0500, Ka-Ping Yee wrote:
On Wed, 21 Jun 2006, Phillip J. Eby wrote:
Well, EIBTI and all that:
switch x:
case == 1: foo(x)
case in S: bar(x)
It even lines up nicely. :)
Hmm, this is rather nice. I can imagine possible use cases for
On 6/21/06, Nick Coghlan [EMAIL PROTECTED] wrote:
There's some benefit to first time it's executed though:
a. it allows access to the local namespace
And how would that be a good thing? It just begs for confusion if the
local variable doesn't always have the same value. (Yes, globals may
On 6/21/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 03:38 AM 6/21/2006 -0500, Ka-Ping Yee wrote:
On Wed, 21 Jun 2006, Phillip J. Eby wrote:
Well, EIBTI and all that:
switch x:
case == 1: foo(x)
case in S: bar(x)
It even lines up nicely. :)
Hmm,
At 09:16 AM 6/21/2006 -0700, Guido van Rossum wrote:
After thinking about it a bit I think that if it's not immediately
contained in a function, it should be implemented as alternative
syntax for an if/elif chain.
That worries me a little. Suppose I write a one-off script like this:
for line in
Guido van Rossum wrote:
(Note how I've switched to the switch-for-efficiency camp, since it
seems better to have clear semantics and a clear reason for the syntax
to be different from if/elif chains.)
if you're now in the efficiency camp, why not just solve this on the
code generator level ?
On 6/21/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
(Note how I've switched to the switch-for-efficiency camp, since it
seems better to have clear semantics and a clear reason for the syntax
to be different from if/elif chains.)
if you're now in the efficiency
On 6/21/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 09:16 AM 6/21/2006 -0700, Guido van Rossum wrote:
After thinking about it a bit I think that if it's not immediately
contained in a function, it should be implemented as alternative
syntax for an if/elif chain.
That worries me a little.
1 - 100 of 174 matches
Mail list logo
