Slices time complexity

bartc bart4858 at gmail.com
Thu May 21 09:34:50 EDT 2015


On Thursday, 21 May 2015 06:19:39 UTC+1, Steven D'Aprano  wrote:
> On Wednesday 20 May 2015 19:56, Bartc wrote:

> What you *shouldn't* do is implement your own argument convention,

(That's exactly what I did for my static language compiler which
generates x64 code. The Win64 calling convention was far too
complicated, and required 16-byte stack alignment which was another
headache. My private calling convention works fine! But I have to use the
official one for calling foreign (eg. C) functions.

This is at a lower level than the logical or language view of parameter passing, but still, you don't always have to do what everyone else does.)

> Don't do what the Lua community does, which is invent a stupid distinction 
> between "reference types" and "value types" so they too can misuse 
> terminology:

But in the mind of the user, such a distinction can be intuitive. If
I'm passing a 32-bit integer, it is easy to think of the value being
passed. With a 100 million element array, it harder to think of it being
passed by value than by reference.

> This calling convention has been known as pass by sharing (or variations of 
> that, like "pass by object sharing") since it was named by Barbara Liskov in 
> the 1970s, for the language CLU, but the convention itself goes back to Lisp 
> in the 1950s.

I looked it up expecting a new convention to solve all my problems.
But it's just a re-statement of how Python works anyway!

So a mutable object passed to a function can be changed by that function,
so that the caller sees the change. An immutable object can't be
changed in the same way, but only because Python doesn't allow it to
be modified. (But it does allow assignment to the version in the
function.)

Using what is really pass-by-reference for everything is fine, but
I'm having some trouble with making it efficient for small integer
values (I think this is a weak area of Python). Even with my clunky system
of passing descriptors, the equivalent of BINARY_ADD for two small
integers can be reduced to perhaps 10 or 12 machine instructions,
byte-code dispatch *and* double type-dispatch overheads included (using ASM that is; and technically the type-dispatching is by-passed).

If small integers need to be heap-allocated and managed, then it might need a few more. (And then Python will auto-range these to arbitrary precision as needed, another difference.)

-- 
Bartc



More information about the Python-list mailing list