+1 Excellent Change
+1 Minimal Backward Compatibility Difficulties
I think this would also help quite a bit with newbie adoption of Python.
I've had to explain this un-feature on numerous occassions and it given
how smart Python is, I've wondered why it has this requirement. If you
look in
Thomas Wouters wrote:
On 4/27/06, Thomas Wouters [EMAIL PROTECTED] wrote:
Alrighty then. The list has about 12 hours to convince me (and you) that
it's a bad idea to generate that warning. I'll be asleep by the time the
trunk un-freezes, and I have a string of early meetings tomorrow. I'll get
Thomas Wouters wrote:
Indeed! I hadn't realized that, although I might've if I'd been able to
find where Modules is put on sys.path. And, likewise, I would do as you
suggest (which feels like the right thing) if I could only find out
where Modules is put on sys.path :) I don't have time to
On 4/27/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 4/26/06, Thomas Wouters [EMAIL PROTECTED] wrote:
Of course, I only consider *my* reasons to be valid, and mine weren't
knee-jerk or tool-related. I don't think Python should be going Oh, what
you wanted wasn't possible, but I think I
On 4/27/06, Paul Moore [EMAIL PROTECTED] wrote:
However, I'd have to say that your timing sucks :-) Your initial
message read to me as Quick! I'm about to get lynched here - can I
have the OK to shove this change in before a2 goes out?
And this just proves that my response wasn't anywhere near
On Thursday 27 April 2006 17:47, Paul Moore wrote:
FWIW, I still have every confidence in your judgement about
features. However, I'd have to say that your timing sucks :-) Your
initial message read to me as Quick! I'm about to get lynched here
- can I have the OK to shove this change in
Guido van Rossum guido at python.org writes:
The requirement that a directlry must contain an __init__.py file
before it is considered a valid package has always been controversial.
It's designed to prevent the existence of a directory with a common
name like time or string from preventing
Guido van Rossum wrote:
So I have a very simple proposal: keep the __init__.py requirement for
top-level pacakages, but drop it for subpackages. This should be a
small change. I'm hesitant to propose *anything* new for Python 2.5,
so I'm proposing it for 2.6; if Neal and Anthony think this
Guido van Rossum wrote:
So I have a very simple proposal: keep the __init__.py requirement for
top-level pacakages, but drop it for subpackages. This should be a
small change. I'm hesitant to propose *anything* new for Python 2.5,
so I'm proposing it for 2.6; if Neal and Anthony think this
Guido One particular egregious problem is that *subpackage* are subject
Guido to the same rule. It so happens that there is essentially only
Guido one top-level package in the Google code base, and it already has
Guido an __init__.py file. But developers create new subpackages at
Not that it would count in any way, but I'd prefer to keep it. How
would I mark a subdirectory as not-a-package otherwise?
Guido What's the use case for that? Have you run into this requirement?
Yes, we run into it. We typically install a package with any resources in a
resources
On 4/26/06, Guido van Rossum [EMAIL PROTECTED] wrote:[...]
So I have a very simple proposal: keep the __init__.py requirement fortop-level pacakages, but drop it for subpackages. This should be asmall change. I'm hesitant to propose *anything* new for Python 2.5,so I'm proposing it for
2.6; if
Gustavo Carneiro [EMAIL PROTECTED] writes:
Now the problem. Suppose you have the source package python-foo-bar,
which installs $pythondir/foo/__init__.py and $pythondir/foo/bar.py. This
would make a module called foo.bar available. Likewise, you can have the
source package
On 4/27/06, Thomas Wouters [EMAIL PROTECTED] wrote:
Alrighty then. The list has about 12 hours to convince me (and you) that it's a bad idea to generate that warning. I'll be asleep by the time the trunk un-freezes, and I have a string of early meetings tomorrow. I'll get to it somewhere in the
At 03:48 PM 4/27/2006 +0200, Bernhard Herzog wrote:
Gustavo Carneiro [EMAIL PROTECTED] writes:
Now the problem. Suppose you have the source package python-foo-bar,
which installs $pythondir/foo/__init__.py and $pythondir/foo/bar.py. This
would make a module called foo.bar available.
On 4/27/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 03:48 PM 4/27/2006 +0200, Bernhard Herzog wrote:Gustavo Carneiro [EMAIL PROTECTED] writes: Now the problem.Suppose you have the source package python-foo-bar,
which installs $pythondir/foo/__init__.py and $pythondir/foo/bar.py.This would
On 4/27/06, Gustavo Carneiro [EMAIL PROTECTED] wrote:
On 4/27/06, Phillip J. Eby
[EMAIL PROTECTED] wrote:
At 03:48 PM 4/27/2006 +0200, Bernhard Herzog wrote:Gustavo Carneiro [EMAIL PROTECTED]
writes: Now the problem.Suppose you have the source package python-foo-bar,
which installs
On 4/27/06, Thomas Wouters [EMAIL PROTECTED] wrote:
On 4/27/06, Gustavo Carneiro
[EMAIL PROTECTED] wrote:
On 4/27/06, Phillip J. Eby
[EMAIL PROTECTED] wrote:
At 03:48 PM 4/27/2006 +0200, Bernhard Herzog wrote:Gustavo Carneiro [EMAIL PROTECTED]
writes: Now the problem.Suppose you have the
On 4/27/06, Gustavo Carneiro [EMAIL PROTECTED] wrote:
Besides, Guido's original proposal is not a fix for your problem, either; he only proposes to change the requirement for *sub*packages.
It *is* a solution for my problem. I don't need the __init__.py file for anything, since I don't need
On 4/27/06, Thomas Wouters [EMAIL PROTECTED] wrote:
On 4/27/06, Gustavo Carneiro
[EMAIL PROTECTED] wrote:
Besides, Guido's original proposal is not a fix for your problem, either; he only proposes to change the requirement for *sub*packages.
It *is* a solution for my problem. I don't need the
On 4/27/06, Thomas Wouters [EMAIL PROTECTED] wrote:
I could check it in, except the make-testall I ran overnight showed a small
problem: the patch would generate a number of spurious warnings in the
trunk:
/home/thomas/python/python/trunk/Lib/gzip.py:9:
ImportWarning: Not importing directory
(Context: There's a large crowd with pitchforks and other sharp pointy
farm implements just outside the door of my office at Google. They are
making an unbelievable racket. It appears they are Google engineers
who have been bitten by a misfeature of Python, and they won't let me
go home before I
* Guido van Rossum wrote:
So I have a very simple proposal: keep the __init__.py requirement for
top-level pacakages, but drop it for subpackages. This should be a
small change. I'm hesitant to propose *anything* new for Python 2.5,
so I'm proposing it for 2.6; if Neal and Anthony think this
Guido van Rossum wrote:
So I have a very simple proposal: keep the __init__.py requirement for
top-level pacakages, but drop it for subpackages.
So this would mean that current non-package subdirectories in a package
(that contain things like data files or configuration info) would become
On 4/26/06, André Malo [EMAIL PROTECTED] wrote:
* Guido van Rossum wrote:
So I have a very simple proposal: keep the __init__.py requirement for
top-level pacakages, but drop it for subpackages. This should be a
small change. I'm hesitant to propose *anything* new for Python 2.5,
so I'm
On 4/26/06, Benji York [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
So I have a very simple proposal: keep the __init__.py requirement for
top-level pacakages, but drop it for subpackages.
So this would mean that current non-package subdirectories in a package
(that contain things like
On 4/26/06, Barry Warsaw [EMAIL PROTECTED] wrote:
On Wed, 2006-04-26 at 10:16 -0700, Guido van Rossum wrote:
So I have a very simple proposal: keep the __init__.py requirement for
top-level pacakages, but drop it for subpackages. This should be a
small change. I'm hesitant to propose
* Guido van Rossum wrote:
On 4/26/06, André Malo [EMAIL PROTECTED] wrote:
* Guido van Rossum wrote:
So I have a very simple proposal: keep the __init__.py requirement
for top-level pacakages, but drop it for subpackages. This should be
a small change. I'm hesitant to propose
At 10:16 AM 4/26/2006 -0700, Guido van Rossum wrote:
So I have a very simple proposal: keep the __init__.py requirement for
top-level pacakages, but drop it for subpackages.
Note that many tools exist which have grown to rely on the presence of
__init__ modules. Also, although your proposal
At 02:07 PM 4/26/2006 -0400, Phillip J. Eby wrote:
def find_module(self, fullname, path=None):
# Note: we ignore 'path' argument since it is only used via
meta_path
subname = fullname.split(.)[-1]
if os.path.isdir(os.path.join(self.path,
On 4/26/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 4/26/06, Benji York [EMAIL PROTECTED] wrote: Guido van Rossum wrote: So I have a very simple proposal: keep the __init__.py requirement for top-level pacakages, but drop it for subpackages.
I don't particularly like it. You still need
Sounds a bit like the tail wagging the dog. I thought the Google geeks
were a smart bunch.
ISTM that something like Phillip Eby's code would be the most
expedient solution. I would add one extension: if a package directory
without an __init__.py file *is* encountered, an empty __init__.py
file
On 4/26/06, André Malo [EMAIL PROTECTED] wrote:
* Guido van Rossum wrote:
On 4/26/06, André Malo [EMAIL PROTECTED] wrote:
* Guido van Rossum wrote:
So I have a very simple proposal: keep the __init__.py requirement
for top-level pacakages, but drop it for subpackages. This should be
On 4/26/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 10:16 AM 4/26/2006 -0700, Guido van Rossum wrote:
So I have a very simple proposal: keep the __init__.py requirement for
top-level pacakages, but drop it for subpackages.
Note that many tools exist which have grown to rely on the presence
Guido van Rossum wrote:
On 4/26/06, Barry Warsaw [EMAIL PROTECTED] wrote:
On Wed, 2006-04-26 at 10:16 -0700, Guido van Rossum wrote:
So I have a very simple proposal: keep the __init__.py requirement for
top-level pacakages, but drop it for subpackages. This should be a
small change. I'm
* Guido van Rossum wrote:
[me]
Actually I have no problems with the change from inside python, but
from the POV of tools, which walk through the directories,
collecting/separating python packages and/or supplemental data
directories. It's an explicit vs. implicit issue, where implicit
Guido van Rossum wrote:
On 4/26/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 10:16 AM 4/26/2006 -0700, Guido van Rossum wrote:
So I have a very simple proposal: keep the __init__.py requirement for
top-level pacakages, but drop it for subpackages.
Note that many tools exist which have grown
On Wednesday 26 April 2006 15:05, André Malo wrote:
Another point is that one can even hide supplementary packages within such
a subdirectory. It's only visible to scripts inside the dir (I admit, that
the latter is not a real usecase, just a thought that came up while
writing this up).
I
Guido van Rossum wrote:
On 4/26/06, Barry Warsaw [EMAIL PROTECTED] wrote:
On Wed, 2006-04-26 at 10:16 -0700, Guido van Rossum wrote:
So I have a very simple proposal: keep the __init__.py requirement for
top-level pacakages, but drop it for subpackages. This should be a
small change. I'm
At 11:50 AM 4/26/2006 -0700, Guido van Rossum wrote:
I'm not sure what you mean by one directory read. You'd have to list
the entire directory, which may require reading more than one block if
the directory is large.
You have to do this to find an __init__.py too, don't you? Technically,
Phillip J. Eby wrote:
My counter-proposal: to be considered a package, a directory must contain
at least one module (which of course can be __init__). This allows the is
it a package? question to be answered with only one directory read, as is
the case now. Think of it also as a nudge in
On 4/26/06, Guido van Rossum [EMAIL PROTECTED] wrote:
So I have a very simple proposal: keep the __init__.py requirement for
top-level pacakages, but drop it for subpackages. This should be a
small change. I'm hesitant to propose *anything* new for Python 2.5,
so I'm proposing it for 2.6; if
At 09:56 PM 4/26/2006 +0200, Martin v. Löwis wrote:
Phillip J. Eby wrote:
My counter-proposal: to be considered a package, a directory must contain
at least one module (which of course can be __init__). This allows the
is
it a package? question to be answered with only one directory read,
Phillip J. Eby wrote:
At 11:50 AM 4/26/2006 -0700, Guido van Rossum wrote:
I'm not sure what you mean by one directory read. You'd have to list
the entire directory, which may require reading more than one block if
the directory is large.
You have to do this to find an __init__.py too,
Phillip J. Eby wrote:
I assume you want
import x.y
to fail if y is an empty directory (or non-empty, but without .py
files). I don't see a value in implementing such a restriction.
No, I'm saying that tools which are looking for packages and asking, Is
this directory a package? should
Guido van Rossum [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
(Context: There's a large crowd with pitchforks and other sharp pointy
farm implements just outside the door of my office at Google. They are
making an unbelievable racket. It appears they are Google engineers
who
OK, forget it. I'll face the pitchforks.
I'm disappointed though -- it sounds like we can never change anything
about Python any more because it will upset the oldtimers.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev
At 04:33 PM 4/26/2006 -0400, Joe Smith wrote:
It seems to me that the right way to fix this is to simply make a small
change to the error message.
On a failed import, have the code check if there is a directory that would
have been the requested package if
it had contained an __init__ module. If
At 01:49 PM 4/26/2006 -0700, Guido van Rossum wrote:
OK, forget it. I'll face the pitchforks.
I'm disappointed though -- it sounds like we can never change anything
about Python any more because it will upset the oldtimers.
I know exactly how you feel. :)
But there's always Python 3.0, and if
On 4/26/06, Terry Jones [EMAIL PROTECTED] wrote:
I would suggest adding a hook to their version control system to
automatically create (and preferably also check out) an __init__.py file
whenever a new (source code) directory was placed under version control
(supposing you can distinguish
On 4/26/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 01:49 PM 4/26/2006 -0700, Guido van Rossum wrote:
OK, forget it. I'll face the pitchforks.
I'm disappointed though -- it sounds like we can never change anything
about Python any more because it will upset the oldtimers.
I know exactly
On Apr 26, 2006, at 4:49 PM, Guido van Rossum wrote:
OK, forget it. I'll face the pitchforks.
I'm disappointed though -- it sounds like we can never change anything
about Python any more because it will upset the oldtimers.
No, you can not make a change which has a tiny (and arguably
Phillip J. Eby [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
It might also be good to check that the directory actually contained
python
modules.
This is a great idea, but might be hard to implement in practice with the
current C implementation of import, at least for the general
Joe Smith wrote:
It seems to me that the right way to fix this is to simply make a small
change to the error message.
On a failed import, have the code check if there is a directory that would
have been the requested package if
it had contained an __init__ module. If there is then append a
On 4/26/06, Guido van Rossum [EMAIL PROTECTED] wrote:
OK, forget it. I'll face the pitchforks.Maybe this'll help:http://python.org/sf/1477281 (You can call it 'oldtimer-repellant' if you want to use it to convince people there isn't any *real* backward-compatibility issue.)
I'm disappointed though
On 4/26/06, Thomas Wouters [EMAIL PROTECTED] wrote:
On 4/26/06, Guido van Rossum [EMAIL PROTECTED] wrote:
OK, forget it. I'll face the pitchforks.
Maybe this'll help:
http://python.org/sf/1477281
(You can call it 'oldtimer-repellant' if you want to use it to convince
people there
On 4/27/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 4/26/06, Thomas Wouters [EMAIL PROTECTED] wrote: On 4/26/06, Guido van Rossum [EMAIL PROTECTED] wrote:
OK, forget it. I'll face the pitchforks. Maybe this'll help: http://python.org/sf/1477281 (You can call it 'oldtimer-repellant' if you
Guido van Rossum wrote:
http://python.org/sf/1477281
(You can call it 'oldtimer-repellant' if you want to use it to
convince people there isn't any *real* backward-compatibility issue.)
I'd worry that it'll cause complaints when the warning is incorrect
and a certain directory is being
On 4/26/06, Thomas Wouters [EMAIL PROTECTED] wrote:
Of course, I only consider *my* reasons to be valid, and mine weren't
knee-jerk or tool-related. I don't think Python should be going Oh, what
you wanted wasn't possible, but I think I know what you wanted, let me do it
for you, first of all
On 4/26/06, Delaney, Timothy (Tim) [EMAIL PROTECTED] wrote:
I really think it would be more useful having an ImportError containing
a suggestion than having a warning. Anyone who knows it's bogus can just
ignore it.
That's effectively what Thomas's patch does though -- if at the end
the path
Guido van Rossum wrote:
The difference is that if you find a valid module package later on the
path, you'll still get warnings.
This is the bit I don't like about it. Currently the warnings are
displayed as the packages are found. I'd be quite happy with the
warnings if they were suppressed
At 01:10 AM 4/27/2006 +0200, Thomas Wouters wrote:
On 4/27/06, Guido van Rossum mailto:[EMAIL PROTECTED][EMAIL PROTECTED]
wrote:
I'd worry that it'll cause complaints when the warning is incorrect
and a certain directory is being skipped intentionally. E.g. the
string directory that someone had.
On 4/26/06, Delaney, Timothy (Tim) [EMAIL PROTECTED] wrote:
Potential packages later in the path won't be
warned about. If you're trying to resolve import problems, it's just as
likely that the package you really want is later in sys.path than
earlier.
But module hiding is a feature, and
At 04:57 PM 4/26/2006 -0700, Guido van Rossum wrote:
On 4/26/06, Delaney, Timothy (Tim) [EMAIL PROTECTED] wrote:
Possibly. Perhaps it would be useful to have `is_package(dirname)`,
`is_rootpackage(dirname)` and `is_subpackage(dirname)` functions
somewhere (pkgutils?).
YAGNI. Also note that
On Thursday 27 April 2006 05:50, Phillip J. Eby wrote:
Anyway, I'm not opposed to the idea of supporting this in future
Pythons, but I definitely think it falls under the but sometimes
never is better than RIGHT now rule where 2.5 is concerned. :)
I agree fully. I don't think we should try
On Thursday 27 April 2006 06:49, Guido van Rossum wrote:
OK, forget it. I'll face the pitchforks.
I'm disappointed though -- it sounds like we can never change
anything about Python any more because it will upset the oldtimers.
I'm not averse to changing this - just not to changing it on
On 4/26/06, Anthony Baxter [EMAIL PROTECTED] wrote:
On Thursday 27 April 2006 06:49, Guido van Rossum wrote:
OK, forget it. I'll face the pitchforks.
I'm disappointed though -- it sounds like we can never change
anything about Python any more because it will upset the oldtimers.
I'm not
Boy, threads here sure move fast when there's work to be done :).
Although largely moot now, I'll follow up for posterity's sake.
On Wed, 2006-04-26 at 10:59 -0700, Guido van Rossum wrote:
Oh, cool gray area. I propose that if there's no __init__.py it prints
'path/sub1/sun2/' i.e. with a
On Wednesday 26 April 2006 22:42, Barry Warsaw wrote:
So I suspect
you're right when you say that if the rule had already been relaxed and
you were now proposing to tighten the rules, we probably get just as
many complaints.
Indeed. I think the problem many of us have with the proposal
On 4/26/06, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote:
Indeed. I think the problem many of us have with the proposal isn't the new
behavior, but the change in the behavior. That's certainly it for me.
Which is why I said earlier that I felt disappointed that we can't
change anything any
On Wed, Apr 26, 2006, Guido van Rossum wrote:
Which is why I said earlier that I felt disappointed that we can't
change anything any more.
I've been here since Python 1.5.1. I don't understand why this issue in
particular makes you feel disappointed. I also think your statement is
just plain
71 matches
Mail list logo
