Python 3.x Progress Update

omz

Awesome. Now I'm going to have to change print "something" statements in my scripts for months to come as I run them only to find my lazy ass didn't use print("something")

There will be some way to automate this.

dgelessus

There's this thing called lib2to3, I hear it's part of the Python standard library. Perhaps that might be useful. ;)

@omz Maybe putting a lib2to3 thing in the action menu would be useful? Like the "Convert Indentation" option, except that it runs 2to3 on the file. Would probably be good to save the output to a different filename though, lib2to3 isn't perfect and doesn't always produce code that can run on Python 3 right away.

Webmaster4o

@Tizzy -

@omz said

It will be possible to access files in Pythonista 2.x from 3.x though (and vice-versa).

He said in more detail on twitter that there would likely be a folder in the file browser for the 3.x version which simply displayed all of the files from the 2.x version. I suggested on Twitter that a dialog could be displayed for importing files from the 2.x folder, which would contain an option to automatically run the 2to3 program on the files imported. We'll see if that's something @omz chooses to implement.

omz

@dgelessus said:

@omz Maybe putting a lib2to3 thing in the action menu would be useful? Like the "Convert Indentation" option, except that it runs 2to3 on the file. Would probably be good to save the output to a different filename though, lib2to3 isn't perfect and doesn't always produce code that can run on Python 3 right away.

Yes, I've implemented pretty much exactly that. Right now, it doesn't make a backup, but the changes are undo-able, and it shows a diff before applying them.

ccc

any reason in particular you use this Anaconda distribution?

http://docs.continuum.io/anaconda/pkg-docs lists all the superpowers that Anaconda adds to Python for free. 150 pre-tested, pre-configured modules. Just the IPython/Jupyter function alone is super cool but there is soooo much more in Anaconda.

Is that what you would recommend for everyone on OS X?

Mac OS X, Windoze, Linux. Yes!

wnMark

Great news!
Sure I will buy and will be available as beta tester!

Webmaster4o

@ccc does the conda utility include fewer packages than pip, or do they both scan the same index ?

ywangd

@Webmaster4o You can use pip with anaconda. I use conda for updating packaged stuff and pip for anything that is not included by default. pip list shows packages installed by both command.

ccc

Correct. http://conda.pydata.org/docs/using/pkgs.html#install-non-conda-packages

ccc

Given that we are going to need to make the transition to Python 3, could I make a few feature requests for the next version of Pythonista 2 to get us started on converting our own scripts?

Pythonista settings already has a 'Use "true" division' switch but that only applies to the console and not to scripts. Would it be possible to add another switch(s) that would be the equivalent of adding the line: from __future__ import absolute_import, division, print_function, unicode_literals to the top of every script systemwide? See: http://python-future.org
In type ahead, could we remove print but keep print()?
While we are at it, would it be possible to add a shebang line to the Python new file template to ease the migration of our scripts to non-Pythonista platforms? This would make new Python files begin with #!/usr/bin/env python\n# coding: utf-8\n\nfrom __future__ import absolute_import, division, print_function, unicode_literals\n\n

ywangd

Since Pythonista 2 will be kept for Python 2.7, I don't see the reason to remove the print statement.

omz

@ccc I like the idea of a "future mode", will think about it. Should probably be optional though.

ccc

Agreed. A switch in Settings.

Phuket2

I am ready to purchase. It can't make me a worse Python programmer than I am already 😝

dgelessus

@ccc Just FYI, unicode_literals unfortunately doesn't always work well in Python 2. The main issue is that Python 2 allows only 8-bit str for identifier names, so getattr and such will fail with unicode_literals enabled, unless you wrap the strings in a str call, which is really ugly.

The way I use strings in Python 2 is:

unicode/u"..." for normal text
bytes/b"..." for binary data
str/"..." for things that are Python identifiers

This is almost fully forwards compatible with Python 3, except that you need to replace unicode with str.

Webmaster4o

I'm looking at Anaconda now. Looks awesome. I'm installing it in my personal school-provided network drive, as it seems to allow installation to a custom directory (yay). Before I was using PortablePython at school, which also came with a lot of useful modules, but Anaconda looks like it offers much more, as well as having a much larger community around it.

nathaniel

I'm looking forward to it (even if it's only a "beta" version). Am perfectly fine to pay for it. Keep up the great work!

omz

I've just submitted the first beta to Apple. The first build needs app review approval, so it'll take a couple of days until I can actually invite external beta testers. I've already addressed most of the limitations I mentioned above, i.e. app extension, URL scheme, documentation etc. should all be working in the first beta. There are probably bugs though (it's a beta after all).

@ccc Now that I think a little more about the "future mode" setting, I'm not sure anymore that it's a good idea. The problem I see is that it would potentially introduce incompatibilities when you share scripts with someone who has different settings, and it would be a hassle to switch settings when using different scripts. The current "true division" setting only applies to the console, so it's not really an issue there. I think it might be better to use explicit __future__ imports in scripts ("explicit is better than implicit").

dgelessus

@omz Though it would be nice to allow any __future__ option to be enabled in the console. Not having print as a function bugs me when I need more than the standard repr.

Somewhat related - since absolute imports are the default in Python 3, would it make sense to remove the root Documents folder from sys.path too? IMHO, having Documents on the sys.path is more confusing than useful. Importable modules should go into site-packages.

omz

@dgelessus ~/Documents isn't in sys.path by default – it only is if the script you're running also happens to be there. The current directory is added to the path automatically, but it's not necessarily ~/Documents.