Phillip J. Eby wrote:
> I meant that just changing its class is a mutation, and since immutables
> can be shared or cached, that could lead to problems. So I do think
> it's a reasonable implementation limit to disallow changing the
> __class__ of an immutable.
That's a fair point.
Although
Sokolov Yura wrote:
> May be allow modules to define __getattr__ ?
I think I like the descriptor idea better. Besides
being more in keeping with modern practice, it would
allow for things like
from autoloading import autoload
Foo = autoload('foomodule', 'Foo')
Blarg = autoload('blargmod
Tony Nelson wrote:
> I have written my fastcharmap decoder and encoder. It's not meant to be
> better than the patch and other changes to come in a future version of
> Python, but it does work now with the current codecs.
It's an interesting solution.
> To use, hook each codec to be speed up:
>
Phillip J. Eby wrote:
> A more
> compact scheme is possible, by using two tables - a bytecode->line
> number table, and a line number-> file table.
>
> If you have to encode multiple files, you just offset their line numbers
> by the size of the other files,
More straightforwardly, the seco
Calvin Spealman <[EMAIL PROTECTED]> wrote:
>
> On 10/11/05, Eyal Lotem <[EMAIL PROTECTED]> wrote:
> > locals()['x'] = 1 # Quietly fails!
> > Replaced by:
> > frame.x = 1 # Raises error
>
> What about the possibility of making this hypothetic frame object an
> indexable, such that fra
On 10/13/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> Indeed. I should've threatened to kill the AST branch long ago! :)
:-)
I decreased a lot of the memory leaks. Here are some more to work on.
I doubt this list is complete, but it's a start:
PyObject_Malloc (obmalloc.c:717)
_PyObject_
On 10/14/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
>
> I decreased a lot of the memory leaks. Here are some more to work on.
> I doubt this list is complete, but it's a start:
Oh and since I fixed the memory leaks in a generated file
Python/Python-ast.c, the changes still need to be implemente
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
> Even better if the lines for a particular piece of code don't have
> to all come from the same file.
This seems _fairly_ esoteric to me. Why do you need it?
I can think of two uses for lnotab information: printing source lines
and locating source l
At 08:07 PM 10/14/2005 +1300, Greg Ewing wrote:
>Phillip J. Eby wrote:
>
> > A more
> > compact scheme is possible, by using two tables - a bytecode->line
> > number table, and a line number-> file table.
> >
> > If you have to encode multiple files, you just offset their line numbers
> > by the si
At 09:23 AM 10/14/2005 +0100, Michael Hudson wrote:
>"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
>
> > Even better if the lines for a particular piece of code don't have
> > to all come from the same file.
>
>This seems _fairly_ esoteric to me. Why do you need it?
Compilers that inline function
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
> At 09:23 AM 10/14/2005 +0100, Michael Hudson wrote:
>>"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
>>
>> > Even better if the lines for a particular piece of code don't have
>> > to all come from the same file.
>>
>>This seems _fairly_ esoteric to me.
Martin v. Löwis wrote:
> Tony Nelson wrote:
>
>> I have written my fastcharmap decoder and encoder. It's not meant to be
>> better than the patch and other changes to come in a future version of
>> Python, but it does work now with the current codecs.
>
> It's an interesting solution.
I like t
Walter Dörwald wrote:
> We've already taken care of decoding. What we still need is a new
> gencodec.py and regenerated codecs.
I'll take care of that; just haven't gotten around to it yet.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Oct 14 2005
Sokolov Yura wrote:
> May be allow modules to define __getattr__ ?
>
> def __getattr__(thing):
> try:
> return __some_standart_way__(thing)
> except AttributeError:
> if thing=="Queue":
>import sys
>from Queue import Queue
>
Hi!
Phillip J. Eby wrote:
[snip]
> Okay, those are fairly esoteric use cases, I admit. :) However, PyPy
> already has some inlining capability in its optimizer, so it's not all that
> crazy of an idea that Python in general will need it.
It's kind of strange to argue with PyPy's inlining capa
> >> > Even better if the lines for a particular piece of code don't
have
> >> > to all come from the same file.
> >>
> >>This seems _fairly_ esoteric to me. Why do you need it?
> >
> > Compilers that inline function calls, but want the code to still be
> > debuggable. AOP tools that weave byteco
I ran across an interesting paper about some VM optimizations yesterday:
http://www.object-arts.com/Papers/TheInterpreterIsDead.PDF
One thing mentioned was that saving even one cycle in their 'PUSH_SELF'
opcode improved interpreter performance by 5%. I thought that was pretty
cool, and the
[Michael Hudson]
> "Phillip J. Eby" <[EMAIL PROTECTED]> writes:
> > Even better if the lines for a particular piece of code don't have
> > to all come from the same file.
> This seems _fairly_ esoteric to me. Why do you need it?
For when Python code is generated from more than one original sour
[Raymond Hettinger]
> > >> > Even better if the lines for a particular piece of code don't
> > >> > have to all come from the same file.
> YAGNI
I surely needed it, more than once. Don't be so assertive. :-)
--
François Pinard http://pinard.progiciels-bpi.ca
At 02:41 PM 10/14/2005 -0400, Raymond Hettinger wrote:
>YAGNI
If the feature were there, I'd have used it already, so I wouldn't consider
it YAGNI. In the cases where I would've used it, I instead split generated
code into separate functions so I could compile() each one with a different
filen
Phillip> Indeed, even pystone doesn't do much attribute access on the
Phillip> first argument of most of its functions, especially not those
Phillip> in inner loops. Only Proc1() and the Record.copy() method do
Phillip> anything that would be helped by SELF_ATTR. But it seems to
Walter Dörwald wrote:
> Of course we can't accept Pyrex code in the Python core, so it would be
> great to rewrite the encoder as a patch to PyUnicode_EncodeCharmap().
> This version must be able to cope with encoding tables that are random
> strings without crashing.
I don't think this will be
Phillip J. Eby wrote:
> Anyway, my main question is, do these sound like worthwhile
> optimizations?
In the past, I think the analysis was always "no". It adds
an opcode, so increases the size of the switch, causing
more pressure on the cache, with an overall questionable
effect.
As for measuri
At 12:33 AM 10/15/2005 +0200, Martin v. Löwis wrote:
>Phillip J. Eby wrote:
> > Anyway, my main question is, do these sound like worthwhile
> > optimizations?
>
>In the past, I think the analysis was always "no". It adds
>an opcode, so increases the size of the switch, causing
>more pressure on the
>> Phillip J. Eby wrote:
>> > Anyway, my main question is, do these sound like worthwhile
>> > optimizations?
>>
>> In the past, I think the analysis was always "no". It adds an opcode,
>> so increases the size of the switch, causing more pressure on the
>> cache, with
Josiah Carlson wrote:
>Sokolov Yura <[EMAIL PROTECTED]> wrote:
>
>
>>Offtopic:
>>
>>Microsoft Windows [Version 5.2.3790]
>>(C) Copyright 1985-2003 Microsoft Corp.
>>
>>G:\Working\1>c:\Python24\python
>>Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on
>>win32
>>Type "help
Sorry I can't reply to the message (I'm at home, and don't currently have
python-dev sent there).
I have a version of Raymond's constant binding recipe:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/277940
that also binds all attribute accesses all the way down into a single
constant
On 10/3/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
> Martin Blais <[EMAIL PROTECTED]> writes:
>
> > How hard would that be to implement?
>
> import sys
> reload(sys)
> sys.setdefaultencoding('undefined')
Hmmm any particular reason for the call to reload() here?
_
28 matches
Mail list logo
