Fixing __file__ to be absolute
Fixing this thing will make my happy (or very sad if you'd like this).
Problem is described here: http://stackoverflow.com/a/6416333/239247 Summary: 1. chdir() 2. dirname(__file__) 3. FAIL
Proposal: from __future__ import abs__file__
? -- anatoly t.
On Wed, Jan 1, 2014 at 9:01 PM, anatoly techtonik techtonik@gmail.com wrote:
Fixing this thing will make my happy (or very sad if you'd like this).
Problem is described here: http://stackoverflow.com/a/6416333/239247 Summary:
- chdir()
- dirname(__file__)
- FAIL
Proposal: from __future__ import abs__file__
Anatoly, this subject was already discussed on this list, just three months ago, in a thread you started! [1]_
To quote one of Nick Coglahan's replies [2]_:
Note that any remaining occurrences of non-absolute values in __file__ are generally considered bugs in the import system. However, we tend not to fix them in maintenance releases, since converting relative paths to absolute paths runs a risk of breaking user code.
We're definitely *not* going to further pollute the module namespace with values that can be trivially and reliably derived from existing values.
- Tal
.. [1]: https://mail.python.org/pipermail/python-ideas/2013-September/023469.html .. [2]: https://mail.python.org/pipermail/python-ideas/2013-September/023486.html
On Thu, Jan 2, 2014 at 7:37 AM, Tal Einat taleinat@gmail.com wrote:
On Wed, Jan 1, 2014 at 9:01 PM, anatoly techtonik techtonik@gmail.com wrote:
Fixing this thing will make my happy (or very sad if you'd like this).
Problem is described here: http://stackoverflow.com/a/6416333/239247 Summary:
- chdir()
- dirname(__file__)
- FAIL
Proposal: from __future__ import abs__file__
Anatoly, this subject was already discussed on this list, just three months ago, in a thread you started! [1]_
To quote one of Nick Coglahan's replies [2]_:
Note that any remaining occurrences of non-absolute values in __file__
are
generally considered bugs in the import system. However, we tend not to
fix
them in maintenance releases, since converting relative paths to absolute paths runs a risk of breaking user code.
We're definitely *not* going to further pollute the module namespace with values that can be trivially and reliably derived from existing values.
This was also changed in Python 3.4 back in October: http://hg.python.org/cpython/rev/76184b5339f2
On Thu, Jan 2, 2014 at 4:28 PM, Brett Cannon brett@python.org wrote:
On Thu, Jan 2, 2014 at 7:37 AM, Tal Einat taleinat@gmail.com wrote:
On Wed, Jan 1, 2014 at 9:01 PM, anatoly techtonik techtonik@gmail.com wrote:
Fixing this thing will make my happy (or very sad if you'd like this).
Problem is described here: http://stackoverflow.com/a/6416333/239247 Summary:
- chdir()
- dirname(__file__)
- FAIL
Proposal: from __future__ import abs__file__
Anatoly, this subject was already discussed on this list, just three months ago, in a thread you started! [1]_
To quote one of Nick Coglahan's replies [2]_:
Note that any remaining occurrences of non-absolute values in __file__ are generally considered bugs in the import system. However, we tend not to fix them in maintenance releases, since converting relative paths to absolute paths runs a risk of breaking user code.
We're definitely *not* going to further pollute the module namespace with values that can be trivially and reliably derived from existing values.
This was also changed in Python 3.4 back in October: http://hg.python.org/cpython/rev/76184b5339f2
Thanks. That's just what I was looking for - a status update. Links in emails are not telling anything about progress being made, roadmap, problems and versions of Python. Seem like tracker is a poor tool to track this stuff too.
Now in spite of recent Python 3 status update, the question is how possible to make this feature more visible and implemented in previous version as from __future__ import abs__file__?
I'd like to ask for two perspectives: 1. technical feasibility 2. political obstacles (backward compatibility policy / process obstacles), even if they are obvious
Also, what is the process of nominating this features to selection in Python 2.8 (or whatever comes out of this incremental development idea)?
So, three questions with ideas in total. -- anatoly t.
On Thu, Jan 2, 2014 at 8:46 AM, anatoly techtonik techtonik@gmail.comwrote:
On Thu, Jan 2, 2014 at 4:28 PM, Brett Cannon brett@python.org wrote:
On Thu, Jan 2, 2014 at 7:37 AM, Tal Einat taleinat@gmail.com wrote:
On Wed, Jan 1, 2014 at 9:01 PM, anatoly techtonik techtonik@gmail.com wrote:
Fixing this thing will make my happy (or very sad if you'd like this).
Problem is described here: http://stackoverflow.com/a/6416333/239247 Summary:
- chdir()
- dirname(__file__)
- FAIL
Proposal: from __future__ import abs__file__
Anatoly, this subject was already discussed on this list, just three months ago, in a thread you started! [1]_
To quote one of Nick Coglahan's replies [2]_:
Note that any remaining occurrences of non-absolute values in __file__ are generally considered bugs in the import system. However, we tend not
to
fix them in maintenance releases, since converting relative paths to absolute paths runs a risk of breaking user code.
We're definitely *not* going to further pollute the module namespace with values that can be trivially and reliably derived from existing
values.
This was also changed in Python 3.4 back in October: http://hg.python.org/cpython/rev/76184b5339f2
Thanks. That's just what I was looking for - a status update. Links in emails are not telling anything about progress being made, roadmap, problems and versions of Python. Seem like tracker is a poor tool to track this stuff too.
It's not in released code yet so there is no way to really promote this in a way that is guaranteed not to change. It will be in the What's New doc for Python 3.4, though, when the final version is released: http://docs.python.org/3.4/whatsnew/3.4.html#other-language-changes
Now in spite of recent Python 3 status update, the question is how possible to make this feature more visible and implemented in previous version as from __future__ import abs__file__?
There is no chance that will ever happen.
I'd like to ask for two perspectives:
- technical feasibility
I don't see why it wouldn't be technically possible since I made it work in Python 3.4.
- political obstacles (backward compatibility policy / process obstacles), even if they are obvious
It would be a total break in backwards-compatibility by adding a new feature in a bugfix release and that's never acceptable (and that rule has been in effect since Python 2.2.1).
Also, what is the process of nominating this features to selection in Python 2.8 (or whatever comes out of this incremental development idea)?
There is no future Python 2.8 release so there is no process to nominate something; PEP 404 is very clear on this: http://python.org/dev/peps/pep-0404/ . And there is no "incremental development idea" or something that's going to change the current development process of Python so that part of the questions doesn't make sense to me.
participants (3)
-
anatoly techtonik -
Brett Cannon -
Tal Einat