Hello,
I've found that abstractmethod and similar decorators "don't work" in
classes, inherited from built-in types other than object.
For example:
>>> import abc
>>> class MyBase(metaclass=abc.ABCMeta):
@abc.abstractmethod
def foo(): pass
>>> MyBase()
Traceback (most recent call
> Because tracker is ugly.
Is this an unbiased opinion? :)
Eugene
___
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
> To answer Eugene's question, there's no official policy but the
> comment at the top of Python/makeopcodetargets.py can indeed serve as
> an useful guideline. I wonder if we still have buildbots with 2.3 as
> the system Python, by the way.
Ok, I'll use 2.3 as my target. Thanks.
Eugene
_
> Ok, so it sounds like ast is *not* limited to CPython? That makes it
> harder to justify changing it just so as to ease the compilation
> process in CPython (as opposed to add new language features).
The changes above are not just for CPython, but to simplify processing
of AST in general, by red
Hello,
CPython source code currently contains a number of python scripts (e.g
Python/makeopcodetargets.py, Objects/typeslots.py, Parser/asdl_c.py)
that are used during the build of the python interpreter itself. For
this reason they are run with system installed python. What is the
policy regardin
> If it's do-able, your option 2 is probably the way to go. Out of the
> box, it may just need to raise an exception if asked to down-convert
> code that uses new constructs that can't readily be expressed using
> the old AST (I'm specifically thinking of the challenge of converting
> PEP 380's yie
> However, I'm not sure we *can* do a general-purpose AST transformation
> that handles both new nodes and changes to existing nodes correctly
> for all applications.
As long as both versions contain the same information we can write a
transformation that does a near-perfect job.
E.g. for my chang
Hello,
While working on a rewrite of peephole optimizer that works on AST
(http://bugs.python.org/issue11549) I had to make a few changes to the
structure of AST. The changes are described in the issue. This raises the
question -- what is the policy for making changes to the AST? Documentation
for
> I'm not disputing that, and I understand that my current choice of mail
> reader limits me. I was just asking if it would be possible (read: fairly
> easy) to only generate utf-8 when it was necessary.
Isn't utf-8 itself same as ascii where no non-ascii symbols are used?
Eugene
___
> 2. The level at which the dependency injection works (function
> arguments, class attributes, module globals) needs to be decided
+1. The scope of parameter needs to be specified. If the scope is
global, this can be achieved pretty easily -- declare some of the
imports in particular modules to b
> My point is that I don't see the distinction between avoiding using dicts
> with well-known keys and wanting to access a dict with attribute access
> (which is where this started). Seems the same to me.
I think using dict with well-known keys is what makes people want dict
with attribute access.
> Although we do something similar with namedtuple (instead of using a
> dict), so it's not like we have a strict distinction.
Named tuple is a convenience to avoid creating boilerplate classes (or
resorting to use dict with well-known keys). Names in named tuple are
not data, only values. In dict
> Not if the changes you want to suppress are actually also on the same
> branch as the one whose mainline you are trying to see (which they
> typically are, with the branch typically being "default").
Right, that would amount to not using named branches. But if you
develop on a named feature-bran
> Bazaar apparently has a notion of mainline whereas Mercurial believes
> that all changesets are created equal. The tools are different.
Mercurial has named branches. When viewing history you can restrict it
to just one named branch, which, I think, will have an effect similar
to "mainline".
Eu
> Out of curiosity, what is your objection to having the child process?
One of the problems is that parent process will not be able to kill
launched script. Simply doing TerminateProcess will kill the launcher,
leaving interpreter running. This can be partially fixed with job
objects, though.
Eug
> I think you guys are forgetting about FOR_ITER, listcomps, and the like.
>
> That is, IIRC, the reason loops use the block stack is because they put
> things on the regular stack, that need to be cleared off the stack when the
> loop is exited (whether normally or via an exception).
Good point.
To give this a positive spin, here's a patch that implements constant
folding on AST (it does few other optimizations on compiler data
structures, so it replaces "peephole over bytecode" completely).
http://bugs.python.org/issue11549
It passes make test, but of course more testing is needed. Comm
Can sort have an option (and/or try to figure it itself) to calculate
key for every comparison instead of caching them? This will have the
same memory requirements as with cmp, but doesn't require rewriting
code if you decide to trade speed for memory. Will this be much slower
than with cmp?
If go
Hi
What OS and what file system you are using? Many file systems (e,g.
ext2/3fs) handle large directories very poorly.
A quick way to check if this has anything to do with Python is writing
a small C program that opens these files and time it.
Eugene
On Sat, Mar 12, 2011 at 10:13 AM, Lukas Lueg
> There are also "with" blocks :-) (which use separate opcodes, although
> they are similar in principle to try/finally blocks)
IIUC they use separate opcode, but the same block type (SETUP_FINALLY).
> There may be complications with nested try/finally blocks. You either
> need to generate separa
> One note on the patch: it allocates an extra stack which is dynamically grown;
> but there is no unittest to exercise the stack-growing code.
Isn't this doing it?
1.20 +# Long tuples should be folded too.
1.21 +asm = dis_single(repr(tuple(range(1
1.22 +# One LOAD
>> Experience shows that optimizations are always error prone, no matter
>> what framework or internal representation you use.
>
> On that basis, I believe that we ought to declare peephole.c as being
> somewhat off-limits for further development (except for small
> adaptations if the underlying op
Experience shows that optimizations are always error prone, no matter
what framework or internal representation you use. I don't think we
should assume that simply rewriting all optimizations to work on AST
will make them bug free once and for all. On the contrary, I think
such a rewrite will intro
Hello,
What is the purpose of SETUP_LOOP instruction? From a quick look it
seems like it just pushes the size of the loop into blocks stack; that
size is only used by BREAK_LOOP instruction.
BREAK_LOOP could just contain the target address directly, like
CONTINUE_LOOP does. This would avoid SETUP_
Well, that was just a though. You're right that long runs of constants
can appear, and it's better to avoid pathological behaviour in such
cases.
Your second path looks good.
Eugene
On Thu, Mar 10, 2011 at 6:30 PM, Antoine Pitrou wrote:
> On Thu, 10 Mar 2011 02:17:34 + (UTC)
&
I've posted a patch.
Eugene
On Thu, Mar 10, 2011 at 3:30 PM, Mark Dickinson wrote:
> On Thu, Mar 10, 2011 at 2:17 AM, Eugene Toder wrote:
>>> Indeed, see http://bugs.python.org/issue11244
>>
>> Yes, I've noticed that too. However, if I'm not missin
> I guess all this advice doesn't really apply to this case, though.
> The Microsoft API declares the parameter as a volatile*, indicating
> that they consider it "proper" usage of the API to declare the storage
> volatile. So ISTM that we should comply regardless of whether volatile
> is considere
> Indeed, see http://bugs.python.org/issue11244
Yes, I've noticed that too. However, if I'm not missing something, your patches
do not address folding of -0.
Btw, there's an alternative approach to allow "recursive" constant folding.
Instead of keeping a stack of last constants, you can keep a po
Hello,
I've noticed since version 3.2 python doesn't fold -0:
Python 3.1.3 (r313:86834, Nov 28 2010, 10:01:07)
>>> def foo(): return -0
>>> dis(foo)
1 0 LOAD_CONST 1 (0)
3 RETURN_VALUE
Python 3.2 (r32:88445, Feb 20 2011, 21:30:00)
>>> def foo(): return -0
29 matches
Mail list logo
