I'll have to look into this. In some limited cases verbosity that leads to a more obvious and understandable presentation is preferable, at least to me.
Or, rather, the dictionary shows that it has been used incorrectly for at least a few years. Knowing what the ending -oid means clearly shows the usage wasn't correct.
"I could care less" is also "correct" according to your criterion.
>Or, rather, the dictionary shows that it has been used incorrectly for at least a few years. Knowing what the ending -oid means clearly shows the usage wasn't correct.
Or you don't know what -oid means either.
Oid doesn't strictly mean "looking like but not being X". Some words ending in -oid can mean that, but generally just means "having the form of X, belonging to the class of X" etc. From the ancient Greek -oides.
Dictionary again:
-oid. a suffix meaning “resembling,” “like,” used in the formation of adjectives and nouns (and often implying an incomplete or imperfect resemblance to what is indicated by the preceding element)
Note the "often", not always.
And not at all mandatory at the original ancient Greek -oeides where -oid was adopted from, for math, zoology, medicine, etc. It means both "likeness" (so alike, but not X), and "form" (belonging to the family of things with X form).
Really, changing a Python project is not pretty, because speed and memory usage guarantees vary wildly between releases. One factor is that CPython is constantly being rewritten.
And that does not even cover projects that depend on 20 PyPI packages, which introduces practically guaranteed breakage.
> One factor is that CPython is constantly being rewritten.
Exactly. I have an impression that the programmers as the whole already spent significant time only to develop and maintain different solutions only to manage different Python versions and dependencies in production environments, which were maybe much less needed exactly with some better "discipline" in the Python development itself.
On another side, Python won many hearts over Perl 5 which is much more stable, but "appears to be" harder. Interestingly, Perl actually forces a programmer to "care more" (i.e. be more precise): the reference to something requires different notation than the direct use of something, the use of the array requires different notation than the use of the scalar etc... it actually has "some kind" of typing enforced by the language and explicit in every line. In my personal experience, I have much more "trust" in a 'biggish' Perl program than in a that big Python program to behave "exactly how I'd expect it" (e.g. in the sense that Perl doesn't produce as easy "exceptions" and whoever wrote it had to think more about the correctness than for Python, especially if "use strict" was used, which has stronger guarantees about the typos in variable names than Python). Going further, however, C-like (actually Algol-like) compiled languages simply allow much more than the scripting languages, regarding the smallness of what is eventually produced. E.g. Busybox ( https://busybox.net/ ) has to be written in C or something very close to C. Free Pascal http://wiki.freepascal.org/Platform_list is actually also very practical language for many use-cases.
Are you making that comment by speculating or by having looked at the Obnam codebase? I'm not a Python developer, but I've looked at the Obnam code enough to have written a replacement crypto plugin for it. AFAICT, if Obnam was holding Python wrong, it's too hard to hold it right.
I haven’t looked at the code, but I hope someone who has been using Python for 20+ years knows how to write and use it properly... so yeah, I’m inclined to agree with you.
Languages encourage various ways or styles of solving problems, though, and some of those ways require more self-discipline or care than others. For example, many languages with static types make it so that you can make sweeping changes to the interfaces between things and the compiler will catch any mismatches for you, but in a language like Python, you'd better hope you have a unit test that will catch it.
I like Python well enough, have been using it since mid-2001 and was very much a hardcore Python enthusiast for a number of years, but nowadays I prefer languages that encourage immutability and functional programming styles, as I find that they make it much easier to avoid bugs. I've had plenty of Python experiences where bugs were caused because something somewhere else was mutating stuff behind my back, messing up my mostly-unrelated code. Usually this other code was also written by someone else, so I had no way of knowing about it. This kind of thing can be prevented in other languages, but requires a lot of discipline to avoid in Python (and other languages, I'm only picking on Python here since that's the topic of the article). These problems won't follow you to the next language, if the next language is more suited to avoid them.
I know it hides similar parts of a series of emails because it cuts off my email salutation and sometimes people think that I'm being disrespectful. I wish I could stop it from doing that.
If true, I wonder how similar these emails were to have that happen.
yes