Re: Explanation of list reference

[Ian Kelly]

On Fri, Feb 14, 2014 at 11:07 PM, Rustom Mody  wrote:
> On Saturday, February 15, 2014 10:50:35 AM UTC+5:30, Ian wrote:
>> This is false.  It happens to hold for CPython, but that's an
>> implementation detail.  The definition of object identity does not
>> depend on memory address.  It also doesn't have anything to do with
>> space-time coordinates.  The concept of object identity is an
>> abstraction, not an analogy from physics.
>
>> The language reference states, "Every object has an identity, a type
>> and a value. An object's identity never changes once it has been
>> created; you may think of it as the object's address in memory."
>> Okay, so that quote does bring up memory address, but in my
>> interpretation that's just an analogy to introduce the concept.  The
>> more important part of that sentence is the first part, which ties an
>> object's identity to its creation.  If two objects share the same
>> creation, then they're the same object.
>
> Whats the notion of object identity is the question.
> Ok so you reject the memory addr as an 'implementation detail'
> Then you are obliged to provide some other way of understanding 
> object-identity

I thought that I did.  Repeating myself from what you quoted above:

If two objects share the same creation, then they're the same object.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Marko Rauhamaa]

Ned Batchelder :

> On 2/14/14 4:43 PM, Marko Rauhamaa wrote:
> Yes, sometimes for teaching reasons, you have to over-simplify or even
> introduce artificial constructs.  I'd recommend acknowledging them as
> such.
>
> When you say, "There are two fundamentally different kinds of values
> in Python," or "So we have four kinds of (memory) slots," you aren't
> letting on that this is a teaching construct. It sounds like you mean
> that this is how Python actually works.
>
> I'd use words like, "This is an oversimplification, but might
> help...", or "You can think of it like ...".

Strictly speaking, I'm not simplifying, but giving an equivalent,
alternative description. I admit that the word "fundamentally" was a bad
choice. I'm not even sure my description was a good illustration. I
definitely was not referring to CPython and was trying to keep the
discussion separate from the implementation of the day.

BTW, I also wasn't oversimplifying, but complicating by bringing in an
unnecessary dichotomy. The challenge is how to present Python's value
model in the most digestible way. For example, how is a beginnger to
understand what's going on in:

   n += 1

Is it easier to think that the number held by the variable n is
incremented by 1, or is it easier to understand it orthodoxly through
instantiations and references?


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Marko Rauhamaa]

Chris Angelico :

> On Sat, Feb 15, 2014 at 8:43 AM, Marko Rauhamaa  wrote:
>> Unfortunately neither the "everything is a reference" model nor the
>> "small/big" model help you predict the value of an "is" operator in
>> the ambiguous cases.
>
> Can you give an example of an ambiguous case?

The "x is y" test may yield different outcomes in different, valid
Python implementations:

   4 is 4
   (x,) is (x,)
   "hello" is "hello"


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

decimal numbers

[luke . geelen]

hello,
i have been working on a python resistor calculator to let my class show what 
you can do with python.
now i have a script that makes the more speekable value of the resistance (res)

#if len(str(res)) > 9:
#  res2 = res / 10
#  print "de weerstand is %s,%s giga ohms" % (res2)
#elif len(str(res)) > 6:
#  res2 = res / 100
#  print "de weerstand is %s,%s Mega ohm" % (res2)
#elif len(str(res)) > 3:
#  res2 = res / 1000
#  print "de weerstand is", res2,"kilo ohm"
#elif len(str(res)) < 4:
#  res2 = res
#  print "de weerstand is", res2,"ohm"

i commented it because it doesn't work (yet), when i have a resistance of 
9.9 Giga ohms it says it is 9 giga ohms. it seems to work with natural number, 
anyway of using decimals insted so that it says : the resistance is 9.9 Giga 
Ohms instead of 9 ?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: decimal numbers

[Luke Geelen]

Op zaterdag 15 februari 2014 10:18:36 UTC+1 schreef Luke Geelen:
> hello,
> 
> i have been working on a python resistor calculator to let my class show what 
> you can do with python.
> 
> now i have a script that makes the more speekable value of the resistance 
> (res)
> 
> 
> 
> #if len(str(res)) > 9:
> 
> #  res2 = res / 10
> 
> #  print "de weerstand is %s,%s giga ohms" % (res2)
> 
> #elif len(str(res)) > 6:
> 
> #  res2 = res / 100
> 
> #  print "de weerstand is %s,%s Mega ohm" % (res2)
> 
> #elif len(str(res)) > 3:
> 
> #  res2 = res / 1000
> 
> #  print "de weerstand is", res2,"kilo ohm"
> 
> #elif len(str(res)) < 4:
> 
> #  res2 = res
> 
> #  print "de weerstand is", res2,"ohm"
> 
> 
> 
> i commented it because it doesn't work (yet), when i have a resistance of 
> 
> 9.9 Giga ohms it says it is 9 giga ohms. it seems to work with natural 
> number, anyway of using decimals insted so that it says : the resistance is 
> 9.9 Giga Ohms instead of 9 ?

, wait i have put one %s to much in the print function. this is from a other 
attempt so please excuse me
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Marko Rauhamaa]

Ben Finney :
> You should never need to predict the result of an ‘is’ operation.
> (More precisely, for *some* cases you can predict it, but for other
> cases you can't.)

No problem there. You have to understand "is" well to use it.

Referring to "objects in memory" when defininig "is" leads to circular
definitions. It think the best way to define the semantics of "is" is
through constraints:

  1. if x is y then y ix x

  2. if x is y and y is z then x is z

  3. after x = y, x is y

  4. if x is y, then x == y

That's why "is" is not introductory material.

The constraints define a relation that coincides with == wherever it is
defined. So why would you ever use "is" instead of "=="? After all, all
well-defined programs would behave identically after replacing "is" with
"==". Really, the only reason would be performance; "is" is often faster
to evaluate than "==".


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Christian Gollwitzer]

Hi Dave,

Am 14.02.14 19:08, schrieb dave em:

He is asking a question I am having trouble answering which is how a
variable containing a value differs from a variable containing a list
or more specifically a list reference.


as others have explained better and in more detail, there are mutable 
and immutable values. The point is, that in


a=b

and

a[1] = x

the "=" behaves differently. In the first case, you discard the 
reference, where a is pointing to, and bind to the same thing as b is 
pointing to. In the second case, you modify the thing that a is pointing 
to.


Recently, we tripped upon such a thing in a bad way; we were doing least 
squares fitting with numpy, and the parameters passed through were 
modified in the residuals function. That caused the LS algorithm to 
fail. After we got suspicious about this, we tried to remedy by copying 
the parameters


param_copy = param[:]

It still didn't work, because a list behaves differently than a numpy 
array in this respect, to our big surprise:


# list slicing, as we know it
>>> a=[1,2,3,4]
>>> b=a[:] # list slicing creates a copy
>>> b[1]=123
>>> b
[1, 123, 3, 4]
>>> a
[1, 2, 3, 4]

# now numpy array slicing
>>> import numpy as np
>>> a=np.array([1, 2, 3, 4])
>>> a
array([1, 2, 3, 4])
>>> b=a[:] # numpy slicing creates a reference
>>> b[1]=123
>>> b
array([  1, 123,   3,   4])
>>> a
array([  1, 123,   3,   4])


Lesson learned: Don't modify parameters you got passed, if possible. It 
is rarely what you want and can sometimes even happen, when you know you 
don't want it.


Christian
--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Christian Gollwitzer]

Am 15.02.14 01:57, schrieb Chris Angelico:

Can you give an example of an ambiguous case? Fundamentally, the 'is'
operator tells you whether its two operands are exactly the same
object, nothing more and nothing less, so I assume your "ambiguous
cases" are ones where it's possible for two things to be either the
same object or two indistinguishable ones.


What about the thing I posted down in this thread?

>>> import numpy as np
>>> a=np.array([1, 2, 3, 4])
>>> b=a[:]
>>> id(a)
140267900969344
>>> id(b)
140267901045920

So, a and b are different things, right?

>>> b[1]=37
>>> b
array([ 1, 37,  3,  4])
>>> a
array([ 1, 37,  3,  4])

Still they are connected. I can imagin that id() is just a debugging 
tool for extensions. What useful applications does it have outside of this?


Christian

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

Re: decimal numbers

[Frank Millman]

"Luke Geelen"  wrote in message 
news:ec88852e-1384-4aa5-834b-85135be94...@googlegroups.com...
> Op zaterdag 15 februari 2014 10:18:36 UTC+1 schreef Luke Geelen:
> hello,
>
> i have been working on a python resistor calculator to let my class show 
> what you can do with python.
>
> now i have a script that makes the more speekable value of the resistance 
> (res)
>
[...]
>
> i commented it because it doesn't work (yet), when i have a resistance of
>
> 9.9 Giga ohms it says it is 9 giga ohms. it seems to work with natural 
> number, anyway of using decimals insted so that it says : the resistance 
> is 9.9 Giga Ohms instead of 9 ?
>

You don't say which version of python you are using.

If you are using python2, an integer divided by an integer always returns an 
integer -

>>> 10/3
3

It was changed in python3 to return a float -

>>> 10/3
3.3335

You can reproduce the python3 behaviour in python2 by adding a 'future' 
directive -

>>> from __future__ import division
>>> 10/3
3.3335

HTH

Frank Millman



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

Re: Explanation of list reference

[Marko Rauhamaa]

Christian Gollwitzer :

> Still they are connected. I can imagin that id() is just a debugging
> tool for extensions. What useful applications does it have outside of
> this?

Calculating hash keys quickly.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: decimal numbers

[Chris Angelico]

On Sat, Feb 15, 2014 at 9:04 PM, Frank Millman  wrote:
> If you are using python2, an integer divided by an integer always returns an
> integer -
>
 10/3
> 3
>
> It was changed in python3 to return a float -
>
 10/3
> 3.3335
>
> You can reproduce the python3 behaviour in python2 by adding a 'future'
> directive -
>
 from __future__ import division
 10/3
> 3.3335
>

Conversely, you can get an integer result by using floor division:

>>> 10//3
3

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

Re: Explanation of list reference

[Marko Rauhamaa]

Marko Rauhamaa :

>   1. if x is y then y ix x
>   2. if x is y and y is z then x is z
>   3. after x = y, x is y
>   4. if x is y, then x == y

A new attempt:

   0. x is x
   1. if x is y then y ix x
   2. if x is y and y is z then x is z
   3. after x = y, x is y
   4. if x is y and x == x, then x == y
   5. id(x) == id(y) iff x is y

Does that cover it?


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Steven D'Aprano]

On Sat, 15 Feb 2014 11:10:46 +0200, Marko Rauhamaa wrote:

> Chris Angelico :
> 
>> On Sat, Feb 15, 2014 at 8:43 AM, Marko Rauhamaa 
>> wrote:
>>> Unfortunately neither the "everything is a reference" model nor the
>>> "small/big" model help you predict the value of an "is" operator in
>>> the ambiguous cases.
>>
>> Can you give an example of an ambiguous case?
> 
> The "x is y" test may yield different outcomes in different, valid
> Python implementations:
> 
>4 is 4
>(x,) is (x,)
>"hello" is "hello"


But none of those examples are ambiguous. They're merely unspecified by 
the language definition. Any specific implementation of Python will 
return either True or False; it may be predictable, or it might be 
impossible to predict until runtime, but either way we know that every 
non-broken Python virtual machine must either treat the two operands as 
the same object or different objects.

These are ambiguous sentences:

I saw the man with the binoculars.
Police help assault victim.
Once there was a blind carpenter who picked up his hammer and saw.
Look at that cat with one eye.

"A Python implementation can choose whether or not to re-use immutable 
objects" is not ambiguous. It's just a choice.



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

Re: decimal numbers

[Luke Geelen]

Op zaterdag 15 februari 2014 11:04:17 UTC+1 schreef Frank Millman:
> "Luke Geelen"  wrote in message 
> 
> news:ec88852e-1384-4aa5-834b-85135be94...@googlegroups.com...
> 
> > Op zaterdag 15 februari 2014 10:18:36 UTC+1 schreef Luke Geelen:
> 
> > hello,
> 
> >
> 
> > i have been working on a python resistor calculator to let my class show 
> 
> > what you can do with python.
> 
> >
> 
> > now i have a script that makes the more speekable value of the resistance 
> 
> > (res)
> 
> >
> 
> [...]
> 
> >
> 
> > i commented it because it doesn't work (yet), when i have a resistance of
> 
> >
> 
> > 9.9 Giga ohms it says it is 9 giga ohms. it seems to work with natural 
> 
> > number, anyway of using decimals insted so that it says : the resistance 
> 
> > is 9.9 Giga Ohms instead of 9 ?
> 
> >
> 
> 
> 
> You don't say which version of python you are using.
> 
> 
> 
> If you are using python2, an integer divided by an integer always returns an 
> 
> integer -
> 
> 
> 
> >>> 10/3
> 
> 3
> 
> 
> 
> It was changed in python3 to return a float -
> 
> 
> 
> >>> 10/3
> 
> 3.3335
> 
> 
> 
> You can reproduce the python3 behaviour in python2 by adding a 'future' 
> 
> directive -
> 
> 
> 
> >>> from __future__ import division
> 
> >>> 10/3
> 
> 3.3335
> 
> 
> 
> HTH
> 
> 
> 
> Frank Millman

how (and where) would i add this rule into a script? by import or the 
calculation?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Steven D'Aprano]

On Sat, 15 Feb 2014 11:31:42 +0200, Marko Rauhamaa wrote:


> It think the best way to define the semantics of "is" is
> through constraints:
> 
>   1. if x is y then y ix x
> 
>   2. if x is y and y is z then x is z
> 
>   3. after x = y, x is y
> 
>   4. if x is y, then x == y

Incorrect.

py> x = float('nan')
py> y = x
py> x is y
True
py> x == y
False


> That's why "is" is not introductory material.

No. "is" is not introductory material because it is an attractive 
nuisance for beginners. Beginners have a tendency to think that "is" is a 
synonym for "equals", as it can be in English. Sometimes it appears to 
work:

x = 2
y = x*3 - 4
x is y
=> probably returns True

but in other cases it fails, confusing the beginner.

With the exception of "is None", beginners almost never need "is".


> The constraints define a relation that coincides with == wherever it is
> defined. 

It certainly does not.

class Wacky:
def __eq__(self, other):
return random.random() < 0.5


> So why would you ever use "is" instead of "=="? After all, all
> well-defined programs would behave identically after replacing "is" with
> "==".  Really, the only reason would be performance; "is" is often
> faster to evaluate than "==".

Incorrect. "is" is NOT equivalent to ==, the two are not guaranteed to do 
the same thing, you CANNOT safely replace "is" with == or visa versa, and 
the meaning of the "is" operator is completely different from the meaning 
of the == operator.

The "is" operator tests whether the two operands are the same object, 
nothing more, nothing less. The == operator tests whether the two 
operands compare equal.


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

Re: decimal numbers

[Frank Millman]

"Luke Geelen"  wrote in message 
news:ae0da085-6c41-4166-92d2-92611a990...@googlegroups.com...
> Op zaterdag 15 februari 2014 11:04:17 UTC+1 schreef Frank Millman:
>> "Luke Geelen"  wrote in message
>>
>> news:ec88852e-1384-4aa5-834b-85135be94...@googlegroups.com...
>>
[...]
>>
>> You can reproduce the python3 behaviour in python2 by adding a 'future' 
>> directive -
>>
>> >>> from __future__ import division
>>
>> >>> 10/3
>>
>> 3.3335
>>
>
> how (and where) would i add this rule into a script? by import or the 
> calculation?

Treat it like any other import - add it as a new line at the top of your 
script.

Frank



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

Re: Explanation of list reference

[Steven D'Aprano]

On Sat, 15 Feb 2014 10:44:39 +0100, Christian Gollwitzer wrote:

> Am 15.02.14 01:57, schrieb Chris Angelico:
>> Can you give an example of an ambiguous case? Fundamentally, the 'is'
>> operator tells you whether its two operands are exactly the same
>> object, nothing more and nothing less, so I assume your "ambiguous
>> cases" are ones where it's possible for two things to be either the
>> same object or two indistinguishable ones.
> 
> What about the thing I posted down in this thread?
> 
>  >>> import numpy as np
>  >>> a=np.array([1, 2, 3, 4])
>  >>> b=a[:]
>  >>> id(a)
> 140267900969344
>  >>> id(b)
> 140267901045920
> 
> So, a and b are different things, right?

Correct. They are different objects. But they may share underlying state.


>  >>> b[1]=37
>  >>> b
> array([ 1, 37,  3,  4])
>  >>> a
> array([ 1, 37,  3,  4])

And indeed numpy arrays do share state. Why? No idea. Somebody thought 
that it was a good idea. (Not me though...)


> Still they are connected. I can imagin that id() is just a debugging
> tool for extensions. What useful applications does it have outside of
> this?

Very few.



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

Re: decimal numbers

[Frank Millman]

"Frank Millman"  wrote in message 
news:ldngnf$c3r$1...@ger.gmane.org...
>
> "Luke Geelen"  wrote in message 
> news:ae0da085-6c41-4166-92d2-92611a990...@googlegroups.com...
>> Op zaterdag 15 februari 2014 11:04:17 UTC+1 schreef Frank Millman:
>>> "Luke Geelen"  wrote in message
>>>
>>> news:ec88852e-1384-4aa5-834b-85135be94...@googlegroups.com...
>>>
> [...]
>>>
>>> You can reproduce the python3 behaviour in python2 by adding a 'future' 
>>> directive -
>>>
>>> >>> from __future__ import division
>>>
>>> >>> 10/3
>>>
>>> 3.3335
>>>
>>
>> how (and where) would i add this rule into a script? by import or the 
>> calculation?
>
> Treat it like any other import - add it as a new line at the top of your 
> script.
>

Actually I did not answer that very accurately. From the documentation -

"""
A future statement must appear near the top of the module. The only lines 
that can appear before a future statement are:

the module docstring (if any),
comments,
blank lines, and
other future statements.
"""

Frank



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

Re: Generator using item[n-1] + item[n] memory

[Steven D'Aprano]

On Fri, 14 Feb 2014 22:21:11 -0500, Roy Smith used a generator:

> print g1.next()

Roy, unless you're stuck with Python 2.5 (or older!), you ought to use 
the built-in function next(g1) rather than directly call the next method. 
Not only is this the recommended way to do it, but it's also more future-
proof (Python 3 drops the next method and makes it a dunder method) and 
has more functionality (the next() function takes an optional default 
value).


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

Re: Explanation of list reference

[Chris Angelico]

On Sat, Feb 15, 2014 at 8:31 PM, Marko Rauhamaa  wrote:
> Referring to "objects in memory" when defininig "is" leads to circular
> definitions. It think the best way to define the semantics of "is" is
> through constraints:
>
>   1. if x is y then y ix x
>
>   2. if x is y and y is z then x is z
>
>   3. after x = y, x is y

Yes. Yes. Yes.

>   4. if x is y, then x == y

No.

>>> x = float("nan")
>>> x == x
False

> The constraints define a relation that coincides with == wherever it is
> defined. So why would you ever use "is" instead of "=="? After all, all
> well-defined programs would behave identically after replacing "is" with
> "==". Really, the only reason would be performance; "is" is often faster
> to evaluate than "==".

Because your criteria are one-way. If x is y, then usually x == y, but
plenty of things compare equal that aren't identical.

>>> x = [1,2,3]
>>> y = [1,2,3]
>>> x == y
True
>>> x.pop()
3
>>> x == y
False

Two things may be equal now and not later, or vice versa, but if
they're identical, they will always be (because they're not "two
things" but one thing), and if they're not identical, they will never
be (because they really are two things, and the traditional marriage
ceremony with the "two becoming one" doesn't happen in computing).
Identity and equality are quite different states, and should be tested
for differently.

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

Re: Explanation of list reference

[Steven D'Aprano]

On Sat, 15 Feb 2014 12:13:54 +0200, Marko Rauhamaa wrote:

> Marko Rauhamaa :
> 
>>   1. if x is y then y ix x
>>   2. if x is y and y is z then x is z
>>   3. after x = y, x is y
>>   4. if x is y, then x == y
> 
> A new attempt:
> 
>0. x is x
>1. if x is y then y ix x
>2. if x is y and y is z then x is z
>3. after x = y, x is y
>4. if x is y and x == x, then x == y
>5. id(x) == id(y) iff x is y

Python implementations are free to re-use IDs after the object is 
destroyed. CPython does; Jython and IronPython do not. So #5 needs to 
point out that the condition id(x) == id(y) only applies if x and y still 
exist.

# Counter-example
py> x = 23
py> idx = id(x)
py> del x
py> y = 42
py> idy = id(y)
py> idx == idy
True


(This is *implementation dependent* so your mileage my vary.)


> Does that cover it?

No. Your definition describes some properties of identity-equivalence, 
but doesn't explain what identity actually means.


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

Re: Explanation of list reference

[Chris Angelico]

On Sat, Feb 15, 2014 at 8:44 PM, Christian Gollwitzer  wrote:
 import numpy as np
 a=np.array([1, 2, 3, 4])
 b=a[:]
 id(a)
> 140267900969344
 id(b)
> 140267901045920
>
> So, a and b are different things, right?
>
 b[1]=37
 b
> array([ 1, 37,  3,  4])
 a
> array([ 1, 37,  3,  4])
>
> Still they are connected.

Well, yes, they are different things; but that doesn't mean they can't
affect each other. And you don't need numpy to see that:

>>> d = {}
>>> k1 = d.keys()
>>> k2 = d.keys()
>>> k1 is k2
False
>>> k1 == k2
True
>>> d[1]=1
>>> k1
dict_keys([1])
>>> k2
dict_keys([1])

Two separate keys views on the same dictionary will, by definition,
always show the same keys (and, I think, in the same order). But
they're still separate objects. Their identities are distinct, their
values are linked.

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

Re: Install python 2 and 3 in the "wrong" order

[Nagy László Zsolt]

 From a cmd window:

ftype python.file="C:\Windows\py.exe" "%1" %*

ftype python.noconfile="C:\Windows\pyw.exe" "%1" %*

There is a serious problem with this! Example code test.py:

#!/usr/bin/env python3
import sys
print(sys.argv)

Test run:

C:\Temp>test.py 1 2 3
['C:\\Temp\\test.py']

This is too bad! Can somebody tell me what would be the good setup for 
py.exe? Do I have to reinstall Python3 with all libs? :-s

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

Re: Generator using item[n-1] + item[n] memory

[Peter Otten]

Chris Angelico wrote:

> On Sat, Feb 15, 2014 at 6:27 PM, Ian Kelly  wrote:
>> On Fri, Feb 14, 2014 at 8:31 PM, Nick Timkovich 
>> wrote:
>>> OK, now the trick; adding `data = None` inside the generator works, but
>>> in my actual code I wrap my generator inside of `enumerate()`, which
>>> seems to
>>> obviate the "fix".  Can I get it to play nice or am I forced to count
>>> manually. Is that a feature?
>>
>> Yeah, looks like enumerate also doesn't release its reference to the
>> previous object until after it gets the next one.  You'll just have to
>> make do without.
> 
> You could write your own enumerate function.
> 
> def enumerate(it, i=0):
> it = iter(it)
> while True:
> yield i, next(it)
> i += 1
> 
> That shouldn't keep any extra references around.

An alternative approach ist to yield weak refs and thus have the generator 
control the object lifetime. This doesn't work with the built-in list type 
though:

import weakref

try:
from itertools import imap # py2
except ImportError:
imap = map # py3

N = 0

def log_deleted(*args):
global N
N -= 1
print("deleted, new N: {}".format(N))

def log_created():
global N
N += 1
print("created, new N: {}".format(N))

def weakrefs(f):
def weakrefs(*args, **kw):
return imap(lambda x: weakref.proxy(x, log_deleted), f(*args, **kw))
return weakrefs

class List(list):
def __str__(self):
s = str(self[:5])
if len(self) > 10:
s = s[:-1] + ", ... ]"
return s

@weakrefs
def biggen():
sizes = 1, 1, 10, 1, 1, 10, 10, 1, 1, 10, 10, 20, 1, 1, 20, 20, 1, 1
for size in sizes:
data = List([1] * int(size * 1e4))
log_created()
yield data
data = None

if __name__ == "__main__":
for i, x in enumerate(biggen()):
print("{} {}".format(i, x))


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

Re: Explanation of list reference

[Gregory Ewing]

Steven D'Aprano wrote:
(1) General relativity tells us that not all observers will agree on the 
space-time coordinates of two objects, since not all observers agree on a 
single frame of reference.


But that doesn't mean they won't agree about whether
objects are identical or not! The coordinates they
use to describe spacetime locations may differ, but
they will agree on whether or not they are equal.
A Lorentz transformation can't cause a single point
in spacetime to split into two, or two distinct points
to merge into one.

(2) Quantum mechanics tells us that objects are not located at a single 
space-time coordinate. Objects are "smeared out" over space (and time). 
We cannot really talk about the location of an object, but only about the 
probability of a measurement registering the object at a certain location.


But that doesn't mean you can stuff two objects into
the same space at the same time. What we perceive as
solid objects are composed of fermions, which obey
the Pauli exclusion principle. That means you can't
have more than one of them in a given quantum state.
While you *could* have two of them equally spread out
over all of space, they would then have to be
separated in some other dimension such as momentum
or spin.

So if you replace "space-time coordinates" with
"quantum state", the original statement remains
essentially true.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Chris Angelico]

On Sat, Feb 15, 2014 at 9:13 PM, Marko Rauhamaa  wrote:
> A new attempt:

Sorry, hadn't seen this when I posted.

>0. x is x

This is the definition of identity.

>1. if x is y then y ix x

Yes, because if x is y, there is absolutely no difference between
using one of those names or the other, in any context.

>2. if x is y and y is z then x is z

Extension of the above. The first statement proves that you can
substitute 'x' for 'y' in the second without changing its truthiness;
therefore, based on the definition of identity, 'x is z' must be
identical to 'y is z'.

>3. after x = y, x is y

This is the definition of assignment. (Obviously this axiom depends on
x and y being simple names and nothing tampering with the situation in
any way. But yes, this is exactly what assignment is.)

>4. if x is y and x == x, then x == y

Yes. As in case 2, 'x is y' implies that you can substitute 'x' for
'y' or vice versa. Therefore, if x == x, then y == y, and x == y, and
y == x; because in each case, what you're doing is "object #1423443,
are you equal to object #1423443 or not?", regardless of the name you
use to access that object.

>5. id(x) == id(y) iff x is y

This is the definition of id(). Note that it does depend on something
holding a reference to each of x and y; if it's possible for the
objects' lifetimes to not overlap, it's possible for them to reuse
ids:

>>> [1,2,3] is [2,3,4]
False
>>> id([1,2,3]) == id([2,3,4])
True

But if x and y are simple names (and therefore retaining their
referent objects), then your statement is valid.

> Does that cover it?

Largely axiomatically, yes.

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

Re: Explanation of list reference

[Gregory Ewing]

Steven D'Aprano wrote:
IDs are a proxy for distinct objects. If you live in a country with an ID 
card of some sort, then the IDs acts as an identifier for each unique 
individual. But countries without ID cards don't lack unique individual 
people.


"You are Number Six."
"I am not an id()! I am an individual object!"

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Install python 2 and 3 in the "wrong" order

[Chris Angelico]

On Sat, Feb 15, 2014 at 10:25 PM, Nagy László Zsolt
 wrote:
>>  From a cmd window:
>>
>> ftype python.file="C:\Windows\py.exe" "%1" %*
>>
>> ftype python.noconfile="C:\Windows\pyw.exe" "%1" %*
>
> There is a serious problem with this! Example code test.py:
>
> #!/usr/bin/env python3
> import sys
> print(sys.argv)
>
> Test run:
>
> C:\Temp>test.py 1 2 3
> ['C:\\Temp\\test.py']
>

Just because I have a distrust of Windows's command interpreter, what
happens when you type:

ftype python.file

? Does it echo back what you thought it had, or has %* been eaten? If
the %* is missing, that would explain the loss of arguments.

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

Re: Explanation of list reference

[Chris Angelico]

On Sat, Feb 15, 2014 at 10:32 PM, Gregory Ewing
 wrote:
> Steven D'Aprano wrote:
>>
>> IDs are a proxy for distinct objects. If you live in a country with an ID
>> card of some sort, then the IDs acts as an identifier for each unique
>> individual. But countries without ID cards don't lack unique individual
>> people.
>
>
> "You are Number Six."
> "I am not an id()! I am an individual object!"

Make it so, Number One.

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

ipython

[greymausg]

using IPython, is there any way of recording the commands I have entered?


-- 
maus
 .
  .
...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Gregory Ewing]

Jussi Piitulainen wrote:

Would it help to say that in case 1 the relevant statement acts on the
variable while in case 2 it acts on the value of the variable?


I would try to avoid using words like "value" and "variable",
because they don't have well-defined meanings in Python.

The way I would put it is that

   a = b

changes which object the name 'a' refers to, whereas

   a[i] = b

does not.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Marko Rauhamaa]

Steven D'Aprano :

> On Sat, 15 Feb 2014 12:13:54 +0200, Marko Rauhamaa wrote:
>>0. x is x
>>1. if x is y then y ix x
>>2. if x is y and y is z then x is z
>>3. after x = y, x is y
>>4. if x is y and x == x, then x == y
>>5. id(x) == id(y) iff x is y
>
> # Counter-example
> py> x = 23
> py> idx = id(x)
> py> del x
> py> y = 42
> py> idy = id(y)
> py> idx == idy
> True

I don't accept that as a counterexample. You will have to produce:

   (id(x) == id(y)) == (x is y)
   > False

> (This is *implementation dependent* so your mileage my vary.)
>
>> Does that cover it?
>
> No. Your definition describes some properties of identity-equivalence,
> but doesn't explain what identity actually means.

That's the point. I don't think id() and "is" have any abstract meaning
on top of the formal axioms.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Gregory Ewing]

Chris Angelico wrote:

But yes, this is an expression, and it evaluates to a reference.


Well, *all* expressions in Python evaluate to references,
so that's not really saying much.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Ben Finney]

Jussi Piitulainen  writes:

> In cheese = spam, cheese is the variable while spam is a variable
> reference and stands for 42.

Oof. This distinction between “variable” and “variable reference” is
bogus and unnecessary, and highlights what is wrong with talking about
“variable” at all.

In the Python code ‘cheese = spam’, “cheese” is a name, and “spam” is a
name. Both of them are references (because all names are references).

The assignment binds the name “cheese” to whatever object the name
“spam” was bound to at that point in time.

In either case, a different kind of reference (for example, a list item)
could have been used. Names are merely one kind of reference.

> > >>> spam = [0, 1, 2, 3, 4, 5]
> > >>> cheese = spam
> > >>> cheese[1] = 'Hello!'
> > >>> spam
> > [0, 'Hello!', 2, 3, 4, 5]
> > >>> cheese
> > [0, 'Hello!', 2, 3, 4, 5]
>
> The first two statements in case 2 are assignments to variables, just
> like in case 1, but the third statement is different: it doesn't
> change the value of the variable (the value is still the same object)
> but it does change the value (replaces one element of the list with
> another).

Again, this distinction is nonsense and confusing.

What is happening in all those assignments is: A reference (the
expression on the left-hand-side of the ‘=’ symbol) is bound to an
object (the value resulting from the expression on the right-hand-side
of the ‘=’ symbol).

In the first two cases, the reference happens to be a name. In the third
case, the reference happens to be a list item.

> Would it help to say that in case 1 the relevant statement acts on the
> variable while in case 2 it acts on the value of the variable? This is
> accurate, I just don't know if it happens to be the thing that helps.

I think not. What would help is to abandon the “variable” baggage, and
focus on what assignment actually does: binds a reference to an object.

> One last thing: a variable is not an object.

Right. Also: a reference is not an object, but a reference always refers
to exactly one object.

-- 
 \ “Science is a way of trying not to fool yourself. The first |
  `\ principle is that you must not fool yourself, and you are the |
_o__)   easiest person to fool.” —Richard P. Feynman, 1964 |
Ben Finney

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

Re: Explanation of list reference

[Chris Angelico]

On Sat, Feb 15, 2014 at 11:18 PM, Gregory Ewing
 wrote:
> Chris Angelico wrote:
>>
>> But yes, this is an expression, and it evaluates to a reference.
>
>
> Well, *all* expressions in Python evaluate to references,
> so that's not really saying much.

Because everything in Python is an object, and objects always are
handled by their references. This wouldn't be true in every language
(eg it's not true of Java's unboxed types), but it's intrinsic to
Python's object model.

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

Re: ipython

[Mark Lawrence]

On 15/02/2014 11:55, greymausg wrote:

using IPython, is there any way of recording the commands I have entered?



I believe ipython automatically stores the commands you enter. 
Searching for ipython+command+history should get you more detail than I 
can offer :)


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: Generator using item[n-1] + item[n] memory

[Mark Lawrence]

On 15/02/2014 03:31, Nick Timkovich wrote:

OK, now the trick; adding `data = None` inside the generator works, but
in my actual code I wrap my generator inside of `enumerate()`, which
seems to obviate the "fix".  Can I get it to play nice or am I forced to
count manually. Is that a feature?


On Fri, Feb 14, 2014 at 9:21 PM, Roy Smith mailto:r...@panix.com>> wrote:

In article mailto:mailman.6952.1392433921.18130.python-l...@python.org>>,
  Nick Timkovich mailto:prometheus...@gmail.com>> wrote:

 > Ah, I think I was equating `yield` too closely with `return` in
my head.
 >  Whereas `return` results in the destruction of the function's
locals,
 > `yield` I should have known keeps them around, a la C's `static`
functions.
 >  Many thanks!

It's not quite like C's static.  With C's static, the static variables
are per-function.  In Python, yield creates a context per invocation.
Thus, I can do

def f():
 for i in range(1):
 yield i

g1 = f()
g2 = f()
print g1.next()
print g1.next()
print g1.next()
print g2.next()
print g1.next()


which prints 0, 1, 2, 0, 3.  There's two contexts active at the same
time, with a distinct instance of "i" in each one.
--
https://mail.python.org/mailman/listinfo/python-list



Nick, please don't top post on this list, thanks.

--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: Explanation of list reference

[Mark Lawrence]

On 15/02/2014 06:07, Rustom Mody wrote:

Then you are obliged to provide some other way of understanding object-identity


I have no interest in understanding object identity, I can write code 
quite happily without it.  If you (plural) are interested in 
understanding this subject I hope you enjoy comparing the various Python 
implementations while I'm *STILL* writing code.


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re:ipython

[Dave Angel]

 greymausg  Wrote in message:
> using IPython, is there any way of recording the commands I have entered?
> 

Try the history command.

 
 http://ipython.org/ipython-doc/rel-1.1.0/api/generated/IPython.
core.magics.history.html


-- 
DaveA

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

Re: Explanation of list reference

[Marko Rauhamaa]

Chris Angelico :

> Because everything in Python is an object, and objects always are
> handled by their references. This wouldn't be true in every language
> (eg it's not true of Java's unboxed types), but it's intrinsic to
> Python's object model.

Well, it's part of Python's reference model. Any model that produces
valid Python behavior is equally good. An implementation that boxes some
or all immutable objects would still be perfectly valid.

Anyway, an object is a fairly advanced and abstract concept. A beginning
programmer wouldn't be equipped to understand the ultimate abstraction;
an object is too all-encompassing to express anything. It might be
productive to lead the aspirant to the mountain summit through a more
concrete model. Identifying the references with RAM addresses and
objects with RAM snippets might keep object tangible for the first few
months, although a more mundane model would be welcome.

I'm reminded of Raymond Smullyan's excellent "To Mock the Mockingbird,"
which models combinatory logic with a forest full of chirping birds.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

[Q] Beaker 1.6.4 not work on Python3

[Makoto Kuwata]

Hi,

Does Beaker 1.6.4 work on Python3 ?
Is there anyone using Beaker on Python3?


I got the following error on Python 3.3:


  File "/opt/lang/python/3.2.2/lib/python3.2/http/cookies.py", line 486, in
__setitem__
rval, cval = self.value_encode(value)
  File
"/opt/lang/python/3.2.2/lib/python3.2/site-packages/Beaker-1.6.4-py3.2.egg/beaker/session.py",
line 70, in value_encode
sig = HMAC.new(self.secret, val.encode('UTF-8'), SHA1).hexdigest()
AttributeError: 'bytes' object has no attribute 'encode'


The following is a monkey patch to avoid this error,
but I'm not sure that it is correct solution.


from beaker.crypto import hmac as HMAC, hmac_sha1 as SHA1
from beaker.session import SignedCookie
def value_encode(self, val):
#sig = HMAC.new(self.secret, val.encode('UTF-8'), SHA1).hexdigest()
sig = HMAC.new(self.secret, val, SHA1).hexdigest()
return str(val), ("%s%s" % (sig, val))
SignedCookie.value_encode = value_encode


And, even with monkey patching, Beaker's SessionMiddleware
doesn't save session correctly on Python3.


Please help me: I want to run Beaker 1.6.4 on Python 3.
(Pyton 3.3.3, MacOSX)

Here is my sample code (which works on Python2.7 very well!):
--
# -*- coding: utf-8 -*-

import sys
import waitress
from beaker.middleware import SessionMiddleware

def testapp(environ, start_response):
session = environ.get('beaker.session')
count = session.get('count', 0) + 1
session['count'] = count
session.save()
content = "count=%s" % count
#
start_response('200 OK', [('Content-Type', 'text/plain')])
return [content.encode('utf-8')]

config = {
'session.type': 'cookie',
'session.validate_key': 'mysecretstring',
}
app = SessionMiddleware(testapp, config=config)

## monkey patch for Python3
python3 = sys.version_info[0] == 3
if 0 and python3:
from beaker.crypto import hmac as HMAC, hmac_sha1 as SHA1
from beaker.session import SignedCookie
def value_encode(self, val):
#sig = HMAC.new(self.secret, val.encode('UTF-8'), SHA1).hexdigest()
sig = HMAC.new(self.secret, val, SHA1).hexdigest()
return str(val), ("%s%s" % (sig, val))
SignedCookie.value_encode = value_encode
## 

waitress.serve(app, port=8080)
--

--
regards,
makoto kuwata
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [RELEASED] Python 3.3.4

[Makoto Kuwata]

Congrat!

By the way, I can't find Python-3.3.4.tar.bz2 in:
http://www.python.org/ftp/python/3.3.4/

Python-3.3.{1,2,3}.tar.bz2 and Python-3.4.0.tar.bz2 are provided,
but Python-3.3.4.tar.bz2 is not. Why?
# I hope that Python-3.3.4.tar.bz2 is also provided.

--
regards,
makoto kuwata



On Tue, Feb 11, 2014 at 5:55 AM, Georg Brandl  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On behalf of the Python development team, I'm very happy to announce
> the release of Python 3.3.4.
>
> Python 3.3.4 includes several security fixes and over 120 bug fixes
> compared to the Python 3.3.3 release.
>
> This release fully supports OS X 10.9 Mavericks.  In particular, this
> release fixes an issue that could cause previous versions of Python to
> crash when typing in interactive mode on OS X 10.9.
>
> Python 3.3 includes a range of improvements of the 3.x series, as well
> as easier porting between 2.x and 3.x.  In total, almost 500 API items
> are new or improved in Python 3.3.  For a more extensive list of
> changes in the 3.3 series, see
>
> http://docs.python.org/3.3/whatsnew/3.3.html
>
> To download Python 3.3.4 visit:
>
> http://www.python.org/download/releases/3.3.4/
>
>
> This is a production release, please report any bugs to
>
>  http://bugs.python.org/
>
>
> Enjoy!
>
> - --
> Georg Brandl, Release Manager
> georg at python.org
> (on behalf of the entire python-dev team and 3.3's contributors)
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> iEYEARECAAYFAlL5PMwACgkQN9GcIYhpnLCv4wCePNVqwsOYCHdJBix2bKk4PNpK
> GBoAnRML2x6obCssnUJe5xwuUZYw8ZSY
> =+/Nz
> -END PGP SIGNATURE-
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Install python 2 and 3 in the "wrong" order

[Nagy László Zsolt]

Just because I have a distrust of Windows's command interpreter, what
happens when you type:

ftype python.file

? Does it echo back what you thought it had, or has %* been eaten? If
the %* is missing, that would explain the loss of arguments.


Already tought of that:


C:\Temp>ftype python.file
python.file="C:\Windows\py.exe" "%1" %*

C:\Temp>

Something else is going on.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Marko Rauhamaa]

Mark Lawrence :

> I have no interest in understanding object identity, I can write code
> quite happily without it.

Luckily, what we are now debating is mostly terminology and points of
view where the outcomes are unaffected.

However, as an example, it is important to know if you should write:

   if x is not None:
   ...

or if

   if x != None:
   ...

is more robust.

As an aside, thousands upon thousands of Java programmers churn out code
quite happily with no interest in understanding the "happens before"
relation (http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4.5>),
which is heavily leaned on by Hotspot's JIT optimizer. I find that
disconcerting.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ipython

[greymausg]

On 2014-02-15, Mark Lawrence  wrote:
> On 15/02/2014 11:55, greymausg wrote:
>> using IPython, is there any way of recording the commands I have entered?
>>
>
> I believe ipython automatically stores the commands you enter. 
> Searching for ipython+command+history should get you more detail than I 
> can offer :)
>

What I was thinking of is like a perl Module WWW::Mechanize::Shell,
which has a script included, "wwwshell.pl", which allows you to
enter commands to explore web sites, then enter "source x",
and it will save the commands you have used to a script, 'x'.
This can be run straight to do what you want, say scraping a 
web site. 


-- 
maus
 .
  .
...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Ben Finney]

Marko Rauhamaa  writes:

> Anyway, an object is a fairly advanced and abstract concept.

It is a concept that, in natural language, has the huge advantage of
producing correct inferences most of the time.

You don't need to give a formal definition when first introducing the
term “object”. Just use it, and the student will produce inferences:

* an object is a distinct concrete entity

* an object is distinct from other objects

* an object may or may not change, but remains the same object

* an object belongs to a class of similar objects, and is different from
  objects of different classes

* an object has behaviours that are mostly the same as other objects of
  the same class

None of this needs to be spelled out when the term is introduced; all of
it will follow from the connotations of the term “object” in English.

> A beginning programmer wouldn't be equipped to understand the ultimate
> abstraction; an object is too all-encompassing to express anything.

Nevertheless, “object” as a term in normal English will produce a bunch
of helpful inferences, and avoid the need for coming up with some
less-familiar term. It will also allow you to postpone a formal
definition until later.

-- 
 \   “Try to learn something about everything and everything about |
  `\  something.” —Thomas Henry Huxley |
_o__)  |
Ben Finney

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

Re: How to turn a package into something pip can install

[Chris “Kwpolska” Warrick]

On Sat, Feb 15, 2014 at 3:26 AM, Roy Smith  wrote:
> In article ,
>  Ryan Gonzalez  wrote:
>
>> python setup.py sdist
>
> OK, I run that and I get a metar-1.4.0.tar.gz under dist.  If I move
> that tarfile to my packages directory, and run pip, I get:
>
> $ pip install --no-index --quiet --find-links packages metar==1.4.0
[snip]
> ValueError: unknown url type: packages

The path to your cache directory is incorrect.  I suggest using
absolute paths (eg. /home/user/packages) instead of relative paths,
which is likely what caused this issue.

On Fri, Feb 14, 2014 at 7:47 PM, Roy Smith  wrote:
> What I can't figure out is what I need to do to go from a clone of the
> github repo to a tarball I can drop into our packages directory.  Is
> there some tutorial somewhere that explains this?

Actually, you could even tar up that entire repo (or even get a nice
ready tarball from GItHub) and you will get something usable with pip.
 For example, we in the Nikola project
(https://github.com/getnikola/nikola) upload the GitHub tarballs to
PyPI because we ship 99.9% of our tree anyways and hiring `setup.py
sdist` would be a waste of time (and would produce two
almost-identical-but-not-quite tarballs).

-- 
Chris “Kwpolska” Warrick 
PGP: 5EAAEA16
stop html mail | always bottom-post | only UTF-8 makes sense
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Localized Type Inference of Atomic Types in Python

[anand]

On Wednesday, May 25, 2005 4:41:34 AM UTC+5:30, Brett C. wrote:
> My thesis, "Localized Type Inference of Atomic Types in Python", was
> successfully defended today for my MS in Computer Science at the California
> Polytechnic State University, San Luis Obispo.  With that stamp of approval I
> am releasing it to the world.  You can grab a copy at
> http://www.drifty.org/thesis.pdf .


Hi,
  This link seems to be down. Can you point us to some current link? Am trying 
to contribute to https://code.google.com/p/py2c/ and reading up on type 
inference for python.

Thanks and Regards,
Anand 

> 
> For those of you who attended my talk at PyCon 2005 this is the thesis that
> stemmed from the presented data.
> 
> As of this exact moment I am not planning to release the source code mainly
> because it's a mess, I am not in the mood to pull the patches together, and 
> the
> last thing I want happening is people finding mistakes in the code.  =)  But 
> if
> enough people request the source I will take the time to generate a tar.bz2
> file of patches against the 2.3.4 source release and put them up somewhere.
> 
> Below is the abstract culled directly from the thesis itself.
> 
> -Brett C.
> 
> -
> ABSTRACT
> 
> Types serve multiple purposes in programming.  One such purpose is in 
> providing
> information to allow for improved performance.  Unfortunately, specifying the
> types of all variables in a program does not always fit within the design of a
> programming language.
> 
> Python is a language where specifying types does not fit within the language
> design.  An open source, dynamic programming language, Python does not support
> type specifications of variables.  This limits the opportunities in Python for
> performance optimizations based on type information  compared to languages 
> that
> do allow or require the specification of types.
> 
> Type inference is a way to derive the needed type information for 
> optimizations
> based on types without requiring type specifications in the source code of a
> program.  By inferring the types of variables based on flow control and other
> hints in a program, the type information can be derived and used in a
> constructive manner.
> 
> This thesis is an exploration of implementing a type inference algorithm for
> Python without changing the semantics of the language.  It also explores the
> benefit of adding type annotations to method calls in order to garner more 
> type
> information.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Ben Finney]

Joshua Landau  writes:

> Here, I give you a pdf. Hopefully this isn't anti
> mailing-list-etiquette.

This forum is read in many different contexts, and attachments aren't
appropriate. You should simply put the text directly into your message,
if it's short enough.

If it's long, then put it online somewhere and send a link with a
description; or, better, make it shorter so it is reasonable to put the
text in a message :-)

-- 
 \ “Smoking cures weight problems. Eventually.” —Steven Wright |
  `\   |
_o__)  |
Ben Finney

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

Re: Localized Type Inference of Atomic Types in Python

[Chris Angelico]

On Sun, Feb 16, 2014 at 1:13 AM,   wrote:
> On Wednesday, May 25, 2005 4:41:34 AM UTC+5:30, Brett C. wrote:
>> My thesis, "Localized Type Inference of Atomic Types in Python", was
>> successfully defended today for my MS in Computer Science at the California
>> Polytechnic State University, San Luis Obispo.  With that stamp of approval I
>> am releasing it to the world.  You can grab a copy at
>> http://www.drifty.org/thesis.pdf .
>
>
> Hi,
>   This link seems to be down. Can you point us to some current link? Am 
> trying to contribute to https://code.google.com/p/py2c/ and reading up on 
> type inference for python.

I think you realize that you're responding to a nine-year-old post
here, but it's possible not everyone does :) Anyway... Tracing the
file through the Internet Archive comes up with this:

https://web.archive.org/web/20061223193827/http://www.ocf.berkeley.edu/~bac/thesis.pdf

I don't know if Brett Cannon (author of the post and thesis) reads
python-list/c.l.p, but as a core developer, he's visible on
python-dev. Depending on what you're trying to do, it may be
appropriate to post there, if after a while (maybe a week) you haven't
heard anything useful from here.

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

Re: Explanation of list reference

[Chris Angelico]

On Sun, Feb 16, 2014 at 1:20 AM, Ben Finney  wrote:
> Joshua Landau  writes:
>
>> Here, I give you a pdf. Hopefully this isn't anti
>> mailing-list-etiquette.
>
> This forum is read in many different contexts, and attachments aren't
> appropriate. You should simply put the text directly into your message,
> if it's short enough.
>
> If it's long, then put it online somewhere and send a link with a
> description; or, better, make it shorter so it is reasonable to put the
> text in a message :-)

I skimmed it, and... uhh... it's not text :) Well, it's mostly text,
but it's arranged on the page with positioning and arrows and stuff.
So a link would be more useful than trying to cram it into the post
itself.

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

Re: Localized Type Inference of Atomic Types in Python

[Mark Lawrence]

On 15/02/2014 14:13, an...@chatimity.com wrote:

On Wednesday, May 25, 2005 4:41:34 AM UTC+5:30, Brett C. wrote:

My thesis, "Localized Type Inference of Atomic Types in Python", was
successfully defended today for my MS in Computer Science at the California
Polytechnic State University, San Luis Obispo.  With that stamp of approval I
am releasing it to the world.  You can grab a copy at
http://www.drifty.org/thesis.pdf .



Hi,
   This link seems to be down. Can you point us to some current link? Am trying 
to contribute to https://code.google.com/p/py2c/ and reading up on type 
inference for python.

Thanks and Regards,
Anand



Hardly surprising for a nine year old link but search for 
brett+cannon+python+thesis and you'll find it :)


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: Explanation of list reference

[Steven D'Aprano]

On Sat, 15 Feb 2014 14:07:35 +0200, Marko Rauhamaa wrote:

> Steven D'Aprano :
> 
>> On Sat, 15 Feb 2014 12:13:54 +0200, Marko Rauhamaa wrote:
>>>0. x is x
>>>1. if x is y then y ix x
>>>2. if x is y and y is z then x is z
>>>3. after x = y, x is y
>>>4. if x is y and x == x, then x == y
>>>5. id(x) == id(y) iff x is y
>>
>> # Counter-example
>> py> x = 23
>> py> idx = id(x)
>> py> del x
>> py> y = 42
>> py> idy = id(y)
>> py> idx == idy
>> True
> 
> I don't accept that as a counterexample. 

Why? Do you think I lied and just faked the output I put into my post? It 
is a clear case where two distinct objects, in this case 23 and 
42, have the same ID.

You cut out the explanation I gave explaining the example, which is 
crucial. Your description of identity leaves out a critical factor, 
namely that the objects being discussed must exist simultaneously. If you 
don't specify that factor, your description includes a great big hole, 
just as I show above.


> You will have to produce:
> 
>(id(x) == id(y)) == (x is y)
>> False

I don't have to produce anything of the sort. All I need to do is show a 
case where two distinct objects have the same ID. That is quite easy in 
CPython, since IDs can be re-used after objects are garbage-collected.


>> (This is *implementation dependent* so your mileage my vary.)
>>
>>> Does that cover it?
>>
>> No. Your definition describes some properties of identity-equivalence,
>> but doesn't explain what identity actually means.
> 
> That's the point. I don't think id() and "is" have any abstract meaning
> on top of the formal axioms.

Who is talking about "abstract meaning"? They have concrete meaning in 
Python, and extremely simple meaning at that. 

* id() is a function which returns an abstract implementation-
  dependent identity number which is unique for each object 
  during the object's lifetime.

* The "is" operator compares the two operands for identity, 
  returning True if, and only if, they are the same object, 
  otherwise returning False.

Object identity is simple and well-defined in Python. I don't know why 
you are so resistant to this. Read the documentation.



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

Re: ipython

[Peter Otten]

greymausg wrote:

> using IPython, is there any way of recording the commands I have entered?

Did you ever enter

?

in ipython?

In [1]: a = float(raw_input("a? "))
a? 1

In [2]: b = float(raw_input("b? "))
b? 2

In [3]: ab = a + b

In [4]: c = ab*ab

In [5]: print c
9.0

In [6]: In[1:3]
Out[6]: u'a = float(raw_input("a? "))\nb = float(raw_input("b? "))\n'

In [7]: %macro abc 1:6
Macro `abc` created. To execute, type its name (without quotes).
Macro contents:
a = float(raw_input("a? "))
b = float(raw_input("b? "))
ab = a + b
c = ab*ab
print c


In [8]: abc
--> abc()
a? 2
b? 2
16.0

In [14]: 



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

Re: decimal numbers

[Laurent Pointal]

luke.gee...@gmail.com wrote:

> hello,
> i have been working on a python resistor calculator to let my class show
> what you can do with python. now i have a script that makes the more
> speekable value of the resistance (res)
> 
> #if len(str(res)) > 9:
> #  res2 = res / 10
> #  print "de weerstand is %s,%s giga ohms" % (res2)
> #elif len(str(res)) > 6:
> #  res2 = res / 100
> #  print "de weerstand is %s,%s Mega ohm" % (res2)
> #elif len(str(res)) > 3:
> #  res2 = res / 1000
> #  print "de weerstand is", res2,"kilo ohm"
> #elif len(str(res)) < 4:
> #  res2 = res
> #  print "de weerstand is", res2,"ohm"
> 
> i commented it because it doesn't work (yet), when i have a resistance of
> 9.9 Giga ohms it says it is 9 giga ohms. it seems to work with natural
> number, anyway of using decimals insted so that it says : the resistance
> is 9.9 Giga Ohms instead of 9 ?

Seem you are using Python2, if res is an integer the division by an integer 
values produce an integer result (changed in Python3), so you loose the 
decimal part.

Try dividing by floating point numbers, like res2 = res / 1000.


Note: should take a lok at the log10() function from math module.

(with Python3)

In [1]: from math import log10

In [2]: r = 132828378723

In [3]: int(log10(r))
Out[3]: 11

In [4]: r / 10**int(log10(r))
Out[4]: 1.32828378723

A+
Laurent.

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

Re: ipython

[greymausg]

On 2014-02-15, greymausg  wrote:
> On 2014-02-15, Mark Lawrence  wrote:
>> On 15/02/2014 11:55, greymausg wrote:
>>> using IPython, is there any way of recording the commands I have entered?
>>>
>>
>> I believe ipython automatically stores the commands you enter. 
>> Searching for ipython+command+history should get you more detail than I 
>> can offer :)
>>
>
> What I was thinking of is like a perl Module WWW::Mechanize::Shell,
> which has a script included, "wwwshell.pl", which allows you to
> enter commands to explore web sites, then enter "source x",

Sorry "script x"

> and it will save the commands you have used to a script, 'x'.
> This can be run straight to do what you want, say scraping a 
> web site. 
>
>


-- 
maus
 .
  .
...
-- 
https://mail.python.org/mailman/listinfo/python-list

Absolute imports?

[Roy Smith]

http://docs.python.org/2/whatsnew/2.5.html says:

"Once absolute imports are the default, import string will always find 
the standard library¹s version."

Experimentally, it appears that modules in site-packages are also found 
by absolute imports.  I wouldn't consider site-packages to be part of 
the "standard library".  Can somebody give me a more precise description 
of what absolute import does?

It also says, "This absolute-import behaviour will become the default in 
a future version (probably Python 2.7)", but it appears that 2.7.6 is 
still doing relative by default.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Absolute imports?

[Chris Angelico]

On Sun, Feb 16, 2014 at 2:06 AM, Roy Smith  wrote:
> It also says, "This absolute-import behaviour will become the default in
> a future version (probably Python 2.7)", but it appears that 2.7.6 is
> still doing relative by default.
>

Since absolute imports can be controlled with a future directive, you
can check it out via that module:

>>> import __future__
>>> __future__.absolute_import
_Feature((2, 5, 0, 'alpha', 1), (3, 0, 0, 'alpha', 0), 16384)

Looks like it was held over for 3.0 rather than potentially breaking
stuff across 2.6->2.7.

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

Quick Help

[kjakupak]

Just need a bit of help understanding this so I can actually start it. 

The input to a program will come from a file called "asdf.in". This file will 
have all the info needed for the course. The formatting of the input file is 
described as follows, with  denoting # of white spaces and  denoting 
n white spaces.

Title:
Title:
etc..

Is it asking me to make an input file with all of that info (like it is above), 
or to have an info file actually filled with all that information filled out? 
Because I then need to have the program be able to output info in certain 
formats that come from that input file.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question on using FP numbers in python 2

[Steven D'Aprano]

On Sat, 15 Feb 2014 00:07:49 -0500, Gene Heskett wrote:

>> Can you extract the float calculations and show us, together with some
>> sample data, expected result, and actual result?
> 
> Not extract, but let you get & look at the code, its the top entry on
> this page:
> 
>  Code_Generators#Counterbore_Software>

Here is the direct link to the Python code:

http://wiki.linuxcnc.org/uploads/counterbore.py


> Assume no bolt size is clicked on, but a wanted diameter is entered in
> the lower left pair of boxes, and its to carve .700" deep in the other
> box. The cutting tool is .250 in diameter, its to do a stepover of 25%
> of the tool diameter, while carving an additional .015" out of the .850"
> hole with the tool bit turning 2000 rpm as it spirals down.

If I've understood the purpose of this program correctly, it generates 
code in some language called "G-code", presumably to control some sort of 
actual physical cutting machine. So the first thing you ought to do is 
have a G-code expert look at the generated code and tell you it does what 
it is supposed to do. Or perhaps your cutting machine is buggy.

> But the hole it will cut will only be .650" in diameter,  And the
> backplot, shown in the axis interface, shows no spiral, its doing what
> it thinks is full diameter in one circular plunge cut.


Scroll to the GeneratePath method, and read the comments at the top of 
the method. They tell you that the *intention* is:

* If the tool diameter equals the hole diameter, then just Plunge 
  down to the hole depth.
 
* If the tool diameter is less than 80% of the hole diameter, 
  then Plunge to each Level and Spiral out.

* If the tool diameter is greater than 80% of the hole diameter,
  then Spiral to each Level and Spiral out.

But a little later, we see this code:

# Figure out what kind of entry into the hole
if (self.ToolDiameter * 1.25 <= self.HoleDiameter):
self.CutType = 'Spiral Down to Depth of each Pass and Spiral Out'
else:
if (self.ToolDiameter < self.HoleDiameter):
self.CutType = 'Plunge Down to Depth of each Pass and Spiral 
Out'
else:
self.CutType = 'Plunge Down to Hole Depth'


Assuming that the comments are correct, the CutType is wrong. It looks 
like a simple logic error, and should be something like this:

# Figure out what kind of entry into the hole
if (self.ToolDiameter * 1.25 <= self.HoleDiameter):
self.CutType = 'Plunge down and spiral out'
elif (self.ToolDiameter * 1.25 > self.HoleDiameter):
self.CutType = 'Spiral down and spiral out'
else:
self.CutType = 'Plunge down'

CutType is, I believe, merely a comment, but it leads me to believe that 
there are probably similar logic errors in the rest of the GeneratePath 
method. In fact, the description states:

"At this time there is a bug if you have a path that does not require a 
spiral... working on it"



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

Re: Absolute imports?

[Peter Otten]

Roy Smith wrote:

> http://docs.python.org/2/whatsnew/2.5.html says:
> 
> "Once absolute imports are the default, import string will always find
> the standard library¹s version."
> 
> Experimentally, it appears that modules in site-packages are also found
> by absolute imports.  I wouldn't consider site-packages to be part of
> the "standard library".  Can somebody give me a more precise description
> of what absolute import does?

Basically, if module foo.bar contains an `import baz` with relative imports 
python will look for foo.baz before searching for baz in sys.path; with 
absolute imports `from . import baz` will only look for baz in the current 
package while `import baz` will only search sys.path.

> It also says, "This absolute-import behaviour will become the default in
> a future version (probably Python 2.7)", but it appears that 2.7.6 is
> still doing relative by default.

$ tree
.
├── baz.py
└── foo
├── bar.py
├── baz.py
└── __init__.py

1 directory, 4 files
$ cat baz.py
print("import is absolute")
$ cat foo/baz.py 
print("import is relative")
$ cat foo/bar.py 
import baz

$ python -c 'import foo.bar'
import is relative
$ python3 -c 'import foo.bar'
import is absolute


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

Re: Explanation of list reference

[Marko Rauhamaa]

Steven D'Aprano :
> On Sat, 15 Feb 2014 14:07:35 +0200, Marko Rauhamaa wrote:
>> Steven D'Aprano :
>>> On Sat, 15 Feb 2014 12:13:54 +0200, Marko Rauhamaa wrote:
5. id(x) == id(y) iff x is y
>>>
>>> # Counter-example
>>> py> x = 23
>>> py> idx = id(x)
>>> py> del x
>>> py> y = 42
>>> py> idy = id(y)
>>> py> idx == idy
>>> True
>> 
>> I don't accept that as a counterexample. 

> Why?

Nowhere do I see the violating "x is y".

> All I need to do is show a case where two distinct objects have the
> same ID.

How do you know objects are "distinct"? Myself, I would use the "is"
test.

>> That's the point. I don't think id() and "is" have any abstract
>> meaning on top of the formal axioms.
>
> Who is talking about "abstract meaning"?

I am. I mean, "implementation-independent".

> Object identity is simple and well-defined in Python. I don't know why
> you are so resistant to this. Read the documentation.

It is not defined at all:

   Every object has an identity, a type and a value. An object’s
   identity never changes once it has been created; you may think of it
   as the object’s address in memory. The ‘is‘ operator compares the
   identity of two objects; the id() function returns an integer
   representing its identity.

Thus "x and y are identical" *means* "x is y" and nothing else.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick Help

[Gary Herron]

On 02/15/2014 07:27 AM, kjaku...@gmail.com wrote:

Just need a bit of help understanding this so I can actually start it.

The input to a program will come from a file called "asdf.in". This file will have all the 
info needed for the course. The formatting of the input file is described as follows, with  
denoting # of white spaces and  denoting n white spaces.

Title:
Title:
etc..

Is it asking me to make an input file with all of that info (like it is above), 
or to have an info file actually filled with all that information filled out? 
Because I then need to have the program be able to output info in certain 
formats that come from that input file.



It makes no sense to ask us to guess what your teacher wants. Please ask 
the teacher.


Once you know what the assignment expects, you may ask us Python 
questions, because we can answer those without guessing.  (But don't ask 
us to write the program for you.)


Gary Herron

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

Re: Explanation of list reference

[Roy Smith]

Steven D'Aprano :
> > Object identity is simple and well-defined in Python. I don't know why
> > you are so resistant to this. Read the documentation.

Marko Rauhamaa :
> It is not defined at all:
> 
>Every object has an identity, a type and a value. An object’s
>identity never changes once it has been created; you may think of it
>as the object’s address in memory. The ‘is‘ operator compares the
>identity of two objects; the id() function returns an integer
>representing its identity.

The "you may think of it as the object's address in memory" part is 
misleading, and should be removed from the docs.  While it's true that 
you may think of it that way, such thinking just leads you to make 
assumptions which are not universally true.

I agree with Marko that this is not a definition.  It's a collection of 
random statements about ids, their use, and some misleading philosophy.  
Even the part about "... compares the identify of two objects" is kind 
of funky, since it implies that you do indeed have two objects!

A definition would be:

"The identity of an object is an integer which never changes during the 
lifetime of the object, and which is guaranteed to be distinct from the 
identities of all other objects with overlapping lifetimes.  A given 
identity may be reused for objects with disjoint lifetimes".

That (I think) says everything is which is guaranteed about identities, 
and nothing more.  Once you've defined what an identity is, then you can 
go on to describe some fun things you can do with it:

"The id() function returns the identity of an object.  The 'is' operator 
compares the identities of its two operands and returns True if they are 
the same."
-- 
https://mail.python.org/mailman/listinfo/python-list

inheriting a large python code base

[Rita]

hi all,

i just inherited a large python code base and I would like to optimize the
code (run faster). The application is a scientific application so I really
don't understand the internal logic.

Here is what I have done so far, profile (cProfile) and was able to see
where the code was taking the longest time.

I was wondering if anyone else experienced something like this and how they
overcame a problem such a this...what techniques have you used to "optimize"
the code.




-- 
--- Get your facts first, then you can distort them as you please.--
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Ian Kelly]

On Sat, Feb 15, 2014 at 9:29 AM, Marko Rauhamaa  wrote:
> Steven D'Aprano :
>> On Sat, 15 Feb 2014 14:07:35 +0200, Marko Rauhamaa wrote:
>>> Steven D'Aprano :
 On Sat, 15 Feb 2014 12:13:54 +0200, Marko Rauhamaa wrote:
>5. id(x) == id(y) iff x is y

 # Counter-example
 py> x = 23
 py> idx = id(x)
 py> del x
 py> y = 42
 py> idy = id(y)
 py> idx == idy
 True
>>>
>>> I don't accept that as a counterexample.
>
>> Why?
>
> Nowhere do I see the violating "x is y".

You formulated your rule as a rule of inference.  The logical
inference from the above is that x is y, which is false even if it
can't be directly tested in Python.

>> All I need to do is show a case where two distinct objects have the
>> same ID.
>
> How do you know objects are "distinct"? Myself, I would use the "is"
> test.

Eliding over details of how one knows that both of the literals above
create objects, if the objects are separately created, then they are
distinct objects.

>>> That's the point. I don't think id() and "is" have any abstract
>>> meaning on top of the formal axioms.
>>
>> Who is talking about "abstract meaning"?
>
> I am. I mean, "implementation-independent".
>
>> Object identity is simple and well-defined in Python. I don't know why
>> you are so resistant to this. Read the documentation.
>
> It is not defined at all:
>
>Every object has an identity, a type and a value. An object's
>identity never changes once it has been created; you may think of it
>as the object's address in memory. The 'is' operator compares the
>identity of two objects; the id() function returns an integer
>representing its identity.
>
> Thus "x and y are identical" *means* "x is y" and nothing else.

This notion of identity sounds useless, and if that is the way you
prefer to understand it then you can safely ignore that it exists.  I
think that most users though inherently understand the concept of
objects being distinct or identical and see the value in being able to
test for this.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: decimal numbers

[Luke Geelen]

If i do set form thing in my script i get 
Invalide syntax pointing at the last word of the form rule
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: decimal numbers

[Ian Kelly]

On Sat, Feb 15, 2014 at 2:18 AM,   wrote:
> hello,
> i have been working on a python resistor calculator to let my class show what 
> you can do with python.
> now i have a script that makes the more speekable value of the resistance 
> (res)
>
> #if len(str(res)) > 9:
> #  res2 = res / 10
> #  print "de weerstand is %s,%s giga ohms" % (res2)
> #elif len(str(res)) > 6:
> #  res2 = res / 100
> #  print "de weerstand is %s,%s Mega ohm" % (res2)
> #elif len(str(res)) > 3:
> #  res2 = res / 1000
> #  print "de weerstand is", res2,"kilo ohm"
> #elif len(str(res)) < 4:
> #  res2 = res
> #  print "de weerstand is", res2,"ohm"
>
> i commented it because it doesn't work (yet), when i have a resistance of
> 9.9 Giga ohms it says it is 9 giga ohms. it seems to work with natural 
> number, anyway of using decimals insted so that it says : the resistance is 
> 9.9 Giga Ohms instead of 9 ?

Others have already explained how to do floating-point rather than
integer division.  I'm curious to know why you're basing the if tests
on the length of the number as a string rather than on the magnitude
of the number.  Consider for example an input of 0.01.  Converted to a
string, that is "0.01" which has a length of 4.  So the output would
be "de weerstand is 0.1 kilo ohm", which is probably not what you
would desire.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: decimal numbers

[Ian Kelly]

On Sat, Feb 15, 2014 at 10:17 AM, Luke Geelen  wrote:
> If i do set form thing in my script i get
> Invalide syntax pointing at the last word of the form rule

Please copy and paste the exact code you ran along with the full text
of the exception into your post.  Paraphrasing it like this doesn't
help us help you.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question on using FP numbers in python 2

[Gene Heskett]

On Saturday 15 February 2014 12:13:42 Steven D'Aprano did opine:

> On Sat, 15 Feb 2014 00:07:49 -0500, Gene Heskett wrote:
> >> Can you extract the float calculations and show us, together with
> >> some sample data, expected result, and actual result?
> > 
> > Not extract, but let you get & look at the code, its the top entry on
> > this page:
> > 
> >  > Code_Generators#Counterbore_Software>
> 
> Here is the direct link to the Python code:
> 
> http://wiki.linuxcnc.org/uploads/counterbore.py
> 
> > Assume no bolt size is clicked on, but a wanted diameter is entered in
> > the lower left pair of boxes, and its to carve .700" deep in the other
> > box. The cutting tool is .250 in diameter, its to do a stepover of 25%
> > of the tool diameter, while carving an additional .015" out of the
> > .850" hole with the tool bit turning 2000 rpm as it spirals down.
> 
> If I've understood the purpose of this program correctly, it generates
> code in some language called "G-code", presumably to control some sort
> of actual physical cutting machine.

More or less standard cNC machine control language.

> So the first thing you ought to do
> is have a G-code expert look at the generated code and tell you it does
> what it is supposed to do.
I think I might qualify for that expert label.  Looking at the output code, 
take the maximum X values it outputs plus and minus, add, then add the tool 
diameter to get the size of the pocket it will cut.  I don't need a 
graphical backplot to check that.

> Or perhaps your cutting machine is buggy.

Not impossible, but that part of the scaling code is 20+ years mature.  It 
knows exactly how many times to step the motor to move the tables 20 feet 
with micron accuracy if there is no mechanical backlash between the motor 
and the table.  Unfortunately there is in my toy mill, which is whats 
driving me to install ball screws in the table drives, which can have 
backlashes well under .0001" if properly made.

> > But the hole it will cut will only be .650" in diameter,  And the
> > backplot, shown in the axis interface, shows no spiral, its doing what
> > it thinks is full diameter in one circular plunge cut.
> 
> Scroll to the GeneratePath method, and read the comments at the top of
> the method. They tell you that the *intention* is:
> 
> * If the tool diameter equals the hole diameter, then just Plunge
>   down to the hole depth.
> 
> * If the tool diameter is less than 80% of the hole diameter,
>   then Plunge to each Level and Spiral out.
> 
> * If the tool diameter is greater than 80% of the hole diameter,
>   then Spiral to each Level and Spiral out.
> 
> But a little later, we see this code:
> 
> # Figure out what kind of entry into the hole
> if (self.ToolDiameter * 1.25 <= self.HoleDiameter):
> self.CutType = 'Spiral Down to Depth of each Pass and Spiral
> Out' else:
> if (self.ToolDiameter < self.HoleDiameter):
> self.CutType = 'Plunge Down to Depth of each Pass and Spiral
> Out'
> else:
> self.CutType = 'Plunge Down to Hole Depth'
> 
> 
> Assuming that the comments are correct, the CutType is wrong. It looks
> like a simple logic error, and should be something like this:
> 
> # Figure out what kind of entry into the hole
> if (self.ToolDiameter * 1.25 <= self.HoleDiameter):
> self.CutType = 'Plunge down and spiral out'
> elif (self.ToolDiameter * 1.25 > self.HoleDiameter):
> self.CutType = 'Spiral down and spiral out'
> else:
> self.CutType = 'Plunge down'
> 
> CutType is, I believe, merely a comment, but it leads me to believe that
> there are probably similar logic errors in the rest of the GeneratePath
> method. In fact, the description states:
> 
> "At this time there is a bug if you have a path that does not require a
> spiral... working on it"

And I just heard back, he is looking at it again.

Thanks Steven.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

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

Re: Explanation of list reference

[Rustom Mody]

On Saturday, February 15, 2014 10:32:39 PM UTC+5:30, Roy Smith wrote:
> Steven D'Aprano :
> > > Object identity is simple and well-defined in Python. I don't know why
> > > you are so resistant to this. Read the documentation.

> Marko Rauhamaa 
> > It is not defined at all:
> >Every object has an identity, a type and a value. An object’s
> >identity never changes once it has been created; you may think of it
> >as the object’s address in memory. The ‘is‘ operator compares the
> >identity of two objects; the id() function returns an integer
> >representing its identity.

> The "you may think of it as the object's address in memory" part is 
> misleading, and should be removed from the docs.  While it's true that 
> you may think of it that way, such thinking just leads you to make 
> assumptions which are not universally true.

> I agree with Marko that this is not a definition.  It's a collection of 
> random statements about ids, their use, and some misleading philosophy.  
> Even the part about "... compares the identify of two objects" is kind 
> of funky, since it implies that you do indeed have two objects!

> A definition would be:

> "The identity of an object is an integer which never changes during the 
> lifetime of the object, and which is guaranteed to be distinct from the 
> identities of all other objects with overlapping lifetimes.  A given 
> identity may be reused for objects with disjoint lifetimes".

> That (I think) says everything is which is guaranteed about identities, 
> and nothing more.  Once you've defined what an identity is, then you can 
> go on to describe some fun things you can do with it:

Thanks! -- Nice to hear slightly more philosophically astute attempt than
the naivete going around: "Object?! We all know whats an object!
Everyone knows whats an object!!"

However I am betting that the problem remains. Youve transfered the identity 
question into the lifetime.

Now define object-lifetime without reference to identity :-)

[Incidentally same applies to Ian's attempt at reducing identity to creation]

Just staying with 'lifetime' and the original meaning from which this word
was analogized. (Allegorized?)

I am supposed to be about 50 years old.
What exactly does that mean?
The cells in my body recycle every few months -- couple of years if we add bones
The molecules that make up those cells are as old as the universe.

What exactly does that 50 refer to?

> "The id() function returns the identity of an object.  The 'is' operator 
> compares the identities of its two operands and returns True if they are 
> the same."

Thats good -- 'is' in terms of 'id' -- better than the obfuscation and
prevarication of the other way round. Only the name id is misleading -- it
should be machine-id or some such.

Consider these examples:

Two graphs are the same if they have the same no of vertices and
there is a mapping f from one vertex set to the other such that
vw is edge in graph1 iff f(v)f(w) is edge in graph2.

For a mathematician such an identity is unexceptionable
The only catch is that implementing such an identity requires
finding the f and that is NP complete.

Even worse...
Two functions f and g are the same (from a math pov)
if ∀ x y . f(x) = g(y)

Now I define
def f(x) : return x+x
def g(x) : return 2*x

If a python (or any such) implementation could 'solve' 
f==g ∀ f,g, it could also 'solve'
f == h
where h is
def h(x) : return h(x) 
which is the halting problem

Moral?
The meaning of identity is very dependent on framing and has
no 'single' 'obvious' 'most natural' answer.
Given that we are (hopefully!) programmers, a machine-oriented framing seems 
appropriate
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: decimal numbers

[Luke Geelen]

Op zaterdag 15 februari 2014 18:23:20 UTC+1 schreef Ian:
> On Sat, Feb 15, 2014 at 10:17 AM, Luke Geelen  wrote:
> 
> > If i do set form thing in my script i get
> 
> > Invalide syntax pointing at the last word of the form rule
> 
> 
> 
> Please copy and paste the exact code you ran along with the full text
> 
> of the exception into your post.  Paraphrasing it like this doesn't
> 
> help us help you.

sorry i made a typo its fixed, thanks a lot
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Rustom Mody]

On Saturday, February 15, 2014 9:59:59 PM UTC+5:30, Marko Rauhamaa wrote:
> Steven D'Aprano:
> > Object identity is simple and well-defined in Python. I don't know why
> > you are so resistant to this. Read the documentation.

> It is not defined at all:

In a certain way thats what I am saying. But you are saying it
stronger than I would... See below

>Every object has an identity, a type and a value. An object's
>identity never changes once it has been created; you may think of it
>as the object's address in memory. The 'is' operator compares the
>identity of two objects; the id() function returns an integer
>representing its identity.

> Thus "x and y are identical" *means* "x is y" and nothing else.

Formally yes.

But in practice, we (where we means experienced programmers and
presumably excludes persons like the OP) understand identity 
'somehow-or-other'

What does that 'somehow-or-other' consist of?

I would argue that we do that comprehending-act by translating to
a kind of C.  Maybe an informal, pidgin C but close enough that we get
(something of) the semantics.

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

Re: inheriting a large python code base

[Mark Lawrence]

On 15/02/2014 17:10, Rita wrote:

hi all,

i just inherited a large python code base and I would like to optimize
the code (run faster). The application is a scientific application so I
really don't understand the internal logic.

Here is what I have done so far, profile (cProfile) and was able to see
where the code was taking the longest time.

I was wondering if anyone else experienced something like this and how
they overcame a problem such a this…what techniques have you used to
"optimize" the code.



https://wiki.python.org/moin/PythonSpeed/PerformanceTips

--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: inheriting a large python code base

[Ray Cote]

Hi Rita:

Some personal thoughts on how I've approached similar situations:


Step 0: Put all that code under version control immediately. 
Being able to track and back-out changes is extremely useful -- even in a 
small, single-coder app. 
With something this big, you'll find "things suddenly stopped working" as you 
make changes, and
being able to back-track your changes is invaluatable. 


Step 2: Ask, "Why do you want to optimize the code (run faster)?"
  - what is slow?
- starting?
- loading data?
- solving specific problem?
- running specific functionality?
- specific calculations?
- network access?
- database access?
- small data sets?
- large data sets?
  - who says it is slow? 
and what is their definition of sufficiently quick?


3: You state you do not understand the internal logic. 
I've also inherited applications where the internal logic was unclear. 
Writing unit and functional tests (if they do not exist) will help to ensure 
you do not change the behavior of the application. 

You may find that understanding the internal logic is the best way to speed-up 
the application. 
You'll likely find that the biggest speed improvements come from optimizing the 
logic -- not the Python.


4: This is a personal prefernce when inheriting large code chunks -- and I'm 
sure some will counter it is not optimum. 
Go through the code and run pep8 and pyflakes (or flake8) on all the code and 
address the issues that come up. 
Aside from bringing the code into styling conformance, I find that this helps 
me to familiarize myself with the code. 
As you're making style changes, review individual functions and add 
documentation if it is missing. 
If you're not clear what a function does, mark it as such so you know to look 
at it carefully in the future. 


5: Now you have a clean set of code -- most of which you've at least visually 
scanned -- and you're 
ready to create some timing tests and dig into specifics.

--Ray


- Original Message -
From: "Rita" 
To: python-list@python.org
Sent: Saturday, February 15, 2014 12:10:33 PM
Subject: inheriting a large python code base



hi all, 


i just inherited a large python code base and I would like to optimize the code 
(run faster). The application is a scientific application so I really don't 
understand the internal logic. 


Here is what I have done so far, profile (cProfile) and was able to see where 
the code was taking the longest time. 



I was wondering if anyone else experienced something like this and how they 
overcame a problem such a this…what techniques have you used to "optimize" the 
code. 






-- 
--- Get your facts first, then you can distort them as you please. -- 
-- 
https://mail.python.org/mailman/listinfo/python-list

-- 
Ray Cote, President
Appropriate Solutions, Inc.
We Build Software
603.924.6079
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problem importing libraries installed with PIP in Eclipse

[Fabio Zadrozny]

On Fri, Feb 14, 2014 at 1:30 AM, Renato  wrote:

> Hi guys, I'm using Python 2.7.5 64 bits and I have a problem when
> importing libraries that were installed via PIP when importing them inside
> Eclipse (version 4.3.1). Outside Eclipse (directly in Python's shell)
> everything works fine, here is an example:
>
> >>> import numpy # installed from repositories
> >>> from numpy import array
> >>> import pybrain   # installed via PIP
> >>> from pybrain import Network
> >>>
>
> Everything works outside Eclipse. But inside Eclipse I can't import
> libraries installed via PIP using "from x import y" format, it will give an
> error. The only way I can import libraries installed via PIP is using
> "import x" format. Here is an example:
>
> import numpy # no errors (installed
> from repositories)
> from numpy import array  # no errors
> import pybrain   # no errors (installed
> via PIP)
> from pybrain import Network  # gives the error below
>
> Traceback (most recent call last):
>   File "/media/arquivos/pybrain_import_test.py", line 4, in 
> from pybrain import Network
> ImportError: cannot import name Network
>
> I suspected it could be related to virtualenv, but here is a print screen (
> http://imageshack.com/a/img534/4307/3x0m.png) of my Python's PATH. The
> directory /usr/lib/python2.7/site-packages where PyBrain is installed is
> already in Python's PATH inside Eclipse. Could someone help me, please?
> --
> https://mail.python.org/mailman/listinfo/python-list
>

Hi Renato,

Can you do the following:

Create a new script with:

import sys
print '\n'.join(sorted(sys.path))

And let me know if the paths you have listed in both are equal... Also,
which version of PyDev are you using?

Cheers,

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

Re: Explanation of list reference

[Ian Kelly]

On Sat, Feb 15, 2014 at 10:30 AM, Rustom Mody  wrote:
> Thanks! -- Nice to hear slightly more philosophically astute attempt than
> the naivete going around: "Object?! We all know whats an object!
> Everyone knows whats an object!!"
>
> However I am betting that the problem remains. Youve transfered the identity
> question into the lifetime.
>
> Now define object-lifetime without reference to identity :-)

Fundamentally that's what definitions do.  They transfer the question
of "what is X" to "okay, so what is this thing that defines X".  All
definitions must ultimately be circular, simply because we have only
finitely many words and concepts to work with.

>> "The id() function returns the identity of an object.  The 'is' operator
>> compares the identities of its two operands and returns True if they are
>> the same."
>
> Thats good -- 'is' in terms of 'id' -- better than the obfuscation and
> prevarication of the other way round. Only the name id is misleading -- it
> should be machine-id or some such.
>
> Consider these examples:
>
> Two graphs are the same if they have the same no of vertices and
> there is a mapping f from one vertex set to the other such that
> vw is edge in graph1 iff f(v)f(w) is edge in graph2.
>
> For a mathematician such an identity is unexceptionable

Is it though?  If we were to play the same game with it, I could point
out that you haven't defined graph.  So I'll retrieve a definition
from Wikipedia:

"""
a graph is an ordered pair G = (V, E) comprising a set V of vertices
or nodes together with a set E of edges or lines, which are 2-element
subsets of V
"""

Well, that's great, but it just transfers the definition of graph into
the definition of an ordered pair.  Ordered pairs can be defined in
terms of sets:

"""
In 1921 Kazimierz Kuratowski offered the now-accepted definition of
the ordered pair (a, b):

(a, b) := {{a}, {a, b}}
"""

But what is a set?  Cantor offers this definition:

"""
A set is a gathering together into a whole of definite, distinct
objects of our perception [Anschauung] or of our thought - which are
called elements of the set.
"""

But what precisely are "objects" and how are we to determine their
distinctness?  Cantor above relates them to perception or thought, but
surely my own perception and thought differ from Cantor's.  If
mathematics or philosophy offer us any absolute answer to this
question, I'm unable to find it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Ian Kelly]

On Sat, Feb 15, 2014 at 11:37 AM, Ian Kelly  wrote:
> But what is a set?  Cantor offers this definition:
>
> """
> A set is a gathering together into a whole of definite, distinct
> objects of our perception [Anschauung] or of our thought - which are
> called elements of the set.
> """
>
> But what precisely are "objects" and how are we to determine their
> distinctness?  Cantor above relates them to perception or thought, but
> surely my own perception and thought differ from Cantor's.  If
> mathematics or philosophy offer us any absolute answer to this
> question, I'm unable to find it.

I sent the last message a little too early.  To continue: the above
definition of set is an informal one.  In axiomatic set theory, it
turns out that "set" is simply taken as an undefined primitive.  In
other words: "Set?! We all know what's a set!
Everyone knows what's a set!!"

At some level we have to have primitives, and while we can at some
level delve into the machine in order to define an object in terms of
memory location and layout and lifetime and even physical
considerations such as "which memory?"; at the level of the Python
abstraction I suggest that an object is simply an undefined primitive.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: decimal numbers

[Luke Geelen]

Op zaterdag 15 februari 2014 18:42:51 UTC+1 schreef Luke Geelen:
> Op zaterdag 15 februari 2014 18:23:20 UTC+1 schreef Ian:
> 
> > On Sat, Feb 15, 2014 at 10:17 AM, Luke Geelen  wrote:
> 
> > 
> 
> > > If i do set form thing in my script i get
> 
> > 
> 
> > > Invalide syntax pointing at the last word of the form rule
> 
> > 
> 
> > 
> 
> > 
> 
> > Please copy and paste the exact code you ran along with the full text
> 
> > 
> 
> > of the exception into your post.  Paraphrasing it like this doesn't
> 
> > 
> 
> > help us help you.
> 
> 
> 
> sorry i made a typo its fixed, thanks a lot

hey, is it possible to remove the .0 if it is a valua without something behind 
the poit (like 5.0 gets 5 but 9.9 stays 9.9
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Grant Edwards]

On 2014-02-15, Chris Angelico  wrote:
> On Sat, Feb 15, 2014 at 4:20 PM, Ian Kelly  wrote:
>> On Fri, Feb 14, 2014 at 9:24 PM, Rustom Mody  wrote:
>>> To start with we say two objects are identical if they have the same
>>> memory address.
>>
>> This is false.  It happens to hold for CPython, but that's an
>> implementation detail.  The definition of object identity does not
>> depend on memory address.  It also doesn't have anything to do with
>> space-time coordinates.  The concept of object identity is an
>> abstraction, not an analogy from physics.
>
> With the restrictions of computer memory, I suspect that two objects
> with the same address must be identical,

That's true if they have the same address _at_the_exact_same_time_.

[AND IF the two chunks of code evaluating the addresses of the objects
share a machine-level address space -- which I doubt is actually
required by the Python language definition. It would be difficult
(but not impossible) to implement a Python where that wasn't true.]

However, it's possible for object 1 to have address XYZ at one point
in time and object 2 to have address XYZ at a different point in time
even though object 1 and object 2 are different objects.

The tricky bit is that those two points in time may occur at adjacent
"lines" when your program is executing.  They may even occur at two
different points within the same line of code.  IOW, there's just no
reason to assume that:

 address_of(object1) == address_of(ojbect2)

is equivalent to 

 object1 is object2

Garbage collection could kick in after the evaluation of
address_of(object1) and before the evaluation of address_of(object2)
with the result that the two objects would appear to have the same
address in memory.

So, unless you're working on the guts of a Python implementation
you've got to just plain stop thinking about memory addresses.
Period.
 
-- 
Grant

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

Re: decimal numbers

[Mark Lawrence]

On 15/02/2014 18:57, Luke Geelen wrote:

Op zaterdag 15 februari 2014 18:42:51 UTC+1 schreef Luke Geelen:

Op zaterdag 15 februari 2014 18:23:20 UTC+1 schreef Ian:


On Sat, Feb 15, 2014 at 10:17 AM, Luke Geelen  wrote:







If i do set form thing in my script i get







Invalide syntax pointing at the last word of the form rule















Please copy and paste the exact code you ran along with the full text







of the exception into your post.  Paraphrasing it like this doesn't







help us help you.




sorry i made a typo its fixed, thanks a lot


hey, is it possible to remove the .0 if it is a valua without something behind 
the poit (like 5.0 gets 5 but 9.9 stays 9.9



Thanks for yet more double line spacing and single line paragraphs.  Is 
it too much to ask for you to follow the instructions that you've 
already been given or better yet to use a decent tool?


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: Explanation of list reference

[Steven D'Aprano]

On Sat, 15 Feb 2014 12:02:39 -0500, Roy Smith wrote:

> Steven D'Aprano :
>> > Object identity is simple and well-defined in Python. I don't know
>> > why you are so resistant to this. Read the documentation.
> 
> Marko Rauhamaa :
>> It is not defined at all:
>> 
>>Every object has an identity, a type and a value. An object’s
>>identity never changes once it has been created; you may think of it
>>as the object’s address in memory. The ‘is‘ operator compares the
>>identity of two objects; the id() function returns an integer
>>representing its identity.
> 
> The "you may think of it as the object's address in memory" part is
> misleading, and should be removed from the docs.  While it's true that
> you may think of it that way, such thinking just leads you to make
> assumptions which are not universally true.
> 
> I agree with Marko that this is not a definition.  It's a collection of
> random statements about ids, their use, and some misleading philosophy.
> Even the part about "... compares the identify of two objects" is kind
> of funky, since it implies that you do indeed have two objects!

Correct, it should say "two operands" to be pedantic.

But in regular English, it is quite normal to say things like "the two 
people actually turned out to be same person" (say, Superman and Clark 
Kent) and I see no reason not to allow the similar, technically sloppy 
but easily understandable idea that the `is` operator tests whether two 
objects are in fact the same object.

This concept isn't really that hard to understand. In the expression `a 
is b`, you have an object bound to the name "a", an object bound to the 
name "b", hence *two objects*, and you want to know if they are the same 
object or not.


> A definition would be:
> 
> "The identity of an object is an integer which never changes during the
> lifetime of the object, and which is guaranteed to be distinct from the
> identities of all other objects with overlapping lifetimes.  A given
> identity may be reused for objects with disjoint lifetimes".

You then go on to say:

> "The id() function returns the identity of an object. ..."


This definition is wrong. An object's identity and its ID are not the 
same. Objects in Python have an identity the instant they are created, 
but they may not have an ID assigned to them until much later, if at all. 
Both IronPython and Jython lazily assign IDs on request, not on creation. 
Here's an example from Jython:

>>> x = "first"
>>> y = "second"
>>> id(y)  # created second, but ID assigned first
1
>>> id(x)  # created first, but ID assigned second
2


IronPython is similar, although the specific IDs may not be the same.


The problem here is that you are wrongly identifying an object's identity 
with its identification number. That doesn't apply to people (if you are 
American, your identity is not the same as your Social Security number); 
it doesn't apply to rocks, or pencils, or kitchen spoons. Why should it 
apply to Python objects? The identity of an object is an inherent, 
fundamental aspect of the object's existence, not some label stuck to it.

In Jython, the `is` operator can distinguish objects without assigning 
them an ID number:

>>> a = 23
>>> b = 23
>>> a is b  # compare two ID-less objects for identity
False
>>> id("fe")
4
>>> id("fi")
5
>>> id(a)  # finally assign a an ID
6
>>> id("fo")
7
>>> id(b)  # and the same for b
8


In plain English, "identity" has various definitions, but the one needed 
here is this:

The state or quality of being identical, or the same; sameness.
[Webster 1913]

where "identical" is understood in the strong sense of:

being the exact same one; not any other
[Wordnet 2006]


rather than the weak sense of merely looking the same, as in "identical 
houses". These are common, ordinary words, and no more need specialist 
definitions in the Python documentation than do the other common, 
ordinary words used, such as "never", "changes" or "created".

An object's identity is that quality which distinguishes it from every 
other object. The nature of that quality is not important. Not 
withstanding such interesting but irrelevant philosophical questions as 
the Paradox Of My Grandfather's Axe, the intuitive, common, plain-English 
meaning of identity is all we need to understand object identity, because 
it's the same meaning.



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

Re: Explanation of list reference

[Steven D'Aprano]

On Sat, 15 Feb 2014 18:29:59 +0200, Marko Rauhamaa wrote:

> Steven D'Aprano :
>> On Sat, 15 Feb 2014 14:07:35 +0200, Marko Rauhamaa wrote:
>>> Steven D'Aprano :
 On Sat, 15 Feb 2014 12:13:54 +0200, Marko Rauhamaa wrote:
>5. id(x) == id(y) iff x is y

 # Counter-example
 py> x = 23
 py> idx = id(x)
 py> del x
 py> y = 42
 py> idy = id(y)
 py> idx == idy
 True
>>> 
>>> I don't accept that as a counterexample.
> 
>> Why?
> 
> Nowhere do I see the violating "x is y".

Do you truly think that there is even the tiniest, most microscopic 
chance that the int 23 which has been garbage-collected and no longer 
exists, and the int 42, are the same object?



>> All I need to do is show a case where two distinct objects have the
>> same ID.
> 
> How do you know objects are "distinct"? Myself, I would use the "is"
> test.

I know objects are distinct if they are objects with different values, 
such as 23 and 42, due to the fundamental fact that ints cannot 
have the value 23 and 42 at the same time. I leverage my 
knowledge that ints are intended to model the mathematical integers, and 
while that model is not perfect, it is not so bad as to have 23 and 
42 be the same number.

I also know that objects are distinct if one of them has been garbage 
collected, on the account of it no longer existing.


>>> That's the point. I don't think id() and "is" have any abstract
>>> meaning on top of the formal axioms.
>>
>> Who is talking about "abstract meaning"?
> 
> I am. I mean, "implementation-independent".

"Abstract meaning" does not mean "implementation independent". The 
definition of identity given in the documentation is both implementation 
independent and concrete: identity is tied concretely to the creation of 
the object, while still leaving implementations free to choose exactly 
how they tie identity to creation.


>> Object identity is simple and well-defined in Python. I don't know why
>> you are so resistant to this. Read the documentation.
> 
> It is not defined at all:
> 
>Every object has an identity, a type and a value. An object’s
>identity never changes once it has been created; you may think of it
>as the object’s address in memory. The ‘is‘ operator compares the
>identity of two objects; the id() function returns an integer
>representing its identity.
> 
> Thus "x and y are identical" *means* "x is y" and nothing else.

You are correct, "x and y are identical" does mean that "x is y". That is 
exactly the point.

However, the `is` operator is not necessarily the same as the English 
word "is". Is some languages, the `is` operator is a synonym for the 
equals operator. That is not the case in Python. In Python, the 
*expression* `x is y` has the same meaning as the English sentence "x is 
y" in the strong sense of testing identity, rather than the weak sense of 
merely testing similarities (or metaphor). So the Python docs don't 
merely give a circular definition, they distinguish between two different 
and competing possibilities:

(1) The `is` operator means the same as the == operator. (NO)

(2) The `is` operator tests for object identity. (YES)


Please also see my response to Roy Smith's message.

Every object has a unique (during the lifetime of the object) identity. 
The specific nature of that identity is implementation-dependent, and 
strictly irrelevant. The `is` operator tests whether the two operands are 
the same object, that is, whether they have the same identity. That's all 
it does.



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

Re: decimal numbers

[Steven D'Aprano]

On Sat, 15 Feb 2014 10:57:20 -0800, Luke Geelen wrote:

> hey, is it possible to remove the .0 if it is a valua without something
> behind the poit (like 5.0 gets 5 but 9.9 stays 9.9

Yes, but not easily. First, check the number's fractional part, and if it 
is zero, convert it to an int:

# Here, your value is x
if x % 1 == 0:
# Exact whole number.
x = int(x)


But be warned that really big floats are always ints, even if they have a 
decimal point in them! For example:

x = 1.1e20

has a decimal point, but its value is:

11000.0

which is a whole number. So perhaps a better way to do this is to operate 
on the number as a string, not as a numeric value:

s = "%s" % x
if s.endswith(".0"):
s = s[:-2]


If there is anything you don't understand about this code snippet, please 
feel free to ask.

By the way, I see that you are using GoogleGroups to post. GoogleGroups 
has an extremely obnoxious and annoying habit of throwing in blank lines 
between every line of your reply. Could you please read and follow the 
instructions here:

https://wiki.python.org/moin/GoogleGroupsPython


otherwise you are likely to annoy people and may find we stop answering 
your questions. We are volunteers, and aren't being paid to answer your 
questions. If you make it difficult for us, we may just stop.

Thank you in advance.

Any questions, please don't hesitate to ask.



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

Re: Explanation of list reference

[Marko Rauhamaa]

Ian Kelly :

> On Sat, Feb 15, 2014 at 9:29 AM, Marko Rauhamaa  wrote:
>> Thus "x and y are identical" *means* "x is y" and nothing else.
>
> This notion of identity sounds useless, and if that is the way you
> prefer to understand it then you can safely ignore that it exists. I
> think that most users though inherently understand the concept of
> objects being distinct or identical and see the value in being able to
> test for this.

It is not useless to identify your fundamental definitions and axioms
instead of resorting to circular reasoning.

The original question was how a beginning programmer could "get" lists.
We very quickly descended into the murky waters of "objects" of an
underlying machine and CPython's way of implementing things. I was
wondering if there was a way to "get" integers, lists, references etc
without hauling the poor student under the keel.

In a word, could Python be your first programming language?


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Terry Reedy]

On 2/15/2014 1:07 AM, Rustom Mody wrote:

On Saturday, February 15, 2014 10:50:35 AM UTC+5:30, Ian wrote:

On Fri, Feb 14, 2014 at 9:24 PM, Rustom Mody  wrote:

In the case of physical objects like dice there is a fairly
unquestionable framing that makes identity straightforward --
4-dimensional space-time coordiantes. If the space-time coordinates of
2 objects are all equal then the objects are identical, else not.
Now we analogize the space-time identity of physical objects to
computer identity of computer objects (so-called) and all sorts of
problems ensue.
To start with we say two objects are identical if they have the same
memory address.



This is false.  It happens to hold for CPython, but that's an
implementation detail.  The definition of object identity does not
depend on memory address.  It also doesn't have anything to do with
space-time coordinates.  The concept of object identity is an
abstraction, not an analogy from physics.



The language reference states, "Every object has an identity, a type
and a value. An object's identity never changes once it has been
created; you may think of it as the object's address in memory."
Okay, so that quote does bring up memory address, but in my
interpretation that's just an analogy to introduce the concept.  The
more important part of that sentence is the first part, which ties an
object's identity to its creation.  If two objects share the same
creation, then they're the same object.


Whats the notion of object identity is the question.
Ok so you reject the memory addr as an 'implementation detail'
Then you are obliged to provide some other way of understanding object-identity


'Identity' is an abstraction. For immutable objects, it is essentially 
irrelevant. For mutable objects, it is essential in the following sense. 
 A and B are the same object if mutating A necessarily mutates B and 
different if they can be independently mutated.


The id() of an object is a fixed integer that is temporally unique. An 
implementation might use the id to access objects. When one executes 
Python mentally, one might skip implementing id(). Its main use is to 
test an implementation. Most beginners should ignore it.


--
Terry Jan Reedy

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

Re: Explanation of list reference

[Joshua Landau]

On 15 February 2014 14:20, Ben Finney  wrote:
> Joshua Landau  writes:
>
>> Here, I give you a pdf. Hopefully this isn't anti
>> mailing-list-etiquette.
>
> This forum is read in many different contexts, and attachments aren't
> appropriate. You should simply put the text directly into your message,
> if it's short enough.
>
> If it's long, then put it online somewhere and send a link with a
> description; or, better, make it shorter so it is reasonable to put the
> text in a message :-)

A PDF seemed like a better use of my time than ASCII art.
Nevertheless, I agree that I can always give a link; I was just
wondering if there was an environment under which this was actively
harmful.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Marko Rauhamaa]

Steven D'Aprano :

> On Sat, 15 Feb 2014 18:29:59 +0200, Marko Rauhamaa wrote:
>> Nowhere do I see the violating "x is y".
>
> Do you truly think that there is even the tiniest, most microscopic
> chance that the int 23 which has been garbage-collected and no
> longer exists, and the int 42, are the same object?

What were we talking about again?


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Emacs python-mode.el bug #1207470

[Frank Stutzman]

This has been resolved and I want to publically thank Andreas for finding 
and fixing this bug so quick.  I'm fairly new to open source development and
the rapidity that this was fix was gratifying.


-- 
Frank Stutzman

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

Re: Explanation of list reference

[Ian Kelly]

On Sat, Feb 15, 2014 at 1:20 PM, Marko Rauhamaa  wrote:
> Ian Kelly :
>
>> On Sat, Feb 15, 2014 at 9:29 AM, Marko Rauhamaa  wrote:
>>> Thus "x and y are identical" *means* "x is y" and nothing else.
>>
>> This notion of identity sounds useless, and if that is the way you
>> prefer to understand it then you can safely ignore that it exists. I
>> think that most users though inherently understand the concept of
>> objects being distinct or identical and see the value in being able to
>> test for this.
>
> It is not useless to identify your fundamental definitions and axioms
> instead of resorting to circular reasoning.
>
> The original question was how a beginning programmer could "get" lists.
> We very quickly descended into the murky waters of "objects" of an
> underlying machine and CPython's way of implementing things. I was
> wondering if there was a way to "get" integers, lists, references etc
> without hauling the poor student under the keel.
>
> In a word, could Python be your first programming language?

Absolutely, many people learn Python as their first language.  Even
MIT famously uses it for their introductory computer science class.
And I think that most of them do it without getting into internal
details like memory addresses and the heap.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: decimal numbers

[Ian Kelly]

On Sat, Feb 15, 2014 at 11:57 AM, Luke Geelen  wrote:
> hey, is it possible to remove the .0 if it is a valua without something 
> behind the poit (like 5.0 gets 5 but 9.9 stays 9.9

The ':g' format specifier will trim off trailing zeroes, e.g.:

>>> '{:g}'.format(5.0)
'5'

It also switches to exponential notation if the scale of the number is
greater than the specified precision (default 6):

>>> '{:g}'.format(500.0)
'5e+06'

You can read up on string formatting for more details:
http://docs.python.org/3/library/string.html#formatstrings
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to turn a package into something pip can install

[Roy Smith]

In article ,
 Chris “Kwpolska” Warrick  wrote:

> On Sat, Feb 15, 2014 at 3:26 AM, Roy Smith  wrote:
> > In article ,
> >  Ryan Gonzalez  wrote:
> >
> >> python setup.py sdist
> >
> > OK, I run that and I get a metar-1.4.0.tar.gz under dist.  If I move
> > that tarfile to my packages directory, and run pip, I get:
> >
> > $ pip install --no-index --quiet --find-links packages metar==1.4.0
> [snip]
> > ValueError: unknown url type: packages
> 
> The path to your cache directory is incorrect.  I suggest using
> absolute paths (eg. /home/user/packages) instead of relative paths,
> which is likely what caused this issue.

No, that's not it.  It doesn't work with an absolute path either.

-
$ pip install -v --no-index --find-links 
/home/roy/deploy/current/code/deploy/python/packages metar==1.4.0
Ignoring indexes: http://pypi.python.org/simple/
Downloading/unpacking metar==1.4.0
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner
self.run()
  File "/usr/lib/python2.7/threading.py", line 504, in run
self.__target(*self.__args, **self.__kwargs)
  File 
"/home/roy/deploy/current/python/local/lib/python2.7/site-packages/pip-1.1-py2.7.egg/pip/index.py",
 line 245, in _get_queued_page
page = self._get_page(location, req)
  File 
"/home/roy/deploy/current/python/local/lib/python2.7/site-packages/pip-1.1-py2.7.egg/pip/index.py",
 line 335, in _get_page
return HTMLPage.get_page(link, req, cache=self.cache)
  File 
"/home/roy/deploy/current/python/local/lib/python2.7/site-packages/pip-1.1-py2.7.egg/pip/index.py",
 line 452, in get_page
resp = urlopen(url)
  File 
"/home/roy/deploy/current/python/local/lib/python2.7/site-packages/pip-1.1-py2.7.egg/pip/download.py",
 line 85, in __call__
response = urllib2.urlopen(self.get_request(url))
  File "/usr/lib/python2.7/urllib2.py", line 126, in urlopen
return _opener.open(url, data, timeout)
  File "/usr/lib/python2.7/urllib2.py", line 392, in open
protocol = req.get_type()
  File "/usr/lib/python2.7/urllib2.py", line 254, in get_type
raise ValueError, "unknown url type: %s" % self.__original
ValueError: unknown url type: 
/home/roy/deploy/current/code/deploy/python/packages

  Could not find any downloads that satisfy the requirement metar==1.4.0
No distributions at all found for metar==1.4.0
Exception information:
Traceback (most recent call last):
  File 
"/home/roy/deploy/current/python/local/lib/python2.7/site-packages/pip-1.1-py2.7.egg/pip/basecommand.py",
 line 104, in main
status = self.run(options, args)
  File 
"/home/roy/deploy/current/python/local/lib/python2.7/site-packages/pip-1.1-py2.7.egg/pip/commands/install.py",
 line 245, in run
requirement_set.prepare_files(finder, force_root_egg_info=self.bundle, 
bundle=self.bundle)
  File 
"/home/roy/deploy/current/python/local/lib/python2.7/site-packages/pip-1.1-py2.7.egg/pip/req.py",
 line 978, in prepare_files
url = finder.find_requirement(req_to_install, upgrade=self.upgrade)
  File 
"/home/roy/deploy/current/python/local/lib/python2.7/site-packages/pip-1.1-py2.7.egg/pip/index.py",
 line 157, in find_requirement
raise DistributionNotFound('No distributions at all found for %s' % req)
DistributionNotFound: No distributions at all found for metar==1.4.0

Storing complete log in /home/roy/.pip/pip.log
-



The tar file is there:

$ ls -l /home/roy/deploy/current/code/deploy/python/packages/metar-1.4.0.tar.gz 
-rw-rw-r-- 1 roy roy 28542 Feb 15 16:55 
/home/roy/deploy/current/code/deploy/python/packages/metar-1.4.0.tar.gz
-- 
https://mail.python.org/mailman/listinfo/python-list

passing an option to the python interpreter

[Jabba Laci]

Hi,

The first line in my scripts looks like this:

#!/usr/bin/env python

I would like to use unbuffered output in a script, which can be done
with the -u option, thus I tried this:

#!/usr/bin/env python -u

But if I want to run it from the command line ($ ./unbuffered.py), I
get this error:

/usr/bin/env: python -u: No such file or directory

env is looking for "python -u" but such a command doesn't exist.

How to overcome this problem? I could write

#!/usr/bin/python -u

but I prefer to call python through env. For instance if I put this
last one in a virtualenv, that would call the system-wide interpreter
not the one in the virtualenv.

Thanks,

Laszlo
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to turn a package into something pip can install

[Roy Smith]

In article ,
 Roy Smith  wrote:

> > > $ pip install --no-index --quiet --find-links packages metar==1.4.0
> > [snip]
> > > ValueError: unknown url type: packages
> > 
> > The path to your cache directory is incorrect.  I suggest using
> > absolute paths (eg. /home/user/packages) instead of relative paths,
> > which is likely what caused this issue.
> 
> No, that's not it.  It doesn't work with an absolute path either.

OK, I figured this out.  The on-line docs 
(http://www.pip-installer.org/en/latest/reference/pip_wheel.html) say 
you can give --find-links a path, but it looks like it insists on it 
being a valid URL.  If I prepend "file:" to the absolute path, it works.

Maybe this is something which has changed in newer versions of pip?  
I've got 1.1 (and python 2.7.3).  I'm pretty sure both of these are what 
came with Ubuntu Precise.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: passing an option to the python interpreter

[Marko Rauhamaa]

Jabba Laci :

> I tried this:
>
> #!/usr/bin/env python -u

The hash-bang notation is quite rigid; it only accepts a single argument
("python") to the command ("/usr/bin/env").

I don't know if there is a simple workaround.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: passing an option to the python interpreter

[Chris Angelico]

On Sun, Feb 16, 2014 at 9:32 AM, Jabba Laci  wrote:
> #!/usr/bin/env python -u
>
> But if I want to run it from the command line ($ ./unbuffered.py), I
> get this error:
>
> /usr/bin/env: python -u: No such file or directory
>
> env is looking for "python -u" but such a command doesn't exist.
>
> How to overcome this problem? I could write
>
> #!/usr/bin/python -u

That's a fundamental limitation with the shebang syntax: you can pass
exactly one argument. Passing more than one is platform-dependent -
some Unixes will pass multiple args, some will pass the whole string
as a single arg (which is what you're seeing here), and I think some
will discard everything from the space onward.

What you could do is add a wrapper called 'pythonu'.which invokes 'env
python -u %*'. Be aware, though, that shebanging to a shell script
isn't safe either; modern Linuxes support it, but to be truly
cross-platform, you'd have to write pythonu in a compiled language and
make a binary.

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

Re: Explanation of list reference

[Chris Angelico]

On Sun, Feb 16, 2014 at 7:44 AM, Joshua Landau  wrote:
> On 15 February 2014 14:20, Ben Finney  wrote:
>> Joshua Landau  writes:
>>
>>> Here, I give you a pdf. Hopefully this isn't anti
>>> mailing-list-etiquette.
>>
>> This forum is read in many different contexts, and attachments aren't
>> appropriate. You should simply put the text directly into your message,
>> if it's short enough.
>>
>> If it's long, then put it online somewhere and send a link with a
>> description; or, better, make it shorter so it is reasonable to put the
>> text in a message :-)
>
> A PDF seemed like a better use of my time than ASCII art.
> Nevertheless, I agree that I can always give a link; I was just
> wondering if there was an environment under which this was actively
> harmful.

A PDF is fine. An attachment is problematic, and won't get to
everyone. Hence the suggestion to put it online somewhere and post a
link. (But be sure the host will be up for the next hundred years,
ish.)

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

Re: inheriting a large python code base

[Cameron Simpson]

On 15Feb2014 12:10, Rita  wrote:
> i just inherited a large python code base and I would like to optimize the
> code (run faster). The application is a scientific application so I really
> don't understand the internal logic.
[...]

One thing I would keep in mind is that scientific applications
generally involve floating point math. That is subject to loss of
precision if done the wrong way.

If you are fiddling with a numeric algorithm (as opposed to plain
old data structure manipulations) I would want to be sure the code
you're changing is not done that way for a specific reason. Make
unit tests to check for correctness if possible. Make regression
tests to compare the results of your modified code against the
results from the original code on the same data.

Cheers,
-- 
Cameron Simpson 

Plague, Famine, Pestilence, and C++ stalk the land. We're doomed! Doomed!
- Simon E Spero
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [RELEASED] Python 3.3.4

[Ned Deily]

In article 
,
 Makoto Kuwata  wrote:
> By the way, I can't find Python-3.3.4.tar.bz2 in:
> http://www.python.org/ftp/python/3.3.4/
> 
> Python-3.3.{1,2,3}.tar.bz2 and Python-3.4.0.tar.bz2 are provided,
> but Python-3.3.4.tar.bz2 is not. Why?
> # I hope that Python-3.3.4.tar.bz2 is also provided.

The release managers decided that having three different source release 
formats was not necessary so, as of recent Python releases, the bz2 
format is no longer provided.  The newer xz compression format provides 
generally smaller files than bz2 and the gz format is provided because 
of its wide support.  (BTW, Python 3.4.0 is not released yet; some early 
alphas of 3.4.0 still provided .bz2 tarballs but the most recent ones, 
including the current rc1, do not.)

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

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

Re: Quick Help

[Cameron Simpson]

On 15Feb2014 07:27, kjaku...@gmail.com  wrote:
> Just need a bit of help understanding this so I can actually start it. 
> 
> The input to a program will come from a file called "asdf.in". This file will 
> have all the info needed for the course. The formatting of the input file is 
> described as follows, with  denoting # of white spaces and  
> denoting n white spaces.
> 
> Title:
> Title:
> etc..
> 
> Is it asking me to make an input file with all of that info (like it is 
> above), or to have an info file actually filled with all that information 
> filled out? Because I then need to have the program be able to output info in 
> certain formats that come from that input file.

I would read this as saying that the your program must understand
an input file of the format described above.

If your teacher has not given you some example file, you will need
to hand-make some files to use as input files to test your program.

BTW, your subject: line is not very good. All questions want "help".
Don't change the subject line for this discussion, but in future,
try to make it more descriptive. For example:
"what does this task specification mean?" Maybe.

Cheers,
-- 
Cameron Simpson 

Copies of ACM publications are filling library self space so rapidly that
shelf boundaries will soon be expanding faster that the speed of light.
But Special Relativity is not violated, as no information is being propagated.
- Howard E. Motteler, 
-- 
https://mail.python.org/mailman/listinfo/python-list