Re: AttributeError in "with" statement (3.2.2)

[Steven D'Aprano]

On Wed, 14 Dec 2011 01:29:13 -0500, Terry Reedy wrote:

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

I'm not sure that is correct... I don't think that there is anything "by 
definition" about where methods live. Particularly not in Python where 
instance methods can be attributes of the instance itself.

>>> class Test(object):
... def method(self):
... print("This method is an attribute of the class.")
... 
>>> t = Test()
>>> t.method()
This method is an attribute of the class.
>>>
>>> import types
>>> t.method = types.MethodType(
... lambda self: print(
... "This method is an attribute of the instance."), t)
>>> t.method()
This method is an attribute of the instance.


So the normal lookup rules that apply to data attributes, namely 
instance, then class, then superclasses, also applies to methods in 
Python. In languages that don't allow that sort of thing, like Java, you 
need to use convoluted design patterns like Dynamic Proxy to make it 
work. In Python, you just create a method and attach it on the instance.

http://stackoverflow.com/questions/8260740/override-a-method-for-an-
instance-of-a-class

But this doesn't apply for special dunder attributes like __exit__, for 
speed reasons. (For new-style classes only, classic classes have no such 
special casing. This makes automatic delegation a breeze in Python 2 with 
classic classes, and a PITA in Python 3. Boo hiss.)



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

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

[Eelco]

On Dec 14, 4:18 am, Steven D'Aprano  wrote:
> > 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?

The philosophy was just a sidehobby to the study of actual
mathematics; and you are right, studying their works is the best way
to get to know them. Speaking from that vantage point, I can say with
certainty that the vast majority of mathematicians do not have a
coherent philosophy, and they adhere to some loosely defined form of
platonism. Indeed that is absurd in a way. Even though you may trust
these people to be perfectly functioning deduction machines, you
really shouldnt expect them to give sensible answers to the question
of which are sensible axioms to adopt. They dont have a reasoned
answer to this, they will by and large defer to authority.
-- 
http://mail.python.org/mailman/listinfo/python-list

Property Abuse

[Felipe O]

Hi All,
I was wondering what everyone's thought process was regarding properties.
Lately I find I've been binging on them and have classes with > 10
properties. While pylint doesn't complain (yet), it tends to be picky about
keeping instance attribute counts low, so I figure there's something
against that. How do you guys decide between using properties versus getter
methods, or how do you refactor them if neither?
Cheers!
-Felipe
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Jussi Piitulainen]

Steven D'Aprano writes:
> 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:

(For 'bijunction', read 'function'.)

I'm not misunderstanding any argument. There was no argument. There
was a blanket pronouncement that _in mathematics_ mod is not a binary
operator. I should learn to challenge such pronouncements and ask what
the problem is. Maybe next time.

But you are right that I don't know how actual mathematicians these
people are. I'm not a mathematician. I don't know where to draw the
line.

A Finnish actual mathematician stated a similar prejudice towards mod
as a binary operator in a Finnish group. I asked him what is wrong
with Knuth's definition (remainder after flooring division), and I
think he conceded that it's not wrong. Number theorists just choose to
work with congruence relations. I have no problem with that.

He had experience with students who confused congruences modulo some
modulus with a binary operation, and mixed up their notations because
of that. That is a reason to be suspicious, but it is a confusion on
the part of the students. Graham, Knuth, Patashnik contrast the two
concepts explicitly, no confusion there.

And I know that there are many ways to define division and remainder
so that x div y + x rem y = x. Boute's paper cited in [1] advocates a
different one and discusses others.

[1] 

But I think the argument "there are several such functions, therefore,
_in mathematics_, there is no such function" is its own caricature.

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

Is someone saying that _division_ is not defined because -42 div -5 is
somehow both 9 and 8? Hm, yes, I see that someone might. The two
operations, div and rem, need to be defined together.

(There is no way to make remainder a bijection. You mean it is not a
function if it is looked at in a particular way.)

[The square root was relevant but I snipped it.]

> 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:
...
> 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.

Scheme is adopting flooring division, ceiling-ing division, rounding
division, truncating division, centering division, and the Euclidean
division advocated by Boute, and the corresponding remainders. There
is no better way to bring home to a programmer the points that there
are different ways to define these, and they come as div _and_ rem.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Verbose and flexible args and kwargs syntax

[Jussi Piitulainen]

Nick Dokos writes:
> Jussi Piitulainen wrote:
> > 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.)
> 
> They are probably arguing that it's uniquely defined only on ZxN and
> that there are different conventions to extend it to ZxZ (the
> programming languages problem that you allude to above - although I
> don't know what you mean by "does not behave well wrt division").

I think Boute [1] says Standard Pascal or some such language failed to
have x div y + x rem y = x, but I can't check the reference now. That
at least waes what I had in mind. Having x rem y but leaving it
underspecified is another such problem: then it is unspecified whether
the equation holds.

[1] 

> If you choose one convention and stick to it, it becomes a
> well-defined binary operation.

That's what I'd like to think.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: boolean from a function

[Andrea Crotti]

On 12/13/2011 11:37 PM, Steven D'Aprano wrote:


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.




No no it was just to show the pattern, it wasn't the actual code.
I don't like to have useless indirections, so I wouldn't do that...

I like the idea of the property (from Duncan Booth) but the thing is 
that that function
looks like it's doing something (from its name), it's not just a simple 
property.


In the case of the square

class Sq(object):
 def __init__(self, x, y):
   self.x = x
   self.y


It makes perfect sense to have "area" as a property, because you can 
either compute

it and cache it or compute it on demand.
It feels a bit less natural to create a property on something that is 
less simple than that imho..

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

Re: % is not an operator

[Paul Rudin]

Steven D'Aprano  writes:

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

This depends on your definition of "operation". Normally an operation is
a function, rather than just a relation.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: xml, minidom, ElementTree

[Paul Rudin]

Ethan Furman  writes:

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

I tend to start with BeautifulSoup, and think about other things if that
doesn't work out. It might just be me, but I find it easier to get stuff
done using BeautifulSoup than either minidom or ElementTree.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: AttributeError in "with" statement (3.2.2)

[Peter Otten]

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__

If you don't know it yet, contextlib.contextmanager offers a highlevel 
alternative:

>>> @contextmanager
... def goodbye(obj):
... try:
... yield obj
... finally:
... print("goodbye", obj.name)
...
>>> with goodbye(Foo()) as foo:
... print("hello", foo.name)
...
hello Steve
goodbye Steve


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

Re: Overriding a global

[Jean-Michel Pichavant]

Joshua Landau wrote:
On 13 December 2011 13:30, Jean-Michel Pichavant 
mailto:jeanmic...@sequans.com>> 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)
you're changing the value of x, that's fine. In the example above, the 
assignement is not the problem. The problem is that you create 2 
different 'x', one in globals(), and one in locals(). Using the same 
name within 2 implicit namespaces is a bad idead in general because it 
can be difficult to know which one is used.


If you want to have fun, try this code, prepared to be amazed. There's 
something funny with the global statement, it's applied on the whole 
block no matter where it is stated in the block.

x=1 # global

def spam():
   x = 2 # local (or so you may think)
   print x
   global x # I need to use the global one now
   print x
   print locals()

For more fun you could create a 'x' name in __builtin__ and import it so 
that people never know which x you are using.



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.


The problem makes little sense when using names like x or func1. Besides 
namespace issues, naming 2 *different objects* with the same meaningful 
name is usually a bad idea and points the fact that your names are no 
that meaningful. To go back to the original post, having a 'logger' that 
may name 2 different logger object during the execution is a bad idea. 
One quick way to fix it is to name the logger 'currentLogger', this way 
you warn the reader that the logger named by curentLogger may change 
over time.


As someone sugggested in this thread one other option is to use a 
different name for the second logger.


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

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

[Eelco]

On 14 dec, 09:56, Jussi Piitulainen  wrote:
> Steven D'Aprano writes:
> > 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:
>
> (For 'bijunction', read 'function'.)
>
> I'm not misunderstanding any argument. There was no argument. There
> was a blanket pronouncement that _in mathematics_ mod is not a binary
> operator. I should learn to challenge such pronouncements and ask what
> the problem is. Maybe next time.
>
> But you are right that I don't know how actual mathematicians these
> people are. I'm not a mathematician. I don't know where to draw the
> line.
>
> A Finnish actual mathematician stated a similar prejudice towards mod
> as a binary operator in a Finnish group. I asked him what is wrong
> with Knuth's definition (remainder after flooring division), and I
> think he conceded that it's not wrong. Number theorists just choose to
> work with congruence relations. I have no problem with that.
>
> He had experience with students who confused congruences modulo some
> modulus with a binary operation, and mixed up their notations because
> of that. That is a reason to be suspicious, but it is a confusion on
> the part of the students. Graham, Knuth, Patashnik contrast the two
> concepts explicitly, no confusion there.
>
> And I know that there are many ways to define division and remainder
> so that x div y + x rem y = x. Boute's paper cited in [1] advocates a
> different one and discusses others.
>
> [1] 
>
> But I think the argument "there are several such functions, therefore,
> _in mathematics_, there is no such function" is its own caricature.

Indeed. Obtaining a well defined function is just a matter of picking
a convention and sticking with it.

Arguably, the most elegant thing to do is to define integer division
and remainder as a single operation; which is not only the logical
thing to do mathematically, but might work really well
programmatically too.

The semantics of python dont really allow for this though. One could
have:

d, r = a // b

But it wouldnt work that well in composite expressions; selecting the
right tuple index would be messy and a more verbose form would be
preferred. However, performance-wise its also clearly the best
solution, as one often needs both output arguments and computing them
simultaniously is most efficient.

At least numpy should have something like:
d, r = np.integer_division(a, b)

And something similar in the math module for scalars.


> > "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)."
>
> Is someone saying that _division_ is not defined because -42 div -5 is
> somehow both 9 and 8? Hm, yes, I see that someone might. The two
> operations, div and rem, need to be defined together.
>
> (There is no way to make remainder a bijection. You mean it is not a
> function if it is looked at in a particular way.)

Surjection is the word you are looking for

That is, if one buys the philosophy of modernists like bourbaki in
believing there is much to be gained by such pedantry.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Overriding a global

[Chris Angelico]

On Wed, Dec 14, 2011 at 9:14 PM, Jean-Michel Pichavant
 wrote:
> The problem makes little sense when using names like x or func1. Besides
> namespace issues, naming 2 *different objects* with the same meaningful name
> is usually a bad idea and points the fact that your names are no that
> meaningful.

So... it's a bad idea for me to use 'i' many times in my code, with
the same name having different meanings in different places? In
languages with infinitely-nesting scopes (one of Python's great lacks,
imho), I've often had three different variables with the same names,
all perfectly valid, and all doing what they should. It's not just
loop indices - I used to have a piece of code in which 'res' was a
MySQL resource being processed in a loop, and I had three nested
loops. Each time I referenced 'res', it used the innermost available
resource, which was precisely what I wanted. If I'd arbitrarily had to
guarantee that all variable names were unique, I would have had
completely unnecessary fiddling around.

Python wouldn't let you do that with three nested 'res'es in one
function, but you can perfectly reasonably have a global and a local.
It makes perfect sense... which is a good reason for keeping it legal.

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

Regexp : repeated group identification

[candide]

Consider the following code

# 
import re

z=re.match('(Spam\d)+', 'Spam4Spam2Spam7Spam8')
print z.group(0)
print z.group(1)
# 

outputting :


Spam4Spam2Spam7Spam8
Spam8


The '(Spam\d)+' regexp is tested against 'Spam4Spam2Spam7Spam8' and the 
regexp matches the string.


Group numbered one within the regex '(Spam\d)+' refers to Spam\d

The fours substrings

Spam4   Spam2   Spam7  and  Spam8

match the group numbered 1.

So I don't understand why z.group(1) gives the last substring (ie Spam8 
as the output shows), why not an another one, Spam4 for example ?

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

Question (PDE solvers in Python)

[narges javaheri]

Hello there,

Based on your experiences, what's the best (the most reliable) package for
solving a system of nonlinear coupled PDEs (partial differential equations)
in 3D using Python, preferably by FEM (finite element method)?

Regards,
Narges
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Regexp : repeated group identification

[Vlastimil Brom]

2011/12/14 candide :
> Consider the following code
>
> # 
> import re
>
> z=re.match('(Spam\d)+', 'Spam4Spam2Spam7Spam8')
> print z.group(0)
> print z.group(1)
> # 
>
> outputting :
>
> 
> Spam4Spam2Spam7Spam8
> Spam8
> 
>
> The '(Spam\d)+' regexp is tested against 'Spam4Spam2Spam7Spam8' and the
> regexp matches the string.
>
> Group numbered one within the regex '(Spam\d)+' refers to Spam\d
>
> The fours substrings
>
> Spam4   Spam2   Spam7  and  Spam8
>
> match the group numbered 1.
>
> So I don't understand why z.group(1) gives the last substring (ie Spam8 as
> the output shows), why not an another one, Spam4 for example ?
> --
> http://mail.python.org/mailman/listinfo/python-list

Hi,
you may find a tiny notice in the re docs on this:
http://docs.python.org/library/re.html#re.MatchObject.group

"If a group is contained in a part of the pattern that matched
multiple times, the last match is returned."

If you need to work with the content captured in the repeated group,
you may check the new regex implementation:
http://pypi.python.org/pypi/regex

Which has a special "captures" method of the match object for this
(beyond many other improvements):

>>> import regex
>>> m=regex.match('(Spam\d)+', 'Spam4Spam2Spam7Spam8')
>>> m.captures(1)
['Spam4', 'Spam2', 'Spam7', 'Spam8']
>>>

hth,
  vbr
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[rusi]

On Dec 14, 1:56 pm, Jussi Piitulainen 
wrote:
>
> Is someone saying that _division_ is not defined because -42 div -5 is
> somehow both 9 and 8? Hm, yes, I see that someone might. The two
> operations, div and rem, need to be defined together.
-
Haskell defines a quot-rem pair and a div-mod pair as follows:
(from http://www.haskell.org/onlinereport/basic.html)

(x `quot` y)*y + (x `rem` y) == x
(x `div`  y)*y + (x `mod` y) == x

`quot` is integer division truncated toward zero, while the result of
`div` is truncated toward negative infinity.
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Chris Angelico]

On Wed, Dec 14, 2011 at 10:47 PM, rusi  wrote:
> `quot` is integer division truncated toward zero, while the result of
> `div` is truncated toward negative infinity.

All these problems just because of negative numbers. They ought never
to have been invented.

At least nobody rounds toward positive infinity... oh wait, that's legal too.

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

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

[Arnaud Delobelle]

On 14 December 2011 07:49, Eelco  wrote:
> On Dec 14, 4:18 am, Steven D'Aprano  +comp.lang.pyt...@pearwood.info> wrote:
>> > 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?
>
> The philosophy was just a sidehobby to the study of actual
> mathematics; and you are right, studying their works is the best way
> to get to know them. Speaking from that vantage point, I can say with
> certainty that the vast majority of mathematicians do not have a
> coherent philosophy, and they adhere to some loosely defined form of
> platonism. Indeed that is absurd in a way. Even though you may trust
> these people to be perfectly functioning deduction machines, you
> really shouldnt expect them to give sensible answers to the question
> of which are sensible axioms to adopt. They dont have a reasoned
> answer to this, they will by and large defer to authority.

Please come down from your vantage point for a few moments and
consider how insulting your remarks are to people who have devoted
most of their intellectual energy to the study of mathematics.  So
you've studied a bit of mathematics and a bit of philosophy?  Good
start, keep working at it.

You think that every mathematician should be preoccupied with what
axioms to adopt, and why?  Mathematics is a very large field of study
and yes, some mathematicians are concerned with these issues (they are
called logicians) but for most it isn't really about axioms.
Mathematics is bigger than the axioms that we use to formalise it.
Most mathematicians do not need to care about what precise
axiomatisation underlies the mathematics that they practise because
they are thinking on a much higher level.  Just like we do not worry
about what machine language instruction actually performs each step of
the Python program we are writing.

You say that mathematicians defer to authority, but do you really
think that thousands of years of evolution and refinement in
mathematics are to be discarded lightly?  I think not.  It's good to
have original ideas, to pursue them and to believe in them, but it
would be foolish to think that they are superior to knowledge which
has been accumulated over so many generations.

You claim that mathematicians have a poor understanding of philosophy.
 It may be so for many of them, but how is this a problem?  I doesn't
prevent them from having a deep understanding of their field of
mathematics.  Do philosophers have a good understanding of
mathematics?

Cheers,

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

Re: Overriding a global

[Jean-Michel Pichavant]

Chris Angelico wrote:

On Wed, Dec 14, 2011 at 9:14 PM, Jean-Michel Pichavant
 wrote:
  

The problem makes little sense when using names like x or func1. Besides
namespace issues, naming 2 *different objects* with the same meaningful name
is usually a bad idea and points the fact that your names are no that
meaningful.



So... it's a bad idea for me to use 'i' many times in my code, with
the same name having different meanings in different places? In
languages with infinitely-nesting scopes (one of Python's great lacks,
imho), I've often had three different variables with the same names,
all perfectly valid, and all doing what they should. It's not just
loop indices - I used to have a piece of code in which 'res' was a
MySQL resource being processed in a loop, and I had three nested
loops. Each time I referenced 'res', it used the innermost available
resource, which was precisely what I wanted. If I'd arbitrarily had to
guarantee that all variable names were unique, I would have had
completely unnecessary fiddling around.

Python wouldn't let you do that with three nested 'res'es in one
function, but you can perfectly reasonably have a global and a local.
It makes perfect sense... which is a good reason for keeping it legal.

ChrisA
  


Bad ideas :

i = 5

def spam():
 for i,v in enumerate([1,2,3,4]):
   for i,v in enumerate(['a','b', 'c']):
 print i, v
   print i,v # bad surprise


good ideas :

# global
nameThatWillNotBeUsedlocally = 'foo'

def spam():
 for qtyIndex, quantity in enumerate([5,6,3,1]):
   for fruitIndex, fruit in enumerate(['orange', 'banana']):
 print fruitIndex, fruit
   print qtyIndex, quantity

While a lot of people still use i,j,k,v to handler values and indexes, I 
think it's a bad idea. I'm just stating an opinion from my personnal 
python experience. I know some people can successfully use the hard way.


JM


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

Re: Overriding a global

[Chris Angelico]

On Wed, Dec 14, 2011 at 11:05 PM, Jean-Michel Pichavant
 wrote:
> Chris Angelico wrote:
>>
>> So... it's a bad idea for me to use 'i' many times in my code, with
>> the same name having different meanings in different places? In
>> languages with infinitely-nesting scopes...

> Bad ideas :
>
> i = 5
>
> def spam():
>  for i,v in enumerate([1,2,3,4]):
>   for i,v in enumerate(['a','b', 'c']):
>     print i, v
>   print i,v # bad surprise

That's my point. It's not safe to do it in Python, because the "inner"
local i is the same as the "outer" local i. Python doesn't have block
scope the way most C-like languages do.

int spam()
{
for (int i=0;i<5;++i)
{
for (int i=2;i<4;++i) write("inner "+i+"\n");
write("outer "+i+"\n");
}
}

Works perfectly, and the only cost is that variables must be formally declared.

In Python, you can kinda fudge that sort of thing with nested functions.

def spam():
q=2  # just to prove that the scopes really are nested
for i in range(5):
def ham():
for i in range(2,4):
print("q = %d, i = %d"%(q,i))
ham()
print("i = %d"%i)

It's somewhat clunky, but it does give the illusion of block scope.
Inners mask outers, outers are visible to inner functions. It's an odd
construct though. Very odd.

So... I think I've figured out how to implement from __future__ import braces.

#define { def innerfunc():
#define } innerfunc()

And there you are, out of your difficulty at once!

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

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

[Jussi Piitulainen]

Eelco writes:
> On 14 dec, 09:56, Jussi Piitulainen wrote:
> > But I think the argument "there are several such functions,
> > therefore, _in mathematics_, there is no such function" is its own
> > caricature.
> 
> Indeed. Obtaining a well defined function is just a matter of
> picking a convention and sticking with it.
> 
> Arguably, the most elegant thing to do is to define integer division
> and remainder as a single operation; which is not only the logical
> thing to do mathematically, but might work really well
> programmatically too.
> 
> The semantics of python dont really allow for this though. One could
> have:
> 
> d, r = a // b
> 
> But it wouldnt work that well in composite expressions; selecting the
> right tuple index would be messy and a more verbose form would be
> preferred. However, performance-wise its also clearly the best
> solution, as one often needs both output arguments and computing them
> simultaniously is most efficient.

The current Scheme draft does this. For each rounding method, it
provides an operation that provides both the quotient and the
remainder, an operation that provides the quotient, and an operation
that provides the remainder. The both-values operation is more awkward
to compose, as you rightly say.

It's just a matter of naming them all. Python has a good default
integer division as the pair of operators // and %. Python also
supports the returning of several values from functions as tuples. It
can be done.

> > Is someone saying that _division_ is not defined because -42 div
> > -5 is somehow both 9 and 8? Hm, yes, I see that someone might. The
> > two operations, div and rem, need to be defined together.
> >
> > (There is no way to make remainder a bijection. You mean it is not
> > a function if it is looked at in a particular way.)
> 
> Surjection is the word you are looking for

Um, no, I mean function. The allegedly alleged problem is that there
may be two (or more) different values for f(x,y), which makes f not a
_function_ (and the notation f(x,y) maybe inappropriate).

Surjectivity is as much beside the point as bijectivity, but I think
we have surjectivity for rem: Z * Z -> Z if we use a definition that
produces both positive and negative remainders, or rem: Z * Z -> N if
we have non-negative remainders (and include 0 in N, which is another
bone of contention). We may or may not want to exclude 0 as the
modulus, or divisor if you like. It is at least a special case.

It's injectivity that fails: 9 % 4 == 6 % 5 == 3 % 2, while Python
quite sensibly has (9, 4) != (6, 5) != (3, 2). (How I love the
chaining of the comparisons.)

> That is, if one buys the philosophy of modernists like bourbaki in
> believing there is much to be gained by such pedantry.

I think something is gained. Not sure I would call it philosophy.
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Juan Perez]

Hi,

Well if I can remmeber since last time I did something similar in C, it was
close stdin channel in the open devices table (I don't know if it is the
correct name in english, I learnt it in spanish) and put a pipe on it and
then create a fork, parent it comunicates to the child through the pipe, so
if child run a shell program, through exec, you should be able to
comunicate to his stdin through his parent... I think that was correct, if
I remmember well...

My app is console app, working by basic commands like send cd or dir to the
console. I thought redirecting stdin (keypad) I could send this basic
comands to it... but obviously I was completely wrong...

I can not use dedicated virtual machines, and it has to be as similar as
user environment as possible, and it can appear new windows that takes
focus, so I have to assure i can get the focus every time before sending
commands Quite tricky stuff if it is possible to do something like
that in Python I can struggle a bit more, if not better leave right now
before wasting time with nonsenses...
Thanks,
Juan

2011/12/13 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
>
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Steven D'Aprano]

On Wed, 14 Dec 2011 10:56:02 +0200, Jussi Piitulainen wrote:

> Steven D'Aprano writes:
>> 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:
> 
> (For 'bijunction', read 'function'.)

Oops, you're right of course. It's been about 20 years since I've needed 
to care about the precise difference between a bijection and a function, 
and I made a mistake. And then to add to my shame, I also misspelt 
bijection.


> I'm not misunderstanding any argument. There was no argument. There was
> a blanket pronouncement that _in mathematics_ mod is not a binary
> operator. I should learn to challenge such pronouncements and ask what
> the problem is. Maybe next time.

So this was *one* person making that claim?

I understand that, in general, mathematicians don't have much need for a 
remainder function in the same way programmers do -- modulo arithmetic is 
far more important. But there's a world of difference between saying "In 
mathematics, extracting the remainder is not important enough to be given 
a special symbol and treated as an operator" and saying "remainder is not 
a binary operator". The first is reasonable; the second is not.


> But you are right that I don't know how actual mathematicians these
> people are. I'm not a mathematician. I don't know where to draw the
> line.
> 
> A Finnish actual mathematician stated a similar prejudice towards mod as
> a binary operator in a Finnish group. I asked him what is wrong with
> Knuth's definition (remainder after flooring division), and I think he
> conceded that it's not wrong. Number theorists just choose to work with
> congruence relations. I have no problem with that.

Agreed.

[...]
> (There is no way to make remainder a bijection. You mean it is not a
> function if it is looked at in a particular way.)

You're right, of course -- remainder cannot be 1:1. I don't know what I 
was thinking.


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

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

[Eelco]

On 14 dec, 12:55, Arnaud Delobelle  wrote:
> On 14 December 2011 07:49, Eelco  wrote:
> > On Dec 14, 4:18 am, Steven D'Aprano  > +comp.lang.pyt...@pearwood.info> wrote:
> >> > 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?
>
> > The philosophy was just a sidehobby to the study of actual
> > mathematics; and you are right, studying their works is the best way
> > to get to know them. Speaking from that vantage point, I can say with
> > certainty that the vast majority of mathematicians do not have a
> > coherent philosophy, and they adhere to some loosely defined form of
> > platonism. Indeed that is absurd in a way. Even though you may trust
> > these people to be perfectly functioning deduction machines, you
> > really shouldnt expect them to give sensible answers to the question
> > of which are sensible axioms to adopt. They dont have a reasoned
> > answer to this, they will by and large defer to authority.
>
> Please come down from your vantage point for a few moments and
> consider how insulting your remarks are to people who have devoted
> most of their intellectual energy to the study of mathematics.  So
> you've studied a bit of mathematics and a bit of philosophy?  Good
> start, keep working at it.

Thanks, I intend to.

> You think that every mathematician should be preoccupied with what
> axioms to adopt, and why?

Of course I dont. If you wish to restrict your attention to the
exploration of the consequences of axioms others throw at you, that is
a perfectly fine specialization. Most mathematicians do exactly that,
and thats fine. But that puts them in about as ill a position to
judged what is, or shouldnt be defined, as the average plumber.
Compounding the problem is not just that they do not wish to concern
themselves with the inductive aspect of mathematics, they would like
to pretend it does not exist at all. For instance, if you point out to
them a 19th century mathematician used very different axioms than a
20th century one, (and point out they were both fine mathematicians
that attained results universally celebrated), they will typically
respond emotionally; get angry or at least annoyed. According to their
pseudo-Platonist philosophy, mathematics should not have an inductive
side, axioms are set in stone and not a human affair, and the way they
answer the question as to where knowledge about the 'correct'
mathematical axioms comes from is by an implicit or explicit appeal to
authority. They dont explain how it is that they can see 'beyond the
platonic cave' to find the 'real underlying truth', they quietly
assume somebody else has figured it out in the past, and leave it at
that.

> You say that mathematicians defer to authority, but do you really
> think that thousands of years of evolution and refinement in
> mathematics are to be discarded lightly?  I think not.  It's good to
> have original ideas, to pursue them and to believe in them, but it
> would be foolish to think that they are superior to knowledge which
> has been accumulated over so many generations.

For what its worth; insofar as my views can be pidgeonholed, im with
the classicists (pre-20th century), which indeed has a long history.
Modernists in turn discard large swaths of that. Note that its largely
an academic debate though; everybody agrees that 1+1=2. But there are
some practical consequences; if I were the designated science-Tsar,
all transfinite-analysist would be out on the street together with the
homeopaths, for instance.

> You claim that mathematicians have a poor understanding of philosophy.
>  It may be so for many of them, but how is this a problem?  I doesn't
> prevent them from having a deep understanding of their field of
> mathematics.  Do philosophers have a good understanding of
> mathematics?

As a rule of thumb: absolutely not, no. I dont think I can think of
any philosopher who turned his attention to mathematics that ever
wrote anything interesting. All the interesting writers had their
boots on mathematical ground; Quine, Brouwer, Weyl and the earlier
renaissance men like Gauss and contemporaries.

The fragmentation of disciplines is infact a major problem in my
opinion though. Most physicists take their mathematics from the ivory-
math tower, and the mathematicians shudder at the idea of listning
back to see which of what they cooked up is actually anything but
mental masturbation, in the meanwhile cranking out more gibberish
about alephs. If any well-rea

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

[Steven D'Aprano]

On Wed, 14 Dec 2011 02:09:32 -0800, Eelco wrote:

> Arguably, the most elegant thing to do is to define integer division and
> remainder as a single operation; which is not only the logical thing to
> do mathematically, but might work really well programmatically too.
> 
> The semantics of python dont really allow for this though. One could
> have:
> 
> d, r = a // b

That would be:

>>> divmod(17, 5)
(3, 2)



> But it wouldnt work that well in composite expressions; selecting the
> right tuple index would be messy and a more verbose form would be
> preferred. However, performance-wise its also clearly the best solution,
> as one often needs both output arguments and computing them
> simultaniously is most efficient.

Premature optimization.



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

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

[Eelco]

On 14 dec, 13:22, Jussi Piitulainen  wrote:
> > > Is someone saying that _division_ is not defined because -42 div
> > > -5 is somehow both 9 and 8? Hm, yes, I see that someone might. The
> > > two operations, div and rem, need to be defined together.
>
> > > (There is no way to make remainder a bijection. You mean it is not
> > > a function if it is looked at in a particular way.)
>
> > Surjection is the word you are looking for
>
> Um, no, I mean function. The allegedly alleged problem is that there
> may be two (or more) different values for f(x,y), which makes f not a
> _function_ (and the notation f(x,y) maybe inappropriate).
>
> Surjectivity is as much beside the point as bijectivity, but I think
> we have surjectivity for rem: Z * Z -> Z if we use a definition that
> produces both positive and negative remainders, or rem: Z * Z -> N if
> we have non-negative remainders (and include 0 in N, which is another
> bone of contention). We may or may not want to exclude 0 as the
> modulus, or divisor if you like. It is at least a special case.
>
> It's injectivity that fails: 9 % 4 == 6 % 5 == 3 % 2, while Python
> quite sensibly has (9, 4) != (6, 5) != (3, 2). (How I love the
> chaining of the comparisons.)

My reply was more to the statement you quoted than to yours; sorry for
the confusion. Yes, we have surjectivity and not injectivity, thats
all I was trying to say.


> > That is, if one buys the philosophy of modernists like bourbaki in
> > believing there is much to be gained by such pedantry.
>
> I think something is gained. Not sure I would call it philosophy.

Agreed; its more the notion that one stands to gain much real
knowledge by writing volumnius books about these matters that irks me,
but I guess thats more a matter of taste than philosophy.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [GENERAL] Philosophical question

[Chris Angelico]

On Wed, Dec 14, 2011 at 11:32 PM, Andreas  wrote:
> Hi,
>
> I asked elsewhere about the best way to store db credentials within a
> user-session of a web-app.
>
> It appeared that it was for everybody but me evident that instead of heaving
> a db-role+passwd for every user of an application it was better to have just
> 1 set of db-credentials for the application and recreate a user management
> within the app instead using the existing user handling of the dbms.
>
> That way the app checks the user's password as a md5 in some table and
> remembers "user is logged in" for later. The actual queries would be done
> with a common set of real db credentials.

This is I think the most common way to do things in web apps these
days. It's viable, at least; whether or not it's the best option is
another question.

As a side point, simply MD5'ing a user's password is sadly
insufficient for proper security. (But at least you're not considering
storing plain-text passwords.) If anyone managed to get hold of your
users table, they'd be able to recognize any of the most common
passwords. You'll want to use some kind of salt; and preferably, a
newer and stronger algorithm than MD5. One simple way to do this is to
concatenate the user name or numeric ID with a constant string of your
own invention, and then put the password after that - so if user
'fred' signs up with password 'barney', you might hash
'fredNaClbarney', which has a SHA-1 of
2DC074250DDA7A903FE6A11B1AEC1EF0A80A0408. Without knowing that you use
"NaCl" as your salt, an attacker would have some difficulty
brute-forcing the passwords; and including the username means that if
someone else uses the same password, the hashes will differ.

That aside, your idea more or less matches up with what a large number
of web sites do.

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

Re: Overriding a global

[Steven D'Aprano]

On Wed, 14 Dec 2011 13:05:19 +0100, Jean-Michel Pichavant wrote:

> Bad ideas :
> 
> i = 5
> 
> def spam():
>   for i,v in enumerate([1,2,3,4]):
> for i,v in enumerate(['a','b', 'c']):
>   print i, v
> print i,v # bad surprise

The bad surprise happens because you are using the same name twice in 
*one* namespace, the local scope. This example has nothing to do with 
local/global name clashes: the existence of global i is irrelevant. 
Python's scoping rules work correctly, and global i is not affected by 
the local i.

Programming languages use multiple namespaces so that you don't need to 
make your variable names globally unique. There are languages that don't 
distinguish between local and global. Python is not one of them. The 
programmer should feel free to use local names without worrying too much 
if they accidentally use a global name.

Having said that, re-using names isn't *entirely* risk free, because if 
you use a global name locally, and then try to *also* access the global 
name, you will fail. This is called shadowing, and the problem with 
shadowing is when you do it by accident. (Newbies are particularly prone 
to this, especially when they call variables "str", "list", etc.) But it 
is the "by accident" part that is dangerous: there is nothing wrong with 
shadowing globals or builtins when you do it by design.


> good ideas :
> 
> # global
> nameThatWillNotBeUsedlocally = 'foo'

Oh please. Names can be too long as well as too short.

 
> def spam():
>   for qtyIndex, quantity in enumerate([5,6,3,1]):
> for fruitIndex, fruit in enumerate(['orange', 'banana']):
>   print fruitIndex, fruit
> print qtyIndex, quantity

More sensible naming conventions are to be encouraged, but verbose names 
just for the sake of verbosity is not. spam() is a five line function; if 
the programmer can't keep track of the meaning of loop variables i and j 
over five lines, perhaps they should consider a change of career and get 
a job more suited to their intellectual prowess. I hear McDonalds is 
hiring.

If spam() were larger and more complex, then more expressive names would 
be valuable. But in the simple example you give, it just adds noise.



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

Re: Regexp : repeated group identification

[candide]

Le 14/12/2011 12:34, Vlastimil Brom a écrit :


"If a group is contained in a part of the pattern that matched
multiple times, the last match is returned."



I missed this point, your answer matches my question ;) thanks.



If you need to work with the content captured in the repeated group,
you may check the new regex implementation:
http://pypi.python.org/pypi/regex

Which has a special "captures" method of the match object for this
(beyond many other improvements):


import regex
m=regex.match('(Spam\d)+', 'Spam4Spam2Spam7Spam8')
m.captures(1)

['Spam4', 'Spam2', 'Spam7', 'Spam8']







Thanks for the reference and the example. I didn't know of this 
reimplementation, hoping it offers the Aho-Corasick algorithm allowing 
multiple keys search.

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

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

[Jussi Piitulainen]

rusi writes:

> On Dec 14, 1:56 pm, Jussi Piitulainen 
> wrote:
> >
> > Is someone saying that _division_ is not defined because -42 div -5 is
> > somehow both 9 and 8? Hm, yes, I see that someone might. The two
> > operations, div and rem, need to be defined together.
> -
> Haskell defines a quot-rem pair and a div-mod pair as follows:
> (from http://www.haskell.org/onlinereport/basic.html)
> 
> (x `quot` y)*y + (x `rem` y) == x
> (x `div`  y)*y + (x `mod` y) == x
> 
> `quot` is integer division truncated toward zero, while the result of
> `div` is truncated toward negative infinity.

Exactly what I mean. (I gave an incorrect equation but meant this.)
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Jussi Piitulainen]

Steven D'Aprano writes:
> On Wed, 14 Dec 2011 10:56:02 +0200, Jussi Piitulainen wrote:
> > I'm not misunderstanding any argument. There was no
> > argument. There was a blanket pronouncement that _in mathematics_
> > mod is not a binary operator. I should learn to challenge such
> > pronouncements and ask what the problem is. Maybe next time.
> 
> So this was *one* person making that claim?

I've seen it a few times from a few different posters, all on Usenet
or whatever this thing is nowadays called. I think I was careful to
say _some_ mathematicians, but not careful to check that any of them
were actually mathematicians speaking as mathematicians.

The context seems to be a cultural divide between maths and cs. Too
much common ground yet very different interests?

> I understand that, in general, mathematicians don't have much need
> for a remainder function in the same way programmers do -- modulo
> arithmetic is far more important. But there's a world of difference
> between saying "In mathematics, extracting the remainder is not
> important enough to be given a special symbol and treated as an
> operator" and saying "remainder is not a binary operator". The first
> is reasonable; the second is not.

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

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

[Eelco]

On Dec 14, 1:38 pm, Steven D'Aprano  wrote:
> On Wed, 14 Dec 2011 02:09:32 -0800, Eelco wrote:
> > Arguably, the most elegant thing to do is to define integer division and
> > remainder as a single operation; which is not only the logical thing to
> > do mathematically, but might work really well programmatically too.
>
> > The semantics of python dont really allow for this though. One could
> > have:
>
> > d, r = a // b
>
> That would be:
>
> >>> divmod(17, 5)
>
> (3, 2)

Cool; if only it were in the math module id be totally happy.


> > But it wouldnt work that well in composite expressions; selecting the
> > right tuple index would be messy and a more verbose form would be
> > preferred. However, performance-wise its also clearly the best solution,
> > as one often needs both output arguments and computing them
> > simultaniously is most efficient.
>
> Premature optimization.

We are talking language design here, not language use. Whether or not
this is premature is a decision that should be left to the user, if at
all possible, which in this case it very well is; just provide
multiple functions to cover all use cases (only return divisor, only
return remainder, or both)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Overriding a global

[Jean-Michel Pichavant]

Steven D'Aprano wrote:

On Wed, 14 Dec 2011 13:05:19 +0100, Jean-Michel Pichavant wrote:

  

Bad ideas :

i = 5

def spam():
  for i,v in enumerate([1,2,3,4]):
for i,v in enumerate(['a','b', 'c']):
  print i, v
print i,v # bad surprise



The bad surprise happens because you are using the same name twice in 
*one* namespace, the local scope. This example has nothing to do with 
local/global name clashes: the existence of global i is irrelevant. 
Python's scoping rules work correctly, and global i is not affected by 
the local i.


Programming languages use multiple namespaces so that you don't need to 
make your variable names globally unique. There are languages that don't 
distinguish between local and global. Python is not one of them. The 
programmer should feel free to use local names without worrying too much 
if they accidentally use a global name.


Having said that, re-using names isn't *entirely* risk free, because if 
you use a global name locally, and then try to *also* access the global 
name, you will fail. This is called shadowing, and the problem with 
shadowing is when you do it by accident. (Newbies are particularly prone 
to this, especially when they call variables "str", "list", etc.) But it 
is the "by accident" part that is dangerous: there is nothing wrong with 
shadowing globals or builtins when you do it by design.



  

good ideas :

# global
nameThatWillNotBeUsedlocally = 'foo'



Oh please. Names can be too long as well as too short.

 
  

def spam():
  for qtyIndex, quantity in enumerate([5,6,3,1]):
for fruitIndex, fruit in enumerate(['orange', 'banana']):
  print fruitIndex, fruit
print qtyIndex, quantity



More sensible naming conventions are to be encouraged, but verbose names 
just for the sake of verbosity is not. spam() is a five line function; if 
the programmer can't keep track of the meaning of loop variables i and j 
over five lines, perhaps they should consider a change of career and get 
a job more suited to their intellectual prowess. I hear McDonalds is 
hiring.


If spam() were larger and more complex, then more expressive names would 
be valuable. But in the simple example you give, it just adds noise.


  


The next time I'll illustrate meaningful names,  I'll write a 3000 lines 
function, just to be sure no one states that my point does'nt apply to a 
function named spam which only counts from 1 to 3.
And don't answer that the spam function above does not count from 1 to 
3, I know it doesn't.


For anyone interested in the actual topic, a good reading is
http://tottinge.blogsome.com/meaningfulnames/#Mult_Meanings


JM

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

Re: Regexp : repeated group identification

[Vlastimil Brom]

2011/12/14 candide :
...
>
> Thanks for the reference and the example. I didn't know of this
> reimplementation, hoping it offers the Aho-Corasick algorithm allowing
> multiple keys search.
> --
> http://mail.python.org/mailman/listinfo/python-list

Hi,
I am not sure about the underlying algorithm (it could as well be an
internal expansion of the alternatives like ...|...|...), but you can
use a list (set, actually) of alternatives to search for.
check the "named lists" feature,
\L<...>

hth,
   vbr
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Chris Angelico]

On Thu, Dec 15, 2011 at 12:29 AM, Eelco  wrote:
> On Dec 14, 1:38 pm, Steven D'Aprano  +comp.lang.pyt...@pearwood.info> wrote:
>> That would be:
>>
>> >>> divmod(17, 5)
>>
>> (3, 2)
>
> Cool; if only it were in the math module id be totally happy.

That's easily solved.

import math
math.divmod=divmod
del __builtins__.divmod

:)

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

Re: text to html

[James Mills]

On Dec 14, 3:30 am, 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 Pedro,

You could also use pygments
to nicely format the logfile
perhaps even with Syntax Highlighting.

https://bitbucket.org/freecodeteam/hpaste/src/749c36d184a6/hpaste.circuits/paste.py

You could also provide an "Download" link
that services the file up as Content-Type: text/plain

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

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

[Ian Kelly]

On Wed, Dec 14, 2011 at 6:29 AM, Eelco  wrote:
> On Dec 14, 1:38 pm, Steven D'Aprano  +comp.lang.pyt...@pearwood.info> wrote:
>> On Wed, 14 Dec 2011 02:09:32 -0800, Eelco wrote:
>> > Arguably, the most elegant thing to do is to define integer division and
>> > remainder as a single operation; which is not only the logical thing to
>> > do mathematically, but might work really well programmatically too.
>>
>> > The semantics of python dont really allow for this though. One could
>> > have:
>>
>> > d, r = a // b
>>
>> That would be:
>>
>> >>> divmod(17, 5)
>>
>> (3, 2)
>
> Cool; if only it were in the math module id be totally happy.

Probably it's not in math because it's not a thin wrapper around a C
math library function, which is how the module was conceived.  There
are already some exceptions in the math module, but I think they are
all newer than divmod.
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Arnaud Delobelle]

On 14 December 2011 12:33, Eelco  wrote:
> On 14 dec, 12:55, Arnaud Delobelle  wrote:
>> On 14 December 2011 07:49, Eelco  wrote:
>> > On Dec 14, 4:18 am, Steven D'Aprano > > +comp.lang.pyt...@pearwood.info> wrote:
>> >> > 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?
>>
>> > The philosophy was just a sidehobby to the study of actual
>> > mathematics; and you are right, studying their works is the best way
>> > to get to know them. Speaking from that vantage point, I can say with
>> > certainty that the vast majority of mathematicians do not have a
>> > coherent philosophy, and they adhere to some loosely defined form of
>> > platonism. Indeed that is absurd in a way. Even though you may trust
>> > these people to be perfectly functioning deduction machines, you
>> > really shouldnt expect them to give sensible answers to the question
>> > of which are sensible axioms to adopt. They dont have a reasoned
>> > answer to this, they will by and large defer to authority.
>>
>> Please come down from your vantage point for a few moments and
>> consider how insulting your remarks are to people who have devoted
>> most of their intellectual energy to the study of mathematics.  So
>> you've studied a bit of mathematics and a bit of philosophy?  Good
>> start, keep working at it.
>
> Thanks, I intend to.
>
>> You think that every mathematician should be preoccupied with what
>> axioms to adopt, and why?
>
> Of course I dont. If you wish to restrict your attention to the
> exploration of the consequences of axioms others throw at you, that is
> a perfectly fine specialization. Most mathematicians do exactly that,
> and thats fine. But that puts them in about as ill a position to
> judged what is, or shouldnt be defined, as the average plumber.

You are completely mistaken.  Whatever the axiomatisation of the
mathematics that we do, we can still do the same mathematics.  We
don't even need an axiomatic basis to do mathematics.  In fact, the
formalisation of mathematics has always come after the mathematics
were well established.Euclid, Dedekind, Peano, Zermelo, Frankael,
didn't create axiomatic systems out of nothing.  They axiomatised
pre-existing theories.

Axiomatising a theory is just one way of exploring it.

> Compounding the problem is not just that they do not wish to concern
> themselves with the inductive aspect of mathematics, they would like
> to pretend it does not exist at all. For instance, if you point out to
> them a 19th century mathematician used very different axioms than a
> 20th century one, (and point out they were both fine mathematicians
> that attained results universally celebrated), they will typically
> respond emotionally; get angry or at least annoyed. According to their
> pseudo-Platonist philosophy, mathematics should not have an inductive
> side, axioms are set in stone and not a human affair, and the way they
> answer the question as to where knowledge about the 'correct'
> mathematical axioms comes from is by an implicit or explicit appeal to
> authority. They dont explain how it is that they can see 'beyond the
> platonic cave' to find the 'real underlying truth', they quietly
> assume somebody else has figured it out in the past, and leave it at
> that.

Again, you are completely mis-representing the situation.  In my
experience, most mathematicians (I'm not talking about undergraduate
students here) do not see the axioms are the root of the mathematics
that they do.  Formal systems are just one way to explore mathematics.
 Of course they can in some cases be very useful and enlightening.

As for inductive reasoning, I really can't understand your point.  Of
course mathematicians use inductive reasoning all the time.  Where do
you think the Riemann Hypothesis comes from? Or Fermat's last theorem?
 Do you think that mathematicians prove results before they even think
about them?  On the other hand, a result needs to be proved to be
accepted by the mathematical community, and inductive reasoning is not
valid in proofs.  That's in the nature of mathematics.

>> You say that mathematicians defer to authority, but do you really
>> think that thousands of years of evolution and refinement in
>> mathematics are to be discarded lightly?  I think not.  It's good to
>> have original ideas, to pursue them and to believe in them, but it
>> would be foolish to think that they are superior to knowledge which
>> has been accumulated over so man

Re: AttributeError in "with" statement (3.2.2)

[88888 Dihedral]

On Wednesday, December 14, 2011 4:01:24 PM UTC+8, Steven D'Aprano wrote:
> On Wed, 14 Dec 2011 01:29:13 -0500, Terry Reedy wrote:
> 
> > 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.
> 
> I'm not sure that is correct... I don't think that there is anything "by 
> definition" about where methods live. Particularly not in Python where 
> instance methods can be attributes of the instance itself.
> 
> >>> class Test(object):
> ... def method(self):
> ... print("This method is an attribute of the class.")
> ... 
> >>> t = Test()
> >>> t.method()
> This method is an attribute of the class.
> >>>
> >>> import types
> >>> t.method = types.MethodType(
> ... lambda self: print(
> ... "This method is an attribute of the instance."), t)
> >>> t.method()
> This method is an attribute of the instance.
> 
> 
> So the normal lookup rules that apply to data attributes, namely 
> instance, then class, then superclasses, also applies to methods in 
> Python. In languages that don't allow that sort of thing, like Java, you 
> need to use convoluted design patterns like Dynamic Proxy to make it 
> work. In Python, you just create a method and attach it on the instance.
> 
> http://stackoverflow.com/questions/8260740/override-a-method-for-an-
> instance-of-a-class
> 
> But this doesn't apply for special dunder attributes like __exit__, for 
> speed reasons. (For new-style classes only, classic classes have no such 
> special casing. This makes automatic delegation a breeze in Python 2 with 
> classic classes, and a PITA in Python 3. Boo hiss.)
> 
> 
> 
> -- 
> Steven

In Python an instance of an object of a class can have its own method. 
A living object can use  those  methods in the class definition and 
can acquire a new method at runtime. 


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

Re: Property Abuse

[Ian Kelly]

On Wed, Dec 14, 2011 at 1:28 AM, Felipe O  wrote:
> Hi All,
> I was wondering what everyone's thought process was regarding properties.
> Lately I find I've been binging on them and have classes with > 10
> properties. While pylint doesn't complain (yet), it tends to be picky about
> keeping instance attribute counts low, so I figure there's something against
> that. How do you guys decide between using properties versus getter methods,
> or how do you refactor them if neither?

I prefer direct instance attribute access where possible*, properties
where necessary, and methods where an argument is needed or the
relationship is more complex than get/set/delete.

* One of the strengths of Python's property system** is that you can
switch between plain attributes and mutable properties as needed
without breaking dependent code.  Often I see people doing this, which
drives me nuts with its useless verbosity, when a plain instance
attribute would have sufficed:

@property
def foo(self):
return self._foo

@foo.setter
def foo(self, value):
self._foo = value

** As opposed, for instance, to the .NET property system.  You can't
arbitrarily switch between public member variables and public
properties in .NET, because it breaks ABI.

Cheers,
Ian
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: AttributeError in "with" statement (3.2.2)

[88888 Dihedral]

On Thursday, December 15, 2011 12:08:32 AM UTC+8, 8 Dihedral wrote:
> On Wednesday, December 14, 2011 4:01:24 PM UTC+8, Steven D'Aprano wrote:
> > On Wed, 14 Dec 2011 01:29:13 -0500, Terry Reedy wrote:
> > 
> > > 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.
> > 
> > I'm not sure that is correct... I don't think that there is anything "by 
> > definition" about where methods live. Particularly not in Python where 
> > instance methods can be attributes of the instance itself.
> > 
> > >>> class Test(object):
> > ... def method(self):
> > ... print("This method is an attribute of the class.")
> > ... 
> > >>> t = Test()
> > >>> t.method()
> > This method is an attribute of the class.
> > >>>
> > >>> import types
> > >>> t.method = types.MethodType(
> > ... lambda self: print(
> > ... "This method is an attribute of the instance."), t)
> > >>> t.method()
> > This method is an attribute of the instance.
> > 
> > 
> > So the normal lookup rules that apply to data attributes, namely 
> > instance, then class, then superclasses, also applies to methods in 
> > Python. In languages that don't allow that sort of thing, like Java, you 
> > need to use convoluted design patterns like Dynamic Proxy to make it 
> > work. In Python, you just create a method and attach it on the instance.
> > 
> > http://stackoverflow.com/questions/8260740/override-a-method-for-an-
> > instance-of-a-class
> > 
> > But this doesn't apply for special dunder attributes like __exit__, for 
> > speed reasons. (For new-style classes only, classic classes have no such 
> > special casing. This makes automatic delegation a breeze in Python 2 with 
> > classic classes, and a PITA in Python 3. Boo hiss.)
> > 
> > 
> > 
> > -- 
> > Steven
> 
> In Python an instance of an object of a class can have its own method. 
> A living object can use  those  methods in the class definition and 
> can acquire a new method at runtime.

Therefore, it is possible for an object to build its decision tree of 
actions toward a problem of various parameters in the run time.



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

Re: Property Abuse

[Jean-Michel Pichavant]

Ian Kelly wrote:

On Wed, Dec 14, 2011 at 1:28 AM, Felipe O  wrote:
  

Hi All,
I was wondering what everyone's thought process was regarding properties.
Lately I find I've been binging on them and have classes with > 10
properties. While pylint doesn't complain (yet), it tends to be picky about
keeping instance attribute counts low, so I figure there's something against
that. How do you guys decide between using properties versus getter methods,
or how do you refactor them if neither?



I prefer direct instance attribute access where possible*, properties
where necessary, and methods where an argument is needed or the
relationship is more complex than get/set/delete.

* One of the strengths of Python's property system** is that you can
switch between plain attributes and mutable properties as needed
without breaking dependent code.  Often I see people doing this, which
drives me nuts with its useless verbosity, when a plain instance
attribute would have sufficed:

@property
def foo(self):
return self._foo

@foo.setter
def foo(self, value):
self._foo = value

** As opposed, for instance, to the .NET property system.  You can't
arbitrarily switch between public member variables and public
properties in .NET, because it breaks ABI.

Cheers,
Ian
  
I second this opinion, plain attributes are what's required most of the 
time.


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

Re: Overriding a global

[Joshua Landau]

On 14 December 2011 10:14, Jean-Michel Pichavant wrote:

> Joshua Landau wrote:
>
>  On 13 December 2011 13:30, Jean-Michel Pichavant 
> > jeanmic...@sequans.com**>> 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)
>>
> you're changing the value of x, that's fine. In the example above, the
> assignement is not the problem. The problem is that you create 2 different
> 'x', one in globals(), and one in locals(). Using the same name within 2
> implicit namespaces is a bad idead in general because it can be difficult
> to know which one is used.
>
> If you want to have fun, try this code, prepared to be amazed. There's
> something funny with the global statement, it's applied on the whole block
> no matter where it is stated in the block.
> x=1 # global
>
> def spam():
>   x = 2 # local (or so you may think)
>   print x
>   global x # I need to use the global one now
>   print x
>   print locals()
>

:3: SyntaxWarning: name 'x' is assigned to before global declaration

I think it's a null point. We're not talking about "globals" being wrong
(or was this poor design) for efficiency reasons. There's an error there
for reason.


> For more fun you could create a 'x' name in __builtin__ and import it so
> that people never know which x you are using.
>
>  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.
>>
>
> The problem makes little sense when using names like x or func1. Besides
> namespace issues, naming 2 *different objects* with the same meaningful
> name is usually a bad idea and points the fact that your names are no that
> meaningful. To go back to the original post, having a 'logger' that may
> name 2 different logger object during the execution is a bad idea. One
> quick way to fix it is to name the logger 'currentLogger', this way you
> warn the reader that the logger named by curentLogger may change over time.
>
> As someone sugggested in this thread one other option is to use a
> different name for the second logger.


So the only problem is that "x" isn't meaningful?

def countToTen():
 for number in range(1, 10): print(number)

def countToTwenty():
 for number in range(1, 20): print(number)

.. Looks fine to me.

Using currentLogger is just padding, in my opinion. *Every *value is
"current". That changes nothing. As long as you never infer that
"logger" is static or totally global (no "global logger" in global
namespace or terming it "LOGGER") I would never assume as much, as with
every other variable I see. Unless I see "global " in a function, I
need to hold the belief that  can change.

In regards to a second name - yes this could work and in many cases would
be desirable, but it doesn't really help this circumstance. [assume, for a
moment, a lot of functions used a local logger] "localLogger" would tell
you very little about what the logger actually *is*. You still have to look
that up. [end assumption] Additionally, this would make changing a logger
that uses the default to a local one *much* harder. And don't say "but you
can just always make a local copy", as then you lose the advantage of a
global.

Typing something like "logger = childLogger(id)" to the start of a function
call *is explicit*, it's clean, and it makes sense to have a default that's
global. You're not appending cruft ("current") and you have consistency. If
you added "logger = globalLogger" to every function start as well you can
argue that it's better. I agree it's more explicit. But then you
lose unneeded if only a small portion of your code localises logger. But I
would recommend it if a large portion of code used local variants.

AND:

> The next time I'll illustrate meaningful names,  I'll write a 3000 lines
> function, just to be sure no one states that my point does'nt apply to a
> function named spam which only counts from 1 to 3.
> And don't answer that the spam function above does not count from 1 to 3,
> I know it doesn't.


You're acting in sarcasm to a comment on scale, when you yourself said that
one of my comments was invalid due to names that were scaled down for
exampling. It seems a bi

Re: AttributeError in "with" statement (3.2.2)

[Eric Snow]

On Tue, Dec 13, 2011 at 11:05 PM, 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
>>
>> 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

Incidently, if you add the function directly to the class, everything works out:

  class Foo(object): # or "class Foo:" under Python 3
  pass

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

  def add_goodbye_function(cls):
  def goodbye(self, *args, **kwargs):
  print("goodbye " + self.name)
  cls.goodbye = goodbye

  add_goodbye_function(type(foo))
  foo.goodbye() # outputs goodbye Steve
  Foo.__exit__ = foo.goodbye
  foo.__exit__() # outputs goodbye Steve
  Foo.__enter__ = (lambda self: None)

  with foo:
  print("doing stuff")

However, perhaps a better approach would be to put the different
pieces directly into the class:

  class Foo: # python 3
  def __init__(self, name):
  self.name = name
  def goodbye(self):
  print("goodbye " + self.name)
  def __enter__(self):
  pass
  def __exit__(self, *args, **kwargs):
  self.goodbye()

  foo = Foo("Steve")
  foo.goodbye() # outputs goodbye Steve
  foo.__exit__() # outputs goodbye Steve
  with foo:
  print("doing stuff")

If you want to be more dynamic about it you can do it, but it involves
black magic.  Chances are really good that being explicit through your
class definition is the right approach.

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

Re: Overriding a global

[Jean-Michel Pichavant]

Joshua Landau wrote:

[snip]
Using currentLogger is just padding, in my opinion. *Every *value is 
"current".
Not always. I try to keep names on the same object because that object 
is supposed to be named that way.
I can change one of the object attribute, but the object named that way 
keep being the same.


Class Foo:
 self.__init__(self):
self.banana = 5

myFoo = Foo()

Now there's a slight difference between

myFoo = Exception()
and
myFoo.banana = 4

The first statement rebind myFoo to something complitely different.
the second statement change one of the object rightfully named myFoo .. 
attribute (not sure about this construct :D )


Int being inmutable, you can rebind a name without changing its meaning.



In regards to a second name - yes this could work and in many cases 
would be desirable, but it doesn't really help this circumstance. 
[assume, for a moment, a lot of functions used a local logger] 
"localLogger" would tell you very little about what the logger 
actually /is/. You still have to look that up. [end assumption] 
Additionally, this would make changing a logger that uses the default 
to a local one /much/ harder. And don't say "but you can just always 
make a local copy", as then you lose the advantage of a global.


Typing something like "logger = childLogger(id)" to the start of a 
function call *is explicit*, it's clean, and it makes sense to have a 
default that's global. You're not appending cruft ("current") and you 
have consistency. If you added "logger = globalLogger" to every 
function start as well you can argue that it's better. I agree it's 
more explicit. But then you lose unneeded if only a small portion of 
your code localises logger. But I would recommend it if a large 
portion of code used local variants.


AND:

The next time I'll illustrate meaningful names,  I'll write a 3000
lines function, just to be sure no one states that my point
does'nt apply to a function named spam which only counts from 1 to 3.
And don't answer that the spam function above does not count from
1 to 3, I know it doesn't.


You're acting in sarcasm to a comment on scale, when you yourself said 
that one of my comments was invalid due to names that were scaled down 
for exampling. It seems a bit hypocritical to me. That said, not all 
functions are long. If the short ones use short names that's fine: I'm 
pretty sure you said it's not.


And in regards to the link:
1) __add__ says otherwise (technically, the operator "+"). It's rarely 
confused me.
2) That's not what we're discussing. As it said: "As long as the 
parameter lists are semantically equal and the desired result is the 
same, all is well." They're doing semantically the same thing (to 
different log levels) with the same parameter lists and they're not 
class methods. You /could/ say that the semantics are different, but 
classes act in a context in the same way local variables can be 
thought of doing, and semantics are the same for them. Instead of a 
different self, it's a different log file/level. Same semantics.
I'd like to argue about that but I won't cause I have the feeling my 
lack of ultra precise english would cause me more trouble. Note that I'm 
not blaming anyone but me, no sarcasm inside.


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

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

[Eelco]

'Kindof' off-topic, but what the hell :).

On Dec 14, 5:13 pm, Arnaud Delobelle  wrote:
> On 14 December 2011 12:33, Eelco  wrote:
> > On 14 dec, 12:55, Arnaud Delobelle  wrote:
> >> On 14 December 2011 07:49, Eelco  wrote:
> >> > On Dec 14, 4:18 am, Steven D'Aprano  >> > +comp.lang.pyt...@pearwood.info> wrote:
> >> >> > 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?
>
> >> > The philosophy was just a sidehobby to the study of actual
> >> > mathematics; and you are right, studying their works is the best way
> >> > to get to know them. Speaking from that vantage point, I can say with
> >> > certainty that the vast majority of mathematicians do not have a
> >> > coherent philosophy, and they adhere to some loosely defined form of
> >> > platonism. Indeed that is absurd in a way. Even though you may trust
> >> > these people to be perfectly functioning deduction machines, you
> >> > really shouldnt expect them to give sensible answers to the question
> >> > of which are sensible axioms to adopt. They dont have a reasoned
> >> > answer to this, they will by and large defer to authority.
>
> >> Please come down from your vantage point for a few moments and
> >> consider how insulting your remarks are to people who have devoted
> >> most of their intellectual energy to the study of mathematics.  So
> >> you've studied a bit of mathematics and a bit of philosophy?  Good
> >> start, keep working at it.
>
> > Thanks, I intend to.
>
> >> You think that every mathematician should be preoccupied with what
> >> axioms to adopt, and why?
>
> > Of course I dont. If you wish to restrict your attention to the
> > exploration of the consequences of axioms others throw at you, that is
> > a perfectly fine specialization. Most mathematicians do exactly that,
> > and thats fine. But that puts them in about as ill a position to
> > judged what is, or shouldnt be defined, as the average plumber.
>
> You are completely mistaken.  Whatever the axiomatisation of the
> mathematics that we do, we can still do the same mathematics.  We
> don't even need an axiomatic basis to do mathematics.  In fact, the
> formalisation of mathematics has always come after the mathematics
> were well established.    Euclid, Dedekind, Peano, Zermelo, Frankael,
> didn't create axiomatic systems out of nothing.  They axiomatised
> pre-existing theories.
>
> Axiomatising a theory is just one way of exploring it.

Yes, axiomization is to some extent a side-show. We know what it is
that we want mathematics to be, and we try to find the axioms that
lead to those conclusions. Not qualitatively different from any other
form of induction (of the epistemological rather than mathematical
kind). Still, different axioms or meta-mathematics give subtly
different results, not to mention are as different to work with as
assembler and haskell. There are no alephs if you start from a
constructive basis, for instance.

Im not sure what 'Axiomatising a theory is just one way of exploring
it' means. One does not axiomatize a single theory; that would be
trivial (A is true because thats what I define A to be). One
constructs a single set of axioms from which a nontrivial set of
theorems follow.

The way id put it, is that axiomazation is about being explicit in
what it is that you assume, trying to minimalize that, and being
systematic about what conclusions that forces you to embrace.

Could you be more precise as to how I am 'completely mistaken'? I
acknowledge that my views are outside the mainstream, so its no news
to me many would think so, but it would be nice to know what im
arguing against in this thread precisely.

> > Compounding the problem is not just that they do not wish to concern
> > themselves with the inductive aspect of mathematics, they would like
> > to pretend it does not exist at all. For instance, if you point out to
> > them a 19th century mathematician used very different axioms than a
> > 20th century one, (and point out they were both fine mathematicians
> > that attained results universally celebrated), they will typically
> > respond emotionally; get angry or at least annoyed. According to their
> > pseudo-Platonist philosophy, mathematics should not have an inductive
> > side, axioms are set in stone and not a human affair, and the way they
> > answer the question as to where knowledge about the 'correct'
> > mathematical axioms comes from is by an implicit or explicit ap

Re: AttributeError in "with" statement (3.2.2)

[Steve Howell]

On Dec 14, 12:01 am, Steven D'Aprano  wrote:
> [...]
>
> So the normal lookup rules that apply to data attributes, namely
> instance, then class, then superclasses, also applies to methods in
> Python. In languages that don't allow that sort of thing, like Java, you
> need to use convoluted design patterns like Dynamic Proxy to make it
> work. In Python, you just create a method and attach it on the instance.
>
> http://stackoverflow.com/questions/8260740/override-a-method-for-an-
> instance-of-a-class
>
> But this doesn't apply for special dunder attributes like __exit__, for
> speed reasons. (For new-style classes only, classic classes have no such
> special casing. This makes automatic delegation a breeze in Python 2 with
> classic classes, and a PITA in Python 3. Boo hiss.)


Thanks to all who responded.  Basically, I think the special casing of
the "dunder" attributes threw me off.

Typically, I would just build context managers from a class, but I
wanted to experiment with instances that were built up without the
standard Python class mechanisms, instead following a Javascript-like
closure-based object creation model.

This is what I came up with:

class WithWrapper:
  def __init__(self, obj):
self.obj = obj
  def __enter__(self):
self.obj['enter']()
  def __exit__(self, *args):
self.obj['exit'](*args)

def greeter_context(hello, goodbye):
  return {
'enter': lambda: print("---\n" + hello),
'exit': lambda *args: print(goodbye)
  }

gc_french = greeter_context("salut", "a plus tard")

with WithWrapper(gc_french):
  print("doing stuff")

gc_slang = greeter_context("yo", "later")
with WithWrapper(gc_slang):
  print("doing stuff")
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to install Python on Debian GNU/Linux (Python-2.7.2.tar.bz2)

[Anssi Saari]

Christian Heimes  writes:

>> Mea culpa, forgot that. Yes, use altinstall. Although it's probably
>> not a problem to replace 2.6.6 with 2.7.2 - I doubt that'll break many
>> things.
>
> Except that all 3rd party extensions and packages are missing if you
> install Python manually.

True, they would have to be built or at least installed manually also.
Major work, especially for a beginner. Shouldn't pick Debian Stable and
then want current software...

Then again, even the standard install of Python has plenty of stuff. I
installed 2.7.2 on my Debian system just to try out some of the new Tk
stuff.

> Debian's backports should provide a well integrated Python 2.7
> package.

But it doesn't. Python 2.7.2 is in Wheezy, which is the current testing
version of Debian. Looks like it has about 700 release critical bugs, so
it'll be a while until release.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: AttributeError in "with" statement (3.2.2)

[Lie Ryan]

On 12/15/2011 03:56 AM, Eric Snow wrote:

On Tue, Dec 13, 2011 at 11:05 PM, Eric Snow  wrote:

If you want to be more dynamic about it you can do it, but it involves
black magic.  Chances are really good that being explicit through your
class definition is the right approach.


Note that the black spice is to use the __class__ attribute:

foo.__class__.__exit__ = foo.goodbye


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

What is this widget?

[Muddy Coder]

Hi Folks,

I am trying to write letters on a photo that is opened in a canvas. So
I think I must need a widget to contain the letters I will type in. I
tried to use a Label, it worked. But, a Label covered part of the
photo underneath, so I can't use it. I saw some software did such a
thing nicely: a box popped on a photo, with dotted lines as borders,
expandable. When such a box was re-sized with a mouse, the font size
in the box also got changed. The box has no background color, so it
does not cover a rectangle area on the photo. I need such a widget,
but I don't know what is this one. I tried Text, Label, but they all
come with Window-like stuff, so they cover some photo content. Can
somebody points me a direction? Thanks!


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

Re: AttributeError in "with" statement (3.2.2)

[Eric Snow]

On Wed, Dec 14, 2011 at 12:14 PM, Lie Ryan  wrote:
> On 12/15/2011 03:56 AM, Eric Snow wrote:
>>
>> On Tue, Dec 13, 2011 at 11:05 PM, Eric Snow
>>  wrote:
>>
>> If you want to be more dynamic about it you can do it, but it involves
>> black magic.  Chances are really good that being explicit through your
>> class definition is the right approach.
>
>
> Note that the black spice is to use the __class__ attribute:
>
> foo.__class__.__exit__ = foo.goodbye

Good point.  'type(foo).__exit__ ...' might be even better.
Regardless, to get the dynamicism to which Steve originally referred
(make it work when added directly to the instance), you have to use a
metaclass, which is black magic[1].  However, rarely is that sort of
thing needed, so the relatively superfluous details would likely only
cloud the question at hand.

-eric

[1] I will point out that metaclasses aren't really all that bad.
They are a tool worth understanding, even if you don't use them all
the time.  Understanding them also opens up a whole new world of
understanding how Python works, particularly regarding name lookup.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is this widget?

[Dave Angel]

On 12/14/2011 01:47 PM, Muddy Coder wrote:

Hi Folks,

I am trying to write letters on a photo that is opened in a canvas. So
I think I must need a widget to contain the letters I will type in. I
tried to use a Label, it worked. But, a Label covered part of the
photo underneath, so I can't use it. I saw some software did such a
thing nicely: a box popped on a photo, with dotted lines as borders,
expandable. When such a box was re-sized with a mouse, the font size
in the box also got changed. The box has no background color, so it
does not cover a rectangle area on the photo. I need such a widget,
but I don't know what is this one. I tried Text, Label, but they all
come with Window-like stuff, so they cover some photo content. Can
somebody points me a direction? Thanks!


Cosmo
I don't have an answer, but it'd be much easier for others if you 
specified what gui toolkit you're using, and probably also the OS and 
Python versions.



--

DaveA

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

replacing timestamps in file [newbie]

[nukeymusic]

I have a file which has the data in the following format:
Dec-13-09:46:45 21.4 +4.76442190E-01 8.135530E-06 1.553691E+00
Dec-13-09:47:12 21.4 +4.76439120E-01 8.135839E-06 1.553726E+00
Dec-13-09:47:39 21.4 +4.76427260E-01 8.136261E-06 1.553853E+00
.
.
the first field is a timestamp, I'd like to replace it with the time
in seconds starting from the first one like this:
0 21.4 +4.76442190E-01 8.135530E-06 1.553691E+00
27 21.4 +4.76439120E-01 8.135839E-06 1.553726E+00
54 21.4 +4.76427260E-01 8.136261E-06 1.553853E+00

Is there a function in python to achieve this?

thanks in advance

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

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

[Terry Reedy]

On 12/14/2011 5:09 AM, Eelco wrote:


Arguably, the most elegant thing to do is to define integer division
and remainder as a single operation;


It actually is, as quotient and remainder are calculated together. The 
microprocessors I know of expose this (as does Python). 'a divmod b' 
puts the quotient in one register and the remainder in another. If you 
ask for just one of the two values, both are calculated and one is 
grabbed while the other is returned.



which is not only the logical
thing to do mathematically, but might work really well
programmatically too.

The semantics of python dont really allow for this though. One could
have:

d, r = a // b


>>> a,b = divmod(10,3)
>>> a,b
(3, 1)

With CPython, int.__divmod__ lightly wraps and exposes the processor 
operation.



But it wouldnt work that well in composite expressions; selecting the
right tuple index would be messy and a more verbose form would be
preferred.


That is why we have
>>> a == 10 // 3
True
>>> b == 10 % 3
True

In both cases, I believe CPython calls int.__divmod__ (or the lower 
level equivalent) to calculate both values, and one is returned while 
the other is ignored. It it the same when one does long division by hand.



However, performance-wise its also clearly the best
solution, as one often needs both output arguments and computing them
simultaniously is most efficient.


As indicated above, there is really no choice but to calculate both at 
once. If one needs both a//b and a%b, one should explicitly call divmod 
once and save (name) both values, instead of calling it implicitly twice 
and tossing half the answer each time.


--
Terry Jan Reedy

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

Re: replacing timestamps in file [newbie]

[Miki Tebeka]

You can either work with datetime module (see datetime.datetime.strptime) or 
with the time module (see time.strptime and time.mktime)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: replacing timestamps in file [newbie]

[Chris Angelico]

On Thu, Dec 15, 2011 at 7:32 AM, nukeymusic  wrote:
> I have a file which has the data in the following format:
> Dec-13-09:46:45 21.4 +4.76442190E-01 8.135530E-06 1.553691E+00
>
> the first field is a timestamp, I'd like to replace it with the time
> in seconds starting from the first one like this:
> 27 21.4 +4.76439120E-01 8.135839E-06 1.553726E+00

You're looking for several things here, all of which Python can do.
I'll give you a few pointers - have a browse of the documentation.

1) Reading a file line-by-line is usually best done with the iterator
idiom. Open your file with the "open()" function, read in any headers,
and then use "for line in inputfile:" to loop over the data.

2) Parse the line into separate pieces using the split() and join()
methods of the string object

3) Use the time.strptime() function to convert the string date into
something more usable

4) Maintain a variable with "previous time" and take the difference each time.

5) Write the modified lines to another file.

Python's pretty good with this sort of job. It won't let you down!

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

file data => array(s)

[Eric]

I'm trying to read some file data into a set of arrays.  The file data
is just four columns of numbers, like so:

   1.22.2   3.3  0.5
   0.1   0.21.0  10.1
   ... and so on

I'd like to read this into four arrays, one array for each column.
Alternatively, I guess something like this is okay too:

   [[1.2, 2.2, 3.3, 0.5], [0.1, 0.2, 1.0, 10.1], ... and so on]

I came up with the following for the four array option:

   file = open(fileName, 'r')
   for line in file.readlines():
  d1, e1, d2, e2 = map(float, line.split())
  data1.append(d1)  # where data1, err1, data2, err2 are init-ed
as empty lists
  err1.append(e1)
  data2.append(d2)
  err2.append(e2)
   file.close()

But somehow it doesn't seem very python-esque (I'm thinking there's a
more elegant and succinct way to do it in python).  I've also tried
replacing the above "map" line with:

  d = d + map(float, line.split())  # where d is initialized as d
= []

But all I get is one long flat list, not what I want.

So is the map and append method the best I can do or is there a
slicker way?

One more thing, no numpy.  Nothing against numpy but I'm curious to
see what can be done with just the box stock python install.

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

Re: file data => array(s)

[Dave Angel]

On 12/14/2011 05:20 PM, Eric wrote:

I'm trying to read some file data into a set of arrays.  The file data
is just four columns of numbers, like so:

1.22.2   3.3  0.5
0.1   0.21.0  10.1
... and so on

I'd like to read this into four arrays, one array for each column.
Alternatively, I guess something like this is okay too:

[[1.2, 2.2, 3.3, 0.5], [0.1, 0.2, 1.0, 10.1], ... and so on]

I came up with the following for the four array option:

file = open(fileName, 'r')
for line in file.readlines():
The readlines() call is a waste of time/space.  file is already an 
iterator that'll return lines for you.

   d1, e1, d2, e2 = map(float, line.split())
   data1.append(d1)  # where data1, err1, data2, err2 are init-ed
as empty lists
   err1.append(e1)
   data2.append(d2)
   err2.append(e2)
file.close()

But somehow it doesn't seem very python-esque (I'm thinking there's a
more elegant and succinct way to do it in python).  I've also tried
replacing the above "map" line with:

   d = d + map(float, line.split())  # where d is initialized as d
= []

But all I get is one long flat list, not what I want.

So is the map and append method the best I can do or is there a
slicker way?

One more thing, no numpy.  Nothing against numpy but I'm curious to
see what can be done with just the box stock python install.

TIA,
eric
When I see a problem like this, I turn to zip().  It's got some powerful 
uses when rows and columns need inverting.


I didn't try it on an actual file, but the following works:
linedata =[[1.2, 2.2, 3.3, 0.5], [0.1, 0.2, 1.0, 10.1] ]

data, err1, data2, err2 = zip(*linedata)

print data
print err1
print data2
print err2

So you could try (untested)

file = open(filename, "r")
linedata = [ map(float, line) for line in file]
data, err1, data2, err2 = zip(*linedata)
file.close()

Note that your code won't work (and mine probably won't either) if one 
of the lines has 3 or 5 items.  Or if one of the numbers isn't legal 
format for a float.  So you need to think about error checking, or 
decide whether a partial result is important.


--

DaveA

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

Re: AttributeError in "with" statement (3.2.2)

[Terry Reedy]

On 12/14/2011 3:01 AM, Steven D'Aprano wrote:

On Wed, 14 Dec 2011 01:29:13 -0500, Terry Reedy wrote:


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.


I'm not sure that is correct... I don't think that there is anything "by
definition" about where methods live.


From the Python glossary:
"method: A function which is defined inside a class body."

That is actually a bit too narrow, as a function can be added to the 
class after it is defined. But the point then is that it is treated as 
if defined inside the class body.



Particularly not in Python where
instance methods can be attributes of the instance itself.


This is access, not definition or actual location. The glossary entry go 
on to say: "If called as an attribute of an instance of that class, the 
method will get the instance object as its first argument (which is 
usually called self)." This does *not* happen if a callable is found in 
the instance-specific dictionary. An instance method is a function 
(callable) attribute of a class that gets special treatment when 
accessed (indirectly) through an instance of that class (or subclass 
thereof).



class Test(object):

... def method(self):
... print("This method is an attribute of the class.")
...

t = Test()
t.method()

This method is an attribute of the class.


The bound method t.method is an instance the class exposed as 
types.MethodType. In other words, isinstance(t.method, types.MethodType) 
== True



import types
t.method = types.MethodType(

... lambda self: print(
... "This method is an attribute of the instance."), t)


Calling any old fruit an apple does not make it one.
Calling any old function a method does not make it one.

'types.MethodType' is the exposed name of the class the interpreter uses 
to create bound methods from a method and an instance of the class 
containing the method. I believe the interpreter does an isinstance 
check, but it must do that before calling the class, and not in the 
bound method constructor itself. In any case, a bound method is not a 
method. So the printed statement is not true.


In this case, the result is not really even a bound method, as the 
function argument is not a method, so we cannot even ask if the second 
arg is an instance of the function class container.  MethodType is a 
special case of functools.partial, which was added later. You could have 
used the latter to the same effect. Or you could have used any old 
function that printed the same thing.


There is no relation between the object passed as the second arg of 
MethodType and what you do with the resulting callable. Either 't' could 
be something else. See below.



t.method()

This method is an attribute of the instance.


Yes, the callable (which is not a method) is (currently) an attribute of 
the instance. But that is irrelevant to its operation. t.method is just 
a callable, in particular, a pseudo bound method, not a method. It is 
*not* supplying the instance it is called on as the first parameter of 
the callable. The arguemnt (which is not used) has already been 
supplied. These produce the same output:


class B: pass
b = B()
b.method = t.method
b.method()

f = t.method
f()

t.method = lambda:  print("This method is an attribute of the instance.")
t.method()


So the normal lookup rules that apply to data attributes, namely
instance, then class, then superclasses, also applies to methods in
Python.


When you ask the interpreter to resolve a.x, x is just a supposed 
attribute, and the interpreter has no idea what class the result should be.



But this doesn't apply for special dunder attributes like __exit__, for
speed reasons.


It does not apply to dunder *methods* because they are reserved names 
defined to be (bound to) methods. So the interpreter knowing that it is 
looking for a method and that methods have to be attributes of classes, 
goes directly to the class.


--
Terry Jan Reedy

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

Re: What is this widget?

[Terry Reedy]

On 12/14/2011 1:47 PM, Muddy Coder wrote:

Hi Folks,

I am trying to write letters on a photo that is opened in a canvas. So
I think I must need a widget to contain the letters I will type in. I
tried to use a Label, it worked. But, a Label covered part of the
photo underneath, so I can't use it.


You could use a entry widget over or outside the canvas for the user to 
enter the text, and then close that box and write the entered text to 
the canvas. Whether you can make the background of the entry box 
transparent probably depends on the gui toolkit.


--
Terry Jan Reedy

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

Re: file data => array(s)

[Eric]

On Dec 14, 4:59 pm, Dave Angel  wrote:

> Note that your code won't work (and mine probably won't either) if one
> of the lines has 3 or 5 items.  Or if one of the numbers isn't legal
> format for a float.  So you need to think about error checking, or
> decide whether a partial result is important.
>
> --
>
> DaveA


Haven't tried your suggestion yet, I just wanted to comment on this
last part real quick.  I have the same concern, my plan is to wrap all
that stuff up in a "try:" construct.  In such cases the program only
has to kick out a simple, sensible (for non-programmers) error message
and quit.

BTW, I didn't say it originally, but this is for 2.7 and hopefully
it'll be easy to carry over to 3.2.

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

Re: file data => array(s)

[Steven D'Aprano]

On Wed, 14 Dec 2011 14:20:40 -0800, Eric wrote:

> I'm trying to read some file data into a set of arrays.  The file data
> is just four columns of numbers, like so:
> 
>1.22.2   3.3  0.5
>0.1   0.21.0  10.1
>... and so on
> 
> I'd like to read this into four arrays, one array for each column.
> Alternatively, I guess something like this is okay too:
> 
>[[1.2, 2.2, 3.3, 0.5], [0.1, 0.2, 1.0, 10.1], ... and so on]

First thing: due to the fundamental nature of binary floating point 
numbers, if you convert text like "0.1" to a float, you don't get 0.1, 
you get 0.10001. That is because 0.1000...01 is the closest 
possible combination of fractions of 1/2, 1/4, 1/8, ... that adds up to 
1/10.

If this fact disturbs you, you can import the decimal module and use 
decimal.Decimal instead; otherwise forget I said anything and continue 
using float. I will assume you're happy with floats.

Assuming the file is small, say, less than 50MB, I'd do it like this:


# Version for Python 2.x
f = open(filename, 'r')
text = f.read()  # Grab the whole file at once.
numbers = map(float, text.split())
f.close()

That gives you a single list [1.2, 2.2, 3.3, 0.5, 0.1, 0.2, ...] which 
you can now split into groups of four. There are lots of ways to do this. 
Here's an inefficient way which hopefully will be simple to understand:

result = []
while numbers != []:
result.append(numbers[0:4])
del numbers[0:4]


Here is a much more efficient method which is only a tad harder to 
understand:

result = []
for start in range(0, len(numbers), 4):
result.append(numbers[start:start+4])


And just for completeness, here is an advanced technique using itertools:

n = len(numbers)//4
numbers = iter(numbers)
from itertools import islice
result = [list(islice(numbers, 4)) for i in range(n)]

Be warned that this version throws away any partial group left over at 
the end; if you don't want that, change the line defining n to this 
instead:

n = len(numbers)//4 + (len(numbers)%4 > 0)


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

PyCharm, .idea, and source control

[alex23]

Hey everyone,

I've been using PyCharm for the past month and only just hit an issue
that I'm hoping someone else may have some experience with resolving.
My problem has to do with PyCharm storing project configuration files
in its .idea folder inside the project.

This is both a mix of project-level settings and individual
customisations. The recommendation is to check this folder into the
repo as well  - excluding the files of individual settings - but I'm
the only developer here using PyCharm and polluting the project with
one user's settings would not be received well. More so, even if I
_did_ this, I'd still need to be storing my individual settings
elsewhere.

So what I'm currently doing is having git ignore the .idea folder, and
then subsequently turning the folder into its own repo and storing it
separately. Ideally I'd just like to be able to have all of the
project-config folders in one user-definable location, but I haven't
found any way to do that.

Has any one else hit this issue, and if so, any tips of resolving it
elegantly?
-- 
http://mail.python.org/mailman/listinfo/python-list

What is this widget? -- again

[Muddy Coder]

Hi Folks,

Sorry for the unclear question in last post. Well, I am using Tkinter
to do GUI, and I just don't know what kind of widget can let me do
annotation on an image being displayed. An example is the Paint of
Windows: a dotted line box appearing on a image to hold a typed in
text. I just can't figure out what widget in Tkinter is equivalent to
that dotted line box. Please help, thanks again!


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

How to use a color value returned by colorChooser?

[Muddy Coder]

Hi Folks,

This should be a simple question, but I just can't get an answer from
Phython Docs. You see, when we created a widget, and need to tweak the
color, we just simply configure it, such as:

abutton = Button(root, text='Foo')
abutton.config(fg='blue')

so we can make the Button color in blue. However, when I choose a
color by a color Dialog, askcolor, and then I will get a color value
as:   (0, 0, 255) . So, I want to use this returned color value to
configure my existing widgets, with widget.config() syntax. The Python
interpreter does not take it. Therefore, I think I must need to covert
this returned color value into a symbolic name, such as 'blue', 'red'
and so on, then the widget.config() syntax can be used. How can I
convert this color value? Please help, thanks folks!

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

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

[rusi]

On Dec 14, 10:15 pm, Eelco  wrote:
> 'Kindof' off-topic, but what the hell :).


We keep having these debates -- so I wonder how off-topic it is...
And so do famous CSists:
http://research.microsoft.com/en-us/um/people/gurevich/opera/123.pdf


:
:
> > Again, you are completely mis-representing the situation.  In my
> > experience, most mathematicians (I'm not talking about undergraduate
> > students here) do not see the axioms are the root of the mathematics
> > that they do.  Formal systems are just one way to explore mathematics.
> >  Of course they can in some cases be very useful and enlightening.
>
> Its your word versus mine I suppose.

Some older discussions:

http://groups.google.com/group/comp.lang.python/browse_thread/thread/46435c36f3a13621/896579b757126243?lnk=gst&q=rusi+steven+platonism#896579b757126243

http://groups.google.com/group/comp.lang.python/browse_thread/thread/d36dcd2e2e175d1e/45dd596bc050ac2d?lnk=gst&q=rusi+steven+platonism#45dd596bc050ac2d
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to use a color value returned by colorChooser?

[MRAB]

On 15/12/2011 02:26, Muddy Coder wrote:

Hi Folks,

This should be a simple question, but I just can't get an answer from
Phython Docs. You see, when we created a widget, and need to tweak the
color, we just simply configure it, such as:

abutton = Button(root, text='Foo')
abutton.config(fg='blue')

so we can make the Button color in blue. However, when I choose a
color by a color Dialog, askcolor, and then I will get a color value
as:   (0, 0, 255) . So, I want to use this returned color value to
configure my existing widgets, with widget.config() syntax. The Python
interpreter does not take it. Therefore, I think I must need to covert
this returned color value into a symbolic name, such as 'blue', 'red'
and so on, then the widget.config() syntax can be used. How can I
convert this color value? Please help, thanks folks!


Look here:

http://effbot.org/tkinterbook/tkinter-widget-styling.htm
--
http://mail.python.org/mailman/listinfo/python-list

Re: AttributeError in "with" statement (3.2.2)

[Steven D'Aprano]

On Wed, 14 Dec 2011 18:13:36 -0500, Terry Reedy wrote:

> On 12/14/2011 3:01 AM, Steven D'Aprano wrote:
>> On Wed, 14 Dec 2011 01:29:13 -0500, Terry Reedy wrote:
>>
>>> 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.
>>
>> I'm not sure that is correct... I don't think that there is anything
>> "by definition" about where methods live.
> 
>  From the Python glossary:
> "method: A function which is defined inside a class body."
> 
> That is actually a bit too narrow, as a function can be added to the
> class after it is defined. But the point then is that it is treated as
> if defined inside the class body.

First off, let me preface this by saying that I'm not necessarily saying 
that the above glossary definition needs to be changed. For most 
purposes, it is fine, since *nearly always* methods are created as 
functions defined inside the class body. But it needs to be understood in 
context as a simplified, hand-wavy definition which covers 99% of the 
common cases, and not a precise, definitive technical definition.

To give an analogy, it is like defining mammals as "hairy animals which 
give birth to live young", which is correct for all mammals except for 
monotremes, which are mammals which lay eggs.

So I'm happy for the glossary entry to stay as is, because complicating 
it would confuse the average coder more than it would educate them.

But the definition as given is strictly wrong, because it fails to 
capture the essence of what distinguishes a method from other objects. It 
mistakes *how* you normally create a method for *what* a method is, a 
little like defining "a hamburger is a foodstuff you get from McDonalds 
by giving them money".

Here are three ways that the definition fails:

(1) You can create a function inside a class, and it remains a function, 
so long as the class constructor (metaclass) never gets to build a method 
object from the function. It is easy to do: just hide it inside a wrapper 
object.

>>> class FunctionInsideClass(object):
... def func(x, y):  # define a function inside a class
... return x + 2*y
... print(type(func))  # confirm is actually is a function
... attr = (func,)  # hide it from the metaclass
... del func
... 

>>> print(type(FunctionInsideClass.attr[0]))



(2) Instead of hiding the function from the metaclass, you can change the 
metaclass to something which doesn't make methods out of functions. I 
won't show an example, because it's tricky to get right (or at least *I* 
find metaclasses tricky).


(3) So the definition is too broad: you can have functions defined inside 
classes that are not methods. But it is also too narrow: you can have 
methods outside of classes. I'm not talking about bound and unbound 
methods, but about *creating* the method from scratch outside of a class. 
When you call the method constructor directly, you can create a method 
from a function defined outside of a class.

>>> def func(self, a):
... return self + a
... 
>>> type(func)  # Definitely a function.

>>> obj = types.MethodType(func, 42)
>>> obj(23)  # Works as expected.
65
>>> type(obj)


So there's a method which has never been inside a class, and couldn't 
even if you tried: int is a built-in immutable type.


So what are methods? In Python, methods are wrappers around functions 
which automatically pass the instance to the inner function object. Under 
normal circumstances, you create methods by declaring functions inside a 
class, but that's not the only way to create methods, and it is not the 
only place they can be found.

Note that this definition can easily be adapted to describe class methods 
and static methods too: class methods are wrappers around functions that 
automatically pass the class to the inner function, and static methods 
are wrappers which don't pass any automatic arguments.


>> Particularly not in Python where
>> instance methods can be attributes of the instance itself.
> 
> This is access, not definition or actual location. 

Not so. In the example I gave, the method *really is* inside the 
instance, stored in the instance __dict__ and not the class __dict__.


> The glossary entry go
> on to say: "If called as an attribute of an instance of that class, the
> method will get the instance object as its first argument (which is
> usually called self)." This does *not* happen if a callable is found in
> the instance-specific dictionary.

That's right. Methods are special not because of where they are, but 
because of what they are.


> An instance method is a function
> (callable) attribute of a class that gets special treatment when
> accessed (indirectly) through an instance of that class (or subclass
> thereof).

Methods aren't functions at all, not in the isinstance sense. They are 
functions in the

Re: AttributeError in "with" statement (3.2.2)

[MRAB]

On 15/12/2011 05:01, Steven D'Aprano wrote:

On Wed, 14 Dec 2011 18:13:36 -0500, Terry Reedy wrote:


 On 12/14/2011 3:01 AM, Steven D'Aprano wrote:

 On Wed, 14 Dec 2011 01:29:13 -0500, Terry Reedy wrote:


 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.


 I'm not sure that is correct... I don't think that there is anything
 "by definition" about where methods live.


   From the Python glossary:
 "method: A function which is defined inside a class body."

 That is actually a bit too narrow, as a function can be added to the
 class after it is defined. But the point then is that it is treated as
 if defined inside the class body.


First off, let me preface this by saying that I'm not necessarily saying
that the above glossary definition needs to be changed. For most
purposes, it is fine, since *nearly always* methods are created as
functions defined inside the class body. But it needs to be understood in
context as a simplified, hand-wavy definition which covers 99% of the
common cases, and not a precise, definitive technical definition.

To give an analogy, it is like defining mammals as "hairy animals which
give birth to live young", which is correct for all mammals except for
monotremes, which are mammals which lay eggs.


[snip]
Or the naked mole-rat. Or cetaceans (whales).
--
http://mail.python.org/mailman/listinfo/python-list

using twisted as a client-server hybrid

[Littlefield, Tyler]

Hello all:
I have a quick question--I am working on a project where a system will 
connect to me to get commands. The idea is to make the server the 
"client," used for dispatching commands, so  I'm trying to find a way 
that I can set it up to listen, but poll stdin somehow for input. Is 
this a possibility?


--

Take care,
Ty
Web: http://tds-solutions.net
The Aspen project: a light-weight barebones mud engine
http://code.google.com/p/aspenmud

Sent from my toaster.

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

Re: AttributeError in "with" statement (3.2.2)

[Steven D'Aprano]

On Thu, 15 Dec 2011 05:15:58 +, MRAB wrote:

> On 15/12/2011 05:01, Steven D'Aprano wrote:
>> On Wed, 14 Dec 2011 18:13:36 -0500, Terry Reedy wrote:
>>
>>>  On 12/14/2011 3:01 AM, Steven D'Aprano wrote:
  On Wed, 14 Dec 2011 01:29:13 -0500, Terry Reedy wrote:

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

  I'm not sure that is correct... I don't think that there is anything
  "by definition" about where methods live.
>>>
>>>From the Python glossary:
>>>  "method: A function which is defined inside a class body."
>>>
>>>  That is actually a bit too narrow, as a function can be added to the
>>>  class after it is defined. But the point then is that it is treated
>>>  as if defined inside the class body.
>>
>> First off, let me preface this by saying that I'm not necessarily
>> saying that the above glossary definition needs to be changed. For most
>> purposes, it is fine, since *nearly always* methods are created as
>> functions defined inside the class body. But it needs to be understood
>> in context as a simplified, hand-wavy definition which covers 99% of
>> the common cases, and not a precise, definitive technical definition.
>>
>> To give an analogy, it is like defining mammals as "hairy animals which
>> give birth to live young", which is correct for all mammals except for
>> monotremes, which are mammals which lay eggs.
>>
> [snip]
> Or the naked mole-rat. Or cetaceans (whales).

Naked mole-rats and cetaceans do have hair, just not very much of it.

E.g. http://marinelife.about.com/od/cetaceans/f/whaleshair.htm




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

Re: using twisted as a client-server hybrid

[Chris Angelico]

On Thu, Dec 15, 2011 at 6:14 PM, Littlefield, Tyler  wrote:
> Hello all:
> I have a quick question--I am working on a project where a system will
> connect to me to get commands. The idea is to make the server the "client,"
> used for dispatching commands, so  I'm trying to find a way that I can set
> it up to listen, but poll stdin somehow for input. Is this a possibility?

One easy way to do that is to use separate threads, one to watch stdin
(preferably the main thread) and one to listen on the socket or
whatever the other end uses. Another option is to use async calls and
callbacks. But to answer your simplest question, yes, it most
definitely is.

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

Re: AttributeError in "with" statement (3.2.2)

[Steven D'Aprano]

On Thu, 15 Dec 2011 05:01:21 +, Steven D'Aprano wrote:

>>  From the Python glossary:
>> "method: A function which is defined inside a class body."
>> 
>> That is actually a bit too narrow, as a function can be added to the
>> class after it is defined. But the point then is that it is treated as
>> if defined inside the class body.
[...]
> But the definition as given is strictly wrong, because it fails to
> capture the essence of what distinguishes a method from other objects.
[...]

TL;DR

http://users.rcn.com/python/download/Descriptor.htm#functions-and-methods

Short and sweet.



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