Python in the Windows 10 May update
devblogs.microsoft.com
devblogs.microsoft.com
Only if your system isn't getting any updates. It would be up to Apple to provide a recent version.
But more broadly speaking, I'm not sure that's going to be enough. Even if you're using virtualenv's, having something installed at the system level means it's shared by all the software you're using. There's bound to be some incompatibility eventually. And then you're stuck waiting for one piece of software to support the latest version of Python. So, you have to keep putting off updates.
I think a better solution is to use something to set the python version for each program (ex. pyenv or docker).
(This was on a Ubuntu LTS system)
It's really not hard. I do this with other compilers and don't really have issues, though I tend to package it up into a container if I'm going to ship it (e.g. build environment for a team, interpretor for a production service, etc).
This stuff is definitely quite new, and I guess the need for it has risen as a consequence of all the great new features that have shipped in Python during the last few years.
I recently had to write an utility script in Python. I chose to use Python 3 and type hints syntax, requiring at least Python 3.6. This was a problem when I realized some of my team use Ubuntu and Debian versions that ship with Python 3.5 (not to speak of Macs with Python 2.x, but these guys use homebrew anyway). Plenty of time was spent researching virtual environments and writing deployment instructions, and I ended up using pip in pyenv (but stopped short of using pipenv, since creating private distributable packages with it seemed convoluted.)
Not to mention there are other distribution tools to acquire a pre-built python release other than installing a .deb.
https://docs.python-guide.org/starting/install3/linux/
~ $ docker run -it --rm ubuntu:xenial
root@b8cda311d766:/# apt-get update -qqy
root@b8cda311d766:/# apt-get install -qqy software-properties-common
…
root@b8cda311d766:/# add-apt-repository --yes ppa:deadsnakes/ppa
gpg: keyring `/tmp/tmpe354n0av/secring.gpg' created
gpg: keyring `/tmp/tmpe354n0av/pubring.gpg' created
gpg: requesting key 6A755776 from hkp server keyserver.ubuntu.com
gpg: /tmp/tmpe354n0av/trustdb.gpg: trustdb created
gpg: key 6A755776: public key "Launchpad PPA for deadsnakes" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
OK
root@b8cda311d766:/# apt-get update -qqy
root@b8cda311d766:/# apt-get install -qqy python3.7
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package libpython3.7-minimal:amd64.
(Reading database ... 7603 files and directories currently installed.)
Preparing to unpack .../libpython3.7-minimal_3.7.3-1+xenial1_amd64.deb ...
Unpacking libpython3.7-minimal:amd64 (3.7.3-1+xenial1) ...
Selecting previously unselected package python3.7-minimal.
Preparing to unpack .../python3.7-minimal_3.7.3-1+xenial1_amd64.deb ...
Unpacking python3.7-minimal (3.7.3-1+xenial1) ...
Selecting previously unselected package libpython3.7-stdlib:amd64.
Preparing to unpack .../libpython3.7-stdlib_3.7.3-1+xenial1_amd64.deb ...
Unpacking libpython3.7-stdlib:amd64 (3.7.3-1+xenial1) ...
Selecting previously unselected package python3.7-lib2to3.
Preparing to unpack .../python3.7-lib2to3_3.7.3-1+xenial1_all.deb ...
Unpacking python3.7-lib2to3 (3.7.3-1+xenial1) ...
Selecting previously unselected package python3.7-distutils.
Preparing to unpack .../python3.7-distutils_3.7.3-1+xenial1_all.deb ...
Unpacking python3.7-distutils (3.7.3-1+xenial1) ...
Selecting previously unselected package python3.7.
Preparing to unpack .../python3.7_3.7.3-1+xenial1_amd64.deb ...
Unpacking python3.7 (3.7.3-1+xenial1) ...
Processing triggers for mime-support (3.59ubuntu1) ...
Setting up libpython3.7-minimal:amd64 (3.7.3-1+xenial1) ...
Setting up python3.7-minimal (3.7.3-1+xenial1) ...
Setting up libpython3.7-stdlib:amd64 (3.7.3-1+xenial1) ...
Setting up python3.7-lib2to3 (3.7.3-1+xenial1) ...
Setting up python3.7-distutils (3.7.3-1+xenial1) ...
Setting up python3.7 (3.7.3-1+xenial1) ...
root@b8cda311d766:/# python3.7
Python 3.7.3 (default, Mar 26 2019, 01:59:45)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
root@b8cda311d766:/# exit
~ $There is a lot of work in this area going on now, though. I think RHEL 8's application streams concept is pretty good: https://developers.redhat.com/blog/2019/05/07/what-no-python...
Fedora has an analogue to this as well. It seems like a good move in the right direction.
Figuring out how to establish a build environment for any program you want to install really can't be the best way to do things.
Maybe one day we'll take the lessons learned and natively build them into the OS, but distros are still obsessed with distro-specific kludges that require extra packaging work.
We have great universal packaging when it comes from the community at large, but not from single organizations. Pip is a platform-independent package manager! Why don't we have that for Linux software in general? Because each distro already has their own solution, and they won't work together to build a common one.
You may be right, but I don't think you should be quite so cynical.
18.04 has a ten year Long Term Support, and Ubuntu was first released in 2004.
By this logic, GNOME should have died a long time ago.
Focusing on the desktop makes Flatpak better at managing desktop apps. For servers we have, well, Docker.
I'd say yes, the coupling of operating system and distribution of software applications has always seemed very wrong to me.
Software should run on the operating system which functions as a platform, not be coupled with the operating system. Linux package management essentially works like an app store with the additional burden of maintenance loaded on the distribution owners. I'd be very happy if flatpaks and snaps take off quickly because distribution agnostic up to date software, maintained by the developer, should be the norm.
I agree with this in principle, but how far down the chain do you go? Obviously, you need to have some base libraries included. You just need to accept that some of those libraries will be old, and that they aren't going to change so rapidly for this to be a problem.
It has nothing to do with Apple scenario where system included interpreter is vendor supported and used by other OS components, this is just a built in shortcut for the store version if python is not installed.
These tools aren't (or at least shouldn't be) only meant for professional engineers.
What? The reason to use the distro-provided python package is because it's maintained by someone and gets you security updates. If Apple is just shipping a version and never bug fixing that version, well Apple sucks.
As it happens with Python, they do micro releases which other upstream projects might not. But, those releases might take longer than, say, a Linux distro might to get the fixes out to their users. So, while developing on an upstream codebase might be nice, what you need to focus on is the deployment lifecycle of your project.
I use virtualenv. When I was first learning to program, and I believe python is a better choice for a first language than PHP or Javascript, it would have been a substantial obstacle to have to do the virtualenv route first. Yeah, it's easy if you've done it and know how to figure out what the problem is if something goes wrong. It's an obstacle if you're just starting out, and I think keeping the on-ramp simple is very important for the long-term health of a language community.
Which suggests that, because python's on-ramp just got easier, it's long-term prospects just got better.
What I'm saying is that bundling a specific Python interpreter and separate package environment should be the default. I'm not sure what it'd take to get there for a vanilla python install. But more system-level interpreters is not it.
Currently, the way I know of to do that is pyenv [0]. And I know PyCharm let's you pick a python version when you start a project (though I don't use pycharm so that may not be true anymore).
though ironically in a very unpythonic way there are a bunch of these python environment creators. (conda, virulenv , pipenv....)
pycharm lets you select you favorite, which is pretty nice.
I’m a seasoned programmer and I absolutely hate how you’re forced to use VirtualEnv with python. One of the absolutely biggest warts of its already poor package-management.
It literally makes everything which should be simple, something you suddenly need to handle. Atrocious.
I like it much better like .Net, Node or Rust (and many others) where the dependencies are entirely handled within a project, completely obsoleting the need for a hack solution like virtualenvs in the first place.
Even now for many languages I shy away from installing globally (I usually install to user if I'm lazy). I feel like in almost any language a "project" (venv) should be taught early on and be simple to use. Basically, the first time you need a third-party module. I feel like newcomers should be shown the REPL, how to save code to a file and run it, standard libraries, then a workspace and how libraries work. Python could be a great example because of the batteries-included model I don't need external libraries for many tasks.
I would like to reverse the question. If you can't install a virtualenv as step 1, the process of creating a virtualenv is simply too difficult and should be streamlined.
But then I remember one scene in high school. I was talking to a friend who coded in IB American History and asked him how to get started with Python. He said just go to this website and download this tarball. I had no idea what a tarball was and was afraid it contained something bad. So I didn't download it and didn't play with Python until a few years later in college. If I had started playing with Python earlier, my life could be a lot different. I was not a guy back then who made programs on TI-84 calculators; I thought that was magic. I was planning on econ/finance. I used Windows (!) and didn't know anything about what Unix was, and barely knew about OS X.
It's hard to see why some decisions pan out and some don't; if you install a system version of Python how would the general public / PSF know how many people use it? But I don't think that's a good enough reason to remove system installs entirely. I think my younger self would have liked it.
How come you didn't start playing with the TI-84 programming language instead?
There's no more "battery included" than that, and it's not a pun only: you can program and run on the calculator (not a GREAT way to program it, but quite a nice way to spend your time instead of paying attention to the class :^) ) if you bought it new I guess you had a paper manual for the language (I had one for my TI-89), and there's so little you need to learn and take care of (libraries, dependencies, versions, execution bit, paths... None of these are an issue the novice user will be confronted with. It's like a C64 all over again).
People wondering why you didn't just power through your doubts may be forgetting what the world was like not too long ago. 'Nerds' weren't cool. If you chose to be a nerd it meant _offering_ yourself up as the _loser_ in every sitcom, movie, or book. Playing video games was something you were supposed to grow out of. No one was throwing 80k at a graduate just because they could pronounce 'WWW'. Perhaps most importantly, _every_ school was pushing the race to no where. If you were thinking about a 'trade' it meant you had given up and would crack out fixing sinks for the rest of your life. At _best_ computers were taught as something you'd use at other careers. Not a career itself, really.
* Please note the last line is less an insult to plumbers and more a commentary on how the perception of success is hammered into you as a very white collar thing.
Ubiquitous access to these tools provides wonderful opportunities, and the drawbacks are minimal.
However, the software distribution model right now is fundamentally broken. And I do not think it is worth leaving broken simply because it makes learning easier for some people.
In general, I think the decision to push people to tie their app less to the system configuration and rely on virtualenv, containers etc more is a good move in the long run.
What about people who dip their toes in Python, then switch to another language? What about people who want to just replace their VBScript integrations with Excel and don't care about Python beyond 1-2 dependencies on local? You'd just push them back towards the less optimum situation.
Oh, and I just remembered, Windows 10 Home Edition does not ship with a hypervisor. You can't run Docker on Windows without Windows 10 Professional. That screwed my team over at a data science hackathon once.
If you're at the point where you're worrying about distribution environments, you're probably ahead of most people already, and you have the wherewithal to figure out what the state-of-the-art is in packaging and distribution, whatever that may be and regardless of how broken it is.
I think a big difference here is expectations: the Apple way is to have the tool itself installed, which creates various expectations with respect to presence and capabilities (or the lack thereof).
Because microsoft only adds a hook / stub, there's no expectations that the tool will be present (as by default it's not), it just makes it easier to enable the tool.
That's how Apple does it. Ubuntu LTS, Debian Stable, CoreOS/Redhat, etc, are useful because the old versions of the software are maintained. Though Windows has not traditionally bundled GNU or Open Source packages, it is also built with a strong commitment to long term maintenance: consider Notepad,MSPaint, and .NET.
Microsoft is including Python 3.7 which has planned support until at least 2023 and possibly 2026 https://www.python.org/dev/peps/pep-0537/#lifespan
Also, as the post sort of points out, this is being built by the Python community itself (rather than by Microsoft directly; contrasting with the distro model), using mostly the same CI/build infrastructure they already use for the builds at python.org and presumably may be as up to date as the Python team wishes it to be.
There goes probably 10% of the software I can apt-get install.
On the other hand, if you can bundle dependencies with your code, you are sure that a certain version of the language will be present and to some degree, you can just rely on that.
No one seems to have a problem with that if it's bash.
You definitely shouldn't be willy-nilly modifying the environment of system interpreters, but relying on them for ops-like uses and bootstrapping dev environments is sensible.
i guess Microsoft agrees with you
Why can't Apple just install a few languages and keep up with them? It will basically kill them on the platform if they're not in common use. I suspect the people making these decisions believe it's good for apple's brand, but I think it will lead to an inward-looking insular culture.
On Macs and Linux I can still use the bc command instead (it’s an old Unix command) but it’s far less handy than Python. See the bc man page.
There’s also dc, the even less used, reverse Polish notation calculator. It is a standard Unix command that predates bc.
Interestingly, the dc “language” is older than C, Awk, Perl, or any other programming language still found on Unix systems. It is implemented in C’s predecessor, the language B.
You can tell that bc and dc are early Unix commands from their names, many of the oldest Unix commands are just two characters long.
The ability to use variables, math functions, lists, loops, and completion in Python will likely keep me using it as my basic calculator. Although I need to figure out a way to edit my REPL history to fix typos better.
Why do you do math on random people's laptops?
In my own office I use perhaps a dozen machines. Servers running FreeBSD, OpenBSD, or Linux. Linux, Windows, and Mac desktops and laptops. Few are actually set up as Python development machines (those of course have recent Python installed), but having a ubiquitous tool for simple calculations (or even short scripts) is quite handy on all of the others.
My work might not be typical: I have been programming for over half a century and I started making use of Python for simple programs in the Python 1.2 time frame around 20 years ago. I'm not really a Python developer, but I appreciate it as a useful tool--even as a keyboard driven calculator.
Also available on macs/linux and most unixes. e.g.:
$echo '1/2' | bc
0
$ echo '1/2' | bc -l
.50000000000000000000
though honestlyI usually just type bc -l you enter into an interactive calculator similar to python.
Now we just need a better bundled IDE. Idle is a horrible first editor, but the added burden of installing a better IDE means it's the one most often used by beginners.
Learning to code is hard enough, without having to learn a new software UI, especially if all you've ever done on a computer is browse Facebook and write Word documents.
If you want a great example of a beginner's/child's first IDE, have a look at SonicPi
I think I still hold a grudge and prefer the command line to compile (which is its own mess).
I think it's probably one of the best IDEs I've seen, aimed at beginners and children.
The basic Windows install comes with a load of useful external libraries as well, so beginners don't have to tackle the pip minefield.
Is it? My first reaction seeing Idle was "there's got to be something better" & started googling. I'd imagine most noobs would do the same.
That said my first encounter with Eclipse put me off that for life.
VS/VS Code on the other hand is a delight.
It has a free community version
[1] https://devblogs.microsoft.com/python/python-in-the-windows-...
It is not correct to say that Apple did not maintain support for it.
Upstream Python is 2.7.15.
And I'm not saying those Linux distros are any better, although at least they typically have officially supported Python 3 packages, even if they are not installed in a stock installation.
"While Python continues to remain completely independent from the operating system, every install of Windows will include python and python3 commands that take you directly to the Python store page"
https://devblogs.microsoft.com/python/python-in-the-windows-...
Do people develop python in Windows? is there any distinct advantage? example: the pi costs $30 and a used keyboard/monitor from a pawn shop, but anything with windows is way more expensive.
If you are looking solely at Python software development, a faster, more reliable machine is always helpful, but some may prefer Linux or MacOS over Windows. All that said, the Pi is a great way to break into software development at a low cost.
Yes there are some advantages, but those aren’t Windows specific. The advantages also apply to traditional desktops/laptops running MacOS or Linux. There are tools written for those platforms that won’t be available on the pi, although the raspberry pi ecosystem is rich enough that that won’t matter much. There’s also the specs of the machine. A beefier machine can power multiple monitors that can let you see more code at a time. That’s just surface level. We can chat more if you’re interested.
Having said that, sounds like what you have right now is working for you. There’s no need to switch to something else if you’re making progress. It’s pretty cool that you got started this way. I wasn’t aware that python is used by car mechanics.
If the pi works for you compared with buying a much more expensive rig, that's great. I was pretty impressed with the desktop experience on the Pi. But if you already have a more expensive computer, developing on the pi doesn't give any advantages. It's slow, it doesn't have much memory, it's storage is SD cards (both slow and prone to failure). Now deploying the result on the pi is great (you can put those anywhere, they're low power, etc).
FWIW, the publisher for the MS app-store Python is "Python Software Foundation" and it, far as I can tell, is just ordinary Python and not some MS-only weirdness. It adds start menu links to the Python REPL and the IDLE tool.
Both sides may have wildly different reasons for making these changes, but the net result seems quite indicative right now.
[1] https://developer.apple.com/documentation/macos_release_note...
But really, that's where that ship is heading now, and it's paying off.
Edit: Oh, I see it's from the store. Well, that doesn't help anything at all.
Some children/students may want to “make the thing work” with electronics rather than “get your dev system built and then program the thing to work”. Dependencies can be a nightmare especially on Windows.
Maybe that isn't so relevant now that it's easy to find and install software but my journey with programming began that day when I was magically dumped into that BASIC interpreter.
I think things have changed - it's super easy to get into it now with the internet being such a great source of information and cheap tools, but having the tools available to us is I'm sure what launched a lot of us into this profession.
Edit: Ah, somehow programming gives you the ability to direct and master technology, instead of being mastered by it. I'm incredulous - my ability to make web-apps doesn't exactly give me a seat at the same tables Facebook, Google, and the NSA are occupying.
Remember the old business folks and politicians we laughed at a few years ago because they couldn’t handle email? Sounds like you’re arguing for that kind of ignorance.
Another example, knowing about the Roman Empire or WW2 is not important to daily lives either but we consider that knowledge to be basic literacy.
Why not? I reckon it's a good idea as a shotgun approach. 90% of the people just won't get it and move on...the other 10% probably are suited to be real coders.
Expecting everyone to code is unreasonable, but a throw it against wall and see what sticks approach to identifying interest & ability seems reasonable.
Thus when you give a coworker instructions how to run something, they wind up using the wrong Python and will waste hours of their own time and your time wondering why it doesn't work. Or maybe they'll get confused about pip vs pip3 or ...
I've found it's a lot easier to get it right on Windows since there is no system Python for people to get confused about.
Java's xenophobia, its insistence on "100% Pure Java" and the various squabbles that Sun and Oracle have had with other platform companies has actually made Java more reliable across different platforms since people expect to have to manage their Java version and don't have a sense of entitlement that they should just type "python" and have it work.
Anyway, we're finally near the end of supported environments caring about Python 2, so the difference between pip and pip3 will stop causing most of us problems soon... (Yeah, I know some people will use Python 2 beyond EOL, but at this point that's their task and the task of whomever they pay for assistance, not everyone else's.)
Virtually every common OS (i.e. Windows, iOS, and Linux) provides Python 2.7 by calling `python`, and Python 3.x by calling `python3` so it's more than "some people" using Python beyond EOL -- it's two languages being used simultaneously.
This is what most languages do when they make a breaking upgrade, e.g. Perl 5.x and Perl 6, or Apache Groovy (which ships two compilers in its Groovy 2 download bundle, i.e. the Groovy 1 compliant one used by Gradle and Jenkins etc, and the later 2012 one with the invoke-dynamic capabilities added. Two weeks ago, the Groovy project managers announced that Groovy 3 would keep on doing this, putting the rewritten parser into the compiler which no-one uses, and keeping the main compiler at Groovy 1 capabilities.)
Yes, OS vendors will temporarily offer some transition past EOL for the versions they ship. But only temporarily, and only in limited form.
Anecdotally I've run into more problems with python than with ruby over this issue, but I think that's just because I'm more familiar with the parts of the ruby ecosystem which let me draw a clear dividing line between system-ruby and my-ruby. My impression (which is probably out of date) is that python tooling tries to bridge the gap, and in my experience that's not worked well, to the extent that I just don't try to use python for anything on OS X.
Does that mean its not actually pre-installed but just super easy to install?
[1] https://docs.microsoft.com/en-us/cognitive-toolkit/setup-win...
I hate all these stores. They are the ultimate gatekeepers and give big companies huge amounts of power and control.
Glad to see some love from Microsoft for Python
[0] https://www.theverge.com/2019/5/6/18527870/microsoft-windows...
https://www.mail-archive.com/python-dev@python.org/msg92514....
http://www.drdobbs.com/cpp/interview-with-herb-sutter/231900...
The C89 issue is completely unrelated.
Absolutely!
If you want to hold on to C, there is clang and GCC.
There are multiple occurrences of this statements from Microsoft employees blogs and talks, apparently some keep missing it.
And actually VC++ compatibility with ISO C has been updated to the extent required by ISO C++, meaning C11 standard library, and some language constructs that were considered relevant by major customers.
The people in question are not missing it. I'm not missing it. The only thing that needs to happen is a decision in the CPython project is to drop MSVC support, move to C++, or give up on C99 and C11.
But it will have taken a long time to get there are they've wasted that time in the meantime waiting for the penny to drop. My point is that is the release channel through the Microsoft Store is held up like the C99 support that never came, then it will be an inconvenient situation for many Python application developers.
But I guess we all use nix, guix, or venv to distribute things so it's no bother at all. (I don't even use Windows on any machine so I have absolutely no skin in the game here).
Plus some C11 language constructs considered relevant enough to support as C++ extensions, due to customers or high profile FOSS projects.
No idea who are "we all use nix, guix, or venv".
There will be no Python already installed or included with Windows 10.
Once you discover that you need to get Python, you are quickly faced with many choices. Will you download an installer from python.org? Or perhaps a distribution such as Anaconda? The Visual Studio installer is also an option. And which version? How will you access it after it’s been installed? You quickly find more answers than you need, and depending on your situation, any of them might be correct.
We spent time figuring out why someone would hit the error above and what help they need. If you’re already a Python expert with complex needs, you probably know how to install and use it. It’s much more likely that someone will hit this problem the first time they are trying to use Python. Many of the teachers we spoke to confirmed this hypothesis – students encounter this far more often than experienced developers.
So we made things easier.
First, we helped the community release their distribution of Python to the Microsoft Store. This version of Python is fully maintained by the community, installs easily on Windows 10, and automatically makes common commands such as python, pip and idle available (as well as equivalents with version numbers python3 and python3.7, for all the commands, just like on Linux).
The possibility of a built-in one not being what you want adds a whole category of issues that wouldn't surface before. Maybe also those alternative ways of packaging die out due to lack of interest.
Ask folks who ran into this with an old release installed by default, as in a Mac. Some of them appear to be on the thread.
In what way does it screw over people who want more control? You don't have to get the python distribution from the Windows store.
It does help students/beginners/'people that want to hassle free install' get going with python.
This could make it extremely easy. "What programming language should I use?" "Learn Python." "How do I install it?" "Through the Windows installer." Boom, done. They're off to the races.
People who want control and specifics are advanced enough to figure out how to get that themselves.
For those that want to install the most recently released or a specific version number of the python installer, there's still the obvious channels and those people that would seek it out will know how to find it the normal way already. It's fine.
I still remember when I was a Python newbie. Just getting it set up was an endlessly frustrating experience. I had to choose between 2.7 and 3, and of course I chose python 3 but then my hello world script failed with a confusing error message. I had copied it straight from a get-started-with-python tutorial. Of course I assumed that I must not have installed it correctly (it turned out that the problem actually was the print statement needed parentheses, which became a requirement in python 3 but I had no way of knowing).
This will help me get my friends into Python, which is great!
I'm mostly familiar with Python, I dabbled in it for a number of years and helped a friend start using it but don't use it for work or personal projects anymore. Occasionally I have a need for it and because I use it infrequently I have to check my environment and update/reinstall it before I proceed.
Have a Store App that updates and maintains itself reduces that friction for me and I can just go play. The same goes for other OSS like the Arduino IDE, and Inkscape.
https://devblogs.microsoft.com/python/python-in-the-windows-...
Somehow, MS missed out on spreading a PSA that any website and web app is 100% telemetrics because that's literally what a web app is (telemetrics with feedback!).
Well seem they did not. Otherwise python will be universal. Anyway need pip etc. And also better to use conda. And easier integration with os. As none, probably not that useful. But better than none.