Re: [Zope-dev] TreeVocabulary in zope.schema.vocabulary
On Mon, 2012-01-30 at 15:42 +0100, Charlie Clark wrote: Am 30.01.2012, 14:33 Uhr, schrieb Jan-Carel Brand li...@opkode.com: ... lots cut ... Yes, the values must be unique, because we do value lookups. The title attr doesn't have to be unique though. You could have a Forestry department for two different regions. The title will be the same, but the value and token attrs can't. I think the tests should be extended to show that this also includes nesting because this is non-obvious. ie. I believe that the region Izmir is within the state of Izimir in Turkey. Ok, I've added the method *test_nonunique_values_and_tokens* to the tests. This should be possible by calling _getPathToTreeNode during one of the passes through _flattenTree. getTermPath would then just need to do a lookup on this. I don't like the way the path_node gets implicitly populated during a call to _flattenTree. hm, okay. Personally, I think you should be able to populate your dictionaries with only a single pass through the terms. However, as this only needs to happen when the application starts we don't need to worry too much about the performance. I think you're right, so I've refactored _flattenTree and _getPathIndex into a single method _populateIndexes that populates all three indexes with one tree-traversal. I'd rather have a separate method that calculates the path and then explicitly assign it to self.path_node. In any case, there is now a node_index in the code snip but I don't see the advantage of cls.createTerm(*args) over SimpleTerm(*args) See above. createTerm is there to let developers override it and provide their own term objects. Do you have a concrete use case for this? Not really, but that doesn't mean it doesn't exist. Then someone will speak up for it if they need it or do their own subclassing/composition as required. Otherwise it's just food for warts. Remember that createTerm is a convenience method only. Frankly, I don't see the need for it in what is a fairly specialised class. I like consistency and symmetry, so if SimpleVocabulary has it, as an add-on developer I'd expect for TreeVocabulary to also have it. I don't however feel very strongly about it though, and I wanna get this done, so I removed it. Well, we could always think about removing it from SimpleVocabulary: it's not in the interface so no subclass actually has the right to depend on it. ;-) Looking at the documentation in fields.txt I see the following: A vocabulary must minimally be able to determine whether it contains a value, to create a term object for a value, and to return a query interface (or None) to find items in itself. So it looks like someone thinks that any vocabulary must be able to create a term object. Thoughts on that? I think I'm now finished and have implemented everybody's suggestions and improvements. The TreeVocabulary now has a terms_factory attribute which is an OrderedDict by default and which can be overridden in a subclass to an alternative datastructure. It also implements IEnumerableMapping. All the TreeVocabulary methods are covered by tests and I tested with Python 2.6 and Python 2.7. If there aren't any more objections, I'd like to now merge with trunk. Regards J-C ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZAM/ZMI Demo
Hello, Op 6 feb 2012, om 10:26 heeft Lennart Regebro het volgende geschreven: This is at least an important attitude. I think also a future admin interface to a large extent should lose many of the ZMI concepts. For example, we need several management tools, like what is in the control panel at the moment. But that should be separate from the browsing of objects. That browsing should instead be a rather low-level ZODB browser, IMO. That would be great, for my part to be able to have the management tools (packing and such) in a separate package than the object browsing (and even the object actions, if you want to keep them, I don't want them). For some projects, I don't wish people to be able to browser the ZODB objects and fucked up things by copying, renaming objects and things like that, but I still want them to able to access the packing screen and such tools. And for this same reason, those two package should not depend on each others, so I say +1. Regards, Sylvain, -- Sylvain Viollon -- Infrae t +31 10 243 7051 -- http://infrae.com Hoevestraat 10 3033GC Rotterdam -- The Netherlands ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 4 release management
On 11/17/2011 07:01 PM, Martin Aspeli wrote: I would actually argue that Zope4 have no real release cycle at all: instead, the individual pieces which make up Zope should have their own cycles, with perhaps a ZTK-like tracking set that Plone and others use as platform targets. -1 - we'll need something to amalgamate this into a release and we'll need a way to manage and number those releases. I agree; actually ZTK-like tracking set is really already talking about doing releases, just like the ZTK has releases. And just like ZTK releases do, this needs some release management effort. Now I would advocate that Zope 4 releases mimic the ZTK in the way things are managed. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 4 release management
On Mon, Feb 6, 2012 at 4:41 PM, Martijn Faassen faas...@startifact.com wrote: I would actually argue that Zope4 have no real release cycle at all: instead, the individual pieces which make up Zope should have their own cycles, with perhaps a ZTK-like tracking set that Plone and others use as platform targets. not sure whom I'm quoting here, but: Zope 2 is special in that it still has one big library named Zope2 at its center. It's not just a collection of libraries. And a lot of the bigger changes being proposed need coordinated changes to multiple libraries. Like the __parent__ work or likely any non-trivial change to publication. You can likely evolve DateTime, Record, Missing or DocumentTermplate on their own - but that's not terribly exciting. I agree; actually ZTK-like tracking set is really already talking about doing releases, just like the ZTK has releases. And just like ZTK releases do, this needs some release management effort. Now I would advocate that Zope 4 releases mimic the ZTK in the way things are managed. Just to clarify: Do you mean in terms of its release team? So instead of having one release manager constituting a team? A team representing the different consumer groups of Zope? Something like Plone, pure-CMF, non-CMF? In terms of its scope Zope 4 is meant to be a feature release, which needs coordination and decisions on what to include. That makes it a bit different from the ZTK, where the release team explicitly stays out of setting development direction and avoids influencing what happens in each library. So I'm not sure the ZTK release team model is directly applicable to Zope 4. The ZTK works fairly well for a mostly stable set of libraries, where not much happens and at most quarterly bug fix releases are needed. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZAM/ZMI Demo
Very good point about different user types. Maybe we could have different permissions on the different roles, and people only get to see their version. Right now there is just a single ZMI permission. At least in Zope 2 that was the case. So I suggest we have 3 new roles. System Administrator, Zope Administrator, Zope Developer. System administrator could view the database size, pack it, and start and stop zope. That is about it. Zope administrator could also move things around and delete things.Maybe add a few types of objects, such as cache objects. Zope developer could add arbitrary objects. I think this distinction would go a long way towards resolving the conflicts I have seen over the years about the ZMI. What do you think? Regards Chris On 2/6/12 7:07 AM, Sylvain Viollon wrote: Hello, Op 6 feb 2012, om 10:26 heeft Lennart Regebro het volgende geschreven: This is at least an important attitude. I think also a future admin interface to a large extent should lose many of the ZMI concepts. For example, we need several management tools, like what is in the control panel at the moment. But that should be separate from the browsing of objects. That browsing should instead be a rather low-level ZODB browser, IMO. That would be great, for my part to be able to have the management tools (packing and such) in a separate package than the object browsing (and even the object actions, if you want to keep them, I don't want them). For some projects, I don't wish people to be able to browser the ZODB objects and fucked up things by copying, renaming objects and things like that, but I still want them to able to access the packing screen and such tools. And for this same reason, those two package should not depend on each others, so I say +1. Regards, Sylvain, -- Regards Christopher Lozinski Check out my iPhone apps TextFaster and EmailFaster http://textfaster.com Expect a paradigm shift. http://MyHDL.org ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZAM/ZMI Demo
Hello, Op 6 feb 2012, om 17:06 heeft Christopher Lozinski het volgende geschreven: Very good point about different user types. Maybe we could have different permissions on the different roles, and people only get to see their version. Right now there is just a single ZMI permission. At least in Zope 2 that was the case. So I suggest we have 3 new roles. System Administrator, Zope Administrator, Zope Developer. System administrator could view the database size, pack it, and start and stop zope. That is about it. Zope administrator could also move things around and delete things.Maybe add a few types of objects, such as cache objects. Zope developer could add arbitrary objects. I think this distinction would go a long way towards resolving the conflicts I have seen over the years about the ZMI. Having different roles will help greatly yes, and even if we end up with multiple packages that would still be a great idea to have, but again, if I don't expect (want) my users to use this browsing interface at all, why should I load all its code when the server start ? That just increase the application footprint for nothing, and designing the new ZMI in two or three packages (not 50) would solve it. And I am against 50 packages too, as setuptools get exponentially slower when you load entry_points, as it check that all dependencies of your packages are installed. Regards, Sylvain, -- Sylvain Viollon -- Infrae t +31 10 243 7051 -- http://infrae.com Hoevestraat 10 3033GC Rotterdam -- The Netherlands ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] ZTK maintenance releases coming up
Hi. I just updated the ZTK 1.0 and 1.1 branches to all latest bugfix versions. I'll give the buildbots until Wednesday to build and find any real problems. If there's no problems, I'll cut new ZTK 1.0.x and 1.1.x releases later this week. If you have any other bugfixes you want to get into those, now's the time ;-) Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZAM/ZMI Demo
Having different roles will help greatly yes, and even if we end up with multiple packages that would still be a great idea to have, but again, if I don't expect (want) my users to use this browsing interface at all, why should I load all its code when the server start ? That just increase the application footprint for nothing, and designing the new ZMI in two or three packages (not 50) would solve it. Makes sense to me. Two or three roles, and two or three packages. One role per package. In any case it should be possible to split ZAM out into different pieces. I am really glad to see that multiple people are interested in building on ZAM and working with it. That motivates me to work on it. Thank you so much Roger for pointing out the + sign for adding objects in the ZAM interface. Now I just need to figure out how to get it to work! Regards Chris ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] [zope2] 2.12.x formal end-of-life
Hi. I just updated the 2.12.x branch with one last batch of bugfix versions. I'll let the buildbots run and if there's no troubles release one more version later this week. I consider this to be the last maintenance release for the 2.12.x series. From now on 2.12.x will only see security updates. I've also put an end-date to the security support (http://zope2.zope.org/releases), stating October 2013 as the end date. This happens to be the end of security support for Python 2.6 - the only Python version supported by the 2.12.x series. This is rather long in the future, one and a half years from now. I think that sets reasonable expectations and gives us a clear end date. It's not meant to prohibit anyone from doing security releases after this date - just set clear expectations to others, like Linux distributors shipping Zope 2 and relieve me of my formal duty ;-) The 2.13 series is going to be supported longer. How long depends on Python 2.7's support and how Zope 4 is going to progress. At this point there's no formal end-of-life date. If you have concerns, please speak up. Zope 2.x release managerly yours ;-) Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [zope2] 2.12.x formal end-of-life
On Feb 6, 2012, at 9:45 AM, Hanno Schlichting wrote: Hi. I just updated the 2.12.x branch with one last batch of bugfix versions. I'll let the buildbots run and if there's no troubles release one more version later this week. I consider this to be the last maintenance release for the 2.12.x series. From now on 2.12.x will only see security updates. I've also put an end-date to the security support (http://zope2.zope.org/releases), stating October 2013 as the end date. This happens to be the end of security support for Python 2.6 - the only Python version supported by the 2.12.x series. This is rather long in the future, one and a half years from now. I think that sets reasonable expectations and gives us a clear end date. It's not meant to prohibit anyone from doing security releases after this date - just set clear expectations to others, like Linux distributors shipping Zope 2 and relieve me of my formal duty ;-) The 2.13 series is going to be supported longer. How long depends on Python 2.7's support and how Zope 4 is going to progress. At this point there's no formal end-of-life date. If you have concerns, please speak up. Zope 2.x release managerly yours ;-) Hanno Sounds good to me. David -- David Glick Web Developer davidgl...@groundwire.org 206.286.1235x32 Engagement technology for social and environmental change. http://www.groundwire.org ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] ZAM Demo Documentation
There are a number of people interested in ZAM, and a lot of discussion about a new ZMI, even an upcoming sprint so I am trying to do my part to get zam.demo installing correctly. Of course the error message was completely incomprehensible, I did not have the context. So step 1 is to figure out how ZAM works. I went to read the source code. Very nicely documented. Thanks to the authors. But there is no high level documentation, so I wrote this user level document. Writing this helped me understand ZAM better. And in general I think a great way for new developers to work with Zope is to write documentation, because then it helps us understand what we are doing, makes it easier to get feedback, and smooths the path for those coming after us. So here is where I left off six months ago. https://mail.zope.org/pipermail/zope-dev/2011-June/043089.html What follows is the updated version. ZAM User Documentation. ZAM is a browser based interface to BlueBream. It allows us to interact with the running BlueBream server. It provides three types of services. Administration services tell you about the Unix processes, and the ZODB databases. Error services tell you about server errors which have occurred. Hierarchy services allow one to interact with the ZODB hierarchy of objects. ADMINISTRATION SERVICES (zamplugin.control) This wepage has links to runtime information, ZODB information, Generations, and Registration. To access it you go to http://localhost/++skin++ZAM/++etc++ApplicationController/index.html The runtime information includes the following: Uptime, System platform, Zope version, Python version, Command line used to start the server, Preferred encoding, Process id, Developer mode on or off, and the Python path ZODB control includes a list of ZODB databases, their file system name, current size, and the ability to pack them, keeping up to X number of days of version. Generations describes the versions of ZODB schemas, and is a way of updating the objects as the schema changes. Impressive! Registrations allow objects to be registered as adaptors or user interfaces. This is a complex topic which requires an understanding of the Zope Component Architecture. In general beginners do not need to worry about this. ERROR SERVICES (zamplugin.error) You can see the error logs here. http://localhost/++skin++ZAM/++etc++site/default/RootErrorReportingUtility Looks very nice, much like the Zope 2 error reports. You get Time, User,and exception. You can click on the exception for more details, the Request URL, Traceback, user permissions, and the full REQUEST object. HIERARCHY SERVICES (zamplugin.sitemanager, zamplugin.navigation) Bluebream stores objects in the Zope Object Database. Objects are stored in a tree. The allows one to navigate the tree, browse objects, cut, copy, paste, and rename those objects. In the current version, when enabled, it is possible to add objects to the tree. In future versions this may also require developer permisssion. I am not sure which part of the interface is handled by the site manager, and which part is handled by navigation. zamplugin.sampledata From pypi: A sample data generator is a pluggable tool to create data needed for tests. Not really sure what this does either. If you want to learn more about ZAM, go into the source code. Go into the eggs directory and type more zam*/zam*/*/README.txt That gets you all of the source code docs. There are several different sections. There is zam.api which provides the core functionality. There is the best README.txt in this section. It explains the ZAM plugin framework. You can add or remove a plugin, but obviously only once. It talks about a base registry plugin. They talk about the layers model. Layers are all about the stuff in the skin, described below. zam.skin contains all the HTML, JS, CSS and image components The other directories correspond to the user interfaces described above. QUESTION: So where should i put this documentation? My next step is to try to run zam.demo again, and see if the error message makes any more sense to me than it did this morning. -- Regards Christopher Lozinski Check out my iPhone apps TextFaster and EmailFaster http://textfaster.com Expect a paradigm shift. http://MyHDL.org ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope-tests - FAILED: 21, OK: 74
This is the summary for test reports received on the zope-tests list between 2012-02-05 00:00:00 UTC and 2012-02-06 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received Bluebream / Python2.5.5 64bit linux Bluebream / Python2.6.7 64bit linux Bluebream / Python2.7.2 64bit linux ZTK 1.0 / Python2.4.6 Linux 64bit ZTK 1.0 / Python2.5.5 Linux 64bit ZTK 1.0 / Python2.6.7 Linux 64bit ZTK 1.0dev / Python2.4.6 Linux 64bit ZTK 1.0dev / Python2.5.5 Linux 64bit ZTK 1.0dev / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.5.5 Linux 64bit ZTK 1.1 / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.7.2 Linux 64bit ZTK 1.1dev / Python2.5.5 Linux 64bit ZTK 1.1dev / Python2.6.7 Linux 64bit [1]ZTK 1.1dev / Python2.7.2 Linux 64bit Zope 3.4 KGS / Python2.4.6 64bit linux Zope 3.4 KGS / Python2.5.5 64bit linux Zope 3.4 Known Good Set / py2.4-32bit-linux Zope 3.4 Known Good Set / py2.4-64bit-linux Zope 3.4 Known Good Set / py2.5-32bit-linux Zope 3.4 Known Good Set / py2.5-64bit-linux Zope Buildbot / zope2.12-py2.6 slave-ubuntu32 Zope Buildbot / zope2.12-py2.6 slave-ubuntu32 Zope Buildbot / zope2.12-py2.6 slave-ubuntu32 Zope Buildbot / zope2.12-py2.6 slave-ubuntu64 Zope Buildbot / zope2.12-py2.6 slave-ubuntu64 Zope Buildbot / zope2.12-py2.6 slave-ubuntu64 Zope Buildbot / zope2.13-py2.6 slave-ubuntu32 Zope Buildbot / zope2.13-py2.6 slave-ubuntu32 Zope Buildbot / zope2.13-py2.6 slave-ubuntu64 Zope Buildbot / zope2.13-py2.6 slave-ubuntu64 Zope Buildbot / zope2.13-py2.7 slave-ubuntu32 Zope Buildbot / zope2.13-py2.7 slave-ubuntu32 Zope Buildbot / zope2.13-py2.7 slave-ubuntu64 Zope Buildbot / zope2.13-py2.7 slave-ubuntu64 Zope Buildbot / zope2.14-py2.6 slave-ubuntu32 Zope Buildbot / zope2.14-py2.6 slave-ubuntu32 Zope Buildbot / zope2.14-py2.6 slave-ubuntu64 Zope Buildbot / zope2.14-py2.6 slave-ubuntu64 Zope Buildbot / zope2.14-py2.7 slave-ubuntu32 Zope Buildbot / zope2.14-py2.7 slave-ubuntu32 Zope Buildbot / zope2.14-py2.7 slave-ubuntu64 Zope Buildbot / zope2.14-py2.7 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu64 [2]Zope Buildbot / zopetoolkit-1.1-py2.5 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.1-py2.5 slave-ubuntu32 [3]Zope Buildbot / zopetoolkit-1.1-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.1-py2.5 slave-ubuntu64 [4]Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu32 [5]Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu64 [6]Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu32 [7]Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu32 [8]Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu64 [9]Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu64 [10] Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu32 Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu32 [11] Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu64 Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu64 Zope-2.10 Python-2.4.6 : Linux Zope-2.11 Python-2.4.6 : Linux Zope-2.12 Python-2.6.6 : Linux Zope-2.12-alltests Python-2.6.6 : Linux Zope-2.13 Python-2.6.6 : Linux Zope-2.13-alltests Python-2.6.6 : Linux Zope-trunk Python-2.6.6 : Linux Zope-trunk-alltests Python-2.6.6 : Linux winbot / ZODB_dev py_265_win32 winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_270_win32 winbot / ZODB_dev py_270_win64 winbot / ztk_10 py_254_win32 winbot / ztk_10 py_265_win32 [12] winbot / ztk_10 py_265_win64 [13] winbot / ztk_11 py_254_win32 [14] winbot / ztk_11 py_265_win32 [15] winbot / ztk_11 py_265_win64 [16] winbot / ztk_11 py_270_win32 [17] winbot / ztk_11 py_270_win64 [18] winbot / ztk_dev py_265_win32 [19] winbot / ztk_dev py_265_win64 [20] winbot
