@ChrisAngelico don't know [replying to your message but addressing to all]
i respect you all, i respect your involvement, i doubt not your py skills but can you please stay on topic and be concise i value all posts here and try to read them all as they are all serious stuffs but when you mix in long paragraphs i have to take the pain to summarise what you just said also i *beg* you all if possible to ignore the like of postx : you are a vermicelli pudding from the north korean suburb of some south pole city posty : you seem like a childish python programmer having Phe in Haskell postz : *some more obscure references* i can feel the octopus nature of some threads in my bones Abdur-Rahmaan Janhangeer https://github.com/Abdur-rahmaanJ > Of course we have no idea what Marko's software is, or what it is doing, > > but frankly that seems pretty implausible to me. On the face of it, it > > seems as ridiculous as the claim that he can't tell which variables are > > quote-unquote "really" lists of weights and which are lists of distances. > > > > On the face of things, this really sounds more like an admission that > > Marko is working with a shitty code base, not a fundamental problem with > > Python. But dealing with shitty code bases is the reality. > > Fair point - but doesn't justify hating on Python 3 for making it > easier to work with good code than with bad code. I've had to work > with ridiculous data formats before (forty-ish lines of block comment > concluding with "Cthulhu's got nothing on a determined bank"), but > when that happens, I *know* that my code is being warped to fit the > requirements. It's not something to replicate elsewhere. > > >>>>> In the end, the Gordian Knot was sliced by using > >>>>> Python3's strings for everything and restricting oneself to Latin-1 > >>>>> codepoints (almost) everywhere. > > [...] > > > > I wonder whether Marko's Python 2.7 code base was ever actually tested > > with non-Latin1 text. I suspect that if Marko had (let's say) Japanese > > users expecting to use CJK characters in the application, his affection > > for the 2.7 version would be a lot less. > > I very much doubt it has. He *restricted* to Latin-1, which means that > he threw away all the support Python offers, restricting to one > seventy-thousandth of the available characters, or a thousandth of the > allocated ones. > > >> Text strings and sequences of bytes *are different*. > > > > At an implementation level, everything is bytes. People do so insist on > > conflating implementation with interface, even when they don't need to... > > And at a different implementation level, everything is electrical signals. > > > (Sometimes I think people should be required to implement algorithms on > > analogue computing devices before they're allowed to write code for > > digital computers, just to drive home the point that neither bytes nor > > bits are fundamental to computing, but are mere implementation details.) > > Every week, I live-stream a workshop on data structures and > algorithms. (You're all most welcome to come by; it's Friday lunchtime > in the US, or Saturday early morning in Australia.) I use JavaScript > (because a lot of people know it), Python (because it's a really > expressive language), or a deck of cards. Have you ever seen > merge-sort implemented on a deck of cards? It's beautifully simple and > elegant. Interestingly, quick-sort looks very different from > merge-sort when implemented in C, but they're fairly similar when > implemented in cards. > > Bytes? Bits? Arrays? If you want them, you have to first implement them. > > > At a semantic level, byte strings and text strings represent > > fundamentally different things, as distinct as weights and lengths. > > Or, as I keep running into when I try to mod Team Fortress 2, entities > and clients and users. They're all represented by the "int" data type, > and I have to spend an insane amount of effort trying to keep them > straight - does this function take a user or a client? Oh wait, this > isn't the user at all, it's the entity ID of that user's gun. But it's > still just an int... *sigh* SourcePawn (the language in question) > lacks a type system strong enough to handle this. > > Having different data types for fundamentally different types of data > is not a weakness. It is a strength. > > > One might as well say that bytes b'@=<\xed\x91hr\xb0' really is the > > number 29.238 and expect to multiple your name by 12.5 and get your > > height in seconds. > > QOTD. > > >>> No, as a large number of Python3 facilities require str objects as > >>> arguments. Consider urllib.request.urlopen(), for example, which > >>> requires a URL to be an str object. > > > > That's because URLs are fundamentally text strings. > > > > Quick quiz: which of the following are real URLs? > > > > (a) http://правительство.рф <http://xn--80aealotwbjpid2k.xn--p1ai> > > > > (b) http://παράδειγμα.δοκιμή <http://xn--hxajbheg2az3al.xn--jxalpdlp> > > > > (c) http://실례.테스트 <http://xn--9n2bp8q.xn--9t4b11yi5a> > > > > (d) All of the above. > > > > https://uxmag.com/articles/a-url-in-any-language > > I had to actually check two of those to be sure they really truly were > *real* URLs, not merely *correctly formatted* URLs. But yes, URLs are > fundamentally text. For hysterical raisins, DNS has some oddities to > it, so when you dive into how these are actually represented, the > Korean example is actually http://xn--9n2bp8q.xn--9t4b11yi5a - but I > don't believe there are any byte-based encodings involved. This is > encoding text using other text, where the encoded form uses an > extremely restricted alphabet (a-z 0-9 and hyphen). > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
