Re: [Python-Dev] Test cases not garbage collected after run
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/14/2011 1:23 AM, Martin (gzlist) wrote: On 07/04/2011, Michael Foord fuzzy...@voidspace.org.uk wrote: On 07/04/2011 20:18, Robert Collins wrote: Testtools did something to address this problem, but I forget what it was offhand. Some issues were worked around, but I don't remember any comprehensive solution. The proposed fix is to make test suite runs destructive, either replacing TestCase instances with None or pop'ing tests after they are run (the latter being what twisted Trial does). run-in-a-loop helpers could still repeatedly iterate over suites, just not call the suite. Just pop-ing is unlikely to be sufficient in practice. The Bazaar test suite (which uses testtools nowadays) has code that pops during the run, but still keeps every case alive for the duration. That trebles the runtime on my memory-constrained box unless I add a hack that clears the __dict__ of every testcase after it's run. Martin I think we would be ok with merging the __dict__ clearing as long as it doesn't do it for failed tests, etc. John =:- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2m1oAACgkQJdeBCYSNAAPHmwCfQSNW8Pk7V7qx6Jl/gYthFVxE p0cAn0XRvRR+Rqb+yiJnaVEzUOBdwOpf =19YJ -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] Test cases not garbage collected after run
On 14/04/2011 00:23, Martin (gzlist) wrote: On 07/04/2011, Michael Foordfuzzy...@voidspace.org.uk wrote: On 07/04/2011 20:18, Robert Collins wrote: Testtools did something to address this problem, but I forget what it was offhand. Some issues were worked around, but I don't remember any comprehensive solution. The proposed fix is to make test suite runs destructive, either replacing TestCase instances with None or pop'ing tests after they are run (the latter being what twisted Trial does). run-in-a-loop helpers could still repeatedly iterate over suites, just not call the suite. Just pop-ing is unlikely to be sufficient in practice. The Bazaar test suite (which uses testtools nowadays) has code that pops during the run, but still keeps every case alive for the duration. That trebles the runtime on my memory-constrained box unless I add a hack that clears the __dict__ of every testcase after it's run. I'd be interested to know what is keeping the tests alive even when the test suite isn't. As far as I know there is nothing else in unittest that would do that. It's either a general problem that unittest can fix, or it is a problem *caused* by the bazaar test suite and should be fixed there. Bazaar does some funky stuff copying tests to run them with different backends, so it is possible that this is the cause of the problem (and it isn't a general problem). All the best, Michael Foord Martin -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] python and super
Hi all, I recently stumbled upon an issue with a class in the mro chain not calling super, therefore breaking the chain (ie, further base classes along the chain didn't get called). I understand it is currently a requirement that all classes that are part of the mro chain behave and always call super. My question is, shouldn't/wouldn't it be better, if python took ownership of that part, and ensured all classes get called, even if some class misbehaved? For example, if using a stack-like structure, pushing super calls and popping until the stack was empty, couldn't this restriction be removed? Thanks, Ricardo ___ 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] python and super
2011/4/14 Ricardo Kirkner ricardokirk...@gmail.com: Hi all, I recently stumbled upon an issue with a class in the mro chain not calling super, therefore breaking the chain (ie, further base classes along the chain didn't get called). I understand it is currently a requirement that all classes that are part of the mro chain behave and always call super. My question is, shouldn't/wouldn't it be better, if python took ownership of that part, and ensured all classes get called, even if some class misbehaved? For example, if using a stack-like structure, pushing super calls and popping until the stack was empty, couldn't this restriction be removed? No. See line 2 of the Zen of Python. -- Regards, Benjamin ___ 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] python and super
On Thu, 14 Apr 2011 08:15:10 -0500 Benjamin Peterson benja...@python.org wrote: 2011/4/14 Ricardo Kirkner ricardokirk...@gmail.com: Hi all, I recently stumbled upon an issue with a class in the mro chain not calling super, therefore breaking the chain (ie, further base classes along the chain didn't get called). I understand it is currently a requirement that all classes that are part of the mro chain behave and always call super. My question is, shouldn't/wouldn't it be better, if python took ownership of that part, and ensured all classes get called, even if some class misbehaved? For example, if using a stack-like structure, pushing super calls and popping until the stack was empty, couldn't this restriction be removed? No. See line 2 of the Zen of Python. You could have quoted it explicitly :) FWIW, line 2 is: Explicit is better than implicit. Regards Antoine. ___ 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] python and super
:-) 2011/4/14 Antoine Pitrou solip...@pitrou.net On Thu, 14 Apr 2011 08:15:10 -0500 Benjamin Peterson benja...@python.org wrote: 2011/4/14 Ricardo Kirkner ricardokirk...@gmail.com: Hi all, I recently stumbled upon an issue with a class in the mro chain not calling super, therefore breaking the chain (ie, further base classes along the chain didn't get called). I understand it is currently a requirement that all classes that are part of the mro chain behave and always call super. My question is, shouldn't/wouldn't it be better, if python took ownership of that part, and ensured all classes get called, even if some class misbehaved? For example, if using a stack-like structure, pushing super calls and popping until the stack was empty, couldn't this restriction be removed? No. See line 2 of the Zen of Python. You could have quoted it explicitly :) FWIW, line 2 is: Explicit is better than implicit. Regards Antoine. ___ 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/g.rodola%40gmail.com ___ 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] python and super
Ricardo Kirkner wrote: Hi all, I recently stumbled upon an issue with a class in the mro chain not calling super, therefore breaking the chain (ie, further base classes along the chain didn't get called). I understand it is currently a requirement that all classes that are part of the mro chain behave and always call super. My question is, shouldn't/wouldn't it be better, if python took ownership of that part, and ensured all classes get called, even if some class misbehaved? Consider the difference between extending the method and replacing it. (I've always known that as overloading and overriding, but the terminology varies.) If Python automagically always called super(), how would you replace a method? For that matter, at which point would you automagically call super()? At the start of the overloaded method, before the subclass code runs? At the end, after the subclass code? Somewhere in the middle? class Spam(Ham): def method(self): # Overload method. super().method() # at the start of the method? do_stuff() super().method() # in the middle of the method? do_more_stuff() super().method() # or at the end of the overloaded method? What arguments should be passed? What do you do with the result? If you can think of a way for Python to automagically tell when to call super(), what arguments to pass to it, and what to do with the result, your crystal ball is better than mine. -- Steven ___ 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] python and super
On 14 Apr, 2011, at 15:09, Ricardo Kirkner wrote: Hi all, I recently stumbled upon an issue with a class in the mro chain not calling super, therefore breaking the chain (ie, further base classes along the chain didn't get called). I understand it is currently a requirement that all classes that are part of the mro chain behave and always call super. My question is, shouldn't/wouldn't it be better, if python took ownership of that part, and ensured all classes get called, even if some class misbehaved? Not calling a method on super isn't necessarily misbehavior. It would be odd to not call super in __init__, but for other methods not calling the superclass implementation is fairly common. Ronald ___ 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] python and super
On 14/04/2011 15:18, Ronald Oussoren wrote: On 14 Apr, 2011, at 15:09, Ricardo Kirkner wrote: Hi all, I recently stumbled upon an issue with a class in the mro chain not calling super, therefore breaking the chain (ie, further base classes along the chain didn't get called). I understand it is currently a requirement that all classes that are part of the mro chain behave and always call super. My question is, shouldn't/wouldn't it be better, if python took ownership of that part, and ensured all classes get called, even if some class misbehaved? Not calling a method on super isn't necessarily misbehavior. It would be odd to not call super in __init__, but for other methods not calling the superclass implementation is fairly common. Right, but where you have an inheritance chain where all the classes do call super but one doesn't then you can get breakage. This is a problem where you want to use multiple inheritance but a parent class of *one* of the classes doesn't call super. Not only does the super of its parents not get called - but the chain stops and other methods (in another branch of the inheritance tree) also don't get called. And if the base classes are not all under your control there maybe no fix - except possibly monkey patching. Ricardo isn't suggesting that Python should always call super for you, but when you *start* the chain by calling super then Python could ensure that all the methods are called for you. If an individual method doesn't call super then a theoretical implementation could skip the parents methods (unless another child calls super). All the best, Michael Foord Ronald ___ 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 -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] python and super
I think that if you add this, people will start relying on it. Laura ___ 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] python and super
On 14/04/2011 16:02, Laura Creighton wrote: I think that if you add this, people will start relying on it. And the specific problem with that would be? Michael Laura -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] python and super
At 03:55 PM 4/14/2011 +0100, Michael Foord wrote: Ricardo isn't suggesting that Python should always call super for you, but when you *start* the chain by calling super then Python could ensure that all the methods are called for you. If an individual method doesn't call super then a theoretical implementation could skip the parents methods (unless another child calls super). That would break classes that deliberately don't call super. I can think of examples in my own code that would break, especially in __init__() cases. It's perfectly sensible and useful for there to be classes that intentionally fail to call super(), and yet have a subclass that wants to use super(). So, this change would expose an internal implementation detail of a class to its subclasses, and make fragile base class problems worse. (i.e., where an internal change to a base class breaks a previously-working subclass). ___ 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] python and super
On 14/04/2011 16:34, P.J. Eby wrote: At 03:55 PM 4/14/2011 +0100, Michael Foord wrote: Ricardo isn't suggesting that Python should always call super for you, but when you *start* the chain by calling super then Python could ensure that all the methods are called for you. If an individual method doesn't call super then a theoretical implementation could skip the parents methods (unless another child calls super). That would break classes that deliberately don't call super. I can think of examples in my own code that would break, especially in __init__() cases. It's perfectly sensible and useful for there to be classes that intentionally fail to call super(), and yet have a subclass that wants to use super(). So, this change would expose an internal implementation detail of a class to its subclasses, and make fragile base class problems worse. (i.e., where an internal change to a base class breaks a previously-working subclass). It shouldn't do. What I was suggesting is that a method not calling super shouldn't stop a *sibling* method being called, but could still prevent the *parent* method being called. Michael -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] python and super
Exactly what Michael said. Stopping the chain going upwards is one thing. Stopping it going sideways is another. On Thu, Apr 14, 2011 at 12:37 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: On 14/04/2011 16:34, P.J. Eby wrote: At 03:55 PM 4/14/2011 +0100, Michael Foord wrote: Ricardo isn't suggesting that Python should always call super for you, but when you *start* the chain by calling super then Python could ensure that all the methods are called for you. If an individual method doesn't call super then a theoretical implementation could skip the parents methods (unless another child calls super). That would break classes that deliberately don't call super. I can think of examples in my own code that would break, especially in __init__() cases. It's perfectly sensible and useful for there to be classes that intentionally fail to call super(), and yet have a subclass that wants to use super(). So, this change would expose an internal implementation detail of a class to its subclasses, and make fragile base class problems worse. (i.e., where an internal change to a base class breaks a previously-working subclass). It shouldn't do. What I was suggesting is that a method not calling super shouldn't stop a *sibling* method being called, but could still prevent the *parent* method being called. Michael -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] python and super
On Thu, Apr 14, 2011 at 16:18, Ronald Oussoren ronaldousso...@mac.com wrote: It would be odd to not call super in __init__, but for other methods not calling the superclass implementation is fairly common. Yes it is odd, that for example list.__init__ doesn't call super :-) (http://bugs.python.org/issue8733) Daniel ___ 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] python and super
On Apr 14, 2011, at 8:34 AM, P.J. Eby wrote: At 03:55 PM 4/14/2011 +0100, Michael Foord wrote: Ricardo isn't suggesting that Python should always call super for you, but when you *start* the chain by calling super then Python could ensure that all the methods are called for you. If an individual method doesn't call super then a theoretical implementation could skip the parents methods (unless another child calls super). That would break classes that deliberately don't call super. I can think of examples in my own code that would break, especially in __init__() cases. It's perfectly sensible and useful for there to be classes that intentionally fail to call super(), and yet have a subclass that wants to use super(). So, this change would expose an internal implementation detail of a class to its subclasses, and make fragile base class problems worse. (i.e., where an internal change to a base class breaks a previously-working subclass). I agree. Better for someone to submit a recipe for a variant of super and see if there is any uptake. 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] python and super
On 14/04/2011 17:02, Raymond Hettinger wrote: On Apr 14, 2011, at 8:34 AM, P.J. Eby wrote: At 03:55 PM 4/14/2011 +0100, Michael Foord wrote: Ricardo isn't suggesting that Python should always call super for you, but when you *start* the chain by calling super then Python could ensure that all the methods are called for you. If an individual method doesn't call super then a theoretical implementation could skip the parents methods (unless another child calls super). That would break classes that deliberately don't call super. I can think of examples in my own code that would break, especially in __init__() cases. It's perfectly sensible and useful for there to be classes that intentionally fail to call super(), and yet have a subclass that wants to use super(). So, this change would expose an internal implementation detail of a class to its subclasses, and make fragile base class problems worse. (i.e., where an internal change to a base class breaks a previously-working subclass). I agree. Better for someone to submit a recipe for a variant of super and see if there is any uptake. In Python 3 super is treated specially by the compiler, so an alternative implementation that behaves similarly to the built-in one modulo this change is not possible. Two use cases for the suggested alternative behaviour have been presented. What is the use case for a method not wanting to prevent its *sibling* methods in a multiple inheritance situation being called? I believe the use case Phillip (and others) have presented is for methods preventing their *parent* methods being called. All the best, Michael Foord Raymond -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] python and super
On 14 Apr, 2011, at 18:10, Michael Foord wrote: On 14/04/2011 17:02, Raymond Hettinger wrote: On Apr 14, 2011, at 8:34 AM, P.J. Eby wrote: At 03:55 PM 4/14/2011 +0100, Michael Foord wrote: Ricardo isn't suggesting that Python should always call super for you, but when you *start* the chain by calling super then Python could ensure that all the methods are called for you. If an individual method doesn't call super then a theoretical implementation could skip the parents methods (unless another child calls super). That would break classes that deliberately don't call super. I can think of examples in my own code that would break, especially in __init__() cases. It's perfectly sensible and useful for there to be classes that intentionally fail to call super(), and yet have a subclass that wants to use super(). So, this change would expose an internal implementation detail of a class to its subclasses, and make fragile base class problems worse. (i.e., where an internal change to a base class breaks a previously-working subclass). I agree. Better for someone to submit a recipe for a variant of super and see if there is any uptake. In Python 3 super is treated specially by the compiler, so an alternative implementation that behaves similarly to the built-in one modulo this change is not possible. Two use cases for the suggested alternative behaviour have been presented. What is the use case for a method not wanting to prevent its *sibling* methods in a multiple inheritance situation being called? I believe the use case Phillip (and others) have presented is for methods preventing their *parent* methods being called. What would the semantics be of a super that intentially calls all siblings? In particular what is the return value of such a call? The implementation can't know how to combine the implementations in the inheritance chain and should refuse the tempation to guess. Ronald ___ 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] python and super
On Apr 14, 2011, at 12:59 PM, Ronald Oussoren wrote: What would the semantics be of a super that (...) I think it's long past time that this move to python-ideas, if you don't mind. ___ 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] [Python-checkins] cpython (merge 3.2 - default): merge from 3.2.
I think you have the wrong issue #; that one has to do with string
exceptions.
On Wed, Apr 13, 2011 at 22:21, senthil.kumaran
python-check...@python.orgwrote:
http://hg.python.org/cpython/rev/7563f10275a2
changeset: 69350:7563f10275a2
parent: 69344:1f767f834e67
parent: 69349:37d1b749eebb
user:Senthil Kumaran orsent...@gmail.com
date:Thu Apr 14 13:20:41 2011 +0800
summary:
merge from 3.2.
Fix closes Issue1147.
files:
Lib/nturl2path.py | 5 -
Lib/test/test_urllib.py | 18 ++
Misc/NEWS | 3 +++
3 files changed, 25 insertions(+), 1 deletions(-)
diff --git a/Lib/nturl2path.py b/Lib/nturl2path.py
--- a/Lib/nturl2path.py
+++ b/Lib/nturl2path.py
@@ -27,9 +27,12 @@
drive = comp[0][-1].upper()
components = comp[1].split('/')
path = drive + ':'
-for comp in components:
+for comp in components:
if comp:
path = path + '\\' + urllib.parse.unquote(comp)
+# Issue #11474 - handing url such as |c/|
+if path.endswith(':') and url.endswith('/'):
+path += '\\'
return path
def pathname2url(p):
diff --git a/Lib/test/test_urllib.py b/Lib/test/test_urllib.py
--- a/Lib/test/test_urllib.py
+++ b/Lib/test/test_urllib.py
@@ -9,6 +9,7 @@
import unittest
from test import support
import os
+import sys
import tempfile
def hexescape(char):
@@ -1021,6 +1022,23 @@
url2pathname() failed; %s != %s %
(expect, result))
+@unittest.skipUnless(sys.platform == 'win32',
+ 'test specific to the urllib.url2path function.')
+def test_ntpath(self):
+given = ('/C:/', '///C:/', '/C|//')
+expect = 'C:\\'
+for url in given:
+result = urllib.request.url2pathname(url)
+self.assertEqual(expect, result,
+ 'urllib.request..url2pathname() failed; %s !=
%s' %
+ (expect, result))
+given = '///C|/path'
+expect = 'C:\\path'
+result = urllib.request.url2pathname(given)
+self.assertEqual(expect, result,
+ 'urllib.request.url2pathname() failed; %s != %s'
%
+ (expect, result))
+
class Utility_Tests(unittest.TestCase):
Testcase to test the various utility functions in the urllib.
diff --git a/Misc/NEWS b/Misc/NEWS
--- a/Misc/NEWS
+++ b/Misc/NEWS
@@ -103,6 +103,9 @@
Library
---
+- Issue #11474: Fix the bug with url2pathname() handling of '/C|/' on
Windows.
+ Patch by Santoso Wijaya.
+
- Issue #11684: complete email.parser bytes API by adding
BytesHeaderParser.
- The bz2 module now handles 4GiB+ input buffers correctly.
--
Repository URL: http://hg.python.org/cpython
___
Python-checkins mailing list
python-check...@python.org
http://mail.python.org/mailman/listinfo/python-checkins
___
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] Status of json (simplejson) in cpython
Hi all, it all started with issue10019. The version we have in cpython of json is simplejson 2.0.9 highly patched (either because it was converted to py3k, and because of the normal flow of issues/bugfixes) while upstream have already released 2.1.13 . Their 2 roads had diverged a lot, and since this blocks any further update of cpython's json from upstream, I'd like to close this gap. This isn't exactly an easy task, and this email is more about a brainstorming on the ways we have to achieve the goal: being able to upgrade json to 2.1.13. Luckily, upstream is receptive for patches, so part of the job is to forward patches written for cpython not already in the upstream code. But how am I going to do this? let's do a brain-dump: - the history goes back at changeset f686aced02a3 (May 2009, wow) when 2.0.9 was merged on trunk - I can navigate from that CS up to tip, and examine the diffs and see if they apply to 2.1.3 and prepare a set of patches to be forwarded - part of those diffs is about py3k conversion, that probably needs to be extended to other part of the upstream code not currently in cpython. For those new code parts, do you have some guides about porting a project to py3k? it would be my first time and other than building it and running it with python3 i don't know what to do :) - once (and if :) I reach the point where I've all the relevant patches applied on 2.1.3 what's the next step? -- take 2.1.3 + patches, copy it on Lib/json + test + Modules and see what breaks? -- what about the doc? (uh luckily I just noticed it's already in the upstream repo, so another thing to sync) - what are we going to do in the long run? how can we assure we'll be having a healthy collaboration with upsteam? f.e. in case a bug is reported (and later on fixed) in cpython? is there a policy for projects present in cpython and also maintained elsewhere? At the end: do you have some suggestions that might this task be successful? advice on the steps above, tips about the merge, something like this. Thanks a lot for your time, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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 json (simplejson) in cpython
On Thu, 14 Apr 2011 21:22:27 +0200 Sandro Tosi sandro.t...@gmail.com wrote: But how am I going to do this? let's do a brain-dump: IMHO, you should compute the diff between 2.0.9 and 2.1.3 and try to apply it to the CPython source tree (you'll probably have to change the file paths). - what are we going to do in the long run? how can we assure we'll be having a healthy collaboration with upsteam? Tricky question... :/ Regards Antoine. ___ 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 json (simplejson) in cpython
- what are we going to do in the long run? how can we assure we'll be having a healthy collaboration with upsteam? f.e. in case a bug is reported (and later on fixed) in cpython? is there a policy for projects present in cpython and also maintained elsewhere? At the end: do you have some suggestions that might this task be successful? advice on the steps above, tips about the merge, something like this. I think it would be useful if the porting was done all-over, in a way that allows upstream to provide 2.x and 3.x out of a single code base, and get this port merged into upstream. If there are bug fixes that we made on the json algorithms proper, these would have to be identified and redone, or simply ignored (hoping that somebody will re-report them if the issue persists). A necessary prerequisite is that we have a dedicated maintainer of the json package. 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] Status of json (simplejson) in cpython
On Apr 14, 2011, at 12:22 PM, Sandro Tosi wrote: The version we have in cpython of json is simplejson 2.0.9 highly patched (either because it was converted to py3k, and because of the normal flow of issues/bugfixes) while upstream have already released 2.1.13 . Their 2 roads had diverged a lot, and since this blocks any further update of cpython's json from upstream, I'd like to close this gap. Are you proposing updates to the Python 3.3 json module to include newer features like use_decimal and changing the indent argument from an integer to a string? - what are we going to do in the long run? If Bob shows no interest in Python 3, then the code bases will probably continue to diverge. Since the JSON spec is set in stone, the changes will mostly be about API (indentation, object conversion, etc) and optimization. I presume the core parsing logic won't be changing much. 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] python and super
On Thu, 2011-04-14 at 17:10 +0100, Michael Foord wrote: On 14/04/2011 17:02, Raymond Hettinger wrote: On Apr 14, 2011, at 8:34 AM, P.J. Eby wrote: At 03:55 PM 4/14/2011 +0100, Michael Foord wrote: Ricardo isn't suggesting that Python should always call super for you, but when you *start* the chain by calling super then Python could ensure that all the methods are called for you. If an individual method doesn't call super then a theoretical implementation could skip the parents methods (unless another child calls super). That would break classes that deliberately don't call super. I can think of examples in my own code that would break, especially in __init__() cases. It's perfectly sensible and useful for there to be classes that intentionally fail to call super(), and yet have a subclass that wants to use super(). So, this change would expose an internal implementation detail of a class to its subclasses, and make fragile base class problems worse. (i.e., where an internal change to a base class breaks a previously-working subclass). I agree. Better for someone to submit a recipe for a variant of super and see if there is any uptake. In Python 3 super is treated specially by the compiler, so an alternative implementation that behaves similarly to the built-in one modulo this change is not possible. I know that super does some astonishing *runtime* hackery with co_code when you don't pass arguments, but I thought that was all that was needed. What does the compiler have to do specially for super that would prevent somebody from implementing something like it? Two use cases for the suggested alternative behaviour have been presented. What is the use case for a method not wanting to prevent its *sibling* methods in a multiple inheritance situation being called? I believe the use case Phillip (and others) have presented is for methods preventing their *parent* methods being called. All the best, Michael Foord 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] Hosting the Jython hg repo
On Apr 10, 2011, at 2:44 PM, Antoine Pitrou wrote: On Sun, 10 Apr 2011 21:58:40 +0200 Martin v. Löwis mar...@v.loewis.de wrote: Ultimately, it's up to Georg and Antoine to decide whether they want to accept the load. I don't want to maintain the Jython repo myself but if Georg or Philip accepts to do it it's fine. One option would be to grant a Jython developer control to account management - preferably a single person, who would then also approve/apply changes to the hooks. +1. Let's go ahead with this option then. Can someone please grant me said access? -- Philip Jenvey ___ 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] python and super
What would the semantics be of a super that intentially calls all siblings? In particular what is the return value of such a call? The implementation can't know how to combine the implementations in the inheritance chain and should refuse the tempation to guess. I'll give you the example I came upon: I have a TestCase class, which inherits from both Django's TestCase and from some custom TestCases that act as mixin classes. So I have something like class MyTestCase(TestCase, Mixin1, Mixin2): ... now django's TestCase class inherits from unittest2.TestCase, which we found was not calling super. Even if this is a bug and should be fixed in unittest2, this is an example where I, as a consumer of django, shouldn't have to be worried about how django's TestCase class is implemented. Since I explicitely base off 3 classes, I expected all 3 classes to be initialized, and I expect the setUp method to be called on all of them. If I'm assuming/expecting unreasonable things, please enlighten me. Otherwise, there you have a real-world use case for when you'd want the sibling classes to be called even if one class breaks the mro chain (in this case TestCase). Thanks, Ricardo ___ 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] python and super
Ricardo Kirkner wrote: What would the semantics be of a super that intentially calls all siblings? In particular what is the return value of such a call? The implementation can't know how to combine the implementations in the inheritance chain and should refuse the tempation to guess. I'll give you the example I came upon: I have a TestCase class, which inherits from both Django's TestCase and from some custom TestCases that act as mixin classes. So I have something like class MyTestCase(TestCase, Mixin1, Mixin2): ... now django's TestCase class inherits from unittest2.TestCase, which we found was not calling super. Even if this is a bug and should be fixed in unittest2, this is an example where I, as a consumer of django, shouldn't have to be worried about how django's TestCase class is implemented. Since I explicitely base off 3 classes, I expected all 3 classes to be initialized, and I expect the setUp method to be called on all of them. If I'm assuming/expecting unreasonable things, please enlighten me. Otherwise, there you have a real-world use case for when you'd want the sibling classes to be called even if one class breaks the mro chain (in this case TestCase). How does python tell your use-case from, say, this: class Mixin3(unittest2.TestCase): stuff happens class MyTestCase(TestCase, Mixin1, Mixin2, Mixin3): ... Here we have django's TestCase that does *not* want to call unittest2.TestCase (assuming that's not a bug), but it gets called anyway because the Mixin3 sibling has it as a base class. So does this mean that TestCase and Mixin3 just don't play well together? Maybe composition instead of inheritance is the answer (in this case, anyway ;). ~Ethan~ ___ 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 test case methods to TestCase subclasses (was: python and super)
Ethan Furman et...@stoneleaf.us writes: Here we have django's TestCase that does *not* want to call unittest2.TestCase (assuming that's not a bug), but it gets called anyway because the Mixin3 sibling has it as a base class. So does this mean that TestCase and Mixin3 just don't play well together? Maybe composition instead of inheritance is the answer (in this case, anyway ;). TestCase subclasses is a multiple-inheritance use case that I share. The mix-ins add test cases (methods named ‘test_’ on the mix-in class) to the TestCase subclass. I would prefer not to use multiple inheritance for this if it can be achieved in a better way. How can composition add test cases detectable by Python 2's ‘unittest’ and Python 3's ‘unittest2’? -- \ “The userbase for strong cryptography declines by half with | `\ every additional keystroke or mouseclick required to make it | _o__) work.” —Carl Ellison | Ben Finney ___ 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] python and super
On Apr 14, 2011, at 3:32 PM, Ricardo Kirkner wrote: What would the semantics be of a super that intentially calls all siblings? In particular what is the return value of such a call? The implementation can't know how to combine the implementations in the inheritance chain and should refuse the tempation to guess. I'll give you the example I came upon: I have a TestCase class, which inherits from both Django's TestCase and from some custom TestCases that act as mixin classes. So I have something like class MyTestCase(TestCase, Mixin1, Mixin2): ... now django's TestCase class inherits from unittest2.TestCase, which we found was not calling super. Even if this is a bug and should be fixed in unittest2, this is an example where I, as a consumer of django, shouldn't have to be worried about how django's TestCase class is implemented. Since I explicitely base off 3 classes, I expected all 3 classes to be initialized, and I expect the setUp method to be called on all of them. If I'm assuming/expecting unreasonable things, please enlighten me. For cooperative-multiple-inheritance to work, the classes need to cooperate by having been designed to work together in a series of cooperative super calls. If an external non-cooperative class needs to be used, then it should be wrapped in a class that makes an explicit __init__ call to the external class and then calls super().__init__() to continue the forwarding. 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] cpython (merge 3.2 - default): merge from 3.2.
On 4/14/2011 2:53 PM, Brett Cannon wrote: I think you have the wrong issue #; that one has to do with string exceptions. Fix closes Issue1147. Right, wrong issue. Log should be corrected if it has not been. +- Issue #11474: Fix the bug with url2pathname() handling of '/C|/' on Windows. Correct one. Senthil has already closed this manually. -- 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] python and super
Ricardo Kirkner wrote: My question is, shouldn't/wouldn't it be better, if python took ownership of that part, and ensured all classes get called, even if some class misbehaved? I don't think so. If a class isn't designed to be part of a super chain, there are likely to be other issues that can't be fixed as simply as this. -- 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] python and super
P.J. Eby wrote: It's perfectly sensible and useful for there to be classes that intentionally fail to call super(), and yet have a subclass that wants to use super(). One such case is where someone is using super() in a single-inheritance environment as a way of not having to write the base class name explicitly into calls to base methods. (I wouldn't recommend using super() that way myself, but some people do.) In that situation, any failure to call super() is almost certainly deliberate. -- 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] python and super
Michael Foord wrote: What I was suggesting is that a method not calling super shouldn't stop a *sibling* method being called, but could still prevent the *parent* method being called. There isn't necessarily a clear distinction between parents and siblings. class A: ... class B(A): ... class C(A, B): ... In C, is A a parent of B or a sibling of B? -- Greg Michael ___ 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] python and super
Ricardo Kirkner wrote: I have a TestCase class, which inherits from both Django's TestCase and from some custom TestCases that act as mixin classes. So I have something like class MyTestCase(TestCase, Mixin1, Mixin2): ... now django's TestCase class inherits from unittest2.TestCase, which we found was not calling super. Even if this is a bug and should be fixed in unittest2, this is an example where I, as a consumer of django, shouldn't have to be worried about how django's TestCase class is implemented. Since I explicitely base off 3 classes, I expected all 3 classes to be initialized, and I expect the setUp method to be called on all of them. If I'm assuming/expecting unreasonable things, please enlighten me. If we treat django's failure to use super as a bug, you want the Python language to work-around that bug so that: I, as a consumer of django, shouldn't have to be worried about bugs in django. (For at least one class of bug.) If we *don't* treat django's failure to use super as a bug, but as a deliberate design choice, then you are trying to do something which django doesn't support. Possibly *deliberately* doesn't support. You want the Python language to add that support so that: I, as a consumer of django, shouldn't have to be worried about whether django supports what I want to do or not. Either way you look at it, I think it's extremely unreasonable to expect the language to work-around bugs in third-party applications, or to add features to them that the third-party developers either didn't consider or don't want. Multiple inheritance is tricky enough to get right without adding Do What I Mean black magic to it. I'd rather work around bugs in third-party classes than try to deal with Python actively subverting the code I read and write by mysteriously calling superclass methods where there is no call to a superclass method. -- Steven ___ 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] cpython (merge 3.2 - default): merge from 3.2.
On Thu, Apr 14, 2011 at 08:00:11PM -0400, Terry Reedy wrote: On 4/14/2011 2:53 PM, Brett Cannon wrote: I think you have the wrong issue #; that one has to do with string exceptions. Fix closes Issue1147. Right, wrong issue. Log should be corrected if it has not been. +- Issue #11474: Fix the bug with url2pathname() handling of '/C|/' on Windows. Yes, I copy-pasted the issue number and seem to have missed the last digit. I wondered why it was not automatically closed when I had to manually close it. Now, I realize the reason. Shall correct the logs. Thanks, Senthil ___ 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] python and super
Raymond Hettinger wrote: If an external non-cooperative class needs to be used, then it should be wrapped in a class that makes an explicit __init__ call to the external class and then calls super().__init__() to continue the forwarding. I don't think it's as simple as that. Isn't that super() call going to call the __init__() method that you just explicitly called *again*? Seems like you would at least need to use super(BaseClass)... to skip the one you just called. But it's not immediately obvious to me that this won't ever skip other classes that you *do* want to call. -- 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] python and super
On Fri, 15 Apr 2011 12:58:14 +1200, Greg Ewing greg.ew...@canterbury.ac.nz wrote: P.J. Eby wrote: It's perfectly sensible and useful for there to be classes that intentionally fail to call super(), and yet have a subclass that wants to use super(). One such case is where someone is using super() in a single-inheritance environment as a way of not having to write the base class name explicitly into calls to base methods. (I wouldn't recommend using super() that way myself, but some people do.) In that situation, any failure to call super() is almost certainly deliberate. Why not? It seems more useful than using it for chaining, especially given the compiler hack in Python3. -- R. David Murray http://www.bitdance.com ___ 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
