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 python-
> 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 searc
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 st
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 ju
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, igno
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 unders
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 expr
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/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
>
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 hav
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? Wh
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 th
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
nuisan
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
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:
> 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:
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:
>>>
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 en
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
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
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:
>> ...
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 empha
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 exp
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 function
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' has the semantics of
> evaluating the atom at the same time as the nearest surrounding
> function definition. If there is no su
> > 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 tha
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
Python-De
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
"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 (s
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
Python-D
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 c
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
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.
http:
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 http://mail.python.org/pipermail/python-dev/2006-June/06640
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 definit
In http://mail.python.org/pipermail/python-dev/2006-June/066409.html,
Guido wrote
> (1) An expression of the form 'static' 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 c
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 ve
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 ma
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 s
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 =
> ...would require too many changes to what some regular python users have
> come to expect from at least module namespaces. I have n
On 6/23/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Guido van Rossum 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
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 dif
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
"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 =
> > >
> > > which would be similar to
> >
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 ti
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-a
[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' has the semantics of
> evaluating the atom at the same time as the nearest surrounding
> function definition.
FWIW, +1.
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 fractio
"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 =
> >
> > which would be similar to
> >
> >= static ()
> >
> > but also prevents from being assi
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 =
> >
> > which would be similar to
> >
> >= static ()
> >
> > but also prevents from b
On 6/23/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> > (1) An expression of the form 'static' has the semantics of
> > evaluating the atom at the same time as the nearest surrounding
> > function definition. If there is no surrounding function d
On 6/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
...
> (1) An expression of the form 'static' 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 expres
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> (1) An expression of the form 'static' 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 evaluate
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.
___
Python-Dev mailing list
Python-Dev@python.org
http://m
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/
___
Python-De
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' has the semantics of
> evaluating the atom at the same time as the nearest surrounding
> function definition. If there is no su
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:
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
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 co
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 computatio
On 6/22/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> 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
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
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
pri
Fredrik Lundh wrote:
> I'm not sure it should, actually -- the primary form is more flexible,
> and it better matches how things work: it's the expression that's
> special, not the variable.
>
> and things like
>
> radian = degree * static (math.pi / 180)
>
> would be pretty nice, for th
At 11:52 AM 6/22/2006 -0700, Guido van Rossum wrote:
>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 n
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
>
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
>
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
>
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 obj
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:
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 ov
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 explaine
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
problem
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
On 6/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> 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
>
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 p
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
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:
>> >>
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: b
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
>
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 wh
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 i
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
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-
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
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,
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
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
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
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 insid
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:
http://mail.python.org/mail
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 woul
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
___
Phillip J. Eby wrote:
> At 09:55 AM 6/21/2006 -0700, Guido van Rossum wrote:
>
>>BTW a switch in a class should be treated the same as a global switch.
>>But what about a switch in a class in a function?
>
>
> Okay, now my head hurts. :)
>
> A switch in a class doesn't need to be treated the s
At 01:16 PM 6/21/2006 -0700, Guido van Rossum wrote:
>On 6/21/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > >But that's not the discerning rule in my mind; the rule is, how to
> > >define "at function definition time".
> >
> > Wa! (i.e., my head hurts again :)
>
>Um, wasn't this your propo
On 6/21/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Fredrik Lundh wrote:
>
> >> But in most cases the 'constant' is actually an expression involving a
> >> global, often even a global in another module. (E.g. sre_compile.py)
> >> The compiler will have a hard time proving that this is really a
>
On 6/21/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >But that's not the discerning rule in my mind; the rule is, how to
> >define "at function definition time".
>
> Wa! (i.e., my head hurts again :)
Um, wasn't this your proposal (to freeze the case expressions at
function definition time)
Fredrik Lundh wrote:
>> But in most cases the 'constant' is actually an expression involving a
>> global, often even a global in another module. (E.g. sre_compile.py)
>> The compiler will have a hard time proving that this is really a
>> constant, so it won't optimize the code.
>
> unless we come
1 - 100 of 184 matches
Mail list logo
