[Zope3-dev] zope3 bug day?
Hi there! is there a zope3 bug day planned soon? there are a couple of bugs that I'd like to fix but I don't want to do it now in the midst of the release process. regards /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Google SoC Project
whit wrote: Adam Groszer wrote: I personally am tired of restarting z3 each time I made an error even if it is just one char mistype. I'm doing now a wx based app, and the problem is the same... made an error, restart, click 10 times... It would be also a way to have a developer version which might run slower. amen... In the plone community, we have several influential developers who don't use z3 tech I suspect because developing with pythonscript is *still faster* than writing views and adapters because one doesn't have to reload to see minor code changes. also, in z2 land, refreshing a product loses all the related z3 registrations. being able to dynamically reload without restart would be a huge fricking win. I guess we need to make this a priority for the next release. Python simply does not support a general robust reload, other than restart. I think that there are 2 ways we can make progress in this area: - Speed up restart. I think there are a lot of ways that restarts can be made faster: o Optimizae what we're doing now. I suspect that there are some opportunuties here. o Load less. A Zope 3 application that only loads what it actually uses will load much more quickly than a full Zope 3 checkout. The Zope 3 checkout has as much as it does to provide a way to test a range of applications when we modify Zope 3. We need to have a better way of solving this problem without such a bloated checkout configuration. Also, we need to make progress with packaging, to make it easier for people to get just the components they need. I wanted to switch to eggs for the 3.3 release, but, sadly, there wasn't enough time. I think switching to package-based distributions and installation should be a top priority for 3.4. Finally, there's a lot of interest in generating configuration actions in Python, rather than ZCML. I suspect that avoiding XML processing, conversion, and validation might speed startup quite a bit. - Look at opprtunities for limited robust reload. Perhaps we could define reloadable modules, especially for defining adapters, with restrictions on their definitions and exports in a way that allows robust reload. This would probably be based on the persistent-module experiments. This is a fair bit of deep work though and I'm not sure who has the interest and ability to make it happen. I'm really not interested in a reload faclity, like the one commonly used in Zope 2, that is not robust. I've wasted too many hours helping people debug problems that were caused by reload misshaps. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3.3.0 beta 1 released!
Andreas Jung wrote: Python 2.5 is not officially released and not offically not supported and not recommended for Zope 3. So stick with the supported versions. Even more so because the RestrictedPython implementation that Zope 3 uses (a small part of) hasn't been updated to work with 2.5. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Google SoC Project
Jim Fulton wrote: - Look at opprtunities for limited robust reload. Perhaps we could define reloadable modules, especially for defining adapters, with restrictions on their definitions and exports in a way that allows robust reload. This would probably be based on the persistent-module experiments. This is a fair bit of deep work though and I'm not sure who has the interest and ability to make it happen. I'm really not interested in a reload faclity, like the one commonly used in Zope 2, that is not robust. I've wasted too many hours helping people debug problems that were caused by reload misshaps. out of curiosity, what are the things that make a reload not robust ? is it just a matter of dependencies or it's deeper ? Tarek ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3.3.0 beta 1 released!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 But the README.txt says Zope 3 requires that Python 2.4.1 or newer be installed. so Python 2.5 should be possible when it is released. Egon Benji York schrieb am 09.05.2006 13:26: Andreas Jung wrote: Python 2.5 is not officially released and not offically not supported and not recommended for Zope 3. So stick with the supported versions. Even more so because the RestrictedPython implementation that Zope 3 uses (a small part of) hasn't been updated to work with 2.5. - -- Egon Frerich, Freudenbergstr. 16, 28213 Bremen E-Mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (MingW32) Comment: GnuPT 2.7.2 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEYIJCuTzybIiyjvURAvapAJ9lamYe/i+uC96bWM6tkdU2EtGwsgCgu6Sb uQf0/QLlhwfstsM0O0Zua+U= =4k5s -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Google SoC Project
On 5/9/06, Jim Fulton [EMAIL PROTECTED] wrote: - Speed up restart. I think there are a lot of ways that restarts can be made faster: [...] o Load less. A Zope 3 application that only loads what it actually uses will load much more quickly than a full Zope 3 checkout. Just a brainstormy idea: One thing I like with Python imports which ZCML doesn't do, is that it only loads things that really are imported. Maybe there could be a way to say which products you depend on in ZCML, and only load the ZCML of these? Kinda like a zcml-import, but not creating problems if you import it twice? -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3.3.0 beta 1 released!
On 5/9/06, Egon Frerich [EMAIL PROTECTED] wrote: Zope 3 requires that Python 2.4.1 or newer be installed. so Python 2.5 should be possible when it is released. Future compatibility is impossible. Any such statement must be seen as Python 2.4.1, or later barring unexpected problems which we don't know of because we can't bloody well see into the future, can we? :-) Besides, in this case it means 2.4.1 or later version of 2.4, which maybe should be made explicit. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Google SoC Project
On Tuesday 09 May 2006 07:22, Jim Fulton wrote: I guess we need to make this a priority for the next release. Python simply does not support a general robust reload, other than restart. I think that there are 2 ways we can make progress in this area: - Speed up restart. I think there are a lot of ways that restarts can be made faster: o Optimizae what we're doing now. I suspect that there are some opportunuties here. I have applied for the SoC with a proposal to enhance ZCML. My proposal is attached. It discusses some of the optimization options we talked of before. If accepted I would work on this and the result would be, naturally, in the next Zope 3 and 2 release. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training == Enhancing ZCML == Name: Stephan Richter E-Mail: [EMAIL PROTECTED] IRC Nickname: srichter How much time do you expect to have for this project? Please list jobs, summer classes, and/or vacations that you'll need to work around: I am a Ph.D. student and do take any classes anymore. I am going to teach the first summer session Physics 11 (Calculus-based mechanics) and continue my thesis. Overall I think 3-4 weeks of time during the summer are a realistic estimate. Development experience: - 9 years of Python experience. - 6 years of Zope experience. - Zope 3 core developer and release manager. Please describe your usage experience/familiarity with the project you are applying for: I am a Zope 3 core developer. I am planning to implement new features in Zope 3 that will make it easier to develop highly-customizable content management systems, like Plone, using Zope 3. What school do you attend? How many years have you attended there? What is your specialty/major at the school? Tufts University, Somerville, MA. Ph.D. in Physics, started in 2002. I am developing models to simulate the immune system repsonse upon SIV/HIV infections. Project Details: Project Outline --- Zope 3 uses a component architecture as one of its most basic building blocks. Since Zope 3 is a Web Application server, it must be possible to run multiple Web sites on one application instance. The consequence is that Zope must be configurable on a site by site basis. Thus an extension of the component architecture allows us to define components globally (for all sites) and locally (site specific). Global components are commonly configured using an XML-based configuration language called ZCML. Currently, local components can only be created and configured via the Web UI. The advantage of doing so is that local components can store their state in the ZODB. But this also means that it is very difficult and cumbersome to register local components using regular filesystem-based code. Clearly, this functionality is sub-optimal. Oftentimes you want to be able to define site-specific (local) components from the filesystem. This is particularly true for presentation code, where it is often not a requirement that the state must be stored in the ZODB. I propose to allow local components to be configurable through ZCML. This goal became feasible with the recent component architecture refactorings by Jim Fulton. Any site (local or global) can now have a set of base sites that are used to provide additional components. I want to allow ZCML to specify any number of base sites and add components to it. Here is an example of how I imagine it to look like (ZCML):: site name=my-base-site / configure use-site=my-base-site ... /configure The new ``site`` directive creates a new site. The ``configure`` directive will grow an ``use-site`` attribute that specifies the site to put in the components. By default, ``use-site`` will use the global site. This also ensures full backward-compatibility. There will be a new registry of all ZCML-defined sites. All existing ZCML directives have to be reviewed and it must be ensured that they are multi-site aware. The tricky part of the implementation will be to hook in those sites as bases to local sites. It must be ensured that the ZODB can load having filesystem-based sub-sites, error handling must be carefully considered and an UI must be written. I believe that this feature is essential for highly customizable applications liek Plone. It will allow skinning of sites using filesystem-based development, something several people in the Plone community have strived for for a long time. I think once the community starts to discover the implications of this development, many new possibilities will open. Another big problem in Zope 3 is the startup time. Some code profiling has determined that most of the time in the startup process is lost in parsing, converting and validating ZCML directives with their
[Zope3-dev] reloading (was Google SoC Project)
I'm really not interested in a reload faclity, like the one commonly used in Zope 2, that is not robust. I've wasted too many hours helping people debug problems that were caused by reload misshaps. understood. perhaps intelligently disabling such facilities in Zope 2 might be wise since they are essentially broken right now (with products using z3 components). re:limited reloading: +1. I think the big win for reloading is iterating over code changes that effect UI directly. in that vein, having limited reload support for view components (or other similar ui elements) would be a boon to acceptance and a real aid to devel speed in the land of a million tiny cuts that is user interface development. -w ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Google SoC Project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: whit wrote: Adam Groszer wrote: I personally am tired of restarting z3 each time I made an error even if it is just one char mistype. I'm doing now a wx based app, and the problem is the same... made an error, restart, click 10 times... It would be also a way to have a developer version which might run slower. amen... In the plone community, we have several influential developers who don't use z3 tech I suspect because developing with pythonscript is *still faster* than writing views and adapters because one doesn't have to reload to see minor code changes. also, in z2 land, refreshing a product loses all the related z3 registrations. being able to dynamically reload without restart would be a huge fricking win. I guess we need to make this a priority for the next release. Python simply does not support a general robust reload, other than restart. I think that there are 2 ways we can make progress in this area: - Speed up restart. I think there are a lot of ways that restarts can be made faster: o Optimizae what we're doing now. I suspect that there are some opportunuties here. o Load less. A Zope 3 application that only loads what it actually uses will load much more quickly than a full Zope 3 checkout. The Zope 3 checkout has as much as it does to provide a way to test a range of applications when we modify Zope 3. We need to have a better way of solving this problem without such a bloated checkout configuration. Also, we need to make progress with packaging, to make it easier for people to get just the components they need. I wanted to switch to eggs for the 3.3 release, but, sadly, there wasn't enough time. I think switching to package-based distributions and installation should be a top priority for 3.4. Finally, there's a lot of interest in generating configuration actions in Python, rather than ZCML. I suspect that avoiding XML processing, conversion, and validation might speed startup quite a bit. If we modified the validation to defer checking things like dotted name resolution until *after* all files have been parsed, then we could make it a requirement that configuration handlers have *no* side effects; at that point, we could save a pickle of the actions list, and restart by loading the pickle instead of parsing. We would need to remember things like file name and line number for the dotted name references, so that we could report them property in the deferred check (after all actions have run). - Look at opprtunities for limited robust reload. Perhaps we could define reloadable modules, especially for defining adapters, with restrictions on their definitions and exports in a way that allows robust reload. This would probably be based on the persistent-module experiments. This is a fair bit of deep work though and I'm not sure who has the interest and ability to make it happen. I'm really not interested in a reload faclity, like the one commonly used in Zope 2, that is not robust. I've wasted too many hours helping people debug problems that were caused by reload misshaps. Amen. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEYLZ9+gerLs4ltQ4RApytAJ0fi8XBcnlt3aR5mM1L9MgdGSZ3DACgtGSj igZb17loQ69PYA8be5KR3jg= =CGBI -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Google SoC Project
Tres Seaver wrote: ... If we modified the validation to defer checking things like dotted name resolution until *after* all files have been parsed, then we could make it a requirement that configuration handlers have *no* side effects; at that point, we could save a pickle of the actions list, and restart by loading the pickle instead of parsing. We would need to remember things like file name and line number for the dotted name references, so that we could report them property in the deferred check (after all actions have run). Yup. This is a possibility I've been thinking of. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] reloading (was Google SoC Project)
whit wrote: I think the big win for reloading is iterating over code changes that effect UI directly. http://gintas.pov.lt/darcs/z3reload/README.txt -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3.3.0 beta 1 released!
baiju m wrote: On 5/9/06, Stephan Richter [EMAIL PROTECTED] wrote: Hello everyone, The Zope 3 development team is proud to announce Zope 3.3.0 beta 1. Congratulations to all worked behind this release! Congratulations from me too! I haven't been able to contribute much personally to the Zope 2 or Zope 3 releases this time around, but I hope that'll change for the next round. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
reloading modules (was Re: [Zope3-dev] Re: Google SoC Project)
Adam Groszer wrote: What about pushing the problem then to the lower level, to Python itself. I think all developers are fighting the same problem, so all Python developers would benefit from the solution. As I know (that may be wrong) not many even if any language supports that, so that would make one big plus point on the Python side also. As I don't have really deep knowledge of the Python interpreter itself, I cannot imagine how weird is the idea. Maybe we should ask Guido to have some thoughts about that. I've spent time thinking about this. Modern operating systems are surprisingly good at reloading processes, but in general, it's hard to reload pieces of a process. What's the difference? I think the difference is in the type of interdependence. Operating systems force processes to talk to each other through high level mechanisms like files, streams, sockets, memory mapped I/O, and so on. Good programmers understand that processes can die and thus make their software resilient to communication channel interruptions. Within a process, programmers have no such expectation. Once the programmer imports a module, the programmer expects the imported module to remain unchanged. There is rarely any concept that modules are actually communicating with each other. A sticky morass of inter-module pointers quickly forms, leaving little hope of reliably reloading arbitrary modules. The operating system has to intervene in order to start the process over. Shared memory makes it possible to link processes at a deeper level, but in practice, shared memory is used mostly for threading. It's no coincidence that multiple threads are generally thought of as a single process that has to restart together. Once two processes share pointers, it's hard to unbind them. So I have considered two basic approaches for reliably reloading a module: 1) Code the reloadable module as a pure communication endpoint, treating the module almost like a process. No other modules should import from the module; instead, the module should register itself with a framework and other modules should talk to the module only through that framework. This is a good approach for writing reloadable application-specific plugins. You can also support clusters of modules that represent a single plugin. The Zope 2 refresh mechanism works quite well with products written this way. Unfortunately, keeping modules free of interdependencies is difficult, and that's a major support risk. 2) Make reloadable code fundamentally different. If module X is supposed to be reloadable, and X creates a module-level global variable Y, and module Z imports Y, then Y needs to be decorated in such a way that Z's view of Y can change automatically when X is reloaded. This second approach has subtle limitations, though. What if Y has the value 10 and Z defines a global variable A whose value is (Y**2)? The value of A might need to change when Y changes, but how can we arrange for that to happen without making a mess of the code? I doubt there's any reasonable general solution. Even more subtle is what happens when a reloadable module holds a registry of things imported from other modules. When the module is reloaded, should the registry get cleared? Zope 2's refresh says the registry should be cleared, but in practice, this confuses everyone. To solve this, I think reloadable modules need to have a special global namespace. Everything in the global namespace, as well as everything reachable from the global namespace, must be explicit about what happens at the time another module imports it or the module is reloaded. I think this could make a refresh mechanism like the one in Zope 2 reliable. It has a lot of similarity with persistent modules, but it might be simpler. I haven't thought it all the way through. The idea came to me about halfway through this post. :-) Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Google SoC Project
Jim Fulton wrote at 2006-5-9 07:22 -0400: ... Finally, there's a lot of interest in generating configuration actions in Python, rather than ZCML. I suspect that avoiding XML processing, conversion, and validation might speed startup quite a bit. Moreover, if the component performs is own reregistration on reload, the Z2 refresh may be possible as well. We use the Z2 refresh all the time and are very satisfied. Of course, with a component (i.e. Product in Z2), all dependent components have to be refreshed as well. We do this with a little tool of ourselves. With a decent dependancy spec, almost all refresh behave as expected. ... I'm really not interested in a reload faclity, like the one commonly used in Zope 2, that is not robust. I've wasted too many hours helping people debug problems that were caused by reload misshaps. I hear of very few problems here. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Re[2]: [Zope3-dev] Re: Google SoC Project
Adam Groszer wrote at 2006-5-9 14:36 +0200: ... [snip] JF Python simply does not support a general robust reload, other than JF restart. [snip] What about pushing the problem then to the lower level, to Python itself. I think all developers are fighting the same problem, so all Python developers would benefit from the solution. As I know (that may be wrong) not many even if any language supports that, so that would make one big plus point on the Python side also. I fear, this is a very deep (and difficult) problem! A reload may modify an object that is used in arbitrary places. and Python may not know all these places... Because of this, Python has only two options: * it creates a new object and leaves all using contexts alone. That is what Python does now. * it overwrite the object in place. But for many modifications this is impossible (e.g. if the new object needs more contigous space then the old one). -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Event suscribing and permissions
Hello, it looks like 'provides' is mandatory for the 'subscriber' directive if I need to set a permission. If I want to add a permission on a simple handler, it won't work: No go: ... subscriber ... handler=my_handler ... for=IMyEvent ... permission=InYourDreams ... / this is because the subscriber directives checks the permission upon the interface provided by the 'provides' attribute. How can I apply a permission then on a simple handler, since i don't have a 'provides' attribute in this case ? is there another technique ? If not, I guess we could change this behavior a bit to allow handler-permission combos, otherwise it makes it quite complicated to set up a simple, secured event handler. Maybe we could check rights directly on the event interface ? Furthermore, the current behavior is not properly raising a TypeError when a 'permission' is set together with a 'handler', we need to correct this as well. Regards, Tarek ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: help with directlyProvides
Hi again,
If there is a bug in the container framework my assumption would be
that that the following part of code causes your problem. The regular
container asserts IContained either by the directlyProvides mechanism
if the item provides ILocation or else by a ContainedProxy.
zope.app.container.contained line 325:
[...]
if not IContained.providedBy(object):
if ILocation.providedBy(object):
zope.interface.directlyProvides(
object, IContained,
zope.interface.directlyProvidedBy(object))
else:
object = ContainedProxy(object)
[...]
[...]
well... I'm not sure but it seems not to be a bug in ContainedProxy, but
just a display bug in the @@introspector.html...
I couldn't trace into the ContainedProxy, but put some debug messages and
got something interesting
I put this code in a pacage called dprovide
###
### dprovide/__init__.py
from zope import interface
from zope import schema
from zope.formlib import form
from zope.app.file import File
from zope.app.folder import Folder
from zope.location import ILocation
class IMarker(interface.Interface):
test marker interface for directlyProvides
class ITestSchema(interface.Interface):
test schema for directlyprovides
file = schema.Bool(
title = u'Create File and directlyProvide IMarker' )
file2= schema.Bool(
title = u'Create File and directlyProvide ILocation and IMarker' )
folder = schema.Bool(
title = u'Create Folder and directlyProvide IMarker' )
class DirectlyProvidesTest(form.AddForm):
form_fields = form.Fields( ITestSchema )
def create( self, data ):
r = {}
if data['file']:
f = File()
interface.directlyProvides( f, IMarker )
r['file'] = f
if not IMarker.providedBy( r['file'] ):
raise Error
if data['file2']:
f = File()
f.__name__ = ''
f.__parent__ = ''
interface.directlyProvides( f, ILocation, IMarker )
r['file2'] = f
if not IMarker.providedBy( r['file2'] ):
raise Error
if data['folder']:
f = Folder()
interface.directlyProvides(f, IMarker)
r['folder'] = f
if not IMarker.providedBy( r['folder'] ):
raise Error
return r
def add( self, r ):
if r.has_key('file'):
self.context.add( r['file'] )
if r.has_key('file2'):
self.context.add( r['file2'] )
if r.has_key('folder'):
self.context.add( r['folder'] )
self._finished_add = True
###
and in dprovide/configure.zcml
page
class=.DirectlyProvidesTest
name=directlyProvides.html
permission=zope.Public
for=zope.app.container.interfaces.IAdding
title=Test page for directlyProvides
menu=zmi_views
/
and I patched zope.app.container.contained @ 325 to look like this:
if not IContained.providedBy(object):
if ILocation.providedBy(object):
zope.interface.directlyProvides(
object, IContained,
zope.interface.directlyProvidedBy(object))
else:
print_provides = False
if object.__class__.__name__ == 'File' or\
object.__class__.__name__ == 'Folder':
from dprovide import IMarker
print ! BEFORE ContainedProxy: ,
object.__provides__
print IMarker.providedBy = ,
IMarker.providedBy(object)
print_provides = True
object = ContainedProxy(object)
if print_provides:
print ### AFTER ContainedProxy: ,
object.__provides__
print IMarker.providedBy = , IMarker.providedBy(object)
###
now.. after adding a File (without) ILocation, I see the output
! BEFORE ContainedProxy: zope.interface.Provides object at
0xb455ea0c
IMarker.providedBy = True
### AFTER ContainedProxy: implementedBy
zope.app.container.contained.ContainedProxy
IMarker.providedBy = True
so, the IMarker is provided by the file, but in a different way.. so I
think the introspector is just not showing it correctly...
if I add a File w/ ILocation, it doesnt go into the ContainedProxy and the
introspector shows the directlyProvided intefaces correctly...
regards.
luis
ps. if you want to try that... you have to add the files one by one.. if
you select two checkboxes at once you get a dupplicate names error.. not
sure why.
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub:
