Chris Gray: I think there is a logical objection to this name [Python Scrpit]: inconsistency with "DTML Method" and "ZSQL Method". Chris Withers: These are old, horrible and will hopefully be re-thought and given different names ;-) > ZIP Method (Zope Internal Python Method) > ZoPy Method > PyZo Method > ZPython Method :-( All imply there is soem difference between the Python used by Zope and any other python ,which isn't, and never should be, the case... This is why I proposed Python ZMethod. I further propose that ZMethod be used generally for anything that Zope considers a method (but which may not necessarily be a method in the implementation language - here, Python). Thus we'd have DTML ZMethod, SQL ZMethod, Perl ZMethod. This puts the decoration where it is most appropriate, i.e. ZMethod, and leaves us to qualify it by the natural name of the implementation language - Python, Perl, DTML, SQL, Tcl, whatever. Hamish Lawson ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie
To Hamish, the other Chris, and anyone else who's going to jump in on this. To be quite blunt, this has now been _decided_ as I understand it. So it's pointless to keep arguing and suggesting new and different names. We now _have_ a president and it's name is 'Python Script' ;-) Like it or hate it (I'm pretty neutral about it), it's here to stay, so lets just get on with using them and making sure they work the way we want them to. cheers, Chris (who, for once, won't be following up on this thread...)
Sorry, My intention was not to annoy Chris Withers or create a headache for him. Really, I'm pretty neutral about any name for any software item. I was just thinking out loud about consistent naming practices in an OO environment. It helps to talk about related things if they have related names. That's the main point I wanted to make. Besides, as a Canadian citizen I'm not bound by any rulings of the Florida Supreme Court :-) Now let's get back to Zoping around. Chris On Thu, 23 Nov 2000, Chris Withers wrote:
To Hamish, the other Chris, and anyone else who's going to jump in on this.
To be quite blunt, this has now been _decided_ as I understand it. So it's pointless to keep arguing and suggesting new and different names. We now _have_ a president and it's name is 'Python Script' ;-)
Like it or hate it (I'm pretty neutral about it), it's here to stay, so lets just get on with using them and making sure they work the way we want them to.
cheers,
Chris (who, for once, won't be following up on this thread...)
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
On Thu, 23 Nov 2000, Chris Withers wrote:
To Hamish, the other Chris, and anyone else who's going to jump in on this.
To be quite blunt, this has now been _decided_ as I understand it. So it's pointless to keep arguing and suggesting new and different names. We now _have_ a president and it's name is 'Python Script' ;-)
With all due respect to everyone, this should not be considered a closed issue. My understanding is that there would be a vote for a name. Skipping that in the name of getting things moving after it was offered by Digital Creations seems to go against the open source nature of the product. Not to mention that the name chosen does nothing to distinguish it from an everyday Python "script" outside of Zope, which is what sparked the name change to begin with. "It's not really a Python method, so let's change the name." Well, it's not just a "Python Script" either. It's Zopified. I agree with Hamish Lawson on the renaming of methods to use a language name with a ZMethod suffix for consistency and for all of the other reasons he mentioned. The argument that all documentation would be rendered incorrect should not be an excuse for keeping bad naming conventions. A document describing new names vs. old names could easily be provided in the book and in an easily accessible location on the Zope site. Over time the "problem" would go away and we would end up with something that is consistent, representative, and easy to understand. On that same note, maybe Zope *should* provide an "alias" for bobobase_modification_time and depricate its use? Maybe I'm pushing it on that one since I don't know what major internal chaos it might cause, but I hope you understand my point. The new getId() comes to mind as an example in the right direction. Please, Digital Creations, keep this issue open for consideration in the name of a better product. *Before* the book is published is the time to pick a naming convention that isn't confusing. I do care about the name. I took great care in naming my child, and though it's not quite the same thing, I think DC should do the same. Thanks, and I *love* Zope. --- Ron Bickers Logic Etc, Inc. rbickers@logicetc.com
The Zope book discusses calling a ZSQL Method via a URL, saying that a request for a URL like: http://localhost:8080/zsql_method/parameter/value "will return a result object", but what I get is the index_html document at the root, although I do get a rendered record with: http://localhost:8080/zsql_method/parameter/value/dtml_method Am I supposed to be getting something like I do with: <dtml-var expr="zsql_method(parameter=value)"> and why am I not getting it? Cheers, Chris
Ron Bickers wrote:
On Thu, 23 Nov 2000, Chris Withers wrote:
To Hamish, the other Chris, and anyone else who's going to jump in on this.
To be quite blunt, this has now been _decided_ as I understand it. So it's pointless to keep arguing and suggesting new and different names. We now _have_ a president and it's name is 'Python Script' ;-)
With all due respect to everyone, this should not be considered a closed issue.
It is. This is the kind of thing where it is impossible to make 100% of the participants happy, we regret that not everyone is going to go for it, but we *must* move forward. This issue is holding up Python Scripts, which is holding up the book, which is intimately tied to Zope 2.3, all of which is intimiately tied to my paycheck. My paycheck doesn't really have anything to do with it but I just thought I'd mention it. ;)
My understanding is that there would be a vote for a name.
We could not afford any further delay, and the last poll was a disaster. The author of Python Scripts (the majority of which were written before he worked at DC) rightly asserted his position and picked a name. I'm sure it wasn't easy for him, and there was lots of internal conflict; many in the company not liking 'Script' for many of the same reasons you do.
Skipping that in the name of getting things moving after it was offered by Digital Creations seems to go against the open source nature of the product.
That is tying a strong semantic relation between "open source" and "democratic". In my mind, the open source nature is that anyone can examine, author and contribute code to a project for peer review and inclusion. Evan did just that, he wrote most of what used to be called Python Methods before he worked at DC and contributed it freely under the open source mantra. I don't think voting has much to do with open source, it has worked for us (with the documentation poll) and failed for us (with what used to be called Python Methods) but we'll probably try it again.
Not to mention that the name chosen does nothing to distinguish it from an everyday Python "script" outside of Zope, which is what sparked the name change to begin with. "It's not really a Python method, so let's change the name." Well, it's not just a "Python Script" either. It's Zopified.
Just to clarify, in the Python language, there is no such thing as a "script". What you are thinking of as a "script" is really some hunk of data (probably a file) containing python code that contains either some platform specific hook to invoke the interpreter, or that you pass to the interpreter on the platform specific "command line". Neither of these things have anything to do with the language called Python. Once inside the interpreter, you are officially working with "modules". "Modules" and "methods" are real, defined, un-ambiguous Python objects defined in the Language Reference (http://www.python.org/doc/current/ref/ref.html). Obviously, naming a Zope object "module" or "method" would be a bad idea, and therein lies the problem. "Script" is just un-bound, non-python specific, vague lingo that everybody uses to describe a chunk of code in just about any language, on any platform. In this case, the platform is Zope, the chunk of code is written in Python, and the "command line" is your web browser. I can sympathize with your feelings, but one of the reasons I don't like "Method" is because it's is OO specific; it is a very technical term. "ZMethod" is no better, even if it doesn't have the problem of clashing names with a python object (and barely not clashing at that!). We want to make using Zope easier. For the target audience we want to approach, if 1000 people pull down the add list and see "Python ZMethod" many more of them are going to scratch their heads about what the hell a ZMethod is than if they see "Python Script". "Oh, a python script? Cool! I've written some CGI scripts! Now I can go and read chapter six of the book 'Scripting Zope' and find out how to 'script the web'!" -Michel
participants (5)
-
Chris Gray -
Chris Withers -
Hamish Lawson -
Michel Pelletier -
Ron Bickers