Property or method?

Ahh you seem to be thinking like a developer :wink: - you want to understand the implementation! In my view, one use of OOP is to abstract the implementation away from the object model. As such, something which seems like an attribute can behave as an attribute even if the getter and setter are implemented as methods…

That potentially gives a more logical object model at the expense of some potentially unexpected hidden behaviour. The art of the api design is in elegantly reconciling the two… … probably using property as sparingly as possible:)

Of course the original PEP puts it far better than I could:

hmm :roll_eyes: is every class in fact a dictionary?

Every class has a __dict__ :

https://docs.python.org/2.7/library/stdtypes.html#object.dict

So I guess as long as the key is hashable, it is OK to use. But, by accessing __dict__ directly, you bypass the ‘write only-ness’ implemented in your override of __setattr__. As others have noted, I don’t think there is any real way to protect something in python.

In your example, I think you lost an indent on the else, but, if the purpose is to not allow foo.readonlyattr or foo.readonlyattr2 to be written to, and allow anything else, then:

class Foo:
    def __setattr__(self, name, val):
        if name == 'readonlyattr':
            raise TypeError('protected attribute "readonlyattr" cannot be written')
        elif name == 'readonlyattr2':
            raise TypeError('protected attribute "readonlyattr2" cannot be written')
        
        self.__dict__[name] = val
        

foo = Foo()
print foo.__dict__

try:
    foo.some_other_attribute = 'some_other_value'
except Exception as exp:
    print exp

print foo.__dict__

try:
    foo.readonlyattr = 'readonlyattr_value'
except Exception as exp:
    print exp

print foo.__dict__

try:
    foo.readonlyattr2 = 'readonlyattr2_value'
except Exception as exp:
    print exp
    
# Accessing __dict__ directly bypasses __setattr__

foo.__dict__['readonlyattr'] = 'bypassed'

print foo.__dict__

In your example’s else block, using “name” for the key should be just name, as you want the name variable passed in, not the string “name”. In the note, if you use str(name) then if the variable name has a __repr__ or __str__ method then I guess it would work, but I would just pass in the name variable directly and trust that dicts will be able to find a hash-able representation. If not you will get an exception, I think.

I‘m not sure if I understand you right, but I indeed see the abstraction benefit in properties. Out of question, but I just think its not well implemented in Python. My argumentation is that a bad implementation doesn‘t give you a real benefit, since the cost of the extra code involved doesn’t wage against the abstraction benefit. I do daily programming with mostly C# and I indeed use more properties then class variables in my code. But the reason I do so, is because in C# it hardly makes any difference, and my code keeps clean and readable. I have worked with a couple of Python apis using get and set methods instead if Python properties and it was no disadvantage working with it all.

Correct. But not only in Python, actually I don‘t know any language where protecting works! Access modifiers are mechanisms to define a scope of code elements. This is rather a way to mark which elements can be modified from outside and which should not, but its by far any true restriction or a security feature. Some languages may indeed need some deeper knowledge for bypassing access limitations, which is good. But storing a password in a private field is almost always a bad idea. Thats also why many language completely leave access modifiers out of their repertoire. And Python is just one of them.

Aight, this question was really noob question, but you brought up some topics I don’t get.

What did I understand:

  • Don’t try to learn C# using Python (IronPython).
  • Properties in C# are weird using {} just like methods but methods have () as well.
  • C# weirdly calls variables fields :man_facepalming:
  • People don’t use underscores in front of object names to avoid name conflicts. These are “private” stuff. I guess also called “builtins” cuz I read if you from someClass import * you won’t get them.

I don’t want to use c# because I want something that can be run without compiling, something that is portable or can run in portable environment or portable IDE. I literally try to code whenever and it is easier if I put the IDE or environment on the cloud and sync it to every machine. (This is how I work with CPython and IronPython). C# requires VS or similar and that is not portable. I have sharpdevelop portable but it’s version 4 and I mainly use it to create IronPython WinForms.

Is there version of C# that is in fact a scripting language?

You should learn many languages. Just remember that each language has its own mechanics, and possibly some own jargon. Learn especially languages from different paradigms so you get an insight in problem solving using different techniques

Weird being a quite subjective take on the topic.

Variables are still variables in many places. Instance variable members are called fields. That is just a different way of saying the same thing.

You don’t need Visual Studio per se. You need a C# compiler (maybe Roslyn works) and a text/code editor (Visual Studio Code - can be used portable).

2 Likes

I just recently posted on how to run C# scripts from vs code in Rhino (an editor working on linux and ios as well) .Mono is a platform independent version of the dotnet framework, which can be used from other operating systems as well.

this approach may also work with little tweaks within Grasshopper.

Same goes for .NET core now

yes right, I think the newest version of core even integrates forms and wpf. Or at least they are planning to do so.

Hey, I remember the monkey, I installed it once seeking portability, but I did not find gui application and I ditched it :smiley:.

I thought .Net core is a single dll file :thinking:

.NET core is a framework for compiling .NET code and executing it. This is similar to CPython 3.7 being the framework that you use for executing python code. Frameworks typically involve many DLLs.

Rhino for Windows currently runs the .NET Framework which is a Windows specific framework. Rhino for Mac currently runs a Mac specific compile of mono for the framework to run .NET code.

.NET Core is Microsoft’s latest work in the “.NET universe” and will probably be the framework that Rhino runs on top of at some point in the distant future.

I believe the WPF and WinForms integration is part of their .NET 5 roadmap

2 Likes

Is it a big task to switch over to .net core?
How distant is that future?
Does the switch affect the current usage of IronPython?
What I mean is will my current scripts work with Rhino when it switches to .net core?

The technology doesn’t even exist yet for what we would need to switch. This is way off in the future and would not have an effect on your work.

Edit: we are not switching over to .NET core during V7 development and will re-evaluate when we get around to working on V8.

2 Likes

It would mean that the overcomplicated Eto framework will be obsolete and being replaced with WPF, which is the better GUI framework in my opinion. The problem with WPF is thats its Windows only, but .Core allows you to be platform independent.
Using WPF with the MVVM pattern lets you extremly fast build reliable gui apps, since everything except the XAML part is fully testable. XAML is the language used to setup your gui, XML like HTML/CSS.
IronPython is legacy code, not being develloped further. I think Microsoft doesn’t plan to integrate CPython, So I think this will be a problem. But maybe building a CPython Rhinocommon_c.dll wrapper would solve it in multiple ways. You could use latest Python, with all libraries and you can work with Rhino Api. But I have no idea if this is planned at McNeel at some degree.

I don’t think that is going to be the case. I haven’t seen any mention of a cross platform version of WPF. The blog only mentions that you will be able to use WPF on your Windows version of .NET compiled code. Also, remember Eto is just a layer on top of WPF on Windows and a layer on top of Xamarin.Mac (cocoa) on Mac

Didn’t know this. Ok so there is probaly no real benefit at all. I mean if you develop a Windows App, where is the problem to install the Dotnet framework?!

Edit: okay they speak of performance optimisation and more modern software architectecture. Probaly the finally integrated ioc-containers etc.

Amen to that. I want to see that happen sooner.