[issue13674] crash in datetime.strftime
New submission from patrick vrijlandt :
This causes a crash in python 3.2.2 and 3.2, but not in 2.7.2
C:\Python32>python
Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> datetime.datetime(1899,12,31).strftime("%y")
The crash happens with %y but not with %Y.
The crash happens with any year < 1900.
On 2.7.2 a ValueError is raised because strftime requires year >= 1900. This is
what IMHO should happen (and would have saved me a lot of time)
--
components: Library (Lib)
messages: 150323
nosy: patrick.vrijlandt
priority: normal
severity: normal
status: open
title: crash in datetime.strftime
type: crash
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue13674>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13674] crash in datetime.strftime
patrick vrijlandt added the comment: Is it relevant that 2.7.2 _does_ throw a correct exception? -- ___ Python tracker <http://bugs.python.org/issue13674> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13674] crash in datetime.strftime
patrick vrijlandt added the comment:
Somewhere in the code is also/still a seperate check concerning strftime:
PythonWin 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on
win32.
Portions Copyright 1994-2008 Mark Hammond - see 'Help/About PythonWin' for
further copyright information.
>>> import datetime
>>> datetime.datetime(-1, 1, 1)
Traceback (most recent call last):
File "", line 1, in
ValueError: year is out of range
>>> datetime.datetime(0, 1, 1)
Traceback (most recent call last):
File "", line 1, in
ValueError: year is out of range
>>> datetime.datetime(1, 1, 1)
datetime.datetime(1, 1, 1, 0, 0)
>>> datetime.datetime(1, 1, 1).strftime("Y")
Traceback (most recent call last):
File "", line 1, in
ValueError: year=1 is before 1000; the datetime strftime() methods require year
>= 1000
>>>
--
___
Python tracker
<http://bugs.python.org/issue13674>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12321] documentation of ElementTree.find
New submission from patrick vrijlandt : >From the python docs for version 3.2: 19.12.3. ElementTree Objects find(match) [...] Same as getroot().find(match). [...] This is not true: tree.find accepts an absolute path (like "/*") , whereas element.find doesn't. Also applies to findall and findtext. -- components: XML messages: 138228 nosy: patrick.vrijlandt priority: normal severity: normal status: open title: documentation of ElementTree.find type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue12321> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12322] ElementPath 1.3 expressions documentation
New submission from patrick vrijlandt : Python 3.2 supports ElementPath version 1.3. The relevant documentation is http://effbot.org/zone/element-xpath.htm. It says: .. (New in 1.3) Selects the parent element. However, a CHANGES document says: The engine also provides limited support for the ".." parent operator; you can use it inside the subtree, but it cannot go above the target element (the element you called "find" on). The normal documentation should document the limitation. -- components: XML messages: 138229 nosy: patrick.vrijlandt priority: normal severity: normal status: open title: ElementPath 1.3 expressions documentation type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue12322> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12323] ElementPath 1.3 expressions
New submission from patrick vrijlandt : >From http://effbot.org/zone/element-xpath.htm: [position] (New in 1.3) Selects all elements that are located at the given position. The position can be either an integer (1 is the first position), the expression “last()” (for the last position), or a position relative to last() (e.g. “last()-1” for the second to last position). This predicate must be preceeded by a tag name. Testing shows, that [0] is accepted, and seems to be [last()]. However [-1] selects no elements. I think these expressions should raise an exception. (Or the feature should be 0-based and behave like python list indices) -- components: XML messages: 138230 nosy: patrick.vrijlandt priority: normal severity: normal status: open title: ElementPath 1.3 expressions type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue12323> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12321] documentation of ElementTree.find
patrick vrijlandt added the comment: [...] Same as getroot().find(match). [...] -> [...] For a relative path, this is equivalent to getroot().find(match). Additionally, this form accepts an absolute path. [...] This is easy, but might not be a very good solution. Random thoughts/Points to consider: It does help the novice in debugging his expressions. A peculiarity of this implementation is documented. As others have stated, the whole elementpath documentation within the python docs is incomplete. Should we document the exception but not the rule? It makes no real sense to do a an absolute search from an element. However, it's not ambiguous. lxml does accept the absolute path search from an element. Actually, I think it's up to Fredrik to decide. 2011/6/18 Terry J. Reedy > > Terry J. Reedy added the comment: > > Are you requesting that the doc be changed or the code? > >From the title, I would infer the doc (which is much easier ;-). > If so, can you suggest an actual revised text? > > -- > nosy: +terry.reedy > stage: -> needs patch > versions: +Python 3.3 > > ___ > Python tracker > <http://bugs.python.org/issue12321> > ___ > -- Added file: http://bugs.python.org/file22406/unnamed ___ Python tracker <http://bugs.python.org/issue12321> ___[...] Same as getroot().find(match). [...] ->[...] For a relative path, this is equivalent to getroot().find(match). Additionally, this form accepts an absolute path. [...] This is easy, but might not be a very good solution. Random thoughts/Points to consider: It does help the novice in debugging his expressions. A peculiarity of this implementation is documented. As others have stated, the whole elementpath documentation within the python docs is incomplete. Should we document the exception but not the rule? It makes no real sense to do a an absolute search from an element. However, it's not ambiguous. lxml does accept the absolute path search from an element. Actually, I think it's up to Fredrik to decide. 2011/6/18 Terry J. Reedy <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> Terry J. Reedy <mailto:tjre...@udel.edu";>tjre...@udel.edu> added the comment: Are you requesting that the doc be changed or the code? >From the title, I would infer the doc (which is much easier ;-). If so, can you suggest an actual revised text? -- nosy: +terry.reedy stage:  -> needs patch versions: +Python 3.3 ___ Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> <http://bugs.python.org/issue12321"; target="_blank">http://bugs.python.org/issue12321> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11987] queue.Queue.put should acquire mutex for unfinished_tasks
New submission from patrick vrijlandt : Line 154 in standard library's queue.py, in the definition of Queue.put() is: self.unfinished_tasks += 1 This line should be protected by acquiring the all_tasks_done lock. Theoretically, the increment could occur somewhere during task_done()! Additional note: Personally, I would like the increment to occur *before* instead of *after* _put(). This is because I would like to be able to implement a _put() that does not put everything. This put should be able to undo the increment. As it is, calling task_done() from put might decrease the counter to zero inadvertently. -- components: Library (Lib) messages: 135063 nosy: patrick.vrijlandt priority: normal severity: normal status: open title: queue.Queue.put should acquire mutex for unfinished_tasks type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue11987> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11987] queue.Queue.put should acquire mutex for unfinished_tasks
patrick vrijlandt added the comment: I agree. Please close the ticket. Thanks, Patrick 2011/5/3 Raymond Hettinger > > Raymond Hettinger added the comment: > > > This line should be protected by acquiring the all_tasks_done lock. > > All of three of the condition variables share the same underlying lock. > The increment occurs only with the lock has been acquired. > > > Theoretically, the increment could occur somewhere during task_done()! > > I don't understand what you mean. The semantics of task_done() method > implies that the count gets decremented. > > > Personally, I would like the increment to occur *before* > > instead of *after* _put(). > > There may be some merit to this but I don't see how it matters much since > both occur within the context of the same lock being held. A user defined > method can still add or subtract any number it wants from the unfinished > task count. The result of +1 -5 is the same as -5 +1. > > I'm reluctant to change the order though because the code is already > published and some user's _put code may be inspecting the unfinished tasks > count. I wouldn't want to break that code without good reason. > > -- > > ___ > Python tracker > <http://bugs.python.org/issue11987> > ___ > -- Added file: http://bugs.python.org/file21877/unnamed ___ Python tracker <http://bugs.python.org/issue11987> ___I agree. Please close the ticket.Thanks,Patrick2011/5/3 Raymond Hettinger <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> Raymond Hettinger <mailto:raymond.hettin...@gmail.com";>raymond.hettin...@gmail.com> added the comment: > This line should be protected by acquiring the all_tasks_done lock. All of three of the condition variables share the same underlying lock. Â The increment occurs only with the lock has been acquired. > Theoretically, the increment could occur somewhere during task_done()! I don't understand what you mean. Â The semantics of task_done() method implies that the count gets decremented. > Personally, I would like the increment to occur *before* > instead of *after* _put(). There may be some merit to this but I don't see how it matters much since both occur within the context of the same lock being held. Â A user defined method can still add or subtract any number it wants from the unfinished task count. Â The result of +1 -5 is the same as -5 +1. I'm reluctant to change the order though because the code is already published and some user's _put code may be inspecting the unfinished tasks count. Â I wouldn't want to break that code without good reason. -- ___ Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> <http://bugs.python.org/issue11987"; target="_blank">http://bugs.python.org/issue11987> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13779] os.walk: bottom-up
New submission from patrick vrijlandt :
PythonWin 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on
win32.
Portions Copyright 1994-2008 Mark Hammond - see 'Help/About PythonWin' for
further copyright information.
>>> import os
>>> os.makedirs("g:/a/b/c")
>>> os.listdir("g:/a")
['b']
>>> for root, dirs, files in os.walk("g:/a", topdown = False):
... print(root, dirs, files, os.listdir(root))
... os.rmdir(root)
...
g:/a\b\c [] [] []
g:/a\b ['c'] [] []
g:/a ['b'] [] []
>>>
>From the documentation of os.walk:
If topdown is False, the triple for a directory is generated after the triples
for all of its subdirectories (directories are generated bottom-up).
As the above example shows, the directories are generated in the correct order,
"generated" referring to yield from generator os.walk. However, the generated
(files? and) dirs do not necessarily reflect the current situation as produced
by os.listdir.
Therefore, this does not clear the entire directory tree as I would expect.
>>> os.makedirs("g:/a/b/c")
>>> for root, dirs, files in os.walk("g:/a", topdown = False):
... print(root, dirs, files, os.listdir(root))
... if not (files + dirs):
... os.rmdir(root)
...
g:/a\b\c [] [] []
g:/a\b ['c'] [] []
g:/a ['b'] [] ['b']
I think that at least the documentation should be more clear on this issue. I
would like even better, if files + dirs would match os.listdir on the moment
they are generated (=yielded).
--
assignee: docs@python
components: Documentation
messages: 151169
nosy: docs@python, patrick.vrijlandt
priority: normal
severity: normal
status: open
title: os.walk: bottom-up
type: behavior
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue13779>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13784] Documentation of xml.sax.xmlreader: Locator.getLineNumber() and Locator.getColumnNumber()
New submission from patrick vrijlandt :
Problem:
Locator methods return the location where the event starts, not where it ends.
Locator line numbers start at 1, Locator column numbers can be 0.
Proposal:
Adapt documentation.
>From the docs:
Instances of Locator provide these methods:
Locator.getColumnNumber()
Return the column number where the current event ends.
Locator.getLineNumber()
Return the line number where the current event ends
My Test:
import xml.sax
data = b"""
"""
class MyHandler(xml.sax.handler.ContentHandler):
def startElement(self, name, attrs):
if name == "sub":
print("open", name, self._locator.getLineNumber(),
self._locator.getColumnNumber())
def endElement(self, name):
if name == "sub":
print("close", name, self._locator.getLineNumber(),
self._locator.getColumnNumber())
xml.sax.parseString(data, MyHandler())
Output:
open sub 2 4
close sub 7 4
--
assignee: docs@python
components: Documentation, XML
messages: 151247
nosy: docs@python, patrick.vrijlandt
priority: normal
severity: normal
status: open
title: Documentation of xml.sax.xmlreader: Locator.getLineNumber() and
Locator.getColumnNumber()
type: behavior
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue13784>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13796] use 'text=...' to define the text attribute of and xml.etree.ElementTree.Element
patrick vrijlandt added the comment: I agree the Element syntax is sometimes awkward. But how would you represent text or tail attributes within this enhanced element? comes to mind ... -- nosy: +patrick.vrijlandt ___ Python tracker <http://bugs.python.org/issue13796> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13779] os.walk: bottom-up
patrick vrijlandt added the comment: The documentation of this function is generally ambiguous, because os.walk is a generator. Thus "generate" means (1) yielded from a generator and (2) prepared for later use within the generator. To avoid the ambiguity, "generate" should be avoided if possible. (1) might be replaced by "return" and (2) by "prepare". @zbysz The paragraph you cite is about "Modifying dirnames ". If you are not "Modifying dirnames" (like me) this section easily skips your attention. My problem was, of course, that I had myself changed the directory structure - It's not a race condition with another process but an effect of the loop os.walk was managing. @pitrou shutil.rmtree cannot help me, because I'm only deleting empty dirs. Proposal (very verbose I'm afraid): If you change the directory structure below dirpath while topdown=True, you can modify dirnames in-place so that walk will visit the right directories. If you change the directory structure below dirpath while topdown=False (maybe while you where there), dirnames and filenames can still reflect the old situation and it might be necessary to call os.listdir again. -- ___ Python tracker <http://bugs.python.org/issue13779> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13796] use 'text=...' to define the text attribute of and xml.etree.ElementTree.Element
patrick vrijlandt added the comment:
Hi,
Did you look at lxml (http://lxml.de)?
from lxml.builder import E
from lxml import etree
tree = etree.ElementTree(
E.Hello(
"Good morning!",
E.World("How do you do", humour = "excellent"),
"Fine",
E.Goodbye(),
),
)
print(etree.tostring(tree, pretty_print=True).decode())
# output, even more prettified
Good morning!
How do you do
Fine
By the way, your Element enhancement is buggy, because all newly create
elements will share the same attrib dictionary (if attrib is not given).
Notice that Donald Duck will be sad; by the time we print even Hello is sad.
import xml.etree.ElementTree as etree
class Element(etree.Element):
def __init__(self, tag, attrib={}, **extra):
super().__init__(tag)
self.tag = tag
self.attrib = attrib
self.attrib.update(extra)
self.text = self.attrib.pop('text', None)
self.tail = self.attrib.pop('tail', None)
self._children = []
if __name__ == '__main__':
test = Element('Hello',)
test2 = Element('World',{'humour':'excelent'},text = 'How do you do',
tail="Fine")
test3 = Element('Goodbye', humour='sad')
test4 = Element('Donaldduck')
test.append(test2)
test.append(test3)
test.append(test4)
tree = etree.ElementTree(test)
print(etree.tostring(test, encoding="utf-8", method="xml"))
How do you doFine
'
The correct idiom would be:
def __init__(self, tag, attrib=None, **extra):
if attrib is None:
attrib = {}
super().__init__(tag)
Cheers,
Patrick
2012/1/16 Pedro Andres Aranda Gutierrez
>
> Pedro Andres Aranda Gutierrez added the comment:
>
> Touché :-)
> I was just frustrated because my XMLs never have tail or text as
> attributes and I wanted to have more compact code...
>
> On Mon, Jan 16, 2012 at 12:14 PM, patrick vrijlandt
> wrote:
> >
> > patrick vrijlandt added the comment:
> >
> > I agree the Element syntax is sometimes awkward.
> >
> > But how would you represent text or tail attributes within this enhanced
> element?
> > comes to mind ...
> >
> > --
> > nosy: +patrick.vrijlandt
> >
> > ___
> > Python tracker
> > <http://bugs.python.org/issue13796>
> > ___
>
> --
>
> ___
> Python tracker
> <http://bugs.python.org/issue13796>
> ___
>
--
___
Python tracker
<http://bugs.python.org/issue13796>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13823] xml.etree.ElementTree.ElementTree.write - argument checking
New submission from patrick vrijlandt : (1) The docs say: xml_declaration controls if an XML declaration should be added to the file. Use False for never, True for always, None for only if not US-ASCII or UTF-8 or Unicode (default is None). The method also accepts other values, like xml_declaration = "yes". This behavior should be documented, or raise a ValueError (up to effbot, I think) (2) The docs say (in a note): The encoding string included in XML output should conform to the appropriate standards. For example, “UTF-8” is valid, but “UTF8” is not. See http://www.w3.org/ But the method accepts both values, (“UTF-8” and “UTF8”). Since this will result in invalid xml, (but not invalid python) it should probably raise ValueError too. (3) Open issue 9458 also refers to this method. It might be wise to raise ValueError if the encoding does not match the (mode of the) file target (binary or text). -- assignee: docs@python components: Documentation, XML messages: 151612 nosy: docs@python, patrick.vrijlandt priority: normal severity: normal status: open title: xml.etree.ElementTree.ElementTree.write - argument checking versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue13823> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13779] os.walk: bottom-up
patrick vrijlandt added the comment: Good solution. +1 for closing. Patrick -- ___ Python tracker <http://bugs.python.org/issue13779> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15564] cgi.FieldStorage should not call read_multi on files
New submission from patrick vrijlandt: .mht is an archive format created by Microsoft IE 8 when saving a webpage. It is essentially a mime multipart message. My problem occurred when I uploaded such a file to a cgi-based server. The posted data would be fed to cgi.FieldStorage. (I can't post the file unfortunately) As it turns out, cgi.FieldStorage tries to recursively parse the postdata, thereby splitting up the uploaded file; this fails. However, this (automatic) recursive behaviour seems unwanted for an uploaded file. My proposal is thus to adapt cgi.py (line number for Python 3.2), so that in FieldStorage.__init__, line 542, read_multi would not be invoked in this case. Currently it says: elif ctype[:10] == 'multipart/': self.read_multi(environ, keep_blank_values, strict_parsing) Change this to: elif ctype[:10] == 'multipart/' and not self.filename: self.read_multi(environ, keep_blank_values, strict_parsing) (I apologise for not submitting a test case. When trying to create it, it is either very complicated, or not easily recognizable as valid. Moreover, my server used a 3rd party software (bottlypy.org: bottle.py)) -- components: Library (Lib) messages: 167548 nosy: patrick.vrijlandt priority: normal severity: normal status: open title: cgi.FieldStorage should not call read_multi on files type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue15564> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15588] quopri: encodestring and decodestring handle bytes, not strings
New submission from patrick vrijlandt: quopri.py's functions encodestring and decodestring are documented to handle strings; and this is clearly suggested by their name. However, these functions accept and return bytes, not strings. This should be reflected in the documentation. Even better: deprecate these functions and introduce new ones with behaviour as suggested by their names: encode_string, encode_bytes etc. -- assignee: docs@python components: Documentation, Library (Lib) messages: 167672 nosy: docs@python, patrick.vrijlandt priority: normal severity: normal status: open title: quopri: encodestring and decodestring handle bytes, not strings type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue15588> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15564] cgi.FieldStorage should not call read_multi on files
patrick vrijlandt added the comment: I would not know how to set the MIME-type of a file during upload. This is apparently set by the browser based on the filename (extension). Even (or: especially) if this is a bug in all the current browsers, python should provide the tools to adapt to this situation. I could perhaps request the whole form to be "application/octet-stream", but the current "multipart/form-data" is appropriate for a form. You are right about renaming. The innocent test file "test2.txt" can be uploaded, but the same file renamed to "test2.mht" causes an exception. Below is a dump of the posted data (using Chrome in this case); attached a script (requiring bottle.py - www.bottlepy.org or PyPI) that demonstrates the problem. There is no doubt that parsing fails; an exception cannot be the result of successful parsing. The input may be wrong, but python should offer the flexibility to handle wrong input. Instead, are you sure it is appropriate to *automatically* dissect a file? It should be fairly easy to handle for the scripter if he really wants to dig deeper. Headers Origin: http://localhost:10080 Referer: http://localhost:10080/url-get Content-Length: 349 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cache-Control: max-age=0 Connection: keep-alive Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.75 Safari/537.1 Host: localhost:10080 Accept-Encoding: gzip,deflate,sdch Accept-Language: nl-NL,nl;q=0.8,en-US;q=0.6,en;q=0.4,en-GB;q=0.2 Content-Type: multipart/form-data; boundary=WebKitFormBoundaryBsBVBYDTxou89uBj Body --WebKitFormBoundaryBsBVBYDTxou89uBj Content-Disposition: form-data; name="data"; filename="test2.mht" Content-Type: multipart/related # dit is een test Dit is een regel Dit is het einde. # --WebKitFormBoundaryBsBVBYDTxou89uBj Content-Disposition: form-data; name="value" abc123 --WebKitFormBoundaryBsBVBYDTxou89uBj-- -- Added file: http://bugs.python.org/file26764/cgibug.py ___ Python tracker <http://bugs.python.org/issue15564> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15564] cgi.FieldStorage should not call read_multi on files
patrick vrijlandt added the comment: I must admit my usage case is a hack, but the summary is: view a page on one computer, process it on another computer; like sending the page to a friend, with friend -> self and send -> upload. I found one other victim in python (https://groups.google.com/d/topic/web2py/ixeUUWryZh0/discussion) but only an occasional reference to other languages; most posts relate to security issues with mht files. My previous example only served to show that the mime-type is a necessary condition for the problem to occur; you are right that this input would be expected to throw an exception. So I went on and created a complete testcase/example (attached). The PatchedFieldStorage class parses the mht file correctly into parts. However, the names of the parts are in "content-location" headers inside the mht file and get lost. Also the code is ugly. Trying to better re-use existing code like in ExperimentalFieldStorage was not succesful so far: The MIME-prologue is parsed as one of the parts, and the outerboundary is not respected, losing a dataelement "next to" the file. The print() calls show that the next line may be valuable (like a header) or not so much (like a boundary), but so far the class has no provision for look-ahead I think. email.message_from_binary_file correctly parses my mht-files; so a completely different approach might be to more rely on that package for parsing MIME encoded data. -- Added file: http://bugs.python.org/file26780/test_cgi4.py ___ Python tracker <http://bugs.python.org/issue15564> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12322] ElementPath 1.3 expressions documentation
patrick vrijlandt added the comment: To be complete: an xpath 'above' the start element returns None Thanks for the patch! -- ___ Python tracker <http://bugs.python.org/issue12322> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12323] ElementPath 1.3 expressions
patrick vrijlandt added the comment:
Dear Eli,
According to the XPath spec, the 'position' as can be used in xpath
expressions, should be positive. However, the current implementation (example
below from 3.3.0) accepts some values that should not be ok.
Therefore, I do not agree that it behaves correctly. Garbage positions should
return [] or an exception, not a value. And if you accept one value before the
first position, you should accept them all.
DATA = '''
2
2008
141100
5
2011
59900
69
2011
13600
'''
import xml.etree.ElementTree as ET
root = ET.XML(DATA)
print(root)
for XP in (['./country'] +
['./country[%d]' % i for i in range(-1, 5)] +
['./country[last()%+d]' % i for i in range(-3, 5)]):
print('{:20}'.format(XP), [elem.get('name') for elem in root.findall(XP)])
## OUTPUT:
##
##./country['Liechtenstein', 'Singapore', 'Panama']
##./country[-1][]
##./country[0] ['Panama']
##./country[1] ['Liechtenstein']
##./country[2] ['Singapore']
##./country[3] ['Panama']
##./country[4] []
##./country[last()-3] []
##./country[last()-2] ['Liechtenstein']
##./country[last()-1] ['Singapore']
##./country[last()+0] ['Panama']
##./country[last()+1] ['Liechtenstein']
##./country[last()+2] ['Singapore']
##./country[last()+3] ['Panama']
##./country[last()+4] []
--
___
Python tracker
<http://bugs.python.org/issue12323>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
