Zope-Dev September 2005

zope-dev@zope.dev

25 participants
28 discussions

Allowing @ in object ids
by Florent Guillaume 04 Oct '05

04 Oct '05

Today @ is forbidden in object ids. That's controlled by the bad_id regexp in OFS.ObjectManager, which tries to ensure that ids will be useable as URL components. However, there's no reason to disallow this, as the URL spec (http:// www.ietf.org/rfc/rfc1738.txt) says: An HTTP URL takes the form: http://<host>:<port>/<path>?<searchpart> [...] Within the <path> and <searchpart> components, "/", ";", "?" are reserved. The "/" character may be used within HTTP to designate a hierarchical structure. Note that somewhere else in the spec, it says that @ (and others) MAY be reserved by some schemes, but HTTP doesn't actually make it reserved. Furthermore, many projects have monkey-patched bad_id to allow @ and see no ill-effects. Having @ in ids is very useful for various things, one of them being to have email-like identifiers (think jabber for instance). There are other uses. Unless there's opposition, I'll change the code to allow it. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg(a)nuxeo.com

1 1

Can't fetch externals???
by Paul Winkler 30 Sep '05

30 Sep '05

I'm trying to fix a bug assigned to me, and for some reason I can use svn to make and check out my branch but it fails when fetching externals. Anybody else seen this? [pwinkler@dev-zope tmp]$ svn co svn+ssh://slinkp@svn.zope.org/repos/main/Zope/branches/slinkp-collector_1895 A slinkp-collector_1895/Extensions A slinkp-collector_1895/Extensions/README.txt A slinkp-collector_1895/log.ini A slinkp-collector_1895/configure A slinkp-collector_1895/doc .... (SNIP) .... A slinkp-collector_1895/skel/README.txt U slinkp-collector_1895 Checked out revision 38707. Fetching external item into slinkp-collector_1895/doc/ZEO svn: Connection refused svn: Can't connect to host 'svn.zope.org' And then I get the same thing if I do svn up: [pwinkler@dev-zope tmp]$ cd slinkp-collector_1895/ [pwinkler@dev-zope slinkp-collector_1895]$ svn up At revision 38707. Fetching external item into doc/ZEO svn: Connection refused svn: Can't connect to host 'svn.zope.org' -- Paul Winkler http://www.slinkp.com

4 9

problems setting up methods for a product that registers no classes
by Chris Withers 30 Sep '05

30 Sep '05

...zdb in this case. I need to make a "global recompile" function available, since zdb requires the co_filename attribute of the script's func_code object to be set to something meaningful, rather than the useless "Script (Python)" it usually gets set to. Once zdb is installed, any scripts editted will have this set, but I wanted to provide a utility method in a similar vein to python scripts' recompile function that could be globally accesed, however since zdb registers no classes, I ended up having to do some fairly horrific stuff, the following code is from zdb's __init__.py: # recompilation utlitity def initialize(context): # This horrificness is required because Zope doesn't understand the concept # of a Product that doesn't register any classes :-( pack=context._ProductContext__pack fd=getattr(pack, '__FactoryDispatcher__', None) if fd is None: class __FactoryDispatcher__(FactoryDispatcher): "Factory Dispatcher for a Specific Product" fd = pack.__FactoryDispatcher__ = __FactoryDispatcher__ if not hasattr(pack, '_m'): pack._m=fd.__dict__ pack._m['debug_compile'] = debug_compile pack._m['debug_compile__roles__'] = ('Manager',) Now, this breaks in 2.8, so what SHOULD I be doing to make a method globally available in a way that works in both 2.7 and 2.8? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

2 2

Strange security issue with Zope 2.8.1
by Jens Vagelpohl 30 Sep '05

30 Sep '05

I have found a strange security issue with Zope 2.8.1 that seems to stem from code not doing what it was supposed to do in Zope 2.7.x, but which works in 2.8.1 and then causes other side effects in code that relied on the broken behavior. Symptom: In Zope 2.8.1 it is *impossible* to override a ClassSecurityInfo security declaration in an Archetypes-derived content item. (I have a small set of unit tests that proves the behavior under Zope 2.8.1 if anyone is interested) A little background: When you register an Archetypes-derived content type, it will do all the generated accessor/setter method magic and then call InitializeClass a second time. The code in lib/python/App/class_init.py has changed between Zope 2.7.x and Zope 2.8 in order to support new-style classes. To be more precise, instead of manipulating the class __dict__ directly we now use setattr/delattr/etc. This change seems to have "un-broken" code which did not do what the code comments suggest. Namely, when a class is sent through class_init.default_class_init__ (better known as Globals.InitializeClass) the class __dict__ is searched to find objects that look like ClassSecurityInfo instances in order to read and apply the security settings. After finding the ClassSecurityInfo instance, it is force-deleted from the object (the comments say, "out of paranoia"). However, somehow this did not work correctly in Zope 2.7.x, where the deletion call looked like... del dict[key] (dict being the class __dict__, and key being the name of the ClassSecurityInfo instance). Under Zope 2.8, it looks like this: delattr(self, key) (self being the class object). Under Zope 2.7, the security object *would still be there* when hitting InitializeClass for the second time via Archetypes' registerType, which in turn meant Archetypes would not instantiate its own ClassSecurityInfo instance and stuff it with the declarations from whatever Archetypes-derived base class you used. In Zope 2.8, the deletion actually works as intended - but due to that fact Archetypes will instantiate its own ClassSecurityInfo and populate it with the declarations from the base class that I am trying to override. So the overridden settings are all overwritten again by the base class declaration. My question is, what is the reasoning behind deleting the ClassSecurityInfo object from the class after it has been read the first time? How can this be implemented in a sane way so that custom security declarations can be retained? jens

2 2

Broken objects
by Victor Safronovich 29 Sep '05

29 Sep '05

Hello zope-dev! http://www.zope.org/Collectors/Zope/1911 I try to migrate my old database from zope 2.6.1. I have Broken objects, but it is impossible to get its state in Zope 2.8. In Zope 2.6 Broken objects have states, what i uses to migrate its. I think this is because DB.classFactory is overrided to use OFS.Uninstalled.BrokenClass, which is bad persistent class. the __dict__ of all my Broken objects equals to {'_p_changed':None}. my_object._p_mtime does not load it`s state. -- Best regards, Victor Safronovich NauMen.NauDoc.SoftwareDeveloper http://www.naumen.ru

3 9

Re: "'Savepoints unsupported' on uploading files into zope"
by Chris Withers 29 Sep '05

29 Sep '05

lavrinenko wrote: >>>RDB-based user folder? ZSQL methods being used somewhere? > > Yes, exUserFolder with MySQL Authentication Source Try SimpleUserFolder ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

1 0

"'Savepoints unsupported' on uploading files into zope"
by Chris Withers 29 Sep '05

29 Sep '05

lavrinenko wrote: > I suspect the bug is in Image.py, and the whole database adapters thing is a > red herring. > > Either that, or Shared.ZRDB has become geb0rken in 2.8 when it comes to > savepoints. ..or, as another possibility, both the DA's these errors have been reported with haven't been updated to support savepoints, which would make the error message more sensible. Although why the DAs are becoming involved when you're just doing stuff with images is beyond me... RDB-based user folder? ZSQL methods being used somewhere? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

1 0

Re: [Zope-Checkins] SVN: Zope/trunk/lib/python/DocumentTemplate/cDocumentTemplate.c Fix incorrect docstring.
by Chris Withers 28 Sep '05

28 Sep '05

Nah, I refer you instead to the docstring at the top of that file which says it's no longer used and is for reference only. It's already out of synch in implementation, so I don't see any point in fixing this one detail... cheers, Chris Victor Safronovich wrote: > Hello Chris Withers, > > Wednesday, September 28, 2005, 6:48:20 PM, you wrote: > > CW> Log message for revision 38664: > CW> Fix incorrect docstring. > > CW> Changed: > CW> U Zope/trunk/lib/python/DocumentTemplate/cDocumentTemplate.c > > CW> -=- > CW> Modified: Zope/trunk/lib/python/DocumentTemplate/cDocumentTemplate.c > CW> =================================================================== > CW> --- > CW> Zope/trunk/lib/python/DocumentTemplate/cDocumentTemplate.c 2005-09-28 > CW> 11:19:50 UTC (rev 38663) > CW> +++ > CW> Zope/trunk/lib/python/DocumentTemplate/cDocumentTemplate.c 2005-09-28 > CW> 12:48:20 UTC (rev 38664) > CW> @@ -420,10 +420,11 @@ > CW> {"_pop", (PyCFunction) MM_pop, 0, > CW> "_pop() -- Remove and return the last data source added"}, > CW> {"getitem", (PyCFunction) MM_get, METH_VARARGS, > CW> - "getitem(key[,call]) -- Get a value\n\n" > CW> - "Normally, callable objects that can be called without arguments are\n" > CW> - "called during retrieval. This can be suppressed by providing a\n" > CW> - "second argument that is false.\n" > CW> + "getitem(key[,call]) -- Get a value from the MultiDict\n\n" > CW> + "If call is true, callable objects that can be called without arguments are\n" > CW> + "called during retrieval.\n" > CW> + "If call is false, the object will be returns without any attempt to call it.\n" > CW> + "If not specified, call is false by default.\n" > please change pDocumentTemplate.py, where _call_ is true by default. > -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

2 2

Re: SVN: Zope/branches/Zope-2_8-branch/ - Collector #1879: applied patch by Dieter Maurer to fix a bug in
by Florent Guillaume 27 Sep '05

27 Sep '05

This is the kind of thing that would *really* benefit from having unit tests... Florent Andreas Jung <andreas(a)andreas-jung.com> wrote: > Log message for revision 38586: > - Collector #1879: applied patch by Dieter Maurer to fix a bug in > ac_aquire() ignoring the default argument > > > Changed: > U Zope/branches/Zope-2_8-branch/doc/CHANGES.txt > U Zope/branches/Zope-2_8-branch/lib/python/Acquisition/_Acquisition.c > > -=- > Modified: Zope/branches/Zope-2_8-branch/doc/CHANGES.txt > =================================================================== > --- Zope/branches/Zope-2_8-branch/doc/CHANGES.txt 2005-09-24 12:01:37 UTC > (rev 38585) > +++ Zope/branches/Zope-2_8-branch/doc/CHANGES.txt 2005-09-24 12:10:07 UTC > (rev 38586) > @@ -31,6 +31,9 @@ > > Bugs Fixed > > + - Collector #1879: applied patch by Dieter Maurer to fix a bug in > + ac_aquire() ignoring the default argument > + > - Collector #1864, #1906: fixed header normalization in appendHeader() > > - Collector #1899: fixed migration issue when using export/import for > > Modified: Zope/branches/Zope-2_8-branch/lib/python/Acquisition/_Acquisition.c > =================================================================== > --- Zope/branches/Zope-2_8-branch/lib/python/Acquisition/_Acquisition.c > 2005-09-24 12:01:37 UTC (rev 38585) > +++ Zope/branches/Zope-2_8-branch/lib/python/Acquisition/_Acquisition.c > 2005-09-24 12:10:07 UTC (rev 38586) > @@ -1059,6 +1059,7 @@ > PyObject *expl=0, *defalt=0; > int explicit=1; > int containment=0; > + PyObject *result; /* DM 2005-08-25: argument "default" ignored */ > > UNLESS (PyArg_ParseTupleAndKeywords( > args, kw, "O|OOOOi", acquire_args+1, > @@ -1070,12 +1071,34 @@ > > if (filter==Py_None) filter=0; > > + /* DM 2005-08-25: argument "default" ignored -- fix it! */ > +# if 0 > return Wrapper_findattr(self,name,filter,extra,OBJECT(self),1, > explicit || > self->ob_type==(PyTypeObject*)&Wrappertype, > explicit, containment); > +# else > + result = Wrapper_findattr(self,name,filter,extra,OBJECT(self),1, > + explicit || > + self->ob_type==(PyTypeObject*)&Wrappertype, > + explicit, containment); > + if (result == NULL && defalt != NULL) { > + /* as "Python/bltinmodule.c:builtin_getattr" turn > + only 'AttributeError' into a default value, such > + that e.g. "ConflictError" and errors raised by the filter > + are not mapped to the default value. > + */ > + if (PyErr_ExceptionMatches(PyExc_AttributeError)) { > + PyErr_Clear(); > + Py_INCREF(defalt); > + result = defalt; > + } > + } > + return result; > +# endif > } > > + > static PyObject * > Wrapper_inContextOf(Wrapper *self, PyObject *args) > { -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg(a)nuxeo.com

3 2

inheritedAttribute -> super
by Florent Guillaume 27 Sep '05

27 Sep '05

Is there any problem if I change current Zope 2 trunk uses of inheritedAttribute into calls to super ? Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg(a)nuxeo.com

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Zope-Dev September 2005