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?
_
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
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
>> 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
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 an overall questionable
effect.
As for measuri
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> 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
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
[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
[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
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
> >> > 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
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
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
>
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
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
"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.
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
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
"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
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
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_
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
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
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:
>
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
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
28 matches
Mail list logo
