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]

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.

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

 

[Rune Strand]

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__.replace('\\', '/').rsplit('/', 1)[-1]

 

[Diez B. Roggisch]

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.

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

solve_my_problems()

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.

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

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

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



Diez

 

[Stefan Rank]

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

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

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

I would say that::

import os
filename = os.path.basename(__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]

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]

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.

those modules are already imported when Python gets to your code, so
the only "overhead" you're saving is a little typing.

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

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.basename(__file__)

</F>

 

[Diez B. Roggisch]

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.

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_problem()-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]

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_problem()-example.

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]

those modules are already imported when Python gets to your code, so

the only "overhead" you're saving is a little typing.

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.

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.basename(__file__)

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]

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?

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_file_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).

Maybe I'm wrong here, and accessing the filesystem and reading the
module into memory represents no cost. My mistake, in that case.

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'].

It may be lousy, but it requires no imports. And, as I said in the

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]

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

 

[Steve Holden]

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

Make that "...when someone beats me over the head with it" ;-) Glad you
have the explanation you needed, anyway.

regards
Steve

 

[Fredrik Lundh]

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?

because they are imported for Python's own purposes, together with lots
of other stuff:

> python Python 2.4.2

['copy_reg', 'locale', '__main__', 'site', '__builtin__', 'encodings', 'os.path'
, 'encodings.cp437', 'encodings.codecs', 'ntpath', 'UserDict', 'encodings.except
ions', 'nt', 'stat', 'zipimport', 'warnings', 'encodings.types', '_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)

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.

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]

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

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

 

[Rune Strand]

I've read a lot of your comments the last years. Your friendliness
always strikes me.

 

[Fredrik Lundh]

I've read a lot of your comments the last years. Your friendliness
always strikes me.

terseness != unfriendlyness

</F>

 

[Magnus Lycka]

I've read a lot of your comments the last years. Your friendliness
always strikes me.

Trying to be ironic? He *is* always right though!

If ones ideas are getting shut down by people like Fredrik
and Steve, the rational reaction would be to assume that
they are right and that it was a bad idea. Sure, it's ok to
ask follow-up questions to understand why, but you can't expect
everybody to spend as much time explaining as Alex did, and
comments like "in your rush to pin-point lousy code, you
didn't read that, I suppose" aren't exactly constructive.

There are certainly postings made by various people in fora
such as comp.lang.python that seem less friendly than one
would prefer, and text based fora such as these obviously
don't give the same immediate emotional feedback as face to
face communication, so it's easy to hurt or get hurt, even
if that's not what people intend.

This is a small "cost" that comes with usenet and mailing
lists, and I think it's clearly worth it for us who ask for
help.

If you've read a lot of Fredrik's comments the last years, I
assume you've figured out by now that he knows Python very,
very well, and spends a lot of time helping a lot of people.
He also belongs to the fairly small group of people who've
made significant contributions to the Python core and also
written excellent third party modules.

You might feel that he's a bit grumpy for your taste, but I
think that we all owe him and many others on comp.lang.python
a lot. Don't bite the hand that feeds you.

I certainly prefer grumpy but good advice over friendly rubbish.


/Magnus