Julian Andres Klode: python-apt: Deprecation of mixedCase names, re-organisation of apt.progress, and more
[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 basedoff 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 changesI. 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 lowercasewithunderscores 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.
and setattr(). These classes will forward all access to attributes
with mixedNames to the ones with lowercasewithunderscores 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.
- 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.
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]
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.
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.
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)
Since I managed to get my 
As I 
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.
I'm trying to work on having days that are somehow individually memorable
this year. So far..
0 (leap day)
Finally tackled the chapter on monads. I'd read various explanations a year
ago, but was swimming in syntax I didn't understand. After percolating for
a year, and learning to read the syntax better, monads turned out to make
very simple sense.
(I can't say the same about 
I bought these 
I've started using 
But it is not only coloring the features you are getting, but also Readline support, command history saving, tab completion, libraries loaded by default, persistent history with Wirble, etc, etc. as you can see yourself on the very self-explanatory configuration file. Enjoy.
Update: I have to thank my co-worker Galin for pointing me most of these neat features.
No, I don't claim 
Yesterday my cat spilled a full cup of hot coffee on my 2k$+ laptop. Today, there is no trace of the incident and the laptop is working perfectly again. This is partially thanks to luck, partially to Dell laptop engineering and partially to my instinctive actions within first 10 seconds of the incident. I will recap it here so that if you happen to have a mishap of such kind you would know what to do to save your laptop.
The first thing I did is pick up the laptop (so that extra coffee from the table would not go into the vents at the bottom of the laptop) keeping the corner that was soaked with coffee downwards. With one hand I held the notebook and pressed and held the Power button to turn the laptop off as soon as possible. With the other hand I removed the power cord and tried to remove the battery as well. It took a couple seconds, but when that was done and the laptop was placed on a towel on the floor the time sensitive part was over.
After that was the clean-up. Coffee from the table and floor (so that other things don t get soaked), coffee form the outside of the laptop (with a damp cloth), After that I disassembled my laptop down to removing the motherboard and checking it for damage. Where ever I found traces of coffee, I cleaned them up with cotton swabs and spirit (clean water would also work, but would require more drying time). After I cleaned and dried every part off with a fan, I put the laptop back together. It took around 2 hours (more like 4 because I had to ask my girlfriend to pick up a new screwdriver on her way home as I lost mine). Everything was working, except the keyboard.
Bits of coffee got inside the keyboard and were shortening the wires so some lines of buttons were not working and some were activating other keys when pressed. On an advice from a fried, I took out the keyboard and washed it. I simply put the keyboard under a stream on running water and made sure that the water got into every possible and impossible opening. After 5 minutes of washing I got the hairdryer and proceeded to dry the keyboard. After an hour I put it in, but it still did not work, so I left it on a heating radiator overnight. After around 18 hours of drying the keyboard started working again. Oh and it was cleaner than it ever was 
Summary: Do not panic! Get water out of you laptop, get it turned off, disconnect power and remove the battery. If you manage to do all that in 10 seconds or less, you might have a chance of seeing your laptop boot up again.