Hacker News Reader

Comment by eru | Hacker News Reader

Python is actually relatively easy to set up on Windows. (Or at least it was easy to set up on Windows 98 in the early 2000s. I don't know how it's now, or five years ago.)

You just download the official Python installer, and off you go. It even comes with Idle as a reasonably good IDE.

View on HN

If you run python in command-line, it starts Windows Store…

The python from Windows Store is not good, it redirects some path writes and will make the debugging experience of tools using python dreadful. Always install from the win32 installer from the website.

That's not the point. The point is that even after you install Python on Windows using the official installer, and unless you put that early in the %PATH%, running 'python' on a powershell / Windows terminal will pop up the Windows Store. That's just how fucking stupid Windows is these days.

If you install Python using the official installer from python.org and check the "Add interpreter to PATH" box when installing, running `python` in shell will launch it.

Experiencing this for the first time was really jaw dropping. And I believe by default "python3" has distinct behaviour of _telling you_ to visit the Microsoft Store, but not opening it. Bizarre.

It's currently just as easy to use for learning and experimenting on Windows as you describe. I don't use Python on Windows heavily enough to evaluate it for more serious development.

Long time ago I participated in a Python course, where it just wouldnt work for half of the students (like 10 people) - and the lecturer couldnt figure it out.

As far as I remember Python REQUIRED to be installed on C: and in something like C:\Python where it would bring 5000 various files.

Even more time ago, I was at a Java class, where my code would work on my computer but just wouldnt work on the computer of the lecturer. I remember the guy spend like 10 minutes looking at the (very simple) code and trying to figure out why the code worked on Windows but not on Linux

On modern Windows there's this weird pre-installed python stub which (IIRC) asks you to install Python from the app store and which can confuse shell script which check if Python is installed.

In terms of IDE support, VSCode with the MS Python extension bundle is a pretty good Python IDE.

In the early 2000s Python was probably the easiest language to install in windows after vbscript and vba. Download the ActiveState python installer, launch it, and you're done. And this included being able to write GUI applications, interact with COM object (Office for example), it was quite nifty, I used it for automating a number of tasks at my first job.

It’s still easy to setup, it’s all the commands that are different in powershell. So if you’re doing a lot of Google programming it’s not going to be easy to actually use Python if you’re running things from a command line.

That being said Microsoft know windows is terrible for software development which is why it’s so easy to use Linux inside Windows with WSL2. Since Docker Desktop for Windows requires WSL2 it’s very common for any developer AD account to have it locally as admin.

> That being said Microsoft know windows is terrible for software development which is why it’s so easy to use Linux inside Windows with WSL2.

What are you smoking man? Don't impose your beliefs as facts upon Microsoft.

I don't think Microsoft is stupid, they know that they have the lions share of developers- they're also aware that they are losing to linux in a big way when it comes to service deployment environments. I even heard Azure itself does not run Hyper-V on Windows anymore (though, who can be sure).

It's a smart play for them to have WSL- it means less friction to target Linux and will keep people writing software on Windows (which increases the likelihood of making software for Windows- especially developer tooling).

I think the parent is wrong that developing software on Windows is hard, my original comment up-thread was largely regarding the fact that in the late-90's and early-00's internet access was not common and getting your hands on a Microsoft Development environment was the furthest thing from easy. Linux, ironically, was easier as it came with all kinds of documentation and interpreters and compilers out of the box.

It certainly still does run on a Windows flavour,

https://techcommunity.microsoft.com/blog/windowsosplatform/a...

However they have been working on something else for specific workloads,

https://opensource.microsoft.com/blog/2024/11/07/introducing...

Huh? Then why WSL2 if not because Windows sucks?

(This latter, Windows sucking, is not necessarily meant in isolation but as part of our world: Windows is not supported by many modern tools.)

It’s possible to accept there are many dev tasks that can only really be achieved on Linux without accepting Windows sucks. The first is pretty much inarguable, the second is emotive and imprecise.

Lots of tools are only built to run on Linux and are ported over in ways that just about run to windows. Wsl was an enormous step up from Cygwin in allowing windows developers to use those tools and wsl2 is another huge leap in that direction.

I don’t think windows sucks, I think that a lot of people outright refuse to use windows and design their tools to run on Linux only, making choices that are optimal for Linux but not for windows. two examples are processes vs threads and opening/closing lots of files. Ironically the Linux first approach of processes over threads doesn’t really scale to the level we want. Postgres is a great example of trying very hard to be multithreaded as it’s hit the multiprocess limit, and struggling to do so.

It isn't easy for folks that see UNIX everywhere, and nowadays a Linux VM makes more sense than the old POSIX subsystem, that is all.

For better or worse, UNIX has won on embedded and server room.

Despite my UNIX experience across all known vendors, I only use WSL for Linux containers.

    For better or worse, UNIX has won on embedded and server room.

I think this is the HN bubble at work. Maybe you mean something qualitatively or quantitatively different than I do when you say server room but every client I've worked with in my extremely conservative industry in the past ten years has been running on site, coloc, or cloud "server rooms" on windows.

No, this the cloud speaking, where Microsoft themselves acknowledge Azure has > 60% workloads on Linux.

On embedded most RTOS support some variation of POSIX, even if not fully compliant.

Windows servers seem to be left to Microsoft shops, running a mix of .NET Framework with IIS, SQL Server, Sitecore, Sharepoint, Dynamics, AD.

I’ve spent a long time in non tech enterprise and I think unix won. 15 years ago you would hire someone and they would be proficient in Windows and Microsoft office. Now people have grown up with Macbooks, Chromebooks and mobile/tablets. It’s not a major issue yet, but it’s increasingly becoming one as the generations in the workplace are slowly shifting.

I started using python at around 2.6/2.7, and while it was easy to install python on windows, anything that involved non pure python was a nightmare.

Back in these days you had no wheels and I think it was at least a partial reason for why conda was a thing.

Yeah, back then, `pip install` just didn't work for anything written in C. I seem to remember a Windows-specific site with builds of popular extension packages - Cython, lxml, OpenSSL, and the like. It was unofficial, and you couldn't use a package manager to install them, but after manually downloading them, they tended to work.

Wheels, Conda, and WSL, helped - now, all the R&D guys at work use Python on Windows with PyTorch, TensorFlow, and all that without problems. I'm also using (mini)conda (on Linux) instead of virtualenv - it's nice because I don't need to worry about all my venvs breaking after an OS upgrade.

Anyway, compared to those days (I started with 2.4 on Windows, switched to Linux around 2.7), working with Python on Windows is at least feasible.

The big problem with installing packages written in C is that on Windows, you needed the matching version of VC++ to build, which wasn't anywhere as easy to obtain as the standard build tools on Unix platforms, usually (where they'd often even be preinstalled, and if not, it's one apt/yum invocation away).

The eventual solution for this was something called "Microsoft Visual C++ Compiler for Python 2.7" - which was pretty much just enough of VC++ command line tools packaged to make it possible to build things.

Yeah, upgrading Python from build-in ancient version that came with Linux distro (usually 3.8, or even 2.x) is actually much harder than doing so on Windows.

you don't have to upgrade, you can have more than one python install at the same time. You only really need to know about how to manage your PATH environment variable.

I guess it depends on what Linux distribution you are using?

> upgrading Python from build-in ancient version ... usually 3.8

Now you're making me feel old.

You shouldn't use the OS's Python for your work. That Python is for OS utilities' use. It's meant to be old and stable. Instead, use pyenv, conda, asdf, mise, etc. - it'll allow you to install multiple versions of Python and easily switch between them for your projects. You're gonna need it anyway once you try writing integration tests for multiple versions of Python, like with tox or nox.

Reply on news.ycombinator.com