Re: Overriding a global

[Joshua Landau]

On 13/12/2011, Ian Kelly  wrote:
> On Mon, Dec 12, 2011 at 4:48 PM, Joshua Landau
>  wrote:
>> Rebinding logger locally in a function is really no
>> different to a subclass rebinding a variable from its main class using
>> that
>> class' value. The only difference is that, in that case, you have an
>> alternate binding to the original value.
>
> No, there is another difference, the reason for rebinding the name.
> In a subclass, you would rebind a class attribute because that
> particular attribute, which you need to change, is used and expected
> by external code, either in the base class or in code that uses its
> API (or both).  Local variables in functions, on the other hand, are
> not externally visible, so there is no need to do this in order to
> conform to the expectations of external code.  All it does in that
> case is to sow potential confusion.
>
So you're saying you should never extend methods or attributes that
aren't meant to be used as part of of the API? Because I can claim
guilty on this point.

I'd make this longer, but I've got class now :(
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Verbose and flexible args and kwargs syntax

[Eelco]

On Dec 13, 1:27 am, alex23  wrote:
> On Dec 13, 3:12 am, Eelco  wrote:
>
> > But to relate it to the topic of this thread: no, the syntax does not
> > allow one to select the type of the resulting sequence. It always
> > constructs a list.
>
> So by this argument, _every_ function that returns a list should take
> an optional argument to specify an alternative form of sequence.
>
> What, exactly, is so onerous about coercing your list to _whatever_
> type you want? You know, like everybody else has been.
>
> What does this _gain_ you other than one less line of code?

1) Turning two lines of code into a single more readable one is
nothing to scoff at
2) After-the-fact conversion is O(n), getting the view you want right
away is O(1)

Not every function needs this flexibility; many specialized functions
could not care less. But collection unpacking is quite a general
thing, and for the record; slicing a tuple returns a tuple. Would you
rather have that return a list too?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Verbose and flexible args and kwargs syntax

[Eelco]

On Dec 13, 1:34 am, Ian Kelly  wrote:
> On Mon, Dec 12, 2011 at 11:51 AM, Eelco  wrote:
> > Either way, its not hard to add some detail to the semantics to allow
> > all this. Even this function definition:
>
> > def func(Foo(args), Foo(kwargs))
>
> > ...could even be defined unambigiously by overloading first on base
> > type, and if that does not uniquely determine the args and kwargs,
> > fall back on positionality, so that:
>
> > def func(Foo(args), dict(kwargs))
> > def func(list(args), Foo(kwargs))
>
> > would be uniquely defined as well.
>
> That solves some of the problems, but if I just have:
>
>         def func(SequenceOrMappingType(args)):
>
> That's going to unpack positionally.  If I want it to unpack keywords
> instead, how would I change the definition to indicate that?

That should raise an ambiguity error. But honestly, how often have you
worked with SequenceOrMappingType's? I think this is a rather
palatable constraint.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Verbose and flexible args and kwargs syntax

[Eelco]

On Dec 13, 2:41 am, Ian Kelly  wrote:
> On Mon, Dec 12, 2011 at 4:40 PM, Eelco  wrote:
> >> For a linked list, no *target and no copying is needed:
>
> >> head, tail = llist
>
> > I have no idea what this means.
>
> Each node of a linked list consists of a data member and a "next"
> member, that holds the next node in the list.  The natural container
> for this and the way it is usually implemented in Python is a
> 2-element tuple.  For example:
>
> llist = ('one', ('two', ('three', ('four', None
>
> would be a linked list as typically constructed in Python, and it can
> be used in pretty much the same way that lists are used in Lisp.  The
> result of the operation:
>
> head, tail = llist
>
> is:
>
> head = 'one'
> tail = ('two', ('three', ('four', None)))
>
> and as Terry pointed out, no copying is required to do this.  I
> believe deque is also implemented as a doubly-linked list, which is
> probably why you keep referring to it as such, but that is an
> implementation detail.  When you say "linked list" in relation to
> Python, the preceding is what comes to mind.

'for i in llist' is not quite going to fly is it? Thats probably the
reason noone ever uses that construct; its not a proper sequence type.


> >>  head, deque(tail) = somedeque
>
> >> > Is better in every way I can think of (readability, consistence,
> >> > performance) than:
> >>  head, *tail = somedeque
> >>  tail = deque(tail)
>
> >> But your suggestion is much worse in each way than
>
> >> head = somedeque.popleft()
>
> > No its not. First of all, its not semantically equivalent; popleft
> > mutates a collection type, and collection unpacking does not; it
> > creates a set of disjoint views of the collection's data. Whether its
> > worse in terms of readability is debatable, but in terms of the other
> > two stated metrics, your claim of it being any kind of worse is
> > objectively false.
>
> I definitely disagree on readability.  Skimming this thread as I have
> been, it took me a while to get that your proposed syntax would create
> a second deque sharing internal state with the original, rather than
> creating a simple copy of the deque, which is what it looks like it
> should do.

Thats a matter of reading up on the semantics of collection unpacking.
To be honest I dont even know what they are for lists, since I dont
use python 3. But whatever is the case, the important thing is that
the semantics should be uniform regardless of the type to be unpacked.

> Incidentally, while that change is not really central to your syntax
> proposal, I think it would be very messy.  For example, how do you
> propose keeping the length elements in sync?  Inserting an item in one
> may or may not affect the length of the other.  If I append an item to
> the end of one deque, should the other automatically be extended as
> well?  What if the tail node of the second deque occurs after the tail
> node of the deque being appended?  Does the appended element then get
> inserted into the middle of the second deque (I think it would have to
> be)?  If I insert an element into the longer (second) deque that just
> happens to be immediately after the tail of the shorter deque, does
> *that* cause the shorter deque to be automatically extended?  And
> likewise for operations at the head of the deque.
>
> None of these questions have obvious answers as to the "right" way to
> it, and for that reason I think this is probably best left to the user
> to implement a custom deque view class with whatever semantics they
> prefer.

Good point. Copy-on-write semantics could be used, but really one
should have several linked list types reflecting the underlying
implementations. I would like to have an immutable singly linked list
builtin of the standard functional type, which you can only unpack
from one end and renders these issues moot, plus a builtin doubly
linked list with copy-on-write or copy-on-unpacking semantics.

> > Furthermore, this brings us back again to the point I raised several
> > times before. Yes, obviously you can already DO these things, but NOT
> > within the same uniform collection unpacking syntactic construct.
> > Again, you have failed to point out what is wrong with supplying a
> > type constrain to python and let it do the right thing based on that;
> > to reiterate:
>
> > head, tail::deque = deque
>
> Python users generally follow the rule "explicit is better than
> implicit".  Setting a general constraint and letting the language "do
> the right thing" is a kind of black magic that feels off because it
> tends to break that rule.  But that's not to say that black magic
> never wins -- just look at super() and the MRO.

We are not talking black magic here; we are talking about an EXPLICIT
type constraint provided on the very same line.

> > If you dont like the extra characters you have to type; there is of
> > course such a thing as defaults. You can choose:
> > head, tail:: = deque; if the type constraint is omitted, we c

Re: Overriding a global

[Antoon Pardon]

On 12/10/2011 09:47 PM, Roy Smith wrote:

I've got a code pattern I use a lot.  In each module, I create a logger
for the entire module and log to it all over:

logger = logging.getLogger('my.module.name')

class Foo:
def function(self):
   logger.debug('stuff')
   logger.debug('other stuff')

and so on.  This works, but every once in a while I decide that a
particular function needs a more specific logger, so I can adjust the
logging level for that function independent of the rest of the module.
What I really want to do is:

def function(self):
   logger = logger.getChild('function')
   logger.debug('stuff')
   logger.debug('other stuff')

which lets me not have to change any lines of code other than inserting
the one to redefine logger.  Unfortunately, that's not legal Python (it
leads to "UnboundLocalError: local variable 'logger' referenced before
assignment").

Any ideas on the best way to implement this?
   

How about two global references:

globallogger = logger = logging.getLogger('my.module.name')

def function(self):
  logger = globallogger.getChild('function')
  logger.debug('stuff')
  logger.debug('other stuff')

--
Antoon Pardon

--
http://mail.python.org/mailman/listinfo/python-list

Re: Verbose and flexible args and kwargs syntax

[Eelco]

On Dec 13, 3:43 am, Steven D'Aprano  wrote:
> On Mon, 12 Dec 2011 04:21:15 -0800, Eelco wrote:
> >> No more, or less, explicit than the difference between "==" and "is".
>
> > == may be taken to mean identity comparison; 'equals' can only mean one
> > thing.
>
> Nonsense. "Equals" can be taken to mean anything the language designer
> chooses, same as "==". There is no language police that enforces The One
> True Meaning Of Equals. In fact, there is no one true meaning of equals.
> Even my tiny Pocket Oxford dictionary lists five definitions.
>
> It is ironic that the example you give, that of identity, is the standard
> definition of equals in mathematics. 2*2 = 4 does not merely say that
> "there is a thing, 2*2, which has the same value as a different thing,
> 4", but that both sides are the same thing. Two times two *is* four. All
> numbers are, in some sense, singletons and equality implies identity.

We are not talking mathemathics, we are talking programming languages.
Identity versus value equality is a well established concept within
its jargon. Within this context, 'equals' and 'is' have clearly
defined meanings. Indeed within broader use, including everyday
language, the distinction is more subtle and therefore less useful,
but obeying a linguistic rule that holds within computer science is
better than making something up just for python, even though its not
the yet better rule that any five year old might grasp.

> > Of course 'formally' these symbols are well defined, but so is
> > brainf*ck
>
> I don't understand your point here.

Hence the above.

> >>  Modulo is hardly an obscure operation. "What's the remainder...?" is a
> >>  simple question that people learn about in primary school.
>
> > So is 'how much wood would a woodchucker chuck if a woodchucker could
> > chuck wood?'. But how often does that concept turn up in your code?
>
> You didn't make a statement about how often modulo turns up in code
> (which is actually quite frequently, and possibly more frequently than
> regular division), but about the obscurity of the operation. Taking the
> remainder is not an obscure operation. The names "modulo" and "modulus"
> may be obscure to those who haven't done a lot of mathematics, but the
> concept of remainder is not. "How many pieces are left over after
> dividing into equal portions" is something which even small children get.

So 'frequency of use' is no valid interpretation of 'obscurity'? Im
not a native speaker, but im pretty sure it is.

> >> And you can blame C for the use of % instead of mod or modulo.
>
> > I didnt know one of Python's design goals was backwards compatibility
> > with C.
>
> Don't be silly. You know full well Python is not backwards compatible
> with C, even if they do share some syntactical features.

Of course I was being silly; I know this use is following a historical
precedent; but id rather see it rectified in the previous version of
python rather than the next. My sillyness was prompted by the
percieved pointlessness of your remark. Of course python is not trying
to be backwards compatible with C; so why bring it up then?

> >>  If you can supply any function at all, what happens if I write this:
>
> > You cannot; only constructors modelling a sequence or a dict, and only
> > in that order. Is that rule clear enough?
>
> But why limit yourself to those restrictive rules?
>
> If I want to collect a sequence of arguments into a string, why shouldn't
> I be allowed to write this?
>
>     def func(parg, str(args)): ...
>
> If I want to sum a collection of arguments, why not write this?
>
>     def func(pargs, sum(args)): ...
>
> Isn't that better than this?
>
>     def func(pargs, *args):
>         args = sum(args)
>         ...
>
> But no. I don't mean those examples to be taken seriously: when you
> answer to your own satisfaction why they are bad ideas, you may be closer
> to understanding why I believe your idea is also a bad idea.

They are bad ideas because they truely do not lead to the execution of
different code, but are merely a reordering, mixing statements in with
a function declaration. I am proposing no such thing; again, the
type(arg) notation I have dropped, and never was meant to have
anything to do with function calling; it is a way of supplying an
optional type constraint, so in analogy with function annotations, I
changed that to arg::type. Again, this has nothing to do with calling
functions on arguments.

First off, type constraints must have some use; all those languages
cant be wrong. Ofcourse, no type constraints also can not be wrong;
see all those other languages. And I obviously dont mean to make type
constraits mandatory in python, all im saying is that optionally
allowing them can open some doors in the right places. The * and **
syntax are also in effect type constraints, saying 'this is a dict to
collect the remaining kwargs in', but in a rather cryptic and
needlessly ungeneral method.

#define a function with args-list and kwar

Re: Verbose and flexible args and kwargs syntax

[Eelco]

> > Python users generally follow the rule "explicit is better than
> > implicit".  Setting a general constraint and letting the language "do
> > the right thing" is a kind of black magic that feels off because it
> > tends to break that rule.  But that's not to say that black magic
> > never wins -- just look at super() and the MRO.
>
> We are not talking black magic here; we are talking about an EXPLICIT
> type constraint provided on the very same line.

To hammer that point home: would you say the following C# code
performs 'black magic'?

float x = 3;

After all, exactly the same thing is going on; C# will 'do the right
thing'; convert the integer literal 3 to a floating point value, based
on the type constraint placed on x.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyDev and multithreaded application debug

[Fabio Zadrozny]

On Mon, Dec 12, 2011 at 2:30 PM, Massi  wrote:
> Hi everyone, I've just started to use pydev to develop my python
> application and I'm encountering some problems to debug it. The
> application I'm dealing with is a multithreaded application; when I
> try to debug it with pydev, it seems not to be able to handle the
> execution of multiple threads. The problem is that when the execution
> reaches a breakpoint in one of the threads, all the other ones don't
> stop, but they continue their execution.
> Have I to make some specific settings or am I missing something?
> Thanks in advance!

Actually, that's expected, as you've only hit the breakpoint at that
thread... if you want, you can press the pause button to stop the
other threads.

Cheers,

Fabio
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Overriding a global

[Jean-Michel Pichavant]

Steven D'Aprano wrote:

On Mon, 12 Dec 2011 12:13:33 +0100, Jean-Michel Pichavant wrote:

  

Using the same name for 2 different objects is a bad idea in general.



We have namespaces precisely so you don't need to care about making names 
globally unique.



  

I don't get your point, namespaced names are unique, by definition.

foo.aname <> bar.aname

The OP showed a code where there was a confusion between a global name 
and a local one. There's no namespace involved. Having a local name 
identical to a global one is a bad idea, def.


JM
--
http://mail.python.org/mailman/listinfo/python-list

Re: Outputting raw MIDI in realtime on Linux

[Peter Billam]

On 2011-12-12, alex23  wrote:
> On Dec 12, 12:14 pm, Nick Irvine  wrote:
>> What do people use to output live MIDI on Linux, assuming it's
>> possible?
> I've yet to try this myself although it's long been on my to-do list.
> There are a couple of packages on PyPI that emit MIDI:
> http://pypi.python.org/pypi?%3Aaction=search&term=midi

Check out
  http://www.pjb.com.au/midi/index.html
  http://www.pjb.com.au/midi/MIDI.html
but what you _really_ want is Patricio Paez' alsaseq and alsamidi
   http://pp.com.mx/python/alsaseq
which I translated into Lua and Perl:
  http://www.pjb.com.au/comp/lua/midialsa.html
  http://search.cpan.org/perldoc?MIDI::ALSA
although by now my translations have developed slightly
more features and fewer quirks than the original...

Hope this helps,
Peter

-- 
Peter Billamwww.pjb.com.auwww.pjb.com.au/comp/contact.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Verbose and flexible args and kwargs syntax

[Eelco]

> To answer that question: for the same reasons. The conversion is
> wasteful; allowing python to do the right thing based on a
> typeconstraint is not. Plus, it is less code, and more readable code;
> the only rule you have to learn is quite general, which is that :: is
> a type constraint annotation; no need to remember specifics, like
> 'unpacking always returns lists for some arbitrary reason'.

Oh my bad; actually, that should be:

'collecting the remainder of an unpacked iterable using * will always
yield a list. That is, unless the construct appears inside a function
definition; then somehow a tuple is always the right choice'
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Verbose and flexible args and kwargs syntax

[Arnaud Delobelle]

On 13 December 2011 09:50, Eelco  wrote:
>> To answer that question: for the same reasons. The conversion is
>> wasteful; allowing python to do the right thing based on a
>> typeconstraint is not. Plus, it is less code, and more readable code;
>> the only rule you have to learn is quite general, which is that :: is
>> a type constraint annotation; no need to remember specifics, like
>> 'unpacking always returns lists for some arbitrary reason'.
>
> Oh my bad; actually, that should be:
>
> 'collecting the remainder of an unpacked iterable using * will always
> yield a list. That is, unless the construct appears inside a function
> definition; then somehow a tuple is always the right choice'

When you quote somebody (even yourself), it would be helpful if you
attributed your quote.

-- 
Arnaud
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Verbose and flexible args and kwargs syntax

[Eelco]

On 13 dec, 11:15, Arnaud Delobelle  wrote:
> On 13 December 2011 09:50, Eelco  wrote:
>
> >> To answer that question: for the same reasons. The conversion is
> >> wasteful; allowing python to do the right thing based on a
> >> typeconstraint is not. Plus, it is less code, and more readable code;
> >> the only rule you have to learn is quite general, which is that :: is
> >> a type constraint annotation; no need to remember specifics, like
> >> 'unpacking always returns lists for some arbitrary reason'.
>
> > Oh my bad; actually, that should be:
>
> > 'collecting the remainder of an unpacked iterable using * will always
> > yield a list. That is, unless the construct appears inside a function
> > definition; then somehow a tuple is always the right choice'
>
> When you quote somebody (even yourself), it would be helpful if you
> attributed your quote.
>
> --
> Arnaud

Ah yes; im more used to proper forums, still getting used to these
mailing-list things. But point taken.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Verbose and flexible args and kwargs syntax

[Eelco]

With all this being said, I must say that the notion of indtroducing
type constraints into Python is quite a radical one*, and one that
should not be taken lightly, so I understand the general conservative
vibe the notion is getting. It probably has implications beyond just
collection types, and if youd introduce such a feature, you would like
to introduce it only once, and correctly the first time around.

Ill probably start a new thread soon, recapping the accumulated
insight, and capping all the OT threads that have spawned.

*even though the asteriks syntax is infact a limited form of exactly
that
-- 
http://mail.python.org/mailman/listinfo/python-list

change a file with a context manager

[Andrea Crotti]

So I have the following problem, I need something to copy a file to a 
certain position

and restore it after.
So I wrote this simple context manager:

class WithCorrectEasyInstall(object):

def __enter__(self):
import pkg_resources
from shutil import copyfile
easy_install_file = 
pkg_resources.resource_filename('psi.devsonly', 'windows_easy_install.pth')
self.global_easy_install = 
'c:/python25/Lib/site-packages/easy-install.pth'

# can use mmap, a temporary file or just write to string
self.stored = open(self.global_easy_install).read()
logger.debug("copying the correct easy_install.pth file to the 
global position")

copyfile(easy_install_file, self.global_easy_install)

def __exit__(self, type, value, traceback):
#TODO: make sure it's restored also when quitting in some other 
ways

# restore the old file
open(self.global_easy_install, 'w').write(self.stored)
logger.debug("restoring the old easy_install.pth file")


The problem is that this is not executed for example when the program is 
interrupted

with for example a KeyboardInterrupt.
But that's also an exception, why is it not caught by the context manager?

And if there are better way to do what I'm trying to achieve they are 
welcome :)

--
http://mail.python.org/mailman/listinfo/python-list

NumPy book review copies

[Jitesh]

Hi,

As a part of our reviewing program, we are giving away limited number
of copies (print & electronic) of our recent publication NumPy 1.5
Beginner's Guide to people interested in reviewing the book.

Book-link: http://link.packtpub.com/sibctR

You need to publish your review/feedback on either your blog or on
websites like Barnes and Noble, Slashdot and so on as per your choice.
We also encourage uploading the review on Amazon since it gives buyers
a chance to know about the book through your perspective.

For more information, please get in touch with me on my email jiteshg
AT packtpub DOT com

Thanks,

Jitesh

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Verbose and flexible args and kwargs syntax

[Steven D'Aprano]

On Tue, 13 Dec 2011 01:15:46 -0800, Eelco wrote:

> On Dec 13, 3:43 am, Steven D'Aprano  +comp.lang.pyt...@pearwood.info> wrote:
>> On Mon, 12 Dec 2011 04:21:15 -0800, Eelco wrote:
>> >> No more, or less, explicit than the difference between "==" and
>> >> "is".
>>
>> > == may be taken to mean identity comparison; 'equals' can only mean
>> > one thing.
[...]
> We are not talking mathemathics, we are talking programming languages.

What *I* am talking about is your assertion that there is only one 
possible meaning for "equals" in the context of a programing language. 
This is *simply not correct*.

You don't have to believe me, just look at the facts. It's hard to find 
languages that use the word "equals" (or very close to it) rather than 
equals signs, but here are four languages which do:

(1) OpenXION:

Equals in OpenXION is weakly typed, like Perl:

>1 + 1.0 equals "2"
true


(2) C# uses method notation: a.Equals(b) can be overridden, but for many 
types it defaults to value equality, that is, the equivalent to Python's 
a == b.

(3) Ruby uses a.equal?(b) for "reference equality", that is, the 
equivalent of Python's "is" operator:

irb(main):001:0> a = "abc"
=> "abc"
irb(main):002:0> b = "abc"
=> "abc"
irb(main):003:0> a.equal?(b)
=> false
irb(main):004:0> a == b
=> true


(4) Mathematica's Equal[x, y] can test values and expressions for 
equality. It may return true, false, or unevaluated (i.e. itself).


Four languages that use Equals (or close to it) with four different 
behaviours.



> Identity versus value equality is a well established concept within its
> jargon. Within this context, 'equals' and 'is' have clearly defined
> meanings. 

Incorrect. Most programming languages do not even have a concept of 
identity: identity is only(?) relevant to reference languages, like 
Python, where variables are references to objects.

Even for languages that have a concept of identity, most don't don't call 
it "is". Objective-C calls it "==", PHP calls it "===", C# calls it 
object.ReferenceEquals. (Python, Algol 68, and VB .NET are three which do 
call it "is".)

For stack-based languages like Forth, it doesn't even make sense to talk 
about identity, since values aren't variables: they're just values on a 
stack, not values in a fixed location, or bound to a known name.

Again, all this goes to demonstrate that the language designer is free to 
choose any behaviour they like, and give it any name they like.


[...]
> So 'frequency of use' is no valid interpretation of 'obscurity'? Im not
> a native speaker, but im pretty sure it is.

No. Things which are obscure are used in language infrequently, because 
if they were common they would not be obscure. But things which are used 
infrequently are not necessarily obscure.

An example in common language: "Napoleon Bonaparte" does not come up in 
conversation very frequently, but he is not an obscure historical figure.

An example from programming: very few people need to use the 
trigonometric functions sin, cos, tan in their code. But they are not 
obscure functions: most people remember them from school. People who have 
forgotten almost everything about mathematics except basic arithmetic 
probably remember sin, cos and tan. But they never use them.



>> >> And you can blame C for the use of % instead of mod or modulo.
>>
>> > I didnt know one of Python's design goals was backwards compatibility
>> > with C.
>>
>> Don't be silly. You know full well Python is not backwards compatible
>> with C, even if they do share some syntactical features.
> 
> Of course I was being silly; I know this use is following a historical
> precedent; but id rather see it rectified in the previous version of
> python rather than the next. My sillyness was prompted by the percieved
> pointlessness of your remark. Of course python is not trying to be
> backwards compatible with C; so why bring it up then?

Because you asked why Python uses the % operator for remainder.


[...]
> They are bad ideas because they truely do not lead to the execution of
> different code, but are merely a reordering, mixing statements in with a
> function declaration. I am proposing no such thing; again, the type(arg)
> notation I have dropped, and never was meant to have anything to do with
> function calling; it is a way of supplying an optional type constraint,
> so in analogy with function annotations, I changed that to arg::type.
> Again, this has nothing to do with calling functions on arguments.

You have not thought about this carefully enough. Consider what happens 
when this code gets called:

def f(*args): pass

f(a, b, c)


The Python virtual machine (interpreter, if you prefer) must take three 
arguments a, b, c and create a tuple from them. This must happen at 
runtime, because the value of the objects is not known at compile time. 
So at some point between f(a, b, c) being called and the body of f being 
entered, a tuple must be created, and the values of a, b, c must be 
collated int

Re: Overriding a global

[Steven D'Aprano]

On Tue, 13 Dec 2011 10:54:51 +0100, Jean-Michel Pichavant wrote:

> Steven D'Aprano wrote:
>> On Mon, 12 Dec 2011 12:13:33 +0100, Jean-Michel Pichavant wrote:
>>
>>
>>> Using the same name for 2 different objects is a bad idea in general.
>>> 
>>> 
>> We have namespaces precisely so you don't need to care about making
>> names globally unique.
>>
>>
>>
> I don't get your point, namespaced names are unique, by definition.
> 
> foo.aname <> bar.aname

Assuming foo and bar are not names for the same object, there are at 
least three namespaces here: the local namespace, where foo and bar can 
be found, the foo.__dict__ namespace, and the bar.__dict__ namespace.


> The OP showed a code where there was a confusion between a global name
> and a local one. There's no namespace involved. Having a local name
> identical to a global one is a bad idea, def.

Of course there are namespaces involved. There is the global namespace, 
and the local namespace. That's how you can have x inside a function 
without it overwriting global x outside of it, because they are different 
namespaces. Which is my point.

When I write this:

x = 1

def spam():
x = 2

def ham():
x = 3

The three x's don't clash because they are in three separate namespaces.

-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: automate commands to an .exe console program through python

[Juan Perez]

Well, if developers have to change something to the code, I'd continue with
autoit, since is closer to real enviroment. You are right, autoit work by
send parametres to GUI focused, but really I don't think it's something
necessary for my purposes as I need only send parameters to a windows cmd
console. Do you know if is that possible by piping standard input? I've
tried but with no results. What I'd need is open a new windows console get
the pid and send messages to it through stdin pipe. But I've been unable to
do it so far.

Thanks,

Juan

2011/12/12 Chris Angelico 

> On Tue, Dec 13, 2011 at 3:41 AM, Juan Perez  wrote:
> > I need to automate a .exe console program in windows, and send key
> > characters like 'a', 'M' ...
> > I had this running in an autoIT script which with only activating cmd
> > window, and with the "send" parameter I had all already done. But I'm
> having
> > a lot of problems with python, I've tried with process.call,
> communicate(),
> > os.popen ... but no results. I can't comunicate with the program and
> even i
> > can't maintain it opened more than  a few seconds. If I open a program
> like
> > notepad.exe it remains opened but when I try to comunicate with the stdin
> > pipe just don't write anything to the program.
>
> GUI programs such as Notepad usually don't read from STDIN, which is
> where text goes if you write to a pipe. You may have to check out how,
> exactly, the program accepts commands; your autoIT script is probably
> sending keystrokes using the Wndows GUI, so it works as long as the
> program has focus.
>
> Ideally, look into whether the program has an actual automation mode -
> and if it doesn't have one, ask the programmer to expose his code
> directly to a Python script. Hey, it's worth a shot! :)
>
> ChrisA
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: automate commands to an .exe console program through python

[Chris Angelico]

On Tue, Dec 13, 2011 at 10:21 PM, Juan Perez  wrote:
> Well, if developers have to change something to the code, I'd continue with
> autoit, since is closer to real enviroment. You are right, autoit work by
> send parametres to GUI focused, but really I don't think it's something
> necessary for my purposes as I need only send parameters to a windows cmd
> console. Do you know if is that possible by piping standard input? I've
> tried but with no results. What I'd need is open a new windows console get
> the pid and send messages to it through stdin pipe. But I've been unable to
> do it so far.

The easiest way to see whether a pipe will work or not is to put the
commands into a file and use redirection:

NameOfProgram http://mail.python.org/mailman/listinfo/python-list

Re: Verbose and flexible args and kwargs syntax

[Steven D'Aprano]

On Tue, 13 Dec 2011 02:46:13 -0800, Eelco wrote:

> With all this being said, I must say that the notion of indtroducing
> type constraints into Python is quite a radical one*, 

Not that radical. Here's the creator of Python musing about adding 
optional type checks to Python:

http://www.artima.com/weblogs/viewpost.jsp?thread=85551
http://www.artima.com/weblogs/viewpost.jsp?thread=86641
http://www.artima.com/weblogs/viewpost.jsp?thread=87182


[...]
> *even though the asteriks syntax is infact a limited form of exactly
> that

It absolutely is not. def f(*args, **kwargs) constructs a tuple and a 
dict, it does not type-check that the function is passed a tuple and a 
dict as arguments. These are completely different things.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: automate commands to an .exe console program through python

[Tim Golden]

On 13/12/2011 11:21, Juan Perez wrote:

Well, if developers have to change something to the code, I'd continue
with autoit, since is closer to real enviroment. You are right, autoit
work by send parametres to GUI focused, but really I don't think it's
something necessary for my purposes as I need only send parameters to a
windows cmd console. Do you know if is that possible by piping standard
input? I've tried but with no results. What I'd need is open a new
windows console get the pid and send messages to it through stdin pipe.
But I've been unable to do it so far.


I think that you're thinking about this the wrong way. You're talking
about automating a Console program as though it were notepad: by sending
keystrokes. Mixed in with that you've got some kind of notion of piping
stdin/stdout.

If you've got a (non-GUI) program which you usually run in a Console
context, it will either take its input from stdin -- in which case,
ignore the fact it runs in a console and feed it via subprocess --
or it will take input from some kind of Console-level getch method,
in which case you'll have to use something like SendKeys [1] or perhaps
WinPexpect [2]

Don't know if that helps at all...

TJG


[1] http://www.rutherfurd.net/python/sendkeys/

[2] https://bitbucket.org/geertj/winpexpect/wiki/Home
--
http://mail.python.org/mailman/listinfo/python-list

Re: Fixing the XML batteries

[Serhiy Storchaka]

09.12.11 17:09, Dirkjan Ochtman wrote:

On Fri, Dec 9, 2011 at 09:02, Stefan Behnel  wrote:
An at least somewhat informed +1 from me. The ElementTree API is a
very good way to deal with XML from Python, and it deserves to be
promoted over the included alternatives.

Let's deprecate the NiCad batteries and try to guide users toward the
Li-Ion ones.


I use xml.dom.minidom for XML canonization and convertion:

doc = xml.dom.minidom.parse( io.BytesIO( data0 ) )
encoding = forceEncoding or doc.encoding or str( 'UTF-8' )
writer = io.BytesIO()
writer = codecs.getwriter( encoding )( writer,  'xmlcharrefreplace' )
doc.writexml( writer, encoding = encoding )
data = writer.getvalue()

How to do this with xml.etree.ElementTree?

--
http://mail.python.org/mailman/listinfo/python-list

Re: Verbose and flexible args and kwargs syntax

[Eelco]

On 13 dec, 12:28, Steven D'Aprano  wrote:
> On Tue, 13 Dec 2011 02:46:13 -0800, Eelco wrote:
> > With all this being said, I must say that the notion of indtroducing
> > type constraints into Python is quite a radical one*,
>
> Not that radical. Here's the creator of Python musing about adding
> optional type checks to Python:
>
> http://www.artima.com/weblogs/viewpost.jsp?thread=85551http://www.artima.com/weblogs/viewpost.jsp?thread=86641http://www.artima.com/weblogs/viewpost.jsp?thread=87182

Good find; but still radical enough that it hasnt been implemented.
Note that these musing are trying to adress a yet far more general
problem of specifying arbitrary types constraints on anything; I am
primarily interested in specifying container types in the special case
of collection packing/unpacking syntax, with further extensions
nothing but a welcome addon. The fact that the former was judged
infeasible does not mean the more modest goal of the latter might not
be attainable.


> > *even though the asteriks syntax is infact a limited form of exactly
> > that
>
> It absolutely is not. def f(*args, **kwargs) constructs a tuple and a
> dict, it does not type-check that the function is passed a tuple and a
> dict as arguments. These are completely different things.

Which is of course not something I ever proposed; I never said
anything about checking types of existing data; im talking about
coercing types of newly created data, like the target of a collection
packing. That is exactly what *args and **kwargs also do.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Fixing the XML batteries

[Serhiy Storchaka]

09.12.11 17:09, Dirkjan Ochtman wrote:

On Fri, Dec 9, 2011 at 09:02, Stefan Behnel  wrote:
An at least somewhat informed +1 from me. The ElementTree API is a
very good way to deal with XML from Python, and it deserves to be
promoted over the included alternatives.

Let's deprecate the NiCad batteries and try to guide users toward the
Li-Ion ones.


I use xml.dom.minidom for XML canonization and convertion:

doc = xml.dom.minidom.parse( io.BytesIO( data0 ) )
encoding = forceEncoding or doc.encoding or str( 'UTF-8' )
writer = io.BytesIO()
writer = codecs.getwriter( encoding )( writer,  'xmlcharrefreplace' )
doc.writexml( writer, encoding = encoding )
data = writer.getvalue()

How to do this with xml.etree.ElementTree?

--
http://mail.python.org/mailman/listinfo/python-list

Re: Fixing the XML batteries

[Stefan Behnel]

Serhiy Storchaka, 13.12.2011 13:17:

09.12.11 17:09, Dirkjan Ochtman wrote:

An at least somewhat informed +1 from me. The ElementTree API is a
very good way to deal with XML from Python, and it deserves to be
promoted over the included alternatives.

Let's deprecate the NiCad batteries and try to guide users toward the
Li-Ion ones.


I stripped my name from the quoted context because I didn't say this.



I use xml.dom.minidom for XML canonization and convertion:


Do you mean "canonicalisation"? I.e. C14N? That's not what the code below 
is doing, not at all.




doc = xml.dom.minidom.parse( io.BytesIO( data0 ) )
encoding = forceEncoding or doc.encoding or str( 'UTF-8' )
writer = io.BytesIO()
writer = codecs.getwriter( encoding )( writer, 'xmlcharrefreplace' )
doc.writexml( writer, encoding = encoding )
data = writer.getvalue()

How to do this with xml.etree.ElementTree?


In Python 2.7/3.2, ElementTree has support for C14N serialisation, just 
pass the option method="c14n".


Stefan

--
http://mail.python.org/mailman/listinfo/python-list

Re: automate commands to an .exe console program through python

[Juan Perez]

Thank you for your responses,

My problem is thinking in windows console somewhat like linux shell, and do
same things I did with pipes in C programming. But it seems not to be the
case.
At a glance I dare say that sendkeys module is useful  enough, but if I've
understood well, you only can send messages to focused window, that will
report some inestabilities if windows focused is changed. You won't be able
to touch anything in the current laptop. So, is there any way to identify
the a process/window and send keystrokes in a smarter way and/or is it
possible to identify a window an get the focus on it?

I'm worried that pexpect is a too dificult way...

Thanks,

Juan

2011/12/13 Tim Golden 

> On 13/12/2011 11:21, Juan Perez wrote:
>
>> Well, if developers have to change something to the code, I'd continue
>> with autoit, since is closer to real enviroment. You are right, autoit
>> work by send parametres to GUI focused, but really I don't think it's
>> something necessary for my purposes as I need only send parameters to a
>> windows cmd console. Do you know if is that possible by piping standard
>> input? I've tried but with no results. What I'd need is open a new
>> windows console get the pid and send messages to it through stdin pipe.
>> But I've been unable to do it so far.
>>
>
> I think that you're thinking about this the wrong way. You're talking
> about automating a Console program as though it were notepad: by sending
> keystrokes. Mixed in with that you've got some kind of notion of piping
> stdin/stdout.
>
> If you've got a (non-GUI) program which you usually run in a Console
> context, it will either take its input from stdin -- in which case,
> ignore the fact it runs in a console and feed it via subprocess --
> or it will take input from some kind of Console-level getch method,
> in which case you'll have to use something like SendKeys [1] or perhaps
> WinPexpect [2]
>
> Don't know if that helps at all...
>
> TJG
>
>
> [1] 
> http://www.rutherfurd.net/**python/sendkeys/
>
> [2] 
> https://bitbucket.org/geertj/**winpexpect/wiki/Home
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: automate commands to an .exe console program through python

[Chris Angelico]

On Tue, Dec 13, 2011 at 11:35 PM, Juan Perez  wrote:
> My problem is thinking in windows console somewhat like linux shell, and do
> same things I did with pipes in C programming. But it seems not to be the
> case.

It is (at least, it supports the basics of pipes and redirection); but
what you're looking at here is an application that appears not to use
STDIN.

> At a glance I dare say that sendkeys module is useful  enough, but if I've
> understood well, you only can send messages to focused window, that will
> report some inestabilities if windows focused is changed. You won't be able
> to touch anything in the current laptop. So, is there any way to identify
> the a process/window and send keystrokes in a smarter way and/or is it
> possible to identify a window an get the focus on it?

You may be able to put focus to the window before sending it keys, but
this is sounding extremely hackish (nearly as bad as the Magic: The
Gathering Online trade-bot system). I'm thinking here the best option
may be to give this a dedicated virtual machine and let it do whatever
it likes - effectively, have an entire "computer" dedicated to just
this application and its automation harness. That would probably make
things simple enough that you don't need to worry too much about
focus, sending keystrokes to other windows, etc.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Verbose and flexible args and kwargs syntax

[Eelco]

On 13 dec, 12:13, Steven D'Aprano  wrote:
> On Tue, 13 Dec 2011 01:15:46 -0800, Eelco wrote:
> > On Dec 13, 3:43 am, Steven D'Aprano  > +comp.lang.pyt...@pearwood.info> wrote:
> >> On Mon, 12 Dec 2011 04:21:15 -0800, Eelco wrote:
> >> >> No more, or less, explicit than the difference between "==" and
> >> >> "is".
>
> >> > == may be taken to mean identity comparison; 'equals' can only mean
> >> > one thing.
> [...]
> > We are not talking mathemathics, we are talking programming languages.
>
> What *I* am talking about is your assertion that there is only one
> possible meaning for "equals" in the context of a programing language.
> This is *simply not correct*.
>
> You don't have to believe me, just look at the facts. It's hard to find
> languages that use the word "equals" (or very close to it) rather than
> equals signs, but here are four languages which do:

That python is not the only language to not get this quite as right as
could be is known to me. But within computer science as a discipline,
equality and identity comparisons have a clear enough meaning. 'is'
has a narrower meaning than 'equals'. '==' has no meaning whatsoever
in computer science.

> Again, all this goes to demonstrate that the language designer is free to
> choose any behaviour they like, and give it any name they like.

Certainly you demonstrated as much. Programming languages are created
by people, and they have a tendency to make mistakes, and to have to
compromise (backwards compatibility, and so on). Thats a seperate
matter from 'what ought to be done', when discussing optimal language
design.

> > So 'frequency of use' is no valid interpretation of 'obscurity'? Im not
> > a native speaker, but im pretty sure it is.
>
> No. Things which are obscure are used in language infrequently, because
> if they were common they would not be obscure. But things which are used
> infrequently are not necessarily obscure.
>
> An example in common language: "Napoleon Bonaparte" does not come up in
> conversation very frequently, but he is not an obscure historical figure.
>
> An example from programming: very few people need to use the
> trigonometric functions sin, cos, tan in their code. But they are not
> obscure functions: most people remember them from school. People who have
> forgotten almost everything about mathematics except basic arithmetic
> probably remember sin, cos and tan. But they never use them.

I dont think its terribly interesting to debate whether the term
obscure applies to trigonometric functions or not: the important
matter is that they are where they should be; under math.cos, etc.
They dont have their own special character, and I hope you agree that
is as it should be.

I use trig far more often than modulus, so that argues in favor of
modulus being under math too; infact I used modulus quite recently,
but naturally it was in a piece of code that should be done in C
eventually anyway (evaluating subdivision surfaces)

> Because you asked why Python uses the % operator for remainder.

So you ARE implying python has backwards compatibility with C as a
design goal? Otherwise the given answer to this question is
nonsensical.

>
> [...]
>
> > They are bad ideas because they truely do not lead to the execution of
> > different code, but are merely a reordering, mixing statements in with a
> > function declaration. I am proposing no such thing; again, the type(arg)
> > notation I have dropped, and never was meant to have anything to do with
> > function calling; it is a way of supplying an optional type constraint,
> > so in analogy with function annotations, I changed that to arg::type.
> > Again, this has nothing to do with calling functions on arguments.
>
> You have not thought about this carefully enough. Consider what happens
> when this code gets called:
>
> def f(*args): pass
>
> f(a, b, c)
>
> The Python virtual machine (interpreter, if you prefer) must take three
> arguments a, b, c and create a tuple from them. This must happen at
> runtime, because the value of the objects is not known at compile time.
> So at some point between f(a, b, c) being called and the body of f being
> entered, a tuple must be created, and the values of a, b, c must be
> collated into a single tuple.
>
> Now extend this reasoning to your proposal:
>
> def f(args:FOO): pass
>
> At runtime, the supplied arguments must be collated into a FOO, whatever
> FOO happens to be. Hence, the function that creates FOO objects must be
> called before the body of f can be entered. This doesn't happen for free.
> Whether you do it manually, or have the Python interpreter do it, it
> still needs to be done.

Of course the python interpreted needs to do this; and in case non-
builtin types are allowed, the mechanism is going to be through their
constructor. But thats a detail; the syntax doesnt say: 'please call
this constructor for me', any more than **kwargs says 'please call a
dict constructor for me', even though equivalent operations are
obviously 

Re: Verbose and flexible args and kwargs syntax

[Chris Angelico]

On Tue, Dec 13, 2011 at 11:47 PM, Eelco  wrote:
>> def f(*args) *constructs* a tuple, it
>> doesn't perform a type-check.
>
> I am talking about type constraints... A type-check is something
> along the lines of type(args)==list, a runtime thing and something
> completely different. I havnt mentioned the latter at all, explicitly
> or implicitly, as far as im aware.

I'm not sure what you mean by a "type constraint". Here's how I understand such:

float|int foobar; //Declare that the variable 'foobar' is allowed to
hold a float or an int
foobar = 3.2; //Legal.
foobar = 1<<200; //Also legal (a rather large integer value)
foobar = "hello"; //Not legal

Python doesn't have any such thing (at least, not in-built). Any name
may be bound to any value - or if you like, any variable can contain
any type. Same applies to argument passing - you can even take an
unbound method and call it with some completely different type of
object as its first parameter. (I can't think of ANY situation in
which this would not be insanely confusing, tbh.) When you gather a
function's arguments into a tuple, list, or any other such container
object, what you're doing is constructing another object and stuffing
it with references to the original arguments. That involves building a
new object, where otherwise you simply bind the arguments' names to
the original objects directly.

Now, it is perfectly conceivable to have designed Python to _always_
pass tuples around. Instead of a set of arguments, you just always
pass exactly one tuple to a function, and that function figures out
what to do with the args internally. If that's the way the language is
built, then it is the _caller_, not the callee, who builds that tuple;
and we still have the same consideration if we want a list instead.

So suppose you can have a user-defined object type instead of
list/dict. How are you going to write that type's __init__ function?
Somewhere along the way, you need to take a variable number of
arguments and bundle them up into a single one... so somewhere, you
need the interpreter to build it for you. This is going to end up
exactly the same as just accepting the tuple and then passing that to
a constructor, like the list example. Keep things transparent and you
make debugging a LOT easier.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Overriding a global

[Jean-Michel Pichavant]

Steven D'Aprano wrote:

On Tue, 13 Dec 2011 10:54:51 +0100, Jean-Michel Pichavant wrote:

  

Steven D'Aprano wrote:


On Mon, 12 Dec 2011 12:13:33 +0100, Jean-Michel Pichavant wrote:


  

Using the same name for 2 different objects is a bad idea in general.




We have namespaces precisely so you don't need to care about making
names globally unique.



  

I don't get your point, namespaced names are unique, by definition.

foo.aname <> bar.aname



Assuming foo and bar are not names for the same object, there are at 
least three namespaces here: the local namespace, where foo and bar can 
be found, the foo.__dict__ namespace, and the bar.__dict__ namespace.



  

The OP showed a code where there was a confusion between a global name
and a local one. There's no namespace involved. Having a local name
identical to a global one is a bad idea, def.



Of course there are namespaces involved. There is the global namespace, 
and the local namespace. That's how you can have x inside a function 
without it overwriting global x outside of it, because they are different 
namespaces. Which is my point.


When I write this:

x = 1

def spam():
x = 2

def ham():
x = 3

The three x's don't clash because they are in three separate namespaces.

  

I know that, why do I have the feel this is juste a semantic issue ?
Aren't you/I/we confusion namespaces & scopes ?

Anyway, semantic is not what we're interested in here.

writing

x = 1

def spam():
   x = 2


is in general a bad idea. That was my point.

JM



--
http://mail.python.org/mailman/listinfo/python-list

Signature-preserving decorators

[Henrik Faber]

Hi group,

when decorating a method in Python3, by use of the
functools.update_wrapper function, it can be achieved that the docstring
and name of the original function is preseverved.

However, the prototype is lost: When looking into the Python help, I
have lots of entries that look like:

getfoo(*args, **kwargs) -> int

setbar(*args, **kwargs)

As you can imagine, this is really not very self-explanatory. I've seen
a solution which constructs a wrapper's wrapper function using
inspection and eval -- this looks really dirty to me, however. Then
there's the "decorator" external module -- but I'd like to do it with
on-board tools.

Is this possible in Python3 with too much of a hassle?

Best regards,
Joe

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Verbose and flexible args and kwargs syntax

[Eelco]

On 13 dec, 14:14, Chris Angelico  wrote:
> On Tue, Dec 13, 2011 at 11:47 PM, Eelco  wrote:
> >> def f(*args) *constructs* a tuple, it
> >> doesn't perform a type-check.
>
> > I am talking about type constraints... A type-check is something
> > along the lines of type(args)==list, a runtime thing and something
> > completely different. I havnt mentioned the latter at all, explicitly
> > or implicitly, as far as im aware.
>
> I'm not sure what you mean by a "type constraint". Here's how I understand 
> such:
>
> float|int foobar; //Declare that the variable 'foobar' is allowed to
> hold a float or an int
> foobar = 3.2; //Legal.
> foobar = 1<<200; //Also legal (a rather large integer value)
> foobar = "hello"; //Not legal
>
> Python doesn't have any such thing (at least, not in-built).

Agreed on what a type constraint is, and that python does not really
have any, unless one counts the current use of asterikses, which are
infact a limited form of type constrait (*tail is not just any object,
but one holding a list, which modifies the semantics of the assignment
statement 'head,*tail=sequence' from a regular tuple unpacking to a
specific form of the more general collection unpacking syntax);

The idea is to enrich this syntax; to add optional and limited type
constraints to python, specifically to enrich collection packing/
unpacking syntax, but perhaps the concept can be further generalized.


> So suppose you can have a user-defined object type instead of
> list/dict. How are you going to write that type's __init__ function?
> Somewhere along the way, you need to take a variable number of
> arguments and bundle them up into a single one... so somewhere, you
> need the interpreter to build it for you. This is going to end up
> exactly the same as just accepting the tuple and then passing that to
> a constructor, like the list example. Keep things transparent and you
> make debugging a LOT easier.

Agreed; for user defined collection types there would not be a
performance benefit over converting a tuple, since this is exactly
what will happen anyway, but for collection types derived from any of
the builtins, python could optimize away the intermediate and
construct the desired collection type directly from the available
information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: change a file with a context manager

[Andrea Crotti]

On 12/13/2011 10:59 AM, Andrea Crotti wrote:
So I have the following problem, I need something to copy a file to a 
certain position

and restore it after.
So I wrote this simple context manager:

class WithCorrectEasyInstall(object):

def __enter__(self):
import pkg_resources
from shutil import copyfile
easy_install_file = 
pkg_resources.resource_filename('psi.devsonly', 
'windows_easy_install.pth')
self.global_easy_install = 
'c:/python25/Lib/site-packages/easy-install.pth'

# can use mmap, a temporary file or just write to string
self.stored = open(self.global_easy_install).read()
logger.debug("copying the correct easy_install.pth file to the 
global position")

copyfile(easy_install_file, self.global_easy_install)

def __exit__(self, type, value, traceback):
#TODO: make sure it's restored also when quitting in some 
other ways

# restore the old file
open(self.global_easy_install, 'w').write(self.stored)
logger.debug("restoring the old easy_install.pth file")


The problem is that this is not executed for example when the program 
is interrupted

with for example a KeyboardInterrupt.
But that's also an exception, why is it not caught by the context 
manager?


And if there are better way to do what I'm trying to achieve they are 
welcome :)



Alright it was probably a stupid idea to start with.
The problem is that if the easy_install is wrong even the imports in the 
module

will not work, so I can't even start to do something.

Another possible option is to just add to the path everything contained 
in that

correct easy_install.pth file.
Or is there a way to reload the path settings?
--
http://mail.python.org/mailman/listinfo/python-list

Re: Dynamic variable creation from string

[88888 Dihedral]

On Tuesday, December 13, 2011 9:35:52 AM UTC+8, Steven D'Aprano wrote:
> On Mon, 12 Dec 2011 15:45:06 -0800, alex23 wrote:
> 
> > On Dec 12, 10:49 pm, 8 Dihedral 
> > wrote:
> >> This is the way to write an assembler or to roll out a script language
> >> to be included in an app by users.
> > 
> > This is a garbage comment that has absolutely nothing to do with the
> > topic at hand _at all_.
> 
> Please stop responding to the bot.
> 
> 
> 
> -- 
> Steven

Do we need to talk aout auto, extern, static in python?
Of course not for an interpreter?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Fixing the XML batteries

[Serhiy Storchaka]

13.12.11 14:32, Stefan Behnel написав(ла):

I stripped my name from the quoted context because I didn't say this.


I am glad to hear this. ;)


I use xml.dom.minidom for XML canonization and convertion:

Do you mean "canonicalisation"? I.e. C14N? That's not what the code
below is doing, not at all.


No, only converting to certain textual representation. Converting 
entities to text (if possible), converting "'" to '"' for quoting, 
sorting attributes, etc.



How to do this with xml.etree.ElementTree?

In Python 2.7/3.2, ElementTree has support for C14N serialisation, just
pass the option method="c14n".


Thanks, I will try this. But I need 2.6+ compatibility.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Fixing the XML batteries

[Stefan Behnel]

Serhiy Storchaka, 13.12.2011 15:27:

13.12.11 14:32, Stefan Behnel написав(ла):

I stripped my name from the quoted context because I didn't say this.


I am glad to hear this. ;)


It matches my opinion though.



I use xml.dom.minidom for XML canonization and convertion:

Do you mean "canonicalisation"? I.e. C14N? That's not what the code
below is doing, not at all.


No, only converting to certain textual representation. Converting entities
to text (if possible), converting "'" to '"' for quoting, sorting
attributes, etc.


Yes, that's what C14N is there for, typically used for cryptography, 
hashing, etc. However, MiniDOM doesn't implement that standard, so you're 
on your own here.




How to do this with xml.etree.ElementTree?

In Python 2.7/3.2, ElementTree has support for C14N serialisation, just
pass the option method="c14n".


Thanks, I will try this. But I need 2.6+ compatibility.


The ET module is actually quite short (<1700 lines), so you can just copy 
the Py2.7 version into your sources and optionally import it on older 
Python releases. Since you only seem to depend on the serialiser (which is 
worth using anyway because it is much faster in the Py2.7 version), older 
platform versions of cET should also work just fine with that module copy, 
so you can basically just import everything from xml.etree.cElementTree and 
use the ElementTree class and the tostring() function from your own local 
version if the platform version is too old.


Note that ET is also still available as a separately installable package, 
may or may not be simpler to use for you.


Stefan

--
http://mail.python.org/mailman/listinfo/python-list

logging issues

[Andrea Crotti]

I think is simple but I can't get it to work as I wish.
Suppose I have a big application, my idea is that the running
script sets a global logging level and then all the imported modules
would act consequently.

In my codebase, however, unless I set the level for each of the loggers
I don't get the debug messages, not really sure why yet.

To check if I understood,
logging.getLogger() returns the root logger, and every other logger
should inherit its settings, is that correct?

What happens if there is another logging.getLogger() somewhere else
in the code after the initialization? Does that become the root logger
overriding the old one?

The example below instead works as expected, so maybe is something
with my codebase...

# m1.py
import logging

logging.basicConfig()
# if no name is specified return the root logger, that's how it works
logger = logging.getLogger()
logger.setLevel(logging.DEBUG)


class ToLogEvents(object):
def __init__(self):
self.logger = logging.getLogger('ToLogEvents')

def important(self):
self.logger.warning("This is an important message")
self.logger.debug("debug message")


if __name__ == '__main__':
logger.debug("debug from m1")
from m2 import logging_function
logging_function()
t = ToLogEvents()
t.important()


# m2.py
import logging

logger = logging.getLogger(__name__)


def logging_function():
logger.debug("debug message")
logger.info("info message")

--
http://mail.python.org/mailman/listinfo/python-list

Using methodcaller in a list sort - any examples anywhere?

[tinnews]

I want to sort a list of 'things' (they're fairly complex objects) by
the contents of one of the fields I can extract from the 'things'
using a Python function.

So I have a list L which is a list of objects of some sort.  I can
output the contents of a field in the list as follows:-

for k in L:
print k.get_property('family-name')

How can I sort the list first?  As I said it seems like a methodcaller
is the answer but I don't see how.  I want to sort the list of objects
not just produce a sorted list of names.

-- 
Chris Green
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: logging issues

[Jean-Michel Pichavant]

Andrea Crotti wrote:

I think is simple but I can't get it to work as I wish.
Suppose I have a big application, my idea is that the running
script sets a global logging level and then all the imported modules
would act consequently.

In my codebase, however, unless I set the level for each of the loggers
I don't get the debug messages, not really sure why yet.

To check if I understood,
logging.getLogger() returns the root logger, and every other logger
should inherit its settings, is that correct?
Not really, if you use the classic way, your subloggers should be 
created an never configured. Their default behavior is to raise any log 
event to its parent. That way, all event logs end up being handled by 
the root logger.


What happens if there is another logging.getLogger() somewhere else
in the code after the initialization? Does that become the root logger
overriding the old one?
multiple calls to logging.getLogger() always return the very same root 
logger (the root one). Loggers are static objects handled by the loggin 
module, once a logger is created (identified by its name, the root 
logger's name is "") it will never be destroyed. Multiple call the 
getLogger(name) with the same name returns the same object.


Logger names are of the form "grandparent.parent.child"


The example below instead works as expected, so maybe is something
with my codebase...

your codebase which is ???

[snip some working code]

As a general advices
- try to never configure a child logger, you should only need to create 
one whithout setting its level nor its handler. A logger is responsible 
of raising log events, not handling them. The root logger is supposed to 
handle them.
- Configure only the root logger and do it in the main function, and 
only there. Configuring means calling basicConfig, setting the level, 
adding a handler etc... everything except the creation.


JM
--
http://mail.python.org/mailman/listinfo/python-list

Re: Using methodcaller in a list sort - any examples anywhere?

[Peter Otten]

tinn...@isbd.co.uk wrote:

> I want to sort a list of 'things' (they're fairly complex objects) by
> the contents of one of the fields I can extract from the 'things'
> using a Python function.
> 
> So I have a list L which is a list of objects of some sort.  I can
> output the contents of a field in the list as follows:-
> 
> for k in L:
> print k.get_property('family-name')
> 
> How can I sort the list first?  As I said it seems like a methodcaller
> is the answer but I don't see how.  I want to sort the list of objects
> not just produce a sorted list of names.

The most obvious way is to use a custom function

def get_family_name(obj):
return obj.get_property("family-name")
L.sort(key=get_family_name)

However, since you already know about methodcaller

""" 
class methodcaller(builtins.object)
 |  methodcaller(name, ...) --> methodcaller object
 |
 |  Return a callable object that calls the given method on its operand.
 |  After, f = methodcaller('name'), the call f(r) returns r.name().
 |  After, g = methodcaller('name', 'date', foo=1), the call g(r) returns
 |  r.name('date', foo=1).


L.sort(key=methodcaller("get_property", "family-name"))

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: logging issues

[Andrea Crotti]

On 12/13/2011 04:11 PM, Jean-Michel Pichavant wrote:
Not really, if you use the classic way, your subloggers should be 
created an never configured. Their default behavior is to raise any 
log event to its parent. That way, all event logs end up being handled 
by the root logger.




Ok thanks now it's more clear.your codebase which is ???


[snip some working code]

As a general advices
- try to never configure a child logger, you should only need to 
create one whithout setting its level nor its handler. A logger is 
responsible of raising log events, not handling them. The root logger 
is supposed to handle them.
- Configure only the root logger and do it in the main function, and 
only there. Configuring means calling basicConfig, setting the level, 
adding a handler etc... everything except the creation.


JM


It turned out that I was calling
logger = logging.getLogger()

In other modules too, and then apparently the logging level was
modified automatically to the default one, is that possible?

changing with
logger = logging.getLogger(__name__) everywhere solved my problems..
--
http://mail.python.org/mailman/listinfo/python-list

boolean from a function

[Andrea Crotti]

I'm not sure for how long I had this bug, and I could not understand the 
problem.


I had a function which would return a boolean

def func_bool():
if x:
return True
else: return False

Now somewhere else I had

if func_bool:
# do something

I could not quite understand why it was always true, until I finally noticed
that the () were missing.
Is there some tool to avoid these stupid mistakes? (pylint doesn't warn 
me on that)
I don't think I will ever (or almost) have to use a function as a 
boolean, instead of its return value...

--
http://mail.python.org/mailman/listinfo/python-list

Re: Getting the current directory path and the path where python script is saved

[Neil Cerutti]

On 2011-12-13, gialloporpora  wrote:
> Dear all,
> I would like to create a little script to rename my files, I think to 
> use argparse module to create it.
> I would like to know how to obtain the path where script is executed and 
> the path where the file script is stored.
>
> For example, if I save my script in c:\python27 and I put the
> directory in %path% I can execute it from any folder, I would
> like to get the two directory path.

Current working directory is available with os.getcwd()

The location of the script you are running may be available as
os.path.basename(sys.argv[0]).

-- 
Neil Cerutti
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Signature-preserving decorators

[Ian Kelly]

On Tue, Dec 13, 2011 at 6:36 AM, Henrik Faber  wrote:
> Hi group,
>
> when decorating a method in Python3, by use of the
> functools.update_wrapper function, it can be achieved that the docstring
> and name of the original function is preseverved.
>
> However, the prototype is lost: When looking into the Python help, I
> have lots of entries that look like:
>
> getfoo(*args, **kwargs) -> int
>
> setbar(*args, **kwargs)
>
> As you can imagine, this is really not very self-explanatory. I've seen
> a solution which constructs a wrapper's wrapper function using
> inspection and eval -- this looks really dirty to me, however. Then
> there's the "decorator" external module -- but I'd like to do it with
> on-board tools.
>
> Is this possible in Python3 with too much of a hassle?

The decorator module also uses inspection and eval to do it, by the
way.  Currently there is no pretty way to do it that I know of, but
see PEP 362:

http://www.python.org/dev/peps/pep-0362/

That PEP has unfortunately been in the "Open" state for quite a long
time now, but it seems to me that a lot of people are starting to get
interested in this issue, so maybe it will start to pick up some steam
before too long.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Getting the current directory path and the path where python script is saved

[Thomas Bach]

gialloporpora  writes:

> I would like to know how to obtain the path where script is executed
> and the path where the file script is stored.

Does this help:

In [16]: import os

In [19]: os.getcwd()
Out[19]: '/home/vince'

In [21]: os.__file__
Out[21]: '/home/vince/src/pyramid_install/lib/python2.7/os.pyc'

regards
-- 
http://mail.python.org/mailman/listinfo/python-list

icmp and raw sockets in python

[Sagy Drucker]

hello
i am relatively new to python, so please be considerate...

i'm implementing a server and a client via raw_sockets.
i have the necessary privileges.

now, the server i defined so:
host = socket.gethostbyname(socket.gethostname())
address = (host, 4)
sockSer = socket.socket(socket.AF_INET, socket.SOCK_RAW,
socket.IPPROTO_ICMP)
sockSer.bind(address)
sockSer.ioctl(socket.SIO_RCVALL, socket.RCVALL_ON)
packet, addr = sockSer .recvfrom(4096)   # wait for packet from client

Q1) why can't i simply type: hosts = 'localhost'.
if i do so, it doesn't allow me to write the line:
sockSer.ioctl(socket.SIO_RCVALL, socket.RCVALL_ON).
only when doing gethostbyname(socket.gethostname()) i get
192.168.1.101
and then it works.

in a different class:
the client socket:
host = socket.gethostbyname(socket.gethostname())
address = (host, 4)
sockCli = socket.socket(socket.AF_INET, socket.SOCK_RAW,
socket.IPPROTO_ICMP)

Q2) do i also need to type: sockCli.ioctl(socket.SIO_RCVALL,
socket.RCVALL_ON)
or maybe sockCli.connect(address)
for the client socket?

now, the problems arise when i do the following:
1) send a packet from client to socket:
header=...
payload='a'
sockCli.sendto(header + payload, address)

2) receive packet in server and send file to client:
while(true):
data, addr = sockSer.recvfrom(4096)
header2=...
payload2='b'
sockSer.sendto(header2 + payload2, addr)

now, my important question is:
Q3) the server sent only 1 packet to client, with payload 'b'.
what happens is, my client actually receives 2 packets in the while
loop:
first packet is what the client itself sent to server, and the other
packet is from the client got from the server.
hence my output is 'ab' instead of simply 'b'
why is this happening???

NOTE: i didn't type the entire code, but i think my
syntax,parsing,header composition etc.. are correct.
is there an obvious problem in my code?
if necessary i'll upload the entire code.

thanks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: logging issues

[Andrea Crotti]

And by the way suppose I have a script which takes as input the log
level and a list of possible filters.
In another file I have a couple of functions as below which are called
in that order.

Is that supposed to work?
In theory I'm getting both times the same logger.
The set_verbosity seems to do its job, the second is also
called and the filters are added but I don't see the output
formatted as it should..
Maybe I can only set it up once?

def set_verbosity(log_level):
"""Set the desired log level
"""
root_logger = logging.getLogger()
root_logger.setLevel(LOG_LEVELS[log_level])

def setup_logging(to_filter):
root_logger = logging.getLogger()
hdlr = logging.StreamHandler()
formatter = logging.Formatter('%(asctime)s %(levelname)s %(message)s')
hdlr.setFormatter(formatter)
# a list of regular expressions to filter out?
if to_filter:
for f in to_filter:
logger.debug("adding filter for name %s" % f)
filt = logging.Filter(f)
hdlr.addFilter(filt)

root_logger.addHandler(hdlr)

--
http://mail.python.org/mailman/listinfo/python-list

Re: Using methodcaller in a list sort - any examples anywhere?

[tinnews]

Peter Otten <__pete...@web.de> wrote:
> tinn...@isbd.co.uk wrote:
> 
> > I want to sort a list of 'things' (they're fairly complex objects) by
> > the contents of one of the fields I can extract from the 'things'
> > using a Python function.
> > 
> > So I have a list L which is a list of objects of some sort.  I can
> > output the contents of a field in the list as follows:-
> > 
> > for k in L:
> > print k.get_property('family-name')
> > 
> > How can I sort the list first?  As I said it seems like a methodcaller
> > is the answer but I don't see how.  I want to sort the list of objects
> > not just produce a sorted list of names.
> 
> The most obvious way is to use a custom function
> 
> def get_family_name(obj):
> return obj.get_property("family-name")
> L.sort(key=get_family_name)
> 
> However, since you already know about methodcaller
> 
> """ 
> class methodcaller(builtins.object)
>  |  methodcaller(name, ...) --> methodcaller object
>  |
>  |  Return a callable object that calls the given method on its operand.
>  |  After, f = methodcaller('name'), the call f(r) returns r.name().
>  |  After, g = methodcaller('name', 'date', foo=1), the call g(r) returns
>  |  r.name('date', foo=1).
> 
> 
> L.sort(key=methodcaller("get_property", "family-name"))
> 
OK, thanks, just what I wanted.

-- 
Chris Green
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using methodcaller in a list sort - any examples anywhere?

[Tim Chase]

On 12/13/11 09:48, tinn...@isbd.co.uk wrote:

I want to sort a list of 'things' (they're fairly complex objects) by
the contents of one of the fields I can extract from the 'things'
using a Python function.

So I have a list L which is a list of objects of some sort.  I can
output the contents of a field in the list as follows:-

 for k in L:
 print k.get_property('family-name')

How can I sort the list first?  As I said it seems like a methodcaller
is the answer but I don't see how.  I want to sort the list of objects
not just produce a sorted list of names.


You want either sorted(..., key=...) to sort and return a copy 
(leaving the original unmodified) or .sort(key=...) to sort the 
list in-place:


  class MyObj(object):
def __init__(self, fn): self.fn = fn
def get_property(self, s): return "%s: %s" % (s, self.fn)
def __str__(self): return self.fn
__repr__ = __str__

  source = [
MyObj("Doug"),
MyObj("Carol"),
MyObj("Bill"),
MyObj("Adam"),
]

  print "Unsorted source before:"
  print repr(source)
  print "Using a lambda:"
  print repr(sorted(source,
key=lambda mo: mo.get_property("family-name")))

  print "Using methodcaller:"
  from operator import methodcaller
  print repr(sorted(source,
key=methodcaller("get_property", "family-name")))

  print "Source still unsorted after:"
  print repr(source)
  source.sort(key=lambda mo: mo.get_property("family-name"))
  print "Source now sorted:"
  print repr(source)

yields the following:

  Unsorted source before:
  [Doug, Carol, Bill, Adam]
  Using a lambda:
  [Adam, Bill, Carol, Doug]
  Using methodcaller:
  [Adam, Bill, Carol, Doug]
  Source still unsorted after:
  [Doug, Carol, Bill, Adam]
  Source now sorted:
  [Adam, Bill, Carol, Doug]

I'm partial to the lambda version over the methodcaller version 
unless there's a reason to dynamically get the method-name as a 
string.  But that's just a personal preference.


-tkc



--
http://mail.python.org/mailman/listinfo/python-list

text to html

[prakash jp]

Hi All,

Want to publish a log file as a web page, is there a parser to retain the
format of the text as is and then convert to html. Please provide the
relevant pointers

Thanks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: boolean from a function

[Grant Edwards]

On 2011-12-13, Andrea Crotti  wrote:

> Now somewhere else I had
>
> if func_bool:
>  # do something
>
> I could not quite understand why it was always true, until I finally
> noticed that the () were missing. Is there some tool to avoid these
> stupid mistakes? (pylint doesn't warn me on that) I don't think I
> will ever (or almost) have to use a function as a boolean, instead of
> its return value...

FWIW, I have do use the truth value of a function (rather than it's
return value) when writing code that uses callbacks:

def foo(callback=None):
# do some stuff
if callback:
callback()
# do some more stuff

It probably would be better to use "if callback is not None:", but I
find I usually skip "is not None".

-- 
Grant Edwards   grant.b.edwardsYow! Will it improve my
  at   CASH FLOW?
  gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: text to html

[Pedro Henrique Guedes Souto]

On Tue, Dec 13, 2011 at 3:22 PM, prakash jp  wrote:
>
> Hi All,
>
> Want to publish a log file as a web page, is there a parser to retain the 
> format of the text as is and then convert to html. Please provide the 
> relevant pointers


Hey, You can use this: http://txt2tags.org/

Att;
Pedro Henrique Guedes Souto
[pedro.h.so...@gmail.com]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: boolean from a function

[Duncan Booth]

Andrea Crotti  wrote:

> I'm not sure for how long I had this bug, and I could not understand
> the problem.
> 
> I had a function which would return a boolean
> 
> def func_bool():
>  if x:
>  return True
>  else: return False
> 
> Now somewhere else I had
> 
> if func_bool:
>  # do something
> 
> I could not quite understand why it was always true, until I finally
> noticed that the () were missing.
> Is there some tool to avoid these stupid mistakes? (pylint doesn't
> warn me on that)
> I don't think I will ever (or almost) have to use a function as a 
> boolean, instead of its return value...

For this particular example why don't you just write 'if x: # do 
something'?

More generally rather than having a global function make it a property on 
an object.

class Snark:
def __init__(self, something):
self.boojum = ...

@property
def is_a_bookum(self):
   return self.boojum

hunted = Snark(whatever)


Then you can write:

if hunted.is_a_boojum:
self.vanish_away()

-- 
Duncan Booth http://kupuguy.blogspot.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: text to html

[Grant Edwards]

On 2011-12-13, Pedro Henrique Guedes Souto  wrote:
> On Tue, Dec 13, 2011 at 3:22 PM, prakash jp  wrote:
>
>> Want to publish a log file as a web page, is there a parser to retain
>> the format of the text as is and then convert to html. Please provide
>> the relevant pointers
>
>
> Hey, You can use this:?http://txt2tags.org/

I think thats a bit too likely to interpret stuff in the log messages
as formatting directives.

Two options come to mind:

  1. Don't use HTML.  Return the logfile as-is with Content-Type:
 text/plain.  [That way the user can also save it if needed.]

  2. Escape the file contents using cgi.escape() and then stick the 
 escaped contents inside   tags.  That's not as nice,
 since saving it is no longer a useful option.


-- 
Grant Edwards   grant.b.edwardsYow! Now KEN and BARBIE
  at   are PERMANENTLY ADDICTED to
  gmail.comMIND-ALTERING DRUGS ...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Verbose and flexible args and kwargs syntax

[Ian Kelly]

On Tue, Dec 13, 2011 at 1:44 AM, Eelco  wrote:
> 'for i in llist' is not quite going to fly is it? Thats probably the
> reason noone ever uses that construct; its not a proper sequence type.

Not really a problem, because fortunately Python makes it super-easy
to create custom iterators.

def listiter(llist):
while llist:
head, llist = llist
yield head

And you're done.  If you like, you could also wrap this up in a class
with all the sequence-related magic methods you want, although you
lose the simplicity of the literal syntax by doing so.  If this is
rarely used, it is more likely because custom containers are going to
be less efficient than built-ins, but if you want to do functional
programming and are not overly concerned with the speed of iteration,
this is not a bad way to do it.

> Good point. Copy-on-write semantics could be used, but really one
> should have several linked list types reflecting the underlying
> implementations. I would like to have an immutable singly linked list
> builtin of the standard functional type, which you can only unpack
> from one end and renders these issues moot, plus a builtin doubly
> linked list with copy-on-write or copy-on-unpacking semantics.

Copy-on-write could be implemented with any type.  You don't need a
doubly linked list for that.

> We are not talking black magic here; we are talking about an EXPLICIT
> type constraint provided on the very same line.

An explicit type constraint with very different semantics depending on
what particular type you specify and what particular type you're
unpacking from, as I had understood it before.  Now you seem to be
saying that it would always be a copy, but sharing state with
copy-on-write possible, which is a different situation.

> Well perhaps, but not always knowing the type of your objects at write-
> time is inherent to weakly typed languages; this happens all the time.
> Not knowing the type of the sequence to be unpacked is in a sense an
> asset; I can use this construct in a function, and unpack any sequence
> type in a manner appropriate for it. About the result of the unpacking
> I will know just as much as about the input to it; that they are the
> same type.

Just because the issue is inherent doesn't mean we should contribute
to it.  Knowing that an object is an arbitrary sequence is fine if all
you want to do is iterate and index it.  If you want to do anything
else, then it's important to know the type.  The copy-on-write
suggestion does make the type-matching approach a bit more attractive.
 On the other hand, it's also more fragile (what if the type being
unpacked can't be constructed from an iterable?  For example, a
database cursor), so that approach potentially needs additional
error-handling.

Anyway, the more I think about it, that concern is really more of an
issue for straight copying.  One of my pet peeves is that I prefer
list(x) for copying sequences rather than the more common x[::].  The
latter is fine if all I need is an immutable sequence of uncertain
type to iterate and index over -- but then why did I need to make a
copy?  Unpacking implies different use cases, though, and maybe a good
argument can be made for it to match type.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: boolean from a function

[Ethan Furman]

Andrea Crotti wrote:
I'm not sure for how long I had this bug, and I could not understand the 
problem.


I had a function which would return a boolean

def func_bool():
if x:
return True
else: return False

Now somewhere else I had

if func_bool:
# do something

I could not quite understand why it was always true, until I finally 
noticed that the () were missing.
Is there some tool to avoid these stupid mistakes? (pylint doesn't warn 
me on that)
I don't think I will ever (or almost) have to use a function as a 
boolean, instead of its return value...


Heh, I do believe I've been bitten by that a couple times.

The only defense I'm aware of is good unit tests.

~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list

Re: Fixing the XML batteries

[Serhiy Storchaka]

13.12.11 16:59, Stefan Behnel написав(ла):

It matches my opinion though.


I would be glad to divide your intentions, however ElementTree looks 
less documented than minidom, and is not full replacement. For example, 
I haven't found how to get XML encoding. Also, at use of ElementTree 
instead of minidom the suffix "ns0:" is added to each element. I do not 
see how to _create_ a new element and to write it with  header.


And DOM interface is more habitual for those who works with some other 
languages.



Yes, that's what C14N is there for, typically used for cryptography,
hashing, etc. However, MiniDOM doesn't implement that standard, so
you're on your own here.


MiniDOM quite suited me earlier in this respect. I will pass to C14N as 
soon as I will be can.



The ET module is actually quite short (<1700 lines), so you can just
copy the Py2.7 version into your sources and optionally import it on
older Python releases. Since you only seem to depend on the serialiser
(which is worth using anyway because it is much faster in the Py2.7
version), older platform versions of cET should also work just fine with
that module copy, so you can basically just import everything from
xml.etree.cElementTree and use the ElementTree class and the tostring()
function from your own local version if the platform version is too old.

Note that ET is also still available as a separately installable
package, may or may not be simpler to use for you.


I thank, it is too bulky for my small scripts (which I have decided to 
update from Python 2.3 or 2.4 to modern Python 3 and 2.6+). I will 
better postpone high-grade migration for half-year or year while the 
Python 2.7 and 3.2 won't appear in stable versions of popular distributives.


I thank you for ET, it really is more convenient at some applications 
(especially at work with the text in elements).


--
http://mail.python.org/mailman/listinfo/python-list

Re: Overriding a global

[Joshua Landau]

On 13 December 2011 13:30, Jean-Michel Pichavant wrote:
>
> writing
>
> x = 1
>
> def spam():
>   x = 2
>
> is in general a bad idea. That was my point.


Why? I have a few (probably wrong) guesses.

Because you expect it to be the same every time you use it?
Well, then this should be "in general a bad idea":
 x = 1; print(x); x = 2; print(x)
Even though it makes total sense to me.

Is it because it's used to different purpose between similarly-looking
functions?
This looks fine, though:
def func1(): x=1; print(x)
def func2(): x=2; print(x)

Is it because it looks like a reassignment of the more global x?
I don't have an example here but, simply put, I don't believe this. We can
use "id" as our own local variable without thinking that we're tampering
with "__builtins__.id". I don't see it as much of a leap from builtin to
global (except that you **can** do "dir = 1; del dir; dir" without error).

That said, I'm sorta' just guessing the reason you might think it's a bad
idea.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Verbose and flexible args and kwargs syntax

[Cameron Simpson]

On 13Dec2011 00:30, Eelco  wrote:
| On Dec 13, 1:27 am, alex23  wrote:
| > On Dec 13, 3:12 am, Eelco  wrote:
| > > But to relate it to the topic of this thread: no, the syntax does not
| > > allow one to select the type of the resulting sequence. It always
| > > constructs a list.
| >
| > So by this argument, _every_ function that returns a list should take
| > an optional argument to specify an alternative form of sequence.
| >
| > What, exactly, is so onerous about coercing your list to _whatever_
| > type you want? You know, like everybody else has been.
| >
| > What does this _gain_ you other than one less line of code?
| 
| 1) Turning two lines of code into a single more readable one is
| nothing to scoff at
| 2) After-the-fact conversion is O(n), getting the view you want right
| away is O(1)

Regarding (2), it has already cost you O(n) to get there. So your O(1)
is a little ingenuous.
-- 
Cameron Simpson  DoD#743
http://www.cskk.ezoshosting.com/cs/

I'm a volunteer EMT-I on our local ambulance service; one of our Paramedics
calls squid style motorcycle accidents "ZoomSplats", as in "we had a good
ZoomSplat the other night". ;-)
- Scott 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Overriding a global

[Ian Kelly]

On Tue, Dec 13, 2011 at 1:34 AM, Joshua Landau
 wrote:
>> No, there is another difference, the reason for rebinding the name.
>> In a subclass, you would rebind a class attribute because that
>> particular attribute, which you need to change, is used and expected
>> by external code, either in the base class or in code that uses its
>> API (or both).  Local variables in functions, on the other hand, are
>> not externally visible, so there is no need to do this in order to
>> conform to the expectations of external code.  All it does in that
>> case is to sow potential confusion.
>>
> So you're saying you should never extend methods or attributes that
> aren't meant to be used as part of of the API? Because I can claim
> guilty on this point.

No, I'm only saying that replacing attributes in subclasses is
accepted because it is necessary due to external dependencies, and
that local variables in functions don't have that excuse.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Fixing the XML batteries

[Stefan Behnel]

Serhiy Storchaka, 13.12.2011 19:57:

13.12.11 16:59, Stefan Behnel написав(ла):

It matches my opinion though.


I would be glad to divide your intentions, however ElementTree looks less
documented than minidom


It's certainly a lot smaller, which makes its API easier to learn and remember.



and is not full replacement.


It's good enough for a surprisingly large part of all XML processing needs, 
and if you need more, there's lxml for that.




For example, I  haven't found how to get XML encoding.


True - lxml provides it, but plain ET doesn't. However, I can't think of 
any major use cases where you'd care about the encoding of the original 
input file. Just use what suites your needs on the way back out. UTF-8 will 
usually do just fine.




Also, at use of ElementTree instead
of minidom the suffix "ns0:" is added to each element.


That's a "prefix", not a suffix. And since prefixes are basically useless 
for XML processing, it isn't commonly a problem whether they are called 
'nsXY' or 'abcdefg'. It's the parser's duty to handle them for you.




I do not see how to _create_ a new element


element = Element('tagname')



and to write it with  header.


That's called a "declaration". You can get it with, e.g.,

ElementTree(element).write(encoding='utf8')

By default, ET doesn't write it unless it can put useful information into 
it. (Note that the XML spec makes the declaration optional for XML 1.0 
serialisation as UTF-8.)




And DOM interface is more habitual for those who works with some other
languages.


Not really. DOM is also considered unwieldy in many other languages. Even 
in a language as unwieldy as Java it's being frowned upon these days. In 
JavaScript, it has basically been replaced by jQuery, and many other 
languages also have substantially more "natural" ways to deal with XML than 
the DOM.


It's true, though, that ElementTree isn't a widely known interface outside 
of the Python world.




Yes, that's what C14N is there for, typically used for cryptography,
hashing, etc. However, MiniDOM doesn't implement that standard, so
you're on your own here.


MiniDOM quite suited me earlier in this respect. I will pass to C14N as
soon as I will be can.


The ET module is actually quite short (<1700 lines), so you can just
copy the Py2.7 version into your sources and optionally import it on
older Python releases. Since you only seem to depend on the serialiser
(which is worth using anyway because it is much faster in the Py2.7
version), older platform versions of cET should also work just fine with
that module copy, so you can basically just import everything from
xml.etree.cElementTree and use the ElementTree class and the tostring()
function from your own local version if the platform version is too old.

Note that ET is also still available as a separately installable
package, may or may not be simpler to use for you.


I thank, it is too bulky for my small scripts (which I have decided to
update from Python 2.3 or 2.4 to modern Python 3 and 2.6+). I will better
postpone high-grade migration for half-year or year while the Python 2.7
and 3.2 won't appear in stable versions of popular distributives.


In case you are only dealing with small in-house scripts, I'd suggest 
installing ET 1.3 (or, even better, lxml) on the machines where you want to 
use it. Then you no longer have to care about those dependencies.




I thank you for ET, it really is more convenient at some applications
(especially at work with the text in elements).


Careful. ;) I'm just the author of lxml, not of ET. That would be Fredrik 
Lundh.


Stefan

--
http://mail.python.org/mailman/listinfo/python-list

Re: Overriding a global

[Joshua Landau]

On 13 December 2011 19:34, Ian Kelly  wrote:

> On Tue, Dec 13, 2011 at 1:34 AM, Joshua Landau
>  wrote:
> >> No, there is another difference, the reason for rebinding the name.
> >> In a subclass, you would rebind a class attribute because that
> >> particular attribute, which you need to change, is used and expected
> >> by external code, either in the base class or in code that uses its
> >> API (or both).  Local variables in functions, on the other hand, are
> >> not externally visible, so there is no need to do this in order to
> >> conform to the expectations of external code.  All it does in that
> >> case is to sow potential confusion.
> >>
> > So you're saying you should never extend methods or attributes that
> > aren't meant to be used as part of of the API? Because I can claim
> > guilty on this point.
>
> No, I'm only saying that replacing attributes in subclasses is
> accepted because it is necessary due to external dependencies, and
> that local variables in functions don't have that excuse.
>

But they aren't needed due to external dependencies if they're
implementation-specific and not part of the API, no?
-- 
http://mail.python.org/mailman/listinfo/python-list

pyside dynamic buttons

[Richard]

Hi,

We are making a screen with data driven buttons. I can add buttons but
can't redraw the buttons for new values. The buttuns are placed in a
frame.
I draw the buttons on the screen in a for loop:

def drawS1Butons(self):
n=0
for self.S1 in self.Org.getVpuChilds(self.Focus):
self.S1.button = QtGui.QPushButton(self.frame_2)# Add
method to the button class !?!?
self.S1.button.setGeometry(QtCore.QRect(80, n*30, 161,
23))
self.S1.button.setObjectName(self.S1.name)
 
self.S1.button.setText(QtGui.QApplication.translate("MainWindow",
self.S1.name, None, QtGui.QApplication.UnicodeUTF8))
n=n+1


How can I delete buttons?

Thanks,
Richard
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Fixing the XML batteries

[ru...@yahoo.com]

On Dec 13, 5:32 am, Stefan Behnel  wrote:
...
> In Python 2.7/3.2, ElementTree has support for C14N serialisation, just
> pass the option method="c14n".

Where in the Python docs can one find information about this?

[previous post disappeared, sorry if I double posted or replied to
author inadvertently.]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Overriding a global

[Ian Kelly]

On Tue, Dec 13, 2011 at 12:43 PM, Joshua Landau
 wrote:
> On 13 December 2011 19:34, Ian Kelly  wrote:
>>
>> On Tue, Dec 13, 2011 at 1:34 AM, Joshua Landau
>>  wrote:
>> >> No, there is another difference, the reason for rebinding the name.
>> >> In a subclass, you would rebind a class attribute because that
>> >> particular attribute, which you need to change, is used and expected
>> >> by external code, either in the base class or in code that uses its
>> >> API (or both).  Local variables in functions, on the other hand, are
>> >> not externally visible, so there is no need to do this in order to
>> >> conform to the expectations of external code.  All it does in that
>> >> case is to sow potential confusion.
>> >>
>> > So you're saying you should never extend methods or attributes that
>> > aren't meant to be used as part of of the API? Because I can claim
>> > guilty on this point.
>>
>> No, I'm only saying that replacing attributes in subclasses is
>> accepted because it is necessary due to external dependencies, and
>> that local variables in functions don't have that excuse.
>
>
> But they aren't needed due to external dependencies if they're
> implementation-specific and not part of the API, no?

By "external dependencies" I mean anything that's not specifically
part of the subclass.  This includes the base class.  If they're not
part of the API, then the base class presumably uses them for
something, and by replacing them, you change the behavior of that base
functionality.  That's an external dependency.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Fixing the XML batteries

[ru...@yahoo.com]

On Dec 13, 5:32 am, Stefan Behnel  wrote:
...
> In Python 2.7/3.2, ElementTree has support for C14N serialisation, just
> pass the option method="c14n".

Where does one find information in the Python documentation about
this?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Fixing the XML batteries

[Stefan Behnel]

ru...@yahoo.com, 13.12.2011 20:37:

On Dec 13, 5:32 am, Stefan Behnel wrote:

In Python 2.7/3.2, ElementTree has support for C14N serialisation, just
pass the option method="c14n".


Where does one find information in the Python documentation about
this?


Hmm, interesting. I though it had, but now when I click on the stdlib doc 
link to read the module source (hint, hint), I can see that it only has the 
hooks. The C14N support module of ET 1.3 was not integrated into the 
stdlib. Sorry for not verifying this earlier.


So you actually need the external package for C14N support. See here:

http://effbot.org/zone/elementtree-13-intro.htm

http://hg.effbot.org/et-2009-provolone/src/tip/elementtree/elementtree/ElementC14N.py

Just to emphasize this once again: it's not more than a single module that 
you can copy into your own code as a fallback import, or deploy in your 
local installations.


Stefan

--
http://mail.python.org/mailman/listinfo/python-list

Re: Verbose and flexible args and kwargs syntax

[Eelco]

On Dec 13, 8:11 pm, Cameron Simpson  wrote:
> On 13Dec2011 00:30, Eelco  wrote:
> | On Dec 13, 1:27 am, alex23  wrote:
> | > On Dec 13, 3:12 am, Eelco  wrote:
> | > > But to relate it to the topic of this thread: no, the syntax does not
> | > > allow one to select the type of the resulting sequence. It always
> | > > constructs a list.
> | >
> | > So by this argument, _every_ function that returns a list should take
> | > an optional argument to specify an alternative form of sequence.
> | >
> | > What, exactly, is so onerous about coercing your list to _whatever_
> | > type you want? You know, like everybody else has been.
> | >
> | > What does this _gain_ you other than one less line of code?
> |
> | 1) Turning two lines of code into a single more readable one is
> | nothing to scoff at
> | 2) After-the-fact conversion is O(n), getting the view you want right
> | away is O(1)
>
> Regarding (2), it has already cost you O(n) to get there. So your O(1)
> is a little ingenuous.

Well, yes, but if one takes a given sequence as input (at least O(n)
complexity to obtain it in the first place, indeed), and then wants
to, say, recursively unwind it, the cost of the total operation is
O(n) versus O(n^2)

And besides, O(n) < 2*O(n); perhaps of lesser concern than different
orders, but still.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Overriding a global

[Joshua Landau]

On 13 December 2011 19:54, Ian Kelly  wrote:

> On Tue, Dec 13, 2011 at 12:43 PM, Joshua Landau
>  wrote:
> > On 13 December 2011 19:34, Ian Kelly  wrote:
> >>
> >> On Tue, Dec 13, 2011 at 1:34 AM, Joshua Landau
> >>  wrote:
> >> >> No, there is another difference, the reason for rebinding the name.
> >> >> In a subclass, you would rebind a class attribute because that
> >> >> particular attribute, which you need to change, is used and expected
> >> >> by external code, either in the base class or in code that uses its
> >> >> API (or both).  Local variables in functions, on the other hand, are
> >> >> not externally visible, so there is no need to do this in order to
> >> >> conform to the expectations of external code.  All it does in that
> >> >> case is to sow potential confusion.
> >> >>
> >> > So you're saying you should never extend methods or attributes that
> >> > aren't meant to be used as part of of the API? Because I can claim
> >> > guilty on this point.
> >>
> >> No, I'm only saying that replacing attributes in subclasses is
> >> accepted because it is necessary due to external dependencies, and
> >> that local variables in functions don't have that excuse.
> >
> >
> > But they aren't needed due to external dependencies if they're
> > implementation-specific and not part of the API, no?
>
> By "external dependencies" I mean anything that's not specifically
> part of the subclass.  This includes the base class.  If they're not
> part of the API, then the base class presumably uses them for
> something, and by replacing them, you change the behavior of that base
> functionality.  That's an external dependency.
>

Touché. On this point, I yield.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Verbose and flexible args and kwargs syntax

[Eelco]

On Dec 13, 7:15 pm, Ian Kelly  wrote:
> On Tue, Dec 13, 2011 at 1:44 AM, Eelco  wrote:
> > 'for i in llist' is not quite going to fly is it? Thats probably the
> > reason noone ever uses that construct; its not a proper sequence type.
>
> Not really a problem, because fortunately Python makes it super-easy
> to create custom iterators.
>
> def listiter(llist):
>     while llist:
>         head, llist = llist
>         yield head
>
> And you're done.  If you like, you could also wrap this up in a class
> with all the sequence-related magic methods you want, although you
> lose the simplicity of the literal syntax by doing so.  If this is
> rarely used, it is more likely because custom containers are going to
> be less efficient than built-ins, but if you want to do functional
> programming and are not overly concerned with the speed of iteration,
> this is not a bad way to do it.

Fair enough. Still, I dont readily see myself using the construct, and
I do feel myself longing for something like that to be included as a
builtin collection type. Im not sure why python is so stingy with the
collections it provides.

> > Good point. Copy-on-write semantics could be used, but really one
> > should have several linked list types reflecting the underlying
> > implementations. I would like to have an immutable singly linked list
> > builtin of the standard functional type, which you can only unpack
> > from one end and renders these issues moot, plus a builtin doubly
> > linked list with copy-on-write or copy-on-unpacking semantics.
>
> Copy-on-write could be implemented with any type.  You don't need a
> doubly linked list for that.

True

> > We are not talking black magic here; we are talking about an EXPLICIT
> > type constraint provided on the very same line.
>
> An explicit type constraint with very different semantics depending on
> what particular type you specify and what particular type you're
> unpacking from, as I had understood it before.  Now you seem to be
> saying that it would always be a copy, but sharing state with
> copy-on-write possible, which is a different situation.

Yes, I think consistent semantics over all sequence types is very
important. Although, returning a view for immutable collections like
tuples and 'functional lists' (for lack of a better term), and always
returning a copy for mutable container types (lists and doubly-linked-
lists / deques) is not so bad either, imo. Just one extra simple rule
that is clear and obvious enough.

> > Well perhaps, but not always knowing the type of your objects at write-
> > time is inherent to weakly typed languages; this happens all the time.
> > Not knowing the type of the sequence to be unpacked is in a sense an
> > asset; I can use this construct in a function, and unpack any sequence
> > type in a manner appropriate for it. About the result of the unpacking
> > I will know just as much as about the input to it; that they are the
> > same type.
>
> Just because the issue is inherent doesn't mean we should contribute
> to it.

How are we contributing to it? If we dont know the type of the RHS, we
dont know the type of the LHS either, but its not like we lost any
information. If we do know the type of the RHS, then we do know the
type of the LHS as well; its conserved.

> Anyway, the more I think about it, that concern is really more of an
> issue for straight copying.  One of my pet peeves is that I prefer
> list(x) for copying sequences rather than the more common x[::].  The
> latter is fine if all I need is an immutable sequence of uncertain
> type to iterate and index over -- but then why did I need to make a
> copy?  Unpacking implies different use cases, though, and maybe a good
> argument can be made for it to match type.

Thanks for the constructive feedback; something to think about.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Fixing the XML batteries

[ru...@yahoo.com]

On Dec 13, 1:21 pm, Stefan Behnel  wrote:
> ru...@yahoo.com, 13.12.2011 20:37:
>
> > On Dec 13, 5:32 am, Stefan Behnel wrote:
> >> In Python 2.7/3.2, ElementTree has support for C14N serialisation, just
> >> pass the option method="c14n".
>
> > Where does one find information in the Python documentation about
> > this?
>
> Hmm, interesting. I though it had, but now when I click on the stdlib doc
> link to read the module source (hint, hint),

I realize the source is available (having had to use it way too
many time in the past, not just with ET), but that does not justify
omission from the docs.  However the point is moot since (as you
say) it seems the Python-distributed ET doesn't contain the c14n
feature.

> I can see that it only has the
> hooks. The C14N support module of ET 1.3 was not integrated into the
> stdlib. Sorry for not verifying this earlier.
>
> So you actually need the external package for C14N support. See here:
>
> http://effbot.org/zone/elementtree-13-intro.htm
>
> http://hg.effbot.org/et-2009-provolone/src/tip/elementtree/elementtre...
>
> Just to emphasize this once again: it's not more than a single module that
> you can copy into your own code as a fallback import, or deploy in your
> local installations.

Right, but many times I try to avoid external dependencies when
feasible.
Thanks for the clarifications.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: change a file with a context manager

[Terry Reedy]

On 12/13/2011 9:21 AM, Andrea Crotti wrote:


Another possible option is to just add to the path everything contained
in that
correct easy_install.pth file.
Or is there a way to reload the path settings?


If you are talking about sys.path, you can certainly copy, mutate or 
replace, and restore sys.path. The details depend on whether you mutate 
or replace the original.


--
Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

Re: icmp and raw sockets in python

[Martin P. Hellwig]

On 13/12/2011 16:50, Sagy Drucker wrote:

hello

Hi

i am relatively new to python, so please be considerate...
As I am only responding to one of your questions, perhaps it would be 
best if you don't get any other more helpful replies to split your 
questions up and post them separately.


i'm implementing a server and a client via raw_sockets.
i have the necessary privileges.

now, the server i defined so:
host = socket.gethostbyname(socket.gethostname())
address = (host, 4)
sockSer = socket.socket(socket.AF_INET, socket.SOCK_RAW,
socket.IPPROTO_ICMP)
sockSer.bind(address)
sockSer.ioctl(socket.SIO_RCVALL, socket.RCVALL_ON)
packet, addr = sockSer .recvfrom(4096)   # wait for packet from client

Q1) why can't i simply type: hosts = 'localhost'.
if i do so, it doesn't allow me to write the line:
sockSer.ioctl(socket.SIO_RCVALL, socket.RCVALL_ON).
only when doing gethostbyname(socket.gethostname()) i get
192.168.1.101
and then it works.



Well localhost should resolve to 127.0.0.1/8 which is attached to the 
loopback interface, my gut feeling is that this interface has a 
particular set of restrictions which you are encountering.

Sorry I can't be more helpful.

--
mph
--
http://mail.python.org/mailman/listinfo/python-list

xml, minidom, ElementTree

[Ethan Furman]

In the near future I will need to parse and rewrite parts of a xml files
created by a third-party program (PrintShopMail, for the curious).
It contains both binary and textual data.

There has been some strong debate about the merits of minidom vs 
ElementTree.


Recommendations?

~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list

Re: boolean from a function

[Steven D'Aprano]

On Tue, 13 Dec 2011 16:24:05 +, Andrea Crotti wrote:

> I'm not sure for how long I had this bug, and I could not understand the
> problem.
> 
> I had a function which would return a boolean
> 
> def func_bool():
>  if x:
>  return True
>  else: return False

x is a global? Poor design. But in any case, instead of an explicit 
if...else block, the canonical way to convert an arbitrary object to True/
False is with bool:

def func_bool():
return bool(x)

But you don't need it. See below.


> Now somewhere else I had
> 
> if func_bool:
>  # do something

That would be better written as:

if x:
   ...

since func_bool always refers to x, it is just a needless level of 
indirection that doesn't buy you anything.


> I could not quite understand why it was always true, until I finally
> noticed that the () were missing.
> Is there some tool to avoid these stupid mistakes? (pylint doesn't warn
> me on that)

Can't help you with that.

Have you tried pychecker? I can't help you with that either :)



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pyside dynamic buttons

[Vincent Vande Vyvre]

  
  
Le 13/12/11 20:46, Richard a écrit :

  Hi,

We are making a screen with data driven buttons. I can add buttons but
can't redraw the buttons for new values. The buttuns are placed in a
frame.
I draw the buttons on the screen in a for loop:

def drawS1Butons(self):
n=0
for self.S1 in self.Org.getVpuChilds(self.Focus):
self.S1.button = QtGui.QPushButton(self.frame_2)# Add
method to the button class !?!?
self.S1.button.setGeometry(QtCore.QRect(80, n*30, 161,
23))
self.S1.button.setObjectName(self.S1.name)
 
self.S1.button.setText(QtGui.QApplication.translate("MainWindow",
self.S1.name, None, QtGui.QApplication.UnicodeUTF8))
n=n+1


How can I delete buttons?

Thanks,
Richard


With PyQt:

self.S1.button.deleteLater()
self.S1.button.setParent(None)


Probably the same with pyside.

-- 
  Vincent V.V.
  Oqapy . Qarte+7 . PaQager
  


-- 
http://mail.python.org/mailman/listinfo/python-list

% is not an operator [was Re: Verbose and flexible args and kwargs syntax]

[Steven D'Aprano]

On Mon, 12 Dec 2011 09:29:11 -0800, Eelco wrote:

[quoting Jussi Piitulainen ]
>> They recognize modular arithmetic but for some reason insist that there
>> is no such _binary operation_. But as I said, I don't understand their
>> concern. (Except the related concern about some programming languages,
>> not Python, where the remainder does not behave well with respect to
>> division.)

I've never come across this, and frankly I find it implausible that 
*actual* mathematicians would say that. Likely you are misunderstanding a 
technical argument about remainder being a relation rather than a 
bijunction. The argument would go something like this:

"Remainder is not uniquely defined. For example, the division of -42 by 
-5 can be written as either:

9*-5 + 3 = -42
8*-5 + -2 = -42

so the remainder is either 3 or -2. Hence remainder is not a bijection 
(1:1 function)."

The existence of two potential answers for the remainder is certainly 
correct, but the conclusion that remainder is not a binary operation 
doesn't follow. It is a binary relation. Mathematicians are well able to 
deal with little inconveniences like this, e.g. consider the square root:

10**2 = 100
(-10)**2 = 100
therefore the square root of 100 is ±10

Mathematicians get around this by defining the square root operator √ as 
*only* the principle value of the square root relation, that is, the 
positive root. Hence:

√100 = 10 only

If you want both roots, you have to explicitly ask for them both: ±√100

Similarly, we can sensibly define the remainder or modulus operator to 
consistently return a non-negative remainder, or to do what Python does, 
which is to return a remainder with the same sign as the divisor:

>>> 42 % 5
2
>>> -42 % 5
3

>>> 42 % -5
-3
>>> -42 % -5
-2

There may be practical or logical reasons for preferring one over the 
other, but either choice would make remainder a bijection. One might even 
define two separate functions/operators, one for each behaviour.


> They might not be willing to define it, but as soon as we programmers
> do, well, we did.
> 
> Having studied the contemporary philosophy of mathematics, their concern
> is probably that in their minds, mathematics is whatever some dead guy
> said it was, and they dont know of any dead guy ever talking about a
> modulus operation, so therefore it 'does not exist'.

You've studied the contemporary philosophy of mathematics huh?

How about studying some actual mathematics before making such absurd 
pronouncements on the psychology of mathematicians?




-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: xml, minidom, ElementTree

[Terry Reedy]

On 12/13/2011 6:21 PM, Ethan Furman wrote:

In the near future I will need to parse and rewrite parts of a xml files
created by a third-party program (PrintShopMail, for the curious).
It contains both binary and textual data.

There has been some strong debate about the merits of minidom vs
ElementTree.

Recommendations?


People's reaction to the DOM interface seem quite varied, with a 
majority, perhaps, being negative. I personally would look at both 
enough to understand the basic API model to see where *I* fit.


--
Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

AttributeError in "with" statement (3.2.2)

[Steve Howell]

I'm using Python 3.2.2, and the following program gives me an error
that I don't understand:

class Foo:
  pass

foo = Foo()
foo.name = "Steve"

def add_goodbye_function(obj):
  def goodbye():
print("goodbye " + obj.name)
  obj.goodbye = goodbye

add_goodbye_function(foo)
foo.goodbye() # outputs goodbye Steve
foo.__exit__ = foo.goodbye
foo.__exit__() # outputs goodbye Steve

with foo: # fails with AttributeError:  __exit__
  print("doing stuff")

I am dynamically adding an attribute __exit__ to the variable foo,
which works fine when I call it directly, but it fails when I try to
use foo as the expression in the with statement.  Here is the full
output:

> python3 with.coffee
goodbye Steve
goodbye Steve
Traceback (most recent call last):
  File "with.coffee", line 17, in 
with foo: # fails with AttributeError:
AttributeError: __exit__

What am I doing wrong?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: AttributeError in "with" statement (3.2.2)

[Eric Snow]

On Tue, Dec 13, 2011 at 10:42 PM, Steve Howell  wrote:
> I'm using Python 3.2.2, and the following program gives me an error
> that I don't understand:
>
> class Foo:
>  pass
>
> foo = Foo()
> foo.name = "Steve"
>
> def add_goodbye_function(obj):
>  def goodbye():
>    print("goodbye " + obj.name)
>  obj.goodbye = goodbye
>
> add_goodbye_function(foo)
> foo.goodbye() # outputs goodbye Steve
> foo.__exit__ = foo.goodbye
> foo.__exit__() # outputs goodbye Steve
>
> with foo: # fails with AttributeError:  __exit__
>  print("doing stuff")
>
> I am dynamically adding an attribute __exit__ to the variable foo,
> which works fine when I call it directly, but it fails when I try to
> use foo as the expression in the with statement.  Here is the full
> output:
>
>> python3 with.coffee
> goodbye Steve
> goodbye Steve
> Traceback (most recent call last):
>  File "with.coffee", line 17, in 
>    with foo: # fails with AttributeError:
> AttributeError: __exit__
>
> What am I doing wrong?

That is a tricky one.

As with many of the special methods (start and end with __) in Python,
the underlying mechanism in the interpreter is directly pulling the
function from the class object.  It does not look to the instance
object for the function at any time.  See
http://docs.python.org/reference/datamodel.html#special-method-lookup-for-new-style-classes.

-eric
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: AttributeError in "with" statement (3.2.2)

[Terry Reedy]

On 12/14/2011 1:05 AM, Eric Snow wrote:

On Tue, Dec 13, 2011 at 10:42 PM, Steve Howell  wrote:

I'm using Python 3.2.2, and the following program gives me an error
that I don't understand:

class Foo:
  pass

foo = Foo()
foo.name = "Steve"

def add_goodbye_function(obj):
  def goodbye():
print("goodbye " + obj.name)
  obj.goodbye = goodbye

add_goodbye_function(foo)
foo.goodbye() # outputs goodbye Steve
foo.__exit__ = foo.goodbye
foo.__exit__() # outputs goodbye Steve


foo.goodbye, aliased as foo.__exit__, is a *function* attribute of the 
foo *instance*.



with foo: # fails with AttributeError:  __exit__
  print("doing stuff")

I am dynamically adding an attribute __exit__ to the variable foo,
which works fine when I call it directly, but it fails when I try to
use foo as the expression in the with statement.  Here is the full
output:


python3 with.coffee

goodbye Steve
goodbye Steve
Traceback (most recent call last):
  File "with.coffee", line 17, in
with foo: # fails with AttributeError:
AttributeError: __exit__

What am I doing wrong?


To complement what Eric says below: The with statement is looking for an 
instance *method*, which by definition, is a function attribute of a 
*class* (the class of the context manager) that takes an instance of the 
class as its first parameter. Notice that goodbye does not take any 
parameter. The first parameter is conventionally called 'self', but that 
is not a requirement. That it be there, that it expect to be bound to an 
instance, and that the function be bound to the class are requirements.



That is a tricky one.

As with many of the special methods (start and end with __) in Python,
the underlying mechanism in the interpreter is directly pulling the
function from the class object.  It does not look to the instance
object for the function at any time.  See
http://docs.python.org/reference/datamodel.html#special-method-lookup-for-new-style-classes.


--
Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

Re: xml, minidom, ElementTree

[Stefan Behnel]

Terry Reedy, 14.12.2011 06:01:

On 12/13/2011 6:21 PM, Ethan Furman wrote:

In the near future I will need to parse and rewrite parts of a xml files
created by a third-party program (PrintShopMail, for the curious).
It contains both binary and textual data.

There has been some strong debate about the merits of minidom vs
ElementTree.

Recommendations?


People's reaction to the DOM interface seem quite varied, with a majority,
perhaps, being negative. I personally would look at both enough to
understand the basic API model to see where *I* fit.


The API is one thing, yes, but there's also the fact that MiniDOM doesn't 
scale. If your XML files are of a notable size (a couple of MB), MiniDOM 
may simply not be able to handle them. I collected some numbers in a blog 
post. Note that this is using a recent CPython 3.3 build which has an 
optimised Unicode string implementation, thus yielding lower memory 
requirements on average than Py2.x.


http://blog.behnel.de/index.php?p=197

The memory consumption makes a difference of a factor of 5-10 compared to 
cElementTree, which makes it two orders of magnitude larger than the size 
of the serialised file. You may be able to stuff one such file into memory, 
but you'll quickly get into trouble when you try to do parallel processing 
or otherwise use more than one document at a time.


Stefan

--
http://mail.python.org/mailman/listinfo/python-list