[Rivet] [Yoda] cython version issue

[David Grellscheid]

Hi again,

Cython 0.24 is still not usable. The blocker that we can't work around 
right now is described in https://github.com/cython/cython/issues/1465

Until this gets fixed, we're stuck with 0.23.x. I'll push the alias 
removal anyway, since right now we're already inconsistent about which 
classes have the aliases available and which don't.

See you,

   David



On 20/09/2016 11:08, David Grellscheid wrote:
> Hi Andy,
>
> The @property decorators themselves don't need to go, it's purely the
> aliasing that causes the issue, and given that the aliases have already
> been marked as 'todo remove' in some places and aren't even there on
> some other classes, the consistent thing is indeed to just get rid of them.
>
> Once I do that, however, another unrelated v24 change throws us off:
> cython now wants to have default constructors for all classes where we
> overload __add__ and __sub__. I'm still looking into it.
>
>   David
>
>
> On 20/09/2016 10:36, Andy Buckley wrote:
>> Hi David,
>>
>> I think this opens the question of what we want the YODA Python API to
>> look like.
>>
>> When Dave Mallows originally wrote it, he decided to make the Python API
>> "Pythonic", i.e. using @property, changing interfaces to make use of
>> multiple/tuple returns, etc. This is nice in some ways, but also
>> confusing because the C++ and Python interfaces are not quite the same.
>> If I remember correctly, those aliases are not so much for backward
>> compatibility as for "Pythonic compatibility".
>>
>> My feeling is that while I like Pythonic code, it will be easier and
>> simpler for users if we can move to the Python API being as close as
>> possible to the C++ one. There are quite a few places where being able
>> to pass arguments (e.g. a bool for including overflows) to attributes
>> that are currently arg-less properties would be useful. And hopefully we
>> can make the C++ interface elegant enough that the Python one can be,
>> too. It can't be an exact clone, due to function overloading/multiple
>> dispatch, but we can get pretty close.
>>
>> So... on that basis I would not mind ditching these convenience aliases.
>> All-lower-case attrs are more Pythony, but this is just cosmetics and
>> the Zen does say "there should only be one way to do it". But we should
>> bump the version to 1.7.0 to indicate the maybe breaking change. Other
>> thoughts? Migrating away from @property accessors is going to be a
>> harder thing to do, so I'd like to hold that back until a bigger
>> structural revamp in YODA2 (if we ever get the time to do that...)
>>
>> Does *Rivet's* Cython interface make use of any aliasing like this, or
>> does the block on Cython 0.24 solely come from YODA?
>>
>> Thanks for grasping the nettle ;-)
>> Andy
>>
>>
>>
>> On 20/09/16 09:18, David Grellscheid wrote:
>>> Hi again,
>>>
>>> the fix is quite simple, but which option do we want to take:
>>>
>>> (1) keep the backward compatibiltiy overloads like 'stddev = stdDev' for
>>> another version cycle
>>>
>>> (2) abandon it now, and only keep the new names, i.e. stdDev
>>>
>>> If I don't hear strong objections today, I'll commit version (2), we can
>>> revert any time of course.
>>>
>>> See you,
>>>
>>>   David
>>>
>>>
>>> On 20/09/2016 07:37, David Grellscheid wrote:
>>>> Hi Andy,
>>>>
>>>> On 19/09/2016 18:37, Andy Buckley wrote:
>>>>> I think there's a problem now that *getting* 0.23.5 is a bit
>>>>> awkward. In
>>>>> the bootstrap script I specifically download this:
>>>>
>>>> For end-users, it's still okay: 'pip install cython==0.23.5' works so
>>>> far.
>>>>
>>>>> Yes, this sucks. Do we know if this bug has been *reported* to Cython?
>>>>
>>>> It's on their tracker, but the discussion is one of those where people
>>>> don't agree it's actually a bug. I'll try to find the ref.
>>>>
>>>>   David
>>>> _______________________________________________
>>>> Yoda mailing list
>>>> Yoda at projects.hepforge.org
>>>> https://www.hepforge.org/lists/listinfo/yoda
>>> _______________________________________________
>>> Rivet mailing list
>>> Rivet at projects.hepforge.org
>>> https://www.hepforge.org/lists/listinfo/rivet
>>
>>
> _______________________________________________
> Rivet mailing list
> Rivet at projects.hepforge.org
> https://www.hepforge.org/lists/listinfo/rivet