first iteration - split more internal utilities out of the main package file #101
Conversation
There was a problem hiding this comment.
Looks good to me @RonnyPfannschmidt.
I like that we're finally breaking up that monster module ;)
|
please dont approve before i even started ^^ |
|
the next step will be to put everything into underscored modules and simplify the locations/dependencies afterwards i hope to optimize details using cython |
|
@RonnyPfannschmidt ahh sorry didn't realize you weren't looking for feedback. Normally I don't put up a PR until I'm looking for review ;) Sounds good though. I'd be happy to help with the |
|
@tgoodlet main reason i put a wip in there ^^ - i just want to try more transparency ^^ |
|
plus travis shows me errors i missed |
|
Cool sounds good! |
|
@RonnyPfannschmidt would be good to know when you're done though because there's going to be a bunch of merge conflicts now for the stuff I've been working on. |
|
@tgoodlet in case of doubt its on me to merge that ^^ - i suspect i will need until after the weekend |
|
@RonnyPfannschmidt nope looks good to me. I trust our CI and as long as you didn't actually change any of the implementation (which looks like you didn't) then I'd say this is good to go. I'd actually rather get this in sooner then later so I can move forward with other stuff. |
|
@tgoodlet in that case lets take a look at merging this, but restructuring it anyway later (some things need to be suffled in that case lets do this one soon, and i#ll follow up with more after your conference to minimize conflicting changes |
RonnyPfannschmidt
changed the title
|
@RonnyPfannschmidt only thing I was thinking is that we'll lose history for each code segment which is kind of annoying. I guess there's not much way around it though. Do you think the history should be squashed or you want to keep the separate commits? |
Shouldn't we do this right away on this PR? |
| @@ -0,0 +1,293 @@ | |||
| from . import _tracing | |||
There was a problem hiding this comment.
Do we want to name our modules twonames or two_names? I ask because we have parse_funcs and now pluginmanager.
FWIW I prefer two_names as I find it easier to read. Either way we should choose a convention.
There was a problem hiding this comment.
thamks for that note, i#l ltry to incooperate it today
There was a problem hiding this comment.
What about just manager.py?
|
@RonnyPfannschmidt I think this will need a rebase to get in the latest changes. |
| @@ -0,0 +1,66 @@ | |||
| import inspect | |||
There was a problem hiding this comment.
I was actually thinking maybe just make this a utils.py mod since it's only got the one function and we might later want a place to add miscellaneous stuff.
There was a problem hiding this comment.
in general - having a utils module/package is a antipattern ^^ - its just a utterly bad name because it caries no meaning
|
Closing in favour of #117. |
No description provided.