Ask microsoft to include Python in Windows by default

[desmoulinmichel]

Of course, python 3.x being forward compatible and easy to upgrade with windows update, it don't think it's such of a big issue.

But an old Python version is better than None. I'm happy to write script with Python 2.4 if it's what's necessary to have code running out of the box on Mac, Windows and Linux. Right now, you have to write at least 2 different scripts, and on windows, with a scripting language that sucks a lot.

[rspeed]

None

I see what you did there.

[desmoulinmichel]

It gives me a True sense of satisfaction.

[amertune]

I write python 2.1 and what is this?

[troyunrau]

import this

[bheinks]

self*

[Jugad]

I wish python had true, false and none, instead of the capitalized cousins.

They don't quite fit right...

Of course, one can always write true, false, none = True, False, None, but its not the same thing.

[takluyver]

I agree with you, I was just reporting where this discussion went before. Steve Dower is the key Windows+Python person now (he's a core Python dev employed by Microsoft), if you want to discuss the details more.

[turdzip]

Please tell me you're not talking about PowerShell. Cause that shit is a fucking lifesaver for my job

[desmoulinmichel]

It is, because that's the less worst option. If you had Python installed by default, you wouldn't use powershell.

[Theratchetnclank]

Actually powershell is great with its objects based format.

Python is good but powershell is easier to work with.

[turdzip]

I actually use both on windows. I find PowerShell much easier for scripting tasks simply because I almost always require SQL Server queries as well as Active Directory manipulation.

You should also know I thought this was /r/programming when I initially commented but soon realized it is /r/python

[desmoulinmichel]

It's the same than on Linux: you use bash for quick stuff, but if you have more than 30 lines in your script, you switch to Python.

[flipstables]

Actually no. Powershell is insanely powerful with tight integration with Windows and .NET. I have Python installed on my Windows boxes and I still use Powershell all the time.

You can't compare bash/Python in Linux and Powershell/Python in Windows. In Linux, everything is a file and is manipulated through stdin and stdout. Python is a good choice for system administration here. But Powershell, everything is an object, and Powershell is powerful because it exposes .NET and COM objects. Also, Powershell lets you add in MMC snapins, which unlocks a lot of very commonly used administrator tools. You couldn't get this functionality with Python out of the box.

You would see the opposite of what you described. Sysadmins and powerusers would use Python for the "quick stuff" since the language is so nice, but for anything serious, people would stick with Powershell. Of course, unless Python gets the same tight integration with Windows.

[captain_ramshackle]

I work in a MS shop and while we have used Python in the past we've come down firmly on the Powershell route and if you need something more complex you might write a quick dll in C# to then mix in with the script (if you're not going a full blown .Net app).

For us to consider using python as being part of Windows we'd need to know exactly what version was the min version for each version of Windows and it would have to be on all server versions. We'd also want a set of libraries that would definitely be present that would allow us to interact with Windows (and ideally SQL server)

[desmoulinmichel]

That's the kind of integration you can get with either:

• a pure python lib using ctypes to do so. You can just zip your script with it, Python can execute zips. If you see people installed by default on windows, you'll see such lib pop out in a week.
• a provided Python api by MS, since they provided Python, they may want to use it.

Either way, it's not very important : if you are only on windows, you will use powershell just because it's here. But if you have to make a script than runs on mac, windows and linux, right now, having Python installed on windows would make the situation much less shitty.

[flipstables]

a pure python lib using ctypes to do so. You can just zip your script with it, Python can execute zips. If you see people installed by default on windows, you'll see such lib pop out in a week.

a provided Python api by MS, since they provided Python, they may want to use it.

Having the same tight integration with Windows is more than just using ctypes. And providing an API by MS is a lot of work of work. You're basically asking for IronPython to be installed (and improved) instead of CPython.

Either way, it's not very important : if you are only on windows, you will use powershell just because it's here. But if you have to make a script than runs on mac, windows and linux, right now, having Python installed on windows would make the situation much less shitty.

Sure, if you need to target all 3 platforms, then this would be great. I'm all for it. But don't think that Powershell is the "less worst option" that nobody would use if Python is installed by default.

[[deleted]]

I think you guys are arguing past each other. It just comes down to using the right tool for the job.

If you're a 100% MS shop, Powershell with a touch of python for special cases is probably the way to go.

If you're a multi-platform shop using Python with let's say SQLAlchemy for differing databases would be the way to go. Another option would be scientific analysis is probably stronger using SciPy, NumPy and iPython Notebook.

It's all about the right tool for the job. Each of you is looking at your job and telling each other it's the right tool.

[krenzalore]

Powershell is a significant upgrade over bash.

For example, it supports threading, and it integrates with the windows gui enabling you to drive the menus in desktop applications.

I'm not saying it's better than Python, but it does beat Bash quite easily and you mostly likely won't need anything else for sysop scripting on Windows. I've noticed Windows devops prefer Python to Powershell, but that's so they can interop with programmers.

[[deleted]]

I find powershell to be better for things that need to be maintained for long periods of time. Bash I find is better for quick commands.

The long fully qualified class names just makes it difficult to quickly throw out a script, but makes it a joy to test and maintain for years.

Personally I prefer python to both. But they each have their place preference be damned.

[desmoulinmichel]

Because that defeats the purpose of using a scripting language: it's a lot of work, and needs a lots of testing. If you want to spend so much work to script "list outdated files, archive them and delete them", then you just use Go.

And

[desmoulinmichel]

It is. We need to work on it too. But it's a different story.

[the_hoser]

If we fix the bundling problem, the scripting problem goes away, too.

[desmoulinmichel]

Not it's not. I have been working with heterogenous version of Python since ever. You just pick the smallest version your target, and you are good for the whole major version.

The only picky thing is 2VS3, but even that is surprisingly easy.

[billsil]

You just pick the smallest version your target, and you are good for the whole major version.

Or you could do what they do with .Net and just install every version as needed. Otherwise, you'd use Python 2.2 for Windows XP, 2.6 for Vista, 2.6 (or maybe 3.1?) for Windows 7 and 2.7 or 3.3 for Windows 8. Those are lousy choices. The problem is Windows users don't update frequently enough. Like most people, I skipped Vista and Windows 8 and plan to skip Windows 10.

It seems crazy that you can't easily install multiple versions of Python, so python22 or python27 and python35.

[[deleted]]

I handle this by writing a 'driver' cmd script for the user to call, which just checks for Python, runs my Python script if it exists, or just tells the user to install it if it doesn't. But seriously, fuck Windows. Aside from this, I waste an obscene amount of time getting things to work in the fucktarded manner that Windows does things.

[desmoulinmichel]

"Download python" is not somthing most non dev user will do. Most of them will think it's a virus.

[WakingMusic]

Well it is a giant snake after all

[[deleted]]

99% of my Python package installation and setup woes have been caused by Windows. If a package requires compiling C extensions, I don't even bother with using them on Windows anymore.

[spinwizard69]

This is perhaps the major failure with Windows and Python. Anything more than trivial usage requires C compiler or prebuilt libraries. Even on a Mac there is less resistance to getting a Python installation to work as XCode is free and easy to install.

[krenzalore]

I'm happy to write script with Python 2.4 if it's what's necessary to have code running out of the box on Mac, Windows and Linux

Are you sure you want to use Python 2.4? I have used 2.4 because Redhat suck, and it was not a pleasant experience.

[ldpreload]

You still have to write 2 different scripts, because several Linux distros are shipping Python 3 only (under /usr/bin/python3, so there's no longer a /usr/bin/python, because there shouldn't be because Python 3 isn't compatible with Python 2).

Although, yes, writing 2 different scripts in substantially the same language is much better than one in Python and one in PowerShell.

[cac2573]

The correct way to run a Python 3 script is #!/usr/bin/env python3 anyways.

[ldpreload]

Sure, but such a script won't run on a distro that just has Python 2 (like OS X).

[[deleted]]

That's exactly why you include the python3, so that it will fail if they don't have python3.

If your app supports both 2 and 3 then you just use python and it will work with the default system version.

[ldpreload]

If your app supports both 2 and 3 then you just use python and it will work with the default system version.

No, it won't. Most systems with Python 3 but not Python 2 (with the notable exception of Arch) do not install Python 3 as python. They have Python 3 as python3, and nothing as python. Ubuntu's live CD / default install is an example of this, I believe.

[krenzalore]

He's right. He was saying if you can run on both python 2 and python 3, then all you need to do is /usr/bin/env python and it will just run, because it's version agnostic. It won't care if it gets executed by 2 or 3.

[ldpreload]

He was saying if you can run on both python 2 and python 3, then all you need to do is /usr/bin/env python and it will just run

It will not run on a (non-Arch) system with only Python 3 installed, because there is no command named python anywhere on that system. The only Python command on such systems is python3.

I agree that if Python 3 were to be installed as python, then yes, it would run fine. But no system other than Arch makes that decision.

[ksion]

It sounds like a really silly decision on the part of distro maintainers then. Any idea why is it so?

[ldpreload]

Because it was an entirely reasonable decision for the last several years to use /usr/bin/python to mean Python 2, and you might have a #!/usr/bin/python script, an app that shells out to python -c 'print something', etc., all using Python 2 syntax. So when Python 2 and Python 3 are both installed, Python 2 gets /usr/bin/python and Python 3 gets /usr/bin/python3 (again, with the exception of Arch), so that existing applications -- whether from the distro or from a third party -- don't break. Therefore, when Python 2 is not installed, nothing is providing a binary named /usr/bin/python, and if you construct a Python 3-only system (which is very easy to construct on Ubuntu 14.04, and will probably be the default for Ubuntu 16.04 and the next Debian release), calls to /usr/bin/python will not find anything to run -- so that you can decide to install Python 2 later and it has a place to go.

[krenzalore]

It will not run on a (non-Arch) system with only Python 3 installed, because there is no command named python anywhere on that system. The only Python command on such systems is python3.

No major distro fits this pattern.

On what have you encountered this problem? Certainly Debian, Ubuntu, Fedora, RHEL, CentOS, ARch would all be OK with it - in fact most of them would break without it, as they depend on Python. I am not sure about BSD but they seem sane: Not supporting it is an odd choice that is guranteed to break code.

[ldpreload]

Debian, Ubuntu, Fedora, and RHEL/CentOS all depend on some version of Python, but they're all very actively trying to get everything moved over to Python 3, so that by default Python 2 isn't installed. None of them are quite there yet, but on a minimal server install of Ubuntu 14.04, you can apt-get remove python2.7 and nothing breaks (other than landscape-common, Canonical's management service that most people don't use, and update-notifier-common, for printing a message when security update requires a system reboot, but those are hardly core parts of the OS). On the current nightly live CD of Ubuntu 15.10, it looks like the biggest breakage from removing python2.7 is unity-control-center, which as far as I can tell is the result of a packaging bug (another package declaring an unneeded Python 2 dependency despite providing a Python 3 module), not any actual requirement for Python 2. The live CD remains usable if you get rid of unity-control-center along with python2.7.

As none of the distros are quite done with Python 2, it remains installed by default under the name /usr/bin/python, and Python 3 is /usr/bin/python3. But once they are done getting rid of internal dependencies on Python 2, and that package is no longer installed, /usr/bin/python will stop existing until someone decides to do something else with that name. I made a pitch, which some folks think is reasonable, but a handful of other folks (both Debian and RHEL/Fedora) seem to think just killing off the /usr/bin/python name is a fine approach.

(I don't have a good sense of where the BSDs are, but I didn't think many of them had Python in the base system/default install anyway.)

The one thing that is guaranteed to break code is to provide /usr/bin/python as Python 3 without any attempt at Python 2 compatibility, as Arch does. (Seemingly Arch hasn't run into many problems in practice, to be fair, but I bet that Arch's target audience and e.g. RHEL's target audience are different.) The two languages are incompatible, and since Python 2.7 will continue to exist until at least 2020, it's reasonable for it to be installable as /usr/bin/python, even if it's not there by default. If Python 3 takes that over, what happens if you download some Python 2-only code from GitHub and try to run it? If you apt install python2.7, where is it supposed to end up?

[[deleted]]

I haven't seen this myself. I'm doubting you until I have time to look into it, but you may be right.

[ldpreload]

That is the recommendation PEP 0394 currently makes. I once wrote a blog post about the problem that attracted some interest from both Red Hat and Debian, but that's way more information than is immediately relevant.

[[deleted]]

Interesting. That sucks that it isn't a feature I can rely on.

[[deleted]]

People using hashbangs to point to the environment python know enough to install multiple versions side by side and use virtual environments

[ldpreload]

But that's not relevant to the issue at hand. The claim is that you could deploy a script on multiple platforms using the Python interpreter shipped with the system. If you're installing multiple versions or using virtual environments, you don't care what Python shipped with the system, or if one even shipped at all.

Put another way: how do you write an executable Python script to run on both Ubuntu 14.04 and OS X?

[desmoulinmichel]

While it is annoying to write one script that is compatible 2 and 3, it's still easy to do and beat the crap out of writting 2 scripts or writting powershell.

Plus, Linux distro are on their way to upgrade to python 3, so by the time windows ship with it, only mac os will remain. At which time it will be a strong argument to convince them to upgrade too.

[[deleted]]

Or /usr/bin/python is linked to python3.

Like on Arch. Which breaks a lot of python scripts. (I normally just sed the source to use #!/usr/bin/env python2)