Re: [Python-Dev] [Python-checkins] Python Regression Test Failures basics (1)
On 5/9/06, Thomas Heller <[EMAIL PROTECTED]> wrote: Thomas Wouters wrote:> On 5/8/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:>>> test_ctypes>> test test_ctypes failed -- Traceback (most recent call last): >> File "/home/neal/python/trunk/Lib/ctypes/test/test_python_api.py", line>> 41, in test_PyInt_Long>> self.failUnlessEqual(grc(42), ref42)>> AssertionError: 336 != 337 We've been seeing this error for a while now, and given the test, it isn't> entirely surprising. The test tries to do what regrtest -R:: also does:> check for refcount leakage. I'm not entirely sure why it's failing as I > can't reproduce it (although it could be because 42's refcount is actually> 42 :) but it does seem to me that this kind of refleak-checking is somewhat> redundant in the Python testsuite, and it is obvious to me that the > breakage> is precisely because it's being run in the Python testsuite (which is a lot> less reliable an environment than ctypes' own, standalone testsuite.)I'm not sure I understand this analysis - how can the refcount be 42 and then, a little bit later, be 366 or 337?Eh, yes, obviously, it can't, and I wasn't paying enough attention. I guess something else is getting a reference to 42 somewhere, which'd have to be in the unittest internals. And since those can change at any time, there's no way to run the test reliably unless there are no external calls between the two getrefcount calls. > Thomas, given the refcount-leakage-coverage the ctypes tests are getting in > the Python distribution, do you want to keep running these tests? Is> there a> way to not run them in the Python testsuite, but still keep them for the> standalone tests? (If you want that, that is.) Yes there is.I'd suggest doing that, then.> Alternatively, we could try > to fix the test. If the problem is indeed what I think it is (42's refcount> being 42 or 41 or 43 at the first grc() call there; I'm not sure) we could> perhaps work around it, using something like: Hm, an easier way would be to use an integer other than 42 which cannot be itsown refcount, say, a negative value, or a much larger value like 12345678.I don't think that'll work, because they aren't interned. The refcount of the constant 12345678 and of the result of pythonapi.PyInt_FromLong(12345678) will be unrelated.-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] rest2latex - pydoc writer - tables
[EMAIL PROTECTED] wrote:
> On Fri, 28 Apr 2006, Thomas Heller wrote:
>
>> I must work on the docs themselves, so I currently have only two things:
>>
>> - the table in the ctypes tutorial has a totally different look than the
>> other
>> tables in the docs. Compare
>> http://docs.python.org/dev/lib/ctypes-simple-data-types.html
>> with
>> http://docs.python.org/dev/lib/module-struct.html
>
> could you try docutils.sf.net sandbox pydoc-writer checkout
> (svn or the snapshot or tomorrow
> http://docutils.sourceforge.net/sandbox/pydoc-writer/mkpydoc.py)
The table looks perfect now - thanks!
>> - feature request: it would be very nice if it were possible to generate
>> links
>> into the index for functions and types from the rest sources.
>
> into the index means what ? into the module index ?
Into the library index. I assume that requires definitions contained in
\begin{funcdesc}...\end{funcdesc} blocks (or datadesc, methoddesc, and so on).
Thomas
___
Python-Dev mailing list
[email protected]
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] Python Regression Test Failures basics (1)
Thomas Wouters wrote: > On 5/9/06, Thomas Heller <[EMAIL PROTECTED]> wrote: >> >> Thomas Wouters wrote: >> > On 5/8/06, Neal Norwitz <[EMAIL PROTECTED]> wrote: >> > >> >> test_ctypes >> >> test test_ctypes failed -- Traceback (most recent call last): >> >> File "/home/neal/python/trunk/Lib/ctypes/test/test_python_api.py", >> line >> >> 41, in test_PyInt_Long >> >> self.failUnlessEqual(grc(42), ref42) >> >> AssertionError: 336 != 337 >> >> >> Thomas, given the refcount-leakage-coverage the ctypes tests are getting >> in >> > the Python distribution, do you want to keep running these tests? Is >> > there a >> > way to not run them in the Python testsuite, but still keep them for >> the >> > standalone tests? (If you want that, that is.) >> >> Yes there is. > > > I'd suggest doing that, then. This is done, now. And thanks for the analysis. Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
Unfortunately, I have no time to read all the details on this interesting thread (I wish), but I also have an alternative path implementation, feel free to scavenge anything from it you might find useful. I put it here: http://furius.ca/pubcode/pub/conf/common/lib/python/ipath.py.html I think it is similar in spirit to what you proposed, a path being treated as a tuple, without the separators. This only makes sense. Using this class solved some really annoying problems while working on a project where I developed on my Linux laptop and released on the client's Windows machines. (I wish I could contribute in a more participatory way, but I'm really really swamped.) Anyway, +1 for a path encapsulation that is not a string, and that abstracts case-sensitiveness and path separators automatically. cheers, On 5/7/06, Noam Raphael <[EMAIL PROTECTED]> wrote: > Hello all again! > > Thanks to Mike's suggestion, I now opened a new wiki page, > AlternativePathDiscussion, in > http://wiki.python.org/moin/AlternativePathDiscussion > > The idea is to organize the discussion by dividing it into multiple > sections, and seeing what is agreed and what should be further > discussed. I now wrote there what I think, and quoted a few opinions > from other posts. The posts by others are only a minority - what's > written there currently is mostly what I think. I'm sorry for the > inconvinience, but please go there and post your opinions (you can > copy and paste from your emails, of course). > > I apologize first for not replying to each post, and second for only > writing my opinions in the wiki. I simply write pretty slowly in > English, and am already developing a growing sleep-hours deficit. I > hope you forgive me. > > Have a good day, > Noam > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/blais%40furius.ca > -- Martin Blais Furius Python Training -- http://furius.ca/training/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] possible use of __decorates__ in functools.decorator
Turns out I didn't need to use the __decorates__ attribute to get the name of the class. I posted on clp (what I should've done in the first place) and got an answer back pretty quickly. After a duh!, hitting my forehead and a couple "of couse" comments, it was as simple as saving the original caller via a sys._getframe(2) call in the decorator factory. Sorry for the noise. -- Luis P Caamano Atlanta, GA USA ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
