[issue41033] readline.c: SEGFAULT on SIGWINCH when loaded twice
Dale added the comment: I hit this on macOS today but I didn't get segmentation fault, at least not for as long as I cared to let Python run. Instead I got a non-responsive Python process using 100% CPU that I had to kill with ^\. I first hit this with GNU readline while running Python interactively under Emacs, then I reproduced it with libedit readline under a regular old terminal using the above recipe. macOS 11.6.1, x86-64, Python 3.10.1 from MacPorts -- nosy: +dale ___ Python tracker <https://bugs.python.org/issue41033> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1346] Error using >>> from OpenGL.GLUT import *
New submission from Dale: I get the response shown below when trying to use OpenGL. I have Python 2.5, PIL-1.1.6, and PyOpenGL 3.0 installed. Any help would be greatly appreciated. Thanks, Dale >>> from OpenGL.GLUT import * Traceback (most recent call last): File "", line 1, in from OpenGL.GLUT import * File "build\bdist.win32\egg\OpenGL\GLUT\__init__.py", line 4, in File "build\bdist.win32\egg\OpenGL\GLUT\special.py", line 73, in AttributeError: 'NoneType' object has no attribute 'glutDestroyWindow' >>> __init__.py line 4 is; from OpenGL.GLUT.special import * special.py line 73 is; _base_glutDestroyWindow = GLUT.glutDestroyWindow -- components: Windows messages: 56866 nosy: neuralsensor severity: normal status: open title: Error using >>> from OpenGL.GLUT import * type: compile error versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1346> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28892] pandas.to_datetime crashes in 3.6b4
New submission from Dale:
I'm trying 3.6b4 on my mac (OS X 10.10.5) and when I run the following code
(after doing pip install numpy and pandas) I see a 'SystemError':
>>> import pandas as pd
>>> pd.to_datetime('10/31/2016')
ValueError: Error parsing datetime string "10/31/2016" at position 2
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "", line 1, in
File
"/Users/schouten/virtualenvs/tmp/lib/python3.6/site-packages/pandas/util/decorators.py",
line 91, in wrapper
return func(*args, **kwargs)
File
"/Users/schouten/virtualenvs/tmp/lib/python3.6/site-packages/pandas/tseries/tools.py",
line 430, in to_datetime
return _convert_listlike(np.array([arg]), box, format)[0]
File
"/Users/schouten/virtualenvs/tmp/lib/python3.6/site-packages/pandas/tseries/tools.py",
line 401, in _convert_listlike
require_iso8601=require_iso8601
File "pandas/tslib.pyx", line 2302, in pandas.tslib.array_to_datetime
(pandas/tslib.c:43278)
File "pandas/tslib.pyx", line 2458, in pandas.tslib.array_to_datetime
(pandas/tslib.c:41773)
File "pandas/tslib.pyx", line 2416, in pandas.tslib.array_to_datetime
(pandas/tslib.c:41009)
File "pandas/src/datetime.pxd", line 141, in datetime._string_to_dts
(pandas/tslib.c:90460)
SystemError: returned a result with an error set
>>>
sys.version says:
>>> import sys
>>> sys.version
'3.6.0b4 (v3.6.0b4:18496abdb3d5, Nov 21 2016, 20:44:47) \n[GCC 4.2.1 (Apple
Inc. build 5666) (dot 3)]'
>>>
With 3.5 it works as expected:
>>> import sys
>>> sys.version
'3.5.1 (v3.5.1:37a07cee5969, Dec 5 2015, 21:12:44) \n[GCC 4.2.1 (Apple Inc.
build 5666) (dot 3)]'
>>> import pandas as pd
>>> pd.to_datetime('10/31/2016')
Timestamp('2016-10-31 00:00:00')
>>>
I know it looks like pandas might be at fault, but given that the only thing
I've changed is the Python version, I'm thinking it might be exposing a 3.6 bug
(or vice versa, I suppose).
My apologies if I'm doing this all wrong, I'm new around here.
--
components: Extension Modules, Interpreter Core, macOS
messages: 282588
nosy: Schouten, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: pandas.to_datetime crashes in 3.6b4
type: crash
versions: Python 3.6
___
Python tracker
<http://bugs.python.org/issue28892>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28892] pandas.to_datetime crashes in 3.6b4
Dale added the comment: Thanks for the quick response! -- ___ Python tracker <http://bugs.python.org/issue28892> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Darren Dale added the comment: Any additional comments? -- ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Darren Dale added the comment: It would be nice if this patch could be merged in time for python-3.3... -- ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Darren Dale added the comment: I just double-checked that the unit tests do not raise any warnings with this patch. Can it be merged? -- ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Darren Dale added the comment: I'll bump this one last time. -- ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Darren Dale added the comment: Here is a new patch addressing comments raised in review. It supersedes previous patch submissions. -- Added file: http://bugs.python.org/file23819/abc_descriptor.patch ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Darren Dale added the comment: Patch addressing latest comments in review. Notable change: defines _PyObject_IsAbstract in object.c/object.h, rather than repeating the code in multiple files and functions. -- Added file: http://bugs.python.org/file23857/abc_descriptor.patch ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Darren Dale added the comment: New patch addressing comments in review. -- Added file: http://bugs.python.org/file23864/abc_descriptor.patch ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Darren Dale added the comment: Is this patch ready to go? I haven't heard any feedback on the most recent version. -- ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale added the comment: Thank you for the suggestion. I will follow up at python-dev, but it will probably be a few weeks before I have time to do a proper job of it. -- ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Darren Dale added the comment:
I posted the following at python-dev
(http://mail.python.org/pipermail/python-dev/2011-June/111837.html):
I would like to try to address some shortfalls with the way python deals with
abstract base classes containing descriptors. I originally was just concerned
with improving support for defining abstract properties with the decorator
syntax and converting between abstract and concrete properties, but recently
realized that the problem extends to descriptors in general.
ABCs
First, a bit of background may be in order. An abstract base class is defined
by specifying its metaclass as ABCMeta (or a subclass thereof)::
class MyABC(metaclass=ABCMeta):
@abstractmethod
def foo(self):
pass
When trying to instantiate MyABC or any of its subclasses, ABCMeta inspects the
current class namespace for items tagged with __isabstractmethod__=True::
class ABCMeta(type):
#[...]
def __new__(mcls, name, bases, namespace):
cls = super().__new__(mcls, name, bases, namespace)
# Compute set of abstract method names
abstracts = {name
for name, value in namespace.items()
if getattr(value, "__isabstractmethod__", False)}
ABCMeta then checks if any of the base classes define any items tagged with
__isabstractmethod__ and whether they remain abstract in the current
class namespace::
for base in bases:
for name in getattr(base, "__abstractmethods__", set()):
value = getattr(cls, name, None)
if getattr(value, "__isabstractmethod__", False):
abstracts.add(name)
cls.__abstractmethods__ = frozenset(abstracts)
In Objects/typeobject.c, __abstractmethods__ is actually a descriptor, and
setting it gives the type a chance to set an internal flag specifying if it
has any abstract methods defined. When object_new is called in typeobject.c,
the flag is checked and an error is raised if any abstract methods were
identified.
Issues with ABCs and descriptors
In order for this scheme to work, ABCMeta needs to identify all of the abstract
methods, but there are some limitations when we consider descriptors. For
example, Python's property is a composite object, whose behavior is defined by
the getter, setter, and deleter methods with which it is composed. Since there
is already an @abstractmethod decorator, I would have suspected that defining
abstract properties would be intuitive::
class MyABC(metaclass=ABCMeta):
@abstractmethod
def _get_foo(self):
pass
@abstractmethod
def _set_foo(self, val):
pass
foo = property(_get_foo, _set_foo)
@property
@abstractmethod
def bar(self):
pass
@bar.setter
@abstractmethod
def bar(self, val):
pass
Ideally, one would want the flexibility of defining a concrete getter and an
abstract setter, for example. However, ABCMeta does not inspect the descriptors
of a class to see if they contain any abstract methods. It only inspects the
descriptor itself for a True __isabstractmethod__ attribute. This places the
burdon on every descriptor implementation to provide its own support for ABC
compatibility. For example, support for abstract properties was attempted by
adding abstractproperty to the abc module. abstractproperty subclasses the
property builtin (as opposed to the relationship between every other abstract
and concrete class in the python language). Here is the definition of
abstractproperty, in its entirety (modulo docstrings)::
class abstractproperty(property):
__isabstractmethod__ = True
A number of problems manifest with this approach, and I think they all can be
traced to the fact that the abstractedness of a descriptor is currently not
dependent upon the abstractedness of the methods with which it is
composed. The documentation for abstractproperty doesn't suggest using
@abstractmethod::
class C(metaclass=ABCMeta):
def getx(self): ...
def setx(self, value): ...
x = abstractproperty(getx, setx)
which leads to Issue #1: What is abstract about C.x? How does a subclass of C
know whether it needs to override the getter or setter?
Issue #2: The decorator syntax cannot be used to convert an abstract property
into a concrete one. (This relates to Issue #1: how would a descriptor even know
when such a conversion would be appropriate?) Running the following code::
from abc import ABCMeta, abstractmethod, abstractproperty
class AbstractFoo(metaclass=ABCMeta):
@abstractproperty
def bar(self):
return 1
@bar.setter
def bar(self, val):
pass
class ConcreteFoo(AbstractFoo):
@AbstractFoo.bar.getter
def bar(self):
return 1
[issue11610] Improved support for abstract base classes with descriptors
Darren Dale added the comment: Here is an improved patch, which includes feedback from python-dev. "make test" runs without failures, however test_abc.py prints deprecation warnings for abstractproperty. I'm not familiar with the protocol here, do we continue to include unit tests for deprecated features until they are removed? -- Added file: http://bugs.python.org/file22322/abc_descriptors.patch ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Changes by Darren Dale : Removed file: http://bugs.python.org/file22322/abc_descriptors.patch ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Changes by Darren Dale : Added file: http://bugs.python.org/file22323/abc_descriptors.patch ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Changes by Darren Dale : -- components: +Library (Lib) -Interpreter Core ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Darren Dale added the comment: On Sat, Jun 11, 2011 at 3:11 AM, Daniel Urban wrote: > > Daniel Urban added the comment: > > It doesn't work with staticmethod: > >>>> import abc >>>> >>>> class C(metaclass=abc.ABCMeta): > ... @staticmethod > ... @abc.abstractmethod > ... def foo(x): > ... raise NotImplementedError() > ... >>>> class D(C): > ... @staticmethod > ... def foo(x): > ... return x + 1 > ... >>>> D() > Traceback (most recent call last): > File "", line 1, in > TypeError: Can't instantiate abstract class D with abstract methods > foo.__func__ You still need to use @abc.abstractstaticmethod. -- ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Darren Dale added the comment: [...] >> Traceback (most recent call last): >> File "", line 1, in >> TypeError: Can't instantiate abstract class D with abstract methods >> foo.__func__ > > You still need to use @abc.abstractstaticmethod. Thinking about this some more, I think the error you found should be considered a problem. The issue is with the descriptor access itself: In class C we inspect the staticmethod instance in the namespace dict passed to ABCMeta and find foo's abstract __func__. But later, ABCMeta identifies C as a base of D, identifies C.foo.__func__ from C.__abstractmethods__, then does a getattr on the formative D class. D.__dict__['foo'] is a descriptor, which when accessed as D.foo returns D.__dict__['foo'].__func__ (as opposed to the other descriptors we have been discussing, where descriptor "get" access is only invoked by an instance of the class). ABCMeta needs to inspect the descriptor itself, not whatever the descriptor wants to return when accessed. We can't use D.__dict__ to access the foo descriptor, since some other base class of D may have provided the concrete implementation of foo. Does anyone know another way to search the MRO and return the foo descriptor? You helped bring up another point: all functions are descriptors, since they all have __get__ methods. That means every method is going to be inspected for abstract members. Is this a problem? -- ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Darren Dale added the comment:
On Sat, Jun 11, 2011 at 8:55 AM, Nick Coghlan wrote:
>
> Nick Coghlan added the comment:
>
> inspect.getattr_static has the necessary logic to search for descriptors
> without invoking them.
Unfortunately, we can't import inspect, even inside ABCMeta.__new__.
> However, it may be better to revert to the idea of pushing this functionality
> back onto the individual descriptors and have the problematic descriptors
> like property and staticmethod simply implement __isabstractmethod__ as a
> property.
>
> property:
> @property
> def __isabstractmethod__(self):
> return (self.fget.__isabstractmethod__ or
> self.fset.__isabstractmethod__ or
> self.fdel.__isabstractmethod__)
>
> staticmethod/classmethod:
>
> @property
> def __isabstractmethod__(self):
> return self.__func__.__isabstractmethod__
That's a good idea.
> With this approach, the "one true way" to handle abstract descriptors would
> be to do:
>
> #instance method
> @abstractmethod
> def f(self):
> ...
>
> @property
> @abstractmethod
> def f(self):
> ...
>
> @classmethod
> @abstractmethod
> def f(self):
> ...
>
> @staticmethod
> @abstractmethod
> def f(self):
> ...
>
> This wouldn't allow for the prettier error messages, but it's much cleaner
> than having ABCMeta trawling through class attribute dir() lists.
Those classes could conceivably do:
@property
def __abstractmethods__(self):
return ("...", ...)
It would not be required, but if ABCMeta found it, it could use it.
Just a thought.
Darren
--
___
Python tracker
<http://bugs.python.org/issue11610>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Darren Dale added the comment: [...] > > This wouldn't allow for the prettier error messages, but it's much cleaner > than having ABCMeta trawling through class attribute dir() lists. I think there is another reason to do it this way. Suppose I have a custom descriptor MyProperty that stores its getter as MyProperty.my_fget. In this example: class C: @property @abstractmethod def foo(self): return 1 class D: @MyProperty def foo(self): return 2 if ABCMeta determines C.foo.fget is abstract, it will not recognize that D.foo.my_fget supplies the concrete implementation. MyProperty may provide the same interface as property, it may even subclass property, but there is no guarantee its implementation conforms to property the way ABCMeta is expecting it to. The downside to making __isabstractmethod__ a property is that if C declares foo to be a read/write property, and D redefines foo as read-only and concrete, ABCMeta will not recognize the oversight. That seems a significant deficiency to me. I'm not sure how to proceed. Darren -- ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Darren Dale added the comment:
On Sat, Jun 11, 2011 at 7:32 PM, Eric Snow wrote:
>
> Eric Snow added the comment:
> Per your last message, if a specific descriptor has an abstract setter then
> the descriptor should be considered abstract. If the implementation of that
> attribute is not a descriptor should it raise a TypeError? If it is a
> descriptor but it does not have a setter, should it likewise fail?
Consider a framework like Enthought's Traits or Riverbank Computing's
dip, where setting the value of a descriptor can result in other
objects being notified of the change. Both Traits and dip are based on
the concept of interfaces, but imagine someone wanted to develop
something similar based on ABCs. In that case, one could argue that
replacing the descriptor with a regular attribute, or another
read-only descriptor, would not satisfy the ABC specification. Then it
might be nice if the abc mechanisms could catch the error. But it
looks like this will be difficult in cases where the subclasses
replaces the descriptor, unless perhaps an AbstractDescriptor were
provided that explained how ABCMeta is going to identify abstract
methods:
class AbstractDescriptor(metaclass=abc.ABCMeta):
@property
@abc.abstractmethod
def __abstractmethods__(self):
# it would be nice if descriptors new their own names here,
# __abstractmethods__ could return: ('bar.fget', 'bar.fset')
return frozenset(m for m in ('fget', 'fset', 'fdel')
if getattr(getattr(self, m, None),
'__isabstractmethod__', False))
@property
def __isabstractmethod__(self):
return True if self.__abstractmethods__
AbstractDescriptor.register(property)
Of course, not all descriptors would be required to derive from
AbstractDescriptor. There is no intended stick, but the carrot is
better integration with with ABCs.
Having said all that, I think the above suggestion including
__abstractmethods__ for descriptors makes unreasonable demands of
conformity between various descriptor implementations, and that Nick's
suggestion of simply asking descriptors to provide an
__isabstractmethod__ descriptor is probably good enough. Sufficient
documentation of an ABC's interface can cover the rest.
The inspect module or something like it may still be needed in ABCMeta
to work around the general issue Daniel discovered with staticmethod.
That way ABCMeta could inspect the descriptors themselves and attempt
to retrieve their __isabstractmethod__ value.
(aside: unlike ABCMeta.__new__, ABCMeta.register makes no attempt to
verify that the class being registered actually meets the
specification. Why not have ABCMeta.register perform the same checks
as ABCMeta.__new__, and raise an error if the registered class does
not conform to the specification?)
My work is going to keep me pretty busy over the next three weeks, and
I'm still not accomplished with Python's C-API. If someone else wants
to take a crack at the next patch, please feel free.
Darren
--
___
Python tracker
<http://bugs.python.org/issue11610>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Darren Dale added the comment: Here is attempt #4. This patch extends the property, classmethod and staticmethod builtins with an __isabstractmethod__ descriptor. Docs and tests are updated as well. "make test" runs without failures. This is my first real attempt with the C-API, and I think I am finally over the learning curve, but comments would be greatly appreciated. -- Added file: http://bugs.python.org/file22407/abc_descriptor.patch ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Changes by Darren Dale : Removed file: http://bugs.python.org/file21307/issue11610.patch ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Changes by Darren Dale : Removed file: http://bugs.python.org/file21375/issue11610_v2.patch ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Changes by Darren Dale : Removed file: http://bugs.python.org/file22323/abc_descriptors.patch ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Darren Dale added the comment: I've requested additional feedback based on comments at Rietveld. -- ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Darren Dale added the comment: Here is a new version of the patch, addressing points raised in the review of the previous version. -- Added file: http://bugs.python.org/file22729/abc_descriptor.patch ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10031] Withdraw anti-recommendation of relative imports from documentation
New submission from Darren Dale : Old-style relative imports have been strongly discouraged in some sections of the python documentation. This was discussed on the python-dev mailing list. Executive summary: "The issue is implementing a PEP with nice support for relative imports, and then documenting that it should never be used." To which Guido responded: --- "Isn't this mostly historical? Until the new relative-import syntax was implemented there were various problems with relative imports. The short-term solution was to recommend not using them. The long-term solution was to implement an unambiguous syntax. Now it is time to withdraw the anti-recommendation. Of course, without going overboard -- I still find them an acquired taste; but they have their place." --- It was suggested I open a ticket and suggest specific changes. They are listed below: The faq at http://docs.python.org/py3k/faq/programming.html#what-are-the-best-practices-for-using-import-in-a-module could go from: "Never use relative package imports. If you’re writing code that’s in the package.sub.m1 module and want to import package.sub.m2, do not just write from . import m2, even though it’s legal. Write from package.sub import m2 instead. See PEP 328 for details." to: "Although the python community generally prefers absolute imports, relative imports may be useful in certain circumstances. See PEP 328 for details." The programming faq for python-2.7 at http://docs.python.org/faq/programming.html#what-are-the-best-practices-for-using-import-in-a-module could go from: "Never use relative package imports. If you’re writing code that’s in the package.sub.m1 module and want to import package.sub.m2, do not just write import m2, even though it’s legal. Write from package.sub import m2 instead. Relative imports can lead to a module being initialized twice, leading to confusing bugs. See PEP 328 for details." to: "Although the python community generally prefers absolute imports, relative imports may be useful in certain circumstances. Support for relative imports has recently been improved, and the use of the old-style relative imports is strongly discouraged. See PEP 328 for details." There is also this warning against relative imports in PEP 8, that could go from: - Relative imports for intra-package imports are highly discouraged. Always use the absolute package path for all imports. Even now that PEP 328 [7] is fully implemented in Python 2.5, its style of explicit relative imports is actively discouraged; absolute imports are more portable and usually more readable. to: - While the python community generally prefers absolute imports, relative imports may be useful in certain circumstances. Now that PEP 328 [7] is fully implemented in Python 2.5 and later, the older style of implicit relative imports is strongly discouraged. -- assignee: d...@python components: Documentation messages: 118031 nosy: d...@python, dsdale24 priority: normal severity: normal status: open title: Withdraw anti-recommendation of relative imports from documentation versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue10031> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
New submission from Darren Dale :
I posted a suggestion at python-ideas that the declaration of abstract
properties could be improved in such a way that they could be declared with
either the long-form or decorator syntax using the built-in property and
abc.abstractmethod:
{{{
class MyProperty(property):
def __init__(self, *args, **kwargs):
super().__init__(*args, **kwargs)
for f in (self.fget, self.fset, self.fdel):
if getattr(f, '__isabstractmethod__', False):
self.__isabstractmethod__ = True
break
class C(metaclass=ABCMeta):
@MyProperty
@abstractmethod
def x(self):
pass
@x.setter
@abstractmethod
def x(self, val):
pass
# this syntax would also be supported:
#@abstractmethod
#def getx(self):
#pass
#@abstractmethod
#def setx(self, val):
#pass
#x = MyProperty(getx, setx)
class D(C):
'D does not define a concrete setter and cannot be instantiated'
@C.x.setter
def x(self):
return 1
class E(D):
'E has a concrete getter and setter, and can be instantiated'
@D.x.setter
def x(self, val):
pass
}}}
It is hopefully evident that a relatively minor extension can be made to the
built-in property such that @abstractproperty would no longer be needed. I have
prepared a patch, complete with documentation and unit tests, but unfortunately
I have not been able to test it because I have not been able to build Python
from a mercurial checkout on either Ubuntu 11.04 or OS X 10.6.6 (for reasons
unrelated to the patch.) BDFL thought the idea sounded good for inclusion in
Python-3.3, and requested I submit the patch here.
--
components: Library (Lib)
files: property_with_abstractmethod.patch
keywords: patch
messages: 131436
nosy: dsdale24
priority: normal
severity: normal
status: open
title: Improving property to accept abstract methods
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file21293/property_with_abstractmethod.patch
___
Python tracker
<http://bugs.python.org/issue11610>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale added the comment: The discussion on python-ideas: http://mail.python.org/pipermail/python-ideas/2011-March/009411.html -- ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale added the comment: Here is a new patch that addresses a couple problems found in review: * Unit tests contained a typo (Property instead of property) * DeprecationWarning would be issued when importing abc rather than when creating abstractproperty. (whether abstractproperty should be deprecated has been questioned). -- Added file: http://bugs.python.org/file21295/property_with_abstractmethod_v2.patch ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale added the comment: On Sun, Mar 20, 2011 at 5:18 AM, Daniel Urban wrote: > > Daniel Urban added the comment: > > I tried to test your patch, but the build dies with this error: > Fatal Python error: Py_Initialize: can't initialize sys standard streams > Traceback (most recent call last): > File ".../cpython/Lib/io.py", line 60, in > Aborted > > I don't know why is this, but I get this error consistently with your patch, > and no error without the patch. > > On Sat, Mar 19, 2011 at 22:13, wrote: >> Thank you for the feedback. The reason I suggested deprecating >> abstractproperty is that I think it is essentially broken. Subclasses >> have to redeclare the entire property, and if they forget to declare >> the setter for what is supposed to be a read/write property, there is >> no way to catch it. With the new approach, it is possible to ensure >> that all the required features of the property have been implemented. > ... >> On 2011/03/19 21:36:09, durban wrote: >> > I don't think abstractproperty should be deprecated. It is still >> > perfectly good to define a read-only abstract property (with one >> > decorator instead of two). >> >> Zen of python. > > I'm guessing you're referring to "There should be one-- and preferably only > one --obvious way to do it." That is a good point. But currently the one > way to: > - create an abstract static method: @abstractstaticmethod > - create an abstract class method: @abstractclassmethod > - create an abstract property: @abstractproperty (as you pointed out, this > has some problems) > > With your proposed change the one way to: > - create an abstract static method: @abstractstaticmethod > - create an abstract class method: @abstractclassmethod > - create an abstract property: @abstractmethod + @property > This is not a very good API. Unlike methods, properties are composite objects. It is therefore reasonable that creating an abstract property might be a little different from creating an abstract method. > Note, that a similar thing could be done for class/staticmethod, and then > using @abstractmethod + @classmethod would be possible, and the API would be > more consistent. But it wasn't done because Guido objected it (see > issue5867). Thank you for pointing that out. I've followed up with him at python-ideas to seek clarification (he did not raise this point when I posted the change to descrobject.c) >> This is the part where I am weak. Can you point me to documentation? >> Why is an exception check necessary? Do PyObject_IsTrue and Py_DECREF >> not know what to do when passed NULL? > > http://docs.python.org/dev/py3k/c-api/object.html#PyObject_GetAttrString I'm familiar with that page. Do you know of any documentation addressing how to anticipate and respond to NULL? -- ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale added the comment: On Sun, Mar 20, 2011 at 12:19 PM, Benjamin Peterson wrote: > > Benjamin Peterson added the comment: > > I think a better idea would be to override getter and friends on the > abstractproperty class. I just suggested the same at python-ideas. I'll work on an alternate patch. -- ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale added the comment: On Sun, Mar 20, 2011 at 5:18 AM, Daniel Urban wrote: > > Daniel Urban added the comment: > > I tried to test your patch, but the build dies with this error: > Fatal Python error: Py_Initialize: can't initialize sys standard streams > Traceback (most recent call last): > File ".../cpython/Lib/io.py", line 60, in > Aborted > > I don't know why is this, but I get this error consistently with your patch, > and no error without the patch. Have you added any print statements to the patch? I'm working on a completely new patch, which only touches abc.py on an existing python3.2 install. When I add a print statement to the abstract property creation routine, and run test_abc.py, I get the same error. -- ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale added the comment: Thank you Daniel and Benjamin for the helpful feedback. I think the attached patch is a much better approach. It only touches abc.abstractproperty (instead of the builtin property), and uses a class method as a factory to return instances of either property or abstractproperty, depending on whether it holds any references to abstractmethods. The patch is backwards compatible with the existing (though in my opinion, still broken) syntax of passing concrete methods to the abstractproperty constructor. I say that syntax is broken because properties are composite objects, and it is the methods that inherently make a property abstract or concrete. If one passes concrete getters and setters to abstractproperty, how do we know when the property has become concrete? Thus, I changed the documentation to refer to the more robust approach of passing abstractproperty methods that have been decorated with abstractmethod. Unit tests are also provided. I still have not been able to build from my hg checkout, but I copied abc.py into my working 3.2 installation and ran the new test_abc.py without errors. I'll be happy to address any additional concerns. -- Added file: http://bugs.python.org/file21307/issue11610.patch ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Changes by Darren Dale : Removed file: http://bugs.python.org/file21293/property_with_abstractmethod.patch ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Changes by Darren Dale : Removed file: http://bugs.python.org/file21295/property_with_abstractmethod_v2.patch ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale added the comment: Here is a new version of the patch. I think it addresses all of the issues that have been raised to date. I had to comment out the -lintl line in Modules/Setup to build on OS X, this seems to be a similar issue to http://bugs.python.org/issue6154 . So I don't have a _locale module, and I also don't have _scproxy. I ran "make test", and get the same results with and without the patch: 315 passes, 22 failed, 15 skipped. All of the failures are due to missing _locale and _scproxy, with the exception of an error during the sax test that is unrelated to my changes. -- components: -Library (Lib) Added file: http://bugs.python.org/file21375/issue11610_v2.patch ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale added the comment: (Ned, I'm running 10.6.6 with a 64-bit kernel. I've tried running ./configure without any arguments, and also with --prefix=/opt/local, since I install essentially everything with MacPorts.) -- ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale added the comment: Benjamin: have you thought this idea through? -- ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale added the comment:
I see some problems with this approach, but maybe I haven't fully appreciated
it. Let me summarize the goals and constraints as I see them:
1) compatible with long-form and decorator syntax of {abstract}property
declaration
2) backwards compatible, no change in semantics/behavior
3) decorator syntax needs to yield a concrete property once all abstract
methods associated with the abstract property have been replaced with concrete
implementations. (This is the reason why each abstract method associated with
the property needs to get tagged with __isabstractmethod__. It provides an
accounting of abstract methods associated with the property which fits with the
existing semantics of abstract method declaration.)
The current approach actually satisfies all of the goals and constraints. It
fits well with the existing semantics, there are no surprises and no changes in
behavior for any existing code. It is even compatible with anyone who may have
used @abstractmethod to decorate methods destined to be passed to
@abstractproperty using the long-form property declaration (which would have
worked even though it was not documented!)
The benefit of abstractproperty.abstract{...} is that one decorator is required
instead of two, right? Are there others?
It is true that one could define abstract{getter,setter,deleter} decorators
that would take care of setting the __isabstractmethod__ attribute on the
function received, so that the @abstractmethod decorator would not be needed
*once the property has been created*.
But if @abstractmethod is discouraged in favor of
abstractproperty.abstractgetter and friends, abstractproperty would have to tag
each method passed to its constructor as abstract (in order to support the
long-form syntax and also the initial declaration with the decorator syntax)
which would actually be a change in behavior with potential consequences. For
example, maybe a third party defined a concrete getter in an abstract base
class, and python-3.3 can't instantiate the subclasses because that getter was
automatically tagged as abstract by the new abstractproperty constructor. So
@abstractmethod would still be needed for methods passed to the constructor,
meaning sometimes @abstractmethod would be needed, and sometimes it would not.
--
___
Python tracker
<http://bugs.python.org/issue11610>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale added the comment:
On Tue, Mar 29, 2011 at 9:31 PM, Benjamin Peterson
wrote:
> 2011/3/29 Darren Dale :
>> The benefit of abstractproperty.abstract{...} is that one decorator is
>> required instead of two, right? Are there others?
>
> Mostly it doesn't create a weird asymmetry between a @abstractproperty
> decorated function not needing @abstractmethod but
> @someabstractprop.setter needing it.
Did you read the documentation I provided in the patch? There is no
asymmetry, the documentation and examples provided by previous python
releases are demonstrably inadequate. For example:
class AbstractFoo(metaclass=ABCMeta):
def get_bar(self): ...
def set_bar(self, val): ...
bar = abstractproperty(get_bar, set_bar)
The documentation indicates that a subclass will not be instantiable
until all of its abstract methods and properties are overridden. What
is abstract about the bar property? Was it the getter, setter, or
both, or neither? The answer is neither. A subclass can simply do:
class Foo(AbstractFoo):
bar = property(AbstractFoo.get_bar, AbstractFoo.set_bar)
and it is instantiable. On the other hand, for AbstractFoo to assert
that subclasses must provide concrete implementations of the get_bar
and set_bar methods, it must decorate get_bar and set_bar with
@abstractproperty. This is true for previous releases of python, the
documentation of abstractproperty in previous python releases is
simply incomplete. If a method is abstract, it needs to have an
__isabstractmethod__ attribute that is True, and @abstractmethod
provides the means of setting this attribute.
This patch simply extends abstractproperty so it can respect the
abstractedness of the methods assigned to it. If somebody defines an
ambiguous abstractproperty like my AbstractFoo example, they get the
same result with the patch as they did without: an abstract property
with two concrete methods (this is an unfortunate situation that
cannot be fixed without breaking backwards compatibility).
Therefore, there is no asymmetry between when @abstractmethod is
required and when it is not. If the *method* is abstract and must be
reimplemented by a subclass, @abstractmethod is required. Even for
methods that participate in property definitions, even with
<=python-3.2.
>> It is true that one could define abstract{getter,setter,deleter} decorators
>> that would take care of setting the __isabstractmethod__ attribute on the
>> function received, so that the @abstractmethod decorator would not be needed
>> *once the property has been created*.
>>
>> But if @abstractmethod is discouraged in favor of
>> abstractproperty.abstractgetter and friends, abstractproperty would have to
>> tag each method passed to its constructor as abstract (in order to support
>> the long-form syntax and also the initial declaration with the decorator
>> syntax) which would actually be a change in behavior with potential
>> consequences. For example, maybe a third party defined a concrete getter in
>> an abstract base class, and python-3.3 can't instantiate the subclasses
>> because that getter was automatically tagged as abstract by the new
>> abstractproperty constructor. So @abstractmethod would still be needed for
>> methods passed to the constructor, meaning sometimes @abstractmethod would
>> be needed, and sometimes it would not.
>
> That's not true. The method could be tagged in @abstractgetter decorator.
I think you misunderstood my point. I agreed with you that it could be
tagged by @abstractgetter. It cannot be tagged by the constructor.
That is where an asymmetry would be introduced between when
@abstractmethod is needed (declare methods abstract before passing
them to the constructor) and when it would not be (passing methods to
abstractgetter which declares them abstract).
(By the way, in review of issue11610.patch, GVR said he thought I had
the right idea and that the backward compatibility goal was satisfied.
Some of these points were covered in that discussion.)
Darren
--
___
Python tracker
<http://bugs.python.org/issue11610>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale added the comment:
On Tue, Mar 29, 2011 at 10:24 PM, Darren Dale wrote:
>
> Darren Dale added the comment:
>
> On Tue, Mar 29, 2011 at 9:31 PM, Benjamin Peterson
> wrote:
>> 2011/3/29 Darren Dale :
>>> The benefit of abstractproperty.abstract{...} is that one decorator is
>>> required instead of two, right? Are there others?
>>
>> Mostly it doesn't create a weird asymmetry between a @abstractproperty
>> decorated function not needing @abstractmethod but
>> @someabstractprop.setter needing it.
>
> Did you read the documentation I provided in the patch? There is no
> asymmetry, the documentation and examples provided by previous python
> releases are demonstrably inadequate. For example:
>
> class AbstractFoo(metaclass=ABCMeta):
> def get_bar(self): ...
> def set_bar(self, val): ...
> bar = abstractproperty(get_bar, set_bar)
>
> The documentation indicates that a subclass will not be instantiable
> until all of its abstract methods and properties are overridden. What
> is abstract about the bar property? Was it the getter, setter, or
> both, or neither? The answer is neither. A subclass can simply do:
>
> class Foo(AbstractFoo):
> bar = property(AbstractFoo.get_bar, AbstractFoo.set_bar)
>
> and it is instantiable. On the other hand, for AbstractFoo to assert
> that subclasses must provide concrete implementations of the get_bar
> and set_bar methods, it must decorate get_bar and set_bar with
> @abstractproperty.
Sorry, that should have read @abstractmethod.
--
___
Python tracker
<http://bugs.python.org/issue11610>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale added the comment: So, are there objections to this patch, or can it be merged? -- ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8094] Multiprocessing infinite loop
Darren Dale added the comment: I think I have a similar situation: C:\Py\Scripts\foo --- if __name__ == '__main__': import bar bar.main() C:\Py\Lib\site-packages\bar.py --- from multiprocessing import Pool def task(arg): return arg def main(): pool = Pool() res = pool.apply_async(task, (3.14,)) print res.get() if __name__ == '__main__': main() I can run "python bar.py". "python C:\Py\Scripts\foo" yields an infinite stream of errors: File "", line 1 in File "C:\Python27\lib\multiprocessing\forking.py", line 346, in main prepare(preparation_data) File "C:\Python27\lib\multiprocessing\forking.py", line 455, in prepare file, path_name, etc = imp.find_module(main_name, dirs) ImportError: No module named foo This same scheme works fine on linux. Have I just overlooked something simple? -- nosy: +dsdale24 ___ Python tracker <http://bugs.python.org/issue8094> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale added the comment: Is there anything preventing this patch from being merged? -- nosy: +Darren.Dale ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale added the comment: On Sat, May 14, 2011 at 12:20 PM, Benjamin Peterson wrote: > > Benjamin Peterson added the comment: > > 2011/5/14 Darren Dale : >> >> Darren Dale added the comment: >> >> Is there anything preventing this patch from being merged? > > I have to make time to think about the API a bit more. Ok. Maybe you will come up with another alternative that hadn't occurred to me. But I have given this issue quite a bit of thought, considered several alternatives, and felt fortunate to find a solution that preserves backwards compatibility, supports the property decorator syntax, and meshes well with the existing syntax for abstract methods. Perhaps, if you shared your concerns, I could help address them and maybe save you some time. Darrren -- ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale added the comment: On Sat, May 14, 2011 at 4:28 PM, Benjamin Peterson wrote: > > Benjamin Peterson added the comment: > > I still dislike the reduntancy of having abstractmethod and abstractproperty > on a method. I think a better idea is having > abstractproperty.abstract(getter/setter/deleter). Right, but I explained why the redundancy is necessary in order to preserve backwards compatibility. If the abstractproperty constructor were changed to tag methods it receives as abstract, it would be a backwards-incompatible change in behavior with potential consequences for consumers of abstractproperty. abstractproperty.abstract(getter/setter/deleter) could be implemented, but it still wouldn't change the fact that if a getter/setter is intended to be abstract, it needs to be decorated with @abstractmethod before being passed to the abstractproperty() constructor. This is true today in <=python-3.2: its not mentioned in the documentation, but the behavior exists all the same. Properties are composite objects, their behavior is defined by it is the setters/getters/deleters they receive. So its actually a very conceptually clean solution to decorate a method with @abstractmethod, and it fits really nicely with the rest of the abc module. Why does abstractproperty need special abstract(setter/getter/deleter) methods, when the existing methods combine with @abstractmethod in a clean way to produce the exact same result? To save one line of code? Darren -- ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale added the comment: On Sat, May 14, 2011 at 5:17 PM, Benjamin Peterson wrote: > > Benjamin Peterson added the comment: > > 2011/5/14 Darren Dale : >> >> Darren Dale added the comment: >> >> On Sat, May 14, 2011 at 4:28 PM, Benjamin Peterson >> wrote: >>> >>> Benjamin Peterson added the comment: >>> >>> I still dislike the reduntancy of having abstractmethod and >>> abstractproperty on a method. I think a better idea is having >>> abstractproperty.abstract(getter/setter/deleter). >> >> Right, but I explained why the redundancy is necessary in order to >> preserve backwards compatibility. If the abstractproperty constructor >> were changed to tag methods it receives as abstract, it would be a >> backwards-incompatible change in behavior with potential consequences >> for consumers of abstractproperty. > > I'm not suggesting that it tag methods it receives as abstract. > @getter/setter/deleter would still act the same. I wasn't talking about @getter/setter/deleter. I tried to be clear that I was talking about the abstractproperty() constructor. It doesn't currently tag the methods it receives as abstract, and to change this would be a backward incompatible change. Therefore, @abstractmethod should be used to tag methods as abstract before passing them to the abstractproperty() constructor, and the abc documentation should be changed to reflect this. >> abstractproperty.abstract(getter/setter/deleter) could be implemented, >> but it still wouldn't change the fact that if a getter/setter is >> intended to be abstract, it needs to be decorated with @abstractmethod >> before being passed to the abstractproperty() constructor. > > Why not? You could set the __abstractmethod__ attribute in abstractgetter(). I was not talking about decorating before passing @abstractgetter. I was talking about decorating before passing to the abstractproperty() constructor. >> This is >> true today in <=python-3.2: its not mentioned in the documentation, >> but the behavior exists all the same. > >> >> Properties are composite objects, their behavior is defined by it is >> the setters/getters/deleters they receive. So its actually a very >> conceptually clean solution to decorate a method with @abstractmethod, >> and it fits really nicely with the rest of the abc module. Why does >> abstractproperty need special abstract(setter/getter/deleter) methods, >> when the existing methods combine with @abstractmethod in a clean way >> to produce the exact same result? To save one line of code? > > I find it produces a rather unfortunate ordering dependency for the > decorators which is hard to remember. Why is it difficult to remember that you need to tag a method as abstract before passing it to the property? -- ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale added the comment: On Sat, May 14, 2011 at 5:55 PM, Benjamin Peterson wrote: > > Benjamin Peterson added the comment: > > Okay: how about this. We retain the passing of @abstractmethod to > abstractpropert(), but @abstractgetter decorates the method for you. That can work, although I would advise against it. I find it strange that we would use @abstractmethod sometimes and not others. If that is what it takes to get the patch accepted, so be it. But since I don't understand the motivation behind this approach, I won't be the one to document the special cases of when @abstractmethod is required and when it is not. > 2011/5/14 Darren Dale : >> >> Darren Dale added the comment: >> >> On Sat, May 14, 2011 at 5:17 PM, Benjamin Peterson >> wrote: >>> >>> Benjamin Peterson added the comment: >>> >>> 2011/5/14 Darren Dale : >>>> >>>> Darren Dale added the comment: >>>> >>>> On Sat, May 14, 2011 at 4:28 PM, Benjamin Peterson >>>> wrote: >>>>> >>>>> Benjamin Peterson added the comment: >>>>> >>>>> I still dislike the reduntancy of having abstractmethod and >>>>> abstractproperty on a method. I think a better idea is having >>>>> abstractproperty.abstract(getter/setter/deleter). >>>> >>>> Right, but I explained why the redundancy is necessary in order to >>>> preserve backwards compatibility. If the abstractproperty constructor >>>> were changed to tag methods it receives as abstract, it would be a >>>> backwards-incompatible change in behavior with potential consequences >>>> for consumers of abstractproperty. >>> >>> I'm not suggesting that it tag methods it receives as abstract. >>> @getter/setter/deleter would still act the same. >> >> I wasn't talking about @getter/setter/deleter. I tried to be clear >> that I was talking about the abstractproperty() constructor. It >> doesn't currently tag the methods it receives as abstract, and to >> change this would be a backward incompatible change. Therefore, >> @abstractmethod should be used to tag methods as abstract before >> passing them to the abstractproperty() constructor, and the abc >> documentation should be changed to reflect this. >> >>>> abstractproperty.abstract(getter/setter/deleter) could be implemented, >>>> but it still wouldn't change the fact that if a getter/setter is >>>> intended to be abstract, it needs to be decorated with @abstractmethod >>>> before being passed to the abstractproperty() constructor. >>> >>> Why not? You could set the __abstractmethod__ attribute in abstractgetter(). >> >> I was not talking about decorating before passing @abstractgetter. I >> was talking about decorating before passing to the abstractproperty() >> constructor. >> >>>> This is >>>> true today in <=python-3.2: its not mentioned in the documentation, >>>> but the behavior exists all the same. >>> >>>> >>>> Properties are composite objects, their behavior is defined by it is >>>> the setters/getters/deleters they receive. So its actually a very >>>> conceptually clean solution to decorate a method with @abstractmethod, >>>> and it fits really nicely with the rest of the abc module. Why does >>>> abstractproperty need special abstract(setter/getter/deleter) methods, >>>> when the existing methods combine with @abstractmethod in a clean way >>>> to produce the exact same result? To save one line of code? >>> >>> I find it produces a rather unfortunate ordering dependency for the >>> decorators which is hard to remember. >> >> Why is it difficult to remember that you need to tag a method as >> abstract before passing it to the property? > > I don't think the common case should be passing things to > abstractproperty(), rather using the decorator. It definitely is a common case, and always will be. You can't begin using abstractproperty.abstract(getter/setter/deleter) until you have an abstract property, which requires passing a (potentially abstract) method to the constructor. -- ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale added the comment: On Sat, May 14, 2011 at 6:24 PM, Benjamin Peterson wrote: > > Benjamin Peterson added the comment: > > 2011/5/14 Darren Dale : >> >> Darren Dale added the comment: >> >> It definitely is a common case, and always will be. You can't begin >> using abstractproperty.abstract(getter/setter/deleter) until you have >> an abstract property, which requires passing a (potentially abstract) >> method to the constructor. > > What about > > @abstractproperty > def something(): pass > > @abstractproperty.setter > def set(): pass > > @abstractproperty.deleter > def delete: pass > > requires you to pass a method (explicitly) to a constructor? @abstractproperty def something(): pass takes the "something" function and passes it to the abstractproperty() constructor. It doesn't appear that you are familiar with how the decorator syntax works for properties. Here is how your example should probably look: @abstractproperty def something(): pass @something.setter def something(): pass @something.deleter def something(): pass -- ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale added the comment: It just occurred to me, there is a potential problem with abstractproperty and the decorator syntax in my patch: class Foo: @abstractproperty def p(self): pass # p is abstract, but has no abstract methods @p.setter def p(self, val): pass # p has no abstract properties, at this point it becomes an instance # of property, not abstractproperty @p.deleter @abstractmethod def p(self): pass # the deleter was tagged as abstract, but p was already a # regular property. There is no way to turn a regular # property into an abstractproperty, so the abstractedness # of the deleter is not respected. Really, the ideal approach is the original one: provide the builtin property with an __isabstractmethod__ attribute, which is set to True if the property has any abstract methods, and False otherwise. (My C is probably too weak to modify the property builtin on my own). -- ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37101] Filterer.filter can be rewritten using built-ins just as efficient much more readable
New submission from Dale Visser : Alternative version of Filterer.filter(...) would look like this, which takes advantage of efficient Python 3.x built-ins, and is immediately understandable: def _filter_callable(filter): return filter.filter if hasattr(filter, 'filter') else filter def filter(self, record): filters = map(_filter_callable, self.filters) return all(f(record) for f in filters) I will add a tested pull request on GitHub. -- components: Library (Lib) messages: 343983 nosy: dwvisser priority: normal severity: normal status: open title: Filterer.filter can be rewritten using built-ins just as efficient much more readable type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue37101> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37101] Filterer.filter can be rewritten using built-ins just as efficient much more readable
Change by Dale Visser : -- keywords: +patch pull_requests: +13570 stage: -> patch review pull_request: https://github.com/python/cpython/pull/13683 ___ Python tracker <https://bugs.python.org/issue37101> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37101] Filterer.filter can be rewritten using built-ins just as efficient much more readable
Dale Visser added the comment: Great! My PR now uses getattr as @zach.ware has suggested. -- ___ Python tracker <https://bugs.python.org/issue37101> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37101] Filterer.filter can be rewritten using built-ins just as efficient much more readable
Dale Visser added the comment: It is with great surprise and sadness that I report that I found that performance measurements don't support merging this change. I'm attaching my performance test script. I ran it with/without the logging filters for 100 iterations, e.g., ./python all 100 The results on my system were as follows, where the numbers may be interpreted as milliseconds per 1000 log messages: No Filters3 Filters master17.9 19.8 CBO-37101 19.6 23.1 I imagine I could put a guard 'if' statement that would restore the 'no filters' performance to match 'master', but my use of generators apparently causes the use of significantly more cycles than the existing code. -- resolution: -> rejected stage: patch review -> resolved status: open -> closed Added file: https://bugs.python.org/file48381/test_filter_perf.py ___ Python tracker <https://bugs.python.org/issue37101> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37101] Filterer.filter can be rewritten using built-ins just as efficient much more readable
Dale Visser added the comment: Correction on that example of running the test script: ./python test_filter_perf.py all 100 I simply prepended this with the Linux `time` command for measuring. -- ___ Python tracker <https://bugs.python.org/issue37101> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37101] Filterer.filter can be rewritten using built-ins just as efficient much more readable
Dale Visser added the comment: Adding the patch file associated with GitHub pull request #13683, as well as the performance test I just reported. -- Added file: https://bugs.python.org/file48383/pr13683.diff ___ Python tracker <https://bugs.python.org/issue37101> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37101] Filterer.filter can be rewritten using built-ins just as efficient much more readable
Dale Visser added the comment: FWIW, when I tried this instead, I got 21 to 22 msec per 1000 log messages (still a 5-10% performance hit): def filter(self, record): rv = True if self.filters: rv = all(getattr(f, 'filter', f)(record) for f in self.filters) return rv I don't see that getattr(...) should be less efficient than hasattr(...), so the generator expression is the likely culprit. -- ___ Python tracker <https://bugs.python.org/issue37101> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37101] Filterer.filter can be rewritten using built-ins just as efficient much more readable
Dale Visser added the comment: I've learned a lot about the performance trade-offs of generator expressions. The only way of shortening this code (readability is subjective) that I've found not to negatively impact performance is this: def filter(self, record): rv = True for f in self.filters: if not getattr(f, 'filter', f)(record): rv = False break return rv -- ___ Python tracker <https://bugs.python.org/issue37101> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18360] Won't install. Keeps telling me DLL is missing.
New submission from Dale Smith: When I click install -> run, it tells me a DLL is missing and to contact my vendor (Windows 7 Home Premium). This is the only installation that does this. I cannot find an answer anywhere and all other installations work fine. What could be causing this? Which DLL is specific only to this installation that Microsoft does not have an answer to? Thank you. -- components: Installation messages: 192294 nosy: daleastar priority: normal severity: normal status: open title: Won't install. Keeps telling me DLL is missing. type: crash versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue18360> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18360] Won't install. Keeps telling me DLL is missing.
Dale Smith added the comment: http://www.python.org/ftp/python/2.7.5/python-2.7.5.msi That is the URL I downloaded from and the installer. Thank you, Dale On 7/4/2013 4:17 PM, R. David Murray wrote: > R. David Murray added the comment: > > Exactly which installer are you trying to run and where did you download it > from? > > -- > nosy: +r.david.murray > > ___ > Python tracker > <http://bugs.python.org/issue18360> > ___ -- ___ Python tracker <http://bugs.python.org/issue18360> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18360] Won't install. Keeps telling me DLL is missing.
Dale Smith added the comment: Was that all the correct information? Do you need more... i.e. about my computer etc? On 7/4/2013 4:17 PM, R. David Murray wrote: > R. David Murray added the comment: > > Exactly which installer are you trying to run and where did you download it > from? > > -- > nosy: +r.david.murray > > ___ > Python tracker > <http://bugs.python.org/issue18360> > ___ -- ___ Python tracker <http://bugs.python.org/issue18360> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18360] Won't install. Keeps telling me DLL is missing.
Dale Smith added the comment: I do see install and it tries to install. When I click "run" and go to the install menu, I select for "All users" and next and the generic "a dll is missing" message pops up. I'll explore this more. I do not have problems installing anything else. Thank you! -- ___ Python tracker <http://bugs.python.org/issue18360> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18360] Won't install. Keeps telling me DLL is missing.
Dale Smith added the comment: I tried everything that is available to "repair" my Windows 7 installer (unregistered/restarted the service etc). Everything installs fine except this installer. -- ___ Python tracker <http://bugs.python.org/issue18360> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18360] Won't install. Keeps telling me DLL is missing.
Dale Smith added the comment: I do not know when but there is a version that seems to be installed. It's in my programs folder. I opened the python shell and it says it is Python 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit (Intel)] on win32 It still does not explain the dll error message. I do assume its windows (of course). -- ___ Python tracker <http://bugs.python.org/issue18360> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18360] Won't install. Keeps telling me DLL is missing.
Dale Smith added the comment: Has anyone figured out what is causing this failure from my windows 7? Thank you. -- ___ Python tracker <http://bugs.python.org/issue18360> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18360] Won't install. Keeps telling me DLL is missing.
Dale Smith added the comment: I have redownloaded. Still getting the same message. Thank you. -- ___ Python tracker <http://bugs.python.org/issue18360> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18360] Won't install. Keeps telling me DLL is missing.
Dale Smith added the comment: I got it! None of these alone actually worked. But it lead me to get it to work. I did several solutions at once. The three in combination that worked were getting this: http://www.howtogeek.com/howto/windows-vista/add-take-ownership-to-explorer-right-click-menu-in-vista <http://www.howtogeek.com/howto/windows-vista/add-take-ownership-to-explorer-right-click-menu-in-vista/> then I disabled my antivirus and User Account Control in windows 7. I'll bet it was just disabling the UAC that did it though. I will find out later. I need to get back to class now that I have what I need. Thank you so much. If you do need more info or help, please feel free to ask! <http://www.howtogeek.com/howto/windows-vista/add-take-ownership-to-explorer-right-click-menu-in-vista/> -- ___ Python tracker <http://bugs.python.org/issue18360> ___ ___ 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)
Darren Dale added the comment: Quoting the documentation for abstractmethod: "When abstractmethod() is applied in combination with other method descriptors, it should be applied as the innermost decorator, as shown in the following usage examples:" The examples include staticmethod and classmethod. -- ___ Python tracker <http://bugs.python.org/issue16267> ___ ___ 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)
Darren Dale added the comment: There is a very practical reason, which was the whole point of issue11610. Descriptors are should declare themselves abstract when they are composed of abstract methods. If you have a property with an concrete getter but an abstract setter, the property should declare itself abstract until such time as it is provided a concrete setter. If we allow __isabstractmethod__ to be settable by @abstractmethod, it undermines the whole scheme of descriptors delegating their abstractedness to the methods of which they are composed. -- ___ Python tracker <http://bugs.python.org/issue16267> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6343] TimedRotatingFileHandler permission denied rename failure on Windows
Changes by Dale Nagata : Removed file: http://bugs.python.org/file14365/testlog.py ___ Python tracker <http://bugs.python.org/issue6343> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6343] TimedRotatingFileHandler permission denied rename failure on Windows
Changes by Dale Nagata : Added file: http://bugs.python.org/file14366/testlog.py ___ Python tracker <http://bugs.python.org/issue6343> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6343] TimedRotatingFileHandler permission denied rename failure on Windows
New submission from Dale Nagata : Traceback (most recent call last): File "C:\python24\lib\logging\handlers.py", line 74, in emit self.doRollover() File "C:\python24\lib\logging\handlers.py", line 271, in doRollover os.rename(self.baseFilename, dfn) OSError: [Errno 13] Permission denied originally hit on W2K3 but could not see evidence as it was running as a service with stderr not going anywhere, but deeply suspicious since it failed right at midnight each time. whittled down to bare essentials, repro'd on XP running in console window, test case will fail in 2 min when rollover is attempted logging set up as follows: def initlog(): #h = logging.handlers.TimedRotatingFileHandler( LOGFILEPATH, 'MIDNIGHT', 1, 7 ) h = logging.handlers.TimedRotatingFileHandler( LOGFILEPATH, 'M', 2, 7 ) h.setLevel( logging.DEBUG ) f = logging.Formatter( '%(asctime)s %(levelname)s %(message)s', '%Y-%m-%d %H:%M:%S' ) h.setFormatter( f ) logging.root.addHandler( h ) logging.root.setLevel( logging.DEBUG ) searched issue tracker for TimedRotatingFileHandler, no hits -- components: Library (Lib) files: testlog.py messages: 89711 nosy: dnagata severity: normal status: open title: TimedRotatingFileHandler permission denied rename failure on Windows type: crash versions: Python 2.4 Added file: http://bugs.python.org/file14365/testlog.py ___ Python tracker <http://bugs.python.org/issue6343> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15869] IDLE: Include .desktop file and icon
Dale E. Moore added the comment: On Ubuntu 12.10 with Unity the task icon is a question mark. And when locked to launcher the button does not start idle. -- nosy: +DaleEMoore ___ Python tracker <http://bugs.python.org/issue15869> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
