Re: [Zope-dev] broken zope.publisher because of new content types in zope.contenttype
On Sat, Jan 2, 2010 at 5:17 AM, Roger d...@projekt01.ch wrote:
Hi all
Since aaron added new mimetypes e.g. application/javascript,
the _implicitResult method in zope.publisher.http.py (line 794)
is broken because the method checks for text/* content types
if unicode is given:
def _implicitResult(self, body):
encoding = getCharsetUsingRequest(self._request) or 'utf-8'
content_type = self.getHeader('content-type')
if isinstance(body, unicode):
try:
if not content_type.startswith('text/'):
raise ValueError(
'Unicode results must have a text content type.')
except AttributeError:
raise ValueError(
'Unicode results must have a text content type.')
I changed the mime-type for .js from application/x-javascript to
application/javascript. Since I didn't change any text/* mime-types,
I'm not seeing how my change could be breaking anything that wasn't
already broken. The tests for zope.publisher run fine for me with my
changes, anyway. Can you tell how to reproduce the breakage?
Sould we remove this basic content type check above?
Or enhance the check with the new added unicode valid
content types like application/javascript.
Since whatever code is breaking for you now probably was breaking
before (since it was passing in application/x-javascript, which is
also not a text/* type), I'm inclined to think that your problem is at
a higher level.
btw, the RFC is just Informational which defines
this changes. See: http://www.rfc-editor.org/rfc/rfc4329.txt
According to the link above, the status of the following are:
text/javascript obsolete
application/x-javascript discouraged
application/javascript intended for common use, should be used
Aaron Lehmann
___
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] [Checkins] SVN: zc.sourcefactory/trunk/buildout.cfg color by default
On Mon, Dec 8, 2008 at 3:05 PM, Fred Drake [EMAIL PROTECTED] wrote: On Mon, Dec 8, 2008 at 10:56 AM, Benji York [EMAIL PROTECTED] wrote: This setting apparently causes problems for people who use Emacs, so for zope. and zc. packages at least, we don't use --auto-color. I've been using this under Emacs for a while, and haven't experienced any tool-related problems with colorization. I *have* generally objected to adding settings like this in buildout.cfg: some of us (including myself!) think it makes the output harder to read. +1 ___ 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] Re: bad zope.size to remove from PyPI
On Aug 2, 2008, at 11:45 AM, Chris Withers wrote: Benji York wrote: In case anybody's wondering how this complies with our no removal of any release whatsoever policy [1], be assured that a 3.4dev-r73090 thing isn't a release by our standards. This version number not only contains the 'dev' marker, meaning it must have come from a development branch (possibly the trunk), it also contains the -rXXX suffix meaning it was made right from a subversion checkout without having created a tags first (why else would you want to include the revision number). Still, it's likely that someone was using it and their buildouts are now broken. We should have instead generated a proper release with a higher version number and left the dev release alone. This is silly. Mistakes happen. Buildout and/or setuptools should be tolerant of accidental releases that are then removed from PyPI. What currently happens in cases like this? If the buildout is nailed to that version or above, and there is none, it breaks. Worse, if someone now adds another egg of the same version, but consumers have cached a version, their buildout won't download it, because it will already have that version in cache. I realize that this particular compound error is unlikely to happen in this instance, but the principle holds. Yes, mistakes happen. What Benji is saying is that deletion is not the right way to remedy them, as unintuitive as that may seem. Aaron Lehmann ___ 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] changelog for zope.exceptions?
On Apr 29, 2008, at 3:12 AM, Christian Theune wrote: I saw zope.exception 3.5.1 get released but the changelog on that tag and on pypi only mentions 3.4. Can someone update it please? Actually, I can't right yet, but I'll tell you what the changes were, since I made both of them. 3.5.0 - Made it possible for exception output to be formatted line by line, but introduced a bug that made each line its own message, resulting in very hard to read logs. 3.5.1 - Reverted 3.5.0. Aaron Lehmann ___ 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] Re: buildout 'versions' and 'develop' conflict
On Feb 26, 2008, at 9:38 AM, Christophe Combelles wrote: Martijn Faassen a écrit : (...) The two easiest choices are 1) issue a clear warning in stderr, or 2) rename 'develop' to something else. So, the people that understand either get spammed with warning messages every build, or have to change all their builds in order to accommodate your thinking? We all know what the solution is, it was supplied at the beginning of the thread: [versions] mynewpin = somenewversion_dev Aaron Lehmann___ 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] Re: buildout 'versions' and 'develop' conflict
On Feb 26, 2008, at 10:29 AM, Martijn Faassen wrote: Aaron Lehmann wrote: On Feb 26, 2008, at 9:38 AM, Christophe Combelles wrote: Martijn Faassen a écrit : (...) The two easiest choices are 1) issue a clear warning in stderr, or 2) rename 'develop' to something else. So, the people that understand either get spammed with warning messages every build, or have to change all their builds in order to accommodate your thinking? We all know what the solution is, it was supplied at the beginning of the thread: [versions] mynewpin = somenewversion_dev It's longer and shorter: * longer: create a 'versions' section if it isn't there yet, and point to it from [buildout] with 'versions'. (the versions section may not be there yet if this buildout.cfg extends another one with such a section) If you're extending a buildout with a versions section, you already have one. That's what extending the buildout did for you. * shorter: [versions] mynewpin = This will burn you if your develop egg is not the highest available version (for example, you are working on a bugfix for an en egg that is not bleeding edge). Also, some folks require everything be pinned. So, we're looking at a way to increase the usability of a common task: hack on a package without having to understand its place in a potentially very complicated dependency structure. If you are hacking on an egg, you should know what the current version is, and how your version is different. If you don't, your confusion is deserved. Aaron Lehmann___ 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] Standard namechooser
On Feb 11, 2008, at 10:15 AM, Aaron Lehmann wrote: Possibly instead of returning an error, it might resolve the name, and take an optional callback that performs said resolution? That way, people who have their own resolution code can easily factor it in. Or is this a case where another NameChooser should be registered? I'm going to shut up now, because I think my schitzophrenia is showing. Aaron Lehmann ___ 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] Standard namechooser
On Feb 11, 2008, at 10:06 AM, Christian Theune wrote: Hi, Aaron Lehmann schrieb: Christian, What if people are relying on those error messages to do different things? Possibly they already have normalization code they expect to come into play in this situation, which is different than yours . I see that people might be doing that, however, it seems like a bad idea to code that way. ;) Maybe. But enforcing this on others seems to cut against consenting adults. After all, how do you know that your desired resolution is the resolution for everyone? On the other hand, having to do this seems annoying, so as someone writing new code I'd consider your proposed patch a feature, rather than a bugfix. I'd be happy to declare it a feature, but I consider the existing state to not be ideal and thus it should be changed. Possibly instead of returning an error, it might resolve the name, and take an optional callback that performs said resolution? That way, people who have their own resolution code can easily factor it in. Aaron Lehmann ___ 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] Standard namechooser
Christian, What if people are relying on those error messages to do different things? Possibly they already have normalization code they expect to come into play in this situation, which is different than yours . On the other hand, having to do this seems annoying, so as someone writing new code I'd consider your proposed patch a feature, rather than a bugfix. My two cents, Aaron Lehmann On Feb 11, 2008, at 9:55 AM, Christian Theune wrote: Hi, the standard name chooser makes sure that the character '+', '@' are not used in the beginning of a name and '/' is never used. When asking the name chooser to choose a name for me, I thought it would normalize those characters away, giving me a usable name. Reading the interface, there is a distiction between checking a name (and giving an error) and choosing a name (create one, maybe with a given name to start from) that is valid. I'd consider this to be a bug and change the name chooser accordingly. What do people think? Christian -- gocept gmbh co. kg - forsterstrasse 29 - 06112 halle (saale) - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development ___ 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] aaron-traceback-log-formatting code review request
I'm taking silence to mean assent, and merging the branch. Aaron Lehmann On Jan 15, 2008, at 10:30 AM, Aaron wrote: Hi all-- I've got a branch of zope.exceptions (aaron-traceback-log- formatting) that allows a formatting pattern to be supplied, which will be applied to each line of any exceptions logged. In the case of html logging, the pattern is applied inside of the html tags. This is intended to be backward compatible, but I'd appreciate a second, or more, set of eyes. Thanks in advance, Aaron Lehmann ___ 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 )
