Re: [Python-Dev] Patchs and bugs resume
old and had not been touched in ages. Hopefully you will be able to easily port this over to the new tracker once it's up (that should happen 2-4 weeks after 2.5.1 is released). You can be sure I'll port it... When you do, make sure you take a look at roundup's search facilities. Roundup keeps a 'last activity' field, on which you can search and sort, and a 'creation date' field (likewise). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunk and 2.5 are borken
Neal Norwitz schrieb: There are several failures with both the trunk and 2.5 branch. I have fixed one problem that allows the tests to run on Windows. That was fixed by reverting 54407 on the trunk. It still needs to be reverted on the 2.5 branch. You can go back in the buildbot logs to find out more about the problem. The 3 test failures on Windows are: test_urllib test_mailbox and test_posixpath. The first 2 fail due to 'Access denied' on @test.2. I'm guessing this is due to the file not being closed before trying to delete it. I don't know where this problem showed up, but it was after rev 54406 which is when all the tests were passing on Windows (and 54407 was backed out). I now changed the test in said revision to not use a second test directory, but only directories under TESTFN. This specific test should not cause any more problems now. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I vote to reject: Adding timeout to socket.py and httplib.py.
[Facundo Batista] Remember that this function primary use is for higher level libraries Yes, I see that clearly now. But remember that by adding a new function to the socket module to support httplib et al, you are also adding a function to the socket module that will be used directly by end users. I vote to reject this patch. The underlying problem it is trying to address is that httplib.HTTPConnection objects do not support timeouts. But solving that problem by moving the functionality of the HTTPConnection.connect() method inside the socket module as a standalone function is the *wrong* solution. The proposed new function does not belong in the socket module. In contrast to all of the other socket creation and management functionality in the socket module, the new function does not handle non-blocking IO. Also, the new functions' use-case is too restricted, to client connections with a positive timeout: this functionality is trivially available using existing functionality, e.g. mysock = socket(AF_INET, SOCK_STREAM) mysocket.settimeout(1.0) mysocket.connect( (host, port) ) # etc In contrast to the new function, the existing functionality in the socket module is much more general, and much better designed to handle the wide range of situations in which sockets are used. Socket APIs are hard to do right because sockets are complex and hard to do right. The problem the patch seeks to fix is is in httplib; the problem should be fixed in httplib. I recommend modifying the patch to remove *all* proposed changes to the socket module. Instead, the patch should restrict itself to fixing the httplib module. Sorry, Alan. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for NamedTemporaryFile?
Greg Ewing wrote: Gregory P. Smith wrote: I prefer the default of clean up after itself as is to avoid leaving temporary file turds on systems caused by us lazy programmers. Maybe instead of an option there should be a separate function with a different name, such as NewUniqueFile. For the use cases I have in mind, the file isn't really temporary at all. Or rather, only the name is temporary, as it ultimately gets renamed. I'm in favor of adding such a function. I've already wrote my way around this missing feature before. The tempfile modules AFAIK is the only portable way to make a unique filename and open it without exposing a race condition. As it is, it's not that difficult to write this function yourselves using mkstemp directly, but I believe there is a great benefit to have it in the stdlib. -Scott -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for NamedTemporaryFile?
Scott Dial wrote: Greg Ewing wrote: Maybe instead of an option there should be a separate function with a different name, such as NewUniqueFile. I'm in favor of adding such a function. A tangential question -- why are TemporaryFile and NamedTemporaryFile named in TitleCase, when they're functions and not classes? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for NamedTemporaryFile?
Greg Ewing wrote: A tangential question -- why are TemporaryFile and NamedTemporaryFile named in TitleCase, when they're functions and not classes? I wondered the same. At first draft of my email I wrote class operating under the assumption that only classes got to be camel-cased. If I had to guess, the rationale was that they are simply wrappers a class. Nevertheless, tempfile dates well back before the PEP 8 style guidelines. I think consistency would dictate that a newly added function should match the other ones, but I have no strong feelings about this. -Scott -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for NamedTemporaryFile?
On 3/21/07, Scott Dial [EMAIL PROTECTED] wrote: Greg Ewing wrote: A tangential question -- why are TemporaryFile and NamedTemporaryFile named in TitleCase, when they're functions and not classes? I wondered the same. At first draft of my email I wrote class operating under the assumption that only classes got to be camel-cased. If I had to guess, the rationale was that they are simply wrappers a class. Nevertheless, tempfile dates well back before the PEP 8 style guidelines. I think consistency would dictate that a newly added function should match the other ones, but I have no strong feelings about this. I wouldn't bet on that. The ElementTree XML module was added to Python 2.5 and it does not follow PEP 8 style (method names are not words separated by underscores). -- Gustavo J. A. M. Carneiro The universe is always one step beyond logic. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I vote to reject: Adding timeout to socket.py and httplib.py.
Alan Kennedy wrote: The proposed new function does not belong in the socket module. In contrast to all of the other socket creation and management functionality in the socket module, the new function does not handle non-blocking IO. The rest of the socket module isn't going anywhere. If you want to do non-blocking IO, don't use the convenience function that is designed for use with blocking IO (even better, use a library that makes non-blocking IO easier to live with, like asyncore or Twisted). While the name of the proposed function and it's signature need to change (which Facundo has already acknowledged), correctly looking up an address and attempting to connect to it is a non-trivial operation, but one that is duplicated in several stdlib modules (httplib, poplib, ftplib, smtplib at least). This level of repetition for a dozen line function is insane - Facundo's patch is merely the first step towards standardising it. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for NamedTemporaryFile?
Greg Ewing schrieb: Scott Dial wrote: Greg Ewing wrote: Maybe instead of an option there should be a separate function with a different name, such as NewUniqueFile. I'm in favor of adding such a function. A tangential question -- why are TemporaryFile and NamedTemporaryFile named in TitleCase, when they're functions and not classes? Probably because they are factory functions potentially returning a _TemporaryFileWrapper. If they were functions, they'd have to be verbed, e.g. make_temporary_file(). The class/function distinction is not so clear in Python from the user's point of view since there is no different calling syntax. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I vote to reject: Adding timeout to socket.py and httplib.py.
Alan Kennedy wrote: But remember that by adding a new function to the socket module to support httplib et al, you are also adding a function to the socket module that will be used directly by end users. I vote to reject this patch. Well, you can vote to name it _create_connection(), if your concern is what the end user will do with it. Or it's just denial towards this patch? I recommend modifying the patch to remove *all* proposed changes to the socket module. Instead, the patch should restrict itself to fixing the httplib module. -1 to repeat the same functionality in 5 other libraries. As I said above, we can make it non-public. So, as a resume of the choices we still need to settle: a) Repeat the same functionality in 5 other libraries b) Write the function in socket.py, public c) Write the function in socket.py, non public We need to make the decission. The functionality was needed years ago, I don't want to lose a year discussing... The way I see it, we have three posible ways: a) python-dev votes b) python-dev doesn't care, nobody votes, I make it my way c) Guido settles this down Voting is open, ;) Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I vote to reject: Adding timeout to socket.py and httplib.py.
Facundo Voting is open, ;) ... Facundo So, as a resume of the choices we still need to settle: Facundo a) Repeat the same functionality in 5 other libraries Facundo b) Write the function in socket.py, public Facundo c) Write the function in socket.py, non public I vote 'c'. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I vote to reject: Adding timeout to socket.py and httplib.py.
[Facundo] Voting is open, ;) So what are we voting on exactly? The patch as it currently is? The patch has not been updated to reflect recent discussions on the list. Will the patch be updated before the vote? I have one more issue with the patch. I think that the exception handling in the function is wrong. This is (approximately) the way the patch is currently defined. def create_connection(address, **kwargs): msg = getaddrinfo returns an empty list host, port = address for res in getaddrinfo(host, port, 0, SOCK_STREAM): af, socktype, proto, canonname, sa = res sock = None try: [snip] return socket except error, err: msg = str(err) # -- don't do this if sock is not None: sock.close() raise error(msg) Changing the exception to with msg = str(err) is the wrong thing to do: this will hide the exception and make comparisons with symbolic constants fail, for users that want to handle exceptions. The correct way to handle 1. An empty return from getaddrinfo() 2. Other socket errors is as follows def create_connection(address, **kwargs): host, port = address for res in getaddrinfo(host, port, 0, SOCK_STREAM): af, socktype, proto, canonname, sa = res sock = None try: [snip] return new_socket except error, err: if sock is not None: sock.close() raise err else: raise error(getaddrinfo returns an empty list) [Facundo] Or it's just denial towards this patch? I think this patch is poorly designed and poorly implemented. There are multiple problems in its 17 lines of socket module code; every time I look I find a new problem. Sorry. Alan. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for NamedTemporaryFile?
Georg Brandl wrote: Greg Ewing schrieb: Scott Dial wrote: A tangential question -- why are TemporaryFile and NamedTemporaryFile named in TitleCase, when they're functions and not classes? Probably because they are factory functions potentially returning a _TemporaryFileWrapper. If they were functions, they'd have to be verbed, e.g. make_temporary_file(). The class/function distinction is not so clear in Python from the user's point of view since there is no different calling syntax. Actually the distinction is very clear: class _PrivateClass(object): ... pass ... def FunctionNamedToLookLikeClass(): ... return _PrivateClass() ... pc = _PrivateClass() isinstance(pc, _PrivateClass) True fntllc = FunctionNamedToLookLikeClass() isinstance(fntllc, FunctionNamedToLookLikeClass) Traceback (most recent call last): File stdin, line 1, in module TypeError: isinstance() arg 2 must be a class, type, or tuple of classes and types That's sure to be an unpleasant surprise for someone. -- Aaron Bingham Senior Software Engineer [EMAIL PROTECTED] Tel. +49 (0)351 4173-146 Fax +49 (0)351 4173-109 Cenix BioScience GmbH Tatzberg 47 01307 Dresden, Germany www.cenix-bioscience.com - Sitz der Gesellschaft (Place of Business): Dresden Geschäftsführer (CEO): Dr. Christophe J. Echeverri Amtsgericht (Local Court): Dresden, HRB 19964 Ust-ID (VAT-No.): DE205824437 - ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I vote to reject: Adding timeout to socket.py and httplib.py.
Alan Kennedy wrote: I think this patch is poorly designed and poorly implemented. There are multiple problems in its 17 lines of socket module code; every time I look I find a new problem. Code which is copied verbatim from httplib, and also occurs with slight variations in several other standard library modules. So all these objections indicate to me is that the operation *needs* to be centralised, any issues corrected, and then the corrected version invoked from all of the places in the standard library that need it. httplib just happens to be the first cab off the rank (as was discussed on this list a short time ago). The objection about but it doesn't support non-blocking sockets doesn't make sense to me. This is a function to make creation of a blocking socket more convenient - if you're doing non-blocking IO, why would you even try to use it? Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I vote to reject: Adding timeout to socket.py and httplib.py.
Alan Kennedy wrote: So what are we voting on exactly? The patch as it currently is? The patch has not been updated to reflect recent discussions on the list. Will the patch be updated before the vote? The voting is on a, b or c. The patch will be updated after I know what python-dev want to do. The correct way to handle 1. An empty return from getaddrinfo() 2. Other socket errors is as follows def create_connection(address, **kwargs): host, port = address for res in getaddrinfo(host, port, 0, SOCK_STREAM): af, socktype, proto, canonname, sa = res sock = None try: [snip] return new_socket except error, err: if sock is not None: sock.close() raise err else: raise error(getaddrinfo returns an empty list) Wrong! You're raising an error the first time you can not connect. Your way, the for is superfluous. You're changing functionality here... See? It's not so easy. Maybe I should correct the patch like this: msg = getaddrinfo returns an empty list host, port = address for res in getaddrinfo(host, port, 0, SOCK_STREAM): af, socktype, proto, canonname, sa = res sock = None try: [snip] return sock except error, msg: if sock is not None: sock.close() raise error, msg Problems with this approach: - It raises an exception the old way - If you try to create three sockets, and all with errors, you'll only see the last one. Why I think that this is the way to go: - Because you're not changing the semantics of the function. Right now it's like this, and maybe we break some code if we change it. I think this patch is poorly designed and poorly implemented. There are multiple problems in its 17 lines of socket module code; every time I look I find a new problem. It's better than yours. Talk is cheap. Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for NamedTemporaryFile?
Aaron Bingham schrieb: Georg Brandl wrote: Greg Ewing schrieb: Scott Dial wrote: A tangential question -- why are TemporaryFile and NamedTemporaryFile named in TitleCase, when they're functions and not classes? Probably because they are factory functions potentially returning a _TemporaryFileWrapper. If they were functions, they'd have to be verbed, e.g. make_temporary_file(). The class/function distinction is not so clear in Python from the user's point of view since there is no different calling syntax. Actually the distinction is very clear: class _PrivateClass(object): ... pass ... def FunctionNamedToLookLikeClass(): ... return _PrivateClass() ... pc = _PrivateClass() isinstance(pc, _PrivateClass) True fntllc = FunctionNamedToLookLikeClass() isinstance(fntllc, FunctionNamedToLookLikeClass) Traceback (most recent call last): File stdin, line 1, in module TypeError: isinstance() arg 2 must be a class, type, or tuple of classes and types That's sure to be an unpleasant surprise for someone. whisperduck typing.../whisper But you have a valid point. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I vote to reject: Adding timeout to socket.py and httplib.py.
On 3/21/07, Facundo Batista [EMAIL PROTECTED] wrote: So, as a resume of the choices we still need to settle: a) Repeat the same functionality in 5 other libraries b) Write the function in socket.py, public c) Write the function in socket.py, non public The fact that it's needed in 5 places in the stdlib suggests that there's plenty of user code that could benefit from it too. Hence, I prefer (b), but if that really freaks people out, I'm okay with (c) too. I'm not okay with (a). Thanks, by the way, for creating this patch (and updating it based on python-dev feedback). I think it's really important for the maintainability of Python that duplicate code is factored out whenever possible. STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I vote to reject: Adding timeout to socket.py and httplib.py.
[Facundo] Talk is cheap. I'm sorry if you see my attempts to review your patch as cheap talk. Maybe I should have just kept my opinion to myself. You'll get your chance to return the favour when I check in my upcoming 1000+ line change to jython 2.3 to bring the jython socket, select and asyncore modules up-to-date with cpython 2.5, including providing ssl support, non-blocking IO, select/poll, etc, for the first time in jython. Alan. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I vote to reject: Adding timeout to socket.py and httplib.py.
[Facundo] Talk is cheap. I'm sorry if you see my attempts to review your patch as cheap talk. Maybe I should have just kept my opinion to myself. You'll get your chance to return the favour when I check in my upcoming 1000+ line change to jython 2.3 to bring the jython socket, select and asyncore modules up-to-date with cpython 2.5, including providing ssl support, non-blocking IO, select/poll, etc, for the first time in jython. Alan. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I vote to reject: Adding timeout to socket.py and httplib.py.
Facundo Batista [EMAIL PROTECTED] wrote: Alan Kennedy wrote: I recommend modifying the patch to remove *all* proposed changes to the socket module. Instead, the patch should restrict itself to fixing the httplib module. -1 to repeat the same functionality in 5 other libraries. As I said above, we can make it non-public. So, as a resume of the choices we still need to settle: a) Repeat the same functionality in 5 other libraries b) Write the function in socket.py, public c) Write the function in socket.py, non public b or c is fine, I have no preference. In regards to 'there is no way to create a blocking socket this way', Alan is off his rocker. Facundo has already stated that he would like to use something that will allow for the passing of None as a timeout argument to specify no timeout - aka blocking sockets, as per sock.settimeout(None) (through either **kwargs or timeout=sentinel). The function is needed, and the implementation is sufficient for its intended uses. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I vote to reject: Adding timeout to socket.py and httplib.py.
[Josiah] In regards to 'there is no way to create a blocking socket this way', Alan is off his rocker. I am not off my rocker. And I never wrote the words you place in quotes (except in relation to an earlier defect in the patch where the timeout=None value was ignored). What I clearly stated is that the function as is doesn't cater for *non-blocking* sockets. I also clearly stated that I have no problem with the fact that it doesn't handle non-blocking sockets, but this either A: Needs to be enforced in the function by disallowing zero timeouts B: Needs to be recorded in the documentation The use cases for the function are limited: that's fine. But either explicitly limit them or document those limits. The function is needed, and the implementation is sufficient for its intended uses. When all the defects are fixed, it will be sufficient. Alan. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunk and 2.5 are borken
test_posixpath is failing in: test_relpath This is due to #1339796, r54419. I left a comment in the tracker. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunk and 2.5 are borken
On 3/21/07, Martin v. Löwis [EMAIL PROTECTED] wrote: test_posixpath is failing in: test_relpath This is due to #1339796, r54419. I left a comment in the tracker. This is my check-in. I'll have a fix shortly. Collin Winter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Adding timeout to socket.py and httplib.py - Updated
I updated the patch #1676823, reflecting discussion here: - The function name changed, now it's _create_connection(). Its signature also changed: now, timeout is mandatorily named. - HTTPConnection has the posibility to call timeout with a number, and also with None. In both cases, it updates sock.timeout (changing effectively the default timeout). Docs and tests cases are also updated (note: now there's no doc in libsocket.tex, as this function is now private). Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunk and 2.5 are borken
Patch 1490190 causes test_posix to fail on Tru64 due to chflags(). I have a potential fix for that in the tracker. Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I vote to reject: Adding timeout to socket.pyand httplib.py.
Josiah Carlson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Alan is off his rocker. To me, this sort of ad hominen comment is anti-productive and out-of-place in technical discussion. Facundo Batista [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] It's better than yours. This is a technical claim that can be debated. Talk is cheap. Though slightly indirect, this strikes me (as well as the target) as an ad hominen slap that detracts from the technical argument in the rest of the post. See comment above. I do my best to restrain and censor such add-on comments and recommend the same to others, for both personal and public benefit. Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patchs and bugs resume
| On 3/20/07, Facundo Batista [EMAIL PROTECTED] wrote: | Brett Cannon wrote: | old and had not been touched in ages. Hopefully you will be able to | easily port this over to the new tracker once it's up (that should | happen 2-4 weeks after 2.5.1 is released). | | You can be sure I'll port it... I am a fan of Edward Tufte and his advocacy of graceful mixtures of text and small graphics. I think this is an example. A possible improvement, if possible, would be to use thin dark bars for actions (comments) and a lighter bars for periods of inactivity. This would differentiate between items that have had no comments between first and last and those with several. tjr ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I vote to reject: Adding timeout to socket.pyand httplib.py.
On 3/21/07, Terry Reedy [EMAIL PROTECTED] wrote: Josiah Carlson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Alan is off his rocker. To me, this sort of ad hominen comment is anti-productive and out-of-place in technical discussion. Facundo Batista [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] It's better than yours. This is a technical claim that can be debated. Talk is cheap. Though slightly indirect, this strikes me (as well as the target) as an ad hominen slap that detracts from the technical argument in the rest of the post. See comment above. I do my best to restrain and censor such add-on comments and recommend the same to others, for both personal and public benefit. Terry Jan Reedy Tempers flare. Alan's first message (in this thread anyway) wasn't a shining sample of diplomacy either, and it appeared to be based in a lack of understanding of the origin of the patch. Let's forget about that and go back to the patch. My only issue at this point is that it tries to distinguish carefully between timeout=None and timeout omitted. As a result the API is somewhat clumsy: a **kwds that is used for only one keyword, and a special object instance used as a default. Is that really worth it? I would personally be totally okay with timeout=None being interpreted as use the default timeout, if one has been set. Since the default timeout is intended for use only as a big hammer to temporarily fix code that doesn't set timeouts but needs it and has no API to pass one (like httplib before the patch), I am personally in favor of going back to defaulting timeout to None and skipping the settimeout() call in _create_connection() if timeout is None. IMO the use case where there is a global timeout set and one library wants to override it with no timeout is pretty theoretical, and can just as well be handled by passing sys.maxint as the timeout. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I vote to reject: Adding timeout to socket.py and httplib.py.
On 3/21/07, Steven Bethard [EMAIL PROTECTED] wrote: On 3/21/07, Facundo Batista [EMAIL PROTECTED] wrote: So, as a resume of the choices we still need to settle: a) Repeat the same functionality in 5 other libraries b) Write the function in socket.py, public c) Write the function in socket.py, non public The fact that it's needed in 5 places in the stdlib suggests that there's plenty of user code that could benefit from it too. Hence, I prefer (b), but if that really freaks people out, I'm okay with (c) too. I'm not okay with (a). I agree with the reasoning leading to choice (b) as optimal. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for NamedTemporaryFile?
Georg Brandl wrote: Aaron Bingham schrieb: Georg Brandl wrote: Greg Ewing schrieb: Scott Dial wrote: A tangential question -- why are TemporaryFile and NamedTemporaryFile named in TitleCase, when they're functions and not classes? Probably because they are factory functions potentially returning a _TemporaryFileWrapper. If they were functions, they'd have to be verbed, e.g. make_temporary_file(). The class/function distinction is not so clear in Python from the user's point of view since there is no different calling syntax. Actually the distinction is very clear: class _PrivateClass(object): ... pass ... def FunctionNamedToLookLikeClass(): ... return _PrivateClass() ... pc = _PrivateClass() isinstance(pc, _PrivateClass) True fntllc = FunctionNamedToLookLikeClass() isinstance(fntllc, FunctionNamedToLookLikeClass) Traceback (most recent call last): File stdin, line 1, in module TypeError: isinstance() arg 2 must be a class, type, or tuple of classes and types That's sure to be an unpleasant surprise for someone. whisperduck typing.../whisper But you have a valid point. Sure, isinstance was only meant as an example. Anything that expects FunctionNamedToLookLikeClass to exhibit class-like behaviors beyond a call returning a new instance will fail. -- Aaron Bingham Senior Software Engineer [EMAIL PROTECTED] Tel. +49 (0)351 4173-146 Fax +49 (0)351 4173-109 Cenix BioScience GmbH Tatzberg 47 01307 Dresden, Germany www.cenix-bioscience.com - Sitz der Gesellschaft (Place of Business): Dresden Geschäftsführer (CEO): Dr. Christophe J. Echeverri Amtsgericht (Local Court): Dresden, HRB 19964 Ust-ID (VAT-No.): DE205824437 - ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Py2.5.1 release schedule
What are the current thoughts on when Py2.5.1 will go out? Do we need a bug-day beforehand? Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I vote to reject: Adding timeout to socket.pyand httplib.py.
Guido van Rossum wrote: (like httplib before the patch), I am personally in favor of going back to defaulting timeout to None and skipping the settimeout() call in _create_connection() if timeout is None. IMO the use case where there is a global timeout set and one library wants to override it with no timeout is pretty theoretical, and can just as well be handled by passing sys.maxint as the timeout. In the new version of the patch (I updated it a few minutes ago), in _create_connection() I handle timeout being mandatory with **kwargs. And in HTTPConnection, I handle the posibility of calling it with timeout=None through a sentinel. It works, but my only issue is that it gets ugly in the help(): sentinel = object() def f(a, b=sentinel): ... pass ... help(f) ... f(a, b=object object at 0xb7d64460) I know I can use a class with __str__ instead of object, but what would one print in that case? In this case, optional does not means a value by default... I don't have very strong feelings about how to use the function. I just need a timeout to HTTPConnection, to finally have it in urllib2.urlopen(). Maybe we can settle all this by just putting timeout=int and blocking=bool in create_connection, HTTPConnection, and urlopen(). This way, the signature would be: _create_connection(address, timeout=None, blocking=None) and the behaviour: if timeout is None: if blocking is None: pass elif blocking: sock.setblocking(True) else: sock.setblocking(False) else: if blocking is None or blocking is False: sock.settimeout(timeout) else: raise TypeError(You can not block a socket and also time it out) This way we get off from the timeout in None means something about blocking trap. What do you think? Thanks everybody for the patience... Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py2.5.1 release schedule
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 21, 2007, at 1:51 PM, Raymond Hettinger wrote: What are the current thoughts on when Py2.5.1 will go out? Do we need a bug-day beforehand? That might not be a bad idea. I've been working on some email package fixes in the background. While not quite ready yet, I'm also becoming less certain that some of them should actually go into 2.5.1, rather than waiting for 2.6. A bug day would be a good way to coordinate with a few other devs and figure stuff like that out. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRgFx7XEjvBPtnXfVAQK11gP/au7vk5qlqzR3fRDtEbuYcsejuoYH8Cec yy4pP5lAOM2JXR432bDx8cRRm73u00ZD16mxm/5QpGtqkSGnXSy9EpfH2VHr1lss NsCAY/drrWk8qoMA03pO1gCVXhRBaIq36W234gB86RC+ZvWuo/pvyPGkixvGrVe3 qgQQsY/jJf0= =gjEk -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I vote to reject: Adding timeout to socket.pyand httplib.py.
On 3/21/07, Facundo Batista [EMAIL PROTECTED] wrote: Guido van Rossum wrote: (like httplib before the patch), I am personally in favor of going back to defaulting timeout to None and skipping the settimeout() call in _create_connection() if timeout is None. IMO the use case where there is a global timeout set and one library wants to override it with no timeout is pretty theoretical, and can just as well be handled by passing sys.maxint as the timeout. In the new version of the patch (I updated it a few minutes ago), in _create_connection() I handle timeout being mandatory with **kwargs. And in HTTPConnection, I handle the posibility of calling it with timeout=None through a sentinel. It works, but my only issue is that it gets ugly in the help(): sentinel = object() def f(a, b=sentinel): ... pass ... help(f) ... f(a, b=object object at 0xb7d64460) I know I can use a class with __str__ instead of object, but what would one print in that case? In this case, optional does not means a value by default... This is why I proposed to *get rid of* the distinction between timeout=None and timeout not specified. Let an unspecified timeout default to None, and if timeout is None, skip the settimeout() call. I don't have very strong feelings about how to use the function. I just need a timeout to HTTPConnection, to finally have it in urllib2.urlopen(). Yes, I remember well how it all started with a two-line patch to httplib.py :-) Maybe we can settle all this by just putting timeout=int and blocking=bool in create_connection, HTTPConnection, and urlopen(). This way, the signature would be: _create_connection(address, timeout=None, blocking=None) and the behaviour: if timeout is None: if blocking is None: pass elif blocking: sock.setblocking(True) else: sock.setblocking(False) else: if blocking is None or blocking is False: sock.settimeout(timeout) else: raise TypeError(You can not block a socket and also time it out) This way we get off from the timeout in None means something about blocking trap. What do you think? Overkill. The socket method settimeout() handles all with a single parameter. Thanks everybody for the patience... Especially you, for volunteering to do this and then getting more feedback than you bargained for!! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I vote to reject: Adding timeout tosocket.pyand httplib.py.
Facundo Batista wrote: It works, but my only issue is that it gets ugly in the help(): sentinel = object() def f(a, b=sentinel): ... pass ... help(f) ... f(a, b=object object at 0xb7d64460) I know I can use a class with __str__ instead of object, but what would one print in that case? I've found missing to be the most common (and the most understandable) thing to print in that case. Robert Brewer System Architect Amor Ministries [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py2.5.1 release schedule
On Wed, Mar 21, 2007 at 01:51:37PM -0400, Raymond Hettinger wrote: What are the current thoughts on when Py2.5.1 will go out? Do we need a bug-day beforehand? A bug day would be a great idea! I have a mailbox bug that'd greatly benefit from discussion about how to fix the problem. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I vote to reject: Adding timeout to socket.pyand httplib.py.
Guido van Rossum wrote: This is why I proposed to *get rid of* the distinction between timeout=None and timeout not specified. Let an unspecified timeout default to None, and if timeout is None, skip the settimeout() call. +1 I'll abuse of your dictatorship, and let's see if we can finally specify what I'd do: - Just put a timeout default to None. If None, skip settimeout() call. - Copy the exceptions behaviour that we have actually in the higher level libraries: maybe it's not the best, but we're sure we aren't breaking anything. - As you said in other thread when voting (a,b,c), let's make the function public (but with the more specific name: create_connection). If it's ok, I'll prepare one more update to the patch. Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Fwd: Re: Py2.5.1 release schedule
[Raymond] What are the current thoughts on when Py2.5.1 will go out? Do we need a bug-day beforehand? [AMK] A bug day would be a great idea! I have a mailbox bug that'd greatly benefit from discussion about how to fix the problem. How about Sunday, April 1st? Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Re: Py2.5.1 release schedule
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 21, 2007, at 3:28 PM, Raymond Hettinger wrote: [Raymond] What are the current thoughts on when Py2.5.1 will go out? Do we need a bug-day beforehand? [AMK] A bug day would be a great idea! I have a mailbox bug that'd greatly benefit from discussion about how to fix the problem. How about Sunday, April 1st? I could probably show up for a few hours that day. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRgGQrnEjvBPtnXfVAQJdwgQAkyf/SAG9Du+BzBzYJQ+0F+kfCglc6BSB U6uBretnedHIYmekTKg3e6Myr23B1DVLyJFuvpS8vN15RAePnZ4RLIRIPBtdkCDE Q0mJTZk5mY9xICeA23yMHVCZgUaflKOavn94SHrUYqsxR5FX/w30HxPWeBKqRro8 YGtiQK4BVLA= =N3Pd -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Extended Buffer Interface/Protocol
I'm soliciting feedback on my extended buffer protocol that I am proposing for inclusion in Python 3000. As soon as the Python 3.0 implementation is complete, I plan to back-port the result to Python 2.6, therefore, I think there may be some interest on this list. Basically, the extended buffer protocol seeks to allow memory sharing with 1) information about what is in the memory (float, int, C-structure, etc.) 2) information about the shape of the memory (if any) 3) information about discontiguous memory segments Number 3 is where I could use feedback --- especially from PIL users and developers. Strides are a common way to think about a possibly discontiguous chunk of memory (which appear in NumPy when you select a sub-region from a larger array). The strides vector tells you how many bytes to skip in each dimension to get to the next memory location for that dimension. Because NumPy uses this memory model as do several compute libraries (like BLAS and LAPACK), it makes sense to allow this memory model to be shared between objects in Python. Currently, the proposed buffer interface eliminates the multi-segment option (for Python 3.0) which I think was originally put in place because of the PIL. However, I don't know if it is actually used by any extension types. This is a big reason why Guido wants to drop the multi-segment interface option. The question is should we eliminate the possibility of sharing memory for objects that store data basically as arrays of arrays (i.e. true C-style arrays). That is what I'm currently proposing, but I could also see an argument that states that if we are going to support strided memory access, we should also support array of array memory access. If this is added, then it would be another function-call that gets a array-of-array-style memory from the object. What do others think of these ideas? One possible C-API call that Python could grow with the current buffer interface is to allow contiguous-memory mirroring of discontiguous memory, or an iterator object that iterates through every element of any object that exposes the buffer protocol. Thanks for any feedback, -Travis Oliphant ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Contents of test_bool
Is there any reason for test_bool to contain assertions like these?
self.assertIs({}.has_key(1), False)
self.assertIs({1:1}.has_key(1), True)
A significant portion of the file is devoted to making sure various
things return bools (isinstance, operator.*) or handle bools correctly
(pickle, marshal). Since these don't test the functionality of the
bool type, is there a reason not to move these tests to more
appropriate test files (eg, test_pickle) or removing them altogether
(if they duplicate existing tests)?
I've started on this somewhat, but I thought I'd ask before I spent
too much time on it.
Collin Winter
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Re: Py2.5.1 release schedule
How about Sunday, April 1st? Barry I could probably show up for a few hours that day. I can likely spend a couple hours as well. Afternoon (Central Time) would be better. Depends on Ellen's work schedule. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Re: Py2.5.1 release schedule
[EMAIL PROTECTED] wrote: How about Sunday, April 1st? Barry I could probably show up for a few hours that day. I can likely spend a couple hours as well. Afternoon (Central Time) would be better. Depends on Ellen's work schedule. I'd like to put something back into Python and can be around on that day. Michael Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Contents of test_bool
I think it was just expedient to group these together when the bool
type was added. I wouldn't lose sleep over it either way.
On 3/21/07, Collin Winter [EMAIL PROTECTED] wrote:
Is there any reason for test_bool to contain assertions like these?
self.assertIs({}.has_key(1), False)
self.assertIs({1:1}.has_key(1), True)
A significant portion of the file is devoted to making sure various
things return bools (isinstance, operator.*) or handle bools correctly
(pickle, marshal). Since these don't test the functionality of the
bool type, is there a reason not to move these tests to more
appropriate test files (eg, test_pickle) or removing them altogether
(if they duplicate existing tests)?
I've started on this somewhat, but I thought I'd ask before I spent
too much time on it.
Collin Winter
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Re: Py2.5.1 release schedule
On 3/21/07, Raymond Hettinger [EMAIL PROTECTED] wrote: [Raymond] What are the current thoughts on when Py2.5.1 will go out? Do we need a bug-day beforehand? [AMK] A bug day would be a great idea! I have a mailbox bug that'd greatly benefit from discussion about how to fix the problem. How about Sunday, April 1st? Is that a joke? ;-) The schedule hasn't changed from my March 7th msg: 2.5.1c1 - Tuesday, April 3 2.5.1 -Thursday April 12 (assuming a c2 is not necessary) My only concern is that 2.5.1 needs to get more stable not less. As long as people are very careful with what's put into 2.5.1 and the buildbots are respected, I think this would be great. I have not received any bug reports through SF or private mail that should block the release. Anthony didn't know of any either. I still have a backlog of mail to go through, but we are in pretty good shape right now. If someone knows of any issues, please let me know. n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding timeout to socket.py and httplib.py - Updated
Facundo Batista schrieb: I updated the patch #1676823, reflecting discussion here: - The function name changed, now it's _create_connection(). Its signature also changed: now, timeout is mandatorily named. - HTTPConnection has the posibility to call timeout with a number, and also with None. In both cases, it updates sock.timeout (changing effectively the default timeout). Docs and tests cases are also updated (note: now there's no doc in libsocket.tex, as this function is now private). Sorry that I didn't manage to review your earlier patch. As it seems, this also had some benefits (the discussion that started on your inquiry). There are others who can judge the new API and implementation better than me, but I can review the formal issues as soon as the API is accepted. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Contents of test_bool
On Wed, Mar 21, 2007 at 03:37:02PM -0500, Collin Winter wrote:
Is there any reason for test_bool to contain assertions like these?
self.assertIs({}.has_key(1), False)
self.assertIs({1:1}.has_key(1), True)
A significant portion of the file is devoted to making sure various
things return bools (isinstance, operator.*) or handle bools correctly
(pickle, marshal). Since these don't test the functionality of the
bool type, is there a reason not to move these tests to more
appropriate test files (eg, test_pickle) or removing them altogether
(if they duplicate existing tests)?
I've started on this somewhat, but I thought I'd ask before I spent
too much time on it.
Most of them could be moved to their specific type's test module.
There are a few (at least on the py3k branch) tests that check if
__bool__ functions really return bools and that the proper exceptions
are raised. Those should stay in test_bool.py
-Jack
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Re: Py2.5.1 release schedule
Raymond Hettinger schrieb: [Raymond] What are the current thoughts on when Py2.5.1 will go out? Do we need a bug-day beforehand? [AMK] A bug day would be a great idea! I have a mailbox bug that'd greatly benefit from discussion about how to fix the problem. How about Sunday, April 1st? Works for me. waiting-for-someone-else-to-deliver-the-joke-on-the-date-ly yours, Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Extended Buffer Interface/Protocol
Attached is the PEP.
:PEP: XXX
:Title: Revising the buffer protocol
:Version: $Revision: $
:Last-Modified: $Date: $
:Author: Travis Oliphant [EMAIL PROTECTED]
:Status: Draft
:Type: Standards Track
:Content-Type: text/x-rst
:Created: 28-Aug-2006
:Python-Version: 3000
Abstract
This PEP proposes re-designing the buffer API (PyBufferProcs
function pointers) to improve the way Python allows memory sharing
in Python 3.0
In particular, it is proposed that the multiple-segment and
character buffer portions of the buffer API be eliminated and
additional function pointers be provided to allow sharing any
multi-dimensional nature of the memory and what data-format the
memory contains.
Rationale
=
The buffer protocol allows different Python types to exchange a
pointer to a sequence of internal buffers. This functionality is
*extremely* useful for sharing large segments of memory between
different high-level objects, but it is too limited and has issues.
1. There is the little (never?) used sequence-of-segments option
(bf_getsegcount)
2. There is the apparently redundant character-buffer option
(bf_getcharbuffer)
3. There is no way for a consumer to tell the buffer-API-exporting
object it is finished with its view of the memory and
therefore no way for the exporting object to be sure that it is
safe to reallocate the pointer to the memory that it owns (for
example, the array object reallocating its memory after sharing
it with the buffer object which held the original pointer led
to the infamous buffer-object problem).
4. Memory is just a pointer with a length. There is no way to
describe what is in the memory (float, int, C-structure, etc.)
5. There is no shape information provided for the memory. But,
several array-like Python types could make use of a standard
way to describe the shape-interpretation of the memory
(wxPython, GTK, pyQT, CVXOPT, PyVox, Audio and Video
Libraries, ctypes, NumPy, data-base interfaces, etc.)
6. There is no way to share discontiguous memory (except through
the sequence of segments notion).
There are two widely used libraries that use the concept of
discontiguous memory: PIL and NumPy. Their view of discontiguous
arrays is different, though. This buffer interface allows
sharing of either memory model. Exporters will only use one
approach and consumers may choose to support discontiguous
arrays of each type however they choose.
NumPy uses the notion of constant striding in each dimension as its
basic concept of an array. With this concept, a simple sub-region
of a larger array can be described without copying the data. T
Thus, stride information is the additional information that must be
shared.
The PIL uses a more opaque memory representation. Sometimes an
image is contained in a contiguous segment of memory, but sometimes
it is contained in an array of pointers to the contiguous segments
(usually lines) of the image. The PIL is where the idea of multiple
buffer segments in the original buffer interface came from.
NumPy's strided memory model is used more often in computational
libraries and because it is so simple it makes sense to support
memory sharing using this model. The PIL memory model is used often
in C-code where a 2-d array can be then accessed using double
pointer indirection: e.g. image[i][j].
The buffer interface should allow the object to export either of these
memory models. Consumers are free to either require contiguous memory
or write code to handle either memory model.
Proposal Overview
=
* Eliminate the char-buffer and multiple-segment sections of the
buffer-protocol.
* Unify the read/write versions of getting the buffer.
* Add a new function to the interface that should be called when
the consumer object is done with the view.
* Add a new variable to allow the interface to describe what is in
memory (unifying what is currently done now in struct and
array)
* Add a new variable to allow the protocol to share shape information
* Add a new variable for sharing stride information
* Add a new mechanism for sharing array of arrays.
* Fix all objects in the core and the standard library to conform
to the new interface
* Extend the struct module to handle more format specifiers
Specification
=
Change the PyBufferProcs structure to
::
typedef struct {
getbufferproc bf_getbuffer
releasebufferproc bf_releasebuffer
}
::
typedef PyObject *(*getbufferproc)(PyObject *obj, void **buf,
Py_ssize_t *len, int *writeable,
char **format, int *ndims,
Py_ssize_t **shape,
Py_ssize_t **strides,
void **segments)
All variables except the
Re: [Python-Dev] Rationale for NamedTemporaryFile?
Georg Brandl wrote: The class/function distinction is not so clear in Python from the user's point of view since there is no different calling syntax. There *is* a visible distinction, though -- you can subclass classes but not functions. If these are uppercased because they wrap classes, why not just expose the class directly? Or if that's an implementation detail, it shouldn't affect the casing of the name. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I vote to reject: Adding timeout to socket.py and httplib.py.
Facundo Batista wrote: So, as a resume of the choices we still need to settle: a) Repeat the same functionality in 5 other libraries b) Write the function in socket.py, public c) Write the function in socket.py, non public or d) Put it in another module Is it time for a sockettools module, maybe? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I vote to reject: Adding timeout to socket.py and httplib.py.
[EMAIL PROTECTED] wrote: Facundo c) Write the function in socket.py, non public Also this option has the problem that it would be a strange usage of non-public, since the function would be designed for use by other modules and not used at all in the module it's supposedly private to. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Extended Buffer Interface/Protocol
Travis Oliphant: 3) information about discontiguous memory segments Number 3 is where I could use feedback --- especially from PIL users and developers. Strides are a common way to think about a possibly discontiguous chunk of memory (which appear in NumPy when you select a sub-region from a larger array). The strides vector tells you how many bytes to skip in each dimension to get to the next memory location for that dimension. I think one of the motivations for discontiguous segments was for split buffers which are commonly used in text editors. A split buffer has a gap in the middle where insertions and deletions can often occur without moving much memory. When an insertion or deletion is required elsewhere then the gap is first moved to that position. I have long intended to implement a good split buffer extension for Python but the best I have currently is an extension written using Boost.Python which doesn't implement the buffer interface. Here is a description of split buffers: http://www.cs.cmu.edu/~wjh/papers/byte.html Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Extended Buffer Interface/Protocol
On 3/21/07, Neil Hodgson [EMAIL PROTECTED] wrote: Travis Oliphant: 3) information about discontiguous memory segments Number 3 is where I could use feedback --- especially from PIL users and developers. Strides are a common way to think about a possibly discontiguous chunk of memory (which appear in NumPy when you select a sub-region from a larger array). The strides vector tells you how many bytes to skip in each dimension to get to the next memory location for that dimension. I think one of the motivations for discontiguous segments was for split buffers which are commonly used in text editors. A split buffer has a gap in the middle where insertions and deletions can often occur without moving much memory. When an insertion or deletion is required elsewhere then the gap is first moved to that position. I have long intended to implement a good split buffer extension for Python but the best I have currently is an extension written using Boost.Python which doesn't implement the buffer interface. Here is a description of split buffers: http://www.cs.cmu.edu/~wjh/papers/byte.html But there's always a call to remove the gap (or move it to the end). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Extended Buffer Interface/Protocol
Neil Hodgson wrote: I think one of the motivations for discontiguous segments was for split buffers which are commonly used in text editors. Note that this is different from the case of an array of pointers to arrays, which is a multi-dimensional array structure, whereas a split buffer is a concatenation of two (possibly different sized) one-dimensional arrays. So an array-of-pointers interface wouldn't be a direct substitute for the existing multi-segment buffer interface. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Breaking calls to object.__init__/__new__
See python.org/sf/1683368. I'd like to invite opinions on whether it's worth breaking an unknown amount of user code in 2.6 for the sake of stricter argument checking for object.__init__ and object.__new__. I think it probably isn't; but the strict version could be added to 3.0 and a warning issued in 2.6 in -Wpy3k mode. Alternatively, we could introduce the stricter code in 2.6, fix the stdlib modules that it breaks, and hope for the best. Opinions? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I vote to reject: Adding timeout to socket.py and httplib.py.
On 3/21/07, Alan Kennedy [EMAIL PROTECTED] wrote: [Greg Ewing] or d) Put it in another module Is it time for a sockettools module, maybe? +1! -1. The new module would be just as much a jumble of unrelated APIs as the socket module already is, so there's no particularly good reason to create an arbitrary separation. Also, KISS. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I vote to reject: Adding timeout to socket.py and httplib.py.
[Greg Ewing] or d) Put it in another module Is it time for a sockettools module, maybe? +1! Alan. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of thread cancellation
Nick Maclaren [EMAIL PROTECTED] wrote: Well, I have seen it hundreds of times on a dozen different Unices; it is very common. You don't always SEE the stuck process - sometimes the 'kill -9' causes the pid to become invisible to ps etc., and just occasionally it can continue to use CPU until the system is rebooted. You're describing something caused by a buggy operating system. I have never seen any modern Unix exhibit any of the behaviours you describe. I have seen such things in the 1990's though. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I vote to reject: Adding timeout to socket.py and httplib.py.
[Facundo] Talk is cheap. I'm sorry if you see my attempts to review your patch as cheap talk. Maybe I should have just kept my opinion to myself. You'll get your chance to return the favour when I check in my upcoming 1000+ line change to jython 2.3 to bring the jython socket, select and asyncore modules up-to-date with cpython 2.5, including providing ssl support, non-blocking IO, select/poll, etc, for the first time in jython. Alan. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug in inspect module
On Sat, Mar 17, 2007 at 08:09:06PM -0500, Collin Winter wrote: On 3/17/07, Ewan Mellor [EMAIL PROTECTED] wrote: I have a problem being reported (by Xen users) where inspect.stack() is throwing IndexError. I think that this is a bug in inspect.py -- findsource generally throws IOError when it can't find a particular source file, but in the case where it finds a source file, but that file is shorter than expected, then findsource throws IndexError, and this is propagated all the way out of inspect.stack(). I'm not sure why inspect.py is finding source files that don't match the code being executed -- it seems to be dependent upon the install environment, because it's not affecting most people. That said, I think that it's reasonable to cope with a too-short source file in the same way as we cope with missing source files -- by throwing IOError from findsource and handling that exception later. FYI: this has been reported at least once before: see bug #1628987 (http://python.org/sf/1628987). The problem (in the bug report, at least) is that the source file changes between compilation and when findsource() is called, and findsource() picks up the modified version. Thanks for that. It's certainly a mismatch between the compiled code and the source file subsequently found. That said, I don't think that it only affects the case when people are editing source files and not recompiling -- this isn't the sort of thing that my users would be doing at this point. I suspect that the source file lookup is broken in some way, and so the wrong file ends up in the line cache. It's not affecting me, unfortunately, so I can't easily investigate. I see that you closed this bug as Won't Fix. My two line patch seems like a reasonable workaround, and certainly more simple than the other proposals -- do you think it's worth dropping in? Cheers, Ewan. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking calls to object.__init__/__new__
On Wed, 21 Mar 2007 15:45:16 -0700, Guido van Rossum [EMAIL PROTECTED] wrote: See python.org/sf/1683368. I'd like to invite opinions on whether it's worth breaking an unknown amount of user code in 2.6 for the sake of stricter argument checking for object.__init__ and object.__new__. I think it probably isn't; but the strict version could be added to 3.0 and a warning issued in 2.6 in -Wpy3k mode. Alternatively, we could introduce the stricter code in 2.6, fix the stdlib modules that it breaks, and hope for the best. Opinions? Perhaps I misunderstand the patch, but it would appear to break not just some inadvisable uses of super(), but an actual core feature of super(). Maybe someone can set me right. Is this correct? class Base(object): def __init__(self, important): # Don't upcall with `important` because object is the base # class and its __init__ doesn't care (or won't accept) it super(Base, self).__init__() self.a = important If so, what are the implications for this? class Other(object): def __init__(self, important): # Don't upcall with `important` because object is the base # class and its __init__ doesn't care (or won't accept) it super(Other, self).__init__() self.b = important class Derived(Base, Other): pass (A similar example could be given where Base and Other take differently named arguments with nothing to do with each other. The end result is the same either way, I think.) I think I understand the desire to pull keyword arguments out at each step of the upcalling process, but I don't see how it can work, since up calling isn't always what's going on - given a diamond, there's arbitrary side-calling, so for cooperation to work every method has to pass on every argument, so object.__init__ has to take arbitrary args, since no one knows when their up call will actually hit object. Since without diamonds, naive by-name upcalling works, I assume that super() is actually intended to be used with diamonds, so this seems relevant. I hope I've just overlooked something. Writing this email feels very strange. Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Tracker Issues
ACTIVITY SUMMARY (03/11/07 - 03/18/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1645 open ( +1) / 8581 closed ( +0) / 10226 total ( +1) Average duration of open issues: 738 days. Median duration of open issues: 686 days. Open Issues Breakdown open 1645 ( +1) pending 0 ( +0) Issues Created Or Reopened (1) __ New issue test for email 03/14/07 http://bugs.python.org/issue1001created dubois Top Issues Most Discussed (1) _ 4 Test issue 8 days openhttp://bugs.python.org/issue1000 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] regexp in Python
For some time I'm interested in regular expressions and Finite State Machine. Recently, I saw that Python uses Secret Labs' Regular Expression Engine, which very often works too slow. Its pesymistic time complexity is O(2^n), although other solutions, with time complexity O(n*m) ( O(n*m^2), m is the length of the regular expression and n is the length of the text, introduction to problem: http://swtch.com/~rsc/regexp/regexp1.html ) For example: $ cat test.py import re import sys if sys.argv[1:]: n = int(sys.argv[1]) regexp = 'a?'*n + 'a'*n print 'regexp=', regexp str = 'a'*n + 'b' + 'a'*n print 'str=', str print re.findall(regexp, str) $ time python test.py 20 regexp= a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a? str= b ['', ''] real0m0.592s user0m0.508s sys 0m0.028s $ time python test.py 21 regexp= a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a str= aba ['a', 'a'] real0m1.018s user0m1.000s sys 0m0.004s $ time python test.py 22 regexp= a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?aa str= aabaa ['aa', 'aa'] real0m2.062s user0m1.992s sys 0m0.028s $ time python test.py 23 regexp= a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?aaa str= aaabaaa ['aaa', 'aaa'] real0m4.159s user0m4.092s sys 0m0.024s Unfortuntely not for all regular expressions quick implementation may be used (e.g. when it uses backreferences), but for major part of regular expressions this implementation works much faster. In addition to Google Summer of Code I would willingly write a faster implementation of regular expressions in Python. Naturally, the implementation would be 100% compatible with the existing regexp engine. What do you think about my proposition? -- Bartlomiej Wolowiec ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Calling base class methods from C
The xxsubtype.c module gives an example of calling a parent method if it is in
a slot:
static int
spamlist_init(spamlistobject *self, PyObject *args, PyObject *kwds)
{
if (PyList_Type.tp_init((PyObject *)self, args, kwds) 0)
return -1;
self-state = 0;
return 0;
}
How you call non-slotted named methods in parent classes?
class List(list):
def append(self, x):
print x
List.append(self, x) # What is the C equivalent of this call?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Extended Buffer Interface/Protocol
Travis Oliphant wrote: The question is should we eliminate the possibility of sharing memory for objects that store data basically as arrays of arrays (i.e. true C-style arrays). Can you clarify what you mean by this? Are you talking about an array of pointers to other arrays? (This is not what I would call an array of arrays, even in C.) Supporting this kind of thing could be a slippery slope, since there can be arbitrary levels of complexity to such a structure. E.g do you support a 1d array of pointers to 3d arrays of pointers to 2d arrays? Etc. The more different kinds of format you support, the less likely it becomes that the thing consuming the data will be willing to go to the trouble required to understand it. One possible C-API call that Python could grow with the current buffer interface is to allow contiguous-memory mirroring of discontiguous memory, I don't think the buffer protocol itself should incorporate anything that requires implicitly copying the data, since the whole purpose of it is to provide direct access to the data without need for copying. It would be okay to supply some utility functions for re-packing data, though. or an iterator object that iterates through every element of any object that exposes the buffer protocol. Again, for efficiency reasons I wouldn't like to involve Python objects and iteration mechanisms in this. The buffer interface is meant to give you raw access to the data at raw C speeds. Anything else is outside its scope, IMO. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Extended Buffer Interface/Protocol
Greg Ewing: So an array-of-pointers interface wouldn't be a direct substitute for the existing multi-segment buffer interface. Providing an array of (pointer,length) wouldn't be too much extra work for a split vector implementation. Guido van Rossum: But there's always a call to remove the gap (or move it to the end). Yes, although its something you try to avoid. I'm not saying that this is an important use-case since no one seems to have produced a split vector implementation that provides the buffer protocol. Numeric-style array handling is much more common so deserves priority. Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for NamedTemporaryFile?
Greg Ewing wrote: A tangential question -- why are TemporaryFile and NamedTemporaryFile named in TitleCase, when they're functions and not classes? I wondered the same. At first draft of my email I wrote class operating under the assumption that only classes got to be camel-cased. If I had to guess, the rationale was that they are simply wrappers a class. Nevertheless, tempfile dates well back before the PEP 8 style guidelines. I think consistency would dictate that a newly added function should match the other ones, but I have no strong feelings about this. -Scott -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Extended Buffer Interface/Protocol
Greg Ewing wrote: Travis Oliphant wrote: The question is should we eliminate the possibility of sharing memory for objects that store data basically as arrays of arrays (i.e. true C-style arrays). Can you clarify what you mean by this? Are you talking about an array of pointers to other arrays? (This is not what I would call an array of arrays, even in C.) I'm talking about arrays of pointers to other arrays: i.e. if somebody defined in C float B[10][20] then B would B an array of pointers to arrays of floats. Supporting this kind of thing could be a slippery slope, since there can be arbitrary levels of complexity to such a structure. E.g do you support a 1d array of pointers to 3d arrays of pointers to 2d arrays? Etc. Yes, I saw that. But, it could actually be supported, in general. The shape information is available. If a 3-d array is meant then ndims is 3 and you would re-cast the returned pointer appropriately. In other words, suppose that instead of strides you can request a variable through the buffer interface with type void **segments. Then, by passing the address to a void * variable to the routine you would receive the array. Then, you could handle 1-d, 2-d, and 3-d cases using something like this: This is pseudocode: void *segments; int ndims; Py_ssize_t *shape; char *format; (ndims, shape, format, and segments) are passed to the buffer interface. if strcmp(format, f) != 0 raise an error. if (ndims == 1) var = (float *)segments for (i=0; ishape[0]; i++) # process var[i] else if (ndims == 2) var = (float **)segments for (i=0; ishape[0]; i++) for (j=0; jshape[1]; j++) # process var[i][j] else if (ndims == 3) var = (float ***)segments for (i=0; ishape[0]; i++) for (j=0; jshape[1]; j++) for (k=0; jshape[2]; k++) # process var[i][j][k] else raise an Error. The more different kinds of format you support, the less likely it becomes that the thing consuming the data will be willing to go to the trouble required to understand it. That is certainly true. I'm really only going through the trouble, since the multiple segment already exists and the PIL has this memory model (although I have not heard PIL developers clamoring for support, --- I'm just being sensitive to that extension type). One possible C-API call that Python could grow with the current buffer interface is to allow contiguous-memory mirroring of discontiguous memory, I don't think the buffer protocol itself should incorporate anything that requires implicitly copying the data, since the whole purpose of it is to provide direct access to the data without need for copying. No, this would not be the buffer protocol, but merely a C-API that would use the buffer protocol - i.e. it is just a utility function as you mention. It would be okay to supply some utility functions for re-packing data, though. or an iterator object that iterates through every element of any object that exposes the buffer protocol. Again, for efficiency reasons I wouldn't like to involve Python objects and iteration mechanisms in this. I was thinking more of a C-iterator, like NumPy provides. This can be very efficient (as long as the loop is not in Python). It sure provides a nice abstraction that lets you deal with discontiguous arrays as if they were contiguous, though. The buffer interface is meant to give you raw access to the data at raw C speeds. Anything else is outside its scope, Sure. These things are just ideas about *future* utility functions that might make use of the buffer interface and motivate its design. Thanks for your comments. -Travis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking calls to object.__init__/__new__
Jean-Paul Calderone wrote: Perhaps I misunderstand the patch, but it would appear to break not just some inadvisable uses of super(), but an actual core feature of super(). Maybe someone can set me right. Is this correct? class Base(object): def __init__(self, important): If so, what are the implications for this? class Other(object): def __init__(self, important): I think the idea was that each __init__ method *extracts* the arguments that apply to it and doesn't pass them on. Then, by the time object.__init__ is reached, there should be none left. This only works if the sets of keywords recognised by each __init__ method are all disjoint. Another approach is for none of them to extract anything, and always pass everything on. Then you need something at the top that accepts anything, and you get no error checking. This kind of thing seems to be a general feature of super, i.e. in order for it to work properly, all the classes using it have to agree on some set of rules or other. This creates isolated ghettos of classes that can't be mixed with each other. If you try to mix in a class which doesn't know about the rules, or follows a different set of rules, everything falls apart. Every time I've considered using super, I've eventually decided against it for reasons like this. I've always found a better way that doesn't introduce so may strange interactions between the classes involved. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking calls to object.__init__/__new__
On 3/21/07, Jean-Paul Calderone [EMAIL PROTECTED] wrote: On Wed, 21 Mar 2007 15:45:16 -0700, Guido van Rossum [EMAIL PROTECTED] wrote: See python.org/sf/1683368. I'd like to invite opinions on whether it's worth breaking an unknown amount of user code in 2.6 for the sake of stricter argument checking for object.__init__ and object.__new__. I think it probably isn't; but the strict version could be added to 3.0 and a warning issued in 2.6 in -Wpy3k mode. Alternatively, we could introduce the stricter code in 2.6, fix the stdlib modules that it breaks, and hope for the best. Opinions? Perhaps I misunderstand the patch, but it would appear to break not just some inadvisable uses of super(), but an actual core feature of super(). Maybe someone can set me right. Is this correct? class Base(object): def __init__(self, important): # Don't upcall with `important` because object is the base # class and its __init__ doesn't care (or won't accept) it super(Base, self).__init__() self.a = important If so, what are the implications for this? class Other(object): def __init__(self, important): # Don't upcall with `important` because object is the base # class and its __init__ doesn't care (or won't accept) it super(Other, self).__init__() self.b = important class Derived(Base, Other): pass (A similar example could be given where Base and Other take differently named arguments with nothing to do with each other. The end result is the same either way, I think.) I think I understand the desire to pull keyword arguments out at each step of the upcalling process, but I don't see how it can work, since up calling isn't always what's going on - given a diamond, there's arbitrary side-calling, so for cooperation to work every method has to pass on every argument, so object.__init__ has to take arbitrary args, since no one knows when their up call will actually hit object. Since without diamonds, naive by-name upcalling works, I assume that super() is actually intended to be used with diamonds, so this seems relevant. I hope I've just overlooked something. Writing this email feels very strange. Jean-Paul There are different philosophies about the correct style for cooperative super calls. The submitter of the bug report likes to remove consumed arguments and pass the others on, having something at the root that complains about any unused arguments. It has the problem that you mention: if multiple classes might be interested in the *same* argument they won't see it. The other style is to pass *all* arguments down, and let everyone cherry-pick them. The last call then just throws them away. This has the problem that misspelled arguments are silently ignored rather than being diagnosed at the point where you can do something about it. I don't know what the best practice is (like Greg Ewing, I don't use either style myself) but I've got a feeling that it must be easier to solve the former problem than the latter (also I don't know that the former actually occurs in practice). When using more traditional styles, or single inheritance, it certainly makes more sense to reject excess arguments than to ignore them; the original code was clearly intending to do this, but due to the minimalist coding, it didn't catch enough. I've pretty much made up my mind at this point that the right way forward is to be strict; in 3.0 we can afford to be strict as in the strict version of the patch, while in 2.6 we'll be less strict, but still stricter than 2.5; 2.6 in -Wpy3k mode will issue warnings for those cases where 3.0 will issue an error but 2.6 doesn't. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I vote to reject: Adding timeout to socket.py and httplib.py.
Guido van Rossum wrote: Is it time for a sockettools module, maybe? +1! -1. The new module would be just as much a jumble of unrelated APIs as the socket module already is, so there's no particularly good reason to create an arbitrary separation. Also, KISS. I agree with Guido on this one. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Calling base class methods from C
Raymond Hettinger wrote: class List(list): def append(self, x): print x List.append(self, x) # What is the C equivalent of this call? Something like PyObject *meth, *result; meth = PyObject_GetAttrString(PyList_Type, append) result = PyObject_CallFunctionObjArgs(meth, self, x, NULL) plus appropriate error checking. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking calls to object.__init__/__new__
Guido van Rossum wrote: See python.org/sf/1683368. I'd like to invite opinions on whether it's worth breaking an unknown amount of user code in 2.6 for the sake of stricter argument checking for object.__init__ Personally I have never written code that relies on being able to pass arbitrary args to object.__init__ and don't ever intend to, so this wouldn't bother me. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] regexp in Python
Bart³omiej Wo³owiec [EMAIL PROTECTED] wrote: For some time I'm interested in regular expressions and Finite State Machine. Recently, I saw that Python uses Secret Labs' Regular Expression Engine, which very often works too slow. Its pesymistic time complexity is O(2^n), although other solutions, with time complexity O(n*m) ( O(n*m^2), m is the length of the regular expression and n is the length of the text, introduction to problem: http://swtch.com/~rsc/regexp/regexp1.html ) [snip] In addition to Google Summer of Code I would willingly write a faster implementation of regular expressions in Python. Naturally, the implementation would be 100% compatible with the existing regexp engine. What do you think about my proposition? Submit it as a Google Summer of Code project. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking calls to object.__init__/__new__
On Wed, Mar 21, 2007, Guido van Rossum wrote: On 3/21/07, Jean-Paul Calderone [EMAIL PROTECTED] wrote: I think I understand the desire to pull keyword arguments out at each step of the upcalling process, but I don't see how it can work, since up calling isn't always what's going on - given a diamond, there's arbitrary side-calling, so for cooperation to work every method has to pass on every argument, so object.__init__ has to take arbitrary args, since no one knows when their up call will actually hit object. Since without diamonds, naive by-name upcalling works, I assume that super() is actually intended to be used with diamonds, so this seems relevant. There are different philosophies about the correct style for cooperative super calls. Maybe so, but this would massively break my company's application, if we were actually using new-style classes and the built-in super(). We have a web application that commonly passes all form fields down as **kwargs; the application uses lots of mixin classes with identically-named methods. We have a home-brew super() that crawls the stack. Call me a strong -1 on this now that JP has explained what it does. I can't believe we're the only people doing this. I guess it doesn't matter as much for 3.0 because we're probably going to have to do a massive rewrite for that, anyway. (This codebase started in 1.4 and we're still running against 2.2.) But my take is that this is still an ugly fix. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Typing is cheap. Thinking is expensive. --Roy Smith ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking calls to object.__init__/__new__
Guido van Rossum [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | There are different philosophies about the correct style for | cooperative super calls. | | The submitter of the bug report likes to remove consumed arguments | and pass the others on, having something at the root that complains | about any unused arguments. It has the problem that you mention: if | multiple classes might be interested in the *same* argument they won't | see it. The other style is to pass *all* arguments down, and let | everyone cherry-pick them. The last call then just throws them away. | This has the problem that misspelled arguments are silently ignored | rather than being diagnosed at the point where you can do something | about it. | | I don't know what the best practice is (like Greg Ewing, I don't use | either style myself) but I've got a feeling that it must be easier to | solve the former problem than the latter (also I don't know that the | former actually occurs in practice). When using more traditional | styles, or single inheritance, it certainly makes more sense to reject | excess arguments than to ignore them; the original code was clearly | intending to do this, but due to the minimalist coding, it didn't | catch enough. It seems to me that to get the exact behavior one wants at the apex of a diamond structure, one should subclass object and override .__init__ with a function that does not call object.__init__ and use that subclass as the apex instead of object itself. Wouldn't this mask the behavior of object.__init__ and whatever changes decided on? (But having said that, I have no opiniou on what the default should be for those who don't do this.) Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking calls to object.__init__/__new__
On 3/21/07, Guido van Rossum [EMAIL PROTECTED] wrote: On 3/21/07, Adam Olsen [EMAIL PROTECTED] wrote: super() has always felt strange to me. When used in __init__? Or in general? If the former, that's because it's a unique Python wart to even be able to use super for __init__. In general. Too many things could fail without errors, so it wasn't obvious how to use it correctly. None of the articles I've read helped either. Now, with PEP 3102 and the strict __init__, not so much. Works for me. :-) -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking calls to object.__init__/__new__
On 3/21/07, Adam Olsen [EMAIL PROTECTED] wrote: On 3/21/07, Jean-Paul Calderone [EMAIL PROTECTED] wrote: On Wed, 21 Mar 2007 15:45:16 -0700, Guido van Rossum [EMAIL PROTECTED] wrote: See python.org/sf/1683368. I'd like to invite opinions on whether it's worth breaking an unknown amount of user code in 2.6 for the sake of stricter argument checking for object.__init__ and object.__new__. I think it probably isn't; but the strict version could be added to 3.0 and a warning issued in 2.6 in -Wpy3k mode. Alternatively, we could introduce the stricter code in 2.6, fix the stdlib modules that it breaks, and hope for the best. Opinions? Perhaps I misunderstand the patch, but it would appear to break not just some inadvisable uses of super(), but an actual core feature of super(). Maybe someone can set me right. Is this correct? class Base(object): def __init__(self, important): # Don't upcall with `important` because object is the base # class and its __init__ doesn't care (or won't accept) it super(Base, self).__init__() self.a = important If so, what are the implications for this? class Other(object): def __init__(self, important): # Don't upcall with `important` because object is the base # class and its __init__ doesn't care (or won't accept) it super(Other, self).__init__() self.b = important class Derived(Base, Other): pass (A similar example could be given where Base and Other take differently named arguments with nothing to do with each other. The end result is the same either way, I think.) The common name is actually critical. Your argument names are essentially a shared namespace, just like that on the object itself, and they're both modifying it on the assumption of being the only thing that does so. There's two ways to fix your example. First, adding a common base class which is the owner of that name: class Owner(object): def __init__(self, important, **kwargs): super(Owner, self).__init__(**kwargs) # important is skipped class Left(Owner): def __init__(self, important, **kwargs): super(Left, self).__init__(important=important, **kwargs) class Right(Owner): def __init__(self, important, **kwargs): super(Right, self).__init__(important=important, **kwargs) class Derived(Left, Right): pass Derived(hi) The other is to rename the argument, removing the namespace conflict: class Left(object): def __init__(self, oranges, **kwargs): super(Left, self).__init__(oranges=oranges, **kwargs) class Right(object): def __init__(self, apples, **kwargs): super(Right, self).__init__(apples=apples, **kwargs) class Derived(Left, Right): pass Hmm, where's that undo post button... That should be: class Left(object): def __init__(self, oranges, **kwargs): super(Left, self).__init__(**kwargs) class Right(object): def __init__(self, apples, **kwargs): super(Right, self).__init__(**kwargs) class Derived(Left, Right): pass And I would have gotten an error when I tested it had I been using the strict __init__. Derived(apples=3, oranges=8) In this second version you could clean up Derived's interface by adding either def __init__(self, apples, oranges, **kwargs) and passing them both explicitly, or by adding def __init__(self, *, **kwargs) and requiring they by given to you by name. Either way you're completely safe. I think I understand the desire to pull keyword arguments out at each step of the upcalling process, but I don't see how it can work, since up calling isn't always what's going on - given a diamond, there's arbitrary side-calling, so for cooperation to work every method has to pass on every argument, so object.__init__ has to take arbitrary args, since no one knows when their up call will actually hit object. Since without diamonds, naive by-name upcalling works, I assume that super() is actually intended to be used with diamonds, so this seems relevant. I hope I've just overlooked something. Writing this email feels very strange. super() has always felt strange to me. Now, with PEP 3102 and the strict __init__, not so much. -- Adam Olsen, aka Rhamphoryncus -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking calls to object.__init__/__new__
On 3/21/07, Aahz [EMAIL PROTECTED] wrote: Maybe so, but this would massively break my company's application, if we were actually using new-style classes and the built-in super(). We have a web application that commonly passes all form fields down as **kwargs; the application uses lots of mixin classes with identically-named methods. We have a home-brew super() that crawls the stack. For what? Call me a strong -1 on this now that JP has explained what it does. I can't believe we're the only people doing this. I guess it doesn't matter as much for 3.0 because we're probably going to have to do a massive rewrite for that, anyway. (This codebase started in 1.4 and we're still running against 2.2.) But my take is that this is still an ugly fix. A trivial fix to get the behavior you want is to introduce a new class Object that all your company's classes derive from which has an __init__ that ignores its arguments and does nothing. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking calls to object.__init__/__new__
At 09:41 PM 3/21/2007 -0700, Guido van Rossum wrote: On 3/21/07, Greg Ewing [EMAIL PROTECTED] wrote: Every time I've considered using super, I've eventually decided against it for reasons like this. I've always found a better way that doesn't introduce so may strange interactions between the classes involved. I end up feeling the same way, for purely pragmatic reasons. However, cooperative multiple inheritance is a respected religion, and when practiced systematically can work well. Also make a big distinction between super calls of __init__ (which are a Pythonic wart and don't exist in other languages practicing multiple inheritance AFAIK) and super calls of regular methods (which are virtually problem-free as long as you agree on a base class that defines a method and derive from that class when you want to extend it). FYI, the only time I ever use super() for __init__ calls is for metaclasses. However, there the signature is fixed, so this problem doesn't really arise. However, in Py3K the metaclass __init__ will accept keyword arguments. What's the right thing to do there? Should we pass them all through? I'm not sure if there's any inherent symmetry between this and object.__init__ -- but it seems to be an interesting question in its own right. The whole point of being co-operative in a metaclass is to allow other metaclasses to be safely mixed in -- and they may be metaclasses from a completely different library or framework. So, it's not as simple as saying use a specialized base class -- the class author may not even *know* that metaclasses are involved, let alone multiple ones. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking calls to object.__init__/__new__
On 3/21/07, Greg Ewing [EMAIL PROTECTED] wrote: Every time I've considered using super, I've eventually decided against it for reasons like this. I've always found a better way that doesn't introduce so may strange interactions between the classes involved. I end up feeling the same way, for purely pragmatic reasons. However, cooperative multiple inheritance is a respected religion, and when practiced systematically can work well. Also make a big distinction between super calls of __init__ (which are a Pythonic wart and don't exist in other languages practicing multiple inheritance AFAIK) and super calls of regular methods (which are virtually problem-free as long as you agree on a base class that defines a method and derive from that class when you want to extend it). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking calls to object.__init__/__new__
On 3/21/07, Terry Reedy [EMAIL PROTECTED] wrote: It seems to me that to get the exact behavior one wants at the apex of a diamond structure, one should subclass object and override .__init__ with a function that does not call object.__init__ and use that subclass as the apex instead of object itself. Wouldn't this mask the behavior of object.__init__ and whatever changes decided on? Yup, that's what I recommended for Aahz. (But having said that, I have no opiniou on what the default should be for those who don't do this.) I do now -- for the single inheritance case, refusing extra args makes the most sense too, so that sohuld be the default in 3.0. With a Py3k warning in 2.6. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking calls to object.__init__/__new__
On 3/21/07, Jean-Paul Calderone [EMAIL PROTECTED] wrote: On Wed, 21 Mar 2007 15:45:16 -0700, Guido van Rossum [EMAIL PROTECTED] wrote: See python.org/sf/1683368. I'd like to invite opinions on whether it's worth breaking an unknown amount of user code in 2.6 for the sake of stricter argument checking for object.__init__ and object.__new__. I think it probably isn't; but the strict version could be added to 3.0 and a warning issued in 2.6 in -Wpy3k mode. Alternatively, we could introduce the stricter code in 2.6, fix the stdlib modules that it breaks, and hope for the best. Opinions? Perhaps I misunderstand the patch, but it would appear to break not just some inadvisable uses of super(), but an actual core feature of super(). Maybe someone can set me right. Is this correct? class Base(object): def __init__(self, important): # Don't upcall with `important` because object is the base # class and its __init__ doesn't care (or won't accept) it super(Base, self).__init__() self.a = important If so, what are the implications for this? class Other(object): def __init__(self, important): # Don't upcall with `important` because object is the base # class and its __init__ doesn't care (or won't accept) it super(Other, self).__init__() self.b = important class Derived(Base, Other): pass (A similar example could be given where Base and Other take differently named arguments with nothing to do with each other. The end result is the same either way, I think.) The common name is actually critical. Your argument names are essentially a shared namespace, just like that on the object itself, and they're both modifying it on the assumption of being the only thing that does so. There's two ways to fix your example. First, adding a common base class which is the owner of that name: class Owner(object): def __init__(self, important, **kwargs): super(Owner, self).__init__(**kwargs) # important is skipped class Left(Owner): def __init__(self, important, **kwargs): super(Left, self).__init__(important=important, **kwargs) class Right(Owner): def __init__(self, important, **kwargs): super(Right, self).__init__(important=important, **kwargs) class Derived(Left, Right): pass Derived(hi) The other is to rename the argument, removing the namespace conflict: class Left(object): def __init__(self, oranges, **kwargs): super(Left, self).__init__(oranges=oranges, **kwargs) class Right(object): def __init__(self, apples, **kwargs): super(Right, self).__init__(apples=apples, **kwargs) class Derived(Left, Right): pass Derived(apples=3, oranges=8) In this second version you could clean up Derived's interface by adding either def __init__(self, apples, oranges, **kwargs) and passing them both explicitly, or by adding def __init__(self, *, **kwargs) and requiring they by given to you by name. Either way you're completely safe. I think I understand the desire to pull keyword arguments out at each step of the upcalling process, but I don't see how it can work, since up calling isn't always what's going on - given a diamond, there's arbitrary side-calling, so for cooperation to work every method has to pass on every argument, so object.__init__ has to take arbitrary args, since no one knows when their up call will actually hit object. Since without diamonds, naive by-name upcalling works, I assume that super() is actually intended to be used with diamonds, so this seems relevant. I hope I've just overlooked something. Writing this email feels very strange. super() has always felt strange to me. Now, with PEP 3102 and the strict __init__, not so much. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Extended Buffer Interface/Protocol
Travis Oliphant wrote: I'm talking about arrays of pointers to other arrays: i.e. if somebody defined in C float B[10][20] then B would B an array of pointers to arrays of floats. No, it wouldn't, it would be a contiguously stored 2-dimensional array of floats. An array of pointers would be float *B[10]; followed by code to allocate 10 arrays of 20 floats each and initialise B to point to them. Yes, I saw that. But, it could actually be supported, in general. Certainly it *can* be supported, but the question is how many different format variations it's reasonable to expect the consumer of the data to be able to deal with. Because each variation requires the consumer to use different code to access the data, if it wants to avoid making a copy. else if (ndims == 3) var = (float ***)segments for (i=0; ishape[0]; i++) for (j=0; jshape[1]; j++) for (k=0; jshape[2]; k++) # process var[i][j][k] This assumes that the 3-dimensional case is using the array-of-pointers implementation at all levels. But there are other possibilities, e.g. a 1d array of pointers to contiguous 2d arrays, or a contiguous 2d array of pointers to 1d arrays. It's hard to deal with all of those using a common piece of code. I can imagine cases like that coming up in practice. For example, an image object might store its data as four blocks of memory for R, G, B and A planes, each of which is a contiguous 2d array with shape and stride -- but you want to view it as a 3d array byte[plane][x][y]. (Actually you'd probably *prefer* to view it as byte[x][y][plane], which would make things even more difficult...) I was thinking more of a C-iterator, like NumPy provides. This can be very efficient (as long as the loop is not in Python). It sure provides a nice abstraction that lets you deal with discontiguous arrays as if they were contiguous, though. Something like that might be useful. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Breaking calls to object.__init__/__new__
At 09:41 PM 3/21/2007 -0700, Guido van Rossum wrote: Also make a big distinction between super calls of __init__ (which are a Pythonic wart and don't exist in other languages practicing multiple inheritance AFAIK) Since I filed the bug, I should clarify that the primary reason I'm using super-init is to avoid multiple construction of a shared base (even if the base is just object, since I'd prefer not to rely on object's initializer being a no-op). C++ ensures that virtual bases are only constructed once, so there's no concern as to multiple construction. Is there a Python pattern better than super-init that provides the same guarantee? (Apologies if this appears in the wrong place; I just joined the list and I'm not seeing a way to participate in an existing thread.) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
