Python has less of a problem here since it represents object data using a
dict internally – when you reload a class, the representation of objects
doesn't change. Still, if adding or removing fields in Python classes works
at all, that's an interesting data point.

On Fri, Feb 5, 2016 at 5:24 AM, Andras Niedermayer <[email protected]>
wrote:

> class X(object):
>     @property
>     def y(self):
>         try: return x.__y
>         except AttributeError: return "default value for y"
>
> x = X()
> print x.y
>
>
>
>
>
> On Friday, February 5, 2016 at 11:22:17 AM UTC+1, Andras Niedermayer wrote:
>>
>> The IPython autoreload extension does something quite similar to what has
>> been discussed here (
>> https://ipython.org/ipython-doc/3/config/extensions/autoreload.html ).
>> There are cases where it's actually very convenient, e.g. if you have
>> results from a long-running calculation in an IPython notebook interactive
>> session and you notice that you should change one of the classes, but don't
>> want to rerun the whole calculation.
>>
>> Some of this one gets almost for free in Julia with the Autoreload.jl
>> package, since methods are outside of types in Julia, so there's no need to
>> search for all object of a modified type in memory and add/modify the
>> methods like in Python. (Modifying inlined methods is a bit of a problem,
>> but one could probably extend Autoreload.jl to inject @noinline into
>> modules.)
>>
>> Adding fields would only be possible in Julia if it were possible to
>> overload field access ( https://github.com/JuliaLang/julia/issues/1974
>> ).
>>
>> That's essentially the way one does this in Python. You add a property
>> getter y to class X, which allows you to access x.y:
>>
>> class X(object):
>>
>>
>>
>>
>> On Friday, February 5, 2016 at 8:17:47 AM UTC+1, Tomas Lycken wrote:
>>>
>>> My main concern is predictability.
>>>
>>> Imagine that I define a type Foo and start playing around with it -
>>> define some functions that work on foot, perhaps one or two types that hold
>>> foos, and manipulate a bunch of Foo instances.
>>>
>>> Then, I redefine the Foo type - say, I add a field. Which of the other
>>> things that I have defined are still valid?
>>>
>>> If I understand the motivation for this feature correctly, it's to make
>>> exploratory programming easier. However, I think it would actually make it
>>> a lot more difficult - it would basically give you a bazooka so heavy that
>>> the only thing you can reasonably aim at is your own foot...
>>>
>>> //T
>>>
>>>

Reply via email to