Re: SMTPHandler and Unicode
Hi Norbert,
On 05/07/2010 13:22, norbert wrote:
On 5 juil, 13:17, Chris Withers wrote:
try MailingLogger:
If you have unicode problems with that, I'd be interested in fixing them!
Your package has the same unicode problem :
import logging,logging.handlers
from mailinglogger.MailingLogger import MailingLogger
mailingLogger = MailingLogger(mailhost=('smtp.example.com',
25),fromaddr='t...@example.com',toaddrs=('t...@example.com',))
LOG = logging.getLogger()
LOG.addHandler(mailingLogger)
LOG.error(u"sans accent")
LOG.error(u"accentu\u00E9")
--> UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9'
in position 7: ordinal not in range(128)
It's taken a ridiculously long amount of time (sadly due to no-one else
complaining) but this is now fixed in the source control for
mailinglogger, and will be in the next release:
https://github.com/Simplistix/testfixtures
cheers,
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
--
http://mail.python.org/mailman/listinfo/python-list
Re: understanding a program project
On Jan 14, 9:29 am, Tracubik wrote: > Hi all, > i hope not to be too much OT with this request. > I'ld like to modify/contribute some open source in python, but first i've > to read and understand the code. > So, is there some guide lines / procedure to follow to help me in this > process. > I remember at school time there was some schema or something to create to > display the interaction of different functions / modules > > My idea was to create a model with all the methods and arrows to link > they... > > any link of post explaining some "learning procedure" or "programs > schema" would be really appreciated > I don't know of a general answer to your question. I've seen tools such as you're describing but they tend to be languages other than Python (eg Java or C#). There are tools such as : * Sphinx * EpyDoc * pycco all of which will produce friendly documentation automatically but the quality of the doco is dependent somewhat upon the amount and nature of comments originally put into the code. I don't think that's much help but I hope it may be some. regards Richard. -- http://mail.python.org/mailman/listinfo/python-list
Re: SMTPHandler and Unicode
On 13/01/2012 20:17, Chris Withers wrote:
Your package has the same unicode problem :
import logging,logging.handlers
from mailinglogger.MailingLogger import MailingLogger
mailingLogger = MailingLogger(mailhost=('smtp.example.com',
25),fromaddr='t...@example.com',toaddrs=('t...@example.com',))
LOG = logging.getLogger()
LOG.addHandler(mailingLogger)
LOG.error(u"sans accent")
LOG.error(u"accentu\u00E9")
--> UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9'
in position 7: ordinal not in range(128)
It's taken a ridiculously long amount of time (sadly due to no-one else
complaining) but this is now fixed in the source control for
mailinglogger, and will be in the next release:
https://github.com/Simplistix/testfixtures
Sorry, I meant this:
https://github.com/Simplistix/mailinglogger/commit/1c95f532c65ab18e1dd8513e1aa1ae328a19d249
cheers,
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
--
http://mail.python.org/mailman/listinfo/python-list
Re: logging and httphandler
Jason Friedman wrote:
> I am logging to my Apache web server, using this Apache format:
>
> LogFormat "%{%Y-%m-%d %H:%M:%S}t %U %q" scriptlog
> CustomLog /var/log/apache2/script.log scriptlog
>
> My code is as follows:
>
> #!/usr/bin/env python3
> import logging, logging.handlers, sys
> logger = logging.getLogger('simple_example')
> logger.setLevel(logging.DEBUG)
> host = "localhost:9090"
> url = "make_deployment_group"
> http_handler = logging.handlers.HTTPHandler(host, url, method='GET')
> http_formatter = logging.Formatter('%(name)s - %(levelname)8s -
> %(message)s') http_handler.setFormatter(http_formatter)
> logger.addHandler(http_handler)
> logger.warn('warn message')
>
> which results in a entry at /var/log/apache2/script.log:
>
> 2012-01-14 05:22:52
>
make_deployment_group?threadName=MainThread&name=simple_example&thread=139923654465280&created=1326518572.83&process=31122&processName=MainProcess&args=%28%29&module=my-
logging&filename=my-logging.py&levelno=30&exc_text=None&pathname=my-
logging.py&lineno=33&asctime=2012-01-14+05%3A22%3A52%2C825&msg=warn+message&exc_info=None&message=warn+message&funcName=%3Cmodule%3E&relativeCreated=20.0970172882&levelname=WARNING&msecs=825.411081314
>
> All the information one could want, which is nice, but is there a way
> to specify I want only certain information sent via the HTTP request?
>>> help(logging.handlers.HTTPHandler.mapLogRecord)
Help on function mapLogRecord in module logging.handlers:
mapLogRecord(self, record)
Default implementation of mapping the log record into a dict
that is sent as the CGI data. Overwrite in your class.
Contributed by Franz Glasner.
Applied to your example:
import logging, logging.handlers, sys
class HTTPHandler(logging.handlers.HTTPHandler):
wanted = ["levelname", "msg", "yadda"]
def mapLogRecord(self, record):
return {name: getattr(record, name, "#missing") for name in self.wanted}
logger = logging.getLogger('simple_example')
logger.setLevel(logging.DEBUG)
host = "localhost:9090"
url = "make_deployment_group"
http_handler = HTTPHandler(host, url, method='GET')
http_formatter = logging.Formatter('%(name)s - %(levelname)8s - %(message)s')
http_handler.setFormatter(http_formatter)
logger.addHandler(http_handler)
logger.warn('warn message')
--
http://mail.python.org/mailman/listinfo/python-list
Re: Hash stability
Steven D'Aprano wrote: > On the Python Dev mailing list, there is a discussion going on about the > stability of the hash function for strings. > > How many people rely on hash(some_string) being stable across Python > versions? Does anyone have code that will be broken if the string hashing > algorithm changes? Nobody who understands the question ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: ERROR:root:code for hash md5 was not found
Steven D'Aprano wrote:
> On Fri, 13 Jan 2012 06:14:50 -0800, mike wrote:
>> pysibelius is a lib that we use.
>>
>> I am not sure that is the problem since the python program works on SuSE
>> but not on RH server. And AFAIK
>> the only difference ( well that I can see) is the OpenSSL version.
>
> OpenSSL is irrelevant. If it isn't available, or doesn't provide md5,
> then the hashlib library will use its own implementation. But the _md5
> module is missing in the pysibelius Python on your RedHat system.
>
> As I said, your Python installation is seriously broken. Required modules
> are just *gone*.
>
> pysibelius appears to have patched Python in some way, because strange
> unexpected error messages are being printed that do not happen on a
> normal unpatched Python, e.g.:
>
> ERROR:root:code for hash sha224 was not found.
>
> That is not a normal Python error message. That looks like something
> added by pysibelius.
Steven, I think you're wrong with regard to the error message.
Straight from the tarball, Python-2.7.2/Lib/hashlib.py line 135ff:
for __func_name in __always_supported:
# try them all, some may not work due to the OpenSSL
# version not supporting that algorithm.
try:
globals()[__func_name] = __get_hash(__func_name)
except ValueError:
import logging
logging.exception('code for hash %s was not found.', __func_name)
Of course this does not invalidate the fact (is that even possible?) of
the brokenness of the installation.
Ciao
Marc
--
http://mail.python.org/mailman/listinfo/python-list
Re: Zealotry [was Re: how to install lxml in window xp?]
On Sat, Jan 14, 2012 at 2:39 AM, Terry Reedy wrote: > On 1/13/2012 3:42 PM, Noah Hall wrote: >> >> On Fri, Jan 13, 2012 at 8:07 PM, Tamer Higazi >> wrote: >>> >>> dear people! >>> I have just opened my MTU client, and figured out that through my >>> comment, i caused a complete NONSENSE discussion at all. > > >>> 1. I am not a zealot or whatever. I code on Linux and port it on MAC and >>> WINDOWS. I do write solutions for customers across the whole 3 platform, >>> and mostly I succeed because I have to figure out in advance which >>> software (packages) are being supported and how far. > > >>> Use Linux! >>> Specially Gentoo Linux! >> >> >> Screams zealot to me. If not, certainly not a very useful reply. > > > Noah, those last two lines you quoted are NOT in the post you are quoting. > Perhaps Tamer said them previously. If so, you should say so: "In a previous > post, you said...". Otherwise, it looks like you made those up and put words > in his pen. Good point. In a previous post, that started all this, he said > Use Linux! > Specially Gentoo Linux! when replying to someone who asked > how can i install the lxml in my xp?? -- http://mail.python.org/mailman/listinfo/python-list
scientific notation in legend (pylab)
Hi, I I would like to have numbers expressed in scientific notation in legend annotations. Does anybody know how to do that? Cheers, S. -- http://mail.python.org/mailman/listinfo/python-list
Can someone explain 2to3?
Ok i'm trying to convert https://github.com/rdeaton/spyral to python3 but i'm at a loss on how to actually use 2to3. Can someone explain it's proper use to me so i can do the conversion? prefereably where i can take "C:\Python32\Lib\site-packages\spyral\" and put it in a new directory that i will name "C:\Python32\Lib\site-packages\spyralpy3\"? Thanks in advance for the help -- ~ Josh Miller A young guy learning to program and develop websites all while still in school -- http://mail.python.org/mailman/listinfo/python-list
Re: Can someone explain 2to3?
On Sat, Jan 14, 2012 at 5:06 PM, Joshua Miller wrote: > Ok i'm trying to convert https://github.com/rdeaton/spyral to python3 > but i'm at a loss on how to actually use 2to3. Can someone explain > it's proper use to me so i can do the conversion? prefereably where i > can take "C:\Python32\Lib\site-packages\spyral\" and put it in a new > directory that i will name "C:\Python32\Lib\site-packages\spyralpy3\"? > Thanks in advance for the help Have a read of the docs[0]. 2to3 will convert it to 3, but it may need more fixes to run as well. [0] - http://docs.python.org/library/2to3.html -- http://mail.python.org/mailman/listinfo/python-list
Re: open office in another language?
Enjoy this relevant article: http://developers.slashdot.org/story/12/01/14/008236/code-cleanup-culls-libreoffice-cruft Dotan Cohen http://what-is-what.com/what_is/open_office.html -- http://mail.python.org/mailman/listinfo/python-list
PyWarts: time, datetime, and calendar modules
The interface for these modules is not intuitive. Instead of creating true OOP objects we have lists and strings. Any calendar object should expose string names of both: days of the week and months of the year. It seems one (or possibly more) of the three expose this important info however i cannot find it *easily* enough. It seems we need to combine the three in some shape or form. time and datetime would no doubt be great bedfellows. Or maybe datetime should be attached to time, like os.path. In any event the interfaces are horrendous. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWarts: time, datetime, and calendar modules
On Sat, Jan 14, 2012 at 1:54 PM, Rick Johnson wrote: > The interface for these modules is not intuitive. Instead of creating > true OOP objects we have lists and strings. Any calendar object should > expose string names of both: days of the week and months of the year. > It seems one (or possibly more) of the three expose this important > info however i cannot find it *easily* enough. > > It seems we need to combine the three in some shape or form. time and > datetime would no doubt be great bedfellows. Or maybe datetime should > be attached to time, like os.path. In any event the interfaces are > horrendous. What's "horrendous" about the datetime module interface? Your listed complaints (OOP etc.) don't seem to have anything to do with it. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Can someone explain 2to3?
On Sat, Jan 14, 2012 at 7:08 PM, Joshua Miller wrote: > I've looked there and it didn't worki may've made all the nesscary > changes manually anyways though i'm not sure... What about it didn't work? Have a read of this too - http://wiki.python.org/moin/PortingPythonToPy3k and if you're still stuck, contact the developer of the program in question. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWarts: time, datetime, and calendar modules
On Jan 14, 1:01 pm, Devin Jeanpierre wrote: > What's "horrendous" about the datetime module interface? Your listed > complaints (OOP etc.) don't seem to have anything to do with it. Well my immediate complaint about date-time is actually a problem with the syntactic quandaries of the Python language itself. I find myself navigating an objects API using the dir function or the autocomplete function of my IDE. Now. One the continuing issues of the Python's syntax (and the syntax of many other languages) is the fact that a reader has no idea which names belonging to an object are methods and which names are instance/class variables. The status quo has been to use verbs for methods but you cannot always find the perfect verb, or even sometimes, anyverb! Consider this: >>> import datetime, time, calendar >>> d = datetime.date.today() >>> d.day 14 >>> d.month 1 >>> d.year 2012 >>> d.weekday THAT PISSES ME OFF!!! >:( We should never be forced to guess if a name is a callable or a variable! So how do we solve this dilemma you ask??? Well, we need to "mark" method OR variable names (OR both!) with syntactic markers so there will be NO confusion. Observe: def $method(self):pass self.@instanceveriable self.@@classvariable I dunno if these are the best markers but the "marker" must be succinct! Of course if we choose to use the "@" and "@@" then we might as well drop the redundant "self" and allow the compiler to parse out the difference. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWarts: time, datetime, and calendar modules
On Sat, Jan 14, 2012 at 2:23 PM, Rick Johnson wrote: > THAT PISSES ME OFF!!! >:( We should never be forced to guess if a name > is a callable or a variable! > > So how do we solve this dilemma you ask??? Well, we need to "mark" > method OR variable names (OR both!) with syntactic markers so there > will be NO confusion. I might be being bit OT, but, you should give Common Lisp a try. It does something similar for functions versus variables. As for the issue, I suppose I can see how this would be confusing. I don't agree with your solution, though. I happen to like the interchangeability of the different sorts of attributes, so that x.foo() can be a method call, a classmethod call, or a call on a function that is an attribute. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
defining class and subclass in C
Hi all.
I spent some days and nights on this already and my google-fu is running out.
I'd like to implement the equivalent of this Python code in a C-extension:
>>> class A(object):
... pass
>>> class B(A):
... pass
>>> A
>>> B
>>> B.__bases__
(,)
However, loading my C-code (quoted below) I get:
>>> import ca
>>> ca
>>> ca.ca
Here I'd expect "" instead?! And I never managed a proper
subclass :|
The point of the excercise: with "ca" and "cb" properly implemented, I'd like
to subclass "cb" not from "ca", but from the Python "class A" - if possible?!
Could somepne kindly point out my mistake(s) and set me back on track?
Thanks
Daniel
--
#include
typedef struct {
PyObject_HEAD
} ca;
static PyTypeObject ca_Type = {
PyObject_HEAD_INIT(NULL)
};
PyMODINIT_FUNC initca(void) {
PyObject *ca;
ca_Type.tp_name = "ca.ca";
ca_Type.tp_basicsize = sizeof(ca);
ca_Type.tp_flags = Py_TPFLAGS_DEFAULT | Py_TPFLAGS_BASETYPE;
if (PyType_Ready(&ca_Type) < 0)
return;
ca = Py_InitModule3("ca", NULL, "ca module");
if (ca == NULL)
return;
Py_INCREF(&ca_Type);
PyModule_AddObject(ca, "ca", (PyObject*)&ca_Type);
}
$ gcc -Wall -Wextra -g -fPIC -I/usr/include/python2.7 ca.c \
-shared -Wl,-soname,ca.so -o ca.so -lpython2.7
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyWarts: time, datetime, and calendar modules
On Jan 14, 1:23 pm, Rick Johnson wrote: > def $method(self):pass > self.@instanceveriable > self.@@classvariable Actually, class level methods can be accessed through ClassIdentifier.method, and instance methods through instanceidentifier.instancemethod. So decorating methods becomes moot. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWarts: time, datetime, and calendar modules
On Sun, Jan 15, 2012 at 6:23 AM, Rick Johnson wrote: > Observe: > def $method(self):pass > self.@instanceveriable > self.@@classvariable Are you deliberately inverting what PHP does, with $variablename? (Incidentally, that's one of the things that irks me about PHP - adorned variable names.) In any case: Python does not distinguish between functions and other sorts of objects. It makes no sense to adorn things in this way. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWarts: time, datetime, and calendar modules
On 01/14/2012 02:11 PM, Devin Jeanpierre wrote: On Sat, Jan 14, 2012 at 2:23 PM, Rick Johnson wrote: THAT PISSES ME OFF!!!>:( We should never be forced to guess if a name is a callable or a variable! So how do we solve this dilemma you ask??? Well, we need to "mark" method OR variable names (OR both!) with syntactic markers so there will be NO confusion. I might be being bit OT, but, you should give Common Lisp a try. It does something similar for functions versus variables. As for the issue, I suppose I can see how this would be confusing. I don't agree with your solution, though. It also has some problems. For instance, if an object has a member which is a type that implements __call__ but is also useful to access "on its own", is that a field or a function? Personally, I'd suggest the thing to "fix" to solve your confusion would be how things like your code completion and dir() display the results, not anything fundamental about the language. (And also the datetime API.) PyDev, for instance, tries to show you what "kind" of thing each entry in its completion menu are. Evan -- http://mail.python.org/mailman/listinfo/python-list
Re: Hash stability
Am 14.01.2012 10:46, schrieb Peter Otten: Steven D'Aprano wrote: How many people rely on hash(some_string) being stable across Python versions? Does anyone have code that will be broken if the string hashing algorithm changes? Nobody who understands the question ;) Erm, not exactly true. There are actually some packages out there (take suds [https://fedorahosted.org/suds/], for example) that rely on the hashing algorithm to be stable to function "properly" (suds uses hash() of strings to create caches of objects/XML Schemas on the filesystem). This, in a different context, bit me at the end of last week, when required to use suds to access EWS. I'd personally start debating the sensibility of this decision on the part of the suds developers, but... That's not the question. ;-) -- --- Heiko. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWarts: time, datetime, and calendar modules
On Jan 14, 2:58 pm, Evan Driscoll wrote: > On 01/14/2012 02:11 PM, Devin Jeanpierre wrote: > It also has some problems. For instance, if an object has a member which > is a type that implements __call__ but is also useful to access "on its > own", is that a field or a function? Can you site a real world example that would prove your point? > Personally, I'd suggest the thing to "fix" to solve your confusion would > be how things like your code completion and dir() display the results, I must admit this would be the low cost solution, although, i have always been irked by the obfuscation of programming language syntax. I don't need the manual anymore. I just need some introspection tools. HOWEVER, even the best introspection tools in the world cannot make up for obfuscation. Consider the case of the obfuscation of sex by certain "gender neutral" names. males and females frequent usenet and forums around the net, and in most cases we know that a "Tom", "Dick", and "Harry" are going be males, and that "June", "April", and "May" are going to be females. But what about "August", "Jamie", "Payton", or "Parker"? ...and don't forget about that boy named Sue! In face to face communication we will know (most times) who is male, who is female, and who is other. But when all we have to go by is a simple name, well, that name MUST be descriptive. It must carry some hint as to sex. "Hello Mr, urrr Mrs., urrr Payton" EGG ON FACE! Same in programming. We need syntactical clues. When we are removed from the visual, and have no proper syntactic clues, we are then forced to guess! -- and nobody wants to be accused of being the opposite sex! -- http://mail.python.org/mailman/listinfo/python-list
Re: defining class and subclass in C
On Saturday 14 January 2012 22:15:36 Daniel Franke wrote:
> Here I'd expect "" instead?! And I never managed a proper
> subclass :|
Found an explanation on type/class at [1]: "he difference between the two is
whether the C-level type instance structure is flagged as having been
allocated on the heap or not" - hu?
With this info, I went ahead and tried the code quoted below. Now I get:
>>> import cmod
>>> cmod.ca
>>> cmod.cb
>>> cmod.ca.__bases__
(,)
>>> cmod.cb.__bases__
(,)
which seems to make sense besides the "type" instead of "class"?!
What threw me is that I expected that I'd need to explicitly subclass the
"object" type, from which I assumed for some reason I'd also inherit the
.tp_new member. This is obviously not the case.
Now the last question is, how do I get the a_type of Python class to use it as
base for "cb"?
On lives and learns.
Daniel
[1] http://utcc.utoronto.ca/~cks/space/blog/python/ClassesAndTypes
--
#include
typedef struct {
PyObject_HEAD
} ca;
static PyTypeObject ca_Type = {
PyObject_HEAD_INIT(NULL)
};
typedef struct {
PyObject_HEAD
} cb;
static PyTypeObject cb_Type = {
PyObject_HEAD_INIT(NULL)
};
PyMODINIT_FUNC initcmod(void) {
PyObject *cmod;
ca_Type.tp_name = "cmod.ca";
ca_Type.tp_basicsize = sizeof(ca);
ca_Type.tp_flags = Py_TPFLAGS_DEFAULT | Py_TPFLAGS_BASETYPE;
ca_Type.tp_new = PyType_GenericNew;
ca_Type.tp_base = &PyBaseObject_Type;
if (PyType_Ready(&ca_Type) < 0)
return;
cb_Type.tp_name = "cmod.cb";
cb_Type.tp_basicsize = sizeof(cb);
cb_Type.tp_flags = Py_TPFLAGS_DEFAULT | Py_TPFLAGS_BASETYPE;
cb_Type.tp_base = &ca_Type;
if (PyType_Ready(&cb_Type) < 0)
return;
cmod = Py_InitModule3("cmod", NULL, "c module");
if (cmod == NULL)
return;
Py_INCREF(&ca_Type);
PyModule_AddObject(cmod, "ca", (PyObject*)&ca_Type);
Py_INCREF(&cb_Type);
PyModule_AddObject(cmod, "cb", (PyObject*)&cb_Type);
}
--
http://mail.python.org/mailman/listinfo/python-list
Re: Hash stability
On Sat, Jan 14, 2012 at 3:42 PM, Steven D'Aprano wrote: > On the Python Dev mailing list, there is a discussion going on about the > stability of the hash function for strings. > > How many people rely on hash(some_string) being stable across Python > versions? Does anyone have code that will be broken if the string hashing > algorithm changes? On reading your post I immediately thought that you could, if changing algorithm, simultaneously fix the issue of malicious collisions, but that appears to be what you're doing it for primarily :) Suggestion: Create a subclass of dict, the SecureDict or something, which could either perturb the hashes or even use a proper cryptographic hash function; normal dictionaries can continue to use the current algorithm. The description in Objects/dictnotes.txt suggests that it's still well worth keeping the current system for programmer-controlled dictionaries, and only change user-controlled ones (such as POST data etc). It would then be up to the individual framework and module authors to make use of this, but it would not impose any cost on the myriad other uses of dictionaries - there's no point adding extra load to every name lookup just because of a security issue in an extremely narrow situation. It would also mean that code relying on hash(str) stability wouldn't be broken. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWarts: time, datetime, and calendar modules
On Sun, Jan 15, 2012 at 10:19 AM, Rick Johnson wrote: > On Jan 14, 2:58 pm, Evan Driscoll wrote: >> On 01/14/2012 02:11 PM, Devin Jeanpierre wrote: > >> It also has some problems. For instance, if an object has a member which >> is a type that implements __call__ but is also useful to access "on its >> own", is that a field or a function? > > Can you site a real world example that would prove your point? Not without breaking a non-disclosure agreement and copyright. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: defining class and subclass in C
Daniel Franke wrote:
>
>I'd like to implement the equivalent of this Python code in a C-extension:
>
class A(object):
>... pass
class B(A):
>... pass
A
>
B
>
B.__bases__
>(,)
>
>However, loading my C-code (quoted below) I get:
>
import ca
ca
>
ca.ca
>
>
>Here I'd expect "" instead?! And I never managed a proper
>subclass :|
Notice this in your code:
static PyTypeObject ca_Type = {
PyObject_HEAD_INIT(NULL)
};
You are creating a "type" object. It shouldn't be a surprise that it is
displayed as a , just like int and dict.
In a sweeping overgenerality, C modules define types and Python modules
define classes. You could redefine the __repr__ method to display "" if you want.
--
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Two questions about logging
On Jan 12, 8:03 pm, K Richard Pixley wrote:
> Here's the confusion. Each log named __name__ is under the root logger.
> If you want them all, then catch them all with the root logger.
Thanks! I knew I was missing something obvious. Between you and Jean-
Michael Pichavant I've figured out what I need to do here.
On Jan 11, 9:34 pm, Roy Smith wrote:
> What I would do is log to syslog (logging.handlers.SysLogHandler) and
> let syslog worry about rotating log files. Why reinvent the wheel?
I've also worked out what I need to reset file handles, although it
took a lot of reading in the various logging.Handler subclasses. What
I needed isn't explicitly documented anywhere, but it turns out that
calling the close() method on a FileHandler instance does what I
need. There's no method to re-open the handler, but the next call to
emit() will automatically re-open the file if it isn't already open.
The upshot is that this does the expected thing if you rename its log
file and then send the running script a HUP signal.
#!/usr/bin/env python
import logging
import signal
import time
logger = logging.getLogger()
lh = logging.FileHandler('./foo.log')
lh.setFormatter(logging.Formatter('%(asctime)s %(name)s: %(message)s',
'%T'))
logger.addHandler(lh)
def sighup(signum, frame):
lh.close()
logger.error("handled {0}: {1}".format(signum, frame))
def main():
signal.signal(signal.SIGHUP, sighup)
while 1:
time.sleep(1)
logger.error('a message')
if __name__ == '__main__':
main()
--
http://mail.python.org/mailman/listinfo/python-list
Re: Hash stability
In article <4f1107b7$0$29988$c3e8da3$54964...@news.astraweb.com>, Steven D'Aprano wrote: > On the Python Dev mailing list, there is a discussion going on about the > stability of the hash function for strings. > > How many people rely on hash(some_string) being stable across Python > versions? Does anyone have code that will be broken if the string hashing > algorithm changes? I would never rely on something like that unless the docs unambiguously stated it were so. Which they don't. All I can find about hash() is: "Return the hash value of the object (if it has one). Hash values are integers. They are used to quickly compare dictionary keys during a dictionary lookup. Numeric values that compare equal have the same hash value (even if they are of different types, as is the case for 1 and 1.0)." -- http://mail.python.org/mailman/listinfo/python-list
mechanize can't get address
here is my code
# -*- coding: gbk -*-
import mechanize
import cookielib
target="http://v.163.com/movie/2008/10/O/Q/M7F57SUCS_M7F5R3DOQ.html";
# Browser
br = mechanize.Browser()
# Cookie Jar
cj = cookielib.LWPCookieJar()
br.set_cookiejar(cj)
# Browser options
br.set_handle_equiv(True)
br.set_handle_gzip(True)
br.set_handle_redirect(True)
br.set_handle_referer(True)
#br.set_handle_robots(False)
# Follows refresh 0 but not hangs on refresh > 0
br.set_handle_refresh(mechanize._http.HTTPRefreshProcessor(), max_time=1)
# Want debugging messages?
#br.set_debug_http(True)
#br.set_debug_redirects(True)
#br.set_debug_responses(True)
# User-Agent (this is cheating, ok?)
br.addheaders = [('User-agent', 'Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.9.0.1) Gecko/2008071615 Fedora/3.0.1-1.fc9 Firefox/4.0.0')]
br.open(target)
web=br.response().read()
file=open('c:\\v','w')
file.write(web)
file.close()
why i can't get the address of movie??
--
http://mail.python.org/mailman/listinfo/python-list
Re: scientific notation in legend (pylab)
> I I would like to have numbers expressed in scientific notation in
> legend annotations. Does anybody know how to do that?
>
Not sure why legend annotations makes the problem different, but
perhaps this is a start:
$ python3
Python 3.2 (r32:88445, Jun 11 2011, 10:38:04)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print("{:e}".format(1000))
1.00e+03
http://docs.python.org/library/string.html
--
http://mail.python.org/mailman/listinfo/python-list
why i can get nothing?
here is my code :
import urllib
import lxml.html
down='http://download.v.163.com/dl/open/00DL0QDR0QDS0QHH.html'
file=urllib.urlopen(down).
read()
root=lxml.html.document_fromstring(file)
tnodes = root.xpath("//a/@href[contains(string(),'mp4')]")
for i,add in enumerate(tnodes):
print i,add
why i can get nothing?
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyWarts: time, datetime, and calendar modules
On Sat, 14 Jan 2012 10:54:57 -0800, Rick Johnson wrote: > The interface for these modules is not intuitive. Instead of creating > true OOP objects we have lists and strings. Lists and strings are true OOP objects. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Hash stability
On 1/14/2012 9:26 PM, Roy Smith wrote: Steven D'Aprano wrote: How many people rely on hash(some_string) being stable across Python versions? Does anyone have code that will be broken if the string hashing algorithm changes? I would never rely on something like that unless the docs unambiguously stated it were so. Which they don't. All I can find about hash() is: "Return the hash value of the object (if it has one). Based on the pydev discussion since, it appears that enough people have inferred stability either from that or empirical stability that it will not be broken, by default, in pre-3.3 releases. What ever option is chosen to guard against attacks will probably be the default in 3.3. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWarts: time, datetime, and calendar modules
On Sat, 14 Jan 2012 11:23:29 -0800, Rick Johnson wrote: > On Jan 14, 1:01 pm, Devin Jeanpierre wrote: > >> What's "horrendous" about the datetime module interface? Your listed >> complaints (OOP etc.) don't seem to have anything to do with it. > > Well my immediate complaint about date-time is actually a problem with > the syntactic quandaries of the Python language itself. > > I find myself navigating an objects API using the dir function or the > autocomplete function of my IDE. Now. One the continuing issues of the > Python's syntax (and the syntax of many other languages) is the fact > that a reader has no idea which names belonging to an object are methods > and which names are instance/class variables. This is not Java, and we prefer Python terminology. A variable holding an int is an int variable. A variable holding a string is a string variable. A variable holding a list is a list variable. A variable holding an instance is an instance variable. A variable holding a class is a class variable. Clarity of language is your friend. Perhaps you mean instance and class ATTRIBUTES, since dotted names are attributes, not variables. x # x is a variable x.y # y is an attribute of x Methods ARE attributes. You are asking for a distinction which does not exist. This is Python, not Java, and methods are attributes which happen to be callable. (Actually, to be technical they are attributes which use the descriptor protocol to return a callable.) In some other languages, methods (and functions and classes) are second-class entities created at compile time. In Python, they are first-class objects created at runtime like all other objects. Distinguishing methods from other attributes by syntax alone is ugly and artificial. > The status quo has been to > use verbs for methods but you cannot always find the perfect verb, or > even sometimes, anyverb! Consider this: > import datetime, time, calendar d = datetime.date.today() d.day > 14 d.month > 1 d.year > 2012 d.weekday > > > THAT PISSES ME OFF!!! >:( We should never be forced to guess if a name > is a callable or a variable! Guessing is for fourth-class programmers who don't know their language and are too lazy to RTFM. py> import datetime py> d = datetime.date.today() py> hasattr(d.weekday, '__call__') True help(d) is also your friend. > So how do we solve this dilemma you ask??? Well, we need to "mark" > method OR variable names (OR both!) with syntactic markers so there will > be NO confusion. No we don't. There is no dilemma. At worst, we might agree that the datetime API is old and tired, and that if descriptors existed back in Python 1.x then datetime.weekday could have been a computed property instead of a method, but alas we've lost the opportunity for this. Any changes to datetime need to be backward compatible. If you want to actually do something useful, instead of just big-noting yourself and trolling about how bad Python is because it doesn't work like the language you have in your head, I suggest you write a datetime wrapper class and offer it to the community via PyPI. If it is good, and becomes popular, then in Python 3.4 or 3.5 it may become part of the standard library. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWarts: time, datetime, and calendar modules
On Sat, 14 Jan 2012 14:58:26 -0600, Evan Driscoll wrote: > On 01/14/2012 02:11 PM, Devin Jeanpierre wrote: >> On Sat, Jan 14, 2012 at 2:23 PM, Rick Johnson >> wrote: >>> THAT PISSES ME OFF!!!>:( We should never be forced to guess if a name >>> is a callable or a variable! >>> >>> So how do we solve this dilemma you ask??? Well, we need to "mark" >>> method OR variable names (OR both!) with syntactic markers so there >>> will be NO confusion. >> >> I might be being bit OT, but, you should give Common Lisp a try. It >> does something similar for functions versus variables. >> >> As for the issue, I suppose I can see how this would be confusing. I >> don't agree with your solution, though. > > It also has some problems. For instance, if an object has a member which > is a type that implements __call__ but is also useful to access "on its > own", is that a field or a function? This is the problem with Ruby's syntax for calling functions with no argument with brackets. Since f on its own is interpreted as "call f with no arguments", there is no easy way to get a reference to the object f. This makes functions second-class objects in Ruby, since you can't refer to them easily by name like you can other objects. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Learn Chinese (Mandarin) faster by using flashcards with pictures
http://www.ichineseflashcards.com will help you learn Chinese (Mandarin) faster by using flashcards with pictures, thanks -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWarts: time, datetime, and calendar modules
On Jan 14, 10:23 pm, Steven D'Aprano wrote: > This is not Java, and we prefer Python terminology. > > A variable holding an int is an int variable. > A variable holding a string is a string variable. > A variable holding a list is a list variable. > A variable holding an instance is an instance variable. > A variable holding a class is a class variable. You went to a lot of trouble to prove nothing. Here allow me to retort: A box holding an apple is an apple box. A box holding a pear is a pear box. A box holding an orange is a orange box. A box holding an banana is an banana box. And a box that penis comes in is a vagina! > Guessing is for fourth-class programmers who don't know their language > and are too lazy to RTFM. Oh really. I don't know about you Steven but i am not JUST a Python programmer. I write tons of code with Python but i also write tons of code in many other languages too. Not only am i emerged in many aspects of the IT world, i have a WIDE scope of knowledge in many other fields and disciplines; all of which is ongoing because let's face it, the minute you _think_ you know everything is the second you become obsolete. But i digress... Making claims that obfuscated syntax and insufficient APIs are *somehow* the programmers fault, because he (or she!) does not have EVERY *SINGLE* corner of the Python library memorized, is quite preposterous. > At worst, we might agree that the datetime API is old and tired, and that > if descriptors existed back in Python 1.x then datetime.weekday could > have been a computed property instead of a method, but alas we've lost > the opportunity for this. Any changes to datetime need to be backward > compatible. Why? "print()" is not backward compatible? Face it, Guido has broken Python's cherry. She is no longer pure. You're acting like some over- protective father. WAKE UP! Python is a promiscuous little whore and she's on girls gone wild (Volume 4000) shaking her little money maker. We should at least profit from the immorality. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWarts: time, datetime, and calendar modules
On Sat, 14 Jan 2012 21:27:32 -0800, Rick Johnson wrote: > On Jan 14, 10:23 pm, Steven D'Aprano +comp.lang.pyt...@pearwood.info> wrote: > >> This is not Java, and we prefer Python terminology. >> >> A variable holding an int is an int variable. A variable holding a >> string is a string variable. A variable holding a list is a list >> variable. A variable holding an instance is an instance variable. A >> variable holding a class is a class variable. > > You went to a lot of trouble to prove nothing. Here allow me to retort: > > A box holding an apple is an apple box. A box holding a pear is a pear > box. > A box holding an orange is a orange box. A box holding an banana is an > banana box. And a box that penis comes in is a vagina! Penises aren't supplied in boxes. About 50% of the population already has one, the other 50% can get as many as they want. >> Guessing is for fourth-class programmers who don't know their language >> and are too lazy to RTFM. > > Oh really. I don't know about you Steven but i am not JUST a Python > programmer. I write tons of code with Python but i also write tons of > code in many other languages too. Why don't you approach those other languages and demand that they change to match Python's model then? See how well that goes over. >> At worst, we might agree that the datetime API is old and tired, and >> that if descriptors existed back in Python 1.x then datetime.weekday >> could have been a computed property instead of a method, but alas we've >> lost the opportunity for this. Any changes to datetime need to be >> backward compatible. > > Why? "print()" is not backward compatible? You missed your opportunity by two versions. The time to have made the change was before Python 3.0 came out. We're now up to 3.2 and 3.3 is under development. The opportunity for breaking backward compatibility was 3-4 years ago. Now we're back to the normal paradigm of caring about backward compatibility. > Face it, Guido has broken Python's cherry. She is no longer pure. You need to get yourself a girlfriend. Or at least a subscription to Playboy. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Extension module question
As I hinted at in an earlier email, I'm working on a module which will
allow calling readdir() (and FindFirstFile on Windows, hopefully pretty
uniformly) from Python. The responses I got convinced me that it was a
good idea to write a C-to-Python bridge as an extension module.
What I'm not sure about is how to store pointers to *C* stuff between
calls. In particular, opendir() returns a DIR* which you then need to
pass to calls to readdir() in the future (and closedir()).
So I've got this:
static PyObject*
py_opendir(PyObject* self, PyObject* args)
{
const char* dirname = 0;
if (!PyArg_ParseTuple(args, "s", &dirname)) {
return NULL;
}
// Eventually want to Py_BEGIN_ALLOW_THREADS here
DIR* directory =
opendir(dirname);
PyObject out = PyBuildValue( ???, directory );
return out;
}
but I don't know what to build. (I might want to wrap it in a custom
handle class or something, but I still need to know how to build the
value I eventually store in an attribute of that class.)
My best idea is to use an unsigned long (so "k") and add a static
assertion that sizeof(long)==sizeof(void*). Is this the canonical way of
doing something like this, or am I missing a better way?
Evan
signature.asc
Description: OpenPGP digital signature
--
http://mail.python.org/mailman/listinfo/python-list
