[issue15787] PEP 3121, 384 Refactoring

[Mark Lawrence]

Change by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15787] PEP 3121, 384 Refactoring

[Nick Coghlan]

Changes by Nick Coghlan :


--
nosy: +ncoghlan

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15787] PEP 3121, 384 Refactoring

[Stefan Krah]

Changes by Stefan Krah :


--
nosy:  -skrah

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15787] PEP 3121, 384 Refactoring

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
nosy: +BreamoreBoy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15787] PEP 3121, 384 Refactoring

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

I strongly believe that it is worthwhile to invest in fixing abitype.py.  It is 
much easier to review a patch to one python script than to review 50+ patches 
to C files.  There is no excuse for this tool not to work on all stdlib 
modules.  If there are any specific issues with the way individual modules are 
written that prevent automatic conversion, I would prefer to make a coding 
style change first and then include all modules in one automated PEP 384 
conversion.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15787] PEP 3121, 384 Refactoring

[Robin Schreiber]

Robin Schreiber added the comment:

I have in fact used abitype.py to produce all of my PEP 384 patches, however it 
failed to work correctly in like 50% of all cases, and I had to complete the 
rest of the patch by hand.I thought about correcting the abitype.py throughout 
the GSOC, but I happened to find it easier to simply do the missing steps by 
hand. (I don't know If the script has been fixed up to this point though).
In any case, it might also be interesting for external extension module 
developers to make use of a fully working version of this script, so they can 
make their modules PEP 384 compliant without investing too much time.
One has to keep in mind however that almost any script will fail to work by 
itself, once we run into problems like refcounting or concurrency when applying 
the patch to a module.

I will have some free time throughout next week and will start to correct the 
patches for the xx modules (as Alex proposed), and continue from there to all 
the other patches I have submitted a year ago.

I am deeply sorry that I have not continued my work on this project earlier, 
however I dramatically underestimated the amount if work related to university, 
etc... I still feel obliged to complete all these patches.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15787] PEP 3121, 384 Refactoring

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

With respect to PEP 384 refactoring, I would like to see 
Tools/scripts/abitype.py used for most of the conversions.  The PEP itself can 
probably be amended to advertise this tool more prominently.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15787] PEP 3121, 384 Refactoring

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

"""
Regarding the suggestion of separating PEP3121 and PEP384. It might be true 
that datetime and other modules do not benefit directly from PEP 384, however 
it is still a fact that the stdlib modules should be seen as a set of reference 
modules, that are all implemented in a way that complies with the 
implementation fo the xxmodules.
I have talked with Martin von Löwis about this, and as far as I understood him 
correctly he also sees the PEP384 refactoring applied to the whole stdlib as a 
necessary "signal" to other developers to refactor their modules accordingly.
""" (Robin Schreiber, #15390, msg177274)

MvL have recently confirmed this on python-dev: "Choice of supporting PEP 384 
was deliberate. It will change all types into heap types, which is useful for 
multiple-interpreter support and GC."

Accordingly, I've changed the title of this issue and added a few PEP 384 only 
dependencies.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15787] PEP 3121, 384 Refactoring

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15787] PEP 3121, 384 Refactoring

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
dependencies: +PEP 384 inconsistent with implementation

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15787] PEP 3121, 384 Refactoring

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
dependencies: +PEP 384 Refactoring applied to _csv module
title: PEP 3121 Refactoring -> PEP 3121, 384 Refactoring

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com