Path: csiph.com!usenet.pasdenom.info!news.redatomik.org!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Thu, 21 May 2015 17:50:32 +0100
From: MRAB <python@mrabarnett.plus.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: Slices time complexity
References: <9ceklad15llnv3npejq9iuh91soci8aeqo@4ax.com> <mailman.114.1431978628.17265.python-list@python.org> <7ea01590-a559-46e5-abf5-29622e39aae7@googlegroups.com> <555ac697$0$12910$c3e8da3$5496439d@news.astraweb.com> <862693ca-42cf-4f5b-ac12-133e43e7606b@googlegroups.com> <878uclf3bt.fsf@elektro.pacujo.net> <555af171$0$12995$c3e8da3$5496439d@news.astraweb.com> <874mn9ezaw.fsf@elektro.pacujo.net> <mailman.124.1432025439.17265.python-list@python.org> <555b2fa9$0$12996$c3e8da3$5496439d@news.astraweb.com> <cs22vbFnd69U1@mid.individual.net> <mailman.156.1432082566.17265.python-list@python.org> <87oalfooz7.fsf@elektro.pacujo.net> <92992653-d511-4e33-a21d-541eeda4799b@googlegroups.com> <555c225b$0$2769$c3e8da3$76491128@news.astraweb.com> <mjhi5a$4pa$1@dont-email.me> <555d6ad8$0$2763$c3e8da3$76491128@news.astraweb.com> <755415ac-25c8-40db-b3c2-78111ed25621@googlegroups.com>
In-Reply-To: <755415ac-25c8-40db-b3c2-78111ed25621@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.204.1432227041.17265.python-list@python.org>
Lines: 56
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:91016

On 2015-05-21 14:34, bartc wrote:
> 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.)
>
If memory addresses aren't byte-aligned, you could use the least-
significant bit to indicate whether it's a small integer, i.e. if it's
zero, then it's an address, else shift right by 1 bit arithmetically
for the integer value.