On 6/26/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> With the simplified proposal, this would be coded with an inverse mapping:
>
> for event in pygame.event.get():
> switch eventmap[event.type]:
> case 'KEYDOWN': ...
> case 'KEYUP': ...
> case 'QUIT': ...
Michael Urman wrote:
> I'm trying to find some real world examples of a pygame event loop
>
>that really show the benefit of supporting named constants and
>expressions. I may mess up irrelevant details, but the primary case
>looks something like the following (perhaps Pete Shinners could point
>u
On 6/26/06, Michael Urman <[EMAIL PROTECTED]> wrote:
> I also would like to see a way to use 'is' instead of (or inaddition
> to) '==' for the comparison, but I don't have any use cases behind
> this.
I've thought about this a bit, and I think it's a red herring. I've
seen some places where 'is' i
On 6/25/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Those were not empty words. I provided two non-trivial worked-out examples
> taken from sre_constants.py and opcode.py. Nick provided a third example from
> decimal.py. In all three cases, the proposal was applied effortlessly
> resulti
Guido van Rossum wrote:
> Here's an argument for allowing names (this argument has been used
> successfully for using names instead of string literals in many APIs):
> if there is a spelling error in the string literal, the case will
> silently be ignored, and who knows when the bug is detected. I
Raymond Hettinger wrote:
> The static() keyword works like Forth's brackets for forcing
> compile-time evaluation. The issue for us is that unlike other Python
> expressions, there are inconvenient limitiations on what can be
> expressed inside:
>
>five = 5
>eight = [8]
>def f(x,
At 01:37 PM 6/25/2006 -0700, Raymond Hettinger wrote:
>>>No thanks. That is its own can of worms. The obvious solutions (like const
>>>declarations, macros, or a syntax to force compile-time expression
>>>evaluation)
>>>are unlikely to sit well because they run afoul Python's deeply ingrained
>
On 6/25/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> On Sun, 25 Jun 2006, Guido van Rossum wrote:
> > In your eagerness to
> > rule out surprises, you're creating the biggest surprise of all: the
> > restriction to literals is certainly a surprise!
>
> I disagree. Perhaps what we mean by "surprise
On Sun, 25 Jun 2006, Guido van Rossum wrote:
> In your eagerness to
> rule out surprises, you're creating the biggest surprise of all: the
> restriction to literals is certainly a surprise!
I disagree. Perhaps what we mean by "surprise" is different. In
Raymond's design, there is a simple rule f
Raymond Hettinger wrote:
>>>No thanks. That is its own can of worms. The obvious solutions (like const
>>>declarations, macros, or a syntax to force compile-time expression
>>>evaluation)
>>>are unlikely to sit well because they run afoul Python's deeply ingrained
>>>dynamism.
>>>
>>>
>>
>>I
On Sat, 24 Jun 2006, Phillip J. Eby wrote:
> At 03:49 PM 6/24/2006 -0700, Raymond Hettinger wrote:
> >Cases values must be ints, strings, or tuples of ints or strings.
>
> -1. There is no reason to restrict the types in this fashion. Even if you
> were trying to ensure marshallability, you could
On Sat, 24 Jun 2006, Raymond Hettinger wrote:
> The main points of contention are 1) a non-ambiguous syntax for assigning
> multiple cases to a single block of code, 2) how to compile variables as
> constants in a case statement, and 3) handling overlapping cases.
>
> Here's a simple approach that
>>No thanks. That is its own can of worms. The obvious solutions (like const
>>declarations, macros, or a syntax to force compile-time expression
>>evaluation)
>>are unlikely to sit well because they run afoul Python's deeply ingrained
>>dynamism.
>>
>>
>
>I think perhaps you haven't been p
At 11:13 AM 6/25/2006 -0700, Raymond Hettinger wrote:
>No thanks. That is its own can of worms. The obvious solutions (like const
>declarations, macros, or a syntax to force compile-time expression
>evaluation)
>are unlikely to sit well because they run afoul Python's deeply ingrained
>dynamism.
> Sorry, no go. You can say "supports key use cases found in real code"
> as often as you like,
Those were not empty words. I provided two non-trivial worked-out examples
taken from sre_constants.py and opcode.py. Nick provided a third example from
decimal.py. In all three cases, the proposal
Sorry, no go. You can say "supports key use cases found in real code"
as often as you like, but limiting it only to literals drops many use
cases on the floor, and is unacceptable for me. There are no other
places in Python where only literals are allowed. In your eagerness to
rule out surprises, y
Phillip J. Eby wrote:
> At 05:30 PM 6/24/2006 -0700, Raymond Hettinger wrote:
>> [Phillip Eby]
>>> I would like to be able to use switches on types, enumerations, and the
>> like.
>>
>> Be careful about wanting everything and getting nothing.
>> My proposal is the simplest thing that gets the job
Raymond Hettinger wrote:
>>From what I can see, almost everyone wants a switch statement, though perhaps
> for different reasons.
>
> The main points of contention are 1) a non-ambiguous syntax for assigning
> multiple cases to a single block of code, 2) how to compile variables as
> constants
Raymond Hettinger wrote:
> [Phillip Eby]
>> I would like to be able to use switches on types, enumerations, and the like.
>
> Be careful about wanting everything and getting nothing.
> My proposal is the simplest thing that gets the job done for key use cases
> found
> in real code.
> Also, it i
At 05:30 PM 6/24/2006 -0700, Raymond Hettinger wrote:
>[Phillip Eby]
> > I would like to be able to use switches on types, enumerations, and the
> like.
>
>Be careful about wanting everything and getting nothing.
>My proposal is the simplest thing that gets the job done for key use cases
>found
>
On Sat, Jun 24, 2006, Raymond Hettinger wrote:
>
> So, that is it, my proposal for simple switch statements with a
> straight-forward implementation, fast execution, simply explained
> behavior, and applicability to to the most important use cases.
+1
I've been trying to write a response to these
[Phillip Eby]
> I would like to be able to use switches on types, enumerations, and the like.
Be careful about wanting everything and getting nothing.
My proposal is the simplest thing that gets the job done for key use cases
found
in real code.
Also, it is defined tightly enough to allow room f
At 03:49 PM 6/24/2006 -0700, Raymond Hettinger wrote:
>Cases values must be ints, strings, or tuples of ints or strings.
-1. There is no reason to restrict the types in this fashion. Even if you
were trying to ensure marshallability, you could still include unicode and
longs. However, there i
>From what I can see, almost everyone wants a switch statement, though perhaps
for different reasons.
The main points of contention are 1) a non-ambiguous syntax for assigning
multiple cases to a single block of code, 2) how to compile variables as
constants in a case statement, and 3) handling
24 matches
Mail list logo
