Re: [Python-Dev] Py3k DeprecationWarning in stdlib
Brett Cannon wrote: > On Wed, Jun 25, 2008 at 6:08 AM, Andrew Bennetts [...] > > > > Should I file a bug for this? > > > > If you want, but Benjamin plans to undocument this for users along > with all other test.support stuff (which I agree with). Most of the > APIs in test.support were just quickly written and have not > necessarily been thought through in order to make sure that the APIs > makes sense (like in this case). Ok, then we're back to there being no supported way to write tests that need to intercept warnings. Twisted has already suffered from this (JP reports that Twisted's assertWarns is broken in 2.6), and I doubt it's alone. So I guess I am filing a bug after all... :) -Andrew. ___ 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] C API for gc.enable() and gc.disable()
On Thu, Jun 26, 2008 at 12:01 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> I would it be possible, if not a good idea, to only track object >> deallocations as the GC traversal trigger? As far as I know, dangling >> cyclic references cannot be formed when allocating objects. > > Not sure what you mean by that. > > x = [] > x.append(x) > del x > > creates a cycle with no deallocation occurring. > Oh... never mind then. -- Alexandre ___ 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] C API for gc.enable() and gc.disable()
> I would it be possible, if not a good idea, to only track object > deallocations as the GC traversal trigger? As far as I know, dangling > cyclic references cannot be formed when allocating objects. Not sure what you mean by that. x = [] x.append(x) del x creates a cycle with no deallocation occurring. 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] Disable tests in unittest (issue3202)
On Wed, Jun 25, 2008 at 7:52 PM, Facundo Batista <[EMAIL PROTECTED]> wrote: > > What about TestSkipped? I thought that raising > test_support.TestSkipped should behave like this: you're saying that > you're actually NOT executing the tests, but you say that they are > there. I think he's talking about outside core Python development (putting it into unittest). -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ 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] Disable tests in unittest (issue3202)
2008/6/25 Justin Mazzola Paluska <[EMAIL PROTECTED]>: > The idea behind the patch is that it's sometimes useful to disable > tests without removing them from the TestCase. For example, a > co-worker and I have a module with a few tests that will fail for the > forseeable future because we haven't had a chance to implement the > features the tests are testing. The tracebacks for these "not > implemented yet" tests obscure real failures in other tests. What about TestSkipped? I thought that raising test_support.TestSkipped should behave like this: you're saying that you're actually NOT executing the tests, but you say that they are there. But a few days ago I needed to comment out a test that previously was raising this, because it made a buildbot to go red. How this should behave? 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] Disable tests in unittest (issue3202)
On Thu, Jun 26, 2008 at 7:13 AM, Justin Mazzola Paluska <[EMAIL PROTECTED]>
wrote:
> Hi,
>
...
> The idea behind the patch is that it's sometimes useful to disable
> tests without removing them from the TestCase. For example, a
> co-worker and I have a module with a few tests that will fail for the
> forseeable future because we haven't had a chance to implement the
> features the tests are testing. The tracebacks for these "not
> implemented yet" tests obscure real failures in other tests.
...
> The patch in issue3202 implements the decorator @disabled and a few
> modifications to the classes in the unittest module.
>
> What does the Python hivemind think? I'm also open to enhancing it if
> the list has any ideas.
I think it's really worth looking at the approach that bzrlib's tests
take here (see bzrlib.tests.ExtendedTestResult and the
out-of-date-but-helpful http://bazaar-vcs.org/BzrExtendTestSuite)
Instead of disabling the tests, their practice is to run the tests but
have them raise KnownFailure. When they write a test that they know
will fail, they have it raise this exception. The extended TestResult
object catches this exception in addFailure and reports it
appropriately.[1]
So, when there's a test that is expected to fail, they do something like this:
def test_foo(self):
x = get_some_value()
self.expectFailure('get_some_value is bogus', self.assertEqual, x, 42)
Using KnownFailure is better than disabling because you'll be able to
tell if the test suddenly and mysteriously passes.
I can see that disabling still has some value, but I'd rather have
KnownFailure first.
jml
[1] They use a similar strategy for skipping tests based on platform.
(You can't test Bazaar's symlink support on Windows, for example).
___
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] Disable tests in unittest (issue3202)
Hi, I just reported issue3202 in the bugracker (http://bugs.python.org/issue3202) with a patch that implements a way to disable unittest.TestCases using a decorator. Benjamin Peterson suggested that I bring up the issue on python-dev. The idea behind the patch is that it’s sometimes useful to disable tests without removing them from the TestCase. For example, a co-worker and I have a module with a few tests that will fail for the forseeable future because we haven’t had a chance to implement the features the tests are testing. The tracebacks for these “not implemented yet” tests obscure real failures in other tests. Normally, we’d just rename the failing methods from something starting with “test” to something like “_test”, so unittest ignores them. However, doing so removes all traces of the tests when you re-run the test suite, so the disabled tests are easy to forget. Instead, issue3202 allows you to write something like: from unittest import main, TestCase, disabled class SampleTest(TestCase): def test_addition(self): self.assertEqual(2, 1+1) def test_broken(self): # this is a real failure in our code self.assertEqual(5, 2+2) @disabled def test_not_implemented(self): # Test of a feature not implemented yet. doit() if __name__ == '__main__': main() which has one test disabled. Running the test suite outputs %python sample_tests2.py .FD == FAIL: test_broken (__main__.SampleTest) -- Traceback (most recent call last): File "sample_tests2.py", line 12, in test_broken self.assertEqual(5, 2+2) AssertionError: 5 != 4 -- Ran 3 tests in 0.001s FAILED (failures=1) showing only the real failure and a simple “D” for the disabled test. The disabled test is still there, but doesn’t get in your way. JUnit4 has a similar decorator for its tests, @Ignore. The patch in issue3202 implements the decorator @disabled and a few modifications to the classes in the unittest module. What does the Python hivemind think? I’m also open to enhancing it if the list has any ideas. —Justin ___ 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] C API for gc.enable() and gc.disable()
On Wed, Jun 25, 2008 at 4:55 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > I think exactly the other way 'round. The timing of thing should not > matter at all, only the exact sequence of allocations and deallocations. I would it be possible, if not a good idea, to only track object deallocations as the GC traversal trigger? As far as I know, dangling cyclic references cannot be formed when allocating objects. So, this could potentially mitigate the quadratic behavior during allocation bursts. -- Alexandre ___ 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] Undocumenting test.support in 3.x (was Py3k DeprecationWarning in stdlib)
On Wed, Jun 25, 2008 at 4:00 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > I'm a little worried about making stuff undocumented that every core > developer needs to use -- everyone writing tests needs to continue to > use test_support (now test.support?). I imagine people writing unit > test suites for 3rd party libraries might want to use its services > too. I think undocumented is a little unspecific here. What I mean is "reserved for core Python tests and no promise is made to retain compatibility." Of course, we would keep docs for them (perhaps in Lib/test/README), so new core developers could write their tests. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ 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] C API for gc.enable() and gc.disable()
> I took the statement, "Current GC only takes into account container > objects, which, most significantly, ignores string objects (of which > most applications create plenty)" to mean that strings were ignored for > deciding when to do garbage collection. I mistakenly thought that was > because they were assumed to be small. It sounds like they're ignored > because they're automatically collected and so they SHOULD be ignored > for object garbage collection. More precisely, a string object can never participate in a cycle (it can be referenced from a cycle, but not be *in* the cycle, as it has no references to other objects). GC in Python is only about container objects (which potentially can be cyclic); non-container objects are released when the refcount says they are no longer referenced. Whether or not allocation of definitely-non-cyclic objects should still trigger cyclic GC (in the hope that some objects hang on a garbage cycle) is a question that is open to debate; I'd prefer an analysis of existing applications before making decisions. 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] Undocumenting test.support in 3.x (was Py3k DeprecationWarning in stdlib)
On Wed, Jun 25, 2008 at 2:00 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > I'm a little worried about making stuff undocumented that every core > developer needs to use -- everyone writing tests needs to continue to > use test_support Right, but I would think all core developers know about test.support and are capable of reading the code and docstring. > (now test.support?). In 3.0, yes. > I imagine people writing unit > test suites for 3rd party libraries might want to use its services > too. > > In general I'm not a big fan of having undocumented APIs; 9 out of 10 > times someone finds a genuine use case for such an API, and then > you're worse off than if it was documented to begin with, since if > people start using undocumented APIs, they necessarily > reverse-engineer how it works, and then you can never change it. If it > was documented, at least you may be able to get away with modifying > the undocumented parts, assuming people actually read the docs. > (Though we've had cases where the docs and implementation were > inconsistent for years, and eventually we ended up fixing the docs...) > My worry is that the module has had stuff tossed in ad-hoc in such a way that maintaining the code for public consumption is a pain. If we took the time to clean up the APIs then I would be fine with documenting the module. -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] C API for gc.enable() and gc.disable()
On Wed, Jun 25, 2008 at 4:55 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > It seems to me that the root problem is allocation spikes of legitimate, > > useful data. Perhaps then we need some sort of "test" to determine if > > those are legitimate. Perhaps checking every nth (with n decreasing as > > allocation bytes increases) object allocated during a "spike" could be > > useful. Then delay garbage collection until x consecutive objects are > > found to be garbage? > > > > It seems like we should be attacking the root cause rather than finding > > some convoluted math that attempts to work for all scenarios. > > I think exactly the other way 'round. The timing of thing should not > matter at all, only the exact sequence of allocations and deallocations. > > I trust provable maths much more than I trust ad-hoc heuristics, even > if you think the math is convoluted. > I probably chose my wording poorly (particularly for a newcomer/outsider). What I meant was that the numbers used in GC currently appear arbitrary. The idea of three "groups" (youngest, oldest and middle) is also arbitrary. Would it not be better to tear that system apart and create a "sliding" scale. If the timing method is undesirable then make it slide based on the allocation/deallocation difference. In this way, the current breakpoints and number of groups (all of which are arbitrary and fixed) could be replaced by one coefficient (and yes, I recognize that it would also be arbitrary but it would be one, tweakable number rather than several). My gut tells me that your current fix is going to work just fine for now but we're going to end up tweaking it (or at least discussing tweaking it) every 6-12 months. > > On a side note, the information about not GCing on string objects is > > interesting? Is there a way to override this behavior? > > I think you misunderstand. Python releases unused string objects just > fine, and automatically. It doesn't even need GC for that. > I took the statement, "Current GC only takes into account container objects, which, most significantly, ignores string objects (of which most applications create plenty)" to mean that strings were ignored for deciding when to do garbage collection. I mistakenly thought that was because they were assumed to be small. It sounds like they're ignored because they're automatically collected and so they SHOULD be ignored for object garbage collection. Thanks for the clarification... Back to the drawing board on my other problem ;) -- Haikus are easy Most make very little sense Refrigerator ___ 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] Undocumenting test.support in 3.x (was Py3k DeprecationWarning in stdlib)
I'm a little worried about making stuff undocumented that every core developer needs to use -- everyone writing tests needs to continue to use test_support (now test.support?). I imagine people writing unit test suites for 3rd party libraries might want to use its services too. In general I'm not a big fan of having undocumented APIs; 9 out of 10 times someone finds a genuine use case for such an API, and then you're worse off than if it was documented to begin with, since if people start using undocumented APIs, they necessarily reverse-engineer how it works, and then you can never change it. If it was documented, at least you may be able to get away with modifying the undocumented parts, assuming people actually read the docs. (Though we've had cases where the docs and implementation were inconsistent for years, and eventually we ended up fixing the docs...) --Guido On Wed, Jun 25, 2008 at 1:00 PM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > On Wed, Jun 25, 2008 at 12:18 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: >> If you want, but Benjamin plans to undocument this for users along >> with all other test.support stuff (which I agree with). Most of the >> APIs in test.support were just quickly written and have not >> necessarily been thought through in order to make sure that the APIs >> makes sense (like in this case). > > Thanks for bringing that up, Brett. Is making test_support non-public > a API in 3.0 fine with everybody? > > > -- > Cheers, > Benjamin Peterson > "There's no place like 127.0.0.1." > ___ > 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] C API for gc.enable() and gc.disable()
> It seems to me that the root problem is allocation spikes of legitimate, > useful data. Perhaps then we need some sort of "test" to determine if > those are legitimate. Perhaps checking every nth (with n decreasing as > allocation bytes increases) object allocated during a "spike" could be > useful. Then delay garbage collection until x consecutive objects are > found to be garbage? > > It seems like we should be attacking the root cause rather than finding > some convoluted math that attempts to work for all scenarios. I think exactly the other way 'round. The timing of thing should not matter at all, only the exact sequence of allocations and deallocations. I trust provable maths much more than I trust ad-hoc heuristics, even if you think the math is convoluted. > On a side note, the information about not GCing on string objects is > interesting? Is there a way to override this behavior? I think you misunderstand. Python releases unused string objects just fine, and automatically. It doesn't even need GC for that. 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] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
[Adding back the list.] On Tue, Jun 24, 2008 at 9:53 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >> While I think it's fine to have some function that reveals the binary >> representation of floats, I don't think that overlaying this on >> hex/oct/bin is worth the problems it causes. > > What problems? The patch is clean. Problems like no two people on python-dev agreeing on how exactly the feature should be implemented. Problems like whether this goes way beyond the philosophical underpinnings of bin/oct/hex. Problems like what to do about other types that might want to overload hex/oct/bin. See Kevin Jacobs' response. >> This API appears to be >> purely for educational purposes; why not implement something in pure >> Python using the struct module that reveals the lay-out of the >> floating-point value? > > This is not the internal floating point layout. It is the real value > expressed in exponential form. It is more than educational -- it is a > platform independent representation (look at Terry's reference -- it is the > usual way to precisely specify a float value and it does not depend on > atof() or vice versa). Possibly, but it is only readable by a Python expression parser. For all practical purposes "%.17g" % x works just as well. And this bypasses the question "why overload this functionality on bin/hex/oct rather than adding e.g. a new function to math or a new method to float." >> (There are also several things wrong with the specific patch, apart >> from its lack of docs; #1 is the introduction of an externaly visible >> symbol that doesn't start with _Py.) > > Will change the global symbol to _Py. I already added docs to the patch. > Did you see the one that was uploaded a few hours ago (float6.diff)? I don't care about the details of the patch until we have agreement about which form the feature should take. We don't have that agreement yet. I mentioned the flaws in the patch to point out that it was apparently a rush job. > I re-opened the discussion at your behest. [...] I'm very glad you're giving the discussion a second chance. Please give it a few days at least. My expectation is that the outcome will be not to overload bin/hex/oct but to add a custom function to math or a custom method to float, whose output can be further massaged to create the platform-independent representation you're after. (I doubt that it's worth changing pickle or marshal though, they are doing fine with their respective current approaches.) -- --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] doctest, exec and __module__
Fred Drake wrote: On Jun 25, 2008, at 2:45 PM, Martijn Faassen wrote: This places new key/value pairs into a dictionary, in this case test.globs. Unfortunately when the execution results in a class definition, it'll have its __module__ attribute set to '__builtin__'. Try as I might, I couldn't convince exec to do it any differently. The zope.testing package has a way to work around this from setup/teardown functions passed to the DocFileSuite (or whatever wrapper you're using). See the module zope.testing.module for the functions. Thanks, I should've checked that! Essentially, the __name__ needs to be set in test.globs; class construction uses the global value for __name__ to provide __module__; doctests normally don't have one, so it acquires the value from __builtin__.__name__ instead. Which is, of course, horribly wrong. Okay, so is this mystery mechanism that I was missing. Sorry to bother people here on the list. Regards, Martijn ___ 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] Last "bug weekend"
Hi all! In Python Argentina we get together in two places, Buenos Aires and Santa Fe, and worked out around 10-12 bugs, which is around the half of the total for both days, so I'm very happy, :) We even had a Python logo shaped cake, see, see [1]. Did you participate? What do you think it's the outcome for both days? Regards, [1] http://www.taniquetil.com.ar/facundo/imgs/tortalogopy.jpeg -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Undocumenting test.support in 3.x (was Py3k DeprecationWarning in stdlib)
On Wed, Jun 25, 2008 at 12:18 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > If you want, but Benjamin plans to undocument this for users along > with all other test.support stuff (which I agree with). Most of the > APIs in test.support were just quickly written and have not > necessarily been thought through in order to make sure that the APIs > makes sense (like in this case). Thanks for bringing that up, Brett. Is making test_support non-public a API in 3.0 fine with everybody? -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ 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] C API for gc.enable() and gc.disable()
It seems to me that the root problem is allocation spikes of legitimate, useful data. Perhaps then we need some sort of "test" to determine if those are legitimate. Perhaps checking every nth (with n decreasing as allocation bytes increases) object allocated during a "spike" could be useful. Then delay garbage collection until x consecutive objects are found to be garbage? It seems like we should be attacking the root cause rather than finding some convoluted math that attempts to work for all scenarios. On a side note, the information about not GCing on string objects is interesting? Is there a way to override this behavior? I've found that re.py chokes on large text files (4MB plus) without line ends (don't ask, they're not our files but we have to parse them). I wonder if this isn't the reason... If the answer to that is, "no, strings are always ignored" I'd recommend rethinking this (or providing an option to override somehow. -- Haikus are easy Most make very little sense Refrigerator ___ 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] doctest, exec and __module__
On Jun 25, 2008, at 2:45 PM, Martijn Faassen wrote: This places new key/value pairs into a dictionary, in this case test.globs. Unfortunately when the execution results in a class definition, it'll have its __module__ attribute set to '__builtin__'. Try as I might, I couldn't convince exec to do it any differently. The zope.testing package has a way to work around this from setup/ teardown functions passed to the DocFileSuite (or whatever wrapper you're using). See the module zope.testing.module for the functions. Essentially, the __name__ needs to be set in test.globs; class construction uses the global value for __name__ to provide __module__; doctests normally don't have one, so it acquires the value from __builtin__.__name__ instead. Which is, of course, horribly wrong. The solution in zope.testing.module allows the class to be used with pickle within the test as well. -Fred -- Fred Drake ___ 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] doctest, exec and __module__
Hi there, I've just witnessed an interesting consequence of the way doctest works. I ran into an issue when doctesting an aspect of SQLAlchemy, where the following guard clause tripped me up: # In the normal call flow, a request for any of the 3 basic collection # types is transformed into one of our trivial subclasses # (e.g. InstrumentedList). Catch anything else that sneaks in here... if cls.__module__ == '__builtin__': raise sa_exc.ArgumentError( "Can not instrument a built-in type. Use a " "subclass, even a trivial one.") My class, coming in as cls here, was defined in a doctest, like this: >>> class Foo(object): ...pass It turns out that doctest compiles and executes this bit of code using a line like this: # Don't blink! This is where the user's code gets run. exec compile(example.source, filename, "single", compileflags, 1) in test.globs This places new key/value pairs into a dictionary, in this case test.globs. Unfortunately when the execution results in a class definition, it'll have its __module__ attribute set to '__builtin__'. Try as I might, I couldn't convince exec to do it any differently. I can't think of an nice way to work around this problem either. The ugly workaround in the doctest itself works: >>> Foo.__module__ = 'whatever' That isn't very nice though. You could also iterate through all the values in the dictionary after each exec, and then check whether it's a class, and if so, set its __module__ to something else than __builtin__, but that doesn't feel very pretty (or efficient) either. Any ideas? Am I missing something? Is there really no way to control this behavior with exec? I'd like to somehow fix doctest.py so it doesn't set the __module__ to '__builtin__' for everything. '__main__' would be nicer, as that's what the interpreter shell does, and a doctest example already looks like the interpreter shell. While the above SQLAlchemy code is hardly pretty, I can't think of any better way to put in a safeguard like that either. Regards, Martijn ___ 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] Py3k DeprecationWarning in stdlib
On Wed, Jun 25, 2008 at 6:08 AM, Andrew Bennetts <[EMAIL PROTECTED]> wrote: > Nick Coghlan wrote: > [...] >> >> I forgot this had already been added to the Python regression test >> machinery, so it will just be a matter of updating the relevant tests to >> use it: > > That's a nice surprise! I'm glad the standard library is growing facilities > like this. > > I think it could be improved a little, though: > >> http://docs.python.org/dev/library/test.html#module-test.test_support >> >> test.test_support.catch_warning(record=True)¶ >> >> Return a context manager that guards the warnings filter from being >> permanently changed and records the data of the last warning that has >> been issued. The record argument specifies whether any raised warnings >> are captured by the object returned by warnings.catch_warning() or >> allowed to propagate as normal. > > The description doesn't really make the record=False case clear. This context > manager is doing two different jobs: 1) restore the filters list and > showwarning > function to their original state when done, and 2) optionally (if record=True) > record the last warning in the "as" target. That feels a bit weird. > The 'record=False' functionality was only added a couple of months ago. The context manager was originally written to help test the warnings module itself, so it was not meant to allow warnings to propagate. I tossed in the 'record' argument so that I could mutate the warnings filter. > I think a clearer way to provide that functionality would be with two separate > context managers: one that copies and finally restores the filters list and > showwarnning function called protect_warnings_module, and then catch_warnings > to > record the warnings. The catch_warnings context manager could reuse the > protect_warnings_module one. "with protect_warnings_module:" seems easier to > understand (and document) than "with catch_warning(record=False)". > > Should I file a bug for this? > If you want, but Benjamin plans to undocument this for users along with all other test.support stuff (which I agree with). Most of the APIs in test.support were just quickly written and have not necessarily been thought through in order to make sure that the APIs makes sense (like in this case). -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] Py3k DeprecationWarning in stdlib
Nick Coghlan wrote:
[...]
>
> I forgot this had already been added to the Python regression test
> machinery, so it will just be a matter of updating the relevant tests to
> use it:
That's a nice surprise! I'm glad the standard library is growing facilities
like this.
I think it could be improved a little, though:
> http://docs.python.org/dev/library/test.html#module-test.test_support
>
> test.test_support.catch_warning(record=True)¶
>
> Return a context manager that guards the warnings filter from being
> permanently changed and records the data of the last warning that has
> been issued. The record argument specifies whether any raised warnings
> are captured by the object returned by warnings.catch_warning() or
> allowed to propagate as normal.
The description doesn't really make the record=False case clear. This context
manager is doing two different jobs: 1) restore the filters list and showwarning
function to their original state when done, and 2) optionally (if record=True)
record the last warning in the "as" target. That feels a bit weird.
I think a clearer way to provide that functionality would be with two separate
context managers: one that copies and finally restores the filters list and
showwarnning function called protect_warnings_module, and then catch_warnings to
record the warnings. The catch_warnings context manager could reuse the
protect_warnings_module one. "with protect_warnings_module:" seems easier to
understand (and document) than "with catch_warning(record=False)".
Should I file a bug for this?
> The context manager is typically used like this:
>
> with catch_warning() as w:
> warnings.warn("foo")
> assert str(w.message) == "foo"
>
Maybe this is a YAGNI, but what if an expression triggers multiple warnings?
Perhaps the WarningMessage object ought to keep a list rather than just the last
warning.
Another thought: if the warnings module had a public, documented way to
manipulate the filter list (e.g. warnings.get_all_filters() and
warnings.set_all_filters(...)), then people could build these sorts of test
facilities for themselves if the test_support one turns out to be too limiting
or otherwise a poor fit.
-Andrew.
___
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] Py3k DeprecationWarning in stdlib
Jean-Paul Calderone wrote:
On Tue, 24 Jun 2008 23:03:33 -, [EMAIL PROTECTED] wrote:
It's also nice to have this facility in the test harness itself, so
that you don't run the additional risk of accidentally (and silently)
leaving warning suppression in place for subsequent tests.
It would be *extra* nice to have this facility added to the standard
library, since assertWarns in Twisted is broken by changes in Python
2.6 (ie, our tests for warnings all fail with [EMAIL PROTECTED]). For now,
we will probably address this by switching to a different warning
API. In the long term, it'd be better for us, other Python developers,
and the standard library if there were an API in the standard library
which facilitated testing of warnings.
I forgot this had already been added to the Python regression test
machinery, so it will just be a matter of updating the relevant tests to
use it:
http://docs.python.org/dev/library/test.html#module-test.test_support
test.test_support.catch_warning(record=True)¶
Return a context manager that guards the warnings filter from being
permanently changed and records the data of the last warning that has
been issued. The record argument specifies whether any raised warnings
are captured by the object returned by warnings.catch_warning() or
allowed to propagate as normal.
The context manager is typically used like this:
with catch_warning() as w:
warnings.warn("foo")
assert str(w.message) == "foo"
New in version 2.6.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
