Re: Pythonwin forum?

[Tim Golden]

On 14/02/2014 03:17, John Doe wrote:
> What's the best place for asking questions about the Pythonwin 
> IDE? 
> 
> I'm a novice programmer, so in an effort to be more clear I'm
> talking about the program at this path on my hard drive... 
> 
> C:\Python27\Lib\site-packages\pythonwin\Pythonwin.exe 
> 
> It appears to be an editor and a compiler. I have some questions 
> about the color scheme. I'd like light/white text on a black 
> background. I realize you can manually change the colors, but I'd 
> like to find out if anyone has a good starting point. I don't see 
> any obvious places on the Internet to ask. 

The pywin32 packages (which includes the Pythonwin editor) do have
their own sourceforge project with trackers etc.:

  http://sourceforge.net/projects/pywin32/

But I suggest that you'd do better to join the python-win32 mailing list:


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

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

Python version problem for rpm

[anju tiwari]

Hi all,

I have two version of python 2.4 and 2.7.

By default python version is 2.4 . I want to install need to install some
rpm
which needs python 2.7 interpreter. how can I enable 2.7 interpreter for
only those
packages which are requiring python 2.7, I don't want to change my default
python version(2.4).

Thank you

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

Re: How to begin

[Terry Reedy]

On 2/13/2014 7:57 PM, Ben Finney wrote:

Ryan Gonzalez  writes:


Read the Python reference. I know it's long, but it saves you trouble
of accidentally reinventing the wheel.


Hmm, the language reference is targeted at people *implementing* Python,


This is the first time I have read that. It is definitely aimed at users 
who have already ready the tutorial and need the information that is not 
in the tutorial.



not people who are learning to use it (though it is valuable for them
also). It would be rather overwhelming for a beginner, IMO.

You should instead be directing newcomers to beginner documentation,
such as https://wiki.python.org/moin/BeginnersGuide> and especially
the Python tutorial http://docs.python.org/3/tutorial/>.




--
Terry Jan Reedy

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

IronPython + Selenium2Library + Visual Studio + Robot Framwork

[nw . rabea]

Hi All,

I already familiar with the python, selenium2library and robot framwork.

But i don't know how to connect those things with the ironpython in visual 
studio.

How to integrate pyhton with selenium2library in visual studio by using 
ironpython, is there a special dll to make import to selenium2library on visual 
studio iron python?


Thank you,
Rabea
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Working with the set of real numbers

[Gregory Ewing]

Devin Jeanpierre wrote:

There is no way to iterate over all the reals one at a time, no matter
how fast you execute instructions. If you could, it would be trivial
to show that the reals have the same cardinality as the positive
integers: correspond n with the whatever is returned by the nth call
to it.next.


You're assuming that the calls to it.next are discrete
events separated by some nonzero time interval.

A decent transfinite processor would make a continuum
of calls, and execute uncountably many of them in any
finite period of time.

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

Re:Python version problem for rpm

[Dave Angel]

 anju tiwari  Wrote in message:
> 

 I have two version of python 2.4 and 2.7.
> By default python version is 2.4 . I want to install need to install some rpm 
which needs python 2.7 interpreter. how can I enable 2.7
 interpreter for only those 
packages which are requiring python 2.7, I don’t want to change my
 default python version(2.4)

You don't say what OS you're running,  but I'll assume some
 version of Linux.

If you have some scripts that require 2.7, then change the shebang
 line to point explicitly to the 2.7 executable,  rather than
 using
#/usr/bin/env python

Or make a symlink called python27 and use that explicitly when non
 default version is needed. 

-- 
DaveA

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

Re: A curious bit of code...

[Dave Angel]

 Terry Reedy  Wrote in message:
> On 2/13/2014 1:37 PM, forman.si...@gmail.com wrote:
>> I ran across this and I thought there must be a better way of doing it, but 
>> then after further consideration I wasn't so sure.
>>
>>if key[:1] + key[-1:] == '<>': ...
> 
> if key[:1] == '<' and key[-1:] == '>: ...
> is the obvious choice to me. If the first clause is false, it never 
> computes the second.
>
And therefore no need for the second colon.

if key[:1] == '<' and key[-1] == '>: ...



-- 
DaveA

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

Re: Working with the set of real numbers

[Dave Angel]

 Chris Angelico  Wrote in message:
> On Fri, Feb 14, 2014 at 5:37 PM, Gregory Ewing

>>
>>
>> If it's a quantum computer, it may be able to execute
>> all branches of the iteration in parallel. But it
>> would only have a probability of returning the right
>> answer (in other cases it would kill your cat).
> 
> Oh, that's fine, he's not my cat anyway. Go ahead, build it.
> 

That cat has got to be at least 79 by now. Probably starved by now.

-- 
DaveA

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

Re: Newcomer Help

[David Robinow]

On Thu, Feb 13, 2014 at 11:32 AM, Larry Martell  wrote:

> 18) If you're on AOL, don't worry about anything I've said here.
> You're already a fucking laughing stock, and there's no hope for you.
 Ah, the email bigots. That's why I keep an AOL address around for
occasional use against these jerks.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A curious bit of code...

[Roy Smith]

In article ,
 Dave Angel  wrote:

>  Terry Reedy  Wrote in message:
> > On 2/13/2014 1:37 PM, forman.si...@gmail.com wrote:
> >> I ran across this and I thought there must be a better way of doing it, 
> >> but then after further consideration I wasn't so sure.
> >>
> >>if key[:1] + key[-1:] == '<>': ...
> > 
> > if key[:1] == '<' and key[-1:] == '>: ...
> > is the obvious choice to me. If the first clause is false, it never 
> > computes the second.
> >
> And therefore no need for the second colon.
> 
> if key[:1] == '<' and key[-1] == '>: ...

I'd leave the second colon in.  It makes the statement more uniform, and 
therefor easier to understand.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Working with the set of real numbers

[Rustom Mody]

On Friday, February 14, 2014 12:14:31 PM UTC+5:30, Chris Angelico wrote:

> Oh, that's fine, he's not my cat anyway. Go ahead, build it.

Now Now! I figured you were the cat out here!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Working with the set of real numbers

[Grant Edwards]

On 2014-02-14, Gregory Ewing  wrote:

> If it's a quantum computer, it may be able to execute
> all branches of the iteration in parallel. But it
> would only have a probability of returning the right
> answer (in other cases it would kill your cat).

I know somebody who would claim that _is_ the right answer.

-- 
Grant Edwards   grant.b.edwardsYow! Hello, GORRY-O!!
  at   I'm a GENIUS from HARVARD!!
  gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Best practices to overcome python's dynamic data type nature

[Sam]

Dynamic data type has pros and cons. It is easier to program but also easier to 
create bugs. What are the best practices to reduce bugs caused by Python's 
dynamic data-type characteristic? Can the experienced Python programmers here 
advise?

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

error handling in multithreaded extension callbacks

[Connor]

Hi,

In my extension I'm calling python functions as callbacks from a thread 
generated in an external module.

This works very well, but I'm not sure about the error handling.

1. Normally the python interpreter exits if it runs on an unhandled 
error. Is this the preferred standard behavior for this case too ?

2. How can I implement this in my error handling ?

Here is my code so far. If an error happens in the python code it is 
printed to stderr, but the python script is still running in the main 
thread.


void FUNC_C_DECL coreCommandReadyCallback(TML_COMMAND_HANDLE cmd, 
TML_POINTER data)

{
  // Calling Python out of a non- python created thread
  PyGILState_STATE gstate;
  try {
gstate = PyGILState_Ensure();

PythonCallbackData* callbackData = (PythonCallbackData*) data;

PyObject *arglist;

PyObject *pythonCBFunc = callbackData->pCBFunc;
/* Time to call the callback */
arglist = Py_BuildValue("(LO)", cmd, callbackData->pCBData);
PyObject* result = PyEval_CallObject(pythonCBFunc, arglist);
Py_DECREF(arglist);

if ( PyErr_Occurred() ) {
  PyErr_Print();
  PyErr_SetString(PyExc_TypeError, "PyErr_Occurred");
}


// Release calling Python out of a non- python created thread
PyGILState_Release(gstate);
  }
  catch (...) {
printf ("An Exception Happened\n");
  }
}

Cheers,
Connor

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

Re:Best practices to overcome python's dynamic data type nature

[Dave Angel]

 Sam  Wrote in message:
> Dynamic data type has pros and cons. It is easier to program but also easier 
> to create bugs. What are the best practices to reduce bugs caused by Python's 
> dynamic data-type characteristic? Can the experienced Python programmers here 
> advise?
> 
> Thank you.
> 


Claiming that bugs are caused by pythons dynamics type data
 characteristic is like saying that's great, mistakes are caused
 bye for spell checkers.


-- 
DaveA

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

Re: Best practices to overcome python's dynamic data type nature

[Mark Lawrence]

On 14/02/2014 16:10, Sam wrote:

Dynamic data type has pros and cons. It is easier to program but also easier to 
create bugs. What are the best practices to reduce bugs caused by Python's 
dynamic data-type characteristic? Can the experienced Python programmers here 
advise?

Thank you.



Bugs are caused by the programmer, regardless of the language.  The best 
way of know of avoiding bugs in Python is a combination of running 
Pylint in the Pydev editor as I type (I'd assume other IDEs let you do 
this as well) and testing, more testing and yet more testing.


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

Emacs python-mode.el bug #1207470

[Frank Stutzman]

According to https://bugs.launchpad.net/python-mode/+bug/1207470 this bug 
was fixed in version 6.1.2 of python-mode.el.  I am trying to run 6.1.3 and
am running into it.  I back dated to 6.1.2 and still see it there.  I am 
running GNU Emacs 23.3.1.

Its possible that something I'm doing it causing it, but I have no idea 
what.  I can start emacs with no init file, load python mode, hit enter 
and I get the error.

Has anyone else experienced this?  I am sure that Andreas Roehler (the 
maintainer of python-mode.el) fixed it, but am thinking that it somehow
didn't make it into the released code. 

Frank

-- 


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

Re: Best practices to overcome python's dynamic data type nature

[Mark Lawrence]

On 14/02/2014 16:42, Dave Angel wrote:

  Sam  Wrote in message:

Dynamic data type has pros and cons. It is easier to program but also easier to 
create bugs. What are the best practices to reduce bugs caused by Python's 
dynamic data-type characteristic? Can the experienced Python programmers here 
advise?

Thank you.




Claiming that bugs are caused by pythons dynamics type data
  characteristic is like saying that's great, mistakes are caused
  bye for spell checkers.




Shouldn't that be "spell chequers"? :)

--
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: Best practices to overcome python's dynamic data type nature

[Marko Rauhamaa]

Sam :

> Dynamic data type has pros and cons. It is easier to program but also
> easier to create bugs. What are the best practices to reduce bugs
> caused by Python's dynamic data-type characteristic? Can the
> experienced Python programmers here advise?

Here's some advice from a very experienced programmer: become a very
experienced programmer.

When you are comfortable with the freedoms a dynamic environment gives
you and know how to use them appropriately, you can perform miracles in
a short time.

I like Java a lot, but boy does the boilerplate get in your way. When
you start writing a feature, you have to produce 2000 lines of code
*before writing a single statement*! That's why experienced Java
programmers tend to resort to code generators.

I'm saying a language has a serious issue if you need a code generator
to use it.


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

Re: Best practices to overcome python's dynamic data type nature

[Ethan Furman]

On 02/14/2014 08:10 AM, Sam wrote:


Dynamic data type has pros and cons. It is easier to program but
 also easier to create bugs. What are the best practices to reduce
 bugs caused by Python's dynamic data-type characteristic? Can the
 experienced Python programmers here advise?


Unit tests.

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

Re: Best practices to overcome python's dynamic data type nature

[Gary Herron]

On 02/14/2014 08:10 AM, Sam wrote:

Dynamic data type has pros and cons. It is easier to program but also easier to 
create bugs. What are the best practices to reduce bugs caused by Python's 
dynamic data-type characteristic? Can the experienced Python programmers here 
advise?

Thank you.


The assumptions in that question are misleading.  In fact, Python, with 
it's dynamic nature and other features, allows me to write fewer lines 
of code with fewer bugs-per-line.  That's a win-win situation, not a 
problem which needs to be worked around.


Still, when bugs do creep into code, the best strategy to find them is a 
good testing strategy.


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

Re: Emacs python-mode.el bug #1207470

[Andreas Röhler]

Am 14.02.2014 17:38, schrieb Frank Stutzman:

According to https://bugs.launchpad.net/python-mode/+bug/1207470 this bug
was fixed in version 6.1.2 of python-mode.el.  I am trying to run 6.1.3 and
am running into it.  I back dated to 6.1.2 and still see it there.  I am
running GNU Emacs 23.3.1.

Its possible that something I'm doing it causing it, but I have no idea
what.  I can start emacs with no init file, load python mode, hit enter
and I get the error.

Has anyone else experienced this?  I am sure that Andreas Roehler (the
maintainer of python-mode.el) fixed it, but am thinking that it somehow
didn't make it into the released code.

Frank



Re-opened the ticket mentioned. Please subscribe there, so you may get the 
bug-mail.

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

Re: Best practices to overcome python's dynamic data type nature

[Ethan Furman]

On 02/14/2014 08:54 AM, Marko Rauhamaa wrote:


Here's some advice from a very experienced programmer: become a very
experienced programmer.


+1 QOTW
--
https://mail.python.org/mailman/listinfo/python-list

Explanation of list reference

[dave em]

Hello,

Background:  My twelve y/o son and I are still working our way through Invent 
Your Own Computer Games with Python, 2nd Edition.
(We finished the Khan Academy Javascript Tutorials is the extent of our 
experience)

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.

I tried the to explain as best I can remember is that a variable is assigned to 
a specific memory location with a value inside of it.  Therefore, the variable 
is kind of self contained and if you change the variable, you change the value 
in that specific memory location.

However, when a variable contains a list reference, the memory location of the 
variable points to a separate memory location that stores the list.  It is also 
possible to have multiple variable that point to the memory location of the 
list reference.  And all of those variable can act upon the list reference.

Question:  Is my explanation correct?  If not please set me straight :)

And does anyone have an easier to digest explanation?

Thanks in advance,
Dave
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Jussi Piitulainen]

dave em writes:

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

My quite serious answer is: not at all. In particular, a list is a
value.

All those pointers to references to locations are implementation
details. The user of the language needs to understand that an object
keeps its identity when it's passed around: passed as an argument,
returned by a function, stored in whatever location, retrieved from
whatever location.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Ned Batchelder]

On 2/14/14 1:08 PM, dave em wrote:

Hello,

Background:  My twelve y/o son and I are still working our way through Invent 
Your Own Computer Games with Python, 2nd Edition.
(We finished the Khan Academy Javascript Tutorials is the extent of our 
experience)

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.

I tried the to explain as best I can remember is that a variable is assigned to 
a specific memory location with a value inside of it.  Therefore, the variable 
is kind of self contained and if you change the variable, you change the value 
in that specific memory location.

However, when a variable contains a list reference, the memory location of the 
variable points to a separate memory location that stores the list.  It is also 
possible to have multiple variable that point to the memory location of the 
list reference.  And all of those variable can act upon the list reference.

Question:  Is my explanation correct?  If not please set me straight :)

And does anyone have an easier to digest explanation?

Thanks in advance,
Dave



Names in Python refer to values.  Thinking in terms of memory locations 
might just confuse things.


This is my best explanation of the details:
http://nedbatchelder.com/text/names.html

--
Ned Batchelder, http://nedbatchelder.com

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

Re: Emacs python-mode.el bug #1207470

[Frank Stutzman]

Andreas R?hler  wrote:

> Re-opened the ticket mentioned. Please subscribe there, so you may get the 
> bug-mail.

I've subscribed at launchpad and have given you a few more details there.  
Much appreciate you taking the time to look at this.

-- 
Frank Stutzman


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

Re: Explanation of list reference

[dave em]

On Friday, February 14, 2014 11:26:13 AM UTC-7, Jussi Piitulainen wrote:
> dave em writes:
> 
> 
> 
> > 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.
> 
> 
> 
> My quite serious answer is: not at all. In particular, a list is a
> 
> value.
> 
> 
> 
> All those pointers to references to locations are implementation
> 
> details. The user of the language needs to understand that an object
> 
> keeps its identity when it's passed around: passed as an argument,
> 
> returned by a function, stored in whatever location, retrieved from
> 
> whatever location.

Jessi,

Thanks for your quick response.  I'm still not sure we understand.  The code 
below illustrates the concept we are trying to understand.

Case 1: Example of variable with a specific value from P 170 of IYOCGWP

>>> spam = 42
>>> cheese = spam
>>> spam = 100
>>> spam
100
>>> cheese
42

Case 2: Example of variable with a list reference from p 170

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

What I am trying to explain is this, why in case 1 when acting on spam 
(changing the value from 42 to 100) only affects spam and not cheese.  
Meanwhile, in case two acting on cheese also affects spam.


Thanks and v/r,
Dave
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Ryan Gonzalez]

On 02/14/2014 12:08 PM, dave em wrote:

Hello,

Background:  My twelve y/o son and I are still working our way through Invent 
Your Own Computer Games with Python, 2nd Edition.
(We finished the Khan Academy Javascript Tutorials is the extent of our 
experience)

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.

I tried the to explain as best I can remember is that a variable is assigned to 
a specific memory location with a value inside of it.  Therefore, the variable 
is kind of self contained and if you change the variable, you change the value 
in that specific memory location.

However, when a variable contains a list reference, the memory location of the 
variable points to a separate memory location that stores the list.  It is also 
possible to have multiple variable that point to the memory location of the 
list reference.  And all of those variable can act upon the list reference.

Question:  Is my explanation correct?  If not please set me straight :)

And does anyone have an easier to digest explanation?

Thanks in advance,
Dave


You've got it backwards. In Python, /everything/ is a reference. The 
variable is just a "pointer" to the actual value. When you change a 
variable, you're just changing the memory location it points to.


Strings, ints, tuples, and floats behave differently because they're 
/immutable/. That means that they CANNOT modify themselves. That's why 
all of the string methods return a new string. It also means that, when 
you pass one two a function, a /copy/ of it is made and passed instead.


So, back to the original subject. Everything is a reference. When you do 
this:


|x = [1,2,3]
x = [4,5,6]
|

x now points to a different memory location. And, when you do this:

|x[0] =99000
x[0] =100
|

you're just changing the memory location that |x[0]| points to.



--
--Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's 
becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated."

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

Re: Explanation of list reference

[Denis McMahon]

On Fri, 14 Feb 2014 10:54:29 -0800, dave em wrote:

> On Friday, February 14, 2014 11:26:13 AM UTC-7, Jussi Piitulainen wrote:
>> dave em writes:
>> 
>> 
>> 
>> > 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.
>> 
>> 
>> 
>> My quite serious answer is: not at all. In particular, a list is a
>> 
>> value.
>> 
>> 
>> 
>> All those pointers to references to locations are implementation
>> 
>> details. The user of the language needs to understand that an object
>> 
>> keeps its identity when it's passed around: passed as an argument,
>> 
>> returned by a function, stored in whatever location, retrieved from
>> 
>> whatever location.
> 
> Jessi,
> 
> Thanks for your quick response.  I'm still not sure we understand.  The
> code below illustrates the concept we are trying to understand.
> 
> Case 1: Example of variable with a specific value from P 170 of IYOCGWP
> 
 spam = 42 cheese = spam spam = 100 spam
> 100
 cheese
> 42
> 
> Case 2: Example of variable with a list reference from p 170
> 
 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]
> 
> What I am trying to explain is this, why in case 1 when acting on spam
> (changing the value from 42 to 100) only affects spam and not cheese. 
> Meanwhile, in case two acting on cheese also affects spam.

A list is a container for multiple values, when you do:

cheese = spam

You're pointing cheese and spam at the same container. Now anything you 
do to the container (whether by referencing it as cheese or spam) will 
affect the container.

If you want cheese and spam to start out as separate copies of the same 
list that you can manipulate independently, then you can use:

cheese = [ x for x in spam ]
eggs = spam[:]
ham = list( spam )

>>> spam = [1,2,3,4,5]
>>> cheese = [ x for x in spam ]
>>> ham = list( spam )
>>> eggs = spam[:]
>>> spam
[1, 2, 3, 4, 5]
>>> cheese
[1, 2, 3, 4, 5]
>>> ham
[1, 2, 3, 4, 5]
>>> eggs
[1, 2, 3, 4, 5]
>>> cheese[3] = "fred"
>>> ham[4] = 'ham'
>>> eggs[4] ='eggs'
>>> spam
[1, 2, 3, 4, 5]
>>> cheese
[1, 2, 3, 'fred', 5]
>>> ham
[1, 2, 3, 4, 'ham']
>>> eggs
[1, 2, 3, 4, 'eggs']

-- 
Denis McMahon, denismfmcma...@gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best practices to overcome python's dynamic data type nature

[Chris Angelico]

On Sat, Feb 15, 2014 at 3:54 AM, Marko Rauhamaa  wrote:
> Sam :
>
>> Dynamic data type has pros and cons. It is easier to program but also
>> easier to create bugs. What are the best practices to reduce bugs
>> caused by Python's dynamic data-type characteristic? Can the
>> experienced Python programmers here advise?
>
> Here's some advice from a very experienced programmer: become a very
> experienced programmer.

Definitely.

> I like Java a lot, but boy does the boilerplate get in your way. When
> you start writing a feature, you have to produce 2000 lines of code
> *before writing a single statement*! That's why experienced Java
> programmers tend to resort to code generators.

Also this. It's been shown that, for any given programmer, the number
of bugs per thousand lines of code is approximately stable. This means
that, all other things being equal, a more expressive language will
help you write less buggy code. When you have to write 2000 lines of
boilerplate in a 200 line program, that's 2200 lines that might
potentially be wrong; if, instead, you use a language that requires
just 20 lines of boilerplate for the same number of lines of your
code, that gives you one tenth the total program size and, in very
rough figures, probably about a tenth the number of bugs.

It gets even better than that, though. The more expressive the
language, the easier it is to notice bugs when they do occur. Tell me,
can you see a couple of bugs in this code?

make_combined_color:
push bp
mov bp,sp
mov bx,[bp+8]
cmp bx,16
ja .err
lea ax,[color_data+bx*4+8]
pop bp
ret 8
.err:
; Handle error by returning 0
mov ax,0
pop bp
ret 8

color_data dw 11, 001011
dw  00h, 7Fh, 007F00h, 007F7Fh, 7Fh, 7F007Fh, 7F7F00h, C0C0C0h
dw 7F7F7Fh, FFh, 00FF00h, 00h, FFh, FF00FFh, 00h, FFh

No? Isn't it obvious? Hmm, okay. Well, here's a C version:

int color_data[] =
{0x00,0x7F,0x007F00,0x007F7F,0x7F,0x7F007F,0x7F7F00,0xC0C0C0,
0x7F7F7F,0xFF,0x00FF00,0x00,0xFF,0xFF00FF,0x00,0xFF};

int make_combined_color(int fg, int bg)
{
if (fg>ARRAY_SIZE(color_data)) return 0;
return color_data[fg];
}

If you know C, you should be able to spot a couple of errors here.
(Assume that ARRAY_SIZE gives you the number of elements in an array.
It's an easy enough macro to define, using sizeof.) Now here's the
high level equivalent:

array 
color_data=({0x00,0x7F,0x007F00,0x007F7F,0x7F,0x7F007F,0x7F7F00,0xC0C0C0,
0x7F7F7F,0xFF,0x00FF00,0x00,0xFF,0xFF00FF,0x00,0xFF});

int make_combined_color(int fg, int bg)
{
return color_data[fg];
}

One of the bugs doesn't even exist now! It's a off-by-one error in
array bounds checking. With the high level code, I'm not checking my
own array bounds, so it's impossible for me to get that wrong. As to
the other bug, it's now patently obvious that it's taking two
arguments and ignoring one of them. That's not necessarily a problem,
but the name make_combined_color suggests that it should be, well,
combining something.

Every line of code you write could potentially have a bug in it. If
you can write less code to achieve your goals, then - all other things
being equal, which of course they never quite are - you'll generally
have less bugs. And of course, when you have something that looks
weird but is intentional (maybe the above function is _supposed_ to
ignore its bg argument, for some reason), you use a code comment.
Here's one of my favourites, just for its brevity:

gc->set_foreground(bg); //(sic)

It's clear from the context this code is in that it's correct to set
the display's foreground color to bg, but since it looks wrong at
first glance, it merits a comment :)

So use a language that lets you say things succinctly and readably
(sorry APL). You'll still make bugs, but you'll be able to spot them
in subsequent editing.

Also: Use source control. Get familiar with a DVCS (I usually
recommend either git or hg for all new projects) and get used to
checking back on the origin of the code. This gives you two benefits:
Firstly, you can know exactly what was written when and why, which
helps hugely when you're trying to figure out whether something's
correct or not. And secondly - more subtly but perhaps more
importantly - it frees you from the need to write all that sort of
thing in code comments. You don't need to retain the history of a
block of code by commenting out the failed attempts; go back to source
control for that. You don't need to predict in advance which bits of
code you'll, in six months time, wonder about. (I guarantee you'll
predict wrong.) When you come to something that seems odd, you look it
up, and *then* add the comments. Consider it a YAGNI policy for
verbiage, if you like. Saves you a huge amount of trouble, and keeps
your source code lean and clean - which, see above, will tend to
reduce your bug count.

Huh. My primary point is "keep your code as short as possible"... and
look how long this p

Re: Best practices to overcome python's dynamic data type nature

[Thomas Heller]

Am 14.02.2014 17:32, schrieb Ethan Furman:

On 02/14/2014 08:10 AM, Sam wrote:


Dynamic data type has pros and cons. It is easier to program but
 also easier to create bugs. What are the best practices to reduce
 bugs caused by Python's dynamic data-type characteristic? Can the
 experienced Python programmers here advise?


Unit tests.


Lint-like tools - there are a few - also help to discover bugs,
even before running or testing the code.  They also help in
other ways to write better code.

Myself I use the 'frosted' tool.

Thomas

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

Re: Explanation of list reference

[Marko Rauhamaa]

dave em :

> Case 1: Example of variable with a specific value from P 170 of IYOCGWP
>
 spam = 42
 cheese = spam
 spam = 100
 spam
> 100
 cheese
> 42
>
> Case 2: Example of variable with a list reference from p 170
>
 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]
>
> What I am trying to explain is this, why in case 1 when acting on spam
> (changing the value from 42 to 100) only affects spam and not cheese.
> Meanwhile, in case two acting on cheese also affects spam.

A very good question! Elementary and advanced at the same time.

There are two fundamentally different kinds of values in Python: "small"
values and "big" values. A variable can only hold a small value. A list
element can only hold a small value. A dictionary entry can only hold a
small value. The same is true for an object member (aka field).

So we have four kinds of (memory) slots: variables, list elements,
dictionary entries and fields. Any slot can only hold a small value.

The small values include numbers, booleans (True or False) and
references. All other values are big, too big to fit in a slot. They
have to be stored in a "vault" big enough to hold them. This vault is
called the heap. Big values cannot be stored in slots directly; instead,
references to big values are used.

Let me now annotate your excellent example:

  spam = 42   # put the small value 42 (number) in a memory slot,
  # namely a variable named "spam"

  cheese = spam   # copy the contents of the variable "spam" into
  # another memory slot, a variable named "cheese;"
  # now both variables contain the same small value 42

  spam = 100  # replace the contents of the variable "spam" with the
  # small value 100; leave the contents of the variable
  # "cheese" intact

  spam
  > 100   # as expected

  cheese
  > 42# ditto


  spam = [0, 1, 2, 3, 4, 5]
  # a list is a "big" value; the statement creates a
  # list of six slots in the heap an puts a number in
  # each slot; then, a reference to the list is placed
  # in the variable "spam"

  cheese = spam   # copy the reference to the six-element list from the
  # variable "spam" into the variable "cheese;" the heap
  # still contains only one list, and the two variables
  # refer to the same one

  # (rationale: big values take time and space to copy
  # in full, and almost always copying references is
  # good for the problem at hand; if a full copy is
  # needed, Python has ways to do that, too)

  cheese[1] = 'Hello!'
  # a character string (text snippet) is a "big" value;
  # the statement creates the six-character string
  # 'Hello!' in the heap; then, a reference to the
  # string is placed in the second element of the list
  # referred to by the variable "cheese"

  # (that's a complicated sentence with lots to chew
  # even though the Python statement looks so innocently
  # simple)

  # there still is a single list in the heap; the list
  # is still referred to by both variables; however the
  # second slot of the list, which used to hold the
  # number 1, has been replaced with a reference to the
  # "big" string 'Hello!'

  spam
  > [0, 'Hello!', 2, 3, 4, 5]
  # as expected, right?

  cheese
  > [0, 'Hello!', 2, 3, 4, 5]
  # right?


The final situation is represented by this picture of Python's memory:


 spam  cheese
+-+   +-+
|  .  |   |  .  |
+--+--+   +--+--+
   | |
   | |   VARIABLES
  = = =|= = = = = = =|= = = = = = = = = = = = = = = = = = =
   |/THE HEAP
   |   -
   |  /
   | |
   v v
+-+-+-+-+-+-+
|  0  |  .  |  2  |  3  |  4  |  5  | a list
+-+--+--+-+-+-+-+
 |
 |
 |
 |
 v a string
 ++
 | Hello! | a string
 ++


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

Re: A curious bit of code...

[forman . simon]

On Thursday, February 13, 2014 7:26:48 PM UTC-8, Ned Batchelder wrote:
> On 2/13/14 9:45 PM, forman.si...@gmail.com wrote:
> 
> > For the record I wasn't worried about the performance.  ;-)
> 
> >
> 
> > It was for Tkinter event strings not markup tags.
> 
> >
> 
> > I'm glad this was the time winner!
> 
> >
> 
> > "key and key[0] == '<' and key[-1] == '>'"
> 
> >
> 
> >
> 
> > Cheers to the folks who did the timings (and saved me from the trouble!)
> 
> >
> 
> > Last but not least...  s[::len(s)-1]   omg!!?   ;-D
> 
> >
> 
> 
> 
> If you aren't worried about performance, why are you choosing your code 
> 
> based on which is the fastest?  There are other characteristics 
> 
> (clarity, flexibility, robustness, ...) that could be more useful.


I guess I'm taking the word "worried" a little too seriously.

Back story: I am hoping to contribute to IDLE and am reading the code as a 
first step.  I came across that line of code (BTW, I was wrong: it is NOT 
processing Tkinter event strings but rather special " entries" in 
linecache.cache [1]) and had to resist the urge to change it to something more 
readable (to me.)  But when I thought about it I wasn't able to discern if any 
of the new versions would actually be enough of an improvement to justify 
changing it.

To be clear: I have no intention of modifying the IDLE codebase just for fairly 
trivial points like this one line.

The most satisfying (to me) of the possibilities is "if key and key[0] == '<' 
and key[-1] == '>':" in the dimensions, if you will, of readability and, uh, 
unsurprising-ness, and so I was pleased to learn that that was also the fastest.


(FWIW, it seems to me that whoever wrote that line was influenced by shell 
programming.  It's a shell sort of a trick to my eye.)


When writing Python code I *do* value "clarity, flexibility, robustness" and 
almost never worry about performance unless something is actually slow in a way 
that affects something..

Warm regards,
~Simon


[1] http://hg.python.org/cpython/file/3a1db0d2747e/Lib/idlelib/PyShell.py#l117
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Ian Kelly]

On Fri, Feb 14, 2014 at 11:54 AM, dave em  wrote:
> Thanks for your quick response.  I'm still not sure we understand.  The code 
> below illustrates the concept we are trying to understand.
>
> Case 1: Example of variable with a specific value from P 170 of IYOCGWP
>
 spam = 42
 cheese = spam
 spam = 100
 spam
> 100
 cheese
> 42
>
> Case 2: Example of variable with a list reference from p 170
>
 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]
>
> What I am trying to explain is this, why in case 1 when acting on spam 
> (changing the value from 42 to 100) only affects spam and not cheese.  
> Meanwhile, in case two acting on cheese also affects spam.

In the first case, after the assignment "cheese = spam", the names
spam and cheese are bound to the same object (42).  If you were to
modify the object 42 (which you cannot do in this case, because ints
are immutable) then you would see the change reflected in the object
regardless of which name you used to access it.  You then rebind the
name "spam" to a different object (100), which does not affect the
binding of the name "cheese" at all; the names end up referring to
different objects.

In the second case, after the assignment "cheese = spam", the names
again are bound to the same object, a list.  The assignment "cheese[1]
= 'Hello!'" then *modifies* that list, without rebinding cheese.
cheese and spam continue to refer to the same object, and since it was
modified you can see the change in that object regardless of which
name you used to access it.

If in the second case, you were to explicitly copy the list (e.g.
"cheese = list(spam)") prior to modifying it, then the two names would
instead be bound to different objects, and so subsequently modifying
one would not affect the other.

So the short answer is that there is no difference at all between the
way that names are bound to ints and the way they are bound to lists.
There only superficially appears to be a difference because ints are
immutable and lists are not.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Ian Kelly]

On Fri, Feb 14, 2014 at 12:56 PM, Marko Rauhamaa  wrote:
> There are two fundamentally different kinds of values in Python: "small"
> values and "big" values. A variable can only hold a small value. A list
> element can only hold a small value. A dictionary entry can only hold a
> small value. The same is true for an object member (aka field).
>
> So we have four kinds of (memory) slots: variables, list elements,
> dictionary entries and fields. Any slot can only hold a small value.
>
> The small values include numbers, booleans (True or False) and
> references. All other values are big, too big to fit in a slot. They
> have to be stored in a "vault" big enough to hold them. This vault is
> called the heap. Big values cannot be stored in slots directly; instead,
> references to big values are used.

This is nonsense.  Python the language makes no such distinction
between "big" and "small" values.  *All* objects in CPython are stored
internally on the heap.  Other implementations may use different
memory management schemes.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python programming

[ngangsia akumbo]

wow wow

Thanks for the contutions

Thanks guys, 
many more are welcome
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Jussi Piitulainen]

dave em writes:

> On Friday, February 14, 2014 11:26:13 AM UTC-7, Jussi Piitulainen wrote:
> > dave em writes:
> > 
> > > 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.
> > 
> > My quite serious answer is: not at all. In particular, a list is a
> > value.
> > 
> > All those pointers to references to locations are implementation
> > details. The user of the language needs to understand that an
> > object keeps its identity when it's passed around: passed as an
> > argument, returned by a function, stored in whatever location,
> > retrieved from whatever location.
> 
> Thanks for your quick response.  I'm still not sure we understand.
> The code below illustrates the concept we are trying to understand.
> 
> Case 1: Example of variable with a specific value from P 170 of IYOCGWP
> 
> >>> spam = 42
> >>> cheese = spam
> >>> spam = 100
> >>> spam
> 100
> >>> cheese
> 42

In case 1, you have only assignments to variables. After spam = 100,
the value of spam is another number. The previous number 42 itself is
still 42 - number are not mutable, and no attempt was made to change
the number.

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

> Case 2: Example of variable with a list reference from p 170
> 
> >>> 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).

You don't need to mention the variable cheese here. Note how the value
of spam is now different (though still the same object), even though
you didn't mention spam at all when you changed it.

Python syntax to replace an element of a list looks much like an
assignment - many languages do this - but it's not. Behind the scenes
it's a method call

>>> cheese.__setitem__(1, 'spam')

where cheese is a variable reference. You are calling a method of the
list that is the value of the variable.

> What I am trying to explain is this, why in case 1 when acting on
> spam (changing the value from 42 to 100) only affects spam and not
> cheese.  Meanwhile, in case two acting on cheese also affects spam.

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.

One last thing: a variable is not an object.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Ned Batchelder]

On 2/14/14 3:17 PM, Ian Kelly wrote:

On Fri, Feb 14, 2014 at 12:56 PM, Marko Rauhamaa  wrote:

There are two fundamentally different kinds of values in Python: "small"
values and "big" values. A variable can only hold a small value. A list
element can only hold a small value. A dictionary entry can only hold a
small value. The same is true for an object member (aka field).

So we have four kinds of (memory) slots: variables, list elements,
dictionary entries and fields. Any slot can only hold a small value.

The small values include numbers, booleans (True or False) and
references. All other values are big, too big to fit in a slot. They
have to be stored in a "vault" big enough to hold them. This vault is
called the heap. Big values cannot be stored in slots directly; instead,
references to big values are used.


This is nonsense.  Python the language makes no such distinction
between "big" and "small" values.  *All* objects in CPython are stored
internally on the heap.  Other implementations may use different
memory management schemes.



Marko, I have to agree with Ian. While I really like the picture you 
drew, the distinction between big and small values is pure fiction. 
CPython does not store ints directly in list elements, for example.


All names are references to values.  All list elements (and dictionary 
values, dictionary keys, set elements, etc) are references to values.  A 
value can be another container like a list, or it can be something 
"simple" like an int.


This covers all the details, including pictures like Marko's, but with 
an explanation why we draw the ints inside the boxes: 
http://nedbatchelder.com/text/names.html


--
Ned Batchelder, http://nedbatchelder.com

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

Re: Explanation of list reference

[Marko Rauhamaa]

Ian Kelly :

> This is nonsense. Python the language makes no such distinction
> between "big" and "small" values. *All* objects in CPython are stored
> internally on the heap. Other implementations may use different memory
> management schemes.

You're right, of course. Conceptually, the "everything is a reference"
and the "small"/"big" distinction are equivalent (produce the same
outcomes). The question is, which model is easier for a beginner to
grasp.

Say you write:

   1 + 2

You may not find it most intuitive to follow through the object
instantiation and reference manipulation implicit in the "everything is
a reference" model when you think you understand numbers but have little
idea of memory, objects, heap, allocation etc.


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

Re: A curious bit of code...

[Mark Lawrence]

On 14/02/2014 20:04, forman.si...@gmail.com wrote:

On Thursday, February 13, 2014 7:26:48 PM UTC-8, Ned Batchelder wrote:

On 2/13/14 9:45 PM, forman.si...@gmail.com wrote:


For the record I wasn't worried about the performance.  ;-)







It was for Tkinter event strings not markup tags.







I'm glad this was the time winner!







"key and key[0] == '<' and key[-1] == '>'"











Cheers to the folks who did the timings (and saved me from the trouble!)







Last but not least...  s[::len(s)-1]   omg!!?   ;-D








If you aren't worried about performance, why are you choosing your code

based on which is the fastest?  There are other characteristics

(clarity, flexibility, robustness, ...) that could be more useful.



I guess I'm taking the word "worried" a little too seriously.

Back story: I am hoping to contribute to IDLE and am reading the code as a first step.  I came 
across that line of code (BTW, I was wrong: it is NOT processing Tkinter event strings but 
rather special " entries" in linecache.cache [1]) and had to 
resist the urge to change it to something more readable (to me.)  But when I thought about it I 
wasn't able to discern if any of the new versions would actually be enough of an improvement to 
justify changing it.

To be clear: I have no intention of modifying the IDLE codebase just for fairly 
trivial points like this one line.

The most satisfying (to me) of the possibilities is "if key and key[0] == '<' and 
key[-1] == '>':" in the dimensions, if you will, of readability and, uh, 
unsurprising-ness, and so I was pleased to learn that that was also the fastest.


(FWIW, it seems to me that whoever wrote that line was influenced by shell 
programming.  It's a shell sort of a trick to my eye.)


When writing Python code I *do* value "clarity, flexibility, robustness" and 
almost never worry about performance unless something is actually slow in a way that 
affects something..

Warm regards,
~Simon


[1] http://hg.python.org/cpython/file/3a1db0d2747e/Lib/idlelib/PyShell.py#l117



Pleased to have you on board, as I'm know that Terry Reedy et al can do 
with a helping hand.


But please note you appear to be using google groups, hence the double 
line spacing above and trying to reply to paragraphs that run as a 
single line across the screen.  Therefore would you please read and 
action this https://wiki.python.org/moin/GoogleGroupsPython, 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

Unitest mock issue

[Joseph L. Casale]

I am trying to patch a method of a class thats proving to be less than trivial.

The module I am writing a test for, ModuleA imports another ModuleB and
instantiates a class from this. Problem is, ModuleA incorporates multiprocessing
queues and I suspect I am missing the patch as the object in question is 
retrieved
from a queue and unpickled, at which point the method is invoked on that 
retrieved
object immediately.

Before the class I am patching is pickled, I don't invoke the method, but if I 
mock
the entire class, I can clearly see I am replacing it before pickling. So, 
given it is
this same module I am pickling/unpickling, what nuance have I missed in just
replacing the method of interest during unpickling?

Thanks for any guidance,
jlc
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Chris Angelico]

On Sat, Feb 15, 2014 at 7:58 AM, Marko Rauhamaa  wrote:
> Say you write:
>
>1 + 2
>
> You may not find it most intuitive to follow through the object
> instantiation and reference manipulation implicit in the "everything is
> a reference" model when you think you understand numbers but have little
> idea of memory, objects, heap, allocation etc.

I don't object to a bit of handwaving where it doesn't matter
(especially as regards language design versus language interpreter
design - I'll happily talk about "storing an object on the heap"
without going into the details of allocating memory, managing
reference counts, and so on; the details of how CPython goes about
storing stuff on the heap isn't particularly significant), but be
careful of simplifications that will cause problems down the line.
Distinguishing "small values" from "big values" leads to the obvious
question: Which is which? And why doesn't this work?

>>> x = 3000
>>> z = x
>>> z is x
True

Seems legit... you set z equal to x, and then z is the same as x.
Okay, let's try that slightly differently.

>>> x = 1000
>>> y = 2000
>>> z = x + y
>>> z is 3000
False

What's different? How come I can do comparisons with 'is' sometimes
but not other times? (And just to make things more confusing, if you
do this in CPython with small numbers, it'll *seem* to work.)

The only way to explain it thoroughly is to fully distinguish between
names and objects, and explain what assignment actually means. Then
it's obvious that, in the first case, the identity check passes, while
in the second case, it doesn't.

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

Re: Explanation of list reference

[Marko Rauhamaa]

Marko Rauhamaa :

> You're right, of course. Conceptually, the "everything is a reference"
> and the "small"/"big" distinction are equivalent (produce the same
> outcomes). The question is, which model is easier for a beginner to
> grasp.

In fact, if you adjust my annotations to the given example from the
"everything is a reference" point of view, you'll see that the
explanations become a whole deal longer and probably more confusing.
Also, the picture becomes much messier with more strings attached.


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

Re: Explanation of list reference

[Terry Reedy]

On 2/14/2014 1:08 PM, dave em wrote:


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.

I tried the to explain as best I can remember is that a variable is
assigned to a specific memory location with a value inside of it.


The data model of C and other memory-oriented languages is *different* 
from the object model of Python and similar languages. The concept of 
'memory address' is fundamental to C and absent from Python. To 
understand Python, one must think in terms of its referenced object 
model and not C's memory-address model.


Consider name-binding statements, also called assignment statements. 
The simplest form is

 = 

As always, the expression evaluates to a Python object. It may be an 
existing object or it may by a newly created. Either way, the name is 
associated with the object. Subsequent to the name binding, the name, as 
an expression, evaluates to the object it points to.


An object can have 0 to many names associated with it. That set of names 
can change. A name can be associated with only one object at a time, but 
can be rebound to other objects.


All objects have class (type) and a value. The value of some objects can 
be changed (lists, sets, dicts, most user-defined classes), others are 
fixed (numbers, strings, tuples, frozensets).


a = 1  # a points to int object with value 1; a == 1
b = a  # b points to the same int object; b == 1 and b is a
a = '1'  # a now points to a str object with value '1'; a == '1'

c = [1,2,3]  # c points to a list object whose value is the
# given sequence of int objects; c == [1,2,3]
d = c  # d is the same list object as c
d[1] = '2'  # This associates the indicated 'slot' in the
collection object d (which is also c) with a '2' string object.

'Variable' in C (a fixed memory location with a mutable value) is quite 
different from 'variable' in Python. Most people in Python mean a fixed 
name, potentially associated with a sequence of objects. In CPython, 
each object would usually be at a different C location. 'Variable' in 
math has multiple meanings.


--
Terry Jan Reedy

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

Re: better and user friendly IDE recommended?

[Martin Schöön]

Den 2014-02-14 skrev Rustom Mody :
> On Friday, February 14, 2014 2:57:13 AM UTC+5:30, Martin Schöön wrote:
>> Den 2013-09-17 skrev rusi 
>> > On Wednesday, September 11, 2013 7:44:04 PM UTC+5:30, 
>> > mnishpsyched wrote:
>> > Just saw this
>> > http://www.youtube.com/watch?v=1-dUkyn_fZA
>> > Yeah... scientific programming and web programming are hardly the same :-)
>> > Still it might be worth 20 minutes of your time
>
>> I have started testing this. It is early days so too early to pass
>> judgement.
>
>> Anyone out there using Emacs + Python + Orgmode like this?
>> I might to need ask some questions :-)
>
> The speaker -- Kitchin -- is quite active on the org mode list.
> And a bunch of other babel users. You should try there.
> And please do report back your findings!

Right. I expected this response. I hoped to keep a cap on the
number of cyberpubs I hang out in :-)

And I prefer the usenet above all other alternatives.

OK, I will dive into the Orgmode pond and I will report back but
please be patient. This is a pure spare time activity.

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

Re: Explanation of list reference

[Marko Rauhamaa]

Chris Angelico :

> be careful of simplifications that will cause problems down the line.

Sure. Let it be said, though, that sometimes you learn through
inaccuracies, a technique used intentionally by Knuth's TeXBook, for
example. In fact, you get through highschool mathematics successfully
without knowing what numbers and variables actually are.

> Distinguishing "small values" from "big values" leads to the obvious
> question: Which is which? And why doesn't this work?

This is related to the recent id(string) question on this forum.

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.

Back to the original question, though. Python, I think, is a great
introductory programming language to a complete newbie. Explaining
Python's memory model at some level is necessary right off the bat.
However, it is far from easy to understand. I'm not sure the small/big
way is the best approach, but it seeks to bridge the gap from the naive
understanding of tutorial day one to the presented question (tutorial
day two).


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

Re: A curious bit of code...

[Simon Forman]

On Friday, February 14, 2014 1:01:48 PM UTC-8, Mark Lawrence wrote:
[snip]
> 
> Pleased to have you on board, as I'm know that Terry Reedy et al can do 
> with a helping hand.
> 
> But please note you appear to be using google groups, hence the double 
> line spacing above and trying to reply to paragraphs that run as a 
> single line across the screen.  Therefore would you please read and 
> action this https://wiki.python.org/moin/GoogleGroupsPython, thanks.


Ah!  Thanks for the tip. ;-)

(Just last night I was trying to explain to a friend about Usenet
and how it's not Google Groups.)


I really hope I can be of use with IDLE.  I've been using it for years now. :)


Warm regards,
~Simon



-- 
http://phoenixbureau.org/
http://phoenixbureau.org/blog.html
http://twitter.com/SimonForman



"The history of mankind for the last four centuries is rather like that of
an imprisoned sleeper, stirring clumsily and uneasily while the prison that
restrains and shelters him catches fire, not waking but incorporating the
crackling and warmth of the fire with ancient and incongruous dreams, than
like that of a man consciously awake to danger and opportunity."
--H. P. Wells, "A Short History of the World"

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

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

[Nick Timkovich]

I have a Python 3.x program that processes several large text files that
contain sizeable arrays of data that can occasionally brush up against the
memory limit of my puny workstation.  From some basic memory profiling, it
seems like when using the generator, the memory usage of my script balloons
to hold consecutive elements, using up to twice the memory I expect.

I made a simple, stand alone example to test the generator and I get
similar results in Python 2.7, 3.3, and 3.4.  My test code follows,
`memory_usage()` is a modifed version of [this function from an SO
question](http://stackoverflow.com/a/898406/194586) which uses
`/proc/self/status` and agrees with `top` as I watch it.  `resource` is
probably a more cross-platform method:

###

import sys, resource, gc, time

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 = [1] * int(size * 1e6)
#time.sleep(1)
yield data

def consumer():
for data in biggen():
rusage = resource.getrusage(resource.RUSAGE_SELF)
peak_mb = rusage.ru_maxrss/1024.0
print('Peak: {0:6.1f} MB, Data Len: {1:6.1f} M'.format(
peak_mb, len(data)/1e6))
#print(memory_usage())

data = None  # go
del data # away
gc.collect() # please.

# def memory_usage():
# """Memory usage of the current process, requires /proc/self/status"""
# # http://stackoverflow.com/a/898406/194586
# result = {'peak': 0, 'rss': 0}
# for line in open('/proc/self/status'):
# parts = line.split()
# key = parts[0][2:-1].lower()
# if key in result:
# result[key] = int(parts[1])/1024.0
# return 'Peak: {peak:6.1f} MB, Current: {rss:6.1f} MB'.format(**result)

print(sys.version)
consumer()

###

In practice I'll process data coming from such a generator loop, saving
just what I need, then discard it.

When I run the above script, and two large elements come in series (the
data size can be highly variable), it seems like Python computes the next
before freeing the previous, leading to up to double the memory usage.

$ python genmem.py
2.7.3 (default, Sep 26 2013, 20:08:41)
[GCC 4.6.3]
Peak:7.9 MB, Data Len:1.0 M
Peak:   11.5 MB, Data Len:1.0 M
Peak:   45.8 MB, Data Len:   10.0 M
Peak:   45.9 MB, Data Len:1.0 M
Peak:   45.9 MB, Data Len:1.0 M
Peak:   45.9 MB, Data Len:   10.0 M
#^^  not much different versus previous 10M-list
Peak:   80.2 MB, Data Len:   10.0 M
#^^  same list size, but new memory peak at roughly twice the
usage
Peak:   80.2 MB, Data Len:1.0 M
Peak:   80.2 MB, Data Len:1.0 M
Peak:   80.2 MB, Data Len:   10.0 M
Peak:   80.2 MB, Data Len:   10.0 M
Peak:  118.3 MB, Data Len:   20.0 M
#^^  and again...  (20+10)*c
Peak:  118.3 MB, Data Len:1.0 M
Peak:  118.3 MB, Data Len:1.0 M
Peak:  118.3 MB, Data Len:   20.0 M
Peak:  156.5 MB, Data Len:   20.0 M
#^^  and again. (20+20)*c
Peak:  156.5 MB, Data Len:1.0 M
Peak:  156.5 MB, Data Len:1.0 M

The crazy belt-and-suspenders-and-duct-tape approach `data = None`, `del
data`, and `gc.collect()` does nothing.

I'm pretty sure the generator itself is not doubling up on memory because
otherwise a single large value it yields would increase the peak usage, and
in the *same iteration* a large object appeared; it's only large
consecutive objects.

How can I save my memory?

Cheers,
Nick

cc: StackOverflow http://stackoverflow.com/q/21787099/194586
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[pecore]

dave em  writes:

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

s/list/mutable object/

# Mr Bond and Mr Tont are two different ob^H^H persons
james_bond = SecretAgent()
james_tont = SecretAgent()

# in some circles, Mr Bond is know as agent 007
agent_007 = james_bond

# Mr Bond, aka 007, is sent to the Caribbeans to crush Spectre
agent_007.move_to('Barbados')
print agent_007.location
print james_bond.location

# Mr Bond, alas, retires and his place in the Mi5 is taken, alas, by Mr Tont
agent_007 = james_tont

# Mr Tont, aka 007, is sent to Hong Kong to, to, whatever... 
agent_007.move_to('Hong Kong')
print agent_007.location
print james_bond.location
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Dave Angel]

 Nick Timkovich  Wrote in message:
> 
 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 = [1] * int(size * 1e6)
        #time.sleep(1)
        yield data

> def consumer():
    for data in biggen():
        rusage = resource.getrusage(resource.RUSAGE_SELF)
        peak_mb = rusage.ru_maxrss/1024.0
        print('Peak: {0:6.1f} MB, Data Len: {1:6.1f} M'.format(
                peak_mb, len(data)/1e6))
        #print(memory_usage())

        data = None  # go
        del data     # away
        gc.collect() # please.



I think one problem is in the generator itself.  After the yield,
 set data=None

-- 
DaveA

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

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

[Ian Kelly]

On Fri, Feb 14, 2014 at 3:27 PM, Nick Timkovich  wrote:
> I have a Python 3.x program that processes several large text files that
> contain sizeable arrays of data that can occasionally brush up against the
> memory limit of my puny workstation.  From some basic memory profiling, it
> seems like when using the generator, the memory usage of my script balloons
> to hold consecutive elements, using up to twice the memory I expect.
>
> I made a simple, stand alone example to test the generator and I get similar
> results in Python 2.7, 3.3, and 3.4.  My test code follows, `memory_usage()`
> is a modifed version of [this function from an SO
> question](http://stackoverflow.com/a/898406/194586) which uses
> `/proc/self/status` and agrees with `top` as I watch it.  `resource` is
> probably a more cross-platform method:
>
> ###
>
> import sys, resource, gc, time
>
> 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 = [1] * int(size * 1e6)
> #time.sleep(1)
> yield data
>
> def consumer():
> for data in biggen():
> rusage = resource.getrusage(resource.RUSAGE_SELF)
> peak_mb = rusage.ru_maxrss/1024.0
> print('Peak: {0:6.1f} MB, Data Len: {1:6.1f} M'.format(
> peak_mb, len(data)/1e6))
> #print(memory_usage())
>
> data = None  # go
> del data # away
> gc.collect() # please.
>
> # def memory_usage():
> # """Memory usage of the current process, requires /proc/self/status"""
> # # http://stackoverflow.com/a/898406/194586
> # result = {'peak': 0, 'rss': 0}
> # for line in open('/proc/self/status'):
> # parts = line.split()
> # key = parts[0][2:-1].lower()
> # if key in result:
> # result[key] = int(parts[1])/1024.0
> # return 'Peak: {peak:6.1f} MB, Current: {rss:6.1f} MB'.format(**result)
>
> print(sys.version)
> consumer()
>
> ###
>
> In practice I'll process data coming from such a generator loop, saving just
> what I need, then discard it.
>
> When I run the above script, and two large elements come in series (the data
> size can be highly variable), it seems like Python computes the next before
> freeing the previous, leading to up to double the memory usage.
>
> [...]
>
> The crazy belt-and-suspenders-and-duct-tape approach `data = None`, `del
> data`, and `gc.collect()` does nothing.

Because at the time you call gc.collect(), the generator still holds a
reference to the data, so it can't be collected.  Assuming this is
running in CPython and there are no reference cycles in the data, the
collection is unnecessary anyway, since CPython will automatically
free the data immediately when there are no references (but this is
not guaranteed for other implementations of Python).

> I'm pretty sure the generator itself is not doubling up on memory because
> otherwise a single large value it yields would increase the peak usage, and
> in the *same iteration* a large object appeared; it's only large consecutive
> objects.

Look again.  What happens to the data between two iterations of the generator?

1) data variable holds the data from the prior iteration
2) the loop jumps back up to the top
3) the data for the next iteration is constructed
4) the data for the next iteration is assigned to the data variable

It is not until step 4 that the variable stops referencing the data
from the prior iteration.  So there is a brief period where both of
these objects must still be in memory.

> How can I save my memory?

Try unreferencing the data in the generator at the end of each iteration.
-- 
https://mail.python.org/mailman/listinfo/python-list

A curious bit of code...

[Simon Forman]

(Apologies if this results in a double-post.)

On Friday, February 14, 2014 1:01:48 PM UTC-8, Mark Lawrence wrote:
[snip]
> 
> Pleased to have you on board, as I'm know that Terry Reedy et al can do 
> with a helping hand.
> 
> But please note you appear to be using google groups, hence the double 
> line spacing above and trying to reply to paragraphs that run as a 
> single line across the screen.  Therefore would you please read and 
> action this https://wiki.python.org/moin/GoogleGroupsPython, thanks.



Ah!  Thanks for the tip. ;-)

(Just last night I was trying to explain to a friend about Usenet
and how it's not Google Groups.)


I really hope I can be of use with IDLE.  I've been using it for years now. :)


Warm regards,
~Simon

-- 
http://phoenixbureau.org/
http://phoenixbureau.org/blog.html
http://twitter.com/SimonForman



"The history of mankind for the last four centuries is rather like that of
an imprisoned sleeper, stirring clumsily and uneasily while the prison that
restrains and shelters him catches fire, not waking but incorporating the
crackling and warmth of the fire with ancient and incongruous dreams, than
like that of a man consciously awake to danger and opportunity."
--H. P. Wells, "A Short History of the World"

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

Re: Explanation of list reference

[Ned Batchelder]

On 2/14/14 4:43 PM, Marko Rauhamaa wrote:

Chris Angelico:


>be careful of simplifications that will cause problems down the line.

Sure. Let it be said, though, that sometimes you learn through
inaccuracies, a technique used intentionally by Knuth's TeXBook, for
example. In fact, you get through highschool mathematics successfully
without knowing what numbers and variables actually are.



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


--
Ned Batchelder, http://nedbatchelder.com

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

Re: Working with the set of real numbers

[Devin Jeanpierre]

On Fri, Feb 14, 2014 at 3:30 AM, Gregory Ewing
 wrote:
> Devin Jeanpierre wrote:
>> There is no way to iterate over all the reals one at a time, no matter
>> how fast you execute instructions. If you could, it would be trivial
>> to show that the reals have the same cardinality as the positive
>> integers: correspond n with the whatever is returned by the nth call
>> to it.next.
>
>
> You're assuming that the calls to it.next are discrete
> events separated by some nonzero time interval.

I'm not. If you want to imagine infinitely fast computers, you must
allow for things to "precede" each other in the program's execution,
or else you can't execute any program at all.

In such an infinitely fast computer, if iteration works by calling a
.next() method repeatedly, it can't iterate uncountably many times, by
construction. If you're executing uncountably many instructions per
second, the loop would terminate immediately, having executed
countably infinitely many iterations.

> A decent transfinite processor would make a continuum
> of calls, and execute uncountably many of them in any
> finite period of time.

Yes, you could imagine a computer that does a thing for every real. My
issue is that the cited thing is transfinite induction, for which the
induction covers countably many values; handling of the rest of the
values is a second step. This is also the implication of such a word
as "iteration".

I suppose this was accidental on the part of the poster, and I
shouldn't have disagreed so strongly. I suspect they meant what you
are getting at, instead, which is that there is no successor to any
iteration, and between any two iterations there are uncountably many
iterations that happened. Operations occur in an order, but not
sequentially. (Of course, such a machine would be alien and absurd.)

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

Re: Explanation of list reference

[dave em]

All,

Thanks for the excellent explanations and for sharing your knowledge.  I 
definitely have a better understanding than I did this morning.

Best regards,
Dave
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

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

The only situation I can think of is that immutables are allowed to be
interned, which is why this comes up True (in CPython) when it would
come up False with larger values (as I demonstrated earlier):

>>> x = 1
>>> y = 2
>>> z = x + y
>>> z is 3
True

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

How to turn a package into something pip can install

[Roy Smith]

I want to use (https://github.com/timetric/python-metar).  Our 
deployment process more or less requires that it be installed via pip.  
We maintain our own cache of packages and install using:

pip install --no-index --quiet --find-links packages --requirement 
requirements.txt 

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?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to begin

[Ryan Gonzalez]

Ack, I meant that, not the whole reference.


On Thu, Feb 13, 2014 at 6:57 PM, Ben Finney wrote:

> Ryan Gonzalez  writes:
>
> > Read the Python reference. I know it's long, but it saves you trouble
> > of accidentally reinventing the wheel.
>
> Hmm, the language reference is targeted at people *implementing* Python,
> not people who are learning to use it (though it is valuable for them
> also). It would be rather overwhelming for a beginner, IMO.
>
> You should instead be directing newcomers to beginner documentation,
> such as https://wiki.python.org/moin/BeginnersGuide> and especially
> the Python tutorial http://docs.python.org/3/tutorial/>.
>
> --
>  \  "If you get invited to your first orgy, don't just show up |
>   `\ nude. That's a common mistake. You have to let nudity |
> _o__)  'happen.'" --Jack Handey |
> Ben Finney
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>



-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Rustom Mody]

On Saturday, February 15, 2014 6:27:33 AM UTC+5:30, Chris Angelico wrote:
> 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? 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.

Fundamentally your definition above is circular: In effect
the python expr "a is b" is the same as a is b.

The only way to move ahead on that circularity is to 'leak-out'
the under-belly of python's object-model.

My own preference: No is operator; only id when we deliberately need to
poke into the implementation.

Of course I am in a miniscule minority I guess on that :-)
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Ryan Gonzalez]

python setup.py sdist



On Fri, Feb 14, 2014 at 7:47 PM, Roy Smith  wrote:

> I want to use (https://github.com/timetric/python-metar).  Our
> deployment process more or less requires that it be installed via pip.
> We maintain our own cache of packages and install using:
>
> pip install --no-index --quiet --find-links packages --requirement
> requirements.txt
>
> 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?
> --
> https://mail.python.org/mailman/listinfo/python-list
>



-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Chris Angelico]

On Sat, Feb 15, 2014 at 12:55 PM, Rustom Mody  wrote:
> On Saturday, February 15, 2014 6:27:33 AM UTC+5:30, Chris Angelico wrote:
>> 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
>
> Fundamentally your definition above is circular: In effect
> the python expr "a is b" is the same as a is b.

It's not circular, it's stating the definition of the operator. And
since the definition is so simple, it's impossible - at that level -
for it to be ambiguous. It's possible for equality to be ambiguous, if
you have two types which define __eq__:

class Everyone:
def __eq__(self, other): return True
class Noone:
def __eq__(self, other): return False

>>> Everyone()==Noone()
True
>>> Noone()==Everyone()
False

But it's not possible for 'is' to behave like that.

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

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

[Roy Smith]

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

  Could not find any downloads that satisfy the requirement metar==1.4.0
No distributions at all found for metar==1.4.0
Storing complete log in /home/roy/.pip/pip.log






> 
> 
> On Fri, Feb 14, 2014 at 7:47 PM, Roy Smith  wrote:
> 
> > I want to use (https://github.com/timetric/python-metar).  Our
> > deployment process more or less requires that it be installed via pip.
> > We maintain our own cache of packages and install using:
> >
> > pip install --no-index --quiet --find-links packages --requirement
> > requirements.txt
> >
> > 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?
> > --
> > https://mail.python.org/mailman/listinfo/python-list
> >
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Rustom Mody]

On Saturday, February 15, 2014 7:38:39 AM UTC+5:30, Chris Angelico wrote:
> On Sat, Feb 15, 2014 at 12:55 PM, Rustom Mody  wrote:
> > On Saturday, February 15, 2014 6:27:33 AM UTC+5:30, Chris Angelico wrote:
> >> 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
> > Fundamentally your definition above is circular: In effect
> > the python expr "a is b" is the same as a is b.

> It's not circular, it's stating the definition of the operator. And
> since the definition is so simple, it's impossible - at that level -
> for it to be ambiguous. It's possible for equality to be ambiguous, if
> you have two types which define __eq__:

At what level can you explain the following?

>>> x = 1234567 * 1234567
>>> x
1524155677489L
>>> y = 1234567 * 1234567
>>> y
1524155677489L
>>> x is y
False
>>> 1524155677489 == x
True
>>> 1524155677489  is x
False
>>> 

As against

>>> x = 2*3
>>> y= 2*3
>>> x == y
True
>>> x is y
True
>>> 6 is x
True
>>> 


"Interning" you will say.
Is interning a simple matter for example at the level of questioning of the OP?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Chris Angelico]

On Sat, Feb 15, 2014 at 1:34 PM, Rustom Mody  wrote:
> At what level can you explain the following?
>
 x = 1234567 * 1234567
 x
> 1524155677489L

Well, for a start, I'd use Python 3, so there's no need to explain why
some numbers have an L after them :)

> As against
>
 x = 2*3
 6 is x
> True
>
> "Interning" you will say.
> Is interning a simple matter for example at the level of questioning of the 
> OP?

When it's utterly impossible for it to matter in any way, Python is
allowed to reuse objects.

I think that's simple enough to explain. There's nothing you can do to
distinguish one 6 from another, so Python's allowed to have them the
same.

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

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

[Nick Timkovich]

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!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Rustom Mody]

On Saturday, February 15, 2014 8:12:14 AM UTC+5:30, Chris Angelico wrote:
> On Sat, Feb 15, 2014 at 1:34 PM, Rustom Mody wrote:
> > At what level can you explain the following?
>  x = 1234567 * 1234567
>  x
> > 1524155677489L

> Well, for a start, I'd use Python 3, so there's no need to explain why
> some numbers have an L after them :)

Nice point!
And only sharpens what I am saying -- python 3 is probably more confusing than
2 wrt object identity

> > As against
>  x = 2*3
>  6 is x
> > True
> > "Interning" you will say.
> > Is interning a simple matter for example at the level of questioning of the 
> > OP?

> When it's utterly impossible for it to matter in any way, Python is
> allowed to reuse objects.

> I think that's simple enough to explain. There's nothing you can do to
> distinguish one 6 from another, so Python's allowed to have them the
> same.

Simple??

>>> x=1234
>>> y=1234
>>> x is y
False
>>> 1234 is 1234
True
>>> x=123
>>> y=123
>>> x is y
True

-
"utterly impossible to matter"...
"nothing you can do to distinguish one 6 from another"

All depend on doing one of these 3 for dealing with object identity
1. Circular definition
2. Delve into implementation
3. Wildly wave the hands

As a teacher Ive done more than my fair share of all especially 3 but if
you have a 4th option Id be interested to know!

Philosophically"to be" called the copula is such a knotty problem that there is 
an entire movement to create a version of English without any form of 
"is,are,be" etc

http://en.wikipedia.org/wiki/E-Prime
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Roy Smith]

In article ,
 Nick Timkovich  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

Question on using FP numbers in python 2

[Gene Heskett]

Greetings;

Is there something I can search for and fix in some python code that is 
giving me bogus answers that get good only when there is a valid digit to 
the left of the decimal point?

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: Generator using item[n-1] + item[n] memory

[Nick Timkovich]

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

> In article ,
>  Nick Timkovich  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
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Chris Angelico]

On Sat, Feb 15, 2014 at 2:14 PM, Rustom Mody  wrote:
> On Saturday, February 15, 2014 8:12:14 AM UTC+5:30, Chris Angelico wrote:
>> Well, for a start, I'd use Python 3, so there's no need to explain why
>> some numbers have an L after them :)
>
> Nice point!
> And only sharpens what I am saying -- python 3 is probably more confusing than
> 2 wrt object identity

How so? Py3 eliminates an unnecessary difference:

>>> 1L == 1
True
>>> 1L is 1
False

In Py3, this can't happen, because there simply is no distinction.

(That said, the Py3 unification does mean that small integers pay the
performance cost of long integers. I've mentioned before that it may
be worth having an "under the covers" optimization whereby small
integers are stored in a machine word - but this should be utterly
invisible to the user. As far as the programmer's concerned, an int is
an int is an int.)

>> When it's utterly impossible for it to matter in any way, Python is
>> allowed to reuse objects.
>>
>> I think that's simple enough to explain. There's nothing you can do to
>> distinguish one 6 from another, so Python's allowed to have them the
>> same.
>
> Simple??
>
 x=1234
 y=1234
 x is y
> False
 1234 is 1234
> True
 x=123
 y=123
 x is y
> True

In all three cases, Python is allowed to use separate objects. Nothing
forces them to be shared. But in all three cases, there's no way you
could distinguish one from another, so Python's allowed to reuse the
same object.

> "utterly impossible to matter"...
> "nothing you can do to distinguish one 6 from another"
>
> All depend on doing one of these 3 for dealing with object identity
> 1. Circular definition
> 2. Delve into implementation
> 3. Wildly wave the hands

How do you distinguish between any other identical things? Once you've
decided that they're equal, somehow you need to separate identity from
value. I could have three six-sided dice, all made from the same
mould, and yet each one is a separate object. If I hold all three in
my hand and toss them onto the table, can I recognize which one is
which? No, they're identical. Are they distinct objects? Yes.

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

Re: Question on using FP numbers in python 2

[Chris Angelico]

On Sat, Feb 15, 2014 at 2:25 PM, Gene Heskett  wrote:
> Is there something I can search for and fix in some python code that is
> giving me bogus answers that get good only when there is a valid digit to
> the left of the decimal point?
>

Interesting. I'd look for anything that mixes very large and very
small numbers, first off. Otherwise, just follow the standard
debugging technique of stripping code out of your program and seeing
if the problem's still there. Continue until you have the barest
minimum, and hope hope hope that it's a Bohr bug and not a Heisenbug!

If it really is a floating point issue, you probably don't have to
worry about, for instance, a segfault that happens when a garbage
collection run occurs between this statement and that statement...
yes, I've had to deal with that sort of thing! (Turned out to be a
refcount bug in C code. When the gc ran, something got disposed of
that shouldn't have.)

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

Re: Explanation of list reference

[Ben Finney]

Marko Rauhamaa  writes:

> Chris Angelico :
> > Distinguishing "small values" from "big values" leads to the obvious
> > question: Which is which? And why doesn't this work?
>
> This is related to the recent id(string) question on this forum.
>
> 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.

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

The Python implementation is free to behave unpredictably for the state
of object identity. It may have some objects that conceptually may be
different (i.e. you'd predict the ‘is’ operation would return False)
actually be the same object (i.e. the ‘is’ operation would return True).

Exactly the same case may behave differently in this regard on other
Python implementations, or different versions of the same Python
implementation, or even exactly the same version of the Python
implementation under different circumstances.

The management of object identity is an implementation detail, not to be
relied on in your Python code. So, if your teaching method depends on
general principles for predicting object identity, you're already
losing.

> Explaining Python's memory model at some level is necessary right off
> the bat. However, it is far from easy to understand.

The use of the term “variable”, and all the implications that has for
“variables contain values” etc., is IMO too confusing, and its use in
the Python documentation is not helping this.

Rather, I recommend that people teaching Python should avoid the term
“variable” entirely, and use the term “reference” which much more
accurately implies Python's data model. An addressable item in a
container is a reference, as is a name. Assignment binds a reference to
a value. And so on.

This article by the Effbot corrects similar misconceptions
http://effbot.org/zone/python-objects.htm>, and is a valuable
approach to teaching the Python data model.

-- 
 \   “Theology is the effort to explain the unknowable in terms of |
  `\ the not worth knowing.” —Henry L. Mencken |
_o__)  |
Ben Finney

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

Re: Best practices to overcome python's dynamic data type nature

[flebber]

Here's a great resource 
http://www.anrdoezrs.net/click-7079286-11260198?url=http%3A%2F%2Fshop.oreilly.com%2Fproduct%2F0636920029533.do%3Fcmp%3Daf-code-book-product_cj_9781449367794_%7BPID%7D&cjsku=0636920029533

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

Re: Explanation of list reference

[Rustom Mody]

On Saturday, February 15, 2014 9:03:36 AM UTC+5:30, Chris Angelico wrote:
> On Sat, Feb 15, 2014 at 2:14 PM, Rustom Mody wrote:
> > On Saturday, February 15, 2014 8:12:14 AM UTC+5:30, Chris Angelico wrote:
> >> Well, for a start, I'd use Python 3, so there's no need to explain why
> >> some numbers have an L after them :)
> > Nice point!
> > And only sharpens what I am saying -- python 3 is probably more confusing 
> > than
> > 2 wrt object identity

> How so? Py3 eliminates an unnecessary difference:

> >>> 1L == 1
> True
> >>> 1L is 1
> False

> In Py3, this can't happen, because there simply is no distinction.

> (That said, the Py3 unification does mean that small integers pay the
> performance cost of long integers. I've mentioned before that it may
> be worth having an "under the covers" optimization whereby small
> integers are stored in a machine word - but this should be utterly
> invisible to the user. As far as the programmer's concerned, an int is
> an int is an int.)

> >> When it's utterly impossible for it to matter in any way, Python is
> >> allowed to reuse objects.
> >> I think that's simple enough to explain. There's nothing you can do to
> >> distinguish one 6 from another, so Python's allowed to have them the
> >> same.
> > Simple??
>  x=1234
>  y=1234
>  x is y
> > False
>  1234 is 1234
> > True
>  x=123
>  y=123
>  x is y
> > True

> In all three cases, Python is allowed to use separate objects. Nothing
> forces them to be shared. But in all three cases, there's no way you
> could distinguish one from another, so Python's allowed to reuse the
> same object.

> > "utterly impossible to matter"...
> > "nothing you can do to distinguish one 6 from another"
> > All depend on doing one of these 3 for dealing with object identity
> > 1. Circular definition
> > 2. Delve into implementation
> > 3. Wildly wave the hands

> How do you distinguish between any other identical things? Once you've
> decided that they're equal, somehow you need to separate identity from
> value.

Implicit circularity problem continues... See below

> I could have three six-sided dice, all made from the same
> mould, and yet each one is a separate object. If I hold all three in
> my hand and toss them onto the table, can I recognize which one is
> which? No, they're identical. Are they distinct objects? Yes.

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.
Then what happens to the same memory address on different computers?
If you say nothing on two different computers are identical then how do you
define the correctness of a serialization protocol?

And is 'different computer' even well-defined? Think of clusters, COWs NOWs,
and other beasties ending in the cloud...

IOW when we analogize 4-dim infinite space-time into the confines of
'a computer' weve bought bigger problems than we disposed off, because

- for space-time it is unreasonable to imagine a larger frame into which that is
embedded

- for computers that larger frame is a key part -- starting with the fact
that you and I are having a conversation right now

tl;dr Analogizing physical objects to computer 'objects' is a mistake
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question on using FP numbers in python 2

[Steven D'Aprano]

On Fri, 14 Feb 2014 22:25:59 -0500, Gene Heskett wrote:

> Greetings;
> 
> Is there something I can search for and fix in some python code that is
> giving me bogus answers that get good only when there is a valid digit
> to the left of the decimal point?

Er, yes? Anything which involves floating point maths?

Your question is to vague to really answer. You are basically saying "I'm 
doing some calculations [what sort of calculations?] with floats [how 
many floats? of what values?], and they're wrong [wrong in what way? how 
badly wrong?] unless there is a valid digit [which digits count as valid 
and which as invalid?] to the left of the decimal point in some number."

Can you extract the float calculations and show us, together with some 
sample data, expected result, and actual result?


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

I'm trying to do this code, can somebody help me

[pabloeruggeri]

1)Given the variables  x , y , and z , each associated with an int , write a 
fragment of code that assigns the smallest of these to min

this is what I have

def main():


 x = eval ( input ("dame el numero X"))
 y = eval ( input ("dame el numero Y"))
 z = eval ( input ("dame el numero Z"))
  
 if(x>y and z>y):
  min=y
  print(min)
 else:
  if(y>x and z>x):
min=x
print(min)
  else:
   min=z
   print(min)

main()

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

Re: Explanation of list reference

[Chris Angelico]

On Sat, Feb 15, 2014 at 3:24 PM, Rustom Mody  wrote:
>> I could have three six-sided dice, all made from the same
>> mould, and yet each one is a separate object. If I hold all three in
>> my hand and toss them onto the table, can I recognize which one is
>> which? No, they're identical. Are they distinct objects? Yes.
>
> 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.

Not once you roll them, which is why I specifically used dice. This
exact situation comes up in roleplaying games - suppose you want to
get a random number from 0 to 999 (or 1 to 1000, by declaring that a
result of 0 is interpreted as 1000). The most common way to do this is
to roll 10-sided dice for the digits; you can either roll one d10
three times, or three dice all at once. In the latter case, you
somehow need to pre-declare which one is the hundreds digit, which is
the tens, and which is the units, which means you need some way to
distinguish the three dice after you roll them (as you can't recognize
by position). This is why dice exist in a variety of colors [1].
Indistinguishable yet distinct dice... and it's actually possible to
merge all three into a single object (which is what happens when you
roll one three times instead of rolling three once), just as Python is
allowed to do.

By the way, if you get into quantum physics, you can't depend on three
dimensions of space and one of time to distinguish objects. You also
need spin. And I think you also need insanity, because you'll be given
it on arrival if you don't have enough.

ChrisA

[1] Well, that and to look cool. I don't know that any system other
than FATAL requires you to roll d1,000,000 on six dice, so three
colors would normally be sufficient. But it's fun to have the full
spectrum.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question on using FP numbers in python 2

[Grant Edwards]

On 2014-02-15, Gene Heskett  wrote:

> Is there something I can search for and fix in some python code that
> is giving me bogus answers that get good only when there is a valid
> digit to the left of the decimal point?

Yes.

Search for incorrectly written code and fix it.  I'd start part way
down in that one file, and then also look in that other file, but not
as far down.

At least he doesn't think he's using real numbers...

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

Re: Question on using FP numbers in python 2

[Gene Heskett]

On Friday 14 February 2014 23:37:53 Chris Angelico did opine:

> On Sat, Feb 15, 2014 at 2:25 PM, Gene Heskett  wrote:
> > Is there something I can search for and fix in some python code that
> > is giving me bogus answers that get good only when there is a valid
> > digit to the left of the decimal point?
> 
> Interesting. I'd look for anything that mixes very large and very
> small numbers, first off. Otherwise, just follow the standard
> debugging technique of stripping code out of your program and seeing
> if the problem's still there. Continue until you have the barest
> minimum, and hope hope hope that it's a Bohr bug and not a Heisenbug!
> 
> If it really is a floating point issue, you probably don't have to
> worry about, for instance, a segfault that happens when a garbage
> collection run occurs between this statement and that statement...
> yes, I've had to deal with that sort of thing! (Turned out to be a
> refcount bug in C code. When the gc ran, something got disposed of
> that shouldn't have.)
> 
> ChrisA

It is the top utility in this page of linuxcnc code generators:



I looked at it, just enough to understand I haven't learned a thing in 2 
years of lurking on this list.  I see Big John has a bug note, and its 
possible this might be related.  You can get it at the upper link, or there 
is a copy on my pages, under Genes-os9-stf/LCNC directory.

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: I'm trying to do this code, can somebody help me

[Chris Angelico]

On Sat, Feb 15, 2014 at 3:27 PM,   wrote:
> 1)Given the variables  x , y , and z , each associated with an int , write a 
> fragment of code that assigns the smallest of these to min

This is homework. Please be honest about it; we will help you to
learn, but we won't write your code for you.

> this is what I have
>
> def main():
>  x = eval ( input ("dame el numero X"))
>  y = eval ( input ("dame el numero Y"))
>  z = eval ( input ("dame el numero Z"))

Using eval is slow and dangerous; what you probably want here is simply int().

>  if(x>y and z>y):
>   min=y
>   print(min)

Oh, you're so close here :) The name "min" should be a clue. If you
type this into a Python-sensitive editor like IDLE, it might even be
highlighted in a different color.

>  else:
>   if(y>x and z>x):
> min=x
> print(min)
>   else:
>min=z
>print(min)
>
> main()

Okay. So why are you posting your code? Is it doing the wrong thing?
Is it throwing an exception? Is it sneaking out and kissing your
girlfriend? (I will never tolerate a program doing that, especially as
it would imply that I have a girlfriend.) Is it working perfectly but
you'd like to see it shorter? Are you hoping for a general code
review? Ask a question regarding the code.

Since you haven't asked anything else, I'll make a few stylistic
recommendations. Firstly, indenting by a single space is a bit too
compact; it's hard to see exactly how far in you are. I like to use
one tab for each indentation level; some prefer to use four spaces, or
eight spaces. Two spaces is usually considered too tight; more than
eight (or more than one tab) is extremely sparse; three, five, six,
and seven are just weird. Four or eight spaces, or exactly one tab,
would be the most common.

Also, putting your code inside main() and then immediately calling
main() doesn't help you much. If you want your module to be importable
from elsewhere, you'll need to check __name__, but I suspect you
haven't learned that yet. Otherwise, just put all your code at top
level and avoid the boiler-plate.

Instead of nesting 'if' inside 'else', you can merge the two into a
single 'elif', which makes good sense here.

What happens if two of your inputted numbers are equal?

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

Re: Question on using FP numbers in python 2

[Gene Heskett]

On Friday 14 February 2014 23:47:26 Steven D'Aprano did opine:

> On Fri, 14 Feb 2014 22:25:59 -0500, Gene Heskett wrote:
> > Greetings;
> > 
> > Is there something I can search for and fix in some python code that
> > is giving me bogus answers that get good only when there is a valid
> > digit to the left of the decimal point?
> 
> Er, yes? Anything which involves floating point maths?
> 
> Your question is to vague to really answer. You are basically saying
> "I'm doing some calculations [what sort of calculations?] with floats
> [how many floats? of what values?], and they're wrong [wrong in what
> way? how badly wrong?] unless there is a valid digit [which digits
> count as valid and which as invalid?] to the left of the decimal point
> in some number."
> 
> 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:



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.

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.  That would leave a big post of 
steel in the center, so I will have to drill it to perhaps a half an inch 
just to keep from pinching & breaking a $20 bit.  But that is a separate 
problem.

So, I  added a .2" offset to the hole diameter, making that entry 1.05".

Then I do get the spiral outward feed, but to make a hole 1.05" in 
diameter.

As for me fixing it, that 30+ kilobytes of python may as well be Navajo.

IOW, help please?

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 

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

Re: Explanation of list reference

[Ian Kelly]

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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question on using FP numbers in python 2

[Chris Angelico]

On Sat, Feb 15, 2014 at 4:07 PM, Gene Heskett  wrote:
> Not extract, but let you get & look at the code, its the top entry on this
> page:
>
>  Code_Generators#Counterbore_Software>

Interesting. At the top of the file, it says GPL3 or later; but then
it puts a requirement on making money off the software. I'm not sure
that's a good thing (what if someone lifts a small part of that code
out and into another GPL project?), and I'm not sure it's
legal/enforceable anyway.

The GUI creation code calls to mind the discussion we had a little
while ago about an alternative way to create a GUI in Python.
Especially compare the GTK2Table() function that I posited - I'm sure
it wouldn't be hard to make a Python (and Tkinter) equivalent.
Massively complicated code for laying out a grid/table.

But check out these comments:

def GeneratePath(self):
 # If ToolDiameter > HoleDiameter then Complain
 # If ToolDiameter == HoleDiameter then Plunge to HoleDepth
 # If (ToolDiameter*1.25) <= HoleDiameter then Plunge to each
Level and Spiral out to HoleDiameter
# If (ToolDiameter*1.25) > HoleDiameter then Spiral to each
Level and Spiral out to HoleDiameter

(Also, o! The GeneratePath function is indented with a mixture of
spaces and tabs. Most of it is indented "four spaces and then a tab",
but some lines use other mixtures. Ow ow ow!)

Does all that make sense, and are you seeing those boundaries
correctly? I strongly suspect you're not seeing a floating-point
error, but a deliberate piece of code and maybe some other form of
bug. I very much doubt the boundary is anything to do with going over
1" in diameter; the numbers you're working with here are easily within
Python's capability (you get roughly 15 decimal digits of accuracy
with the default float type).

I'm afraid I can't really help more, as I don't speak CNC. But have a
look at GeneratePath(); it does have comments, and for all of being
two hundred lines of code, it's reasonably segmented into sections.
Manually step through it, see where it's going wrong. Standard Python
debugging, nothing to do with floats AFAICT.

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

Re: Explanation of list reference

[Chris Angelico]

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, simply because it's not
possible for it to be otherwise. However, the converse isn't
necessarily true; two objects may have the same identity while being
at different addresses (or, more likely, one object may occupy
different memory addresses over time, if the gc moves it around). But
since memory addresses are completely inaccessible to Python code, we
can't say whether two objects have the same address.

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

Re: Explanation of list reference

[Steven D'Aprano]

On Fri, 14 Feb 2014 12:31:56 -0600, Ryan Gonzalez wrote:

> On 02/14/2014 12:08 PM, dave em wrote:
>> Hello,
>>
>> Background:  My twelve y/o son and I are still working our way through
>> Invent Your Own Computer Games with Python, 2nd Edition. (We finished
>> the Khan Academy Javascript Tutorials is the extent of our experience)
>>
>> 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.
>>
>> I tried the to explain as best I can remember is that a variable is
>> assigned to a specific memory location with a value inside of it. 
>> Therefore, the variable is kind of self contained and if you change the
>> variable, you change the value in that specific memory location.
>>
>> However, when a variable contains a list reference, the memory location
>> of the variable points to a separate memory location that stores the
>> list.  It is also possible to have multiple variable that point to the
>> memory location of the list reference.  And all of those variable can
>> act upon the list reference.
>>
>> Question:  Is my explanation correct?  If not please set me straight :)
>>
>> And does anyone have an easier to digest explanation?
>>
>> Thanks in advance,
>> Dave
> 
> You've got it backwards. In Python, /everything/ is a reference.

What's a reference?

How is the value 23 a reference? What is it a reference to?


> The
> variable is just a "pointer" to the actual value. When you change a
> variable, you're just changing the memory location it points to.

What do memory locations have to do with Python code? When I execute 
Python code in my head, perhaps using a pencil and paper, or build a 
quantum computer (or analog clockwork device) to execute Python code, 
where are the memory locations?

I think you are conflating the *implementation* of Python's virtual 
machine in a C-like language written for a digital computer with the 
*defined behaviour* of the Python virtual machine. If you think about the 
Python execution model, there is almost nothing about memory locations in 
it. The only exception I can think of is the id() function, which uses 
the memory address of the object as the ID, and even that is *explicitly* 
described as an implementation detail and not a language feature. And in 
fact Jython and IronPython assign IDs to objects consecutively from 1, 
and PyPy has to go through heroic and complicated measures to ensure that 
objects have the same ID at all times.

Thinking about the implementation of Python as written for certain types 
of digital computing devices can be useful, but we must be very careful 
to avoid mixing up details at the underlying C (or Java, or Haskell, or 
Lisp, or ...) layer with questions about the Python execution model.

As soon as you mention "pointers", you're in trouble, because Python has 
no pointers. There is nothing in Python that will give you a pointer to 
an object, or dereference a pointer to get the object at the other end. 
Pointers in the sense of C or Pascal pointers to memory addresses simply 
don't have any existence in Python. Python compilers can even be written 
in languages like Java that don't have pointers. The fact that the C 
implementation of Python uses pointers internally is not very 
interesting, any more than the fact that a Python implementation running 
on a Turing Machine would use a pencil and eraser that can draw marks on 
a very long paper tape.


> Strings, ints, tuples, and floats behave differently because they're
> /immutable/. That means that they CANNOT modify themselves. That's why
> all of the string methods return a new string. It also means that, when
> you pass one two a function, a /copy/ of it is made and passed instead.

Yes, strings etc. are immutable, but no, they are not copied when you 
pass them to a function. We can be sure of this for two reasons:

(1) We can check the id() of the string from the inside and the outside 
of the function, and see that they are the same; and 

(2) We can create a HUGE string, hundreds of megabytes, and pass it to 
dozens of functions, and see no performance slowdown. It might take a 
second or five to build the initial string, and microseconds or less to 
pass it to function after function after function.


> So, back to the original subject. Everything is a reference. 

To really under stand Python's behaviour, we need to see that there are 
two kinds of entities, names and values. Or another way to put it, 
references and objects. Or another way to put it, there's actually only 
one kind of thing in Python, that is, everything in Python is an object, 
but Python *code* can refer to objects indirectly by names and other 
references. Names aren't "things", but the things that names refer to are 
things.

Objects have a clear definition in the Python world: they are an entity 
that has a type (e.g. a string), a set of behaviour (methods), and a 
value ("

Re: Question on using FP numbers in python 2

[Gene Heskett]

On Saturday 15 February 2014 00:43:53 Chris Angelico did opine:

> On Sat, Feb 15, 2014 at 4:07 PM, Gene Heskett  wrote:
> > Not extract, but let you get & look at the code, its the top entry on
> > this page:
> > 
> >  > Code_Generators#Counterbore_Software>
> 
> Interesting. At the top of the file, it says GPL3 or later; but then
> it puts a requirement on making money off the software. I'm not sure
> that's a good thing (what if someone lifts a small part of that code
> out and into another GPL project?), and I'm not sure it's
> legal/enforceable anyway.
> 
> The GUI creation code calls to mind the discussion we had a little
> while ago about an alternative way to create a GUI in Python.
> Especially compare the GTK2Table() function that I posited - I'm sure
> it wouldn't be hard to make a Python (and Tkinter) equivalent.
> Massively complicated code for laying out a grid/table.
> 
> But check out these comments:
> 
> def GeneratePath(self):
>  # If ToolDiameter > HoleDiameter then Complain
>  # If ToolDiameter == HoleDiameter then Plunge to HoleDepth
>  # If (ToolDiameter*1.25) <= HoleDiameter then Plunge to each
> Level and Spiral out to HoleDiameter
> # If (ToolDiameter*1.25) > HoleDiameter then Spiral to each
> Level and Spiral out to HoleDiameter
> 
> (Also, o! The GeneratePath function is indented with a mixture of
> spaces and tabs. Most of it is indented "four spaces and then a tab",
> but some lines use other mixtures. Ow ow ow!)
> 
> Does all that make sense, and are you seeing those boundaries
> correctly? I strongly suspect you're not seeing a floating-point
> error, but a deliberate piece of code and maybe some other form of
> bug. I very much doubt the boundary is anything to do with going over
> 1" in diameter; the numbers you're working with here are easily within
> Python's capability (you get roughly 15 decimal digits of accuracy
> with the default float type).
> 
> I'm afraid I can't really help more, as I don't speak CNC.

Actually, the output is RS-274-D, originally from NIST.  But it has 
developed some pretty distinct "accents" in the 20 some years its been in 
the wild.  The NIST version was, shall we say, quite incomplete but a lot 
of the stuff shoved in to scratch this or that itch is often vaguely 
incompatible with the next vendors version of that particular function.

> But have a
> look at GeneratePath(); it does have comments, and for all of being
> two hundred lines of code, it's reasonably segmented into sections.
> Manually step through it, see where it's going wrong. Standard Python
> debugging, nothing to do with floats AFAICT.
> 
> ChrisA

I'll do that when next I have both eyes open at the same time. That is 
usually about halfway thru the third cuppa. :)

Thanks Chris A.

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

[Chris Angelico]

On Sat, Feb 15, 2014 at 4:36 PM, Steven D'Aprano
 wrote:
> References can be names like `mystring`, or list items `mylist[0]`, or
> items in mappings `mydict["key"]`, or attributes `myobject.attr`, or even
> expressions `x+y*(1-z)`.

I agree with most of what you've said, but I'm not sure I like that
last bit. The expression evaluates to an object, yes, but it's not
itself a reference... is it? It has references to x, y, 1, and z, but
it's not itself a reference to anything. If you take a reference and
assign it to a name, and take that same reference and assign it to
another name, I would expect those two names to now refer to the same
object:

>>> lst = [1000, 2000, 3000]
>>> x = lst[1]
>>> y = lst[1]
>>> x is y
True

But with expressions, it's not so, and new objects may be created. The
expression isn't a reference to its result, but it can yield an
object, which it (naturally) does by reference.

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

Re: Question on using FP numbers in python 2

[Chris Angelico]

On Sat, Feb 15, 2014 at 4:50 PM, Gene Heskett  wrote:
>> I'm afraid I can't really help more, as I don't speak CNC.
>
> Actually, the output is RS-274-D, originally from NIST.  But it has
> developed some pretty distinct "accents" in the 20 some years its been in
> the wild.  The NIST version was, shall we say, quite incomplete but a lot
> of the stuff shoved in to scratch this or that itch is often vaguely
> incompatible with the next vendors version of that particular function.

Ehh, I don't speak that either, but now I feel like a guy who's told
"Polly voo Fronsay?" and says that he don't speak no Eyetalon. :)

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

Re: Explanation of list reference

[Rustom Mody]

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


On Saturday, February 15, 2014 11:01:35 AM UTC+5:30, 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, simply because it's not
> possible for it to be otherwise. However, the converse isn't
> necessarily true; two objects may have the same identity while being
> at different addresses (or, more likely, one object may occupy
> different memory addresses over time, if the gc moves it around). But
> since memory addresses are completely inaccessible to Python code, we
> can't say whether two objects have the same address.

Nice point!
I earlier talked of the macro problems of identity, viz across machines.
You are bringing up a more 'micro' angle, viz gc.
An even more micro (or lower level) example would be the mismatch between
physical and virtual memory, dram and cache etc etc.
Is memory such a clear concept?

Just different examples to show that object identity is anything but
straightforward
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Steven D'Aprano]

On Fri, 14 Feb 2014 19:00:36 -0500, Ned Batchelder wrote:

> On 2/14/14 4:43 PM, Marko Rauhamaa wrote:
>> Chris Angelico:
>>
>>> >be careful of simplifications that will cause problems down the line.
>> Sure. Let it be said, though, that sometimes you learn through
>> inaccuracies, a technique used intentionally by Knuth's TeXBook, for
>> example. In fact, you get through highschool mathematics successfully
>> without knowing what numbers and variables actually are.
>>
>>
> Yes, sometimes for teaching reasons, you have to over-simplify or even
> introduce artificial constructs.  I'd recommend acknowledging them as
> such.

The mathematician Ian Stewart and biologist Jack Cohen call these "lies 
for children". They don't mean it as a pejorative. In fact, calling them 
"lies for children" is itself a lie for children :-)

(Lies for children are not lies, nor are they just for children.)


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

Re: Explanation of list reference

[Steven D'Aprano]

On Fri, 14 Feb 2014 17:55:52 -0800, Rustom Mody wrote:

> My own preference: No is operator; only id when we deliberately need to
> poke into the implementation.
> 
> Of course I am in a miniscule minority I guess on that :-)

If I have understood you, I think that's a poor way of looking at it. We 
can have an `is` operator to determine whether or not two objects are the 
same, without having a concept of object IDs; but you can't have a 
concept of object IDs without having distinct objects. `is` is more 
fundamental than id().

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.


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

Re: Explanation of list reference

[Ben Finney]

Rustom Mody  writes:

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

How about: Every object has an identity, which is unique among all
concurrently-existing objects. The ‘is’ operator queries whether two
references are referring to objects with the same identity, which
implies they are actually referring to the same object.

Is that sufficient?

> I earlier talked of the macro problems of identity, viz across
> machines.

Python doesn't make any promises about object identity beyond the
current run-time of a single instance of a program. So while the problem
you describe is interesting, it isn't relevant when talking about Python
object identity.

-- 
 \“When in doubt tell the truth. It will confound your enemies |
  `\   and astound your friends.” —Mark Twain, _Following the Equator_ |
_o__)  |
Ben Finney

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

Re: Explanation of list reference

[Chris Angelico]

On Sat, Feb 15, 2014 at 5:07 PM, Rustom Mody  wrote:
> Nice point!
> I earlier talked of the macro problems of identity, viz across machines.
> You are bringing up a more 'micro' angle, viz gc.
> An even more micro (or lower level) example would be the mismatch between
> physical and virtual memory, dram and cache etc etc.
> Is memory such a clear concept?
>
> Just different examples to show that object identity is anything but
> straightforward

Not really; they just show that object identity is nothing to do with
memory location. An object is itself, and is not anything else, and
neither of those truisms has anything to do with memory. I could
implement Python using a pencil and paper, using physical pieces of
string to create references; if a gust of wind blows all the paper
around, it won't change anything. (Though it might be a problem if I
have any weak references...) You could walk up to me and look at my
pieces of paper, and you'll know if two strings are linking to the
same paper; it's obvious that that paper is the same thing as itself.

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

Re: Explanation of list reference

[Rustom Mody]

On Saturday, February 15, 2014 11:45:00 AM UTC+5:30, Steven D'Aprano wrote:
> On Fri, 14 Feb 2014 17:55:52 -0800, Rustom Mody wrote:

> > My own preference: No is operator; only id when we deliberately need to
> > poke into the implementation.
> > Of course I am in a miniscule minority I guess on that :-)

> If I have understood you, I think that's a poor way of looking at it. We 
> can have an `is` operator to determine whether or not two objects are the 
> same, without having a concept of object IDs; but you can't have a 
> concept of object IDs without having distinct objects. `is` is more 
> fundamental than id().


Pick is or id. Matters little
To define either you need the notion of 'same'

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

With humans like Chris' dice the notion of 'same' is unexceptionable
[well sci-fi, teleportation etc aside :-) ]

To define is or id or same you need to
1 use machine details
or
2 do mathematics
or
3 wave our hands -- Dont we all know that same is same? 

My bet is that python's id/is cannot be defined with 2 so we use a 
combo of 1 and 3
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of list reference

[Rustom Mody]

On Saturday, February 15, 2014 11:49:38 AM UTC+5:30, Ben Finney wrote:
> Rustom Mody  writes:

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

> How about: Every object has an identity, which is unique among all
> concurrently-existing objects. The 'is' operator queries whether two
> references are referring to objects with the same identity, which
> implies they are actually referring to the same object.

> Is that sufficient?

Are you explaining or defining identity?

As an explanation its ok though a bit tautologous
As a definition its circular
[Just for context remember the OP -- a noob father-son duo confused by 
python's memory model]

> > I earlier talked of the macro problems of identity, viz across
> > machines.

> Python doesn't make any promises about object identity beyond the
> current run-time of a single instance of a program. So while the problem
> you describe is interesting, it isn't relevant when talking about Python
> object identity.

Hard as a nail the problem persists -- Non-promise of identity implies we 
understand it!!
> -- 
>  \"When in doubt tell the truth. It will confound your enemies |
>   `\   and astound your friends." --Mark Twain, _Following the Equator_ |
> _o__)  |
> Ben Finney

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

Re: Explanation of list reference

[Steven D'Aprano]

On Fri, 14 Feb 2014 20:24:20 -0800, 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.

That simply is not correct. 

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

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


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

Not quite. We say that two objects are identical (that is, that they 
actually are the same object) if they exist simultaneously, in the same 
process, and have the same ID. Normally we don't bother to say that they 
must be in the same process, as that is implied by our understanding of 
how computers normally work.

In fact, even the above is a simplification, since processes may share 
certain objects. This is why Python prohibits Ruby-style monkey-patching 
of built-in types. If we could add or remove methods from (say) lists, 
that could affect more than one Python process.

But ignoring complications like that, we can say that for a wide range of 
implementations, the condition "two objects exist at the same time and 
have the same ID" is equivalent to saying that they exist at the same 
time with the same memory address.


> Then what happens to the same memory address on different computers? If
> you say nothing on two different computers are identical then how do you
> define the correctness of a serialization protocol?

I would not expect that the None object running on my computer is the 
same None object running on another computer. None is a singleton *within 
a single running process*, not over the entire universe of Python virtual 
machines.


> And is 'different computer' even well-defined? Think of clusters, COWs
> NOWs, and other beasties ending in the cloud...

But for all of these things, we can create the abstraction of "a single 
process running at a single moment". True, observers in orbit around a 
black hole a thousand light-years away will disagree about that single 
moment, but we're not talking to them and don't care what they think.


> IOW when we analogize 4-dim infinite space-time into the confines of 'a
> computer' weve bought bigger problems than we disposed off, because
> 
> - for space-time it is unreasonable to imagine a larger frame into which
> that is embedded
> 
> - for computers that larger frame is a key part -- starting with the
> fact that you and I are having a conversation right now
> 
> tl;dr Analogizing physical objects to computer 'objects' is a mistake

Over-philosophising abstractions without the sanity check of what happens 
in real life is an even bigger mistake.

You may or may not choose to lie awake at night obsessing whether 
changing a tyre on your car makes it a different car (see the paradox of 
the Ax of my Grandfather), but the rest of us are too busy actually 
programming to care about such edge cases. They make good discussions for 
a philosophy class, but 99.999% of the time, the abstraction of computer 
objects being like physical objects is a good one.

If you want to demonstrate the fact that this abstraction sometimes 
leaks, you don't need to concern yourself with cloud computing, shared 
process memory space, or any such thing. You just need to recognise that 
objects can contain themselves:

py> L = []
py> L.append(L)
py> L in L
True


Of course, if you are a fan of the Doctor Who television show, you won't 
be concerned by this. If the TARDIS can materialise inside itself, then 
there isn't any problem with lists containing themselves either.



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

Re: Explanation of list reference

[Steven D'Aprano]

On Sat, 15 Feb 2014 17:07:17 +1100, Chris Angelico wrote:

> On Sat, Feb 15, 2014 at 4:36 PM, Steven D'Aprano
>  wrote:
>> References can be names like `mystring`, or list items `mylist[0]`, or
>> items in mappings `mydict["key"]`, or attributes `myobject.attr`, or
>> even expressions `x+y*(1-z)`.
> 
> I agree with most of what you've said, but I'm not sure I like that last
> bit. The expression evaluates to an object, yes, but it's not itself a
> reference... is it? 

[snip discussion]

You may be right. I will have to think about it a little more. Or a lot 
more. Ah wait, I got it: I chose a bad example for the expression. Here 
is a better one:

myobj.alist[12]["some key"].attribute


I think it is fair to call that both an expression and a reference.



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

Re: Explanation of list reference

[Steven D'Aprano]

On Sat, 15 Feb 2014 15:37:20 +1100, Chris Angelico wrote:

[...]
> This is why dice exist in a variety of colors [1]. Indistinguishable yet
> distinct dice...

Since they have different colours, they can be distinguished and aren't 
indistinguishable.

One might also distinguish three dice by position in space ("the die 
closest to the wall counts as the HUNDREDS digit, the one closest to me 
counts as the TENS digit, and the one closest to you counts as the UNITS 
digit") or by space ("roll this die first for the HUNDREDS, then roll 
that one for TENS, then this third one for UNITS"). Or scent, or texture, 
or the typeface used for the numbers.



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

Re: Explanation of list reference

[Chris Angelico]

On Sat, Feb 15, 2014 at 5:48 PM, Steven D'Aprano
 wrote:
> On Sat, 15 Feb 2014 17:07:17 +1100, Chris Angelico wrote:
>
>> On Sat, Feb 15, 2014 at 4:36 PM, Steven D'Aprano
>>  wrote:
>>> References can be names like `mystring`, or list items `mylist[0]`, or
>>> items in mappings `mydict["key"]`, or attributes `myobject.attr`, or
>>> even expressions `x+y*(1-z)`.
>>
>> I agree with most of what you've said, but I'm not sure I like that last
>> bit. The expression evaluates to an object, yes, but it's not itself a
>> reference... is it?
>
> You may be right. I will have to think about it a little more. Or a lot
> more. Ah wait, I got it: I chose a bad example for the expression. Here
> is a better one:
>
> myobj.alist[12]["some key"].attribute
>
> I think it is fair to call that both an expression and a reference.

Sure. If it helps, the part that's a reference is the ".attribute" at
the end; the rest is an expression which determines what object's
attribute you're looking at. Same with the earlier parts; the [12] is
a form of reference (albeit one that requires another object). But
yes, this is an expression, and it evaluates to a reference.

In any case, your main point is still valid: each of those forms will
yield a reference to something. (Aside from the possibility of raising
KeyError. As an expression, it has to yield a reference to an object.)

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