Re: [Python-Dev] Switch statement

[Nick Coghlan]

M.-A. Lemburg wrote:
> The standard
> 
> if ...
> elif ...
> efif ...
> else:
> ...
> 
> scheme already provides the above logic. There's really
> no need to invent yet another syntax to write such
> constructs, IMHO.

It's a DRY thing. The construct that a switch statement can replace actually 
needs to be written:

v = ...
if v == ...:
...
elif v == ...:
...
elif v == ...:
...
else:
...

The 'v =' part is replaced by 'switch' and the 'if v ==' and 'elif v ==' are 
all replaced by 'case'.

A separate statement is also easier to document to say that order of 
evaluation of the cases is not guaranteed, and that the cases may only be 
evaluated once and cached thereafter, allowing us free rein for optimisations 
that aren't possible with a normal if statement. The optimisation of the 
if-elif case would then simply be to say that the compiler can recognise 
if-elif chains like the one above where the RHS of the comparisons are all 
hashable literals and collapse them to switch statements.

It's also worth thinking about what a 'missing else' might mean for a switch 
statement. Should it default to "else: pass" like other else clauses, or does 
it make more sense for the default behaviour to be "else: raise 
ValueError('Unexpected input to switch statement')", with an explicit "else: 
pass" required to suppress the exception?

The lack of a switch statement doesn't really bother me personally, since I 
tend to just write my state machine type code so that it works off a 
dictionary that I define elsewhere, but I can see the appeal of having one, 
*if* there are things that we can do with a separate statement to make it 
*better* for the purpose than a simple if-elif chain or a predefined function 
lookup dictionary.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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] Last-minute curses patch

[Walter Dörwald]

I have a small patch http://bugs.python.org/1506645 that adds
resizeterm() and resize_term() to the curses module. Can this still go
in for beta1? I'm not sure, if it needs some additional configure magic.

Servus,
   Walter

___
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

[M.-A. Lemburg]

Nick Coghlan wrote:
> M.-A. Lemburg wrote:
>> The standard
>>
>> if ...
>> elif ...
>> efif ...
>> else:
>> ...
>>
>> scheme already provides the above logic. There's really
>> no need to invent yet another syntax to write such
>> constructs, IMHO.
> 
> It's a DRY thing.

Exactly, though not in the sense you are suggesting :-)

The motivation for the PEP 275 is to enhance performance when
switching on multiple values with these values being
constants.

I don't want to repeat the discussion here. Please see
the PEP for details:

http://www.python.org/dev/peps/pep-0275/

Note that the PEP is entitled "Switching on Multiple Values".
Adding a switch statement is only one of the two proposed
solutions.

My personal favorite is making the compiler
smarter to detect the mentioned if-elif-else scheme
and generate code which uses a lookup table for
implementing fast branching. The main arguments
for this solution are:

* existing code can benefit from the optimization
* no need for new keywords
* code written for Python 2.6 will be executable
  by earlier Python versions as well

> The construct that a switch statement can replace
> actually needs to be written:
> 
> v = ...
> if v == ...:
>...
> elif v == ...:
>...
> elif v == ...:
>...
> else:
>...
> 
> The 'v =' part is replaced by 'switch' and the 'if v ==' and 'elif v =='
> are all replaced by 'case'.

Actually, there's one more contraint: the ... part on the right
needs to be constant - at least if you use the same motiviation
as in the PEP 275.

> A separate statement is also easier to document to say that order of
> evaluation of the cases is not guaranteed, and that the cases may only
> be evaluated once and cached thereafter, allowing us free rein for
> optimisations that aren't possible with a normal if statement.

No need for any caching magic: the values on which you
switch will have to be constants anyway.

> The optimisation of the if-elif case would then simply be to say that the
> compiler can recognise if-elif chains like the one above where the RHS
> of the comparisons are all hashable literals and collapse them to switch
> statements.

Right (constants are usually hashable :-).

> It's also worth thinking about what a 'missing else' might mean for a
> switch statement. Should it default to "else: pass" like other else
> clauses, or does it make more sense for the default behaviour to be
> "else: raise ValueError('Unexpected input to switch statement')", with
> an explicit "else: pass" required to suppress the exception?

Good point.

I'd say it's a SyntaxError not to provide an else part.
That way you leave the decision to raise an exception
or not to the programmer.

> The lack of a switch statement doesn't really bother me personally,
> since I tend to just write my state machine type code so that it works
> off a dictionary that I define elsewhere, but I can see the appeal of
> having one, *if* there are things that we can do with a separate
> statement to make it *better* for the purpose than a simple if-elif
> chain or a predefined function lookup dictionary.

The problem with a dispatch approach is that Python function
or method calls take rather long to setup and execute.

If you write things like parsers, you typically have
code that only does very few things per switch case,
e.g. add the data to some list - the function call
overhead pretty much kills the dispatch approach
compared to the O(n) approach using if-elif-chains.

Dispatching is useful in situations where you do lots
of complicated things for each case. The function
call overhead then becomes negligible.

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 15 2006)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

2006-07-03: EuroPython 2006, CERN, Switzerland  17 days left

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
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] DRAFT: python-dev summary for 2006-05-16 to 2006-05-31

[Steven Bethard]

Ok, for the first time in a few months, you're getting this summary
before the next one is due.  Woo-hoo!  (Yes, I know I'm not even a day
ahead.  Let me enjoy my temporary victory.) =)

Here's the draft summary for the second half of May.  Let me know what
comments/corrections you have.  Thanks!


=
Announcements
=


QOTF: Quote of the Fortnight


Martin v. Löwis on what kind of questions are appropriate for python-dev:

... [python-dev] is the list where you say "I want to help", not
so much "I need your help".

Contributing thread:

- `Segmentation fault of Python if build on Solaris 9 or 10 with Sun
Studio 11 `__

---
Python 2.5 schedule
---

Python 2.5 is moving steadily towards its next release.  See `PEP
356`_ for more details and the full schedule.  You may start to see a
few warnings at import time if you've named non-package directories
with the same names as your modules/packages.  Python-dev suggests
renaming these directories -- though the warnings won't give you any
real trouble in Python 2.5, there's a chance that a future version of
Python will drop the need for __init__.py.

.. _PEP 356: http://www.python.org/dev/peps/pep-0356/

Contributing thread:

- `2.5 schedule
`__
- `warnings about missing __init__.py in toplevel directories
`__

--
Restructured library reference
--

Thanks to work by A.M. Kuchling and Michael Spencer, the organization
of the `development Library Reference documentation`_ structure is
much improved over the `old one`_.  Thanks for your hard work guys!

.. _development Library Reference documentation:
http://docs.python.org/dev/lib/lib.html
.. _old one: http://docs.python.org/lib/lib.html

Contributing thread:

- `[Python-3000] stdlib reorganization
`__

-
Need for Speed Sprint results
-

The results of the `Need for Speed Sprint`_ are all posted on the
wiki.  In particular, you should check a number of `successes`_ they
had in speeding up various parts of Python including function calls,
string and Unicode operations, and string<->integer conversions.

.. _Need for Speed Sprint: http://wiki.python.org/moin/NeedForSpeed/
.. _successes: http://wiki.python.org/moin/NeedForSpeed/Successes

Contributing threads:

- `[Python-checkins] r46043 - peps/trunk/pep-0356.txt
`__
- `Need for Speed Sprint status
`__

-
Python old-timer memories
-

Guido's been collecting `memories of old-timers`_ who have been using
Python for 10 years or more.  Be sure to check 'em out and add your
own!

.. _memories of old-timers:
http://www.artima.com/weblogs/viewpost.jsp?thread=161207

Contributing thread:

- `Looking for Memories of Python Old-Timers
`__


=
Summaries
=

-
Struct module inconsistencies
-

Changes to the struct module to do proper range checking resulted in a
few bugs showing up where the stdlib depended on the old, undocumented
behavior.  As a compromise, Bob Ippolito added code to do the proper
range checking and issue DeprecationWarnings, and then made sure that
the all struct results were calculated with appropriate bit masking.
The warnings are expected to become errors in Python 2.6 or 2.7.

Bob also updated the struct module to return ints instead of longs
whenever possible, even for the format codes that had previously
guaranteed longs (I, L, q and Q).

Contributing threads:

- `Returning int instead of long from struct when possible for
performance 
`__
- `test_gzip/test_tarfile failure om AMD64
`__
- `Converting crc32 functions to use unsigned
`__
- `test_struct failure on 64 bit platforms
`__

-
Using epoll for the select module
-

Ross Cohen implemented a `drop-in replacement for select.poll`_ using
Linux's epoll (a more efficient io notifcation system than poll).  The
select interface is already much closer to the the epoll API than the
poll API, and people liked the idea of using epoll silently when
available. Ross promised to look into merging his 

Re: [Python-Dev] Source control tools

[Jan Claeys]

Op di, 13-06-2006 te 10:27 +0200, schreef Alexander Schremmer:
> Bazaar-NG seems to reach limits already when working on
> it's own code/repository. 

Canonical uses bzr to develop launchpad.net, which is a "little bit"
larger dan bzr itself, I suspect...?


-- 
Jan Claeys

___
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] The baby and the bathwater (Re: Scoping, augmented assignment, 'fast locals' - conclusion)

[Boris Borcic]

[this is bytes of an oversized put-all-into-it intervention. A possibly 
expanded 
version will be submitted on clp with local followup before a couple days]

Josiah Carlson wrote:

[BB]
 >> I'd say a first step in convincing me I am wrong would be to show me 
examples of
 >> object methods of the standard library that are recursive, and cut out for
 >> recursion.

[JC]
 > Actually, I don't believe that is necessary. I've shown that you would
 > get better performance with a non-recursive function and passing two
 > arguments, than you would passing one argument with scoping tricks to
 > get the second.

Assuming my aim was purely performance clearly stretches the hints I gave that 
I 
wasn't unconcerned by it. Taking ground on this to unwarrantedly suppose that 
my 
methodology was deficient, rectify it, and then dictate the "necessary" 
conclusions I find... er, preposterous seems balanced, "thought police" not 
totally unwarranted.

What I am doing. After a long while of relaxed ties with the latest Python, and 
upon observing at http://pythonsudoku.sourceforge.net/, an imo hugely bloated 
code-base concerned with sudoku, I found it a convenient means to refamiliarize 
myself with some leading edge Python, to explore the manifold of equivalent 
programs defined a priori by the invariant constraint :

"universal sudoku solver in +-pure python, ~10ms/problem, and ~60 LOCS total".

At present I must have examined about 50 versions, some unfinished, some 
differing only by details you would call "trivial", others massively differing 
by choice of key data types and modules. And algorithmic details, readability, 
ease of debugging, obviousness, speed, concision... in brief, differing in 
beauty as I see it.

A minute example that this approach works (given my aims) is that has 
signification to me, such a leading edge detail as the news that 
unicode.translate() had been accelerated during the latest 2.5 sprint.

While I've not excluded code profiling as a tool to use at some point, I don't 
think it is adapted at this stage; timeit does what I need, whenever I want to 
compare speed of versions differing by one factor that usually implies many 
local changes. As made clear (I hope) speed isn't the primary or unique concern 
anyway.

[...]

This said...

This said, first : I deny you have or ever had real ground to refuse 
legitimacy, 
motivation, efficiency or methodological soundness to my approach.

Second : I tell you with good ground that under these (admittedly peculiar, but 
quite intense) "lighting conditions" the compiler "feature" that's the cause of 
the present debate stands out like a sore thumb.

[JC]
 >>> Given [...]
 >>> you are not likely to find me agreeing with you about
 >>> augmented assignment and/or lexically nested scopes.

[BB]
 >> I see. Thanks for the background. Background for backround, let me just say 
that
 >> python hadn't yet grown a lambda when I first played with it. May I read 
 >> your
 >> last statement as acknowledging that I am not so much asking for a door to 
 >> be
 >> created, than asking for a naturally builtin door, not to be locked by 
 >> special
 >> efforts ?

[JC]
 > No, you may not.  There are two options for the Python compiler/runtime
 > behavior when faced with an augmented assignment for a name not yet
 > known in this particular lexical scope but known in a parent scope:

"Special efforts" I maintain. Here they hide in the choice of hypothesis and 
tensing to artificially exclude from the "use case", what is in fact the most 
likely situation whenever the compiler/runtime follows to its end the codepath 
you advocate.

Indeed, that situation is almost bound to be the case *if* the resulting error 
message acurately describes the user's real error *and* the latter is not prey 
to foolish coding habits (further than the in-your-opinion fatally foolish 
habit 
that's assumed by hypothesis : and I guess this explains your bias here, 
crediting *presumed* fools with more than their share of foolishness - circular 
thinking).

As relates to this "background use case", what I advocate amounts to 
substituting "reference to unknown global variable" for "local variable 
referenced before initialization". An error message for another, both bringing 
attention to the right problem.

[JC]
 > to expect whenever the "compiler/runtime" system
 > assume you meant the name in the parent scope, or assume you made a
 > mistake. The current state of affairs (for all released Pythons with
 > augmented assignment) is to assume that you meant the local scope. Why?
 > Because while allowing the augmented assignment would make your life
 > easier in this case, the error would "pass silently"

Yeah, this all quite fits what I had anticipated when I spoke of my "deeply 
felt 
aversion for whatever resembles a constraining curriculum of errors to make (or 
else I would program in Java)". But its true I hadn't anticipated the 
concurrent 
case of errors one is required to make simu

Re: [Python-Dev] Switch statement

[Raymond Hettinger]

  
The optimisation of the if-elif case would then simply be to say that the
compiler can recognise if-elif chains like the one above where the RHS
of the comparisons are all hashable literals and collapse them to switch
statements.

  
  
Right (constants are usually hashable :-).
  


The LHS is more challenging.  Given:

    if x == 1: p_one()
    elif x == 2: p_two()
    elif x == 3: p_three()
    else: p_catchall()

There is no guarantee that x is hashable.  For example:

    class X:
    def __init__(self, value):
 self.value = value
    def __cmp__(self, y):
 return self.value == y
    x = X(2)


Raymond





___
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] The baby and the bathwater (Re: Scoping, augmented assignment, 'fast locals' - conclusion)

[Josiah Carlson]

As Guido has already asked for this thread to be moved to c.l.py, I'm
going to do so.

 - 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

Re: [Python-Dev] Source control tools

[Alexander Schremmer]

On Thu, 15 Jun 2006 19:00:09 +0200, Jan Claeys wrote:

> Op di, 13-06-2006 te 10:27 +0200, schreef Alexander Schremmer:
>> Bazaar-NG seems to reach limits already when working on
>> it's own code/repository. 
> 
> Canonical uses bzr to develop launchpad.net, which is a "little bit"
> larger dan bzr itself, I suspect...?

I don't think so, without having seen the Launchpad code. I assume that
Launchpad has less comitters (closed source!) and therefore less change
sets and less parallel branches.

Once I pulled the bzr changesets (1-3 months ago) and it needed 3 hours on
a 900 MHz machine with a high-speed (> 50 MBit) internet connection (and it
was CPU bound). Note that bzr has gained a lot of speed since then, though.

Kind regards,
Alexander

___
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] Keeping interned strings in a set

[Alexander Belopolsky]

As an exercise in using the new set C API, I've replaced the
"interned" dictionary in stringobject.c with a set.  Surprisingly,
what I thought would be a simple exercise, took several hours to
implement and debug.  Two problems are worth mentioning:

1. I had to add a function to setobject.h to retrieve a pointer to an
object stored in a set. I could not find a way to do it using current
API (short of iterating through the set of course).

2. I had to change the  PyString_Fini() and PySet_Fini() in
Py_Finalize() because cleaning "interned" set cannot be done after the
set module is finalized.

If there is any interest, I will submit a patch, but it does not seem
to affect performance in any meaningful way.
___
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] Keeping interned strings in a set

[Neal Norwitz]

On 6/15/06, Alexander Belopolsky <[EMAIL PROTECTED]> wrote:
> As an exercise in using the new set C API, I've replaced the
> "interned" dictionary in stringobject.c with a set.
>
> If there is any interest, I will submit a patch, but it does not seem
> to affect performance in any meaningful way.

Can you measure memory usage difference in a large app?  How many
strings are interned?
(I think sets use less memory, it seems like they could, but I don't
really remember.)

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] Switch statement

[Nicko van Someren]

On 15 Jun 2006, at 11:37, Nick Coghlan wrote:
> ...
> The lack of a switch statement doesn't really bother me personally,  
> since I
> tend to just write my state machine type code so that it works off a
> dictionary that I define elsewhere,

Not trying to push more LISP into python or anything, but of course  
we could converge your method and the switch statement elegantly if  
only we could put whole suites into lamdbas rather than just single  
expressions :-)

{"case1": lamdba : some-suite-lambda... ,
  "case2": lambda : some-other-suite...
}[switch-condition-expression]()

Nicko

___
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]

At 11:45 PM 6/15/2006 +0100, Nicko van Someren wrote:
>On 15 Jun 2006, at 11:37, Nick Coghlan wrote:
> > ...
> > The lack of a switch statement doesn't really bother me personally,
> > since I
> > tend to just write my state machine type code so that it works off a
> > dictionary that I define elsewhere,
>
>Not trying to push more LISP into python or anything, but of course
>we could converge your method and the switch statement elegantly if
>only we could put whole suites into lamdbas rather than just single
>expressions :-)

As has already been pointed out, this

1) adds function call overhead,
2) doesn't allow changes to variables in the containing function, and
3) even if we had a rebinding operator for free variables, we would have 
the overhead of creating closures.

The lambda syntax does nothing to fix any of these problems, and you can 
already use a mapping of closures if you are so inclined.  However, you'll 
probably find that the cost of creating the dictionary of closures exceeds 
the cost of a naive sequential search using if/elif.

___
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] Keeping interned strings in a set

[Raymond Hettinger]

Alexander Belopolsky wrote:

>As an exercise in using the new set C API, I've replaced the
>"interned" dictionary in stringobject.c with a set.  Surprisingly,
>what I thought would be a simple exercise, took several hours to
>implement and debug.  Two problems are worth mentioning:
>
>1. I had to add a function to setobject.h to retrieve a pointer to an
>object stored in a set. I could not find a way to do it using current
>API (short of iterating through the set of course).
>
>2. I had to change the  PyString_Fini() and PySet_Fini() in
>Py_Finalize() because cleaning "interned" set cannot be done after the
>set module is finalized.
>
>If there is any interest, I will submit a patch, but it does not seem
>to affect performance in any meaningful way.
>  
>

I would be curious to see your patch.


Raymond
___
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] Keeping interned strings in a set

[Alexander Belopolsky]

This is very raw, but in the spirit of "release early and often",  
here it is:

http://sourceforge.net/tracker/download.php? 
group_id=5470&atid=305470&file_id=181807&aid=1507011

On Jun 15, 2006, at 8:47 PM, Raymond Hettinger wrote:
>
> I would be curious to see your patch.
>
>
> Raymond

___
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] Keeping interned strings in a set

[Raymond Hettinger]

Alexander Belopolsky wrote:

> This is very raw, but in the spirit of "release early and often",  
> here it is:
>
> http://sourceforge.net/tracker/download.php? 
> group_id=5470&atid=305470&file_id=181807&aid=1507011
>
> On Jun 15, 2006, at 8:47 PM, Raymond Hettinger wrote:
>
>>
>> I would be curious to see your patch.
>

Nicely done.  It is fine by me if this goes in so we save a little space 
in the intern table.

One nit, in _Py_ReleaseInternedStrings() you can use 
PySet_CheckExact(interned) instead of the ob_type.


Raymond
___
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] Keeping interned strings in a set

[Alexander Belopolsky]

On Jun 15, 2006, at 10:29 PM, Raymond Hettinger wrote:
>
> Nicely done.  It is fine by me if this goes in so we save a little  
> space in the intern table.

Thanks for the good word.   I've reworked the code a little bit and  
fixed the comments.  I don't have svn write access, so someone else  
will have to take over from here.

http://sourceforge.net/tracker/download.php? 
group_id=5470&atid=305470&file_id=181816&aid=1507011

>
> One nit, in _Py_ReleaseInternedStrings() you can use  
> PySet_CheckExact(interned) instead of the ob_type.

That's what I wanted to use myself, but  PySet_CheckExact does not  
exist.  This looks like an oversight, but fixing that should probably  
come as a separate patch.
___
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

[Greg Ewing]

M.-A. Lemburg wrote:

> My personal favorite is making the compiler
> smarter to detect the mentioned if-elif-else scheme
> and generate code which uses a lookup table for
> implementing fast branching.

But then the values need to be actual compile-time
constants, precluding the use of symbolic names,
values precomputed a run time, etc.

A new statement would allow us to simply document
that the case values are *assumed* constant, and
then the implementation could cache them in a dict
or whatever.

--
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

[Nicko van Someren]

On 16 Jun 2006, at 00:49, Phillip J. Eby wrote:

> At 11:45 PM 6/15/2006 +0100, Nicko van Someren wrote:
>> On 15 Jun 2006, at 11:37, Nick Coghlan wrote:
>> > ...
>> > The lack of a switch statement doesn't really bother me personally,
>> > since I
>> > tend to just write my state machine type code so that it works  
>> off a
>> > dictionary that I define elsewhere,
>>
>> Not trying to push more LISP into python or anything, but of course
>> we could converge your method and the switch statement elegantly if
>> only we could put whole suites into lamdbas rather than just single
>> expressions :-)
>
> As has already been pointed out, this
>
> 1) adds function call overhead,
> 2) doesn't allow changes to variables in the containing function, and
> 3) even if we had a rebinding operator for free variables, we would  
> have the overhead of creating closures.

Noted.  I find (2) the most compelling issue.  I was merely  
suggesting a succinct way to express the model that Nick Cohglan was  
espousing.

> The lambda syntax does nothing to fix any of these problems, and  
> you can already use a mapping of closures if you are so inclined.   
> However, you'll probably find that the cost of creating the  
> dictionary of closures exceeds the cost of a naive sequential  
> search using if/elif.

The smiley was supposed to indicate that this was not an entirely  
serious suggestion; my apologies if the signal was lost in  
transmission.  In the equivalent if/elif to a switch you're only  
comparing a single value against a set of pre-computed values, and  
expecting to only do half the tests, so it's almost certainly going  
to be quicker than sorting out the whole set of closures.  I do  
however have a bug-bear about lambdas being restricted to single  
expressions, but maybe that's just me.

Nicko

___
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

[Talin]

Phillip J. Eby wrote:
> As has already been pointed out, this
> 
> 1) adds function call overhead,
> 2) doesn't allow changes to variables in the containing function, and
> 3) even if we had a rebinding operator for free variables, we would have 
> the overhead of creating closures.
> 
> The lambda syntax does nothing to fix any of these problems, and you can 
> already use a mapping of closures if you are so inclined.  However, you'll 
> probably find that the cost of creating the dictionary of closures exceeds 
> the cost of a naive sequential search using if/elif.

This brings me back to my earlier point - I wonder if it would make 
sense for Python to have a non-closure form of lambda - essentially an 
old-fashioned subroutine:

def foo( x ):
   x = 0
   sub bar: # Arguments are not allowed, since they create a scope
  x = y # Writes over the x defined in 'foo'

   bar()

The idea is that 'bar' would share the same scope as 'foo'. To keep the 
subroutine lightweight (i.e. just a single jump and return instruction 
in the virtual machine) arguments would not be allowed.

-- Talin
___
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] Last-minute curses patch

[Martin v. Löwis]

Walter Dörwald wrote:
> I have a small patch http://bugs.python.org/1506645 that adds
> resizeterm() and resize_term() to the curses module. Can this still go
> in for beta1? I'm not sure, if it needs some additional configure magic.

It can go into beta1 until the beta1 code freeze is announced.
It does need a configure test, though.

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