[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 information. import __future__ dir(__future__) ['CO_FUTURE_ABSOLUTE_IMPORT', 'CO_FUTURE_DIVISION', 'CO_FUTURE_PRINT_FUNCTION', 'CO_FUTURE_UNICODE_LITERALS', 'CO_FUTURE_WITH_STATEMENT', 'CO_GENERATOR_ALLOWED', 'CO_NESTED', '_Feature', '__all__', '__builtins__', '__doc__', '__file__', '__name__', '__package__', 'absolute_import', 'all_feature_names', 'division', 'generators', 'nested_scopes', 'print_function', 'unicode_literals', 'with_statement'] This also works: Python 3.1 (r31:73578, Jun 27 2009, 21:49:46) [GCC 4.0.1 (Apple Inc. build 5493)] on darwin Type help, copyright, credits or license for more information. import __future__ dir(__future__) ['CO_FUTURE_ABSOLUTE_IMPORT', 'CO_FUTURE_BARRY_AS_BDFL', 'CO_FUTURE_DIVISION', 'CO_FUTURE_PRINT_FUNCTION', 'CO_FUTURE_UNICODE_LITERALS', 'CO_FUTURE_WITH_STATEMENT', 'CO_GENERATOR_ALLOWED', 'CO_NESTED', '_Feature', '__all__', '__builtins__', '__doc__', '__file__', '__name__', '__package__', 'absolute_import', 'all_feature_names', 'barry_as_FLUFL', 'division', 'generators', 'nested_scopes', 'print_function', 'unicode_literals', 'with_statement'] In Python 3.2 and 3.3 it appears broken. Python 3.2.2 (v3.2.2:137e45f15c0b, Sep 3 2011, 17:28:59) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type help, copyright, credits or license for more information. import __future__ dir(__future__) Segmentation fault: 11 also 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 help, copyright, credits or license for more information. import __future__ dir(__future__) Segmentation fault: 11 -- assignee: ronaldoussoren components: Macintosh messages: 208819 nosy: christopherthemagnificent, ronaldoussoren priority: normal severity: normal status: open title: dir(__future__) gives segfault on OS X in 3.2 and 3.3 type: crash versions: Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20347 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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:11) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type copyright, credits or license() for more information. import abc help(abc.abstractclassmethod) Help on class abstractclassmethod in module abc: class abstractclassmethod(builtins.classmethod) | A decorator indicating abstract classmethods. | | Similar to abstractmethod. | | Usage: | | class C(metaclass=ABCMeta): | @abstractclassmethod | def my_abstract_classmethod(cls, ...): | ... | | 'abstractclassmethod' is deprecated. Use 'classmethod' with | 'abstractmethod' instead. . (et cetra) . . # doesn't work class Demo(metaclass=abc.ABCMeta): ... @abc.abstractmethod ... @classmethod ... def test(cls): ... pass ... Traceback (most recent call last): File pyshell#26, line 1, in module class Demo3(metaclass=abc.ABCMeta): File pyshell#26, line 3, in Demo3 @classmethod File /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/abc.py, line 24, in abstractmethod funcobj.__isabstractmethod__ = True AttributeError: attribute '__isabstractmethod__' of 'classmethod' objects is not writable # DOES work class Demo2(metaclass=abc.ABCMeta): ... @classmethod ... @abc.abstractmethod ... def test(cls): ... pass ... Demo2() Traceback (most recent call last): File pyshell#33, line 1, in module Demo4() TypeError: Can't instantiate abstract class Demo2 with abstract methods test Hopefully this is enough documentation to show what the issues is. If not, just chime in. :-) -- assignee: docs@python components: Documentation, Interpreter Core messages: 173183 nosy: christopherthemagnificent, docs@python priority: normal severity: normal status: open title: order of decorators @abstractmethod and @classmethod is significant (is not documented to be in @abstractclassmethod which advises their combined use) type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16267 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 help, copyright, credits or license for more information. class Thing: ... def method(self): ... print(__class__) ... x = Thing.method.__closure__[0] dir(x) Traceback (most recent call last): File stdin, line 1, in module TypeError: object does not provide __dir__ type(x).__dir__(x) ['__gt__', '__eq__', '__setattr__', '__doc__', '__sizeof__', '__str__', '__init__', '__repr__', 'cell_contents', '__dir__', '__ge__', '__class__', '__new__', '__ne__', '__subclasshook__', '__hash__', '__lt__', '__reduce__', '__le__', '__getattribute__', '__format__', '__reduce_ex__', '__delattr__'] dir(x) ['__class__', '__delattr__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'cell_contents'] -- components: Interpreter Core messages: 173197 nosy: christopherthemagnificent priority: normal severity: normal status: open title: dir(closure) claims that a closure has no __dir__, only to work later after manually invoking __dir__ from its type type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16268 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 docs on abstract method to know that he needs to put the one decorator first and other other second. Changing Python to make it indifferent to the order of classmethod and abstractmethod wouldn't be a bad idea if it isn't too hairy to implement, since it does not seem to be intuitive to me and probably others that the order of the decorators in this specific situation should matter. At bare minimum, I recommend that the documentation for abstractclassmethod and abstractstaticmethod should be updated to indicate not merely that abstractmethod and either classmethod or staticmethod should be used together, but IN WHICH ORDER they should be used, if it is decided to preserve the sensitivity to ordering. :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16267 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 attached file)
def name_globalize_class(name, second=None):
def decorator(cls):
def printval(source, value=None):
print( + source)
if value is not None:
print(repr(value))
print(in decorator: new name is:, repr(name))
print()
printval(cls, cls)
printval(cls.__name__, cls.__name__)
printval(cls.__qualname__, cls.__qualname__)
printval('type.__dict__[__qualname__].__get__(cls)',
type.__dict__[__qualname__].__get__(cls))
print()
cls.__name__ = name
cls.__qualname__ = name
stuff = cls.__name__ = {0}\n cls.__qualname__ = {0}\n
print(stuff.format(repr(name)))
printval(cls.__name__, cls.__name__)
printval(cls.__qualname__, cls.__qualname__)
printval('type.__dict__[__qualname__].__get__(cls)',
type.__dict__[__qualname__].__get__(cls))
printval(cls, cls)
print()
globals()[name] = cls
pdb.set_trace()
return cls
return decorator
HERE IS THE OUTPUT:
cls
class '__main__._maketokensnodes.locals._TokenClass'
cls.__name__
'_TokenClass'
cls.__qualname__
'_maketokensnodes.locals._TokenClass'
type.__dict__[__qualname__].__get__(cls)
'_maketokensnodes.locals._TokenClass'
cls.__name__ = 'KEYWORD'
cls.__qualname__ = 'KEYWORD'
cls.__name__
'KEYWORD'
cls.__qualname__
'KEYWORD'
type.__dict__[__qualname__].__get__(cls)
'_maketokensnodes.locals._TokenClass'
cls
class '__main__._maketokensnodes.locals._TokenClass'
END OF OUTPUT
Note how after assigning to cls.__qualname__ it looks like the class's
dictionary object has been assigned into, masking the class's C-level type
attribute-level ht_qualname!
My gut feeling is that this has to be some kind of a bug. Let me know if it is.
--
components: Interpreter Core
files: parser_BUGGY2.py
messages: 173217
nosy: christopherthemagnificent
priority: normal
severity: normal
status: open
title: weird dual behavior with changing __qualname__; different values
observed through attribute and descriptor
versions: Python 3.3
Added file: http://bugs.python.org/file27604/parser_BUGGY2.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16271
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15343] pydoc -w package writes out page with empty Package Contents section
Christopher the Magnificent ultimate.mac.fana...@gmail.com 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 people that know the guts of Python and its libraries, who coordinated and coded to get this fixed, especially Mr. Nick Coghlan, who it appears took on the responsibility for resolving this. My hat is off to you all! --Christopher P. S. I'm fairly new to the bug forums. If anyone is bothered that I wrote this after the issue closed, just let me know what the policy is so I can learn to adapt to it. If no one complains, I will assume it was okay in this instance. :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15343 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15343] pydoc -w package write out page with empty package contents section
New submission from Christopher the Magnificent ultimate.mac.fana...@gmail.com: 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_DIR/testpkg.html In testpkg.html there will be a section called Package Contents with two links named bob and sally. If I instead run pydoc3.3 -w testpkg inside $SOME_DIR, it will still output the file $SOME_DIR/testpkg.html Only this time, in testpkg.html the section called Package Contents will be empty when there should be links named bob and sally -- messages: 165352 nosy: christopherthemagnificent priority: normal severity: normal status: open title: pydoc -w package write out page with empty package contents section type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15343 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15343] pydoc -w package writes out page with empty Package Contents section
Changes by Christopher the Magnificent ultimate.mac.fana...@gmail.com: -- title: pydoc -w package writes out page with empty package contents section - pydoc -w package writes out page with empty Package Contents section ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15343 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15343] pydoc -w package writes out page with empty package contents section
Changes by Christopher the Magnificent ultimate.mac.fana...@gmail.com: -- title: pydoc -w package write out page with empty package contents section - pydoc -w package writes out page with empty package contents section ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15343 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13581] help() appears to be broken; doesn't display __doc__ for class type when called as help(type)
New submission from Christopher the Magnificent
ultimate.mac.fana...@gmail.com:
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
|
| Methods defined here:
|
| __call__(...)
| x.__call__(...) == x(...)
|
| __delattr__(...)
| x.__delattr__('name') == del x.name
|
| __getattribute__(...)
| x.__getattribute__('name') == x.name
|
| __init__(...)
| x.__init__(...) initializes x; see x.__class__.__doc__ for signature
|
| __instancecheck__(...)
| __instancecheck__() - check if an object is an instance
|
| __repr__(...)
| x.__repr__() == repr(x)
|
| __setattr__(...)
| x.__setattr__('name', value) == x.name = value
|
| __subclasscheck__(...)
| __subclasschck__ - check if an class is a subclass
|
| __subclasses__(...)
| __subclasses__() - list of immediate subclasses
|
| mro(...)
| mro() - list
| return a type's method resolution order
|
| --
| Data descriptors defined here:
|
| __abstractmethods__
|
| __base__
|
| __bases__
|
| __basicsize__
|
| __dict__
|
| __dictoffset__
|
| __flags__
|
| __itemsize__
|
| __mro__
|
| __weakrefoffset__
|
| --
| Data and other attributes defined here:
|
| __new__ = built-in method __new__ of type object at 0x145600
| T.__new__(S, ...) - a new object with type S, a subtype of T
|
| __prepare__ = built-in method __prepare__ of type object at 0x145600
| __prepare__() - dict
| used to create the namespace for the class statement
type.__doc__
type(object) - the object's type\ntype(name, bases, dict) - a new type
observe help(type) and type.__doc__ in Python 3.2:
help(type)
Help on class type in module builtins:
type = class 'type'
type.__doc__
type(object) - the object's type\ntype(name, bases, dict) - a new type
It appears that the __doc__ attribute of class 'type' is unchanged from
Python 3.1 to 3.2, but it is not being displayed by the help function in Python
3.2.
The help function is very important to using Python! This should be fixed.
--
assignee: docs@python
components: Documentation, Interpreter Core
messages: 149234
nosy: christopherthemagnificent, docs@python
priority: normal
severity: normal
status: open
title: help() appears to be broken; doesn't display __doc__ for class type when
called as help(type)
type: behavior
versions: Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13581
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8030] documentation bugs and improvements
New submission from Christopher the Magnificent
ultimate.mac.fana...@gmail.com:
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:
help(dict)
class dict(object)
| dict() - new empty dictionary.
| dict(mapping) - new dictionary initialized from a mapping object's
| (key, value) pairs.
| dict(seq) - new dictionary initialized as if via:
| d = {}
| for k, v in seq:
| d[k] = v
| dict(**kwargs) - new dictionary initialized with the name=value pairs
| in the keyword argument list. For example: dict(one=1, two=2)
|
As suggested by the documentation above -- and proven by verification:
a = [1, 2, 3]# a new list
b = list(a)
a is a
True
a == b
True
a is b
False
a is list(a)
False
a = {'do': 1, 'rey': 2, 'mi': 3}# a new dict
b = dict(a)
a is a
True
a == b
True
a is b
False
a is dict(a)
False
-- we can clearly see that list(x) and dict(x) ALWAYS return a new, unique
object.
What about set?
help(set)
class set(object)
| set(iterable) -- set object
|
| Build an unordered collection of unique elements.
|
help(set) simply reports that set(x) returns a set object. For all we know,
this could mean creating a new object only if coercion is necessary; that
sounds plausible enough, and people could easily write code dependent on that
assumption that would introduce VERY subtle bugs!
Experimentation shows however that, like list and dict, set always returns a
new, unique object:
a = {1, 2, 3}
b = set(a)
a is a
True
a == b
True
a is b
False
a is set(a)
False
Yipes! CONFUSION!!!
How about we fix the documentation for set so that it matches that of list and
dict, including disclosure of its always-create-new-object behavior? We can
also make the returns arrow have one hyphen instead of two for consistency
with most other Python documentation.
Let's replace this line:
X set(iterable) -- set object
with this line:
√ set(iterable) - new set object
so that our help(set) documentation ends up looking like this:
class set(object)
| set(iterable) - new set object
|
| Build an unordered collection of unique elements.
|
While we're at it, I'd recommend changing the help for list and dict so that
instead of saying list(sequence), dict(seq), and for k, v in seq: --
which, besides being inconsistent in use of abbreviation, also use the older
paradigm of sequences instead of iterables -- we instead say list(iterable),
dict(iterable), and for k, v in iterable:, giving us (X's by altered lines):
help(list)
class list(object)
| list() - new list
X| list(iterable) - new list initialized from sequence's items
|
help(dict)
class dict(object)
| dict() - new empty dictionary.
| dict(mapping) - new dictionary initialized from a mapping object's
| (key, value) pairs.
X| dict(iterable) - new dictionary initialized as if via:
| d = {}
X| for k, v in iterable:
| d[k] = v
| dict(**kwargs) - new dictionary initialized with the name=value pairs
| in the keyword argument list. For example: dict(one=1, two=2)
|
Making these changes from seq/sequence to iterable will serve to
eliminate confusion as to whether set objects are usable in list and dict
constructors -- for example, like this:
x = {('spam', 'icky'),
... ('balony', 'stomachable'),
... ('beef', 'palatable'),
... ('turkey', 'yummy')}
dict(x)
{'turkey': 'yummy', 'balony': 'stomachable', 'beef': 'palatable', 'spam':
'icky'}
Python's clear and helpful online documentation is one of my most favorite
features of the language, and I'm not alone in feeling this way, so we should
make it the very best resource that we can! Python rules!!
--
assignee: georg.brandl
components: Documentation
messages: 100212
nosy: christopherthemagnificent, georg.brandl
severity: normal
status: open
title: documentation bugs and improvements
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8030
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
