Re: Application and package of the same name

2017-10-21 Thread Christopher Reimer 
On Oct 21, 2017, at 6:08 AM, David Stanek  wrote:

> This is actually a common pattern I see when teaching the language. For
> example, when a student wants to test out a package like requests many
> seem to initially want to create a requests.py module. Then they become
> very confused when they get an AttributeError on requests.get().

For my web scraper program, I'm using "requestor.py" for requests. :)

Chris R.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Application and package of the same name

2017-10-21 Thread Skip Montanaro 
This is actually a common pattern I see when teaching the language. For
example, when a student wants to test out a package like requests many
seem to initially want to create a requests.py module. Then they become
very confused when they get an AttributeError on requests.get().


That I should fall prey to this after using Python for over 20 years...
Should I be humbled, ashamed, delighted that I unwittingly demonstrated
something I've seen in others' code?

The sequence of events here was that I actually did have my main program
inside the package, but wanted to separate the two, since the package is
installed for clients of the allocation to use. As I was moving the
application into a Docker environment, it made sense to extract the main
program from the package and copy it separately into the image. I just git
mv'd the file from the package directory to the scripts directory, and it
stopped working. I should have realized right then and there what I'd done
wrong, but I got hung up thinking I'd done something wrong with absolute
imports.

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Application and package of the same name

2017-10-21 Thread David Stanek 
On 19-Oct 19:34, Paul Moore wrote:
> On 19 October 2017 at 19:18, Skip Montanaro  wrote:
> >
> > This is in Python 2.7, FWIW. What am I missing?
> 
> My immediate reaction is "you shouldn't name your main program and
> your package the same". It's not a pattern I've seen commonly used.
> 

This is actually a common pattern I see when teaching the language. For
example, when a student wants to test out a package like requests many
seem to initially want to create a requests.py module. Then they become
very confused when they get an AttributeError on requests.get().

-- 
david stanek
web: https://dstanek.com
twitter: https://twitter.com/dstanek
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Application and package of the same name

2017-10-19 Thread Skip Montanaro 
Have you toyed with "from __future__ import absolute_import" ? Not
sure if it'd help or not, but worth a try.


Yeah, I did, but it didn't change anything as far as I could tell.

S
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Application and package of the same name

2017-10-19 Thread Chris Angelico 
On Fri, Oct 20, 2017 at 7:09 AM, Skip Montanaro
 wrote:
>> My immediate reaction is "you shouldn't name your main program and
>> your package the same". It's not a pattern I've seen commonly used.
>>
>> However, the approaches I've seen used (a __main__.py inside the
>> package, so you can execute it via `python -m fribble`, or a setup.py
>> entry point to generate a script wrapper for the application) may be
>> more common among people focused more on library development than on
>> application development.
>
> Thanks Paul. The simplest course for me is to change the name of the
> application,
> as the package is already in use by other people, and I don't really
> want to embed the
> application in the package.
>

Have you toyed with "from __future__ import absolute_import" ? Not
sure if it'd help or not, but worth a try.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Application and package of the same name

2017-10-19 Thread Skip Montanaro 
> My immediate reaction is "you shouldn't name your main program and
> your package the same". It's not a pattern I've seen commonly used.
>
> However, the approaches I've seen used (a __main__.py inside the
> package, so you can execute it via `python -m fribble`, or a setup.py
> entry point to generate a script wrapper for the application) may be
> more common among people focused more on library development than on
> application development.

Thanks Paul. The simplest course for me is to change the name of the
application,
as the package is already in use by other people, and I don't really
want to embed the
application in the package.

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Application and package of the same name

2017-10-19 Thread Paul Moore 
On 19 October 2017 at 19:18, Skip Montanaro  wrote:
> I'm not understanding something fundamental about absolute/relative
> imports. Suppose I have an application, fribble.py, and it has a
> corresponding package full of goodies it relies on, also named fribble.
> From the fribble package, the application wants to import the sandwich
> function from the lunchtime module. At the top level it thus has an import
> like this:
>
> from fribble.lunchtime import sandwich
>
> I might have a directory structure like this:
>
> example
> example/fribble.py
> fribble
> __init__.py
> lunchtime.py
>
> If I run inside the example directory with PYTHONPATH=.. I can't
> find/import the fribble package, because the main application directory is
> prepended to sys.path. Consequently, the import machinery never gets any
> further down sys.path. It stumbles on the fribble application and tries to
> find the bits it's interested in, to no avail.
>
> This is in Python 2.7, FWIW. What am I missing?

My immediate reaction is "you shouldn't name your main program and
your package the same". It's not a pattern I've seen commonly used.

However, the approaches I've seen used (a __main__.py inside the
package, so you can execute it via `python -m fribble`, or a setup.py
entry point to generate a script wrapper for the application) may be
more common among people focused more on library development than on
application development.

Paul
-- 
https://mail.python.org/mailman/listinfo/python-list

Application and package of the same name

2017-10-19 Thread Skip Montanaro 
I'm not understanding something fundamental about absolute/relative
imports. Suppose I have an application, fribble.py, and it has a
corresponding package full of goodies it relies on, also named fribble.
>From the fribble package, the application wants to import the sandwich
function from the lunchtime module. At the top level it thus has an import
like this:

from fribble.lunchtime import sandwich

I might have a directory structure like this:

example
example/fribble.py
fribble
__init__.py
lunchtime.py

If I run inside the example directory with PYTHONPATH=.. I can't
find/import the fribble package, because the main application directory is
prepended to sys.path. Consequently, the import machinery never gets any
further down sys.path. It stumbles on the fribble application and tries to
find the bits it's interested in, to no avail.

This is in Python 2.7, FWIW. What am I missing?

Thx,

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list