-
-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal for nicer init() #26
Comments
Pythonista's This would also be a good use case for PEP 468's order-preserving keyword arguments, which are available as of Python 3.6. Ordered keyword arguments are not necessary for this feature though, they are just an optimization - on older Python versions, the correct method name would need to be guessed, by trying every possible permutation of the keyword arguments, until a valid method name is found. |
Completely agreed that this sounds like a good idea - it's just a matter of implementation. Since argument order isn't guaranteed (until Python 3.6, anyway), that means the lookup process will be (a) O(2^n) complexity for the number of arguments, and (b) potentially ambiguous, because the method I'm not sure if the latter will be a problem in practice - and it becomes a non-issue under Python3.6 - but it's worth keeping in mind. There's also a minor issue of how |
To keep it simple at first, maybe it would be good to require |
Quick update - I've played around with this a little and implemented a basic version of this feature (in my local copy of the repo). The current implementation is not very good though. Right now, when any nonexistant attribute is accessed on an As a (hopefully better) alternative I'll try caching all instance methods when an |
Okay, PR has been made. The way I implemented it now uses sets as dictionary keys to look up the method for a set of kwargs. This doesn't depend on PEP 468, so it should work equally well on all Python versions. I haven't tested the performance of the new syntax much, but the unit tests run in about the same time as before, so hopefully it shouldn't affect the speed of existing code much. |
So, now that PR is merged, what's the new way to do the following?
Or are we not there yet? |
@dimaqq The call would be:
The first argument is always a positional argument; all subsequent arguments are keywords. |
Oh, cool, I didn't realise that. Would be nice to have that documented :) Here's what I can do now (it works, I hope I understood why): - rv = view.dequeueReusableCellWithReuseIdentifier_forIndexPath_("knob", path)
+ rv = view.dequeueReusableCellWithReuseIdentifier("knob", forIndexPath=path) |
Documentation is definitely needed (but that's true of most of Rubicon...) - but AFAICT, this has now been implemented. If I'm mistaken, please re-open this ticket. |
Reopening this for now - there are two suggestions from the OP that are not yet supported:
IMHO both of these would be good to have as they would make object creation shorter and more readable. This is also basically what Swift does when it imports |
For the >>> ObjCInstance(ptr) # Wrap a Objective-C object
>>> NSObject(...) # Create a new instance of NSObject
>>> NSObject(ptr) # Currently allowed, but not allowed in this idea |
The potential issue with what you've described is that when you wrap an ObjCInstance, you likely want to preserve the Python details of the class you're wrapping. This might be possible with the approach you've described, but it's firmly in the space of "provide at least a prototype implementation that works, not just a hypothetical potential syntax". Personally, I suspect any movement on this issue will require a resolution to #70. |
Do you mean to make |
I mean that, at present, an instance of ObjCClass is an ObjCInstance, not a "type". Untangling the hierarchy of relationships between ObjCClass, ObjCInstance, and |
Indeed, this currently seems to be weird a bit. class ObjCInstance(metaclass=ObjCClass):
... Then, |
That is a possible end state; whether that end state is desirable is another question. What we have currently is another end state - one that we know works. This is why I made my comment about needing a prototype - this isn't a conversation that will be improved by hypothetical discussions about possible syntax unless those discussions also include prototype implementations that demonstrate that the proposed syntax is actually possible in practice. |
Thank you so much! Now I could understand what you were saying. I will keep this in mind as a future issue. |
Through trial and error I got following to pass:
Wouldn't it be nice to get that data from call signature:
And then, perhaps, move to:
The text was updated successfully, but these errors were encountered: