Thanks very much in advance for paying attention to this newbie patch series!
2014-04-01 15:39 GMT+08:00 陈子杭 (Zihang Chen) <[email protected]>: > Hi everyone. > > Sorry for being late on amending my previous patches. > > I here upload version 2 of the patches. > > Changes since v1: > * Uppercase git commit lines in order to be consist with the older commits. > * Reduce lengths of commit lines and items in ChangeLog. > > P.S. I chose not to use git-send-email, it's too slow. > > Zihang Chen (11): > Create package misc, move ColourTerm.py to misc > From WgetTest.py move WgetFile to misc > Fix a typo in Test-Proto.py > Create package exc and move TestFailed to exc > Create package conf where rules and hooks are put > Move server classes to package server.protocol > Create package test for test case classes > Refactor mainly the test cases classes > Update README > Ensure line feed and blank line between methods > In conf, rename register to rule and hook > > testenv/ChangeLog | 144 ++++++++ > testenv/ColourTerm.py | 23 -- > testenv/FTPServer.py | 162 --------- > testenv/HTTPServer.py | 467 > -------------------------- > testenv/README | 81 +++-- > testenv/Test--https.py | 6 +- > testenv/Test--spider-r.py | 3 +- > testenv/Test-Content-disposition-2.py | 3 +- > testenv/Test-Content-disposition.py | 3 +- > testenv/Test-Head.py | 3 +- > testenv/Test-O.py | 3 +- > testenv/Test-Parallel-Proto.py | 6 +- > testenv/Test-Post.py | 3 +- > testenv/Test-Proto.py | 6 +- > testenv/Test-auth-basic-fail.py | 3 +- > testenv/Test-auth-basic.py | 3 +- > testenv/Test-auth-both.py | 3 +- > testenv/Test-auth-digest.py | 3 +- > testenv/Test-auth-no-challenge-url.py | 3 +- > testenv/Test-auth-no-challenge.py | 3 +- > testenv/Test-auth-retcode.py | 3 +- > testenv/Test-auth-with-content-disposition.py | 3 +- > testenv/Test-c-full.py | 3 +- > testenv/Test-cookie-401.py | 3 +- > testenv/Test-cookie-domain-mismatch.py | 3 +- > testenv/Test-cookie-expires.py | 3 +- > testenv/Test-cookie.py | 3 +- > testenv/WgetTest.py | 337 ------------------- > testenv/conf/__init__.py | 49 +++ > testenv/conf/authentication.py | 9 + > testenv/conf/expect_header.py | 7 + > testenv/conf/expected_files.py | 42 +++ > testenv/conf/expected_ret_code.py | 16 + > testenv/conf/files_crawled.py | 18 + > testenv/conf/hook_sample.py | 15 + > testenv/conf/local_files.py | 12 + > testenv/conf/reject_header.py | 7 + > testenv/conf/response.py | 7 + > testenv/conf/rule_sample.py | 10 + > testenv/conf/send_header.py | 7 + > testenv/conf/server_conf.py | 11 + > testenv/conf/server_files.py | 15 + > testenv/conf/urls.py | 10 + > testenv/conf/wget_commands.py | 10 + > testenv/exc/__init__.py | 0 > testenv/exc/test_failed.py | 7 + > testenv/misc/__init__.py | 0 > testenv/misc/colour_terminal.py | 29 ++ > testenv/misc/constants.py | 3 + > testenv/misc/wget_file.py | 16 + > testenv/server/__init__.py | 0 > testenv/server/ftp/__init__.py | 0 > testenv/server/ftp/ftp_server.py | 162 +++++++++ > testenv/server/http/__init__.py | 0 > testenv/server/http/http_server.py | 467 > ++++++++++++++++++++++++++ > testenv/test/__init__.py | 0 > testenv/test/base_test.py | 223 ++++++++++++ > testenv/test/http_test.py | 45 +++ > 58 files changed, 1451 insertions(+), 1035 deletions(-) > delete mode 100644 testenv/ColourTerm.py > delete mode 100644 testenv/FTPServer.py > delete mode 100644 testenv/HTTPServer.py > delete mode 100644 testenv/WgetTest.py > create mode 100644 testenv/conf/__init__.py > create mode 100644 testenv/conf/authentication.py > create mode 100644 testenv/conf/expect_header.py > create mode 100644 testenv/conf/expected_files.py > create mode 100644 testenv/conf/expected_ret_code.py > create mode 100644 testenv/conf/files_crawled.py > create mode 100644 testenv/conf/hook_sample.py > create mode 100644 testenv/conf/local_files.py > create mode 100644 testenv/conf/reject_header.py > create mode 100644 testenv/conf/response.py > create mode 100644 testenv/conf/rule_sample.py > create mode 100644 testenv/conf/send_header.py > create mode 100644 testenv/conf/server_conf.py > create mode 100644 testenv/conf/server_files.py > create mode 100644 testenv/conf/urls.py > create mode 100644 testenv/conf/wget_commands.py > create mode 100644 testenv/exc/__init__.py > create mode 100644 testenv/exc/test_failed.py > create mode 100644 testenv/misc/__init__.py > create mode 100644 testenv/misc/colour_terminal.py > create mode 100644 testenv/misc/constants.py > create mode 100644 testenv/misc/wget_file.py > create mode 100644 testenv/server/__init__.py > create mode 100644 testenv/server/ftp/__init__.py > create mode 100644 testenv/server/ftp/ftp_server.py > create mode 100644 testenv/server/http/__init__.py > create mode 100644 testenv/server/http/http_server.py > create mode 100644 testenv/test/__init__.py > create mode 100644 testenv/test/base_test.py > create mode 100644 testenv/test/http_test.py > > -- > 1.8.3.2 > > 2014-03-14 21:00 GMT+08:00 Darshit Shah <[email protected]>: > > On Fri, Mar 14, 2014 at 1:20 PM, 陈子杭 (Zihang Chen) <[email protected]> >> wrote: >> > >> > >> > >> > 2014-03-14 20:01 GMT+08:00 Darshit Shah <[email protected]>: >> >> >> >> Hi, >> >> >> >> Things are getting much cleaner with each iteration. :) >> >> I haven't had the time to check the patchset yet. And I may not have >> the >> >> time until Monday either. However, I do have a few high level comments: >> >> >> >> 1. Please upload all patches directly to the mail. Do not compress >> >> them. It may look ugly, but it is much more convenient. >> >> This is fixed, if you follow Yousong's recommendations on how to send >> >> patches. Using git for it all is always a good idea. >> >> >> > Yes, I'll follow this advice. >> >> >> >> 2. Your commit messages are still too long. Always follow 80 chars >> >> per line. If you wish to add more, the correct way is to write a short >> 80 >> >> char message, leave a blank line and then write however long a commit >> >> message you want. >> >> The point is, the first line goes into the repository, patch, name, >> etc. >> >> It >> >> is supposed to be an extremely short description of the commit. Later, >> >> in the body, you can expand as much as you want. Again, I'm not sure >> >> what your editor is, but with the git syntax files, ViM highlights and >> >> lets >> >> you know when you've exceeded the maximum line length or are >> >> writing on the 2nd line of a commit message, which generally should be >> >> empty. >> > >> > I edit ChangeLog, README with vim, if you're talking about them. I >> checked >> > them with Kate, it surely does exceed 2 or 3 chars in some lines. Wired. >> > I'll try fixing my .vimrc. >> Yes. The same. Vim's textwidth is complex. You probably have a wrapmargin >> of 2. And that is fine. Your commit messages had multiple sentences, which >> is hard to read. >> >> Also, check http://blog.ezyang.com/2010/03/vim-textwidth/ for a better >> understanding of the textwidth features. >> >> >> >> >> >> >> 3. Also, I'm not a fan of making things very Pythonic. It, in my >> personal >> >> opinion makes code more unreadable for the general non-Python >> >> developer. The whole point of using Python is to ensure that a random >> >> C developer can read and follow the code. Hence, I was very particular >> >> about not using fancy Python features in the Test Suite. The module >> >> was horrible, I concede (I'm no Object oriented programmer, I like C), >> >> but I would prefer the code remains simpler. I'll give more specific >> >> examples and pointers to locations which I think should be improved >> >> once I look at the code. >> > >> > I totally understand what you're talking about and I agree with you. >> > However, >> > I still insist that under certain circumstances, it's better to be a >> little >> > more >> > Pythonic. IMO, C developers who uses this test suite rarely need to >> modify >> > the framework of the test suite. They only need to write new test case >> > scripts, and if needed, write new hook or rule. They can write however >> they >> > like. I just need make the interface as plain as possible. >> >> >> Sure. Being pythonic is not always bad. Also, I agree that most of the >> times >> you do not need to edit the core framework. Especially as long as you >> provide >> and excellent API. However, oftentimes, you want to know what's going on >> in the Test Suite setup, just to see what can be tweaked and how. Else, >> you >> simply want to know how it runs, and you try to follow the code. >> >> Specifically, I'd like to stay away from concepts like aliases which can >> get >> confusing sometimes for someone not used to Python. >> >> >> >> >> On Fri, Mar 14, 2014 at 10:28 AM, 陈子杭 (Zihang Chen) < >> [email protected]> >> >> wrote: >> >> > Thank you very much for your advice! >> >> > >> >> > >> >> > 2014-03-14 16:58 GMT+08:00 Yousong Zhou <[email protected]>: >> >> > >> >> >> Hi, Zihang. >> >> >> >> >> >> You are making progress. :) Below are my comments and hope that >> will >> >> >> help you in some way. >> >> >> >> >> >> - I haven't got the chance to try python3, but in python2, there is >> >> >> the difference between traditional classes and new-style classes, >> i.e. >> >> >> "class C:" versus "class C(obj):". If it is still there in python3, >> >> >> new-style classes is generally preferred. >> >> >> >> >> > Yes, there are only new-style classes in Python3. >> >> > >> >> >> - In the newly introduced "conf" package, if it is your intention >> >> >> that "gen_hook()" is not expected to be exported, then you may want >> to >> >> >> enforce it in some way. >> >> >> >> >> > Sure, I'll see what I can do. >> >> > >> >> >> - "Refactor a lot" is truly a lot for a single commit. :) >> >> >> - I randomly check on the 8th patch. >> >> >> >> >> >> 1. Why there are three names of almost the same meaning >> appearing >> >> >> in the code, i.e. ExpectedRetcode, ExpectedRetCode, >> ExpectedReturnCode >> >> >> (This one was found in the repository). >> >> >> >> >> > The first one is the one I think is named inappropriately (Retcode => >> >> > RetCode). >> >> > But to maintain compatibility (ExpectedRetcode is still used in test >> >> > case >> >> > scripts), >> >> > it's still in use utilizing register(alias='ExpectedRetcode'). >> >> > >> >> >> 2. The newly formatted error string will not run, since >> >> >> "expected_ret_code" is a int, and it will not format with "%s". >> >> >> >> >> > Actually, an int object will be converted to str automatically using >> >> > __str__ if >> >> > formatted with '%s'. (I use format int with '%s' all the time.) >> >> > >> >> >> 3. I vaguely remembered that a new format string syntax was >> >> >> proposed and recommended. While at it, is it possible that this >> >> >> feature be used? >> >> >> >> >> > Yes, there is one. However using this feature will cause changes in >> the >> >> > test >> >> > case scripts, because in the test cases {{port}} is used, while the >> >> > format >> >> > syntax >> >> > is {port}. I'll think about it though. >> >> > >> >> >> 4. If the decorator "register()" is about "conf", then "conf" or >> >> >> "register_conf" should be a better name, for the same reason it is >> >> >> "staticmethod" instead of "register_staticmethod". >> >> >> >> >> > Yes! Didn't think about it. I think I'll rename register to "rule" >> and >> >> > "hook" for >> >> > different type of confs, though rule and hook are the same thing. >> >> > >> >> >> 5. On the expected_files.py, files_crawled.py, etc. you may want >> >> >> to format a proper error string and raise an exception with it >> instead >> >> >> of "print" it to stdout. >> >> >> >> >> > Yes, I'll think about it. >> >> > >> >> >> >> >> >> - Double blank lines. >> >> >> >> >> > Ouch, I thought methods are separated with two blank lines in PEP8. >> >> > Looks like I'm wrong. I'll try fix this. >> >> > >> >> >> - Notice the "No newline at end of file" messages generated by git. >> >> >> Vim will automatically add a newline at end of a file, not sure >> what's >> >> >> your editor for this. >> >> > >> >> > Yes, I'll fix my editor for this. (I actually in my latest patches >> >> > delete >> >> > the >> >> > newline at end of files on purpose. Looks like I got it wrong again.) >> >> > >> >> >> >> >> >> >> >> > Below are my personal preferences on SubmittingPatches, pick some if >> >> >> they seem to be reasonable. >> >> >> >> >> >> - Describe your overall plan and intention in a cover letter can be >> >> >> good. Try it with --cover-letter option when generating patches >> with >> >> >> "git format-patch". >> >> >> - Cover letter can also be used to track differences between >> versions >> >> >> of your patch series so that reviewers can easily know what's new in >> >> >> this version. Try it with --subject-prefix='PATCH vN' option when >> >> >> using "git format-patch". >> >> >> - The Subject line of your should be short and concise, fitted into >> >> >> one line sentence without commas, and detailed description goes to >> >> >> message body. >> >> >> - I prefer patches sent with "git send-email 000*.patch", that way >> we >> >> >> can view and refer to the specific lines of the patch with context. >> >> >> >> >> >> Thanks very much for these suggestions! I'll see what I can do. >> >> > >> >> > >> >> >> Link [1] may serve as a good example. I can only find guide for >> >> >> submitting patches to wget with Mercurial [2]. >> >> >> >> >> >> [1] >> >> >> >> >> >> >> http://www.linux-mips.org/archives/linux-mips/2011-01/threads.html#00006 >> >> >> [2] >> >> >> >> >> >> >> http://wget.addictivecode.org/PatchGuidelines#How_to_create_patches_with_Mercurial >> >> >> >> >> >> >> >> >> yousong >> >> >> >> >> >> On 14 March 2014 10:16, 陈子杭 (Zihang Chen) <[email protected]> >> wrote: >> >> >> > Hi. >> >> >> > >> >> >> > Just finished on my latest patches. >> >> >> > >> >> >> > >> >> >> > 2014-03-12 22:49 GMT+08:00 Darshit Shah <[email protected]>: >> >> >> > >> >> >> >> Hi, >> >> >> >> >> >> >> >> That's great! Thanks for the patches. I do have a few comments >> about >> >> >> >> it >> >> >> >> though: >> >> >> >> >> >> >> >> 1. You are still missing ChangeLog entries for each patch. You >> >> >> >> should >> >> >> >> Ideally have a ChangeLog entry for every commit. >> >> >> >> 2. I am not sure I completely follow the logic of the extra >> lines of >> >> >> >> code that you've added to colour_terminal.py >> >> >> >> 3. More importantly, you moved the module ColourTerm, but did not >> >> >> >> change the import statements in any file. >> >> >> >> Each commit should build successfully. That is why we have >> smaller >> >> >> >> commits. A failure in this commit will give >> >> >> >> false positives when someone attempts to use git bisect to find a >> >> >> >> regression. >> >> >> >> 4. Your commit message states, "move ColourTerm.py to >> >> >> >> misc/colour_terminal.py" but you're doing more than that. >> >> >> >> >> >> >> >> I would suggest you move all the files you want in one commit and >> >> >> >> then >> >> >> >> edit them later in different commits. >> >> >> >> Please fix the patches so that every commit compiles and runs the >> >> >> >> tests independently. A commit should not >> >> >> >> depend on patches that come in the following commit. >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Mar 12, 2014 at 3:14 PM, 陈子杭 (Zihang Chen) >> >> >> >> <[email protected]> >> >> >> >> wrote: >> >> >> >> > Hi Darshit and Yousong, >> >> >> >> > >> >> >> >> > I think I finally got things straight. >> >> >> >> > >> >> >> >> > The big commit was split into 9 relatively small commits, and I >> >> >> removed >> >> >> >> all >> >> >> >> > the trailing backspaces and new lines. These patches apply to >> >> >> >> > origin/parallel-wget without warnings. >> >> >> >> > >> >> >> >> > Thank both of you very much for all the help! >> >> >> >> > >> >> >> >> > If you have any concerns about the contents of the patches, >> please >> >> >> let me >> >> >> >> > know. >> >> >> >> > >> >> >> >> > >> >> >> >> > 2014-03-10 19:49 GMT+08:00 Darshit Shah <[email protected]>: >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Mar 10, 2014 at 10:25 AM, 陈子杭 (Zihang Chen) < >> >> >> [email protected] >> >> >> >> > >> >> >> >> >> wrote: >> >> >> >> >>> >> >> >> >> >>> I applied dos2unix to all the files under testenv, checked >> with >> >> >> >> >>> file >> >> >> >> >>> command, deleted all pyc files, line wrap to 80 characters >> and >> >> >> format >> >> >> >> a new >> >> >> >> >>> patch. (I swear this will be the last huge patch I'll ever >> >> >> >> >>> make.) >> >> >> >> >>> >> >> >> >> >>> I also git am this patch to a clean clone locally, and got >> two >> >> >> warning: >> >> >> >> >>> warning: squelched 16 whitespace errors >> >> >> >> >>> warning: 21 lines add whitespace errors. >> >> >> >> >>> Is this ok? >> >> >> >> >>> >> >> >> >> >> I haven't checked the patch yet, but just a few suggestions: >> >> >> >> >> >> >> >> >> >> 1. You don't need to delete the pyc files locally. Simply >> don't >> >> >> >> >> add >> >> >> them >> >> >> >> >> to the git commit. Use a local .gitignore file to handle it >> >> >> >> >> 2. You can and should split this patch. I'm assuming it's the >> >> >> >> >> same >> >> >> stuff >> >> >> >> >> as before, and that can be split. Use your imagination >> >> >> >> >> 3. The whitespace errors imply trailing whitespace. This >> happens >> >> >> when yo >> >> >> >> >> uhave extra whitespace characters at the end of a >> >> >> >> >> line. Usually not a good idea sinec these are characters that >> >> >> >> >> cannot >> >> >> be >> >> >> >> >> seen. You should eliminate them. My ViM editor >> >> >> >> >> simply highlights all trailing whitespaces so I always know if >> >> >> >> >> they >> >> >> are >> >> >> >> >> there. Also, you can configure your git to explicitly >> >> >> >> >> highlight trailing whitespaces in its diff output (Assuming >> >> >> >> >> you're >> >> >> >> using a >> >> >> >> >> git shell, not a GUI, in which case I have no idea.) >> >> >> >> >> >> >> >> >> >>> Nervously, Chen >> >> >> >> >> >> >> >> >> >> Don't worry. Everyone faces problems with these items in the >> >> >> beginning. >> >> >> >> >> It's not something you are used to. >> >> >> >> >> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> 2014-03-10 16:34 GMT+08:00 陈子杭 (Zihang Chen) >> >> >> >> >>> <[email protected]>: >> >> >> >> >>> >> >> >> >> >>>> >> >> >> >> >>>> >> >> >> >> >>>> >> >> >> >> >>>> 2014-03-10 16:17 GMT+08:00 Darshit Shah <[email protected]>: >> >> >> >> >>>> >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> On Mon, Mar 10, 2014 at 8:46 AM, 陈子杭 (Zihang Chen) < >> >> >> >> [email protected]> >> >> >> >> >>>>> wrote: >> >> >> >> >>>>>> >> >> >> >> >>>>>> Hi Yousong, >> >> >> >> >>>>>> >> >> >> >> >>>>>> So sorry about the line endings, I'll have to do a >> thorough >> >> >> check. >> >> >> >> >>>>> >> >> >> >> >>>>> I'm not sure about the line endings since my git and vim >> >> >> >> cinfiguration >> >> >> >> >>>>> simply do the magic >> >> >> >> >>>>> of conversions for me. But if Yousong says do, do look into >> >> >> >> >>>>> it. >> >> >> >> >>>>> >> >> >> >> >>>>> However, you seem to have added a huge amount of those >> >> >> >> >>>>> especially >> >> >> in >> >> >> >> >>>>> your 2nd patch. >> >> >> >> >>>>> >> >> >> >> >>>>> I do however, very strongly suggest that you get access to >> >> >> >> >>>>> some >> >> >> sort >> >> >> >> of >> >> >> >> >>>>> a linux system. It will >> >> >> >> >>>>> make your life so much easier. Autoconf takes ages to run >> on >> >> >> Windows >> >> >> >> in >> >> >> >> >>>>> a cygwin shell. >> >> >> >> >>>>> >> >> >> >> >>>>>> >> >> >> >> >>>>>> >> >> >> >> >>>>>> BTW, the pyc files in 0001.patch was deleted in the second >> >> >> commit. >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> It would be better if you just did not have them there. It >> >> >> >> >>>>> woulld >> >> >> >> >>>>> clutter *everyone's* git repos >> >> >> >> >>>>> if the .pyc files were there and later deleted. Because git >> >> >> >> >>>>> will >> >> >> >> leave >> >> >> >> >>>>> a snapshot of each >> >> >> >> >>>>> commit in the history. Keep a .gitignore file handy. Those >> are >> >> >> very >> >> >> >> >>>>> important. You'll get >> >> >> >> >>>>> good ones for starts from github's own gitignore >> repository. >> >> >> >> >>>> >> >> >> >> >>>> Got it. But I wonder where to put the .gitignore file. >> Should I >> >> >> >> >>>> use >> >> >> >> the >> >> >> >> >>>> one in the `wget` directory or >> >> >> >> >>>> get a new one under `testenv`? >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> Also, we usually expect a ChangeLog entry for *every* patch >> >> >> >> >>>>> being >> >> >> >> sent. >> >> >> >> >>>>> So, please keep that >> >> >> >> >>>>> in mind too. And there's also the 80 characters per line >> limit >> >> >> >> >>>>> we >> >> >> >> like >> >> >> >> >>>>> to follow for all files. >> >> >> >> >>>>> >> >> >> >> >>>> I'll keep that in mind. >> >> >> >> >>>>> >> >> >> >> >>>>> The chief reason was that older terminals could only >> display >> >> >> >> >>>>> 80 >> >> >> >> >>>>> characters. Now, the reason is >> >> >> >> >>>>> that it allows you to have two vertical windows with code >> >> >> >> >>>>> simultaneously without any line wraps. >> >> >> >> >>>>> >> >> >> >> >>>>> And do follow Yousong's advice on organizing your patchset. >> >> >> >> >>>>> Ask >> >> >> for >> >> >> >> >>>>> help and you shall get it. >> >> >> >> >>>>> Large, single commits are seldom looked upon favourably. >> >> >> >> >>>>>> >> >> >> >> >>>>>> >> >> >> >> >>>> I'll try to make my commits smaller next time. Work till >> now I >> >> >> >> >>>> is >> >> >> not >> >> >> >> >>>> likely to be divided into small >> >> >> >> >>>> commits though ;( >> >> >> >> >>>>>> >> >> >> >> >>>>>> And thanks very much for the advice! >> >> >> >> >>>>>> >> >> >> >> >>>>>> >> >> >> >> >>>>>> 2014-03-10 15:38 GMT+08:00 Yousong Zhou >> >> >> >> >>>>>> <[email protected]>: >> >> >> >> >>>>>> >> >> >> >> >>>>>> > Hi, Zihang, >> >> >> >> >>>>>> > >> >> >> >> >>>>>> > On 10 March 2014 13:05, 陈子杭 (Zihang Chen) >> >> >> >> >>>>>> > <[email protected]> >> >> >> >> >>>>>> > wrote: >> >> >> >> >>>>>> > > Hi, Darshit. >> >> >> >> >>>>>> > > I fixed the line ending using git config --global >> >> >> >> >>>>>> > > autocrlf >> >> >> >> input. >> >> >> >> >>>>>> > > Line >> >> >> >> >>>>>> > > endings should be lf now. I also added some >> >> >> >> >>>>>> > > documentation. >> >> >> File >> >> >> >> >>>>>> > > modes for >> >> >> >> >>>>>> > > Test-*.py are 755 now. >> >> >> >> >>>>>> > > >> >> >> >> >>>>>> > >> >> >> >> >>>>>> > I just did a quick check on the patch and the line >> endings >> >> >> >> >>>>>> > are >> >> >> >> still >> >> >> >> >>>>>> > wrong, e.g. testenv/test/http_test.py >> >> >> >> >>>>>> > >> >> >> >> >>>>>> > Also, .pyc files should not be included, right? >> >> >> >> >>>>>> > >> >> >> >> >>>>>> > I do not have much experience with parallel-wget, but >> you >> >> >> >> >>>>>> > can >> >> >> >> >>>>>> > enhance >> >> >> >> >>>>>> > organizing your commits by following how existing ones >> in >> >> >> >> >>>>>> > the >> >> >> >> >>>>>> > repository were written. >> >> >> >> >>>>>> > >> >> >> >> >>>>>> > >> >> >> >> >>>>>> > yousong >> >> >> >> >>>>>> > >> >> >> >> >>>>>> >> >> >> >> >>>>>> >> >> >> >> >>>>>> >> >> >> >> >>>>>> -- >> >> >> >> >>>>>> Regards, >> >> >> >> >>>>>> Chen Zihang, >> >> >> >> >>>>>> Computer School of Wuhan University >> >> >> >> >>>>>> --- >> >> >> >> >>>>>> 此致 >> >> >> >> >>>>>> 陈子杭 >> >> >> >> >>>>>> 武汉大学计算机学院 >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> -- >> >> >> >> >>>>> Thanking You, >> >> >> >> >>>>> Darshit Shah >> >> >> >> >>>>> >> >> >> >> >>>> >> >> >> >> >>>> >> >> >> >> >>>> >> >> >> >> >>>> -- >> >> >> >> >>>> Regards, >> >> >> >> >>>> Chen Zihang, >> >> >> >> >>>> Computer School of Wuhan University >> >> >> >> >>>> --- >> >> >> >> >>>> 此致 >> >> >> >> >>>> 陈子杭 >> >> >> >> >>>> 武汉大学计算机学院 >> >> >> >> >>>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> -- >> >> >> >> >>> Regards, >> >> >> >> >>> Chen Zihang, >> >> >> >> >>> Computer School of Wuhan University >> >> >> >> >>> --- >> >> >> >> >>> 此致 >> >> >> >> >>> 陈子杭 >> >> >> >> >>> 武汉大学计算机学院 >> >> >> >> >>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> >> Thanking You, >> >> >> >> >> Darshit Shah >> >> >> >> >> >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > -- >> >> >> >> > Regards, >> >> >> >> > Chen Zihang, >> >> >> >> > Computer School of Wuhan University >> >> >> >> > --- >> >> >> >> > 此致 >> >> >> >> > 陈子杭 >> >> >> >> > 武汉大学计算机学院 >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> Thanking You, >> >> >> >> Darshit Shah >> >> >> >> >> >> >> > >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > Regards, >> >> >> > Chen Zihang, >> >> >> > Computer School of Wuhan University >> >> >> > --- >> >> >> > 此致 >> >> >> > 陈子杭 >> >> >> > 武汉大学计算机学院 >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > Regards, >> >> > Chen Zihang, >> >> > Computer School of Wuhan University >> >> > --- >> >> > 此致 >> >> > 陈子杭 >> >> > 武汉大学计算机学院 >> >> >> >> >> >> >> >> -- >> >> Thanking You, >> >> Darshit Shah >> > >> > >> > >> > >> > -- >> > Regards, >> > Chen Zihang, >> > Computer School of Wuhan University >> > --- >> > 此致 >> > 陈子杭 >> > 武汉大学计算机学院 >> > >> >> >> >> -- >> Thanking You, >> Darshit Shah >> > > > > -- > Regards, > Chen Zihang, > Computer School of Wuhan University > --- > 此致 > 陈子杭 > 武汉大学计算机学院 > > -- Regards, Chen Zihang, Computer School of Wuhan University --- 此致 陈子杭 武汉大学计算机学院
