Re: ANN: decorator 4.2.0
On Monday, January 15, 2018 at 2:20:15 PM UTC+1, Michele Simionato wrote: > Dear all, > > a new release of the decorator module is out. The new feature is a simple > facility to define parametric families of decorators (aka decorators with > arguments). > > Here are the relevant links: > > Download: https://pypi.python.org/pypi/decorator/4.2.0 > Project: https://github.com/micheles/decorator/ > Docs: http://decorator.readthedocs.io/en/4.2.0/ We are already at version 4.2.1 now: Download: https://pypi.python.org/pypi/decorator/4.2.1 Docs: http://decorator.readthedocs.io/en/4.2.1/ -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
ANN: decorator 4.2.0
Dear all, a new release of the decorator module is out. The new feature is a simple facility to define parametric families of decorators (aka decorators with arguments). Here are the relevant links: Download: https://pypi.python.org/pypi/decorator/4.2.0 Project: https://github.com/micheles/decorator/ Docs: http://decorator.readthedocs.io/en/4.2.0/ -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Re: Let's talk about debuggers!
pdb plus plus: https://pypi.python.org/pypi/pdbpp -- https://mail.python.org/mailman/listinfo/python-list
Re: multiprocessing shows no benefit
There is a trick that I use when data transfer is the performance killer. Just save your big array first (for instance on and .hdf5 file) and send to the workers the indices to retrieve the portion of the array you are interested in instead of the actual subarray. Anyway there are cases where multiprocessing will never help, since the operation is too fast with respect to the overhead involved in multiprocessing. In that case just give up and think about ways of changing the original problem. -- https://mail.python.org/mailman/listinfo/python-list
Re: Users of namedtuple: do you use the _source attribute?
Il giorno lunedì 17 luglio 2017 19:20:04 UTC+2, Steve D'Aprano ha scritto:
> collections.namedtuple generates a new class using exec, and records the
> source
> code for the class as a _source attribute.
>
> Although it has a leading underscore, it is actually a public attribute. The
> leading underscore distinguishes it from a named field potentially
> called "source", e.g. namedtuple("klass", ['source', 'destination']).
>
>
> There is some discussion on Python-Dev about:
>
> - changing the way the namedtuple class is generated which may
> change the _source attribute
>
> - or even dropping it altogether
>
> in order to speed up namedtuple and reduce Python's startup time.
>
>
> Is there anyone here who uses the namedtuple _source attribute?
>
> My own tests suggest that changing from the current implementation to one
> similar to this recipe here:
>
> https://code.activestate.com/recipes/578918-yet-another-namedtuple/
>
> which only uses exec to generate the __new__ method, not the entire class, has
> the potential to speed up namedtuple by a factor of four.
>
>
>
> --
> Steve
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.
It is an attribute that looks handy for understanding how a namedtuple works,
and can be used in debugging, but in practice I have never used it in
production code. I use a a lot of namedtuple, and if we can get a factor 4
speedup I am pretty happy to lose _source.
--
https://mail.python.org/mailman/listinfo/python-list
decorator 4.1 is out
Dear all,
a new release of the decorator module is out. For the first time we support
decorating Python 3.5 coroutines. For instance, this is an example of how to
implement a tracing decorator called log_start_stop that you can use for
debugging:
import time
import logging
from asyncio import get_event_loop, sleep, wait
from decorator import decorator
@decorator
async def log_start_stop(coro, *args, **kwargs):
logging.info('Starting %s%s', coro.__name__, args)
t0 = time.time()
await coro(*args, **kwargs)
dt = time.time() - t0
logging.info('Ending %s%s after %d seconds', coro.__name__, args, dt)
@log_start_stop
async def make_task(n):
for i in range(n):
await sleep(1)
if __name__ == '__main__':
logging.basicConfig(level=logging.INFO)
tasks = [make_task(3), make_task(2), make_task(1)]
get_event_loop().run_until_complete(wait(tasks))
You will get an output like this:
INFO:root:Starting make_task(1,)
INFO:root:Starting make_task(3,)
INFO:root:Starting make_task(2,)
INFO:root:Ending make_task(1,) after 1 seconds
INFO:root:Ending make_task(2,) after 2 seconds
INFO:root:Ending make_task(3,) after 3 seconds
Also, for the first time the documentation is hosted on readthedocs.org.
Here are the relevant links:
Download: https://pypi.python.org/pypi/decorator/4.1.1
Project: https://github.com/micheles/decorator/
Docs: http://decorator.readthedocs.io/en/latest/index.html
--
https://mail.python.org/mailman/listinfo/python-announce-list
Support the Python Software Foundation:
http://www.python.org/psf/donations/
Decorating coroutines
I have just released version 4.1.1 of the decorator module. The new feature is
that it is possible to decorate coroutines. Here is an example of how
to define a decorator `log_start_stop` that can be used to trace coroutines:
$ cat x.py
import time
import logging
from asyncio import get_event_loop, sleep, wait
from decorator import decorator
@decorator
async def log_start_stop(coro, *args, **kwargs):
logging.info('Starting %s%s', coro.__name__, args)
t0 = time.time()
await coro(*args, **kwargs)
dt = time.time() - t0
logging.info('Ending %s%s after %d seconds', coro.__name__, args, dt)
@log_start_stop
async def task(n): # a do nothing task
for i in range(n):
await sleep(1)
if __name__ == '__main__':
logging.basicConfig(level=logging.INFO)
tasks = [task(3), task(2), task(1)]
get_event_loop().run_until_complete(wait(tasks))
This will print something like this:
~$ python3 x.py
INFO:root:Starting task(1,)
INFO:root:Starting task(3,)
INFO:root:Starting task(2,)
INFO:root:Ending task(1,) after 1 seconds
INFO:root:Ending task(2,) after 2 seconds
INFO:root:Ending task(3,) after 3 seconds
The trouble is that at work I am forced to maintain compatibility with Python
2.7, so I do not have significant code using coroutines. If there are people
out there which use a lot of coroutines and would like to decorate them, I
invite you to try out the decorator module and give me some feedback if you
find errors or strange behaviors. I am not aware of any issues, but one is
never sure with new features.
Thanks for your help,
Michele Simionato
--
https://mail.python.org/mailman/listinfo/python-list
Re: sqlite3 is non-transactional??
Thanks. I suspected the culprit was executescript, but I did not see it documented in https://docs.python.org/3/library/sqlite3.html#connection-objects. -- https://mail.python.org/mailman/listinfo/python-list
sqlite3 is non-transactional??
I know that CREATE queries are non-transactional in sqlite, as documented, but
I finding something really strange in INSERT queries.
Consider this example:
$ cat example.py
import os
import shutil
import sqlite3
script0 = '''\
CREATE TABLE test (
id SERIAL PRIMARY KEY,
description TEXT NOT NULL);
'''
script1 = '''\
INSERT INTO test (id, description)
VALUES (1, 'First');
INSERT INTO test (id, description)
VALUES (2, 'Second');
'''
script2 = '''\
INSERT INTO test (id, description)
VALUES (1, 'Conflicting with the First');
'''
def main(test_dir):
if os.path.exists(test_dir):
shutil.rmtree(test_dir)
os.mkdir(test_dir)
path = os.path.join(test_dir, 'db.sqlite')
conn = sqlite3.connect(path)
conn.executescript(script0) # this is committing implicitly
try:
conn.executescript(script1) # this should not be committing
conn.executescript(script2) # this one has an error
except:
conn.rollback()
curs = conn.execute('select * from test')
for row in curs: # no rows should have been inserted
print(row)
if __name__ == '__main__':
main('/tmp/test')
I am creating the test table in script0, populating it in script1, then trying
to insert another row with a primary key violation. I would have expected the
rollback to remove the rows inserted in script1, since they are part of the
same transaction. Instead they are not removed!
Can somebody share some light on this? I discover the issue while porting some
code from PostgreSQL to sqlite3, with Postgres doing the right thing and sqlite
failing.
I am puzzled,
Michele Simionato
--
https://mail.python.org/mailman/listinfo/python-list
Re: argparse and subparsers
I did not know about docopt. It is basically the same idea of this recipe I wrote about 12 years ago: https://code.activestate.com/recipes/278844-parsing-the-command-line/?in=user-1122360 Good that it was reinvented :-) -- https://mail.python.org/mailman/listinfo/python-list
ANN: plac 0.9.3
plac is a command line parser with strong support for subcommands. Moreover, it offers a framework for defining simple command-based languages. It has also the ability to define remote shells by using an asynchat server. This release fixes some bugs and supports both Python 2 and Python 3 with a single code base. The code has been moved from GoogleCode to GitHub and put under continuous integration with Travis. The tests run for Python 2.6, 2.7, 3.3, 3.4 and 3.5. You can download the new release from PyPI with the usual $ pip install plac The documentation is on GitHub: https://github.com/micheles/plac/blob/0.9.3/doc/plac.pdf Michele Simionato -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Decorator 4.0.10
I have released a new version of the decorator module with an improved documentation, thanks also to the nice CSS submitted by Tony Goodchild. If you are a long time user of the module, see what's new at http://pythonhosted.org/decorator/documentation.html -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Re: Recommendation for Object-Oriented systems to study
On Sunday, May 29, 2016 at 4:42:17 PM UTC+2, Ankush Thakur wrote: > Hello, > > I'm a self-taught programmer who has managed to claw his way out of Python > basics and even covered the intermediate parts. But I feel I have a ton of > theory in my head and would like to see some smallish applications in action. > More specifically, I'm looking for Object Oriented designs that will help me > cement my knowledge and expose me to best practices that books never cover. I > have half a mind to start reading up the Django or Pandas source code, but I > don't want to overwhelm myself. > > Can somebody recommend smaller and simpler projects I can learn from? And if > I can pick the brains of the creator, bonus points! > > Thanks in advance! > > Ankush Read the source code of the doctest module in the standard library. -- https://mail.python.org/mailman/listinfo/python-list
Re: XML Binding
On Thursday, September 3, 2015 at 6:55:06 PM UTC+2, Palpandi wrote: > Hi All, > > Is there any module available in python standard library for XML binding? If > not, any other suggestions. > > Which is good for parsing large file? > 1. XML binding > 2. Creating our own classes > > > Thanks, > Palpandi I am one who has just abandoned lxml for xml.etree in the standard library. The reasons for that change were: 1. we had issues compiling/installing lxml on different platforms 2. we had instabilities from one version to the other for what we wanted to do (XML validation with an XSD schema) At the end we solved everything by replacing the XSD validation with a custom validation (which we had to do anyway); at that point the need for lxml disappeared and ElementTree did everything we wanted, except providing the line error in case of invalid files, which was easy to add. It was also smaller, easier to understand and to customize. Its speed was more than enough. However I hear that everybody else is happy with lxml, so YMMV. Michele -- https://mail.python.org/mailman/listinfo/python-list
Re: ANN: decorator-4.0.0 released
Ops! Cut and paste error from an old announcement. Of course now there is a single documentation both for Python 2 and 3, so the only valid link is https://github.com/micheles/decorator/blob/4.0.0/documentation.rst -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
ANN: decorator-4.0.0 released
The decorator module is over ten years old, but still alive and kicking. It is used by several frameworks and has been stable for a long time. It is your best option if you want to preserve the signature of decorated functions in a consistent way across Python releases. Version 4.0 is fully compatible with the past, except for one thing: support for Python 2.4 and 2.5 has been dropped and now there is an unified code base for Python 2.6, 2.7, 3.0, 3.1, 3.2, 3.3, 3.4, 3.5. You can download the new release from PyPI with the usual $ pip install decorator The source code and the documentation are on GitHub: https://github.com/micheles/decorator/blob/4.0.0/documentation.rst (for Python 2.X) https://github.com/micheles/decorator/blob/4.0.0/documentation3.rst (for Python 3.X) What's new - Since now there is a single manual for all Python versions, I took the occasion for overhauling the documentation. Therefore, even if you are an old time user, you may want to read the docs again, since several examples have been improved. The packaging has been improved and I am distributing the code in wheel format too. The integration with setuptools has been improved and now you can use ``python setup.py test`` to run the tests. A new utility function ``decorate(func, caller)`` has been added, doing the same job that in the past was done by ``decorator(caller, func)``. The old functionality is still there for compatibility sake, but it is deprecated and not documented anymore. Apart from that, there is a new experimental feature. The decorator module now includes an implementation of generic (multiple dispatch) functions. The API is designed to mimic the one of ``functools.singledispatch`` (introduced in Python 3.4) but the implementation is much simpler; moreover all the decorators involved preserve the signature of the decorated functions. Enjoy! Michele Simionato -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
ANN: decorator 3.4.1
The decorator module is 10 year old but still alive and kicking! This release 3.4.1 contains some minor bug fixes. The big change is in the hosting: since Google Code is shutting down the project is now hosted on GitHub: https://github.com/micheles/decorator You can download the new release from PyPI with the usual $ pip install decorator The documentation is on GitHub too: https://github.com/micheles/decorator/blob/3.4.1/documentation.rst (for Python 2.X) https://github.com/micheles/decorator/blob/3.4.1/documentation3.rst (for Python 3.X) Travis is now used to run the tests on several Python versions at the same time: https://travis-ci.org/micheles/decorator/builds/54584865 Enjoy! Michele Simionato -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Re: Python Object Systems
Il giorno mercoledì 13 agosto 2014 19:13:16 UTC+2, thequie...@gmail.com ha scritto: What is the difference between traits and roles? People keep using the same names to mean different concepts. For me traits are the things described here: http://www.iam.unibe.ch/~scg/Archive/Papers/Scha03aTraits.pdf I have no idea of what you mean by roles. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Object Systems
Years ago I wrote strait: https://pypi.python.org/pypi/strait I wonder who is using it and for what purpose, since surprisingly enough it has 50+ downloads per day. For me it was more of an experiment than a real project. -- https://mail.python.org/mailman/listinfo/python-list
Trying to understand the memory occupation of big lists
I have a memory leak in a program using big arrays. With the goal of debugging it I run into the memory_profiler module. Then I discovered something which is surprising to me. Please consider the following script: $ cat memtest.py import gc from memory_profiler import profile @profile def test1(): a = [0] * 1024 * 1024 del a gc.collect() # nothing change if I comment this @profile def test2(): for i in range(10): a = [0] * 1024 * 1024 del a gc.collect() # nothing change if I comment this test1() test2() Here is its output, on a Linux 64 bit machine: $ python memtest.py Filename: memtest.py Line #Mem usageIncrement Line Contents 5 @profile 6 9.250 MB 0.000 MB def test1(): 717.246 MB 7.996 MB a = [0] * 1024 * 1024 8 9.258 MB-7.988 MB del a 9 9.258 MB 0.000 MB gc.collect() # nothing change if I comment this Filename: memtest.py Line #Mem usageIncrement Line Contents 12 @profile 13 9.262 MB 0.000 MB def test2(): 1417.270 MB 8.008 MB for i in range(10): 1517.270 MB 0.000 MB a = [0] * 1024 * 1024 1617.270 MB 0.000 MB del a 1717.270 MB 0.000 MB gc.collect() # nothing change if I comment this In the first case the memory is released (even if strangely not completely, 7.996 != 7.988), in the second case the memory is not. Why it is so? I did expect gc.collect() to free the memory but it is completely ininfluent. In the second cases there are 10 lists with 8 MB each, so 80 MB are allocated and 72 released, but 8 MB are still there apparently. It does not look like a problem of mem_profile, this is what observe with top too. Any ideas? -- http://mail.python.org/mailman/listinfo/python-list
Re: Decorating functions without losing their signatures
On Wednesday, April 3, 2013 3:05:31 AM UTC+2, Rotwang wrote: After thinking about it for a while I've come up with the following abomination Alas, there is actually no good way to implement this feature in pure Python without abominations. Internally the decorator module does something similar to what you are doing. However, instead of cooking up yourself your custom solution, it is probably better if you stick to the decorator module which has been used in production for several years and has hundreds of thousands of downloads. I am not claiming that it is bug free, but it is stable, bug reports come very rarely and it works for all versions of Python from 2.5 to 3.3. -- http://mail.python.org/mailman/listinfo/python-list
Re: Testing against multiple versions of Python
ShiningPanda looks really really cool. I need to investigate it. -- http://mail.python.org/mailman/listinfo/python-list
Testing against multiple versions of Python
Yesterday I released a new version of the decorator module. It should run under Python 2.4, 2.5, 2.6, 2.7, 3.0, 3.1, 3.2, 3.3. I did not have the will to install on my machine 8 different versions of Python, so I just tested it with Python 2.7 and 3.3. But I do not feel happy with that. Is there any kind of service where a package author can send a pre-release version of her package and have its tests run againsts a set of different Python versions? I seem to remember somebody talking about a service like that years ago but I don't remembers. I do not see anything on PyPI. Any advice is welcome! Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
surprising behaviour of global dictionaries
I have the following module implementing a registry of functions with a
decorator:
$ cat x.py
registry = {} # global dictionary
def dec(func):
registry[func.__name__] = func
print registry, id(registry)
return func
if __name__ == '__main__':
import xlib
print registry, id(registry)
The library xlib just defines two dummy functions:
$ cat xlib.py
from x import dec
@dec
def f1():
pass
@dec
def f2():
pass
Then I get the following output:
$ python x.py
{'f1': function f1 at 0x7f7bce0cd668} 27920352
{'f1': function f1 at 0x7f7bce0cd668, 'f2': function f2 at 0x7f7bce0cd6e0}
27920352
{} 27395472
This is surprising since I would expect to have a single global dictionary, not
two: how comes the registry inside the ``if __name__ == '__main__'`` block is
different from the one seen in the library?
This is python 2.7.3 on Ubuntu.
--
http://mail.python.org/mailman/listinfo/python-list
Re: surprising behaviour of global dictionaries
On Tuesday, October 9, 2012 5:24:17 PM UTC+2, Peter Otten wrote: Seriously, you shouldn't use the main script as a library; it is put into the sys.modules cache under the __main__ key. Subsequent imports under its real name will not find that name in the cache and import another instance of the module, with puzzling effects Actually I usually never use the main script as a library, this is why I never experience this puzzling behavior before. But now it is clear, thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: Style question: metaclass self vs cls?
The standard is to use `cls`. In the __new__ method you can use `mcl` or `meta`. -- http://mail.python.org/mailman/listinfo/python-list
A better contextlib.contextmanager
Python 3.2 enhanced contextlib.contextmanager so that it is possible to
use a context manager as a decorator. For instance, given the
contextmanager factory below
@contextmanager
def before_after():
print(before)
yield
print(after)
it is possibile to use it to generate decorators:
@before_after()
def hello(user):
print('hello', user)
This is equivalent to the more traditional
def hello(user):
with before_after():
print('hello', user)
but it has the advantage of saving a level of indentation and we all
know that flat is better than nested. Cool, but there are three issues:
1. I am using Python 2.7, not Python 3.2, so contextmanager has not such feature
2. The contextmanager decorator is losing the signature of the before_after
factory:
help(before_after)
Help on function before_after in module __main__:
before_after(*args, **kwds)
3. before_after() decorators do not preserve the signature of the decorated
function either.
Since I am the author of the decorator module I have easily found out a recipe
to solve both issues. Here it is:
from decorator import decorator, FunctionMaker
from contextlib import GeneratorContextManager
class GeneratorCM(GeneratorContextManager):
def __call__(self, func):
return FunctionMaker.create(
func, with _cm_: return _func_(%(shortsignature)s),
dict(_cm_=self, _func_=func), __wrapped__=func)
@decorator
def contextmanager(func, *args, **kwds):
return GeneratorCM(func(*args, **kwds))
before_after() objects obtained by using this version of
contextmanager become signature-preserving decorators. I am not going
to explain how FunctionMaker performs its magic (hint: it uses eval),
but I am asking a question instead: should I add this feature to the
next release of the decorator module? Do people use the
context-manager-as-decorator functionality? It is quite handy in unit
tests and actually I think it came from the unittest2 module. But I am
reluctant to complicate the API of the module, which currently is
really really small and such has been for many years.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Instrumenting a class to see how it is used
This may get you started (warning: not really tested).
$ echo instr.py
from warnings import warn
oget = object.__getattribute__
tget = type.__getattribute__
class Instr(object):
class __metaclass__(type):
def __getattribute__(cls, name):
clsname = tget(cls, '__name__')
warn('accessing %s.%s' % (clsname, name), stacklevel=2)
return tget(cls, name)
def __getattribute__(self, name):
warn('accessing %s.%s' % (self, name), stacklevel=2)
return oget(self, name)
Then change the base classes of the class you want to instrument, i.e.
class MyClass(MyBase) - class MyClass(MyBase, Instr)
and see what happens. It should work in simple cases.
It will log a lot, so will have to adapt this.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Hierarchical commnd line parsing / help texts
plac is based on argparser and it is intended to be much easier to use. See http://plac.googlecode.com/hg/doc/plac.html Here is an example of usage. $ cat vcs.py class VCS(object): A fictitious version control tool commands = ['checkout', 'commit'] def checkout(self, url): return 'ok' def commit(self): return 'ok' if __name__ == '__main__': import plac; plac.Interpreter.call(VCS) The line plac.Interpreter.call instantiates the VCS class by passing to it the arguments in the command line and then calls the appropriate method. You can use the script as follows: $ python vcs.py -h usage: vcs.py [-h] [args [args ...]] positional arguments: args optional arguments: -h, --help show this help message and exit $ python vcs.py checkout url ok $ python vcs.py commit ok plac takes care of parsing the command line, giving the correct error message if you pass wrong arguments or not enough arguments: $ python vcs.py checkout usage: checkout url checkout: error: too few arguments plac can also be used to write command interpreters. -- http://mail.python.org/mailman/listinfo/python-list
Re: Argparse, and linking to methods in Subclasses
Here is an example by using my own library plac (http://pypi.python.org/pypi/plac): class Server(): def configure_logging(self, logging_file): pass def check(self): pass def deploy(self): pass def configure(self): pass def __init__(self, hostname): self.hostname = hostname class SpamServer(Server): def check(self): pass class HamServer(Server): def deploy(self): pass def main(classname, hostname, methname): # add error checking at will instance = globals()[classname](hostname) getattr(instance, methname)() if __name__ == '__main__': import plac; plac.call(main) -- http://mail.python.org/mailman/listinfo/python-list
Re: Class decorators might also be super too
He is basically showing that using mixins for implementing logging is not such a good idea, i.e. you can get the same effect in a better way by making use of other Python features. I argued the same thing many times in the past. I even wrote a module once (strait) to reimplement 99% of multiple inheritance without multiple inheritance, just to show that in can be done in few lines of code in a language as powerful as Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's super() considered super!
On Friday, May 27, 2011 10:49:52 AM UTC+2, Ben Finney wrote: The exquisite care that you describe programmers needing to maintain is IMO just as much a deterrent as the super-is-harmful essay. Worth quoting. Also I think this article may encourage naive programmers along the dark path of cooperative multiple inheritance, when they could instead use better designs. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's super() considered super!
The fact that even experienced programmers fail to see that super(type(self),self) in Python 2 is NOT equivalent to super() in Python 3 is telling something. -- http://mail.python.org/mailman/listinfo/python-list
Re: Markdown to reStructuredText
Looks cool, I will have a look at it, thanks! -- http://mail.python.org/mailman/listinfo/python-list
Markdown to reStructuredText
Do you know if there is any converter from the Markdown syntax to the rst syntax? Googling for markdown2rst did not help. Thanks! -- http://mail.python.org/mailman/listinfo/python-list
Re: DRY and static attribute for multiple classes.
Notice that Peter's approach also works without inheritance:
registries = {}
@property
def per_class(self):
cls = type(self)
try:
return registries[cls]
except KeyError:
result = registries[cls] = []
return result
class A(object): per_class=per_class
class B(object): per_class=per_class
assert A().per_class is A().per_class
assert B().per_class is B().per_class
assert A().per_class is not B().per_class
(you can also put the per_class property in a module and import it
with
class A(object): from module import per_class).
There is no need to use inheritance if you only need one method.
Notice also that if you
are working with a complex third party framework (say Django) that may
use metaclasses
or strange tricks (such as __slots__) the safer way is to avoid both
inheritance and metaclasses.
HTH,
Michele
--
http://mail.python.org/mailman/listinfo/python-list
Re: Ideas for a module to process command line arguments
On Jan 12, 6:09 pm, Alice Bevan–McGregor al...@gothcandy.com wrote: entirely sure what you mean by 'smart' options. If your'e referring to using a single hyphen and a list of characters to represent a long option (which, to the rest of the world, use two leading hyphens) then that's pretty weird. ;) One major system in the world that doesn't really differentiate between long and short options is... DOS, and by extension, Windows. But they also use / as a switch character. Yes, and plac (it is argparse actually) can accomodate the Windows convention by setting the prefix_chars to /. I wanted to be able to give that freedom even if personally am more used to the GNU double-dash convention. Anyway; I'm happy with what I have wrought (and am continuing to update with support for class-based sub-command dispatch) and will be utilizing it for all scripts in the Marrow suite. To each their own, but reinvention itself can be for motivations other than NIH. I wanted something pure-Python, portable across the 3k barrier without code modification (no 2to3), that didn't use optparse, getopt, or argparse and basically be a translation layer. It can be simpler than that, as marrow.script demonstrates. No arguing against that. BTW, I was not criticizing marrow.script, I was simply deploring the situation in the standard library. If the same approach for parsing command-line options is being reinvented by different people multiple times there must be something wrong with the current standard. -- http://mail.python.org/mailman/listinfo/python-list
Re: Ideas for a module to process command line arguments
On Jan 11, 8:25 am, Alice Bevan–McGregor al...@gothcandy.com wrote: explicit callbacks or typecasting functions, etc. I got tired of using PasteScript and OptParse. Mostly OptParse, actually. :/ It's a pity that the argument parsing modules in the standard library are so verbose that everybody is reinventing the same thing :-( It looks like you have reinvented plac: http://pypi.python.org/pypi/plac -- http://mail.python.org/mailman/listinfo/python-list
Re: Ideas for a module to process command line arguments
On Jan 11, 4:06 pm, Alice Bevan–McGregor al...@gothcandy.com wrote: Plac appears (from the documentation) to be written on top of argparse. :( And the problem with that being what? -- http://mail.python.org/mailman/listinfo/python-list
Re: Ideas for a module to process command line arguments
On Jan 11, 5:22 pm, Jean-Michel Pichavant jeanmic...@sequans.com wrote: Michele Simionato wrote: On Jan 11, 4:06 pm, Alice Bevan McGregor al...@gothcandy.com wrote: Plac appears (from the documentation) to be written on top of argparse. :( And the problem with that being what? ... not available to python 2.5 / 2.6 users :) JM In that case easy_install/pip/whatever will install the dependency automatically (who is installing dependencies by hand nowadays?). More seriously I thought being based on a solid module which is also part of the standard library (for Python 2.7+) was an asset of plac. -- http://mail.python.org/mailman/listinfo/python-list
Re: Ideas for a module to process command line arguments
On Jan 11, 4:06 pm, Alice Bevan–McGregor al...@gothcandy.com wrote:
After looking into it, Plac's default help display isn't very helpful;
you need to massage your application a fair amount before generating
nice, complete-looking argument lists and such. For example:
def main(verbose: ('prints more info', 'flag', 'v'), dsn: 'connection
string'):
@annotate(dsn=connection string, verbose=prints more info)
def main(dsn, verbose=False):
The latter is marrow.script, and even without the annotation a more
complete help text is generated. The -v and flag nature are assumed
from the first unique character and default value. (Flags, when
present on the command line, invert the default value.)
Honestly I do not see any significant difference both in the
level of verbosity for the annotations and in the quality of the help
message provided in the absence of annotations. Originally plac too
was able to recognize flags automatically by looking at the default
value (if the default value is a boolean then the option is a flag);
however I removed that functionality because I wanted to be able to
differentiate between flag and (smart) options (see
http://micheles.googlecode.com/hg/plac/doc/plac.html#scripts-with-options-and-smart-options).
--
http://mail.python.org/mailman/listinfo/python-list
Re: Ideas for a module to process command line arguments
On Jan 11, 6:57 pm, Mike ter...@gmail.com wrote: On Jan 11, 11:26 am, Michele Simionato michele.simion...@gmail.com wrote: In that case easy_install/pip/whatever will install the dependency automatically (who is installing dependencies by hand nowadays?). I do. Is this bad? :} You are simply spending more time than needed, since there are already tools available to perform the task for you. -- http://mail.python.org/mailman/listinfo/python-list
decorator 3.3 is out
Thanks to the holiday period I found the time to add to the decorator module a long-awaited feature, the ability to understand and to preserve Python 3 function annotations. I have just released version 3.3 which implements such feature. It should be considered at an experimental stage. If you use Python 3 and function annotations you may want to try out the new decorator module (easy_install decorator) and give me feedback. See http://pypi.python.org/pypi/decorator for more. Thanks for your time and Happy New Year to all fellows Pythonistas! Michele Simionato P.S. today I have also released a new bug-fixed version of plac (see http://pypi.python.org/pypi/plac) -- http://mail.python.org/mailman/listinfo/python-list
Re: STARTTLS extension not supported by server
For future googlers: it turns out in my case the call to .starttls() was not needed: I removed it and everything worked. Dunno why I was there in the first place, the original code was written by somebody else. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using property() to extend Tkinter classes but Tkinter classes are old-style classes?
On Nov 29, 12:15 am, Terry Reedy tjre...@udel.edu wrote: On 11/28/2010 3:47 PM, pyt...@bdurham.com wrote: I had planned on subclassing Tkinter.Toplevel() using property() to wrap access to properties like a window's title. After much head scratching and a peek at the Tkinter.py source, I realized that all Tkinter classes are old-style classes (even under Python 2.7). 1. Is there a technical reason why Tkinter classes are still old-style classes? To not break old code. Being able to break code by upgrading all classes in the stdlib was one of the reasons for 3.x. -- Terry Jan Reedy Notice that you can upgrade a Tkinter class to a new-style class simply by deriving from object. For instance you could define a new-style Label class as: class Label(Tkinter.Label, object): pass then you can attach properties to it. You have a good chance of not breaking anything in doing so, but you cannot know for sure unless you try. I don't know if Tkinter uses features of old-style classes which are inconsistent with new- style classes, but probably the answer is not much. Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Needed: Real-world examples for Python's Cooperative Multiple Inheritance
On Nov 28, 2:01 pm, m...@distorted.org.uk (Mark Wooding) wrote: Steve Holden st...@holdenweb.com writes: It isn't. Even inheritance itself isn't as useful as it at first appears, and composition turns out in practice to be much more useful. That goes double for multiple inheritance. Composition /with a convenient notation for delegation/ works fairly well. Indeed, this can be seen as the basis of Self. But downwards delegation -- where a superclass leaves part of its behaviour unspecified and requires (concrete) subclasses to fill in the resulting blanks -- is hard to express like this without some kind of means of identifying the original recipient of the delegated message. Once you've done that, there isn't much of a difference between a superclass and a component with implicit delegation. -- [mdw] For a long time I had the feeling that in a language with pattern matching inheritance (both single and double) is basically useless. You can easily define objects as functions responding to messages and classes becomes useless. However I have never implemented a large project with such techniques, so I am not sure how much my gut feeling is sound. Apparently here at work we are going to use Erlang in the near future and I hope to get my hand dirty and see in practice how well one can work with a language without inheritance. BTW, is there anybody here with experience on such languages and caring to share his learned lessons? Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: How do you find out what's happening in a process?
On Nov 29, 7:01 am, Leo Jay python.leo...@gmail.com wrote: Hi all, I'd like to know how do you guys find out what's happening in your code if the process seems not work. In java, I will use jstack pid to check stacks of threads and lock status. But I don't know how to do it in python. -- Best Regards, Leo Jay If you give a CTRL-C the Python process will die with a traceback showing the line where the process got stuck (assuming you started it from the command-line). You can even run the script under the debugger and give a CTRL-C after a while, as follows: $ python -m pdb thescript.py (Pdb) c wait a bit ... CTRL-C Traceback ... ... (Pdb) inspect the variables and continue if you like -- http://mail.python.org/mailman/listinfo/python-list
Re: Needed: Real-world examples for Python's Cooperative Multiple Inheritance
On Nov 24, 9:08 pm, Raymond Hettinger pyt...@rcn.com wrote: So far, the only situation I can find where method names necessarily overlap is for the basics like __init__(), close(), flush(), and save() where multiple parents need to have their own initialization and finalization. I do not know of other use cases either. Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
STARTTLS extension not supported by server
I have a CentOS machine with Python 2.4 and I wanted to install Python 2.7 on it. The installation went fine but now I have a problem with a script sending email via TLS authentication. If I do something like import smtplib smtpO = smtplib.SMTP(server) smtpO.ehlo() smtpO.starttls() I get the following error: Traceback (most recent call last): File y.py, line 5, in module smtpO.starttls() File /home/rcare/lib/python2.7/smtplib.py, line 614, in starttls raise SMTPException(STARTTLS extension not supported by server.) smtplib.SMTPException: STARTTLS extension not supported by server. Notice that this not a problem of the SMTP server, since with Python 2.4 the script is connecting to the SMTP server just fine. At first I thought the problem was with the ssl support, I recompiled the module, but I still get the same error. Do you have any suggestion to be debug the issue and to figure out where the problem is? TIA, Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: How to get dynamically-created fxn's source?
On Nov 5, 5:55 pm, gb345 gb...@invalid.com wrote: For a project I'm working on I need a way to retrieve the source code of dynamically generated Python functions. (These functions are implemented dynamically in order to simulate partial application in Python.[1]) The ultimate goal is to preserve a textual record of transformations performed on data, along with all the data (both pre- and post- transformation) itself. These transformation functions could be dynamically generated as closures, but I suspect that this would make it more difficult to extract source code that could serve as a reasonably self-contained description of the transformation (because this source code would refer to variables defined outside of the function). An alternative would be to generate the *source code* for the functions dynamically, from a template having slots (within the function's definition) that gets filled in with actual parameter values, and pass this source code to exec. In any case, the problem remains of how to extract the dynamically-generated function's source code. One possibility would be to define a Transformation wrapper class whose __init__ takes the dynamically-generated source code (a string) as argument, keeps it around as an instance attribute for future reference, and exec's it to define its __call__ method. Is this overkill/reinventing the wheel? IOW, does Python already have a built-in way to achieve this same effect? (Also, the wrapper scheme above is somewhat loose: it's relatively easy for the source code instance attribute (as described) to fall out of sync with the function that actually executes when __call__ runs. Maybe a tighter connection between the obtained source code and the code that actually executes when __call__ runs is possible.) I'm aware of the inspect module, but from reading its source code I gather that it is designed for inspecting source code that is explicitly written in files, and would not be too good at inspecting functions that are generated dynamically (i.e. not from source code explicitly given in a source file--I hope that made sense). Your comments and suggestions would be much appreciated. Many thanks in advance! G [1] For example, given a base function spam that has the signature (typeT, typeT, typeT, int, int, int) and three specific integer values X, Y, and Z, dynamically generate a new function spamXYZ with signature (typeT, typeT, typeT) such that spamXYZ(A, B, C) is identical to spam(A, B, C, X, Y, Z), for all possible values of A, B, C. I wondered a lot about this issue when writing my own decorator module. You may look at the source code of the FunctionMaker class which tries to address the problem by storing the source code of the generated function into an attribute. Using inspect.getsource does not work (see http://bugs.python.org/issue1764286). Of course if you functools.partial is enough to solve your problem use it and be done with it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Best method for a menu in a command line program?
On Nov 4, 2:19 am, braden faulkner brf...@gmail.com wrote: I'm using a menu for my command line app using this method. choice = foobar while choice != q: if choice == c: temp = input(Celsius temperature:) print Fahrenheit:,celsius_to_fahrenheit(temp) elif choice == f: temp = input(Fahrenheit temperature:) print Celsius:,fahrenheit_to_celsius(temp) elif choice != q: print_options() choice = raw_input(option:) Just wondering if there is another or more efficient way I should be doing it? Thanks -- Braden Faulkner Here is a solution using plac (http://pypi.python.org/pypi/plac): $ echo c2f.py import plac class Converter(object): commands = ['celsius_to_fahrenheit', 'fahrenheit_to_celsius'] @plac.annotations(t='convert Celsius to Fahrenheit') def celsius_to_fahrenheit(self, t): return round(32 + float(t) * 9/5) @plac.annotations(t='convert Fahrenheit to Celsius') def fahrenheit_to_celsius(self, t): return round((float(t) - 32) * 5 / 9.0) if __name__ == '__main__': import plac; plac.Interpreter.call(Converter) Here is an example of non-interactive usage: $ python c2f.py fahrenheit_to_celsius 212 100.0 $ python c2f.py celsius_to_fahrenheit 100 212.0 Here is an example of interactive usage:$ python c2f.py -i i celsius_to_fahrenheit 100 212.0 i celsius_to_fahrenheit 0 32.0 i fahrenheit_to_celsius 32 0.0 i fahrenheit_to_celsius 212 100.0 -- http://mail.python.org/mailman/listinfo/python-list
Re: A good decorator library
On Oct 22, 10:42 pm, Felipe Bastos Nunes felipe.bast...@gmail.com wrote: Hi! I was looking for a good decorator library to study and make my own decorators. I've read the Bruce Eckel's blog at artima dot com. But I need some more examples. I'm building a WSN simulator like SHOX is in java, but programming it in python. I'd like to use decorators to set methods that would be logged as statistics and some more funcionalities like check a method to check the params' types. Thanks in advance, and (at least here) good night eheh -- Felipe Bastos Nunes My own decorator module seems to be quite popular nowadays, by judging by the number of downloads. Even if you end up not using it, the documentation is quite pedagogic and intended for beginners, so you may want to look at it: http://pypi.python.org/pypi/decorator -- http://mail.python.org/mailman/listinfo/python-list
Re: using optparser
Accepting both options and positional arguments for the same purpose
does not look like a good idea to me.
Anyway, here is a solution using plac (http://pypi.python.org/pypi/
plac) assuming you can afford an external dependency:
import plac
@plac.annotations(
personname=(person to be matched, 'option', 'i'),
groupname=(group containing people to be tested against,
'option', 'f'),
samplenumber=(how many samples to be used, 'option', 'n', int),
cutoff=(some upperlimit, 'option', 't'))
def main(personname, groupname, samplenumber, cutoff, *args):
# the implementation below does not allow mixing options and args
# it works only if you give no options and the needed 4 arguments
if (personname is None and groupname is None and samplenumber is
None
and cutoff is None): # no options given, look at the arguments
try:
personname, groupname, samplenumber, cutoff = args
except ValueError:
plac.parser_from(main).error('Not enough arguments (got %d
of 4)'
% len(args))
return personname, groupname, samplenumber, cutoff
if __name__ == '__main__':
import plac; print plac.call(main)
--
http://mail.python.org/mailman/listinfo/python-list
Re: optparser: how to register callback to display binary's help
Here is a solution using plac (http://pypi.python.org/pypi/plac) and
not OptionParse, in the case
the Linux underlying command is grep:
import subprocess
import plac
@plac.annotations(help=('show help', 'flag', 'h'))
def main(help):
if help:
script_usage = plac.parser_from(main).format_help()
po = subprocess.Popen(['grep', '-h'], stderr=subprocess.PIPE)
grep_usage = po.stderr.read()
print script_usage
print grep_usage
main.add_help = False
if __name__ == '__main__':
plac.call(main)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python in Linux - barrier to Python 3.x
On Sep 21, 2:29 pm, Ant ant...@gmail.com wrote: Hi all, I've just seen this:http://sheddingbikes.com/posts/1285063820.html Whatever you think of Zed Shaw (author of the Mongrel Ruby server and relatively recent Python convert), he has a very good point in this. I run Fedora 12 on my home computers, and find it far too much hassle to try to get Python 3 installed. Even the 2.x's are behind - IIRC think it currently uses 2.5. So I really think this is a barrier to entry to Python 3 that we could do without - it's the only reason I do all of my Python work in 2.x, I would jump at migrating to Python 3 if it was easily available on Fedora. Is there a solution to this that anyone knows of? Has Zed jumped to conclusions? Have I? Zed's approach (removing Python when it could just have downgraded to Python 2.4) does not look very smart to me. The post itself is pretty much bullshit. Yes, there are Linux distributions with old Python versions out there. Yes, if you don't want to install a newer Python on such distributions you need to take in account this fact and not to use modern features of Python. But the situation is not different for other languages such as Perl or Ruby. C is free from this problem because it is a very old and stable language. There is no more content in that post and everybody should already know such basic facts. Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: argparse list
On Sep 2, 1:45 pm, Neal Becker ndbeck...@gmail.com wrote:
I'm interested in using argparse to parse a string formatted as:
my_prog --option1=1,10,37
That is, a list of comma delimited values. I guess nargs almost does it,
but expects options to be space-delimited.
What would be the easiest approach?
In plac (http://pypi.python.org/pypi/plac) you would write the
following:
import plac
@plac.annotations(
option1=('option with comma separated values',
'option',
'o',
lambda x: x.split(',')))
def main(option1):
print option1
if __name__ == '__main__':
plac.call(main)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Structured programming with optionParser
On Aug 31, 3:45 am, NickC reply...@works.fine.invalid wrote: I'm struggling to see how you could refactor the option parsing function. After all, it has to process the options, so it has to do all the setup for those options, and then process them. Perhaps plac could simplify your life, by removing most of the boilerplate of option parsing: http://pypi.python.org/pypi/plac -- http://mail.python.org/mailman/listinfo/python-list
Re: Structured programming with optionParser
Perhaps, I should give an example of using plac. For instance, here is how you could implement a SVN-like tool with two commands ``checkout`` and ``commit``. The trick is to write a class with two methods ``checkout`` and ``commit`` and an attribute ``.commands`` listing them, and to call the class with ``plac.Interpreter.call``:: $ cat vcs.py class VCS(object): A fictitious version control tool commands = ['checkout', 'commit'] def checkout(self, url): return 'ok' def commit(self): return 'ok' if __name__ == '__main__': import plac; plac.Interpreter.call(VCS) The line ``plac.Interpreter.call`` instantiates the ``VCS`` class by passing to it the arguments in the command line and then calls the appropriate method. You can use the script as follows:: $ python vcs.py -h usage: vcs.py [-h] [args [args ...]] positional arguments: args optional arguments: -h, --help show this help message and exit $ python vcs.py checkout url ok $ python vcs.py commit ok plac_ takes care of parsing the command line, giving the correct error message if you pass wrong arguments or not enough arguments:: $ python vcs.py checkout usage: checkout url checkout: error: too few arguments You should realize that there is no real difference between a command-line argument parser featuring subcommands and an command interpreter, therefore the previous script also works as an interactive interpreter:: $ python vcs.py -i i .help special commands .help .last_tb custom commands === checkout commit i checkout url ok i commit ok There is full help support, i.e. you can ask for ``.help command`` for any command, including the special ones such as ``.help`` and ``.last_tb``. There is full support for autocompletion and command history too, provided you have the readline library installed (on Unices) or the pyreadline library (on Windows). plac also support a batch mode: you can write a set of commands on a file and have them executed by the plac runner. :: $ echo vcs-commands.plac #!vcs.py:VCS checkout url # nontrivial commands here commit $ plac_runner.py --batch vcs-commands.plac ok skip #lines with comments are skipped ok For more (including managing options, which I have not shown here) you should check the full documentation of plac. I have just uploaded release 0.7.2, which is required for this example to work. -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On Aug 17, 6:50 am, AK andrei@gmail.com wrote: On 08/17/2010 12:26 AM, James Mills wrote: By the way, the reason I asked is that we're working on a python tutorial and I realized that even though I'm used to 99, I wasn't sure if it's ok to teach that to new users or not.. -andrei It is certainly NOT useful to teach a convention which is explicitly discouraged in the Python guidelines (PEP 8). Having said that, I particularly *hate* people using long lines, and I usually reindent the code of my coworkers not following that convention. The reason is that my Emacs is set to 79 chars and longer code looks ugly, that I look at two-side diffs all the time, and that sometimes I want to print on paper the code I have to work with. OTOH, I do not see a single advantage in using long lines. Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Builtn super() function. How to use it with multiple inheritance? And why should I use it at all?
On Jul 31, 5:08 am, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: I have read Michelle Simionato's articles on super in Python. One l please! I am a man! ;-) But Michelle is wrong to conclude that the problem lies with the concept of *superclass*. The problem lies with the idea that there is ONE superclass. By dismissing the entire concept, he is throwing out the baby with the bathwater. I am actually more radical than that. From http://www.artima.com/weblogs/viewpost.jsp?thread=237121: In this series I have argued that super is tricky; I think nobody can dispute that. However the existence of dark corners is not a compelling argument against a language construct: after all, they are rare and there is an easy solution to their obscurity, i.e. documenting them. This is what I have being doing all along. On the other hand, one may wonder if all super warts aren't hints of some serious problem underlying. It may well be that the problem is not with super, nor with cooperative methods: the problem may be with multiple inheritance itself. Then I spend thousands of words in the Mixin considered harmful series and in other articles arguing against multiple inheritance and cooperative methods. They are just bad design IMO. Of course we are in the range of opinions, this is a tricky subject: many smart people agree with me and many others equally smart disagree. Still I believe that super is a red herring and that you should really start thinking: what advantages did multiple inheritance *really* bring into my code? Could have I done without? And what would have happen? These are the relevant question, not the exact meaning of super in hairy hierarchies. M. Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: let optionparse.Optionparser ignore unknown command line switches.
On Aug 1, 1:08 pm, News123 news1...@free.fr wrote:
I wondered, whether there's a simple/standard way to let
the Optionparser just ignore unknown command line switches.
thanks in advance for any ideas
I will plug in my own work on plac: http://pypi.python.org/pypi/plac
Your problem would be solved as follows:
import plac
@plac.annotations(test=('a flag', 'flag', 't'))
def main(test, *ignore):
print test, ignore
if __name__ == '__main__':
plac.call(main, [-t,--ignoreme_and_dont_fail])
--
http://mail.python.org/mailman/listinfo/python-list
Re: Multiprocessing zombie processes
On Jul 25, 1:11 am, Navkirat Singh navkir...@gmail.com wrote: OK I wanted zombie processes and have been able to regenerate them with multiprocessing. Now lets see how I can handle them. The multiprocessing docs say: Joining zombie processes On Unix when a process finishes but has not been joined it becomes a zombie. There should never be very many because each time a new process starts (or active_children() is called) all completed processes which have not yet been joined will be joined. Also calling a finished process’s Process.is_alive() will join the process. Even so it is probably good practice to explicitly join all the processes that you start. -- http://mail.python.org/mailman/listinfo/python-list
Re: Builtn super() function. How to use it with multiple inheritance? And why should I use it at all?
Everything you ever wanted to know about super is collected here: http://micheles.googlecode.com/hg/artima/python/super.pdf M.S. -- http://mail.python.org/mailman/listinfo/python-list
Re: understanding the mro (long)
On Jul 24, 4:42 am, Rolando Espinoza La Fuente dark...@gmail.com wrote: Finally everything make sense. And make think about be careful when doing multiple inheritance. Any thoughts? ~Rolando I am not fond of multiple inheritance either and I wrote at length about the dangers of it. If you do not know it already, you may be interested in reading my Mixins considered harmful series http://www.artima.com/weblogs/viewpost.jsp?thread=246341 (together with any blog posts on super and related subjects). -- http://mail.python.org/mailman/listinfo/python-list
Re: linux console command line history
On Jul 20, 11:38 pm, kak...@gmail.com kak...@gmail.com wrote: Hi to all, I 'm writing a linux console app with sockets. It's basically a client app that fires commands in a server. For example: $log user 55 $sessions list $server list etc. What i want is, after entering some commands, to press the up arrow key and see the previous commands that i have executed. Any hints? Any examples? Antonis You may find interesting to look at the source code for plac (http:// micheles.googlecode.com/hg/plac/doc/plac_adv.html). The readline support (including command history and autocompletion) is implemented in the ReadlineInput class (see http://code.google.com/p/micheles/source/browse/plac/plac_ext.py). If you just want command history you can use rlwrap (http:// freshmeat.net/projects/rlwrap). -- http://mail.python.org/mailman/listinfo/python-list
Re: Code generator and visitor pattern
On Jul 15, 7:58 pm, Karsten Wutzke kwut...@web.de wrote:
Hello,
this is obviously a Python OO question:
Since Python isn't stringly typed, single-dispatch isn't available per
se. So is the double-dispatch Visitor pattern, which is usually used
in OO systems to implement code generators. So, what is the de facto
method in Python to handle source code generation?
Karsten
You ask about code generation and you already had answers in that
area, but let me talk a bit about a simpler topic, traversing a
hierarchical file system. I think this is relevant (even if not
answering your question) if you want to get familiar with the Python
way. In the old days, the way to traverse a file system was through
the os.path.walk function. Here is what the docs say (from
http://docs.python.org/library/os.path.html):
os.path.walk(path, visit, arg)
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). The argument dirname specifies the visited
directory, the argument names lists the files in the directory (gotten
from os.listdir(dirname)). The visit function may modify names to
influence the set of directories visited below dirname, e.g. to avoid
visiting certain parts of the tree. (The object referred to by names
must be modified in place, using del or slice assignment.)
As you see the documentation make explicit reference to the visitor
pattern.
However a note below says:
This function is deprecated and has been removed in 3.0 in favor of
os.walk().
In other word, the visitor pattern is *not* the Pythonic way to solve
this
problem. The Pythonic way is to use os.walk, which converts the nested
structure in a flat structure. From the docs
(http://docs.python.org/library/os.html):
This example displays the number of bytes taken by non-directory files
in each directory under the starting directory, except that it doesn’t
look under any CVS subdirectory:
import os
from os.path import join, getsize
for root, dirs, files in os.walk('python/Lib/email'):
print root, consumes,
print sum(getsize(join(root, name)) for name in files),
print bytes in, len(files), non-directory files
if 'CVS' in dirs:
dirs.remove('CVS') # don't visit CVS directories
There is a big conceptual difference between os.path.walk and os.walk.
The first works like a framework: you pass a function to it and
os.path.walk
is in charging of calling it when needed. The second works like a
library:
os.walk flattens the hierarchical structure and then you are in charge
of
doing everything you wish with it.
os.walk is the Pythonic way, and you suggested to follow that
approach;
for instance elementTree and lxml (libraries for parsing XML data)
work
exactly that way. Actually one of the motivating examples for the
introduction of generators in Python was their use in flattening
data structure, i.e. exactly the pattern used by os.walk.
The message is stop thinking like in Java and start using idiomatic
Python. We are here to help.
Michele Simionato
--
http://mail.python.org/mailman/listinfo/python-list
multiline input and readline
Googling for ways to use the readline library with multiline input I found out the following stackoverflow answer: http://stackoverflow.com/questions/161495/is-there-a-nice-way-of-handling-multi-line-input-with-gnu-readline The solution is to use the rl_bind_key function, but it does not look like such function is wrapped in Python: what are my options? Notice that compatibility with pyreadline (which work on Windows) would be a plus. TIA, Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: C interpreter in Lisp/scheme/python
On Jun 14, 1:07 am, bolega gnuist...@gmail.com wrote: I am trying to compare LISP/Scheme/Python for their expressiveness. For this, I propose a vanilla C interpreter. I have seen a book which writes C interpreter in C. The criteria would be the small size and high readability of the code. Are there already answers anywhere ? How would a gury approach such a project ? Bolega This look like a huge project for an evaluation of expressiveness which result is obvious. Lisp (including Scheme) is more expressive than Python, for many definitions of expressiveness (see for instance http://www.ccs.neu.edu/scheme/pubs/scp91-felleisen.ps.gz if you like academic papers). However, who cares? What matters in everyday life are other things, like the availability of libraries, tools, easy of maintenance, etc. In your proposed project the choice of the parsing library would matter a lot. Writing languages is a domain where Lisp is traditionally strong, so you may find good libraries to help you with the task. My guess is that it would take more or less the same amount of effort both in Python and in Lisp. The place where Lisp has an advantage is writing an *embedded* language: then thanks to macros you could write a *compiled* sublanguage. Doing the same in Python is essentially impossible. Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)
On Jul 7, 10:55 pm, Carl Banks pavlovevide...@gmail.com wrote: On Jul 7, 1:31 am, Paul McGuire pt...@austin.rr.com wrote: I just couldn't get through on the python-dev list that I couldn't just upgrade my code to 2.6 and then use 2to3 to keep in step across the 2-3 chasm, as this would leave behind my faithful pre-2.6 users. This is a point I do not understand. My recent module plac is meant to work from Python 2.3 to Python 3.1 and to this goal I make use of 2to3 at the *client* side. Users of Python 2.X get the original code with no magic whatsoever; users of Python 3.X get the same code, but at installation time 2to3 is run by the setup.py script. The mechanism requires distribute to be installed, but I would say that having distribute is a must for Python 3.X users; Python 2.X users do not need anything, so the approach is backward compatible. I thought this was the recommended way of using 2to3 and so far is working for me. M. Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: I strongly dislike Python 3
On Jun 30, 2:52 pm, Lie Ryan lie.1...@gmail.com wrote: On 06/27/10 11:24, Steven D'Aprano wrote: Producing print function takes a little bit more effort than producing a print statement. (1) The main use-cases for print are quick (and usually dirty) scripts, interactive use, and as a debugging aid. That is precisely how the quick-and-dirty syntax of print statement can be justified. While debugging, you'll need to be able to quickly add and delete prints here and there, and the extra parens can quickly become irritating. Actually when debugging I use pdb which uses p (no parens) for printing, so having print or print() would not make any difference for me. -- http://mail.python.org/mailman/listinfo/python-list
Re: optparse TypeError
On Jun 28, 3:30 pm, dirknbr dirk...@gmail.com wrote:
I get an int object is not callable TypeError when I execute this. But
I don't understand why.
parser = optparse.OptionParser(usage: %lines [options] arg1)
parser.add_option(-l, --lines, dest=lines,
default=10, type=int,
help=number of lines)
parser.add_option(-t, --topbottom, dest=topbottom,
default=T, type=str,
help=T(op) or B(ottom))
(options, args) = parser.parse_args()
if len(args) != 1:
parser.error(incorrect number of arguments)
lines=options.lines
tb=options.topbottom
Dirk
lines(args[0],topbottom=tb,maxi=lines)
optparse is so old-fashioned. Use plac!
$ cat x.py
import plac
@plac.annotations(
lines=('number of lines', 'option', 'l', int),
topbottom=('T(op) or B(ottom)', 'option', 't', str, 'TB'))
def main(arg, lines=10, topbottom='T'):
print arg, lines, topbottom
if __name__ == '__main__':
plac.call(main)
$ python x.py -h
usage: x.py [-h] [-l 10] [-t T] arg
positional arguments:
arg
optional arguments:
-h, --help show this help message and exit
-l 10, --lines 10number of lines
-t T, --topbottom T T(op) or B(ottom)
(see http://pypi.python.org/pypi/plac)
--
http://mail.python.org/mailman/listinfo/python-list
Re: optparse TypeError
On Jun 28, 9:56 pm, Ben Finney ben+pyt...@benfinney.id.au wrote: Michele Simionato michele.simion...@gmail.com writes: optparse is so old-fashioned. Use plac! The OP should be made aware that: * plac is a third-party library with (TTBOMK) no prospect of inclusion in the standard library * optparse is in the standard library and has been for many versions * argparse is a third-party library that is now accepted for inclusion in the standard library, intended as a full optparse replacement URL:http://www.python.org/dev/peps/pep-0389/ All valid points. I will just add that plac is based on argparse and nothing else, so it is an external dependency, yes, but not a large dependency. Moreover the core is only 200 lines. People can just grab http://micheles.googlecode.com/hg/plac/plac_core.py, and include it in their personal code base, possibly adapting it (I mean for people preferring recipes to external dependencies). Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: optparse TypeError
On Jun 28, 11:47 pm, rantingrick rantingr...@gmail.com wrote:
Give your *script* an
enema, and do *yourself* a favor by harnessing the simplistic elegance
of the optphart module instead!
#-- Start Script --#
def optphart(args):
d = {'args':[]}
for arg in args:
if arg.startswith('-'):
key, value = arg.split('=', 1)
options = value.split(',')
if len(options) 1:
d[key[1:]] = options
else:
d[key[1:]] = [value]
else:
d['args'].append(arg)
return d
Probably I should not be answering this, but try to implement the
parsing required by the OP with this approach, including the
generation of the usage message and the error checking. Just try.
M. S.
--
http://mail.python.org/mailman/listinfo/python-list
plac 0.5 is out!
A few weeks ago I presented on this list my most recent effort, plac. Now there is a *huge* new release: the size of plac and of its documentation doubled. Now plac is much more than a simple command-line arguments parser: it is also a generic tool to write command languages, similar to the cmd module in the standard library, only better. In particular plac supports a doctests-like functionality for each language you define for it, as well as a plac runner to run your scripts and tests. You define plac commands from Python functions: plac will build a parser from the function signature and interpret the command line accordingly. The documentation contains a lot of simple and not so simple examples: http://micheles.googlecode.com/hg/plac/doc/plac.html http://micheles.googlecode.com/hg/plac/doc/plac_ext.html Plac works in all versions of Python starting from Python 2.3 up to Python 3.1, but the new features require Python 2.5. You can download it from PyPI ($ easy_install -U plac): http://pypi.python.org/pypi/plac Enjoy! Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: plac 0.5 is out!
On Jun 20, 12:02 pm, Andre Alexander Bell p...@andre-bell.de wrote: How about adding some support for internationalization of the generated usage output? The usage message of plac is actually generated by the underlying argparse library. argparse use gettext internally, so I would say the support is already there. -- http://mail.python.org/mailman/listinfo/python-list
Re: plac 0.5 is out!
On Jun 20, 8:26 pm, Andre Alexander Bell p...@andre-bell.de wrote: On 06/20/2010 11:22 AM, Michele Simionato wrote: A few weeks ago I presented on this list my most recent effort, plac. http://micheles.googlecode.com/hg/plac/doc/plac_ext.html But this one is broken. :( Aagh! The good one is http://micheles.googlecode.com/hg/plac/doc/plac_adv.html. Luckily the one I posted on PyPI is correct. snip Maybe one could even extend to subcommands and so on. Maybe this is already possible but just not covered by the first link I've read by now. Indeed this is already possible and covered in the advanced document. See the section containers of commands: http://micheles.googlecode.com/hg/plac/doc/plac_adv.html#containers-of-commands -- http://mail.python.org/mailman/listinfo/python-list
Re: Overriding __setattr__ of a module - possible?
On Jun 16, 7:25 am, John Nagle na...@animats.com wrote: OK, working on this. I can make a module make itself into a fake class, but can't yet do it to other modules from outside. John Nagle I think you can with something like import module sys.modules[module.__name__] = FakeModule(vars(module)) -- http://mail.python.org/mailman/listinfo/python-list
Re: Overriding __setattr__ of a module - possible?
On Jun 16, 4:43 am, John Nagle na...@animats.com wrote: Is it possible to override __setattr__ of a module? I want to capture changes to global variables for debug purposes. None of the following seem to have any effect. modu.__setattr__ = myfn setattr(modu, __setattr__, myfn) delattr(modu, __setattr__) John Nagle There is a dirty trick which involves fiddling with sys.modules. For instance: $ cat x.py import sys class FakeModule(object): def __init__(self, dic): vars(self).update(dic) def __setattr__(self, name, value): print setting %s=%s % (name, value) object.__setattr__(self, name, value) a = 1 def f(): print 'called f' sys.modules[__name__] = FakeModule(globals()) Here is an ipython session: In [1]: import x In [2]: x.a Out[2]: 1 In [3]: x.f Out[3]: function f at 0x93f5614 In [4]: x.f() called f In [5]: x.a=2 setting a=2 In [6]: x.a Out[6]: 2 -- http://mail.python.org/mailman/listinfo/python-list
Re: optparse: best way
On Jun 8, 10:38 am, hiral hiralsmaill...@gmail.com wrote:
Hi,
I am using optparser to do following...
Command syntax:
myscript -o[exension] other_arguments
where; extension can be 'exe', 'txt', 'pdf', 'ppt' etc.
Now to parse this, I am doing following...
parser.add_option(-oexe', dest=exe_file...)
parser.add_option(-otxt', dest=txt_file...)
parser.add_option(-opdf', dest=pdf_file...)
parser.add_option(-oppt', dest=ppt_file...)
The above way is the most simple way to parser options.
Can you please suggest any other best way / optimized way to parse
these kind of options.
Thank you in advance.
Use plac: http://pypi.python.org/pypi/plac
Here is an example:
import plac
EXTENSIONS = ('exe', 'txt', 'pdf', 'ppt')
@plac.annotations(
ext=('a valid extension', 'option', 'o', None, EXTENSIONS))
def main(ext, *args):
Do something
if __name__ == '__main__':
plac.call(main)
$ python myscript.py -h
usage: myscript.py [-h] [-o {exe,txt,pdf,ppt}] [args [args ...]]
Do something
positional arguments:
args
optional arguments:
-h, --helpshow this help message and exit
-o, --ext {exe,txt,pdf,ppt}
a valid extension
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python Forum
On Jun 3, 12:28 pm, Martin P. Hellwig martin.hell...@dcuktec.org wrote: On the other hand it might not be so bad that you don't get questions from users here who are unable to use a nntp reader or news to mail service. I am unable to use a nntp reader or news to mail service. I use the Google Groups interface and I am happy with it. -- http://mail.python.org/mailman/listinfo/python-list
Re: plac, the easiest command line arguments parser in the world
On Jun 2, 6:37 am, Michele Simionato michele.simion...@gmail.com wrote: I would like to announce to the world the first public release of plac: http://pypi.python.org/pypi/plac The second release is out. I have added the recognition of keyword arguments, improved the formatting of the help message, and added many tests. -- http://mail.python.org/mailman/listinfo/python-list
Re: plac, the easiest command line arguments parser in the world
On Jun 2, 10:43 am, Paul Rubin no.em...@nospam.invalid wrote: Tim Golden m...@timgolden.me.uk writes: pattern, which provides a minimally semi-self-documenting approach for positional args, but I've always found the existing offerings just a little too much work to bother with. I'll give plac a run and see how it behaves. After using optparse a couple of times I got the hang of it. Maybe its docs could be organized a bit better, but it does the obvious things conveniently once you've figured it out a bit. Notice that optparse is basically useless in the use case Tim is considering (positional arguments) since it only manages options. -- http://mail.python.org/mailman/listinfo/python-list
Re: plac, the easiest command line arguments parser in the world
On Jun 2, 11:01 am, Stefan Behnel stefan...@behnel.de wrote: I managed to talk a Java-drilled collegue of mine into writing a Python script for a little command line utility, but he needed a way to organise his argument extraction code when the number of arguments started to grow beyond two. I told him that there were two ways to do it: do it by hand or do it right. He took the right choice and I took him to the optparse docs, copied the first example into his code and we adapted it a little. He just loved the beauty of it. Could you show plac to your friend? I would be curious to know what he think. Perhaps he would call out his judgment on optparse ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: functools.wraps and help()
On Jun 2, 2:20 pm, Ulrich Eckhardt eckha...@satorlaser.com wrote: Hi! When I use help() on a function, it displays the arguments of the function, along with the docstring. However, when wrapping the function using functools.wraps it only displays the arguments that the (internal) wrapper function takes, which is typically *args, **kwargs, which isn't very useful. Any suggestions how to fix that? Is that even a bug or a systematic limitation? In case of the latter, should the documentation for functools.wraps mention it? See http://pypi.python.org/pypi/decorator -- http://mail.python.org/mailman/listinfo/python-list
Re: plac, the easiest command line arguments parser in the world
On Jun 2, 6:37 am, Michele Simionato michele.simion...@gmail.com wrote: With blatant immodesty, plac claims to be the easiest to use command line arguments parser module in the Python world It seems I have to take that claim back. A few hours after the announce I was pointed out to http://pypi.python.org/pypi/CLIArgs which, I must concede, is even easier to use than plac. It seems everybody has written its own command line arguments parser! -- http://mail.python.org/mailman/listinfo/python-list
plac, the easiest command line arguments parser in the world
I would like to announce to the world the first public release of
plac:
http://pypi.python.org/pypi/plac
Plac is a wrapper over argparse and works in all versions of
Python starting from Python 2.3 up to Python 3.1.
With blatant immodesty, plac claims to be the easiest to use command
line arguments parser module in the Python world. Its goal is to
reduce the
learning curve of argparse from hours to minutes. It does so by
removing the need to build a command line arguments parser by hand:
actually it is smart enough to infer the parser from function
annotations.
Here is a simple example (in Python 3) to wet your appetite:
$ cat example.py
def main(arg: required argument):
do something with arg
print('Got %s' % arg)
if __name__ == '__main__':
import plac; plac.call(main) # passes sys.argv[1:] to main
$ python example.py -h
usage: example.py [-h] arg
do something with arg
positional arguments:
arg required argument
optional arguments:
-h, --help show this help message and exit
$ python example.py
usage: example.py [-h] arg
example.py: error: too few arguments
$ python example.py arg
Got arg
$ python example.py arg1 arg2
usage: example.py [-h] arg
example.py: error: unrecognized arguments: arg2
You can find in the documentation a lot of other simple and not so
simple
examples:
http://micheles.googlecode.com/hg/plac/doc/plac.html
Enjoy!
Michele Simionato
P.S. answering an unspoken question: yes, we really needed yet
another
command line arguments parser! ;)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Generator expressions vs. comprehensions
On May 25, 9:08 am, Peter Otten __pete...@web.de wrote: But the list comprehension is already non-equivalent to the for loop as the loop variable isn't leaked anymore. We do have three similar constructs with subtle differences. I think not turning the list-comp into syntactic sugar for list(genexp) in py3 is a missed opportunity. Actually I do agree with the feeling, and this is not the only missed opportunity in Python 3 :-/ -- http://mail.python.org/mailman/listinfo/python-list
Re: asyncore loop and cmdloop problem
On May 25, 10:42 am, kak...@gmail.com kak...@gmail.com wrote:
Hi to all,
i'm creating a command line application using asyncore and cmd. At
if __name__ == '__main__':
import socket
args = sys.argv[1:]
if not args:
print Usage: %s querystring % sys.argv[0]
sys.exit(0)
address = ('localhost', 0) # let the kernel give us a port
server = EchoServer(address)
ip, port = server.address # find out what port we were given
asyncore.loop()
CmdClass().cmdloop()
what i want is that the above commands asyncore.loop() and
CmdClass().cmdloop()
running at the same time. Meaning that while the application is in cmd
mode
with the cmdloop(), it is still able to listen for incoming messages?
What should i do?
thanks in advance
A.K.
cmd.Cmd is blocking, so the only way it to run the cmdloop in a
separated thread. Once for fun
I rewrote the cmd module to be non-blocking but if you want to stick
with the standard library you need to use a thread.
--
http://mail.python.org/mailman/listinfo/python-list
Re: asyncore loop and cmdloop problem
On May 25, 12:03 pm, Giampaolo Rodolà g.rod...@gmail.com wrote: Too bad cmdloop() doesn't provide an argument to return immediately. Why don't you submit this patch on the bug tracker? --- Giampaolohttp://code.google.com/p/pyftpdlibhttp://code.google.com/p/psutil Because it is not a bug, cmd was designed to be blocking. It would be a feature request. I wrote a cmd2 module a few years ago, which was intended as a replacement for cmd with various additional features (including the non blocking behavior). We are using it in production, but I have never published it (I intended to but, you know, a days has only 24 hours ;) I should put together the code in a single file and publish it, but I cannot guarantee if and when I will have the time to do so. -- http://mail.python.org/mailman/listinfo/python-list
Re: asyncore loop and cmdloop problem
On May 25, 2:56 pm, kak...@gmail.com kak...@gmail.com wrote: Could you please provide me with a simple example how to do this with threads. I don't know where to put the cmdloop(). Please help, i' m so confused! Thank you What are you trying to do? Do you really need to use the standard library? Likely what you want to accomplish is already implemented in Twisted; I remember there was something like that in their examples directory. -- http://mail.python.org/mailman/listinfo/python-list
Re: Generator expressions vs. comprehensions
On May 25, 12:47 am, Carl Banks pavlovevide...@gmail.com wrote: The situation here is known. It can't be corrected, even in Python 3, without modifying iterator protocol to tie StopIteration to a specific iterator. This is possible and might be worth it to avoid hard-to- diagnose bugs but it would complicate iterator protocol, which becomes less useful as it becomes more complex. The situation here is a known and could be corrected by changing the meaning of list comprehension, for instance by having [x for x in iterable] to be an alias for list(x for x in iterable). In such a way the StopIteration exception would be always swallowed and there would be consistency with generator expressions (by construction). However, the list comprehension would become non-equivalent to the corresponding for-loop with an .append, so somebody would be un happy anyway :-/ -- http://mail.python.org/mailman/listinfo/python-list
Re: help with the Python 3 version of the decorator module
On May 22, 10:49 am, Michele Simionato michele.simion...@gmail.com wrote: I have finally decided to port the decorator module to Python 3. Changing the module was zero effort (2to3 worked) but changing the documentation was quite an effort, since I had to wait for docutils/ pygements to support Python 3 and to change all my custom build process. Also, I am relying on distribute for installing on Python 3. I would welcome feedback for people using Python 3 on various platforms (including Windows) to see if they can install the module and how much of effort it is. Here is the tarball:http://micheles.googlecode.com/files/decorator-3.2beta.tar.gz Here is the documentation:http://micheles.googlecode.com/hg/decorator/index.html The installation process should work for Python 2.4, 2.5, 2.6, 2.7, 3.0, 3.1 and all platforms were Python runs, but I have only tested it on Linux for Python 2.6 and 3.1. The module has no relevant changes, so I expect problems only from the building process, if any. I am not sure of what will happen if you do not have distribute or if you have a previous version of the module, or if you use pip or something else (even in Python 2.X). The packaging in Python has become a real mess! TIA for you help, Michele Simionato decorator-3.2.0 has been released on PyPI: http://pypi.python.org/pypi/decorator -- http://mail.python.org/mailman/listinfo/python-list
help with the Python 3 version of the decorator module
I have finally decided to port the decorator module to Python 3. Changing the module was zero effort (2to3 worked) but changing the documentation was quite an effort, since I had to wait for docutils/ pygements to support Python 3 and to change all my custom build process. Also, I am relying on distribute for installing on Python 3. I would welcome feedback for people using Python 3 on various platforms (including Windows) to see if they can install the module and how much of effort it is. Here is the tarball: http://micheles.googlecode.com/files/decorator-3.2beta.tar.gz Here is the documentation: http://micheles.googlecode.com/hg/decorator/index.html The installation process should work for Python 2.4, 2.5, 2.6, 2.7, 3.0, 3.1 and all platforms were Python runs, but I have only tested it on Linux for Python 2.6 and 3.1. The module has no relevant changes, so I expect problems only from the building process, if any. I am not sure of what will happen if you do not have distribute or if you have a previous version of the module, or if you use pip or something else (even in Python 2.X). The packaging in Python has become a real mess! TIA for you help, Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Another Go is Python-like article.
On May 21, 4:20 pm, Grant Edwards inva...@invalid.invalid wrote: What about Go, exactly, do people see as Python-like? The philosophy of keeping things simple. I find the concurrency mechanism quite Pythonic. Moreover Go interfaces are quite akin to Python duck typing, but better. There also things which are quite different from Python e.g. the attitude towards exceptions. In theory Go should be akin to C, but my gut feeling is that in practice programming in it should not feel too much different from programming in Python (but I do not have first hand experience). Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python a functional programming language?
On May 10, 8:18 pm, a...@pythoncraft.com (Aahz) wrote: saying that functional features are tacked on understates the case. Consider how frequently people reach for list comps and gen exps. Function dispatch through dicts is the standard replacement for a switch statement. Lambda callbacks are common. Etc, etc, etc Just to play devil's advocate, I will notice that list comps and gen exps are not really functional (a generator has a state that changes at each call of next). A functional language would use streams instead. Function dispatch through dicts is very lame compared to pattern matching. Lambdas are restricted. There is no tail call optimization. Definitively Python functional features are tacked on with respect to a language defined to be functional. Having said that, the functional features are still usable and one can use a functional style in Python if she wants to (module a few caveats). -- http://mail.python.org/mailman/listinfo/python-list
Re: Iterating over dict and removing some elements
Or you copy the whole dictionary or you just copy the keys: for k in d.keys(): ... or for k in list(d): ... -- http://mail.python.org/mailman/listinfo/python-list
Re: Sphinx hosting
On May 5, 8:00 am, James Mills prolo...@shortcircuit.net.au wrote: On Wed, May 5, 2010 at 3:35 PM, Michele Simionato michele.simion...@gmail.com wrote: I am sure it has, but I was talking about just putting in the repository an index.html file and have it published, the wayI hear it works in BitBucket and GitHub. I'm pretty sure Google Code Hosting doesn't support rendering text/html mime-type files in the repository (like Trac can). At the end I discovered that if you put HTML files into a Googlecode repository and you click on display raw file it just works (TM). So my problem was already solved and I my worries were unjustified. I have just committed my talk at the Italian PyCon and all the stylesheets are recognized just fine: http://micheles.googlecode.com/hg/pypers/pycon10/talk.html -- http://mail.python.org/mailman/listinfo/python-list
Sphinx hosting
Say you have a project with a lot of documentation in the form of Sphinx pages (for instance a book project). What is the the easiest way to publish it on the Web? I see that GitHub Pages allows you to publish static pages, but I would need to check in both the .rst sources and the .html output: it is not that annoying, but perhaps there is already some services out there publishing Sphinx pages directly. Do you know of any? Currently I am hosting my stuff on Google Code but I do not see an easy way to publish the documentation there. Any hint is appreciated. Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Sphinx hosting
On May 4, 8:07 am, Martin v. Loewis mar...@v.loewis.de wrote: If it's a Python package that this documentation is about, you can host it on PyPI. It must not be Python, but let's consider this case first. How does it work? When I published my decorator module (http://pypi.python.org/pypi/decorator) the support was not very good. At the end I decided to put the generated .html inside the long_description field instead of the .rst source to get the look and feel I wanted. Moreover the long_description hack works for a single page documentation, but I am talking here of a book-sized document with many pages and hyperlinks. Do you know of recent improvements on the PyPI side about docs hosting? The CheeseShopTutorial http://wiki.python.org/moin/CheeseShopTutorial seems to give the same info of the last time I checked. -- http://mail.python.org/mailman/listinfo/python-list
Re: Sphinx hosting
On May 4, 8:37 am, Martin v. Loewis mar...@v.loewis.de wrote: Do you know of recent improvements on the PyPI side about docs hosting? Yes; go to your package's pkg_edit page, i.e. http://pypi.python.org/pypi?%3Aaction=pkg_editname=decorator and provide a zip file at Upload Documentation. Regards, Martin Cool, that's good to know. I am still accepting recommendations for non-Python projects ;) -- http://mail.python.org/mailman/listinfo/python-list
