[issue20347] dir(__future__) gives segfault on OS X in 3.2 and 3.3

New submission from Christopher the Magnificent: On OS X 10.9.1 This works: Python 2.7.5 (default, Aug 25 2013, 00:04:04) [GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin Type "help", "copyright", "credits" or "license" for more in

[issue16271] weird dual behavior with changing __qualname__; different values observed through attribute and descriptor

New submission from Christopher the Magnificent: The output below is NOT typed at the Python interactive interpeter. The ">>> " shows what is being evaluated and the line below it shows what the result it. The output gets generated here: (lines 418-449 of the atta

[issue16267] order of decorators @abstractmethod and @classmethod is significant (is not documented to be in @abstractclassmethod which advises their combined use)

Christopher the Magnificent added the comment: As Darren Dale pointed out, it looks like this is a (partial) documentation issue. I think it's plausible that someone like me, who has used abstractmethod by itself, would read the docs for abstractclassmethod and not re-read the do

[issue16268] dir(closure) claims that a closure has no __dir__, only to work later after manually invoking __dir__ from its type

New submission from Christopher the Magnificent: This is really short, you should spot the inconsistency in the result of the same function call fairly easily. Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 01:25:11) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "

[issue16267] order of decorators @abstractmethod and @classmethod is significant (is not documented to be in @abstractclassmethod which advises their combined use)

New submission from Christopher the Magnificent: This may be an issue with the interpreter behavior or it may be a documentation issue. Note: I only selected Python 3.3 as the version, but it probably affects MANY other Python versions. Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 01:25

[issue15343] "pydoc -w " writes out page with empty "Package Contents" section

Christopher the Magnificent added the comment: ISSUE CONFIRMED FIXED ON MY END, AND MANY THANKS I downloaded, compiled, and installed the latest Python 3.3 beta on my machine with Mercurial, and can confirm that the problem is no longer presenting itself. Thank you and great job to you smart

[issue15343] "pydoc -w " writes out page with empty "package contents" section

Changes by Christopher the Magnificent : -- title: "pydoc -w " write out page with empty "package contents" section -> "pydoc -w " writes out page with empty "package contents" section ___ Python

[issue15343] "pydoc -w " writes out page with empty "Package Contents" section

Changes by Christopher the Magnificent : -- title: "pydoc -w " writes out page with empty "package contents" section -> "pydoc -w " writes out page with empty "Package Contents" section ___ Python

[issue15343] "pydoc -w " write out page with empty "package contents" section

New submission from Christopher the Magnificent : Let there be a folder "testpkg" contained in $SOME_DIR with three empty files: "__init__.py", "bob.py", and "sally.py If I run "pydoc3.2 -w testpkg" inside $SOME_DIR, it will output the file $SOME

[issue13581] help() appears to be broken; doesn't display __doc__ for class type when called as help(type)

New submission from Christopher the Magnificent : observe help(type) and type.__doc__ in Python 3.1: >>> help(type) Help on class type in module builtins: class type(object) | type(object) -> the object's type | type(name, bases, dict) -> a new type | |

[issue8030] documentation bugs and improvements

New submission from Christopher the Magnificent : Help for list looks like this: >>> help(list) class list(object) | list() -> new list | list(sequence) -> new list initialized from sequence's items | Help for dict looks like this