mitsuhiko/werkzeug — Issue #154: Python 3 API Tracking Ticket
Author: mitsuhiko
Created: 2012-01-12 15:11:12+00:00
State: open

All things considered this is the current plan for Python 3 support:

### Step 0: Removal of Modules

The following modules should go or move for 1.0:

* werkzeug.script
* werkzeug.templates
* werkzeug.contrib.atom -> move into a separate package on pypi
* werkzeug.contrib.limiter -> already unnecessary
* werkzeug.contrib.profiler -> separate package if still necessary
* werkzeug.contrib.lint -> separate package if still necessary
* werkzeug.contrib.cache -> separate package

Reasoning: many of those are totally not Werkzeug specific and now that we have 2012 it's no longer an issue to have a higher dependency count. Also this makes porting a lot easier and will make it possible to mix and match technologies better. The cache layer is general enough for instance that it could be used with any other framework or library and totally does not depend on any other Werkzeug module.

### Step 1: Small API Changes

The following things will need to be changed:

#### URI / IRI

It's a mess, especially on Python 3. Proposed changes:

* Add werkzeug.urls.parse_url / werrkzeug.urls.unparse_uri
* Add werkzeug.urls.parse_irl / werrkzeug.urls.unparse_iri
* Make all URI functions accept bytes and unicode strings on 2.x
* Make all IRI functions only accept unicode strings where not yet done
* Make all quote functions switch between bytes and unicode strings for 3.x

Open questions:

* How to change werkzeug.urls.url_fix? It's used by the IRI support

#### Headers

Right now headers have two operation modes: copy and linked. We do not do anything with the encoding on setting but we encode to latin1 in the response objects. That was fine on 2.x but it's annoying on 3.x because now we have two different behaviors. Is it okay to stick to unicode only on Python 3 and disable our own encoding since this is now task of the WSGI server?