[issue23189] Set docstrings to empty string when optimizing with -OO.

2015-07-08 Thread Erik Bray

Erik Bray added the comment:

For what it's worth (since it was mentioned toward the end of this thread as an 
offending package) Astropy has a patch now to fix its misbehavior with respect 
to this issue.

I do feel like this would be nice to fix though, since I think it's awkward to 
have code that on its face clearly has a docstring, but still have to check 
that the docstring may be None.  Just to put it out there if anyone were really 
interested, I identified two ways this could be changed:

1) For functions add a new co_flags flag indicating that docstrings were 
optimized out.  This is at the cost of a co_flags flag.

2) Keep an empty string as the first element in co_consts, at the const of one 
additional constant per function that previously had a docstring (still cheaper 
than the docstring itself in most cases).

Of course, it would still break backward compatibility for code that expects 
None for an optimized out docstring, I guess, and probably isn't worth either 
of the above two sacrifices at the end of the day.

--
nosy: +erik.bray

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



[issue23189] Set docstrings to empty string when optimizing with -OO.

2015-01-13 Thread Raymond Hettinger

Raymond Hettinger added the comment:

 Here are some of the packages that run into trouble
 when the docstrings are set to 'None' by the -OO optimization

I think you should file bug reports for those packages.

We've agreed here that the current behavior is correct and that the proposed 
change in backward incompatible, so I'm gone to close this one as not a bug.  
 Perhaps, some not in the docs for packaging and distributing python would be 
appropriate and perhaps some PEP-8 guidance for avoiding __doc__+='moredocs' 
without first checking whether __doc__ is None.

--
resolution:  - not a bug
status: open - closed

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



[issue23189] Set docstrings to empty string when optimizing with -OO.

2015-01-12 Thread Jarle Selvåg

Jarle Selvåg added the comment:

I agree that -OO does what (people have agreed) it's supposed to do.

Many packages manipulates the docstring without checking for 'None' (see list 
below). For many package developers, it seems hard to remember that the 
docstrings may disappear after optimization. This behavior is not intuitive. At 
least in cases where the docstring is set to a string value, the expected 
behavior in my opinion would be to set its value to an empty string during 
optimization with -OO.

Here are some of the packages that run into trouble when the docstrings are set 
to 'None' by the -OO optimization:
algopy
astropy
lmfit
pyamg
pyvisa
mpl_toolkits
sympy
statsmodels
patsy
sklearn

--

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



[issue23189] Set docstrings to empty string when optimizing with -OO.

2015-01-09 Thread Raymond Hettinger

Raymond Hettinger added the comment:

It seems to me that the problem here lies with the packages that use 
__doc__+=sometext rather than with -OO which is doing exactly what it is 
supposed to.

--
nosy: +rhettinger

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



[issue23189] Set docstrings to empty string when optimizing with -OO.

2015-01-08 Thread Jarle Selvåg

New submission from Jarle Selvåg:

Python code byte-compiled with -OO has doc-strings stripped out. 

This creates problems when compiling different packages which changes the 
doc-strings by doing something like this:
 __doc__ += additional text
(when the docstring is 'None', this will fail).

The packages lmfit 0.8.1 and Patsy 0.3.0 have this problem, and must be 
patched before compilation.

See related discussion on Stackoverflow:
http://stackoverflow.com/questions/22299532/unsupported-operand-types-for-nonetype-and-str-winappdbg-error-after-c

Proposal: Set the doc-strings to empty string () instead of removing them 
completely during optimization with -OO. The memory footprint would anyway be 
the same.

--
components: Interpreter Core
messages: 233634
nosy: jvs
priority: normal
severity: normal
status: open
title: Set docstrings to empty string when optimizing with -OO.
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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



[issue23189] Set docstrings to empty string when optimizing with -OO.

2015-01-08 Thread Jarle Selvåg

Jarle Selvåg added the comment:

This issue is only relevant for classes that have this construct:

class MyClass(object):
__doc__ += '''Some more text'''


--

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



[issue23189] Set docstrings to empty string when optimizing with -OO.

2015-01-08 Thread Barry A. Warsaw

Barry A. Warsaw added the comment:

That's a backward compatibility break since existing code may be expecting 
None.  At least it needs to be carefully considered, and should have no 
possibility of be applied to anything before Python 3.5.

--
nosy: +barry
versions:  -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.6

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