Re: [Zope3-Users] Re: zope.intid and UUIDs
Thanks Derek. I think perhaps there may be a better response to this on zope3-dev list. Regards, David Derek Richardson wrote: I have no principled objection to a ZPL license. And I would like the code to make it into the core, if appropriate. So, the answer is, a ZPL license is likely. David Pratt wrote: I like this idea of abstracting the code for ids myself. It will be interesting to hear what others have to say. Can you advise whether the UUID utility will be ZPL licensed since this is important if you are talking about something with generic functionality for z3. Many thanks. Regards, David Derek Richardson wrote: All, I've decided to go ahead and write an RFC 4122 UUID utility based on zope.intid (this is for a Plone SoC project, but this bit is pure Zope 3). I wrote most of it today and there is more code shared between the two than is different. The main differences are: * OOBTrees, instead of an IOBTree and an OIBTree * Different events are fired when an object is registered and unregistered (they could be merged, but this is easy backwards-compatibility) * _generateId() is, of course, different The rest is pretty much copied and pasted, even most of the tests. My question is: should the common parts be abstracted out into a framework for id utilities, of which intid and uuid will be two instantiations? I know this is a small amount of code but: * I hate copy and paste * I hate the idea of bugs in two places (implicit coupling, from a bug fixer's perspective) * Larger codebases mean more to read to understand what is going on for newbies, like me Of course, the duplication rule is "If you do it three times, you're doing it wrong" and I've only done it the second time. So, part of this question is whether anyone can see a future need for any id utilities other than intid and uuid. If so, I think this would definitely be a good move. Otherwise, I'm up in the air. Of course, this would be a change to zope core, which is the main reason I'm leery. I will be sending in my contributor agreement tomorrow. So, I'm really wondering whether this is worth changing in the core or whether we shouldn't bother. Thanks, Derek ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Add unittest
Hi Florian,
I've had some success with:
import unittest
class MyTestClass (unittest.TestCase):
def test_something (self):
...
def test_suite ():
return unittest.TestLoader().loadTestsFromTestCase(MyTestClass)
if __name__ == '__main__':
unittest.main(defaultTest='test_suite')
Florian Lindner wrote:
Hello,
I've tried to add a test to my package (I must confess it's my first test.)
I've added an directory "tests", created an empty __init__.py in it and a file
named test_proxycache.py which contains:
import unittest
from zope.testing.doctestunit import DocTestSuite
from zope.app.container.tests.test_icontainer import TestSampleContainer
from ProxyCache.proxycache import ProxyCache
class Test(TestSampleContainer):
def makeTestObject(self):
return ProxyCache()
def test_suite():
return unittest.TestSuite((
DocTestSuite("ProxyCache.proxycache"),
unittest.makeSuite(Test) ))
if __name__ == "__main__":
unittest.main(defaultTest="test_suite")
as a first step.
Now I try to run the tests:
[EMAIL PROTECTED] ~/Zope3 $ python
test.py -vpu --dir ../Desktop/zope/lib/python/ProxyCache/
Running tests at level 1
Traceback (most recent call last):
File "test.py", line 61, in ?
result = testrunner.run(defaults)
File "/home/florian/Zope3/src/zope/testing/testrunner.py", line 256, in run
failed = not run_with_options(options)
File "/home/florian/Zope3/src/zope/testing/testrunner.py", line 365, in
run_with_options
tests_by_layer_name = find_tests(options, found_suites)
File "/home/florian/Zope3/src/zope/testing/testrunner.py", line 1033, in
find_tests
for suite in found_suites:
File "/home/florian/Zope3/src/zope/testing/testrunner.py", line 1072, in
find_suites
for fpath, package in find_test_files(options):
File "/home/florian/Zope3/src/zope/testing/testrunner.py", line 1138, in
find_test_files
for f, package in find_test_files_(options):
File "/home/florian/Zope3/src/zope/testing/testrunner.py", line 1166, in
find_test_files_
for (p, package) in test_dirs(options, {}):
File "/home/florian/Zope3/src/zope/testing/testrunner.py", line 1220, in
test_dirs
p = import_name(p)
File "/home/florian/Zope3/src/zope/testing/testrunner.py", line 1236, in
import_name
__import__(name)
ValueError: Empty module name
tried also some variations but the error does not change.
What's wrong there?
Thanks,
Florian
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
--
---
Reurbanise - Urban Sustainability
ph: (03) 3528 055, mobile: 0274 992 569
http://www.reurbanise.co.nz
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: zope.intid and UUIDs
I have no principled objection to a ZPL license. And I would like the code to make it into the core, if appropriate. So, the answer is, a ZPL license is likely. David Pratt wrote: I like this idea of abstracting the code for ids myself. It will be interesting to hear what others have to say. Can you advise whether the UUID utility will be ZPL licensed since this is important if you are talking about something with generic functionality for z3. Many thanks. Regards, David Derek Richardson wrote: All, I've decided to go ahead and write an RFC 4122 UUID utility based on zope.intid (this is for a Plone SoC project, but this bit is pure Zope 3). I wrote most of it today and there is more code shared between the two than is different. The main differences are: * OOBTrees, instead of an IOBTree and an OIBTree * Different events are fired when an object is registered and unregistered (they could be merged, but this is easy backwards-compatibility) * _generateId() is, of course, different The rest is pretty much copied and pasted, even most of the tests. My question is: should the common parts be abstracted out into a framework for id utilities, of which intid and uuid will be two instantiations? I know this is a small amount of code but: * I hate copy and paste * I hate the idea of bugs in two places (implicit coupling, from a bug fixer's perspective) * Larger codebases mean more to read to understand what is going on for newbies, like me Of course, the duplication rule is "If you do it three times, you're doing it wrong" and I've only done it the second time. So, part of this question is whether anyone can see a future need for any id utilities other than intid and uuid. If so, I think this would definitely be a good move. Otherwise, I'm up in the air. Of course, this would be a change to zope core, which is the main reason I'm leery. I will be sending in my contributor agreement tomorrow. So, I'm really wondering whether this is worth changing in the core or whether we shouldn't bother. Thanks, Derek ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] zope.intid and UUIDs
I like this idea of abstracting the code for ids myself. It will be interesting to hear what others have to say. Can you advise whether the UUID utility will be ZPL licensed since this is important if you are talking about something with generic functionality for z3. Many thanks. Regards, David Derek Richardson wrote: All, I've decided to go ahead and write an RFC 4122 UUID utility based on zope.intid (this is for a Plone SoC project, but this bit is pure Zope 3). I wrote most of it today and there is more code shared between the two than is different. The main differences are: * OOBTrees, instead of an IOBTree and an OIBTree * Different events are fired when an object is registered and unregistered (they could be merged, but this is easy backwards-compatibility) * _generateId() is, of course, different The rest is pretty much copied and pasted, even most of the tests. My question is: should the common parts be abstracted out into a framework for id utilities, of which intid and uuid will be two instantiations? I know this is a small amount of code but: * I hate copy and paste * I hate the idea of bugs in two places (implicit coupling, from a bug fixer's perspective) * Larger codebases mean more to read to understand what is going on for newbies, like me Of course, the duplication rule is "If you do it three times, you're doing it wrong" and I've only done it the second time. So, part of this question is whether anyone can see a future need for any id utilities other than intid and uuid. If so, I think this would definitely be a good move. Otherwise, I'm up in the air. Of course, this would be a change to zope core, which is the main reason I'm leery. I will be sending in my contributor agreement tomorrow. So, I'm really wondering whether this is worth changing in the core or whether we shouldn't bother. Thanks, Derek ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] zope.intid and UUIDs
All, I've decided to go ahead and write an RFC 4122 UUID utility based on zope.intid (this is for a Plone SoC project, but this bit is pure Zope 3). I wrote most of it today and there is more code shared between the two than is different. The main differences are: * OOBTrees, instead of an IOBTree and an OIBTree * Different events are fired when an object is registered and unregistered (they could be merged, but this is easy backwards-compatibility) * _generateId() is, of course, different The rest is pretty much copied and pasted, even most of the tests. My question is: should the common parts be abstracted out into a framework for id utilities, of which intid and uuid will be two instantiations? I know this is a small amount of code but: * I hate copy and paste * I hate the idea of bugs in two places (implicit coupling, from a bug fixer's perspective) * Larger codebases mean more to read to understand what is going on for newbies, like me Of course, the duplication rule is "If you do it three times, you're doing it wrong" and I've only done it the second time. So, part of this question is whether anyone can see a future need for any id utilities other than intid and uuid. If so, I think this would definitely be a good move. Otherwise, I'm up in the air. Of course, this would be a change to zope core, which is the main reason I'm leery. I will be sending in my contributor agreement tomorrow. So, I'm really wondering whether this is worth changing in the core or whether we shouldn't bother. Thanks, Derek ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Add unittest
Hello,
I've tried to add a test to my package (I must confess it's my first test.)
I've added an directory "tests", created an empty __init__.py in it and a file
named test_proxycache.py which contains:
import unittest
from zope.testing.doctestunit import DocTestSuite
from zope.app.container.tests.test_icontainer import TestSampleContainer
from ProxyCache.proxycache import ProxyCache
class Test(TestSampleContainer):
def makeTestObject(self):
return ProxyCache()
def test_suite():
return unittest.TestSuite((
DocTestSuite("ProxyCache.proxycache"),
unittest.makeSuite(Test) ))
if __name__ == "__main__":
unittest.main(defaultTest="test_suite")
as a first step.
Now I try to run the tests:
[EMAIL PROTECTED] ~/Zope3 $ python
test.py -vpu --dir ../Desktop/zope/lib/python/ProxyCache/
Running tests at level 1
Traceback (most recent call last):
File "test.py", line 61, in ?
result = testrunner.run(defaults)
File "/home/florian/Zope3/src/zope/testing/testrunner.py", line 256, in run
failed = not run_with_options(options)
File "/home/florian/Zope3/src/zope/testing/testrunner.py", line 365, in
run_with_options
tests_by_layer_name = find_tests(options, found_suites)
File "/home/florian/Zope3/src/zope/testing/testrunner.py", line 1033, in
find_tests
for suite in found_suites:
File "/home/florian/Zope3/src/zope/testing/testrunner.py", line 1072, in
find_suites
for fpath, package in find_test_files(options):
File "/home/florian/Zope3/src/zope/testing/testrunner.py", line 1138, in
find_test_files
for f, package in find_test_files_(options):
File "/home/florian/Zope3/src/zope/testing/testrunner.py", line 1166, in
find_test_files_
for (p, package) in test_dirs(options, {}):
File "/home/florian/Zope3/src/zope/testing/testrunner.py", line 1220, in
test_dirs
p = import_name(p)
File "/home/florian/Zope3/src/zope/testing/testrunner.py", line 1236, in
import_name
__import__(name)
ValueError: Empty module name
tried also some variations but the error does not change.
What's wrong there?
Thanks,
Florian
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] How i can get IRequest
Hi, On Tue, Apr 17, 2007 at 08:55:02PM +0400, Garanin Michael wrote: > Hello! > How i can get IRequest in my event handler (i has only context)? from zope.security.management import getInteraction request = getInteraction().participations[0] Regards, Frank ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] How i can get IRequest
Hello! How i can get IRequest in my event handler (i has only context)? Thanks! ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
