Re: Comparison operators in Python

[Terry Reedy]

On 6/1/2011 8:44 PM, harrismh777 wrote:

Ian Kelly wrote:


>> ?? wrote

integer. However comparison between a string and an integer seems to
be permitted. Is there any rationale behind this ?



It allows things like sorting of heterogeneous lists. It's generally
viewed as a wart, though, and it was fixed in Python 3:


This was a Python 1.0 idea that Guido decided was more bug-inducing than 
useful.



Just another example (excluding print 1/2 and unicode) where 3.x seems
to be completely compatible with 2.x/ (tongue-in-cheek)


Arbitrary comparisons were broken and effectively deprecated about a 
decade ago with the introduction of the complex type. Just another 
example where 3.x completes a process of change started years before.


--
Terry Jan Reedy

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

Re: Something is rotten in Denmark...

[Terry Reedy]

On 6/1/2011 8:40 PM, harrismh777 wrote:


The part that I don't see much about in the docs (some books, that is)
is that the lambda lookups occur late (the lambda is evaluated at the
time it is called). The Python docs on-line *do say* this (I found too
late) but its one quick phrase that can be missed. So, the i in
range(10) is sitting there at '9' by the time *any* of the ten lambdas
get called. This is not intuitive, nor good. IMHO


I readily admit that the docs might be improved. Part of the reason I 
spend time responding to issues like this is to practive giving 
explanations that I might use in my own writings or even in the doc. I 
have at least one small idea already.



Yes, I can explicitly grab each 'i' as it flies by with a little clever
coding of the default value for the lambda n, i=i: i + n but that
'trick' is not intuitive, nor is it clear reading. It 'works' is just
about all one can say for it (not very elegant).


You found the alternative of using a closure (the g(i) that returns a 
*new* function for each i). You happened to use lambda to create each 
new function; a nested def statement would have served just as well. 
Replacing the default arg trick was one of the reasons to introduce 
closures (in about 2.3). It might be considered the recommended solution 
to this use case.



work. I'm wondering if whether it would make some sense to put some
'binding smarts' into the interpreter to allow for 'interpreter
intuition' (say AI ) that would presume to understand when early vs late
binding makes sense and apply early binding in those cases where the
context is not ambiguous and when it is clear that an iterable is being
passed to the constant lambda function?


Oh the irony of this proposal. You scolded us for breaking code with 2 
to 3 changes, and here you propose a change more radical than anything 
done in Python 3, and certain to break code, introduce bugs, complicate 
the language, and reduce its functionality. Most of Guido's design 
decision are rejections of such changes ;-).


--
Terry Jan Reedy

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

Re: float("nan") in set or as key

[Steven D'Aprano]

On Wed, 01 Jun 2011 13:41:15 -0700, Carl Banks wrote:

> On Wednesday, June 1, 2011 11:10:33 AM UTC-7, Ethan Furman wrote:
>> Carl Banks wrote:
>> > For instance, say you are using an implementation that uses
>>  > floating point, and you define a function that uses Newton's method
>>  > to find a square root:
>> > 
>> > def square_root(N,x=None):
>> > if x is None:
>> > x = N/2
>> > for i in range(100):
>> > x = (x + N/x)/2
>> > return x
>> > 
>> > It works pretty well on your floating-point implementation.
>>  > Now try running it on an implementation that uses fractions by
>>  > default
>> > 
>> > (Seriously, try running this function with N as a Fraction.)
>> 
>> Okay, will this thing ever stop?  It's been running for 90 minutes now.
>>   Is it just incredibly slow?
>> 
>> Any enlightenment appreciated!
> 
> Fraction needs to find the LCD of the denominators when adding; but LCD
> calculation becomes very expensive as the denominators get large (which
> they will since you're dividing by an intermediate result in a loop).  I
> suspect the time needed grows exponentially (at least) with the value of
> the denominators.
> 
> The LCD calculation should slow the calculation down to an astronomical
> crawl well before you encounter memory issues.
> 
> This is why representation simply cannot be left as an implementation
> detail; rationals and floating-points behave too differently.

True. Any rational implementation that has any hope of remaining fast has 
to limit the denominator to not exceed some fixed value.

Which makes it roughly equivalent to a float, only done in software with 
little hardware support.

(In case it's not obvious: floats are equivalent to implicit rationals 
with a scaling factor and denominator equal to some power of two.)

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

Re: Something is rotten in Denmark...

[Steven D'Aprano]

On Wed, 01 Jun 2011 19:40:30 -0500, harrismh777 wrote:

> The part that I don't see much about in the docs (some books, that is)
> is that the lambda lookups occur late (the lambda is evaluated at the
> time it is called). The Python docs on-line *do say* this (I found too
> late) but its one quick phrase that can be missed. So, the i in
> range(10) is sitting there at '9' by the time *any* of the ten lambdas
> get called. This is not intuitive, nor good. IMHO

I agree it's not intuitive. But where does it say that programming 
language semantics must always be intuitive? Whose intuition? Mine? 
Yours? Linus Torvalds'? Donald Knuth's? My auntie Rose's?


> Please allow me to whine a little bit, ... but the *whole point* of
> iterating is to be able to implicitly grab each iterated value as it
> flies by (by the lambda or anything else!) and there is not much point
> to having a 'late-binding' on an iterable particularly range(n).

What do you expect this code to do?

a = 42
funcs = [(lambda x: x+a) for i in range(10)]
funcs[0](1)

a = 23
funcs[0](1)


Do you agree that `a` should be late bound in this situation?

If so, why do you think that `i` should be early bound here?

funcs = [(lambda x: x+i) for i in range(10)]


Oh, the fact that it works at all in Python 2.5 is a side-effect of i 
leaking from the list comprehension:

>>> funcs = [(lambda x: x+i) for i in range(10)]
>>> del i
>>> funcs[0](1)
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 1, in 
NameError: global name 'i' is not defined


We can see that the closure isn't created:

>>> funcs[0].func_closure is None
True


However, with a generator expression, i does not leak, a closure is 
created, but it is still late bound:

>>> funcs = list((lambda x: x+i) for i in range(10))
>>> funcs[0].func_closure
(,)
>>> del i
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'i' is not defined
>>> funcs[0](1)
10
>>> funcs[1](1)
10


> Yes, I can explicitly grab each 'i' as it flies by with a little clever
> coding of the default value for the  lambda n, i=i: i + n  but that
> 'trick' is not intuitive, nor is it clear reading. It 'works' is just
> about all one can say for it (not very elegant).

It might be more clear reading if you do it this way:

funcs = [(lambda x, i=j: x+i) for j in range(10)]

Now the reader is no longer distracted by the "i=i" ugliness.


> I'm not sure what the answer is, but I think all of us need to think
> through it some more. Placing lambdas in a list comprehension is just
> delicious, except for the explicit kludges we have to code to get it to
> work. I'm wondering if whether it would make some sense to put some
> 'binding smarts' into the interpreter to allow for 'interpreter
> intuition' (say AI ) that would presume to understand when early vs late
> binding makes sense and apply early binding in those cases where the
> context is not ambiguous and when it is clear that an iterable is being
> passed to the constant lambda function??

The problem with Do What I Mean is that it so rarely Does What You Mean. 
At best it Does What Some Other Guy Imagined I'd Probably Mean In This 
Situation. Let's not go there.


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

Re: Something is rotten in Denmark...

[Steven D'Aprano]

On Wed, 01 Jun 2011 19:50:14 -0500, harrismh777 wrote:

> harrismh777 wrote:
>> Allow me to clarify... I'm not speaking about whether the lambda is
>> short-hand for def, ... that part of the docs I understand well!... no
>> problems there.
> 
> Allow me to clarify a little further...   the docs are misleading in
> that they state that the lambda can be coded (as an expression) where
> the def 'statement' cannot be coded.   Well, I know, this is speaking to
> the syntax rules not the binding rules, but the point is that it implies
> that the lambda can be used where the def cannot... 

And so it can.


> and this is where
> the hypnosis takes place... we assume that something 'additional' is
> happening with the lambda that is *not* happening with the def.

This is not a failure of the docs, but of your assumption. The only 
difference is that lambda is an expression , and is limited to a single 
expression. The leap from "lambda is an expression" to "...and therefore 
the thing created by lambda has 'additional' stuff beyond ordinary def 
functions" is unjustified.

Nevertheless, it does seem to be awfully common. You're hardly alone.



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

Re: datetime.datetime and mysql different after python2.3

[Tim Roberts]

Tobiah  wrote:
>
>I'm grabbing two fields from a MySQLdb connection.
>One is a date type, and one is a time type.
>
>So I put the values in two variables and print them:
>...
>In python 2.3.4, I get:
>
> 
>2010-07-06 09:20:45.00
>
>Put in python2.4 and greater, I get this:
>
> 
>2010-07-06
>
>So I'm having trouble adding the two to get one
>datetime.

Many of the database layers switched to the built-in "datetime" module when
it was introduced in 2.4.  Prior to that, they had to use custom classes.

  date, time = get_fields()
  date = datetime.datetime.fromordinal( date.toordinal() )
  print str(date+time)
-- 
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Unshelving the data?

[Ben Finney]

Uncle Ben  writes:

> Or should I to go the full database route?  It is not a lage
> application.

I would recommend you at least investigate the use of SQLite for your
application. It is part of the standard library since Python 2.5
http://docs.python.org/library/sqlite3.html>.

-- 
 \   “Well, my brother says Hello. So, hooray for speech therapy.” |
  `\  —Emo Philips |
_o__)  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Unshelving the data?

[Chris Torek]

In article <4433955b-7f54-400a-af08-1f58a75e7...@j31g2000yqe.googlegroups.com>
Uncle Ben   wrote:
>Shelving is a wonderfully simple way to get keyed access to a store of
>items. I'd like to maintain this cache though.
>
>Is there any way to remove a shelved key once it is hashed into the
>system?

$ pydoc shelve
...
To summarize the interface (key is a string, data is an arbitrary
object):
...
d[key] = data   # store data at key (overwrites old data if
# using an existing key)
data = d[key]   # retrieve a COPY of the data at key (raise
# KeyError if no such key) -- NOTE that this
# access returns a *copy* of the entry!
del d[key]  # delete data stored at key (raises KeyError
# if no such key)
...

Seems pretty straightforward. :-)  Are you having some sort
of problem with "del"?
-- 
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W)  +1 801 277 2603
email: gmail (figure it out)  http://web.torek.net/torek/index.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Unshelving the data?

[Uncle Ben]

Shelving is a wonderfully simple way to get keyed access to a store of
items. I'd like to maintain this cache though.

Is there any way to remove a shelved key once it is hashed into the
system?  I could do it manually by removing the value and erasing the
key in the directory list. But is there a more elegant way?

Or should I to go the full database route?  It is not a lage
application.

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

Re: float("nan") in set or as key

[Steven D'Aprano]

On Wed, 01 Jun 2011 14:03:14 +, Grant Edwards wrote:

> On 2011-06-01, Chris Angelico  wrote:
>> On Wed, Jun 1, 2011 at 12:59 PM, Carl Banks 
>> wrote:
>>> On Sunday, May 29, 2011 7:53:59 PM UTC-7, Chris Angelico wrote:
 Okay, here's a question. The Python 'float' value - is it meant to be
 "a Python representation of an IEEE double-precision floating point
 value", or "a Python representation of a real number"?
>>>
>>> The former. ?Unlike the case with integers, there is no way that I
>>> know of to represent an abstract real number on a digital computer.
>>
>> This seems peculiar. Normally Python seeks to define its data types in
>> the abstract and then leave the concrete up to the various
>> implementations - note,
> 
> But, "real numbers" and "IEEE float" are so different that I don't think
> that it would be a wise decision for people to pretend they're working
> with real numbers when in fact they are working with IEEE floats.

People pretend that *all the time*.

Much of the opposition to NANs, for example, is that it violates 
properties of the reals. But so do ordinary floats! People just pretend 
otherwise.

For reals, a + b - a = b, always without exception. For floats, not so 
much.

For reals, a*(b + c) = a*b + a*c, always without exception. For floats, 
not so much.

For reals, 1/(1/x) = x, except for 0, always. For floats, not so much. 
For IEEE floats with proper support for INF, 0 is one of the cases which 
does work!

These sorts of violations are far more likely to bite you than the NAN 
boogey, that x != x when x is a NAN. But people go into paroxysms of 
concern over the violation that they will probably never see, and ignore 
the dozens that they trip over day after day.

Compiler optimizations are some of the worst and most egregious 
violations of the rule Floats Are Not Reals. Large numbers of numeric 
algorithms are simply broken due to invalid optimizations written by C 
programmers who think that because they have a high school understanding 
of real-value math they therefore understand floats.


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

Re: float("nan") in set or as key

[Steven D'Aprano]

On Tue, 31 May 2011 19:45:01 -0700, Carl Banks wrote:

> On Sunday, May 29, 2011 8:59:49 PM UTC-7, Steven D'Aprano wrote:
>> On Sun, 29 May 2011 17:55:22 -0700, Carl Banks wrote:
>> 
>> > Floating point arithmetic evolved more or less on languages like
>> > Fortran where things like exceptions were unheard of,
>> 
>> I'm afraid that you are completely mistaken.
>> 
>> Fortran IV had support for floating point traps, which are "things like
>> exceptions". That's as far back as 1966. I'd be shocked if earlier
>> Fortrans didn't also have support for traps.
>> 
>> http://www.bitsavers.org/pdf/ibm/7040/C28-6806-1_7040ftnMathSubrs.pdf
> 
> Fine, it wasn't "unheard of".  I'm pretty sure the existence of a few
> high end compiler/hardware combinations that supported traps doesn't
> invalidate my basic point.

On the contrary, it blows it out of the water and stomps its corpse into 
a stain on the ground. NANs weren't invented as an alternative for 
exceptions, but because exceptions are usually the WRONG THING in serious 
numeric work.

Note the "usually". For those times where you do want to interrupt a 
calculation just because of an invalid operation, the standard allows you 
to set a trap and raise an exception.

There's plenty of information available about how and why IEEE-754 was 
created. Go do some research and stop making up rubbish based on what you 
assume must have been their motives. Start with William Kahan, who has 
written extensively about it. If you can find a version of the Apple 
Numerics Manual 2nd Edition, it has an extremely entertaining forward by 
Professor Kahan about the mess that was floating point before IEEE-754.


> If your aim is to support every last clause of IEEE for better or
> worse, then yes that's what Python should do.  If your aim is to make
> Python the best language it can be, then Python should reject IEEE's
> obsolete notions, and throw exceptions when operating on NaN.

Python's usefulness for good numeric work is seriously hurt by the fact 
that it tries so hard to never generate a NAN, and rarely an INF, and 
instead keeps raising annoying exceptions that have to be caught (at 
great expense of performance) and turned into something useful.

You'll note that, out of the box, numpy generates NANs:

>>> import numpy
>>> x = numpy.array([float(x) for x in range(5)])
>>> x/x
Warning: invalid value encountered in divide
array([ nan,   1.,   1.,   1.,   1.])


The IEEE standard supports both use-cases: those who want exceptions to 
bail out early, and those who want NANs so the calculation can continue. 
This is a good thing. Failing to support the standard is a bad thing. 
Despite your opinion, it is anything but obsolete.


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

Re: Something is rotten in Denmark...

[harrismh777]

harrismh777 wrote:

Allow me to clarify... I'm not speaking about whether the lambda is
short-hand for def, ... that part of the docs I understand well!... no
problems there.


Allow me to clarify a little further...   the docs are misleading in 
that they state that the lambda can be coded (as an expression) where 
the def 'statement' cannot be coded.   Well, I know, this is speaking to 
the syntax rules not the binding rules, but the point is that it implies 
that the lambda can be used where the def cannot... and this is where 
the hypnosis takes place... we assume that something 'additional' is 
happening with the lambda that is *not* happening with the def.


And the truth is that the def (save its coding syntax) is the 'same' 
critter as the lambda. It seems, in fact, that the only difference is 
two ... that  1) the lambda does not automatically bind to a name, and 
2) the lambda is a constant expression rather than a statement.






thanks for listening...


m harris

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

Re: Comparison operators in Python

[harrismh777]

Ian Kelly wrote:

integer. However comparison between a string and an integer seems to
>  be permitted. Is there any rationale behind this ?

It allows things like sorting of heterogeneous lists.  It's generally
viewed as a wart, though, and it was fixed in Python 3:



   Just another example (excluding  print  1/2  and  unicode) where 3.x 
seems to be completely compatible with 2.x/   (tongue-in-cheek)



(do Brits say tongue-in-cheek?)


:)


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

Re: Something is rotten in Denmark...

[harrismh777]

Terry Reedy wrote:

function (I know, not so) is built-in. There is little to nothing
indicating in the docs that this is not so


On the contrary, the docs very explicitly say that a lambda expression
is equivalent to a def statement.


Allow me to clarify... I'm not speaking about whether the lambda is 
short-hand for def, ... that part of the docs I understand well!... no 
problems there.


The part that I don't see much about in the docs (some books, that is) 
is that the lambda lookups occur late (the lambda is evaluated at the 
time it is called). The Python docs on-line *do say* this (I found too 
late) but its one quick phrase that can be missed. So, the i in 
range(10) is sitting there at '9' by the time *any* of the ten lambdas 
get called. This is not intuitive, nor good. IMHO


Please allow me to whine a little bit, ... but the *whole point* of 
iterating is to be able to implicitly grab each iterated value as it 
flies by (by the lambda or anything else!) and there is not much point 
to having a 'late-binding' on an iterable particularly range(n).


Yes, I can explicitly grab each 'i' as it flies by with a little clever 
coding of the default value for the  lambda n, i=i: i + n  but that 
'trick' is not intuitive, nor is it clear reading. It 'works' is just 
about all one can say for it (not very elegant).


I'm not sure what the answer is, but I think all of us need to think 
through it some more. Placing lambdas in a list comprehension is just 
delicious, except for the explicit kludges we have to code to get it to 
work. I'm wondering if whether it would make some sense to put some 
'binding smarts' into the interpreter to allow for 'interpreter 
intuition' (say AI ) that would presume to understand when early vs late 
binding makes sense and apply early binding in those cases where the 
context is not ambiguous and when it is clear that an iterable is being 
passed to the constant lambda function??



kind regards,
m harris


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

Re: float("nan") in set or as key

[Grant Edwards]

On 2011-05-29, Nobody  wrote:
> On Sun, 29 May 2011 10:29:28 +, Steven D'Aprano wrote:
>
>>> The correct answer to "nan == nan" is to raise an exception, because
>>> you have asked a question for which the answer is nether True nor
>>> False.
>> 
>> Wrong.
>
> That's overstating it. There's a good argument to be made for raising
> an exception. Bear in mind that an exception is not necessarily an
> error, just an "exceptional" condition.
>
>> The correct answer to "nan == nan" is False, they are not equal.
>
> There is no correct answer to "nan == nan".

For those of us who have to deal with the real world (that means
complying with IEEE-754), there _is_ a correct answer.  IIRC, the IEEE
standard requires nan == nan is false, and nan != nan is true.

That said, I don't remember what the other comparisons are supposed to
do...

> Defining it to be false is just the "least wrong" answer.
>
> Arguably, "nan != nan" should also be false, but that would violate
> the invariant "(x != y) == !(x == y)".

And it would violate the IEEE standard.  IEEE-754 has it's warts, but
we're far better off than we were with dozens of incompatible,
undocumented, vendor-specific schemes (most of which had more warts
than IEEE-754).

-- 
Grant Edwards   grant.b.edwardsYow! I'm dressing up in
  at   an ill-fitting IVY-LEAGUE
  gmail.comSUIT!!  Too late...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Updated now can't scroll uparrow

[Ned Deily]

In article 
<6dc00d94-2776-47c1-8ad6-d7e608c6e...@n11g2000yqf.googlegroups.com>,
 Gnarlodious  wrote:

> Like so:
> 
> ./configure MACOSX_DEPLOYMENT_TARGET=10.6 \
> --enable-framework=/usr/local/python-3.1/frameworks \
> --prefix=/usr/local/python-3.1 \
> --enable-universalsdk=/ \
> --with-universal-archs=intel
> 
> Is there some directive to enable Readline?

You need to supply your own copy of GNU readline; Apple does not ship 
it.  You can use one from MacPorts or other 3rd-party distributor.  
Python 2.7 and 3.2 have a feature to use the readline compatibility 
interface of BSD editline (libedit) which Apple does ship but that 
feature was not backported to Python 3.1.  The python.org 3.1.x 
installers are built with GNU readline (and there is one for 3.1.4rc1).

-- 
 Ned Deily,
 n...@acm.org

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

Re: float("nan") in set or as key

[Carl Banks]

On Wednesday, June 1, 2011 11:10:33 AM UTC-7, Ethan Furman wrote:
> Carl Banks wrote:
> > For instance, say you are using an implementation that uses
>  > floating point, and you define a function that uses Newton's
>  > method to find a square root:
> > 
> > def square_root(N,x=None):
> > if x is None:
> > x = N/2
> > for i in range(100):
> > x = (x + N/x)/2
> > return x
> > 
> > It works pretty well on your floating-point implementation.
>  > Now try running it on an implementation that uses fractions
>  > by default
> > 
> > (Seriously, try running this function with N as a Fraction.)
> 
> Okay, will this thing ever stop?  It's been running for 90 minutes now. 
>   Is it just incredibly slow?
> 
> Any enlightenment appreciated!

Fraction needs to find the LCD of the denominators when adding; but LCD 
calculation becomes very expensive as the denominators get large (which they 
will since you're dividing by an intermediate result in a loop).  I suspect the 
time needed grows exponentially (at least) with the value of the denominators.

The LCD calculation should slow the calculation down to an astronomical crawl 
well before you encounter memory issues.

This is why representation simply cannot be left as an implementation detail; 
rationals and floating-points behave too differently.


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

Re: float("nan") in set or as key

[Nobody]

On Sun, 29 May 2011 23:31:19 +, Steven D'Aprano wrote:

>> That's overstating it. There's a good argument to be made for raising an
>> exception. 
> 
> If so, I've never heard it, and I cannot imagine what such a good 
> argument would be. Please give it.

Exceptions allow you to write more natural code by ignoring the awkward
cases. E.g. writing "x * y + z" rather than first determining whether
"x * y" is even defined then using a conditional.

>> Bear in mind that an exception is not necessarily an error,
>> just an "exceptional" condition.
> 
> True, but what's your point? Testing two floats for equality is not an 
> exceptional condition.

NaN itself is an exceptional condition which arises when a result is
undefined or not representable. When an operation normally returns a
number but a specific case cannot do so, it returns not-a-number.

The usual semantics for NaNs are practically identical to those for
exceptions. If any intermediate result in a floating-point expression is
NaN, the overall result is NaN. Similarly, if any intermediate calculation
throws an exception, the calculation as a whole throws an exception.

If x is NaN, then "x + y" is NaN, "x * y" is NaN, pretty much anything
involving x is NaN. By this reasoning both "x == y" and "x != y" should
also be NaN. But only the floating-point types have a NaN value, while
bool doesn't. However, all types have exceptions.

>>> The correct answer to "nan == nan" is False, they are not equal.
>> 
>> There is no correct answer to "nan == nan". 
> 
> Why on earth not?

Why should there be a correct answer? What does NaN actually mean?

Apart from anything else, defining "NaN == NaN" as False means that
"x == x" is False if x is NaN, which violates one of the fundamental
axioms of an equivalence relation (and, in every other regard, "==" is
normally intended to be an equivalence relation).

The creation of NaN was a pragmatic decision on how to handle exceptional
conditions in hardware. It is not holy writ, and there's no fundamental
reason why a high-level language should export the hardware's behaviour
verbatim.

>> Arguably, "nan != nan" should also be false,
>> but that would violate the invariant "(x != y) == !(x == y)".
> 
> I cannot imagine what that argument would be. Please explain.

A result of NaN means that the result of the calculation is undefined, so
the value is "unknown". If x is unknown and y is unknown, then whether x
is equal to y is itself unknown, and whether x differs from y is also
unknown.

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

Re: how to avoid leading white spaces

[Karim]

On 06/01/2011 09:39 PM, ru...@yahoo.com wrote:

On Jun 1, 11:11 am, Chris Rebert  wrote:

On Wed, Jun 1, 2011 at 12:31 AM, rakesh kumar

Hi

i have a file which contains data

//ACCDJ EXEC DB2UNLDC,DFLID=&DFLID,PARMLIB=&PARMLIB,
// UNLDSYST=&UNLDSYST,DATABAS=MBQV1D0A,TABLE='ACCDJ   '
//ACCT  EXEC DB2UNLDC,DFLID=&DFLID,PARMLIB=&PARMLIB,
// UNLDSYST=&UNLDSYST,DATABAS=MBQV1D0A,TABLE='ACCT'
//ACCUM EXEC DB2UNLDC,DFLID=&DFLID,PARMLIB=&PARMLIB,
// UNLDSYST=&UNLDSYST,DATABAS=MBQV1D0A,TABLE='ACCUM   '
//ACCUM1EXEC DB2UNLDC,DFLID=&DFLID,PARMLIB=&PARMLIB,
// UNLDSYST=&UNLDSYST,DATABAS=MBQV1D0A,TABLE='ACCUM1  '

i want to cut the white spaces which are in between single quotes after TABLE=.

for example :
'ACCT[spaces] '
'ACCUM   '
'ACCUM1 '
the above is the output of another python script but its having a leading 
spaces.

Er, you mean trailing spaces. Since this is easy enough to be
homework, I will only give an outline:

1. Use str.index() and str.rindex() to find the positions of the
starting and ending single-quotes in the line.
2. Use slicing to extract the inside of the quoted string.
3. Use str.rstrip() to remove the trailing spaces from the extracted string.
4. Use slicing and concatenation to join together the rest of the line
with the now-stripped inner string.

Relevant docs:http://docs.python.org/library/stdtypes.html#string-methods

For some odd reason (perhaps because they are used a lot in Perl),
this groups seems to have a great aversion to regular expressions.
Too bad because this is a typical problem where their use is the
best solution.

 import re
 f = open ("your file")
 for line in f:
 fixed = re.sub (r"(TABLE='\S+)\s+'$", r"\1'", line)
 print fixed,

(The above is for Python-2, adjust as needed for Python-3)

Rurpy,
Your solution is neat.
Simple is better than complicated... (at list for this simple issue)



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

Re: float("nan") in set or as key

[Carl Banks]

On Wednesday, June 1, 2011 10:17:54 AM UTC-7, OKB (not okblacke) wrote:
> Carl Banks wrote:
> 
> > On Tuesday, May 31, 2011 8:57:57 PM UTC-7, Chris Angelico wrote:
> >> On Wed, Jun 1, 2011 at 1:30 PM, Carl Banks  wrote:
> > Python has several non-integer number types in the standard
> > library.  The one we are talking about is called float.  If the
> > type we were talking about had instead been called real, then your
> > question might make some sense.  But the fact that it's called
> > float really does imply that that underlying representation is
> > floating point. 
> 
>   That's true, but that's sort of putting the cart before the horse.

Not really.  The (original) question Chris Angelico was asking was, "Is it an 
implementation detail that Python's non-integer type is represented as an IEEE 
floating-point?"  Which the above is the appropriate answer to.

> In response to that, one can just ask: why is this type called "float"? 

Which is a different question; not the question I was answering, and not one I 
care to discuss.
 

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

Re: how to avoid leading white spaces

[ru...@yahoo.com]

On Jun 1, 11:11 am, Chris Rebert  wrote:
> On Wed, Jun 1, 2011 at 12:31 AM, rakesh kumar
> > Hi
> >
> > i have a file which contains data
> >
> > //ACCDJ EXEC DB2UNLDC,DFLID=&DFLID,PARMLIB=&PARMLIB,
> > // UNLDSYST=&UNLDSYST,DATABAS=MBQV1D0A,TABLE='ACCDJ   '
> > //ACCT  EXEC DB2UNLDC,DFLID=&DFLID,PARMLIB=&PARMLIB,
> > // UNLDSYST=&UNLDSYST,DATABAS=MBQV1D0A,TABLE='ACCT    '
> > //ACCUM EXEC DB2UNLDC,DFLID=&DFLID,PARMLIB=&PARMLIB,
> > // UNLDSYST=&UNLDSYST,DATABAS=MBQV1D0A,TABLE='ACCUM   '
> > //ACCUM1    EXEC DB2UNLDC,DFLID=&DFLID,PARMLIB=&PARMLIB,
> > // UNLDSYST=&UNLDSYST,DATABAS=MBQV1D0A,TABLE='ACCUM1  '
> >
> > i want to cut the white spaces which are in between single quotes after 
> > TABLE=.
> >
> > for example :
> >    'ACCT[spaces] '
> >    'ACCUM   '
> >    'ACCUM1 '
> > the above is the output of another python script but its having a leading 
> > spaces.
>
> Er, you mean trailing spaces. Since this is easy enough to be
> homework, I will only give an outline:
>
> 1. Use str.index() and str.rindex() to find the positions of the
> starting and ending single-quotes in the line.
> 2. Use slicing to extract the inside of the quoted string.
> 3. Use str.rstrip() to remove the trailing spaces from the extracted string.
> 4. Use slicing and concatenation to join together the rest of the line
> with the now-stripped inner string.
>
> Relevant docs:http://docs.python.org/library/stdtypes.html#string-methods

For some odd reason (perhaps because they are used a lot in Perl),
this groups seems to have a great aversion to regular expressions.
Too bad because this is a typical problem where their use is the
best solution.

import re
f = open ("your file")
for line in f:
fixed = re.sub (r"(TABLE='\S+)\s+'$", r"\1'", line)
print fixed,

(The above is for Python-2, adjust as needed for Python-3)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Comparison operators in Python

[Ian Kelly]

On Wed, Jun 1, 2011 at 12:50 PM, Anirudh Sivaraman  wrote:
> Hi
>
> I am a relative new comer to Python. I see that typing is strongly
> enforced in the sense you can't concatenate or add a string and an
> integer. However comparison between a string and an integer seems to
> be permitted. Is there any rationale behind this ?

It allows things like sorting of heterogeneous lists.  It's generally
viewed as a wart, though, and it was fixed in Python 3:

Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> 'x' < 5
Traceback (most recent call last):
  File "", line 1, in 
TypeError: unorderable types: str() < int()

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

Re: Comparison operators in Python

[Jussi Piitulainen]

Anirudh Sivaraman writes:

> I am a relative new comer to Python. I see that typing is strongly
> enforced in the sense you can't concatenate or add a string and an
> integer. However comparison between a string and an integer seems to
> be permitted. Is there any rationale behind this ?

In Python 3 it is an error.

Python 3.1.1 (r311:74480, Feb  8 2010, 14:06:51) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 3 < 'kolme'
Traceback (most recent call last):
  File "", line 1, in 
TypeError: unorderable types: int() < str()
-- 
http://mail.python.org/mailman/listinfo/python-list

Comparison operators in Python

[Anirudh Sivaraman]

Hi

I am a relative new comer to Python. I see that typing is strongly
enforced in the sense you can't concatenate or add a string and an
integer. However comparison between a string and an integer seems to
be permitted. Is there any rationale behind this ?

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

Re: datetime.datetime and mysql different after python2.3

[Tobiah]

> import datetime
> date, time = get_fields() # for example
> print str(type(date)), str((type(time)))
> print str(date + time)

News reader stripped newlines

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

datetime.datetime and mysql different after python2.3

[Tobiah]

I'm grabbing two fields from a MySQLdb connection.
One is a date type, and one is a time type.

So I put the values in two variables and print them:

import datetime
date, time = get_fields() # for example
print str(type(date)), str((type(time)))
print str(date + time)

In python 2.3.4, I get:

 
2010-07-06 09:20:45.00

Put in python2.4 and greater, I get this:

 
2010-07-06

So I'm having trouble adding the two to get one
datetime.

Thanks for any insight.

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

Re: Thanks for all responses

[Chris Angelico]

On Thu, Jun 2, 2011 at 3:29 AM, Wolfgang Meiners
 wrote:
> Yes it helped a lot. One last question here: When i have free choice and
> i dont know Python 2 and Python 3 very good: What would be the
> recommended choice?

Generally, Python 3. Unless there's something you really need in
Python 2 (a module that isn't available in 3.x, for instance, or
you're deploying to a site that doesn't have Python 3 installed), it's
worth going with the newer one.

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

Re: float("nan") in set or as key

[Chris Torek]

>Carl Banks wrote:
>> For instance, say you are using an implementation that uses
> > floating point, and you define a function that uses Newton's
> > method to find a square root:
>> 
>> def square_root(N,x=None):
>> if x is None:
>> x = N/2
>> for i in range(100):
>> x = (x + N/x)/2
>> return x
>> 
>> It works pretty well on your floating-point implementation.
> > Now try running it on an implementation that uses fractions
> > by default
>> 
>> (Seriously, try running this function with N as a Fraction.)

In article 
Ethan Furman   wrote:
>Okay, will this thing ever stop?  It's been running for 90 minutes now. 
>  Is it just incredibly slow?

The numerator and denominator get very big, very fast.

Try adding a bit of tracing:

for i in range(100):
x = (x + N/x) / 2
print 'refinement %d: %s' % (i + 1, x)

and lo:

>>> square_root(fractions.Fraction(5,2))
refinement 1: 13/8
refinement 2: 329/208
refinement 3: 216401/136864
refinement 4: 93658779041/59235012928
refinement 5: 17543933782901678712641/11095757974628660884096
refinement 6: 
615579225157677613558476890352854841917537921/389326486355976942712506162834130868382115072
refinement 7: 
757875564891453502666431245010274191070178420221753088072252795554063820074969259096915201/479322593608746863553102599134385944371903608931825380820104910630730251583028097491290624
refinement 8: 
1148750743719079498041767029550032831122597958315559446437317334336105389279028846671983328007126798344663678217310478873245910031311232679502892062001786881913873645733507260643841/726533762792931259056428876869998002853417255598937481942581984634876784602422528475337271599486688624425675701640856472886826490140251395415648899156864835350466583887285148750848

In the worst case, the number of digits in numerator and denominator
could double on each pass, so if you start with 1 digit in each,
you end with 2**100 in each.  (You will run out of memory first
unless you have a machine with more than 64 bits of address space. :-) )

-- 
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W)  +1 801 277 2603
email: gmail (figure it out)  http://web.torek.net/torek/index.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: float("nan") in set or as key

[Ethan Furman]

Carl Banks wrote:

For instance, say you are using an implementation that uses

> floating point, and you define a function that uses Newton's
> method to find a square root:


def square_root(N,x=None):
if x is None:
x = N/2
for i in range(100):
x = (x + N/x)/2
return x

It works pretty well on your floating-point implementation.

> Now try running it on an implementation that uses fractions
> by default


(Seriously, try running this function with N as a Fraction.)


Okay, will this thing ever stop?  It's been running for 90 minutes now. 
 Is it just incredibly slow?


Any enlightenment appreciated!

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

Re: Updated blog post on how to use super()

[Chris Torek]

Summary: super(cls, data) in a method gets you the "next" handler
for a given class "cls" and an instance "data" that has derived
from that class at some point.  In Python 2 you must spell out the
names of the class and instance (normally "self") explicitly, while
Python 3 grabs, at compile time, the class from the lexically
enclosing class, and the instance from the first argument of the
method that invokes "super".

The "next" handler depends on the instance's __mro__.  If all
your classes use at most single inheritance, the "next" handler
in class Cls1 is easy to predict:

class Cls1(Cls2):

Any instance of Cls1 always has Cls2 as its "next", so:

def method(self, arg1, arg2):
...
Cls2.method(self, arg1_mutated, arg2_mutated)
...

works fine.  But if you use multiple inheritance, the next method
is much harder to predict.  If you have a working "super", you
can use:

super().method(self, arg1_mutated, arg2_mutated)

and it will find the correct "next method" in all cases.

In article 
Billy Mays   wrote:
>What it does is clear to me, but why is it interesting or special isn't. 
>  This looks like a small feature that would be useful in a handful of 
>cases.

Indeed: it is useful when you have multiple inheritance, which for
most programmers, is a "handful of cases".

However, provided you *have* the Py3k super() in the first place,
it is also trivial and obviously-correct to write:

super().method(...)

whereas writing:

NextClass.method(...)

requires going up to the class definition to make sure that
"NextClass" is indeed the next class, and hence -- while usually
no more difficult to write -- less obviously-correct.

Moreover, if you write the easy-to-write obviously-correct
"super().method", *your* class may now be ready for someone
else to use in a multiple-inheritance (MI) situation.  If you type
in the not-as-obviously-correct "NextClass.method", *your* class
is definitely *not* ready for someone else to use in that MI
situation.

(I say "may" be ready for MI, because being "fully MI ready" requires
several other code discipline steps.  The point of super() -- at
least when implemented nicely, as in Py3k -- is that it makes it
easy -- one might even say "super easy" :-) -- to write your code
such that it is obviously correct, and also MI-friendly.)
-- 
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W)  +1 801 277 2603
email: gmail (figure it out)  http://web.torek.net/torek/index.html
-- 
http://mail.python.org/mailman/listinfo/python-list

feedparser hanging after I/O error

[John Nagle]

  I have a program which uses "feedparser".  It occasionally hangs when
the network connection has been lost, and remains hung after the network
connection is restored.

  My program calls

d = feedparser.parse(self.url,etag=self.etag,modified=self.modified)

  If d is None, it raises an exception, and I see that happen when
the machine loses its WiFi connection.  My program then waits about
a minute, then retries.  On the retry, the same call is made, but
it never returns, even after a full day.  The WiFi connection is
back up; other connections work.  But "feedparser" is neither failing
nor retrying, just hanging.  Note that this happens on the SECOND
failure, not the first.

  Looking at the code, "feedparser" calls urllib2.opener for the
open.  There's some deprecated timeout-related code in feedparser,
which I am not calling.

  Running Python 2.6.3.7 (ActiveState) on Linux, on an EeePC 2G Surf.

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

Re: Thanks for all responses

[Wolfgang Meiners]

Am 31.05.11 23:56, schrieb Chris Angelico:
> On Wed, Jun 1, 2011 at 5:52 AM, Wolfgang Meiners
>  wrote:
>> Whenever i 'cross the border' of my program, i have to encode the 'list
>> of bytes' to an unicode string or decode the unicode string to a 'list
>> of bytes' which is meaningful to the world outside.
> 
> Most people use "encode" and "decode" the other way around; you encode
> a string as UTF-8, and decode UTF-8 into a Unicode string. But yes,
> you're correct.

Ok. I think i will adapt to the majority in this point.
I think i mixed up
unicodestring=unicode(bytestring,encoding='utf8')
and
bytestring=u'unicodestring'.encode('utf8')

> 
>> So encode early, decode lately means, to do it as near to the border as
>> possible and to encode/decode i need a coding system, for example 'utf8'
> 

I think i should change this to decode early, encode lately.

> Correct on both counts.
> 
>> That means, there should be an encoding/decoding possibility to every
>> interface i can use: files, stdin, stdout, stderr, gui (should be the
>> most important ones).
> 
> The file objects (as returned by open()) have an encoding, which
> (IMHO) defaults to "utf8". GUI work depends on your GUI toolkit, and
> might well accept Unicode strings directly - check the docs.
> 
>>def __repr__(self):
>>return u'My name is %s' % self.Name
> 
> This means that repr() will return a Unicode string.
> 
>># this does work
>>print a.__repr__()
>>
>># throws an error if default encoding is ascii
>># but works if default encoding is utf8
>>print a
>>
>># throws an error because a is not a string
>>print unicode(a, encoding='utf8')
> 
> The __repr__ function is supposed to return a string object, in Python
> 2. See http://docs.python.org/reference/datamodel.html#object.__repr__
> for that and other advice on writing __repr__. The problems you're
> seeing are a result of the built-in repr() function calling
> a.__repr__() and then treating the return value as an ASCII str, not a
> Unicode string.
> 
> This would work:
> def __repr__(self):
> return (u'My name is %s' % self.Name).encode('utf8')
> 
> Alternatively, migrate to Python 3, where the default is Unicode
> strings. I tested this in Python 3.2 on Windows, but it should work on
> anything in the 3.x branch:
> 
> class NoEnc:
>   def __init__(self,Name=None):
>   self.Name=Name
>   def __repr__(self):
>   return 'My name is %s' % self.Name
> 
> if __name__ == '__main__':
> 
>a = NoEnc('Müller')
> 
># this will still work (print is now a function, not a statement)
>print(a.__repr__())
> 
># this will work in Python 3.x
>print(a)
> 
># 'unicode' has been renamed to 'str', but it's already unicode so
> this makes no sense
>print(str(a, encoding='utf8'))
> 
># to convert it to UTF-8, convert it to a string with str() or
> repr() and then print:
>print(str(a).encode('utf8'))
> 
> 
> Note that the last one will probably not do what you expect. The
> Python 3 'print' function (it's not a statement any more, so you need
> parentheses around its argument) wants a Unicode string, so you don't
> need to encode it. When you encode a Unicode string as in the last
> example, it returns a bytes string (an array of bytes), which looks
> like this: b'My name is M\xc3\xbcller'  The print function wants
> Unicode, though, so it takes this unexpected object and calls str() on
> it, hence the odd display.
> 
> Hope that helps!

Yes it helped a lot. One last question here: When i have free choice and
i dont know Python 2 and Python 3 very good: What would be the
recommended choice?

> 
> Chris Angelico

Wolfgang

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

Re: float("nan") in set or as key

[OKB (not okblacke)]

Carl Banks wrote:

> On Tuesday, May 31, 2011 8:57:57 PM UTC-7, Chris Angelico wrote:
>> On Wed, Jun 1, 2011 at 1:30 PM, Carl Banks  wrote:
>> > I think you misunderstood what I was saying.
>> >
>> > It's not *possible* to represent a real number abstractly in any
>> > digita 
> l computer.  Python couldn't have an "abstract real number" type
> even it wanted to.
>> 
>> True, but why should the "non-integer number" type be floating
>> point rather than (say) rational? 
> 
> Python has several non-integer number types in the standard
> library.  The one we are talking about is called float.  If the
> type we were talking about had instead been called real, then your
> question might make some sense.  But the fact that it's called
> float really does imply that that underlying representation is
> floating point. 

That's true, but that's sort of putting the cart before the horse.  
In response to that, one can just ask: why is this type called "float"?  
Why is it that when I type 1.37 or sqrt(2) in my program, the resulting 
object is a "float" rather than some other numeric type?  I'm aware 
that there are answers to this having to do with standardization and 
efficiency.  But I do sometimes wish that the "default" type for non-
integers (as created through Python expressions) was something more like 
"rationals with a denominator no bigger than N".

-- 
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is
no path, and leave a trail."
--author unknown
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python regexp exclude problem

[MRAB]

On 01/06/2011 15:20, Lutfi Oduncuoglu wrote:

Hello,

I am trying to write a script for adding ip address to a list. Those ip
addresses coming thorough from our edge router.
I have a line in may script like

   if  any(s not in z2 for s
in('144.122.','188.38','193.140.99.2','213.161.144.166','92.45.88.242')):
   os.system(" echo " +z2+ " >> kapat_py_log")

However ip addresses like  213.161.144.166 are added to the list. What
can I do about this problem?


I think the problem is that you have "any(s not in ...)".

If you have the IP address "213.161.144.166", the string "144.122."
isn't in it, so the "any" returns True.

Try either "all(s not in z2 ...)" or "not any(s in z2 ...)".
--
http://mail.python.org/mailman/listinfo/python-list

Re: Something is rotten in Denmark...

[Terry Reedy]

On 5/31/2011 8:09 PM, harrismh777 wrote:


At the moment I'm only speaking about my OP and that particular list
comprehension... the thing that happened (at least for me) is that the
intuitive sense that each 'i' somehow becomes a part of the anonymous
function (I know, not so) is built-in. There is little to nothing
indicating in the docs that this is not so


On the contrary, the docs very explicitly say that a lambda expression 
is equivalent to a def statement.


"[Lambda forms (lambda expressions)] are a shorthand to create anonymous 
functions; the expression lambda arguments: expression yields a function 
object. The unnamed object behaves like a function object defined with


def (arguments):
return expression"

? Again, what we have here is

the 'i' being saved in a cell and looked up at call time (an
implementation detail, 'late-binding') that is critical for the
user-coder to understand.


Again, exactly the same as if the function were created with a def 
statement.



I'm not commenting on that, but it seems to me that if lambda is going
to remain in the language at all that 'early-binding' in the lambda
specific case would make sense; at least make the lambda more useful
generally.


I disagree. Currently, late-binding is the default, with early-binding 
an option through a few different mechanisms. Making early binding the 
default would *reduce* the usefulness by eliminating the late-binding 
option and would add nothing that cannot be done now.


There are some people whose 'intuition' is the opposite of yours. They 
instead want to eliminate the early-binding option of default argument 
expressions. They want to reduce flexibility in the other direction. 
Both proposals are equally bad.


--
Terry Jan Reedy

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

Re: how to avoid leading white spaces

[Chris Rebert]

On Wed, Jun 1, 2011 at 12:31 AM, rakesh kumar
 wrote:
>
> Hi
>
> i have a file which contains data
>
> //ACCDJ EXEC DB2UNLDC,DFLID=&DFLID,PARMLIB=&PARMLIB,
> // UNLDSYST=&UNLDSYST,DATABAS=MBQV1D0A,TABLE='ACCDJ   '
> //ACCT  EXEC DB2UNLDC,DFLID=&DFLID,PARMLIB=&PARMLIB,
> // UNLDSYST=&UNLDSYST,DATABAS=MBQV1D0A,TABLE='ACCT    '
> //ACCUM EXEC DB2UNLDC,DFLID=&DFLID,PARMLIB=&PARMLIB,
> // UNLDSYST=&UNLDSYST,DATABAS=MBQV1D0A,TABLE='ACCUM   '
> //ACCUM1    EXEC DB2UNLDC,DFLID=&DFLID,PARMLIB=&PARMLIB,
> // UNLDSYST=&UNLDSYST,DATABAS=MBQV1D0A,TABLE='ACCUM1  '
>
> i want to cut the white spaces which are in between single quotes after 
> TABLE=.
>
> for example :
>    'ACCT[spaces] '
>    'ACCUM   '
>    'ACCUM1 '
> the above is the output of another python script but its having a leading 
> spaces.

Er, you mean trailing spaces. Since this is easy enough to be
homework, I will only give an outline:

1. Use str.index() and str.rindex() to find the positions of the
starting and ending single-quotes in the line.
2. Use slicing to extract the inside of the quoted string.
3. Use str.rstrip() to remove the trailing spaces from the extracted string.
4. Use slicing and concatenation to join together the rest of the line
with the now-stripped inner string.

Relevant docs: http://docs.python.org/library/stdtypes.html#string-methods

Cheers,
Chris
--
http://rebertia.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Updated blog post on how to use super()

[Ian Kelly]

On Wed, Jun 1, 2011 at 10:46 AM, Billy Mays  wrote:
> What it does is clear to me, but why is it interesting or special isn't.
>  This looks like a small feature that would be useful in a handful of cases.

Well, I agree with you there.  The complexity introduced by super
typically outweighs the benefits it provides, IMO.  The only time when
it is really necessary is in non-trivial diamond inheritance
situations (to avoid calling the same method on some base class more
than once), and in those cases I think it is simply better to not use
multiple inheritance in the first place.

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

Re: Updated now can't scroll uparrow

[Gnarlodious]

Like so:

./configure MACOSX_DEPLOYMENT_TARGET=10.6 \
--enable-framework=/usr/local/python-3.1/frameworks \
--prefix=/usr/local/python-3.1 \
--enable-universalsdk=/ \
--with-universal-archs=intel

Is there some directive to enable Readline?

-- Gnarlie
http://Gnarlodious.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Updated blog post on how to use super()

[Brian J Mingus]

On Tue, May 31, 2011 at 8:44 PM, Raymond Hettinger  wrote:

> I've tightened the wording a bit, made much better use of keyword
> arguments instead of kwds.pop(arg), and added a section on defensive
> programming (protecting a subclass from inadvertently missing an MRO
> requirement).  Also, there is an entry on how to use assertions to
> validate search order requirements and make them explicit.
>
>  http://bit.ly/py_super
> or
>  http://rhettinger.wordpress.com/2011/05/26/super-considered-super/
>
> Any further suggestions are welcome.  I'm expecting this to evolve
> into how-to guide to be included in the regular Python standard
> documentation.  The goal is to serve as a reliable guide to using
> super and how to design cooperative classes in a way that lets
> subclasses compose and extent them.
>
>
> Raymond Hettinger
>
> 
> follow my python tips on twitter: @raymondh
> --
> http://mail.python.org/mailman/listinfo/python-list
>

I would recommend a more constructive introduction that has less
meta-analysis of what the post is about and just digs in.

*If you aren’t wowed by Python’s super() builtin, chances are you don’t
really know what it is capable of doing or how to use it effectively.*

This strikes me as a thinly veiled dis..

*Much has been written about super() and much of that writing has been a
failure.
*

I'm having a hard time seeing how this supremely condescending bit is
helpful? If *your* writing is not a failure time will tell.
*

 This article seeks to improve on the situation by:

   - providing practical use cases
   - giving a clear mental model of how it works
   - showing the tradecraft for getting it to work every time
   - concrete advice for building classes that use super()
   - solutions to common issues
   - favoring real examples over abstract ABCD diamond
diagrams
   .

*

These strikes me as notes by the author for the author. You could easily
extract the gist of the above points and convert them into a sentence or
two.

Overall, take everything up to the end of the last bullet point and convert
it into a 2-3 sentence intro paragraph.

-- 
Brian Mingus
Graduate student
Computational Cognitive Neuroscience Lab
University of Colorado at Boulder
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Updated now can't scroll uparrow

[Chris Rebert]

On Wed, Jun 1, 2011 at 7:37 AM, Gnarlodious  wrote:
> I updated Python to 3.1.3 on Mac OSX. Now suddenly in the Interactive
> interpreter I get all this instead of scrolling the history:
>
 ^[[A^[[A^[[A
>
> What's wrong and how to fix it?

Looks like GNU readline support wasn't enabled in the build you
installed. How did you install your Python?

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

how to avoid leading white spaces

[rakesh kumar]

Hi

i have a file which contains data

//ACCDJ EXEC DB2UNLDC,DFLID=&DFLID,PARMLIB=&PARMLIB,
// UNLDSYST=&UNLDSYST,DATABAS=MBQV1D0A,TABLE='ACCDJ   '
//ACCT  EXEC DB2UNLDC,DFLID=&DFLID,PARMLIB=&PARMLIB,
// UNLDSYST=&UNLDSYST,DATABAS=MBQV1D0A,TABLE='ACCT'
//ACCUM EXEC DB2UNLDC,DFLID=&DFLID,PARMLIB=&PARMLIB,
// UNLDSYST=&UNLDSYST,DATABAS=MBQV1D0A,TABLE='ACCUM   '
//ACCUM1EXEC DB2UNLDC,DFLID=&DFLID,PARMLIB=&PARMLIB,
// UNLDSYST=&UNLDSYST,DATABAS=MBQV1D0A,TABLE='ACCUM1  '

i want to cut the white spaces which are in between single quotes after
TABLE=.

for example :
   'ACCT[spaces] '
   'ACCUM   '
   'ACCUM1 '
the above is the output of another python script but its having a leading
spaces.

any help is much appreciate.





-- 

Thanks and  regards
@@ Be An Innovator @@
Rakesh Kumar A
+917428243738
[image: cid:image001.jpg@01CA6F8E.95C07E20]
<>-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Updated blog post on how to use super()

[Billy Mays]

On 6/1/2011 12:42 PM, Ian Kelly wrote:

On Wed, Jun 1, 2011 at 7:03 AM, Billy Mays  wrote:

I read this when it was on HN the other day, but I still don't see what is
special about super().  It seems (from your post) to just be a stand in for
the super class name?  Is there something special I missed?


It's not a stand-in for the super-class name.  It's a stand-in for
whatever class is next in the Method Resolution Order (MRO), which is
determined at run-time and can vary depending on what the actual class
of the object is.  For example, in this inheritance situation:

class A(object):
 ...

class B(object):
 ...

class C(A, B):
 ...

a = A()
c = C()

The MRO of A is (A, object).
The MRO of B is (B, object).
The MRO of C is (C, A, B, object).

Thus, super(A, a) is going to resolve to object, as you might expect.
But super(A, c) is going to resolve to B, because the next class after
A in the MRO for C instances is B.

That's a pretty quick and dirty explanation.  If it doesn't make
sense, I suggest reading the article again.


What it does is clear to me, but why is it interesting or special isn't. 
 This looks like a small feature that would be useful in a handful of 
cases.


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

Re: Updated blog post on how to use super()

[Ian Kelly]

On Wed, Jun 1, 2011 at 7:03 AM, Billy Mays  wrote:
> I read this when it was on HN the other day, but I still don't see what is
> special about super().  It seems (from your post) to just be a stand in for
> the super class name?  Is there something special I missed?

It's not a stand-in for the super-class name.  It's a stand-in for
whatever class is next in the Method Resolution Order (MRO), which is
determined at run-time and can vary depending on what the actual class
of the object is.  For example, in this inheritance situation:

class A(object):
...

class B(object):
...

class C(A, B):
...

a = A()
c = C()

The MRO of A is (A, object).
The MRO of B is (B, object).
The MRO of C is (C, A, B, object).

Thus, super(A, a) is going to resolve to object, as you might expect.
But super(A, c) is going to resolve to B, because the next class after
A in the MRO for C instances is B.

That's a pretty quick and dirty explanation.  If it doesn't make
sense, I suggest reading the article again.
-- 
http://mail.python.org/mailman/listinfo/python-list

Packaing configuration files

[Miki Tebeka]

Greetings,

For some modules, I have .yaml file which contains configuration option next to 
the module itself. For example, there will be mypackage/logger.yaml next to 
mypackag/logger.py.

What the best way to tell distutils/setuptools to package all these files?

(I can write my custom function to generate data_files, however I'm wondering 
if there is a better option).

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

Re: float("nan") in set or as key

[Chris Angelico]

On Wed, Jun 1, 2011 at 11:44 PM, Jerry Hill  wrote:
>> On Wed, Jun 1, 2011 at 1:30 PM, Carl Banks  wrote:
>> True, but why should the "non-integer number" type be floating point
>> rather than (say) rational?

Careful with the attributions, Carl was quoting me when he posted that :)

> You seem to be implying that python only provides a single non-integer
> numeric type.  That's not true.  Python ships with a bunch of
> different numeric types, including a rational type.  Off the top of my
> head, we have:
>
> IEEE floating point numbers
> (http://docs.python.org/library/stdtypes.html#numeric-types-int-float-long-complex)
> Rationals (http://docs.python.org/library/fractions.html)
> Base-10 fixed and floating point numbers
> (http://docs.python.org/library/decimal.html)
> Complex numbers
> (http://docs.python.org/library/stdtypes.html#numeric-types-int-float-long-complex
> plus http://docs.python.org/library/cmath.html)
> Integers (both ints and longs, which are pretty well unified by now)

I know Python does support all of the above. Leave off int/long and
complex, which are obviously not trying to store real numbers
(although I guess you could conceivably make 'complex' the vehicle for
reals too), there's three: float, fraction, decimal. Of them, one is a
built-in type and the other two are imported modules. Hence my
question about why this one and not that one should be the "default"
that people will naturally turn to as soon as they need non-integers.
(Or, phrasing it another way: Only one of them is the type that "3.2"
in your source code will be represented as.)

> Floats have far and away the best performance in most common
> situations, so they end up being the default, but if you want to use
> something different, it's usually not hard to do.

And that, right there, is the answer.

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

Updated now can't scroll uparrow

[Gnarlodious]

I updated Python to 3.1.3 on Mac OSX. Now suddenly in the Interactive
interpreter I get all this instead of scrolling the history:

>>> ^[[A^[[A^[[A

What's wrong and how to fix it?

-- Gnarlie
http://Gnarlodious.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python regexp exclude problem

[Christian Heimes]

Am 01.06.2011 16:20, schrieb Lutfi Oduncuoglu:
> Hello,
> 
> I am trying to write a script for adding ip address to a list. Those ip
> addresses coming thorough from our edge router.
> I have a line in may script like
> 
>   if  any(s not in z2 for s
> in('144.122.','188.38','193.140.99.2','213.161.144.166','92.45.88.242')):
>   os.system(" echo " +z2+ " >> kapat_py_log")
> 
> However ip addresses like  213.161.144.166 are added to the list. What can I
> do about this problem?

I recommend the ipaddr module [1] for the job. It supports nice features
like:

  if IPAddress("144.122.23.42") in IPNetwork("144.122.0.0/16"):
  ...

Christian


[1] http://pypi.python.org/pypi/ipaddr

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

Python regexp exclude problem

[Lutfi Oduncuoglu]

Hello,

I am trying to write a script for adding ip address to a list. Those ip
addresses coming thorough from our edge router.
I have a line in may script like

  if  any(s not in z2 for s
in('144.122.','188.38','193.140.99.2','213.161.144.166','92.45.88.242')):
  os.system(" echo " +z2+ " >> kapat_py_log")

However ip addresses like  213.161.144.166 are added to the list. What can I
do about this problem?

Thank You,

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

Re: float("nan") in set or as key

[Grant Edwards]

On 2011-06-01, Roy Smith  wrote:
> In article 
> Carl Banks  wrote:
>
>> pretty much everyone uses IEEE format
>
> Is there *any* hardware in use today which supports floating point using 
> a format other than IEEE?

Well, there are probably still some VAXes around in odd corners...

-- 
Grant Edwards   grant.b.edwardsYow! Thank god!! ... It's
  at   HENNY YOUNGMAN!!
  gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: float("nan") in set or as key

[Grant Edwards]

On 2011-06-01, Chris Angelico  wrote:
> On Wed, Jun 1, 2011 at 12:59 PM, Carl Banks  wrote:
>> On Sunday, May 29, 2011 7:53:59 PM UTC-7, Chris Angelico wrote:
>>> Okay, here's a question. The Python 'float' value - is it meant to be
>>> "a Python representation of an IEEE double-precision floating point
>>> value", or "a Python representation of a real number"?
>>
>> The former. ?Unlike the case with integers, there is no way that I know of 
>> to represent an abstract real number on a digital computer.
>
> This seems peculiar. Normally Python seeks to define its data types
> in the abstract and then leave the concrete up to the various
> implementations - note,

But, "real numbers" and "IEEE float" are so different that I don't
think that it would be a wise decision for people to pretend they're
working with real numbers when in fact they are working with IEEE
floats.

> for instance, how Python 3 has dispensed with 'int' vs 'long' and
> just made a single 'int' type that can hold any integer.

Those concepts are much closer than "real numbers" and "IEEE floats".

> Does this mean that an implementation of Python on hardware that has
> some other type of floating point must simulate IEEE double-precision
> in all its nuances?

I certainly hope so.  I depend on things like propogation of
non-signalling nans, the behavior of infinities, etc.

> I'm glad I don't often need floating point numbers. They can be so
> annoying!

They can be -- especially if one pretends one is working with real
numbers instead of fixed-length binary floating point numbers.  Like
any tool, floating point has to be used properly. Screwdrivers make
very annoying hammers.

-- 
Grant Edwards   grant.b.edwardsYow! How's it going in
  at   those MODULAR LOVE UNITS??
  gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: float("nan") in set or as key

[Jerry Hill]

> On Wed, Jun 1, 2011 at 1:30 PM, Carl Banks  wrote:
> True, but why should the "non-integer number" type be floating point
> rather than (say) rational?

You seem to be implying that python only provides a single non-integer
numeric type.  That's not true.  Python ships with a bunch of
different numeric types, including a rational type.  Off the top of my
head, we have:

IEEE floating point numbers
(http://docs.python.org/library/stdtypes.html#numeric-types-int-float-long-complex)
Rationals (http://docs.python.org/library/fractions.html)
Base-10 fixed and floating point numbers
(http://docs.python.org/library/decimal.html)
Complex numbers
(http://docs.python.org/library/stdtypes.html#numeric-types-int-float-long-complex
plus http://docs.python.org/library/cmath.html)
Integers (both ints and longs, which are pretty well unified by now)

Floats have far and away the best performance in most common
situations, so they end up being the default, but if you want to use
something different, it's usually not hard to do.

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

Re: Updated blog post on how to use super()

[Billy Mays]

On 5/31/2011 10:44 PM, Raymond Hettinger wrote:

I've tightened the wording a bit, made much better use of keyword
arguments instead of kwds.pop(arg), and added a section on defensive
programming (protecting a subclass from inadvertently missing an MRO
requirement).  Also, there is an entry on how to use assertions to
validate search order requirements and make them explicit.

   http://bit.ly/py_super
  or
   http://rhettinger.wordpress.com/2011/05/26/super-considered-super/

Any further suggestions are welcome.  I'm expecting this to evolve
into how-to guide to be included in the regular Python standard
documentation.  The goal is to serve as a reliable guide to using
super and how to design cooperative classes in a way that lets
subclasses compose and extent them.


Raymond Hettinger


follow my python tips on twitter: @raymondh


I read this when it was on HN the other day, but I still don't see what 
is special about super().  It seems (from your post) to just be a stand 
in for the super class name?  Is there something special I missed?


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

Re: No module name tests

[Abhishek Amberkar [अभिषेक]]

On Wed, Jun 1, 2011 at 11:53 AM, SONAL ...  wrote:
> Hey i have directory structure as
> gkwebapp/gnukhata-webapp/gnukhata/tests/functional in which we have our test
> files.
>
> When i run tests, get following error:
>
> Traceback (most recent call last):
>   File "test_account.py", line 1, in 
>     from gnukhata.tests import *
> ImportError: No module named gnukhata.tests
>
> Why do this error come?? I have searched a lot but no use. Can you please
> help me to sort it out???
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
>

Perhaps that directory is not listed in "sys.path" ??


-- 
With Regards
Abhishek Amberkar
-- 
http://mail.python.org/mailman/listinfo/python-list