Re: [Zope-dev] Infuriating ZClass registry Heisenbug
If you feel like it, the change that is biting you is probably in here: http://cvs.zope.org/Zope/lib/python/ZODB/ coptimizations.c.diff?r1=1.17r2=1.17.60.1only_with_tag=Zope-2_6-branch I looked and there are some changes to the persistent_id code, but I lack sufficient background with this module to have something leap out at me and say aha! On Wednesday, December 11, 2002, at 11:13 PM, Shane Hathaway wrote: On Wed, 11 Dec 2002, Evan Simpson wrote: I think I've fixed my ZGlobals, but there's definitely a problem in coptimizations. I made Connections.py use the Python persistent_id, restarted twice, and ZGlobals was fine on the second restart. Ah-ha, you now have a reproducible test case. The coptimizations code has been undergoing beautification lately; apparently this particular ZClass-related functionality was not retained correctly. This ought to be a priority for Zope 2.6, I think. Shane ___ 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 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] Infuriating ZClass registry Heisenbug
SH == Shane Hathaway [EMAIL PROTECTED] writes: SH On Wed, 11 Dec 2002, Evan Simpson wrote: I think I've fixed my ZGlobals, but there's definitely a problem in coptimizations. I made Connections.py use the Python persistent_id, restarted twice, and ZGlobals was fine on the second restart. SH Ah-ha, you now have a reproducible test case. The SH coptimizations code has been undergoing beautification lately; SH apparently this particular ZClass-related functionality was not SH retained correctly. This ought to be a priority for Zope 2.6, I SH think. Evan, Can you give me a recipe from reproducing the problem? Ideally, we'd write a little unit test that verified that the persistent_id code handled ZClass properly. Jeremy ___ 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] Proper Use of __init__ inside Zope Products?
Can a Zope-internals guru provide some enlightenment regarding the mysteries of __init__? I'm writing some zproducts that subclass the existing Folder class, and then are themselves subclassed. What I've got works, but I'm not sure its _correct_. As I'm writing a Zope Best Practices document, I'd like to get it right. As I understand it, the use of __init__ should be avoided when possible, since it isn't invoked (necessarily) when persistent objects are reloaded from disk. Therefore Zope tends to do instance init within manage_addMYPRODUCT global-to-Zope functions, although this doesn't seem to be fully consistent throughout the Zope community contributions. The scenario is something like the following: def manage_addFolder(self, id, title='', ...): instance = Folder() instance.id = str(id) instance.title = title self._setObject(id, instance) class Folder(...): # no __init__ method def manage_addLargeFolder(self, id, title='', ...): instance = LargeFolder() instance.id = str(id) instance.title = title self._setObject(id, instance) class LargeFolder(Folder): def __init__(self): # parent class has no __init__ so don't call it! #Folder.__init__() self._tree = OOBTree() def manage_addSpecialLargeFolder(self, id, title='', ...): instance = SpecialLargeFolder() instance.id = str(id) instance.title = title self._setObject(id, instance) class SpecialLargeFolder(LargeFolder): def __init__(self): # parent class DOES have an __init__ so call it LargeFolder.__init__() self._other = OOBTree() (A) I reluctantly found it necessary to add an __init__ to my LargeFolder class because if I init'd self._tree in manage_addLargeFolder(), then it won't get init'd when manage_addSpecialLargeFolder() is used to create instances. manage_addLargeFolder doesn't get invoked in that case. (B) Currently the Folder class lacks an __init__ so I cannot call it from LargeFolder.__init__, but if someday ZC decides to add one, my code will fail to init Folder and break. Is this correct? I wish Python auto-provided a default no-nothing __init__ for this case so I could always call it. So the Guiding Rule seems to be initialize those attributes that are common to all Zope objects, e.g. id and title, within the factory functions, but init any attributes you introduce using an __init__ method. Correct? -Jeff Rush ___ 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] Proper Use of __init__ inside Zope Products?
From: Jeff Rush [EMAIL PROTECTED] As I understand it, the use of __init__ should be avoided when possible, since it isn't invoked (necessarily) when persistent objects are reloaded from disk. I'm not sure why that would matter. I'm using __init__ all the time, never had one single problem. Best Regards Lennart Regebro Torped Strategi och Kommunikation AB ___ 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.0 ZMI Problem for CJK(Collector 623) patch.
Thank you for the detailed comment..
On Wed, 11 Dec 2002 11:15:37 +0900
Kazuya FUKAMACHI [EMAIL PROTECTED] wrote:
---
2) Russian patch:
http://itconnection.ru/pipermail/zopyrus/2002-November/001388.html
+0.5
i) I like such an approach.
- select name=dtml-var id:utf8:text
+ select name=dtml-var id:dtml-var management_page_charset:text
i') using newly implemented function management_page_charset_default(),
it can set the value of default management_page_charset.
This avoids hard coding of default value.
ii) but this patch may have a few troubles in Japnanese environment.
This code returns 'eucJP' in many Japanese environment.
charset = locale.getlocale()[1]
And
codecs.lookup(charset) == codecs.lookup('eucJP')
will fail, because there are no entry for 'eucJP', but 'euc-jp'
and 'ujis'. I think it is possible to add 'eucJP' entry to
JapaneseCodecs as an alias for 'euc-jp'. So, it's not a big problem.
(I don't know why JapaneseCodecs doesn't have 'eucJP' alias.)
If the problem above has been solved,
the value of management_page_charset maybe set to 'eucJP',
and it leads to another problem.
If management_page_charset returns 'eucJP', then header should be
RESPONSE.setHeader('Content-Type','text/html; charset=eucJP')
It is not common way as a Content-Type header.
We prefer
RESPONSE.setHeader('Content-Type','text/html; charset=EUC-JP')
And also, it does not work in Windows environment.
This code returns (None, None).
locale.getlocale()[1]
I guess the problem is the difference of char-encoding naming
convention: even among Posix-complient OSes, the naming of encodings
are vender dependent (the situation is the same among RDBMS vendors).
If I were to use Russian patch, I might put one abstraction in the
char-encoding-name handling by providing some facilities like:
def getDefaultPythonCharEncodingName():
if os.name == 'posix':
return charEncodingMap.get(locale.getlocale()[1], 'latin1')
else: # For MS Windows
return os.environ.get('Z_CHAR_ENCODING', 'latin1')
def mapToIANA(encodingName):
get IANA encoding name for HTTP Header
return IANACharEncodingMap.get(encodingName, encodingName)
charEncodingMap = {
'PCK': 'Shift_JIS'
...
}
IANACharEncodingMap = {
'SJIS': 'Shift_JIS'
...
}
Sooner or later, I think this kind of mechanism will be required
for the mature support of Unicode, as Unicode brings a lot of
this kind of problems. Without the rational addressing of such issues,
the support of Unicode shouldn't be called mature I think.
Still I don't like this patch's approach very much because
this is the per-server-instance configuration, not useful
for building M17N web site.
iii) I guess modification to class PropertyManager seems
to fix http://collector.zope.org/Zope/697
Basically, it's interesting approach, but still needed to be brush up.
5) Toby's proposal
I hope +1.
I'm not satisfied with (1)-(4).
So, I would like to wait for Toby's implementation.
Probably it's a preferable choice.
My concern is I'm afraid if Toby is too busy to do that.
Since none of the choices(1-5) provide the perfect solution,
all of them are just a temporary patch for the urgent fix of
the severe issue (Collector 623).
So, I think it shouldn't take too much time (we shouldn't spend
too much time).
(further comments welcomed)
Regards,
---
Heiichiro NAKAMURA [EMAIL PROTECTED]
___
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.0 ZMI Problem for CJK(Collector 623) patch.
The current status of each resolutions (my own perception): --- 1) Nakagami Patch: http://lists.zope.org/pipermail/zope-dev/2002-November/018177.html - security concern 2) Russian patch: http://itconnection.ru/pipermail/zopyrus/2002-November/001388.html - some small modification should be done. 3) TAHARA's patch: http://lists.zope.org/pipermail/zope-dev/2002-November/018198.html - need fix of some problems 4) Rollback approach: Rollback some hassle code back to old safe one. - safer option(?) 5) Toby's proposal - relatively better consensus - not feasible if Toby is too busy to do that quickly. --- (Any comments/corrections welcomed) Regards, --- Heiichiro NAKAMURA [EMAIL PROTECTED] ___ 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.0 ZMI Problem for CJK(Collector 623) patch.
On Thu, 12 Dec 2002 15:51:48 -0800
Heiichiro NAKAMURA [EMAIL PROTECTED] wrote:
I guess the problem is the difference of char-encoding naming
convention: even among Posix-complient OSes, the naming of encodings
are vender dependent (the situation is the same among RDBMS vendors).
If I were to use Russian patch, I might put one abstraction in the
char-encoding-name handling by providing some facilities like:
Probably you're right.
I do agree your approach bellow.
def getDefaultPythonCharEncodingName():
if os.name == 'posix':
return charEncodingMap.get(locale.getlocale()[1], 'latin1')
else: # For MS Windows
return os.environ.get('Z_CHAR_ENCODING', 'latin1')
[snip]
IANACharEncodingMap = {
'SJIS': 'Shift_JIS'
...
}
Sooner or later, I think this kind of mechanism will be required
for the mature support of Unicode, as Unicode brings a lot of
this kind of problems. Without the rational addressing of such issues,
the support of Unicode shouldn't be called mature I think.
Still I don't like this patch's approach very much because
this is the per-server-instance configuration, not useful
for building M17N web site.
- per-server-instance configuration
- not useful for building M17N web site
I agree.
5) Toby's proposal
Probably it's a preferable choice.
My concern is I'm afraid if Toby is too busy to do that.
Yes, I'm also afraid so.
It's very difficult to provide a perfect solution.
Since none of the choices(1-5) provide the perfect solution,
all of them are just a temporary patch for the urgent fix of
the severe issue (Collector 623).
As a temporary patch,
+1
3) TAHARA's patch:
http://lists.zope.org/pipermail/zope-dev/2002-November/018198.html
- need fix of some problems
It has some problems but easy to patch and start to use,
and also easy to remove after complete solution is provided.
If Toby will take some time, I will use 3) for a while.
But, if it takes a few months or longer,
I will try to modify Russian patch as an experiment,
maybe taking in your approach in some degree.
Is that bad idea?
So, I think it shouldn't take too much time (we shouldn't spend
too much time).
Maybe, we should separate the problem into temporary patch
and complete solution, if it takes much time.
___
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] allowable object ids
Dieter Maurer [EMAIL PROTECTED] wrote: I'm currious, why aren't arbitrary characters allowed in object ids? I cannot tell you precisely. My guess: It was an initial simplification to avoid URL quoting at many places. With the given restriction, you can use ids directly in URLs -- no need to escape parts of them. I hope (and expect) that the restriction will be dropped when Zope becomes unicode based. Not because I miss characters like +?/... but because international letters should be allowed in ids. It will be the case in Zope 3 (only / will be forbidden in ids (=names)). For Zope 2 I strongly doubt we'll have full unicode ids. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:[EMAIL PROTECTED] ___ 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] Re: [Zope-dev] post-publishing hook
Shane Hathaway [EMAIL PROTECTED] wrote: On 11/29/2002 01:33 PM, Ivo van der Wijk wrote: On Fri, Nov 29, 2002 at 01:07:24PM +0100, Carlo Giomini wrote: Dear all, I need a sort of post-publishing hook (so to say). I need Zope to call a function of mine as the very last action of publishing a request, i.e. after having built the response (and sent it to the browser possibly), but before starting publishing a new request. My Zope server is running as a single-threaded app. Does Zope support this any way? You'll be working outside the REQUEST transaction at that moment, so please keep that in mind when modifying objects. In fact, the database connection might already be closed. If you need to read or write the ZODB, you might have to open a private connection and close it before returning. Ugh. Indeed, the connection has already been closed at that point so you will need to open a new one. Note also that you won't be able to report any error to the user (obviously). Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:[EMAIL PROTECTED] ___ 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 )
