Lang: Python module for enforcing programming language constraints
1–10 of 21 posts
Re: Lang: Python module for enforcing programming language constraints
#2This will add some overhead for every single call to such wrapped function. If you use that extensively for many classes, won't that be a huge performance degradation?
It would maybe be nice to have a flag so that these wrappings apply only in test or debug mode.
Also, it works e.g. by using `inspect.currentframe().f_back.f_back`. I'm not sure if that is such a clean and stable solution. (See e.g. here: https://github.com/amitassaraf/lang/blob/master/src/lang/acc...) E.g. when you add other wrappers around your function, I'm quite sure that this would break.
Re: Lang: Python module for enforcing programming language constraints
#3This is an impressive library, but I don't really see the usefulness. That is either because I'm a Python programmer, and Java semantics aren't useful in Python, or because I'm a Python programmer, and I haven't used Java semantics, so I wouldn't know.
I can say, though, that I've never had problems with something accessing private variables that it shouldn't have. The meaning of private variables in Python isn't "don't access anything that starts with an underscore", rather it's "you're accessing these variables at your own risk".
This "we're all adults" model has worked out very well for my use cases. Can anyone share a few cases where hard constraints here would be beneficial?
Re: Lang: Python module for enforcing programming language constraints
#4I feel like this is the most anti-pythonic thing I've ever seen.
Re: Lang: Python module for enforcing programming language constraints
#5This makes me a little sad. So, a few observations:
- The use of metaclasses for (almost?) every feature in this library makes it prone to metaclass conflicts. What if I want to inherit from two classes that use two different features from the library?
>>> class MetaOne(type):
... pass
...
>>> class MetaTwo(type):
... pass
...
>>> class One(metaclass=MetaOne):
... pass
...
>>> class Two(metaclass=MetaTwo):
... pass
...
>>> class Both(One, Two):
... pass
...
Traceback (most recent call last):
File "", line 1, in
TypeError: metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases
- And when they're not, there's __name_mangling, which is sufficient to avoid the need for a 'final'. Compilers can make use of 'final', which is why final exists in Cython. I'm not sure the purpose in pure Python.
- There's no need for the distinction between an Abstract class and and Interface. Python already supports multiple inheritance of abstract classes.
Re: Lang: Python module for enforcing programming language constraints
#6This is an impressive library, but I don't really see the usefulness. That is either because I'm a Python programmer, and Java semantics aren't useful in Python, or because I'm a Python programmer, and I haven't used Java semantics, so I wouldn't know. I can say, though, that I've never had problems with something accessing private variables that it shouldn't have. The meaning of private variables in Python isn't "do…
It feels like it might work better used as a test/verify step, but doesn't have the mechanics to be toggled on and off easily.
I can see the value in quickly knowing if new code is mucking with private/protected properties.
Re: Lang: Python module for enforcing programming language constraints
#7This is an impressive library, but I don't really see the usefulness. That is either because I'm a Python programmer, and Java semantics aren't useful in Python, or because I'm a Python programmer, and I haven't used Java semantics, so I wouldn't know. I can say, though, that I've never had problems with something accessing private variables that it shouldn't have. The meaning of private variables in Python isn't "do…
It feels like it might work better used as a test/verify step, but doesn't have the mechanics to be toggled on and off easily. I can see the value in quickly knowing if new code is mucking with private/protected properties.
> I can see the value in quickly knowing if new code is mucking with private/protected properties.
Would this do it?
re.findall(r'(?Re: Lang: Python module for enforcing programming language constraints
#8I feel like this is the most anti-pythonic thing I've ever seen.
This _is_ the most anti-pythonic thing I've ever seen.
Re: Lang: Python module for enforcing programming language constraints
#9Earlier quoted context omitted.
It feels like it might work better used as a test/verify step, but doesn't have the mechanics to be toggled on and off easily. I can see the value in quickly knowing if new code is mucking with private/protected properties.
> I can see the value in quickly knowing if new code is mucking with private/protected properties. Would this do it? re.findall(r'(? Anytime you're using ``obj._foo`` and it's not ``self._foo`` that suggests you're mucking about with the internals of an object that the author didn't expect you to use.
That would miss some things, like iteration of all properties without a direct reference, subclasses accessing _Parent__private stuff, etc.
I'm not actively looking for a solution, just noting this might be more well received if you could easily turn it off and on.
Edit: Again, not looking for solutions. I thought the feedback of being able to turn it on/off might be useful for the OP.
Re: Lang: Python module for enforcing programming language constraints
#10An impressive effort. Nonetheless, I feel like it would be better to warn about these things via static analysis rather than enforcing at run time.