Jump to content

Recommended Posts

Alfred-Workflow doesn't support Python 3. It says on the Cheeseshop page that 2.6 and 2.7 are the only supported versions, so I'm not sure why pip thinks it's okay to install it in Python 3.

 

There's almost zero chance that I'll add (official) Python 3 support to AW until 2 things happen:

  1. Alfred v3 comes out. Alfred 2 runs workflows in an incorrectly-configured environment that makes it impossible for me to write a version of Alfred-Workflow that works out of the box with Python 3. Andrew has said that he won't be changing the environment in version 2 of Alfred, as it may change the way existing workflows work.
  2. Apple starts shipping Py3 with OS X.

There's no compelling reason not to add Py3 support (no. 1 is easy enough to work around), but the bottom line is, AW is my project and I just don't like Python 3 very much. I have very little desire to invest a lot of my time in what I consider messing up AW's code in order to support a language I neither like nor use, and which doesn't (yet) provide any must-have features versus Python 2.7.

 

So, yeah, if you want to use AW, you'll have to use Python 2 for the foreseeable future.

 

And unless there's some compelling reason to use Python 3, using Python 2 has the additional advantage that you can share your workflows between machines, or with other users, and they will work without needing to install Python 3.

Edited by deanishe
Link to comment

Re-reading my previous comment, I think I should say—in fairness to Python 3—that workflows are a lot easier to write in Python 3 than Python 2. Provided you set the locale to something UTF-8, you mostly won't have to worry about encoding and decoding any strings (which is a PITA in Py2 and the cause of a very large proportion of bugs).
 
AW takes care of a lot of that for you, but it's still something you usually have to deal with in Python 2.

Edited by deanishe
Link to comment
  • 3 years later...

Nothing material has changed.

 

Until Apple starts shipping Python 3 with macOS, I personally won't consider adding Py3 support. If someone else wants to do it and submit a pull request, that's a different matter.

 

There are two related reasons for that: Firstly, it's a lot of work just to end up with a library that works exactly the same as it did before. Secondly, the net result of Py3 support would be to increase developer convenience (no more UnicodeDecodeError) but at significant cost to users (Py3 workflows can't run out-of-the-box on a vanilla macOS—users must first get their hands dirty installing developer tools).

 

That is antithetical to the way I approach workflow development. When faced with the choice of using a preferred language/tool that isn't pre-installed or using one I don't know or don't like that is pre-installed, I have always chosen the latter. Developers having to mess around with development tools they don't like is (almost) always preferable to workflow users having to mess around with development tools at all.

 

That's not just a philosophical position. Look in the threads belonging to Node-based workflows and they're full of users asking for help with getting the damn things running. I don't really want to be the guy who turns Python workflow development into a similar tragicomedy.

 

All that said, I imagine Apple's next OS will have Python 3 and the above becomes largely moot.

Link to comment
On 3/30/2019 at 11:38 AM, deanishe said:

That's not just a philosophical position. Look in the threads belonging to Node-based workflows and they're full of users asking for help with getting the damn things running. I don't really want to be the guy who turns Python workflow development into a similar tragicomedy.

 

I refuse to install any Node-based workflow for the sole reason they are not installed in the default workflow's installation folder.

Link to comment
5 hours ago, xilopaint said:

they are not installed in the default workflow's installation folder.

 

In addition to that (which means they don't sync like proper workflows), updating via npm is broken. Apart from the bug they've been sitting on for nearly a year now, by not using Alfred to install updates, all your customisations (hotkeys, keywords) get dropped on the floor.

 

The way the community around alfy (and some other Node devs) generally go about workflow development is fundamentally broken, imo. By that, I mean it's impossible to create an Alfred workflow that Just Works the way they're intended to.

Link to comment
  • 1 month later...

I was afraid of this. I've been playing around with another workflow for interacting with the Google Play Music Desktop Player, and I'm using Python 3 because the websocket library I picked up uses the coroutine support in Py3, which is really nice to have. I was really wondering about how such a workflow could be reasonably distributed, and it seems as painful as I assumed it might be.

 

Oh well, maybe I'll get lucky and by the time I get it to something presentable, Py3 will be available natively 😬

Link to comment
On 5/13/2019 at 2:10 AM, troycurtisjr said:

Py3 will be available natively

 

The only sensible thing to do would be for Apple to include Py3 in the next release of macOS, as Py2 will be EOLed next spring.


I don't at all trust them to do it, though, based on how criminally out-of-date they let some of the UNIX libraries on macOS (OpenSSL, for example) become.

Link to comment
  • 8 months later...

If the Python 3 executable is called python3, then yes. Personally, I'd use the full path to it (/usr/bin/python3, I'd guess), so you know which version you're getting.

 

If a user has messed around with the environment and/or installed a weird Python like Anaconda, env might give you an unexpected Python.

Link to comment
  • 7 months later...
On 3/30/2019 at 6:12 PM, Kim Aldis said:

Resurrecting this; Python 2.7 comes to end of life next January. I wondered what your thoughts are

 

Python has a rule that all 2.x versions will be backward compatible . The same rule applies to Python 3.x versions. However, Python does not guarantee backward compatibility between versions. Python 3 introduced several changes to the actual structure and syntax of the Python language. The whole Python community was pretty much sceptical when they received Python 3.x. Python 3.0 is fundamentally different to previous Python releases because it is the first Python release that is not compatible with older versions . Most of the things written in Python 2.x were not compatible with Python 3.x, as it did not support backward compatibility. Many applications and frameworks needed to rewritten completely due to this, hence, it was very difficult to port to Python 3.x from Python 2.x . Programmers who first learned to program in Python 2.x sometimes find the new changes difficult to adjust to, but newcomers often find that the new version of the language makes more sense.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...