Just to emphasize (though I’m sure you know this): in Python this is solving a non-problem, since you have to opt in to modifying globals - as Python has different rules for determining variable scope (link is to my Stack Overflow answer for a question on the topic).
2 Likes
With extra benefit of no import!
And the disbenefit that if you decide to change its logic you have to ferret out all the individual uses and update each one. I’m sure I read somewhere that’s a bad idea.
Why? Could you give an example?
nice.
Why? Could you give an example?
OK, suppose you start using the simple one-line definition, that you use in 150 files across your product. Later you discover that you need a more complex case (for example, one that cna handle zero-argument functions).
If you’ve imported the functionality, you can make the fix by editing the imported module, once. If you’ve used copy-and-paste then you have 150 edits to do (or you have to start thinking about whether each of 150 cases needs updating, and then edit those).
Have I made my meaning clearer?
1 Like
No, you are talking hypothetically.
With no reference to how this could apply to this specific case.
Obviously, take a valid starting point. There is a one-liner that can handle 0 and non-0 argument functions and destroy the function or leave it in place.
What other functionality additions are possible?
What could be the case that all such functions had to be updated across the library?
What could be the case that all such functions had to be updated and the best solution was to wait for the update in stdlib?
If you want to repeat yourself that way I’m happy to let you suffer the consequences.
It is you who replied to me and now trying to avoid inspection of quality of your words.
If you at least refrained from patronising comment at the end I wouldn’t have bothered.
To add:
Unless you are new to python and concept of factoring the code out where appropriate is not obvious to you. In this case, let me know, I will “suffer” the consequences accordingly.
Are you referring to Steve’s attitude that you’re welcome to repeat yourself, even though it isn’t what he would do? That doesn’t strike me as “patronising”; that’s just the acknowledgement that everything said about “best practice” is advice, not rules. I could tell you “hey, it’d make your code SO much easier to read if you use proper variable names” and you could say “nah, I like using a, b, c, d etc”. That’s fine. Nobody’s stopping you; you’re the one who’d suffer as a result of that decision, not us (and by “suffer”, I mean that debugging the code in the future will be harder, not that you’ll be punished by the community in any way).
Python has a wide variety of tools to allow you to reuse code rather than copy/paste it. But hey. If you would prefer to copy/paste, that is entirely your decision. There are a ton of little utility functions that I haven’t put into a library, because I end up wanting subtly different versions of them in different projects, so the most convenient approach is to copy/paste and then adjust as needed. (As mentioned, there are already two incompatible ways of defining the @invoke decorator’s return value.)
BTW, please don’t keep editing your posts in this way. You can post another followup, and that way, people don’t have to go click the pencil to see what you actually edited - particularly problematic for people who read the emailed version, and only get sent one copy.
1 Like
I was (still am) annoyed at the initial reply and completely misinterpreted that statement. I apologise for that.
Will adjust accordingly.
1 Like
I apologise for the snarkiness of my last comment, which was unnecessary. I doubt I’m newer to Python than you are. My intent was to suggest that in your code you may do as you wish, as will I in mine.
1 Like
@lnxpy , I haven’t read the whole discussion, but google just showed me a third-party package that you might be interested in invoke-iife · PyPI .
But I’m not sure if that’s what you wanted.
2 Likes
Thank you, but it’s doing almost the same thing that I just showed in the very first comment. You can check it here: iife-py/src/iife/__init__.py at 8885ac1b53bbc10ed4fd943553f128568a739866 · torshepherd/iife-py · GitHub