Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #68413 > unrolled thread

Correct idiom for determining path when frozen in 3.4

Back to article view | Back to comp.lang.python

Contents

  Correct idiom for determining path when frozen in 3.4 Mark Summerfield <list@qtrac.plus.com> - 2014-03-17 01:44 -0700
    Re: Correct idiom for determining path when frozen in 3.4 Ben Finney <ben+python@benfinney.id.au> - 2014-03-17 20:02 +1100
    Re: Correct idiom for determining path when frozen in 3.4 Devin Jeanpierre <jeanpierreda@gmail.com> - 2014-03-17 02:16 -0700
    Re: Correct idiom for determining path when frozen in 3.4 Ben Finney <ben+python@benfinney.id.au> - 2014-03-17 20:23 +1100
    Re: Correct idiom for determining path when frozen in 3.4 Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2014-03-17 09:52 +0000
    Re: Correct idiom for determining path when frozen in 3.4 Mark Summerfield <list@qtrac.plus.com> - 2014-03-17 08:31 -0700
      Re: Correct idiom for determining path when frozen in 3.4 Zachary Ware <zachary.ware+pylist@gmail.com> - 2014-03-17 11:03 -0500

#68413 — Correct idiom for determining path when frozen in 3.4

Hi,

What is the correct idiom for getting the path to a top-level module in 3.3 and 3.4 when the module might be frozen?

At the moment I'm using this:

    if getattr(sys, "frozen", False):
        path = os.path.dirname(sys.executable)
    else:
        path = os.path.dirname(__file__)

Thanks!

[toc] | [next] | [standalone]

#68415

Mark Summerfield <list@qtrac.plus.com> writes:

> What is the correct idiom for getting the path to a top-level module

I'm not sure I understand what this concept is. What do you mean by
“top-level module”?

> in 3.3 and 3.4 when the module might be frozen?
>
> At the moment I'm using this:
>
>     if getattr(sys, "frozen", False):
>         path = os.path.dirname(sys.executable)
>     else:
>         path = os.path.dirname(__file__)

That looks okay. Does it work?

The code is readable and Pythonic as is. But I would suggest several
improvements::

    if getattr(sys, "frozen"):    # ‘getattr’ will return None by default

Also, why test for “sys.frozen” when you're about to use
“sys.executable”?

    if getattr(sys, "executable"):

Lastly, it's slightly more Pythonic to execute the normal path
unconditionally, and let it raise an exception if there's a problem::

    try:
        executable = sys.executable
    except AttributeError:
        executable = __file__
    path = os.path.dirname(executable)

-- 
 \     “It is far better to grasp the universe as it really is than to |
  `\    persist in delusion, however satisfying and reassuring.” —Carl |
_o__)                                                            Sagan |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#68416

On Mon, Mar 17, 2014 at 2:02 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
> Mark Summerfield <list@qtrac.plus.com> writes:
>     if getattr(sys, "frozen"):    # ‘getattr’ will return None by default

No it won't.

> Lastly, it's slightly more Pythonic to execute the normal path
> unconditionally, and let it raise an exception if there's a problem::
>
>     try:
>         executable = sys.executable
>     except AttributeError:
>         executable = __file__
>     path = os.path.dirname(executable)

Sure, but sys.executable always exists. sys.frozen doesn't, and the
existence or nonexistence is apparently meaningful; so your code does
something different than the original problem statement.

Also, if that weren't the case, I'd really replace that try-except
with getattr(sys, 'executable', __file__)

-- Devin

[toc] | [prev] | [next] | [standalone]

#68417

Devin Jeanpierre <jeanpierreda@gmail.com> writes:

> On Mon, Mar 17, 2014 at 2:02 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
> > Mark Summerfield <list@qtrac.plus.com> writes:
> >     if getattr(sys, "frozen"):    # ‘getattr’ will return None by default
>
> No it won't.
> […]
> Sure, but sys.executable always exists.

My apologies for posting untested code without making that clear. Thanks
to Devin for picking up my mistakes.

> > Lastly, it's slightly more Pythonic to execute the normal path
> > unconditionally, and let it raise an exception if there's a problem::
> >
> >     try:
> >         executable = sys.executable
> >     except AttributeError:
> >         executable = __file__
> >     path = os.path.dirname(executable)

> sys.frozen doesn't [necessarily exist], and the existence or
> nonexistence is apparently meaningful; so your code does something
> different than the original problem statement.

Right. I didn't understand why ‘__file__’ is a suitable substitute for
‘sys.executable’; they're always (?) different values. So that probably
is what led to the confusion in the code behaviour.

I hope the Pythonic idioms are helpful to the original poster
nevertheless.

-- 
 \      “Anyone who believes exponential growth can go on forever in a |
  `\        finite world is either a madman or an economist.” —Kenneth |
_o__)                                                         Boulding |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#68418

On 17 March 2014 08:44, Mark Summerfield <list@qtrac.plus.com> wrote:
> Hi,
>
> What is the correct idiom for getting the path to a top-level module in 3.3 and 3.4 when the module might be frozen?
>
> At the moment I'm using this:
>
>     if getattr(sys, "frozen", False):
>         path = os.path.dirname(sys.executable)
>     else:
>         path = os.path.dirname(__file__)

Why do you want to know this? Does pkgutil.get_data do what you want?

http://docs.python.org/3.3/library/pkgutil.html#pkgutil.get_data


Oscar

[toc] | [prev] | [next] | [standalone]

#68428

On Monday, 17 March 2014 08:44:23 UTC, Mark Summerfield  wrote:
> Hi,
> 
> 
> 
> What is the correct idiom for getting the path to a top-level module in 3.3 and 3.4 when the module might be frozen?
> 
> 
> 
> At the moment I'm using this:
> 
> 
> 
>     if getattr(sys, "frozen", False):
> 
>         path = os.path.dirname(sys.executable)
> 
>     else:
> 
>         path = os.path.dirname(__file__)
> 
> 
> 
> Thanks!

My code was adapted from this:
http://cx-freeze.readthedocs.org/en/latest/faq.html#using-data-files

When you freeze a Python program with cx_Freeze, sys.freeze exists; but otherwise it doesn't.

I develop some programs which I freeze for distribution but during development I test them as-is so I need to be able to distinguish.

Also, from 3.4, __file__ won't exist in frozen modules:
http://docs.python.org/3.4/whatsnew/3.4.html#changes-in-the-python-api

Thanks for your thoughtful replies.

[toc] | [prev] | [next] | [standalone]

#68430

On Mon, Mar 17, 2014 at 10:31 AM, Mark Summerfield <list@qtrac.plus.com> wrote:
> My code was adapted from this:
> http://cx-freeze.readthedocs.org/en/latest/faq.html#using-data-files
>
> When you freeze a Python program with cx_Freeze, sys.freeze exists; but otherwise it doesn't.
>
> I develop some programs which I freeze for distribution but during development I test them as-is so I need to be able to distinguish.
>
> Also, from 3.4, __file__ won't exist in frozen modules:
> http://docs.python.org/3.4/whatsnew/3.4.html#changes-in-the-python-api

Have a look at __spec__, specifically __spec__.origin:

>>> import sys
>>> _fi = sys.modules['_frozen_importlib']
>>> _fi
<module '_frozen_importlib' (frozen)>
>>> _fi.__spec__
ModuleSpec(name='_frozen_importlib', loader=<class
'_frozen_importlib.FrozenImporter'>, origin='<frozen>')
>>> _fi.__spec__.origin
'<frozen>'

I've not looked up in the importlib docs to confirm, but that should
mean that frozen modules should have a __spec__.origin that contains
"frozen".

HTH,
-- 
Zach

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web