Re: [Pydev-code] Extend rename-refactoring to properly cover all 'uses' of a method

[Fabio Z. <fa...@gm...>]

On Tue, Mar 24, 2015 at 4:13 PM, Andreas Pakulat <an...@fr...>
wrote:

> On 2015-03-24 18:48, Fabio Zadrozny wrote:
>
>> Hi Andreas,
>>
>> You're right in both cases:
>>
>> 1. Duplicate module names under the same project are not supported -- I
>> do have plans to improve on that to support namespace-based packages
>> (I actually dislike those and find them a hack in Python, but PyDev
>> should probably support that -- the issue here is that the indexing should
>> be per source folder and not only per-project), but there's no hard date
>> on that.
>>
>
> I assume thats a more extensive change that a 'newcomer' like me is
> unlikely to be able to resolve?
>
>  2. Folders which don't have __init__.py files are really invisible to
>> PyDev and that's what Python expects -- that'd usually be an error in
>> the project structure, so, PyDev itself should probably not support it...
>> although I'm Ok if you want to add that through some extension.
>>
>
> I see, in our case the subfolders are actually testcase directories and
> each testcase has a 'driving' test.py with a main function that is being
> executed. Most users have the test.py filled with shared function calls and
> hence renaming one of them in only one of the tests is a small disaster :)
>
> If 1. would be solved I could adapt the setup so that each testcase folder
> is setup up separately as a source folder which should make an extension
> unneeded if I understand things correctly. That would also likely better
> reflect the runtime python path.
>
> Since the lookup is done per-project already that should also cover the
> shared folder within each project that we have (to share between testcases
> but not 'globally').
>
> If you have any suggestions on where an extension for 2. would be best be
> inserted I'd be happy to hear them. Otherwise do you see any general
> problem with adjusting ModuleKey to consider name + file for
> compareTo/equal/hashCode - other than potential speed issues? We could
> carry as a custom patch for the time being.
>
>
​I think changing ModuleKey may end up breaking other things (and the speed
issues are likely to happen too on big projects), so, I'd recommend
​against it (and I can't really think of a better solution that's not the
proper fix -- which would be fixing item 1)...

As for item 1, I think the effort to make it work properly will be
substantial and will really require many changes, (which is why I haven't
tackled that so far...), so, I think it may be really harder to resolve on
your side...

Best Regards,

Fabio