#2133: AttributeError in beaker in tg2.0b2 python2.4
------------------------+---------------------------------------------------
Reporter: lszyba1 | Owner: faide
Type: defect | Status: closed
Priority: normal | Milestone: 2.0rc1
Component: TurboGears | Version: trunk
Severity: normal | Resolution: wontfix
Keywords: |
------------------------+---------------------------------------------------
Comment (by toshio):
Replying to [comment:17 bbangert]:
> There is a '''lot''' of packages that look for hashlib like we do,
'''NONE''' of them will work on your system as long as you have that
hashlib package that doesn't work like the Python 2.5 and later one.
>
Note that this is incorrect on two counts. 1) the hashlib package
'''is''' a drop in replacement for the python-2.5 and later one. That's
not the problem here. 2) '''MOST''' modules that check for hashlib like
this will work fine. The problem only arises when code that checks for
hashlib like this then sends the created object into code that can only
work with the old md5 and sha objects, not the new objects from hashlib.
In third-party modules, you could ask that those modules be changed to
accept the new-style hashlib objects. Since hmac comes in the python2.4
stdlib it's not realistic to think that this will be changed there.
Especially because the API documents its expectations and Beaker is
breaking it. If Beaker wants to be compatible with python-2.4, it needs
to only pass in the old-style md5/hash objects if it's using the 2.4 hmac.
This means you have to resort to an ugly python version check where you're
importing md5/sha/hashlib to determine what hmac version you're working
with: (if sys.version_info[0:2] == (2,4): # old style else: # new style)
but that's a limitation of hmac.py not providing a separate version.
This check belongs in Beaker since it's Beaker that's deciding what object
to instantiate and then pass on to hmac. The current Beaker logic is
choosing which version of hmac it is coded for based on the availability
of hashlib. This is flawed logic - instead Beaker needs to check what
hmac is installed (via the python version check) to make the decision.
> Are you really suggesting that everyone put in a decent amount of
try/except's along with other various feature tests to deal with *one*
guy's hashlib package that uses the same namespace as a later Python
versions and thus causes this whole problem?
>
> I mean, its possible that a proper solution might be that everyone goes
and does this.... but I'd like to believe this is a situation where the
hashlib package for Python 2.4 users should monkey-patch hmac so that its
used properly, as feature testing around the issue is rather ugly.
While that's another solution, having a third-party library that monkey
patches stdlib libraries seems like a bad design decision. When an
application chooses to do this at least the coder knows that they've
changed the semantics of something basic to the python distribution
they're using. But for a library to do this can lead to all sorts of
problems: user expectations, unintentionally breaking unrelated code that
depended on that version, etc.
I'm not going to reopen this ticket as in Fedora we only support
python-2.4 in EPEL, not Fedora proper and we'll modify the Beaker packages
locally to support the old hmac API there. Just wanted to point out for
people googling this that this is not hashlib's problem. It's a problem
with passing the incorrect type to a specific hmac API version because the
Beaker's detection logic is flawed.
--
Ticket URL: <http://trac.turbogears.org/ticket/2133#comment:24>
TurboGears <http://www.turbogears.org/>
TurboGears front-to-back web development
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "TurboGears Tickets" group.
This group is read-only. No posting by normal members allowed.
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/turbogears-tickets?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---
