Re: [Zope-dev] zope.password
On Wed, 2009-03-18 at 13:07 -0600, Shane Hathaway wrote: > Christian Theune wrote: > > I remember that at the sprint we used to identify packages which are > > "always good". E.g. zope.interface is a declared no-brainer to add to > > your dependencies. The other two that keep popping up that we *might* > > wanna white-list are zope.schema and zope.component. > > To whitelist zope.component would be quite interesting. As I recall, > there was a time when all packages that depended on zope.component were > required to be in the zope.app namespace. Interesting, didn't know/remember that. > I don't object to the idea, though. We're using zope.schema and > zope.component almost like language features. Same here. -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT attributes and ""
On Wed, Mar 18, 2009 at 07:31:36AM -0400, Tres Seaver wrote:
> Roger Ineichen wrote:
> > Hi Malthe
> >
> >> Betreff: [Zope-dev] ZPT attributes and ""
> >>
> >> Currently, if an attribute expression evaluates to any value
> >> that's boolean False, it's omitted (e.g. 0, "", object()).
object() is true in boolean contexts.
> >> I
> >> think that's unexpected. Instead, attributes should only be
> >> omitted when the expression evaluates to ``None``.
> >
> > I think this is better then render empty strings. see below...
> >
> >> How do folks feel about changing this behavior in
> >> ``zope.pagetemplate``.
> >
> > Probably anything else then "" should be skipped. There is no
> > logic why object() or False should get rendered as "".
>
> Non-true values have special semantics for certain attributes
> ('checked', 'selected', I think).
True values also.
This is a feature of TAL in HTML mode and should be preserved
Marius Gedminas
--
http://pov.lt/ -- Zope 3 consulting and development
signature.asc
Description: Digital signature
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.password
Christian Theune wrote: > I remember that at the sprint we used to identify packages which are > "always good". E.g. zope.interface is a declared no-brainer to add to > your dependencies. The other two that keep popping up that we *might* > wanna white-list are zope.schema and zope.component. To whitelist zope.component would be quite interesting. As I recall, there was a time when all packages that depended on zope.component were required to be in the zope.app namespace. I don't object to the idea, though. We're using zope.schema and zope.component almost like language features. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT attributes and ""
On Wed, Mar 18, 2009 at 7:59 AM, Roger Ineichen wrote: > As far as I know it is valid to skip attributes for empty values > but for some attributes it is not valid to use empty values. Let's not use the term valid in this context, as it's pretty overloaded here. In the general case, there's no way to know what string values can be dropped silently, and it's wrong to assume that it can be done safely. Using a special value (None, a.k.a. nothing in templates) is the only reasonable indicator that an attribute should be dropped. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] XML-RPC does not work under the paster process
Hi Michael > Betreff: Re: [Zope-dev] XML-RPC does not work under the paster process > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Michael Haubenwallner wrote: > > When using paste.httpserver instead of twisted.wsgi server > > zope.publisher.xmlrpc.XMLRPCRequest.processInputs() hangs > when reading > > 0 Bytes from the request (wsgi.input ). > > > > As i found the zope.publisher.http.HTTPInputStream.readlines() > > signature was changed 3 years ago from readlines(self, hint=None) > > to readlines(self, hint=0) > > > http://svn.zope.org/Zope3/trunk/src/zope/publisher/http.py?rev=66941&r > > 1=66940&r2=66941 > > > > Do you think we could revert the change? > > > > Bugs reported: > > zopeproject: https://bugs.launchpad.net/zope3/+bug/283089 > > grokproject: https://bugs.launchpad.net/grok/+bug/332063 > > > > Bump - maybe my description was too complicated, but the > issue is serious: > > XMLRPC is broken at least with paste.httpserver > > Any input on the implications of reverting the change in > revision #66941? We should also add a good test case where we can see what happens. Regards Roger Ineichen > Regards > Michael > > - -- > http://blog.d2m.at > http://planetzope.org > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFJwOU0l0uAvQJUKVYRAnILAKCOSnA3YfUXilqoTD74/ukemGPkyACgil0O > 1F0ZmR11vhodC33S6Wcg0z0= > =JX17 > -END PGP SIGNATURE- > > ___ > Zope-Dev maillist - Zope-Dev@zope.org > http://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** (Related lists - > http://mail.zope.org/mailman/listinfo/zope-announce > http://mail.zope.org/mailman/listinfo/zope ) > ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Windows binary egg for zope.interface 3.5.1?
Hi. Chris Withers wrote: > Got zope.interface 3.5.1. > > Any chance someone could roll and release a Windows binary egg for this? I just uploaded binary Windows eggs for Python 2.4, 2.5 and 2.6. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] XML-RPC does not work under the paster process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Haubenwallner wrote: > When using paste.httpserver instead of twisted.wsgi server > zope.publisher.xmlrpc.XMLRPCRequest.processInputs() hangs when reading 0 > Bytes from the request (wsgi.input ). > > As i found the zope.publisher.http.HTTPInputStream.readlines() signature > was changed 3 years ago > from readlines(self, hint=None) > to readlines(self, hint=0) > http://svn.zope.org/Zope3/trunk/src/zope/publisher/http.py?rev=66941&r1=66940&r2=66941 > > Do you think we could revert the change? > > Bugs reported: > zopeproject: https://bugs.launchpad.net/zope3/+bug/283089 > grokproject: https://bugs.launchpad.net/grok/+bug/332063 > Bump - maybe my description was too complicated, but the issue is serious: XMLRPC is broken at least with paste.httpserver Any input on the implications of reverting the change in revision #66941? Regards Michael - -- http://blog.d2m.at http://planetzope.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJwOU0l0uAvQJUKVYRAnILAKCOSnA3YfUXilqoTD74/ukemGPkyACgil0O 1F0ZmR11vhodC33S6Wcg0z0= =JX17 -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 6 OK
Summary of messages to the zope-tests list. Period Tue Mar 17 12:00:00 2009 UTC to Wed Mar 18 12:00:00 2009 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Tue Mar 17 21:23:50 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011289.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Tue Mar 17 21:25:55 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011290.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Tue Mar 17 21:27:55 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011291.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Tue Mar 17 21:29:55 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011292.html Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Tue Mar 17 21:31:55 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011293.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Tue Mar 17 21:33:57 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011294.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT attributes and ""
Hi Tres
> Betreff: Re: [Zope-dev] ZPT attributes and ""
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Roger Ineichen wrote:
> > Hi Malthe
> >
> >> Betreff: [Zope-dev] ZPT attributes and ""
> >>
> >> Currently, if an attribute expression evaluates to any
> value that's
> >> boolean False, it's omitted (e.g. 0, "", object()). I think that's
> >> unexpected. Instead, attributes should only be omitted when the
> >> expression evaluates to ``None``.
> >
> > I think this is better then render empty strings. see below...
> >
> >> How do folks feel about changing this behavior in
> >> ``zope.pagetemplate``.
> >
> > Probably anything else then "" should be skipped. There is no logic
> > why object() or False should get rendered as "".
>
> Non-true values have special semantics for certain attributes
> ('checked', 'selected', I think).
Good point
> > I only whould expect that an empty string whould get
> rendered as "".
> > And probably we should check the HTML specification and
> make sure that
> > we only render empty strings for attributes where they are allowed.
> >
> > see:
> > http://www.w3.org/TR/html401/types.html#type-name
> >
> > ID and NAME tokens must begin with a letter ([A-Za-z]) and may be
> > followed by any number of letters, digits ([0-9]), hyphens ("-"),
> > underscores ("_"), colons (":"), and periods (".").
> >
> > This means to me that an empty value for id or name doen't
> start with
> > [A-Za-z] and is invalid because is must start with [A-Za-z]. or not?
>
> - -1 on making ZPT / chameleon responsible for enforcing that
> requirement:
> that would be the application's job.
Hm, that's a good point too. I see what you are thinking.
My motivation is, it is valid to skip attributes with empty
values for an element in an XML document. (not sure)
If this is true, then there is no reason why a default empty
values should get rendered.
As far as I know it is valid to skip attributes for empty values
but for some attributes it is not valid to use empty values.
And the bad thing, some attributes need empty values like
you suggested with checked="" etc, oh my ;-)
Regards
Roger Ineichen
> 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.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFJwNuY+gerLs4ltQ4RAnvLAJ41d/7G0sHnH7GfX/CV9v+Dw6ksAQCgw+ZC
> LfHPVXRoCkejJLyCvLjdvyU=
> =ClnO
> -END PGP SIGNATURE-
>
> ___
> Zope-Dev maillist - Zope-Dev@zope.org
> http://mail.zope.org/mailman/listinfo/zope-dev
> ** No cross posts or HTML encoding! ** (Related lists -
> http://mail.zope.org/mailman/listinfo/zope-announce
> http://mail.zope.org/mailman/listinfo/zope )
>
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT attributes and ""
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roger Ineichen wrote:
> Hi Malthe
>
>> Betreff: [Zope-dev] ZPT attributes and ""
>>
>> Currently, if an attribute expression evaluates to any value
>> that's boolean False, it's omitted (e.g. 0, "", object()). I
>> think that's unexpected. Instead, attributes should only be
>> omitted when the expression evaluates to ``None``.
>
> I think this is better then render empty strings. see below...
>
>> How do folks feel about changing this behavior in
>> ``zope.pagetemplate``.
>
> Probably anything else then "" should be skipped. There is no
> logic why object() or False should get rendered as "".
Non-true values have special semantics for certain attributes
('checked', 'selected', I think).
> I only whould expect that an empty string whould get rendered
> as "". And probably we should check the HTML specification and
> make sure that we only render empty strings for attributes where
> they are allowed.
>
> see:
> http://www.w3.org/TR/html401/types.html#type-name
>
> ID and NAME tokens must begin with a letter ([A-Za-z]) and
> may be followed by any number of letters, digits ([0-9]),
> hyphens ("-"), underscores ("_"), colons (":"), and periods (".").
>
> This means to me that an empty value for id or name
> doen't start with [A-Za-z] and is invalid because is must start
> with [A-Za-z]. or not?
- -1 on making ZPT / chameleon responsible for enforcing that requirement:
that would be the application's job.
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.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJwNuY+gerLs4ltQ4RAnvLAJ41d/7G0sHnH7GfX/CV9v+Dw6ksAQCgw+ZC
LfHPVXRoCkejJLyCvLjdvyU=
=ClnO
-END PGP SIGNATURE-
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT attributes and ""
2009/3/18 Roger Ineichen : > This means to me that an empty value for id or name > doen't start with [A-Za-z] and is invalid because is must start > with [A-Za-z]. or not? Correct, but should enforce these requirements? I think ZPT should just have predictable, expected behavior, but not make too much fuss about syntax. I agree though, that object() or False should probably raise exceptions. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT attributes and ""
Hi Malthe
> Betreff: [Zope-dev] ZPT attributes and ""
>
> Currently, if an attribute expression evaluates to any value
> that's boolean False, it's omitted (e.g. 0, "", object()). I
> think that's unexpected. Instead, attributes should only be
> omitted when the expression evaluates to ``None``.
I think this is better then render empty strings. see below...
> How do folks feel about changing this behavior in
> ``zope.pagetemplate``.
Probably anything else then "" should be skipped. There is no
logic why object() or False should get rendered as "".
I only whould expect that an empty string whould get rendered
as "". And probably we should check the HTML specification and
make sure that we only render empty strings for attributes where
they are allowed.
see:
http://www.w3.org/TR/html401/types.html#type-name
ID and NAME tokens must begin with a letter ([A-Za-z]) and
may be followed by any number of letters, digits ([0-9]),
hyphens ("-"), underscores ("_"), colons (":"), and periods (".").
This means to me that an empty value for id or name
doen't start with [A-Za-z] and is invalid because is must start
with [A-Za-z]. or not?
Regards
Roger Ineichen
> \malthe
> ___
> Zope-Dev maillist - Zope-Dev@zope.org
> http://mail.zope.org/mailman/listinfo/zope-dev
> ** No cross posts or HTML encoding! ** (Related lists -
> http://mail.zope.org/mailman/listinfo/zope-announce
> http://mail.zope.org/mailman/listinfo/zope )
>
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.password
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Theune wrote: > On Wed, 2009-03-11 at 17:27 +0100, Martijn Faassen wrote: >> Hi there, >> >> Stephan Richter wrote: >> [snip] In my opinion going for an extra here just to avoid this is speculating a bit too much right now. Do we really have users that want to use zope.password and really don't want zope.component and zope.schema? If so, we'll hear from them when they speak up and *then* declare an extra or take some other action. >>> +1. I want more of our decisions to go into this direction. It is a sign >>> that >>> we turn the # of packages knob as well. >> I agree with you in the case against extras. >> >> It appears though that Dan has a concrete use case for using >> zope.password in a Pylons app where he isn't interested in >> zope.component, so I'm +1 on the extra in this case. We'll see whether >> this leads to difficulties. Luckily the zope.component and zope.schema >> libraries are typically around anyway so it doesn't make reasoning about >> the graph that much harder. > > I remember that at the sprint we used to identify packages which are > "always good". E.g. zope.interface is a declared no-brainer to add to > your dependencies. The other two that keep popping up that we *might* > wanna white-list are zope.schema and zope.component. That woould imply the transitive closure of their dependencies, which would be: - - zope.event - - zope.i18nmessageid - - zope.interface - - zope.component - - zope.schema We would need to finish trimming off the zope.component extras, first. Once done, those pacakges are all essentially "libraries," and could be managed as a "chunk." > In addition this would need documentation as well. Fleshing out the in-package narrative docs for those packages (or perhaps for the set?) would be pretty valuable, too. 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.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJwNge+gerLs4ltQ4RAtV8AKC0+44VxwGBq4n65uwM+ry4xRQfsQCfbQTQ klc7Xe1goO+nSPfaAflpl48= =2+XJ -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.password
On Wed, 2009-03-11 at 17:27 +0100, Martijn Faassen wrote: > Hi there, > > Stephan Richter wrote: > [snip] > >> In my opinion going for an extra here just to avoid this is speculating > >> a bit too much right now. Do we really have users that want to use > >> zope.password and really don't want zope.component and zope.schema? If > >> so, we'll hear from them when they speak up and *then* declare an extra > >> or take some other action. > > > > +1. I want more of our decisions to go into this direction. It is a sign > > that > > we turn the # of packages knob as well. > > I agree with you in the case against extras. > > It appears though that Dan has a concrete use case for using > zope.password in a Pylons app where he isn't interested in > zope.component, so I'm +1 on the extra in this case. We'll see whether > this leads to difficulties. Luckily the zope.component and zope.schema > libraries are typically around anyway so it doesn't make reasoning about > the graph that much harder. I remember that at the sprint we used to identify packages which are "always good". E.g. zope.interface is a declared no-brainer to add to your dependencies. The other two that keep popping up that we *might* wanna white-list are zope.schema and zope.component. In addition this would need documentation as well. Christian -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT attributes and ""
On Wed, 2009-03-18 at 10:55 +0300, Malthe Borch wrote: > 2009/3/18 Christian Theune : > > I'm not sure how to time the move, though. One option would be to > > release a bugfix with the option as non-default and a feature release > > with the option as default. > > That's a good approach. > > What kind of configuration should enable it; an environment variable > or a module global? Module global please. The global can then be also set using e.g. a configuration option in other programs, like making it configurable from zope.conf. -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT attributes and ""
2009/3/18 Christian Theune : > I'm not sure how to time the move, though. One option would be to > release a bugfix with the option as non-default and a feature release > with the option as default. That's a good approach. What kind of configuration should enable it; an environment variable or a module global? \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT attributes and ""
On Tue, 2009-03-10 at 10:50 -0400, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Malthe Borch wrote: > > 2009/3/10 Fred Drake : > >> The change would need to be in zope.tal. > > > > True. > > > >> I'm ambivalent; while it makes sense to me in isolation, the affect on > >> existing templates is undesirable, and compatibility is a huge deal > >> for this bit of machinery. > > > > I agree, but it would be interesting to gauge the usage of this > > functionality (e.g. if everyone could put a breakpoint in the right > > place, run their apps and check). > > > > Actually, I think this is a bug; why would the empty string not be > > printed? If we can agree it's a bug, then I guess it should be fixed > > as part of the general maintenance of the package. > > > > At any rate, if we did change/fix the behavior, a warning should > > probably be issued. If an attribute == "" then log a warning such as > > "The behavior of this has changed. Make sure your templates are > > updated." > > It seems like we ought to start emitting the warnings first, and then > fold in the new behavior as the default later. Maybe we could allow > some kind of configuration to enable the newer behavior sooner. Ack. Not being able to produce empty attributes is a bug. Fixing it might break apps. Adding an option to enable it first and then moving this to a default setting later is a good way to go, IMHO. I'm not sure how to time the move, though. One option would be to release a bugfix with the option as non-default and a feature release with the option as default. Christian -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope.component/trunk/ Merge the 'tseaver-wo_zope_deferredimport' branch:
Hi, On Tue, 2009-03-10 at 04:18 +0300, Dan Korostelev wrote: > 2009/3/5 Martijn Faassen : > > Chris Withers wrote: > >> Martijn Faassen wrote: > >>> I think we can only make the correct determination if we get an idea of > >>> the performance implications. If it turns out the C code brings > >>> significant speedups in real-world applications, we should create a > >>> zope.hookable with a Python + C implementation. > >> > >> Even if it does bring significant speedups, why does it need to be a > >> seperate package? > > > > It doesn't, but it's already a package that could be easily turned into > > something with proper documentation (it's mostly there, just hidden), > > and one of the goals was to reduce C dependencies in zope.component, not > > add C code to it. > > Let's decide that and make a release of zope.component so we could > move forward on adapting other packages to recent removal of BBB > interfaces. > > Here's three variants: > > * Move pure python implementation to zope.hookable as a fallback. > * Move C implementation to zope.component and drop zope.hookable > dependency at all. > * Just drop zope.hookable dependency, providing only pure python > version of hookable. I'm -1 on version 3. Whether to keep it as a separate module IMHO depends on the usefulness of the C implementation. If we drop it then we can IMHO live without the standalone package. If we keep two implementations then I'd move both of them to a separate package. Christian -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [zope.testbrowser] r84900
2009/3/18 Christian Theune : > Did this get resolved by any means? As it didn't spur any discussion at > all, you might want to at least file a bug tracker issue for that > problem. It has now been filed as https://bugs.launchpad.net/zope3/+bug/344680. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [zope.testbrowser] r84900
Malthe, On Mon, 2009-03-09 at 19:57 +0300, Malthe Borch wrote: > Code snippet: > > >>>def open(self, url, data=None): > >>> """See zope.testbrowser.interfaces.IBrowser""" > >>>url = str(url) > > This string coercion is unfortunate, because ``mechanize`` accepts a > (mechanize-) request-object in place of a URL string here. Using a > custom request object allows us to do such things as setting the > REQUEST_TYPE header string, which is not possible throught the > standard API. > > Changeset comment: > > - Remove vendor import of mechanize. > > - Fix bug that caused HTTP exception tracebacks to differ between > version 3.4.0 and 3.4.1. > > - Workaround for bug in Python Cookie.SimpleCookie when handling > unicode strings. > > - Fix bug introduced in 3.4.1 that created incompatible tracebacks in > doctests. This necessitated adding a patched mechanize to the > source tree; patches have been sent to the mechanize project. > > Not sure which of the above this coercion is trying to solve, but > perhaps it could be solved in a way that didn't break the mechanize > functionality. Did this get resolved by any means? As it didn't spur any discussion at all, you might want to at least file a bug tracker issue for that problem. Christian -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
