Re: [Pyobjc-dev] @python_method rationale?

[Marc V. O. <ma...@ac...>]

Just,

My thoughts on this:

I have been doing PyOBJC for about 8 years because the previous team started the project like this and they created like 600 files/classes…
So this exception was introduced about a year ago, so it took me 1 day to upgrade the source code, but with this I found like a dozen of mistakes of misnamed methods.

1. So personally I prefer this approach, because it finds errors early, just as the editor with integrated PEP 8 linter finds typos early… I would regret if this functionality would go away.
2. Usually when I have a lot of python methods, this usually goes in a separate python class, with python naming conventions, and the PyObJC class is more like an interface that hides this python class. Just as Model-View-Controller… where the View in this case is the PyObjc class.

Maybe for you there should be a kind of "class decorator/flag" that you don’t care about it for this class.

best

Marc




> On Mar 11, 2018, at 3:42 AM, Just van Rossum <jus...@gm...> wrote:
> 
> Hi,
> 
> I’m curious about the rationale of the @python_method decorator from the objc module.
> 
> In current PyObjC versions any method in an NSObject subclass that does not conform to the ObjC conventions need to be decorated with @python_method. I understand this means such methods can’t be called from ObjC.
> 
> The thing is, when I’m writing Python code, I am well aware of what will be a valid ObjC method and what won’t be. I write lots of methods that I know will never be accessed from the ObjC side, and I’m fine with that. I want to write Pythonic code, so I have no interest in using ObjC selector naming conventions for such methods. Yet my code is now necessarily littered with @python_method decorators, which feels clumsy and ugly, and goes against the point of wanting to write clean Python code that does _not_ use the ObjC naming conventions. I’m currently looking at a page of code containing seven methods, _all_ of which have the decorator, which makes me sad :)
> 
> I long for the “old” days when these things “just worked”, and there was simple and clean code on the Python side.
> 
> If I omit the decorator, an exception is raised: objc.BadPrototypeError. So PyObjC already knows that that method is not conforming.
> 
> I feel this is a case of “explicit is better than implicit” going too far.
> 
> Maybe I’m missing something, but how is the @python_method decorator actually solving problems? So far it’s only gettin in my way.
> 
> Thanks for any insights,
> 
> Just
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev