[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