dout...
While:
Installing.
Getting section app.
Initializing section app.
Installing recipe zc.zope3recipes>=0.5.3.
Getting distribution for 'zc.zope3recipes==0.6b1'.
Error: Couldn't find a distribution for 'zc.zope3recipes==0.6b1'.
Tres.
- --
=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Sutherland wrote:
> On Mon, Oct 08, 2007 at 06:49:02PM -0400, Stephan Richter wrote:
>> On Monday 08 October 2007 15:09, Tres Seaver wrote:
>>> Presuming agreement on the "known good set" (KGS) term, I would think
>
obably use a
little more tooling. Once we have the tools, then tweaking them to
allow generating a "frozen" release will be simple. In that mode, the
two flavors of release here could be thought of as like "tags" and
"branches" in the CVS sense (not SVN, which doe
f packges, and why
RPM bundles them inside the SRPMs: *other* people and their software
distribution mechanisms can't be relied on when repeatability is your goal.
- -Tres.-
===
Tres Seaver +1 540-429-0999 [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Fulton wrote:
> Any objections?
>
> This would basically involve retiring the zope3-dev list and moving
> zope3 developers to the zope-dev list.
+1.
Tres.
- --
===
: setuptools
will happily install it into a Python which has incompatible compilation
options (UCS4 vs UCS2, for instance). AFAIK, the Mac toolchain, like
the Linux one, is happy to create locally-installable binary eggs from
the sdist versions.
Tres.
- --
x27; target):
http://grok.zope.org/dist/grok-0.10/simple/
One could of course write a webapp to manage these sets, but that feels
like it might be overkill, unless the application did more stuff as well
(like maybe generating buildout.cfg files, or virtualenv derivatves).
Tres.
- --
==
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
> On 9/28/07, Tres Seaver <[EMAIL PROTECTED]> wrote:
> [snip]
>> Total effort involved in maintaining the "gated community" then becomes
>> keeping a set of tarballs available at some we
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tres Seaver wrote:
> Anybody running against the Cheeseshop today is *more* on the bleeding
> edge than a sysadmin whose production boxes are running 'sid': Debian
> has cultural constraits, even for that distro, which are vastl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
> Hey,
>
> On 9/27/07, Tres Seaver <[EMAIL PROTECTED]> wrote:
> [snip]
>>> I don't like it either. I thought we resolved this though so I'm not
>>> sure why we're discussing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
> Hey,
>
> On 9/27/07, Jim Fulton <[EMAIL PROTECTED]> wrote:
>> On Sep 26, 2007, at 8:26 PM, Tres Seaver wrote:
> [snip]
>>>> Including a file other
>>>> that README in the
ires' are sufficient to make the tests
pass instead.
I thought Roger was one of the folks looking to *reduce* the set of
dependencies his application had on zope3 coee -- testing against the
meta-egg actually makes that problem worse.
Tres.
- --
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
> Hey,
>
> Tres Seaver wrote:
> [snip]
>> I think that replacing 'index_url' with a "gated community" of packages
>> is the only path to sanity here: the contract of the Cheeseshop
even in the face of missing
distributions, you have to mirror the "blessed" distributions.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNA
hey never call __conforms__.
Why does the caller care? She just wants an object which will provide
the 'IFoo' contract on behalf of the passed context. If 'x' is capable
of providing 'IFoo' without help, then failing (or worse, returning a
less-specific factory result) when calling 'getAdapter' is the W
daptation.
>
> IFoo.adapt() for normal adaptation
> IFoo.multiadapt() for multi adaptation
I'd rather have 'adapt' take *args for the contexts, and keywords for
extras (like name).
> sound reasonable to me. We then explain that if you call IFoo directly,
> IFoo.adapt is
e a newer version than the latest released egg.
If it were impossible to create an 'sdist' or 'bdist_egg' from such a
checkout, I would be OK with this. However, history shows that people
*will* make distributions from such "not-ready-for-prime-time"
checkou
>
>> - Set the version in setup.py on the tag. Check it in.
>>
>> - Make the release from the tag.
>
> I could live with that, even with the fact that you'd be modifying a
> tag, as long as it's done in this exact order and the only
> modificdations to a tag woudl be setting setup.py.
I'm fine with making "p
you
need a better tool: the consequences of carelessness are too
significant (bad releases punish everyone *else*).
> So I usually create the release first and upload it and after that create the
> tag.
- -100. Get it right, check it in, *then* upload the distribution.
Tres.
- --
==
t; release
> (which since this is a branch, we can actually predict).
>
> I prefer the "last" version, but "next" would work too.
I prefer neither, as I don't want to encourage people to make releases
without doing the bookkeeping required to get the versions ri
a versino-controlled checkout
is insane.
Further, anybody who finds the effort of creating a "fresh' checkout
bevore making a release too burdensome should consider themselves
self-selected out of the "release manager" pool.
I'm *not* kidding about that: taking s
ackages themselves, but it does have the advantage that it causes
> the files to be included in eggs as well as source distributions.
Not having those files available after installing is a complete
non-starter for me.
Tres.
- --
===
Tres Seaver +1 540-429-0999
gt; pinned down hard. That said, I believe there are ways to solve these
> problems without hardcoding them in install_requires. I hope we can have
> the benefits of weak dependencies while having the safetly of hardcoded
> ones. See here:
I think that replacing 'index_url' w
FWIW, I think that both README.txt and CHANGES.txt should be "package
data", so that they are discoverable after installing an egg. The
top-level README.txt should be boilerplate, and point to those files
(the setup.py process can then stitch them all todgether).
Tres.
- --
s and all was fine there. But then everyone else at Lovely
> has Macs.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN P
thing appended
to the version, except just before cutting a release tag.
Anything else makes it too easy to cut a premature / broken release;
such mistakes are going to damange our story if we don't get out ahead
of them.
Tres.
- --
======
e first known working set discussion
> started a while ago)
>
> Tres Seaver wrote:
>> This is the "known good" problem. I'm pretty convinced that adding some
>> kind of "PyPI subset", where gardeners for a given "package set" keep
>> the
gt; the views, you will have to replace them in another package. And you
> can override them in another package already...
You can override, but you can't "subtract" them. Breaking the
configurations out into separate pieces allows finer-grained reuse.
Tres.
- --
nkly, anybody who *wants*
such an egg should instead be using a checkput + 'setup.py develop',
instead; anything else is an invitation to disaster.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECT
n
> Python 2.7 and 3.0. Maybe a 3.1 with some more backwards compatibility
> will be needed to, I don't know.
>
> Just my 2 cents.
Amen, brother. "From you lips to [Guido's] ears."
Tres.
- --
==
easy-install.pth file
Installed \
/home/tseaver/tmp/foo/lib/python2.4/site-packages/zope.testing-3.4-py2.4.egg
Processing dependencies for zope.testing
Finished processing dependencies for zope.testing
Another alternative would be to maintain the "subset" pages in SVN
(perhaps with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
> On 4 Sep 2007, at 20:07 , Tres Seaver wrote:
>> Perhaps we need to think of the "known good" set as a "PyPI subset",
>> which is maintained in the same way that the various Debian
rious Debian distro lists
are: they may end up pulling packages from the same "pool", but they
don't expose versions / packages which have not been "opted in" to the set.
Tres.
- --
===
Tres Seaver
kages among themselves can use some
other mechanism (SVN + 'setup.py develop', for preference).
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Desig
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
> On 4 Sep 2007, at 01:21 , Tres Seaver wrote:
>> Philipp von Weitershausen wrote:
>>> Wichert Akkerman wrote:
>>>>> The only problem is that distributing grok-0.11.cfg is a bit
ll then take this
> information and generate 'known_working_versions.txt' or whatever in
> EGG-INFO. The only problem is that this custom writer needs to be
> installed when setup.py is called to create egg, in other words to
> generate the right kind of eggs you'd need
part of the GSoC project or
>> not. That said, we can't drop Python 2.4 support until
>
> ... we've made sure Zope 2 runs on Python 2.5...
How are you getting ExtensionClass working? Last I looked, the C
extension didn't compile on 2.5.
Tres.
- --
==
ent).
I'm pretty sure conditional compilation is going to be required, because
object laysut changed in incompatible ways. We might be able to confine
most of that to a couple of macro definitions, though.
Tres.
- --
===
Tres
27;m doing, and active damage
from trying to do so in Zope.
Tres.
- --
=======
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
thon 2.5 until Zope 2 is also ported.
> (This is a policy of Zope Foundation, I guess)
> But we can give support for individual packages, is it ?
>
> May be we can try Python 3.0 porting in next GSoC ? :)
Frankly, I'm uninterested in spending *any* effort on Py3K support:
we&
ch' in their version, except immediately before
copying to a release tag. As an alternative (see above), copy the
release tag and then change the version there.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROT
ote that I have alreay moved there myself). That
style is already documented; we should not need to expend any
significant effort maintaining it.
Tres.
- --
=======
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Pa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christian Theune wrote:
> Am Mittwoch, den 22.08.2007, 16:15 -0400 schrieb Tres Seaver:
>>> I eventually came to the conclusion that our original conclusion was
>>> sound, but that we should only introduce backward incompatibi
ackage / API name altogether, with the old name
left as a pure compatibility shim (perhaps wich "evergreen" deprecation
warnings).
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software
ing the older
versions as scripts. Even "brown bag" releases should remain available
(albeit, with perhaps some way to tag them as problematic).
Releasing a software package is a contract which implies more than
"flavor of the week" status, at least in lots of circles.
Tres.
- --
the if condition is
> incorrect.
Returning boolean discards the information which only this function
should know, and which the caller (potentially) needs: the list of
errors. The name 'validate' doesn't imply a boolean return to me at
all. I would expect to see it used as follo
value; either
> the exception is raised or it isn't. Code that wants to introspect
> the exception can catch that and act accordingly.
- -1. Detecting the schema violation is "mechanism", raising an
exception is "policy"; they shouldn't be mixed here. Let the calle
egg in the first place.
You're hosed, then: people are going to release eggs which break
"downstream" applications (think libs in Debian unstable). Until we
segreate the "known good" set away from the "I just did something cool,
please test" set, this problem
et rid of ++etc++ and implement ++site++ and
> ++control++. Now that I think about it, I actually favor this. ;-)
Or change zope.traversing such that it looks up namespace-based stuff
via a named utility / adapter; then packages which supply a namespace
are not dependencies at all.
Tres.
- --
==
expect people to fetch eggs for
packages: having such a refactoring affect an indirect client (one not
expecting to track day-to-day development) is a disaster.
Dumping revision-stamped (unreleased) eggs into a directory used by
unsuspecting users is a recipe for bringing *all* development to a
screec
cation.
+1
> - zope.app.component.interfaces then can import ISite from the new
> place to avoid deprectation.
+1.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excell
know about that to use
> it.
I think we need to leave soem space for people who want to customize the
site, without wanting to do "full-on" Zope3 package-based development.
If zopeproject makes it obvious where to put "filesystem pages", people
will use them, probably.
gt;> The locations of these eggs is actually site-packages. This sounds
>> very wonky to me, but Phillip Eby says it is normal.
>
> It's actually necessary (to install these things as eggs) because
> many packages nowadays depend on entry points. One could argue,
> obviousl
; Can you point me to the right repos/place of this allready fixed
> issue in Zope2. So I can take a look at that and fix it if I find
> out how this eggs work.
http://svn.zope.org/Zope/?rev=75066&view=rev
Tres.
- --
quot; don't always make "good documentation"; I prefer the
isolation of traditional unittests for anything other than "main line"
use cases, for which doctests are best suited.
Tres.
- --
===
Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gary Poster wrote:
> On Jul 13, 2007, at 11:30 AM, Jim Fulton wrote:
>
>> On Jul 13, 2007, at 11:07 AM, Philipp von Weitershausen wrote:
>>
>>> Tres Seaver wrote:
>>>> Doing proper release management can
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
> Tres Seaver wrote:
>>>> Point me at an existing source release, and I'll be happy to generate
>>>> corresponding windows eggs.
>>>>
>>>> I made windows
the-cuff version. There's a *lot* of room for
> figuring out different ways for this to work, which is one of the
> interesting bits, and why we've said, at least internally, "let a
> thousand pipelines bloom"...and then presumably just a few of them
> will
er are you expecteing (wanting) to test these eggs?
> Thanks again
>
> Philipp
>
>
> P.S.: While looking around, I found that an ancient version of
> zope.security actually exists as a Win32 egg on the CheeseShop:
> http://cheeseshop.python.org/pypi/zope.security
ng issues, and
is rock-solid stable.
- I don't need the extra "shiny" features.
Note that the "flavor-of-the-month" is actually WSGI now, rather than
Tsisted (which uses the WSGI support): see Philipp's "zope on a paste"
demo, for instance.
Tres.
- --
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marius Gedminas wrote:
> On Wed, Jul 11, 2007 at 02:13:46PM -0400, Tres Seaver wrote:
>> Fred Drake wrote:
>>> On 7/11/07, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:
>>>> Right, I made the same ass
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Benji York wrote:
> Tres Seaver wrote:
> > [1] This means *never* doing 'svn mv' or 'svn remove' on such a tag,
> > once announced. No exceptions, period, even for "brown bags".
>
> I can see
#x27; on such a tag,
once announced. No exceptions, period, even for "brown bags".
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN P
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephan Richter wrote:
> On Sunday 08 July 2007 13:19, Tres Seaver wrote:
>> I don't see how that can be: 'zope.event' hsa no dependencies[1], and
>> provides a service which is at least as low-level (lower, in my opinio
27;zope',],
tests_require = ['zope.testing'],
install_requires=['setuptools',
'zope.i18nmessageid',
'zope.interface',
'zope.event',
],
Tres.
- -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tres Seaver wrote:
> Stephan Richter wrote:
>> On Wednesday 04 July 2007 08:08, Jim Fulton wrote:
>>> I propose we stop bothering to include $Id$ strings. (Note that I'm
>>> *not* suggesting we go out of our way t
hout a network call; is
that too much trouble?
Tres.
- --
=======
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux
uture is the way to go. Removing them opportunistically
> (as modules get touched anyway) would be welcome gardening of the
> codebase.
- -1. Such cosmetic cleanup tends to make backporting patches harder, for
very little win.
Tres.
- --
===
't think we have figured out yet how to handle the "known
good working set" problem: not having a handle on that is actually the
biggest risk of eggification (really, of the "satellite project" model).
Continuous integration (e.g., buildbot testing) against such a worki
e setting up of contexts like
> db, site, global utils etc? I've googled around a fair bit and been
> over all the z3 doco, it would be great if there was a simple howto on
> setting up a thread that would have the usual access to various
> components.
Tres.
- --
==
ny sort.
>
> Geeh. I'm so blind. :(
That is actually why I am against the practice of using "real" objects
as markers, instead of artificial ones with obvious names: it makes the
reader stop, and breaks the flow. Too clever by half, as it were.
Trse.
- --
might want this to work in the long run.
Hanno has checked in a Zope2 patch which makes 'zopectl' work on
Windows, and adds two new Windows-specific commands to install and
remove the Zope servvice:
http://svn.zope.org/Zope/trunk/lib/python/Zope2/Startup/zopectl.py?rev=75066&view=rev
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Fulton wrote:
> On May 31, 2007, at 10:58 AM, Tres Seaver wrote:
>> I'd rather have the dot, e.g. "foo 2.* >= 2.5", just for clarity:
>>
>> - It makes the intent clearer (that you want any versi
ot; release line).
- It disambiguates the case where the version number might have
double digits (e.g, '0.1' vs. '0.10').
Another feature I'm not sure is already in setuptools:
- I *don't* want dev releases to replace production ones
implicitly: no package
se. AFAIK, eggification is on
the roadmap for 3.5, right? So we should be focused on stabilizing the
"last zpkg build", while still allowing the eggified / broken-out
project model to move forward.
Tres.
- --
===
Tres Sea
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marius Gedminas wrote:
> On Mon, May 21, 2007 at 12:21:42PM -0400, Tres Seaver wrote:
>> Reinoud van Leeuwen wrote:
>>> On Mon, May 21, 2007 at 10:39:22AM -0400, Fred Drake wrote:
>>> As a developer it might be a good idea
se workingenv didn't provide enough
> control or automation for my needs.)
I use virtual python for this, actually: the separate tree makes it
possible to allow distutils / easy_install to "pollute" their own,
private site-packages directory without my having to fight with
sys.pa
ork around a bug which is only
problemnatic for long-running Python instances (e.g., the
longstanding cgi.FieldStorage DoS problem).
- You can create a repeatable environment for testing each deployed
application, even where those applications are running on boxes
with different OS / distro
rious satellite
projects.
+1 for avoiding gratuitous version-specific dependencies in "library"
eggs; unless there is a known incompatibility, eggs should specify
their dependencies by name.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bethany Nohlgren
Assistant Dean of Students and Director of First-Year Students
x7454
[EMAIL PROTECTED]
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED
e main Zope tree.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http:/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christian Theune wrote:
> Hi,
>
> Am Donnerstag, den 03.05.2007, 13:18 -0400 schrieb Tres Seaver:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Fred Drake wrote:
>>> On 5/3/07, Christian Theune
e aren't going
to do release management on the pieces, then for sanity's sake keep them
in-tree.
Plone's own trunk-based bundles are living proof of the hell that is
caused by having svn:externals point at non-frozen dependencies.
Tres.
- --
===
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
> Tres Seaver wrote:
> [snip]
>> One example of such an implementation would be an optional, lxml-based
>> directive which uses the native structure of the ZCML file and XPath.
>> E.g. to include only
third-party library like lxml; folks who can't install lxml just lose
this feature.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNA
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
> Hello,
>
> Tres Seaver wrote:
>> David Pratt wrote:
>>> On the basis that eggs spell out dependencies, I am thinking the
>>> inclusion of packages and their dependencies should be enoug
hat has ZCML should load
> the ZCML from other eggs it depends on. This means that these eggs
> have to be designed this way.
Our override story is too weak to support this now, because the author
of package "C" may make a configuration choice which is inappropriate
for how "C&qu
.zcml'. Until then, I don't
want package authors dictating to site managers.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tres Seaver wrote:
> Rocky Burt wrote:
>> On Wed, 2007-10-01 at 11:09 -0500, Tres Seaver wrote:
>>> While I am vehemently opposed to code generation per se, one alternative
>>> which I think is important is to gener
sed code in
> Plone. Simply because everyone are acustomed to the structures and
> conventions.
I think you just proved Martin's point: in my experience, maintaining
other people's AT-based code is like Napoleon before Moscow: thigh deep
in freezing mud.
Tres.
- --
=
quot; or "license" for more information.
>>> from zope.pagetemplate.pagetemplatefile import PageTemplateFile
>>>
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion S
allow the superuser to attempt to hard link directories (note:
will probably fail due to system restrictions, even for the
superuser)
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL
e in Javascript using
'getElementById'.
- -1 on changing the default behavior; to paraphrase, "broken browsers
you will have always with you."
+1 on changing 'renderTag' to use some kind of "local" policy (e.g.,
look up an 'ITagElementCleaner' utility
to the developer who checks out the
whole thing.
I know that distutils / setuptools complain if they find no 'README.txt
' next to setup.py: I ususally have a nearly empty one pointing "down"
to the real one.
Tres.
- --
===
T
e
('FooUtil', 'default')
Named utilities can also be looked up (SF)::
>>> u_named = IFoo(name='named')
>>> u_named.__class__.__name__, u_named.name
('FooUtil', 'named')
Default adapter lookup works as expected::
>>> context
gt;> getMultiAdapter((1,1),ITest)
> Traceback (most recent call last):
> ...
> zope.component.interfaces.ComponentLookupError:
> ((1, 1), , u'')
>
> Oh dear, what have I done wrong here?
The "order" of your adapter registration is *one*, but you are try
t 0xb6a319ac>,
>>'usage': > 0xb5c3ea4c>,
>>'view': > from /usr/lib/zope3/lib/python/zope/app/apidoc/ifacemodule/index.pt
>> object at 0xb5c3ef4c>,
>>'views': > object at 0xb5bf9d6c>}
Please give us
ode text to the page template. No encoding=""
> bit will be in the XML presented in the editor.
>
> F) form submit: Rip out any encoding="" before storing, ignoring it as
> XML was in output encoding, then convert to unicode using input encoding.
>
> encod
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
> Tres Seaver wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Andreas Jung wrote:
>>> --On 14. Januar 2007 18:14:45 + Chris Withers <[EMAIL PROTECTED]>
>&g
. The Zope 2
> publisher "avoids" this problem converting the unicode result using
> errors='replace' (which is likely something we might discuss :-))
Unicode XML is not only problematic for streaming. For instance, you
*can't* pass a Unicode string to the libxml2 *at all* , unle
1 - 100 of 282 matches
Mail list logo
