[Python-ideas] Extending language syntax

[Gregory Salvan]

Sorry Chris Angelico and Andrew Barnert, I have not enough knowledge of
python implementations to correctly answer your questions.
I just wanted to share the idea in order to see if It was interesting
before I dig in that way.

I thought token can act like a macro, replacing at compile time things
like: 'abc' should_equal 'abc' by should_equal.__get__('abc', 'abc', None)
Then I saw assert_equal as a "keyword" like "if" and it seemed obvious to
have "assert if is if" raising assertion error.
Finally authorising should_equal.__get__ to behave differently due to its
state seemed dangerous.

As I need immutable objects with an identity given by their values, I
deduce it was value objects.

This might be confusing.

Thanks for your enlightments.



2013/11/12 Andrew Barnert <abarnert at yahoo.com>

> On Nov 11, 2013, at 21:27, Chris Angelico <rosuav at gmail.com> wrote:
>
> > On Tue, Nov 12, 2013 at 4:03 PM, Gregory Salvan <apieum at gmail.com>
> wrote:
> >> I suggested generating value object by freezing object states and to
> have
> >> object identities defined on their values instead of their memory
> >> allocation.
> >
> > I can see some potential in this if there were a way to say "This will
> > never change, don't refcount it or GC-check it"; that might improve
> > performance across a fork (or across threads), but it'd take a lot of
> > language support. Effectively, you would be forfeiting the usual GC
> > memory saving "this isn't needed, get rid of it" and fixing it in
> > memory someplace. The question would be: Is the saving of not writing
> > to that memory (updating refcounts, or marking for a mark/sweep GC, or
> > whatever the equivalent is for each Python implementation) worth the
> > complexity of checking every object to see if it's a frozen one?
>
> 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.
>
> I believe CPython and standard PyPy just use plain adds under the GIL, and
> Jython and IronPython leave all the gc up to the underlying VM, so it would
> probably be a lot harder to get enough benefit there without a lot more
> effort.
>
> Also, as I said in my previous message, I don't think this "permanent
> value" idea is in any way dependent on any of the other stuff suggested,
> and in fact would work better without them. (For example, being able to
> have multiple separate copies of the permanent object that act as if
> they're identical, and can't be distinguished at the Python level.)
>
> >
> > ChrisA
> > _______________________________________________
> > 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/20131112/a53227d7/attachment.html>