UNIX timestamp from a datetime class
Hi.
>>> import time, calendar, datetime
>>> n= 1133893540.874922
>>> datetime.datetime.fromtimestamp(n)
datetime.datetime(2005, 12, 6, 10, 25, 40, 874922)
>>> lt= _
>>> datetime.datetime.utcfromtimestamp(n)
datetime.datetime(2005, 12, 6, 18, 25, 40, 874922)
>>> gmt= _
So it's easy to create datetime objects from so-called UNIX timestamps
(i.e. seconds since Jan 1, 1970 UTC). Is there any way to get a UNIX
timestamp back from a datetime object besides the following
circumlocutions?
>>> float(lt.strftime('%s'))
1133893540.0
>>> calendar.timegm(gmt.timetuple())
1133893540
--
http://mail.python.org/mailman/listinfo/python-list
using HTTP Digest auth with arbitrary HTTP methods?
Hello there. I've run into some missing functionality with HTTP Digest authentication in the 2.3 library and I was wondering if I'm just missing something. Missing functionality the first: urllib2 1a. You can add "handlers" to your opener indicating that you want to use HTTP Digest auth. This is nice way to handle it, but I don't see any way to use a custom verb in your URLOpener -- it always uses either GET or POST depending on whether you provided data. Is there any way to specify an arbitrary method? This would allow urllib2 to be used to write WebDAV clients. 1b. HTTPDigestAuthHandler is initialized with an HTTPPasswordMgr object, which unfortunately deals in cleartext passwords. Digest authentication can be computed using only a hash of username, password, and realm; it would be nice if there was an alternate version of HTTPPasswordMgr that let you deal in hashes instead of or in addition to plaintext passwords. Missing functionality the second: httplib. 2a. httplib.HTTPConnection lets you execute arbitrary HTTP methods with arbitrary headers and data; this is the missing functionality in 1a above. However, you have to deal with following redirects and authentication and so forth yourself. Is there any way to use the flexibility of HTTPConnection.request(method, url[, body[, headers]]) with the convenience of the chains of urllib2 handlers? The upshot is what I'm trying to do is write a WebDAV-using DAV client library, and I almost have everything I need to do it; the problem is I can't find an easy way to do digest authentication for arbitrary HTTP methods. WebDAV (RFC 2518), for those not familiar, is an extension to HTTP that defines some new methods and settles the semantics of some existing but rarely implemented HTTP methods (PUT and DELETE, for example) to define something similar to a file system. It's intended for things like letting a group of people author a web site. -- http://mail.python.org/mailman/listinfo/python-list
Re: using HTTP Digest auth with arbitrary HTTP methods?
In comp.lang.python, [I] wrote: > Hello there. I've run into some missing functionality with HTTP Digest > authentication in the 2.3 library and I was wondering if I'm just > missing something. > > Missing functionality the first: urllib2 > > 1a. You can add "handlers" to your opener indicating that you want to > use HTTP Digest auth. This is nice way to handle it, but I don't > see any way to use a custom verb in your URLOpener -- it always > uses either GET or POST depending on whether you provided data. > Is there any way to specify an arbitrary method? This would allow > urllib2 to be used to write WebDAV clients. > > 1b. HTTPDigestAuthHandler is initialized with an HTTPPasswordMgr > object, which unfortunately deals in cleartext passwords. Digest > authentication can be computed using only a hash of username, > password, and realm; it would be nice if there was an alternate > version of HTTPPasswordMgr that let you deal in hashes instead of > or in addition to plaintext passwords. Well, I figured out a workaround, but it requires changing urllib2.py since the bugs are in base classes. I instead copied it (to urllib3.py) and made the following changes: a. in AbstractDigestAuthHandler.get_authorization, call req.get_method() instead of req.has_data() and 'POST' or 'GET' (python has a ternary operator, who knew) b. in AbstractHTTPHandler.do_open, call req.get_method instead of the hard-coded if-logic which is the same as that in req.get_method Both of these seem like bugs in urllib2. Then I overrode urllib2.Request and made it possibly to set the method, and then passed an instance of my custom Request class (the one that shouldn't have to exist, since Request should allow method to be set explicitly) to OpenerDirector.open(). I'd like to see these changes make it into the standard library -- after being vetted by whoever's in charge of urllib2. Anybody know who I should talk to? -- http://mail.python.org/mailman/listinfo/python-list
Re: using HTTP Digest auth with arbitrary HTTP methods?
On 03 Jan 2005 18:11:06 +, John J. Lee <[EMAIL PROTECTED]> wrote: > (Re ternary operator: Everybody who read this list at certain times in > the past is painfully aware of that fact, and of precisely why it's > not quite true, and of all the syntax alternatives for real ternary > conditionals that will never be part of Python ;-) Yeah, I ran across the PEP after I posted this. Sorry to bring up a sore subject > Nobody is really in charge: just go ahead and submit a patch. Drop me > an email when you do, and I'll try to review it. The only reason > urllib2 doesn't already do arbitrary HTTP methods is that nobody has > spent the time to think carefully if a .set_method() really is the > right way to do it, then followed through with the work needed to get > a patch applied. Patch id #1095362 on Sourceforge. It turns out one of the bugs had already been fixed in CVS -- the digest bug was the only one left, so this is a one-line fix. > > As always, a precondition for change is that somebody thinks something > through carefully, writes tests, documentation, patch and submits all > three to the SF patch tracker with a brief explanation like the one > you give above. > > BTW, Greg Stein started work on adding the stuff you need at the > httplib level (as module httpx). He seems too busy to finish it, but > see modules httpx and davlib (one or both are in the Python CVS > sandbox). He thinks httplib is a better place for DAV than urllib2, > and he should know. But go ahead and fix urllib2 anyway... :-) These files are 2 and 3 years old. He's probably right that an interface more like httplib would be more appropriate for a DAV client; urllib2 is more about generalizing open() to use URLs than fully exposing the protocol. But urllib2 does have all those convenient handler-chains, and a good DAV client needs to handle a lot of those same situations, so it might be a good idea to at least find a way to share the handler classes. -- http://mail.python.org/mailman/listinfo/python-list
Re: HTTP GET request with basic authorization?
On 03 Jan 2005 18:27:52 +, John J. Lee <[EMAIL PROTECTED]> wrote:
> Jonas Galvez <[EMAIL PROTECTED]> writes:
>
>> Christopher J. wrote:
>> > I tried this, but it didn't work:
>> > conn.request("GET", "/somepage.html", None,
>> > {"AUTHORIZATION": "Basic username:password"})
> [...]
>> import re, base64, urllib2
>>
>> userpass = ('user', 'pass')
>> url = 'http://somewhere'
>>
>> request = urllib2.Request(url)
>> authstring = base64.encodestring('%s:%s' % userpass)
>> authstring = authstring.replace('\n', '')
>> request.add_header("Authorization", "Basic %s" % authstring)
>>
>> content = urllib2.urlopen(request).read()
>
> There are handlers in urllib2 to do this for you, you shouldn't need
> to do it by hand. I rarely do, so I won't risk an example...
>
>
> John
>
The way to do it with the handlers follows; oddly, it's just about as
long.
import urllib2
url = 'http://somewhere'
realm, user, pass = 'realm', 'user', 'pass'
hm = urllib2.HTTPPasswordMgrWithDefaultRealm()
hm.add_password(realm, url, user, pass)
od = urllib2.build_opener(urllib2.HTTPBasicAuthHandler(hm))
content = od.open(url).read()
--
http://mail.python.org/mailman/listinfo/python-list
Is there a library to parse Mozilla "mork" documents?
Mozilla, Firefox, Thunderbird, and so forth use this awful format called MORK to store all kinds of things: which messages you've read in a newsgroup, headers and indexes into the mbox file of messages in a mail folder, and address books. It's documented to some extent here: http://www.mozilla.org/mailnews/arch/mork/primer.txt Does anyone know of a Python library for parsing these files? A single file basically just stores the equivalent of a nested dictionary with text that can be declared separately and interpolated. jwz has an over-specific perl version at http://www.jwz.org/hacks/marginal.html, which I might have to try to translate if there's nothing already available in Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is there a library to parse Mozilla "mork" documents?
On Thu, 20 Jan 2005 23:48:34 -0800, Tim Roberts <[EMAIL PROTECTED]> wrote: > John Reese <[EMAIL PROTECTED]> wrote: >> >>Mozilla, Firefox, Thunderbird, and so forth use this awful format >>called MORK to store all kinds of things: which messages you've read >>in a newsgroup, headers and indexes into the mbox file of messages in >>a mail folder, and address books. > > Yes. What a crock that is. The MORK format is a great way to compress > tabular information, IF the information consists of the same pieces of data > over and over. E-mail boxes do not fit into that class, so I have no doubt > that the typical Thunderbird MORK file is singificantly LARGER than the > same file would be in, say, INI format. > > I wrote a Python script to parse it, but it isn't terribly robust. I was > able to produce a dictionary, but I didn't do anything with the results. > You're welcome to take a look: > http://www.probo.com/timr/parsemsf.py Thanks, I'll work with this. I have to say that this has all been worth it just to read about Jamie Zawinski railing against this file format. I think your comment at the top sums it up well: # Why am I doing this? -- http://mail.python.org/mailman/listinfo/python-list
SSL problem... SSL23_GET_SERVER_HELLO:unknown protocol
Morning. I've been running into an error message pertaining to SSL
that I don't understand, and I was hoping someone had some insight.
Gmail provides POP access over SSL on port 587, so I tried to use
poplib.POP_SSL, with the following results:
%python
Python 2.4.1 (#1, May 16 2005, 15:19:29)
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from poplib import POP3_SSL
>>> pop= POP3_SSL('pop.gmail.com', 587)
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/poplib.py", line 359, in __init__
self.sslobj = socket.ssl(self.sock, self.keyfile, self.certfile)
File "/usr/lib/python2.4/socket.py", line 74, in ssl
return _realssl(sock, keyfile, certfile)
socket.sslerror: (1, 'error:140770FC:SSL
routines:SSL23_GET_SERVER_HELLO:unknown protocol')
>>>
Any suggestions or insight?
--
http://mail.python.org/mailman/listinfo/python-list
Re: SSL problem... SSL23_GET_SERVER_HELLO:unknown protocol
On Sun, 17 Jul 2005 11:05:06 +0100, Stephen Illingworth <[EMAIL PROTECTED]> wrote: > John Reese wrote: >> Morning. I've been running into an error message pertaining to SSL >> that I don't understand, and I was hoping someone had some insight. >> Gmail provides POP access over SSL on port 587, so I tried to use >> poplib.POP_SSL, with the following results: > > GMail uses port 995. Yeah. I misread the instructions. I apologize for being an idiot. It works just fine on port 995. -- http://mail.python.org/mailman/listinfo/python-list
memory profiler?
Good afternoon, ha ha ha! Is there a memory or heap profiler for python programs? So that, for example, if a program was bloating over time I could see how many of each object there were and maybe even where the references were? -- http://mail.python.org/mailman/listinfo/python-list
Re: memory profiler?
On Wed, 20 Apr 2005 23:06:51 -0400, Peter Hansen <[EMAIL PROTECTED]> wrote: > John Reese wrote: >> Is there a memory or heap profiler for python programs? So that, for >> example, if a program was bloating over time I could see how many of >> each object there were and maybe even where the references were? > > The "gc" module has a variety of helpful features > like that. > > -Peter In particular, get_objects() and get_referrers(). Good point. -- http://mail.python.org/mailman/listinfo/python-list
Python 3000 idea -- + on iterables -> itertools.chain
It seems like it would be clear and mostly backwards compatible if the + operator on any iterables created a new iterable that iterated throught first its left operand and then its right, in the style of itertools.chain. This would allow summation of generator expressions, among other things, to have the obvious meaning. Any thoughts? Has this been discussed before? I didn't see it mentioned in PEP 3100. The exception to the compatibility argument is of course those iterables for which + is already defined, like tuples and lists, for that set of code that assumes that the result is of that same type, explicitly or implicitly by calling len or indexing or whathaveyou. In those cases, you could call tuple or list on the result. There are any number of other things in Python 3000 switching from lists to one-at-a-time iterators, like dict.items(), so presumably this form of incompatibility isn't a showstopper. -- http://mail.python.org/mailman/listinfo/python-list
reference counting and file objects
def uselessHash(filename): fp= open(filename) hash= 0 for line in fp: hash ^= hash(line.strip()) fp.close() # do I need this or is fp closed by ref count? return hash Consider the function above. Do I need the fp.close(), or will the file be closed automatically when fp goes out of scope and its reference count drops to zero? If so, there's really no point in calling .close() in situations like this where the function completes in a relatively short time,, and if not, I should probably be using try-finally. That's my thinking... or the thinking of the coworker who was arguing with me. -- http://mail.python.org/mailman/listinfo/python-list
unbuffering std streams in code
You know how you can specify that stderr, stdin, stdout should be unbuffered by running python with the -u switch? Is there any way I can have the same affect in code by doing something to the sys.std* variables? -- http://mail.python.org/mailman/listinfo/python-list
Why is there no instancemethod builtin?
Why hello there ha ha. I have got in the habit of testing the types of variables with isinstance and the builtin type names instead of using the types module, as was the style back around Python 2.1. That is, rather than if type(x) == types.ListType: I now do: if isinstance(x, list): It is my understanding that this is what people do nowadays. One problem I have, though, is that not all type names are available as builtins. Just looking through the types declared in types, the following are builtins: bool, buffer, complex, dict, file, float, list, long, object, slice, str, tuple, type, unicode, xrange, NoneType, NotImplementedType And the following are not: dictproxy, ellipsis, frame, function, instancemethod, module, traceback, instancemethod, NoneType, NotImplementedType So for any in the latter batch, I have to import types after all. I assume the dividing line is whether the name is useful as a constructor. Still, I feel there's some inconsistencies in the usefulness of the new type system. Why do str and unicode derive from basestring, while list and tuple are independent types? list and tuple support most of the same operations... it seems like either they should also have an abstract base class or str and unicode shouldn't, because duck typing doesn't really require that. It also seems like types may be on the way out, because I don't see constants for set or frozenset. I'm not sure I have a question here, just pointing out what I see as some flaws in the new type system. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is there no instancemethod builtin?
On Fri, 17 Jun 2005 16:40:56 -0600, <[EMAIL PROTECTED]> wrote: > John Reese wrote: >> I now do: >> >> if isinstance(x, list): >> >> It is my understanding that this is what people do nowadays. > > I wouldn't go that far. I don't have an isinstance check for lists > anywhere in my entire codebase. Why do you think you need to check to > see if something is of type list? Why don't you just use it as needed, > and find out, e.g.: > > try: > itr = iter(x) > except TypeError: > # do whatever you need to do if it's not iterable > else: > # do whatever you need to do if it *is* iterable > > STeVe I'm not saying I do it a lot, but sometimes it's useful to write methods with interfaces like, well, isinstance's, whose second argument can be a single type object or a sequence of class objects. The standard conditional vs. exception tradeoffs exist here... if it's likely that x isn't iterable, I shouldn't have to incur the time and heap churn penalty of filling in sys.exc_info and its obsolete cousins, potentially rolling back the stack, etc. -- http://mail.python.org/mailman/listinfo/python-list
