Re: comment out more than 1 line at once?
Marc Boeren wrote: Well, you could fake it by doing """ block of code here is commented out """ """ Yes, this is generally how it is done in python. """ Byron --- -- http://mail.python.org/mailman/listinfo/python-list
lxml: traverse xml tree and retrieve element based on an attribute
I am using the lxml.etree library to validate an xml instance file
with a specified schema that contains the data types of each element.
This is some of the internals of a function that extracts the
elements:
schema_doc = etree.parse(schema_fn)
schema = etree.XMLSchema(schema_doc)
context = etree.iterparse(xml_fn, events=('start', 'end'),
schema=schema)
# get root
event, root = context.next()
for event, elem in context:
if event == 'end' and elem.tag == self.tag:
yield elem
root.clear()
I retrieve a list of elements from this... and do further processing
to represent them in different ways. I need to be able to capture the
data type from the schema definition for each field in the element.
i.e.
My thought is to recursively traverse through the schema definition
match the `name` attribute since they are unique to a `type` and
return that element. But I can't seem to make it quite work. All the
xml is valid, validation works, etc. This is what I have:
def find_node(tree, name):
for c in tree:
if c.attrib.get('name') == name:
return c
if len(c) > 0:
return find_node(c, name)
return 0
I may have been staring at this too long, but when something is
returned... it should be returned completely, no? This is what occurs
with `return find_node(c, name) if it returns 0. `return c` works
(used pdb to verify that), but the recursion continues and ends up
returning 0.
Thoughts and/or a different approach are welcome. Thanks
--
http://mail.python.org/mailman/listinfo/python-list
Re: lxml: traverse xml tree and retrieve element based on an attribute
On May 21, 6:57 pm, MRAB wrote:
> byron wrote:
> > I am using the lxml.etree library to validate an xml instance file
> > with a specified schema that contains the data types of each element.
> > This is some of the internals of a function that extracts the
> > elements:
>
> > schema_doc = etree.parse(schema_fn)
> > schema = etree.XMLSchema(schema_doc)
>
> > context = etree.iterparse(xml_fn, events=('start', 'end'),
> > schema=schema)
>
> > # get root
> > event, root = context.next()
>
> > for event, elem in context:
> > if event == 'end' and elem.tag == self.tag:
> > yield elem
> > root.clear()
>
> > I retrieve a list of elements from this... and do further processing
> > to represent them in different ways. I need to be able to capture the
> > data type from the schema definition for each field in the element.
> > i.e.
>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
> > My thought is to recursively traverse through the schema definition
> > match the `name` attribute since they are unique to a `type` and
> > return that element. But I can't seem to make it quite work. All the
> > xml is valid, validation works, etc. This is what I have:
>
> > def find_node(tree, name):
> > for c in tree:
> > if c.attrib.get('name') == name:
> > return c
> > if len(c) > 0:
> > return find_node(c, name)
> > return 0
>
> You're searching the first child and then returning the result, but what
> you're looking for might not be in the first child; if it's not then you
> need to search the next child:
>
> def find_node(tree, name):
> for c in tree:
> if c.attrib.get('name') == name:
> return c
> if len(c) > 0:
> r = find_node(c, name)
> if r:
> return r
> return None
>
> > I may have been staring at this too long, but when something is
> > returned... it should be returned completely, no? This is what occurs
> > with `return find_node(c, name) if it returns 0. `return c` works
> > (used pdb to verify that), but the recursion continues and ends up
> > returning 0.
>
> > Thoughts and/or a different approach are welcome. Thanks
>
>
Thanks. Yes i tried something like this, but I think I overwrite `c`
when i wrote it, as in:
if len(c) > 0:
c = fin_node(c, name)
if c is not None:
return c
Thanks for you help.
--
http://mail.python.org/mailman/listinfo/python-list
Re: lxml: traverse xml tree and retrieve element based on an attribute
On May 21, 8:27 pm, MRAB wrote: > byron wrote: > > [snip] > > > Thanks. Yes i tried something like this, but I think I overwrite `c` > > when i wrote it, as in: > > > if len(c) > 0: > > c = fin_node(c, name) > > if c is not None: > > return c > > FYI, doing that won't actually matter in this case; 'c' will still be > bound to the next value on the next iteration of the loop because it's > just a reference to the iterator and 'assigning' won't affect the > iterator as in soem other languages. Good to know. Thanks. -- http://mail.python.org/mailman/listinfo/python-list
book example confusion
I am reading o'reilly's learning python (great book), but i came across an example (pg 291, pdf) that I am not quite understanding the reasoning for the author's explanation: if f1() or f2(): The author states that do to the nature of that expression, if f1() returns True, f2() will not be evaluated.. which makes sense. His quote: "Here, if f1 returns a true (or nonempty) value, Python will never run f2." He then states: "To guarantee that both functions will be run, call them before the 'or':" tmp1, tmp2 = f1(), f2() if tmp1 or tmp2: Being that each function is an object, a name assignment to (tmp1,tmp2) doesn't actually evaluate or run the function itself until the name is called.. so why would the latter example "run" both functions as the author suggests? -- http://mail.python.org/mailman/listinfo/python-list
Re: book example confusion
On Sep 12, 3:51 pm, John Machin <[EMAIL PROTECTED]> wrote: > On Sep 13, 5:36 am, byron <[EMAIL PROTECTED]> wrote: > > > > > I am reading o'reilly's learning python (great book), but i came > > across an example (pg 291, pdf) that I am not quite understanding the > > reasoning for the author's explanation: > > > if f1() or f2(): > > > The author states that do to the nature of that expression, if f1() > > returns True, f2() will not be evaluated.. which makes sense. His > > quote: > > > "Here, if f1 returns a true (or nonempty) value, Python will > > never run f2." > > > He then states: > > > "To guarantee that both functions will be run, call them > > before the 'or':" > > > tmp1, tmp2 = f1(), f2() > > if tmp1 or tmp2: > > > Being that each function is an object, a name assignment to > > (tmp1,tmp2) doesn't actually evaluate or run the function itself until > > the name is called.. so why would the latter example "run" both > > functions as the author suggests? > > It's not a "name assignment". > In effect it's doing this: > tmp1 = f1() # get the RESULT of calling f1() > tmp2 = f2() # likewise f2 > if tmp1 or tmp2: # if result1 or result2 > A (pointless) "name assignment") with the nil effect that you fear > would look like this: > tmp1, tmp2 = f1, f2 # Look, no parentheses after function names > if tmp1() or tmp2(): > > HTH, > John That makes sense. Thank you for the clarification. -- http://mail.python.org/mailman/listinfo/python-list
Maven like tool?
Hi, I'm new to Python and looking to run a large project that would need automated builds and project reports such as unit test coverage. Maven is a great Java software to do this - but is there something I should use for Python? I did some searching on SF and this list but can't figure out what tools are used by teams to manage large Python projects (other than the obvious CVS). One idea is to create Maven plugins and reports that would work for Python. The plugin would offer build/test/pydoc. One report could be based on PyLint. Sounds like fun but I don't want to re-invent the wheel if something is already out there then I'd rather be a user for this one than the developer. Thanks in advance. Byron Saltysiak -- http://mail.python.org/mailman/listinfo/python-list
collections.Iterator __subclasshook__ does not check if next() is callable
I submitted this as bug last night: http://bugs.python.org/issue17584 and was *honored* to be rejected by Raymond Hettinger. However, I would like feedback on whether my concern (this bug) is justified and clarity if not. Consider: ```python class A(object): def __init__(self): self.r = iter(range(5)) def __iter__(self): return self @property def next(self): return next(self.r) ``` The `next` method is a property, however: ```python from collections import Iterator a = A() isinstance(a, Iterator) # True next(a) # TypeError: 'int' object is not callable ``` I am using `collections.Iterator` as the means to check if the object is an iterator, however I am not sure if that is _root_ problem here. My understanding of the iterator protocol is that is assumes the __iter__ and next *methods* are implemented. In the example, `A.next` is defined as a property, but is still identified as an iterator. To me, this is incorrect behavior since it's not conforming to the iterator protocol requirements (i.e. a `next` method, not a property). Raymond stated: "The design of ABCs are to check for the existence to required named; none of them verify the signature." I think I understand _why_ this is the case.. but I downstream libraries use `collections.Iterator` to determine if an object _is one_: see https://github.com/django/django/blob/master/django/utils/itercompat.py#L22-L31 Who's job is it to check if `next` (and technically `__iter__`) are methods? -- http://mail.python.org/mailman/listinfo/python-list
Re: collections.Iterator __subclasshook__ does not check if next() is callable
Raymond's replied to my follow-up and made me realize that the `next` property could return a callable and it would be transparent to the caller. On Sunday, March 31, 2013 1:57:08 PM UTC-4, Byron Ruth wrote: > I submitted this as bug last night: http://bugs.python.org/issue17584 and was > *honored* to be rejected by Raymond Hettinger. However, I would like feedback > on whether my concern (this bug) is justified and clarity if not. > > > > Consider: > > > > ```python > > class A(object): > > def __init__(self): > > self.r = iter(range(5)) > > def __iter__(self): > > return self > > @property > > def next(self): > > return next(self.r) > > ``` > > > > The `next` method is a property, however: > > > > ```python > > from collections import Iterator > > a = A() > > isinstance(a, Iterator) # True > > next(a) # TypeError: 'int' object is not callable > > ``` > > > > I am using `collections.Iterator` as the means to check if the object is an > iterator, however I am not sure if that is _root_ problem here. My > understanding of the iterator protocol is that is assumes the __iter__ and > next *methods* are implemented. In the example, `A.next` is defined as a > property, but is still identified as an iterator. To me, this is incorrect > behavior since it's not conforming to the iterator protocol requirements > (i.e. a `next` method, not a property). > > > > Raymond stated: "The design of ABCs are to check for the existence to > required named; none of them verify the signature." I think I understand > _why_ this is the case.. but I downstream libraries use > `collections.Iterator` to determine if an object _is one_: see > https://github.com/django/django/blob/master/django/utils/itercompat.py#L22-L31 > > > > Who's job is it to check if `next` (and technically `__iter__`) are methods? -- http://mail.python.org/mailman/listinfo/python-list
Re: collections.Iterator __subclasshook__ does not check if next() is callable
Thanks for responding Terry. I can assure you I did not initially realize both the `next` and the `__iter__` methods were implemented when I ran into my original problem. I saw a behavior and had to work backwards to realize why it was behaving the way it was (the comparison against Iterator). Once I realized this, the behavior made complete sense. It just dawned on me the fact that `next` was not being checked to be callable (I was surprised by this at the time) which is why I investigated the `Iterator.__subclasshook__` and assumed it was behaving incorrectly based on my assumptions. On Sunday, March 31, 2013 3:47:07 PM UTC-4, Terry Jan Reedy wrote: > On 3/31/2013 1:57 PM, Byron Ruth wrote: > > > I submitted this as bug last night: http://bugs.python.org/issue17584 and > > was *honored* to be rejected by Raymond Hettinger. However, I would like > > feedback on whether my concern (this bug) is justified and clarity if not. > > > > > > Consider: > > > > > > ```python > > > class A(object): > > > def __init__(self): > > > self.r = iter(range(5)) > > > def __iter__(self): > > > return self > > > @property > > > def next(self): > > > return next(self.r) > > > ``` > > > > > > The `next` method is a property, however: > > > > A competent Python programmer should not do that. In Py3, the method is > > properly renamed '__next__', which should make doing that accidentally > > even less likely. > > > > > > > > ```python > > > from collections import Iterator > > > a = A() > > > isinstance(a, Iterator) # True > > > next(a) # TypeError: 'int' object is not callable > > > ``` > > > > > > I am using `collections.Iterator` as the means to check if the object is an > > iterator, > > > > Being an Iterator only means that it *might* be an iterator. > > > > > however I am not sure if that is _root_ problem here. My > > understanding of the iterator protocol is that is assumes the __iter__ > > and next *methods* are implemented. In the example, `A.next` is defined > > as a property, but is still identified as an iterator. To me, this is > > incorrect behavior since it's not conforming to the iterator protocol > > requirements (i.e. a `next` method, not a property). > > > > There is more to any protocol than can be statically checked. > > > > > Raymond stated: "The design of ABCs are to check for the existence to > > required named; none of them verify the signature." > > > > Having the required attributes is currently the definition of being an > > instance of an ABC. Adding 'not a property' would be possible. but > > hardly worthwhile. Checking signatures would be worthwhile, but > > signatures are not yet available to Python for C-coded methods, let > > alone other implementations. > > > > I think I understand _why_ this is the case.. but I downstream > > libraries use `collections.Iterator` to determine if an object _is one_: > > see > > https://github.com/django/django/blob/master/django/utils/itercompat.py#L22-L31 > > > > > > Who's job is it to check if `next` (and technically `__iter__`) are methods? > > > > The programmer, and a user who does not trust the competence of the > > programmer. But this is the least of the possible errors. > > > > -- > > Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Python doc problem example: gzip module (reprise)
>>> fileToCompress = open('finalcallejon.mb')
>>> fileToStr = fileToCompress.read()
>>> import gzip
>>> fileZipped = gzip.GzipFile('finalcallejon.mb.gz', 'wb', 9)
>>> fileZipped.write(fileToStr)
>>> fileZipped.close()
this may help you in
http://mail.python.org/pipermail/python-list/2005-November/349718.html
have a nice day <>--
http://mail.python.org/mailman/listinfo/python-list
