| *** srichter has quit IRC | 00:10 | |
| *** Aiste has quit IRC | 00:13 | |
| *** Aiste has joined #zope3-dev | 00:18 | |
| *** [apoirier] has quit IRC | 00:20 | |
| *** PalmTree has quit IRC | 00:30 | |
| *** hazmat has quit IRC | 00:33 | |
| *** hazmat has joined #zope3-dev | 00:34 | |
| *** J1m has quit IRC | 01:58 | |
| *** niemeyer has quit IRC | 02:03 | |
| *** srichter has joined #zope3-dev | 03:04 | |
| *** ChanServ sets mode: +o srichter | 03:05 | |
| *** lodragan has joined #zope3-dev | 03:08 | |
| *** philiKON has quit IRC | 03:17 | |
| lodragan | hilo | 03:19 |
|---|---|---|
| *** projekt01 has quit IRC | 04:51 | |
| *** hazmat has quit IRC | 04:55 | |
| *** sashav has joined #zope3-dev | 06:15 | |
| *** lodragan has left #zope3-dev | 06:20 | |
| *** `anthony has quit IRC | 06:59 | |
| *** hazmat has joined #zope3-dev | 07:04 | |
| *** hazmat has quit IRC | 07:04 | |
| *** sashav has quit IRC | 07:32 | |
| *** `anthony has joined #zope3-dev | 07:33 | |
| *** zagy has joined #zope3-dev | 08:48 | |
| *** SteveA has joined #zope3-dev | 08:52 | |
| *** stub has joined #zope3-dev | 08:54 | |
| *** vinsci has quit IRC | 08:58 | |
| *** sashav has joined #zope3-dev | 09:00 | |
| *** zagy has quit IRC | 09:07 | |
| *** stub has quit IRC | 09:13 | |
| *** stub has joined #zope3-dev | 09:24 | |
| *** zagy has joined #zope3-dev | 09:24 | |
| *** d2m has quit IRC | 09:30 | |
| zagy | moin | 09:31 |
| SteveA | ciao | 09:47 |
| zagy | hi SteveA :) | 09:55 |
| *** `anthony has quit IRC | 10:27 | |
| *** jproby has joined #zope3-dev | 10:39 | |
| *** vinsci has joined #zope3-dev | 10:49 | |
| *** vinsci has joined #zope3-dev | 10:49 | |
| *** Aiste has quit IRC | 10:51 | |
| *** MalcolmC has joined #zope3-dev | 11:46 | |
| *** vlado has joined #zope3-dev | 11:57 | |
| *** jproby has left #zope3-dev | 11:59 | |
| *** jproby has joined #zope3-dev | 12:10 | |
| *** mgedmin has joined #zope3-dev | 12:48 | |
| *** jproby has left #zope3-dev | 13:07 | |
| *** regebro has joined #zope3-dev | 13:08 | |
| *** philiKON has joined #zope3-dev | 13:10 | |
| *** d2m has joined #zope3-dev | 13:50 | |
| *** stub has quit IRC | 13:56 | |
| *** stub has joined #zope3-dev | 13:57 | |
| *** gintas has joined #zope3-dev | 14:16 | |
| *** `anthony has joined #zope3-dev | 14:24 | |
| *** niemeyer has joined #zope3-dev | 14:50 | |
| *** srichter has quit IRC | 14:51 | |
| *** Aiste has joined #zope3-dev | 14:55 | |
| mgedmin | does the anonymous svn repo lag behind the read-write one? | 15:05 |
| philiKON | uh, i don't think it should | 15:06 |
| mgedmin | no it doesn't | 15:06 |
| mgedmin | must be a stale .pyc file | 15:06 |
| mgedmin | (I got a spurious DeprecationWarning in _field.py) | 15:07 |
| mgedmin | use-commit-times in ~/.subversion/config is contraindicated | 15:10 |
| philiKON | mgedmin, what do you mean? | 15:12 |
| mgedmin | if you say use-commit-times = yes in that config file | 15:13 |
| mgedmin | then when you run svn co/svn up/svn revert | 15:13 |
| mgedmin | subversion sets mtime of files it modifies to the time of the commit | 15:13 |
| mgedmin | which is all very nice | 15:13 |
| philiKON | ok | 15:13 |
| mgedmin | but if you have a .pyc file with mtime greater than the commit time | 15:13 |
| mgedmin | and run svn update | 15:13 |
| mgedmin | python will not notice that the file was changed | 15:14 |
| mgedmin | and will not recompile the .pyc | 15:14 |
| philiKON | aah | 15:14 |
| philiKON | makes sense | 15:14 |
| mgedmin | (I had turned that option on because pyblosxom need stable mtimes, and I keep my blog in subversion) | 15:15 |
| *** danika has joined #zope3-dev | 15:30 | |
| *** srichter has joined #zope3-dev | 15:39 | |
| *** ChanServ sets mode: +o srichter | 15:46 | |
| *** danika has quit IRC | 15:50 | |
| *** sashav has quit IRC | 16:36 | |
| *** J1m has joined #zope3-dev | 17:36 | |
| *** bradb has joined #zope3-dev | 17:37 | |
| *** Aiste has quit IRC | 17:42 | |
| *** mgedmin has quit IRC | 17:45 | |
| J1m | Hey folks | 17:52 |
| J1m | In the past, I suggested that implements and adapts could also be used as decorators outside of classes. | 17:53 |
| J1m | I looked at this last night and ran into a problem. | 17:53 |
| SteveA | decorators? | 17:54 |
| SteveA | oh, like, to state that some class elsewhere implements something | 17:54 |
| J1m | We said that these would work only in a class statement or in a global context (locals is globals), but I have a case where I want to declare the interfaces implemented by a comuted factory | 17:54 |
| J1m | decorators in the Python 2.4 sense | 17:54 |
| J1m | as in: | 17:54 |
| J1m | @implements(I) | 17:54 |
| J1m | def foo(): ... | 17:55 |
| SteveA | oh, those | 17:55 |
| SteveA | i'm not using 2.4 in production yet because it is not in the ubuntu stable distro release | 17:55 |
| J1m | I think the idea of having these functions used the way they are now and as decorators is too fragile. | 17:55 |
| SteveA | my sysadmin said "no." | 17:55 |
| vlado | fyi, pje has decorators for 2.3 | 17:55 |
| J1m | I think we need separate functions. | 17:55 |
| SteveA | vlado: written inside the class suite? | 17:56 |
| J1m | I want these functions to be usable as decorators in 2.4, even though we'll have to use an ickier syntax for now. | 17:56 |
| SteveA | J1m: trouble picking up the context magically by looking at the stack of frames? | 17:56 |
| J1m | I think it's just too magic. | 17:57 |
| J1m | I want to be able to use these in cases where globals() is not locals() | 17:57 |
| SteveA | like, classes defined inside a function | 17:57 |
| SteveA | or in a doctest ? | 17:57 |
| J1m | so the only way to know if we're in a class definition is to look for __module__. | 17:57 |
| J1m | No, as in a function that computes a factory | 17:58 |
| vlado | SteveA, class suite ? | 17:58 |
| J1m | The factory isn't a class. | 17:58 |
| SteveA | vlado: indented inside a class statement. | 17:58 |
| SteveA | J1m: okay, i follow. | 17:58 |
| J1m | Also, standard decorators like classmethod and staticmethod are nouns. | 17:59 |
| J1m | So, I suggest "implementor" and "adapter", as in: | 17:59 |
| J1m | def foo(): ... | 17:59 |
| J1m | implementor(I)(foo) | 17:59 |
| J1m | 17:59 | |
| J1m | in Python 2.4: | 17:59 |
| J1m | @implementor(I) | 18:00 |
| J1m | def foo(): .. | 18:00 |
| J1m | 18:00 | |
| philiKON | well, the most common usecase would still be aclass, right? | 18:00 |
| philiKON | @implementor(IFile) | 18:00 |
| J1m | No | 18:00 |
| philiKON | class File | 18:00 |
| philiKON | no? | 18:00 |
| *** bradb has quit IRC | 18:00 | |
| J1m | well, first, Python doesn't have class decorators yet. | 18:00 |
| J1m | Second, I find: | 18:01 |
| J1m | class File: | 18:01 |
| J1m | implements(IFile) | 18:01 |
| J1m | 18:01 | |
| J1m | more readable. | 18:01 |
| philiKON | same here | 18:01 |
| vlado | SteveA, | 18:01 |
| vlado | """Use Python 2.4 decorators w/Python 2.2+ | 18:01 |
| vlado | Example: | 18:01 |
| vlado | import dispatch | 18:01 |
| J1m | This is really for the increasingly important case of factories that are not classes. | 18:01 |
| vlado | class Foo(object): | 18:01 |
| vlado | [dispatch.as(classmethod)] | 18:01 |
| vlado | def something(cls,etc): | 18:01 |
| vlado | \"""This is a classmethod\""" | 18:01 |
| vlado | """ | 18:01 |
| J1m | Or for subscribers. | 18:01 |
| SteveA | vlado: okay. thanks | 18:02 |
| philiKON | ah, right, foo would just be a factory, it'd "implement" something because stuff that it pops out provides it | 18:02 |
| J1m | Or even: | 18:02 |
| J1m | @handler(IFile, IObjectModifiedEvent) | 18:03 |
| srichter | yes, this is also very important for documentation | 18:03 |
| J1m | def do_x_when_file_modified(file, event): ... | 18:03 |
| SteveA | not @handlor? ;-) for consistency with @implementor | 18:03 |
| philiKON | J1m, that's the equivalent of adapts()? | 18:03 |
| J1m | philiKON, not quite. It would also somehow note that we don't return anything. | 18:04 |
| J1m | We do all of the work in the call. | 18:04 |
| philiKON | ah, ok | 18:04 |
| philiKON | btw, does adapts() already support multiadapters? | 18:04 |
| J1m | SteveA, do you have an alternate spelling of implementor? Did I spell it wrong? | 18:04 |
| SteveA | I don't see why it is hard to disambiguate between use of implements() in an class suite and use of implements() as a decorator. The result of the former is not called, the result of the latter is. | 18:05 |
| J1m | philiKON, Of course | 18:05 |
| SteveA | J1m: I always get confused between implementer/implementor and similar cases. I've seen docs that confuse adapter/adaptor. | 18:05 |
| J1m | SteveA, then interface specifications (or at least implements specifications) would have to be called. | 18:05 |
| J1m | They can't really do anything when they aren't called. | 18:05 |
| J1m | SteveA, then interface specifications (or at least implements specifications) would have to be callable. | 18:06 |
| J1m | It still feels very brittle to me. | 18:06 |
| philiKON | +1 for keeping implements and implementor separate things | 18:06 |
| J1m | Plus, in the in-class case, they have to do the advice magic, which stuffs a __metaclass__ into locals. | 18:06 |
| philiKON | one is a decorator, one mangles with f_local and what not | 18:06 |
| SteveA | philiKON: your arguments are compelling thinking from the point of view of someone who implements these things. I'm not so sure they are valid from the point fo view of a user of these things. | 18:07 |
| J1m | I think it's clearer from the user's point of view too. | 18:07 |
| SteveA | that's the argument that counts for me | 18:08 |
| J1m | You'd have a single name that would have two extremely different usages. | 18:08 |
| philiKON | SteveA, i didn't tell you what my arguments were | 18:08 |
| philiKON | :) | 18:08 |
| J1m | The user might see: | 18:08 |
| J1m | 18:08 | |
| J1m | def foo(): | 18:08 |
| J1m | ... | 18:08 |
| SteveA | philiKON: okay, you can buy me a beer at EP2005 and tell me all your arguments ;-) | 18:08 |
| J1m | implements(I)(foo) | 18:08 |
| J1m | 18:08 | |
| J1m | and | 18:08 |
| philiKON | SteveA, hehe :)... if i ever make it to EP2005 | 18:09 |
| J1m | 18:09 | |
| J1m | class Foo: | 18:09 |
| J1m | implements(IFoo) | 18:09 |
| J1m | 18:09 | |
| SteveA | @implementing(IFoo) ; def foo(...) | 18:09 |
| J1m | and somehow understand why these two usages are different. | 18:09 |
| SteveA | @implement(IFoo) ; def foo(...) # PEP-257 style imperative language | 18:09 |
| J1m | Also, note that: | 18:10 |
| J1m | @implementor(I) | 18:10 |
| J1m | class X: ... | 18:10 |
| J1m | 18:10 | |
| J1m | would be equivalent to: | 18:10 |
| J1m | 18:10 | |
| J1m | class X: ... | 18:11 |
| J1m | classImplementsOnly(I) | 18:11 |
| J1m | 18:11 | |
| philiKON | btw, i'm wondering (i don't know enough of that majyck going on in implements()), why can't we say: | 18:11 |
| philiKON | def foo(): | 18:11 |
| philiKON | implements(I) | 18:11 |
| philiKON | ? | 18:11 |
| J1m | Because: | 18:11 |
| SteveA | J1m: why? | 18:11 |
| SteveA | J1m: why the classImplementsOnly(I) ? | 18:12 |
| J1m | 1. The foo suite is executed at foo usage time, not foo definition time | 18:12 |
| philiKON | ah, right | 18:12 |
| J1m | 2, Python doesn't let is introspect function innards without far deeper voodoo than I'm willing to consider. | 18:12 |
| J1m | SteveA, because I think this thing should have the same semantics for classes as for functions and other factiries. | 18:13 |
| SteveA | dictionary.reference.com says implementor and implementer are equivalent | 18:13 |
| philiKON | so maybe they shoudl be aliases to the same thing? | 18:13 |
| SteveA | bytecodehacks! | 18:13 |
| J1m | Hm, I dodn't realize that implementer was a word | 18:13 |
| SteveA | OOTDI | 18:14 |
| SteveA | http://dictionary.reference.com/search?q=implementor | 18:14 |
| J1m | philiKON, no, because decorators have a different syntax. | 18:14 |
| philiKON | i meant implementer and implementor | 18:14 |
| philiKON | not implementor and implements | 18:14 |
| philiKON | i see SteveA's point about people mixing -or and -er endings for implementor, adaptor, etc. etc. | 18:15 |
| philiKON | though zope.component and the rest of z3 has definitely chosen adapter, so we might as well chose one of the others for real | 18:15 |
| J1m | dictionary.reference.com doesn't have an entry for implementer. | 18:15 |
| SteveA | J1m: why is following inheritence for implementor for classes a problem for use in functions, where there is no inheritence? sounds like standard liskov substitutable polymorphic behaviour to me. | 18:16 |
| SteveA | ... if you consider classes to be a specialized kind of factory | 18:16 |
| SteveA | J1m: metioned at the bottom of the implementor page | 18:16 |
| J1m | I see that, but it still doesn't have an entry. | 18:17 |
| SteveA | i just asked someone here | 18:17 |
| SteveA | he spelled it "implementor" as a first guess. google's spelling suggester (suggestor) suggests implementer | 18:18 |
| J1m | But both emacs and mozilla consider implementer to be correct spellings. :) | 18:18 |
| SteveA | farm, farmer, farmor | 18:18 |
| SteveA | arm, armer, armor | 18:18 |
| J1m | I'm OK with implementer | 18:18 |
| SteveA | in british, it might have to be implementour ;-) | 18:18 |
| philiKON | lol | 18:18 |
| SteveA | as armor is armour, color is colour | 18:19 |
| philiKON | i still write like that. that's the way i learned it in school here :) | 18:19 |
| J1m | OK, so, I'll let implementer(I)(cls) === classImplements(cls, I) | 18:20 |
| SteveA | J1m: I like the sound of imperatives: implement(I), handle(...), report(...), confess(...) | 18:20 |
| SteveA | although implement() is a bit close to implements() | 18:20 |
| philiKON | SteveA, but a) no nouns and b) implement() and adapt() look a lot like implements() and adapts() | 18:20 |
| SteveA | and i dislike too-closely-similar things | 18:20 |
| philiKON | right | 18:20 |
| SteveA | philiKON: it isn't used as a noun. "You! Implement this!" | 18:21 |
| J1m | I do too, but I think we need different names and Python *does* use nouns for it's decorators. | 18:21 |
| philiKON | SteveA, right, that was the point. all decorators so far are nouns | 18:21 |
| SteveA | okay | 18:21 |
| *** mooded has joined #zope3-dev | 18:21 | |
| SteveA | if only guido was a linguist like larry wall. | 18:22 |
| SteveA | ;-) | 18:22 |
| J1m | OK, I'll go ahead and do implementer and adapter, which will work as decoraters in 2.4. | 18:22 |
| J1m | :) | 18:22 |
| SteveA | okay | 18:22 |
| philiKON | both importable from the samel ocation as implements() and adapts(), respecively? | 18:22 |
| SteveA | can we have adaptee() for use on interfaces? | 18:22 |
| J1m | yes | 18:22 |
| philiKON | lol | 18:22 |
| philiKON | implementee() | 18:22 |
| SteveA | handlee | 18:23 |
| SteveA | this is getting sillee | 18:23 |
| SteveA | and I have more specs to review. | 18:23 |
| SteveA | thanks folks. | 18:23 |
| * philiKON returns back to electrodynamics | 18:23 | |
| * J1m goes if to implement this. | 18:24 | |
| SteveA | (if only guido was a linguist like adele goldburg) | 18:26 |
| J1m | :) | 18:28 |
| srichter | J1m: I have a tricky case of BBB | 18:30 |
| J1m | ok | 18:30 |
| srichter | J1m: our ServiceManagerContainer has an attribute called __sm | 18:30 |
| srichter | Now, I renamed ServiceManagerContainer to SiteManagerContainer | 18:30 |
| srichter | and it will not find __sm anymore | 18:30 |
| srichter | this is because | 18:30 |
| srichter | __sm got stored as _ServiceManagerContainer__sm | 18:31 |
| J1m | Yes another reason why Python got private attributes wrong. :( | 18:31 |
| srichter | and now this variable is called _SiteManagerContainer__sm | 18:31 |
| J1m | OK, fro now on, no more __. | 18:31 |
| srichter | so, what's best approach? have a custom __setstate__ method? | 18:32 |
| J1m | It would be nice if someone added this to the style guide. | 18:32 |
| J1m | No | 18:32 |
| srichter | what then? make it a property? | 18:32 |
| J1m | I would create a *read* descriptor for it that tries to get it via the old name. | 18:33 |
| philiKON | why not a database evolvement script so that old databases will always work in the future, even if that BBB is removed some day | 18:33 |
| srichter | I can't | 18:33 |
| srichter | because Zope will not even start up | 18:33 |
| J1m | philiKON, he needs that too. | 18:33 |
| philiKON | ok | 18:34 |
| J1m | You need an evolution script to fix this, but you also need to make it work without the script. | 18:34 |
| srichter | a lot of code expects the root folder to have a site manager right away | 18:34 |
| srichter | right | 18:34 |
| J1m | srichter, Use zope.cachedescriptors.property.Lazy | 18:35 |
| *** gintas has quit IRC | 18:35 | |
| J1m | Read descrs have the nice property that they are overridden by instance attrs | 18:35 |
| J1m | (no pun indented ;) | 18:35 |
| srichter | ok | 18:36 |
| srichter | how do LAzy properties work? | 18:36 |
| J1m | Read the documentation. :) | 18:37 |
| srichter | __sm = Lazy(lambda x: x._ServiceManageContainer, '__sm') | 18:37 |
| srichter | ? | 18:37 |
| srichter | oh, I see | 18:38 |
| srichter | actually, I will not need an evolve script for this | 18:42 |
| srichter | the lazy property does the necessary work | 18:42 |
| philiKON | but then we'll have to keep that code in there until the dawn of mankind | 18:43 |
| srichter | nope | 18:43 |
| srichter | lazy property automatically sets the value after the first lookup | 18:43 |
| philiKON | ah, nice | 18:43 |
| J1m | Hm, I'd forgotten about that. :) | 18:44 |
| J1m | You still want the evolution. | 18:44 |
| srichter | and all site managers are called by all other evolve scripts before, so they all have been converted | 18:44 |
| J1m | ah | 18:44 |
| J1m | k | 18:44 |
| J1m | so you will have evolution, for free. | 18:44 |
| srichter | yes :-) | 18:44 |
| philiKON | question is, why don't we use this opportunity and get rid of the __ attribute alltogether | 18:44 |
| philiKON | and make it _sm | 18:45 |
| philiKON | or something like that | 18:45 |
| J1m | Good point. | 18:45 |
| srichter | you do that :-) my goal is to get Zope runnoing with old DBs now and merge my branch | 18:45 |
| srichter | I want to take the path of least resistence for now | 18:45 |
| J1m | Especially since I just gave an edict that we wouldn't use private underwere anymore. ;) | 18:45 |
| srichter | I am getting very tired of this project | 18:45 |
| srichter | :-) | 18:45 |
| philiKON | Umm, would it be so much harder making the new property _sm than __sm? | 18:46 |
| srichter | probably not; I am just not taking the chance that soemthing weird is going to happen | 18:47 |
| philiKON | i sure like to do it, but i'm having big exams coming up; i shouldn't even be wasting brain cells on zope right now ;) | 18:48 |
| srichter | okay, okay, I did ot | 18:48 |
| srichter | yeah, E&M sucks! :-) | 18:48 |
| philiKON | you're my hero :) | 18:48 |
| philiKON | got oral exams (vordiplom) coming up in ExpPhy and TheoPhy | 18:48 |
| srichter | I see | 18:48 |
| srichter | it's so different in Germany | 18:49 |
| srichter | here everything is sorted by area | 18:49 |
| philiKON | hmm | 18:49 |
| philiKON | well, the whole carreer is different, with bachelor/master and all that | 18:50 |
| philiKON | but we'll be getting that in 2-3 years i think | 18:50 |
| philiKON | i still like the old system | 18:50 |
| srichter | J1m: ok, so now I passed the initial hurdle, but now I get some TypeError | 18:51 |
| srichter | TypeError: Cache values must be persistent objects. | 18:52 |
| srichter | philiKON: the old system totally isolates Germany from the rest of the world; and Germany is not the leading nation in science anymore (I think partially because of this), so they cannot afford to be different | 18:53 |
| * J1m wonders if srichter is going to provide more context than that | 18:53 | |
| srichter | J1m: ok | 18:53 |
| philiKON | srichter, that's the only reason i support the switch to the new system. that doesn't mean that I have to *like* it better than the old | 18:54 |
| srichter | utils = [reg for reg in sm.utilities.registrations() | 18:54 |
| srichter | File "/opt/zope/Zope3/Zope3-CA/src/ZODB/Connection.py", line 814, in setstate | 18:54 |
| srichter | self._setstate(obj) | 18:54 |
| srichter | File "/opt/zope/Zope3/Zope3-CA/src/ZODB/Connection.py", line 868, in _setstate | 18:54 |
| srichter | self._reader.setGhostState(obj, p) | 18:54 |
| srichter | File "/opt/zope/Zope3/Zope3-CA/src/ZODB/serialize.py", line 407, in setGhostState | 18:54 |
| srichter | state = self.getState(pickle) | 18:54 |
| srichter | File "/opt/zope/Zope3/Zope3-CA/src/ZODB/serialize.py", line 400, in getState | 18:54 |
| srichter | return unpickler.load() | 18:54 |
| srichter | File "/opt/zope/Zope3/Zope3-CA/src/ZODB/serialize.py", line 485, in _persistent_load | 18:54 |
| srichter | self._cache[oid] = obj | 18:54 |
| srichter | TypeError: Cache values must be persistent objects. | 18:54 |
| srichter | the only weird thing there is that sm is now retrieved using this lazy property, but I still do not see how this causes problems | 18:55 |
| srichter | oh, I think I know | 18:55 |
| srichter | this might still be an SM of the old kind; I guess that sm.utilitites is tried to be pickled and can't be | 18:55 |
| J1m | There error message indicates an object that used to be persistent, but isn't anymore. | 18:56 |
| J1m | The error message indicates an object that used to be persistent, but isn't anymore. | 18:56 |
| srichter | ahh, ok | 18:56 |
| srichter | mmh, there are plenty of candidates | 18:57 |
| J1m | Use your friend | 18:57 |
| srichter | yep | 18:58 |
| *** Aiste has joined #zope3-dev | 19:00 | |
| J1m | sigh | 19:03 |
| J1m | I'm blocked by the freeze | 19:03 |
| J1m | srichter, when will we be thawed? | 19:03 |
| *** mgedmin has joined #zope3-dev | 19:04 | |
| srichter | It depends on the obstacles | 19:05 |
| srichter | but I think I will just get this database I have working and throw it out there | 19:05 |
| J1m | An indefinite freeze is unsat | 19:05 |
| srichter | I can remove the last XXXs after the merge | 19:05 |
| srichter | so I hope I will finish over the weekend | 19:05 |
| srichter | J1m: you can always make the change in the trunk and the branch | 19:06 |
| srichter | then I don't care what you change | 19:06 |
| J1m | How would it help to make the change on the branch? | 19:06 |
| J1m | Generally it | 19:07 |
| srichter | because I do not have to worry about correct merges | 19:07 |
| J1m | Generally it's a bad idea to make a change both on a branch and on the trunk. | 19:07 |
| srichter | and with conflicts I can just use the working version | 19:07 |
| J1m | Merging is usually harder with duplicate changes. | 19:07 |
| srichter | usually, not here :-) | 19:07 |
| srichter | I agree though | 19:08 |
| philiKON | srichter, i don't think J1m addinig something (not modifying) shouldn't affect your work on the branch nor your merging | 19:08 |
| J1m | Can I just delete a test assertion from a test in zope.app.component.tests.test_factory? | 19:08 |
| srichter | but because the diff utilities break down I have no reliable merges anmore | 19:08 |
| srichter | with the last sync I had to go through each revision manually and make sure it worked | 19:08 |
| srichter | sure I think I can handle that | 19:09 |
| J1m | k, thanks | 19:09 |
| srichter | philiKON: adding is bad too | 19:09 |
| srichter | a bunch of stuff has moved so even additions hurt (badly) | 19:10 |
| J1m | srichter, I was mistaken | 19:25 |
| *** tvon has joined #zope3-dev | 19:26 | |
| J1m | implementedBy will now always suceed for callables. | 19:26 |
| srichter | J1m: oh, for above; ok | 19:26 |
| J1m | I want to remove the feature from zope.component.factory that tries to support objects for which implementedBy fails. | 19:26 |
| J1m | Since it will no longer fail for a callable. | 19:27 |
| srichter | oh, I see | 19:27 |
| J1m | So I'm removing that feature and it's tests. | 19:27 |
| srichter | ok | 19:27 |
| *** vlado has quit IRC | 19:28 | |
| srichter | darn this sucks | 19:28 |
| srichter | so old instances of the site manager do not have a utilitities attribute | 19:28 |
| srichter | so sm.utiltities fails | 19:28 |
| srichter | but instead of a attribute error I get this TypeError about cached values | 19:29 |
| srichter | so I added a lazy property to provide this attribute and still no luck | 19:29 |
| *** alga has joined #zope3-dev | 19:30 | |
| srichter | I am wondering if I should try to convert old SMs at all and just store them in a temp variable until the evolve script is applied; at this point I will copy all the data | 19:31 |
| srichter | J1m: when an object is loaded from a pickle, is __init__ called? (I would say no) | 19:32 |
| mgedmin | srichter, no | 19:33 |
| srichter | yeah, so now the question is why the persistence framework has a state for this attribute (or thinks it does) | 19:35 |
| srichter | even worse, it makes my Python stop without recovery of the prompt | 19:36 |
| J1m | Has a state for what attribute? | 19:37 |
| mgedmin | could it be a class attribute? | 19:37 |
| J1m | I don't know what you are saying. | 19:37 |
| srichter | mgedmin: no, I checked | 19:38 |
| srichter | J1m: well, the ZODB thinks it has a state for sm.utilities | 19:39 |
| srichter | but this is impossible | 19:39 |
| * mgedmin sometimes dreams about a through-the-web zodb object inspector that would show contents of pickles with hyperlinks to other persistent objects | 19:39 | |
| mgedmin | srichter, you said something about a lazy property | 19:39 |
| mgedmin | properties are class attributes | 19:40 |
| mgedmin | or does zodb try to assign something to a read-only property? | 19:40 |
| srichter | yeah, but I added those lazy properties after the error already occured (as a possible fix) | 19:40 |
| J1m | What do you mean "it has a state for sm.utilities"? | 19:43 |
| srichter | well, it seems the ZODB tries to load the attribute 'utilitities' from the pickle | 19:44 |
| srichter | oh, I see now | 19:45 |
| srichter | it actually finds something else | 19:45 |
| srichter | so apparently, once you try to access an objcet's attribute it tries to load them all | 19:45 |
| *** MalcolmC has quit IRC | 19:45 | |
| J1m | yes | 19:45 |
| *** benji_york has joined #zope3-dev | 19:45 | |
| J1m | It tries to change state from "ghost" to "saved" | 19:45 |
| srichter | so in this case the RegistrationStack was among them which in my version was not persistent of course | 19:45 |
| srichter | I see | 19:46 |
| *** J1m is now known as J1m|lunch | 19:46 | |
| *** bskahan has joined #zope3-dev | 19:51 | |
| *** J1m|lunch is now known as J1m | 20:03 | |
| srichter | I HATE PRIVATE ATTRIBUTES!!!!!!!!!!!!!!! ARG | 20:08 |
| philiKON | let's not give srichter Guido's home address, people might get hurt ... | 20:10 |
| srichter | :-) | 20:10 |
| srichter | Lazy properties rectify this a bit (but jsut a little tiny bit ;-) | 20:10 |
| srichter | I hope I will make better progress once Zope starts up with an old database | 20:11 |
| *** regebro has quit IRC | 20:35 | |
| srichter | yes, Zope starts! :-) | 20:45 |
| *** mooded has quit IRC | 20:47 | |
| *** Aiste has quit IRC | 21:22 | |
| Voblia | i was playing with locale.date.formatter and og this stuff: | 21:25 |
| Voblia | http://www.mif.vu.lt/~igmi1451/test.txt | 21:25 |
| Voblia | should the default locale work this way ? | 21:26 |
| Voblia | I mean u'1' does not look like "Sun" to me ... | 21:26 |
| philiKON | question is what TestRequest.locale really is | 21:27 |
| Voblia | well i would assume that it uses "C" | 21:28 |
| philiKON | request.locale != system locale | 21:28 |
| philiKON | my guess is that TestRequest.locale is some stub locale | 21:28 |
| philiKON | that doesn't provide any useful data for the locale formatters from zope.i18n.locales | 21:29 |
| Voblia | I see | 21:30 |
| mgedmin | I think deliberately providing misleading data is a bug | 21:31 |
| Voblia | and how one could provide a sensible locale | 21:31 |
| Voblia | for testing purposes | 21:31 |
| philiKON | Voblia, i would look at how zope.publisher does it | 21:31 |
| philiKON | mgedmin, what are you suggesting? | 21:31 |
| mgedmin | sensible data in the stub locale | 21:32 |
| philiKON | Voblia, it must have some fall-back locale and it must somehow get a hold of the locale objects from zope.i18n.locale | 21:32 |
| philiKON | mgedmin, fair enough. sounds like a cool project for Voblia, eh ;) | 21:32 |
| srichter | 1 == Sun in the default locale | 21:32 |
| srichter | because the default locale is based on the US locale | 21:32 |
| srichter | it is also not misleading, it is just the default ICU decided to have | 21:33 |
| philiKON | what's the formatstring "E" anyway? weekday? | 21:33 |
| mgedmin | eek! | 21:33 |
| srichter | philiKON: Can't remember, but I am pretty sure it is documented in zope.i18n.locales.formatter | 21:34 |
| mgedmin | if it is based on the US locale, why doesn't it say "Sun"? | 21:34 |
| philiKON | clj.d | 21:34 |
| philiKON | err | 21:34 |
| philiKON | homerow | 21:34 |
| Voblia | srichter, if you would take a look at the text file then you get '7' twice and u'1' after that | 21:34 |
| philiKON | couldn't it be that the formatting strings are just applied wrong? | 21:35 |
| srichter | mgedmin: no, the code 1 stands for Sunday | 21:35 |
| philiKON | i mean, i've never seen this multiple "E" thingy | 21:35 |
| srichter | if you ask the formatter to display EEE you get "Sun" | 21:35 |
| * philiKON only knows the regular strftime() notation | 21:35 | |
| philiKON | srichter, apparently you don't (see textfile) | 21:35 |
| srichter | philiKON: it is the ICU notation that is also used commonly in spreadsheet applications such as Excel, .... | 21:36 |
| philiKON | hmm, ok... i thought spreadsheets use #### | 21:36 |
| philiKON | but whatever | 21:36 |
| mgedmin | srichter, did you look at http://www.mif.vu.lt/~igmi1451/test.txt ? | 21:36 |
| mgedmin | "E" returns 7, "EEE" returns 1 | 21:36 |
| mgedmin | for the same date | 21:36 |
| srichter | that's bad | 21:36 |
| srichter | this is a bug | 21:36 |
| * mgedmin whishes Voblia's snipped included all the imports | 21:37 | |
| srichter | ('E', 1): str(weekday), | 21:37 |
| srichter | ('E', 2): "%.2i" %weekday, | 21:37 |
| srichter | ('E', 3): calendar.days[weekday][1], | 21:37 |
| srichter | ('E', 4): calendar.days[weekday][0], | 21:37 |
| srichter | so E should be 1, EE be 01, EEE be "Sun, and EEEE be "Sunday" | 21:38 |
| srichter | this is from zope.i18n.format | 21:38 |
| mgedmin | that would be sensible | 21:38 |
| srichter | this is definitely a bug | 21:39 |
| srichter | it seems that calendar.days does not return the right thing | 21:39 |
| mgedmin | actually, "E" returns 7, not 1 | 21:39 |
| *** mexiKON has joined #zope3-dev | 21:39 | |
| srichter | let me check the default locale though | 21:39 |
| srichter | hold on | 21:39 |
| *** Voblia is now known as Awayblia | 21:40 | |
| srichter | ok, so the default locale has "1" for "EEE" and "EEEE" | 21:40 |
| srichter | so I am not sure where the 7 comes from | 21:40 |
| srichter | eek, and "E" and "EE" should be 1, if it really uses the root locale | 21:41 |
| srichter | oh, this is clearly a bug in the formatting code | 21:42 |
| srichter | it does not take the "firstDay" element setting into account | 21:42 |
| mgedmin | does this mean that in real life, if the browser does not send an Accept-Language header, weekdays will be displayed as numbers? | 21:44 |
| srichter | yes, because then the browser does not know what language you have | 21:44 |
| mexiKON | if you use that formatting code, i guess | 21:44 |
| mexiKON | i've never had a problem with other formatting options | 21:44 |
| srichter | of course you could change the adapter choosing the locale | 21:44 |
| mgedmin | then I do not want to use that formatting code | 21:44 |
| mgedmin | ever | 21:44 |
| mexiKON | :) | 21:44 |
| mgedmin | how do I know if Monday is 0 like in Python, 1 like it seems natural for me, or 2 like Zope 3's standard locale? | 21:45 |
| mgedmin | if I am just a hapless user | 21:45 |
| srichter | you can always make en the default instead | 21:45 |
| mgedmin | does ICU require this? | 21:46 |
| srichter | mgedmin: it is not Zope 3, all of ICU and thus Java uses this standard | 21:46 |
| * mgedmin is baffled | 21:46 | |
| srichter | and that's only for your locale data | 21:46 |
| mgedmin | "Sun" etc. was good enough for the default C/POSIX locale | 21:46 |
| *** philiKON has quit IRC | 21:46 | |
| mgedmin | perhaps there is a good reason to move to ambiguous numbers | 21:47 |
| srichter | yeah, because they were US centric | 21:47 |
| mgedmin | I'd just like to know that reason | 21:47 |
| srichter | well, Sunday is 1, iff the firstDay option is set to "sun" | 21:47 |
| srichter | ICU locales never start counting at 0 | 21:47 |
| srichter | mgedmin: what is the Lithuanian locale shortcut? | 21:48 |
| mgedmin | what do you mean by "locale shortcut"? | 21:49 |
| srichter | lt | 21:49 |
| mgedmin | yes | 21:49 |
| srichter | so in lt.xml, the firstDay = "mon" | 21:49 |
| srichter | so for "lt" you have "sun" being the seventh day | 21:49 |
| mgedmin | I'm not complaining about E/EE returning different numbers in different locales | 21:51 |
| mgedmin | I was surprised that EEE/EEEE returns a number instead of a name in the default locale | 21:51 |
| srichter | yeah, but the really bad thing is that the numbers are different, which they should not | 21:52 |
| mgedmin | uhh | 21:53 |
| mgedmin | >>> formatter.format(date(2004, 10, 31), "EEEE, DD MMMM YYYY") | 21:53 |
| mgedmin | gives me an exception | 21:53 |
| mgedmin | TypeError: coercing to Unicode: need string or buffer, tuple found | 21:53 |
| srichter | eek | 21:53 |
| srichter | can someone please make a bug report to this effect | 21:54 |
| srichter | I'll check all failures and wrong doings out as soon as my branch is merged | 21:54 |
| mgedmin | ok | 21:55 |
| srichter | of course, feel free to check some of this stuff out yourself ;-) | 21:55 |
| mgedmin | by the way, is there a locale-aware way to say things like "3rd Monday of a week"? | 22:01 |
| mgedmin | formatter.format(..., "F EEEE") returns "3 2" with the default formatter, which should explain my initial amazement and confusion | 22:02 |
| srichter | you mean 3rd Monday of a month, right? | 22:06 |
| mgedmin | err, yea | 22:06 |
| srichter | mhh, F seems to be about timezones | 22:07 |
| srichter | it is currently hardcoded to be 2 | 22:07 |
| mgedmin | " F day of week in month (Number) 2 (2nd Wed in July)" | 22:07 |
| mgedmin | that's what IDateFormatter says | 22:07 |
| srichter | for some reason I did not implement it | 22:08 |
| mgedmin | err, IDateTimeFormat | 22:08 |
| srichter | ok, so this is right, but it is not implemented for some reason; I wonder why | 22:08 |
| srichter | see zope.i18n.format, line 576 | 22:08 |
| mgedmin | you're right, it always returns 2 | 22:08 |
| srichter | mmh, I guess the datetime object could not return that info to me | 22:09 |
| srichter | so we would have to write a small helper method | 22:09 |
| * mgedmin blinks | 22:10 | |
| mgedmin | k hour in day (1~24) (Number) 24 | 22:10 |
| mgedmin | K hour in am/pm (0~11) (Number) 0 | 22:10 |
| srichter | same for w and W | 22:10 |
| mgedmin | shouldn't hour in day be 0~23 and hour in am/pm 1~12? | 22:10 |
| mgedmin | I've never seen 00:00 AM | 22:10 |
| srichter | I am pretty sure I just copied this stright out of the specs | 22:11 |
| srichter | I agree totally though | 22:11 |
| srichter | I would not mind changing this behavior | 22:12 |
| mgedmin | never mind, h/H are like I said | 22:12 |
| srichter | oh, right | 22:12 |
| srichter | totally forgot ;-) | 22:12 |
| mgedmin | >>> dtf.format(datetime(2004, 10, 31, 15, 42), 'h H k K') | 22:12 |
| mgedmin | '3 15 16 3' | 22:12 |
| mgedmin | 16? | 22:12 |
| mgedmin | >>> dtf.format(datetime(2004, 10, 31, 3, 42), 'h H k K') | 22:12 |
| mgedmin | '3 3 4 3' | 22:12 |
| mgedmin | >>> dtf.format(datetime(2004, 10, 31, 12, 00), 'h H k K') | 22:12 |
| mgedmin | '12 12 13 0' | 22:12 |
| mgedmin | >>> dtf.format(datetime(2004, 10, 31, 00, 00), 'h H k K') | 22:12 |
| mgedmin | '12 0 1 0' | 22:12 |
| mgedmin | I suppose 'k' and 'K' are also just stubs | 22:13 |
| srichter | they are | 22:14 |
| mgedmin | ok, then I'm no longer surprised | 22:14 |
| srichter | :-) | 22:14 |
| mgedmin | here's the issue: http://zope.org/Collectors/Zope3-dev/364 | 22:14 |
| srichter | did you look at format.py? | 22:14 |
| srichter | thanks | 22:14 |
| srichter | it has a comment in front of all the stubs | 22:14 |
| * mgedmin looking now | 22:15 | |
| srichter | we really need TZ support in Zope 3 and finish the date/time formatting code once and for all | 22:15 |
| mgedmin | do you know what needs to be done for date/time formatting apart from bugfixes and finishing those stubs? | 22:18 |
| * mgedmin looks into doc/TODO.txt | 22:18 | |
| * mgedmin greps for TODO in zope/i18n | 22:18 | |
| srichter | TZ support! | 22:18 |
| srichter | once we can go from timezone number to timezone name and back we are all set | 22:19 |
| mgedmin | There's a TODO: implement this method in LocaleCalendar.isWeekend | 22:19 |
| srichter | we basically need support for the following four formats: "+000", "+00:00", "UTC", and "Greenwich Time" | 22:20 |
| mgedmin | also I don't like the look of "TODO: tworks for gregorian only right now" | 22:20 |
| srichter | do you have other calendars? :-) | 22:20 |
| mgedmin | not me | 22:20 |
| mgedmin | but the interface defined six or seven of them | 22:20 |
| srichter | I would be surprised if anyone did | 22:20 |
| mgedmin | look at ILocaleDates | 22:21 |
| mgedmin | gregorian arabic chinese civil-arabic hebrew japanese thai-buddhist | 22:21 |
| mgedmin | whew | 22:21 |
| srichter | right | 22:21 |
| srichter | the only difference is the year I think | 22:22 |
| srichter | they compute them in different ways | 22:22 |
| mgedmin | regarding timezones, where do you get the timezone database from? | 22:22 |
| srichter | but I will wait until someone actually requests those, before I worry | 22:22 |
| mgedmin | bundle pytz with Zope 3? | 22:22 |
| srichter | that would be best | 22:22 |
| srichter | since it uses the Olsen data, which is the defacto one to use | 22:23 |
| srichter | we really should ask the pytz developer to contribute his code to the Zope 3 project | 22:23 |
| srichter | well, it's stuart; he is already a contributer | 22:24 |
| J1m | srichter, how does the apidoc adapter listing for an interface manage to filter out views? :) | 22:27 |
| srichter | :-) it checks whether the last adapted object implements IRequest | 22:28 |
| J1m | why does it filter? | 22:30 |
| srichter | because I have not had a chance to redesign API doc since 3.0 | 22:33 |
| srichter | also, I still think it is useful | 22:33 |
| srichter | but the main point is that I did not want to work on API doc until all the services were gone | 22:34 |
| srichter | J1m: the Lazy property is great for BBB | 22:47 |
| *** niemeyer has quit IRC | 23:04 | |
| *** dman13 has joined #zope3-dev | 23:28 | |
| *** SteveA has quit IRC | 23:45 | |
| *** stub has quit IRC | 23:56 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!