[Trimming recipients to just python-dev... BAW]
"PKO" == Patrick K O'Brien
writes:
PKO> Without trying to open a can of worms here, is there any sort PKO> of consensus on the use of packages with multiple smaller PKO> modules vs. one module containing everything? It's an interesting topic, to be sure, and no doubt will generate some nice cooked (charred?) worms. I'll only describe my own thoughts on the matter. I personally like files in bite-sized chunks, which means when they get to be more than one or a few tall emacs screenfuls, I start to get the urge to split things up. I'm probably somewhat influenced too by my early C++ days when we adopted a one class per .h file (and one class implementation per .cc file). IIRC, Objective-C also encouraged this granularity of organization. Even earlier influences include the FORTH convention of organizing everything into 1024 byte blocks, and that's it! For whatever reason, I definitely prefer to edit more smaller files than fewer large files (but all in moderation!), and the class seems to be a good organizational structure around which to split things. PKO> I'm just wondering if there are any guidelines that should PKO> frame one's thinking beyond the fairly obvious ones? For PKO> example, is the standard library an exceptional case because PKO> it must appeal to new users as well as experts? Does a good PKO> part of this issue come down to personal preference? Or are PKO> there advantages and disadvantages that should be documented? PKO> (Maybe they already have.) I think most of the standard modules are special because they were written before Python had a good (or any!) package system. For legacy modules that export lots of classes, there's probably little benefit to refactoring them into packages. That might change if we want to start separating things out into separately installable distutilized packages though. The package seems to be the smallest convenient unit for distutils. PKO> Is the current library configuration considered healthy? PKO> There are a mix of packages and single modules. Are these PKO> implementations pretty optimal, or would they be organized PKO> differently if one had the chance to do it all over again? Some of the newer packages are designed as packages because they're complex and big: distutils, xml, email, compiler. That makes perfect sense to me. It's possible something like Cookie.py if re-done /might/ make sense as a package, but I'm not sure. I doubt it makes much sense for something like smtplib.py to ever be a package, and besides other than exceptions, it only exports one main class. BTW, exceptions are...exceptions! I don't have much problem lumping all of a package's exception classes in one module. so-yeah-it-probably-is-personal-preference-ly y'rs, -Barry