homepage

This is to keep track of who is working on what for PEP 3108 
(http://www.python.org/dev/peps/pep-3108/). Once something is complete it 
should be denoted in the PEP itself, so always check the PEP to see what 
is left to be done (for both 2.6 and 3.0).

I'm working on the new urllib package.

I'm working on removing mac modules.

I am working on audiodev to get the basic structure of removals worked out 
(testing infrastructure, etc.).

For the TextMate users, I am going to be checking in a Python-Dev bundle 
into svn soon which will include a command to insert the warnpy3k() call 
for module deletions. Might want to wait for that if you want to cut out 
at least one copy-and-paste step. =)

If you use TextMate, get the Python-Dev bundle and use the command in 
there to insert the deprecation boilerplate for removing a module.

I'm working on removing symtable/_symtable

I'm working on creating http package with httplib, BaseHTTPServer,
CGIHTTPServer, SimpleHTTPServer, Cookie and cookielib

Here is a patch for the Queue module renaming - I can not easily do the 
actual svn rename to the lowercase queue myself (it's easier to do it with 
commit privs). Tests pass, documentation updated as well.

Here is a patch for the required changes to rename SocketServer.py - tests 
pass after I manually rename SocketServer.py locally. Again skipping the 
svn rename of the actual module. Doc updates included.

I'm working on xmlrpc/* changes

I think we should move robotparser into the urllib package. Anyone
disagree?
Jeremy

Should DocXMLRPCServer.py be moved into xmlrpc/ as well?

On Sat, May 10, 2008 at 12:29 PM, Jesse Noller <report@bugs.python.org> wrote:
>
> Jesse Noller <jnoller@gmail.com> added the comment:
>
> Should DocXMLRPCServer.py be moved into xmlrpc/ as well?
Yes, and end up in the server module. That was just an oversight on my
part. The PEP has been updated.

I add deprecated warnings symtable/_symtable in python 2.6

Just so people know, I have emailed python-dev about renaming urllib as I 
realized there are some issues with the solution proposed in the PEP.

The files Python/compile.c and Python/pythonrun.c depends of the
_symtable (Python/symtable.c and Include/symtable.h).
What I do for remove _symtable in py3k?

Andrews, this discussion would be more appropriate to the mailing list, 
but anyway: I believe you're mixing things up. When PEP 3108 says "remove 
symtable/_symtable", it must be talking only about symtable.py and 
symtablemodule.c, not symtable.[ch] (used by the compiler).

I'm working on the new package tkinter and dialogs merging where
appropriate.

Patch regarding the move to tkinter package added.
What this patch does
--------------------
* Moved lib-tk to tkinter and renamed modules according to PEP 3108
* Merged tkFileDialog into filedialog 
* Merged tkSimpleDialog into simpledialog 
* Updated imports in pydoc
* Updated imports in idlelib
* Updated imports in Tools and Demos
* Changed lib-tk to tkinter at Makefile.pre.in
* Removed TKPATH from Modules/Setup.dist
* Removed references of lib-tk at PC/
What has to be done
-------------------
* Update iss script at PC/ to change lib-tk to tkinter
* Update docs
* stub modules ?

I'm working on creating html package with HTMLParser and htmlentitydefs

Just so people know, feel free to create new issues for stuff if you want. 
Other issues can be made dependencies of this issue very easily.

New patch regarding the move to tkinter package, now with docs updated.
This one should be the "final" patch, and while the patch is relatively
large it mostly trivial to review.

For to remove the htmllib on Python 3000 is need to removed these files:
Lib/htmllib.py
Lib/test_htmllib.py
And apply this patch

I'm working on renaming the ConfigParser module.

I've somehow lost my xmlrpc* changes on my local machine - if someone else 
gets to it before me, feel free to work on it.

I almost finished the http package patch, but I'm doubt about how I
would do it with Docs.
There are various doc files: basehttpserver.rst, cgihttpserver.rst,
httplib.rst and so on.
Would I join them into one's or only update their information (imports) ?

Keep one file per submodule, but rename them to the new names, and
update all references to the old name.
If the new toplevel package (http in this case) contains something,
there must be a new file for it.

I've finished a patch for http package, but I've doubts about how to
make a patch.
I've used a svn diff and svn status to make the patch and status file
respectively.

Output for svn status of http package patch.

On Wed, May 14, 2008 at 6:33 PM, Juracy Filho <report@bugs.python.org> wrote:
>
> Juracy Filho <juracy@gmail.com> added the comment:
>
> I've finished a patch for http package, but I've doubts about how to
> make a patch.
>
> I've used a svn diff and svn status to make the patch and status file
> respectively.
That should be enough. Thanks, Juracy!

I've found some places where configparser, copyreg, queue and
socketserver haven't been renamed. The attached patch
'renaming_leftovers_2.6.patch' corrects this.
I'm working on renaming markupbase in 2.6 as of now.

Removing htmllib is not as simple as just removing the modules as pydoc 
uses htmllib.

Issue 2883 is where future http package stuff should occur. I referenced 
this issue for initial patches.

Issue 2884 references this issue as it is to be used to tracker the new 
tkinter package.

I have created an individual issue for every major step left in 
implementing PEP 3108. Each one that is still open is now listed as a 
dependency for this issue.

Quentin Gallet-Gilles wrote:
> I've found some places where configparser, copyreg, queue and
> socketserver haven't been renamed. The attached patch
> 'renaming_leftovers_2.6.patch' corrects this.
Thanks! Applied in r63384.

The html package has been created (issue 2882).

I have now removed the closed issues as dependencies. Thanks to everyone 
who has helped so far! You have no idea how appreciative I am.

OK, so it turns out the way renames have been handled breaks pre-existing 
pickles. That means that the stubs in 2.6 will actually have to be the new 
names and not the old ones.
I will work with the stdlib-sig to try to come up with a reasonable way to 
rectify the situation, but until then do NOT check in any rename patches.

Because of pickle compatibility in 2.x, all renames in the trunk need to 
be reverted. Work in 3.0 is still fine and won't be touched.
I have already updated the PEP with the new steps required for renames.

I'm working on issue 2873 (remove htmllib dependency from pydoc).

On May 21, 2008, at 10:16 AM, Mark Dickinson wrote:
> I'm working on issue 2873 (remove htmllib dependency from pydoc).
Thanks, Mark! I was dreading the thought of looking at that.

While working on the commands module removal, I found two missed import
renaming in the py3k branch that made regrtest skip some tests. The
attached patch corrects them.

On Fri, May 23, 2008 at 7:49 AM, Quentin Gallet-Gilles
<report@bugs.python.org> wrote:
>
> Quentin Gallet-Gilles <qgallet@gmail.com> added the comment:
>
> While working on the commands module removal, I found two missed import
> renaming in the py3k branch that made regrtest skip some tests. The
> attached patch corrects them.
The test_tcl one was fixed in 2.6 (when we were renaming) and will be
merged into Py3k. I will catch the test_1413192.py. Thanks!
>
> Added file: http://bugs.python.org/file10416/import_renames_py3k.patch
>
> __________________________________
> Tracker <report@bugs.python.org>
> <http://bugs.python.org/issue2775>
> __________________________________
>

Done with pickle and stringio.

We've got what we've got for the first betas.

Not creating new bug entry because everybody can quickly fix it.
In urllib/request.py some instances of URLError are raised with "raise
urllib.error.URLError" and this works, buth there are lines with "raise
URLError" which produces "NameError: global name 'URLError' is not defined"

Fixed in r64624.

For those of you following along, the only thing keeping PEP 3108 and
this issue from being finished are the two dependent issues: os.stat and
profile/cProfile.

I found some bsddb code left in setup.py. Patch attached.

Thanks for the patch. Applied in r738067.

Modules "hotshot" and "xmllib" give deprecation warnings. But they are not part of PEP 3108 or PEP 4.

I don't know why hotshot was deprecated specifically for Python 3 as that was never directly part of the discussion for PEP 3108. As for xmllib, that is most likely an oversight. Either way they should get added to the relevant PEPs.

I am very glad you're reorganizing the Standard Library. Thumbs up! I hope everything will comply to PEP 8 after you're done.
Since you're reorganizing, I have my own contribution. I have uploaded a patch. The issue7351 (http://bugs.python.org/issue7351) was not accepted at the time, I hope you'll accept this fix now.
My point is that every class name in module zipfile is like this:
- exception class: LargeZipFile
- normal class: ZipFile
- normal class: PyZipFile
So apply my fix to make the exception class BadZipfile consistent to others and let it be BadZipFile.
Thank you.

The reorganization is over short of one or two lasting changes that may not even be made now. New suggestions are not directly being discussed here and would have to be taken up on python-dev.

Can you send my patch and comment to python-dev? Because I don't know how to. I don't know where is python-dev and what exactly you mean by this.

No. Best I can do is suggest you perform an internet search on the term as it makes it obvious what python-dev is.

My patch "zipfile-patch.diff" was sent to python-dev. Please act on it as you see fit. Thank you.

Did you manage to apply my fix "zipfile-patch.diff" to the trunk?

If any action regarding your patch takes place there will be a comment here about it. Until then assume nothing has happened.

Shouldn't this be closed? Most of this has been done and we can't do the rest anyway, without breaking backwards compatibility.

profile and cProfile could still conceivably be merged, even if it is under a new name if someone found the time to do the compatibility work.

I will have a go at the profiler situation.
I imagine the following: deprecate the cProfile module, and provide both profiler classes from the profile module -- e.g. as PythonProfile and CProfile, and provide Profile = PythonProfile. (From cProfile.py, obviously Profile = CProfile). A lot of the interface (module-level helpers and script entry) are near duplicated anyway.
In 3.3, the default Profile could then be reassigned to CProfile.

Alas, too late for 3.2 now.

Just so people know, if the profile situation isn't resolved by 3.3 I'm considering PEP 3108 done.
IOW, if anyone wants to step forward and deal with cProfile/profile, that would be appreciated. =)

For the stat module in the "Obsolete" section[1], should the entry be updated to indicate that the module was left alone (see issue 2874)?
Would it be worth having the "Merging C and Python Impl..." section[2] include a reference to PEP 399?
[1] http://www.python.org/dev/peps/pep-3108/#obsolete
[2] http://www.python.org/dev/peps/pep-3108/#merging-c-and-python-implementations-of-the-same-interface 

Answers to Eric's questions: yes and yes, but I probably won't bother until I do a final update to the PEP.

Brett, issue 2919 had a patch that merges profile/cProfile for a while now but nobody test it yet.
All I need it someone to download the patch, install it, test it on some random script and tell me if it works. I don't need more.

> Brett, issue 2919 had a patch that merges profile/cProfile for a while 
> now but nobody test it yet.
> All I need it someone to download the patch, install it, test it on
> some random script and tell me if it works. I don't need more.
I don't see any patch there, only a .tgz and two Python files.

I think we are as close as we are going to get with PEP 3018 being implemented. if profile/cProfile ever get merged that is great (issue #16492), but I'm not holding my breath and thus I am closing this issue.