[PATCH 6 of 6] tests: check import cycles in hgext/**.py, too

FUJIWARA Katsunori foozy at lares.dti.ne.jp
Thu May 14 01:23:41 CDT 2015


At Wed, 13 May 2015 20:15:41 -0400,
Augie Fackler wrote:
> 
> 
> > On May 13, 2015, at 20:12, Pierre-Yves David <pierre-yves.david at ens-lyon.org> wrote:
> > 
> > 
> > 
> > On 05/13/2015 05:11 PM, Augie Fackler wrote:
> >> On Wed, May 13, 2015 at 04:43:43PM -0700, Pierre-Yves David wrote:
> >>> 
> >>> 
> >>> On 05/13/2015 09:53 AM, FUJIWARA Katsunori wrote:
> >>>> # HG changeset patch
> >>>> # User FUJIWARA Katsunori <foozy at lares.dti.ne.jp>
> >>>> # Date 1431535750 -32400
> >>>> #      Thu May 14 01:49:10 2015 +0900
> >>>> # Node ID e4eba789328746bf2f4e2a0498c0afb08b80ae34
> >>>> # Parent  28a977036067ea7bb0af50218edbee9abe82331a
> >>>> tests: check import cycles in hgext/**.py, too
> >>> 
> >>> This series looks good to me and I've pushed it to the clowncopter.
> >>> CCing Augie as I think he may have a stronger opinion than me.
> >> 
> >> Patches 1 and 6 are obviously correct, but I'm unclear on the
> >> correctness of 3 and 4, and therefore am also unsure of the merits of
> >> 2 and 5.
> > 
> > What kind of uncorrectness do you fear?
> 
> Basically, shadowing builtin module names in Python 3 is a dangerous
> proposition. Right now we have some places where the import-checker
> says we mix local imports with upstream packages, and we're actually
> (correctly) getting all local modules, but that breaks in Python 3
> unless we move to explicit relative imports everywhere. I thought I
> responded to patch 3 with my concerns.

Oh, I had misunderstood that just separating local ones from upstream
packages is safe enough. Sorry, I'm not well at Python 3.

Then, what about steps below ?

  1. drop patches for "detect mixing imports" from this series

     before:
       #1: add xargs like mode
       #2: loop to get list of locally defined	modules at first
       #3: change the logic of "verify_stdlib_on_own_line()"
       #4: change the logic of "checkmod()"
       #5: remove useless stdlib_modules and related code paths
       #6: check import cycles in hgext/**.py, too

    after:
       #1: add xargs like mode
       #2: loop to get list of locally defined	modules at first
       #4: change the logic of "checkmod()" (*)
       #6: check import cycles in hgext/**.py, too

    (*) #4 needs some changes to be applied correctly

    This can improve cycle detection, as a first step.

  2. use explicit relative import for locally defined one

     Even though this requires many many changes, now is the good time
     to forget compatibility for Python 2.4, isn't it ? :-)

  3. change the logic of "verify_stdlib_on_own_line()"

     I assume the logic like below:

       examine whether name in implicit relative importing matches
       against locally defined one or not, and show warning "this
       import is ambiguous (or dangerous ?)" if so.

     ("verify_fromimport_for_local_one()" or so ?)

     This should show no warning, because there is no standard library
     importing, of which collides against locally defined one in
     Mercurial, AFAIK.

  4. remove useless stdlib_modules and related code paths

     Now, list of standard Python library isn't needed.


> I'm tired from travel at this point, but am happy to talk more tomorrow about this series.
> 
> AF
> 
> > 
> > -- 
> > Pierre-Yves David
> 
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel

----------------------------------------------------------------------
[FUJIWARA Katsunori]                             foozy at lares.dti.ne.jp


More information about the Mercurial-devel mailing list