MemberAdaptor.py [lines 119-124] def getMemberPassword(self, member): """Return the member's password.
If the member KEY/LCE is not a member of the list, raise
NotAMemberError.
"""should there be a "raise NotImplemented" after the documentation stuff?? ie - is that the general rule to raise with any method in MemberAdaptor that we don't want implemented...
Currently working on the LDAP authenticator and I don't want people to change their LDAP password with Mailman. :)
Regards
Donal --DCU--
"DH" == Donal Hunt <donal.hunt2@mail.dcu.ie> writes:
DH> MemberAdaptor.py [lines 119-124]
| def getMemberPassword(self, member):
| """Return the member's password.
| If the member KEY/LCE is not a member of the list, raise
| NotAMemberError.
| """
DH> should there be a "raise NotImplemented" after the
DH> documentation stuff?? ie - is that the general rule to raise
DH> with any method in MemberAdaptor that we don't want
DH> implemented...Not quite, although you're right that there should be a "raise NotImplemented" there. The exception is raised in the method because MemberAdaptor.py plays the role of an abstract interface, defining method that /must/ be overridden in derived classes. In practice, it probably makes little difference, but I'll add it back for cleanliness.
DH> Currently working on the LDAP authenticator and I don't want
DH> people to change their LDAP password with Mailman. :)Then you should either no-op the setMemberPassword() method, or raise a RuntimeError. I sort of doubt that Mailman is prepared to capture exceptions in the MemberAdaptor methods, so a no-op might be the most expedient thing to do.
-Barry
-- Original Message -- Date: Sat, 26 Jan 2002 18:57:08 -0500 To: Donal Hunt <donal.hunt2@mail.dcu.ie> Cc: "mailman-developers@python.org" <mailman-developers@python.org> Subject: Re: [Mailman-Developers] MemberAdaptor.py [missing line?] From: barry@zope.com (Barry A. Warsaw)
DH> should there be a "raise NotImplemented" after the DH> documentation stuff?? ie - is that the general rule to raise DH> with any method in MemberAdaptor that we don't want DH> implemented...
Not quite, although you're right that there should be a "raise NotImplemented" there. The exception is raised in the method because MemberAdaptor.py plays the role of an abstract interface, defining method that /must/ be overridden in derived classes. In practice, it probably makes little difference, but I'll add it back for cleanliness.
Yeh - it was more a cleanliness thing more than anything...
DH> Currently working on the LDAP authenticator and I don't want DH> people to change their LDAP password with Mailman. :)
Then you should either no-op the setMemberPassword() method, or raise a RuntimeError. I sort of doubt that Mailman is prepared to capture exceptions in the MemberAdaptor methods, so a no-op might be the most expedient thing to do.
That's what I wasn't sure about... There's no point raising exceptions in MemberAdaptor methods if they aren't caught at a later stage...
Depending on what the LDAP authenticator code throws up, i might add some code to the Mailman GUI side, so that the users get a nice message when an admin decides that password changes aren't permitted via Mailman... I haven't checked the code to see what happens presently...
On a separate note (and more on python train of thought...) - is there a way of working out what types are being returned by Python methods?? For example in the OldStyleMemberships class, you return different structures for some methods... eg getRegularMemberKeys() returns a marshal (I think)...
If the expected return type was specified in the MemberAdaptor.py file for the method, it would be mighty handy... :)
Later
Donal
Then you should either no-op the setMemberPassword() method, or raise a RuntimeError. I sort of doubt that Mailman is prepared to capture exceptions in the MemberAdaptor methods, so a no-op might be the most expedient thing to do.
DH> That's what I wasn't sure about... There's no point raising
DH> exceptions in MemberAdaptor methods if they aren't caught at a
DH> later stage...Agreed. We definitely don't want exceptions percolating up to the top.
DH> Depending on what the LDAP authenticator code throws up, i
DH> might add some code to the Mailman GUI side, so that the users
DH> get a nice message when an admin decides that password changes
DH> aren't permitted via Mailman...Cool.
DH> On a separate note (and more on python train of thought...) -
DH> is there a way of working out what types are being returned by
DH> Python methods?? For example in the OldStyleMemberships
DH> class, you return different structures for some methods... eg
DH> getRegularMemberKeys() returns a marshal (I think)Not in plain Python, there really isn't. However, Zope defines and uses something called an Interface type which is likely how MemberAdaptor and friends should refer to. Interfaces can define the signatures of methods, although implementations aren't forced to adhere to them. Python ain't C++. :)
I don't think I'll use Interfaces until I can require Python 2.2 or better. I believe (but am not 100% sure) that Zope's Interfaces are implemented as ExtensionClass types, and that's too big a hurdle for Mailman.
-Barry
participants (3)
-
barry＠zope.com -
Donal Hunt -
donal.hunt2＠mail.dcu.ie