Attribute Error when running scripts in my site-ackages in beta

ClareMacrae

PS It's Editorial Version 1.3 (130005)

ClareMacrae

Just to note that the problem is still present in 1.3 (130006) and 1.3 (130007)

omz

I thought this would be fixed with the latest beta. ~/Documents/site-packages should already be in sys.path by default, so I don't think the workaround above is necessary anymore, I could be wrong though. What do you get when you enter import sys; sys.path in the console?

ClareMacrae

Hi Ole,

I've only just seen your question...

I get this (with some added line wrapping):

>>> import sys
>>> sys.path
['/var/mobile/Containers/Data/Application/3132ED2D-F6DF-4976-8984-2AFE7BE75247/Library/Application Support/Commands',
'/var/mobile/Containers/Data/Application/3132ED2D-F6DF-4976-8984-2AFE7BE75247/Documents/site-packages-2',
'/var/mobile/Containers/Data/Application/3132ED2D-F6DF-4976-8984-2AFE7BE75247/Documents/site-packages',
'/var/containers/Bundle/Application/A35D4C58-A130-4CC8-94EB-3DDAAAE4F464/Editorial.app/Frameworks/PythonistaKit.framework/pylib',
'/var/containers/Bundle/Application/A35D4C58-A130-4CC8-94EB-3DDAAAE4F464/Editorial.app/Frameworks/PythonistaKit.framework/pylib/site-packages',
'/var/containers/Bundle/Application/A35D4C58-A130-4CC8-94EB-3DDAAAE4F464/Editorial.app/Frameworks/PythonistaKit.framework/pylib/site-packages/PIL_compat']

ClareMacrae

@omz Are there any particular requirements for the files in site-packages as to line-endings, character encodings or similar, please?

The path is fine - the import commands work - the problem seems to be with what is imported.

omz

@ClareMacrae Could you perhaps post a full traceback? You can print it from the Python console by entering the following code (after the error has occurred):

import traceback; traceback.print_last()

ClareMacrae

Thank you. That allowed me to understand the problem.

I was calling a helper function I'd written, and put in site-packages this starts with this:

def dropbox_directory():
    if sys.platform == 'win32':
        return os.getenv('MY_DROPBOX_DIR')
    elif sys.platform == 'unknown':
        ....

At some point recently, Editorial's Python has gone from saying sys.platform is unknown to now saying iphoneos.

I hadn't coded for else raise an exception so various such helper functions now return None.... and depending on where the function is called from, I get different kinds of error messages about things that don't work with None...

My only problem now is how to get the fixed scripts over to Editorial, as the Workflow I use to import site-packages is itself broken... I guess I'll have to initially edit the relevant Workflow to put in hard-code values instead of calling helpers.

Is there a recommended way to access the Dropbox directory inside Editorial?

The code I had isn't very pretty, having evolved over a few different versions of Editorial:

def dropbox_directory():
    if sys.platform == 'win32':
        return os.getenv('MY_DROPBOX_DIR')
    elif sys.platform == 'unknown':
        # Find the absolute path of the Dropbox folder, relative to the Workflows folder:
        # TODO Try using os.chdir(expanduser('~/Documents/')) instead
        # TODO The /private probably doesn't matter, now that I'm only showing the filename
        import editor

        commands_dir = editor.get_workflows_path()
        dropbox_dir = os.path.realpath(commands_dir + '/../Dropbox/')
        private_suffix = '/private'
        if dropbox_dir.startswith(private_suffix):
            dropbox_dir = string.replace(dropbox_dir, private_suffix, '', 1)
        return dropbox_dir

omz

@ClareMacrae The code you're using to get the Dropbox directory seems fine to me. There isn't really a "recommended" way because I usually recommend against doing this at all (but you seem to know what you're doing ;)). The problem is sometimes when people start writing stuff in that directory, and then expect sync to work... :/

ClareMacrae

Thanks... In scripts, I'm only ever reading from files in the Dropbox directory, not writing to them... (The only time I ever write to them, I open them in the Editorial editor and change the contents there...)

Would you consider mentioning prominently in the notes for the next version of Editorial that the result of sys.platform has changed, please, to help others out?

Getting this sorted out is a huge relief for me, given my dependence on Editorial - thanks for the import traceback; traceback.print_last() tip!

sydneycbd

I deleted both versions of Pythonista I had on my iPad after countless errors, consistent with those mentioned above. I reinstalled it but my previous setup was likely rubbish. I'm a novice that wants to learn beautiful soup. How do I do things properly this time. How exactly do I download, install, configure, and use pythonista and these packages? I've really tried as hard as possible with little 'luck'?

omz

@sydneycbd Not really an answer to your question, but I thought it might be worth mentioning that you don't have to install anything to use Beautiful Soup. It's already included in Pythonista.

sydneycbd

@omz that's an answer I'm happy with :) so when I start an empty script, in which folder do you suggest I store it?

dgelessus

@sydneycbd It doesn't matter where you put your script or what you call it, except for one thing: you cannot name your script the same as a library you want to import. For example, if you call your script bs4.py and run import bs4 inside, this will import your own bs4.py file instead of the bs4 module included with Pythonista, and you won't be able to use the real bs4 library. The same goes for any other Python module - if you call your script editor.py, you can't import Pythonista's editor module, and if you call it os.py, you can't use Python's os library.

sydneycbd

@dgelessus thank you kindly

ClareMacrae

I said:

At some point recently, Editorial's Python has gone from saying sys.platform is unknown to now saying iphoneos.

In beta 130010, it now says sys.platform is ios. Which means I have to re-copy my site-packages over...

On the up-side, it was really useful that the traceback was shown in the console - thanks very much indeed for this - it made the problem immediately clear... :)

(If this changes again, please could you put it in the TestFlight release notes, as it's a lot easier to update the site-packages in advance of the change in value....)