From jeffrey at skyhouseconsulting.com Tue May 3 01:33:40 2005 From: jeffrey at skyhouseconsulting.com (Jeffrey Harris) Date: Mon, 02 May 2005 19:33:40 -0400 Subject: [icalendar-dev] Python iCalendar libraries Message-ID: <4276B8D4.3000403@skyhouseconsulting.com> Hi Folks, As part of my work for OSAF (osafoundation.org), I've also written an Python iCalendar parser. It's available at vobject.skyhouseconsulting.com. OSAF tries not to be a NIH kind of place, so I'm sorry I didn't know about Python iCalendar before I wrote vobject! Now that I've written it, I'd love to avoid a proliferation of incomplete Python iCalendarlibraries. I'm not sure if the community should tend towards vobject or iCalendar. vobject is under the Apache license. I don't know if it makes more sense to have a standard Python library be LGPLed or Apache licensed, I've erred on the side of fewer restrictions. I've tried to design vobject with an extensible architecture so vCalendar 1.0 and variou vCard versions can be parsed using the same library. At the moment, only iCalendar (vCalendar 2.0) is supported very sucessfully. I'd be interested in comparisons of this iCalendar library and vobject. I'm not sure if OSAF will move away from vobject any time soon, but feel free to grab ideas from vobject, if you like! Sincerely, Jeffrey From faassen at infrae.com Tue May 3 11:34:28 2005 From: faassen at infrae.com (Martijn Faassen) Date: Tue, 03 May 2005 11:34:28 +0200 Subject: [icalendar-dev] Python iCalendar libraries In-Reply-To: <4276B8D4.3000403@skyhouseconsulting.com> References: <4276B8D4.3000403@skyhouseconsulting.com> Message-ID: <427745A4.3070201@infrae.com> Jeffrey Harris wrote: > As part of my work for OSAF (osafoundation.org), I've also written an > Python iCalendar parser. It's available at vobject.skyhouseconsulting.com. I briefly took a look at the code. I didn't notice an abundance of tests, was my impression correct? > OSAF tries not to be a NIH kind of place, so I'm sorry I didn't know > about Python iCalendar before I wrote vobject! I think I hadn't seen vobject when I did my googling around for a suitable iCalendar library. I ran into Max M's which took this ball rolling. I'm glad at least my work in publicizing its existence has helped other iCalendar developers to find it now; that means the work was not for naught! > Now that I've written > it, I'd love to avoid a proliferation of incomplete Python > iCalendarlibraries. I'm not sure if the community should tend towards > vobject or iCalendar. Yes, that's an unfortunate situation. And of course we're unlikely to give up our babies, both. :) > vobject is under the Apache license. I don't know if it makes more > sense to have a standard Python library be LGPLed or Apache licensed, > I've erred on the side of fewer restrictions. Concerning minimizing restrictions, in my conversations with Max M he indicated not minding lifting the restrictions further. > I've tried to design vobject with an extensible architecture so > vCalendar 1.0 and variou vCard versions can be parsed using the same > library. At the moment, only iCalendar (vCalendar 2.0) is supported > very sucessfully. > > I'd be interested in comparisons of this iCalendar library and vobject. > I'm not sure if OSAF will move away from vobject any time soon, but > feel free to grab ideas from vobject, if you like! From my impressions, differences involve: iCalendar library vobject many (doc)tests less tests can generate iCalendar too just parsing less consideration for tz more consideration for timezones I'm unsure on the timezone issues; iCalendar does define a few and works with them, but I don't know how it would work in more complicated situations. I don't know how good vobject is at decoding input into appropriate Python (and of course iCalendar library also encoded python input back into vobject); iCalendar in my experience is pretty good at it. One area in which the iCalendar library is sometimes not entirely nice is error handling. If for instance you input a \n separated iCalendar file instead of \r\n file, you get nothing as output. I'd expect at least an error. There are also some bare excepts in the code that I'd like to get rid of. I have the impression that the iCalendar library allows extensibility; perhaps Max M can talk more about this. I think the iCalendar library is very nice in that the same objects are used in round-tripping; you can generate iCalendar data and then load them in again as objects, etc. It's very flexible that way; it also works for calendar fragments, not just whole calendars. Regards, Martijn From maxm at mxm.dk Tue May 3 13:48:06 2005 From: maxm at mxm.dk (Max M) Date: Tue, 03 May 2005 13:48:06 +0200 Subject: [icalendar-dev] Python iCalendar libraries In-Reply-To: <4276B8D4.3000403@skyhouseconsulting.com> References: <4276B8D4.3000403@skyhouseconsulting.com> Message-ID: <427764F6.5040909@mxm.dk> Jeffrey Harris wrote: >OSAF tries not to be a NIH kind of place, so I'm sorry I didn't know >about Python iCalendar before I wrote vobject! > I am not shure which module came first. >Now that I've written >it, I'd love to avoid a proliferation of incomplete Python >iCalendarlibraries. I'm not sure if the community should tend towards >vobject or iCalendar. > > Most likely we (the authors) are not the right judges. >vobject is under the Apache license. I don't know if it makes more >sense to have a standard Python library be LGPLed or Apache licensed, >I've erred on the side of fewer restrictions. > > LGPL was picked a bit by random. It is the hope that an iCal library will be part of Python standard library. If it where to be iCalendar the licens will naturally change. >I've tried to design vobject with an extensible architecture so >vCalendar 1.0 and variou vCard versions can be parsed using the same >library. At the moment, only iCalendar (vCalendar 2.0) is supported >very sucessfully. > Ditto -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science From jeffrey at skyhouseconsulting.com Tue May 3 15:27:49 2005 From: jeffrey at skyhouseconsulting.com (Jeffrey Harris) Date: Tue, 03 May 2005 09:27:49 -0400 Subject: [icalendar-dev] Python iCalendar libraries In-Reply-To: <427745A4.3070201@infrae.com> References: <4276B8D4.3000403@skyhouseconsulting.com> <427745A4.3070201@infrae.com> Message-ID: <42777C55.6050406@skyhouseconsulting.com> Hi Martijn, > I briefly took a look at the code. I didn't notice an abundance of > tests, was my impression correct? There are a fair number of doctests, especially in tests.py :) Not perhaps as many as in iCalendar, more tests are always better, of course. I keep meaning to write more. I'm afraid I didn't do TDD like I'd meant to with this. > I think I hadn't seen vobject when I did my googling around for a > suitable iCalendar library. I ran into Max M's which took this ball > rolling. I'm glad at least my work in publicizing its existence has > helped other iCalendar developers to find it now; that means the work > was not for naught! Certainly. > Yes, that's an unfortunate situation. And of course we're unlikely to > give up our babies, both. :) Well, it sounds like Max is willing to change the license. If so, I think we can likely work together. So perhaps neither of us have to abandon our babies, we could come up with a more original name and merge. I'm not attached to that, though. > iCalendar library vobject > > many (doc)tests less tests > can generate iCalendar too just parsing > less consideration for tz more consideration for timezones vobject does do serialization, of everything except vtimezones and dateutil.rrules. I just looked through iCalendar, our code is VERY similar. Not, I suppose, terribly surprising! > I don't know how good vobject is at decoding input into appropriate > Python (and of course iCalendar library also encoded python input back > into vobject); iCalendar in my experience is pretty good at it. This is where I put most of my effort, I'd like to think vobject does a pretty good job, too. Base64 encoding, backslash escaping, datetime (or datetime.date, when appropriate) and timedelta encoding, vtimezones, and rrules are all there. > One area in which the iCalendar library is sometimes not entirely nice > is error handling. If for instance you input a \n separated iCalendar > file instead of \r\n file, you get nothing as output. I'd expect at > least an error. There are also some bare excepts in the code that I'd > like to get rid of. I'll cast no stones on this, vobject is very liberal in what it accepts, but there are MANY corner cases I haven't written tests for, I expect many of those corner cases fall down currently. > I think the iCalendar library is very nice in that the same objects are > used in round-tripping; you can generate iCalendar data and then load > them in again as objects, etc. It's very flexible that way; it also > works for calendar fragments, not just whole calendars. Ditto for vobject :) Sincerely, Jeffrey From maxm at mxm.dk Tue May 3 16:05:31 2005 From: maxm at mxm.dk (Max M) Date: Tue, 03 May 2005 16:05:31 +0200 Subject: [icalendar-dev] Python iCalendar libraries In-Reply-To: <42777C55.6050406@skyhouseconsulting.com> References: <4276B8D4.3000403@skyhouseconsulting.com> <427745A4.3070201@infrae.com> <42777C55.6050406@skyhouseconsulting.com> Message-ID: <4277852B.1020904@mxm.dk> Jeffrey Harris wrote: >>One area in which the iCalendar library is sometimes not entirely nice >>is error handling. If for instance you input a \n separated iCalendar >>file instead of \r\n file, you get nothing as output. I'd expect at >>least an error. >> You could say that. The RFC is completely unambigiouos at that point. It's illegal to use \n instead of \r\n. It's simply not a valid ical file. So it should probably treat it as an Ical file with no components. Which is also illegal. I am not shure how it should react on an empty file. >>There are also some bare excepts in the code that I'd >>like to get rid of. >> Whimp ;-) -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science From jeffrey at skyhouseconsulting.com Tue May 3 17:13:36 2005 From: jeffrey at skyhouseconsulting.com (Jeffrey Harris) Date: Tue, 03 May 2005 11:13:36 -0400 Subject: [icalendar-dev] Python iCalendar libraries In-Reply-To: <427764F6.5040909@mxm.dk> References: <4276B8D4.3000403@skyhouseconsulting.com> <427764F6.5040909@mxm.dk> Message-ID: <42779520.9070404@skyhouseconsulting.com> Hi Max, > I am not shure which module came first. I don't know, either. I didn't want to trumpet my very incomplete work from the hilltops when I was writing it, but of course that's wrong approach in a free software project, you've got to do a bit of trumpeting to avoid duplication of effort. Hopefully I'll remember that next time! > Most likely we (the authors) are not the right judges. Yes, although I'd like to TRY to set my ego aside! > LGPL was picked a bit by random. It is the hope that an iCal library > will be part of Python standard library. If it where to be iCalendar the > licens will naturally change. I understand completely, I hadn't gotten a clear signal from OSAF from what license they wanted for a long time. Basically, we'd like to have an iCalendar/vCard parser as part of the Python standard library, so we decided it would make sense to have a license as liberal as the PSF uses from the start. If you'd be willing to adjust your license downward now, I think we could very fruitfully start cross fertilizing our work. As it is, I'm a bit wary of reading through LGPL code for a project very similar to my own, it seems a bit dangerous! To start, I think it would be very nice to harmonize our object access APIs, they're already very similar, so I think this wouldn't take much. Once we'd done that, we could share tests, that would pretty immediately benefit us both, I expect. Eventually, I'd be interested in combining projects, but I don't think we need to rush into that. Glad to be working with you all! Sincerely, Jeffrey From jeffrey at skyhouseconsulting.com Tue May 3 17:19:50 2005 From: jeffrey at skyhouseconsulting.com (Jeffrey Harris) Date: Tue, 03 May 2005 11:19:50 -0400 Subject: [icalendar-dev] Python iCalendar libraries In-Reply-To: <4277852B.1020904@mxm.dk> References: <4276B8D4.3000403@skyhouseconsulting.com> <427745A4.3070201@infrae.com> <42777C55.6050406@skyhouseconsulting.com> <4277852B.1020904@mxm.dk> Message-ID: <42779696.9020302@skyhouseconsulting.com> Hi Max, >>> One area in which the iCalendar library is sometimes not entirely nice >>> is error handling. If for instance you input a \n separated iCalendar >>> file instead of \r\n file, you get nothing as output. I'd expect at >>> least an error. > > You could say that. The RFC is completely unambigiouos at that point. > It's illegal to use \n instead of \r\n. It's simply not a valid ical file. > > So it should probably treat it as an Ical file with no components. Which > is also illegal. > > I am not shure how it should react on an empty file. The RFC is unambiguous, but generally I think it's better to be liberal in what you accept. It would probably be good to have a strict mode for parsing that's off by default. Sincerely, Jeffrey From faassen at infrae.com Tue May 3 18:26:54 2005 From: faassen at infrae.com (Martijn Faassen) Date: Tue, 03 May 2005 18:26:54 +0200 Subject: [icalendar-dev] Python iCalendar libraries In-Reply-To: <4277852B.1020904@mxm.dk> References: <4276B8D4.3000403@skyhouseconsulting.com> <427745A4.3070201@infrae.com> <42777C55.6050406@skyhouseconsulting.com> <4277852B.1020904@mxm.dk> Message-ID: <4277A64E.4030505@infrae.com> Max M wrote: [you're replying to me a level too deep, so Jeffrey is involved without him saying anything :)] >> Martijn wrote: >>> One area in which the iCalendar library is sometimes not entirely nice >>> is error handling. If for instance you input a \n separated iCalendar >>> file instead of \r\n file, you get nothing as output. I'd expect at >>> least an error. > > You could say that. The RFC is completely unambigiouos at that point. > It's illegal to use \n instead of \r\n. It's simply not a valid ical file. > > So it should probably treat it as an Ical file with no components. Which > is also illegal. > > I am not shure how it should react on an empty file. Raise an exception seems to be the most sensible thing. You could even detect newlines without \r in this case and say something informative, as this is one thing that tripped me up a number of times. Even after I knew this was wrong I still sometimes ran into the problem, so an informative exception would be best. >>> There are also some bare excepts in the code that I'd >>> like to get rid of. > Whimp ;-) No, I actually discovered they were there when debugging something, and the bare excepts hurt me. I don't remember the exact case, but they suppressed information that would have helped me track down my error sooner if I'd actually seen it. I'd like to replace them with more specific exception handlers. Regards, Martijn From faassen at infrae.com Tue May 3 18:30:30 2005 From: faassen at infrae.com (Martijn Faassen) Date: Tue, 03 May 2005 18:30:30 +0200 Subject: [icalendar-dev] Python iCalendar libraries In-Reply-To: <42779520.9070404@skyhouseconsulting.com> References: <4276B8D4.3000403@skyhouseconsulting.com> <427764F6.5040909@mxm.dk> <42779520.9070404@skyhouseconsulting.com> Message-ID: <4277A726.7020708@infrae.com> Jeffrey Harris wrote: [snip] >>LGPL was picked a bit by random. It is the hope that an iCal library >>will be part of Python standard library. If it where to be iCalendar the >>licens will naturally change. > > I understand completely, I hadn't gotten a clear signal from OSAF from > what license they wanted for a long time. Basically, we'd like to have > an iCalendar/vCard parser as part of the Python standard library, so we > decided it would make sense to have a license as liberal as the PSF uses > from the start. > If you'd be willing to adjust your license downward now, I think we > could very fruitfully start cross fertilizing our work. As it is, I'm a > bit wary of reading through LGPL code for a project very similar to my > own, it seems a bit dangerous! Max M, can I change it all over to (non-advertising clause) BSD or MIT? > To start, I think it would be very nice to harmonize our object access > APIs, they're already very similar, so I think this wouldn't take much. > Once we'd done that, we could share tests, that would pretty > immediately benefit us both, I expect. Eventually, I'd be interested in > combining projects, but I don't think we need to rush into that. I think this is a good plan. I had quite a bit of success doing this when I was implementing lxml and I wanted to reuse ElementTree's tests. Sharing tests is indeed of immediate benefit. Any concrete suggestions? I'm personally okay with modifying the code that I wrote that would break if iCalendar's APIs changed, and with the 0.10 release I broke all previous code anyway, so I don't think we'd hurt anyone if we act relatively quickly and push out a new 0.11 release. The interfaces.py should give a good overview of the current APIs. Regards, Martijn From maxm at mxm.dk Tue May 3 20:22:29 2005 From: maxm at mxm.dk (Max M) Date: Tue, 03 May 2005 20:22:29 +0200 Subject: [icalendar-dev] Python iCalendar libraries In-Reply-To: <4277A726.7020708@infrae.com> References: <4276B8D4.3000403@skyhouseconsulting.com> <427764F6.5040909@mxm.dk> <42779520.9070404@skyhouseconsulting.com> <4277A726.7020708@infrae.com> Message-ID: <4277C165.6000502@mxm.dk> Martijn Faassen wrote: >> could very fruitfully start cross fertilizing our work. As it is, I'm a >> bit wary of reading through LGPL code for a project very similar to my >> own, it seems a bit dangerous! > > If you'd be willing to adjust your license downward now, I think we > > Max M, can I change it all over to (non-advertising clause) BSD or MIT? As we allready has discussed a while ago, I don't really care much about the license. Infrastructure libraries like these, especially when based on open standards, should be usable in a commercial/closed setting anyway. As much as I like open/free software, I am a firm believer that not all software is suitable for it. > Any concrete suggestions? I'm personally okay with modifying the code > that I wrote that would break if iCalendar's APIs changed, and with > the 0.10 release I broke all previous code anyway, so I don't think > we'd hurt anyone if we act relatively quickly and push out a new 0.11 > release. There are probably not many users yet. I have no problem with it. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science From jeffrey at skyhouseconsulting.com Tue May 3 20:49:44 2005 From: jeffrey at skyhouseconsulting.com (Jeffrey Harris) Date: Tue, 03 May 2005 14:49:44 -0400 Subject: [icalendar-dev] Python iCalendar libraries In-Reply-To: <4277A726.7020708@infrae.com> References: <4276B8D4.3000403@skyhouseconsulting.com> <427764F6.5040909@mxm.dk> <42779520.9070404@skyhouseconsulting.com> <4277A726.7020708@infrae.com> Message-ID: <4277C7C8.2040108@skyhouseconsulting.com> Hi Martijn, > Any concrete suggestions? I'm personally okay with modifying the code > that I wrote that would break if iCalendar's APIs changed, and with the > 0.10 release I broke all previous code anyway, so I don't think we'd > hurt anyone if we act relatively quickly and push out a new 0.11 release. > > The interfaces.py should give a good overview of the current APIs. Unfortunately, this isn't an ideal month for me to work much on vobject or iCalendar, so I have limited time for looking into this right now. I'll try to read over iCalendar in more depth soon. Sincerely, Jeffrey From faassen at infrae.com Wed May 4 11:34:21 2005 From: faassen at infrae.com (Martijn Faassen) Date: Wed, 04 May 2005 11:34:21 +0200 Subject: [icalendar-dev] Python iCalendar libraries In-Reply-To: <4277C165.6000502@mxm.dk> References: <4276B8D4.3000403@skyhouseconsulting.com> <427764F6.5040909@mxm.dk> <42779520.9070404@skyhouseconsulting.com> <4277A726.7020708@infrae.com> <4277C165.6000502@mxm.dk> Message-ID: <4278971D.3080409@infrae.com> Max M wrote: > Martijn Faassen wrote: > >>> could very fruitfully start cross fertilizing our work. As it is, I'm a >>> bit wary of reading through LGPL code for a project very similar to my >>> own, it seems a bit dangerous! >> >> If you'd be willing to adjust your license downward now, I think we >> >> Max M, can I change it all over to (non-advertising clause) BSD or MIT? > > As we allready has discussed a while ago, I don't really care much about > the license. Infrastructure libraries like these, especially when based > on open standards, should be usable in a commercial/closed setting anyway. Yes, but I won't change the license to software you wrote without your explicit permission. :) > As much as I like open/free software, I am a firm believer that not all > software is suitable for it. I'll go ahead and change it to BSD then, then we won't get new license debates in the future. >> Any concrete suggestions? I'm personally okay with modifying the code >> that I wrote that would break if iCalendar's APIs changed, and with >> the 0.10 release I broke all previous code anyway, so I don't think >> we'd hurt anyone if we act relatively quickly and push out a new 0.11 >> release. > > There are probably not many users yet. I have no problem with it. Okay, good, then we can start a discussion on what might be good changes. Regards, Martijn From faassen at infrae.com Wed May 4 11:35:16 2005 From: faassen at infrae.com (Martijn Faassen) Date: Wed, 04 May 2005 11:35:16 +0200 Subject: [icalendar-dev] Python iCalendar libraries In-Reply-To: <4277C7C8.2040108@skyhouseconsulting.com> References: <4276B8D4.3000403@skyhouseconsulting.com> <427764F6.5040909@mxm.dk> <42779520.9070404@skyhouseconsulting.com> <4277A726.7020708@infrae.com> <4277C7C8.2040108@skyhouseconsulting.com> Message-ID: <42789754.8010704@infrae.com> Jeffrey Harris wrote: > Hi Martijn, > > >>Any concrete suggestions? I'm personally okay with modifying the code >>that I wrote that would break if iCalendar's APIs changed, and with the >>0.10 release I broke all previous code anyway, so I don't think we'd >>hurt anyone if we act relatively quickly and push out a new 0.11 release. >> >>The interfaces.py should give a good overview of the current APIs. > > Unfortunately, this isn't an ideal month for me to work much on vobject > or iCalendar, so I have limited time for looking into this right now. > I'll try to read over iCalendar in more depth soon. All right, but do contact us about this when you have more time. We're happy to change the APIs where it makes sense and where helpful to you. Regards, Martijn From judson at mcs.anl.gov Wed May 4 05:49:28 2005 From: judson at mcs.anl.gov (Ivan R. Judson) Date: Tue, 3 May 2005 22:49:28 -0500 Subject: [icalendar-dev] new line support Message-ID: <200505040349.j443nXn20286@mcs.anl.gov> I've been reading the archives and I agree with Jeffrey Harris that good implementations generally are generously accepting of crappy input, but strictly produce correct output. This principle makes systems work better. I say this because I'm tinkering with vCalendar from MS Outlook which doesn't do \r\n (oddly) it does \n. I'd like it to work but I don't know the magic needed in parser.py to make it happy. Is there any chance someone could poke at that? I'm keen to build an interesting calendaring service for one of our projects, but I want to use python, vcal, etc. I'd also vote for merging vobject and icalendar under the python license, and proposing it as a std lib addition. This is something really useful; I particularly like icalendars lack of requirements except python 2.3, vobject should consider dropping the dateutil thing. Then we could focus on one project with better support for things like timezones :-) Just jumping in, don't shoot me. --Ivan From maxm at mxm.dk Tue May 10 13:33:59 2005 From: maxm at mxm.dk (Max M) Date: Tue, 10 May 2005 13:33:59 +0200 Subject: [icalendar-dev] new line support In-Reply-To: <200505040349.j443nXn20286@mcs.anl.gov> References: <200505040349.j443nXn20286@mcs.anl.gov> Message-ID: <42809C27.5090304@mxm.dk> Ivan R. Judson wrote: >I say this because I'm tinkering with vCalendar from MS Outlook which doesn't do \r\n (oddly) it does \n. I'd like it to work but I >don't know the magic needed in parser.py to make it happy. Is there any chance someone could poke at that? > It's like a four line change. But should it really parse illegal files? -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science From judson at mcs.anl.gov Tue May 10 14:27:20 2005 From: judson at mcs.anl.gov (Ivan R. Judson) Date: Tue, 10 May 2005 07:27:20 -0500 (CDT) Subject: [icalendar-dev] new line support In-Reply-To: <42809C27.5090304@mxm.dk> References: <200505040349.j443nXn20286@mcs.anl.gov> <42809C27.5090304@mxm.dk> Message-ID: I think the general policy of liberal input and strictly correct output is a good interoperability practice. I'm open to being argued with, but I also think the fancy python newline support where everything is converted to '\n' makes it reasonable to account for the common problems...makes things work better more often. --Ivan On Tue, 10 May 2005, Max M wrote: > Ivan R. Judson wrote: > > >I say this because I'm tinkering with vCalendar from MS Outlook which doesn't do \r\n (oddly) it does \n. I'd like it to work but I > >don't know the magic needed in parser.py to make it happy. Is there any chance someone could poke at that? > > > > It's like a four line change. But should it really parse illegal files? > > -- > > hilsen/regards Max M, Denmark > > http://www.mxm.dk/ > IT's Mad Science > > _______________________________________________ > icalendar-dev mailing list > icalendar-dev at codespeak.net > http://codespeak.net/mailman/listinfo/icalendar-dev > > From jeffrey at skyhouseconsulting.com Tue May 10 18:47:13 2005 From: jeffrey at skyhouseconsulting.com (Jeffrey Harris) Date: Tue, 10 May 2005 11:47:13 -0500 Subject: [icalendar-dev] new line support In-Reply-To: <200505040349.j443nXn20286@mcs.anl.gov> References: <200505040349.j443nXn20286@mcs.anl.gov> Message-ID: <4280E591.7050907@skyhouseconsulting.com> Hi Ivan, > I'd also vote for merging vobject and icalendar under the python > license, and proposing it as a std lib addition. This is something > really useful; I particularly like icalendars lack of requirements > except python 2.3, vobject should consider dropping the dateutil > thing. dateutil provides rrule parsing/interpreting and vtimezone parsing. Possibly vobject could fail gracefully in the abscence of dateutil, but I don't particularly want to reinvent the rrule/vtimezone wheel. Another possibility would be to have vobject/icalendar keep a non-standard copy of the relevant dateutil modules, but that seems like a maintenance nightmare. I talked with Guido briefly at PyCon this year about getting dateutil included in the standard library, he wasn't into the idea, although I believe he's open to being convinced. I think once PyPi (intended to be Python's CPAN eventually) gets used more, dependencies will be less of an issue. Sincerely, Jeffrey