A lot of people are mentioning Apple removing scripting languages at the same time as Windows is adding it. The stub is nice for learners. But ultimately I like Apple's decision to remove them. You should not be relying on system installed interpreters, because you end up with an ancient, unmaintained version. And you are co-mingling all your dependencies with whatever else is installed. Everyone should be using virtualenv. And it should be easier to use virtualenv.
It depends on who you're talking about. There is an attitude of, "if you can't install a virtualenv as step 1 in learning how to do python, you don't deserve to learn python". Not, I would hope, consciously thought of in that way, but that's the practical affect.
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.
If you're just learning, you don't need to mess around with virtualenvs; you can install Python via the official Windows installer and install packages globally. I don't feel like installing something is a very big initial hurdle to overcome, as opposed to having it be pre-installed (but potentially very outdated in the future).
On the contrary, installing something is the biggest hurdle after perhaps coming up with the idea that there's something here to be learned at all. And sometimes it's part of the latter.
Well, I don't have that attitude. Lately, I push beginners towards repl.it so that they don't need to install anything or setup an IDE. There, each script/program is completely separate. So it avoids this issue entirely. Then, when they're a bit more familiar with programming, they can transition to a good local environment like PyCharm or some other setup that manages python versions, virtualenvs, etc.
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).
> 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
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.
I always felt that virtualenv is vastly superior to most other package managers. I think comparing it to Rust and .Net is a little unfair, as these are compiled languages and have different deployment models.
When I was first learning and there was a system Python I would install packages, then 6mo to a year later I would find something old. Because the OS came with Python and some number of libraries and because I modified that somehow, I couldn't get back to a known state without reinstalling my OS or updating/removing things likely causing problems. Everything I did were separate test projects, so it never made sense to install libraries globally.
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.
First step of creating a hello world Node.js application is to write a package.json file which is somewhat equivalent of virtualenv. Nobody ever complained about that. Isolated packages per project becomes the default and not an obscure extra command. Same with Rust, Gradle and many others.
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 at the same time, Microsoft is actually throwing people at the task to maintain it meanwhile Apple is letting them languish. Why discourage it if there are active maintainers?
Are you saying that Linux is also doing it wrong? Python packages often come from distro maintainers and not python devs?
Yeah, Linux is doing it wrong. I hate that I can't get a new version of python on my machine because the distro maintainers haven't gotten around to it.
Docker solves that. Yeah, you then have to deal with container problems, but it's the best packaging solution we have at the moment.
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.
Both of which will be dead in 10 years, the former because it's solely focused on the desktop, latter because it's a vendor initiative not a community one.
You just compile your own from source. Python plays nice with older versions of itself. Use Gnu Stow as a secondary package manager to make it easier to remove or replace.
You can use, today, the same ways that you would force everyone to find/install python (virtualenv, docker, pipenv, conda, whatever is hot this week) in a world without distro-provided python.
And then halfway through the compilation you find out you are missing fifteen different dev-packages and the only way to figure out which are by googling obscure error messages. Oh, can't find include efglx.h, you obviously have to apt install libstdglx4-dev. (This was probably written deep on some establish build environment-wiki page that's impossible to find but since you are on Ubuntu 18 instead of 14 it wouldn't have worked anyway because now the package has changed name to apt install glx-dev. Besides - they also forgot to list half of the dependencies required on that page).
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.
Updating and replacing system Python takes tremendous blood and treasure. Compiling python from scratch, updating symlinks, resolving dependency issues and finally debugging the whole thing is no small endeavour. Been there, done that; never again.
I've done this dozens of times, didn't seem like that big of a deal? I think the place this might have fallen over is the "updating symlinks" part. Don't replace the system Python, install yours alongside it. They don't need to know anything about each other; aliases in developers profiles and full paths in services/scripts.
Yup, stick it in /usr/local and place that in your PATH and Python search path before other dependencies. If you want to be fancy, put it somewhere in your home directory so other users on your same machine cannot be affected.
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).
Or you could, just like on other platforms and with other languages, use virtual environments with a version manager such as pyenv for your development environment. Combine that with pipenv and you get pretty painless python development. To be fair, some of this stuff is more recent though.
Here is an excellent short blog describing all this and how pyenv and pipenv click together to create a virtual Python environment, that is completely independent of your OS vendor's runtime: https://gioele.io/pyenv-pipenv
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.)
It's hard if you're trying to update the system Python and need to upgrade every dependency for that but if you just want to have, say, “python3.7” in your path it's just a couple of commands:
> Are you saying that Linux is also doing it wrong?
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'd say yes, the coupling of operating system and distribution of software applications has always seemed very wrong to me.
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.
I believe that it's the Python Software Foundation that is controlling the install and maintaining updates.
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).
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.
I fully agree. I started programming in JavaScript because I only had access to public computers, where I couldn't install or even download binaries, but I could write a .html file and open it in the browser.
Ubiquitous access to these tools provides wonderful opportunities, and the drawbacks are minimal.
> 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
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).
A number of good points. At the time I took (I think) 5 IB higher-level courses as a junior/senior, as well as a pretty tough art curriculum, and economics competitions as extracurricular activities. There wasn't a lot of energy I could afford to something that didn't require my primary attention and time. Another big reason is the inability to quantify my fears and the ability to divide and conquer them, which is a problem I still have.
I'm in the US, not sure if you are. I think I had a similar experience. Didn't get into programming until much later in life and kicked every wall once I realized I love it.
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.
I appreciate the honest and personal answer. What I meant was... considering you had access to a programming language (albeit very limited) in your TI but you didn't use it, why do you think it could have been different with python?
That's a great anecdote, and I see how learning Python might have been harder for someone if it was not included.
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.
I very much disagree. The whole point of Python is to make programming as easy as possible, so that it can reach as many people as possible. Python literally gave up design optimizations like tail recursion elimination so that beginners wouldn't be confused with stack traces.
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.
You should not be relying on system installed interpreters, because you end up with an ancient, unmaintained version.
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.
Additionally, this is an "App" Store release that can update independently of the OS (and at least at this point in time Windows itself doesn't have a dependency on it).
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.
This will pull python down from the app store which is a community maintained package and installed just like any other store app.
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.
Removing them from MacOS was the right decision for MacOS, but only because Apple never maintained it. If Microsoft can provide a good distribution channel and maintain it, this is a fantastic move. And the Windows Store is a fine distribution channel, and Microsoft recently has been very on-top-of this kind of thing.
> A lot of people are mentioning Apple removing scripting languages at the same time as Windows is adding it.
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.
> You should not be relying on system installed interpreters, because you end up with an ancient, unmaintained version
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.
Agree completely. It would be interesting to see how many installs there are of n/nvm/rvm/rbenv/virtualenv with only one version of scripting language installed. Often the version bundled with the system is too out of date or too locked down in root directories for users who just want something simple.
Updating Python once a year shouldn't be too much to ask of a company like Apple, and is adequate for 90% of users. I shouldn't need to install pipenv and virtualenv if I want to drop into a scripting environment once a month.
These tools aren't (or at least shouldn't be) only meant for professional engineers.
That's not the case here, according to the link. There is no and will be no no system installed interpreter in Windows. It's just directing people who enter 'python' or 'python3' on a CLI to a package on the Microsoft Store.
> You should not be relying on system installed interpreters
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.
My understanding is that Python break backwards compatibility (or forward compatibility) comparatively more often than bash. The problem with OS interpreters is entirely linked to stability and portability indeed regarding bash, many suggest to avoid bashism as much as possible and be posix compliant.
I've seen lots of companies do what Apple is doing, and it always makes the platform less valuable.
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.
I'm desperately in need of a guide on how to un-fuck my Python setup. On my Mac I have several versions of the default shipped Python, brew-installed versions of 2 and 3, and Anaconda-installed versions of 2 and 3, and I have no idea which I'm getting when I call 'python3' or 'ipython', or what should be being used. Substitute brew for apt and it's the same situation on Ubuntu. It's really confusing and means I have to troubleshoot dependencies for any Python project I try to run.
Disagree... there is tops of vbs around. why? It's default. Fought with a bank for months to use python but ended up with perl scripts on Solaris back in the day... Why? Perl came with Solaris. Having a trusted base and scripts that are easily auditable is good from a infosec perspective.
> Finally, with the May 2019 Windows Update, we are completing the picture. 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.
> You should not be relying on system installed interpreters, because you end up with an ancient, unmaintained version.
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.
I also agree with Apple's decision and I was bit surprised that Microsoft would go the other direction until I read the article -- they also not bundling Python with the OS -- they're just putting it in the store and adding some stubs.
Therein lies python’s biggest weakness. You effectively are containerizing the runtime to be sure your code will work. This is why languages like C++ are compiled to platform executable or why Java has byte run code (or whatever it’s called).
To be fair even with C++ you have to distribute some dependencies, e.g. MSVCRT. It's just that that is a lot easier and more efficient than distributing a copy of Python with every program that uses it, which is what currently happens on Windows.
In the past when I needed a calculator on someone’s Mac, I just started Python in a terminal and typed in expressions to be evaluated. It was nice to be able to find it on any Mac and it’s much nicer to type into Python’s REPL than clicking on a calculator’s GUI buttons. Now, Windows machines
will have Python and
Macs may not.
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.
I use spotlight a lot, but never for calculations. I’ll have to try that out.
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.
>In the past when I needed a calculator on someone’s Mac, I just started Python in a terminal and typed in expressions to be evaluated (...) The ability to use variables, math functions, lists, loops, and completion in Python will likely keep me using it as my basic calculator.
I do all that too, it rarely, if ever, involves math. Installing this, formatting that, removing some virus, installing some hardware, configuring the OS or a program yes.
Yes, a lot of the tech support falls into your enumeration, but I was Chief Scientist at a company for over six years, an OS Architect at IBM for five years and subsequently have done years of part time consulting at a number of startups. It's not unusual to be in someone's office or even having coffee with my daughter (she studying engineering) when some question that involves simple calculations comes up, things like "Is this algorithm warranted given the data set size?". One of my degrees is in math and perhaps this leads me to think quantitatively about many questions.
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.
I was referring to readline-style completion (as in GNU Readline) as is also found in the bash shell. You're right that the stock REPL doesn't have IDE style completion.
What's sad is that JavaScript isn't a very convenient language for this type of thing, but it's available (Math.pow(x, y) instead of x \\ y, limited integer accuracy, etc). I usually use the Python REPL, but occasionally I use the browser, it's just so ubiquitous.
It's not actually on Windows default installs though, it's just more easily installable. So not much help in your situation. Google will do arithmetic for you, that's often the quickest.
This is great for learners looking to write their first few lines of code.
No more wondering which Python version to install, or having to check the box to have Python added to your path.
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.
I've been using Visual Studio Code for my Python development lately, it seems like it would be a sensible choice to bundle (or install on demand) with Windows.
VS Code has too steep a learning curve for someone who has never even written Hello World!
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 remember in college being thrown into Visual Studio. I got things to work basically from a checklist. For the longest time includes and building/linking were mysteries done in the background. I feel like a lot of people were "programming by coincidence."
I think I still hold a grudge and prefer the command line to compile (which is its own mess).
There is a bit of a learning curve, but some sensible defaults and bundled extensions could go a long way to help new users along. Perhaps a "playground" mode, similar to what XCode has, would help as well.
I recently taught a class[0] on Python programming for children where we used the Mu[1] editor. Mu bundles Python with the editor in a single download so it is very easy for beginners to get started.
Pycharm is way too intimidating if the goal is to get non-programmers to play with a language. Something more like Swift playgrounds would be a better target
It looks like this update breaks already-installed Python execution if its position in the PATH environment variable is after the WindowsApps folder. [1]
bash does exactly that - it has command_not_found_handle function and distributions define it, so they can offer package installation for any command not found.
Yep, I ran into this some months ago with an insider build. IIRC though, I had manually added Python to my PATH. So I just adjusted the order and kept using my existing Python install.
Strictly speaking though, it's not out of the box. From MS's blog about this:
"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"
This statement is misleading. Apple kept up with the 2.x versions, the same as almost every linux distro. Only recently have the linux distros started to move on to Python 3.x. And most of them still include Python 2.x (specifically 2.7) as the default `python`, and have added Python 3.x as `python3`.
It is not correct to say that Apple did not maintain support for it.
Similarly I think it's misleading to imply Apple ever really encouraged the use of Python given they never shipped with 3. Those minor version upgrades are the bare minimum requirement to produce a stable product.
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.
I think it's actually a blessing in disguise... managing Python environments on macOS has always been a massive nightmare precisely because of the default Apple Python environment.
Exactly - in a way that was a blessing in disguise because Python environments on MacOS is such a massive nightmare that it forced me to learn to use venv in all cases.
sort of a selective use case here, but im an automotive mechanic that started learning python to track engine firmware, mileages, and tools at work. I always did this on a raspberry pi, partly because it makes doing computer stuff a bit more approachable than the ole black and beige dell laptop. We have windows desktops for the office area, but I never once considered using them for this.
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.
I’m a little confused by your first question. I’m going to guess you’re mostly used to interacting with Windows to browse the web, use Office, or other software specific to your business. In that case, yes, that same computer can be used to program python and people do it all the time. A computer is a computer.
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.
Yes, I've developed in Python on Windows. The pi is great little device (I have one) but it's also a pretty under-powered computer. Having a modern computer running Windows, Mac OS, or Linux is probably going to be a better experience.
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).
As a Sysadmin, I would caution you on the Raspberry Pi as a critical device, unless you have a very strong backup regime. Pis tend to corrupt the SD card after a while, so make sure you have very good backups. I would make sure you have them daily, if not more often.
Former auto tech here- cheap used laptop is really preferable simply due to portability, python works with windows just fine. Plus, having a laptop in your box can replace multiple tools. I used AutoEnginuity as an OBD2 tool (expensive, but cheaper than snap-on), a Hantek USB oscilloscope, as well as having a convenient way to access Alldata manuals. Check Craigslist for a used laptop though, nothing you need requires a powerful computer and a shop environment will ruin most laptops eventually.
I use Windows in my office and I also develop Python software to accomplish some tasks related to my job. If I really had to save money, I might consider a Raspberry Pi, but they are less reliable (SD Card versus robust SSD) and are not as fast. Also, I need Microsoft Office for my job, so Windows makes the most sense all the way around.
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.
If you are already using Windows and run into a solution for a problem you are trying to solve that uses Python. This is my use case, there are lots of useful tools and scripts that need Python to run.
Just tried it. Looks like the latest Windows update installs a stub that sends the Windows app-store to the Python installer page if you type "Python" from the command line.
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.
Yes I did. I just wanted to relate my personal experience with it. Sometimes I'll see an article about something new just to discover that it's actually for an update that's a couple of weeks away. In this case, I just wanted to verify that it's working as advertised.
Looking at the bigger trend, it feels like recently MS is doing everything it can to engage developers. imo Apple is doing the opposite with bad keyboards and the continued refusal to give developers a reasonably priced, expandable box like the ancient G models or the old cheese grater product line.
While I don't like the "let's teach everyone to become coders!" thing that some companies seem to be pressing, I think this is a great addition for dabblers, or for people who are on their parents computer and want to do something quick without installing a bunch of junk. I really like this.
Edit: Oh, I see it's from the store. Well, that doesn't help anything at all.
There are a lot of electronics hobbyist who may not know much about programming. The Adafruit/Pi community have a lot of python libraries for sensors and such.
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.
When I was 11 years old I was looking at a bit of code in a magazine and, being curious to know what it did, I booted up my parents' old IBM PC. I typed GWBASIC.EXE into the command line and I was astounded that it worked.
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.
The first coding I ever did was along the same lines, carefully copying dozens of lines of BASIC into a Commodore 64 - I still recall the feeling of wonder that it actually worked!
That's what first got me into coding - finding QBASIC on my grandmother's PC.
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.
>While I don't like the "let's teach everyone to become coders!" thing
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.
I don't know that it has value - coding and computer use many years ago were similar - but now it's so different, I don't know how learning to do basic programming tasks would make most people's lives better.
I'm not sure I follow that argument - I don't think that the skill of programming is relevant to most people's lives, and I feel like the world of tech is actually getting easier for users to navigate - comparing DOS to a modern Android device, you basically don't need to know anything about command line commands to do whatever you need.
“Software is eating the world.” Everything is programmable these days, it’s highly relevant. And administration is not programming.
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.
That sure sounds profound, but I don't know what it means.
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.
The worst thing about Python on Unix is that there is always a system Python you get when you type "python" -- it might have been up to date once, but it will be out of date someday, if only because updating it would break other system dependencies.
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.
Red Hat ditched the user-accessible default system Python in RHEL 8, but offers ways to have several versions of Python available and ways for sysadmins to configure the target of /usr/bin/python.
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.)
> 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.)
For all of those common OSes, either Python 2 is no longer installed by default or a plan to do that in the near future has been announced. Many of those are preparing no longer to offer Python 2 at all, though few have already dropped it. I don't think RHEL 9, Debian 11, Ubuntu 20.04 LTS, Windows's new Python stub after the EOL date passes, or 1-2 major versions of macOS in the future will offer it.
Yes, OS vendors will temporarily offer some transition past EOL for the versions they ship. But only temporarily, and only in limited form.
The one thing you can guarantee about the system python is that it's exactly as up to date as the system itself needs it to be. That's why it's there: it's not necessarily for you, unless you happen to be writing something system-level.
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.
Microsoft also provides CNTK and CNTK-GPU[1], which can be used as a backend for Keras. That could make life easier to kick off with machine learning by providing correct libraries for GPU. If you ever tried to install not-the-latest Tensorflow for the oldster graphics card you may know what I'm talking about, all that wading through a variety of lib versions. Nah, good news anyways.
If they wanted Python on Windows, why didn't they just include it like they include every other command? It's miniscule in size to have Python stored on every Windows computer compared to the size of Windows. Why go through the "Windows Store" to get it?
I hate all these stores. They are the ultimate gatekeepers and give big companies huge amounts of power and control.
There are a lot of comments talking about how you should not rely on the built in version of python or whatever instead installing it yourself, but it is really nice being able to pass people scripts that you know will work with the stock operating system with no additional installs.
As a side note: I really enjoy how the imagery at the top shows the rating for Python is E (for everybody). Do all apps receive this type of rating? Who got to test this and decide it was E? I always assumed the ESRB rating system was only attached to video games.
Why is there windows python Team and what do they do.
Python is 1 of N slow scripting languages that has sod all to do with Windows.
This is not a language that should be treated differently to a dozen others.
I like that Microsoft is moving more of its stuff to their store in a way that encourages people to use it. The desktop is becoming a powerful tool for getting work done, and I think this is a great move.
Is this going to freeze everyone at Python 3.7 in the same way that CPython had been stuck on C89 basically forever because Microsoft refuses to fully support C99:
Not only Python is not installed (the command is a stub), but linux distributions have been shipping Python forever, and it never froze anybody. It's a matter of how you support upgrading, now what you provide out of the box.
Because C++ is the future of systems programming on Windows.
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.
>There are multiple occurrences of this statements from Microsoft employees blogs and talks, apparently some keep missing it.
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).
Microsoft declared back in 2011 that Microsoft will never support the now 20 year old C standard. The MSVC compiler should be considered deprecated and removed in favor of something like llvm with MSVC system headers like Chrome does. The actual compiler isn't really a C Compiler anymore.
The title is inaccurate, if you write "python" in a Terminal and you don't have Python installed, the Windows Store will launch and show you the Python app/installer from the store.
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).
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!
While they might be targeting newbies, I find this type of work to be great for enthusiasts and hobbyist as well.
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.
This is weird because "making it easier" seems a bit like screwing over people who want more control and specifics. MS is relatively new at packaging open source and doesn't seem to have much experience in the phenomenon of official packages being not what you want.
I think this is wonderful for people who are interested in learning programming. Right now one of the biggest hurdles to learning programming is just getting the damn environment set up. Why does it have to be so hard? How many people never learn to program because they can't get "hello world" to print out?
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.
I very much agree and love how the programming language AutoIt does it. When I was starting out, both C and Java took several frustrating hours to set up (don't get me started on requiring environment variables to be manually changed). However, after a basic installation, AutoIt gives its au3 files a right-click context menu option to compile to an exe. It also gives you a shortcut to a help file that contains basic examples, a complete list of language concepts, and a complete list of all first party functions and a page on every single one complete with an example of how to use it.
I'm not sure. It's not really all that different from any Linux distro (or macOS) having a specific version of the python binaries in their own repositories. Basically, this is for those that either need the hand held manner of doing it, respect Microsoft's vetting, or any other reasons.
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 could very easily see a scenario in which your own version has a conflict with the official one. For example maybe you need to get really careful about where the install stub is on PATH.
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.
Use your imagination. Sometimes the machines are not set up and maintained by you. Sometimes you write scripts and run them far away. Sometimes someone else's script mucks with PATH. Now there is an ambiguity about which python runs.
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.
I think this is a healthy decision. It minimizes frustration on programming first steps and is, at worst, a minor frustration for people who know what they’re doing and launch the store on one by accident.
My favorite part about people raging about telemetrics is that for many of them, their primary computer usage is using Facebook and Google services.
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!).
Can we please have "Stability in the Windows 10 May Update". It's nice that Microsoft's giving us free updates, but Python support, a new terminal, and all the other things would be more appreciated if our machines remained reliable while before the features.
Based on experience, I’d rather install my own Python environment than rely on Microsoft’s suggestion of what I should install. This is Microsoft folks - there is >always< a catch.
Microsoft wants to spoon-feed beginner Python programmers their way, via their ‘community’. It really is unnecessary. In time, this will lead to classic Microsoft lock-in or dependency. I’ve seen this happen time and time again. As much as I’ve been a big fan of Microsoft dev tooling since the mid 90’s, I think Microsoft and other vendor’s newly-found open-source and Linux evangelism will, in the long-run, be a disservice to those communities.
Surprise they do. Other than basic (and no longer after bill gate is gone) the only programming language is dos command :-(.
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.
