"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Marcin Qrczak Kowalczyk wrote:
> What about lists? I guess (haven't checked) that they are made like
> tuples.
I always thought they were built one item at a time,
but I was wrong (see below). So there doesn't seem to
be
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Marcin Qrczak Kowalczyk wrote:
> What about lists? I guess (haven't checked) that they are made like
> tuples.
I always thought they were built one item at a time,
but I was wrong (see below). So there doesn't seem to
be
Marcin ‘Qrczak’ Kowalczyk wrote:
> What about lists? I guess (haven't checked) that they are made like
> tuples.
I always thought they were built one item at a time,
but I was wrong (see below). So there doesn't seem to
be much logic or consistency here at all.
>>> def f():
... x = [1,2,3]
...
On Fri, Mar 28, 2008 at 9:46 AM, Marcin 'Qrczak' Kowalczyk
<[EMAIL PROTECTED]> wrote:
> Dnia 27-03-2008, Cz o godzinie 11:48 +1200, Greg Ewing pisze:
>
>
> > Tuples are created batchwise because, being immutable,
> > that's the only way to do it. But if set literals are
> > to produce mutable ob
Dnia 27-03-2008, Cz o godzinie 11:48 +1200, Greg Ewing pisze:
> Tuples are created batchwise because, being immutable,
> that's the only way to do it. But if set literals are
> to produce mutable objects, there's no need for them
> to be created batchwise, and doing so has unfortunate
> stack size
Alexander Belopolsky wrote:
> 1. Do nothing: dicts are built incrementally, and sets in batch.
> 2. Implement batch processing for dict literals.
> 3. Implement incremental processing for sets.
My thought is that sets are the odd one out here.
Tuples are created batchwise because, being immutabl
On Wed, Mar 26, 2008 at 9:18 AM, Alexander Belopolsky
<[EMAIL PROTECTED]> wrote:
>
> On Tue, Mar 25, 2008 at 5:06 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > On Tue, Mar 25, 2008 at 2:43 PM, Alexander Belopolsky
> >
> > <[EMAIL PROTECTED]> wrote:
> >
> > > On Tue, Mar 25, 2008 at 4:26 PM, Ad
On Tue, Mar 25, 2008 at 5:06 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 25, 2008 at 2:43 PM, Alexander Belopolsky
>
> <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Mar 25, 2008 at 4:26 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
>
> > > It does not even have to be a frozenset. A set works
On Tue, Mar 25, 2008 at 2:43 PM, Alexander Belopolsky
<[EMAIL PROTECTED]> wrote:
> On Tue, Mar 25, 2008 at 4:26 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > It does not even have to be a frozenset. A set works just as well,
> > never modified by the produced bytecode.
>
> With the current im
On Tue, Mar 25, 2008 at 4:26 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> I meant that there may be disgustingly
> large globals that exceed some maximum size the stack allows.
I am to aware of any hard limit on the stack size other than whatever
the limit for a contiguous in-memory array may be
On Tue, Mar 25, 2008 at 2:11 PM, Alexander Belopolsky
<[EMAIL PROTECTED]> wrote:
> On Tue, Mar 25, 2008 at 3:32 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> ..
> > I worry that there might be generated code using disgustingly large
> > literals.
>
> I don't see how this would presents a bigger
On Tue, Mar 25, 2008 at 3:32 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
..
> I worry that there might be generated code using disgustingly large
> literals.
I don't see how this would presents a bigger problem to the stack
scheme compared to the current insert as you go scheme. Note that
for "d
On Tue, Mar 25, 2008 at 12:35 PM, Alexander Belopolsky
<[EMAIL PROTECTED]> wrote:
> Python 3.0 set and dict literals produce very different bytecode:
>
> >>> dis(lambda:{1,2,3})
> 1 0 LOAD_CONST 0 (1)
> 3 LOAD_CONST 1 (2)
> 6 LOAD
Python 3.0 set and dict literals produce very different bytecode:
>>> dis(lambda:{1,2,3})
1 0 LOAD_CONST 0 (1)
3 LOAD_CONST 1 (2)
6 LOAD_CONST 2 (3)
9 BUILD_SET3
12 RETURN_V
14 matches
Mail list logo
