← Back to team overview

openstack team mailing list archive

Re: WebOb + DeprecationWarning

 

On Wed, 2012-03-07 at 22:40 -0800, Maru Newby wrote:
> I'm using a devstack-configured box with all the latest code and am
> running into DeprecationWarning wherever
> weob.Request.str_[GET,PUT,cookies,params] are accessed (they are being
> replaced by unicode equivalents).  Since Python < 2.7 does not ignore
> DeprecationWarning, and I am running on Python 2.6, the warnings are
> being thrown as exceptions.

They're being thrown as exceptions?  I thought the default in Python 2.6
was to report them, not to throw them.  Did someone change the warnings
settings to throw instead?

> I then realized that the nova api is similarly afflicted, and thought
> that some discussion might be warranted since so many projects were
> affected:
> 
> 1. Should DeprecationWarning be ignored by OpenStack projects when
> using Python < 2.7?

I vote 'no' on development.  I'd say it makes sense to ship final
releases with deprecation warnings disabled, but they exist to warn us
developers that some interface is going away, and we should pay
attention to that.  That said, unless you're specifically hunting
deprecation warnings, I wouldn't set them up to throw exceptions…

> 2. If no to #1, should OpenStack projects be proactively surveyed for
> use of deprecated webob.Request properties, with an eye towards
> replacing such use immediately?  Note that the string properties will
> not be removed until WebOb 1.2 and all projects are currently on
> 1.0.8.

I say yes.

> 3. As a follow-on to #2, is there going to be any fallout from
> switching from string to unicode webob.Request properties?  Web apps
> generally code defensively against non-ascii input, but being new to
> OpenStack I'm not sure how well this best-practice has been adhered
> to.

I think the only way to really know is going to be to go there and
exercise it, then make sure everything handles it OK.  Maybe we should
consider some unit tests?
-- 
Kevin L. Mitchell <kevin.mitchell@xxxxxxxxxxxxx>



Follow ups

References