Stefan Behnel | 3 Jul 20:33 2011
Picon

[Cython] Fwd: Re: GCC Python FE

Hi,

just got this back as a reply from the author of a GCC Python frontend. 
This project flew completely below my radar so far, even though it's the 
second GSoC being invested here.

 From the Python wiki page, it looks like static Python compilers are 
starting to sum up these days. IMHO, it would be better to get these 
consolidated a bit, rather than having people reinvent wheels all over the 
place.

http://wiki.python.org/moin/PythonImplementations

Stefan

-------- Original-Message --------
Subject: Re: GCC Python FE
From: Philip Herron <herron.philip (at) googlemail.com>

On 3 July 2011 16:57, Stefan Behnel wrote:
> I just stumbled over this wiki page:
>
> http://gcc.gnu.org/wiki/PythonFrontEnd
>
> I'm a Cython core developer, and as such, I wonder what the purpose of this
> project was, and what it lead to.

Well i was inspired by PHC http://www.phpcompiler.org/ which was a
similar idea but for php, the purpose was mostly i though it was
interesting and wanted to see how feasible it is to do something like
(Continue reading)

Vitja Makarov | 4 Jul 20:43 2011
Picon

[Cython] Hudson is down?

It seems that hudson server is down.

--

-- 
vitja.
Stefan Behnel | 5 Jul 06:12 2011
Picon

Re: [Cython] Hudson is down?

Vitja Makarov, 04.07.2011 20:43:
> It seems that hudson server is down.

It's back now. Looks like the sage.math machine was restarted.

Stefan
Vitja Makarov | 5 Jul 08:21 2011
Picon

[Cython] PEP 3135 -- New Super

I was thinking about implementing new super() with no arguments.

The problem is where to store __class__, I see two options here:

1. Add func_class member to CyFunction, this way __class__ will be
private and not visible for inner functions:
2. Put it into closure

Actually, I like the first one.
And I don't think that __class__ should be use somewhere outside super()

--

-- 
vitja.
Stefan Behnel | 5 Jul 09:00 2011
Picon

Re: [Cython] PEP 3135 -- New Super

Vitja Makarov, 05.07.2011 08:21:
> I was thinking about implementing new super() with no arguments.

Please do :)

If you start working on it, please assign the ticket to you:

http://trac.cython.org/cython_trac/ticket/696

> The problem is where to store __class__, I see two options here:
>
> 1. Add func_class member to CyFunction, this way __class__ will be
> private and not visible for inner functions:
> 2. Put it into closure

The second option has the advantage of requiring the field only when 
super() is used, whereas the first impacts all functions.

I would expect that programs commonly have a lot more functions than 
specifically methods that use a no-argument call to super(), so this may 
make a difference.

OTOH, not all methods have a closure, so creating one just to store the 
"__class__" field is very wasteful, in terms of both runtime and memory 
overhead. A lot more wasteful than paying 8 bytes of memory for each 
function, with no additional time overhead.

> And I don't think that __class__ should be use somewhere outside super()

Agreed. CPython simply uses a compile time heuristic ("is there a function 
(Continue reading)

Vitja Makarov | 5 Jul 09:17 2011
Picon

Re: [Cython] PEP 3135 -- New Super

2011/7/5 Stefan Behnel <stefan_ml@...>:
> Vitja Makarov, 05.07.2011 08:21:
>>
>> I was thinking about implementing new super() with no arguments.
>
> Please do :)
>
> If you start working on it, please assign the ticket to you:
>
> http://trac.cython.org/cython_trac/ticket/696
>

Ok, I'll do this if I start.

>
>> The problem is where to store __class__, I see two options here:
>>
>> 1. Add func_class member to CyFunction, this way __class__ will be
>> private and not visible for inner functions:
>> 2. Put it into closure
>
> The second option has the advantage of requiring the field only when super()
> is used, whereas the first impacts all functions.
>
> I would expect that programs commonly have a lot more functions than
> specifically methods that use a no-argument call to super(), so this may
> make a difference.
>

So, now classes are created the following way:
(Continue reading)

Stefan Behnel | 5 Jul 10:04 2011
Picon

Re: [Cython] PEP 3135 -- New Super

Vitja Makarov, 05.07.2011 09:17:
> 2011/7/5 Stefan Behnel:
>> Vitja Makarov, 05.07.2011 08:21:
>>> I was thinking about implementing new super() with no arguments.
>> http://trac.cython.org/cython_trac/ticket/696
>>
>>> The problem is where to store __class__, I see two options here:
>>>
>>> 1. Add func_class member to CyFunction, this way __class__ will be
>>> private and not visible for inner functions:
>>> 2. Put it into closure
>>
>> The second option has the advantage of requiring the field only when super()
>> is used, whereas the first impacts all functions.
>>
>> I would expect that programs commonly have a lot more functions than
>> specifically methods that use a no-argument call to super(), so this may
>> make a difference.
>>
>
> So, now classes are created the following way:
>
> class_dict = {}
> class_dict.foo = foo_func
> class = CreateClass(class_dict)
>
> So after class is created I should check its dict for CyFunction
> members (maybe only ones that actually require __class__)
> and set __class__:
>
(Continue reading)

Vitja Makarov | 5 Jul 10:37 2011
Picon

Re: [Cython] PEP 3135 -- New Super

2011/7/5 Stefan Behnel <stefan_ml@...>:
> Vitja Makarov, 05.07.2011 09:17:
>>
>> 2011/7/5 Stefan Behnel:
>>>
>>> Vitja Makarov, 05.07.2011 08:21:
>>>>
>>>> I was thinking about implementing new super() with no arguments.
>>>
>>> http://trac.cython.org/cython_trac/ticket/696
>>>
>>>> The problem is where to store __class__, I see two options here:
>>>>
>>>> 1. Add func_class member to CyFunction, this way __class__ will be
>>>> private and not visible for inner functions:
>>>> 2. Put it into closure
>>>
>>> The second option has the advantage of requiring the field only when
>>> super()
>>> is used, whereas the first impacts all functions.
>>>
>>> I would expect that programs commonly have a lot more functions than
>>> specifically methods that use a no-argument call to super(), so this may
>>> make a difference.
>>>
>>
>> So, now classes are created the following way:
>>
>> class_dict = {}
>> class_dict.foo = foo_func
(Continue reading)

Stefan Behnel | 5 Jul 10:49 2011
Picon

Re: [Cython] PEP 3135 -- New Super

Vitja Makarov, 05.07.2011 10:37:
> 2011/7/5 Stefan Behnel:
>> IMO, the main reason for the heuristic is to prevent class objects from
>> being kept alive by their methods, except for the single case where super()
>> is used. Keeping a class alive just because one of its methods is still used
>> somewhere can be very costly, depending on the content of the class dict. It
>> also creates a reference cycle, which is another costly thing in CPython as
>> it requires a GC run over the whole class dict to get cleaned up.
>>
>> The situation for modules is at least slightly different, as modules do not
>> tend to get unloaded, so there's always a reference to them from
>> sys.modules. If that ever gets removed, it's really ok if it takes time to
>> clean things up.
>
> Yes, but I hope that classes are rarely deleted.
> And I'm afraid that we can't avoid cycles when implementing __class__
> for pure-python classes.

As I said, it's fine if super() is used, but not otherwise. Basically, 
no-args super() is just a shortcut for "super(TheClass, self)", with the 
difference that the long form looks up the name at runtime, whereas the 
short form keeps a reference to the type at module setup time. So, both 
need the class at runtime, but have different characteristics otherwise.

(but if the code is not using super(), there is no need to have the methods 
own a reference to their class)

Stefan
Robert Bradshaw | 5 Jul 23:31 2011

Re: [Cython] Hudson is down?

On Mon, Jul 4, 2011 at 9:12 PM, Stefan Behnel <stefan_ml@...> wrote:
> Vitja Makarov, 04.07.2011 20:43:
>>
>> It seems that hudson server is down.
>
> It's back now. Looks like the sage.math machine was restarted.

Yep, sage.math was restarted. Thanks for getting this back up and running.

- Robert

Gmane