Re: [Python-Dev] Fixing the XML batteries

[Tim Wintle]

On Fri, 2011-12-09 at 19:39 +0100, Xavier Morel wrote:
> On 2011-12-09, at 19:15 , Bill Janssen wrote:
> > I use ElementTree for parsing valid XML, but minidom for producing it.
> Could you expand on your reasons to use minidom for producing XML?

To throw my 2c in here:

I personally normally use minidom for manipulating (x)html data (through
html5lib), and for writing XML.

I think it's primarily because DOM:

a) matches the way I think about XML documents.

b) Provides the same API as I use in other languages. (FWIW, I do a lot
of DOM manipulation in javascript)

c) "Feels" (to me) more similar to other formats I work with.


All three may be because I haven't spent enough time with ElementTree -
again I've found the documentation lacking.

Tim

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PATCH] Adding braces to __future__

[Ben Finney]

Guido van Rossum  writes:

> On Fri, Dec 9, 2011 at 12:26 PM, Cedric Sodhi  wrote:
>
> > IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT THIS HAD
> > BEEN DISCUSSED BEFORE, REPLY THAT "IT'S SIMPLY NOT GO'NNA HAPPEN",
> > THAT "WHO DOESN'T LIKE IT IS FREE TO CHOOSE ANOTHER LANGUAGE" OR
> > SOMETHING SIMILAR, JUST DON'T.
>
> Every single response in this thread so far has ignored this request.

The request was completely unreasonable. Cedric does not get to
unilaterally set restrictions on who and how people respond to a screed
in a public forum.

> the rest I have to say about the topic would violate the above
> request.

You have my permission to violate the above request. That should have at
least as much authority as the request itself, so you are hereby
empowered to respond as you like.

-- 
 \ “We can't depend for the long run on distinguishing one |
  `\ bitstream from another in order to figure out which rules |
_o__)   apply.” —Eben Moglen, _Anarchism Triumphant_, 1999 |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PATCH] Adding braces to __future__

[Guido van Rossum]

On Sat, Dec 10, 2011 at 4:15 AM, Ben Finney wrote:

> Guido van Rossum  writes:
>
> > On Fri, Dec 9, 2011 at 12:26 PM, Cedric Sodhi  wrote:
> >
> > > IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT THIS HAD
> > > BEEN DISCUSSED BEFORE, REPLY THAT "IT'S SIMPLY NOT GO'NNA HAPPEN",
> > > THAT "WHO DOESN'T LIKE IT IS FREE TO CHOOSE ANOTHER LANGUAGE" OR
> > > SOMETHING SIMILAR, JUST DON'T.
> >
> > Every single response in this thread so far has ignored this request.
>
> The request was completely unreasonable. Cedric does not get to
> unilaterally set restrictions on who and how people respond to a screed
> in a public forum.
>

Oh, of course. I was just playing along. But my real point was to berate
the community for responding at all to such an obvious trolling post.


>  > the rest I have to say about the topic would violate the above
> > request.
>
> You have my permission to violate the above request. That should have at
> least as much authority as the request itself, so you are hereby
> empowered to respond as you like.
>

It would be utterly redundant. He said it all in his all-caps message.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PATCH] Adding braces to __future__

[francis]

Hi Cedric,

On 12/09/2011 09:26 PM, Cedric Sodhi wrote:

It is widely known among the programmer's community that spaces and tabs
are remarkably similar to eachother. So similar even, that people fight
wars about which to use in a non-py context. It might strike one as an
equally remarkably nonsensical idea to give them programmatic meaning -
two DIFFERENT meanings, to make things even worse.

While it becomes a practical impossibility to spot these kind of bugs
while reviewing code -- optionally mangled through a medium which
expands tabs to whitespace, not so much of a rarity -- it is still a
time-consuming and tedious job to find them in a local situation.



I'm not so experienced with python as the majority of
people here, but I've read that the practice is: do not to
mix them (spaces and tabs).

If this is taking much of you time while reviewing I would
recommend you to let some script run on you code first to
spot that mixture. IMHO that is a rule that should go in the
code rules of your project and the build process should break
if this mixture if found. Don't let that code reach the sync
repository. As I said I'm maybe failing to see some case.

Formatting is like food, everyone has it's own taste. One has
to use spicery to change it (if possible). For me the view of
the code (the layout) by the programmer should be automatically
changed by the tool that reads the code. Here you could have
a python with braces if you want... (I thing that 'go' has some
autoformater or a standard way of formatting).

-- francis

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tag trackbacks with version (was Re: readd u'' literal support in 3.3?)

[PJ Eby]

On Fri, Dec 9, 2011 at 11:11 PM, Terry Reedy  wrote:

> This just gave me the idea of tagging tracebacks with the Python version
> number. Something like
>
> Traceback (Py3.2.2, most recent call last):
>
> and perhaps with the platform also
>
> Traceback (most recent call last) [Py3.2.2 on win23]:
>
> Since computation has stopped, the few extra milliseconds is trivial. This
> would certainly help on Python list and the tracker when people do post the
> traceback (which they do not always) without version and system (which they
> often do not, especially on Python list). It might suggest to people that
> this is important info to include. I wonder if this would also help with
> tracebacks sent to library/app developers.
>

Yes, but doctest will need to take this into account, both for its native
traceback matcher, and for traceback matches using ellipses.  Otherwise you
introduce more Python version hell for doctest users.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tag trackbacks with version (was Re: readd u'' literal support in 3.3?)

[Steven D'Aprano]

Terry Reedy wrote:

On 12/9/2011 5:17 AM, Nick Coghlan wrote:


As Chris pointed out though, the real problem with the "repeatedly run
2to3" workflow is that it can make interpreting tracebacks from the
field *really* hard.


This just gave me the idea of tagging tracebacks with the Python version 
number. Something like


Traceback (Py3.2.2, most recent call last):

and perhaps with the platform also

Traceback (most recent call last) [Py3.2.2 on win23]:

Since computation has stopped, the few extra milliseconds is trivial. 
This would certainly help on Python list and the tracker when people do 
post the traceback (which they do not always) without version and system 
(which they often do not, especially on Python list). It might suggest 
to people that this is important info to include.

[...]

But how often is it actually important information to include?

I am active on both the tutor and the python-list lists, and it seems to me 
that this proposed feature won't be very useful in either place. In my 
experience, the version number is rarely important for the sorts of questions 
that are commonly asked. Python is quite a stable language, and alist = 
alist.append(1) has confused newbies since version 1.5 and will probably 
continue confusing them in version 4000. (Aside: I was reading historical 
What's New docs today, and was stunned to realise how many cool features go 
back all the way to version 2.0.)


Obviously there are times where knowing the version is useful, but often you 
can often derive the version number from the error (at least to 1 significant 
figure):


>>> map(chr, (40, 41, 42))[1]
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'map' object is not subscriptable

Assuming map has not been shadowed, this is obviously Python 3.

If the question involves tracking down an actual bug in Python, the version 
number becomes important. E.g. "it works as documented in 2.6 on Linux, but 
not in 2.7 on OS-X" sort of thing. But that's quite unusual.


Newbies barely read tracebacks at all. Adding the version number and platform 
will just add more text which they won't read and will probably discourage 
them further from reading it (more text = less chance they read it). 
Experienced coders tend to know when the version number is important and 
provided it only when necessary. So it's hard to see who this is aimed at... 
users experienced enough to pay attention to tracebacks but not experienced 
enough to know when to provide the version number?


YMMV, but I don't see much value in this. If it comes at the cost of making 
doctest harder to use, I'm actively against it. Otherwise I'm just mildly 
"meh, why bother?".




--
Steven

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PATCH] Adding braces to __future__

[Serhiy Storchaka]

10.12.11 13:14, francis написав(ла):

Formatting is like food, everyone has it's own taste. One has
to use spicery to change it (if possible). For me the view of
the code (the layout) by the programmer should be automatically
changed by the tool that reads the code. Here you could have
a python with braces if you want... (I thing that 'go' has some
autoformater or a standard way of formatting).


pindent -c

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PATCH] Adding braces to __future__

[Xavier Morel]

On 2011-12-10, at 12:14 , francis wrote:
> 
> (I thing that 'go' has some
> autoformater or a standard way of formatting).
`gofmt` yes, it simply reformats all the code to match the style
decided by the core go team, it does not provide support formatting-
independent edition.

Think of it as pep8.py editing the code in place instead of just
reporting the stuff it does not like.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fixing the XML batteries

[Bill Janssen]

Stefan Behnel  wrote:

> Bill Janssen, 09.12.2011 19:15:
> > I think another thing that might go into "refreshing the batteries" is a
> > feature comparison of BeautifulSoup and HTML5lib against the stdlib
> > competition, to see what needs to be added/revised.  Having to switch to
> > an outside package for parsing possibly invalid HTML is a pain.
> 
> Such a feature request should be worth a separate thread.
> 
> Note, however, that html5lib is likely way too big to add it to the
> stdlib, and that BeautifulSoup lacks a parser for non-conforming HTML
> in Python 3, which would be the target release series for better HTML
> support. So, whatever library or API you would want to use for HTML
> processing is currently only the second question as long as Py3 lacks
> a real-world HTML parser in the stdlib, as well as a robust character
> detection mechanism. I don't think that can be fixed all that easily.

Sounds like it needs a PEP.

I'm only advocating spending some thought on what needs to be done --
whether outside libraries need to be adopted into the stdlib would be a
step after that.  But understanding *why* those libraries exist and are
widely used should be a prerequisite to "refreshing" the stdlib's support.

Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fixing the XML batteries

[Glyph Lefkowitz]

On Dec 10, 2011, at 2:38 AM, Stefan Behnel wrote:

> Note, however, that html5lib is likely way too big to add it to the stdlib, 
> and that BeautifulSoup lacks a parser for non-conforming HTML in Python 3, 
> which would be the target release series for better HTML support. So, 
> whatever library or API you would want to use for HTML processing is 
> currently only the second question as long as Py3 lacks a real-world HTML 
> parser in the stdlib, as well as a robust character detection mechanism. I 
> don't think that can be fixed all that easily.


Here's the problem in a nutshell, I think:

Everybody wants an HTML parser in the stdlib, because it's inconvenient to pull 
in a dependency for such a "simple" task.
Everybody wants the stdlib to remain small, stable, and simple and not get 
"overcomplicated".
Parsing arbitrary HTML5 is a monstrously complex problem, for which there exist 
rapidly-evolving standards and libraries to deal with it.  Parsing 'the web' 
(which is rapidly growing to include stuff like SVG, MathML etc) is even harder.

My personal opinion is that HTML5Lib gets this problem almost completely right, 
and so it should be absorbed by the stdlib.  Trying to re-invent this from 
scratch, or even use something like BeautifulSoup which uses a bunch of 
heuristics and hacks rather than reference to the laboriously-crafted standard 
that says exactly how parsing malformed stuff has to go to be "like a browser", 
seems like it will just give the stdlib solution a reputation for working on 
the test input but not working in the real world.

(No disrespect to BeautifulSoup: it was a great attempt in the pre-HTML5 world 
which it was born into, and I've used it numerous times to implement useful 
things.  But much more effort has been poured into this problem since then, and 
the problems are better understood now.)

-glyph

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PATCH] Adding braces to __future__

[Lennart Regebro]

On Sat, Dec 10, 2011 at 13:15, Ben Finney  wrote:
> Guido van Rossum  writes:
>
>> On Fri, Dec 9, 2011 at 12:26 PM, Cedric Sodhi  wrote:
>>
>> > IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT THIS HAD
>> > BEEN DISCUSSED BEFORE, REPLY THAT "IT'S SIMPLY NOT GO'NNA HAPPEN",
>> > THAT "WHO DOESN'T LIKE IT IS FREE TO CHOOSE ANOTHER LANGUAGE" OR
>> > SOMETHING SIMILAR, JUST DON'T.
>>
>> Every single response in this thread so far has ignored this request.
>
> The request was completely unreasonable.

As it basically said "I will ignore everything everyone ever will say
on this issue, and if you don't think I should do that, then you
should ignore me", I find the request very reasonable. I wish more
people would advertise that they not only know about the facts of the
matter but completely ignore them. It's basically a big sign saying
"LALALALIMNOTLISTENING", which would shorten a lot of internet debates
if it was more widely used. :-)

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tag trackbacks with version (was Re: readd u'' literal support in 3.3?)

[Terry Reedy]

On 12/10/2011 12:09 PM, PJ Eby wrote:

On Fri, Dec 9, 2011 at 11:11 PM, Terry Reedy mailto:tjre...@udel.edu>> wrote:

This just gave me the idea of tagging tracebacks with the Python
version number. Something like

Traceback (Py3.2.2, most recent call last):

and perhaps with the platform also

Traceback (most recent call last) [Py3.2.2 on win23]:

Since computation has stopped, the few extra milliseconds is
trivial. This would certainly help on Python list and the tracker
when people do post the traceback (which they do not always) without
version and system (which they often do not, especially on Python
list). It might suggest to people that this is important info to
include. I wonder if this would also help with tracebacks sent to
library/app developers.


Yes, but doctest will need to take this into account, both for its
native traceback matcher, and for traceback matches using ellipses.
  Otherwise you introduce more Python version hell for doctest users.


Is doctest really insisting that the whole line
  Traceback (most recent call last):
exactly match, with nothing added? It really should not, as that is not 
part of the language spec. This seems like the tail wagging the dog.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tag trackbacks with version (was Re: readd u'' literal support in 3.3?)

[Terry Reedy]

On 12/10/2011 12:52 PM, Steven D'Aprano wrote:

Terry Reedy wrote:

On 12/9/2011 5:17 AM, Nick Coghlan wrote:


As Chris pointed out though, the real problem with the "repeatedly run
2to3" workflow is that it can make interpreting tracebacks from the
field *really* hard.


This just gave me the idea of tagging tracebacks with the Python
version number. Something like

Traceback (Py3.2.2, most recent call last):

and perhaps with the platform also

Traceback (most recent call last) [Py3.2.2 on win23]:

Since computation has stopped, the few extra milliseconds is trivial.
This would certainly help on Python list and the tracker when people
do post the traceback (which they do not always) without version and
system (which they often do not, especially on Python list). It might
suggest to people that this is important info to include.

[...]

But how often is it actually important information to include?

I am active on both the tutor and the python-list lists, and it seems to
me that this proposed feature won't be very useful in either place. In
my experience, the version number is rarely important for the sorts of
questions that are commonly asked.


My experience on Python list is that version and platform are often 
important. But leave that aside. It is definitely important on the 
tracker, which I already mentioned. Just a few days ago, for instance, 
the opening message of

http://bugs.python.org/issue13538
has
" >>> bytes("foo")
  Traceback (most recent call last):
File "", line 1, in 
  TypeError: string argument without an encoding"
with no indication of the version anywhere in the message.

Perhaps in such cases the OP correctly marks the version up in the 
header, but it would be nice to have it right there in the traceback.


As for doctest, it could/should be changed to check for 
s.startswith("Traceback (most recent call last)") (instead of s == ...) 
if it does not do that now.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Adding GNU conditional execution in the Makefile?

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Working in the DTRACE probes, I think I can simplify the build logic
quite a bit using the GNU Makefile conditional execution:
.

In concrete, I have object files that must be compiled and linked, or
not, according to a "configure" test result.

But currently I think we are not using these features. Maybe because
we don't want to force the use of GMAKE, I don't know.

If this is a policy, I would like to know.

And if somebody has a suggestion to cope with this difficulty...

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTuPrqZlgi5GaxT1NAQIRmQP/ebIcya/xg/lCTXPd6QyaBaFxrhL6jLiP
osKeklCSH/aw6tt6v1lK7XgPf8HBEU11KGBmL4xJUsVcDExkNb3Mdu3bSW4Gb5ao
Ep1PxvEWLxa/yVkKuvgdBpvdCoxibhNLfGgVTj08ZE18o9tGbhNKS6EN94uAQJT9
ZASlf8baOss=
=5lr+
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fixing the XML batteries

[Terry Reedy]

On 12/10/2011 4:32 PM, Glyph Lefkowitz wrote:

On Dec 10, 2011, at 2:38 AM, Stefan Behnel wrote:


Note, however, that html5lib is likely way too big to add it to the
stdlib, and that BeautifulSoup lacks a parser for non-conforming HTML
in Python 3, which would be the target release series for better HTML
support. So, whatever library or API you would want to use for HTML
processing is currently only the second question as long as Py3 lacks
a real-world HTML parser in the stdlib, as well as a robust character
detection mechanism. I don't think that can be fixed all that easily.


Here's the problem in a nutshell, I think:

 1. Everybody wants an HTML parser in the stdlib, because it's
inconvenient to pull in a dependency for such a "simple" task.
 2. Everybody wants the stdlib to remain small, stable, and simple and
not get "overcomplicated".
 3. Parsing arbitrary HTML5 is a monstrously complex problem, for which
there exist rapidly-evolving standards and libraries to deal with
it. Parsing 'the web' (which is rapidly growing to include stuff
like SVG, MathML etc) is even harder.


My personal opinion is that HTML5Lib gets this problem almost completely
right, and so it should be absorbed by the stdlib.


A little data: the HTML5lib project lives at
https://code.google.com/p/html5lib/
It has 4 owners and 22 other committers.

The most recent release, html5lib 0.90 for Python, is nearly 2 years 
old. Since there is a separate Python3 repository, and there is no 
mention on Python3 compatibility elsewhere that I saw, including the 
pypi listing, I assume that is for Python2 only.


A comment on a recent (July 11) Python3 issue
https://code.google.com/p/html5lib/issues/detail?id=187&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary%20Port
suggest that the Python3 version still has problems. "Merged in now, 
though still lots of errors and failures in the testsuite."


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding GNU conditional execution in the Makefile?

[Guido van Rossum]

I don't know how widespread gmake is, but I certainly don't want Python to
be dependent on GNU tools exclusively. You don't have to use GCC to compile
it. (Autoconfig is a different story, it only is needed when
config.inchanges. Similar, readline is optional.)

--Guido

On Sat, Dec 10, 2011 at 3:30 PM, Jesus Cea  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Working in the DTRACE probes, I think I can simplify the build logic
> quite a bit using the GNU Makefile conditional execution:
> .
>
> In concrete, I have object files that must be compiled and linked, or
> not, according to a "configure" test result.
>
> But currently I think we are not using these features. Maybe because
> we don't want to force the use of GMAKE, I don't know.
>
> If this is a policy, I would like to know.
>
> And if somebody has a suggestion to cope with this difficulty...
>
> - --
> Jesus Cea Avion _/_/  _/_/_/_/_/_/
> j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
> jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
> .  _/_/  _/_/_/_/  _/_/  _/_/
> "Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
> "My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
> "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQCVAwUBTuPrqZlgi5GaxT1NAQIRmQP/ebIcya/xg/lCTXPd6QyaBaFxrhL6jLiP
> osKeklCSH/aw6tt6v1lK7XgPf8HBEU11KGBmL4xJUsVcDExkNb3Mdu3bSW4Gb5ao
> Ep1PxvEWLxa/yVkKuvgdBpvdCoxibhNLfGgVTj08ZE18o9tGbhNKS6EN94uAQJT9
> ZASlf8baOss=
> =5lr+
> -END PGP SIGNATURE-
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fixing the XML batteries

[Glyph Lefkowitz]

On Dec 10, 2011, at 6:30 PM, Terry Reedy wrote:

> A little data: the HTML5lib project lives at
> https://code.google.com/p/html5lib/
> It has 4 owners and 22 other committers.
> 
> The most recent release, html5lib 0.90 for Python, is nearly 2 years old. 
> Since there is a separate Python3 repository, and there is no mention on 
> Python3 compatibility elsewhere that I saw, including the pypi listing, I 
> assume that is for Python2 only.

I believe that you are correct.

> A comment on a recent (July 11) Python3 issue
> https://code.google.com/p/html5lib/issues/detail?id=187&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary%20Port
> suggest that the Python3 version still has problems. "Merged in now, though 
> still lots of errors and failures in the testsuite."


I don't see what bearing this has on the discussion.  There are three possible 
ways I can imagine to interpret this information.

First, you could believe that porting a codebase from Python 2 to Python 3 is 
much easier than solving a difficult domain-specific problem.  In that case, 
html5lib has done the hard part and someone interested in html-in-the-stdlib 
should do the rest.

Second, you could believe that porting a codebase from Python 2 to Python 3 is 
harder than solving a difficult domain-specific problem, in which case 
something is seriously wrong with Python 3 or its attendant migration tools and 
that needs to be fixed, so someone should fix that rather than worrying about 
parsing HTML right now.  (I doubt that many subscribers to this list would 
share this opinion, though.)

Third, you could believe that parsing HTML is not a difficult domain-specific 
problem.  But only a crazy person would believe that, so you're left with one 
of the previous options :).

-glyph

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fixing the XML batteries

[Terry Reedy]

On 12/10/2011 9:25 PM, Glyph Lefkowitz wrote:

On Dec 10, 2011, at 6:30 PM, Terry Reedy wrote:



A little data: the HTML5lib project lives at
https://code.google.com/p/html5lib/
It has 4 owners and 22 other committers.


If there really are 4 'owners' rather than 4 people with admin access to 
the site, then there are 4 people to negotiate with.



The most recent release, html5lib 0.90 for Python, is nearly 2 years
old. Since there is a separate Python3 repository, and there is no
mention on Python3 compatibility elsewhere that I saw, including the
pypi listing, I assume that is for Python2 only.


I believe that you are correct.


There are issues pointing to a 1.0 release, but I could not find any 
current timetable. The project lots a bit stagnant. That does not bode 
well for a commitment to future active maintenance.



A comment on a recent (July 11) Python3 issue
https://code.google.com/p/html5lib/issues/detail?id=187&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary%20Port

suggest that the Python3 version still has problems. "Merged in now,
though still lots of errors and failures in the testsuite."


I don't see what bearing this has on the discussion.


I think both points above show that 'absorbing HTML5Lib in the stdlib' 
will involve more sociological and technical problems than doing so with 
a active one-person module that already runs on 3.2. One is that the 
multiple version Python 2.x codebase is the reference version and that 
will not be incorporated. A serious plan will have to address the real 
situation.


---
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com