released: RPyC 2.50A
Remote Python Call (RPyC) version 2.50-final is about to be released in the week or so. meanwhile, a release candidate (2.50A) has been released to public review -- please report bugs. i'm still working on real unit-tests for the library, but i'm sure users can help uncover more bugs. http://rpyc.wikispaces.com -tomer -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
Construct 1.25 released
Construct, the parsing made fun library this release focused on minor bugfixes and other small improvements http://pyconstruct.sourceforge.net http://pyconstruct.wikispaces.net -tomer -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
introducing Construct
Construct -- parsing made fun info, demos, and download at: http://pyconstruct.sourceforge.net about: Construct is a library for declaratively defining parsers and builders for arbitrary data structures. Constructs are symmetrical: they can do both parsing and building. Using the vast number of provided primitives, you can easily define your data structures, including advanced concepts like meta-constructs, as shown below. And it's declarative -- so you don't need to write any code for the common cases. You can also easily subclass Construct and write user-defined constructs. Unlike most parsers, Construct works at the bit-level, which means you can easily parse unaligned fields, or work with bit fields of arbitrary lengths. The library supports Fields, Structs, Unions, and Repeaters; Adapters and Validators; Switches, Pointers and other Meta-constructs. To show its power, I provided a fully functional ELF32 file parser, WITHOUT ONE LINE OF PROCEDURAL CODE. It's all declerative. I used it to parse python23.o (2.1MB), in 2.88 sec on my machine. The library comes with a demos folder, an inventory of useful ready-made protocols, and is fully documented with doc-strings, for easy viewing with pydoc and the like. examples: from Construct import * # # simple structures # ethernet_header = Struct(ethernet_header, Bytes(destination, 6), Bytes(source, 6), UInt16(type), ) print ethernet_header.parse(123456ABCDEF\x08\x00) # # meta constructs -- uses meta data # tlv = Struct(tlv, Byte(type), Byte(length), MetaBytes(value, _.length), ) print ethernet_header.parse(\x01\x05ABCDE) -tomer -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
RPyC 2.40
hello pythoneers, last week i released RPyC 2.40 -- http://rpyc.sf.net -- but didnt have time to announce it. also, i updated the site and added sections. i'm not going to repeat the code snippet from the previous release (2.32), you can see full demos on the site. so, of course this release adds many internal changes and (a very few) bugfixes, but the reason i announce it is the new feature added: direct execution of code on the remote side. previously, you had to distribute modules (files) over to the server's side, in order to have remote code, but with the new `execute` method, you can do it with ease. = from Rpyc import SocketConnection c = SocketConnection(somehost) c.execute(something = 9) c.execute(print something) c.execute( def f(name): print hello %s, something is %r % (name, something) ) = and of course you can use the objects you named, via the `namespace`: = c.namespace.something = 28 c.namespace.f(lucy) = that's just a code snippet. see the site and demos (demo-6.py) for much more info. note: this mechanism allows you to embed remote code into your local code, so you dont have to maintain two different files. it should be used when you write ONE module that has two aspects to it (remote code and local code). but dont go and embed different modules into each other -- use it properly. if your scenario calls for two modules, use two modules. don't use shortcuts. and as always, enjoy. -tomer -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
why use special config formats?
hey
i've been seeing lots of config-file-readers for python. be it
ConfigObj (http://www.voidspace.org.uk/python/configobj.html) or the
like. seems like a trend to me.
i came to this conclusion a long time ago: YOU DON'T NEED CONFIG FILES
FOR PYTHON. why re-invent stuff and parse text by yourself, why the
interpreter can do it for you? and anyway, i find this a very ugly
format:
http://www.voidspace.org.uk/python/configobj.html#the-config-file-format
there are two use cases for configuration: static vs. dynamic
configuration.
for the most common case, static configuration, you just have a
human-edited config file holding key-and-value pairs. so just add to
your package a file called config.py, and import it.
for example, if that's our package structure:
PyApache/
__init__.py
config.py
server.py
then server.py would do:
...
import config
listener_sock.bind((config.host, config.port))
...
and config.py would look like:
# the port to bind to
port = 80
host = localhost
timeout = 300
enable_keep_alives = False
options = [1, 2, 3]
...
isn't python suitable enough to hold your configuration?
the second case, dynamic configuration, is when you need to alter your
configuration at runtime or programatically, so the configuration
doesnt need to be human-readable. for that case -- use pickle. and
Bunch (as shown on the aspn python cookbook)
class Bunch(object):
def __init__(self, **kw):
self.__dict__.update(kw)
create the initial config file:
config = Bunch(port = 80, host = localhost, timeout = 300, ...)
pickle.dump(open(config.pkl, wb), config)
of course you can nest Bunch'es inside one another, i.e.,
config = Bunch(
# global config
port = 80,
host = localhost,
# this is per-user configuration
users = {
malcom_x : Bunch(
http_path = /home/joe/httpdocs,
cgi_path = /home/joe/cgi-bin,
options = [i love lucy, bush is gay]
),
...
},
...
)
and now you use it:
# global configuration
config = pickle.load(open(config.pkl))
listener_sock.bind((config.host, config.port))
# and per-user configuration
from getpass import getuser
print config.users[getuser()].http_path
...
that way, if you need to programatically change your configuration,
just change and pickle.dump() it.
hope it helps,
-tomer
--
http://mail.python.org/mailman/listinfo/python-list
Re: why use special config formats?
and just as i was writing, this was added to lang.python.announce: http://groups.google.com/group/comp.lang.python.announce/browse_thread/thread/7a6cbcd8070627a0/24a7b35599f65794#24a7b35599f65794 -tomer -- http://mail.python.org/mailman/listinfo/python-list
Re: why use special config formats?
i dont know about your experience with config files, but there thousands of formats. on the python side -- just in this conversation, we mentioned ConfigObj, ConfigParser and the Config module i linked to. when everybody writes his own config, you get loads of unique formats. anyway, for all the cry-babies here that can't edit pickle files. okay -- just load() them, change what you want, and dump() them. don't cry. and if you insist, i'm sure there's a python serializer to XML/SOAP/whatever other readble format. persistency is far better for configuration than config files. they are limited, have weird syntaxes, hard to extend, and are never generic enough. with my approach -- anything you can do in python, or anything you can pickle -- is possible. and for security issues -- usually config files are edited by admins, so that's not a problem. and per-user config files (at $HOME), can easily be achieved with execfile(). the point is NOT TO WRITE A PARSER for every config file. you can easily crash your web server (or make it non functional) if you pass an invalid port or host, or make it act weird by changing the timeouts or paths... so yeah, if the admin writes a config script that does os.system(rm -rf /), well, too bad. but then the admin can do stupid things at the shell level as well. again -- the points are: * python is readable and easy to write config files with * usually admins change the configuration, and they have too much power anyway * if you worry about security/too much power, pickle your config * if you need to edit your pickled config on a regular basis, serialize it with some other textual serializer (xml, etc). but inventing proprietary formats with unique syntaxes, and having to write and debug parsers for them -- that's stupid. a configuration is just a persistent state of your program. it shouldnt be any more complex than that. -tomer -- http://mail.python.org/mailman/listinfo/python-list
Re: Difference: __iadd__ and __add__
__add__ is called for the + operator __iadd__ is called for the += operator if __iadd__ doesnt exist, fallbacks to __add__ you know what they say for such things: rtfm. -- http://mail.python.org/mailman/listinfo/python-list
