[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
I'm working on designing a microformat that can be used to
indicate the location of VCS (git, svn, etc) repositories
related to a web page.
I'd appreciate some web standards-savvy eyes on my
rel-vcs microformat rfc.
If it looks good, next steps will be making things like
gitweb, viewvc, ikiwiki, etc, support it. I've already written a
preliminary 
A few experiments have led to a partial route to pre-seeding Emdebian Grip from a standard Debian Lenny ISO. A few issues arise:
SMS daemon in Gammu is one of it's widely deployed applications. However
I never really liked the way how it is integrated into Gammu. I did not
know much the code, so I did not want to touch it. But recent posts on
Two fixes in this release, let s start with the more important one :)
The DBus configuration file shipped with pommed now explicitly allows method calls to org.pommed, which is needed with the newer versions of DBus where the default configuration on the system bus has been made more strict to close a security hole. If the pommed clients stopped working for you after a DBus update, replace /etc/dbus-1/system.d/pommed.conf by the dbus-policy.conf file shipped with pommed.
Second fix is related to the Apple wireless (Bluetooth) keyboard, which previous versions of pommed would recognize just fine but reject because it exposes a type of events usually indicative of a mouse (and pommed doesn t listen to mouse devices). This is now fixed for this particular keyboard, so pommed will react to the hotkeys on this keyboard too.
For the complete list of changes, see the ChangeLog file in the source distribution. Comments at the usual address :)
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 
Since I managed to get my 
For those following d-devel, you may notice that I've recently been working on improving one of the cornerstones of Debian infrastructure; the Debian Archive Kit, or dak for short. Most DDs and DMs don't notice dak exists expect when trying to determine why their latest upload was rejected, and then yelling at the powers that be. I'm here to shead some light on this mythicial beast.
A few days ago, I