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
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
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
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
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
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.
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
+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
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
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
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
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
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
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
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
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
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:
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
-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
[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
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
-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
[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
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
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
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
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
___
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
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
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
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,
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
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
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
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 ==
35 matches
Mail list logo
