[Python-ideas] Extending language syntax

[Gregory Salvan]

I've open a gdoc to share our visions and be able to collaborate on this
subject.

It is open, everybody can contribute, I'll be happy if it permits us to
find a good solution.

https://docs.google.com/document/d/15IPMNzUnK9nd_j7B6wdo7gAn2US52qa8MjGcfQeaRtk/edit?usp=sharing


2013/11/12 Haoyi Li <haoyi.sg at gmail.com>

> >  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
>>
>
>
> _______________________________________________
> 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/20131113/dad29024/attachment.html>