[issue20288] HTMLParse handing of non-numeric charrefs broken
New submission from Anders Hammarquist:
Python 2.7 HTMLParse.py lines 185-199 (similar lines still exist in Python 3.4)
match = charref.match(rawdata, i)
if match:
...
else:
if ; in rawdata[i:]: #bail by consuming #
self.handle_data(rawdata[0:2])
i = self.updatepos(i, 2)
break
if you feed a broken charref, that is non-numeric, it will pass whatever random
string that happened to be at the start of rawdata to handle_data(). Eg:
p = HTMLParser()
p.handle_data = lambda x: sys.stdout.write(x)
p.feed('p#foo;/p')
will print 'p' which is clearly wrong. I think the intention of the code is to
pass '#', which seems saner.
--
components: Library (Lib)
messages: 208336
nosy: iko
priority: normal
severity: normal
status: open
title: HTMLParse handing of non-numeric charrefs broken
type: behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20288
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15292] import hook behavior documentation improvement
New submission from Anders Hammarquist i...@iko.pp.se: When testing Eutaxia on PyPy (1.9) I discovered a discrepancy in the path_hooks import hook implementation. In CPython (2.7), if the find_module() method raises ImportError (as imp.find_module() does when it does not find a module in the given path), will cause the search to continue, whereas PyPy would propagate the ImportError. PyPy has now been changed to behave like CPython. The documentation is not entirely clear, but it does not explicitly document the import hook mechanism as eating an ImportError in find_module(). It should probably be made explicit, which ever way it should be. It is not obvious what is the correct behaviour, given the implicit relative imports, where the ImportError simply means that the import hook cannot find the module. Quick testing on CPython 3.3 indicates that it behaves like PyPy did, but as it doesn't do implicit relative imports my test case didn't work as it was. For 3.3, without implicit relative imports, propagating the ImportError feels like the correct behaviour. The attached demonstration needs a file /tmp/test/foo.py that does a top-level import, e.g. import errno to demonstrate the discrepancy. -- assignee: docs@python components: Documentation files: testimport.py messages: 164998 nosy: docs@python, iko priority: normal severity: normal status: open title: import hook behavior documentation improvement type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file26315/testimport.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15292 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Real-world use cases for map's None fill-in feature?
In article [EMAIL PROTECTED], Raymond Hettinger [EMAIL PROTECTED] wrote: Request for more information My request for readers of comp.lang.python is to search your own code to see if map's None fill-in feature was ever used in real-world code (not toy examples). I had a quick look through our (Strakt's) codebase and found one example. The code is used to process user-designed macros, where the user wants to append data to strings stored in the system. Note that all data is stored as lists of whatever the relevant data type is. While I didn't write this bit of code (so I can't say what, if any, alternatives were considered), it does seem to me the most straight- forward way to do it. Being able to say what the fill-in value should be would make the code even simpler. oldAttrVal is the original stored data, and attValue is what the macro wants to append. ---8--- newAttrVal = [] for x, y in map(None, oldAttrVal, attrValue): newAttrVal.append(u''.join((x or '', y or ''))) ---8--- /Anders -- -- Of course I'm crazy, but that doesn't mean I'm wrong. Anders Hammarquist | [EMAIL PROTECTED] Physics student, Chalmers University of Technology, | Hem: +46 31 88 48 50 G|teborg, Sweden. RADIO: SM6XMM and N2JGL | Mob: +46 707 27 86 87 -- http://mail.python.org/mailman/listinfo/python-list
Re: Is 'everything' a refrence or isn't it?
In article [EMAIL PROTECTED], Fredrik Lundh [EMAIL PROTECTED] wrote: and the Python use is consistent with the rest of computer science. The problem isn't the word reference in itself, the problem is when people are implying that since Python passes object references to functions, it's using call by reference. Actually, I think the problem is not in the call bit. Python behaves more or less like all other call by reference languages in the call. What is confusing people is what happens when you *assign* to a function argument. Those confused are expecting Python function arguments to behave just like C++ references (which are just syntactic sugar for a dereferenced pointer) or an Ada in out parameter when assigned. Python doesn't, because in Python assignment assigns a new reference to the name, rather than changing the referenced object. /Anders -- -- Of course I'm crazy, but that doesn't mean I'm wrong. Anders Hammarquist | [EMAIL PROTECTED] Physics student, Chalmers University of Technology, | Hem: +46 31 88 48 50 G|teborg, Sweden. RADIO: SM6XMM and N2JGL | Mob: +46 707 27 86 87 -- http://mail.python.org/mailman/listinfo/python-list
