Iterating. A line still missing:
>
> ### Simple OO Framework
>
> class _O: pass
>
> def make_object(*procedures, base=None, bases=None):
> o = _O()
> methods = {}
> o.__methods__ = methods
> o.__derived__ = N
On 17/05/2015 13:25, Jonas Wielicki wrote:
On 16.05.2015 02:55, Gregory Ewing wrote:
BartC wrote:
For example, there is a /specific/ byte-code called BINARY_ADD, which
then proceeds to call a /generic/ binary-op handler! This throws away
the advantage of knowing at byte-code generation time exa
On 16.05.2015 02:55, Gregory Ewing wrote:
> BartC wrote:
>> For example, there is a /specific/ byte-code called BINARY_ADD, which
>> then proceeds to call a /generic/ binary-op handler! This throws away
>> the advantage of knowing at byte-code generation time exactly which
>> operation is needed.
>
Marko Rauhamaa :
> Ok, here's a quick port that have barely tried out:
And here's a more complete port (with some possible dunder abuse):
### Simple OO Framework
class _O: pass
def make_object(*procedures, base=None, base
Steven D'Aprano :
> On Sat, 16 May 2015 11:59 pm, Marko Rauhamaa wrote:
>> supports multiple inheritance without classes. Maybe I should port that
>> to Python...
>
> I'd like to see it, but somehow I don't think that your "Scheme object
> system" is another name for "closures". We were talking ab
On Sat, 16 May 2015 11:59 pm, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> A couple more negatives:
>>
>> - no such thing as inheritance;
>
> Untrue. My simple Scheme object system (125 lines incl. documentation)
Ah yes, I've seen Javascript code like that too. Each line is thirty
thousand ch
Steven D'Aprano :
> A couple more negatives:
>
> - no such thing as inheritance;
Untrue. My simple Scheme object system (125 lines incl. documentation)
supports multiple inheritance without classes. Maybe I should port that
to Python...
> - "is-a" relationship tests don't work;
>From the duckty
On Sat, 16 May 2015 06:08 pm, Marko Rauhamaa wrote:
> Note that almost identical semantics could be achieved without a class.
> Thus, these two constructs are almost identical:
[...]
> IOW, the class is a virtually superfluous concept in Python. Python has
> gotten it probably without much though
BartC :
> I suppose in many cases an object will have no attributes of its own,
> and so it can rapidly bypass the first lookup.
Almost all objects have quite many instance attributes. That's what
tells objects apart.
> I don't understand the need for an object creation (to represent A.B
> so th
On 16/05/2015 02:55, Steven D'Aprano wrote:
On Sat, 16 May 2015 09:27 am, Mark Lawrence wrote:
On 15/05/2015 23:44, Marko Rauhamaa wrote:
BartC :
What /is/ a method lookup? Is it when you have this:
A.B()
and need to find whether the expression A (or its class or type) has a
name B asso
On Sat, May 16, 2015 at 11:55 AM, Steven D'Aprano
wrote:
> but in Python's case it has to be resolved at run-time, so if you care about
> speed, you should try to avoid long chains of dots in performance critical
> loops. E.g. instead of:
>
> for x in sequence:
> foo.bar.baz.foobar.spa
On Sat, 16 May 2015 09:27 am, Mark Lawrence wrote:
> On 15/05/2015 23:44, Marko Rauhamaa wrote:
>> BartC :
>>
>>> What /is/ a method lookup? Is it when you have this:
>>>
>>> A.B()
>>>
>>> and need to find whether the expression A (or its class or type) has a
>>> name B associated with it? (And
On 2015-05-16 01:43, BartC wrote:
On 15/05/2015 23:44, Marko Rauhamaa wrote:
BartC :
What /is/ a method lookup? Is it when you have this:
A.B()
and need to find whether the expression A (or its class or type) has a
name B associated with it? (And it then needs to check whether B is
somethi
BartC wrote:
For example, there is a /specific/ byte-code called BINARY_ADD, which
then proceeds to call a /generic/ binary-op handler! This throws away
the advantage of knowing at byte-code generation time exactly which
operation is needed.
While inlining the binary-op handling might give yo
On 15/05/2015 23:44, Marko Rauhamaa wrote:
BartC :
What /is/ a method lookup? Is it when you have this:
A.B()
and need to find whether the expression A (or its class or type) has a
name B associated with it? (And it then needs to check whether B is
something that can be called.)
If so, doe
On 5/15/2015 5:54 PM, BartC wrote:
What /is/ a method lookup? Is it when you have this:
A.B()
This is parsed as (A.B)()
and need to find whether the expression A (or its class or type) has a
name B associated with it?
Yes. Dotted names imply an attribute lookup.
(And it then needs to
On 15/05/2015 23:44, Marko Rauhamaa wrote:
BartC :
What /is/ a method lookup? Is it when you have this:
A.B()
and need to find whether the expression A (or its class or type) has a
name B associated with it? (And it then needs to check whether B is
something that can be called.)
If so, doe
BartC :
> What /is/ a method lookup? Is it when you have this:
>
> A.B()
>
> and need to find whether the expression A (or its class or type) has a
> name B associated with it? (And it then needs to check whether B is
> something that can be called.)
>
> If so, does that have to be done using Pyt
On 15/05/2015 09:59, Marko Rauhamaa wrote:
The path from decoding a bytecode to the C code that implements it can
be rather convoluted, but there are reasons for each of the
complications -- mainly to do with supporting the ability to override
operators with C and/or Python code.
If you removed
On 5/15/2015 6:51 AM, Christian Gollwitzer wrote:
Am 14.05.15 um 20:50 schrieb Terry Reedy:
On 5/14/2015 1:11 PM, Chris Angelico wrote:
2) make test - run the entire test suite. Takes just as long every
time, but most of it won't have changed.
The test runner has an option, -jn, to run tests
On 5/15/2015 4:59 AM, Marko Rauhamaa wrote:
Must a method lookup necessarily involve object creation?
Where is matters, inside loops, method lookup can be avoided after doing
it once.
for i in range(100): ob.meth(i)
versus
meth = ob.meth
for i in range(100): meth(i)
For working wi
On Sat, May 16, 2015 at 1:00 AM, Ian Kelly wrote:
> On Fri, May 15, 2015 at 6:43 AM, Steven D'Aprano
> wrote:
>> How much time would it save? Probably very little. After all, unless the
>> method call itself did bugger-all work, the time to create the method
>> object is probably insignificant. B
On Fri, May 15, 2015 at 9:00 AM, Ian Kelly wrote:
> On Fri, May 15, 2015 at 6:43 AM, Steven D'Aprano
> wrote:
>> How much time would it save? Probably very little. After all, unless the
>> method call itself did bugger-all work, the time to create the method
>> object is probably insignificant. B
On Fri, May 15, 2015 at 6:43 AM, Steven D'Aprano
wrote:
> How much time would it save? Probably very little. After all, unless the
> method call itself did bugger-all work, the time to create the method
> object is probably insignificant. But it's a possible optimization.
An interesting alternati
On 15/05/2015 11:52, Marko Rauhamaa wrote:
wxjmfa...@gmail.com:
Le vendredi 15 mai 2015 11:20:25 UTC+2, Marko Rauhamaa a écrit :
wxjmfa...@gmail.com:
Implement unicode correctly.
Did they reject your patch?
You can not patch something that is wrong by design.
Are you saying the Python l
On Fri, 15 May 2015 08:50 pm, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Fri, May 15, 2015 at 6:59 PM, Marko Rauhamaa wrote:
>>> Must a method lookup necessarily involve object creation?
>>
>> Actually, no.
>> [...]
>> a particular Python implementation is most welcome to notice the
>> ext
On 15/05/2015 10:20, Marko Rauhamaa wrote:
wxjmfa...@gmail.com:
Implement unicode correctly.
Did they reject your patch?
Marko
Please don't feed him, it's been obvious for years that he hasn't the
faintest idea what he's talking about.
--
My fellow Pythonistas, ask not what our languag
On Fri, May 15, 2015 at 10:10 PM, Steven D'Aprano
wrote:
> The benefit of this is that most strings will use 1/2 or 1/4 of the memory
> that they otherwise would need, which gives an impressive memory saving.
> That leads to demonstrable speed-ups in real-world code, however it is
> possible to fi
On Fri, 15 May 2015 08:52 pm, Marko Rauhamaa wrote:
> wxjmfa...@gmail.com:
>
>> Le vendredi 15 mai 2015 11:20:25 UTC+2, Marko Rauhamaa a écrit :
>>> wxjmfa...@gmail.com:
>>>
>>> > Implement unicode correctly.
>>> Did they reject your patch?
>>
>> You can not patch something that is wrong by desi
wxjmfa...@gmail.com:
> Le vendredi 15 mai 2015 11:20:25 UTC+2, Marko Rauhamaa a écrit :
>> wxjmfa...@gmail.com:
>>
>> > Implement unicode correctly.
>> Did they reject your patch?
>
> You can not patch something that is wrong by design.
Are you saying the Python language spec is unfixable or tha
Am 14.05.15 um 20:50 schrieb Terry Reedy:
On 5/14/2015 1:11 PM, Chris Angelico wrote:
2) make test - run the entire test suite. Takes just as long every
time, but most of it won't have changed.
The test runner has an option, -jn, to run tests in n processes instead
of just 1. On my 6 core pe
Chris Angelico :
> On Fri, May 15, 2015 at 6:59 PM, Marko Rauhamaa wrote:
>> Must a method lookup necessarily involve object creation?
>
> Actually, no.
> [...]
> a particular Python implementation is most welcome to notice the
> extremely common situation of method calls and optimize it.
I'm no
On Fri, May 15, 2015 at 8:14 PM, Steven D'Aprano
wrote:
> (If anything, using an implicit boolean test will be faster than an
> explicit manual test, because it doesn't have to call the len() global.)
Even more so: Some objects may be capable of determining their own
lengths, but can ascertain th
On Fri, 15 May 2015 06:59 pm, Marko Rauhamaa wrote:
> However, in some respects, Python might be going overboard with its
> dynamism; are all those dunder methods really needed? Must "false" be
> defined so broadly? Must a method lookup necessarily involve object
> creation?
Yes, what do you mean
On Fri, May 15, 2015 at 6:59 PM, Marko Rauhamaa wrote:
> However, in some respects, Python might be going overboard with its
> dynamism; are all those dunder methods really needed?
Yes - at least, most of them. As regards operators, there are three
options: either you have magic methods for all o
On 15/05/2015 07:05, Gregory Ewing wrote:
BartC wrote:
It appears to be those "<=" and "+" operations in the code above where
much of the time is spent. When I trace out the execution paths a bit
more, I'll have a better picture of how many lines of C code are
involved in each iteration.
The p
wxjmfa...@gmail.com:
> Implement unicode correctly.
Did they reject your patch?
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Gregory Ewing :
> BartC wrote:
>> It appears to be those "<=" and "+" operations in the code above
>> where much of the time is spent. When I trace out the execution paths
>> a bit more, I'll have a better picture of how many lines of C code
>> are involved in each iteration.
>
> The path from dec
BartC wrote:
It appears to be those "<=" and "+" operations in the code above where
much of the time is spent. When I trace out the execution paths a bit
more, I'll have a better picture of how many lines of C code are
involved in each iteration.
The path from decoding a bytecode to the C cod
On 14/05/2015 22:55, BartC wrote:
> def whiletest():
> i=0
> while i<=1:
> i=i+1
>
> whiletest()
>
Python 2.5 9.2 seconds
Python 3.1 13.1
Python 3.4.317.0
Python 3.4.314.3 (under Ubuntu on same machine, using the version
I buil
On 2015-05-14 22:55, BartC wrote:
On 14/05/2015 17:29, Marko Rauhamaa wrote:
BartC :
That's a shame because I wanted to tinker with the main dispatcher
loop to try and find out what exactly is making it slow. Nothing that
seems obvious at first sight.
My guess is the main culprit is attribut
On 14/05/2015 17:29, Marko Rauhamaa wrote:
BartC :
That's a shame because I wanted to tinker with the main dispatcher
loop to try and find out what exactly is making it slow. Nothing that
seems obvious at first sight.
My guess is the main culprit is attribute lookup in two ways:
* Each obj
On 5/14/2015 1:11 PM, Chris Angelico wrote:
2) make test - run the entire test suite. Takes just as long every
time, but most of it won't have changed.
The test runner has an option, -jn, to run tests in n processes instead
of just 1. On my 6 core pentium, -j5 cuts time to almost exactly 1/5
On Fri, May 15, 2015 at 3:32 AM, BartC wrote:
> OK, thanks. I didn't even know where the executable was put! Now I don't
> need 'make install', while 'make test' I won't bother with any more.
>
> Making a small change and typing 'make' took 5 seconds, which is reasonable
> enough (although I had t
On 14/05/2015 18:11, Chris Angelico wrote:
On Fri, May 15, 2015 at 3:02 AM, BartC wrote:
I hope there's a quicker way of re-building an executable after a minor
source file change, otherwise doing any sort of development is going to be
impractical.)
The whole point of 'make' is to rebuild o
On Fri, May 15, 2015 at 3:02 AM, BartC wrote:
> Actually I had VirtualBox with Ubuntu, but I don't know my way around Linux
> and preferred doing things under Windows (and with all my own tools).
>
> But it's now building under Ubuntu.
>
> (Well, I'm not sure what it's doing exactly; the instructi
On 05/14/2015 01:02 PM, BartC wrote:
On 14/05/2015 17:09, Chris Angelico wrote:
On Fri, May 15, 2015 at 1:51 AM, BartC wrote:
OK, the answer seems to be No then - you can't just trivially compile
the C
modules that comprise the sources with the nearest compiler to hand.
So much
for C's famous
On 14/05/2015 17:09, Chris Angelico wrote:
On Fri, May 15, 2015 at 1:51 AM, BartC wrote:
OK, the answer seems to be No then - you can't just trivially compile the C
modules that comprise the sources with the nearest compiler to hand. So much
for C's famous portability!
(Actually, I think you a
BartC :
> That's a shame because I wanted to tinker with the main dispatcher
> loop to try and find out what exactly is making it slow. Nothing that
> seems obvious at first sight.
My guess is the main culprit is attribute lookup in two ways:
* Each object attribute reference involves a diction
On Fri, May 15, 2015 at 1:51 AM, BartC wrote:
> OK, the answer seems to be No then - you can't just trivially compile the C
> modules that comprise the sources with the nearest compiler to hand. So much
> for C's famous portability!
>
> (Actually, I think you already lost me on your first line.)
>
On 13/05/2015 23:34, Terry Reedy wrote:
On 5/13/2015 3:36 PM, BartC wrote:
I'm interested in playing with the CPython sources. I need to be able to
build under Windows, but don't want to use make files (which rarely work
properly), nor do a 6GB installation of Visual Studio Express which is
what
On 5/13/2015 3:36 PM, BartC wrote:
I'm interested in playing with the CPython sources. I need to be able to
build under Windows, but don't want to use make files (which rarely work
properly), nor do a 6GB installation of Visual Studio Express which is
what seems to be needed (I'm hopeless with co
On 13/05/2015 20:36, BartC wrote:
I'm interested in playing with the CPython sources. I need to be able to
build under Windows, but don't want to use make files (which rarely work
properly), nor do a 6GB installation of Visual Studio Express which is
what seems to be needed (I'm hopeless with com
I'm interested in playing with the CPython sources. I need to be able to
build under Windows, but don't want to use make files (which rarely work
properly), nor do a 6GB installation of Visual Studio Express which is
what seems to be needed (I'm hopeless with complicated IDEs anyway).
Is it po
On 8/20/2014 8:24 PM, Adam Bishop wrote:
>> Or you can ignore it.
>
> It's a little tricky with mock, as failures during the test phase are
fatal.
Unfortunately, I have no idea what 'mock' is in this context.
Thanks for pointing me in the right direction.
If you possibly can, also act on N
On 21 Aug 2014, at 01:08, Terry Reedy wrote:
> This is a test of lib/distutils.sysconfig, a near but not exact copy of
> lib/sysconfig. I don't know why we have both, but this one will not affect
> you unless you use distutils to compile something.
I've been staring at this for a couple of hour
In article <09843563-b0fd-451b-bf66-0fb720cec...@ja.net>,
Adam Bishop wrote:
> I'm trying to build python 3.3.2 from source packages provided by Red Hat
> under mock.
>
> The build itself works,but one specific test is failing:
>
>=
On 8/20/2014 7:05 PM, Adam Bishop wrote:
I'm trying to build python 3.3.2 from source packages provided by Red Hat under
mock.
The build itself works,but one specific test is failing:
==
FAIL: test_sysconfig_module
(d
I'm trying to build python 3.3.2 from source packages provided by Red Hat under
mock.
The build itself works,but one specific test is failing:
==
FAIL: test_sysconfig_module
(distutils.tests.test_sysconfig.SysconfigTest
59 matches
Mail list logo
