🌐 Mailman 3 May 2000 - Python-list - python.org

Perl to Python
by Ivan Van Laningham June 1, 2000

June 1, 2000

Hi All-- I know I've seen the URL go by on this list; where is the page describing Pythonic ways of doing things for recovering Perlers?-) <now-is-that-perls-before-pythons-or-pythons-before-swine?>-ly y'rs, Ivan ---------------------------------------------- Ivan Van Laningham Axent Technologies, Inc. http://www.pauahtun.org http://www.foretec.com/python/workshops/1998-11/proceedings.html Army Signal Corps: Cu Chi, Class of '70 Author: Teach Yourself Python in 24 Hours

2 1

RMON module
by lellinghaus＠bellsouthips.com May 31, 2000

May 31, 2000

Has anyone created a RMON module for python? Thanks! -- Lance Ellinghaus Sr. Architect eConnections

1 0

tkinter module on a Sgi
by Maurizio Turatti May 31, 2000

May 31, 2000

Hi, I installed the python 1.5.2 package from freeware.sgi.com but when I import Tkinter it doesn't find the _tkinter module. Should I download and compile the source or is the precompiled module "hidden" somewhere into the tarball? thanks, M.T. Sent via Deja.com http://www.deja.com/ Before you buy.

3 2

Python decentralized
by Darrell Gallion May 31, 2000

May 31, 2000

Has anyone thought about decentralizing the Python resources? A system like Gnutella might be the way to get started. http://news.cnet.com/news/0-1005-200-1983259.html?tag=st Bring-on-the-asteroid-ly yr's darrell ===== Darrell Gallion __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/

1 0

[FAQTS] Python Knowledge Base Update -- May 31st, 2000
by Fiona Czuczman May 31, 2000

May 31, 2000

Hi! Below are the entries I've entered into http://python.faqts.com tonight. Request: As a newbie to Python I'm not confident that I am arranging the content into FAQTs as well as I could. If anyone could suggest a more appropriate folder structure or jump into FAQTs and help create it (or move questions into more appropriate folders) I'd be eternally grateful :-) Cheers, Fiona Czuczman ## New Entries ################################################# ------------------------------------------------------------- Why are there no operators equivalent to C's ++, --, +=, etc.? http://www.faqts.com/knowledge-base/view.phtml/aid/3378 ------------------------------------------------------------- Fiona Czuczman Fredrik Lundh, Peter Schneider-Kamp, Michael Hudson if you write things like "var = var + 1" a lot, you might be missing some important python idioms... here are a few, in no specific order: for item in sequence: ... sequence = map(operation, sequence) sequence.append(item) for index in range(size): ... for item1, item2 in map(None, sequence1, sequence): ... for index in range(start, stop, step): ... n = sequence.count(item) for index in range(len(sequence)): ... sequence.remove(item) for index in range(len(sequence)-1, -1, -1): ... (also note that most basic types are *immutable*, so it's not entirely clear how things like ++ and += should work. Michael Hudson wrote a patch for the +=, -=, *=, /= and some other of these operators. A patch can be found at: http://starship.python.net/crew/mwh/aug-patch.html http://www-jcsu.jesus.cam.ac.uk/~mwh21/aug-patch.html ------------------------------------------------------------- How come the global declaration works when I define it from within the interpreter, but not from within a file that I import? http://www.faqts.com/knowledge-base/view.phtml/aid/3381 ------------------------------------------------------------- Fiona Czuczman Curtis Jensen, Emile van Sebille, David Goodger Example: file: foo_bar.py: def foo(i): x = i def bar(i): global y y = i Python interpreter: >>> from foo_bar import * >>> bar(0) >>> print y Traceback (innermost last): File "<stdin>", line 1, in ? NameError: y >>> def other(i): ... global z ... z = i ... >>> other(5) >>> print z 5 >>> ^D Solution: Your 'y' variable exists at the module level in foo_bar. See section 4.1 in the Python Refernce Manual the explains namespaces. Also, from import * can be dangerous as it replaces references in the current namespace. >>> bar(3) >>> foo_bar.y 3 >>> ---------- Because global means "global at the module level". There is no sharing of globals between modules (if there were, what chaos that would create!). When you're working in the interactive interpreter, you are actually in the "__main__" module's namespace. When you import a module (regardless of whether you use "import x" or "from x import *"; the latter just copies all of x's names into the current namespace), you create a new namespace for that module. Any global variables created by that module are global within that module's namespace. For example, assume file mytest.py contains: def spam(i): global x x = i So "x" will be global in mytest's namespace, rather than just local to the spam() function. Now let's test it: >>> from mytest import * >>> spam(5) >>> x Traceback (innermost last): File "<input>", line 1, in ? NameError: x This is as you saw. Now, let's "import sys". "sys.modules" is a dictionary contining all imported modules, indexed by name: >>> import sys >>> sys.modules["mytest"] <module 'mytest' ...> >>> sys.modules["mytest"].x 5 So x *was* changed, in mytest's global namespace, but not __main__'s. When you define a function in the interpreter: >>> def eggs(i): ... global z ... z = i >>> eggs(5) >>> z 5 The function "eggs()" is defined in the "__main__" module, in __main__'s namespace, therefore "global z" makes z a global variable in __main__'s namespace. ------------------------------------------------------------- Walking recursivly through a directory-structure, I've been looking at os.path.walk for this, but I'm not sure how to implement it. http://www.faqts.com/knowledge-base/view.phtml/aid/3380 ------------------------------------------------------------- Fiona Czuczman bragib, François Pinard, Alex You are on the right track... Just use os.path.walk(path, visit, arg) You should write the visit function yourself. Calls the function visit with arguments (arg, dirname, names) for each directory in the directory tree rooted at path (including path itself, if it is a directory). So for instance if you would had a directory tree like this /home/bragi/tmp2/ /home/bragi/tmp2/file1.dat /home/bragi/tmp2/file2.dat /home/bragi/tmp2/file3.dat /home/brag/tmp2/dir2/file1.dat /home/bragi/tmp2/dir2/file2.dat and you want to make a dictionary keyed by the directory name and the dictionary values being the files in that dictionary. import os, posixpath dirContents = {} def visit(arg, dirname, names): files = [] for name in names: if os.path.isfile(name): # keep if file files.append(name) dirContents[dirname] = files arg1 = 'Hello' arg2 = 'World' os.path.walk('/home/bragi/tmp2', visit, (arg1, arg2)) print dirContents Your output would be: {'/home/bragi/tmp2': ['file2.dat', 'file3.dat', 'file1.dat'], '/home/bragi/tmp2/dir2': ['file2.dat', 'file1.dat']} ------ I'm sure examples abound. Like: http://www.iro.umontreal.ca/contrib/recode/lib/distroweb.py Just look for occurrences of the `walk' or `walker' strings. ------ I wanted to learn to use os.path.walk, too, so I wrote a little function that takes a directory and makes a graph out of all the files and sub-directories below it: import os class Directory: def __init__ (self, path): self.path = path self.directory = {self.path: {}} self.directory_pointers = {self.path: self.directory[self.path]} os.path.walk (self.path, self.walk_callback, None) def walk_callback (self, args, directory, files): directory_list = self.directory_pointers[directory] self.directory_pointers[directory] = directory_list for file in files: file = os.path.join (directory, file) directory_list[file] = {} if os.path.isdir (file): self.directory_pointers[file] = directory_list[file] if __name__ == '__main__': t = Directory ('/afs/athena.mit.edu/user/a/l/alex_c/mail') import pprint pprint.pprint (t.directory)

1 0

other python ideas
by Steven D. Arnold May 31, 2000

May 31, 2000

If we do allow typing in a future version of Python, perhaps we should also allow function overloading. This would permit having several, for example, __init__ functions, each taking different parameters. Of course, with Python's named parameter facility, that may be unnecessary, but I tend to think it's better to have several small and simple functions rather than one large and complex one. Also, it seems to me Python's importing mechanism could use some work. Here are some ideas, meant both as interesting ideas in themselves as well as sparks that may introduce even better ways of solving the problem. Perhaps we could allow the programmer of a module to specify sets of names to be exported. Some conventional export sets would be `*', `interface', `standard' and `minimal'. Asterisk is already in use and would continue to mean what it does now -- all top-level names in the module would be exported. The `interface' tag means "give me everything that is part of the public interface." The `standard' tag is similar -- it means "give me the most-used names, the typical ones recommended by the developer." The `minimal' tag means "give me only the most important names." Of course, you could import specific names, too, or a combination of name sets and individual names. For example: from foo import standard, bar It would be up to the developer to determine what name sets to export. The name sets mentioned above would be only conventions -- you could create a named set called anything you want. As with most conventions, people will be less confused if you go with the standard, unless there is a compelling reason to do otherwise. The programmer should be able to mark certain names as "not-for-export." The `*' set would not export such names, though if the module user were to import the name specifically, that would override the "not-for-export" flag. Actually, perhaps it would be simpler to automatically assume that anything not in the `interface' set is "not-for-export." Thoughts, criticisms, etc? steve -- Steven D. Arnold Que quiero sera stevena(a)permanent.cc "We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard." -- John F. Kennedy

19 22

Python for project planning tool
by Jeroen Lamain May 31, 2000

May 31, 2000

Hello, We are trying to develop a project managment tool like MS Project 98. Previously we were developing using c++ and gtk. Yesterday I tried Python and the GNOME binding. I was very impressed by the ease of development. (this was my first experience with Python) Is python ok for developing such a tool ? I mean... is it usable for a such a kind of project. Will I have enough performance when writing everything in Python (UI, task scheduler) ? Regards, Jeroen Lamain

4 3

RE: Using strings with ' in them in SQL-queries
by Doug Stanfield May 31, 2000

May 31, 2000

I do it thus: ----snick---- query = query + "account.account_number LIKE '" + str(value) + "%'" ----snack---- -Doug- > -----Original Message----- > From: thomas(a)cintra.no [mailto:thomas@cintra.no] > Sent: Tuesday, May 30, 2000 10:28 AM > To: python-list(a)python.org > Subject: Using strings with ' in them in SQL-queries > > > Hi, > > I need to insert strings with ' in them in query-strings. I`m using > the PostgreSQL-database. > > If I try stuff like this : > > db = _pg.connection(....) > db.query('insert into test (id, name) value (1, 'fdsfds''fdsf') ') > > That works ok. But the string I need to insert I get from a variable. > I cannot seem to use a variable in the query-string. Is there any way > around this? How can I handle characters in strings that may > comprimise the requirements of a valid sql-statement?? > > Thomas > > > -- > http://www.python.org/mailman/listinfo/python-list >

1 0

CRAZY: First class namespaces
by amitp＠Xenon.Stanford.EDU May 31, 2000

May 31, 2000

I have to warn you. This is a bit wacky, and I have no illusion that any of this will go into Python. It's just some stuff that Python has inspired me to think about, mainly because Python exposes namespaces to the programmer, and programmers do cool things with it. How far can that go? (You're supposed to run away yelling when you hear someone say "How far can something go?") This idea touches on stackless (because stack frames become objects, which are on the heap) and nested scopes, too, if that'll help you run screaming. But if you're ready to read some crazy stuff, here it is: == Python and many other OO languages have a nice way of looking up field names in objects -- they look in an object, then in the class, then superclass, and so on. It's a chained lookup system. Python also uses a chained lookup for variable names. It first looks in locals() and then looks in globals(). If we have nested scopes in P3k, it will look in the local namespace, then in the parent namespace, then in its parent, and so on until we reach the global namespace. Jim Fulton's ExtensionClass implements a chained lookup system that can go from one object to its "container" to find values. I'd like to see all of the chained namespace implementations unified. Objects, classes, modules, activation records ("stack frames") -- all are namespaces underneath. In this proposal, the __parent__ name is treated specially in an object. For looking up a name, you first check the namespace and then if you don't have the name, you ask your parent. If you have no __parent__, you give a NameError. For assigning to a name, you always assign the name in the current namespace, and you never look at the parent. Note that this is just like what we do now, except we call the special field "__class__" if it's in an object and "__bases__" if it's a class. In this system, "ordinary" objects would simply have their class as the __parent__. An ordinary class would have its base class as its __parent__, as long as there's no multiple inheritance [1]. Environmental acquisition (e.g., ExtensionClass) would have its container has its __parent__. At this point, an ordinary class or an acquisition class is no different than a "normal" object, so we may not need classes. (Already in Python, classes and objects aren't so different.) The lookup semantics (chaining for getattr and not chaining for setattr) almost match both how fields in objects work and how local variables work [2]. So we could make namespaces into objects too. In the following example: # module spam.py x = 5 def foo(y): print x x = 8 print x def cheese(z): print x, y, z return spam bar = foo(10) bar(35) The global (module) namespace is an object. (In fact, it's the module object.) It's the object <x = 5, foo = function....>. The function foo needs to remember its scope, so its .co_namespace points to the spam module object. When we *call* foo(10), we need to create a new namespace for the local variables. This is an object <y=10, __parent__ = spam-module>. When we print x, we look for x in this object, and it isn't there. So we look for x in the __parent__, which is the spam module object. It's there, so we return 5 and print it. The next thing we do is assign x to 8. Since there's no chaining on assignment, we create an entry x=8 in the namespace object, which becomes <y=10, x=8, __parent__ = spam-module>. Now we try to print x again. We look in the namespace object and find x is 8, so that's what we print. Next we define a function cheese, which gets its .co_namespace set to the current namespace object. Then we return that function object. The global module now gets bar=function... added to it. And we call bar(35). What happens here? When we call a function, we have to create a new namespace object where the parent is set to the co_namespace. So that's <z=35, __parent__ = <y=10, x=8, __parent__ = spam-module>>. So when we try to print x, y, z, we find 8, 10, 35. Does that all make sense? Summary: rules for variable lookup look and smell a lot like rules for object lookup. If we combine the two, we can also put in classes, acquisition classes, and modules. It's "everything's an object" pushed a bit farther, into the area of local variables. I would keep the syntax that distinguishes classes from objects, but it'd be just syntax -- nothing deeply different underneath. There are few more notes I have: * Methods on objects: We have to resolve the issue of "self" being a magic argument. If objects and classes are the same, then either def foo(self, x) or self.foo = lambda x: .. isn't consistent. We might want to say "method" introduces an unbound method and "def" introduces a bound method (i.e., a function that isn't going to take 'self'). * A magic "self" variable: We could have it so that when you invoke a method, it sets not only __parent__ to the co_namespace, but also sets self to the object. That way, you'd define foo() without listing "self", but you'd still have a "self" object and you'd access fields with "self.f". method foo(x): print self.f + x I'm not convinced this is the right thing to do. * Inline objects: It'd be nice to have a lightweight way of declaring objects, like the <name=value, name=value, ...> syntax I used in the examples above. If objects are everything, you want to be able to make them all the time. It's possible to use {} even though {} is used for dictionaries. If it's {key:value, ..} then it's a dictionary and if it's {name=value, ..} then it's an object. But that may be too confusing. * The "global" keyword: We still want some way of getting to the next level of scope. Since objects and namespaces are combined, and the object has a special __parent__, the __parent__ is exposed as a local variable. So we could do: x = 5 def foo(): __parent__.x = 10 to assign to the global x. If it's nested more: x = 5 def foo(): def cheese(): __parent__.__parent__.x = 5 Not ideal, but then, I don't deal with globals too much anyway. Maybe 'global' can be a magic variable (not keyword) that gets set to the last non-empty __parent__. Then you'd end up doing: x = 5 def foo(): def cheese(): global.x = 5 * Cycles and refcounting If we do nested scopes, we already get the cycles problem. I don't think making namespaces into objects makes anything worse. * Modules: Modules already exhibit this unification of namespaces and objects. From inside the module, you can refer to variables. From otuside the module, you refer to fields. Unifying namespaces and objects wouldn't really do anything to modules. Instead, it'd make all namespaces behave like a module in that they're objects. * Methods on modules: I think you could get methods (including things like __repr__) on modules free here. I haven't thought about it enough, but my intuition tells me that since classes have gone away, and you can put methods on objects, you should be able to put methods on modules too. We just have resolve the bound/unbound method issue. * The "with" statement from Pascal: I suspect you can do "with" pretty easily but I'm not sure about the details. It may require multiple inheritance (aiee) if you want to be able to see local variables at the same time you see an object's fields. * Assignment to __parent__: So far I've been assuming that __parent__ is something set by Python for internal use. For objects, it's set when you call a class constructor. For classes, it's set when you declare the class using the "class" construct. For namespaces, it's set when you call a function. But really, the cool stuff is really when the user can assign to __parent__! For example, __parent__ = self would make it so that you can assign to fields in your object without using "self.". (You'd also lose your local *and* global variables, which would discourage anyone from doing this.) The environmental acquisition aspect of ExtensionClass is pretty easy now -- you just create a raw object and set its __parent__ to its container. You could "reparent" an object on the fly to change its class. Or you could use prototype-based programming techniques, as in Self. * Efficiency: It'll probably be harder to optimize name lookup with something like this (especially if you can change __parent__). However .. with only one underlying implementation for namespaces, objects, modules, and classes, any optimization work you perform here will benefit all of those language features. * Related language features: Simula's objects were originally activation records / stack frames. So making the two similar or even the same is a really old idea. Smalltalk makes everything an object, so my guess is that activation records too were objects. Smalltalk blocks are objects too. JavaScript tries to do something that unifies the two, but gets many aspects totally wrong, by mixing up static scopes and dynamic activation records. (For example, functions get an object with local variables when they're *declared*, even though they haven't been *called* yet!) Pascal and JavaScript have a "with" statement that lets you view an object's fields as variables. -crazily-yr's - Amit FOOTNOTES [1] One snag is multiple inheritance. I don't think we really need multiple inheritance once we have nested scopes, but MI is a really controversial issue. Here's an example of MI: class TCPServer: ... class ForkingMixIn: ... class ForkingTCPServer(ForkingMixIn, TCPServer): pass What I'd do instead is write ForkingMixIn this way: def ForkingMixIn(AnyServer): class ForkingMixIn(AnyServer): ... return ForkingMixIn [Note: I wouldn't want to use this syntax, but this illustrates the underlying construct.] Now I can write ForkingTCPServer this way: ForkingTCPServer = ForkingMixIn(TCPServer) The advantage of this over MI (in Python) is that you can call the methods from the base class. Right now, ForkingMixIn can't easily define method foo() to call TCPServer's foo() and then do one more thing. With the above setup, ForkingMixIn has a handle to the base class, and can call AnyServer.foo(self). Alternatively, a namespace could have a __parents__ tuple, and it could search each one of them. However, this would be unnecessary for variable scoping (unless your mind is really twisted!). It'd be useful for the "with" statement, but it seems confusing. [2] One thing I find confusing in Python is that a local name definition applies even before it's been executed: x = 5 def foo(): print x x = 3 print x IMO, this should print 5 and then 3. The unified namespace proposal would do this. However, Python currently gives a NameError. -- -- Amit J Patel, Computer Science Department, Stanford University http://www-cs-students.stanford.edu/~amitp/

5 14

ANNOUNCE: Release of PyGreSQL version 3.0
by D'Arcy J.M. Cain May 31, 2000

May 31, 2000

Announce: Release of PyGreSQL version 3.0 =============================================== PyGreSQL v3.0 has been released. It is available at: ftp://ftp.druid.net/pub/distrib/PyGreSQL.tgz. If you are running NetBSD, look in the packages directory under databases. There is also a package in the FreeBSD ports collection. PostgreSQL is a database system derived from Postgres4.2. It conforms to (most of) ANSI SQL and offers many interesting capabilities (C dynamic linking for functions or type definition, etc.). This package is copyright by the Regents of the University of California, and is freely distributable. Python is an interpreted programming language. It is object oriented, simple to use (light syntax, simple and straightforward statements), and has many extensions for building GUIs, interfacing with WWW, etc. An intelligent web browser (HotJava like) is currently under development (November 1995), and this should open programmers many doors. Python is copyrighted by Stichting S Mathematisch Centrum, Amsterdam, The Netherlands, and is freely distributable. PyGreSQL is a python module that interfaces to a PostgreSQL database. It embeds the PostgreSQL query library to allow easy use of the powerful PostgreSQL features from a Python script. This release of PyGreSQL is the first DB-SIG API. That's why we have a bump in the major number. There is also a potential problem in backwards compatibility. Previously when there was a NULL in a returned field it was returned as a blank. Now it is more properly returned as a Python None. Any scripts that expect NULLs to be blanks will have problems with this. Due to the fact that the DB-API is brand new, it is expected that there will be a 3.1 release shortly with corrections once many people have had a chance to test it. See the other changes below or in the Changelog file. PyGreSQL 2.0 was developed and tested on a NetBSD 1.3_BETA system. It is based on the PyGres95 code written by Pascal Andre, andre(a)chimay.via.ecp.fr. I changed the version to 2.0 and updated the code for Python 1.5 and PostgreSQL 6.2.1. While I was at it I upgraded the code to use full ANSI style prototypes and changed the order of arguments to connect. Later versions are fixes and enhancements to that. The latest version of PyGreSQL works with Python 1.5.2 and PostgreSQL 6.5. Important changes from PyGreSQL 2.4 to PyGreSQL 3.0: - Remove strlen() call from pglarge_write() and get size from object. (Richard(a)Bouska.cz) - Add a little more error checking to the quote function in the wrapper - Add extra checking in _quote function - Wrap query in pg.py for debugging - Add DB-API 2.0 support to pgmodule.c (andre(a)via.ecp.fr) - Add DB-API 2.0 wrapper pgdb.py (andre(a)via.ecp.fr) - Correct keyword clash (temp) in tutorial - Clean up layout of tutorial - Return NULL values as None (rlawrence(a)lastfoot.com) (WARNING: This will cause backwards compatibility issues.) - Change None to NULL in insert and update - Change hash-bang lines to use /usr/bin/env - Clearing date should be blank (NULL) not TODAY - Quote backslashes in strings in _quote (brian(a)CSUA.Berkeley.EDU) - Expanded and clarified build instructions (tbryan(a)starship.python.net) - Make code thread safe (Jerome.Alet(a)unice.fr) - Add README.distutils (mwa(a)gate.net & jeremy(a)cnri.reston.va.us) - Many fixes by chifungfan(a)yahoo.com, tony(a)printra.net, jeremy(a)alum.mit.edu and others to get the final version ready to release. Important changes from PyGreSQL 2.3 to PyGreSQL 2.4: - Insert returns None if the user doesn't have select permissions on the table. It can (and does) happen that one has insert but not select permissions on a table. - Added ntuples() method to query object (brit(a)druid.net) - Corrected a bug related to getresult() and the money type - Corrected a bug related to negative money amounts - Allow update based on primary key if munged oid not available and table has a primary key - Add many __doc__ strings. (andre(a)via.ecp.fr) - Get method works with views if key specified Important changes from PyGreSQL 2.2 to PyGreSQL 2.3: - connect.host returns "localhost" when connected to Unix socket (torppa(a)tuhnu.cutery.fi) - Use PyArg_ParseTupleAndKeywords in connect() (torppa(a)tuhnu.cutery.fi) - fixes and cleanups (torppa(a)tuhnu.cutery.fi) - Fixed memory leak in dictresult() (terekhov(a)emc.com) - Deprecated pgext.py - functionality now in pg.py - More cleanups to the tutorial - Added fileno() method - terekhov(a)emc.com (Mikhail Terekhov) - added money type to quoting function - Compiles cleanly with more warnings turned on - Returns PostgreSQL error message on error - Init accepts keywords (Jarkko Torppa) - Convenience functions can be overridden (Jarkko Torppa) - added close() method Important changes from PyGreSQL 2.1 to PyGreSQL 2.2: - Added user and password support thanks to Ng Pheng Siong <ngps(a)post1.com> - Insert queries return the inserted oid - Add new pg wrapper (C module renamed to _pg) - Wrapped database connection in a class. - Cleaned up some of the tutorial. (More work needed.) - Added version and __version__. Thanks to thilo(a)eevolute.com for the suggestion. Important changes from PyGreSQL 2.0 to PyGreSQL 2.1: - return fields as proper Python objects for field type - Cleaned up pgext.py - Added dictresult method Important changes from Pygres95 1.0b to PyGreSQL 2.0: - Updated code for PostgreSQL 6.2.1 and Python 1.5. - Reformatted code and converted to ANSI . - Changed name to PyGreSQL (from PyGres95.) - Changed order of arguments to connect function. - Created new type pgqueryobject and moved certain methods to it. - Added a print function for pgqueryobject - Various code changes - mostly stylistic. For more information about each package, please have a look to their web pages: - Python : http://www.python.org/ - PostgreSQL : http://www.PostgreSQL.org/ - PyGreSQL : http://www.druid.net/pygresql/ -- D'Arcy J.M. Cain <darcy(a)druid.net> | Democracy is three wolves http://www.druid.net/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.

1 0