[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