[as sent to deity@lists.debian.org]
Hello,
while hacking a bit on python-apt in the last days, I formulated some
proposals which I want to present to you.
I have already implemented proposals I and VII, started with the implementation
of proposal II, and have partially implemented proposal III, all in
my local branch. I could implement the rest next week, and this could
result in python-apt 0.7.9~exp2 (at least this is my wish, I do not
have commit access to the python-apt repository, and this mail is not
discussed yet
).
My local branch is not online yet, but I m working on it. It is based
off debian-sid revision 202 (which is 0.7.9~exp1).
I would have also suggest to (at least partially) follow PEP 7 (C code),
but re-indenting the whole extension code is not a good idea.
Before I go on, I would like to know your opinions about these proposals,
what you like and what not, your suggestions, etc, etc
List of Proposals
I Deprecation of mixedCase naming conventions in apt module
II Re-organisation of the apt.progress module
III Language updates
IV Unification of testing code
V Cleanup of the code
VI Using unique variable names throughout the modules
VII Some other changes
I. Deprecation of mixedCase naming conventions in apt module
In order to comply with PEP 8, we should start to change our names
from mixedCase to lowercase
withunderscores style. This style is
more common in the Python world, and used eg. in the Python library.
I hereby propose that:
- a new module apt.deprecate is introduced, which provides functions
for compatibility and a class named DeprecateMixedCase
- Most classes are changed to subclass DeprecateMixedCase instead of
object.
- All methods, attributes and variable names are changed from the
mixedCase style to the lowercasewithunderscores style.
- apt_pkg will be changed to call the new methods on progress objects,
and fall back to the old names if methods with new names are not
available.
How backward compatibility is implemented:
The DeprecatedMixedName class provides the methods getattr()
and setattr(). These classes will forward all access to attributes
with mixedNames to the ones with lowercase
withunderscores names.
In case of methods, the getattr() method returns a helper function
which fixes all keyword arguments with mixedCase names and than calls
the right function.
As this only works for methods with mixedCase names, methods which have
mixedCase-named args, get the argument **kwds, and its content will be
checked for mixedCase-named arguments. [On the other side, given that
the API is marked as not stable, we could also drop that level of
compatibility.]
Schedule:
- Implement all the changes in an experimental version of python-apt
as soon as possible.
- (A) Once all packages have been adjusted to use the new names, remove
the old ones (about 50 binary packages, and I would write the needed
patches). This would Breaks: about 50 packages.
or
(B) After the release of Debian Squeeze, remove the compatibility
functions (and the deprecate module from apt). This is the same
as (A), but does not require Breaks on 50 packages.
Known Issues:
- The methods will not be available using their oldName at class
level, only at object level. This means that some code subclassing
apt.* classes may fail. Most code will not break, however.
II. Re-organisation of the apt.progress module
The apt.progress module is not very consistent in the way classes
are named. For example, there is OpTextProgress but TextFetchProgress.
Therefore, I hereby propose that:
- For each of the for types of progress ( Cdrom , Fetch , Install , Op ),
a new class is introduced with the name: Abstract%sProgress % progress
- For each type of progress a class Text%sprogress % progress is introduced,
which subclasses Abstract%sProgress and provides textual output
- For further classes, a general naming scheme is introduced, which is
%(outputtype)s%(progresstype)sProgress [whereas (1) and (2) implement
this naming scheme]
Schedule:
Same as in proposal I.
III. Language updates
The apt package has been written some time ago, and has not been updated
to make use of the latest language features.
Therefore, I propose that:
- all code using old language features is adjusted to use language
features as of Python 2.5.
1.1 Examples include the use of decorators, and the use
of str methods instead of functions of the string module.
- The with statement will be used where appropriate, and that
apt_pkg.*Lock() gain support for being used as context managers.
Schedule:
Implement as soon as possible.
IV. Unification of testing code
Most modules ship test code which will be called when the module is
run as a script.
Therefore, I propose that:
- All testing code in the apt module is removed
- All the tests in the tests directory of python-apt
are converted to a unified testing suite.
- Testing code which has been removed as part of (1) is
reintroduced in the relevant test module, if appropriate.
Schedule:
Implement as soon as possible.
V. Cleanup of the code
In accordance to PEP 8, which is also named as a rule in apt/README.apt,
code will be reformatted where needed.
This includes 2 lines between module-level definitions, spaces after
, , comparing to None using is instead of = , and more.
Schedule:
Implement as soon as possible.
VI. Using unique variable names throughout the modules
I hereby propose the following names:
cache - An apt.cache.Cache() object
pkg - An object returned by cache[str()] (in special cases)
pkg - An apt.package.Package() object
cand - An object returned by depcache.GetCandidateVer()
This would remove some confusion for developers, especially
if you see that apt.Package() objects are named cand in debfile,
but pkg everywhere else.
Schedule:
Implement as soon as possible.
VII. Some other changes
Here is a list of other changes I have already made in my branch:
- Remove apt.package.Record(), it behaves exactly like the
object it is wrapping (apt_pkg.ParseTagFile() result)
- Move the Origin class out of the Package() class and at
the module level.
- If a package should be marked for upgrade, but is not upgradable
raise an exception (which will be apt.package.NotUpgradableError)
Schedule:
Implement as soon as possible.
Posted in Debian
of Nova Scotia.
My past and future colleague Trevor Smedley just lost his appeal to the Supreme Court of Nova Scotia of his criminal conviction for having pet chickens. As the Supreme Court noted in Trevor J. Smedley and Her Majesty the Queen:
Sami Haahtinen wrote a nice post 
In June of 2005, I finished reading
When I ran Black Cat we preferred customers to use role addresses (eg support@, sales@) rather than contact us directly. This had the advantage that more people got the mail, increasing the likelihood of it getting answered swiftly. However some people preferred to email one of us directly, even for trivial matters. Having a preference for using role addresses myself I can sort of understand why people did this; often there is a poor or non existant response from a company's generic email addresses, leaving no choice but to try and email a known contact. However in our case it would have led to a poorer chance of timely response.
If you don t know that leap years don t always happen every 4 years, you really should read about 
I received a 
The 
J r my Bobbio suggested that I should explain how I looked for packages
affected by a compiler bug
(
I really like the 
I make a lot of Web script processing, whether scraping, webservices, systems administration, etc. Because I sometimes happen to repeat small and useful chunks of code for different projects, I thought that, given making new modules and methods is usually hassleless in Ruby, I should make my own set of methods and goodies I constantly use. Example 1, I sometimes miss Perl s LWP::Simple simplicity where I just pass a URL to a subroutine and get the content on a variable, quick, one-liner. Example 2, extract all links on a given URL on an array that I can then iterate and maybe fetch given the first example. Getting all A links is very easy to do, say with regex or with Hpricot (which should the best way to parse HTML), but most of the time I (and people, I d bet) need absolute URLs which is fairly more complex (relative, absolute URLs, BASE href declarations, etc, the same case as in 
As I