[Python-ideas] Extending language syntax

[Haoyi Li]

>  to have object identities defined on their values instead of their
memory allocation

but the whole point of identity is to be their memory allocation! There's
already equality if you want to compare on values.

I'm not sure what you really want, and I suspect you're also somewhat
uncertain. Do you want multiline lambdas, by-name variables, custom blocks,
interned objects, infix operators? Other things? It's a lot of distinct
feature requests to ask for and it would be good to get them cleared up in
everyone's minds.

If you want interning for arbitrary expressions, MacroPy lets you do that
already <https://github.com/lihaoyi/macropy#interned> in your own code. It
interns on a per-declaration basis rather than on a per-value basis,
because the task of evaluating an arbitrary expression at macro expansion
time is icky. You can pull some other neat tricks with it (e.g. classes
whose equality is by default defined by
value<https://github.com/lihaoyi/macropy#case-classes>),
but are limited to Python's grammar and parser, so no
infix-method-operators and such, but you can trigger macro expansion easily
with should_equal['abc', ''abc'] and do whatever "compile"-time
substitution you want.







On Tue, Nov 12, 2013 at 9:56 AM, Andrew Barnert <abarnert at yahoo.com> wrote:

> On Nov 12, 2013, at 2:37, Charles-François Natali <cf.natali at gmail.com>
> wrote:
>
> > 2013/11/12 Andrew Barnert <abarnert at yahoo.com>:
> >> Is there any implementation (like one of the PyPy sub projects) that
> uses refcounting, with interlocked increments if two interpreter threads
> are live but plain adds otherwise? In such an implementation, I think the
> cost of checking a second flag to avoid the interlocked increment would, at
> least on many platforms (including x86, x86_64, and arm9), be comparatively
> very cheap, and if used widely could provide big benefits.
> >
> > How would you do this in a thread-safe way without atomic operations,
> > or at least memory barriers?
>
> The whole point of a "permanent" flag would be that it's only set at
> object creation time and never modified, and the object never gets cleaned
> up.
>
> That means you can just check the flag, without an atomic operation, and
> if it's set you can skip the (slow/cache-killing) atomic increment or
> decrement.
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20131112/008393fd/attachment-0001.html>