[issue12323] ElementPath 1.3 expressions

[patrick vrijlandt]

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 = '''?xml version=1.0?
data
country name=Liechtenstein
rank updated=yes2/rank
year2008/year
gdppc141100/gdppc
neighbor name=Austria direction=E/
neighbor name=Switzerland direction=W/
/country
country name=Singapore
rank updated=yes5/rank
year2011/year
gdppc59900/gdppc
neighbor name=Malaysia direction=N/
/country
country name=Panama
rank updated=yes69/rank
year2011/year
gdppc13600/gdppc
neighbor name=Costa Rica direction=W/
neighbor name=Colombia direction=E/
/country
/data
'''

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:
##Element 'data' at 0x03CD9BD0
##./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 rep...@bugs.python.org
http://bugs.python.org/issue12323
___
___
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]

patrick vrijlandt added the comment:

To be complete: an xpath 'above' the start element returns None

Thanks for the patch!

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12322
___
___
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]

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 rep...@bugs.python.org
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]

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 rep...@bugs.python.org
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

[patrick vrijlandt]

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 rep...@bugs.python.org
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]

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 rep...@bugs.python.org
http://bugs.python.org/issue15564
___
___
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]

patrick vrijlandt patrick.vrijla...@gmail.com added the comment:

Good solution. +1 for closing.

Patrick

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13779
___
___
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

[patrick vrijlandt]

New submission from patrick vrijlandt patrick.vrijla...@gmail.com:

(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 rep...@bugs.python.org
http://bugs.python.org/issue13823
___
___
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]

patrick vrijlandt patrick.vrijla...@gmail.com 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

Hello
Good morning!
World humour=excellent
  How do you do
/World
  Fine
Goodbye/
/Hello

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))

Hello humour=sad
World humour=excelentHow do you do/WorldFine
Goodbye humour=sad /
Donaldduck humour=sad /
/Hello'

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 rep...@bugs.python.org


 Pedro Andres Aranda Gutierrez paag...@gmail.com 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
 rep...@bugs.python.org wrote:
 
  patrick vrijlandt patrick.vrijla...@gmail.com added the comment:
 
  I agree the Element syntax is sometimes awkward.
 
  But how would you represent text or tail attributes within this enhanced
 element?
  animal name=cat tail=yes comes to mind ...
 
  --
  nosy: +patrick.vrijlandt
 
  ___
  Python tracker rep...@bugs.python.org
  http://bugs.python.org/issue13796
  ___

 --

 ___
 Python tracker rep...@bugs.python.org
 http://bugs.python.org/issue13796
 ___


--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13796
___
___
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]

patrick vrijlandt patrick.vrijla...@gmail.com added the comment:

I agree the Element syntax is sometimes awkward.

But how would you represent text or tail attributes within this enhanced 
element?
animal name=cat tail=yes comes to mind ...

--
nosy: +patrick.vrijlandt

___
Python tracker rep...@bugs.python.org
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]

patrick vrijlandt patrick.vrijla...@gmail.com 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 rep...@bugs.python.org
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()

[patrick vrijlandt]

New submission from patrick vrijlandt patrick.vrijla...@gmail.com:

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 = bmain
sub
attr=1
id=name

subsub /
/sub
/main


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 rep...@bugs.python.org
http://bugs.python.org/issue13784
___
___
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]

New submission from patrick vrijlandt patrick.vrijla...@gmail.com:

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 rep...@bugs.python.org
http://bugs.python.org/issue13779
___
___
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]

patrick vrijlandt patrick.vrijla...@gmail.com 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 interactive input, line 1, in module
ValueError: year is out of range
 datetime.datetime(0, 1, 1)
Traceback (most recent call last):
  File interactive input, line 1, in module
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 interactive input, line 1, in module
ValueError: year=1 is before 1000; the datetime strftime() methods require year 
= 1000


--

___
Python tracker rep...@bugs.python.org
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]

New submission from patrick vrijlandt patrick.vrijla...@gmail.com:

This causes a crash in python 3.2.2 and 3.2, but not in 2.7.2

C:\Python32python
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 rep...@bugs.python.org
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]

patrick vrijlandt patrick.vrijla...@gmail.com added the comment:

Is it relevant that 2.7.2 _does_ throw a correct exception?

--

___
Python tracker rep...@bugs.python.org
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

[patrick vrijlandt]

patrick vrijlandt patrick.vrijla...@gmail.com 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 rep...@bugs.python.org


 Terry J. Reedy 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 rep...@bugs.python.org
 http://bugs.python.org/issue12321
 ___


--
Added file: http://bugs.python.org/file22406/unnamed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12321
___span class=Apple-style-span style=border-collapse: collapse; font-family: 
arial, sans-serif; font-size: 13px; [...] Same as getroot().find(match). 
[...] -gt;/spandivfont class=Apple-style-span face=arial, 
sans-serifspan class=Apple-style-span style=border-collapse: 
collapse;[...] For a relative path, this is equivalent 
to /span/fontspan class=Apple-style-span style=border-collapse: 
collapse; font-family: arial, sans-serif; font-size: 13px; 
getroot().find(match). Additionally, this form accepts an absolute path. 
[...]/span/div
divspan class=Apple-style-span style=border-collapse: collapse; 
font-family: arial, sans-serif; font-size: 13px; br/span/divdivspan 
class=Apple-style-span style=border-collapse: collapse; font-family: arial, 
sans-serif; font-size: 13px; This is easy, but might not be a very good 
solution. /span/div
divspan class=Apple-style-span style=border-collapse: collapse; 
font-family: arial, sans-serif; font-size: 13px; br/span/divdivspan 
class=Apple-style-span style=border-collapse: collapse; font-family: arial, 
sans-serif; font-size: 13px; Random thoughts//spanspan 
class=Apple-style-span style=border-collapse: collapse; font-family: arial, 
sans-serif; font-size: 13px; Points to consider:/span/div
divspan class=Apple-style-span style=border-collapse: collapse; 
font-family: arial, sans-serif; font-size: 13px; It does help the novice in 
debugging his expressions. /span/divdivspan class=Apple-style-span 
style=border-collapse: collapse; font-family: arial, sans-serif; font-size: 
13px; A peculiarity of this implementation is documented./span/div
divspan class=Apple-style-span style=border-collapse: collapse; 
font-family: arial, sans-serif; font-size: 13px; As others have stated, the 
whole elementpath documentation within the python docs is incomplete. Should we 
document the exception but not the rule?/span/div
divspan class=Apple-style-span style=border-collapse: collapse; 
font-family: arial, sans-serif; font-size: 13px; It makes no real sense to do 
a an absolute search from an element. However, it#39;s not 
ambiguous./span/div
divspan class=Apple-style-span style=border-collapse: collapse; 
font-family: arial, sans-serif; font-size: 13px; lxml does accept the 
absolute path search from an element./span/divdivfont 
class=Apple-style-span face=arial, sans-serifspan 
class=Apple-style-span style=border-collapse: collapse;br
/span/font/divdivdivspan class=Apple-style-span 
style=border-collapse: collapse; font-family: arial, sans-serif; font-size: 
13px; Actually, I think it#39;s up to Fredrik to 
decide. /span/div/divdiv
span class=Apple-style-span style=border-collapse: collapse; font-family: 
arial, sans-serif; font-size: 13px; br/span/divdivfont 
class=Apple-style-span face=arial, sans-serifspan 
class=Apple-style-span style=border-collapse: collapse;br
/span/fontbrdiv class=gmail_quote2011/6/18 Terry J. Reedy span 
dir=ltrlt;a 
href=mailto:rep...@bugs.python.org;rep...@bugs.python.org/agt;/spanbrblockquote
 class=gmail_quote style=margin:0 0 0 .8ex;border-left:1px #ccc 
solid;padding-left:1ex;
br
Terry J. Reedy lt;a href=mailto:tjre...@udel.edu;tjre...@udel.edu/agt; 
added the comment:br
br
Are you requesting that the doc be changed or the code?br
gt;From the title, I would infer the doc (which is much easier ;-).br
If so, can you suggest an actual revised text?br
br
--br
nosy: +terry.reedybr
stage:  -gt; needs patchbr
versions: +Python 3.3br
divdiv/divdiv class=h5br

[issue12321] documentation of ElementTree.find

[patrick vrijlandt]

New submission from patrick vrijlandt patrick.vrijla...@gmail.com:

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 rep...@bugs.python.org
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

[patrick vrijlandt]

New submission from patrick vrijlandt patrick.vrijla...@gmail.com:

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 rep...@bugs.python.org
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]

New submission from patrick vrijlandt patrick.vrijla...@gmail.com:

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 rep...@bugs.python.org
http://bugs.python.org/issue12323
___
___
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]

patrick vrijlandt patrick.vrijla...@gmail.com added the comment:

I agree. Please close the ticket.

Thanks,

Patrick

2011/5/3 Raymond Hettinger rep...@bugs.python.org


 Raymond Hettinger 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 rep...@bugs.python.org
 http://bugs.python.org/issue11987
 ___


--
Added file: http://bugs.python.org/file21877/unnamed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11987
___I agree. Please close the 
ticket.divbr/divdivThanks,/divdivbr/divdivPatrickbrbrdiv 
class=gmail_quote2011/5/3 Raymond Hettinger span dir=ltrlt;a 
href=mailto:rep...@bugs.python.org;rep...@bugs.python.org/agt;/spanbr
blockquote class=gmail_quote style=margin:0 0 0 .8ex;border-left:1px #ccc 
solid;padding-left:1ex;br
Raymond Hettinger lt;a 
href=mailto:raymond.hettin...@gmail.com;raymond.hettin...@gmail.com/agt; 
added the comment:br
div class=imbr
gt; This line should be protected by acquiring the all_tasks_done lock.br
br
/divAll of three of the condition variables share the same underlying lock. 
 The increment occurs only with the lock has been acquired.br
div class=imbr
gt; Theoretically, the increment could occur somewhere during task_done()!br
br
/divI don#39;t understand what you mean.  The semantics of task_done() 
method implies that the count gets decremented.br
div class=imbr
gt; Personally, I would like the increment to occur *before*br
gt; instead of *after* _put().br
br
/divThere may be some merit to this but I don#39;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.br

br
I#39;m reluctant to change the order though because the code is already 
published and some user#39;s _put code may be inspecting the unfinished tasks 
count.  I wouldn#39;t want to break that code without good reason.br

br
--br
divdiv/divdiv class=h5br
___br
Python tracker lt;a 
href=mailto:rep...@bugs.python.org;rep...@bugs.python.org/agt;br
lt;a href=http://bugs.python.org/issue11987; 
target=_blankhttp://bugs.python.org/issue11987/agt;br
___br
/div/div/blockquote/divbr/div
___
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]

New submission from patrick vrijlandt patrick.vrijla...@gmail.com:

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 rep...@bugs.python.org
http://bugs.python.org/issue11987
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com