Giampaolo Rodola' added the comment:
Looking back at this: a warning seems a bit too invasive to me as there are
cases where avoiding to override a certain methods are legitimate.
I will just close this out as won't fix, also because asyncore has been
deprecated by asyncio.
--
Changes by Terry J. Reedy tjre...@udel.edu:
--
versions: -Python 2.5, Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11792
___
___
Éric Araujo mer...@netwok.org added the comment:
Some guidance on print vs. warnings vs. logging on
http://docs.python.org/dev/howto/logging#when-to-use-logging
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
New submission from Samuele Kaplun samuele.kap...@cern.ch:
The method log_info of the dispatcher class of the asyncore.py module, uses
print statement to print to stdout.
This lead to conflicts when asyncore is used within e.g. mod_wsgi, as writing
to stdout is not supposed to be valid.
Changes by Antoine Pitrou pit...@free.fr:
--
assignee: - giampaolo.rodola
nosy: +giampaolo.rodola
stage: - needs patch
versions: +Python 3.2, Python 3.3 -Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11792
Giampaolo Rodola' g.rod...@gmail.com added the comment:
What change are you proposing exactly?
Btw, overriding log_info() in such cases seems reasonable to me, without
changing anything in asyncore.
--
___
Python tracker rep...@bugs.python.org
Samuele Kaplun samuele.kap...@cern.ch added the comment:
Thanks for looking into it.
Indeed that's the workaround I implemented in our application. On the other
hand it would be nice if either:
* the log_info method would print to stderr,
* would use warning.warn()
* would use the logging
Giampaolo Rodola' g.rod...@gmail.com added the comment:
asyncore is a minimalistic and generic framework; as such it should not
privilege a specific application such as mod_wsgi or make any other
assumption.
I'd say it's fine to let user decide what to do in its own subclass.
Furthermore,
Samuele Kaplun samuele.kap...@cern.ch added the comment:
Hi Giampaolo,
shouldn't then the 2nd option I was proposing (i.e. to call warning.warn) the
best behavior, given your explanation?
[...]
Warning messages are typically issued in situations where it is useful to alert
the user of some
