Adding a __filename__ predefined attribute to 2.5?

[Rune Strand]

Is it an idea to include a new __filename__ predefined attribute to
2.5, so that __file__ contains the entire path to the module, and
__filename__ only the name of the module?

For instance it's useful to include a not-static reference to the
filename in a scripts usage() section and it's cumbersome to extract
the filename or to do module imports just to parse it.

[Steve Holden]

Re: Adding a __filename__ predefined attribute to 2.5?

Rune Strand wrote:[color=blue]
> Is it an idea to include a new __filename__ predefined attribute to
> 2.5, so that __file__ contains the entire path to the module, and
> __filename__ only the name of the module?
>
> For instance it's useful to include a not-static reference to the
> filename in a scripts usage() section and it's cumbersome to extract
> the filename or to do module imports just to parse it.
>[/color]
No. It's not usually a good idea to remove complexity from your program
by adding it (where most of the time it's not needed) to the underlying
system. Here's a clue as to how you might do without __file__ altogether:

sholden@bigboy ~/Projects/Python
$ cat test78.py
import sys
print sys.argv

sholden@bigboy ~/Projects/Python
$ python test78.py can we say live with it?
['test78.py', 'can', 'we', 'say', 'live', 'with', 'it?']

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Rune Strand]

Re: Adding a __filename__ predefined attribute to 2.5?

I Steve,

I know it's several ways to isolate the filename. I just want to avoid
the overhead of importing sys or os to achieve it.

Currently I have this in my scripts:
__filename__ = __file__.replac e('\\', '/').rsplit('/', 1)[-1]

[Diez B. Roggisch]

Re: Adding a __filename__ predefined attribute to 2.5?

Rune Strand wrote:[color=blue]
> I Steve,
>
> I know it's several ways to isolate the filename. I just want to avoid
> the overhead of importing sys or os to achieve it.[/color]

What overhead? Besides: if you want to do python this, why don't we
introduce the function

solve_my_proble ms()

that is the only thing a programmer has to invoke... Seriously: Just
because you have a usecase for __filename__ doesn't mean everybody else has.
[color=blue]
> Currently I have this in my scripts:
> __filename__ = __file__.replac e('\\', '/').rsplit('/', 1)[-1][/color]

This is neither platform independent nor less "overhead". This is:

import os
__filname__ = os.path.split(_ _file__)[-1]



Diez

[Stefan Rank]

Re: Adding a __filename__ predefined attribute to 2.5?

on 12.10.2005 10:02 Diez B. Roggisch said the following:[color=blue]
> Rune Strand wrote:
>[color=green]
>>Currently I have this in my scripts:
>>__filename_ _ = __file__.replac e('\\', '/').rsplit('/', 1)[-1][/color]
>
> This is neither platform independent nor less "overhead". This is:
>
> import os
> __filname__ = os.path.split(_ _file__)[-1]
>[/color]

I would say that::

import os
filename = os.path.basenam e(__file__)

is even more explicit.

And with one of the several existing 'path' modules it would be::

from path import path
filename = path(__file__). basename


I am sorry if I missed this on this list,
but was there a decision on the idea of including an object-oriented
path class in the standard library?

cheers,
stefan

[Rune Strand]

Re: Adding a __filename__ predefined attribute to 2.5?

Excuse me, do you suffer from a bad hair-day? I didn't say it is
platform independant. It's ok for my use on Linux and Windows. If you
cannot imagine any other usecase for a __filename__ attribute, that's
your problem, not mine.

[Fredrik Lundh]

Re: Adding a __filename__ predefined attribute to 2.5?

Rune Strand wrote:
[color=blue]
> I know it's several ways to isolate the filename. I just want to avoid
> the overhead of importing sys or os to achieve it.[/color]

those modules are already imported when Python gets to your code, so
the only "overhead" you're saving is a little typing.
[color=blue]
> Currently I have this in my scripts:
> __filename__ = __file__.replac e('\\', '/').rsplit('/', 1)[-1][/color]

wow. that's one lousy optimization...

here's a *shorter* piece of code, which is also readable and portable, and
a lot easier to type on most keyboards:

import os
__filename__ = os.path.basenam e(__file__)

</F>

[Diez B. Roggisch]

Re: Adding a __filename__ predefined attribute to 2.5?


Rune Strand wrote:[color=blue]
> Excuse me, do you suffer from a bad hair-day? I didn't say it is
> platform independant. It's ok for my use on Linux and Windows. If you
> cannot imagine any other usecase for a __filename__ attribute, that's
> your problem, not mine.[/color]

I think you are the one who wants __filename__, not me. So I don't have
to have any usecase for it.

And requesting random features built into the interpreter without even
specifying a usecase - as remote as it may be - isn't very likely
happen, don't you think? Which I wanted to express with my apparently
misunderstood solve_my_proble m()-example.

And if your solution isn't platform-independent and one (several people
actually) provides you with one that is short and concise and no
overhead at all - well, that _could_ trigger a "cool, didn't know about
that"-reaction. But obviously, it hasn't.

Diez

[Diez B. Roggisch]

Re: Adding a __filename__ predefined attribute to 2.5?


Diez B. Roggisch wrote:
[color=blue]
> And requesting random features built into the interpreter without even
> specifying a usecase - as remote as it may be - isn't very likely
> happen, don't you think? Which I wanted to express with my apparently
> misunderstood solve_my_proble m()-example.[/color]

Reread your post - you did specify it. So forget about that. Maybe I
_have_ a bad hair day - even though I'm pretty bald. Might be because
of too much JAVA these days... *sigh*

Sorry.

Diez

[Rune Strand]

Re: Adding a __filename__ predefined attribute to 2.5?

> those modules are already imported when Python gets to your code, so[color=blue]
> the only "overhead" you're saving is a little typing.[/color]

I don't understand this. Could you please elaborate? - if sys or os
are not imported for any other causes how are they already imported?
Maybe I'm wrong here, and accessing the filesystem and reading the
module into memory represents no cost. My mistake, in that case.
[color=blue]
> wow. that's one lousy optimization...[/color]
[color=blue]
> here's a *shorter* piece of code, which is also readable and portable, and
> a lot easier to type on most keyboards:[/color]
[color=blue]
> import os
> __filename__ = os.path.basenam e(__file__)[/color]

It may be lousy, but it requires no imports. And, as I said in the
answer to Steve, I _know_ there are many ways to achieve this,
including yours. But in your rush to pin-point lousy code, you didn't
read that, I suppose.

[Alex Martelli]

Re: Adding a __filename__ predefined attribute to 2.5?

Rune Strand <rune.strand@gm ail.com> wrote:
[color=blue][color=green]
> > those modules are already imported when Python gets to your code, so
> > the only "overhead" you're saving is a little typing.[/color]
>
> I don't understand this. Could you please elaborate? - if sys or os
> are not imported for any other causes how are they already imported?[/color]

The "other causes" are always present, since these modules include
functionality Python always needs -- a fact that is no big secret,
either. For example: you know (I assume and hope) that Python's import
statement finds files to import along directories (and zipfiles) listed
in sys.path -- so how do you think 'sys' itself can possibly get
'imported' in the first place, since the import mechanism depends on one
of sys's attributes...? Answer: sys is a built-in module, compiled into
the Python interpreter itself. There are several, see
sys.builtin_fil e_names for a list. 'os' is a slightly different case --
it's not built-in, but gets imported anyway during startup because other
modules need it anyway. In my build of Python 2.4.1, there are 16
built-in modules, and 9 others that aren't built-in but get imported at
startup -- check sys.modules on your version for the total number of
modules that are in memory by the time any code of yours runs. (This is
with -S to inhibit Python from reading the site.py module, otherwise you
might get more... but never, I believe, could you get fewer).
[color=blue]
> Maybe I'm wrong here, and accessing the filesystem and reading the
> module into memory represents no cost. My mistake, in that case.[/color]

Your mistake is due to a different case: the filesystem access and
reading have ALREADY happened (for os; for sys, as I explained, the
mechanism is different). Therefore, an import does NO such access and
reading -- it just gets the module object from (e.g.) sys.modules['os'].

[color=blue][color=green]
> > wow. that's one lousy optimization...[/color]
>[color=green]
> > here's a *shorter* piece of code, which is also readable and portable, and
> > a lot easier to type on most keyboards:[/color]
>[color=green]
> > import os
> > __filename__ = os.path.basenam e(__file__)[/color]
>
> It may be lousy, but it requires no imports. And, as I said in the[/color]

The point is that there's no substantial advantage to "requiring no
imports". Python, if anything, already has too many built-ins -- once
backwards compatibility can be broken (i.e., in 3.0), many of them
should be moved to standard library modules, "requiring imports" (which
are cheap operations anyway). The desire for MORE built-ins with no
real advantage (since "requiring no imports" ISN'T a true advantage) is
definitely misplaced.


Alex

[Rune Strand]

Re: Adding a __filename__ predefined attribute to 2.5?

Ok, Alex. I know a good explanation when I see one. Thanks!

[Steve Holden]

Re: Adding a __filename__ predefined attribute to 2.5?

Rune Strand wrote:[color=blue]
> Ok, Alex. I know a good explanation when I see one. Thanks!
>[/color]
Make that "...when someone beats me over the head with it" ;-) Glad you
have the explanation you needed, anyway.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Fredrik Lundh]

Re: Adding a __filename__ predefined attribute to 2.5?

Rune Strand wrote:
[color=blue][color=green]
>> those modules are already imported when Python gets to your code, so
>> the only "overhead" you're saving is a little typing.[/color]
>
> I don't understand this. Could you please elaborate? - if sys or os
> are not imported for any other causes how are they already imported?[/color]

because they are imported for Python's own purposes, together with lots
of other stuff:
[color=blue]
> python[/color]
Python 2.4.2[color=blue][color=green][color=darkred]
>>> import sys
>>> sys.modules.key s()[/color][/color][/color]
['copy_reg', 'locale', '__main__', 'site', '__builtin__', 'encodings', 'os.path'
, 'encodings.cp43 7', 'encodings.code cs', 'ntpath', 'UserDict', 'encodings.exce pt
ions', 'nt', 'stat', 'zipimport', 'warnings', 'encodings.type s', '_codecs', 'enc
odings.cp1252', 'sys', 'codecs', 'types', '_locale', 'signal', 'linecache', 'enc
odings.aliases' , 'exceptions', 'os']

(sys is a built-in module, btw, so the cost of importing that is always close to zero)
[color=blue]
> It may be lousy, but it requires no imports. And, as I said in the
> answer to Steve, I _know_ there are many ways to achieve this,
> including yours. But in your rush to pin-point lousy code, you didn't
> read that, I suppose.[/color]

you know, being clueless is one thing, but being both clueless and arrogant is
not a good way to get anywhere. I suggest spending more time learning things
(start with the language reference), and less time picking fights that leads no-
where.

</F>

[Alex Martelli]

Re: Adding a __filename__ predefined attribute to 2.5?

Rune Strand <rune.strand@gm ail.com> wrote:
[color=blue]
> Ok, Alex. I know a good explanation when I see one. Thanks![/color]

You're welcome! I've tried to give good (but shorter!-) explanations in
the Nutshell, too, but of course it's easier to aim a specific
explanation to a specific questioner than to try and clarify
"everything " for "everybody" (particularly because, when posting, I'm
not forced to be concise as I am when writing books or articles, so I
can aim more relentlessly for completeness and precision...).


Alex