Re: [Zope-dev] Merge proposal: tseaver-better_unittests branch of zope.interface

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/27/2012 06:32 PM, Marius Gedminas wrote:

> I've a comment about this change, which was part of that large "merge
>  from launchpad" commit:
> 
> --- 
> zope.interface/branches/tseaver-better_unittests/src/zope/interface/_zope_interface_coptimizations.c
>
>
>
> 
(revision 118418) +++
> zope.interface/branches/tseaver-better_unittests/src/zope/interface/_zope_interface_coptimizations.c
>
>
>
> 
(revision 124742) @@ -980,5 +980,11 @@ } else -Py_INCREF(result);
> +{ +  if (result == Py_None && default_ != NULL) +{ + 
> result = default_; +} +  Py_INCREF(result); +}
> 
> return result;
> 
> It seems to be a bugfix for http://pad.lv/910987 from [1]
> 
> [1] 
> http://bazaar.launchpad.net/~tseaver/zope.interface/better_unittests/revision/182
>
>
>
>
> 
I failed to find any mention of this CHANGES.txt on that branch.

Thanks for the catch.  This was indeed a fix for a problem I uncovered
while ensuring that the Python and C implementations passed the same test
suite.  I have update the 'CHANGES.txt` file on the branch to indicate
the fix.



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9yeBcACgkQ+gerLs4ltQ6cRQCeI9K1J040qOWRI3OnB6Vu4t3M
DgEAoLSnM4RBc3tcRivZFyWbbVARUpKg
=9SeP
-END PGP SIGNATURE-

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] zope-tests - OK: 42

[Zope tests summarizer]

This is the summary for test reports received on the 
zope-tests list between 2012-03-26 00:00:00 UTC and 2012-03-27 00:00:00 UTC:

See the footnotes for test reports of unsuccessful builds.

An up-to date view of the builders is also available in our 
buildbot documentation: 
http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds

Reports received


   Bluebream / Python2.5.5 64bit linux
   Bluebream / Python2.6.7 64bit linux
   Bluebream / Python2.7.2 64bit linux
   ZTK 1.0 / Python2.4.6 Linux 64bit
   ZTK 1.0 / Python2.5.5 Linux 64bit
   ZTK 1.0 / Python2.6.7 Linux 64bit
   ZTK 1.0dev / Python2.4.6 Linux 64bit
   ZTK 1.0dev / Python2.5.5 Linux 64bit
   ZTK 1.0dev / Python2.6.7 Linux 64bit
   ZTK 1.1 / Python2.5.5 Linux 64bit
   ZTK 1.1 / Python2.6.7 Linux 64bit
   ZTK 1.1 / Python2.7.2 Linux 64bit
   Zope 3.4 KGS / Python2.4.6 64bit linux
   Zope 3.4 KGS / Python2.5.5 64bit linux
   Zope 3.4 Known Good Set / py2.4-32bit-linux
   Zope 3.4 Known Good Set / py2.4-64bit-linux
   Zope 3.4 Known Good Set / py2.5-32bit-linux
   Zope 3.4 Known Good Set / py2.5-64bit-linux
   Zope-2.10 Python-2.4.6 : Linux
   Zope-2.11 Python-2.4.6 : Linux
   Zope-2.12 Python-2.6.6 : Linux
   Zope-2.12-alltests Python-2.6.6 : Linux
   Zope-2.13 Python-2.6.6 : Linux
   Zope-2.13-alltests Python-2.6.6 : Linux
   Zope-trunk Python-2.6.6 : Linux
   Zope-trunk-alltests Python-2.6.6 : Linux
   winbot / ZODB_dev py_265_win32
   winbot / ZODB_dev py_265_win64
   winbot / ZODB_dev py_270_win32
   winbot / ZODB_dev py_270_win64
   winbot / ztk_10 py_254_win32
   winbot / ztk_10 py_265_win32
   winbot / ztk_10 py_265_win64
   winbot / ztk_11 py_254_win32
   winbot / ztk_11 py_265_win32
   winbot / ztk_11 py_265_win64
   winbot / ztk_11 py_270_win32
   winbot / ztk_11 py_270_win64
   winbot / ztk_dev py_265_win32
   winbot / ztk_dev py_265_win64
   winbot / ztk_dev py_270_win32
   winbot / ztk_dev py_270_win64

Non-OK results
--

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Merge proposal: tseaver-better_unittests branch of zope.interface

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/27/2012 06:21 PM, Marius Gedminas wrote:

>>  $ bin/python setup.py dev
> 
> Is that different from 'python setup.py develop'?  I've never seen 'dev'
> before.

'dev' is an alias (defined in 'setup.cfg' for the following::

  setup.py develop easy_install zope.interface[testing]


>>  running develop
>>  ...
>>  Finished processing dependencies for zope.interface[testing]
>>  $ bin/nosetests --with-coverage
>>  
>> ...
>>  Name   Stmts   Miss  Cover   Missing
>>  
>>  zope.interface30  0   100%
>>  zope.interface.adapter   440  0   100%
>>  zope.interface.advice 69  0   100%
>>  zope.interface.common  0  0   100%
>>  zope.interface.common.idatetime   98  0   100%
>>  zope.interface.common.interfaces  81  0   100%
>>  zope.interface.common.mapping 32  0   100%
>>  zope.interface.common.sequence38  0   100%
>>  zope.interface.declarations  312  0   100%
>>  zope.interface.document   54  0   100%
>>  zope.interface.exceptions 21  0   100%
>>  zope.interface.interface 378  0   100%
>>  zope.interface.interfaces137  0   100%
>>  zope.interface.registry  300  0   100%
>>  zope.interface.ro 25  0   100%
>>  zope.interface.verify 48  0   100%
>>  
>>  TOTAL   2063  0   100%
>>  --
>>  Ran 707 tests in 2.880s
> 
> Ooh, and I also see a tox.ini on that branch!  That's extremely welcome!
> 
> (Lately when I had to make some changes to zope.* packages I've been
> kind of annoyed about the non-straightforwardness of testing all
> supported Python versions.  I briefly tried tox, but didn't want to
> spend hours figuring out how to make it play nice with buildout.)


I still use buildout for complicated "application" installs, but have grown
to dislike it for testing "library" code.

> Question: does the 100% coverage number mean both C code *and* Python
> fallbacks are tested now?

They both pass the same suite of tests.  I can't guarantee 100% covereage
of the C code, but given that it passes the same tests, I'm satisfied.

> Question: does 'bin/python setup.py test' work?

Yes.  I consider that a necessary-but-not-sufficient minium for any library.

> It seems to be becoming a sort of a universal standard for "run all the
> tests of this Python package please", and is usually not that difficult
> to hook up.  (If not, I may volunteer to hook it up.)
> 
> Question: can we still use zope.testrunner?

You can bootstrap and run the buildout and then run 'bin/test'.

> I like some of zope.testrunner's features a lot (like colorization, test
> filtering options explicitly by module and by test name).  (I may also
> volunteer to hook this up, if it's not hooked up.)
> 
>>
>>  OK
>>  $ bin/python setup.py docs
>>  running easy_install
>>  Searching for zope.interface[docs]
>>  ...
>>  Finished processing dependencies for zope.interface[docs]
>>  $ cd docs
>>  $ PATH=../bin:$PATH make html
>>  ...
>>  build succeeded.
>>
>>  Build finished. The HTML pages are in _build/html.
>> -- %< ---
> 
> Ooh, are we going to see zope.interface docs on readthedocs.org?

I'm not opposed in principle. :)

>> In addition to minimizing "Zope-iness", providing full coverage using
>> small, descriptively-named unittests makes the code more maintainable.
>> For instance, I expect to build on top of these improved tests as the basis
>> for a conversion to a "subset", supporting Python 2.6, 2.7, and 3.x from
>> a single codebase, without needing a translator like lib2to3.
> 
> Ooh, nice!
> 
>> I think it will also be easier to improve the docs, now that they no
>> longer bear the burden of supplying coverage / regression testing for
>> the code.  We can remove a bunch of extremely-terse fragments, and have
>> the examples which remain fo

Re: [Zope-dev] Merge proposal: tseaver-better_unittests branch of zope.interface

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/27/2012 05:08 AM, Brian Sutherland wrote:
> On Mon, Mar 26, 2012 at 05:38:07PM -0400, Tres Seaver wrote:
>> In addition to minimizing "Zope-iness", providing full coverage 
>> using small, descriptively-named unittests makes the code more 
>> maintainable. For instance, I expect to build on top of these 
>> improved tests as the basis for a conversion to a "subset", 
>> supporting Python 2.6, 2.7, and 3.x from a single codebase, without 
>> needing a translator like lib2to3.
>> 
>> I think it will also be easier to improve the docs, now that they no
>> longer bear the burden of supplying coverage / regression testing 
>> for the code.  We can remove a bunch of extremely-terse fragments, 
>> and have the examples which remain focus more on improving the 
>> reader's understanding than exercising some corner case.
>> 
>> Unless the consensus is against it, I plan to merge this branch to 
>> the trunk early next week.
> 
> This sounds great, I think it's exactly the right way to go. It's
> just a LOT of work, a BIG thanks for taking it on!

Thanks for the support!


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9yQA8ACgkQ+gerLs4ltQ40LwCggtNkxJxKGsazi76KBz3IMM9c
eUQAnj5aM1M1gZnryHwpjKjSswn8tzX2
=Rkao
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Merge proposal: tseaver-better_unittests branch of zope.interface

[Marius Gedminas]

On Mon, Mar 26, 2012 at 05:38:07PM -0400, Tres Seaver wrote:
> I've (finally!) finished my work to get zope.interface to 100% unit test
> coverage without relying on doctests:
> 
>   http://svn.zope.org/zope.interface/branches/tseaver-better_unittests/
> 
> The work is outlined in this document on the branch:
> 
> 
> http://svn.zope.org/zope.interface/branches/tseaver-better_unittests/README-better_unittest.txt?rev=124744&view=auto

I've a comment about this change, which was part of that large "merge
from launchpad" commit:

--- 
zope.interface/branches/tseaver-better_unittests/src/zope/interface/_zope_interface_coptimizations.c
(revision 118418)
+++ 
zope.interface/branches/tseaver-better_unittests/src/zope/interface/_zope_interface_coptimizations.c
(revision 124742)
@@ -980,5 +980,11 @@
 }
   else
-Py_INCREF(result);
+{
+  if (result == Py_None && default_ != NULL)
+{
+  result = default_;
+}
+  Py_INCREF(result);
+}
 
   return result;

It seems to be a bugfix for http://pad.lv/910987 from [1]

[1] 
http://bazaar.launchpad.net/~tseaver/zope.interface/better_unittests/revision/182

I failed to find any mention of this CHANGES.txt on that branch.

Cheers!
Marius Gedminas
-- 
http://pov.lt/ -- Zope 3/BlueBream consulting and development


signature.asc
Description: Digital signature
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Merge proposal: tseaver-better_unittests branch of zope.interface

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/27/2012 05:08 AM, Brian Sutherland wrote:
> On Mon, Mar 26, 2012 at 05:38:07PM -0400, Tres Seaver wrote:
>> In addition to minimizing "Zope-iness", providing full coverage
>> using small, descriptively-named unittests makes the code more
>> maintainable. For instance, I expect to build on top of these
>> improved tests as the basis for a conversion to a "subset",
>> supporting Python 2.6, 2.7, and 3.x from a single codebase, without
>> needing a translator like lib2to3.
>> 
>> I think it will also be easier to improve the docs, now that they
>> no longer bear the burden of supplying coverage / regression testing
>> for the code.  We can remove a bunch of extremely-terse fragments,
>> and have the examples which remain focus more on improving the
>> reader's understanding than exercising some corner case.
>> 
>> Unless the consensus is against it, I plan to merge this branch to
>> the trunk early next week.
> 
> This sounds great, I think it's exactly the right way to go. It's just
> a LOT of work, a BIG thanks for taking it on!

Thanks for the support!


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9yP+IACgkQ+gerLs4ltQ5aawCfY5GhVswjgbDYTuVeZc0NyukP
wPoAoKMPxLs034DbJmMg6/mwRqxBlR98
=ZEWK
-END PGP SIGNATURE-

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Merge proposal: tseaver-better_unittests branch of zope.interface

[Marius Gedminas]

On Mon, Mar 26, 2012 at 05:38:07PM -0400, Tres Seaver wrote:
> I've (finally!) finished my work to get zope.interface to 100% unit test
> coverage without relying on doctests:
> 
>   http://svn.zope.org/zope.interface/branches/tseaver-better_unittests/

Yay!

> The work is outlined in this document on the branch:
> 
> http://svn.zope.org/zope.interface/branches/tseaver-better_unittests/README-better_unittest.txt?rev=124744&view=auto
> 
> For those who are into sausage factories, the bulk of the work is
> available on Launchpad:
> 
>   https://code.launchpad.net/~tseaver/zope.interface/better_unittests
> 
> The branch makes many fewer "Zope-y" assumptions about how it is
> developed.  In particular, in a fresh checkout, you can run the tests
> and build the docs with widely-used 3rd-party tools, without needing
> to set up a buildout::
> 
> -- %< ---
>  $ svn co $ZSVN/zope.interface/branches/tseaver-better_unittests
>  ...
>   U   tseaver-better_unittests
>  Checked out revision 124746.
>  $ /opt/Python-2.7.2/bin/virtualenv .
>  New python executable in ./bin/python
>  Installing setuptoolsdone.
>  Installing pip...done.
>  $ bin/python setup.py dev

Is that different from 'python setup.py develop'?  I've never seen 'dev'
before.

>  running develop
>  ...
>  Finished processing dependencies for zope.interface[testing]
>  $ bin/nosetests --with-coverage
>  
> ...
>  Name   Stmts   Miss  Cover   Missing
>  
>  zope.interface30  0   100%
>  zope.interface.adapter   440  0   100%
>  zope.interface.advice 69  0   100%
>  zope.interface.common  0  0   100%
>  zope.interface.common.idatetime   98  0   100%
>  zope.interface.common.interfaces  81  0   100%
>  zope.interface.common.mapping 32  0   100%
>  zope.interface.common.sequence38  0   100%
>  zope.interface.declarations  312  0   100%
>  zope.interface.document   54  0   100%
>  zope.interface.exceptions 21  0   100%
>  zope.interface.interface 378  0   100%
>  zope.interface.interfaces137  0   100%
>  zope.interface.registry  300  0   100%
>  zope.interface.ro 25  0   100%
>  zope.interface.verify 48  0   100%
>  
>  TOTAL   2063  0   100%
>  --
>  Ran 707 tests in 2.880s

Ooh, and I also see a tox.ini on that branch!  That's extremely welcome!

(Lately when I had to make some changes to zope.* packages I've been
kind of annoyed about the non-straightforwardness of testing all
supported Python versions.  I briefly tried tox, but didn't want to
spend hours figuring out how to make it play nice with buildout.)

Question: does the 100% coverage number mean both C code *and* Python
fallbacks are tested now?

Question: does 'bin/python setup.py test' work?

It seems to be becoming a sort of a universal standard for "run all the
tests of this Python package please", and is usually not that difficult
to hook up.  (If not, I may volunteer to hook it up.)

Question: can we still use zope.testrunner?

I like some of zope.testrunner's features a lot (like colorization, test
filtering options explicitly by module and by test name).  (I may also
volunteer to hook this up, if it's not hooked up.)

> 
>  OK
>  $ bin/python setup.py docs
>  running easy_install
>  Searching for zope.interface[docs]
>  ...
>  Finished processing dependencies for zope.interface[docs]
>  $ cd docs
>  $ PATH=../bin:$PATH make html
>  ...
>  build succeeded.
> 
>  Build finished. The HTML pages are in _build/html.
> -- %< ---

Ooh, are we going to see zope.interface docs on readthedocs.org?

> In addition to minimizing "Zope-iness", providing full coverage using
> small, descriptively-named unittests makes the code more maintainable.
> For instance

Re: [Zope-dev] Content Type Meta tag stripping in zope.pagetemplate

[Marius Gedminas]

On Tue, Mar 27, 2012 at 12:36:19PM +0200, Charlie Clark wrote:
> Am 27.03.2012, 12:16 Uhr, schrieb Fred Drake :
> 
> >In other words... "the web" will continue to thrive on hacks and
> >sniffing data to support users' expectations in spite of the data on
> >"the web".  I appreciate the motivation (it's not the users' fault
> >the content provider can't get it right), it saddens me that there
> >will no end of quirks-mode-like data interpretation.  And that after
> >this many years, we still can't get content-type and encodings
> >straightened out.
> 
> True but I think that the problem was largely of our own making in
> not coming up with "one, preferably only one" way of handling this.
> Re-reading Marius' post I was struck by the whole idea of the
> http-server transcoding the content on the fly. Now, I've never
> looked at this in detail but have any of the major webservers ever
> done that?

No idea.

I wish I remembered where I read about that.  There used to be a dozen
charsets for Russian (koi8-r, windows-1251, cp866, iso-8859-5,
x-mac-cyrillic; basically at least one for every OS ;) and some websites
even went as far as letting the visitor choose the charset they wanted
to see.

*google google*

  "Having words like "please, choose an appropriate encoding" on your
   pages is really a BAD idea, drives people crazy. [...]

   Here is my advice. Get the latest version of Apache and a FLY plug-in
   module written by Igor Sereda (ser...@spb.runnet.ru). The module
   allows on-the-fly recoding from one character set to another on the
   basis of either HTTP_ACCEPT_CHARSET or, if it is not set, it scans
   "User-Agent" field from which it tries to figure out what platform
   and OS you are on. I am archiving it on sunsite as well."
-- http://www.ibiblio.org/sergei/Software/http.html

That document even mentions *proxy servers doing charset conversions on
the fly*. (O.o)

This is all, of course, completely irrelevant to the modern web.

I mention this merely as a historical curiosity, because I find the "why
are the rules that way?" type of questions fascinating.

Marius Gedminas
-- 
http://pov.lt/ -- Zope 3/BlueBream consulting and development


signature.asc
Description: Digital signature
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Content Type Meta tag stripping in zope.pagetemplate

[Charlie Clark]

Am 27.03.2012, 16:04 Uhr, schrieb Fred Drake :


Transcoding on the fly?
The page template generates Unicode; that's then encoded.
Are you suggesting we shouldn't be using Unicode as the internal  
representation?


Not at all, just harking back to the time when we didn't use unicode  
internally. In the CMF we still have to deal with that on occasion.



Failure to do so would make it easy to get things wrong.


Indeed.

Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Kronenstr. 27a
Düsseldorf
D- 40217
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Bugtracker for z3c.relationfield and reasons for objects loosing their parent pointers

[Hanno Schlichting]

On Tue, Mar 27, 2012 at 3:50 PM, Patrick Gerken  wrote:
> Hmm, since I didn't understand what magic happens with __parent__ pointers,
> I tried the following in pdb:
> unwrapped = aq_base(a)
> unwrapped.__parent__ = aq_base(a.__parent__)
>
> So I stored a not acquisition wrapped object onto the __parent__ attr
> of another unwrapped object.
> But then the result, unwrapped.__parent__ was acquisition wrapped again!

Yep. That's one thing we changed in Acquisition and ExtensionClass
4.0a1: Prevent wrappers to be created while accessing __parent__ on
types derived from Explicit or Implicit base classes.

Usually accessing any attribute on a type derived from
Acquisition.Explicit or Implicit will force wrapping to take place,
unless there's already a wrapper present. Maybe you remember the whole
weird story with browser views in Zope 2 and the need for using
"context = aq_inner(self.context)". That was the same problem.
Accessing the context attribute of the view (self), created a wrapper
equivalent to: "context = context.__of__(self)", as the view itself
wasn't wrapped in anything. For views we got rid of the problem by
removing the Acquisition.Implicit base class.

For normal content classes in Zope 2, removing the Implicit base class
is much harder, as there's more stuff depending on it, and you'd need
to ensure to switch every type derived from this, to manually store
parent pointers. But the 4.0a1 releases of AQ/EC at least treat
__parent__ differently, as it doesn't make much sense to force
wrapping for that particular attribute.

Hanno
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Content Type Meta tag stripping in zope.pagetemplate

[Fred Drake]

On Tue, Mar 27, 2012 at 6:36 AM, Charlie Clark
 wrote:
> True but I think that the problem was largely of our own making in not
> coming up with "one, preferably only one" way of handling this. Re-reading
> Marius' post I was struck by the whole idea of the http-server transcoding
> the content on the fly.

Transcoding on the fly?

The page template generates Unicode; that's then encoded.

Are you suggesting we shouldn't be using Unicode as the internal representation?
Failure to do so would make it easy to get things wrong.


  -Fred

-- 
Fred L. Drake, Jr.    
"A storm broke loose in my mind."  --Albert Einstein
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Bugtracker for z3c.relationfield and reasons for objects loosing their parent pointers

[Patrick Gerken]

On Tue, Mar 27, 2012 at 15:18, Hanno Schlichting  wrote:
> On Tue, Mar 27, 2012 at 2:53 PM, Patrick Gerken  
> wrote:
>> I found out, somewhat surprised, that __parent__ pointers are just
>> disguised aq_parent pointers.
>
> Are you maybe trying to use or set __parent__ on Acquisition wrappers
> instead of unwrapped objects?

Yes this is what happened with z3c.relationfields

> AQ wrappers have various attributes, among those aq_parent and
> __parent__ being the same thing. If you store an actual __parent__
> attribute on a "real" object, you should make sure to not wrap it in
> an Acquisition context or explicitly unwrap it before we
> Acquisition.aq_base(obj). You might need some compatibility code for
> "Zope 3" libraries, to introduce aq_base calls in the right places.

Hmm, since I didn't understand what magic happens with __parent__ pointers,
I tried the following in pdb:
>>> unwrapped = aq_base(a)
>>> unwrapped.__parent__ = aq_base(a.__parent__)

So I stored a not acquisition wrapped object onto the __parent__ attr
of another unwrapped object.
But then the result, unwrapped.__parent__ was acquisition wrapped again!
a and b both are subclasses of zope.container.contained.Contained,
which has some C Code for __parent__ pointer handling. How it works I
did not fully understand.

My conclusion on this is, that I can't use z3c.relationfield relations
directly in Zope2/Plone, but I need a tiny wrapper.
z3c.relationfield stores a normal acquisition wrapped object in an
attribute of a persistent relation. And after rollbacks or restarts
the __parent__ pointers are gone.

https://dev.plone.org/ticket/12802

Best regards,

   Patrick
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Bugtracker for z3c.relationfield and reasons for objects loosing their parent pointers

[Hanno Schlichting]

On Tue, Mar 27, 2012 at 2:53 PM, Patrick Gerken  wrote:
> I found out, somewhat surprised, that __parent__ pointers are just
> disguised aq_parent pointers.

Are you maybe trying to use or set __parent__ on Acquisition wrappers
instead of unwrapped objects?

AQ wrappers have various attributes, among those aq_parent and
__parent__ being the same thing. If you store an actual __parent__
attribute on a "real" object, you should make sure to not wrap it in
an Acquisition context or explicitly unwrap it before we
Acquisition.aq_base(obj). You might need some compatibility code for
"Zope 3" libraries, to introduce aq_base calls in the right places.

On any one object, you use either parent pointers to real persistent
objects, or you use Acquisition. Zope 2.12 has not introduced anything
to actually store pointers to real objects. It just provides forward
compatibility, so objects that do have those pointers, can avoid using
Acquisition. And all of that while keeping the Acquisition API's like
"from Acquisition import aq_parent, aq_get") intact and working for
both types of approaches. Or well, this is a bit of a lie, Zope 2.12
actually did change things for browser views, so those don't inherit
from Acquisition anymore, but with those view.__parent__ is just the
same as view.context - so it's easier.

We worked on actually storing parent pointers on objects during last
years Zope 4 sprint at Plone Conf. But today I doubt using parent
pointers actually works. Or at least you have to be really careful
with Acquisition wrappers and cannot use API's like OFS.CopySupport or
ZEXP export.

Hanno
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Bugtracker for z3c.relationfield and reasons for objects loosing their parent pointers

[Patrick Gerken]

Hi,

I found out, somewhat surprised, that __parent__ pointers are just
disguised aq_parent pointers.
The changelog entries for zope 2.12 are a bit misleading in this regard.
Is there somewhere an explanation of how this works? I was quite by
some of the properties.

Best regards,

 Patrick


On Tue, Mar 27, 2012 at 00:09, Patrick Gerken  wrote:
> Hi,
>
> I have a very curious problem with relationfields, and I don't know
> which bugtracker to use for z3c.relationfield.
> So, hopefully somebody here can give me some pointers.
>
> The relations are persistent objects and the from relation is stored
> directly on them on the from_object.
>
> For some reason, the existing relations have from objects without
> __parent__ or aq_parent pointers.
> When I update a relation, from_object is updated with an object with
> __parent__ and aq_parent pointers.
> After restart, the pointers are gone, the attribute value is None.
> When I want to delete the relation target object, Plone first starts a
> savepoint, tries to delete the object, catches any exceptions and does
> a rollback. It does so to test for certain exception. After the
> rollback, the objects lost their __parent__ and aq_parent pointers.
> There was something else that felt odd. the object in from_object
> always returned a string representation without a path on
> obj.__str__(), but a string representation with a path when doing
> obj.__repr__() and when the object had __parent__ pointers. I noticed
> that, because print statements and pdb tests displayed different
> things.
> The whole thing happens in Zope 2.13 with dexterity content types.
> I have no idea why this could happen. Anybody has any  pointers for me?
>
> Thanks and best regards,
>
>       Patrick
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Merge proposal: tseaver-better_unittests branch of zope.interface

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/27/2012 02:25 AM, Wolfgang Schnerring wrote:
> * Tres Seaver  [2012-03-26 23:38]:
>> I've (finally!) finished my work to get zope.interface to 100% unit
>> test coverage without relying on doctests:
> 
> That's an impressive feat, congratulations!

Thank you!


>> In addition to minimizing "Zope-iness", providing full coverage
>> using small, descriptively-named unittests makes the code more
>> maintainable. For instance, I expect to build on top of these
>> improved tests as the basis for a conversion to a "subset",
>> supporting Python 2.6, 2.7, and 3.x from a single codebase, without
>> needing a translator like lib2to3.
>> 
>> I think it will also be easier to improve the docs, now that they
>> no longer bear the burden of supplying coverage / regression testing
>> for the code.  We can remove a bunch of extremely-terse fragments,
>> and have the examples which remain focus more on improving the
>> reader's understanding than exercising some corner case.
> 
> I haven't had time yet to review this in detail, but this is most 
> definitely the right direction: separate tests from documentation,
> make the tests expressive and the documentation clear. Wonderful! 
> (I've I get some 'round toits, I'd much like to look through this;
> I'll let you know if I find anything.)

Great, thanks!

>> Unless the consensus is against it, I plan to merge this branch to
>> the trunk early next week.
> 
> +1, please do.
> 
>> The branch makes many fewer "Zope-y" assumptions about how it is 
>> developed.  In particular, in a fresh checkout, you can run the
>> tests and build the docs with widely-used 3rd-party tools, without
>> needing to set up a buildout::
> 
> Since I've thinking along these lines recently ("why do I need
> buildout if all I want is a testrunner?"), I'm curious as to how this
> works, especially - Where does bin/nosetests come from? - Where does
> "setup.py docs" come from?

The 'docs' and 'dev' aliases are defined in setup.cfg::

 $ tail -n -3 setup.cfg
 [aliases]
 dev = develop easy_install zope.interface[testing]
 docs = easy_install zope.interface[docs]

and their extras_require in setup.py::

 $ egrep -B 2 "(testing_extras|'docs')" setup.py
 features = {'codeoptimization': codeoptimization}
 tests_require = ['zope.event']
 testing_extras = tests_require + ['nose', 'coverage']
 --
 tests_require = tests_require,
 install_requires = ['setuptools'],
 extras_require={'docs': ['Sphinx'],
 'test': tests_require,
 'testing': testing_extras,


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9xr0wACgkQ+gerLs4ltQ4ihACg22pNtSDSrBpJ6jHEijmqJKc5
ihcAnAyjrukF6ukG8XVuyZREup89q1nr
=v9nN
-END PGP SIGNATURE-

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Content Type Meta tag stripping in zope.pagetemplate

[Charlie Clark]

Am 27.03.2012, 12:16 Uhr, schrieb Fred Drake :


In other words... "the web" will continue to thrive on hacks and
sniffing data to
support users' expectations in spite of the data on "the web".
I appreciate the motivation (it's not the users' fault the content
provider can't
get it right), it saddens me that there will no end of quirks-mode-like  
data
interpretation.  And that after this many years, we still can't get  
content-type

and encodings straightened out.


True but I think that the problem was largely of our own making in not  
coming up with "one, preferably only one" way of handling this. Re-reading  
Marius' post I was struck by the whole idea of the http-server transcoding  
the content on the fly. Now, I've never looked at this in detail but have  
any of the major webservers ever done that? Having struggled in the past  
with "weird" encoding errors limited to Safari and IE only, probably  
caused by me not handling the encode/decode chain properly in my code but  
still left staring unbelievingly at a long and confusing traceback and  
yearning for an easy to way "to do the right thing" which in my view  
should be the webserver trying to serve up UTF-8.


I guess, that years ago we had to worry much more about encodings  
(latin-1, windows-1252, mac-roman, IBM code pages, and whatever unix was  
doing).


I've been reading about http 2.0 coming up - is this going to improve the  
matter?


Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Kronenstr. 27a
Düsseldorf
D- 40217
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Content Type Meta tag stripping in zope.pagetemplate

[Miano Njoka]

>
>
>
> """
> It is better to encode your Web pages in UTF-8, and serve them as such. In
> HTTP, the HTTP header has priority, then the meta name contained in HTML.
> Some Web pages have specific encoding. It happens often on the Web that the
> Web page encoding is different from the one specified in the file and/or
> the one specified in HTTP headers. It creates issues for users who receive
> unreadable characters on their screens. So the browsers have to fix the
> encoding on the fly. We had bug reports about Web sites sending BOM
> different from the HTTP header. We decided to make the BOM authoritative
> like webkit and IE, because there are more chances for it to be exact than
> the HTTP headers.
> """
>
> http://my.opera.com/ODIN/blog/**2012/03/26/whats-new-in-opera-**
> development-snapshots-march-**26-2012
>
>
In our case if a meta content type tag exists in a template, the HTTP
header charset parameter will always be set to the same value. Always.
There is no chance of a conflict. zope.pagetemplate should therefore not
opaquely strip out the meta tag.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Content Type Meta tag stripping in zope.pagetemplate

[Fred Drake]

On Tue, Mar 27, 2012 at 4:54 AM, Charlie Clark
 wrote:
> """
> We had bug reports about Web sites sending BOM different from the HTTP
> header.
> """

In other words... "the web" will continue to thrive on hacks and
sniffing data to
support users' expectations in spite of the data on "the web".

I appreciate the motivation (it's not the users' fault the content
provider can't
get it right), it saddens me that there will no end of quirks-mode-like data
interpretation.  And that after this many years, we still can't get content-type
and encodings straightened out.


  -Fred

-- 
Fred L. Drake, Jr.    
"A storm broke loose in my mind."  --Albert Einstein
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Merge proposal: tseaver-better_unittests branch of zope.interface

[Brian Sutherland]

On Mon, Mar 26, 2012 at 05:38:07PM -0400, Tres Seaver wrote:
> In addition to minimizing "Zope-iness", providing full coverage using
> small, descriptively-named unittests makes the code more maintainable.
> For instance, I expect to build on top of these improved tests as the basis
> for a conversion to a "subset", supporting Python 2.6, 2.7, and 3.x from
> a single codebase, without needing a translator like lib2to3.
> 
> I think it will also be easier to improve the docs, now that they no
> longer bear the burden of supplying coverage / regression testing for
> the code.  We can remove a bunch of extremely-terse fragments, and have
> the examples which remain focus more on improving the reader's
> understanding than exercising some corner case.
> 
> Unless the consensus is against it, I plan to merge this branch to the
> trunk early next week.

This sounds great, I think it's exactly the right way to go. It's just a
LOT of work, a BIG thanks for taking it on!

-- 
Brian Sutherland
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Content Type Meta tag stripping in zope.pagetemplate

[Charlie Clark]

Am 25.02.2012, 00:18 Uhr, schrieb Marius Gedminas :


The HTML spec requires that:
 "To sum up, conforming user agents must observe the following
   priorities when determining a document's character encoding (from
   highest priority to lowest):
   1. An HTTP "charset" parameter in a "Content-Type" field.
2. A META declaration with "http-equiv" set to "Content-Type" and a
   value set for "charset".
3. The charset attribute set on an element that designates an
   external resource."
   -- http://www.w3.org/TR/html4/charset.html#h-5.2.2



(Aside: The rationale for this ordering, IIRC, is that it allows HTTP
servers to do on-the-fly charset conversion from one 8-bit charset to a
different one, without having to parse HTML and modify the charset name
in the  declaration.)


As a follow up to this it's worth noting that as from Opera 12 the  
practice will be:


* BOM sniffing
* http header
* meta declaration

In that order and inline with Webkit and IE:

"""
It is better to encode your Web pages in UTF-8, and serve them as such. In  
HTTP, the HTTP header has priority, then the meta name contained in HTML.  
Some Web pages have specific encoding. It happens often on the Web that  
the Web page encoding is different from the one specified in the file  
and/or the one specified in HTTP headers. It creates issues for users who  
receive unreadable characters on their screens. So the browsers have to  
fix the encoding on the fly. We had bug reports about Web sites sending  
BOM different from the HTTP header. We decided to make the BOM  
authoritative like webkit and IE, because there are more chances for it to  
be exact than the HTTP headers.

"""

http://my.opera.com/ODIN/blog/2012/03/26/whats-new-in-opera-development-snapshots-march-26-2012

Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Kronenstr. 27a
Düsseldorf
D- 40217
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )