Generate parameterized __init__ for meta model classes about pyecore HOT 15 CLOSED

I am on it. Expect PR within the next couple of days.

from pyecore.

Oups, really sorry about the push...

If the shadowing is a result of the name attribute, it is not an issue. The name, nsURI, eClassifiers...etc comes directly from the ecore metamodel which defines these EAttributes/EReferences for EPackage, they are not constant per say and tries to keep the EMF name. The logic of the static code generator is to give an instance level as well as a meta level in once. To do this, the mapping applied is:

• EClass -> Python class + metaclass
• EPackage -> Python package + module

For example using the library metamodel:

>>> import library  # We import the equivalent of the 'library' EPackage
>>> library.name
'library'
>>> library.nsURI
'http://emf.wikipedia.org/2011/Library'
>>> library.eClassifiers
{'Book': library.library.Book,
 'BookCategory': BookCategoryEOrderedSet([ScienceFiction=0, Biographie=1, Mistery=2]),
 'Employee': library.library.Employee,
 'Library': library.library.Library,
 'Writer': library.library.Writer}
>>> library.Book.title  # We access the Book 'title' EAttribute
<EStructuralFeature title: EString(str)>
>>> book = Book(title='test')  # We create an instance
>>> book.title  # We access the value of the attribute using the classic way
'test'
>>> book.eGet(library.Book.title)  # But we also can access it using reflection
'test'
>>> book.eGet('title')  # Also works, but in the call above, you have more meta-details about your 'title'
'test'

This 'layer' eases reflection/generic algorithms and allows you to easily work/deal with the meta level when the static code is generated.

So, as these EAttribute values defined in the module will never be used in the generated metaclasses the shadowing in the attributes init of the metaclasses cannot occurs as they does not represent data that would be handled by the metaclasses or their instances (however, you're right this is not very Pythonic).

Anyway, thanks again for this awsome new feature in the generator. I think I will prepare a new release tomorrow in the morning and communicate about it on monday.

from pyecore.

Just to clarify: the code completion is obviously done by the IDE, which simply finds and interprets standard __init__... Nothing specific here for pyecore.

from pyecore.

I think, that's a terrific idea! The purpose of the generated code was to give you the ability to create/modify the __init__() as you wish, but your proposal is so much better. I often forgot that we are not in Java and that default parameter value exists.

In your code, the only thing that I would change is the affectation of an EAttribute from:

self.name = name or None

To simply:

self.name = name

as the ... or None would prevent the empty string to be assigned as name (even it has no realy purpose here, perhaps an empty string could be useful in some case) or it could prevent an integer attribute to be set to 0.

I was also a little bit worried about the __init__() parameter size when big meta-classes hierachies are defined, but, hey, it is generated code, it should propose flexibility to the end-user. Long story short, I totally love your idea!

from pyecore.

Thanks for the positive comments. Regarding the long initializer lists in case of large hierarchies I'd follow Hettinger's pattern, https://rhettinger.wordpress.com/2011/05/26/super-considered-super/amp/

This is also the way it's been done in django's classes and mixins. It plays nicely in presence of multiple inheritance as well.

So I'd give it a try then.

from pyecore.

I was not aware of that way of handling large __init__(), thanks for the link and thanks a lot for your proposal/work Mike, I really appreciate.

from pyecore.

Thanks a lot Mike!

from pyecore.

Finally, following your PR, I have generated the 'library' metamodel code for the tests. I also added some quick tests on it, everything's fine.
I really love the flexibility the new generated code gives. I code with the atom editor with only few Python plugins, and the result is very pleasant.
I think I will release a new version by the end of the week, and directly bump the version to '0.2.0'.

Thanks again Mike, that's a great addition to PyEcore!

from pyecore.

I just added another test for the unknown attribute case, see PR.

When looking at using code and the tests I increasingly get the feeling I should get rid of the trailing underscore for the argument names. The reason I did it was to prevent shadowing existing names (I got linter warnings). However, for users the underscore is just weird and technically, shadowing is not an error as the its well-defined that the most local name will be used in all cases. So unless you object I would remove the underscore from generator and test cases. I'll do this throughout the day probably.

from pyecore.

I agree, I was not so much disturbed by the underscore, but when reading again the code, it feels a little weired.

from pyecore.

I'll fix that soon and then close this ticket.

from pyecore.

Thanks so much Mike, I'm sorry, I have little time this morning to do it myself...

from pyecore.

Mike, I hope you don't mind, but I had time this morning and I removed the underscore from the generated code/generator. If the result is what you expected, I will close the ticket.

from pyecore.

I don't mind at all. I was about to merge it, when I got conflicts, because you were first... :-) Thanks.

I dug a bit into the resulting name collisions. This mainly affects the name attribute of some of the generated metaclasses, which shadows the package name attribute. In general Python constants should be all capitals. That would indeed prevent the shadowing altogether. Would this be an option for name, nsURI and so on? They are indeed constants, aren't they?

from pyecore.

Tested with my model, looking great, btw.

from pyecore.