changeset 5512:c652849bfc75

Remove 2to3-done.txt (issue2550979). With all the mechanical and most of the non-mechanical parts of Python 3 support done, the lists of source files in 2to3-done.txt are no longer relevant. The discussion of plans for Python 3 support is also no longer relevant, with the string representations being described in a comment in roundup/anypy/strings.py and other known outstanding issues being described in open issues in the tracker.
author Joseph Myers <jsm@polyomino.org.uk>
date Sat, 18 Aug 2018 16:38:38 +0000
parents bfe8e52af1e7
children 19bd4b413ed6
files 2to3-done.txt MANIFEST.in
diffstat 2 files changed, 0 insertions(+), 226 deletions(-) [+]
line wrap: on
line diff
--- a/2to3-done.txt	Sat Aug 18 10:05:52 2018 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,225 +0,0 @@
-CAN'T VERIFY
-
-./roundup/backends/back_mysql.py
-
-TODO
-
-./roundup/cgi/exceptions.py
-./roundup/cgi/form_parser.py
-./roundup/cgi/MultiMapping.py
-./roundup/cgi/PageTemplates/__init__.py
-./roundup/cgi/PageTemplates/Expressions.py
-./roundup/cgi/PageTemplates/GlobalTranslationService.py
-./roundup/cgi/PageTemplates/MultiMapping.py
-./roundup/cgi/PageTemplates/PageTemplate.py
-./roundup/cgi/PageTemplates/PathIterator.py
-./roundup/cgi/PageTemplates/PythonExpr.py
-./roundup/cgi/PageTemplates/TALES.py
-./roundup/cgi/TAL/__init__.py
-./roundup/cgi/TAL/DummyEngine.py
-./roundup/cgi/TAL/HTMLParser.py
-./roundup/cgi/TAL/HTMLTALParser.py
-./roundup/cgi/TAL/markupbase.py
-./roundup/cgi/TAL/TALDefs.py
-./roundup/cgi/TAL/TALGenerator.py
-./roundup/cgi/TAL/talgettext.py
-./roundup/cgi/TAL/TALInterpreter.py
-./roundup/cgi/TAL/TALParser.py
-./roundup/cgi/TAL/TranslationContext.py
-./roundup/cgi/TAL/XMLParser.py
-./roundup/cgi/templating.py
-./roundup/cgi/TranslationService.py
-./roundup/cgi/wsgi_handler.py
-./roundup/cgi/zLOG.py
-./roundup/cgi/ZTUtils/__init__.py
-./roundup/cgi/ZTUtils/Batch.py
-./roundup/cgi/ZTUtils/Iterator.py
-./roundup/configuration.py
-./roundup/date.py
-./roundup/dist/__init__.py
-./roundup/dist/command/__init__.py
-./roundup/dist/command/bdist_rpm.py
-./roundup/dist/command/build.py
-./roundup/dist/command/build_doc.py
-./roundup/dist/command/build_scripts.py
-./roundup/exceptions.py
-./roundup/hyperdb.py
-./roundup/i18n.py
-./roundup/init.py
-./roundup/install_util.py
-./roundup/instance.py
-./roundup/mailer.py
-./roundup/mailgw.py
-./roundup/msgfmt.py
-./roundup/password.py
-./roundup/rfc2822.py
-./roundup/roundupdb.py
-./roundup/scripts/__init__.py
-./roundup/scripts/roundup_admin.py
-./roundup/scripts/roundup_demo.py
-./roundup/scripts/roundup_gettext.py
-./roundup/scripts/roundup_mailgw.py
-./roundup/scripts/roundup_server.py
-./roundup/scripts/roundup_xmlrpc_server.py
-./roundup/security.py
-./roundup/support.py
-./roundup/token.py
-./roundup/version_check.py
-./roundup/xmlrpc.py
-./run_tests.py
-./scripts/copy-user.py
-./scripts/imapServer.py
-./scripts/import_sf.py
-./scripts/schema_diagram.py
-./setup.py
-./share/roundup/templates/classic/detectors/messagesummary.py
-./share/roundup/templates/classic/detectors/nosyreaction.py
-./share/roundup/templates/classic/detectors/statusauditor.py
-./share/roundup/templates/classic/detectors/userauditor.py
-./share/roundup/templates/classic/initial_data.py
-./share/roundup/templates/classic/schema.py
-./share/roundup/templates/minimal/detectors/userauditor.py
-./share/roundup/templates/minimal/initial_data.py
-./share/roundup/templates/minimal/schema.py
-./test/__init__.py
-./test/benchmark.py
-./test/db_test_base.py
-./test/memorydb.py
-./test/mocknull.py
-./test/session_common.py
-./test/test_actions.py
-./test/test_anydbm.py
-./test/test_cgi.py
-./test/test_dates.py
-./test/test_hyperdbvals.py
-./test/test_indexer.py
-./test/test_locking.py
-./test/test_mailer.py
-./test/test_mailgw.py
-./test/test_mailsplit.py
-./test/test_memorydb.py
-./test/test_multipart.py
-./test/test_mysql.py
-./test/test_postgresql.py
-./test/test_rfc2822.py
-./test/test_schema.py
-./test/test_security.py
-./test/test_sqlite.py
-./test/test_templating.py
-./test/test_textfmt.py
-./test/test_token.py
-./test/test_userauditor.py
-./test/test_xmlrpc.py
-./test.py
-./tools/fixroles.py
-./tools/load_tracker.py
-./tools/migrate-queries.py
-./tools/pygettext.py
-./frontends/ZRoundup/__init__.py
-./frontends/ZRoundup/ZRoundup.py
-
-
-DONE
-
-./doc/conf.py
-./roundup/admin.py
-./roundup/backends/__init__.py
-./roundup/backends/back_anydbm.py
-./roundup/backends/back_postgresql.py
-./roundup/backends/back_sqlite.py
-./roundup/backends/indexer_common.py
-./roundup/backends/indexer_dbm.py
-./roundup/backends/indexer_rdbms.py
-./roundup/backends/locking.py
-./roundup/backends/portalocker.py
-./roundup/backends/rdbms_common.py
-./roundup/backends/sessions_dbm.py
-./roundup/backends/sessions_rdbms.py
-./roundup/cgi/accept_language.py
-./roundup/cgi/actions.py
-./roundup/cgi/cgitb.py
-
-
-NOTHING DONE
-
-./roundup/__init__.py
-./roundup/actions.py
-./roundup/anypy/__init__.py
-./roundup/backends/blobfiles.py
-./roundup/backends/indexer_xapian.py
-./roundup/cgi/__init__.py
-./roundup/cgi/apache.py
-./roundup/cgi/client.py
-
-Joseph S. Myers notes:
->The key difficulty is undoubtedly dealing with the changes to string types
->- combined with how the extensibility of Roundup means people will have
->Python code in their instances (detectors, etc.), both directly and
->embedded in HTML - which passes strings to Roundup interfaces and gets
->strings from Roundup interfaces.
->
->Roundup makes heavy use of string objects that really are text strings -
->logically, sequences of Unicode code points.  Right now, those strings,
->with Python 2, are str objects, encoded in UTF-8.  This means that
->people's Python code in their instances, running under Python 2, will
->expect str objects encoded in UTF-8 (and if their code is e.g. generating
->HTML text encoded in UTF-8 to be sent to the user, it never actually has
->to deal with the encoding explicitly, just passes the text through).
->(The experimental Jinja2 templating engine then explicitly converts those
->UTF-8 encoded str objects to unicode objects because that's what Jinja2
->expects to deal with.)
->
->It's quite plausible people's code in their instances will work fine with
->Python 3 if it gets str objects for both Python 2 and Python 3 (UTF-8
->encoded str for Python 2, ordinary Unicode string objects for Python 3).
->It's more likely to break if it gets Python 2 unicode objects, although
->using such objects in Python 2 seems to be how a lot of people do their
->porting to Python 3.  And certainly if when an instance is running with
->Python 3, it gets an object that's not a native sequence of Unicode code
->points, but has each UTF-8 byte as a separate element of the str object,
->things will break.
->
->(I have an instance that uses Unicode collation via PyICU on data from
->Roundup, for example.  That works fine with UTF-8 str objects in Python 2,
->would work fine with Python 2 unicode objects though I don't use those,
->works fine with Python 3 str objects when used in their native way - the
->same code has a large part also used outside of Roundup that works with
->both Python 2 and Python 3.  Actually, I'd like to have a way to make
->Roundup's built-in sorting of database objects use Unicode collation, or
->otherwise have a way of computing a sort key that isn't simply naming a
->particular property as the sort key, but that's another matter.)
->
->But Roundup *also* has strings that are sequences of bytes - String()
->database fields, which can be both.  Many are data displayed directly on
->web pages and edited there by the user - those are ordinary strings (UTF-8
->at present).  But FileClass objects have a String() content property which
->is arbitrary binary data such as an attached file - which logically should
->appear to the user as a bytes object in Python 3.  Except that some
->FileClass objects use that data to store text (e.g. the msg class in the
->classic scheme).  So you definitely need a Bytes() alternative to String()
->fields, for binary data, and may or may not also need separate text and
->binary variants of FileClass.
->
->I've found that for text-heavy code, always using str objects for text and
->having them be normal Unicode strings in Python 3 but UTF-8-encoded in
->Python 2 works well with the vast bulk of code being encoding-agnostic and
->just passing the strings around.  Obviously things are different for the
->sort of code that mixes text and binary data - that is, the sort of thing
->you describe as systems programs in your porting HOWTO.  I don't think
->Roundup really is such a systems program, except in limited areas such as
->dealing with attached files.
-
->For network data, Roundup is already careful about character sets -
->converting to UTF-8 on input (see e.g. "if client charset is different
->from the storage charset, recode form fields" in cgi/client.py, or the
->code in mailgw.py that checks the encoding of each MIME part and converts
->to UTF-8).  Presumably in such cases the decoding would remain unchanged
->for Python 3, but the encoding should be a function that's a no-op for
->Python 3 to get native str objects there (and likewise for the places
->where data is turned into Python 2 unicode objects, processed and
->converted back to UTF-8 - both steps should be no-ops for Python 3).
->
->For reading templates, database string data, etc., Roundup knows the
->storage format is UTF-8 so has no explicit conversions - those are places
->that will need to be found and made to decode as UTF-8 for Python 3 (or do
->a no-op for Python 2).
--- a/MANIFEST.in	Sat Aug 18 10:05:52 2018 +0100
+++ b/MANIFEST.in	Sat Aug 18 16:38:38 2018 +0000
@@ -9,6 +9,5 @@
 global-exclude *.pyc *.pyo .DS_Store *.orig *.rej *~ \#*
 include run_tests.py demo.py *.txt
 include doc/conf.py doc/roundup-favicon.ico
-exclude 2to3-done.txt
 exclude doc/security.txt
 include locale/*.po locale/*.mo locale/roundup.pot

Roundup Issue Tracker: http://roundup-tracker.org/