Re: [Python-Dev] [Python-checkins] r45770 - in python/trunk:
On Fri, Apr 28, 2006 at 01:13:21AM +0200, thomas.wouters wrote:
- Warn-raise ImportWarning when importing would have picked up a directory as package, if only it'd had an __init__.py. This swaps two tests (for case-ness and __init__-ness), but case-test is not really more expensive, and it's not in a speed-critical section.
For the what's new, I'd like to clarify the purpose of this change. Is the plan to make __init__.py optional in subpackages in 2.6, and this warning is a first step toward that? Or is this just to improve the error reporting when a directory lacking an __init__.py is found, and no further changes will be in 2.6? --amk
A.M. Kuchling wrote:
On Fri, Apr 28, 2006 at 01:13:21AM +0200, thomas.wouters wrote:
- Warn-raise ImportWarning when importing would have picked up a directory as package, if only it'd had an __init__.py. This swaps two tests (for case-ness and __init__-ness), but case-test is not really more expensive, and it's not in a speed-critical section.
For the what's new, I'd like to clarify the purpose of this change. Is the plan to make __init__.py optional in subpackages in 2.6, and this warning is a first step toward that? Or is this just to improve the error reporting when a directory lacking an __init__.py is found, and no further changes will be in 2.6?
From what I have read out of the quite lengthy thread on this topic, there's no decision yet. Georg
A.M. Kuchling wrote:
On Fri, Apr 28, 2006 at 01:13:21AM +0200, thomas.wouters wrote:
- Warn-raise ImportWarning when importing would have picked up a directory as package, if only it'd had an __init__.py. This swaps two tests (for case-ness and __init__-ness), but case-test is not really more expensive, and it's not in a speed-critical section.
For the what's new, I'd like to clarify the purpose of this change. Is the plan to make __init__.py optional in subpackages in 2.6, and this warning is a first step toward that? Or is this just to improve the error reporting when a directory lacking an __init__.py is found, and no further changes will be in 2.6?
I think it's hard to say because that thread moved so fast :) FWIW, my interpretation was that there was some degree of consensus that better error reporting for this situation was a good thing, but Guido still has a bit of persuading to do if he wants to make an empty __init__.py optional in subpackages for Python 2.6. So the relatively non-controversial bit (improving the error reporting) was added immediately, and the controversial bit postponed to see if the better error reporting had any effect on the demand for it. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
On 4/29/06, Nick Coghlan <ncoghlan@gmail.com> wrote:
So the relatively non-controversial bit (improving the error reporting) was added immediately, and the controversial bit postponed to see if the better error reporting had any effect on the demand for it.
This is exactly how I intended it, and I believe that's Guido's desire, too. Otherwise, he would've asked me to make the warning a FutureWarning, instead. (Which could of course still happen.) -- Thomas Wouters <thomas@python.org> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Actually after all the -1 responses I wasn't going to reconsider this for 2.x; maybe for py3k. Most of the -1 votes were unconditional; only a few respondents thought that I was proposing it for 2.5. --Guido On 4/29/06, Thomas Wouters <thomas@python.org> wrote:
On 4/29/06, Nick Coghlan <ncoghlan@gmail.com> wrote:
So the relatively non-controversial bit (improving the error reporting) was added immediately, and the controversial bit postponed to see if the better error reporting had any effect on the demand for it.
This is exactly how I intended it, and I believe that's Guido's desire, too. Otherwise, he would've asked me to make the warning a FutureWarning, instead. (Which could of course still happen.)
-- Thomas Wouters <thomas@python.org>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread! _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
"Guido van Rossum" <guido@python.org> wrote in message news:ca471dc20604291959p37b47f67k18f888dd5b9b54a7@mail.gmail.com...
Actually after all the -1 responses I wasn't going to reconsider this for 2.x; maybe for py3k.
I think there may be proposals to review and possibly revise the packing and import mechanisms for 3.0. So I think your comment about str.join "one change in the near(ish) future is enough of a transition." may turn out to be relevant here also. tjr
I may be misunderstanding what you wrote. I thought that packing and join were *only* being discussed in a py3k context? If they are being discussed in a 2.x context, then yes, these discussions ought to be moved to py3k. --Guido On 4/29/06, Terry Reedy <tjreedy@udel.edu> wrote:
"Guido van Rossum" <guido@python.org> wrote in message news:ca471dc20604291959p37b47f67k18f888dd5b9b54a7@mail.gmail.com...
Actually after all the -1 responses I wasn't going to reconsider this for 2.x; maybe for py3k.
I think there may be proposals to review and possibly revise the packing and import mechanisms for 3.0. So I think your comment about str.join "one change in the near(ish) future is enough of a transition." may turn out to be relevant here also.
tjr
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (6)
-
A.M. Kuchling -
Georg Brandl -
Guido van Rossum -
Nick Coghlan -
Terry Reedy -
Thomas Wouters