Re: More efficient/elegant branching
Hello Neil, thanks for the detailed answer. Question: are there other people/factors who/which should be regarded as more important than the linter's opinion? Yes. Mine. I was just puzzled at the linter's output (took me a while to figure out what it actually meant), and that got me started on the track if there was maybe a more Pythonic way of dealing with that decision chain. The usual dictionary-controlled construct I've seen (and used) involves using functions as the dict's values: [...] Yeah, I do that a lot, too, but for that you need a meaningful "key" object. In the case at hand, I'm really using individually formulated conditions. Is it ironic that the language does not have a form of case/switch statement (despite many pleas and attempts to add it), Wouldn't do me any good here because case/switch also compares a fiked key against a bunch of candidates, like a dict. Also, in terms of line count the if/elif chain isn't worse than a switch statement. yet the linter objects to an if-elif-else nesting??? Like I said, that's what got me started on this. And it's not even nested, it's purely linear. One reason why this code looks a bit strange (and possibly why PyLint reacts?) is because it is trivial. When we look at the overall picture, the question becomes: what will the 'mainline' do with "result" (the returned value)? Immediately one suspects it will be fed into another decision, eg: No, the "result" is a text message that actually means something and is eventually output for human consumption. The whole thing is rather academic. Also my efficiency argument doesn't hold water because this routine is executed just a few times per hour. I like the "condition table" approach for its lower line count but I'll stick with if/elif because it's more conventional and therefore easier to understand for the casual reader. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python3 - How do I import a class from another file
Am 10.12.2019 22:29 schrieb Chris Angelico: And once again, you are maintaining your assumptions despite being very clearly shown that they are wrong. "del instance" does not directly call __del__ any more than "instance = 1" does. You HAVE been shown. Much of the confusion in this thread comes from the murky distinction between "garbage collection" and "memory management." I wouldn't call a reference-counting system "garbage collection" per se. Another bone of contention seems to be the question exactly WHEN reference counting and/or garbage collection release an object's resources (give it back to memory management). I read the word "when" in the non-implementation-specific Python docs as "immediately upon" (quote below, caps by me): "Note: del x doesn’t directly call x.__del__() — the former decrements the reference count for x by one, and the latter is only called WHEN x’s reference count reaches zero." It is then up to Python's memory management (PyMem_Alloc et al in CPython) what to do, and when: Give it back to the OS, keep it around for later use, whatever. -- https://mail.python.org/mailman/listinfo/python-list
Re: Clarification on Immutability please
Am 27.01.2020 15:23 schrieb Chris Angelico: The way execution works in Python, you first evaluate the object, then assign it to the target. The new object HAS to exist before the old one is replaced. There's no such thing as "atomic reassignment" that simultaneously destroys the old object and assigns a new one. The slicing will always happen first, and then the assignment. Hi Chris, I agree that that is how it's done because it makes sense. My completely academic question is this: If the Python compiler sees that the operation effectively just chops a few items off the end of a tuple which will be immediately discarded I can't see an issue with an implementation simply shortening the length of the tuple. In C this would be an ultra cheap operation, and the pointer to the tuple object (CPython's object ID) would indeed not change. A possible drawback would be waste of memory because the unused tuple items are still around in allocated memory. The introductory comment in tupleobject.h is clear on this subject: "[...] C code can change the tuple items (but not their number) [...]", so this is not how it's done in CPython 3.8.0, but IMO an implementation could legally do this. All this is beside the point of the OP's question. There is no connection between an object's mutability and its ID. -- https://mail.python.org/mailman/listinfo/python-list
Writing SOME class methods in C
Hello, I'm trying to implement some (but not all) methods of a Python class in C. What I've found on the Net is: - how to implement entire modules in C so that I can import that module and use the C functions (successfully done it, too). - how to implement entire classes in C But I can't find any examples of modules which consist of a mixture of C and Python, nor modules that define classes of which some members are implemented in C, others in Python. Of course, once I have the "mixture" bit figured out I could just define wrapper class methods that call C functions (functions impleneted in C, that is). But I would find it rather elegant if the C function could access the class members directly. The fact that the C extension functions have a mandatory "PyObject *self" parameter tells me that this must be somehow possible, but I don't know how. I'm sure that many of the plethora of Python extension modules out there must use the technique that I'm looking for, but I don't even know where to start looking. Pointers are welcome. Thanks, robert -- https://mail.python.org/mailman/listinfo/python-list
(Windows) "Dropping" stuff onto a Python script
Hello people, I'd like to have the functionality known from "real" executables that if I drag-drop a file icon on top of the app, the app starts and has the file's path as command-line argument. However, this doesn't seem to work with Python scripts because Windows sees those just as files, not apps. Can this be done? Thanks, robert -- http://mail.python.org/mailman/listinfo/python-list
