Re: zope vs openACS
Bruno Desthuilliers <[EMAIL PROTECTED]> wrote: > Stefan Scholl a écrit : >> [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >>> On Nov 19, 1:50 am, gavino <[EMAIL PROTECTED]> wrote: >>>> what is nicer about each? >>> Yes. >> >> And No. >> > Or maybe ? This isn't Haskell. -- http://mail.python.org/mailman/listinfo/python-list
Re: zope vs openACS
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On Nov 19, 1:50 am, gavino <[EMAIL PROTECTED]> wrote: >> what is nicer about each? > > Yes. And No. -- http://mail.python.org/mailman/listinfo/python-list
Re: Amazon: "Practical Django Projects" by James Bennett (June 2008)
Fredrik Lundh <[EMAIL PROTECTED]> wrote: > (and the "stable release" and "much will change" stuff is pure FUD, of > course. what competing project will I find if I google your name?) Found something? Maybe this could help me to choose a web framework. -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Amazon: "Practical Django Projects" by James Bennett (June 2008)
Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote: > On Thu, 17 Jul 2008 05:41:11 +0200, Stefan Scholl wrote: >> Fredrik Lundh <[EMAIL PROTECTED]> wrote: >>> Stefan Scholl wrote: >>> >>>> Django isn't ready. >>> >>> That's a remarkably ignorant statement. >> >> The 1.0 release will be in September. > > So what? It's not the version number that matters but features and > stability. It's not uncommon in open source projects to have very usable > software with a version number below 1.0. The book is about the development version, which was current at the time the book was written. See page 4. Nobody says something about "Book after feature freeze" (or similar). Instead I get "ignorant statement" and "usable software". My conclusion: This book isn't about a stable release and not about a future stable release. (And even if it was about the last stable relase, too much has changed and will change until September 2008. IMHO.) And by the way: The quote was changed by deleting something on the same line: "June 2008 is a bit too early. Django isn't ready." vs. "Django isn't ready." -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Amazon: "Practical Django Projects" by James Bennett (June 2008)
Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Stefan Scholl wrote: > >> Django isn't ready. > > That's a remarkably ignorant statement. The 1.0 release will be in September. -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Amazon: "Practical Django Projects" by James Bennett (June 2008)
Dave U. Random <[EMAIL PROTECTED]> wrote: > http://snipr.com/PracticalDjango June 2008 is a bit too early. Django isn't ready. -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/ -- http://mail.python.org/mailman/listinfo/python-list
Re: developing web spider
abeen <[EMAIL PROTECTED]> wrote: > I would want to know which could be the best programming language for > developing web spider. Since you ask in comp.lang.python: I'd suggest APL -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Any reason why cStringIO in 2.5 behaves different from 2.4?
Michael L Torrie <[EMAIL PROTECTED]> wrote:
> Stefan Scholl wrote:
>> Don't let the subject line fool you. I'm OK with cStringIO. The
>> thread is now about xml.sax's parseString().
>
> Giving you the benefit of the doubt here, despite the fact that Stefan
> Behnel has state this over and over again and you just haven't listened.
Speaking of over and over again ...
> xml.sax's use of parseString() is exactly correct. xml.sax should
> *never* parse python unicode strings as by definition XML must be
> encoded as a *byte stream*, which is what a python string is.
I don't care about the definition of XML at this point of the
program. http://docs.python.org/lib/module-xml.sax.html calls
parseString() a convenience function.
This is Python. Python has a class named unicode. Its literals
look like strings. The base class is basestring.
xml.sax belongs to Python. Batteries included. parseString() is
in Python.
It's not parseString() that tells me something is wrong with the
parameter. It's cStringIO, which is used on platforms where it is
available. On other platforms no exceptions are thrown, because
then StringIO is used, which behaves in Python 2.4 and Python 2.5
the same, regarding unicode strings.
Other libraries like LXML (not included) parse unicode strings.
And these are two additional lines in my code now:
if isinstance(string, unicode):
string = string.encode("utf-8")
> A python /unicode/ string could be held internally in any number of
> ways, 2, 3, 4, or even 8 bytes per character if the implementation
> demanded it (a bit contrived, I admit). Since the xml parser is only
> ever intended to parse *XML*, why should it ever know what to do with
> python unicode strings, which could be stored any number of ways, making
> byte-parsing impossible.
xml.sax is no external parser. The program doesn't have to
communicate with the outside world at this point of execution.
The Python programm calls a Python function of a Python class and
passes a Python unicode string as parameter.
XML parsers only have to support few encodings. But nobody has
something against it when they support more than that.
A Python convenience function isn't broken when it allows Python
unicode strings.
The behavior of cStringIO (the original topic of this thread) is
correct and documented. parseString() uses the old idiom where
cStringIO is imported as StringIO, when available. Despite the
fact that they behave differently.
In my personal opinion: If parseString() shouldn't support
unicode strings, then it should check for it and throw a
meaningful exception.
At the moment the code just looks as if someone has overlooked
the fact that unicode strings (with non-ascii characters in it)
cause a problem. Missing test?
> So your code is faulty in its assumptions, not xml.sax.
As I said in the conclusion, a few messages before: Undocumented,
implementation dependent behavior.
Or maybe just a bug, considering the following on
http://docs.python.org/lib/module-xml.sax.html
A typical SAX application uses three kinds of objects:
readers, handlers and input sources. ``Reader'' in this
context is another term for parser, i.e. some piece of
code that reads the bytes or characters from the input
source, and produces a sequence of events.
Bytes _or_ characters.
--
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/
--
http://mail.python.org/mailman/listinfo/python-list
Re: Any reason why cStringIO in 2.5 behaves different from 2.4?
Chris Mellon <[EMAIL PROTECTED]> wrote: > On 7/28/07, Stefan Scholl <[EMAIL PROTECTED]> wrote: >> Just checked on a system without PyXML: xml/sax/__init__.py >> defines parseString() and uses cStringIO (when available). >> >> Python 2.5.1 >> > > Yes, thats the fixed bug. After all this you still do not seem to be > clear on what the bug is. The bug is not that your code fails in 2.5, > it's that it worked at all in 2.4. Don't let the subject line fool you. I'm OK with cStringIO. The thread is now about xml.sax's parseString(). -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Any reason why cStringIO in 2.5 behaves different from 2.4?
Stefan Behnel <[EMAIL PROTECTED]> wrote: > Stefan Scholl wrote: >> But the style of the answers makes me wonder if I should report >> the bug in xml.sax (or its documentation) or just ignore it. > > Note that PyXML is no longer actively maintained, so it's unlikely that Too bad it can still be found in at least 80 % of all XML examples. I should burn the XML chapter of the cookbook. By the way: Thanks for the tip regarding LXML. I'll try to remember it for the next project. > reporting the bug would get you a version that raises an exception when > passing a unicode string *independent of the Python version*. > > Besides, the bug has been fixed in Python 2.5 already. Just checked on a system without PyXML: xml/sax/__init__.py defines parseString() and uses cStringIO (when available). Python 2.5.1 -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Any reason why cStringIO in 2.5 behaves different from 2.4?
Chris Mellon <[EMAIL PROTECTED]> wrote: > On 7/26/07, Stefan Scholl <[EMAIL PROTECTED]> wrote: >> Chris Mellon <[EMAIL PROTECTED]> wrote: >> > XML is not a string. It's a specific type of bytestream. If you want >> > to work with XML, then generate well-formed XML in the correct >> > encoding. There's no reason you should have an XML document (as >> > opposed to values extracted from that document) in unicode objects at >> > all. >> >> The affected method in xml.sax is called parseString() > > The imprecision of the english language has caused greater problems > than this. Since you've now had everything clarified for you, and the > imprecision is resolved, I'm sure that this won't be a problem again. Right. I now know that xml.sax's parseString() has undocumented implementation dependent behavior. That there are libraries (not included with Python) which can parse Unicode strings. And that the reason to change cStringIO's behavior is acceptable. But the style of the answers makes me wonder if I should report the bug in xml.sax (or its documentation) or just ignore it. -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Any reason why cStringIO in 2.5 behaves different from 2.4?
Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote: > On Fri, 27 Jul 2007 06:47:48 +0200, Stefan Scholl wrote: > >> Chris Mellon <[EMAIL PROTECTED]> wrote: >>> XML is not a string. It's a specific type of bytestream. If you want >>> to work with XML, then generate well-formed XML in the correct >>> encoding. There's no reason you should have an XML document (as >>> opposed to values extracted from that document) in unicode objects at >>> all. >> >> The affected method in xml.sax is called parseString() > > Exactly. It's *not* called `parseUnicode()`. Semantics. >>> u"".__class__.__base__ >>> "".__class__.__base__ -- http://mail.python.org/mailman/listinfo/python-list
Re: Any reason why cStringIO in 2.5 behaves different from 2.4?
Stefan Behnel <[EMAIL PROTECTED]> wrote: > Stefan Scholl wrote: >> Stefan Behnel <[EMAIL PROTECTED]> wrote: >>> The XML is *not* well-formed if you pass Python unicode instead of a byte >>> encoded string. Read the XML spec. >> >> Pointers, please. > > There you have it: > > http://www.w3.org/TR/xml/#charencoding > > """ > In the absence of information provided by an external transport protocol (e.g. > HTTP or MIME), it is a *fatal error* for an entity including an encoding > Byte Order Mark nor an encoding declaration to use an encoding other than > UTF-8. > """ > specific). You might argue that there is some kind of "external transportation > protocol" as it is a Python Unicode string (I used that excuse when I Not the string itself. The method that ist called: parseString() -- http://mail.python.org/mailman/listinfo/python-list
Re: Any reason why cStringIO in 2.5 behaves different from 2.4?
Chris Mellon <[EMAIL PROTECTED]> wrote: > XML is not a string. It's a specific type of bytestream. If you want > to work with XML, then generate well-formed XML in the correct > encoding. There's no reason you should have an XML document (as > opposed to values extracted from that document) in unicode objects at > all. The affected method in xml.sax is called parseString() -- http://mail.python.org/mailman/listinfo/python-list
Re: Any reason why cStringIO in 2.5 behaves different from 2.4?
Stefan Behnel <[EMAIL PROTECTED]> wrote: > The XML is *not* well-formed if you pass Python unicode instead of a byte > encoded string. Read the XML spec. Pointers, please. Last time I read that part of the spec was when a customer's consulting company switched to ISO-8859-15 without saying something beforehand. The old code (PHP) I have to maintain couldn't deal with it. It was wrong to switch encoding without telling somebody about it. And a XML processor isn't required to support ISO-8859-15. But I thought it was too embarrassing not to support this encoding. I fixed that part without making a fuss. A Python XML processor that can't handle the own encoding is embarrassing. It isn't required to support it. It would be OK if it wouldn't support UTF-7. But a parseString() method that doesn't want Python strings? No way! -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Any reason why cStringIO in 2.5 behaves different from 2.4?
Stefan Behnel <[EMAIL PROTECTED]> wrote: > Stefan Scholl wrote: >> Stefan Behnel <[EMAIL PROTECTED]> wrote: >>> Stefan Scholl wrote: >>>> Stefan Behnel <[EMAIL PROTECTED]> wrote: >>>>> Stefan Scholl wrote: >>>>>> Well, http://docs.python.org/lib/module-xml.sax.html is missing >>>>>> the fact, that I can't use Unicode with parseString(). >>>>>> >>>>>> This parseString() uses cStringIO. >>>>> Well, Python unicode is not a valid *byte* encoding for XML. >>>>> >>>>> lxml.etree can parse unicode, if you really want, but otherwise, you >>>>> should >>>>> maybe stick to well-formed XML. >>>> The XML is well-formed. Works perfect in Python 2.4 with Python >>>> unicode and Python sax parser. >>> The XML is *not* well-formed if you pass Python unicode instead of a byte >>> encoded string. Read the XML spec. >>> >>> It would be well-formed if you added the proper XML declaration, but that is >>> system specific (UCS-4 or UTF-16, BE or LE). So don't even try. >> >> Who cares? I'm not calling any external tools. > > XML cares. If you want to work with something that is not XML, do not expect > XML tools to help you do it. XML tools work with XML, and there is a spec that > says what XML is. Your string is not XML. This isn't some sophisticated XML tool that tells me the string is wrong. It's a changed behavior of cStringIO that throws an exception. While I'm just using the method parseString() of xml.sax. We both repeat ourselves. I don't think this thread brings something new. I'm all for correct XML and hate XML bozos. But there are limits you have to learn after a few years. -- http://mail.python.org/mailman/listinfo/python-list
Re: Any reason why cStringIO in 2.5 behaves different from 2.4?
Stefan Behnel <[EMAIL PROTECTED]> wrote: > Stefan Scholl wrote: >> Stefan Behnel <[EMAIL PROTECTED]> wrote: >>> Stefan Scholl wrote: >>>> Well, http://docs.python.org/lib/module-xml.sax.html is missing >>>> the fact, that I can't use Unicode with parseString(). >>>> >>>> This parseString() uses cStringIO. >>> Well, Python unicode is not a valid *byte* encoding for XML. >>> >>> lxml.etree can parse unicode, if you really want, but otherwise, you should >>> maybe stick to well-formed XML. >> >> The XML is well-formed. Works perfect in Python 2.4 with Python >> unicode and Python sax parser. > > The XML is *not* well-formed if you pass Python unicode instead of a byte > encoded string. Read the XML spec. > > It would be well-formed if you added the proper XML declaration, but that is > system specific (UCS-4 or UTF-16, BE or LE). So don't even try. Who cares? I'm not calling any external tools. Python should know its own strings. -- http://mail.python.org/mailman/listinfo/python-list
Re: Any reason why cStringIO in 2.5 behaves different from 2.4?
Stefan Behnel <[EMAIL PROTECTED]> wrote: > Stefan Scholl wrote: >> Well, http://docs.python.org/lib/module-xml.sax.html is missing >> the fact, that I can't use Unicode with parseString(). >> >> This parseString() uses cStringIO. > > Well, Python unicode is not a valid *byte* encoding for XML. > > lxml.etree can parse unicode, if you really want, but otherwise, you should > maybe stick to well-formed XML. The XML is well-formed. Works perfect in Python 2.4 with Python unicode and Python sax parser. This stays all inside Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Any reason why cStringIO in 2.5 behaves different from 2.4?
Stefan Behnel <[EMAIL PROTECTED]> wrote: > Stefan Scholl wrote: >> After an hour searching for a potential bug in XML parsing >> (PyXML), after updating from 2.4 to 2.5, I found this one: >> >> $ python2.5 >> Python 2.5 (release25-maint, Dec 9 2006, 14:35:53) >> [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)] on linux2 >> Type "help", "copyright", "credits" or "license" for more information. >>>>> import StringIO >>>>> x = StringIO.StringIO(u"m\xf6p") >>>>> import cStringIO >>>>> x = cStringIO.StringIO(u"m\xf6p") >> Traceback (most recent call last): >> File "", line 1, in >> UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6' in position >> 1: ordinal not in range(128) >> $ python >> Python 2.4.4 (#2, Apr 5 2007, 20:11:18) >> [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2 >> Type "help", "copyright", "credits" or "license" for more information. >>>>> import StringIO >>>>> x = StringIO.StringIO(u"m\xf6p") >>>>> import cStringIO >>>>> x = cStringIO.StringIO(u"m\xf6p") >> >> >> OK, that's why my code was fine with Python 2.4 and breaks with >> 2.5. > > It wasn't fine with 2.4 either: Worked in my test, a few lines above ... > > """ > Unlike the memory files implemented by the StringIO module, those provided by > this module are not able to accept Unicode strings that cannot be encoded as > plain ASCII strings. > """ > > http://docs.python.org/lib/module-cStringIO.html > > Read the docs... Well, http://docs.python.org/lib/module-xml.sax.html is missing the fact, that I can't use Unicode with parseString(). This parseString() uses cStringIO. -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/ -- http://mail.python.org/mailman/listinfo/python-list
Any reason why cStringIO in 2.5 behaves different from 2.4?
After an hour searching for a potential bug in XML parsing
(PyXML), after updating from 2.4 to 2.5, I found this one:
$ python2.5
Python 2.5 (release25-maint, Dec 9 2006, 14:35:53)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import StringIO
>>> x = StringIO.StringIO(u"m\xf6p")
>>> import cStringIO
>>> x = cStringIO.StringIO(u"m\xf6p")
Traceback (most recent call last):
File "", line 1, in
UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6' in position 1:
ordinal not in range(128)
>>>
$ python
Python 2.4.4 (#2, Apr 5 2007, 20:11:18)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import StringIO
>>> x = StringIO.StringIO(u"m\xf6p")
>>> import cStringIO
>>> x = cStringIO.StringIO(u"m\xf6p")
>>>
OK, that's why my code was fine with Python 2.4 and breaks with
2.5.
{sigh}
--
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/
--
http://mail.python.org/mailman/listinfo/python-list
Re: Microsoft's Dynamic Languages Runtime (DLR)
In comp.lang.lisp sturlamolden <[EMAIL PROTECTED]> wrote: > I am curious to know how it performs in comparison to CPython and an > efficient compiled Lisp like CMUCL. Speed is a major problem with You are not allowed to publish .NET benchmarks. :-) -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/ -- http://mail.python.org/mailman/listinfo/python-list
Re: pop method question
Nicholas Parsons <[EMAIL PROTECTED]> wrote: > I realize that in this context it is used for removing a specific key > from the current dictionary object. But why call it pop and not > something more intuitive like remove or delete? I wasn't a python programmer back than, but I'd guess it's because pop not just removes the key, it returns the value as well. -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Django, one more newbie question
Boris Ozegovic <[EMAIL PROTECTED]> wrote: > Umm, can somebody tell me which language is this one: >No polls are available. English? -- http://mail.python.org/mailman/listinfo/python-list
Re: A mail from Steve Ballmer. See what Microsoft will do and follow.
JustStand <[EMAIL PROTECTED]> wrote: > In many ways, it was the launch of Windows 95 and Office 95 eleven > years ago that signaled the start of this transformation. ..." Right. 11 years ago I switched from Amiga to Linux. -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Computer Language Popularity Trend
In comp.lang.lisp Jon Ribbens <[EMAIL PROTECTED]> wrote: > In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: >>> http://xahlee.org/lang_traf/index.html >> >> Careful there with the sweeping generalizations and quick judgments >> about languages :) > > I just read "PHP as a language is rather dry and business-like", > and fell off my chair. Well, business really is that crazy! :-) -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/ -- http://mail.python.org/mailman/listinfo/python-list
