Re: [Python-Dev] Unit Test Guide
On Thu, Feb 21, 2008 at 7:43 AM, Giampaolo Rodola' <[EMAIL PROTECTED]> wrote: > > I have usually seen a lot of tests implemented like this: > > from test.test_support import TESTFN, unlink > import unittest > > class TestCase(unittest.TestCase): > > def setUp(self): > self.file = None > > def tearDown(self): > if self.file is not None: > self.file.close() > unlink(TESTFN) > > def test_something(self): > self.file = open(TESTFN, 'r') > ... Yes, but this is not as robust as it could be. It's better to also unlink/rmtree in the setUp. That way if the file doesn't get cleaned up (interpreter crash, KeyboardInterrupt, file not closed on Windows, exception in tearDown, etc), the test won't fail on the next run or the next test that assumes TESTFN doesn't exist won't fail. 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] Backporting PEP 3127 to trunk
On Thu, Feb 21, 2008 at 2:26 PM, Eric Smith <[EMAIL PROTECTED]> wrote: > I'm going to work on backporting PEP 3127, specifically the hex, oct(), > and bin() builtins. I have bin() completed, and I'll check it in > shortly. oct() will require a future import. Does anyone have any > pointers for implementing this? I understand (and have completed) > adding the future import, but what I don't understand is how to modify > the behavior of oct() for only the module where the future import is > execute. Any rough ideas or pointers to existing code that does > something similar would be helpful. See co_flags in PyCodeObject in Include/code.h. When you are compiling the code objects, you have access to the future flags. These (can) get baked into the code objects when they are created. You will need to make a new CO_* macro (0x1 is the next available after CO_FUTURE_WITH_STATEMENT). In the past future imports have typically affected the parser or semantics of the VM (e.g., future division). In your case, you need something different. Thomas Wouters had a somewhat similar problem when changing dict methods. In his case though, he output different op codes for the interpreter to execute to call the proper methods (*). You could use a similar trick here. However, if you were doing that, it begs the question of why not do as Guido suggests and just replace the builtins. If you only stored the info in the co_flags of code objects, the only way I know of would be to access the callers frame and get its co_flags. This is yucky. For example, what if oct() was called from C code? I think Guido's suggestion makes the most sense. My description above is just so people know what needs to be done, not a recommendation that it ought to be done. n (*) - e.g. STORE_VIEWATTR in http://svn.python.org/projects/python/branches/twouters-dictviews-backport/Python/ceval.c http://svn.python.org/projects/python/branches/twouters-dictviews-backport/Python/compile.c ___ 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] Backporting PEP 3127 to trunk
Raymond Hettinger wrote: > [Eric Smith] >> Speaking for myself, these features are generally useful, >> and are so even without the new integer literal syntax. > > I'm curious how these are useful to you in Py2.6 where > they are not invertible. In Py3.0, we can count on > > x == int(bin(x), 2) > x == eval(bin(x)) > > I don't see how these could work in Py2.6 without > changing the parser and changing the int() function. > > Why would you ever want to create a string like > '0o144' when there is no way to convert the string > back into a value? Because I need to output the values, for debugging and other purposes. I have no need to eval something I've bin'd, so I don't need them to be invertible. Same with hex. I realize I could just write these functions myself in Python, and not use the builtins. But I don't see the drawback of them being in 2.6. Eric. ___ 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] Backporting PEP 3127 to trunk
[Eric Smith] > Speaking for myself, these features are generally useful, > and are so even without the new integer literal syntax. I'm curious how these are useful to you in Py2.6 where they are not invertible. In Py3.0, we can count on x == int(bin(x), 2) x == eval(bin(x)) I don't see how these could work in Py2.6 without changing the parser and changing the int() function. Why would you ever want to create a string like '0o144' when there is no way to convert the string back into a value? Having both 0123 and 0o123 in the same version of language will create a confused mess, IMO. We should draw the line on Py3.0 backports whenever the two different models would be conflated (i.e. str/unicode vs bytes/text or 0123 vs 0o123). 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] Backporting PEP 3127 to trunk
Raymond Hettinger wrote: > [Eric Smith] >> I'm going to work on backporting PEP 3127, specifically >> the hex, oct(), and bin() builtins. > > IMO, these should not be backported. They are strongly > associated with 3.0's new literal syntax. They don't > don't really fit in with 2.6 and don't make 2.6 any more > attractive. I'm just going by what's on the spreadsheet. I assumed that these were all vetted. http://spreadsheets.google.com/pub?key=pCKY4oaXnT81FrGo3ShGHGg&gid=2 Speaking for myself, these features are generally useful, and are so even without the new integer literal syntax. Their existence would make 2.6 more attractive to me. Eric. ___ 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] dir() and __all__
[Benjamin] > Are you proposing just a list those modules > or all module objects? The idea is dead. Guido specified that the dir() function returns a list of names for which hasattr() will succeed. I only brought this up because a colleague was using dir() on modules to find-out about the API. He was thrown-off by some of the entries in dir(logging). 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-checkins] r60919 - peps/trunk/pep-0008.txt
Why not just skip the specifics except to say < 80 characters for all lines? Don't mention 72, 79 or any other number than 80: Maximum Line Length There are still many devices around that are limited to 80 character lines; plus, limiting windows to 80 characters makes it possible to have several windows side-by-side. The default wrapping on such devices disrupts the visual structure of the code, making it more difficult to understand. Therefore, please limit all lines to less than 80 characters. ... 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] int/float freelists vs pymalloc
May I chime in? :-) Gents, the current implementation of Python's memory management is really fine and most problems it used to have in the past have been fixed in recent years (at least the ones I know of). Probably the only one left, indeed, is the potential unbounded growth of int/float objects' freelists (beyond the shared cache of small ints). Yet, this seems to be a questionable problem because any change in the freelists' management will invariably slow down their allocation. By how much, I don't know, but whether you fallback to pymalloc above a certain threshold or use something else, the change will have a generic perf hit. The explanation is simple: you can't beat the free list scheme performance when you have frequent short bursts of allocations and deallocations, which is the typical Python pattern observed on New() & DECREF() calls. BTW if you have 2 AMD combos showing speedups noone can explain in an obvious way, then it's a cache effect. Optimizing pymalloc for non-standard byte-sizes is a no go, and although I've seen suggestions for further optimizations tailored to ints and floats, I haven't seen anyone spelling out what that optimization of pymalloc would consist of. MAL's suggestion to preallocate a pymalloc pool cache for certain object sizes is something I actually implemented in the earliest versions of pymalloc, but eventually dropped in favor of the current dynamic, on-request allocation because pre-allocating pools (and initializing the free lists) costs time and in general leads to degraded performance in the average case. I can't perf this now to prove it, but that was very clear at the time when I wrote the original stuff and applied the regression test on it. So I would kindly suggest to get down to the only problem (if any) which is the uncontrolled growth of the specialized freelists, the shared int cache notwithstanding. If you can limit a degenerative growth without a noticeable generic perf sacrifice, that would sound like an improvement to me, but so far I haven't seen any convincing arguments. And, of course, if the int/float freelist scheme was a real issue we would have probably heard of it by now in a very sound way. Vladimir ___ 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-math
Nick Coghlan wrote: > I would put the context manager in the math module as well. contextlib > is intended for generic context related tools (like nested() and > closing() that don't have a more topical home. I'll reimplement the ieee754 context manager in C once the feature gets accepted. For the experimental branch it was much easier to write it in Python. Christian ___ 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] dir() and __all__
On Feb 15, 9:18 pm, "Raymond Hettinger" <[EMAIL PROTECTED]> wrote: > [Raymond] > > >> Should dir(module) use __all__ when defined? > > [GvR] > > > It's not consistent with what dir() of a class or instance does though. > > > -1. > > Perhaps there is another solution. Have dir() exclude objects > which are modules. For example, dir(logging) would exclude > sys, os, types, time, string, cStringIO, and traceback. Are you proposing just a list those modules or all module objects? Excluding all modules would endanger __init__.py modules which imported modules from their package. > > Raymond > ___ > Python-Dev mailing list > [EMAIL PROTECTED]://mail.python.org/mailman/listinfo/python-dev > Unsubscribe:http://mail.python.org/mailman/options/python-dev/python-dev2-garchiv... ___ 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] Backporting PEP 3101 to 2.6
André Malo wrote: > * Eric Smith wrote: >> But now that I look at time.strftime in py3k, it's converting the entire >> unicode string to a char string with PyUnicode_AsString, then converting >> back with PyUnicode_Decode. > > Looks wrong to me, too... :-) > > nd I don't understand Unicode encoding/decoding well enough to describe this bug, but I admit it looks suspicious. Could someone who does understand it open a bug against 3.0 (hopefully with an example that fails)? The bug should also mention that 2.6 avoids this problem entirely by not supporting unicode with strftime or datetime.__format__, but 2.6 could probably leverage whatever solution is developed for 3.0. Thanks. ___ 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] Backporting PEP 3127 to trunk
[Eric Smith] > I'm going to work on backporting PEP 3127, specifically >the hex, oct(), and bin() builtins. IMO, these should not be backported. They are strongly associated with 3.0's new literal syntax. They don't don't really fit in with 2.6 and don't make 2.6 any more attractive. 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] Backporting PEP 3127 to trunk
I wonder if, in order to change the behavior of various built-in functions, it wouldn't be easier to be able to write from future_builtins import oct, hex # and who knows what else Agreed with your approach for bin(). On Thu, Feb 21, 2008 at 2:26 PM, Eric Smith <[EMAIL PROTECTED]> wrote: > I'm going to work on backporting PEP 3127, specifically the hex, oct(), > and bin() builtins. I have bin() completed, and I'll check it in > shortly. oct() will require a future import. Does anyone have any > pointers for implementing this? I understand (and have completed) > adding the future import, but what I don't understand is how to modify > the behavior of oct() for only the module where the future import is > execute. Any rough ideas or pointers to existing code that does > something similar would be helpful. I also need a name for the future > import statement. > > Also, I notice in py3k that __hex__ and __oct__ have vanished, and > instead hex() and oct() just uses the __index__ machinery to produce a > number, then converts that to a string. So I'm thinking that maybe we > could use the same future import statement that controls oct()'s > behavior to also switch hex() and oct() to the py3k behavior. Or, maybe > we should use a different future import? Or, I guess, not do this at > all. But I think it's a good idea. > > I guess another issue is changing hex()'s behavior of adding a trailing > L for longs. I don't really see the value in this, and maybe it should > also change with a future import statement. > > For bin(), I just used the py3k behavior, and didn't implement a __bin__ > method. I'm also not adding a trailing L for longs. I think that makes > the most sense. > > Eric. > > ___ > 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
[Python-Dev] Backporting PEP 3127 to trunk
I'm going to work on backporting PEP 3127, specifically the hex, oct(), and bin() builtins. I have bin() completed, and I'll check it in shortly. oct() will require a future import. Does anyone have any pointers for implementing this? I understand (and have completed) adding the future import, but what I don't understand is how to modify the behavior of oct() for only the module where the future import is execute. Any rough ideas or pointers to existing code that does something similar would be helpful. I also need a name for the future import statement. Also, I notice in py3k that __hex__ and __oct__ have vanished, and instead hex() and oct() just uses the __index__ machinery to produce a number, then converts that to a string. So I'm thinking that maybe we could use the same future import statement that controls oct()'s behavior to also switch hex() and oct() to the py3k behavior. Or, maybe we should use a different future import? Or, I guess, not do this at all. But I think it's a good idea. I guess another issue is changing hex()'s behavior of adding a trailing L for longs. I don't really see the value in this, and maybe it should also change with a future import statement. For bin(), I just used the py3k behavior, and didn't implement a __bin__ method. I'm also not adding a trailing L for longs. I think that makes the most sense. Eric. ___ 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] Unit Test Guide
On Fri, Feb 22, 2008 at 2:43 AM, Giampaolo Rodola' <[EMAIL PROTECTED]> wrote: > On 21 Feb, 12:30, "Virgil Dupras" <[EMAIL PROTECTED]> wrote: > > Hi devs, > > > > > > Specifically, I'd like to know about files managements in tests. Is > > every test expected to clean after itself, or is there an automatic > > cleanup mechanism in place? > > I have usually seen a lot of tests implemented like this: > > > from test.test_support import TESTFN, unlink > import unittest > > class TestCase(unittest.TestCase): > > def setUp(self): > self.file = None > > def tearDown(self): > if self.file is not None: > self.file.close() > unlink(TESTFN) > > def test_something(self): > self.file = open(TESTFN, 'r') > ... > This is a little off-topic but FWIW, bzrlib.tests.TestCase and Twisted's TestCase have a nice helper method called 'addCleanup' that adds a nullary callable to a stack of callable that get popped off and run at the start of tearDown. That would allow your example to be rewritten as: from test.test_support import TESTFN, unlink import unittest class TestCase(unittest.TestCase): def open_file(self, filename, mode): opened_file = open(filename, mode) def close_and_delete(): opened_file.close() unlink(filename) self.addCleanup(close_and_delete) return opened_file def test_something(self): file = self.open_file(TESTFN, 'r') ... This isn't any shorter, but now you can open as many files as you want. It also keeps clutter out of setUp and tearDown. jml ___ 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] Small RFEs and the Bug Tracker
On Thu, Feb 21, 2008 at 8:06 AM, Facundo Batista <[EMAIL PROTECTED]> wrote: > 2008/2/21, Gregory P. Smith <[EMAIL PROTECTED]>: > > > > > That sounds eminently sensible. So sensible there should be > > > documentation that tells us to do that. Drat it, where's Brett Cannon > > > when you need him? :-) > > > > I'm always faced with a tiny quandry when closing a fixed bug that had a > > patch to fix it attached because both seem to apply. ;-) > > Yeap, and I'm sure I ave a % of wrongly marked issues when closing, :p. > > Anyway, if a patch, and a bug, and a RFE, etc, are all "issues", IMHO > is cluttering the fact that we have two or three denominations to > "this issue was ok and we executed the proper actions to close it". > > Everything in this aspect would be simpler if we have one word for > what I just meant. Something like "handle" or "resolved". An issue is an issue and we wanting a single way to say the issue was closed because what is was about was handled seems reasonable. -Brett ___ 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] Small RFEs and the Bug Tracker
On Thu, Feb 21, 2008 at 7:50 AM, Steve Holden <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > On Wed, Feb 20, 2008 at 11:59 PM, Virgil Dupras <[EMAIL PROTECTED]> wrote: > >> On 2/21/08, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > >> > - no selection -118 > >> > wont fix189 > >> > works for me62 > >> > accepted310 > >> > fixed 611 > >> > duplicate 75 > >> > later 17 > >> > invalid 73 > >> > postponed 6 > >> > out of date 193 > >> > remind 1 > >> > rejected180 > >> > >> Thanks for running it. The rate is better than I expected, so I was > >> wrong in my assumption. > >> > >> What would be the difference between accepted and fixed for a closed > ticket? > > > > I don't know what others do, but I use accepted for a patch submission > > and fixed for a bug report. > > > That sounds eminently sensible. So sensible there should be > documentation that tells us to do that. Drat it, where's Brett Cannon > when you need him? :-) Trying to get his sprint intro talk lined up for PyCon while dealing with the stdlib reorg. =) -Brett ___ 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] r60919 - peps/trunk/pep-0008.txt
On Thu, Feb 21, 2008 at 9:15 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > On Feb 21, 2008, at 11:21 AM, skip.montanaro wrote: > > > Author: skip.montanaro > > Date: Thu Feb 21 17:21:15 2008 > > New Revision: 60919 > > > > Modified: > > peps/trunk/pep-0008.txt > > Log: > > Replace "looks ugly" with a hopefully more concrete explanation of > > why line > > wrapping is bad - it disrupts the visual structure of the code. > > > > > > Modified: peps/trunk/pep-0008.txt > > = > > = > > = > > = > > = > > = > > = > > = > > == > > --- peps/trunk/pep-0008.txt (original) > > +++ peps/trunk/pep-0008.txt Thu Feb 21 17:21:15 2008 > > @@ -77,10 +77,11 @@ > > > > There are still many devices around that are limited to 80 > > character > > lines; plus, limiting windows to 80 characters makes it possible > > to have > > -several windows side-by-side. The default wrapping on such > > devices looks > > -ugly. Therefore, please limit all lines to a maximum of 79 > > characters. > > -For flowing long blocks of text (docstrings or comments), > > limiting the > > -length to 72 characters is recommended. > > +several windows side-by-side. The default wrapping on such > > devices > > +disrupts the visual structure of the code, making it more > > difficult to > > +understand. Therefore, please limit all lines to a maximum of 79 > > +characters. For flowing long blocks of text (docstrings or > > comments), > > +limiting the length to 72 characters is recommended. > > Why should docstrings and comments be limited to 72 characters when > code is limited to 79 characters? I ask because there is an ongoing > debate at my company about this. > > Personally, I see no justification for it, and further, it's a pita to > support automatically because tools like Emacs only have one auto- > wrapping variable (fill-column). Emacs doesn't know that it should > fill comments and docstrings different than code lines, so you have to > do a bunch of manual crud to support these guidelines. > > I recommend removing the guideline of 72 characters, and just say > everything, code, comments, and docstrings should be no wider than 79 > characters. +1 from me. I know having a separate line break rule just for PEPs and such is a pain as I am having to constantly look down at the column number to know when I have run afoul of this. -Brett ___ 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] Unit Test Guide
On Thu, Feb 21, 2008 at 7:43 AM, Giampaolo Rodola' <[EMAIL PROTECTED]> wrote: > On 21 Feb, 12:30, "Virgil Dupras" <[EMAIL PROTECTED]> wrote: > > Hi devs, > > > > > > Specifically, I'd like to know about files managements in tests. Is > > every test expected to clean after itself, or is there an automatic > > cleanup mechanism in place? > > I have usually seen a lot of tests implemented like this: > > > from test.test_support import TESTFN, unlink > import unittest > > class TestCase(unittest.TestCase): > > def setUp(self): > self.file = None > > def tearDown(self): > if self.file is not None: > self.file.close() > unlink(TESTFN) > > def test_something(self): > self.file = open(TESTFN, 'r') > ... > test.test_support contains all of the various test-helping code that is not in unittest or doctest. > > > > Even more specifically, I'd like to create > > a test for the proposed patch inhttp://bugs.python.org/issue2127so I > > > need to create a subdir with non-ascii character in it, then connect > > to a db in it. So, do I need to do the cleanup in the test? Is there a > > special path I can write to that will automatically be cleaned up? > > I don't think so. > You could create a directory in setUp method by using tempfile.mkdtemp > and then remove it in tearDown. > > > > I guess I could find the answer in regrtest.py, but frankly, this unit > > is a little bit overwhelming. > > > > If there is no guide, am I the only one to think it would be a good > > idea to have one (Yeah, I could volunteer to write it)? > > Don't know whether Lib/test/readme.txt could be considered a guide but > it contains a lot of useful information for developers. A more appropriate doc is on the todo list to write. -Brett ___ 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] Small RFEs and the Bug Tracker
> This is the result for the "open" status issues? I guess not, because > the rejected, fixed, etc, should be closed. > > Could you run this again, please, but filtering by "open" tickets? Here you go - no selection -381 wont fix2 works for me0 accepted4 fixed 2 duplicate 0 later 6 invalid 0 postponed 0 out of date 1 remind 0 rejected0 As Virgil expected: it's not very meaningful, but it's what you've asked for. 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] Nosy lists on issue tracker.
Martin v. Löwis schrieb: >> What is the policy regarding nosy lists? Is it appropriate it add people >> to it besides oneself? As I cannot assign items, I'm sometimes tempted >> to add someone relevant to the list. (ie Should I add Georg to >> documentation related issues?) > > I would find it appropriate. In theory, there should be auto-assignment, > but that isn't really implemented, and I don't know whether Georg would > want to be auto-assigned Documentation or Sphinx issues. If there was auto-assignment, I'd opt in for those groups :) Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] Small RFEs and the Bug Tracker
> Everything in this aspect would be simpler if we have one word for > what I just meant. If you think it should be fixed, please submit a report in the meta tracker, ideally specifying precisely how you want to see it changed. It's possible to "retire" objects in Roundup: certain resolution values would still be present and referenced by issues that use it, but they would not appear anymore in the drop-down list. 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] Small RFEs and the Bug Tracker
> What would be the difference between accepted and fixed for a closed ticket? As Guido says: a bug gets fixed, a patch gets accepted. This was copied over from SF, but it makes sense to me and everybody seems to be following it. 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] [Python-checkins] r60919 - peps/trunk/pep-0008.txt
Barry Warsaw wrote: > Why should docstrings and comments be limited to 72 characters when > code is limited to 79 characters? I ask because there is an ongoing > debate at my company about this. I'm not sure if this is the main reason, but when using pydoc to view docstrings, the 72 character width allows for the added indent in class and method sections. Ron ___ 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] r60919 - peps/trunk/pep-0008.txt
On Thu, Feb 21, 2008 at 9:15 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > Why should docstrings and comments be limited to 72 characters when > code is limited to 79 characters? I ask because there is an ongoing > debate at my company about this. People in your company have too much time on their hands. :-) > Personally, I see no justification for it, and further, it's a pita to > support automatically because tools like Emacs only have one auto- > wrapping variable (fill-column). Emacs doesn't know that it should > fill comments and docstrings different than code lines, so you have to > do a bunch of manual crud to support these guidelines. > > I recommend removing the guideline of 72 characters, and just say > everything, code, comments, and docstrings should be no wider than 79 > characters. I'm fine with getting rid of this, but since that originally comes from me, here's my justification. Somehow my Emacs usually defaults to 72 for its fill column. That means that when I reflow text in a block comment or docstring, it'll use this limit. OTOH I don't use anything to automatically fold long code lines: when they start wrapping I manually decide on the best place to break it (and my windows are typically 80 chars wide so I can have several side by side(*)). However there are occasions where I manually format docstrings or comments, and then I will again use 79 as the limit. (*) When is Emacs going to fix the bug where it decides to fold a line that's exactly as wide as the window? This 79 business is really silly, and had to impose on people using other editors. -- --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] [Python-checkins] r60919 - peps/trunk/pep-0008.txt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 21, 2008, at 11:21 AM, skip.montanaro wrote: > Author: skip.montanaro > Date: Thu Feb 21 17:21:15 2008 > New Revision: 60919 > > Modified: > peps/trunk/pep-0008.txt > Log: > Replace "looks ugly" with a hopefully more concrete explanation of > why line > wrapping is bad - it disrupts the visual structure of the code. > > > Modified: peps/trunk/pep-0008.txt > = > = > = > = > = > = > = > = > == > --- peps/trunk/pep-0008.txt (original) > +++ peps/trunk/pep-0008.txt Thu Feb 21 17:21:15 2008 > @@ -77,10 +77,11 @@ > > There are still many devices around that are limited to 80 > character > lines; plus, limiting windows to 80 characters makes it possible > to have > -several windows side-by-side. The default wrapping on such > devices looks > -ugly. Therefore, please limit all lines to a maximum of 79 > characters. > -For flowing long blocks of text (docstrings or comments), > limiting the > -length to 72 characters is recommended. > +several windows side-by-side. The default wrapping on such > devices > +disrupts the visual structure of the code, making it more > difficult to > +understand. Therefore, please limit all lines to a maximum of 79 > +characters. For flowing long blocks of text (docstrings or > comments), > +limiting the length to 72 characters is recommended. Why should docstrings and comments be limited to 72 characters when code is limited to 79 characters? I ask because there is an ongoing debate at my company about this. Personally, I see no justification for it, and further, it's a pita to support automatically because tools like Emacs only have one auto- wrapping variable (fill-column). Emacs doesn't know that it should fill comments and docstrings different than code lines, so you have to do a bunch of manual crud to support these guidelines. I recommend removing the guideline of 72 characters, and just say everything, code, comments, and docstrings should be no wider than 79 characters. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR72xlXEjvBPtnXfVAQKEdAP/f1xnvn6jw04yyhSZfqA6HdgnYnpnYPAl S4ixszL8phg6KRq8CD2ceskY8TocDg+GG6c//M+jihRRzXMXHW/1Lfp/6syqAd1d vkWaUffaSK4rReMiEG0EmFZmYwaJA660RU0YBnv1d1Idpexj4Y/kIgfgou9OkWDY iJO+efk93Xc= =qYfT -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] Unit Test Guide
Guido van Rossum wrote: >> I don't think so. >> You could create a directory in setUp method by using tempfile.mkdtemp >> and then remove it in tearDown. > > Specifically, clean it up with shutil.rmtree() And make sure you have closed all files before you rmtree() the directory. Otherwise the unit test *will* fail on Windows. Christian ___ 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] Unit Test Guide
On 2/21/08, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Virgil Dupras wrote: > > On 2/21/08, Virgil Dupras <[EMAIL PROTECTED]> wrote: > >> Hi devs, > >> > >> Being a python dev newbie, I look in http://www.python.org/dev/ for > >> some guide to write unit tests in python and I can't find any. > >> Specifically, I'd like to know about files managements in tests. Is > >> every test expected to clean after itself, or is there an automatic > >> cleanup mechanism in place? Even more specifically, I'd like to create > >> a test for the proposed patch in http://bugs.python.org/issue2127 so I > >> need to create a subdir with non-ascii character in it, then connect > >> to a db in it. So, do I need to do the cleanup in the test? Is there a > >> special path I can write to that will automatically be cleaned up? If > >> not, wouldn't it be a good idea to have one? > > > The tempfile module provides some useful tools for making individual > files that clean themselves up, but individual tests are currently > pretty much left to fend for themselves as far as cleaning up temporary > directories. This can be done using the setUp/tearDown methods of the > test case (as Giampaolo described), or more directly using context > managers (that latter is obviously only common in tests added for 2.6/3.0) > > Something to consider would be to relocate the temp_dir() context > manager from test_cmd_line_script [1] to test.test_support and use that. > That context manager should be able to clean up for you no matter what > you put in the temporary directory. The major downside of that approach > is that test_support would end up depending on yet more modules being > available for import (shutil and tempfile in this case), which isn't > hugely desirable for test infrastructure). A way around that may be to > guard the imports and define a dummy context manager that raises > TestSkipped if either import fails. > > (If you do come up with a patch to relocate temp_dir(), put it up as a > separate tracker item and add me to the nosy list for it) What do you people think about this issue I just opened? http://bugs.python.org/issue2156 ___ 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] Small RFEs and the Bug Tracker
2008/2/21, Gregory P. Smith <[EMAIL PROTECTED]>: > > That sounds eminently sensible. So sensible there should be > > documentation that tells us to do that. Drat it, where's Brett Cannon > > when you need him? :-) > > I'm always faced with a tiny quandry when closing a fixed bug that had a > patch to fix it attached because both seem to apply. ;-) Yeap, and I'm sure I ave a % of wrongly marked issues when closing, :p. Anyway, if a patch, and a bug, and a RFE, etc, are all "issues", IMHO is cluttering the fact that we have two or three denominations to "this issue was ok and we executed the proper actions to close it". Everything in this aspect would be simpler if we have one word for what I just meant. 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] Small RFEs and the Bug Tracker
On 2/21/08, Steve Holden <[EMAIL PROTECTED]> wrote: > > Guido van Rossum wrote: > > On Wed, Feb 20, 2008 at 11:59 PM, Virgil Dupras <[EMAIL PROTECTED]> > wrote: > > >> What would be the difference between accepted and fixed for a closed > ticket? > > > > I don't know what others do, but I use accepted for a patch submission > > and fixed for a bug report. > > > > That sounds eminently sensible. So sensible there should be > documentation that tells us to do that. Drat it, where's Brett Cannon > when you need him? :-) I'm always faced with a tiny quandry when closing a fixed bug that had a patch to fix it attached because both seem to apply. ;-) ___ 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] Small RFEs and the Bug Tracker
2008/2/21, Virgil Dupras <[EMAIL PROTECTED]>: > I don't see why would want to run this query on open tickets. What > would it tell you? How many old issue there is? You can already know > that with a simple search. The goal of this script is to know the > resolution of tickets that had a 6+ month gap in their activity. In the context of what to do with RFEs (my original question), if keep them in the tracker, or removing them from there and putting them in the PEP, I want to see this distribution in the actually opened tickets (as they're disturbed or not by the RFEs). 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] Unit Test Guide
Virgil Dupras wrote: > On 2/21/08, Virgil Dupras <[EMAIL PROTECTED]> wrote: >> Hi devs, >> >> Being a python dev newbie, I look in http://www.python.org/dev/ for >> some guide to write unit tests in python and I can't find any. >> Specifically, I'd like to know about files managements in tests. Is >> every test expected to clean after itself, or is there an automatic >> cleanup mechanism in place? Even more specifically, I'd like to create >> a test for the proposed patch in http://bugs.python.org/issue2127 so I >> need to create a subdir with non-ascii character in it, then connect >> to a db in it. So, do I need to do the cleanup in the test? Is there a >> special path I can write to that will automatically be cleaned up? If >> not, wouldn't it be a good idea to have one? The tempfile module provides some useful tools for making individual files that clean themselves up, but individual tests are currently pretty much left to fend for themselves as far as cleaning up temporary directories. This can be done using the setUp/tearDown methods of the test case (as Giampaolo described), or more directly using context managers (that latter is obviously only common in tests added for 2.6/3.0) Something to consider would be to relocate the temp_dir() context manager from test_cmd_line_script [1] to test.test_support and use that. That context manager should be able to clean up for you no matter what you put in the temporary directory. The major downside of that approach is that test_support would end up depending on yet more modules being available for import (shutil and tempfile in this case), which isn't hugely desirable for test infrastructure). A way around that may be to guard the imports and define a dummy context manager that raises TestSkipped if either import fails. (If you do come up with a patch to relocate temp_dir(), put it up as a separate tracker item and add me to the nosy list for it) > Oops, nevermind I ended up finding it at > http://docs.python.org/lib/module-test.html and > http://docs.python.org/lib/module-test.testsupport.html. I didn't > expect to find it in the Python documentation itself. Sorry. Might I > suggest adding a link to it in http://www.python.org/dev/? Sounds like a good idea to me too. Cheers, Nick. [1] http://svn.python.org/projects/python/trunk/Lib/test/test_cmd_line_script.py -- 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] Small RFEs and the Bug Tracker
On 2/21/08, Facundo Batista <[EMAIL PROTECTED]> wrote: > This is the result for the "open" status issues? I guess not, because > the rejected, fixed, etc, should be closed. > > Could you run this again, please, but filtering by "open" tickets? I don't see why would want to run this query on open tickets. What would it tell you? How many old issue there is? You can already know that with a simple search. The goal of this script is to know the resolution of tickets that had a 6+ month gap in their activity. Virgil ___ 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] Small RFEs and the Bug Tracker
Guido van Rossum wrote: > On Wed, Feb 20, 2008 at 11:59 PM, Virgil Dupras <[EMAIL PROTECTED]> wrote: >> On 2/21/08, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> > - no selection -118 >> > wont fix189 >> > works for me62 >> > accepted310 >> > fixed 611 >> > duplicate 75 >> > later 17 >> > invalid 73 >> > postponed 6 >> > out of date 193 >> > remind 1 >> > rejected180 >> >> Thanks for running it. The rate is better than I expected, so I was >> wrong in my assumption. >> >> What would be the difference between accepted and fixed for a closed ticket? > > I don't know what others do, but I use accepted for a patch submission > and fixed for a bug report. > That sounds eminently sensible. So sensible there should be documentation that tells us to do that. Drat it, where's Brett Cannon when you need him? :-) regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.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] Small RFEs and the Bug Tracker
2008/2/20, "Martin v. Löwis" <[EMAIL PROTECTED]>: > - no selection -118 > wont fix189 > works for me62 > accepted310 > fixed 611 > duplicate 75 > later 17 > invalid 73 > postponed 6 > out of date 193 > remind 1 > rejected180 This is the result for the "open" status issues? I guess not, because the rejected, fixed, etc, should be closed. Could you run this again, please, but filtering by "open" tickets? Thanks! -- .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] Small RFEs and the Bug Tracker
On Thu, Feb 21, 2008 at 08:59:51AM +0100, Virgil Dupras wrote: > Thanks for running it. The rate is better than I expected, so I was > wrong in my assumption. > > What would be the difference between accepted and fixed for a closed ticket? 'accepted' is probably used more for patches, while 'fixed' is more likely to be used for a bug report. --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] Unit Test Guide
On Thu, Feb 21, 2008 at 7:43 AM, Giampaolo Rodola' <[EMAIL PROTECTED]> wrote: > On 21 Feb, 12:30, "Virgil Dupras" <[EMAIL PROTECTED]> wrote: > > Hi devs, > > > > > > Specifically, I'd like to know about files managements in tests. Is > > every test expected to clean after itself, or is there an automatic > > cleanup mechanism in place? > > I have usually seen a lot of tests implemented like this: > > > from test.test_support import TESTFN, unlink > import unittest > > class TestCase(unittest.TestCase): > > def setUp(self): > self.file = None > > def tearDown(self): > if self.file is not None: > self.file.close() > unlink(TESTFN) > > def test_something(self): > self.file = open(TESTFN, 'r') > ... > > > > > Even more specifically, I'd like to create > > a test for the proposed patch inhttp://bugs.python.org/issue2127so I > > > need to create a subdir with non-ascii character in it, then connect > > to a db in it. So, do I need to do the cleanup in the test? Is there a > > special path I can write to that will automatically be cleaned up? > > I don't think so. > You could create a directory in setUp method by using tempfile.mkdtemp > and then remove it in tearDown. Specifically, clean it up with shutil.rmtree() > > I guess I could find the answer in regrtest.py, but frankly, this unit > > is a little bit overwhelming. > > > > If there is no guide, am I the only one to think it would be a good > > idea to have one (Yeah, I could volunteer to write it)? > > Don't know whether Lib/test/readme.txt could be considered a guide but > it contains a lot of useful information for developers. > > > Hope this helps a little > > > ___ > 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] Unit Test Guide
On 21 Feb, 12:30, "Virgil Dupras" <[EMAIL PROTECTED]> wrote: > Hi devs, > > Specifically, I'd like to know about files managements in tests. Is > every test expected to clean after itself, or is there an automatic > cleanup mechanism in place? I have usually seen a lot of tests implemented like this: from test.test_support import TESTFN, unlink import unittest class TestCase(unittest.TestCase): def setUp(self): self.file = None def tearDown(self): if self.file is not None: self.file.close() unlink(TESTFN) def test_something(self): self.file = open(TESTFN, 'r') ... > Even more specifically, I'd like to create > a test for the proposed patch inhttp://bugs.python.org/issue2127so I > need to create a subdir with non-ascii character in it, then connect > to a db in it. So, do I need to do the cleanup in the test? Is there a > special path I can write to that will automatically be cleaned up? I don't think so. You could create a directory in setUp method by using tempfile.mkdtemp and then remove it in tearDown. > I guess I could find the answer in regrtest.py, but frankly, this unit > is a little bit overwhelming. > > If there is no guide, am I the only one to think it would be a good > idea to have one (Yeah, I could volunteer to write it)? Don't know whether Lib/test/readme.txt could be considered a guide but it contains a lot of useful information for developers. Hope this helps a little ___ 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] Small RFEs and the Bug Tracker
On Wed, Feb 20, 2008 at 11:59 PM, Virgil Dupras <[EMAIL PROTECTED]> wrote: > On 2/21/08, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > - no selection -118 > > wont fix189 > > works for me62 > > accepted310 > > fixed 611 > > duplicate 75 > > later 17 > > invalid 73 > > postponed 6 > > out of date 193 > > remind 1 > > rejected180 > > Thanks for running it. The rate is better than I expected, so I was > wrong in my assumption. > > What would be the difference between accepted and fixed for a closed ticket? I don't know what others do, but I use accepted for a patch submission and fixed for a bug report. -- --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] Unit Test Guide
On 2/21/08, Virgil Dupras <[EMAIL PROTECTED]> wrote: > Hi devs, > > Being a python dev newbie, I look in http://www.python.org/dev/ for > some guide to write unit tests in python and I can't find any. > Specifically, I'd like to know about files managements in tests. Is > every test expected to clean after itself, or is there an automatic > cleanup mechanism in place? Even more specifically, I'd like to create > a test for the proposed patch in http://bugs.python.org/issue2127 so I > need to create a subdir with non-ascii character in it, then connect > to a db in it. So, do I need to do the cleanup in the test? Is there a > special path I can write to that will automatically be cleaned up? If > not, wouldn't it be a good idea to have one? > > I guess I could find the answer in regrtest.py, but frankly, this unit > is a little bit overwhelming. > > If there is no guide, am I the only one to think it would be a good > idea to have one (Yeah, I could volunteer to write it)? > > > Virgil > Oops, nevermind I ended up finding it at http://docs.python.org/lib/module-test.html and http://docs.python.org/lib/module-test.testsupport.html. I didn't expect to find it in the Python documentation itself. Sorry. Might I suggest adding a link to it in http://www.python.org/dev/? Virgil ___ 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] Unit Test Guide
Hi devs, Being a python dev newbie, I look in http://www.python.org/dev/ for some guide to write unit tests in python and I can't find any. Specifically, I'd like to know about files managements in tests. Is every test expected to clean after itself, or is there an automatic cleanup mechanism in place? Even more specifically, I'd like to create a test for the proposed patch in http://bugs.python.org/issue2127 so I need to create a subdir with non-ascii character in it, then connect to a db in it. So, do I need to do the cleanup in the test? Is there a special path I can write to that will automatically be cleaned up? If not, wouldn't it be a good idea to have one? I guess I could find the answer in regrtest.py, but frankly, this unit is a little bit overwhelming. If there is no guide, am I the only one to think it would be a good idea to have one (Yeah, I could volunteer to write it)? Virgil ___ 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] Small RFEs and the Bug Tracker
On 2/21/08, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > - no selection -118 > wont fix189 > works for me62 > accepted310 > fixed 611 > duplicate 75 > later 17 > invalid 73 > postponed 6 > out of date 193 > remind 1 > rejected180 Thanks for running it. The rate is better than I expected, so I was wrong in my assumption. What would be the difference between accepted and fixed for a closed ticket? Virgil ___ 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
