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.
I say that because "python.com" looks like a URL. DOS was a loooong time ago (I used it in my youth) and well out of the memory of most internet users today. So instead they see "python.com" and think it's a web address. And while I thought it would direct you to a website about python, you know where that address goes? To a website that has something to do with creating your own camsite. Yeah... that kind of camsite.
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.
Yeah, I was aware most would take it as a domain name, but we _are_ on HackerNews, and I think .COM is still an applicable executable extension on Windows. As such, it strikes me as a decent name (when looked at independently).
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).
I was confused by this naming scheme and I am an (allegedly) seasoned software engineer of the DOS era (team 6.11a).
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.
It's named .com because it's a flat executable format. If you map it into memory and start executing at the first byte (MZ which means JG +69) then it'll just work.
If you are looking for a multi platform build of a specific version of python built with an obscure libc for some niche use case it's _very_ likely none of that is an issue for you, at all.
I would say .com extension as an indication of an executable is acceptable exactly because we are on HackerNews (and not W3Schools.com, for instance). Basically, IMHO, "hackers" are supposed to know a bit of (arcane) history as well: "hacking", to me, presumes a deeper investment in the field. Otherwise, they might only be (web) software developers (or engineers).
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 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.
COM "format" is "trivially" portable for a limited subset of functionality where you don't interface with the rest of the system except possibly memory (I think .o files produced by GCC compiler are very close to pure machine instructions too, before they get massaged into an ELF file with ld): in the sense that you can wrap them in a function and just execute them on the same architecture.
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.
python.exe is the only other option to fulfill the Actually Portable requirement on Windows.
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.
Just to clarify, APE is both an EXE and a COM file. The COM file format is basically just flat executable code. The only thing you need to do, to be a legal .com file, is if the program is loaded and execution starts from the first byte -- it works. APE meets that requirement for Linux and bare metal. It uses a polyglot to tell if the processor is running in real mode or long mode within its DOS stub. https://github.com/jart/cosmopolitan/blob/066ed2b2b229dce4d1... APE is also a legal EXE file because it has the MZ header. However... I thought it'd be more cool to signal as a DOS binary than to signal as a Windows binary, since signalling as the latter would probably be a turnoff for the Mac/Linux/BSD crowds, who are also supported by APE.
