[Zope-dev] Product version number redundancy with version.txt and setup.py

[Tim Hicks]

Hi,

Am I right in thinking that there is a duplication of information in 
having an eggified product's version number stored in setup.py and 
version.txt?


Both seem to be necessary - the first for use with pypi and the second 
so that Zope knows what version of a product it has.  The former seems 
more like it should be the preferred single place for this information. 
 Does anyone have any ideas about how we might update Zope to read 
version information from setup.py instead?


The initializeProduct function at 
 
seems to be the relevant place.  However, I'm not sure if that code has 
access to the full eggy package at that stage.  My guess is that the 
relevant object (productp?) might already have been adjusted for 
backward compatibility reasons at that stage.


Any ideas?


Tim
___
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] Re: Resolution of issue #2333 before next maintenance release(s)?

[Tim Hicks]

Tres Seaver wrote:
> Tres Seaver wrote:
>> Tim Hicks wrote:
>>> Hi,
>>> Apparently a maintenance release for 2.10 is imminent.  Would it be
>>> possible for someone to review the report for issue #2333 @:
>>> <http://www.zope.org/Collectors/Zope/2333>.
>>> The fix provided there comes with a test.  If it's deemed suitable,
>>> could someone with commit privileges apply the patches before the
>>> release is cut?  If not, could they tell me what I need to do to have it
>>> accepted?
>> I am in the process of landing the test and fix on the Five 1.3, 1.4,
>> and 1.5 branches and the Five trunk.
> 
>> Question for Andreas / Stefan:  would it be alright if I blow away the
>> "release" tags for Five 1.3.9 / 1.5.4 pseudo-releases?  No tarballs /
>> release announcements were made, AFAIK, and the only clients are the
>> svn:externals links in the Zope2 tree.
> 
>> OTherwise, I need to create new releases, and change the Zope2 links.
> 
> For the record, I chose the second path after thinking it over a bit.

Thanks for seeing to this!


Tim
___
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] Resolution of issue #2333 before next maintenance release(s)?

[Tim Hicks]

Hi,

Apparently a maintenance release for 2.10 is imminent.  Would it be
possible for someone to review the report for issue #2333 @:

.

The fix provided there comes with a test.  If it's deemed suitable,
could someone with commit privileges apply the patches before the
release is cut?  If not, could they tell me what I need to do to have it
accepted?

Thanks,

Tim
___
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] local namespace optimizations?

[Tim Hicks]

Florent Guillaume wrote:

Is anyone opposed to me removing the stupid:
_getattr = getattr
_none = None
marker = _marker
local namespace """optimizations""" that are found in unrestrictedTraverse?


I find these things rather confusing when looking at zope core code, and 
always wondered why they were there.  In what sense are they optimisations?



Tim
___
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] Re: Wishlist Item

[Tim Hicks]

Tino Wildenhain wrote:


Maybe its just me but I personally dont like direct filesystem
access in the core - if someone wants it, (s)he can pick from
the 3rd party products - maybe there can be a list of recommended
(active maintained) products? Direct access products should also
carry some easily understandable warnings.


I can understand that point of view for products that allow writing to 
the filesystem, but, conceptually, what's the difference between 
read-only "filesystem access" and a standard filesystem product?


None, I think, but then I may have misunderstood the purpose of 
FileSystemSite, and friends.


Tim
___
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] Make objectValues return a generator?

[Tim Hicks]

Petri Savolainen wrote:
> Am I right in assuming that calls to objectValues etc. still return a
> real sequence of objects loaded in memory from ZODB? How about making
> object* calls return a generator instead? Has this been discussed
> somewhere already? I tried a bit of googling & list-searching but could
> not find much anything on this.

Funny you should ask, I played with something similar the other day.  I
wanted superValues-like functionality for CMF portal_types.  Take a look
at

for some rather inelegant looking code the implements this as an iterator.

It's a bit different from what you're after as the gain isn't in the
contentValues call (which is the equivalent of your objectValues), but
rather in the fact that only the smallest number of those calls that are
needed is made.

Tim
___
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] 2.8.0b1 issues with plone 2.0.5

[Tim Hicks]

Tim Hicks said:



>   File "/home/tim/zope/2.8.0b1/lib/python/ZPublisher/Publish.py", line 40,
> in call_object
> result=apply(object,args) # Type s to step into published object.
>   File "/home/tim/zope/2.7.4b2/Products/CMFCore/PortalContent.py", line
> 116, in __call__
> return view()

Eek, just noticed that for some reason I seem to have some 2.7.4b2 mixed
up in here.  Not sure how/why that would happen.  I have one copy of all
my products and then symlink to them for each of my zope instances.  Could
it be the cause of my problem?

tim
___
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] 2.8.0b1 issues with plone 2.0.5

[Tim Hicks]

Apologies if this is already known about...

I just installed 2.8.0b1 (using python 2.3.5), fired it up, then tried to
add a 'plone site' (2.0.5).  The plone site actually did get added, but
here's what I got as well:


2005-04-24 12:57:32 ERROR Zope.ZCatalog Recataloging object at
/test/test/index_html failed
Traceback (most recent call last):
  File "/home/tim/zope/2.8.0b1/lib/python/Products/ZCatalog/ZCatalog.py",
line 298, in refreshCatalog
self.catalog_object(obj, p, pghandler=pghandler)
TypeError: catalog_object() got an unexpected keyword argument 'pghandler'
2005-04-24 12:57:34 ERROR Zope.SiteErrorLog
http://glenmore.dyndns.org:7080/test/test/index_html
Traceback (most recent call last):
  File "/home/tim/zope/2.8.0b1/lib/python/ZPublisher/Publish.py", line
113, in publish
request, bind=1)
  File "/home/tim/zope/2.8.0b1/lib/python/ZPublisher/mapply.py", line 88,
in mapply
if debug is not None: return debug(object,args,context)
  File "/home/tim/zope/2.8.0b1/lib/python/ZPublisher/Publish.py", line 40,
in call_object
result=apply(object,args) # Type s to step into published object.
  File "/home/tim/zope/2.7.4b2/Products/CMFCore/PortalContent.py", line
116, in __call__
return view()
  File "/home/tim/zope/2.8.0b1/lib/python/Shared/DC/Scripts/Bindings.py",
line 311, in __call__
return self._bindAndExec(args, kw, None)
  File "/home/tim/zope/2.8.0b1/lib/python/Shared/DC/Scripts/Bindings.py",
line 348, in _bindAndExec
return self._exec(bound_data, args, kw)
  File "/home/tim/zope/2.7.4b2/Products/CMFCore/FSPageTemplate.py", line
191, in _exec
result = self.pt_render(extra_context=bound_names)
  File "/home/tim/zope/2.7.4b2/Products/CMFCore/FSPageTemplate.py", line
124, in pt_render
result = FSPageTemplate.inheritedAttribute('pt_render')(
  File
"/home/tim/zope/2.8.0b1/lib/python/Products/PageTemplates/PageTemplate.py",
line 96, in pt_render
c = self.pt_getContext()
TypeError: unbound method pt_getContext() must be called with
ZopePageTemplate instance as first argument (got nothing instead)

___
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] Re: CookieCrumbler and User-Logging

[Tim Hicks]

Tres Seaver said:

> | Does it have any downsides?
>
> I can't recall whether the patch includes a knob to turn off the logging
> behavior.  If not, I would want to add one before checking it in.

It does have that knob.

> | Would you install it on a production server?
>
> We have done so for some hosted customers who wanted the capability to
> track their users.

Well, on the strength of that, I've installed it too, and it seems to work
nicely.

Thanks.

Tim
___
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] Re: CookieCrumbler and User-Logging

[Tim Hicks]

Tres Seaver said:

> I am attaching the patch which Casey Duncan worked up to log the
> cookie-based user somewhat more cleanly.

Hi Tres,

I'm just wondering what the status of this patch is.  I mean, is it now
part of any (forthcoming) release of cookiecrumbler or CMF?  Does it have
any downsides?

Would you install it on a production server?

Tim
___
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] 2.7 and 2.8 roadmap

[Tim Hicks]

Andreas Jung said:

>> 1) When is the recent release of 2.7.4b2 expected to be followed up with
>> a
>> 'final' (or indeed another beta) release?
>
> 2.7.4 final is scheduled for early January.


Ok, thanks.


>> 2) I have seen mutterings about a 2.7.5 release, but I'm not sure why
>> this
>> should be necessary as I thought all 'dot releases' were only supposed
>> to
>> provide bug-fixes.  Seeing as we're still on beta for 2.7.4, shouldn't
>> any
>> outstanding fixes go into that?
>
> Have you seen anything other than bugfixes  in dot releases? Except some
> minor
> improvements all releases were bugfix releases only. No major new
> features
> were introduced. And new  2.7.X release will be made as long as
> outstanding
> bugs are fixed but not *every* outstanding will be fixed.


That's fair enough.  Thanks for the clarification.


>> 3) Are there plans for another 2.8 (alpha or beta) release in the near
>> future?  Is there a timeline for this?  Are ZC or anyone else hanging
>> out
>> for this?  Personally, I'm pretty keen to be able to persist new style
>> classes (for use with the email.Message.Message class).  The wiki at
>>  seems a
>> little out of date.
>>
>
> There are some outstanding issues that must be fixed before the next alpha
> 2
> (ZClasses, garbage collection). I don't know when Jim can work on this
> issue
> (there are only some people  with the detail knowledge to fix these
> issues). Since
> I can not enforce people to work on particular issues, a2 will released
> when the
> outstanding issues are solved.


I understand.


FWIW, the two things I'd like are a stable 2.7 release in the short term
to setup a new site on, and a stable 2.8 release to develop a new product
on.  Sounds like Santa (aka Andreas) will be bringing the former ;-).  I
think in the back of my mind, I was hoping that more people waiting on 2.8
to get their features into zope might speed things up on the latter -
hence my wondering about the motivations for a 2.7.5 (which you have now
cleared up).

That said, I'm in no position to do anything other than inquire (in a most
friendly and appreciative manner) about 2.8 as I'm certainly not on of the
people with the 'detailed knowledge' to fix zclasses and garbage
collection.


cheers,


tim
___
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] 2.7 and 2.8 roadmap

[Tim Hicks]

Hi,

just wondering what the plans are for zope 2.7 and 2.8.  Specifically:

1) When is the recent release of 2.7.4b2 expected to be followed up with a
'final' (or indeed another beta) release?

2) I have seen mutterings about a 2.7.5 release, but I'm not sure why this
should be necessary as I thought all 'dot releases' were only supposed to
provide bug-fixes.  Seeing as we're still on beta for 2.7.4, shouldn't any
outstanding fixes go into that?

3) Are there plans for another 2.8 (alpha or beta) release in the near
future?  Is there a timeline for this?  Are ZC or anyone else hanging out
for this?  Personally, I'm pretty keen to be able to persist new style
classes (for use with the email.Message.Message class).  The wiki at
 seems a
little out of date.


Just interested.


cheers,

tim
___
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] connecting server code to the ZODB

[Tim Hicks]

Replying to myself in case anyone is interested in the answer to my
problems...

Tim Hicks said:

> Nope, I don't have a reference to a persistent object.  I'm looking at the
> code in smtpserver.SMTPServer and trying to figure out what I need to
> adjust.  As far as I can tell, the only point in that code at which a
> 'link' to zope/zodb objects is made is in the following call in
> SMTPChannel.process_message:
>
> handle(self.server.module, request, response)
>
> My immediate problem is that I don't understand how the result of this
> call gets dealt with.  It just seems to get discarded in the smtpserver
> code.  If this is the way to interact with the publisher, how do I get
> hold of the return value?
>
> I'm assuming that by adjusting the REQUEST['PATH_INFO'] value before
> calling handle(), I can affect which ZODB object/method gets called, but I
> want to know the result of this call.

The REQUEST['PATH_INFO'] part is correct: that is how you determine which
method gets traversed to and called.  I discovered that you get hold of
the return value from this method by passing a callback method into the
response constructor.  This gives you access to whatever arguments you
arrange to have the callback called with *plus* the response object, which
you can use to have a look at status codes etc.

cheers,

tim
___
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] connecting server code to the ZODB

[Tim Hicks]

Paul Winkler said:

>> Ok, so I could simply drop the Zope.startup() line and things would be
>> fine (and quick), right?
>
> I haven't tried it, but I think doing Zope.app() will try to
> acquire a lock on the database and it is already locked by
> the running Zope (or ZEO). So I don't think you can do that.


Ok, I think I follow that.


>> > I think you should use the existing publisher machinery.
>> > Given an SMTPRequest instance foo, you should be able to
>> > do foo.traverse(path, response) and get back an object.
>> > This monster method is defined in ZPublisher/BaseRequest.py
>>
>>
>> What does using foo.traverse() buy me over simply accessing the ZODB
>> objects 'by hand', as in root = Zope.app()?
>
> Well, for one thing it might actually work ;-)


Good point :-).  The only thing is that I'm not sure that I actually am
able to call foo.traverse() before it gets passed into handle() (see
below) because I don't think that it will be populated with 'PARENTS'
before it's been 'sent to zope'.


> Note, I'm not sure what your code looks like - if you already
> have a reference to any persistent object (as long as it's
> Traversable which basically anything of interest to you would be),
> you can get the root by doing root = someObject.getPhysicalRoot().


Nope, I don't have a reference to a persistent object.  I'm looking at the
code in smtpserver.SMTPServer and trying to figure out what I need to
adjust.  As far as I can tell, the only point in that code at which a
'link' to zope/zodb objects is made is in the following call in
SMTPChannel.process_message:

handle(self.server.module, request, response)

My immediate problem is that I don't understand how the result of this
call gets dealt with.  It just seems to get discarded in the smtpserver
code.  If this is the way to interact with the publisher, how do I get
hold of the return value?

I'm assuming that by adjusting the REQUEST['PATH_INFO'] value before
calling handle(), I can affect which ZODB object/method gets called, but I
want to know the result of this call.

Any ideas?


tim
___
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] connecting server code to the ZODB

[Tim Hicks]

Paul Winkler said:

>> > What I really want to be able to do from the server code is something
>> like::
>> >
>> > root = magic_that_gets_me_zodb_root()
>>
>> That magic is basically (from memory):
>>
>>   import Zope
>>   Zope.startup()
>>   root = Zope.app()
>>
>> But note that starting up a zope is slow, so you don't want to do that
>> very often.
>
> Well, in this case zope is already running.


Ok, so I could simply drop the Zope.startup() line and things would be
fine (and quick), right?


> I think you should use the existing publisher machinery.
> Given an SMTPRequest instance foo, you should be able to
> do foo.traverse(path, response) and get back an object.
> This monster method is defined in ZPublisher/BaseRequest.py


What does using foo.traverse() buy me over simply accessing the ZODB
objects 'by hand', as in root = Zope.app()?  It seems I get security by
using foo.traverse() - although I'm not sure whether that is really
necessary for my purposes.  Would it also deal with any ZODB transaction
stuff for me that I would otherwise have to sort out -
get_transaction().commit().  If I'm just reading ZODB objects (not
writing), does the transaction stuff even matter?


thanks,

tim
___
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] connecting server code to the ZODB

[Tim Hicks]

Hi,

I'm trying to figure out how to adjust Nikolay Kim's smtpserver code
 so that
objects within the ZODB can affect the way that messages are received
(i.e. veto messages based on certain criteria in the first instance).

My problem is that I don't quite know how to get hold of the ZODB objects.
 As far as I can tell, Nikolay's
smtpserver.SMTPServer.SMTPChannel.process_message method uses
ZServer.PubCore.handle to make the connection, but I don't really
understand how this all works.

What I really want to be able to do from the server code is something like::

root = magic_that_gets_me_zodb_root()
account_manager = root['Control_Panel']['AccountManager']
account_manager.checkAccepts(msg)

I want calls like that to checkAccepts(msg) to be made a several points in
the SMTP session - say after each of the SMTP commands RCPT, MAIL, DATA,
etc.  I only mention that in case there are implications for some
transaction jiggery-pokery (although I don't expect any of the
checkAccepts() type calls to need to write to the ZODB).

Any pointers much appreciated.


tim
___
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] Bug in ExternalMethods?

[Tim Hicks]

I think I've found a bug in ExternalMethod, but I don't know if it's
already been fixed or not.

Basically, the call signature of ExternalMethods seems to get mixed up
sometimes.  I'm running Zope 2.5.1 on Linux.

Here's a small demonstration of the bug:

--test.py--
def test(self, a_string, an_int, a_named_arg=1):
"""bug provoking?"""
template =  """a_string = %s; type(a_string) -> %s\n
an_int = %s; type(an_int) -> %s\n
a_named_arg = %s; type(a_named_arg) -> %s"""
return template % (a_string, type(a_string), an_int, type(an_int),
a_named_arg, type(a_named_arg))


--Script (Python)--
return container.test('tim', 10, a_named_arg=(1,1))
return container.test('tim', 10, (1,1))


You can see the dodgy behaviour by switching between the two test() calls
in the Script (Python).


tim



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

[Zope-dev] Re: bug in mapply.py?

[Tim Hicks]

Evan Simpson said:
> Tim Hicks wrote:
>> Given a call signature like:
>>
>> def method(self, *args, **kw)
>>
>> In this way, mapply.py seems to ignore the fact that I want my method
>> to accept an arbitrary number of arguments (line 69).
>
> When mapply was written, its only purpose was to map explicit method
> parameters to request variables.  There was no concept of RPC of any
> kind, so neither '*args' nor '**kwargs' had any kind of sensible
> interpretation.
>
> So, yes, mapply does ignore what you want :-)
>
> Unfortunately, given the way that XML-RPC and WebDAV have been piled on
> top of the initial implementation, I'm not sure how this could be fixed
> properly in Zope 2.x.
>
> Sorry,
>
> Evan @ 4-am

Evan,

thanks for at least confirming my fears.  I've got a workaround going now;
albeit with slightly hobbled functionality.

As is the standard cry at these times - 'will this be fixed in Zope3?'

cheers,

tim



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] bug in mapply.py?

[Tim Hicks]

Thanks for the reply Steve,

Steve Alexander said:
>
>> I must admit to not understanding why this should only break over
>> xmlrpc and not directly from Zope.  The problem appears to be that my
>> method is defined something like:
>>
>> def method(self, *args, **kw)
>
> mapply doesn't put things into **kw arguments of methods.

Yeah, that's what I understood to be the case.  However, coming in over
xmlrpc, I don't have any keyword arguments - I say that because that's
explicitly what I'm doing, but I'm not sure xmlrpc handles keyword args
anyway.  The **kw is just there for easier use when the method is called
directly from zope.

> I wanted this once for a product in Zope 3, looked deeply into mapply,
> and talked to Jim Fulton about it.
>
> IIRC, Jim said that mapply shouldn't put things into **kw arguments
> because it isn't at all explicit, and would end up implicitly putting in
>  a whole bunch of things that you generally wouldn't want in a lot of
> cases.
>
>
> Can you make up a simple python module to demonstrate your case, just
> using a method, and mapply?

I guess I could try, but I'm not convinced this is my problem at the moment.

> It may be that there's a way to achieve what you want, while still
> keeping things reasonably explicit.

>From what I can tell, the problem seems to be at line 58 (mapply.py):

names=c.co_varnames[1:c.co_argcount]

Given a call signature like:

def method(self, *args, **kw)

c.co_argcount == 1
c.co_varnames == ('self', 'args', 'kw')

Now, 'names' (the variable) becomes only 'self' (the string) on line 58. 
In this way, mapply.py seems to ignore the fact that I want my method to
accept an arbitrary number of arguments (line 69).

I don't know if there's a good reason for this, or whether I'm doing
things wrong.  I also don't know why this only crops up over xmlrpc, as I
presume mapply.py is used (in some way) from within zope as well.

Any ideas?

tim



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

[Zope-dev] bug in mapply.py?

[Tim Hicks]

Hi all,

I've been trying to track down the problem outlined here *:
http://zope.nipltd.com/public/lists/zope-archive.nsf/ByKey/B9323F6D666D3D5C

I got a traceback (see below), that indicates that the problem occurs when
mapply.py inspects my method.

I must admit to not understanding why this should only break over xmlrpc
and not directly from Zope.  The problem appears to be that my method is
defined something like:

def method(self, *args, **kw)

As far as I can tell, this means that co_argcount is 1, which makes
'names' == [self,].  Passing in positional arguments to the method then
fails as len(positional) > len(names).  (All this is taken from around
line 54 of mapply.py)

Well, that seems to be why my code fails.  Can anyone tell me either what
I'm doing wrong or tell me I've found a bug.  The latter seems pretty
unlikely I would think - I'm assuming this code has been around and
working for quite a while now.

cheers,

tim

'File "D:\\Zlave\\zope251\\lib\\python\\ZPublisher\\Publish.py", line 150,
in publish_module\nresponse = publish(request, module_name,
after_list, debug=debug)',
'File "D:\\Zlave\\zope251\\lib\\python\\Products\\Localizer\\__init__.py",
line 65, in new_publish\nmapply)',
'File "D:\\Zlave\\zope251\\lib\\python\\ZPublisher\\Publish.py", line 114,
in publish\nsys.exc_info()[2],',
'File "D:\\Zlave\\zope251\\lib\\python\\Zope\\__init__.py", line 159, in
zpublisher_exception_hook\nf(client, REQUEST, t, v, traceback)',
'File "D:\\Zlave\\zope251\\lib\\python\\ZPublisher\\Publish.py", line 98,
in publish\nrequest, bind=1)',
'File "D:\\Zlave\\zope251\\lib\\python\\ZPublisher\\mapply.py", line 69,
in mapply\nif len(positional) > nargs: raise TypeError, \'too many
arguments\'

* One final unrelated point.  I was only able to get this far by hacking
at ZPublisher/xmlrpc.py so that def exception(self...) appended the
'server-side' traceback to the faultString that is returned to the client.
 This seems like a *very* useful feature.  Any chance of this getting
implemented?



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Zope 2.6 planning - call for contributors!

[Tim Hicks]

> This isn't exciting by any means unless you're one of the people who
> package Zope up for distribution, or maybe you're one of the people who
> manage lots of little Zopes on one system; but I'd like to revive the
> "grand unified Zope installation and control" proposal that has been
> floated by many people (including me) in one form or another for some
> time.  Wikiwise, this would wrap up
> http://dev.zope.org/Wikis/DevSite/Proposals/ZopeStartupProvisions and
> http://dev.zope.org/Wikis/DevSite/Proposals/InstallationAndConfiguration,
> at least.
>
> To summarize, this would involve
>
> - an expanded build program with an installation scheme that would allow
> multiple versions of Zope to be present on the same system
>
> - making that installation 'secure by default'
>
> - a registry of Zope installations and one of instances and their
> configuration settings
>
> - a 'zopectl' program or similar that would be able to start and stop
> instances
>
> - a 'zopeinstance' program or similar that would become the
> _recommended_ way of setting up Zope, by creating an INSTANCE_HOME
>
> It would be nice if
>
> - the same framework could apply to Zope 3, maybe taking care of that
> piece ahead of time
>
> I'm more than willing to head this up, though I question how long we
> have before 2.6 to do so.

Matt,

I read 'InstallationAndConfiguration' page, and it made me wonder exactly
how that aspect would work.
Assuming some sort of distutils based setup [1], would something like the
following be the desired approach? [2]

#Installs zope in it's current simplest configuration.  Equivalent of
"python wo_pcgi.py"
$ python setup.py

#Equivalent of w_pcgi.py
$ python setup.py pcgi

#Creates SOFTWARE_HOME or ZOPE_HOME (I'm not sure if there's a difference,
or which one I would mean)
#I guess it would just do this in the current directory
$ python setup.py zope_home

#Creates an INSTANCE_HOME by prompting the user for a path (if not already
given) to install to
#Add's instance to some sort of registry [3]
$ python setup.py instance [/path/to/instance]

I don't really know what else to think about.  I haven't ever used ZEO, so I
don't have the first clue about that side of things.

So, as you may be able to tell, I'm a little hazy on many (most?) aspects of
this install/configure idea, but I'm quite keen on it.  I've tried to post
something that is at least mildly useful more in the hope that it may keep
the proposal rolling rather than as a 'me too' or '+1' (as Paul E already
told us off for ;-) ).  I guess, at the end of the day, I can't really get
around the fact it's a 'me too' without any coding commitment [4].

Do you have any concrete ideas for this?

cheers

tim

[1] I've never used distutils before
[2] Feel more than free to knock down and tear up anything I've said here
:-)
[3] Would this 'registry' be some sort of flat text file, or perhaps a zodb
store, or...?
[4] Apart from the fact that I've never written anything other than web-code
(so my python probably isn't up to it), I can't commit time at the moment
due to my degree having to take priority :-(.  If there were any simply
odd-jobs, testing, something I couldn't ballsup, I'd like to help if I can.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )