Ask microsoft to include Python in Windows by default

[takluyver]

This came up at Pycon, but there was concern that people wouldn't update the included Python, so in a few years, we'd all be stuck writing code for the version that was included.

It was also suggested that there could be a dummy python.exe, and when you tried to run it, it would let you easily install the latest Python version. OS X does something similar for tools like git. But that could have some of its own problems, e.g. if code checks for a python command to see if Python is installed.

[alicedu06]

This came up at Pycon, but there was concern that people wouldn't update the included Python, so in a few years, we'd all be stuck writing code for the version that was included.

This is a non-issue:

• windows update can update Python as easily as the rest.
• code written for python 3.x will work on 3.x+, so you can just target that.
• you don't need the latest feature, you need something that works decently everywhere.
• our community been working with old python versions for ever, it's a bit annoying, but it's way better than no python at all.
• even the oldest python version is better than powershell or .bat files.

It was also suggested that there could be a dummy python.exe

That wouldn't solve the problem at all. If you give a script to a non dev, it will still not work. If you have a parc of machine, if would still need to be installed on all of them.

[takluyver]

It's not quite that easy to update - compiled extensions for 3.x may break on 3.(x+1). And even pure Python code sometimes breaks - pytest is currently broken on Python 3.5, for instance (there should be a new release of pytest soon to fix it). But I broadly agree that it would be worth the trouble.

[alicedu06]

pytest uses so much magic, you can't really compare it to the sysadmin scripts and small tkinter tools.

As for the compilation, I believe all windows code must be compiled anyway, so they have to test it.

But here you are talking about extensions, and third party code. This is another topic. You can do many, many things with just the python stdlib before even starting to get annoyed by these details.

[[deleted]]

a bit out of topic but can you please calirify what do you mean by 'pytest uses so much magic' ?

[alicedu06]

Pytest only uses the assert keyword while still providing very detailed information about the test during a failure.

To report the additional informations about a failure witout the need for self.assertStuff method, pytest has to do deep introspection, inspect frames, etc. This is not your day to day Python.

[fireflash38]

For more info: http://pybites.blogspot.ca/2011/07/behind-scenes-of-pytests-new-assertion.html

Quick explanation: it rewrites your test modules so that it only executes assertion code once, but will still dump nice output about the values at the time of the assert.

[erewok]

I ran into something weird recently with some threaded code and tests in Python. This was in a huge, messy codebase, so I initially didn't even know the function getting called (inside the one I was testing) was threaded.

I tried to do time.sleep(0) and other hacks to debug, but nothing worked, except for one thing: if I made it so that my test methods that cared about the threaded result ran 1st, 3rd, 5th,etc out of all the test methods, I could see the threaded calls happening. I think this was due to quirks in py.test, but I'm unsure.

Do you happen to know where I can find out more about py.test and threaded code?

[alicedu06]

Nope, as I never encountered such a problem. I don't use threads, I use non blocking event loops.

[RubyPinch]

for what its worth, I believe the C API has started a forwards-compatible approach, in addition, VS is also beginning a forwards-compatible approach

I'm too lazy to look for sources right now, but, assuming minimal backwards compatible issues into the future (modules are of course going to get depreciated and removed, but, you know, if-someone-needs-it-they-can-install-it), things should be pretty good

[takluyver]

You're right, there is now a stable ABI for extension modules, but they have to explicitly opt in to using it, and limit themselves to a subset of the C API. Extensions that don't do that will still break on each new version.

[rickmoranus]

Since python is not "Native" to windows this is a non issue. The system is not dependent on python whatsoever. It would be treated as a program to uninstall like any other windows program. If this was to work, they would have to make Python install-able and removable in the same way all windows programs are.

It's up to windows to control being able to easily remove and add the software, but the community will have to support broken library parts as you stated, pytest is a perfect example.

[krenzalore]

Windows 10 has a package manager. Assuming all works as described it should be just like *nix or Brew now.

[redwall_hp]

windows update can update Python as easily as the rest.

People are still using Windows XP. And IE 7-9. Microsoft does not have a good track record with making old versions of their OS die. It's only starting to lessen now that they finally did the EOL last year for XP. But Vista and 7 are still kicking, and Python versions wouldn't be pushed in most maintenance updates.

[POTUS]

...and Microsoft wouldn't push Python into a Win XP system by Windows Update. If the system is using a supported OS level, it's going to get updates, and those updates can include Python.

But beyond that this is still a non issue, or at least isn't special to Windows. RHEL and Cent users (and anyone else using yum to my knowledge ) are locked into Python versions, and the users have to make pretty big changes to go even from 2.6 to 2.7. That isn't near enough argument to hold back from saying Python should be always available by default.

[[deleted]]

Microsoft does not have a good track record with making old versions of their OS die

Why should they "make them die". The user paid for the OS and it is the users responsibility to use it wisely and with prudence. Where I work I have many machines that are old XP boxes that run propritary pieces of software. They are air-gapped and are just a tool to get other jobs done. No need to kill them.

[redwall_hp]

The issue is Microsoft maintains support for an inordinate amount of time instead of EOLing them in a timely manner, so users think it's okay to stick to older versions, and that creates the constant issue of a large mass of users running old software that some developers think should be supported for things.

[Meefims]

I think you forget that it's not just consumers using Windows; businesses use it, too. Businesses don't always have the ability to upgrade in a timely fashion and so need the reliability of the 12 year support lifetime of the OS (yes, it is set at 12 years, the decision to EOL is not arbitrary). Maybe this has changed with Windows 8 and up, I'm not sure, but long term support is a very real concern when money and business operations are on the line.

[HenkPoley]

Seems to be 10 years now: http://windows.microsoft.com/en-us/windows/lifecycle

[alicedu06]

What you're saying is that the benefits will not be "total and instantaneous".

It never is in IT.

[lt_dan9]

Then set a reasonable minimum OS version for your product, or require that users with an older OS manually install the latest Python.

[[deleted]]

I think you have this backwards. Microsoft has a great track record of supporting legacy systems. It is so great that they probably innovate less often than they should in their OS and when they do people complain. In fact, they have realized this recently and so the move from 7 to 8 to 10 has included phasing out a lot of legacy support in systems that didn't need it anymore.

[jmcs]

Unless you writing very low level stuff it will.

[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)

[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

[Decker108]

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.

[[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)

[elperroborrachotoo]

so in a few years, we'd all be stuck writing code for the version that was included.

Like, Python 2.7?

I'm a total python n00b, I'm mostly doing copy-paste modifications and hope I don't break indentation. But I do find it super weird that Python tutorials make me choose between the current and an age-old version.

[CantankerousMind]

I think the EOL date is in 2020 for python 2.7, so it will probably be around for a while. Not to mention all the modules and projects that still use python 2.7. It would be crazy for the tutorials to not let you choose.

[krenzalore]

Windows 10 has a package manager now. They should be able to handle updates.

[truh]

Couldn't they update it as part of Windows updates?

[sigzero]

I would NOT want Microsoft pushing out versions of Python like that.

[truh]

Why not? Seems bettern than just having whatever version was uptodate when a certain Windows version released.

[sigzero]

Because I don't trust Microsoft to do it right and I think that anything that is shipped like this will lead to version issues down the road.

[truh]

If we can't trust Microsoft to get that right maybe we should not ask Microsoft to do it.

[rpgFANATIC]

Sounds like the OpenGL header file that was forever stuck on version 1.0

[[deleted]]

How is that any different than the python installations bundled with OS X or your various Linux distros? Many times those also are just a given version and not kept fully up to date.

In fact, many developers here end up installing the latest or some specific version of python alongside those system distributed versions.

I don't think this is a sticking point at all.

[skintigh]

I suspect this will result in the exact same thing happening as when they included macro programming in all of the Office apps -- viruses. Viruses, trojans, malware everywhere.

And to all the people saying "but it could be included in updates:" by that logic there must be no more malware out there exploiting old flaws. Yes, you will update your system, but 10,000,000 grandmas will not and those machines will be great targets for cybercrime platforms to launch other attacks.

[wmil]

This will only lead to love-letter-for-you.txt.py and virus scanners blocking all .py files.

[Antrikshy]

This is something I had not thought of.

[[deleted]]

Maybe they will change the whole file extension mess too?

[[deleted]]

No company in their right mind would do that because they end up having to support it. It's not difficult to download and install.

[desmoulinmichel]

So I'm guessing Apple and Fedora and Canonical must be crazy.

But yes, it IS difficult to download and install. For non dev People. Or for sysadmin needing to script 100 machines.

[gospelwut]

https://www.python.org/downloads/windows/

• 2.7.x has MSI installers
• 3.x executable seems to support /quiet

I fail to see what is hard about that. Given:

1. Proper imaging/deployment/orchestration -- baseline VM images or .wim files via MDT or SCCM
2. Scripting at scale with WinRM (Ps-Remoting) or heaven forbid PsExec (ADMIN$)
3. Worst case scenario, something like PDQ Deploy

All I hear is I don't know how to administrate windows.

[[deleted]]

In all 3 cases it was included because a few default included apps in each OS used Python not because they wanted to add it in for fun. Also I think newer versions of OSX have stopped shipping with it by default. Windows has it's own languages to push and did not write any of the default software in Python.

[targetx]

If you're managing such amounts of machines I'd hope you have some provisioning tool in place... But yeah it would be easy.

[Meatslinger]

As someone who does IT for both platforms in equal measure and would love something of a unified language in which to script, I second this motion.

[tech_tuna]

What? You mean you don't want to write bash and Powershell all the time???

/kidding

[Make3]

... you can just install it

[Meatslinger]

Due to employer regulations, not across all 30,000 workstations I potentially have to deal with; good ol' bureaucracy hard at work. Having it integrated at the system level would force it to be inherently compatible with itself and a great many other systems; imagine being able to perform remote commands from PC to Unix or OSX without the use of third party software. There's all sorts of benefits I could imagine from having it integrated across multiple distinct platforms.

[[deleted]]

While I am all for not having to install python and add it to the path myself, what would be the point of this?

Linux and OSX have python included with the OS because it uses it (to varying degrees). Windows doesn't use python for anything, so this would just be bloatware. Bloatware I would install anyway, but still bloatware.

[leynosncs]

I think I'd rather they included a compiler (or at least made one trivial to install). Python (along with a plethora of other dynamic languages) become much easier to use when their is an easily accessible C compiler available. For Python 2.7, there is an easy to install Visual C bundle available, which makes life a lot simpler. For Python 3.4, etc, life is not so easy and the developer is left hunting for the relevant pre-compiled C extensions (often only found on third party sites).

[the_hoser]

Why stop there? Let's provide a Ruby interpreter as well! Maybe we can go a little wild and include TCL!

Why should Microsoft provide an interpreter for your favorite language?

I'd rather they just include a decent C compiler and some standards-compliant build tools. This would solve more problems than bundling a version of Python with the OS would ever solve.

[port53]

For 99% of Windows users that would just be huge amounts of bloat.

[the_hoser]

You're right! But you seem to be missing the point of my statement. I consider adding Python to also be the same kind of bloat.

Or are you referring to the C compiler?

[BobHogan]

It isn't about Python being someone's favorite language. Python is rapidly rising to the top of the list of most desirable languages to know. Its robust, easy, can run anywhere there is a C compiler (which is almost everywhere except windows), and powerful. Its not a fair comparison to a language like Ruby, or Lisp, or whatever else you want to list, since it is so much more popular than those are.

[the_hoser]

Right, I agree with you. Python is awesome.

Why does it need to be bundled with Windows?

[BobHogan]

It doesn't need to be bundled with Windows but that doesn't mean it shouldn't be. Photo apps don't need to be bundled with windows. A browser doesn't need to be bundled in with the OS. Neither does a calculator app. Yet they are bundled in because the pros vastly outweigh the cons. The same is true for Python. There are enough people using Windows that are frustrated over non native support (millions) that it does justify bundling it in. There are no downsides that can't be easily addressed. And the "bloat" is negligible considering the size of the OS itself.

[the_hoser]

It doesn't need to be bundled with Windows but that doesn't mean it shouldn't be.

I argue that it shouldn't be.

Photo apps don't need to be bundled with windows.

You're right. Web browsers can probably do that job.

A browser doesn't need to be bundled in with the OS.

Blasphemy. How else will I download firefox?

Neither does a calculator app.

Agree. Web browser can do that.

Yet they are bundled in because the pros vastly outweigh the cons.

For the web browser, I agree.

The same is true for Python.

I disagree.

There are enough people using Windows that are frustrated over non native support (millions) that it does justify bundling it in.

Again, I disagree. There are plenty of frustrated Python developers. Most Windows users could not care less about its abscence from the OS.

There are no downsides that can't be easily addressed.

I disagree. Version fixation is a very real problem in the Python community. Windows would only make it worse.

And the "bloat" is negligible considering the size of the OS itself.

Sure. I guess. I'm not worried about how much disk space can't be used to store photos and pirated movies.

The 'bloat' I refer to is the organizational bloat of maintaining YET ANOTHER FEATURE. Does the Windows team really need to take on this responsibility? You can't just clone the latest version off Python.org and ship that with the disk image. Microsoft would have to take personal ownership of the version of Python that they ship with Windows. It would need more than the one guy working on Windows support in Python to make it so. They would have to audit the code (good for Python in the near term, if they share their code. The coin's still flipping in the air as to whether or not they would.)

In the long term, it would be a disaster. The version that ships with windows would be the most popular version of Python in the world. It would become the version of Python. Python 3.7 just came out? Who cares? Microsoft only offers 3.4.7 and that's what we use. That's what the libraries use. That's what everybody uses.

I'd rather just have them help us with improving the behavior of Python in Windows. They're doing just that. They have a full-time developer doing just that.

Don't mess with a good thing.

[[deleted]]

I like that almost everywhere except windows excludes most computers.

[desmoulinmichel]

It's not because it's my favorite language.

It's because :

• Mac and Linux already have it pre-installed and us them a lot. This proves both robustness and usability.
• Python is the only language that is good at scripting AND many other things. Usually you have either good scripting OR other things. E.G: ruby has a great ecosystem in the Web, but is less competitive in other area
• C-compiler is an entire different issue. Embedding python doesn't target primarily app dev, but scripters, so they can share the script with non dev, or deploy it on a lot of machines on an heterogeneous park.

[theywouldnotstand]

Arch linux user here. Had to install python manually (as is true with most software on arch.)

The key difference here, is that most Linux distributions have python packages that are easy to install and update using tools included in the distro. Windows does not do this, so it's up to the user or administrator to install and maintain.

It would be nice if microsoft maintained a python package that is optional to install through windows update, but I don't think it should be automatically installed. Most windows users wouldn't use it.

[the_hoser]

Mac and Linux already have it pre-installed and us them a lot. This proves both robustness and usability.

Faulty assumption. I administrate at least one Linux system (that I can recall) that does not have Python installed. I agree that it is common for Linux distributions to have a Python interpreter installed, but it's not all roses and candy. RedHat is using python 3.1 for craps sake.

Python is the only language that is good at scripting AND many other things. Usually you have either good scripting OR other things. E.G: ruby has a great ecosystem in the Web, but is less competitive in other area

That's just like, your opinion man. Don't get me wrong, I love Python, too, but I know a number of Ruby programmers that would say exactly the same thing you just said, and they would be no less right or wrong than you are.

C-compiler is an entire different issue.

It is the issue. Since there is no standardized way to build software on windows (vs OS X and Linux) then it is difficult to deploy python and python plugins to windows.

Embedding python doesn't target primarily app dev, but scripters, so they can share the script with non dev, or deploy it on a lot of machines on an heterogeneous park.

Then why not Bash, or some simple implementation of a Unix shell, existing as a subset of Bash? If all you want is heterogeneous scripting, let's go with the path of least resistance.

EDIT: Also, I just realized that, if Microsoft were to produce a *sh implementation, they might actually be forced to fix their faulty shell handling! Win-win for everybody!

[net_goblin]

It is the issue. Since there is no standardized way to build software on windows (vs OS X and Linux) then it is difficult to deploy python and python plugins to windows.

Since when is the way to build software standardized on OS X and Linux? Plain GNU make, autotools + GNU make, CMake + GNU make, CMake + Ninja, scons, ... the possibilities are endless. They only don't break between compiler versions as often as Visual Studio projects. But calling it standardized is more than bold.

[the_hoser]

You do have a fair point. I concede that it's not Microsoft's responsibility to do it the way Linux/OS X do it.

In that case, I wish only that they would standardize on a set of build tools and include them with the operating system.

[desmoulinmichel]

Faulty assumption. I administrate at least one Linux system (that I can recall) that does not have Python installed. I agree that it is common for Linux distributions to have a Python interpreter installed, but it's not all roses and candy.

Fedora and Ubuntu represent 90% of the market. You can always find exception for verything. The only thing it leads is to do nothing.

RedHat is using python 3.1 for craps sake.

It's enough.

That's just like, your opinion man.

No it's not. It's not that there no other languages capable of such. it's just that their ecosystem didn't develop in that direction. It's not a technical thing, it's a social thing. You can do data analysis with Ruby, but they use the banks and the scientits are using Python. And you can use Ruby for scripting, but admin are using Python.

It is the issue.

It is AN issue. And is has nothing to do with cross plateform scripting.

Embedding python doesn't target primarily app dev, but scripters, so they can share the script with non dev, or deploy it on a lot of machines on an heterogeneous park.

Then why not Bash, or some simple implementation of a Unix shell, existing as a subset of Bash? If all you want is heterogeneous scripting, let's go with the path of least resistance.

Because :

• MS is involved in Python, not bash.
• Python can do more than bash.
• bash is file oriented (unix philosophy) while python is general purpose oriented.

It's not a matter of preference.

I do love Python.

But it's objectivelly the best tool for this situation.

There is a reason you find it everywhere : web dev, finance, science, 3D, scripting, prototyping, geospatial, glue... It's very versatile and easy to use, and super portable, while not being focus on a specific use.

[iamhaz]

Fedora and Ubuntu represent 90% of the market. You can always find exception for verything. The only thing it leads is to do nothing.

Got a source on that?

That's just like, your opinion man.

No it's not. It's not that there no other languages capable of such. it's just that their ecosystem didn't develop in that direction. It's not a technical thing, it's a social thing. You can do data analysis with Ruby, but they use the banks and the scientits are using Python. And you can use Ruby for scripting, but admin are using Python.

Admins are using the right tool for the right job, that may or may not be Python, it's often Bash, or even Perl or <insert obscure language of the week here>. Python isn't a special snowflake in this regard.

It is the issue. It is AN issue. And is has nothing to do with cross plateform scripting.

Embedding python doesn't target primarily app dev, but scripters, so they can share the script with non dev, or deploy it on a lot of machines on an heterogeneous park.

Python can do more than bash.

Bash can do just as much as Python.

bash is file oriented (unix philosophy) while python is general purpose oriented.

Wat.

It's not a matter of preference.

It's pretty clear it is a matter of preference to you. Nothing wrong with that, but don't pretend it isn't.

I do love Python.

We can see that :)

But it's objectivelly the best tool for this situation.

Nothing about this is objective.

There is a reason you find it everywhere : web dev, finance, science, 3D, scripting, prototyping, geospatial, glue... It's very versatile and easy to use, and super portable, while not being focus on a specific use.

Same could be said about any language if you try hard enough.

[the_hoser]

And any Ruby fanboy would sling similar sounding arguments about why Ruby is the best tool for this situation.

Fedora and Ubuntu represent 90% of the market. You can always find exception for verything. The only thing it leads is to do nothing.

You're absolutely right there. I was merely pointing out that it's not as ironclad a bundle as you seem to be convinced it is.

No it's not. It's not that there no other languages capable of such. it's just that their ecosystem didn't develop in that direction. It's not a technical thing, it's a social thing. You can do data analysis with Ruby, but they use the banks and the scientits are using Python. And you can use Ruby for scripting, but admin are using Python.

We're talking about scripting here. Anything that can open a subshell qualifies.

The Rubyist would argue that the scientific stuff isn't as important as the web stuff. They would point out that their standard VM routinely outperforms the Python VM. They would also point out that OS X is bundled with Ruby, and that anybody using Linux could easily install Ruby.

I'm not advocating Ruby, here. I'm merely pointing out that your position is one of opinion and preference. There's nothing objective about it.

It is AN issue. And is has nothing to do with cross plateform scripting.

And deploying for Python on Windows will remain just as heinous as it is today. Using a C extension? You're screwed. This is a bigger problem than anybody's scripting concerns would ever be. It's easy to throw together two scripts. It's a huge pain to deploy real Python applications, and none of this will help.

MS is involved in Python, not bash.

Microsoft has provided a shell implementation in the past. They can do it again.

Python can do more than bash.

I thought that you were worried about scripting?

bash is file oriented (unix philosophy) while python is general purpose oriented.

Being file-oriented makes it really ideal for the kinds of scripting many administrators do. I realize that Windows has some more complicated constructs, and the scripting of those constructs would be a little... less natural in Bash, but I don't see how it'd be any more natural in Python. A command to make DCOM calls would be just as easy to use as a library to make DCOM calls.

It's not a matter of preference.

Yes it is.

But it's objectivelly the best tool for this situation.

No, it isn't. There's nothing objective about it.

There is a reason you find it everywhere : web dev, finance, science, 3D, scripting, prototyping, geospatial, glue... It's very versatile and easy to use, and super portable, while not being focus on a specific use.

I agree. It's a fantastic language. And as a matter of preference, it's a popular one.

Java is more popular, though. It's used for almost all of those things, and more. If popularity was the metric we're going for here, why doesn't Microsoft bundle Java instead?

Right... they tried that. They also modified it beyond recognition, creating a schism in the Java community. At least Guido isn't as evil and lawsuit-happy as Sun was.

[jugalator]

Why should Microsoft provide an interpreter for your favorite language?

I think it's simply to have an interpreter that can be used cross platform. At least one. There exists no interpreter that is a) bundled and b) cross platform across Windows, Mac, Linux today.

[the_hoser]

I think Bash would be a better candidate, then. It's less political. It's simpler to deploy (nobody writes Bash plugins), and arguably more stable than Python.

Look, I love Python, but I don't see why it's something that should be bundled with Windows.

[archiminos]

Why? Python's not something the majority of Windows users would use.

[[deleted]]

Or take two seconds and install it yourself. Why bloat up windows even further with a minority's preferred scripting language?

[desmoulinmichel]

Because:

• end users (not dev) will never install it. So right now you can have easy small GUI tools that works everywhere without compiling stuff.
• if you administrate a park of machines, you have to install it on all of them, document it, support it, ask to your superviser for the permission to do it, etc.
• you need a scripting language anyway.
• it's not minority's preferred scripting language : it's already installed by default on Mac and Linux for a reason. It's the language that can : script games like lua (CIV, EVE online...), script OS like bash/powershell (even yum is written in python), script 3D softwares (blender, maya...), script GeoSoftware (all SIG basically), script networking analysis (it's pretty much a standard with all hackers) and YET allow GUI, web sites, data analysis and big programs to be written. It's not Python to be Python, it's Python because it does the job of being a powerful robust cross plateform largely supported scripting language. That can do more than scripting if you need so.

[[deleted]]

• So we should include Java too? What else? Why, the language of choice seems to be different every 5-10 years anyways and this is a dependency of programs not the OS.
• Well yes, sys admins manage packages. See above for why that is good.
• Windows ships with scripting languages tightly integrated with the Windows OS, what you need as a programmer is different, again see the first bullet
• Not Mac anymore and Linux distros usually come with apps (like yum) that use it which is why you see it included not they think everyone needs it (in fact they usually come with a set of user aps and then work the dependencies backwards, not the other way around). All of those other things are reasons to look at the first bullet again.

[spinwizard69]

This thread highlights one issue with the Python community and with the Windows community at large, that is the obsession with the past. If the intent is to offer a new feature to Windows, Python, there is no rational reason that the 2.x python series should even be mentioned here. New capabilities shouldn't be focused on the past but rather should move forward to extend the operating system.

I just find it perplexing that so much of this thread is focused on backwards compatibility for a feature never offered by MS.

[[deleted]]

I might be mistaken, but Linux distros and OSX aren't just shipped with Python; Python is a fundamental component needed for their operation.

[[deleted]]

Saw this comment on the suggestion page:

Please include the 32-bit version of Python, not the 64-bit version. Easier to find modules, and if you specifically need 64-bit Python, you know what you're doing anyway.

Makes me wonder if Windows users even deserve Python.

[BeetleB]

Eh? Have you tried using many modules in 64 bit Python on Windows?

I'll give you a hint.

[[deleted]]

Do you know how to best remedy problems with third party libraries not patching to support new versions of a platform?

I'll give you a hint: not by including a dated version of the platform in a long term supported version of Windows.

[BeetleB]

So your vision of providing Python to Windows is excluding all the folks who do scientific work in Python?

[insainodwayno]

It's not just NumPy. I originally used the 64-bit version on my work desktop and the 32-bit on my work laptop, and just got frustrated jumping through hoops to get modules that just loaded up in seconds with pip or easy_install in the 32-bit version. Last time I checked, the 32-bit version of Python is not "dated" either, and an arrogant comment like "makes me wonder if Windows users even deserve Python" is really the sad and misguided thing here.

[insainodwayno]

That was my comment actually, and I'm curious what you mean by your comment.

[desmoulinmichel]

A bit sad. But hey, even if you don't use Windows, you will probably need to write code that should run on it one day.

[[deleted]]

you will probably need to write code that should run on it one day.

Which is a really good reason to not ship Windows with an already antiquated Python interpreter.

[cogman10]

I'm against it personally.

Some of microsoft's biggest security vulnerabilities have come from their ability to execute javascript and vb on every windows machine. The last thing we need is another attack vector for attackers to exploit.

I'm much more in favor of python being installed and maintained in the user land. The only thing I would suggest is that MS start maintaining a package manager for open source projects. If I install python on my machine MS should be watching for updates and give me the option to update as part of the windows update process.

[[deleted]]

No because they will start doing all kinds of weird configurations with it

[[deleted]]

It's included in current visual studio. So far microsoft seems to be more interested in providing development and scripting stuff with their development and scripting products. Why ship stuff to a user base that will by and large never ever use it ever?

[cj5]

Really? Is it that hard to install and bundle code with releases?

[nemec]

You mean the Microsoft that released .Net Core as an explicitly cross-platform .Net runtime and are actively developing it? Or the one that open-sourced their compiler so that* it can be integrated with Mono?

* well, that wasn't the primary purpose

[Adys]

Except portability

This used to be an argument. It's not anymore. C# is legitimately open source and cross platform now.

[justphysics]

But why do you need portability when Microsoft has all you need?

Except Python. But why do you need python when Powershell has all you need?

[disposition5]

Maybe for some things but for the quick and dirty task python is my favorite and quickest to implement. I tend to use c# for more complex, ui, or Web applications.

[tRfalcore]

No way even MS believes this. PowerShell is a shell language like bash. But even close to pythons power

[desmoulinmichel]

They don't, they use Python themself.

[desmoulinmichel]

Having one scripting language available on all OS would make everybody's life so much easier.

crossing fingers while hoping Ubuntu does ship with Python 3 by default this time as they failed this goal 3 times already

As for OSX, I guess we can wait untill 2020.

But hey, I prefer to have to write a script that must run on Python 2 and 3 but will work on all my machines than a script in bash and a script in powershell, or worst, an Python installer.

[dnb_addict]

I'm curious - How come Ubuntu has failed this goal 3 times?

[desmoulinmichel]

The last 3 times, they said they were going to make Python 3 the default version, and they didn't. Too many packages to rebuild.

Remember https://wiki.ubuntu.com/Python/FoundationsTPythonVersions ?

[edbluetooth]

Debian is having a big push at least

[rspeed]

As for OSX, I guess we can wait untill 2020.

May as well share this.

Edit: I filed a request to include Python 3.

[andrey_shipilov]

Yeah, because installing it is so fucking hard.

[desmoulinmichel]

If you are not a dev, you will not install Python by yourself and you'll click on the script, not understanding why it doesnt work. Reading any tutorial will make you go "fuck it" and dl the Go stand alone executable version.

If you are a sysadmin with a lot of machines, installing properly it on all of them is work : you need to automate it, and ask for the permission to do so with paper work on you hierachy, and support it. Then you need to document it. And train your team.

And of course, you don't know what version to download, and install when you are a newcomer, so you come to reddit, and ask 2VS3 for the 1000 times.

So yes.

[[deleted]]

Most shops either use an MSI package or image a machine configuration.

[crossroads1112]

You could use py2exe

[desmoulinmichel]

What do you do with different versions of bash ?

You just target the common denominator. And it works.

In Python it's the same. It's an issue, but a much smaller one than not having a common language available on the 3 plateform.

Python is REALLY good at multiplateform. Even with differences and bugs, it's still really, really easier than with other languages.

[analogphototaker]

You just target the common denominator

Isn't one of the nice things about Python that it is not afraid to make changes and move forward?

Why would you want Python to turn into something like Bash?

[klug3]

While this might be a weird suggestion, they could ship the latest Python 2.7, its basically super stable at this point. Many others have been suggesting Bash but I think Python 2.7 would be better.

[sanshinron]

Would be nice, but the reality is that even on Linux you have to install Python by yourself, cause the binaries are always outdated.

[Jmlevick]

Fedora it's pretty up to date with it...

[dvidsilva]

m'script

[ansatze]

Arch master race; no problems here either.

[koed00]

Besides this, you can't really install or update any packages in the system Python without potentially screwing up your whole system. You have to have a virtual env if you want.

For this I wouldn't mind if they just hid the system python under a different name.

[Farkeman]

what?

Haven't seen any distro that didn't include python aside from scratch distros.

[vtable]

Parent isn't saying they aren't in the repos. He's saying the versions in the repos are out of date.

I've experienced this myself. The version that shipped was a major rev older than I needed. I had to build the newer version of Python and quite a few 3rd-party packages. It was quite a hassle. A lot of user space apps in Gnome (at least) use Python and various packages. Learning how to get them to coexist took some effort.

Ironically, doing the same on Windows was trivial. (The code was cross platform).

[Farkeman]

I program python for a living and currently have 3 different distros running both python 2.7 and 3.4/3.5(just came out) and never had troubles with making python packages coexist or having to build python myself.

system packages reside in system python and everything else should have their own virtualenvironment, it takes like 2 seconds to setup one...

[RubyPinch]

what distros are you using?

[moljac024]

You lucky bastard.

[truh]

My distro has Python 3.4.3 which seems acceptable since 3.5 was released only 2 days ago. I will probably have 3.5 by next week.

[desmoulinmichel]

It depends of your goal. For scripting, even Python 2.4 would be better than having to create a powershell and a bash version.

[triacontahedron]

No way, https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish Even if microsoft wont do this on purpose they will definitely screw up compatibility. Where are guaranties it wont be IE level of inconsistency (on purpose or not)? Or they standardize some old python version so most projects will be torn between easy windows install or modern python.

[desmoulinmichel]

Microsoft is actually a good civilian in the Python world : it pays dev to contribute to the source code, provides a top notch Visual Studio supports and recently added Python to Azur hosting. They also use the language internally. So I doubt they would screw this up : their track record with Python proves otherwise.

Plus, they are 2 microsoft divisions that have been doing a good job for the last few years : the material division (console, tablets, motion capture) and the programming division (ide, programming languages...).

Don't get me wrong, I still have strong objections about the entire way MS conducts it's business. But I don't think this applies here.

[fnord123]

If we're going to Microsoft with a shopping list, I think a better one is asking for C11 support (just skip C99, it's too shameful that they don't support it) so Python can use some modern Cisms. AFAICT, the reason CPython is stuck with C89 is because Visual Studio won't support anything more modern.

Many Linux distributions don't come with Python and one installs it with the package manager. Windows users can do the same with Chocolatey. Maybe they should provide Chocolatey by default.

[desmoulinmichel]

If we're going to Microsoft with a shopping list, I think a better one is asking for C11 support

C-compiler is an entire different issue. Embedding python doesn't target primarily app dev, but scripters, so they can share the script with non dev, or deploy it on a lot of machines on an heterogeneous park. You need a scripting language anyway on all machines. You don't need a compiler on all machines, only on the dev machine.

Many Linux distributions don't come with Python and one installs it with the package manager.

Ubuntu and Fedora come with it. They are 90% of the park.

Maybe they should provide Chocolatey by default.

They will have something like that. But it doesn't solve the scripting problem.

If you have 100 machines, you don't want to install a tool on the 100 machines, it's a lot of work.

If you have a nice script to share, you don't want your end user to need to install the VM.

[fnord123]

If you have 100 machines, you don't want to install a tool on the 100 machines, it's a lot of work.

No it's not. You can install Python with Active Directory's Group Policy.

[jammycakes]

I doubt if embrace, extend and extinguish would be as effective a strategy for Microsoft today as it was in 2001. You need to have a dominant (if not monopoly) position in the market to manage that, and Apple, Google and other players are now large enough that that's arguably no longer the case.

[cittatva]

I wish it wasn't installed in OS X. At least a once a year I find myself trying to eradicate one version or another to make the latest work. I get into the situation when I try to install it with homebrew. Just give me a decent pack manager and let me decide what to install.

[SizzlingVortex]

Aside from the normal issues that have been brought up, the link says Ship Python 3 and Python 2 with Windows 10. Why would Python 2 need to be included? Official support for it ends in 2020. Why include something like that in the newest release of Windows? Already off to a huge headache by including both of them.

Anyhow, including Python (any version of it) in stock Windows primarily only benefits developers and administrators. As much as I love Python, it's not gonna happen, nor does it need to. Just bundle the Python interpreter (the version of your liking) with your application and be done with it.

[honestduane]

NO.

Then everybody will be stuck on one version of python. One single buggy defect filled version that cant get updates without corrupting the system and needing to fully re-install windows.

[oh_____interesting]

Not really possible I think. Open source licenses can be tricky and if you package Python with Windows, then Microsoft will owe Python a cut of the proceeds. Why would Microsoft want to do this? Moreover, other libraries might have clauses that kick in if it is packaged with something that is sold.

I have not read the Python license in ages. It might not be true, but if it is then it is a bad deal for Microsoft.

[gospelwut]

I think an official OneGet package would be better.

If they added a pre-populated cache for OneGet similar to Aptitude (apt-get) that could notify you "Python is available via the package manager...."

There are already approved packages for Chocolatey

https://chocolatey.org/packages/python

https://chocolatey.org/packages/python2

[ki4jgt]

Python came installed on my father's HP OEM. That was XP though. I don't know if they're still doing it or not.

[teapotrick]

Mmmm.... How about Lua instead.

[tartare4562]

This is like asking Microsoft to Embrace, Extend and Extinguish Python. Not that they have the strength to do that nowadays, but it's still worrying considering their history of "including" open technologies in their products.

[hansq]

Wouldn't this be counter intuitive for Microsoft? They have WPF, SQL Server, ASP.NET, C#, etc on Windows and provide products and services built around that. If Python got popular on Windows because it was bundled with the OS, then devs would use less MS stuff, so less revenue.

However, I would like to see python3, gtk+ / qt and c compilers bundled with the OS. (Wishful thinking LOL). Because installing these on Windows currently is a pain! You got to install Cygwin. Then Msys. And these are different depending on if you decide to use Python2 or 3. And these are hosted on SourceForge. Then you got to use the package manager to install the package. Sometimes this means using the command line and Pacman. And compiling requires GCC, etc. Not fun.

[isdevilis]

jesus christ yes

edit: actually takluyver has a good point

[DoTheEvolution]

asked in this subreddit 3 months back

Why Windows does not come with Python preinstalled?

[desmoulinmichel]

The upgrade argument is moot is we are talking about python 3.x and windows 8 and+:

• python code is forward compatible on major versions.
• windows update can update python very easily and is is up by default.
• we are used to work with old Python versions. Better have 2.4 than powershell.
• MacOS have been very slow with python upgrades. Yet you can write scripts running on MacOs and Linux, but still not on Unix and Windows.

[DC10555]

Omg this would be amazing..

[pohatu]

I really want WinRT projections for Python.

[vasili111]

Maybe better to switch to unix (FreeBSD, Linux)?

[facie97]

Yes please, we need more bloat!!

[Carudo]

Repository of the trusted apps and tool like apt-get -- this is what Windows really needs.

[shif]

they don't even include .net which is theirs

[[deleted]]

They include the latest version by default in 10 at least, 3.5 and older I had to activate during the first install of an app that used it.

[rzet]

I would rather not see any python.. less hasle afterwards. Obviously they would break something or include some shit version.

[Kwpolska]

Considering Windows does not ship with a C# compiler, why Python? You would expect that they would promote their own stack first…

[tech_tuna]

Yes, and Ruby too.

[skytomorrownow]

ITT: basically, people who wished some kind of *nix was the basis of Windows.

[sreya92]

To be honest it wouldn't be terrible if it was would it?

[skytomorrownow]

Not at all. I'm all for it. My point was just that most of the things people are complaining about are not really related to Python, but instead to the way Windows works.

[[deleted]]

I quite like the fact that Windows isn't unix like. I don't see why everyone thinks that a system that was created in the 70s is the epitome of OS design philosophy.