Re: [Python-Dev] Switch statement
This discussion appears to repeat everything we already have
in the PEP 275:
http://www.python.org/dev/peps/pep-0275/
FWIW, below is a real-life use case that would
benefit from a switch statement or an optimization of the
existing if-elif-else case. It's the unpickler inner loop
of an XML pickle mechanism for Python objects.
Many parser doing the usual tokenize first, then parse the
tokens steps would benefit in the same way by avoiding the
function call overhead.
Note that you rarely have the situation where you need
to have a single cases for huge ranges of values (and
these can easily be handled in a separate if-else in the
else branch of the switch).
You do sometimes need to identical code for a few cases, so
allowing multiple values per case would make such use cases
have less code duplication.
However, using tuple syntax for
this would not be ideal, since a tuple may well be a valid value
to test for. This was discussed last time around: the only
way to cover this case is to always use tuple notation
for the values (see the syntax example in the PEP).
The code currently relies on Python interning
constants that appear in code, making the 'is' test slightly
faster than the '==' test.
for tag in taglist:
node = tag.name
tagtype = tag.type
if tagtype == DATA:
if readdata:
data = tag.tag
readdata = 0
continue
# This is where the switch would start...
elif node is 'int':
if tagtype == STARTTAG:
readdata = 1
continue
elif tagtype == ENDTAG:
stack.append(int(data))
continue
elif node is 'float':
if tagtype == STARTTAG:
readdata = 1
continue
elif tagtype == ENDTAG:
stack.append(float(data))
continue
elif node is 'long':
if tagtype == STARTTAG:
readdata = 1
continue
elif tagtype == ENDTAG:
stack.append(long(data))
continue
elif node is 'string':
if tagtype == STARTTAG:
refid = int(tag.attributes['id'])
readdata = 1
continue
elif tagtype == ENDTAG:
data = xmlunescape(data, xmlentities)
obj = data.encode('latin-1')
stack.append(obj)
memo[refid] = obj
continue
elif node is 'tuple':
if tagtype == STARTTAG:
refid = int(tag.attributes['id'])
pushframe((node, stack, refid))
stack = []
continue
elif tagtype == ENDTAG:
obj = tuple(stack)
node, stack, refid = popframe()
memo[refid] = obj
stack.append(obj)
continue
elif node is 'list':
if tagtype == STARTTAG:
refid = int(tag.attributes['id'])
pushframe((node, stack, refid))
stack = []
continue
elif tagtype == ENDTAG:
obj = list(stack)
node, stack, refid = popframe()
memo[refid] = obj
stack.append(obj)
continue
elif node is 'dict':
if tagtype == STARTTAG:
refid = int(tag.attributes['id'])
pushframe((node, stack, refid))
stack = []
continue
elif tagtype == ENDTAG:
items = stack
node, stack, refid = popframe()
obj = {}
for k,v in items:
obj[k] = v
memo[refid] = obj
stack.append(obj)
continue
elif node is 'item':
if tagtype == STARTTAG:
continue
elif tagtype == ENDTAG:
key = stack[-2]
value = stack[-1]
stack[-2] = (key, value)
del stack[-1]
continue
elif node is 'key' or \
node is 'value':
if tagtype == STARTTAG:
continue
elif tagtype == ENDTAG:
continue
elif node is 'none':
if tagtype == STARTTAG:
stack.append(None)
continue
elif tagtype == ENDTAG:
continue
Re: [Python-Dev] Switch statement
On Mon, 19 Jun 2006, Josiah Carlson wrote: I personally don't find switch/case statements to be significantly (if at all) easier to read than if/elif/else chains, but that is subjective, and I note that Ka-Ping finds switch/case to be significantly easier to read. Uh, i didn't mean to say that. I said readability should be the primary motivator for new syntax (in general). Whether switch/case provides a significant readability improvement, and how often it turns out to be useful -- these things depend on the semantics we choose. -- ?!ng ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Documentation enhancement: MS free compiler?
On 6/19/06, Paul Moore [EMAIL PROTECTED] wrote: I'll see if I have time to look at the README and suggest suitable words. I've uploaded http://www.python.org/sf/1509163 and assigned it to you, Martin. I hope that's OK. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Numerical robustness, IEEE etc.
This mail never appeared on python-dev as far as I can tell, so I'm not snipping anything. On 19 Jun 2006, at 16:29, Nick Maclaren wrote: Michael Hudson [EMAIL PROTECTED] wrote: As I have posted to comp.lang.python, I am not happy with Python's numerical robustness - because it basically propagates the 'features' of IEEE 754 and (worse) C99. That's not really now I would describe the situation today. It is certainly the case in 2.4.2, however you would describe it. I guess you could say it reflects the features of C89. It certainly doesn't do anything C99 specific. But I wouldn't characterize anything Python does in the floating point area as designed, particularly. Portability makes that hard. 2) Because some people are dearly attached to the current behaviour, warts and all, and there is a genuine quandary of whether the 'right' behaviour is trap-and-diagnose, propagate-NaN or whatever-IEEE-754R- finally-specifies (let's ignore C99 and Java as beyond redemption), Why? Maybe it's clear to you, but it's not totally clear to me, and it any case the discussion would be better informed for not being too dismissive. Why which? Why are C99 and Java beyond redemption? I know some of the mistakes Java makes here, but still, you could at least hint at which you are thinking of. There are several things that you might be puzzled over. And where can I start? Part of the problem is that I have spent a LOT of time in these areas in the past decades, and have been involved with many of the relevant standards, and I don't know what to assume. Well, if you can't explain what your intentions are to *me*, as a mathematics-degree holding core Python developer that has done at least some work in this area, I posit that you aren't going to get very far. I'm not intimately familiar with the standards like 754 but I have some idea what they contain, and I've read appendix F of C99, if that helps you target your explanations. there might well need to be options. These can obviously be done by a command-line option, an environment variable or a float method. There are reasons to disfavour the last, but all are possible. Which is the most Pythonesque approach? I have heard Tim say that there are people who would dearly like to be able to choose. Environment variables and command line switches are not Pythonic. All right, but what is? Firstly, for something that needs to be program-global? Why does it need to be program global? In my not-really-thought-out plans for straightening out CPython's floating point story I had envisioned code to be written something like this: with fp_context(non_stop_context): a = 1e308*1e308 # a is now +inf b = a/a # b is now a quiet nan with fp_context(all_traps_context): a = 1.0/3.0 # raises some Inexact exception (and have a default context which raises for Overflow, DivideByZero and InvalidOperation and ignores Underflow and Inexact). This could be implemented by having a field in the threadstate of FPU flags to check after each fp operation (or each set of fp operations, possibly). I don't think I have the guts to try to implement anything sensible using HW traps (which are thread-local as well, aren't they?). Does this look anything at all like what you had in mind? Secondly, for things that don't need to be brings up my point of adding methods to a built-in class. This isn't very hard, really, in fact float has class methods in 2.5... I'm interested in making Python's floating point story better, and have worked on a few things for Python 2.5 -- such as pickling/marshalling of special values -- but I'm not really a numerical programmer and don't like to guess what they need. Ah. I must get a snapshot, then. That was one of the lesser things on my list. It was fairly straightforward, and still caused portability problems... I have spent a lot of the past few decades in the numerical programming arena, from many aspects. Well, I hope I can help you bring some of that experience to Python. Cheers, mwh ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
Guido van Rossum wrote: On 6/19/06, Raymond Hettinger [EMAIL PROTECTED] wrote: I say, let someone give a complete implementation a try, and then try to modify as much standard library code as possible to use it. Then report back. That would be a very interesting experiment to do. (And thanks for the pointer to sre_compile.py as a use case!) Hmm, it could be time for the Georg bot to graduate to big game. Georg, are you up to it? I feel I am, and I'll have enough time until 2.6 anyway. However, I first want to know that the syntax and semantics have been properly discussed and fixed. One thing I like to propose which could resolve the ambiguity of case 1,2,3: is: switch x: case (1, 2, 3): # if x is the tuple (1,2,3) case in 1, 2, 3: # if x is 1, 2 or 3 Georg is a bot? :-) Yes, I was initiated in Reykjavik ;) Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Numerical robustness, IEEE etc.
Nick Maclaren wrote:
Brett Cannon's and Neal Norwitz's replies appreciated and noted, but
responses sent by mail.
Nick Coghlan [EMAIL PROTECTED] wrote:
Python 2.4's decimal module is, in essence, a floating point emulator based
on
the General Decimal Arithmetic specification.
Grrk. Format and all? Because, in software, encoding, decoding and
dealing with the special cases accounts for the vast majority of the
time. Using a format and specification designed for implementation
in software is a LOT faster (often 5-20 times).
If by format you mean storing the number as sign, coefficient, exponent, then
yes the decimal module took that part from Cowlishaw. Facundo (sensibly)
ignored some of the hardware-specific details, though. The initial Python
implementation was designed to be reasonably efficient from a speed point of
view without being too hard to follow. Memory efficiency wasn't really a
priority (the only concession to it that I can recall is the use of __slots__
on the decimal objects). So most of the time the decimal coefficients are
stored as tuples of digits, with an internal conversion to long integers in
order to do arbitrary coefficient arithmetic, but staying with the tuples of
digits for multiplication and division by powers of ten.
And yes, we ended up adding an '_is_special' flag to the decimal objects
simply because profiling showed that a whole heap of time was being spent
deciding if any of the special cases applied to an operation. Having a single
flag to check cut that time down appreciably.
The intent was always to replace the internal use of tuples and longs with a
more efficient C implementation - that particular step simply wasn't needed
for the original use case that lead Facundo to write and implement PEP 327.
If you want floating point mathematics that doesn't have insane platform
dependent behaviour, the decimal module is the recommended approach. By the
time Python 2.6 rolls around, we will hopefully have an optimized version
implemented in C (that's being worked on already).
Yes. There is no point in building a wheel if someone else is doing it.
Please pass my name on to the people doing the optimisation, as I have
a lot of experience in this area and may be able to help. But it is a
fairly straightforward (if tricky) task.
Mateusz Rucowicz has taken up the challenge for Google's Summer of Code
(mentored by Facundo Batista, the original author of PEP 327 and the decimal
module).
I've cc'ed Facundo, so hopefully he will see this thread and chime in :)
Mode A: follow IEEE 754R slavishly, if and when it ever gets into print.
There is no point in following C99, as it is too ill-defined, even if it
were felt desirable. This should not be the default, because of the
flaws I mention above (see Kahan on Java).
If the C-coded decimal module proves fast enough (for a given definition of
'fast enough'), I'll certainly be pushing for it to be made the standard float
type in Py3k. Although I'm sure Tim will miss having to explain the result of
repr(1.1) every few months ;)
That said, the fact that 754R *isn't* finished yet, is one of the big reasons
why the decimal module is based on the General Decimal Arithmetic
Specification instead.
Mode B: all numerically ambiguous or invalid operations should raise
an exception - including pow(0,0), int(NaN) etc. etc. There is a moot
point over whether overflow is such a case in an arithmetic that has
infinities, but let's skip over that one for now.
Let's not skip it, because the decimal module already seems to do pretty much
what you describe here :)
(The below example code was tested with 2.5a2, but the same code should work
in Python 2.4. Uninteresting traceback details have been omitted)
from decimal import Decimal as d
nan = d('NaN')
zero = d(0)
pow(zero, zero)
Traceback (most recent call last):
...
decimal.InvalidOperation: 0 ** 0
int(nan)
Traceback (most recent call last):
...
decimal.InvalidOperation
d('1e9') * 10
Traceback (most recent call last):
...
decimal.Overflow: above Emax
from decimal import getcontext, Overflow
ctx = getcontext()
ctx.traps[Overflow] = False
d('1e9') * 10
Decimal(Infinity)
Emax can be changed if the default limit is too low for a given application :)
Mode C: all numerically ambiguous or invalid operations should return
a NaN (or infinity, if appropriate). Anything that would lose the error
indication would raise an exception. The selection between modes B and
C could be done by a method on the class - with mode B being selected
if any argument had it set, and mode C otherwise.
from decimal import InvalidOperation
ctx.traps[InvalidOperation] = False
pow(zero, zero)
Decimal(NaN)
int(nan)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: __int__ returned non-int (type Decimal)
The selection of the current mode is on a per-thread basis.
Re: [Python-Dev] unicode imports
Martin v. Löwis schrieb: Thomas Heller wrote: It should be noted that I once started to convert the import machinery to be fully unicode aware. As far as I can tell, a *lot* has to be changed to make this work. Is that code available somewhere still? Does it still work? Available as patch 1093253, I have not tried if it stil works I started with refactoring Python/import.c, but nobody responded to the question whether such a refactoring patch would be accepted or not. I would like to see minimal changes only. I don't see why massive refactoring would be necessary: the structure of the code should persist - only the data types should change from char* to PyObject*. Calls like stat() and open() should be generalized to accept PyObject*, and otherwise keep their interface. To be really useful, wide char versions of other things must also be made available: command line arguments, environment variables (PYTHONPATH), and maybe other stuff. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping __init__.py requirement for subpackages
+1 Excellent Change +1 Minimal Backward Compatibility Difficulties I think this would also help quite a bit with newbie adoption of Python. I've had to explain this un-feature on numerous occassions and it given how smart Python is, I've wondered why it has this requirement. If you look in various open source packages, you'll find that 95% of these __init__.py files are empty. The ones at my work actually say: # stupid Python requirement, don't remove this file Why? Someone decided to remove files of length 0 in our repository without realizing the consequences. Since it had the __init__.pyc file around, it still worked... till one brought down a fresh copy of the repository and then it just stopped working. Quite a bit of hair pulling that one caused us. The only case where this might cause a problem is with resource directories that only contain .html, .jpg and other files. So, perhpas this feature would only turn a directory into a package if it didn't have any .py files. It could also trigger only when the package is explicitly imported? Good luck /w the pitch-fork wielding users and telling the old-timers where they can keep their backward compatibility. Clark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode imports
Thomas Heller wrote: Is that code available somewhere still? Does it still work? Available as patch 1093253, I have not tried if it stil works I see. It's quite a huge change, that's probably why nobody found the time to review it, yet. To be really useful, wide char versions of other things must also be made available: command line arguments, environment variables (PYTHONPATH), and maybe other stuff. While I think these things should eventually be done, I don't think they are that related to import.c. If W9x support gets dropped, we can rewrite PC/getpathp.c to use the Unicode API throughout; that would allow to put non-ANSI path names onto PYTHONPATH. Making os.environ support Unicode is entirely different isusue. I would like to see os.environ return Unicode if the key is Unicode; another option would be to introduce os.uenviron. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] test_ctypes failure on Mac OS X/PowerPC 10.3.9 (Panther)
Thomas and others, Has anyone else seen failures in test_ctypes on older Mac OS X/PowerPC? Results are below. This is running a build of the trunk from last night: ./configure make ./python.exe Lib/test/test_ctypes.py Note that the test does NOT fail on the Mac OS X/x86 10.4.6 box that I have. Trent $ ./python.exe Lib/test/test_ctypes.py /Users/trentm/src/python/Lib/ctypes/__init__.py:10: ImportWarning: Not importing directory '/Users/trentm/src/python/Modules/_ctypes': missing __init__.py from _ctypes import Union, Structure, Array test_anon (ctypes.test.test_anon.AnonTest) ... ok test_anon_nonmember (ctypes.test.test_anon.AnonTest) ... ok test_anon_nonseq (ctypes.test.test_anon.AnonTest) ... ok test_nested (ctypes.test.test_anon.AnonTest) ... ok test (ctypes.test.test_array_in_pointer.Test) ... ok test_2 (ctypes.test.test_array_in_pointer.Test) ... ok test_classcache (ctypes.test.test_arrays.ArrayTestCase) ... ok test_from_address (ctypes.test.test_arrays.ArrayTestCase) ... ok test_from_addressW (ctypes.test.test_arrays.ArrayTestCase) ... ok test_numeric_arrays (ctypes.test.test_arrays.ArrayTestCase) ... ok test_simple (ctypes.test.test_arrays.ArrayTestCase) ... ok test_longlong (ctypes.test.test_bitfields.BitFieldTest) ... ok test_mixed_1 (ctypes.test.test_bitfields.BitFieldTest) ... ok test_mixed_2 (ctypes.test.test_bitfields.BitFieldTest) ... ok test_mixed_3 (ctypes.test.test_bitfields.BitFieldTest) ... ok test_multi_bitfields_size (ctypes.test.test_bitfields.BitFieldTest) ... ok test_nonint_types (ctypes.test.test_bitfields.BitFieldTest) ... ok test_signed (ctypes.test.test_bitfields.BitFieldTest) ... ok test_single_bitfield_size (ctypes.test.test_bitfields.BitFieldTest) ... ok test_ulonglong (ctypes.test.test_bitfields.BitFieldTest) ... ok test_unsigned (ctypes.test.test_bitfields.BitFieldTest) ... ok test_ints (ctypes.test.test_bitfields.C_Test) ... ok test_shorts (ctypes.test.test_bitfields.C_Test) ... ok test_buffer (ctypes.test.test_buffers.StringBufferTestCase) ... ok test_string_conversion (ctypes.test.test_buffers.StringBufferTestCase) ... ok test_unicode_buffer (ctypes.test.test_buffers.StringBufferTestCase) ... ok test_unicode_conversion (ctypes.test.test_buffers.StringBufferTestCase) ... ok test_endian_double (ctypes.test.test_byteswap.Test) ... ok test_endian_float (ctypes.test.test_byteswap.Test) ... ok test_endian_int (ctypes.test.test_byteswap.Test) ... ok test_endian_longlong (ctypes.test.test_byteswap.Test) ... ok test_endian_other (ctypes.test.test_byteswap.Test) ... ok test_endian_short (ctypes.test.test_byteswap.Test) ... ok test_struct_fields_1 (ctypes.test.test_byteswap.Test) ... ok test_struct_fields_2 (ctypes.test.test_byteswap.Test) ... ok test_struct_struct (ctypes.test.test_byteswap.Test) ... ok test_unaligned_native_struct_fields (ctypes.test.test_byteswap.Test) ... ok test_unaligned_nonnative_struct_fields (ctypes.test.test_byteswap.Test) ... ok test_byte (ctypes.test.test_callbacks.Callbacks) ... ok test_char (ctypes.test.test_callbacks.Callbacks) ... ok test_double (ctypes.test.test_callbacks.Callbacks) ... ok test_float (ctypes.test.test_callbacks.Callbacks) ... ok test_int (ctypes.test.test_callbacks.Callbacks) ... ok test_long (ctypes.test.test_callbacks.Callbacks) ... ok test_longlong (ctypes.test.test_callbacks.Callbacks) ... ok test_pyobject (ctypes.test.test_callbacks.Callbacks) ... ok test_short (ctypes.test.test_callbacks.Callbacks) ... ok test_ubyte (ctypes.test.test_callbacks.Callbacks) ... ok test_uint (ctypes.test.test_callbacks.Callbacks) ... ok test_ulong (ctypes.test.test_callbacks.Callbacks) ... ok test_ulonglong (ctypes.test.test_callbacks.Callbacks) ... ok test_ushort (ctypes.test.test_callbacks.Callbacks) ... ok test_integrate (ctypes.test.test_callbacks.SampleCallbacksTestCase) ... ok test_address2pointer (ctypes.test.test_cast.Test) ... ok test_array2pointer (ctypes.test.test_cast.Test) ... ok test_other (ctypes.test.test_cast.Test) ... ok test_p2a_objects (ctypes.test.test_cast.Test) ... ok test_byte (ctypes.test.test_cfuncs.CFunctions) ... ok test_byte_plus (ctypes.test.test_cfuncs.CFunctions) ... ok test_callwithresult (ctypes.test.test_cfuncs.CFunctions) ... ok test_double (ctypes.test.test_cfuncs.CFunctions) ... ok test_double_plus (ctypes.test.test_cfuncs.CFunctions) ... ok test_float (ctypes.test.test_cfuncs.CFunctions) ... ok test_float_plus (ctypes.test.test_cfuncs.CFunctions) ... ok test_int (ctypes.test.test_cfuncs.CFunctions) ... ok test_int_plus (ctypes.test.test_cfuncs.CFunctions) ... ok test_long (ctypes.test.test_cfuncs.CFunctions) ... ok test_long_plus (ctypes.test.test_cfuncs.CFunctions) ... ok test_longlong (ctypes.test.test_cfuncs.CFunctions) ... ok test_longlong_plus (ctypes.test.test_cfuncs.CFunctions) ... ok test_short (ctypes.test.test_cfuncs.CFunctions) ... ok test_short_plus (ctypes.test.test_cfuncs.CFunctions) ... ok
Re: [Python-Dev] uuid backward compatibility
All your replies clarifies what your comment was intended to mean, especially this one: I'd just like people who get their hands on the module to know that they can use it with 2.3. When I first read the comment, I interpretted it too broadly and took it as a requirement for compatibility. But you didn't mean it that way at all. My apology for not asking you beforehand. uuid is now removed from the dont-break-compatibility list. -- george ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_ctypes failure on Mac OS X/PowerPC 10.3.9 (Panther)
Trent Mick schrieb: Thomas and others, Has anyone else seen failures in test_ctypes on older Mac OS X/PowerPC? Results are below. This is running a build of the trunk from last night: ./configure make ./python.exe Lib/test/test_ctypes.py Note that the test does NOT fail on the Mac OS X/x86 10.4.6 box that I have. It also works on 10.4.?? Power PC. I guess the fix has to wait until I'm able to install 10.3 on my mac, I have the DVDs already but have not yet had the time. If anyone is willing to give me ssh access to a 10.3 box I can try to fix this earlier. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Numerical robustness, IEEE etc.
2006/6/20, Nick Coghlan [EMAIL PROTECTED]: Nick Maclaren wrote: Brett Cannon's and Neal Norwitz's replies appreciated and noted, but responses sent by mail. Damn, the most difficult way to keep a thread... The intent was always to replace the internal use of tuples and longs with a more efficient C implementation - that particular step simply wasn't needed for the original use case that lead Facundo to write and implement PEP 327. Right. We never addressed speed. I mean, we made Decimal as fast as we could in the limited time we had (Raymond H. helped a lot also here), but it was NOT designed for speed. BTW, prove me Decimal is not fast enough, ;) Mateusz Rucowicz has taken up the challenge for Google's Summer of Code (mentored by Facundo Batista, the original author of PEP 327 and the decimal module). I've cc'ed Facundo, so hopefully he will see this thread and chime in :) I was reading the thread, yes, but it's so difficult to follow when half the messages are not in the list... :( Mode A: follow IEEE 754R slavishly, if and when it ever gets into print. There is no point in following C99, as it is too ill-defined, even if it were felt desirable. This should not be the default, because of the flaws I mention above (see Kahan on Java). See Cowlishaw's specification for how you can configure contexts to achieve different modes, and reasons for it and all. Easier way: Just read Decimal docs. Let's not skip it, because the decimal module already seems to do pretty much what you describe here :) Well... I think I missed it... but a very good way to resume it would be: Explain us what do you need to do that there's not achievable with Decimal... Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_ctypes failure on Mac OS X/PowerPC 10.3.9 (Panther)
On 20-jun-2006, at 20:06, Thomas Heller wrote: Trent Mick schrieb: Thomas and others, Has anyone else seen failures in test_ctypes on older Mac OS X/ PowerPC? Results are below. This is running a build of the trunk from last night: ./configure make ./python.exe Lib/test/test_ctypes.py Note that the test does NOT fail on the Mac OS X/x86 10.4.6 box that I have. It also works on 10.4.?? Power PC. I guess the fix has to wait until I'm able to install 10.3 on my mac, I have the DVDs already but have not yet had the time. If anyone is willing to give me ssh access to a 10.3 box I can try to fix this earlier. I had some problems with my 10.3-capable box, but happily enough it decided to come alive again. I'm currently booted into 10.3.9 and will have a look. Ronald ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
On 6/19/06, Josiah Carlson [EMAIL PROTECTED] wrote: Guido van Rossum [EMAIL PROTECTED] wrote: Perhaps I misunderstood Josiah's comment; I thought he was implying that a switch should be significantly *faster* than if/elif, and was arguing against features that would jeopardize that speedup. I would think that it would be fine if some switches could be compiled into some kind of lookup table while others would just be translated into a series of if/elifs. As long as the compiler can tell the difference. I personally don't find switch/case statements to be significantly (if at all) easier to read than if/elif/else chains, but that is subjective, and I note that Ka-Ping finds switch/case to be significantly easier to read. Regardless of readability (I know that readability counts), TOOWTDI. If we allow somewhat arbitrary cases, then any potential speedup may be thrown away (which would bother those of us who use dispatching), and we essentially get a different syntax for if/elif/else. I don't know about everyone else, but I'm not looking for a different syntax for if/elif/else, I'm looking for fast dispatch with some reasonable syntax. Careful though. Even the most efficient switch can't meet all your dispatch needs; a switch requires that you be able to list all the cases statically in your source code. If that works for you, great. But if you need some kind of dynamic extensibility, switch will never cut it, and you'll have to use a dict of fuctions or the standard getattr(self, '_Prefix_' + name) dynamic-dispatch-without-dict approach. In my opinion, the most reasonable syntax is a semantic change for fast dispatch inside of specifically crafted if/elif chains of the form: if/elif non_dotted_name == constant_expression: As stated various ways by various people, you can generate a hash table during function definition (or otherwise), verify that the value of non_dotted_name is hashable, and jump to particular offsets. If you are careful with your offsets, you can even have parallel if/elif/else tests that fall through in the case of a 'non-hashable'. Note that this is just Solution 1 from PEP 275. There is a drawback to the non-syntax if/elif/else optimization, specifically that someone could find that their dispatch mysteriously got slower when they went from x==1 to including some other comparison operator in the chain somewhere. Well, that and the somewhat restricted set of optimizations, but we seem to be headed into that restricted set of optimizations anyways. Remember that most things we usually *think* of as constants aren't recognized as such by the compiler. For example the constants used by sre_compile.py. One benefit to the non-syntax optimization is that it seems like it could be implemented as a bytecode hack, allowing us to punt on the entire discussion, and really decide on whether such a decorator should be in the standard library (assuming someone is willing to write the decorator). I expect the scope of the optimization to be much less than you think, and I expect that people will waste lots of time trying to figure out why the optimization doesn't happen. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.4 extensions require VC 7.1?
Actually, I was looking at the 1989 standard which is what we are supposed to be using, right? But the exact wording in 99 is: If the request can be honored, the signal function returns the value of func for the most recent successful call to signal for the specified signal sig. Otherwise, a value of SIG_ERR is returned and a positive value is stored in errno.. Sorry for meitioning EINVAL, my mistake. Continuing the hairsplitting: Note that the standard doesn´t specify the valid signals, they are implementation defined as you say. and in that sense, any old integer cannot be considered a signal sig in the above quote. So stricly speaking (in my interpretation) there is nothing wrong in aborting for an integer that isn´t defined to be a signal by the implementation. However: Let´s just agree that signal() isn´t up to spec, and leave it out of the discussion. There are provisions all over the code for particular quirks of particular platforms. Everything else appears to be up to spec. However, the usual, natural, straight-forward way of processing the mode string (in a loop with a switch statement) can't possible cause crashes. Making assumptions about how someone implements the CRT is not good practice. Relying on the implementors to go above and beyond the spec to ensure stability or some common sense behaviour is inviting trouble. We should be wary, not just on microsoft platforms, on treading onto domain that isn't defined. Anything can happen. Literally. But if you expect that, then in that sense, the VC8 implementation is probably better than most. Because they have gone out of their way to try to identify all possible ways that you can violate the domain of those functions, and do something defined if you do. So the behavior of these functions is defined for much wider range of input than for most other implementations, in other words, they have gone above and beyond the spec. So we can redirect all signals handlers to Python code if the user wishes so. I wonder. Setting process wide handlers like that seems to be odd if you are embedding python to do scripting for you. The main app is usually the one that decides on signal handling for various things. Seems like a python.exe thing to me. But never mind. At the very least one should then only set those handlers that are valid for each implementation. I'd also like to draw your attention to lines 1162 and onwards in timemodule.c, lines 410 onwards. Here is an example of us forcing values into an acceptable range, although the standard says: If any of the specified values is outside the normal range, the characters stored are unspecified.. But on some platforms it would crash, not just store unspecified values. So we are already compensating for implementations that break the standard (I think we can agree that this is breakage). So, if I agree with you that signal() is broken (by default, but mended by our fix) is there any any other technical reason why VC8 should not be taken into the fold? After all, it has already pointed out to us that we are dangerously allowing user format strings to propagate. Cheers, Kristján ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_ctypes failure on Mac OS X/PowerPC 10.3.9 (Panther)
On 20-jun-2006, at 20:50, Ronald Oussoren wrote:
On 20-jun-2006, at 20:06, Thomas Heller wrote:
Trent Mick schrieb:
Thomas and others,
Has anyone else seen failures in test_ctypes on older Mac OS X/
PowerPC?
Results are below. This is running a build of the trunk from last
night:
./configure make ./python.exe Lib/test/test_ctypes.py
Note that the test does NOT fail on the Mac OS X/x86 10.4.6 box
that I have.
It also works on 10.4.?? Power PC. I guess the fix has to wait until
I'm able to install 10.3 on my mac, I have the DVDs already but
have not
yet had the time. If anyone is willing to give me ssh access to a
10.3
box I can try to fix this earlier.
I had some problems with my 10.3-capable box, but happily enough it
decided to come alive again. I'm currently booted into 10.3.9 and
will have a look.
It is a platform bug, RTLD_LOCAL doesn't work on 10.3. The following
C snippet fails with the same error as ctypes: FAIL: dlcompat: unable
to open this file with RTLD_LOCAL. This seems to be confirmed by this
sourcet test file from darwin: http://darwinsource.opendarwin.org/
10.4.1/dyld-43/unit-tests/test-cases/dlopen-RTLD_LOCAL/main.c.
/* Begin of file */
#include dlfcn.h
#include stdio.h
int main(void)
{
void* lib;
lib = dlopen(/usr/lib/libz.dylib, RTLD_LOCAL);
if (lib == NULL) {
printf(FAIL: %s\n, dlerror());
} else {
printf(OK\n);
}
return 0;
}
/* End of file */
Ronald
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/
ronaldoussoren%40mac.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
Guido van Rossum [EMAIL PROTECTED] wrote: On 6/19/06, Josiah Carlson [EMAIL PROTECTED] wrote: Regardless of readability (I know that readability counts), TOOWTDI. If we allow somewhat arbitrary cases, then any potential speedup may be thrown away (which would bother those of us who use dispatching), and we essentially get a different syntax for if/elif/else. I don't know about everyone else, but I'm not looking for a different syntax for if/elif/else, I'm looking for fast dispatch with some reasonable syntax. Careful though. Even the most efficient switch can't meet all your dispatch needs; a switch requires that you be able to list all the cases statically in your source code. If that works for you, great. But if you need some kind of dynamic extensibility, switch will never cut it, and you'll have to use a dict of fuctions or the standard getattr(self, '_Prefix_' + name) dynamic-dispatch-without-dict approach. Indeed. Not all dispatch methods are solved by if/elif/else blocks, nor would be solved by switch/case statements, especially not in the case of subclassing. Though the subclassing case can be fixed with the use of things like if cur_case not in self.handles: ... . Note that this is just Solution 1 from PEP 275. Yes it is. I was describing it for those who hadn't read the PEP (there were a few earlier in this thread). Remember that most things we usually *think* of as constants aren't recognized as such by the compiler. For example the constants used by sre_compile.py. Right, which is one of two reasons why I'm not writing the bytecode hack or even an AST transformation (the other being time). With the 'names in case matches are bound at time X' semantic inside switch/case statements, we gain more than could be offered with if/elif/else optimization. One benefit to the non-syntax optimization is that it seems like it could be implemented as a bytecode hack, allowing us to punt on the entire discussion, and really decide on whether such a decorator should be in the standard library (assuming someone is willing to write the decorator). I expect the scope of the optimization to be much less than you think, and I expect that people will waste lots of time trying to figure out why the optimization doesn't happen. It depends. The simple case would offer very limited optimization, but with a bit of help from Raymond's global binding decorator, it suddenly becomes almost as useful as the currently being discussed switch/case statement, offering one of the two options previously discussed for name binding. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Small sqlite3 test suite fix (Python 2.5b1 candidate)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://www.python.org/sf/1509584 Please apply if you think it should go in Python 2.5b1, otherwise I'll commit it after the freeze. I'd personally postpone it, because it's only cosmetic (but maybe it's related to the strange sqlite3 regression test failure Neil reported). Also, somebody please add me as Python developer on Sourceforge (I cannot assign items to myself there). - -- Gerhard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEmGcjdIO4ozGCH14RAjfuAJ451ElbxqDqi6O+cGV3nVXgp0qLNwCgp6pI usZh93QtNgRz5Es3WmaX2W8= =5owZ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Small sqlite3 test suite fix (Python 2.5b1 candidate)
[Gerhard Häring] ... Also, somebody please add me as Python developer on Sourceforge (I cannot assign items to myself there). If you still can't, scream at me ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.4 extensions require VC 7.1?
Kristján V. Jónsson wrote: However, the usual, natural, straight-forward way of processing the mode string (in a loop with a switch statement) can't possible cause crashes. Making assumptions about how someone implements the CRT is not good practice. I'm not arguing about that, and I think Python should be changed. Notice, however, that this would be a behavioural change: currently, Python passes through the mode argument for open(), exposing the platform-specific behaviour. If Python would reject mode arguments that are not supported in standard C, programs that currently work may break. I wonder. Setting process wide handlers like that seems to be odd if you are embedding python to do scripting for you. The main app is usually the one that decides on signal handling for various things. Seems like a python.exe thing to me. But never mind. At the very least one should then only set those handlers that are valid for each implementation. There is no portable way to find out what those are. So, if I agree with you that signal() is broken (by default, but mended by our fix) is there any any other technical reason why VC8 should not be taken into the fold? After all, it has already pointed out to us that we are dangerously allowing user format strings to propagate. I can't say for sure - there should be some testing first. One issue I can think of is the packaging: Microsoft wants us to install msvcr80.dll using their SxS technology, with manifests and everything. That needs to be considered in the build process, and dealt with in the MSI production. I have no experience with side-by-side installation of native assemblies yet, so I would have to learn this first, or wait for somebody to provide patches. This probably also impacts exe builders, which have to pick up the DLL from SxS. Another technical issue is the absence of support for msvcr80.dll in MinGW - one currently couldn't build Python extensions that link with the right CRT. Not purely technical, but somebody would also need to find out what the licensing conditions on msvcr80.dll are: what are the conditions for redistribution if I have a licensed copy of VS 2005? What if I have VS Express? What if I have neither, and just want to package it as a side effect of using, say, py2exe? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Small sqlite3 test suite fix (Python 2.5b1 candidate)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim Peters wrote: [Gerhard Häring] ... Also, somebody please add me as Python developer on Sourceforge (I cannot assign items to myself there). If you still can't, scream at me ;-) Bwah!!! :-P I still cannot see myself in the Assigned to dropdown ... - -- Gerhard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEmHFZdIO4ozGCH14RArtWAJwPpJ/BmnCR34UgnsJxbEieU/MdeQCdFTu2 nht30gADuguOlWvhnn5Tj7E= =QZlI -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Small sqlite3 test suite fix (Python 2.5b1 candidate)
[Gerhard] ... Also, somebody please add me as Python developer on Sourceforge (I cannot assign items to myself there). [Tim] If you still can't, scream at me ;-) [Gerhard] Bwah!!! :-P I still cannot see myself in the Assigned to dropdown ... Screaming apparently helped! I can see you now ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
Josiah Carlson wrote: Offering arbitrary expressions whose meaning can vary at runtime would kill any potential speedup (the ultimate purpose for having a switch statement) I don't agree that speedup is *the* ultimate purpose of a switch statement. There's also the matter of providing a construct that expresses the high-level intent of the code more clearly than an if-else chain. I think both of these are equally important. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
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 a question of which one is easier to explain. I think the function-definition-time one is easiest to both explain and also to reason about when writing code, since definition time is well-defined, whereas the first time it's executed is somewhat fuzzy. It's also a lot clearer how it interacts with closures, which is another good point. I recommend adding this option to the relevant PEP (whichever it is). -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
Phillip J. Eby wrote: Sadly, it's not *quite* that simple, due to the fact that co_lnotab must be increase in line numbers as bytecode offsets increase. I think it's high time all the cleverness was ripped out of the lnotab and it just became a plain array of independent entries. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
Raymond Hettinger wrote: switch x: case 1: one() case 2: two() case 3: three() default: too_many() Do we require that x be hashable so that the compiler can use a lookup table? That sounds reasonable. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
On 6/20/06, Greg Ewing [EMAIL PROTECTED] 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! Seconded. (I somehow missed Phillip's post the first time around -- apologies.) It's just a question of which one is easier to explain. I think the function-definition-time one is easiest to both explain and also to reason about when writing code, since definition time is well-defined, whereas the first time it's executed is somewhat fuzzy. It's also a lot clearer how it interacts with closures, which is another good point. I recommend adding this option to the relevant PEP (whichever it is). I think we should consider adding to PEP 275 rather than starting over; it's still mostly relevant. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
Guido van Rossum wrote: Well, the hypothetical use case is one where we have an arbitrary object of unknown origin or type, and we want to special-case treatment for a few known values. I'd need convincing that this use case is anything more than hypothetical. Also, you can always put your own test for hashability around it if you want. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
Guido van Rossum wrote: But it would be easy enough to define a dict-filling function that updates only new values. Or evaluate the case expressions in reverse order. Was it decided yet how to write the cases for a switch that tests for tuples of values? Requiring parentheses might be sufficient, essentially making what follows a case *always* take on sequence syntax. Sounds good to me. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
At 12:26 PM 6/21/2006 +1200, Greg Ewing wrote: Guido van Rossum wrote: But it would be easy enough to define a dict-filling function that updates only new values. Or evaluate the case expressions in reverse order. -1; stepping through the code in a debugger is going to be weird enough, what with the case statements being executed at function definition time, without the reverse order stuff. I'd rather make it an error to list the same value more than once; we can just check if the key is present before defining that value. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
On 6/20/06, Greg Ewing [EMAIL PROTECTED] wrote: Guido van Rossum wrote: Well, the hypothetical use case is one where we have an arbitrary object of unknown origin or type, and we want to special-case treatment for a few known values. I'd need convincing that this use case is anything more than hypothetical. Also, you can always put your own test for hashability around it if you want. Right. I wasn't defending the use case. That's why I called it hypothetical. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
On 6/20/06, Phillip J. Eby [EMAIL PROTECTED] wrote: At 12:26 PM 6/21/2006 +1200, Greg Ewing wrote: Guido van Rossum wrote: But it would be easy enough to define a dict-filling function that updates only new values. Or evaluate the case expressions in reverse order. -1; stepping through the code in a debugger is going to be weird enough, what with the case statements being executed at function definition time, without the reverse order stuff. Agreed. I'd rather make it an error to list the same value more than once; we can just check if the key is present before defining that value. That makes sense too. I was thinking of a use case where you'd have a couple of sets of cases that need the same treatment per set (sre_compile.py has a few of these) but one of the sets has an exception. With the if/elif style you could write this as if x is exception: ...exceptional case... elif x in set1: ...case for set1... elif x in set2: ..case for set2... etc. But the prospect of something like this passing without error: switch x: case 1: ...case 1... case 1: ...another case 1?!?!... makes me think that it's better to simply reject overlapping cases. BTW I think the several-sets use case above is important and would like to have syntax for it. Earlier it was proposed to allow saying case 1, 2, 3: ...executed if x==1 or x==2 or x==3... but now that we're agreed to evaluate the expression at function definition time, I want to support case S: ...executed if x in S... but that would be ambiguous. So, thinking aloud, here are a few possibilities: case A: ... if x == A... cases S: ...if x in A... or perhaps (saving a keyword): case A: ... if x == A... case in S: ...if x in A... This would also let us write cases for ranges: case in range(10): ...if x in range(10)... I propose that the expression used for a single-value should not allow commas, so that one is forced to write case (1, 2): ...if x == (1, 2)... if you really want a case to be a tuple value, but you should be able to write case in 1, 2: ...if x in (1, 2)... since this really doesn't pose the same kind of ambiguity. If you forget the 'in' it's a syntax error. Hm, so this still doesn't help if you write case S: ... (where S is an immutable set or sequence) when you meant case in S: ... so I'm not sure if it's worth the subtleties. Time for bed here, -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
On 6/20/06, Guido van Rossum [EMAIL PROTECTED] wrote: case A: ... if x == A... cases S: ...if x in A... or perhaps (saving a keyword): case A: ... if x == A... case in S: ...if x in A... I was too quick with cut/paste here; I meant case S: ...if x in S... or case in S: ...if x in S... -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
At 10:14 PM 6/20/2006 -0700, Guido van Rossum wrote: Hm, so this still doesn't help if you write case S: ... (where S is an immutable set or sequence) when you meant case in S: ... so I'm not sure if it's worth the subtleties. Well, EIBTI and all that: switch x: case == 1: foo(x) case in S: bar(x) It even lines up nicely. :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
