-
Notifications
You must be signed in to change notification settings - Fork 10.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The code should be broken out in smaller pieces #193
Comments
My trivial HTML parser is still in its infancy stages. Eventually, it will replace all the regular expressions and lxml calls. Since lxml is not in the stdlib, we can't use it, and I haven't found an other good HTML parser. My trivial JSON parser is just needed for Python 2.5. If we ever stop supporting that, we can switch to the standard JSON. JSON IEs are a good idea since they're using an API that's unlikely to break in the future, and extremely simple. The report_ functions are not really necessary, we should indeed have a report(message) in the Splitting the IEs into different files is a good idea, and I'll leave this bug open for that change.
|
@phihag although the code base still leaves a lot to be desired, I think this issue can safely be closed now as most of the improvements seem to have happened ( |
[pull] master from ytdl-org:master
[MTV/Nick] universal mgid extractor + fix nick.de feed
Hi.
I was reading the code to implement the recent xvideos IE and it became obvious to me that the code is of a very heterogeneous quality: the techniques used for extraction is, sometimes, using pre-existing python modules, sometimes a module like yours 'trivial' xml parser, sometimes with hand-rolled regular expressions etc.
The coding style is also heterogeneous.
There are also some duplications of code: I can't see any reason why the
_simplify_title
(just to give one example) is not in the parentInfoExtractor
class: most implementations ofInfoExtractor
would use that, anyway.Similarly to the
report_webpage
andreport_extraction
. Factoring those out can lead to smaller code, fewer duplications, benefits when the basic implementation is improved etc.Another thing, possibly for a longer term: perhaps the code could be, somehow, split with each information extractor in one file and, to guarantee convenience for updates/downloads, the "real" youtube-dl could be made with a simple concatenation of the files.
This would allow some modularization when we write the code, fewer paging up/down to see other parts of the code, etc. and, most important of all, being easier to be able to hold more of the program inside our heads.
Of course, it doesn't need to be that way, and that's just brainstorming, but the general principle of a "compilation step" could be taken.
Regards.
The text was updated successfully, but these errors were encountered: