| *** J1m has quit IRC | 00:06 | |
| *** SteveA has joined #zope3-dev | 00:47 | |
| *** J1m has joined #zope3-dev | 00:53 | |
| *** SteveA has quit IRC | 01:07 | |
| *** stub has joined #zope3-dev | 01:14 | |
| *** zagy has quit IRC | 01:14 | |
| *** benji_york has quit IRC | 01:43 | |
| *** bskahan has quit IRC | 01:44 | |
| *** BradB has quit IRC | 02:09 | |
| *** J1m has quit IRC | 02:10 | |
| *** paolo has joined #zope3-dev | 02:13 | |
| *** paolo has quit IRC | 02:37 | |
| *** jhauser_ has quit IRC | 02:41 | |
| *** mooded has quit IRC | 03:21 | |
| *** stub has quit IRC | 04:19 | |
| *** stub has joined #zope3-dev | 04:20 | |
| *** RaFromBRC has joined #zope3-dev | 04:56 | |
| *** RaFromBRC has quit IRC | 05:15 | |
| *** Suresh-E has joined #zope3-dev | 06:15 | |
| *** BradB has joined #zope3-dev | 06:27 | |
| *** bskahan has joined #zope3-dev | 06:54 | |
| *** tvon has quit IRC | 08:08 | |
| *** tvon has joined #zope3-dev | 08:08 | |
| *** sashav has quit IRC | 09:15 | |
| *** hdima has joined #zope3-dev | 09:18 | |
| *** stub has quit IRC | 09:34 | |
| *** Damascene has quit IRC | 09:36 | |
| *** bskahan has quit IRC | 09:41 | |
| *** agenteo has joined #zope3-dev | 09:47 | |
| *** stub has joined #zope3-dev | 10:00 | |
| *** sashav has joined #zope3-dev | 10:20 | |
| *** zagy_ has joined #zope3-dev | 10:30 | |
| *** mgedmin has joined #zope3-dev | 11:14 | |
| *** MalcolmC has joined #zope3-dev | 11:14 | |
| *** mgedmin has quit IRC | 11:14 | |
| *** SteveA has joined #zope3-dev | 11:14 | |
| *** Aiste has left #zope3-dev | 11:19 | |
| *** mgedmin has joined #zope3-dev | 11:51 | |
| *** mooded has joined #zope3-dev | 11:54 | |
| *** J1m has joined #zope3-dev | 12:31 | |
| *** kaczordek has joined #zope3-dev | 12:48 | |
| *** paolo has joined #zope3-dev | 13:20 | |
| *** agenteo has quit IRC | 13:22 | |
| *** u has joined #zope3-dev | 13:28 | |
| *** u is now known as vlado | 13:30 | |
| *** Voblia has joined #zope3-dev | 13:44 | |
| *** kaczordek has quit IRC | 13:47 | |
| *** mgedmin_ has joined #zope3-dev | 14:44 | |
| *** mgedmin has quit IRC | 14:44 | |
| *** mgedmin_ is now known as mgedmin | 14:44 | |
| *** J1m has quit IRC | 14:49 | |
| *** mooded has quit IRC | 14:51 | |
| *** Suresh-E has left #zope3-dev | 15:04 | |
| *** Voblia has quit IRC | 15:27 | |
| *** Voblia has joined #zope3-dev | 15:27 | |
| *** agenteo has joined #zope3-dev | 15:34 | |
| *** apoirier has joined #zope3-dev | 15:42 | |
| *** regebro has joined #zope3-dev | 15:51 | |
| regebro | Hiya! I just hit a confusing "snag" with zcml on X3.0.0. | 15:52 |
|---|---|---|
| regebro | In a case where I try to reference an interfaces.py with ".interfaces" I got the error message that the module did not have a global "interfaces". | 15:52 |
| regebro | The problem was that there was an error in interface.py which prevented it from being imported. | 15:53 |
| regebro | I quickly suspected that this was the problem, but it does become slightly tricky to debug. | 15:53 |
| regebro | Would it be possible to get a better error message in that case? | 15:54 |
| *** BradB has quit IRC | 16:04 | |
| srichter | regebro: yeah, I have noticed this problem many times before | 16:05 |
| srichter | regebro: it is definitely possible to improve the error message, but it will need some work in zope.configuration | 16:06 |
| srichter | beascially what fails is the field conversion from a string to a Python object | 16:06 |
| srichter | I bet you the configuration code just generically calls these conversion errors; if so there needs to be a special handler for syntax or import errors | 16:06 |
| regebro | srichter: Cool. I couldn't find a collector issue for it. Should I create one? Or maybe you, since you obviously know more about the issue? | 16:08 |
| srichter | regebro: please create one | 16:08 |
| *** BradB has joined #zope3-dev | 16:09 | |
| regebro | Done. http://zope.org/Collectors/Zope3-dev/348 | 16:19 |
| *** mooded has joined #zope3-dev | 16:20 | |
| srichter | thanks | 16:24 |
| *** regebro is now known as regebro-lunch | 16:30 | |
| *** AJC has quit IRC | 16:45 | |
| *** Damascene has joined #zope3-dev | 16:58 | |
| *** stub has quit IRC | 17:13 | |
| *** regebro-lunch is now known as regebro | 17:14 | |
| *** tvon has quit IRC | 17:17 | |
| *** Voblia has quit IRC | 17:18 | |
| *** tav_ has joined #zope3-dev | 17:31 | |
| *** hdima has quit IRC | 17:36 | |
| *** tav has quit IRC | 17:46 | |
| *** tvon has joined #zope3-dev | 17:53 | |
| *** J1m has joined #zope3-dev | 18:00 | |
| *** apoirier has quit IRC | 18:12 | |
| *** vlado has quit IRC | 18:24 | |
| *** AJC has joined #zope3-dev | 18:55 | |
| *** sashav has quit IRC | 18:58 | |
| AJC | does it make sense to have all .css .jpg and other resources served by another server but zope? there would be a faster turn around time with, say, twisted... | 19:01 |
| Theuni | or even apache | 19:03 |
| Theuni | for images and css you could also use special squid rules | 19:03 |
| AJC | squid? | 19:06 |
| Theuni | you can use squid (a caching server / web proxy) to deliver those objects faster | 19:08 |
| AJC | ok, cool. so it does make sense! | 19:09 |
| *** regebro has quit IRC | 19:09 | |
| *** Voblia has joined #zope3-dev | 19:16 | |
| *** mkerrin has joined #zope3-dev | 19:16 | |
| *** mohsen is now known as mohsen-away | 19:20 | |
| *** Voblia has quit IRC | 19:28 | |
| *** paolo has quit IRC | 19:32 | |
| *** Theuni has quit IRC | 19:36 | |
| *** MalcolmC has quit IRC | 19:41 | |
| srichter | J1m: are you there? Do you have a minute? | 19:54 |
| *** __gotcha_ has joined #zope3-dev | 19:57 | |
| J1m | yes | 20:08 |
| srichter | J1m: I have a problem with local roles/permissions | 20:11 |
| srichter | J1m: some functional tests fail because the manager having the local manager role does not work | 20:11 |
| srichter | where should I start looking? | 20:12 |
| *** __gotcha has quit IRC | 20:12 | |
| srichter | zopepolicy.py? | 20:12 |
| srichter | J1m: it must have something to do with my changes, since the tests clearly passed before | 20:13 |
| J1m | brb | 20:15 |
| srichter | ok | 20:15 |
| srichter | ok, I think I got it | 20:16 |
| srichter | the view does not have a parent, so it cannot find the role/permission settings | 20:17 |
| J1m | cool :) | 20:17 |
| srichter | well, it kind of sucks | 20:18 |
| srichter | because no interface describes that | 20:18 |
| srichter | so if someone does not implement BrowserView they will not have a parent | 20:18 |
| srichter | and that means security will be broken | 20:18 |
| J1m | True | 20:18 |
| J1m | It does kind of suck. | 20:18 |
| J1m | I'd like to get to a point though where most adapters, including views are public | 20:19 |
| J1m | If views are public, then this is not an issue. | 20:19 |
| srichter | mmh, interesting | 20:19 |
| srichter | right | 20:19 |
| J1m | This is something I ramble on about toward the end of the current tutorial. | 20:20 |
| J1m | You say: "view does not have a parent, so it cannot find the role/permission settings" | 20:20 |
| J1m | what does that mean? | 20:20 |
| J1m | Is it trying to acquire it? | 20:20 |
| srichter | well, local roles are stored in persistent objects | 20:21 |
| J1m | yes, so? | 20:21 |
| srichter | the way local role and permission settings are found is by looking at the parent | 20:21 |
| srichter | for example you want to do: | 20:21 |
| srichter | checkPermission(myview, 'browserDefault') | 20:21 |
| J1m | Oh, so you are trying to access a view | 20:22 |
| srichter | yes | 20:22 |
| J1m | and the view is proxied. | 20:22 |
| srichter | yes | 20:22 |
| J1m | right | 20:22 |
| J1m | I'll note that this doesn't happen very often. | 20:22 |
| J1m | What is trying to access the view? | 20:23 |
| srichter | usually only if someone implements their own __init__ | 20:23 |
| J1m | Hm? | 20:23 |
| srichter | other views tried to access that view | 20:23 |
| J1m | How did they get it? | 20:23 |
| srichter | I dunno, it's a functional test | 20:23 |
| J1m | hm | 20:24 |
| J1m | I know this comes up some times. | 20:24 |
| srichter | and this sort of thing is very hard to detect too | 20:24 |
| J1m | I wonder why your changes would affect this | 20:25 |
| srichter | because getView always located the view | 20:25 |
| srichter | parent and name | 20:25 |
| srichter | ohh, shoot | 20:26 |
| srichter | there is even more trouble coming, because untrusted adapters need a location too | 20:26 |
| J1m | is the view in question one that wasn't defined via a page directive? | 20:26 |
| srichter | no, it used a page directive | 20:27 |
| srichter | but it implemented its own __init__ | 20:27 |
| J1m | why do untrusted adapters, which we don't have yet, need a location? | 20:27 |
| srichter | which overrides BRwoserView's version | 20:27 |
| J1m | ah | 20:27 |
| srichter | I think I meant trusted ones (which ones are security proxied) | 20:27 |
| J1m | My suggestion was to have the page directives create factories that called the view constructor and then set the parent and name. | 20:28 |
| *** agenteo has quit IRC | 20:28 | |
| srichter | right,... | 20:29 |
| srichter | mmh, oh, I just set the name | 20:29 |
| J1m | ah | 20:29 |
| srichter | because I thought BrowserView was handling the parent | 20:29 |
| srichter | the problem is that the page directives do not create factories, but new types | 20:30 |
| srichter | I guess I could create an additional base class :-( | 20:31 |
| J1m | They use the new types as factories. | 20:31 |
| *** BjornT has quit IRC | 20:31 | |
| J1m | actually, you know the name at that point. You could just set the name as a class attribute | 20:32 |
| srichter | that is what I am doing | 20:32 |
| J1m | wrt parent, you could make __parent__ a property that returns self.context | 20:32 |
| srichter | unless the context is not named self.context :-) | 20:33 |
| srichter | but not a bad idea actually | 20:33 |
| J1m | It has to be for pages | 20:33 |
| srichter | maybe this is what bBrowserView does instead of directly setting it | 20:33 |
| J1m | Anything that has zpt *must* provide a context attr | 20:33 |
| srichter | oh, ok | 20:34 |
| srichter | s/does/should do | 20:34 |
| J1m | where is BrowserView? | 20:34 |
| srichter | zope.app.publisher.browser __init__.py | 20:35 |
| J1m | I hate hiding code in __init__,py :) | 20:35 |
| srichter | :-) | 20:35 |
| J1m | It sets it in the constructor | 20:35 |
| srichter | right | 20:35 |
| J1m | Just change it to use a property | 20:36 |
| srichter | which sometimes gets overridden | 20:36 |
| srichter | yep, will do that | 20:36 |
| srichter | now all hell is breaking loose :-) | 20:37 |
| srichter | I have to be a bit more clever I think | 20:38 |
| J1m | You've been in hell for weeks now | 20:38 |
| srichter | yeah, I was looking forward to the decent to heaven | 20:38 |
| srichter | but the devil pulls on me | 20:38 |
| srichter | ok, this did not solve the entire problem | 20:42 |
| srichter | ok, yipee, it seems fixed | 20:48 |
| srichter | ok, only 12 ftests failures left | 20:49 |
| * VladDrac 's back | 21:20 | |
| *** tvon has quit IRC | 21:21 | |
| *** RaFromBRC has joined #zope3-dev | 21:24 | |
| *** tav_ is now known as tav | 21:39 | |
| *** foom has joined #zope3-dev | 21:39 | |
| foom | I've found what I think is a serious bug in zope.interface's AdapterRegistry | 21:40 |
| foom | http://rafb.net/paste/results/Vf1gl510.html | 21:40 |
| foom | it appears the issue is that adapter.Surrogate doesn't track changes in spec.__bases__ | 21:41 |
| *** d2m has quit IRC | 21:44 | |
| srichter | foom: can you make a unittest out of this? | 21:49 |
| srichter | btw, are you coming to the Python meetup on Thursday? | 21:49 |
| *** bskahan has joined #zope3-dev | 21:50 | |
| srichter | it seems to be a bug of classImplementsOnly | 21:52 |
| srichter | I think we do not use this function in Zope at all, so it might be under-exposed and thus buggy | 21:52 |
| foom | No I'm pretty sure it's a bug in Surrogate | 21:52 |
| foom | it sets __bases__ but doesn't ever change it in response to dirtying | 21:53 |
| foom | i dunno i'm not on python meetup mls. where is it? | 21:53 |
| srichter | Tufts University | 21:53 |
| srichter | you just take the T to Davis | 21:53 |
| srichter | See who's coming and RSVP (it's not too late!): | 21:54 |
| srichter | http://python.meetup.com/48/events/3860264/ | 21:54 |
| srichter | What: Boston Python January Meetup | 21:54 |
| srichter | When: Thursday, January 13 at 7:00PM | 21:54 |
| srichter | Where: Tufts Physics Department | 21:54 |
| srichter | Robinson Hall 200 College Avenue | 21:54 |
| srichter | Medford MA 02155 | 21:54 |
| foom | hm i have to go to springfield tomorrow after work, can't be there. :( | 21:58 |
| srichter | ok | 21:59 |
| srichter | no problemo; it would have just a good oppurtunity to look at the bug together | 21:59 |
| foom | this seems to fix it: http://rafb.net/paste/results/7RXCHU91.html | 22:03 |
| *** tvon has joined #zope3-dev | 22:03 | |
| *** BjornT has joined #zope3-dev | 22:04 | |
| foom | Although I really have no idea what's going on with this code, it's incredibly roundabout and complicated | 22:05 |
| foom | so that may or may not actually be correct. :) | 22:05 |
| *** sashav has joined #zope3-dev | 22:07 | |
| J1m | That looks about right | 22:08 |
| J1m | Are you a contributor? | 22:08 |
| foom | no | 22:09 |
| J1m | OK, could you file a collector issue? | 22:09 |
| foom | how? | 22:10 |
| J1m | http://collector.zope.org/Zope3-dev | 22:10 |
| J1m | We never ran into this because be never modify interfaces or declarations at run time. | 22:11 |
| J1m | An update to adapter.txt would be helpful too. :) | 22:11 |
| foom | you never modify them at runtime? wow. you made an awful lot of framework for handling runtime modification and not even using it? :P | 22:12 |
| J1m | If you have suggestions for making the code less roundabout and complicated, I'm open to suggestions. | 22:12 |
| J1m | <shrug> | 22:13 |
| SteveA | implement it in C so that python programmers don't see it ;-) | 22:13 |
| J1m | I guess I was right to anticipate the need. | 22:13 |
| foom | yep | 22:13 |
| SteveA | works for the "class" implementation in the python runtime ;-) | 22:13 |
| foom | It's good that it's there. I'm just amazed that you implemented it without needing it | 22:14 |
| J1m | We anticipate and have played with persistent interfaces | 22:14 |
| J1m | Which obviously need it. | 22:15 |
| srichter | J1m: might this fix our persistent interface problem? | 22:15 |
| foom | that new user form could do with some error notification isntead of just taking you back to the form with no idea what happened. | 22:15 |
| J1m | srichter, no | 22:16 |
| srichter | ok | 22:16 |
| *** SteveA has quit IRC | 22:19 | |
| foom | done, http://collector.zope.org/Zope3-dev/349 | 22:25 |
| foom | i'd like to request a bugfix release of zope-interface after the bug is fixed, too. | 22:25 |
| J1m | OK | 22:26 |
| *** mgedmin has quit IRC | 22:31 | |
| *** mkerrin has quit IRC | 22:37 | |
| srichter | J1m: did you get anywhere today with your back-wardcompatibility discussion? | 22:40 |
| *** RaFromBRC has quit IRC | 23:00 | |
| *** benji_york has joined #zope3-dev | 23:03 | |
| *** benji_york has joined #zope3-dev | 23:04 | |
| J1m | srichter, yes | 23:23 |
| VladDrac | hmm.. can't subscribe to zope3-checkins from gmail it seems, confirmation mail never arrived | 23:23 |
| VladDrac | anyone seen this before? | 23:23 |
| srichter | J1m: so you wanna share? | 23:23 |
| srichter | :-) | 23:23 |
| J1m | sure | 23:24 |
| J1m | I'd like an api like: | 23:24 |
| J1m | deprecate('foo', 'bar') | 23:24 |
| J1m | This means that the names foo and bar in the current module are deprecated. | 23:25 |
| J1m | Or | 23:25 |
| srichter | I think it needs to be deprecate('foo', 'bar', explanation='some text') | 23:25 |
| J1m | deprecatedModule(explanation) | 23:25 |
| J1m | ok | 23:25 |
| J1m | deprecate(('foo', 'bar'), explanation) | 23:26 |
| srichter | yes | 23:26 |
| VladDrac | decorators! | 23:26 |
| J1m | deprecateNames(('foo', 'bar'), explanation) | 23:26 |
| J1m | no, no decorators | 23:26 |
| J1m | Now, these deprecation functions do the following: | 23:26 |
| J1m | 1. Get the module name (__name__) from the calling frame. | 23:27 |
| J1m | 2. Check to see if sys.modules[name] is a deprecated module. | 23:27 |
| J1m | 3. If it is, then just add the names to the deprecated names for the module. | 23:28 |
| J1m | 4. Otherwise, create a deprecated module of the current module with the given names (or for all names) | 23:28 |
| J1m | A deprecated module is a proxy of the original module with a __getattr__ that generates a warning whenever someone gets a deprecated attr. | 23:29 |
| srichter | sounds good to me | 23:29 |
| J1m | In step 4, of course, the deprecated module gets stuffed into sys.modules. | 23:29 |
| srichter | that should be easy to implement as well | 23:29 |
| J1m | Yup, just needs an implementation. | 23:29 |
| J1m | fairly | 23:30 |
| J1m | Tim and Fred didn't think it was unpythonic in any way. | 23:30 |
| srichter | great | 23:30 |
| srichter | I think this might work for class attributes as well | 23:31 |
| J1m | class attributes should be handled using descriptors | 23:31 |
| srichter | right | 23:31 |
| srichter | where should the imlementation go? | 23:32 |
| srichter | zope.backward :-) | 23:32 |
| J1m | zope.deprecation? | 23:32 |
| srichter | sounds good | 23:33 |
| srichter | what about situations where we change a name? | 23:34 |
| srichter | like IMyService becomes IMyUtility? | 23:34 |
| srichter | I think we should have a nice method for this too | 23:34 |
| J1m | then the old name is deprecated. | 23:34 |
| J1m | We aren't deprecating the object, we're deprecating the name | 23:34 |
| srichter | yes | 23:35 |
| srichter | so | 23:35 |
| srichter | MyService = MyUtility | 23:35 |
| srichter | depcrecateName('MyService', 'explain') | 23:35 |
| J1m | yup | 23:35 |
| srichter | ok | 23:35 |
| J1m | BTW, can we stop putting "Utility" on the end of everything? | 23:36 |
| srichter | I wonder whether we should encode the deprecation date/time with it as well | 23:36 |
| srichter | sure | 23:36 |
| srichter | I found it awkward as well, but could not think of better names | 23:36 |
| J1m | The release in which is goes away should be in the message | 23:36 |
| srichter | ok | 23:36 |
| J1m | Just leave "Utility" off. | 23:36 |
| srichter | ok | 23:37 |
| *** benji_york has quit IRC | 23:41 | |
| srichter | J1m: what if an entire module is deprecated | 23:42 |
| srichter | for example zope.app.utility | 23:42 |
| srichter | when I do `import zope.app.utility`, __getattr__ of zope.app is never called and the deprecation warning is not issued | 23:42 |
| *** benji_york has joined #zope3-dev | 23:49 | |
| AJC | are you guys still on Python 2.3.x or 2.4 | 23:56 |
| Damascene | personally 2.3. i did a fresh activestate instal of 2.4 on another machien though. ;) | 23:57 |
| AJC | for running Zope3 also? | 23:57 |
| srichter | AJC: there are only two tests failing with Py 2.4, which is an easy fix | 23:57 |
| *** J1m has quit IRC | 23:58 | |
| AJC | ok, thanks for the info. | 23:58 |
| AJC | btw, i've written a script for getting twisted to do the vhost redirection to zope instead of apache btw... still need to set everything up on the server ;) | 23:59 |
| Damascene | for zope3, i use 2.3.4 | 23:59 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!