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:
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]_:
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:
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:
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.com>wrote:
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
There is no chance that will ever happen.
I'd like to ask for two perspectives: 1. technical feasibility
I don't see why it wouldn't be technically possible since I made it work in Python 3.4.
2. 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.
On Wed, Jan 1, 2014 at 9:01 PM, anatoly techtonik <techtonik@gmail.com> wrote:
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]_:
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:
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:
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.com>wrote:
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
There is no chance that will ever happen.
I'd like to ask for two perspectives: 1. technical feasibility
I don't see why it wouldn't be technically possible since I made it work in Python 3.4.
2. 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