Re: [Python-Dev] 128 bit integer support
On Wed, Dec 4, 2013 at 8:15 AM, Antoine Pitrou solip...@pitrou.net wrote: Aren't you talking about the struct module? In ctypes, it seems it would be sufficient to add a c_int128 type (and/or c_uint128). Even in ctypes these codes are used internally for the field descriptors. For ctypes c_int128 seems reasonable to me. We already have support for for 8-bit, 16-bit, 32-bit, and 64-bit fixed sized integer types with comparable names. The struct module has the notion of a standard size where the size is fixed, but we default to native. -- Meador ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Running the unit test as root/administrator
Am 05.12.13 02:04, schrieb Vajrasky Kok: Cool. What about Linux/Unix/BSD with root account? If we have something similar, I may plan to write unit test for spwd module. Can you please phrase your question more explicit? What is it that you want to be done before writing unit tests for the spwd module? Anybody could run the test suite, and somebody might run it as root - so you must be asking for something else. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Running the unit test as root/administrator
Am 05.12.13 16:21, schrieb Vajrasky Kok: On Thu, Dec 5, 2013 at 11:06 PM, Martin v. Löwis mar...@v.loewis.de wrote: Can you please phrase your question more explicit? What is it that you want to be done before writing unit tests for the spwd module? I am asking buildbot of Linux/Unix/BSD with root account. Do we have it now? Ah. I don't think we have one. If somebody would want to donate one, I suggest to run it in a VM, to reduce the (valid) security concerns that Guido has voiced. If a snapshot of the VM is made, it would be easy to restore in case a commit performs serious damage. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Running the unit test as root/administrator
On Fri, Dec 6, 2013 at 2:29 AM, Martin v. Löwis mar...@v.loewis.de wrote: Am 05.12.13 16:21, schrieb Vajrasky Kok: On Thu, Dec 5, 2013 at 11:06 PM, Martin v. Löwis mar...@v.loewis.de wrote: Can you please phrase your question more explicit? What is it that you want to be done before writing unit tests for the spwd module? I am asking buildbot of Linux/Unix/BSD with root account. Do we have it now? Ah. I don't think we have one. If somebody would want to donate one, I suggest to run it in a VM, to reduce the (valid) security concerns that Guido has voiced. If a snapshot of the VM is made, it would be easy to restore in case a commit performs serious damage. Are we worried about malicious or accidental damage, here? I might be able to offer a buildbot VM, though I don't know what the requirements are. ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Running the unit test as root/administrator
On Thu, Dec 5, 2013 at 11:06 PM, Martin v. Löwis mar...@v.loewis.de wrote: Can you please phrase your question more explicit? What is it that you want to be done before writing unit tests for the spwd module? I am asking buildbot of Linux/Unix/BSD with root account. Do we have it now? Anybody could run the test suite, and somebody might run it as root - so you must be asking for something else. Of course, I can write unit test for spwd module right now and mark it only to be run with root account and skipped with regular user account. But I would argue that it would be hard to find people running test suite with root account. That's why buildbot is helping much in this case. --Vajrasky ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Running the unit test as root/administrator
Am 05.12.13 16:31, schrieb Chris Angelico: Ah. I don't think we have one. If somebody would want to donate one, I suggest to run it in a VM, to reduce the (valid) security concerns that Guido has voiced. If a snapshot of the VM is made, it would be easy to restore in case a commit performs serious damage. Are we worried about malicious or accidental damage, here? Accidental damage is a serious risk, IMO. Malicious damage is a risk for the paranoid: it might be that an SSH key gets stolen, and is then used to commit a trojan. Of course, that would affect all build slaves (but less so if they run in a restricted account), and we would disable the key as soon as we notice, but some damage might have happened. I might be able to offer a buildbot VM, though I don't know what the requirements are. The machine should be up most of the time, including internet connectivity. A fixed IP address is no requirement (although I'm unsure how resilient the slaves are when the IP changes). The admin (i.e. you) needs to set up the box initially, and then care for it in case of problems; a response time of a few days for most of the year would be appreciated (although we can also deal with operators that leave for longer periods of time - we just disable the slave then, and reenable it when the admin brings it back up). The commitment should be for a long period, i.e. a few years. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] One-line abstractmethod function?
Hello Python devs,
As a regular Python user, I find the abc module useful for making
Python's duck typing more explicit. In particular, I ofen use it
like a Java interface or C header, to provide methods to implement for a
given duck type.
90% of the time, it ends up looking something like this:
class Foo(metaclass=abc.ABCMeta):
@abc.abstractmethod
def f1(self):
raise NotImplementedError
@staticmethod
@abc.abstractmethod
def f2(arg1):
raise NotImplementedError
...
What if there was a function, say make_abstract_method (better name
pending), so that the above could be written like:
class Foo(metaclass=abc.ABCMeta):
f1 = abc.make_abstract_method('f1', ['self'])
f2 = staticmethod(abc.make_abstract_method('f2', ['arg1']))
...
I think that it would make ABC definitions a lot more compact for many
use cases, but I welcome any criticisms against this idea.
Allen Li
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] One-line abstractmethod function?
How would you get the docstrings in? It seems cramming that much on a
single line doesn't help readability (even though I agree there is a
fair amount of boilerplace).
On Thu, Dec 5, 2013 at 10:20 AM, Allen Li cyberdup...@gmail.com wrote:
Hello Python devs,
As a regular Python user, I find the abc module useful for making
Python's duck typing more explicit. In particular, I ofen use it
like a Java interface or C header, to provide methods to implement for a
given duck type.
90% of the time, it ends up looking something like this:
class Foo(metaclass=abc.ABCMeta):
@abc.abstractmethod
def f1(self):
raise NotImplementedError
@staticmethod
@abc.abstractmethod
def f2(arg1):
raise NotImplementedError
...
What if there was a function, say make_abstract_method (better name
pending), so that the above could be written like:
class Foo(metaclass=abc.ABCMeta):
f1 = abc.make_abstract_method('f1', ['self'])
f2 = staticmethod(abc.make_abstract_method('f2', ['arg1']))
...
I think that it would make ABC definitions a lot more compact for many
use cases, but I welcome any criticisms against this idea.
Allen Li
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] One-line abstractmethod function?
On Thu, Dec 5, 2013 at 1:24 PM, Guido van Rossum gu...@python.org wrote: How would you get the docstrings in? It seems cramming that much on a single line doesn't help readability (even though I agree there is a fair amount of boilerplace). One way to reduce the amount of boilerplate code is to make abstractmethod to supply raise NotImplementedError body when none is given. Then you can write class Foo: @abc.abstractmethod def do_bar(self): perform bar instead of class Foo: @abc.abstractmethod def do_bar(self): perform bar raise NotImplementedError The docstring will be required when skipping the body which is probably a good thing. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] One-line abstractmethod function?
On 12/05/2013 10:56 AM, Alexander Belopolsky wrote: On Thu, Dec 5, 2013 at 1:24 PM, Guido van Rossum wrote: How would you get the docstrings in? [...] One way to reduce the amount of boilerplate code is to make abstractmethod to supply raise NotImplementedError body when none is given. Then you can write class Foo: @abc.abstractmethod def do_bar(self): perform bar The docstring will be required when skipping the body which is probably a good thing. How will abstractmethod know its function has no body? -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] One-line abstractmethod function?
On Thu, Dec 5, 2013 at 2:22 PM, Ethan Furman et...@stoneleaf.us wrote: On 12/05/2013 10:56 AM, Alexander Belopolsky wrote: On Thu, Dec 5, 2013 at 1:24 PM, Guido van Rossum wrote: How would you get the docstrings in? [...] One way to reduce the amount of boilerplate code is to make abstractmethod to supply raise NotImplementedError body when none is given. Then you can write class Foo: @abc.abstractmethod def do_bar(self): perform bar The docstring will be required when skipping the body which is probably a good thing. How will abstractmethod know its function has no body? Technically you could inspect the code object of the method. to figure out if the body is empty. But I would be very leery of this being a default behaviour. Raising NotImplementedError is not necessarily what the default result should be for a method. If you are building a class that supports multiple inheritance you will be calling super().do_bar() almost blindly which, if you are not careful, will raise NotImplementedError and that might not be appropriate. Maybe returning None is more reasonable, maybe raising TypeError. But support a default blindly like this can promote bad practices. You can see all of changes I had to make for importlib.abc in Python 3.4 to have API-matching default exceptions and return values instead of blindly raising NotImplementedError as a lesson learned: http://docs.python.org/3.4/library/importlib.html#module-importlib.abc. Hunt down Thomas Wouters at PyCon if you want to hear the same arguments he gave me as to why blindly raise NotImplementedError is bad. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] One-line abstractmethod function?
On 05/12/2013 19:22, Ethan Furman wrote: On 12/05/2013 10:56 AM, Alexander Belopolsky wrote: On Thu, Dec 5, 2013 at 1:24 PM, Guido van Rossum wrote: How would you get the docstrings in? [...] One way to reduce the amount of boilerplate code is to make abstractmethod to supply raise NotImplementedError body when none is given. Then you can write class Foo: @abc.abstractmethod def do_bar(self): perform bar The docstring will be required when skipping the body which is probably a good thing. How will abstractmethod know its function has no body? An abstract method won't have a body (I'm not counting the docstring). If it _does_ have a body, then it's _not_ an abstract method! ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] One-line abstractmethod function?
On Thu, Dec 05, 2013 at 10:24:11AM -0800, Guido van Rossum wrote:
How would you get the docstrings in? It seems cramming that much on a
single line doesn't help readability (even though I agree there is a
fair amount of boilerplace).
I was basing my initial suggestion somewhat on collections.namedtuple,
which doesn't support docstring either. One option would be to simply
not allow for docstrings, requiring the boilerplate method, the other
would be to add a parameter for the docstring:
make_abstractmethod(name, arglist, docstring='')
On Thu, Dec 5, 2013 at 2:22 PM, Ethan Furman et...@stoneleaf.us wrote:
On 12/05/2013 10:56 AM, Alexander Belopolsky wrote:
On Thu, Dec 5, 2013 at 1:24 PM, Guido van Rossum wrote:
How would you get the docstrings in? [...]
One way to reduce the amount of boilerplate code is to make abstractmethod
to supply raise NotImplementedError body when none is given. Then you can
write
class Foo:
@abc.abstractmethod
def do_bar(self):
perform bar
The docstring will be required when skipping the body which is probably a
good thing.
How will abstractmethod know its function has no body?
I don't think this is a good idea at all, very magical behavior. It is
not intuitive or explicit that an abstractmethod-decorated empty
function raises NotImplementedError.
On Thu, Dec 05, 2013 at 03:06:00PM -0500, Brett Cannon wrote:
But I would be very leery of this being a default behaviour. Raising
NotImplementedError is not necessarily what the default result should be
for a method. If you are building a class that supports multiple
inheritance you will be calling super().do_bar() almost blindly which, if
you are not careful, will raise NotImplementedError and that might not be
appropriate. Maybe returning None is more reasonable, maybe raising
TypeError. But support a default blindly like this can promote bad
practices.
I'm not sure what's considered best practice with super() at the moment.
super() is dangerous if you don't know what you are doing in
multi-inheritance design, so I'd consider calling super() blindly is the
problem here, not raising NotImplementedError. I do think raising
NotImplementedError is reasonable default behavior for an
abstractmethod. The only two alternatives are doing nothing/pass/return
None or having actual code in the method.
The former is only useful to silently ignore blind super() calling, the
latter you would define and decorate the method normally.
On Thu, Dec 05, 2013 at 08:39:05PM +, MRAB wrote:
An abstract method won't have a body (I'm not counting the docstring).
If it _does_ have a body, then it's _not_ an abstract method!
It could have a body, though I would agree it's not commonly used that
way. Maybe something like the following (though it's a poor example):
class Printer(metaclass=abc.ABCMeta):
@abc.abstractmethod
def print(self):
print(Print done.)
class Foo(Printer):
def print(self):
print('foo')
super().print()
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] One-line abstractmethod function?
On Thu, Dec 5, 2013 at 3:06 PM, Brett Cannon br...@python.org wrote: How will abstractmethod know its function has no body? Technically you could inspect the code object of the method. to figure out if the body is empty. One way if to check f.__code__.co_lnotab - it will be empty when f has no body. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] One-line abstractmethod function?
On 12/05/2013 12:39 PM, MRAB wrote: On 05/12/2013 19:22, Ethan Furman wrote: On 12/05/2013 10:56 AM, Alexander Belopolsky wrote: On Thu, Dec 5, 2013 at 1:24 PM, Guido van Rossum wrote: How would you get the docstrings in? [...] One way to reduce the amount of boilerplate code is to make abstractmethod to supply raise NotImplementedError body when none is given. Then you can write class Foo: @abc.abstractmethod def do_bar(self): perform bar The docstring will be required when skipping the body which is probably a good thing. How will abstractmethod know its function has no body? An abstract method won't have a body (I'm not counting the docstring). If it _does_ have a body, then it's _not_ an abstract method! To quote the docs [1]: Note Unlike Java abstract methods, these abstract methods may have an implementation. This implementation can be called via the super() mechanism from the class that overrides it. This could be useful as an end-point for a super-call in a framework that uses cooperative multiple-inheritance. -- ~Ethan~ [1] http://docs.python.org/dev/library/abc.html ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_bind_port and test_find_unused_port fail due to missing SO_REUSEPORT when building Python 3.3.2-r2 (from portage) on 3.7.10-gentoo-r1 kernel
On Tue, Dec 3, 2013 at 9:44 AM, Guido van Rossum gu...@python.org wrote: Thanks for reporting this. With pleasure! I'm just glad to have reported a valid bug for once in my life :b This really belongs in the Python issue tracker (bugs.python.org) -- can you submit a bug there? I've opened issue # 19901 [1] as requested. My hunch is that, because this seems to be a relatively new feature, we should just catch and ignore the exception from that specific call. I agree, although I sort of phrased it poorly in the bug. Thank you again for your support (and sorry for the delayed response). Python is cool :] [1]: http://bugs.python.org/issue19901 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] One-line abstractmethod function?
On Thu, Dec 5, 2013 at 1:12 PM, Allen Li cyberdup...@gmail.com wrote:
On Thu, Dec 05, 2013 at 10:24:11AM -0800, Guido van Rossum wrote:
How would you get the docstrings in? It seems cramming that much on a
single line doesn't help readability (even though I agree there is a
fair amount of boilerplace).
I was basing my initial suggestion somewhat on collections.namedtuple,
which doesn't support docstring either.
Not yet. :-) (http://bugs.python.org/issue16669)
One option would be to simply
not allow for docstrings, requiring the boilerplate method, the other
would be to add a parameter for the docstring:
make_abstractmethod(name, arglist, docstring='')
On Thu, Dec 5, 2013 at 2:22 PM, Ethan Furman et...@stoneleaf.us wrote:
On 12/05/2013 10:56 AM, Alexander Belopolsky wrote:
On Thu, Dec 5, 2013 at 1:24 PM, Guido van Rossum wrote:
How would you get the docstrings in? [...]
One way to reduce the amount of boilerplate code is to make abstractmethod
to supply raise NotImplementedError body when none is given. Then you can
write
class Foo:
@abc.abstractmethod
def do_bar(self):
perform bar
The docstring will be required when skipping the body which is probably a
good thing.
How will abstractmethod know its function has no body?
I don't think this is a good idea at all, very magical behavior. It is
not intuitive or explicit that an abstractmethod-decorated empty
function raises NotImplementedError.
Agreed.
On Thu, Dec 05, 2013 at 03:06:00PM -0500, Brett Cannon wrote:
But I would be very leery of this being a default behaviour. Raising
NotImplementedError is not necessarily what the default result should be
for a method. If you are building a class that supports multiple
inheritance you will be calling super().do_bar() almost blindly which, if
you are not careful, will raise NotImplementedError and that might not be
appropriate. Maybe returning None is more reasonable, maybe raising
TypeError. But support a default blindly like this can promote bad
practices.
I'm not sure what's considered best practice with super() at the moment.
super() is dangerous if you don't know what you are doing in
multi-inheritance design, so I'd consider calling super() blindly is the
problem here, not raising NotImplementedError.
Actually I think the combination of not knowing what you're doing and
mulitple inheritance is the problem.
I do think raising
NotImplementedError is reasonable default behavior for an
abstractmethod.
When not using multiple inheritance, yes.
The only two alternatives are doing nothing/pass/return
None or having actual code in the method.
The former is only useful to silently ignore blind super() calling, the
latter you would define and decorate the method normally.
Actually if you want to support multiple inheritance of your ABC, your
abstract methods *must* be no-ops (or have some kind of default
behavior that can always be done last).
On Thu, Dec 05, 2013 at 08:39:05PM +, MRAB wrote:
An abstract method won't have a body (I'm not counting the docstring).
If it _does_ have a body, then it's _not_ an abstract method!
It could have a body, though I would agree it's not commonly used that
way. Maybe something like the following (though it's a poor example):
class Printer(metaclass=abc.ABCMeta):
@abc.abstractmethod
def print(self):
print(Print done.)
class Foo(Printer):
def print(self):
print('foo')
super().print()
That's exactly right.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] One-line abstractmethod function?
On 12/05/2013 10:20 AM, Allen Li wrote: 90% of the time, it ends up looking something like this: class Foo(metaclass=abc.ABCMeta): @abc.abstractmethod def f1(self): raise NotImplementedError @staticmethod @abc.abstractmethod def f2(arg1): raise NotImplementedError I think we're getting sidetracked by the `raise NotImplementedError` -- why do you have that line in there? If I understand the ABCs correctly a class that does *not* have concrete methods to replace the abstract methods will raise an exception at class creation time, so why do you need the `raise NotImplementedError`? It would only ever happen on a super() type of call. Having said all that, I would hope that any abstract class I had to implement would have good doc strings, and the multi-line format is much easier to read. -1 on the one-liner. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-Dev Digest, Vol 125, Issue 5
Hi Antoine, I've found that libffi does support this type, but sadly ctypes and cffi do not. Adding to ctypes does not seem to be trivial, since the description of an integer type is limited to a single character (q in the case of long long). q is considered to be a length of 8, whereas what I really want is the integer type ll which is correctly considered length of 16. Aren't you talking about the struct module? In ctypes, it seems it would be sufficient to add a c_int128 type (and/or c_uint128). Adding a c_int128 type seems somewhat non trivial though. The specific-sized c_intX types are assigned to the named equivalents (c_long etc.). Getting a named type that equates to 128-bit (on OSX at least anyway) is the problem. The : class c_something(_SimpleCData): _type_ = ? _check_size(c_something) The type q seems to relate to long long (quad word?) - but that has a size of 8 for me. I don't know: what something should be, and what ? should be. I am guessing stay away from the long long long schenanigans and just define c_int128 directly: class c_int128(_SimpleCData): _type_ = ? .. but there still seems to lack a _type_ that will relate to a 128-bit integer.. OK, it seems that adding a new ? that relates to 128-bit requires the change to struct module. This seems to be in lib-dynload and is written in C not python? Can anyone give me some pointers as to why this has not been added to date, and the best line of attack? Probably because noone needed it until now? We have a comprehensive guide if you want to contribute a patch: http://docs.python.org/devguide/ The first step would be to open an enhancement request on the issue tracker, the discussion will then move on there: http://bugs.python.org/ (if you want to enhance both the ctypes and struct modules, please open a separate issue for each) OK, thanks. I had been put off by the bugs title since this is an enhancement.. will do. Regards, Fil. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 is five years old
[Brett] On 2008-12-03, Python 3.0.0 was released by Barry. Dang - nobody ever tells me anything. Congratulations! It's about time 3.0.0 was released ;-) ... Thanks to those in the community who stuck by the dev team and had faith we knew what we were doing and have continued to help everyone move forward and off of Python 2 to realize how much more pleasant Python 3 is to work with. I'm doing all my own coding in 3 now - I like it. I just wish someone had told me in 2008 ;-) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] One-line abstractmethod function?
On Thu, Dec 05, 2013 at 01:33:00PM -0800, Guido van Rossum wrote: The only two alternatives are doing nothing/pass/return None or having actual code in the method. The former is only useful to silently ignore blind super() calling, the latter you would define and decorate the method normally. Actually if you want to support multiple inheritance of your ABC, your abstract methods *must* be no-ops (or have some kind of default behavior that can always be done last). I must respectfully disagree with this. If your ABCs aren't meant to be in the MRO, then you should be @registering them as virtual classes and not inheriting them. The trick with Python multiple inheritance and super() (from personal experience) is to not think of it as multiple inheritance (a tree with cycles), but as building the MRO (linear, the same as single inheritance). ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 is five years old
Tim Peters writes: I'm doing all my own coding in 3 now - I like it. I just wish someone had told me in 2008 ;-) I think it's a testament to the basic strength of the language that you haven't noticed that *nothing has changed* in Python 2 for several years. ;-) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] One-line abstractmethod function?
On 12/05/2013 06:08 PM, Allen Li wrote: On Thu, Dec 05, 2013 at 01:33:00PM -0800, Guido van Rossum wrote: Actually if you want to support multiple inheritance of your ABC, your abstract methods *must* be no-ops (or have some kind of default behavior that can always be done last). Done last or first really depends on what the default behavior is, doesn't it? Using __new__ as an example, the chain of calls for that has the most ancestorish (yeah, I just made that word up ;) method doing the work first, with each less-ancestorish method building on to that as the call chain unwinds. I must respectfully disagree with this. If your ABCs aren't meant to be in the MRO, then you should be @registering them as virtual classes and not inheriting them. Why would you think they are not meant to be in the MRO? When dealing with multiple-inheritance, there must be a base class that does not try to call super() (object does not work for this) -- what better class to use than the base abstract class? The trick with Python multiple inheritance and super() (from personal experience) is to not think of it as multiple inheritance (a tree with cycles), but as building the MRO (linear, the same as single inheritance). -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] One-line abstractmethod function?
On Thu, Dec 5, 2013 at 6:08 PM, Allen Li cyberdup...@gmail.com wrote: On Thu, Dec 05, 2013 at 01:33:00PM -0800, Guido van Rossum wrote: The only two alternatives are doing nothing/pass/return None or having actual code in the method. The former is only useful to silently ignore blind super() calling, the latter you would define and decorate the method normally. Actually if you want to support multiple inheritance of your ABC, your abstract methods *must* be no-ops (or have some kind of default behavior that can always be done last). I must respectfully disagree with this. If your ABCs aren't meant to be in the MRO, then you should be @registering them as virtual classes and not inheriting them. Registering is meant to be a method of last resort; it is implemented for cases where an ABC is introduced after implementations already exist (IOW, formalizing duck typing). When the ABC *is* actually used as a base class, when the standard M.I. patterns are used, the abstract methods must be no-ops, because they will be called (last). The trick with Python multiple inheritance and super() (from personal experience) is to not think of it as multiple inheritance (a tree with cycles), but as building the MRO (linear, the same as single inheritance). I'm not sure I understand -- or maybe I disagree. A tree with cycles seems a really poor way to describe what is usually referred to as a diamond inheritance diagram. The right patterns require that you design your class to be unaware of the exact MRO. But we're getting off-topic. You should probably read one of the standard tutorials on the topic to refresh your use of the terminology. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] One-line abstractmethod function?
On Thu, Dec 5, 2013 at 6:31 PM, Ethan Furman et...@stoneleaf.us wrote: On Thu, Dec 05, 2013 at 01:33:00PM -0800, Guido van Rossum wrote: Actually if you want to support multiple inheritance of your ABC, your abstract methods *must* be no-ops (or have some kind of default behavior that can always be done last). Done last or first really depends on what the default behavior is, doesn't it? Using __new__ as an example, the chain of calls for that has the most ancestorish (yeah, I just made that word up ;) method doing the work first, with each less-ancestorish method building on to that as the call chain unwinds. If you count which call *starts* first, the base class is always called later than the subclass (even if it finishes earlier :-). -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] One-line abstractmethod function?
Hi,
maybe a syntax like that can correspond:
class MyObject(metaclass=ObjectSpec):
''' MyObject doc'''
'attr1 contains something'
attr1 = None
'attr2 contains something'
attr2 = str
'method1 do something'
method1 = NotImplementedMethod('self', 'arg1', kwarg1=str)
Metaclass ObjectSpec would extend ABCMeta to search class source code for
comments before members assignement,
and replace NotImplementedMethod objects by a corresponding method wich
signature can simply be given by arguments or by ArgSpec, FullArgSpec,
Signature...
with factories like these of Signature (from_function, from_builtins...).
2013/12/6 Guido van Rossum gu...@python.org
On Thu, Dec 5, 2013 at 6:31 PM, Ethan Furman et...@stoneleaf.us wrote:
On Thu, Dec 05, 2013 at 01:33:00PM -0800, Guido van Rossum wrote:
Actually if you want to support multiple inheritance of your ABC, your
abstract methods *must* be no-ops (or have some kind of default
behavior that can always be done last).
Done last or first really depends on what the default behavior is,
doesn't
it? Using __new__ as an example, the chain of calls for that has the
most
ancestorish (yeah, I just made that word up ;) method doing the work
first,
with each less-ancestorish method building on to that as the call chain
unwinds.
If you count which call *starts* first, the base class is always
called later than the subclass (even if it finishes earlier :-).
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/apieum%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
