Re: [Zope-dev] Python3 and attribute annotations.
On Mon, Mar 9, 2009 at 23:35, Dan Korostelev nad...@gmail.com wrote:
def hello(who:'name') - None:
... print('Hello, {0}!'.format(who))
...
hello.__annotations__
{'who': 'name', 'return': None}
Yup. So, it's stored on the function, not the class. Hence, it will not collide.
Might be confusing though.
--
Lennart Regebro: Pythonista, Barista, Notsotrista.
http://regebro.wordpress.com/
+33 661 58 14 64
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Question: additional context for IAnnotations adapter?
Dan Korostelev wrote: 2009/3/9 Dieter Maurer die...@handshake.de: Jacob Holm wrote at 2009-3-6 01:55 +0100: ... I added it while working for ZC two years ago. It was needed to support a use case where the context used for looking up the annotation was not necessarily the current site. I don't know if the use case is still relevant to ZC, but the pattern is still being used in e.g. zc.notification and zope.app.preference (where it was added by me at the time). I expect that use cases like this (looking up objects in a foreign site context) will be important for my current employer (if it continuous to use Zope in the future). Thanks for comments. The functionality stayed and migrated to zope.principalannotation. It now even have a doctest. :-) It's interesting, this use case sound pretty close to what I'm talking about in the very last part of this message: http://mail.zope.org/pipermail/zope-dev/2009-March/035220.html ie: adapter context based on object traversal rather than notion of current site. Can someone confirm to me whether or not manually specifying the context as I have in the example above would work, or would I need to do: adapter1 = getAdapter(a,ISomething,context=siteA) adapter2 = getAdapter(b,ISomething,context=siteB) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.site
2009/3/13 Christian Theune c...@gocept.com: On Thu, 2009-03-12 at 22:00 +0300, Dan Korostelev wrote: Please, can someone review the current zope.site's trunk? It fails the persistent_interfaces tests. I didn't ever work with persistent code, so I don't have idea about what's going on. But I'd like to make a release of this package. For me this t est works but the following tests fail: zope.site.tests.test_folder zope.site.tests.test_localsitemanager zope.site.tests.test_registration zope.site.tests.test_site That's strange. Are you sure that you're testing with latest versions of other packages? -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Question: additional context for IAnnotations adapter?
Chris Withers wrote: [snip] It's interesting, this use case sound pretty close to what I'm talking about in the very last part of this message: http://mail.zope.org/pipermail/zope-dev/2009-March/035220.html ie: adapter context based on object traversal rather than notion of current site. Not quite, since this was about principal annotations and principals cannot be found by object traversal. It was specifically about letting the adapter know the context, not about finding a different adapter based on context. Can someone confirm to me whether or not manually specifying the context as I have in the example above would work, or would I need to do: adapter1 = getAdapter(a,ISomething,context=siteA) adapter2 = getAdapter(b,ISomething,context=siteB) In general, using context=a should give the same result as context=siteA. In the particular case of principalannotations, this would not help. There the adapter is the same globally, but needs to know the context so it can find the proper utility to use. To make it work you'd need to register a different adapter for each utility. This is certainly doable, but probably not worth the effort. Hope this helps Jacob ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.app.security refactoring results
Hey there! The refactoring of zope.app.security is now generally done. In the process, three new packages has been created: * zope.authentication - the most interesting and small. It contains the IAuthentication contract, as well as IUnauthenticatedPrincipal/IAuthenticatedGroup and company. Beyond that, it also contains several utilities related to principal lookup - the PrincipalLookupError and PrincipalSource/PrincipalTerms. * zope.principalregistry - it's an implementation of IAuthentication that's based on global non-persistent registry object. It provides zcml-based principal creation. Yes, it's the global principal registry from zope.app.security. * zope.localpermission - the implementation of persistent/local permission class that can be added and used per-site. It's a bit of (possibly deprecated) TTW development. I created another thread about possibility of death of local permisions, so may be this package will be named zope.app.localpermission and forgotten forever. :) Also, two other packages were touched: * zope.security - here migrated some bits of zope.app.security - the NoProxy definition for zope.i18nmessageid.Messages, the permission vocabularies, zcml definitions of some common permissions, like zope.View. * zope.publisher - here migrated the adapter from IPrincipal to ILoggingInfo and the adapters from zope.publisher's HTTP/FTP requests to ILoginPassword. May be they will be moved again, when we'll be doing zope.publisher's refactorings. One nice feature provided as a result of refactoring is possiblity of the authentication system to be used without of zope.publisher. The zope.app.authentication and z3c.authenticator probably can be modified/refactored not to depend on zope.publisher as well, but it will be another task. The original zope.app.security now only contains browser views and BBB imports. Other packages still need to be adapted to new imports, but I'd like to do that after releasing refactored packages. I already adapted zope.securitypolicy and zope.app.authentication though. It's a big win for zope.securitypolicy that it doesn't pull the whole zope anymore. Please, check it out and say your opinion. I'd like new packages to be released ASAP. :-) -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Python3 and attribute annotations.
On Fri, Mar 13, 2009 at 08:10, Dan Korostelev nad...@gmail.com wrote: As I said before, even if python itself won't add __annotations__ to some callable objects, this thing may be done by third-party tools. Ah, I have would expected that to go on __call__ but you are right, that probably doens't make any sense, they should be on the object in that case. In any case, __whatever__ is nowadays wrong, and we might want to think about moving to something else. I personally don't like _z_whatever, but _whatever_ is to similar to __whatever__ and __whatever also has implications, and _whatever isn't magic enough, so unless we can think of something better... :) The it's the question if we want to start moving before going over to Python 3 or after. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 6 OK
Summary of messages to the zope-tests list. Period Thu Mar 12 12:00:00 2009 UTC to Fri Mar 13 12:00:00 2009 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Thu Mar 12 21:28:53 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011259.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Thu Mar 12 21:30:55 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011260.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Thu Mar 12 21:32:59 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011261.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Thu Mar 12 21:34:59 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011262.html Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Thu Mar 12 21:36:59 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011263.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Thu Mar 12 21:39:00 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011264.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.app.security refactoring results
2009/3/13 Dan Korostelev nad...@gmail.com: The refactoring of zope.app.security is now generally done. In the process, three new packages has been created: [snip] Please, check it out and say your opinion. I'd like new packages to be released ASAP. :-) BTW, now when we have a steering group, I'd like my changes to be approved by them :) -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.app.security refactoring results
On Friday 13 March 2009, Dan Korostelev wrote: 2009/3/13 Dan Korostelev nad...@gmail.com: The refactoring of zope.app.security is now generally done. In the process, three new packages has been created: [snip] Please, check it out and say your opinion. I'd like new packages to be released ASAP. :-) BTW, now when we have a steering group, I'd like my changes to be approved by them :) You can assume I approve unless I send you a message. :-) Keep sending the summary E-mails as they are a good redux as well. Thanks for all your work! Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Dependencies for ZCML
Tres Seaver wrote at 2009-3-11 21:27 -0400: ... In packages that don't load their own ZCML during the tests, it's harder to say. One reaction could be that this package doesn't have enough tests then! Of course another would argue that this is configuration information only that can be overridden, but it is rather special configuration... - -1 on having configuration dependecies, including having mandatory tests that ZCML will load: mandatory configuration is a contradiction in terms. I therefore don't believe that tests which try to load ZCML are useful, at least for library pacakges (as opposed to applications). I do not agree with you here. *IF* a package contains ZCML files (e.g. in order to facilitate a standard integration into a larger Zope 3 system), then these ZCML files should of course be tested -- even when there are conceivable package uses that do not use the ZCML files. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Dependencies for ZCML
Tres Seaver wrote at 2009-3-12 14:25 -0400: ... Sorry, I meant mandatory tests which load ZCML. I'm actually against ever loading ZCML in tests at all. If you ship ZCML, you should test it, no? You will not ship ZCML, but this may not apply to everybody -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Dependencies for ZCML
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dieter Maurer wrote: Tres Seaver wrote at 2009-3-12 14:25 -0400: ... Sorry, I meant mandatory tests which load ZCML. I'm actually against ever loading ZCML in tests at all. If you ship ZCML, you should test it, no? Not necessarily: in fact, if testing it means that users of my package have to accept a big dogpile of dependencies that they otherwise wouldn't need to, then no. I can easily imagine shipping ZCML in the form I outline below in a package which itself doesn't depend on zope.configuration at all, for instance. You will not ship ZCML, but this may not apply to everybody I likely won't ship ZCML inside a reusable library (as opposed to a deployable application): if I do, it will probably be not a convenience that I make everybody include (not my definition of convenience, anyway) but an example which I expect they can either include or *copy and change*. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJusAW+gerLs4ltQ4RAv0wAKCJg83M2fgdaunXS9b8PZysJDHLrgCg0MHQ 6+VxRild3DMB5y8PYJ7RK1s= =a3Ax -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Dependencies for ZCML
Tres Seaver wrote at 2009-3-13 16:20 -0400: ... Dieter Maurer wrote: Tres Seaver wrote at 2009-3-12 14:25 -0400: ... Sorry, I meant mandatory tests which load ZCML. I'm actually against ever loading ZCML in tests at all. If you ship ZCML, you should test it, no? Not necessarily: in fact, if testing it means that users of my package have to accept a big dogpile of dependencies that they otherwise wouldn't need to, then no. Your and my quality principles diverge: If I release a package, then its tests have the verify that the package contents work correctly. This implies: the tests should cover everything the package delivers including delivered ZCML files and optional features. The tests are my tool (as developper of the package) to help me find and fix errors before the release. I am completely uninterested to facilitate testing of reduced or otherwise special use of my packages. If the full tests pass then a reduced use should work as well (provided the integrator did everything right). If the user is interested to verify for his own that the tests pass, I expect of him to test the full functionality -- or not use the package at all. To stress it: the above just describes test requirements -- not install requirements. I am ready to support loose install requirements (and use extras to support optional features) but I am not ready to invest in loose test requirements. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Death of local/persistent permissions (zope.app.security refactoring)
2009/3/13 Dan Korostelev nad...@gmail.com: 2009/3/11 Martijn Faassen faas...@startifact.com: - Move LocalPermission into new zope.localpermission package. I personally didn't ever need local permissions. You're talking about locally defined permissions, correct, not about giving someone a permission locally? I'm talking about local persistent permissions that can be added to ZODB and registered per site. It's zope.securitypolicy that gives local permissions, so, LocalPermission has nothing to do with local grants. Right, that's what I thought. Agreed they should go off into a package on its own, probably to eventually die. :) (I have bad memories of struggling with this stuff in a sprint in 2003). Thinking now. If we want local persistent permissions to be considered dead and we want to discourage their usage, may be the package should be called zope.app.localpermission then? If so, we could also move its ZMI views there and forget about that package. :) It's just because zope.localpermission name sounds like some nice part of zope framework, but in reality, the functionality provided by the package is deprecated for use withing _the framework_. But, do we really want it deprecated and dead? May be there's some nice use cases for it? Anyone? Martijn, Stephan, anyone? This question is the only thing that stops me from releasing refactored packages. Personally, I quite like the idea of naming it zope.app.localpermission, merging it with its views (possibly as an optional dependency) and forgetting about it. But it's just because I didn't ever need and probably won't ever need local permissions, so it's one of some old and deprecated patterns to me. So, if noone will object/reply soon, I'll rename the package and finally release the refactorings. -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Death of local/persistent permissions (zope.app.security refactoring)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dan Korostelev wrote: 2009/3/13 Dan Korostelev nad...@gmail.com: 2009/3/11 Martijn Faassen faas...@startifact.com: - Move LocalPermission into new zope.localpermission package. I personally didn't ever need local permissions. You're talking about locally defined permissions, correct, not about giving someone a permission locally? I'm talking about local persistent permissions that can be added to ZODB and registered per site. It's zope.securitypolicy that gives local permissions, so, LocalPermission has nothing to do with local grants. Right, that's what I thought. Agreed they should go off into a package on its own, probably to eventually die. :) (I have bad memories of struggling with this stuff in a sprint in 2003). Thinking now. If we want local persistent permissions to be considered dead and we want to discourage their usage, may be the package should be called zope.app.localpermission then? If so, we could also move its ZMI views there and forget about that package. :) It's just because zope.localpermission name sounds like some nice part of zope framework, but in reality, the functionality provided by the package is deprecated for use withing _the framework_. But, do we really want it deprecated and dead? May be there's some nice use cases for it? Anyone? Martijn, Stephan, anyone? This question is the only thing that stops me from releasing refactored packages. Personally, I quite like the idea of naming it zope.app.localpermission, merging it with its views (possibly as an optional dependency) and forgetting about it. But it's just because I didn't ever need and probably won't ever need local permissions, so it's one of some old and deprecated patterns to me. So, if noone will object/reply soon, I'll rename the package and finally release the refactorings. Silence is assent. ;) Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJut/S+gerLs4ltQ4RApSOAKCYmmDeS5NUzLrofSYiKqIo9aVt5QCgup58 IOl27I6zo+dIaRecPbKX8qQ= =kE0K -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Dependencies for ZCML
Dieter Maurer wrote: Tres Seaver wrote at 2009-3-13 16:20 -0400: ... Dieter Maurer wrote: Tres Seaver wrote at 2009-3-12 14:25 -0400: ... Sorry, I meant mandatory tests which load ZCML. I'm actually against ever loading ZCML in tests at all. If you ship ZCML, you should test it, no? Not necessarily: in fact, if testing it means that users of my package have to accept a big dogpile of dependencies that they otherwise wouldn't need to, then no. Your and my quality principles diverge: If I release a package, then its tests have the verify that the package contents work correctly. This implies: the tests should cover everything the package delivers including delivered ZCML files and optional features. The tests are my tool (as developper of the package) to help me find and fix errors before the release. I am completely uninterested to facilitate testing of reduced or otherwise special use of my packages. If the full tests pass then a reduced use should work as well (provided the integrator did everything right). If the user is interested to verify for his own that the tests pass, I expect of him to test the full functionality -- or not use the package at all. To stress it: the above just describes test requirements -- not install requirements. I am ready to support loose install requirements (and use extras to support optional features) but I am not ready to invest in loose test requirements. As a frequent recipient of Tres' wrath when things go untested, I can vouch that Tres is definitely interested in comprehensive test coverage. ;-) I think the point is that some ZCML he ships might be example ZCML which he has previously tested interactively. Like, say, a configuration snippet within a README.txt. I think maybe the lesson here is: think very carefully before you release a package with any ZCML in it that you want to be a library; if users *need* to load the ZCML, it's probably really not a library, it's probably an application. If you're OK with it being an application, then by all means, you should have automated end-to-end tests. But if you really mean it to be a library, the ZCML should be advisory (close to documentation), I don't see a problem with not doing any automated testing of it if that means the package doesn't have inappropriate dependencies. - C ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
