I think some explanations might be helpful. I'm familiar with python, but not cosmopolitan libc.
I think some explanations might be helpful. I'm familiar with python, but not cosmopolitan libc.
The flask demo is unnaturally slow because my old computer is slow (running python tests in the background). plus I was using `_dummy_thread` Python3.6's pure-python threads implementation.
https://news.ycombinator.com/user?id=jart
Her comment history is full of good info about the project.
Cosmopolitan is a libc for that bundle [1], so that you can write your C code just the once, and then you have just the one output executable. No download-per-platform, or that's the goal.
Of course, I am sure some screen readers will simply take a custom text preprocessor that will turn l337sp34k and similar spellings like this one into regular text, but I am certain none of them have it as the default.
I use a magic string somewhere, which has control codes, three ASCII digits for versioning, and an RTL UTF-8 character, and is exactly eight bytes wide.
Anything munges my file, I'll know. Meanwhile I can just mask it.
I would not call it a shibboleth, but vague, generic terms are known to be for most purposes unsearchable, and having a really unique string identifier for your thing could make it more valuable.
It reminds me of this other HN link:
What other term would people suggest then? Surely it's a real concern for projects to be easily accessible by people looking for them.
DOS .COM programs were pure maching language programs with no OS-specifics like headers or syscalls (though running in real mode, they did expect BIOS interrupts), so that makes sense to me: they are trivially portable.
The most famous one was COMMAND.COM.
But to each their own.
(I think the most unfortunate thing is what content is present on the python.com domain, as a sibling comment highlighted)
And then, it's bad because a user trying to search for it using the universal search/URL bar in their browser can't just type that in and hit enter to search for it, they have to manually select that they want to search for it, or else they go to the site about starting your own camsite.
AND THEN... once they have googled for it... none of the results on the first page have anything to do with this program as far as I can tell.
So yeah, weird, obscure, confusing branding that makes the program hard to search for.
EDIT: I could be missing something? Does this program have a different name and python.com is solely the file name of the executable or whatever? It still seems like it could be more descriptively named.
This is a non issue.
But ouch, I haven't looked where python.com might be pointing to today, so that's indeed unfortunate.
As for search results, I think the most obvious candidate for bad naming is... the Go language. ;-)
Btw, this is part of the Cosmopolitan (referenced multiplatform libc implementation) monorepo, and only lives in the `third_party/python` directory. I am not sure if it's customary to name Cosmopolitan-linked binaries with a ".com" extension (perhaps it also alludes to the name "Cosmopolitan", but I guess then it'd be "cosm" or "cosmo"), but it definitely does not seem to be a public name you'd search for.
Searching for "python.com" (in quotes) on Kagi or Google returns a bunch of Python-related .com domains, whereas searching for "Actually Portable Python" returns the above site as the first hit — that's the name one should be looking under for this. Though I am sure it'd be nice if a more generic "multi-platform Python binary" also matched some of this (though platforms sometimes mean architectures as well).
Reading these comments about why it's named python.COM, yes that's pretty clever but it didn't even occur to me when I first read the post and I suspect the majority of people on hackernews had the same impression.
Go is definitely also bad naming, but the domain is golang.org and the canonical search term for the Go programming language is "golang".
In this day and age, we should probably be optimizing for clarity and searchability instead of "clever use of an outdated tech naming" which half of the engineers nowadays wouldn't even know about.
I am not disagreeing on the clarity and naming, but in this case, I don't think it's a big deal at all.
And how is headerless raw assembly that expects the bios interrupts to be usable "trivially portable"? If it was, it would run on modern amd64 OSs without emulation, but it doesn't.
The fact that system interfaces like BIOS interrupts may or may not work is insignificant when you start thinking of it as only a playful name.
And let me repeat a word of warning: this is only my guess, I am unrelated to the project.
Thing is, an APE is a COM file, not an EXE. Different headers, which contemporary Windows no longer cares about; but why lie about it? python.com is in COM format, as far as Windows is concerned.
Added for clarity: 'no longer cares about' meaning, Windows loads executables by checking the header for COM or EXE format and behaving accordingly, it's which of the two valid extensions gets used which it no longer cares about.