Ticket #5929 task new

Opened 9 months ago

Last modified 10 days ago

Port remaining parts of twisted.python.reflect to Python 3

Reported by: exarkun Owned by:
Priority: normal Milestone: Python-3.x
Component: core Keywords: py3k review
Cc: thijs Branch:
Author: Launchpad Bug:

Description

Many parts of twisted.python.reflect were individually ported to Python 3 as part of the Python 3 minimal milestone. These were moved into twisted.python._reflectpy3 due to technical limitations of the approach taken to porting.

For the full Python 3 port, all the rest of twisted.python.reflect needs to be ported (except for deprecated APIs that we can delete instead). As part of this, twisted/python/_reflectpy3.py should be eliminated and its contents put back into twisted/python/reflect.py.

The test suite, similarly divided, should also be re-unified. One minor but important part of this will be fixing the import of _fullyQualifiedName in twisted.python.test.test_reflectpy3. It is currently not possible to import twisted.python.reflect.fullyQualifiedName, but once twisted.python.reflect is ported it will be, and that spelling should be preferred over twisted.python._deprecatepy3._fullyQualifiedName for the testing of fullyQualifiedName.

Attachments

python3-reflect-5929-1.patch Download (1.3 KB) - added by multani 10 days ago.
python3-reflect-5929-1.2.patch Download (102.4 KB) - added by multani 10 days ago.
python3-reflect-5929-2.patch Download (102.3 KB) - added by multani 10 days ago.

Change History

1

Changed 3 months ago by thijs

  • cc thijs added
  • type changed from enhancement to task

2

Changed 10 days ago by multani

I started to port the rest of t.p.reflect to Python according to the indications in this ticket.

I have a few questions though, before uploading a first patch:

* it is said: (except for deprecated APIs that we can delete instead). There are several deprecations from Twisted 11.0.0 and 12.1.0. Most of them are portable (I already ported them actually), but should they be really deleted instead?

* I'm not sure how I should handle the move of _fullyQualifiedName from t.p.deprecate back to t.p.reflect, since deprecate uses fullyQualifiedName and reflect use the deprecation functions from deprecate so there will be a circular dependency between them. Or maybe I misunderstood something?

* Finally, I still have a test failure with Python 3 regarding the tests from twisted.test.test_reflect.GetClass http://twistedmatrix.com/trac/browser/trunk/twisted/test/test_reflect.py#L296 "Old-style" classes don't exist anymore in Python 3, and both classes as written in the test are reflected as the same kind of class. I will probably propose a fix that basically offers a specific version of this class for Python 3 which will expect the same result for both kind of classes. Is there's a preferred way to handle it?

The current state of the patch is available on a Git branch at  https://github.com/multani/twisted/tree/python3-reflect-5929

2

Changed 10 days ago by multani

I started to port the rest of t.p.reflect to Python according to the indications in this ticket.

I have a few questions though, before uploading a first patch:

* it is said: (except for deprecated APIs that we can delete instead). There are several deprecations from Twisted 11.0.0 and 12.1.0. Most of them are portable (I already ported them actually), but should they be really deleted instead?

* I'm not sure how I should handle the move of _fullyQualifiedName from t.p.deprecate back to t.p.reflect, since deprecate uses fullyQualifiedName and reflect use the deprecation functions from deprecate so there will be a circular dependency between them. Or maybe I misunderstood something?

* Finally, I still have a test failure with Python 3 regarding the tests from twisted.test.test_reflect.GetClass http://twistedmatrix.com/trac/browser/trunk/twisted/test/test_reflect.py#L296 "Old-style" classes don't exist anymore in Python 3, and both classes as written in the test are reflected as the same kind of class. I will probably propose a fix that basically offers a specific version of this class for Python 3 which will expect the same result for both kind of classes. Is there's a preferred way to handle it?

The current state of the patch is available on a Git branch at  https://github.com/multani/twisted/tree/python3-reflect-5929

2

Changed 10 days ago by multani

I started to port the rest of t.p.reflect to Python according to the indications in this ticket.

I have a few questions though, before uploading a first patch:

* it is said: (except for deprecated APIs that we can delete instead). There are several deprecations from Twisted 11.0.0 and 12.1.0. Most of them are portable (I already ported them actually), but should they be really deleted instead?

* I'm not sure how I should handle the move of _fullyQualifiedName from t.p.deprecate back to t.p.reflect, since deprecate uses fullyQualifiedName and reflect use the deprecation functions from deprecate so there will be a circular dependency between them. Or maybe I misunderstood something?

* Finally, I still have a test failure with Python 3 regarding the tests from twisted.test.test_reflect.GetClass http://twistedmatrix.com/trac/browser/trunk/twisted/test/test_reflect.py#L296 "Old-style" classes don't exist anymore in Python 3, and both classes as written in the test are reflected as the same kind of class. I will probably propose a fix that basically offers a specific version of this class for Python 3 which will expect the same result for both kind of classes. Is there's a preferred way to handle it?

The current state of the patch is available on a Git branch at  https://github.com/multani/twisted/tree/python3-reflect-5929

2

Changed 10 days ago by multani

I started to port the rest of t.p.reflect to Python according to the indications in this ticket.

I have a few questions though, before uploading a first patch:

* it is said: (except for deprecated APIs that we can delete instead). There are several deprecations from Twisted 11.0.0 and 12.1.0. Most of them are portable (I already ported them actually), but should they be really deleted instead?

* I'm not sure how I should handle the move of _fullyQualifiedName from t.p.deprecate back to t.p.reflect, since deprecate uses fullyQualifiedName and reflect use the deprecation functions from deprecate so there will be a circular dependency between them. Or maybe I misunderstood something?

* Finally, I still have a test failure with Python 3 regarding the tests from twisted.test.test_reflect.GetClass http://twistedmatrix.com/trac/browser/trunk/twisted/test/test_reflect.py#L296 "Old-style" classes don't exist anymore in Python 3, and both classes as written in the test are reflected as the same kind of class. I will probably propose a fix that basically offers a specific version of this class for Python 3 which will expect the same result for both kind of classes. Is there's a preferred way to handle it?

The current state of the patch is available on a Git branch at  https://github.com/multani/twisted/tree/python3-reflect-5929

3

Changed 10 days ago by multani

  • keywords py3k review added

[Sorry for the duplicated messages, Trac got stuck waiting for the first one, and I did POST several others thinking the first ones weren't working :[ ]

I solved the first two points after the answer of exarkun on the mailing list (which basically said to remove deprecated objects), which allowed me to move back fullyQualifiedName back to t.p.reflect

I proposed a not-so-good fix for the 3rd point, I'm open to better suggestion.

Changed 10 days ago by multani

Changed 10 days ago by multani

Changed 10 days ago by multani

2

Changed 10 days ago by multani

I started to port the rest of t.p.reflect to Python according to the indications in this ticket.

I have a few questions though, before uploading a first patch:

* it is said: (except for deprecated APIs that we can delete instead). There are several deprecations from Twisted 11.0.0 and 12.1.0. Most of them are portable (I already ported them actually), but should they be really deleted instead?

* I'm not sure how I should handle the move of _fullyQualifiedName from t.p.deprecate back to t.p.reflect, since deprecate uses fullyQualifiedName and reflect use the deprecation functions from deprecate so there will be a circular dependency between them. Or maybe I misunderstood something?

* Finally, I still have a test failure with Python 3 regarding the tests from twisted.test.test_reflect.GetClass http://twistedmatrix.com/trac/browser/trunk/twisted/test/test_reflect.py#L296 "Old-style" classes don't exist anymore in Python 3, and both classes as written in the test are reflected as the same kind of class. I will probably propose a fix that basically offers a specific version of this class for Python 3 which will expect the same result for both kind of classes. Is there's a preferred way to handle it?

The current state of the patch is available on a Git branch at  https://github.com/multani/twisted/tree/python3-reflect-5929

2

Changed 10 days ago by multani

I started to port the rest of t.p.reflect to Python according to the indications in this ticket.

I have a few questions though, before uploading a first patch:

* it is said: (except for deprecated APIs that we can delete instead). There are several deprecations from Twisted 11.0.0 and 12.1.0. Most of them are portable (I already ported them actually), but should they be really deleted instead?

* I'm not sure how I should handle the move of _fullyQualifiedName from t.p.deprecate back to t.p.reflect, since deprecate uses fullyQualifiedName and reflect use the deprecation functions from deprecate so there will be a circular dependency between them. Or maybe I misunderstood something?

* Finally, I still have a test failure with Python 3 regarding the tests from twisted.test.test_reflect.GetClass http://twistedmatrix.com/trac/browser/trunk/twisted/test/test_reflect.py#L296 "Old-style" classes don't exist anymore in Python 3, and both classes as written in the test are reflected as the same kind of class. I will probably propose a fix that basically offers a specific version of this class for Python 3 which will expect the same result for both kind of classes. Is there's a preferred way to handle it?

The current state of the patch is available on a Git branch at  https://github.com/multani/twisted/tree/python3-reflect-5929

Note: See TracTickets for help on using tickets.