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:
c
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
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.
>
>
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 a
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 enoug
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 su
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
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.
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
___
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
__
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 whi
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 cons
[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 apparentl
-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
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
[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/list
-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
"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
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
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 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
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
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
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 fa
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. Bu
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
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 t
+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 vario
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
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 specificatio
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.
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 b
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 l
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
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
35 matches
Mail list logo
