[PATCH] util: move windows and posix wildcard imports to begin of file
Adrian Buehlmann
adrian at cadifra.com
Thu Jul 21 11:06:08 CDT 2011
On 2011-07-21 13:46, Mads Kiilerich wrote:
> On 07/21/2011 11:54 AM, Adrian Buehlmann wrote:
>> # HG changeset patch
>> # User Adrian Buehlmann<adrian at cadifra.com>
>> # Date 1311239126 -7200
>> # Node ID 812684d6af83113b37f26f964fdaee87e9f74363
>> # Parent 6d1d0b9c4ecce74ed782d87fa7f10acd54c1c640
>> util: move windows and posix wildcard imports to begin of file
>>
>> making it more explicit for people reading the code that definitions from
>> windows.py or posix.py are poured into the same namespace as util, hopefully
>> helping to prevent future accidental redefinitions (see de9eb6b1da4f)
>
> The imports used to be in the middle of the file because the first part
> defined some default implementations that were overridden by the
> posix/windows imports.
IMHO, we should stop overriding stuff in util by importing windows and
posix.
> AFAICS we still have that - for example with lookupreg?
..which I think could (and should) easily be fixed by moving
def lookupreg(key, name=None, scope=None):
return None
into posix.py
> I guess the safest way to avoid that kind of problems is to avoid the
> wildcard imports and be very explicit with something like
>
> if ...
> import posix as platformutil
> else:
> import windows as platformutil
> posixfile = platformutil.posixfile
> nulldev = platformutil.nulldev
> ...
>
> Just enumerating in the import what we use instead of using a wildcard
> would perhaps be better.
Not sure this is worth the trouble, but if you like to do this as a
follow up, feel free to do this. I'll try sending an updated patch for
my lookupreg defect.
> Slightly related: demandimport can't optimize from...import..., so I
> wonder how much we could win by only using full reusable imports in all
> places. Will the frequence of use and the overhead for an extra
> namespace lookup outweigh the benefit of being able to reuse imports and
> do them on demand?
More information about the Mercurial-devel
mailing list