twitter: comp.lang.python - 25 new messages in 15 topics

comp.lang.python
http://groups.google.com/group/comp.lang.python?hl=en

comp.lang.python@googlegroups.com

Today's topics:

==============================================================================
TOPIC: A "scopeguard" for Python
http://groups.google.com/group/comp.lang.python/t/8c752e871801c223?hl=en
==============================================================================

== 1 of 3 ==
Date: Thurs, Mar 4 2010 7:42 pm
From: Robert Kern

On 2010-03-04 16:27 , Alf P. Steinbach wrote:
> * Mike Kent:

>> However, I fail to understand his response that I must have meant try/
>> else instead, as this, as Mr. Kern pointed out, is invalid syntax.
>> Perhaps Mr. Steinbach would like to give an example?
>
> OK.
>
> Assuming that you wanted the chdir to be within a try block (which it
> was in your code), then to get code equivalent to my code, for the
> purpose of a comparision of codes that do the same, you'd have to write
> something like ...
>
> original_dir = os.getcwd()
> try:
> os.chdir(somewhere)
> except Whatever:
> # E.g. log it.
> raise
> else:
> try:
> # Do other stuff
> finally:
> os.chdir(original_dir)
> # Do other cleanup
>
> ... which would be a more general case.
>
> I've also given this example in response to Robert earlier in the
> thread. Although I haven't tried it I believe it's syntactically valid.
> If not, then the relevant typo should just be fixed. :-)
>
> I have no idea which construct Robert thought was syntactically invalid.
> I think that if he's written that, then it must have been something he
> thought of.

I was just trying to interpret what you meant by "Changing 'finally' to 'else'
could make it equivalent." As far as I can tell, that has only one possible
interpretation going by the plain meaning of the words, and it isn't yours.
Since you always seem to refer to "try/else" as if it were an independent
construct and not part of "try: except: else:" and no one else introduced
except: clause, I must reiterate that your communications have been fabulously
misleading.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

== 2 of 3 ==
Date: Thurs, Mar 4 2010 7:35 pm
From: Robert Kern

On 2010-03-04 15:12 , Mike Kent wrote:
> On Mar 4, 12:30 pm, Robert Kern<robert.k...@gmail.com> wrote:
>
>> He's ignorant of the use cases of the with: statement, true.
>
> <humor> Ouch! Ignorant of the use cases of the with statement, am I?
> Odd, I use it all the time.</humor>

No, I was referring to Jean-Michel, who was not familiar with the with: statement.

>> Given only your
>> example of the with: statement, it is hard to fault him for thinking that try:
>> finally: wouldn't suffice.
>
> <humor> Damn me with faint praise, will you?</humor>

Also talking about Jean-Michel. :-)

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

== 3 of 3 ==
Date: Thurs, Mar 4 2010 8:01 pm
From: Robert Kern

On 2010-03-04 17:52 , Alf P. Steinbach wrote:
> * Robert Kern:
>> On 2010-03-04 12:37 PM, Alf P. Steinbach wrote:
>>> * Robert Kern:
>>>> On 2010-03-04 10:56 AM, Alf P. Steinbach wrote:
>>>>> * Robert Kern:
>>>>>> On 2010-03-03 18:49 PM, Alf P. Steinbach wrote:
>>> [snippety]
>>>>>>
>>>>>>> If you call the possibly failing operation "A", then that systematic
>>>>>>> approach goes like this: if A fails, then it has cleaned up its own
>>>>>>> mess, but if A succeeds, then it's the responsibility of the calling
>>>>>>> code to clean up if the higher level (multiple statements) operation
>>>>>>> that A is embedded in, fails.
>>>>>>>
>>>>>>> And that's what Marginean's original C++ ScopeGuard was designed
>>>>>>> for,
>>>>>>> and what the corresponding Python Cleanup class is designed for.
>>>>>>
>>>>>> And try: finally:, for that matter.
>>>>>
>>>>> Not to mention "with".
>>>>>
>>>>> Some other poster made the same error recently in this thread; it is a
>>>>> common fallacy in discussions about programming, to assume that since
>>>>> the same can be expressed using lower level constructs, those are all
>>>>> that are required.
>>>>>
>>>>> If adopted as true it ultimately means the removal of all control
>>>>> structures above the level of "if" and "goto" (except Python doesn't
>>>>> have "goto").
>>>>
>>>> What I'm trying to explain is that the with: statement has a use even
>>>> if Cleanup doesn't. Arguing that Cleanup doesn't improve on try:
>>>> finally: does not mean that the with: statement doesn't improve on
>>>> try: finally:.
>>>
>>> That's a different argument, essentially that you see no advantage for
>>> your current coding patterns.
>>>
>>> It's unconnected to the argument I responded to.
>>>
>>> The argument that I responded to, that the possibility of expressing
>>> things at the level of try:finally: means that a higher level construct
>>> is superfluous, is still meaningless.
>>
>> I am attacking your premise that the "with Cleanup():" construct is
>> higher level than try: finally:. It isn't. It provides the same level
>> of abstraction as try: finally:.
>>
>> This is distinct from the accepted uses of the with: statement which
>> *are* higher level than try: finally: and which do confer practical
>> benefits over using try: finally: despite being syntactical sugar for
>> try: finally:.
>>
>>>>>>>> Both formulations can be correct (and both work perfectly fine with
>>>>>>>> the chdir() example being used). Sometimes one is better than the
>>>>>>>> other, and sometimes not. You can achieve both ways with either
>>>>>>>> your
>>>>>>>> Cleanup class or with try: finally:.
>>>>>>>>
>>>>>>>> I am still of the opinion that Cleanup is not an improvement over
>>>>>>>> try:
>>>>>>>> finally: and has the significant ugliness of forcing cleanup code
>>>>>>>> into
>>>>>>>> callables. This significantly limits what you can do in your
>>>>>>>> cleanup
>>>>>>>> code.
>>>>>>>
>>>>>>> Uhm, not really. :-) As I see it.
>>>>>>
>>>>>> Well, not being able to affect the namespace is a significant
>>>>>> limitation. Sometimes you need to delete objects from the
>>>>>> namespace in
>>>>>> order to ensure that their refcounts go to zero and their cleanup
>>>>>> code
>>>>>> gets executed.
>>>>>
>>>>> Just a nit (I agree that a lambda can't do this, but as to what's
>>>>> required): assigning None is sufficient for that[1].
>>>>
>>>> Yes, but no callable is going to allow you to assign None to names in
>>>> that namespace, either. Not without sys._getframe() hackery, in any
>>>> case.
>>>>
>>>>> However, note that the current language doesn't guarantee such
>>>>> cleanup,
>>>>> at least as far as I know.
>>>>>
>>>>> So while it's good practice to support it, to do everything to let it
>>>>> happen, it's presumably bad practice to rely on it happening.
>>>>>
>>>>>
>>>>>> Tracebacks will keep the namespace alive and all objects in it.
>>>>>
>>>>> Thanks!, I hadn't thought of connecting that to general cleanup
>>>>> actions.
>>>>>
>>>>> It limits the use of general "with" in the same way.
>>>>
>>>> Not really.
>>>
>>> Sorry, it limits general 'with' in /exactly/ the same way.
>>>
>>>> It's easy to write context managers that do that [delete objects from
>>>> the namespace].
>>>
>>> Sorry, no can do, as far as I know; your following example quoted below
>>> is an example of /something else/.
>>
>> Okay, so what do you mean by 'the use of general "with"'? I'm talking
>> about writing a context manager or using the @contextmanager decorator
>> to do some initialization and then later cleaning up that
>> initialization. That cleaning up may entail deleting an object. You
>> are correct that the context manager can't affect the namespace of the
>> with: clause, but that's not the initialization that it would need to
>> clean up.
>>
>> Yes, you can write code with a with: statement where you try to clean
>> up stuff that happened inside of the clause (you did), but that's not
>> how the with: statement was ever intended to be used nor is it good
>> practice to do so because of that limitation. Context managers are
>> designed to initialize specific things, then clean them up. I thought
>> you were talking about the uses of the with: statement as described in
>> PEP-343, not every possible misuse of the with: statement.
>
> I'm not the one talking about removing variables or that "it's easy to
> write context managers that do that".
>
> You are the one talking about that.
>
> So I have really not much to add.
>
> It seems that you're now agreeing with me that former is not good
> practice and that the latter is impossible to do portably, but you now
> argue against your earlier stand as if that was something that I had put
> forward.

No, I'm still saying that sometimes you do need to remove variables that you
initialized in the initialization section. Writing a purpose-built context
manager which encapsulates the initialization and finalization allows you to do
this easily. Putting the initialization section inside the with: clause, as you
do, and requiring cleanup code to be put into callables makes this hard.

> It's a bit confusing when you argue against your own statements.
>
>>> And adding on top of irrelevancy, for the pure technical aspect it can
>>> be accomplished in the same way using Cleanup (I provide an example
>>> below).
>>>
>>> However, doing that would generally be worse than pointless since with
>>> good coding practices the objects would become unreferenced anyway.
>>>
>>>
>>>> You put the initialization code in the __enter__() method, assign
>>>> whatever objects you want to keep around through the with: clause as
>>>> attributes on the manager, then delete those attributes in the
>>>> __exit__().
>>>
>>> Analogously, if one were to do this thing, then it could be accomplished
>>> using a Cleanup context manager as follows:
>>>
>>> foo = lambda: None
>>> foo.x = create_some_object()
>>> at_cleanup.call( lambda o = foo: delattr( o, "x" ) )
>>>
>>> ... except that
>>>
>>> 1) for a once-only case this is less code :-)
>>
>> Not compared to a try: finally:, it isn't.
>
> Again, this context shifting is bewildering. As you can see, quoted
> above, you were talking about a situation where you would have defined a
> context manager, presumably because a 'try' would not in your opinion be
> simpler for whatever it was that you had in mind. But you are responding
> to the code I offered as if it was an alternative to something where you
> would find a 'try' to be simplest.

I have consistently put forward that for once-only cases, try: finally: is a
preferable construct to "with Cleanup():". I also put forward that for
repetitive cases, a purpose-built context manager is preferable. I note that for
both try: finally: and a purpose-built context manager, modifying the namespace
is easy to do while it is difficult and less readable to do with "with
Cleanup():". Since you were claiming that the "generic with:" would have the
same problem as "with Cleanup():" I was trying to explain for why all of the
intended use cases of the with: statement (the purpose-built context managers),
there is no problem. Capisce?

>>> 2) it is a usage that I wouldn't recommend; instead I recommend adopting
>>> good
>>> coding practices where object references aren't kept around.
>>
>> Many of the use cases of the with: statement involve creating an
>> object (like a lock or a transaction object), keeping it around for
>> the duration of the "# Do stuff" block, and then finalizing it.
>>
>>>> Or, you use the @contextmanager decorator to turn a generator into a
>>>> context manager, and you just assign to local variables and del them
>>>> in the finally: clause.
>>>
>>> Uhm, you don't need a 'finally' clause when you define a context
>>> manager.
>>
>> When you use the @contextmanager decorator, you almost always do. See
>> the Examples section of PEP 343:
>>
>> http://www.python.org/dev/peps/pep-0343/
>>
>>> Additionally, you don't need to 'del' the local variables in
>>> @contextmanager decorated generator.
>>>
>>> The local variables cease to exist automatically.
>>
>> True.
>>
>>>> What you can't do is write a generic context manager where the
>>>> initialization happens inside the with: clause and the cleanup actions
>>>> are registered callables. That does not allow you to affect the
>>>> namespace.
>>>
>>> If you mean that you can't introduce direct local variables and have
>>> them deleted by "registered callables" in a portable way, then right.
>>>
>>> But I can't think of any example where that would be relevant; in
>>> particular what matters for supporting on-destruction cleanup is whether
>>> you keep any references or not, not whether you have a local variable of
>>> any given name.
>>
>> Well, local variables keep references to objects. Variable assignment
>> followed by deletion is a very readable way to keep an object around
>> for a while then remove it later. If you have to go through less
>> readable contortions to keep the object around when it needs to be and
>> clean it up later, then that is a mark against your approach.
>
> Sorry, as with the places noted above, I can't understand what you're
> trying to say here. I don't recommend coding practices where you keep
> object references around,

Then how do you clean up locks and transaction objects and similar things if you
don't keep them around during the code suite? Creating an object, keeping it
around while executing a specific chunk of code, and finalizing it safely is a
prime use case for these kinds of constructs.

> and you have twice quoted that above. I don't
> have any clue what "contortions" you are talking about, it must be
> something that you imagine.

These are the contortions:

foo = lambda: None
foo.x = create_some_object()
at_cleanup.call( lambda o = foo: delattr( o, "x" ) )

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

==============================================================================
TOPIC: ImportError: No module named glib
http://groups.google.com/group/comp.lang.python/t/59965420484523de?hl=en
==============================================================================

== 1 of 3 ==
Date: Fri, Mar 5 2010 12:30 am
From: Michael Joachimiak

I am too new to python.
If anybody has an idea what to do please help.
when I use

import glib

in my code I get this:

>>> import glib
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named glib

:~$ python -V
Python 2.6.4

/usr/lib/libpyglib-2.0-python2.6.so.0.0.0 exists in version 2.18.0-0ubuntu2

:~$ pkg-config glib-2.0 --cflags --libs
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -lglib-2.0

== 2 of 3 ==
Date: Fri, Mar 5 2010 2:54 am
From: mblume

Am Fri, 05 Mar 2010 10:30:49 +0200 schrieb Michael Joachimiak:

> I am too new to python.
> If anybody has an idea what to do please help. when I use
>
> import glib
>
> in my code I get this:
>
>>>> import glib
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> ImportError: No module named glib
>

Shot in the dark: maybe "import pyglib"?
Hint: you can look around in /usr/lib/python to see what files can be imported.

HTH
Martin

== 3 of 3 ==
Date: Fri, Mar 5 2010 3:46 am
From: Peter Otten <__peter__@web.de>

Michael Joachimiak wrote:

> I am too new to python.
> If anybody has an idea what to do please help.
> when I use
>
> import glib
>
> in my code I get this:
>
>>>> import glib
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> ImportError: No module named glib
>
> :~$ python -V
> Python 2.6.4
>
> /usr/lib/libpyglib-2.0-python2.6.so.0.0.0 exists in version
> 2.18.0-0ubuntu2
>
> :~$ pkg-config glib-2.0 --cflags --libs
> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -lglib-2.0

After the following random walk through my system

$ python
Python 2.6.4 (r264:75706, Dec 7 2009, 18:43:55)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import glib
>>> glib.__file__
'/usr/lib/pymodules/python2.6/gtk-2.0/glib/__init__.pyc'

In the above __init__.py:
...
from glib._glib import *
_PyGLib_API = _glib._PyGLib_API

del _glib
...

>>> import sys
>>> sys.modules["glib._glib"]
<module 'glib._glib' from
'/usr/lib/pymodules/python2.6/gtk-2.0/glib/_glib.so'>
>>>
$ dpkg -S _glib.so
python-gobject: /usr/lib/pyshared/python2.5/gtk-2.0/glib/_glib.so
python-gobject: /usr/lib/pyshared/python2.6/gtk-2.0/glib/_glib.so
$

... I believe that you have to install the python-gobject package.

Peter

==============================================================================
TOPIC: indentation error
http://groups.google.com/group/comp.lang.python/t/c0fcd040bcecfca0?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Mar 5 2010 12:32 am
From: Ulrich Eckhardt

asit wrote:
> pattern = raw_input("Enter the file pattern to search for :\n")
> commandString = "find " + pattern
> commandOutput = commands.getoutput(commandString)
> findResults = string.split(commandOutput, "\n")
> print "Files : "
> print commandOutput
> print "============================="
> for file in findResults:
> mode = stat.S_IMODE(os.lstat(file)[stat.ST_MODE])
> print "\nPermissions for file", file, ":"
> for level in "USR", "GRP", "OTH":
> for perm in "R", "W", "X":
> if mode & getattr(stat,"S_I"+perm+level):
> print level, " has ", perm, " permission"
> else:
> print level, " does NOT have ", perm, "
> permission"
[...]
> According to me, indentation is ok. but the python interpreter gives
> an indentation error
>
> [asit ~/py] $ python search.py
> File "search.py", line 7
> findResults = string.split(commandOutput, "\n")
> ^
> IndentationError: unindent does not match any outer indentation level

Hard to tell, since your posting was already line-broken which already
changes the correctness. In any case, watch for tabs/spaces, many editors
have an option to display whitespace.

Uli

--
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

== 2 of 2 ==
Date: Fri, Mar 5 2010 3:48 am
From: Steven D'Aprano

On Fri, 05 Mar 2010 00:04:13 -0800, asit wrote:

> Consider the following code
[snip]
> According to me, indentation is ok. but the python interpreter gives an
> indentation error

You can trust the interpreter. There *is* an indentation error. Most
likely you have mixed spaces and tabs. Try:

python -t -t search.py

instead. (Yes, -t twice.)

On an unrelated note, your code snippet shows a very poor coding style.
Firstly, bare "except" clauses are VERY bad practice: it will mask bugs
in your code. Secondly, you should wrap the smallest amount of code in
the try block as you need.

Something like this is probably better:

pattern = raw_input("Enter the file pattern to search for :\n")
commandString = "find " + pattern
commandOutput = commands.getoutput(commandString)
findResults = string.split(commandOutput, "\n")
print "Files : "
print commandOutput
print "============================="
for file in findResults:
try:
mode = stat.S_IMODE(os.lstat(file)[stat.ST_MODE])
except (IOError, OSError):
# Print a useless error message so your users will hate you.
print "There was a problem with %s" % file
continue
print "\nPermissions for file", file, ":"
for level in "USR", "GRP", "OTH":
for perm in "R", "W", "X":
if mode & getattr(stat,"S_I"+perm+level):
print level, " has ", perm, " permission"
else:
print level, " does NOT have ", perm, "permission"

--
Steven

==============================================================================
TOPIC: 10th Python Game Programming Challenge in three weeks
http://groups.google.com/group/comp.lang.python/t/2fba6f7c0adab3dc?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 5 2010 12:39 am
From: Richard Jones

The 10th Python Game Programming Challenge (http://pyweek.org/) will
run from the 28th of March to the 4th of April.

The PyWeek challenge:

- Invites entrants to write a game in one week from scratch either as
an individual or in a team,
- Is intended to be challenging and fun,
- Will hopefully increase the public body of game tools, code and expertise,
- Will let a lot of people actually finish a game, and
- May inspire new projects (with ready made teams!)

Come along and play, it's lots of fun :)

Richard

==============================================================================
TOPIC: loop over list and process into groups
http://groups.google.com/group/comp.lang.python/t/18776b6cab6d4cba?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Mar 4 2010 9:30 pm
From: Dennis Lee Bieber

On Thu, 4 Mar 2010 07:57:18 -0800 (PST), Sneaky Wombat
<joe.hrbek@gmail.com> declaimed the following in
gmane.comp.python.general:

> [ {'vlan_or_intf': 'VLAN2021'},
> {'vlan_or_intf': 'Interface'},
> {'vlan_or_intf': 'Po1'},
> {'vlan_or_intf': 'Po306'},
> {'vlan_or_intf': 'VLAN2022'},
> {'vlan_or_intf': 'Interface'},
> {'vlan_or_intf': 'Gi7/33'},
> {'vlan_or_intf': 'Po1'},
> {'vlan_or_intf': 'Po306'},
> {'vlan_or_intf': 'VLAN2051'},
> {'vlan_or_intf': 'Interface'},
> {'vlan_or_intf': 'Gi9/6'},
> {'vlan_or_intf': 'VLAN2052'},
> {'vlan_or_intf': 'Interface'},
> {'vlan_or_intf': 'Gi9/6'},]
>
That is an interesting data set...

It is a list of ONE ELEMENT dictionaries...
> I want it to be converted to:
>
> [{'2021':['Po1','Po306']},{'2022':['Gi7/33','Po1','Po306']},etc etc]

And so is your specified output... How do you intend to use this
data structure? Compared to a dictionary with multiple entries:

{ "2021" : ["P01", "Po306"],
"2022" : ["Gi7/33", "Po1", "Po306"],
.... }

which can be used via keys: converted["2022"] would retrieve the list of
whatever's...
> I also have the data in a list,
>
> [ 'VLAN4065',
> 'Interface',
> 'Gi9/6',
> 'Po2',
> 'Po3',
> 'Po306',
> 'VLAN4068',
> 'Interface',
> 'Gi9/6',
> 'VLAN4069',
> 'Interface',
> 'Gi9/6',]

Offhand, the "Interface" entries are superfluous. You appear to be
looking for items starting with VLAN, stripping off the VLAN and using
the remaining numbers as the "name", and then collecting all entries up
to the next "VLAN...", ignoring the "Interface" item.

-=-=-=-=-=-=-=-=-=-=-=-=-
INDATA = [ "VLAN4065",
"Interface",
"Gi9/6",
"Po2",
"Po3",
"Po306",
"VLAN4068",
"Interface",
"Gi9/6",
"VLAN4069",
"Interface",
"Gi9/6" ]

outDict = {}

key = None
for item in INDATA:
if item.startswith("VLAN"):
if key:
outDict[key] = items
key = item[4:]
items = []
elif item == "Interface":
pass
else:
if key: #if no key, can't use data
items.append(item)
if key: #handle last set
outDict[key] = items

from pprint import pprint
pprint(outDict)
-=-=-=-=-=-=-=-=-=-=-=-=-
{'4065': ['Gi9/6', 'Po2', 'Po3', 'Po306'],
'4068': ['Gi9/6'],
'4069': ['Gi9/6']}
-=-=-=-=-=-=-=-=-=-=-=-=-

--
Wulfraed Dennis Lee Bieber KD6MOG
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/

== 2 of 2 ==
Date: Fri, Mar 5 2010 1:45 am
From: Paul Rubin

lbolla <lbolla@gmail.com> writes:
> for k, g in groupby(clean_up(data) , key=lambda s: s.startswith('VLAN')):
> if k:
> key = list(g)[0].replace('VLAN','')

This is the nicest solution, I think. Mine was more cumbersome.

==============================================================================
TOPIC: pysqlite 2.6.0 released
http://groups.google.com/group/comp.lang.python/t/8764cfb7a832f619?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 5 2010 12:40 am
From: Gerhard Häring

pysqlite 2.6.0 released
=======================

Release focus: Synchronize with sqlite3 module in Python trunk.

pysqlite is a DB-API 2.0-compliant database interface for SQLite.

SQLite is a in-process library that implements a self-contained,
serverless, zero-configuration, transactional SQL database
engine.

Go to http://pysqlite.googlecode.com/ for downloads, online documentation and
for reporting bugs.

Changes
=======

- pysqlite can now be built against Python versions without thread support
- PyDict_SetItem is now checked so you cannot shoot yourself in the
foot, even if you try to
- More checks for closed connections were added to avoid possible segfaults

Compatibility
=============

Warning:

pysqlite is not supported for Python < 2.5 any longer. This release still
builds against Python 2.3 and 2.4, but I won't bother with these in the future.

==============================================================================
TOPIC: Partly erratic wrong behaviour, Python 3, lxml
http://groups.google.com/group/comp.lang.python/t/cc11fa023e436ad5?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 5 2010 12:03 am
From: Stefan Behnel

Jussi Piitulainen, 04.03.2010 22:40:
> Stefan Behnel writes:
>> Jussi Piitulainen, 04.03.2010 11:46:
>>> I am observing weird semi-erratic behaviour that involves Python 3
>>> and lxml, is extremely sensitive to changes in the input data, and
>>> only occurs when I name a partial result. I would like some help
>>> with this, please. (Python 3.1.1; GNU/Linux; how do I find lxml
>>> version?)
>>
>> Here's how to find the version:
>>
>> http://codespeak.net/lxml/FAQ.html#i-think-i-have-found-a-bug-in-lxml-what-should-i-do
>
> Ok, thank you. Here's the results:
>
> >>> print(et.LXML_VERSION, et.LIBXML_VERSION,
> ... et.LIBXML_COMPILED_VERSION, et.LIBXSLT_VERSION,
> ... et.LIBXSLT_COMPILED_VERSION)
> (2, 2, 4, 0) (2, 6, 26) (2, 6, 26) (1, 1, 17) (1, 1, 17)

I can't reproduce this with the latest lxml trunk (and Py3.2 trunk) and
libxml2 2.7.6, even after running your test script for quite a while. I'd
try to upgrade the libxml2 version.

Stefan

==============================================================================
TOPIC: comparing two lists
http://groups.google.com/group/comp.lang.python/t/afe61f0eb9c1939d?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 5 2010 12:50 am
From: Vlastimil Brom

2010/3/5 jimgardener <jimgardener@gmail.com>:
> hi
> I have two lists of names.I need to find the difference between these
> two lists.I tried to do it using sets.But I am wondering if there is a
> better way to do it.Please tell me if there is a more elegant way.
> thanks,
> jim
>
> my code snippet follows..
>
> oldlst=['jon','arya','ned','bran']
> newlst=['jaime','jon','cersei']
>
> newlyadded=set(newlst)-set(oldlst)
> removed=set(oldlst)-set(newlst)
> unchanged=set(oldlst)& set(newlst)
> print '%d were newly added= %s'%(len(newlyadded),list(newlyadded))
> print '%d were removed=%s'%(len(removed),list(removed))
> print '%d were unchanged=%s'%(len(unchanged),list(unchanged))
>
> this produces the output
> --------------
> 2 were newly added= ['jaime', 'cersei']
> 3 were removed=['ned', 'arya', 'bran']
> 1 were unchanged=['jon']
> --
> http://mail.python.org/mailman/listinfo/python-list
>

Hi,
I guess for lists with unique items and order insignificant this is
just fine; you may also check difflib, if it suits your needs; there
are multiple comparing and displaying possibilities, e.g.:

>>> import difflib
>>> print "\n".join(difflib.unified_diff(['jon','arya','ned','bran'], ['jaime','jon','cersei']))
---

+++

@@ -1,4 +1,3 @@

+jaime
jon
-arya
-ned
-bran
+cersei
>>>

hth,
vbr

==============================================================================
TOPIC: NoSQL Movement?
http://groups.google.com/group/comp.lang.python/t/942e22a0145599b2?hl=en
==============================================================================

== 1 of 4 ==
Date: Fri, Mar 5 2010 1:07 am
From: Duncan Booth

Gregory Ewing <greg.ewing@canterbury.ac.nz> wrote:

> Duncan Booth wrote:
>> Did I mention that bigtable doesn't require you to have the same
>> columns in every record? The main use of bigtable (outside of
Google's
>> internal use) is Google App Engine and that apparently uses one
table.
>>
>> Not one table per application, one table total. It's a big table.
>
> Seems to me in that situation the term "table" ceases to
> have any meaning. If every record can have its own unique
> structure, and data from completely unrelated applications
> can all be thrown in together, there's no more reason to
> call it a "table" than, say, "file", "database" or "big
> pile of data".
>
I think it depends on how you look at things.

AppEngine uses a programming model which behaves very much as though you
do have multiple tables: you use Django's programming model to wrap each
record in a class, or you can use Gql query languages which looks very
similar to SQL and again the class names appear in the place of table
names.

So conceptually thinking of it as separate tables make a lot of sense,
but the underlying implementation is apparently a single table where
records simply have a type field that is used to instantiate the proper
class on the Python side (and another hidden application field to
prevent you accessing another application's data). Also of course
records with the same type still may not all have the same columns if
you change the class definition between runs, so even at this level they
aren't tables in the strict SQL sense.

There may of course be other applications using bigtable where the
bigtable(s) look much more like ordinary tables, but I don't know what
they are.

From your suggested terms, I'd agree you could call it a database rather
than a table but I think it's too structured for "file" or "big pile of
data" to be appropriate.

--
Duncan Booth http://kupuguy.blogspot.com

== 2 of 4 ==
Date: Fri, Mar 5 2010 1:37 am
From: Juan Pedro Bolivar Puente

On 04/03/10 19:52, ccc31807 wrote:
> On Mar 4, 11:51 am, Juan Pedro Bolivar Puente <magnic...@gmail.com>
> wrote:
>> No, relations are data.
>
> This depends on your definition of 'data.' I would say that
> relationships is information gleaned from the data.
>
>> "Data is data" says nothing. Data is
>> information.
>
> To me, data and information are not the same thing, and in particular,
> data is NOT information. To me, information consists of the sifting,
> sorting, filtering, and rearrangement of data that can be useful in
> completing some task. As an illustration, consider some very large
> collection of ones and zeros -- the information it contains depends on
> whether it's views as a JPEG, an EXE, XML, WAV, or other sort of
> information processing device. Whichever way it's processed, the
> 'data' (the ones and zeros) stay the same, and do not constitute
> 'information' in their raw state.
>
>> Actually, all data are relations: relating /values/ to
>> /properties/ of /entities/. Relations as understood by the "relational
>> model" is nothing else but assuming that properties and entities are
>> first class values of the data system and the can also be related.
>
> Well, this sort of illustrates my point. The 'values' of 'properties'
> relating to specific 'entities' depends on how one processes the data,
> which can be processed various ways. For example, 10000001 can either
> be viewed as the decimal number 65 or the alpha character 'A' but the
> decision as to how to view this value isn't inherent in the data
> itself, but only as an artifact of our use of the data to turn it into
> information.
>

Well, it depends as you said on the definition of information; actually
your definition of data fits into the information-theorical definition
of information as sequence of symbols... But I understand that in other
context /information/ can also mean the next level of abstraction on top
of /data/, in the same way as /knowledge/ is the next level of
abstraction on top of information; lets ground or basis on that.

In any case, your definition and George's still support my point of view
where relations are data: they are stored in the computer as a sequence
of ones and zeroes and is indistinguishable from any other thing in the
data space in that sense. Of course, it is a key data to be able to
recover information and specially to add new information consistently to
the data storage... That SQL includes special syntax for manipulating
relations should not hide this fact; and one can still query the
relational information in the same way one would query non-relational
data in most DBMS anyway...

Anyway I'm sorry for drifting the conversation away... Going back to the
main topic, I agree with the general view on this thread that relational
databases (information-bases ? ;) and non-relational ones are there to
do some different jobs. It is just by carefully examining a problem that
we can define which one fits it better; with relational databases having
the clear advantage that is mathematically grounded basis makes its
fitness for most problems quite clear, while the preference for
non-relational systems is a more technical and empirical problem of the
trade-offs of consistency vs scalability and so on.

== 3 of 4 ==
Date: Fri, Mar 5 2010 2:54 am
From: Bruno Desthuilliers

Philip Semanchuk a écrit :
>
> On Mar 3, 2010, at 5:41 PM, Avid Fan wrote:
>
>> Jonathan Gardner wrote:
>>
>>> I see it as a sign of maturity with sufficiently scaled software that
>>> they no longer use an SQL database to manage their data. At some point
>>> in the project's lifetime, the data is understood well enough that the
>>> general nature of the SQL database is unnecessary.
>>
>> I am really struggling to understand this concept.
>>
>> Is it the normalised table structure that is in question or the query
>> language?
>>
>> Could you give some sort of example of where SQL would not be the way
>> to go. The only things I can think of a simple flat file databases.
>
> Well, Zope is backed by an object database rather than a relational one.

And it ended up being a *major* PITA on all Zope projects I've worked on...

== 4 of 4 ==
Date: Fri, Mar 5 2010 3:56 am
From: mk

Bruno Desthuilliers wrote:
>> Well, Zope is backed by an object database rather than a relational one.
>
> And it ended up being a *major* PITA on all Zope projects I've worked on...

Care to write a few sentences on nature of problems with zodb? I was
flirting with the thought of using it on some project.

Regards,
mk

==============================================================================
TOPIC: Evaluate my first python script, please
http://groups.google.com/group/comp.lang.python/t/24bfa00b428f868f?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Mar 4 2010 11:07 am
From: Tim Wintle

On Thu, 2010-03-04 at 10:39 -0800, Pete Emerson wrote:
> I am looking for advice along the lines of "an easier way to do this"
> or "a more python way" (I'm sure that's asking for trouble!) or
> "people commonly do this instead" or "here's a slick trick" or "oh,
> interesting, here's my version to do the same thing".

(1) I would wrap it all in a function

def main():
# your code here

if __name__ == "__main__":
main()

(2) PEP8 (python style guidelines) suggests one import per line

(3) I'd use four spaces as tab width

(4)
I'd change this:

> for arg in sys.argv[1:]:
> for section in hostname.split('.'):
> if section == arg:
> count = count + 1
> break

to something more like:

for section in hostname.split("."):
if section in sys.argv[1:]:
count += 1

(although as you suggested I'd only calculate sys.argv[1:] once)

... or you could replace whole section between the for loop and
hosts.append with:

if sorted(hostname.split(".")) == sorted(sys.argv[1:]):
host.append(hostname)

, at a slight loss of clarity - but I think I'd stick with the more
verbose version personally.

Tim

== 2 of 2 ==
Date: Fri, Mar 5 2010 2:44 am
From: Jean-Michel Pichavant

Pete Emerson wrote:
> I've written my first python program, and would love suggestions for
> improvement.
>
> I'm a perl programmer and used a perl version of this program to guide
> me. So in that sense, the python is "perlesque"
>
> This script parses /etc/hosts for hostnames, and based on terms given
> on the command line (argv), either prints the list of hostnames that
> match all the criteria, or uses ssh to connect to the host if the
> number of matches is unique.
>
> I am looking for advice along the lines of "an easier way to do this"
> or "a more python way" (I'm sure that's asking for trouble!) or
> "people commonly do this instead" or "here's a slick trick" or "oh,
> interesting, here's my version to do the same thing".
>
> I am aware that there are performance improvements and error checking
> that could be made, such as making sure the file exists and is
> readable and precompiling the regular expressions and not calculating
> how many sys.argv arguments there are more than once. I'm not hyper
> concerned with performance or idiot proofing for this particular
> script.
>
> Thanks in advance.
>
> ########################################################
> #!/usr/bin/python
>
> import sys, fileinput, re, os
>
> filename = '/etc/hosts'
>
> hosts = []
>
> for line in open(filename, 'r'):
> match = re.search('\d+\.\d+\.\d+\.\d+\s+(\S+)', line)
> if match is None or re.search('^(?:float|localhost)\.', line):
> continue
> hostname = match.group(1)
> count = 0
> for arg in sys.argv[1:]:
> for section in hostname.split('.'):
> if section == arg:
> count = count + 1
> break
> if count == len(sys.argv) - 1:
> hosts.append(hostname)
>
> if len(hosts) == 1:
> os.system("ssh -A " + hosts[0])
> else:
> print '\n'.join(hosts)
>
You've already been given good advices.
Unlike some of those, I don't think using regexp an issue in any way.
Yes they are not readable, for sure, I 100% agree to that statement, but
you can make them readable very easily.

# not readable
match = re.search('\d+\.\d+\.\d+\.\d+\s+(\S+)', line)

# readable
match = re.search('\d+\.\d+\.\d+\.\d+\s+(\S+)', line) # match
'192.168.200.1 (foo123)'

I gladly understand ppl that are not willing to use regexp (or as last
resort), but for a perl guy, that should not be an issue.

==============================================================================
TOPIC: _winreg and accessing registry settings of another user
http://groups.google.com/group/comp.lang.python/t/52d636db0efe185d?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 5 2010 1:59 am
From: Tim Golden

On 05/03/2010 07:21, News123 wrote:
> My script shall be part of installing and configuring a PC with some
> default settings with the minimal amount of human administrator
> interactions.
>
> The steps:
> - install windows
> - install python
> - setup one admin account and one or more user accounts (without admin
> privileges)
> - run a script, that preconfigures registry settings for some users.

> 2.) being able to load the 'hive' of another user into the registry and
> be therefore able to change his settings. I didn't find a function
> allowing _winreg to load additional 'hives'

You can use a combination of the win32security, win32api and win32profile
modules from the pywin32 package for this:

<code>
import win32security
import win32api
import win32profile

username = "USERNAME"
domain = "DOMAIN"
password = "PASSWORD"

hUser = win32security.LogonUser (
username,
domain,
password,
win32security.LOGON32_LOGON_NETWORK,
win32security.LOGON32_PROVIDER_DEFAULT
)
hReg = win32profile.LoadUserProfile (
hUser,
{"UserName" : "fozrestore"}
)
try:
print win32api.RegEnumKeyExW (hReg)
finally:
win32profile.UnloadUserProfile (hUser, hReg)

</code>

TJG

==============================================================================
TOPIC: SOAP 1.2 Python client ?
http://groups.google.com/group/comp.lang.python/t/9b1fab5e52c8cfd9?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 5 2010 2:01 am
From: BlueBird

On 3 mar, 20:35, Stefan Behnel <stefan...@behnel.de> wrote:
> BlueBird, 03.03.2010 17:32:
>
> > I am looking for a SOAP 1.2 python client. To my surprise, it seems
> > that this does not exist. Does anybody know about this ?
>
> SOAP may be an overly bloated protocol, but it's certainly not black magic.
> It's not hard to do manually if you really need to:
>
> http://effbot.org/zone/element-soap.htm

But this requires a goog knowloedge of SOAP, in order to parse
everything correctly. The reason I want to use a ready-made client is
that I have about zero knowledge about SOAP, and even more in the
differences between SOAP 1.1 and 1.2 .

cheers,

Philippe

==============================================================================
TOPIC: (www.globlepurchase.com)PAYPAL payment wholesale BRAND shoes,clothing,
watch,handbag,jean,UGG boot,t-shirt,jersey,eyeglass,belt,wallet and so on
http://groups.google.com/group/comp.lang.python/t/0964bbd10efaf58e?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 5 2010 3:42 am
From: brandmarket

paypal payment wholesale
shoes(NIKE,ADIDAS,LV,GUCCI,CHANEL,PRADA,POLO,UGG BOOTS,D&G,DIOR AND

SO ON)
paypal payment wholesale clothing and jeans(A&F,D&G,ED

HARDAY,BAPE,BBC,LV,GUCCI,ARMANI,POLO,POUL SMITH AND SO ON)
http://www.globlepurchase.com
paypal payment watch(ROLEX,OMEGA,CHANEL,LV,CARTIER,IWC,GUCCI,RADO AND
SO ON)
paypal payment
handbag(LV,GUCCI,CHANEL,PRADA,POLO,COACH,FENDI,CHLOE,BUBERRY,JUICY AND
SO ON)
paypal payment brand cap,shawl,belt,wallet,under wear,and so on.

More detail land, address:http://www.globlepurchase.com

==============================================================================
TOPIC: Selecting MAX from a list
http://groups.google.com/group/comp.lang.python/t/961aa5f13067a3a9?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 5 2010 3:39 am
From: Ines T

I need to select a maximum number from a list and then call the variable that
identifies that number, for example:
x1,x2=1, y1,y2=4, z1,z2=3
So I need first to find 4 and then to take y to do additional operations as y-z.
I will appreciate your SOON help!

==============================================================================
TOPIC: Proper way to return an instance of a class from a class method ?
http://groups.google.com/group/comp.lang.python/t/d7498802ae93db37?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 5 2010 4:01 am
From: Chris Rebert

On Fri, Mar 5, 2010 at 2:35 AM, Auré Gourrier
<aurelien.gourrier@yahoo.fr> wrote:
<snip>
> QUESTION 2:
> If I go this way, I have a second problem: if I create a new class which
> inherits from the previous, I would expect/like the methods from the initial
> class to return instances from the new class:
>
> class MyClass2(MyClass):
>
> def othermethods(self):
> return MyClass2(whatever)
>
> Then I get:
>
> x = list1
> y = list2
> data = MyClass2([x,y])
> finaldata = data.transformdata()
>
> My problem is that finaldata is (of course) an instance of MyClass and not
> MyClass2. How do I deal with this ?

Get the object's actual class at runtime and use that.

#in MyClass
def transformdata(self):
newdata = transform(data)
return self.__class__(newdata)

When called on an instance of the subclass, self.__class__ will be
MyClass2 and everything will work out.

Cheers,
Chris
--
http://blog.rebertia.com

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.python"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.python?hl=en

To unsubscribe from this group, send email to comp.lang.python+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.python/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Friday, March 5, 2010

comp.lang.python - 25 new messages in 15 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts