lxml.etree, namespaces and element insertion
The other day i was processing an xml tree using lxml.etree. That tree
contained a namespace. During that processing i inserted an element.
Later on
i tried to find that element using xpath. And to my suprise that
element was
not found! Maybe my suprise is just the result of my marginal
knowledge about
xml namespaces.
After some examination i found out that the reason for not finding the
element
was that i did not supply a namespace when inserting the element.
This behavior can be reproduced be the folowing code:
from lxml import etree
import sys
print "Python:", sys.version_info
print "lxml.etree:", etree.__version__
string_data = [
'',
'',
''
]
trees = map(etree.fromstring, string_data)
print "\n Before insertion:"
for t in trees:
print etree.tostring(t, pretty_print=True)
trees[1].insert(-1, etree.Element("sometag"))
trees[2].insert(-1, etree.Element("{NameSpace.com}sometag",
nsmap={None : "NameSpace.com"}))
print "\n After insertion:"
for t in trees:
print etree.tostring(t, pretty_print=True)
print "\n Using xpath:"
for t in trees:
elements = t.xpath("//ns:sometag", namespaces={'ns':
'NameSpace.com'})
print len(elements),
if elements:
print [e.tag for e in elements]
else:
print elements
Its output is:
Python: (2, 6, 6, 'final', 0)
lxml.etree: 2.2.8
Before insertion:
After insertion:
Using xpath:
1 ['{NameSpace.com}sometag']
0 []
1 ['{NameSpace.com}sometag']
So my suprise was that in the second case the xpath result is an empty
list.
I have two questions on this:
- Is what i am seeing expected behavior?
- How am i supposed to detect a missing namespace, if there are no
differences
in the serialized representation? (That's what i initially used to
debug the
problem.)
--
http://mail.python.org/mailman/listinfo/python-list
Help installing Python 2.3 on Win2K
I have installed python 2.3 on my Windows 2K laptop and I can run python from the command prompt. I have tried various ways to set PYTHONPATH with the various directories where I have python programs (i.e. xx.py) but no matter how I set PYTHONPATH I keep getting a message that python can't open the python file. If I try to specify the full pathname by typing: python c:\Documents and Settings\-rest of path- I get an error message that python can't open c:\Documents. The ways I have set PYTHONPATH are by directly changing the registry entry for Python 2.3, by setting the environment variable by right-clicking on My Computer and by adding set PYTHONPATH=-various pathnames-. I'd be grateful for any guidance on how to organize my system. -- http://mail.python.org/mailman/listinfo/python-list
Help understanding code
Hi. I am trying to understand a section of code written for Plone and I
am having problems understanding the Python syntax in a few of the
following lines.
I'd be grateful if someone could help me understand what's happening in
the lines I've marked. I can't see how the dictionary is built or how
the lists ['bytype'][cytype] make sense in python.
Thanks in advance.
class Stats:
def getContentTypes(self):
""" Returns the number of documents by type """
pc = getToolByName(self, "portal_catalog")
# call the catalog and loop through the records
results = pc()
<=== what is the difference between pc and pc()?
numbers = {"total":len(results),"bytype":{},"bystate":{}} <===
This is hard to understand
for result in results:
# set the number for the type
ctype = str(result.Type)
num = numbers["bytype"].get(ctype, 0) < where does .get
come from? and what is the string 'bytype' doing?
num += 1
numbers["bytype"][ctype] = num<== is this some kind
of an array?
# set the number for the state
state = str(result.review_state)
num = numbers["bystate"].get(state, 0)
num += 1
numbers["bystate"][state] = num
return numbers
--
http://mail.python.org/mailman/listinfo/python-list
Is it possible to deliver different source distributions for different Python versions?
I would like to distribute a python package with different code for Python 2.* than for Python 3.*. (Mostly this is because of different unicode string handling). There is nothing in to setuptools or PyPi that directly supports this scenario. But perhaps there could be some script run at install time that moves the correct source code to the right location? In other works, if I included both source code versions in the distribution (in a src2 and a src3 subdirectory) then a function invoked at install time could detect the python version and copy the appropriate source code to the right location. Is that at all possible? Is there some install time hook that lets me supply custom installation code? -- Dave Hein -- https://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to deliver different source distributions for different Python versions?
On Sunday, April 5, 2015 at 10:28:55 PM UTC-5, Mark Lawrence wrote: > On 05/04/2015 21:38, Dave Hein wrote: > > I would like to distribute a python package with different code for > > Python 2.* than for Python 3.*. (Mostly this is because of different > > unicode string handling). > > > > There is nothing in to setuptools or PyPi that directly supports > > this scenario. > > > > But perhaps there could be some script run at install time that moves > > the correct source code to the right location? In other works, if I > > included both source code versions in the distribution (in a src2 and > > a src3 subdirectory) then a function invoked at install time could > > detect the python version and copy the appropriate source code to the > > right location. > > > > Is that at all possible? Is there some install time hook that lets me > > supply custom installation code? > > > > -- > > Dave Hein > > > > I can't help directly but have you looked here > https://packaging.python.org/en/latest/ ? Yep. I looked there first and from that thought that I could distribute "wheels" -- a 2.7 wheel, a 3.3 wheel, and a 3.4 wheel. But the latest setup.py (version 15.0) doesn't build wheels anymore. It does build binary distributions, but they are tied more to a particular version of a particular OS rather than to a particular version of Python. So, anyway, I think parts of that documentation site are out of date. And I didn't see anything that let me do what I wanted. > > -- > My fellow Pythonistas, ask not what our language can do for you, ask > what you can do for our language. > > Mark Lawrence -- Dave Hein -- https://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to deliver different source distributions for different Python versions?
On Monday, April 6, 2015 at 12:47:05 AM UTC-5, Stefan Behnel wrote: > Dave Hein schrieb am 05.04.2015 um 22:38: > > I would like to distribute a python package with different code for > > Python 2.* than for Python 3.*. (Mostly this is because of different > > unicode string handling). > > > > There is nothing in to setuptools or PyPi that directly supports > > this scenario. > > > > But perhaps there could be some script run at install time that moves > > the correct source code to the right location? In other works, if I > > included both source code versions in the distribution (in a src2 and > > a src3 subdirectory) then a function invoked at install time could > > detect the python version and copy the appropriate source code to the > > right location. > > > > Is that at all possible? Is there some install time hook that lets me > > supply custom installation code? > > Sure. You can simply change the directory in which distutils looks for your > Python code: > > https://docs.python.org/2/distutils/setupscript.html#listing-whole-packages > > However, in general, you shouldn't be doing this. It's usually easier > (definitely in the long-term) to keep your sources cross-Py2.x/3.x > compatible, maybe with the help of tools like "six" or "python-future", > than to try to keep separate source trees in sync. > > http://python-future.org/ > > Stefan I understand. What got me going down the two-source-trees path is that the unittest support isn't cross compatible ... the way I'm using mocks doesn't translate between 2.7 and 3.3. I also like having really clean 3.x code and just keeping the warts confined to the 2.x branch. I use the futures stuff in the 2.x branch to keep it as close as possible to the 3.x branch, but there are still enough differences that I have to mung the 3.x changes just a little when I merge them back into the 2.x branch. -- Dave Hein -- https://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to deliver different source distributions for different Python versions?
On Sunday, April 5, 2015 at 8:01:22 PM UTC-5, Steven D'Aprano wrote: > On Mon, 6 Apr 2015 06:38 am, Dave Hein wrote: > > > I would like to distribute a python package with different code for > > Python 2.* than for Python 3.*. (Mostly this is because of different > > unicode string handling). > > > > There is nothing in to setuptools or PyPi that directly supports > > this scenario. > > > > But perhaps there could be some script run at install time that moves > > the correct source code to the right location? In other works, if I > > included both source code versions in the distribution (in a src2 and > > a src3 subdirectory) then a function invoked at install time could > > detect the python version and copy the appropriate source code to the > > right location. > > > > Is that at all possible? Is there some install time hook that lets me > > supply custom installation code? > > I'm not aware of any standard solution to that, but I'm not a setuptools > expert. setup.py files are Python code, so you can put any code you like in > them. But, as far as I am concerned, having the installer pick and choose > what source files to include is not a good solution. Instead, you should > pick one of these two alternatives: > > > (1) Supply a separate package for 2.x and 3.x, each with their own > installer. The installer confirms that it is running under the correct > version of Python, and just installs. > Yep. That's what I'm doing now. Two distinct packages on PyPi. > > (2) Or supply a single package with a single installer that works under both > 2.x and 3.x. (This is my preference.) > > One way of handling the second case is to only support 3.3 or better: that > way, you can still use u"..." for Unicode strings. Hardly anyone used 3.1 > or 3.2, and 3.0 is no longer supported, so it is quite reasonable to insist > people upgrade to 3.3. > There is other code that doesn't translate cleanly between 2.x and 3.x. Specifically the unittest tests and unittest.mock usage. That's mainly why I don't have one source tree. > Another way to handle the second case is to use conditional imports: Hmm. Maybe I can figure out how to isolate the 2.x weirdness into a separate package and conditionally import the 3.x version vs. 2.x version. I'll look into that. Thanks. > [snip] > > -- > Steven -- Dave Hein -- https://mail.python.org/mailman/listinfo/python-list
Re: pypi submission?
On Monday, April 6, 2015 at 5:19:29 PM UTC-5, Benjamin Schollnick wrote: > Folks, > > > I'm having issues with submitting to pypi. > > > I can register and upload my package. > > > > nerv:~ Benjamin$ pip search directory_caching > Directory_Caching - A Caching library for Directories & Files > nerv:~ Benjamin$ > > > but, if you try to install it using pip: > > > > pip install directory_caching > Reading Profile from ~/dropbox/shellscripts/profile > nerv:~ Benjamin$ pip install directory_caching > Collecting directory-caching > Could not find any downloads that satisfy the requirement directory-caching > No distributions at all found for directory-caching > > Try adding the "--pre" option. If your version number is an 'alpha' or 'pre' or 'rc' version (like 1.0a1 or 1.0rc4), then pip won't install it by default ... it will only install 'released' versions (like 1.0 or 1.0.1). Adding the --pre option tells pip you actually do want the pre-release version. So: pip install --pre directory-caching > [snip] > > - Benjamin -- Dave Hein -- https://mail.python.org/mailman/listinfo/python-list
