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 g
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 fal
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
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
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
> 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 ge
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 appl
