From: Frank W. <fwi...@gm...> - 2006-07-29 20:11:30
|
On 7/27/06, Matt Small <ms...@ac...> wrote: > Hey Charlie.. I'm seeing some problems with the modifications to > Time.java. With this patch in-place, I get errors from datetime when it > tries to create instances of struct_time. > > I've attached a test case; it fails with this error: > > [migo] msmall:~/source/jython> jython datetimetest.py > Traceback (innermost last): > File "datetimetest.py", line 2, in ? > TypeError: cannot create 'timetuple' instances > > For now, I've backed out this change.. Hey Matt, While I agree with your reasons for reverting, normally we should discuss a reversion on the jython-dev list before doing it. Under normal circumstances it would be best if the the person who made the changes did the reversion if at all possible. Also, when you reply to a commit, it is nicer if you cc jython-dev instead of jython-commit, just to keep development discussion on one list. Regards, -Frank |
From: Charlie G. <cha...@gm...> - 2006-07-30 00:25:34
|
Looks like I made a double faux pas in response to Matt. Not only did I recommit a fixed version without any discussion, I sent my reasons to Matt individually and not to the list. Here's my response to complete the record: Hi Matt, Sorry about that. I just saw that test_imaplib was failing since it was trying to use time.struct_time to check for the types of things and not expecting it to be a function and added it. I didn't realize that other things would use it to make struct_times. I think I fixed it by adding __new__ to PyTimeTuple. svn up and give it a whirl. Charlie On 7/29/06, Frank Wierzbicki <fwi...@gm...> wrote: > On 7/27/06, Matt Small <ms...@ac...> wrote: > > Hey Charlie.. I'm seeing some problems with the modifications to > > Time.java. With this patch in-place, I get errors from datetime when it > > tries to create instances of struct_time. > > > > I've attached a test case; it fails with this error: > > > > [migo] msmall:~/source/jython> jython datetimetest.py > > Traceback (innermost last): > > File "datetimetest.py", line 2, in ? > > TypeError: cannot create 'timetuple' instances > > > > For now, I've backed out this change.. > Hey Matt, > > While I agree with your reasons for reverting, normally we should > discuss a reversion on the jython-dev list before doing it. Under > normal circumstances it would be best if the the person who made the > changes did the reversion if at all possible. Also, when you reply to > a commit, it is nicer if you cc jython-dev instead of jython-commit, > just to keep development discussion on one list. > > Regards, > > -Frank > |
From: Frank W. <fwi...@gm...> - 2006-07-30 02:09:37
|
On 7/29/06, Charlie Groves <cha...@gm...> wrote: > Looks like I made a double faux pas in response to Matt. Not only did > I recommit a fixed version without any discussion, I sent my reasons > to Matt individually and not to the list. Here's my response to > complete the record: Thanks for that Charlie and Matt, I don't think there is any kind of documentation for these sorts of things, I just want to keep any friction from forming, and I think it works best when the original committer has a chance to do a reversion before others do it for them. There could certainly be exceptions to this, for example, I would understand aggressive reversions during an announced feature freeze. -Frank |
From: Matt S. <ms...@ac...> - 2006-07-31 18:11:19
|
Checking (and checking in the right place) is a better best practice -- sorry for rushing in with the reversion. -matt Frank Wierzbicki wrote: > On 7/29/06, Charlie Groves <cha...@gm...> wrote: > >> Looks like I made a double faux pas in response to Matt. Not only did >> I recommit a fixed version without any discussion, I sent my reasons >> to Matt individually and not to the list. Here's my response to >> complete the record: > > Thanks for that Charlie and Matt, > > I don't think there is any kind of documentation for these sorts of > things, I just want to keep any friction from forming, and I think it > works best when the original committer has a chance to do a reversion > before others do it for them. There could certainly be exceptions to > this, for example, I would understand aggressive reversions during an > announced feature freeze. > > -Frank |