On Fri, Dec 5, 2014 at 9:10 AM, Wolfgang Maier
wrote:
> which I read as there has been a stepwise transition between 2.5 and 2.7 so
> that 2.7 now behaves like Python 3 even without the __future__ statement.
> OTOH, I believe you, of course, if you're saying implicit relative imports
> are working
On 04.12.2014 22:30, Chris Angelico wrote:
On Fri, Dec 5, 2014 at 7:56 AM, Wolfgang Maier
wrote:
On 04.12.2014 19:05, Chris Angelico wrote:
With os.path it definitely is. With the actual code in question, it's
a Python 2.7 project that mostly uses relative imports - inside
package.module1 is
On Fri, Dec 5, 2014 at 7:56 AM, Wolfgang Maier
wrote:
> On 04.12.2014 19:05, Chris Angelico wrote:
>>
>>
>> With os.path it definitely is. With the actual code in question, it's
>> a Python 2.7 project that mostly uses relative imports - inside
>> package.module1 is "import module2" etc - and I wa
On 04.12.2014 19:05, Chris Angelico wrote:
With os.path it definitely is. With the actual code in question, it's
a Python 2.7 project that mostly uses relative imports - inside
package.module1 is "import module2" etc - and I was writing an
external script that calls on one of the modules.
What
On Fri, Dec 5, 2014 at 4:36 AM, Jean-Michel Pichavant
wrote:
> I know you specifically stated you didn't want to do this but
>
> import os
>
> os.path.isfile()
>
> is the best option imo, especially from the reader point of view ("Namespaces
> are one honking great idea").
With os.path it defini
On 12/03/2014 03:02 AM, Chris Angelico wrote:
>
> Throughout the code, I want to refer to "path.split()",
> "path.isfile()", etc, without the "os." in front of them. I could do
> either of these:
>
> import os.path as path
> from os import path
>
> Which one would you recommend? Does it depend o
On 12/04/2014 09:36 AM, Jean-Michel Pichavant wrote:
>
> I know you specifically stated you didn't want to do this but
>
> import os
>
> os.path.isfile()
>
> is the best option imo, especially from the reader point of view ("Namespaces
> are one honking great idea").
But, "Flat is better
- Original Message -
> From: "Chris Angelico"
> To: python-list@python.org
> Sent: Wednesday, 3 December, 2014 12:02:17 PM
> Subject: Style question: Importing modules from packages - 'from' vs 'as'
>
> When importing a module from a subpac
On 12/03/2014 12:02 PM, Chris Angelico wrote:
When importing a module from a subpackage, it's sometimes convenient
to refer to it throughout the code with a one-part name rather than
two. I'm going to use 'os.path' for the examples, but my actual
use-case is a custom package where the package nam
On 12/3/2014 6:02 AM, Chris Angelico wrote:
When importing a module from a subpackage, it's sometimes convenient
to refer to it throughout the code with a one-part name rather than
two. I'm going to use 'os.path' for the examples, but my actual
use-case is a custom package where the package name
On Dec 3, 2014 4:34 AM, "Chris Angelico" wrote:
>
> On Wed, Dec 3, 2014 at 10:27 PM, Peter Otten <__pete...@web.de> wrote:
> > Don't repeat yourself, so
> >
> > from os import path
> >
> > always. On the other hand I have never thought about actual renames, e.
g.
> >
> > from os import path as std
On Wed, Dec 3, 2014 at 10:27 PM, Peter Otten <__pete...@web.de> wrote:
> Don't repeat yourself, so
>
> from os import path
>
> always. On the other hand I have never thought about actual renames, e. g.
>
> from os import path as stdpath
>
> versus
>
> import os.path as stdpath
>
> I think I'd use t
Chris Angelico wrote:
> When importing a module from a subpackage, it's sometimes convenient
> to refer to it throughout the code with a one-part name rather than
> two. I'm going to use 'os.path' for the examples, but my actual
> use-case is a custom package where the package name is, in the
> ap
On 3 December 2014 at 22:02, Chris Angelico wrote:
>
> import os.path as path
> from os import path
>
Bah - deleted the list and sent directly to Chris ... time to go to bed.
The advantage of the former is that if you want to use a different name,
it's a smaller change. But the disadvantage of
When importing a module from a subpackage, it's sometimes convenient
to refer to it throughout the code with a one-part name rather than
two. I'm going to use 'os.path' for the examples, but my actual
use-case is a custom package where the package name is, in the
application, quite superfluous.
Th
15 matches
Mail list logo
