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.
I
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
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
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 na
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
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 curi
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
___
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 a
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 else
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, b
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.
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 ret
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
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/py
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 :-).
[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
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
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!
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
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
P
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
21 matches
Mail list logo
