My favorites | Sign in
Project Home Downloads Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
  Advanced search   Search tips   Subscriptions
Issue 83: Questions about the project
1 person starred this issue and may be notified of changes. Back to list
Status:  Fixed
Owner:  pts...@gmail.com
Closed:  Feb 2014


 
Reported by rbr...@gmail.com, Feb 27, 2013
Hi, Peter.

I have some questions about the project, which are not so visible (at least after browsing the pages a bit):

* Which versions of python do you want to support? For instance, would it be OK to drop support for any version of python that is very old?

* How do you feel about breaking the large monolithic file in smaller modules, for ease of maintenance (and, possibly, for ease of creation of some unit tests)?

* How do you feel about changing the parsing of command line options to use, say, optparse? This way, you get, as a nice side effect, an automatically documented `--help` switch for users to learn how to use the program (with all the options).

* How do you feel about using the logging module to control the verboseness of the program (I had good experience when using optparse to set the level of debug, or informational, or warnings or critical errors when used in conjunction with the optparse method mentioned above)?

These questions about your intentions with the project would be very nice to know, as it would help experimentation or external contributions (and everybody would benefit could benefit from that).


Thanks a lot,

Rogério.

Feb 28, 2013
Project Member #1 pts...@gmail.com
> Which versions of python do you want to support?

Python 2.4, 2.5, 2.6 and 2.7. Nothing more, nothing less this time.

> How do you feel about breaking the large monolithic file in smaller modules, for ease of maintenance (and, possibly, for ease of creation of some unit tests)?

I don't see the huge benefits. I wouldn't object if there was a script which would concatenate these files and generate the final, monolithic pdfsizeopt.py. I can write this script easily. If you feel strongly about this, please open an issue for it. I don't mind splitting the tests to smaller files though.

> * How do you feel about changing the parsing of command line options to use, say, optparse?

Cool idea, I'll accept a patch for that.

> How do you feel about using the logging module to control the verboseness of the program

Cool idea. Do you mean replacing the prints with logging.error, logging.warning, logging.info and logging.debug? Yes, we can do it. I would change the default log format though so by default pdfsizeopt.py would print exactly the same bytes to stderr as before.

> These questions about your intentions with the project would be very nice to know, as it would help experimentation or external contributions (and everybody would benefit could benefit from that).

Currently I'm busy with other stuff in my life, so pdfsizeopt is mostly in bugfix mode. Depending on the enthusiasm of the possible other contributors, I may decide to allocate more work time, just to help them. I have a few urgent-but-not-easy TODOs, and a bit longer wishlist, but I'm also open for external improvement ideas, especially if there is a volunteer who's ready to implement them. Please open a separate issue for which asks me to document them publicly.

If you ever consider forking the project, please let me know why, maybe I can provide better service to avoid the fork.

Please open a separate issue for all changes you want to make happen.
Feb 27, 2014
Project Member #2 pts...@gmail.com
(No comment was entered for this change.)
Status: Fixed

Powered by Google Project Hosting