[Zope-dev] Why are width and height strings?
I've run into a weird problem with product development (VarImage product): Since I inherit from Zope's 'Image' object, I get and use its width and height attributes -- which I blithely assumed were integer properties. But they're not -- they're strings. (At least in Zope 2.6.4 they were). Why? There doesn't seem to be any logical reason for that, since the only sensible values are integer numbers. Things get weird when you set them to integer values and then try to use Zope's management screens to set them, which I'm currently trying to fix as a bug in VarImage. Is there some compelling reason why they should be strings? I'm thinking about overriding this, because it doesn't make any sense to me, but I'm curious if there was a rationale behind it (and whether I'm creating a whole new group of bugs if I do that). Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Re: [Zope3-dev] Decouple Interface and zope.interface (Martijn was right)
On Sunday 25 April 2004 06:57 am, Jim Fulton wrote: If we drop the requirement to make the interfaces interoperate (e.g. extend one another, or be used in the same declarations), then, with a small change that Martijn has suggested, we can use zope.interface in Zope 2 without any other changes. That would be terrific! (Makes my life easier, anyway). Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] The bleak Future of Zope?!
On Thursday 22 April 2004 05:22 pm, Dieter Maurer wrote: Writing a fundamentally complex web application within 2 months work is quite impressive, isn't it? Apparently, the framework is not too bad... Ya' think? I thought it just meant I kicked ass. :-D No, seriously Zope is great. But it's a bit rigid. Zope 3 will (I think) be a lot better. There's also the tiny detail that I haven't actually written it to the point where it can be used yet. So maybe it isn't that impressive. :-( Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] The bleak Future of Zope?!
On Wednesday 21 April 2004 05:52 am, Eckart Hertzler wrote: I don't agree. I am new to zope. So I tried zope2 first, because plone had a lot of appeal. I got discouraged very quickly, because zope2 is so very grown over a time it's hard to join later. Zope3 seemed quite well documented and I had no problems going on on my own. ( There is a tutorial, a cookbook, and an online apidoc ) I can say nothing however to migrating apps from zope2 to zope3. I'm really looking forward to Zope 3, and I'm thinking about migrating to it this Summer. I've been developing an application, which has taken about two years, largely because developing in the Zope 2 Framework model is like beating your head against the wall constantly. That's probably because I'm writing a fundamentally complex web application which I need to have a lot of large-scale control over. I'm not writing in an environment where a slightly-customized ZMI or even a collection of new Zope objects will quite do the job. I'm writing a system which gives end-users (NOT CS experts) a lot of control over their environment. And there are fundamental user-interface changes involved. I also have to do this in my copious free time, as I'm not commercially employed to do this work (maybe someday, but not now). So in those two years, I've probably had the equivalent of 2 months of full-time work. For somebody dealing with that, the constant pressure to adapt to a changing platform and the myriad interfaces that break when you do, and the unwillingness to document these problems because that's too old get really frustrating. The lack of formally defined interfaces makes it very hard to deal with this situation -- it's not easy to mix-and-match the new parts you need with the old parts you haven't been able to upgrade yet. In short -- Zope 2 is TOO LABOR INTENSIVE. Mostly because it's TOO COMPLEX and TOO MONOLITHIC. During the development phase of my project, I've had to upgrade Zope THREE times, and EACH one REQUIRED A MAJOR RE-WRITE on my part. That makes it very difficult to concentrate on forward momentum. I've missed my own deadlines, and had to admit that I simply can't deliver the product on anything like the schedule I originally was trying for. And this 3 steps forward, 2 steps back problem of dealing with a changing, poorly documented, and often buggy platform is part of the reason. The promise of Zope 3 is that it is following Python's TOOLBOX model, and making it easier to separate out the parts you need into separate interfaceable components. This will make life vastly easier for large-scale projects which don't follow the typical quick and dirty Zope site model. Or so I hope. ;-) I don't understand everything else they're doing with it, and I've had frustrations with Zope 3, but in the long run (which I care about -- I expect my application, or a later version of it, to be in use in 15-20 years, so I'm not just concerned with first to market), I think it will be easier to keep up with. I understand that my situation is probably unusual, but I do want to speak out to say that there is interest in Zope 3, and I personally expect to be using it before 2005. Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Re: The bleak Future of Zope?
On Wednesday 21 April 2004 09:40 am, Max M wrote: Stephan Richter wrote: However, we are getting the first alpha out by the end of the month. Hopefully, by end of May we will have finished the X3.0 to-do list and will release the beta. At this point the API will freeze and application developers are encouraged to have look at it. Well, I couldn't find the antecedent for that quote, but it's really good news! I'm deeply embroiled in organizing for an upcoming space conference on Memorial Day Weekend (May 27-31, http://www.isdc2004.org ), so I'm not able to do *any* programming for about a month, but I will definitely be checking X3.0 out in June. That's probably when I'll be available to look at the Schema package and see if I can contribute usefully to it, as well. Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Interfaces in Zope 2.5, 2.7, and 3.x
directly to Zope X3's interface instead of subclassing it? All it requires is something like: class SubInterface(Attribute): A SubInterface is an Attribute with an assigned Interface. def __init__(self, __name__=None, __doc__=None, api=None, optional=0): self.__name__=__name__ self.__doc__=__doc__ or __name__ self.api = api self.optional = optional Which is what my module defines -- the trickier bit is defining a function to recursively check SubInterfaces. That's included too, but it breaks due to major API changes in Interface. Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] bizarre slicing behaviour in Zope
On Wednesday 17 December 2003 02:44 pm, Casey Duncan wrote:
On Wed, 17 Dec 2003 15:30:50 -0500
Gerry Kirk [EMAIL PROTECTED] wrote:
try this in a script in zope 2.7b3 (maybe others, too) if you want to go
crazy:
dd = ('dd', 'diocese', 'Parish.2003-12-16.8636751973', 'bob',
'Workspace.2003-12-17.8140751750','gerry.2003-12-17.8140751750')
return dd[4:]
you should get the last two items from the tuple, but I get the last
item returned as a string
if i loop through the slice, it's ok. it seems to be a publishing problem.
Look at the title of the browser window to see the other item of the tuple.
Welcome to 2-tuple publication ;^)
Perhaps more constructively, I think you can solve this by either
adding a dummy element to the tuple:
return dd[4:] + (None,)
or making it a list instead of a tuple:
return list(dd[4:])
Cheers,
Terry
--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks http://www.anansispaceworks.com
___
Zope-Dev maillist - [EMAIL PROTECTED]
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] Versions: should they die?
Can I, a humble Zope product developer, please make a plea that anything marked as an 'official evil' be made as invisible as possible? (I.e. that you make it disappear unless specifically configured as an option, as was suggested up-thread). Zope is already full of deprecated methods that make learning the one obvious way to do it very hard to figure out. The refrain on the ML and in other places is if the documentation isn't good enough, 'use the Source, Luke', but have you actually looked at the source? Sorry, I know you have -- but please try to imagine what it looks like to a newcomer who doesn't know their way around like you do. We already have same-named objects defined in multiple places -- are they really all the same object? Are they different implementations of the same object? Are they actually just imports from one module to another? Are they overloaded with additional functionality? Also lots of similar objects -- should I use Item or SimpleItem. Should I inherit stuff from Globals or from the files they are actually defined in? It is an important point of information architecture that signs to the user must be graded in order to be most useful -- many signs with the same apparent importance are confusing, and may be worse than no signs at all. Also, whereas you, who are intimately familiar with evolutionary history of Zope's source may be completely aware of what's old and what's new, the newbie developer has little way to determine this. I can look at file dates, and occasionally I can find notes explaining this in the comments. But too often developers say something along the lines of this is the new improved way to do X. But when did they write that? Last month? A year ago? Longer? I recognize that you all have made steps in this direction for Zope 3 (such as the interface/components concept, which IMHO is a big improvement). Reducing confusion should be a big priority, I hope. And what you don't say is just as good as what you do. Minimalism seems very pythonic to me. ;-) Just my 2 cents. Cheers, Terry On Wednesday 04 June 2003 09:21 am, [EMAIL PROTECTED] wrote: If I remember correctly, though, there was still a lot in question about legitimate use cases. The web-services cluster-safety use-case I sketched out here (http://mail.zope.org/pipermail/zope3-dev/2002-October/003112.html) is still (perhaps) a valid case, but ONLY in a very-carefully constructed application (and even that case leaves me wanting a better app-level way to do it). I think I agree with the feeling that versions should stay in ZODB, but be depreciated/marked as official evil in ZMI. Sean -Original Message- From: Guido van Rossum [mailto:[EMAIL PROTECTED] To anyone not following the Problem committing zope 'version' objects thread on [EMAIL PROTECTED]: It's been proposed that Versions should be at least stamped in the ZMI with big warnings, or possibly disabled altogether. Numerous users have been bit by the fact that versions basically do not work as advertised, leading in various cases to zodb corruption or work that can't be saved. There are other security issues that Oliver Bleutgen raised privately which I won't state here. Comments? Could we get at least some warnings in the ZMI before 2.6.2 final? IMO versions do nothing except complexify the code. I believe it's an official Zope Corp position to discourage them for new projects. Yet Jeremy Hylton seems to think that they are somehow useful and has carefully preserved them in ZODB 4 (== Zope 3). If it were up to me, they would have been gone, with a big helping of YAGNI! --Guido van Rossum (home page: http://www.python.org/~guido/) -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Zpydoc
On Wednesday 04 June 2003 07:16 pm, alan milligan wrote: Personally, I am a bit sceptical about the whole Interface concept. Fortunately because Python supports multiple inheritance, it's not like the Java mechanism. But it strikes me as being much too like the concept of a pure abstract base class in C++. But the reality is that this almost never happens, and it always seems like a good idea to start using this class for common methods. I do not have a problem with this and think that just declaring a function gives you little benefit when you could provide a definition as well - even a 'raise AssertionError, 'Implement me!' seems more useful :) I think it depends on what they are used for. In my situation, I am defining objects that future 3rd party developers will likely have to subclass. But what methods and attributes do I promise to keep, and which do I plan to alter at need? Also, the interface concept allows me to specify what an object *behaves like* -- not what it *is*. Right now if I subclass from Folder, it isn't easy for me to tell this with introspection -- I have to *know* that a Topic is just an extended Zope folder. Interfaces will allow me to simply say that Topic implements a Folder interface. Then it's easy to tell whether I can call certain methods on it. The metatype concept just isn't good enough for this, and inspecting __bases__ is too complicated. Anyway, what if I *don't* subclass from Folder? Maybe I just implement all the same methods. Interfaces lets me just say what it does in an unambiguous way. And since it's in the code, and there is a mechanism for checking that the interface is implemented (in fact I'm thinking of building in such a check into my installation process), this is a nice arrangement. The thing to realize is that interfaces are self-checking documentation, not code. Well, so far, they seem really nice, anway. Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
