On Thu, Mar 10, 2016 at 10:14 AM, BartC <b...@freeuk.com> wrote: > On 09/03/2016 21:13, Mark Lawrence wrote: >> >> On 09/03/2016 12:02, BartC wrote: >>> >>> On 09/03/2016 08:40, Mark Lawrence wrote: >>> >>> Here's another: you have a program in Python that you'd quite like to >>> port to another dynamic language. Transcribing actual Python code is >>> straightforward. Until you come to an import of a module that you can't >>> find, because it's not written in Python. Now what? Now, you might >>> appreciate the advantage of a program in 100% pure Python. >>> >> >> That is not Python's problem, or my problem, that is your problem. > > > Maybe that's not the best example of why someone might prefer a 'Python' > program to be actually written in Python. Sometimes you want to understand > how code works or what it does or simply to learn from it. (Or sometimes, to > rip bits off.) Then it's frustrating when you come up against a dead-end so > quickly. Because the real meat isn't in Python at all.
What *is* the real meat of a program? Every action is defined in terms of smaller actions - a Python program is built out of Python primitives and function calls, a C program is built out of C primitives and function calls, an 80x86 machine code program is built out of 80x86 CPU instructions and calls to other code. Does my MUD server need to have its own memory allocation code? No. Does it need an algorithm for adding two integers together? Certainly not! And nor does it need PNG encoding and decoding algorithms; I simply call on Image.PNG.encode() and Image.PNG.decode() to do the work, passing images around in my code as first-class objects. Does it detract from my code? Not in the least. My code treats "load an image from a PNG file" as a fundamental operation, and gets on with doing its stuff. Reinventing the wheel does NOT intrinsically make your code better. Unless there's something you're doing that's fundamentally different from what's already available (maybe a database client that uses non-blocking sockets with async/await), it's usually better to use what someone else has written. I'd much rather use a one-liner that reads an image from the disk than wade through your pages and pages of bitshift operations in Python (especially as it's all uncommented - how can I know if it's even correct, other than by finding a reference algorithm written in C?). >> Python 2.8 or RickedPython? Will the unicode handling be better than >> that of the dread Python 3.3+, PEP393 Flexible String Representation > as >> repeatedly pointed out by the RUE? > > I'm not much interested in Unicode at the minute. I'll pass. Then *get interested*. Unicode is the only way that you'll ever not be parochially bound to a subset of English - or, worse, bound to an arbitrary eight-bit codepage that you don't even control the choice of, such that your program behaves differently on different systems. FIX YOUR LANGUAGE and support non-English text. Integers, floating point numbers, lists, and images all need encodings; so does text. It's an abstract data type, just as the others are. ChrisA -- https://mail.python.org/mailman/listinfo/python-list