Re: A question about import

2024-02-16 Thread Cameron Simpson via Python-list

On 16Feb2024 20:32, MRAB  wrote:

On 2024-02-16 20:07, Gabor Urban via Python-list wrote:

I need something about modules to be clarified.

Suppose I have written a module eg: ModuleA which imports an other
module, let us say the datetime.

If I import ModuleA in a script, will be datetime imported automatically?


Yes. When a module is imported it can import other modules.


But note that `datetime` does not magicly get put in the script's 
namespace.


Module A:

import datetime

Script:

import A

In the code in module A the name datetime is known and can be used.

In the code in the script the name A is known and can be used. Importing 
A does not magicly set the name datetime in the script's namespace - 
imagine the the pollution!


You _can_ access it as A.datetime because it is in the A module's 
namespace. But really if you just wanted datetime for direct use in the 
script you would import it there too:


import datetime
import A

Note that the datetime module is only actually loaded once. The import 
binds the name into your local namespace like any other variable.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list


Re: A question about import

2024-02-16 Thread MRAB via Python-list

On 2024-02-16 20:07, Gabor Urban via Python-list wrote:

Hi guys,

I need something about modules to be clarified.

Suppose I have written a module eg: ModuleA which imports an other
module, let us say the datetime.

If I import ModuleA in a script, will be datetime imported automatically?


Yes. When a module is imported it can import other modules.
--
https://mail.python.org/mailman/listinfo/python-list


A question about import

2024-02-16 Thread Gabor Urban via Python-list
Hi guys,

I need something about modules to be clarified.

Suppose I have written a module eg: ModuleA which imports an other
module, let us say the datetime.

If I import ModuleA in a script, will be datetime imported automatically?

Thanks in advance,

--
Urbán Gábor

Linux is like a wigwam: no Gates, no Windows and an Apache inside.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: New to python - Just a question

2020-07-03 Thread Tim Chase
On 2020-07-03 10:09, Daley Okuwa via Python-list wrote:
> Write an algorithm (choose the language you prefer) that given a
> character string, for instance {‘c’,’a’,’i’,’o’,’p’,’a’}, will
> print out the list of characters appearing at least 2 times. In
> this specific example, it would return {‘a’}. Afterwards, comment
> out the cost in terms of space and time.

What have you tried already?  Where are you having trouble?

Have you written a program that accepts a character string?  Is the
string coming in as a command-line argument or on standard-input?

The example string you give looks more like some sort of
serialization format rather than a string.

Are you having difficulty counting the letters?  Python provides a
"dict()" type that would work well.

Should uppercase letters be counted the same as lowercase letters?
I.e., should "Pop" report that there are 2 "p"s?

If you've counted the duplicates, 

Have you studied space/time complexity and do you know how to
evaluate code for these characteristics?  The problem should be
solvable in roughly O(k) per word.

> Write a bash/python script that takes a directory as an argument
> and output the total lines of code in *.cpp files recursively.

Again, what have you tried?

Have you been able to iterated over a directory? See find(1) or ls(1)
or grep(1) in a shell-script or os.listdir()/os.scandir()/glob.glob()
in Python

Have you been able to open those files?

Can you iterate over the lines in each file?

Do you need to filter out any lines (such as blank lines or comments)?

If you provide what you've tried, folks here on the list are pretty
happy to help.  But most won't do your homework for you.

-tkc




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


Re: New to python - Just a question

2020-07-03 Thread Rhodri James

On 03/07/2020 11:09, Daley Okuwa via Python-list wrote:


Please can someone help

Write an algorithm (choose the language you prefer) that given a character 
string, for instance {‘c’,’a’,’i’,’o’,’p’,’a’}, will print out the list of 
characters appearing at least 2 times. In this specific example, it would 
return {‘a’}. Afterwards, comment out the cost in terms of space and time.


The first thing to do with any problem is to break it down into bits. 
In the case of Python, writing them out as "pseudo-code" instructions 
often helps.  In this case you have:


Set up something to count letters with
For each letter in the string:
If we haven't seen this letter before:
Set the counter for the letter to 1
Else:
Add 1 to the counter for the letter

For each counter:
If the count is 2 or more:
Print the letter

Now there are a lot of possible ways to write that, but they mostly come 
down to deciding what data structure to use to count letters with.  Have 
a browse through a tutorial (or the standard library if you are feeling 
adventurous) and see what you think might work, then try it.



Write a bash/python script that takes a directory as an argument and output the 
total lines of code in *.cpp files recursively.


In bash, what existing commands count things?  If you don't know, how 
might you find out?  Then you have to figure out how to do that for each 
*.cpp file in a directory, and add the totals together.


In Python, you can read a file one line at a time, so how to count the 
number of lines in a file should be pretty obvious.  Figuring out how to 
do that for every *.cpp file in a directory will involve looking through 
the standard library, or getting a bash script to do it for you :-)


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list


Re: New to python - Just a question

2020-07-03 Thread David Lowry-Duda
Hello!

> Please can someone help
> 
> Write an algorithm (choose the language you prefer) that given a 
> character string, for instance {‘c’,’a’,’i’,’o’,’p’,’a’}, will print 
> out the list of characters appearing at least 2 times. In this 
> specific example, it would return {‘a’}. Afterwards, comment out the 
> cost in terms of space and time.
> 
> Write a bash/python script that takes a directory as an argument and 
> output the total lines of code in *.cpp files recursively.

These are both pretty classical problems. But the way you've presented 
them sounds a bit like a "do my homework for me" style question.

Do you know any python? I recommend that you consider following a book 
or tutorial to get through some of the basics. I like to recommend Think 
Python (available for free from the author).

If you have particular questions that come up while you're trying to 
write a solution, I think more people would be more inclined to help.

Good luck! - DLD

-- 
David Lowry-Duda  
-- 
https://mail.python.org/mailman/listinfo/python-list


New to python - Just a question

2020-07-03 Thread Daley Okuwa via Python-list

Please can someone help

Write an algorithm (choose the language you prefer) that given a character 
string, for instance {‘c’,’a’,’i’,’o’,’p’,’a’}, will print out the list of 
characters appearing at least 2 times. In this specific example, it would 
return {‘a’}. Afterwards, comment out the cost in terms of space and time.


Write a bash/python script that takes a directory as an argument and output the 
total lines of code in *.cpp files recursively.


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


Re: A question related to the PYTHONPATH

2018-03-26 Thread oyono
Le mardi 27 mars 2018 07:42:57 UTC+2, dieter a écrit :
> oyono  writes:
> > ...
> > I was thinking, maybe it could have been done this way to enforce not 
> > running module files that are supposed to be bundled into packages as 
> > "independant" python scripts...Therefore, running "python script.py" should 
> > be reserved to effectively independant python scripts that do not import 
> > from a user-created package or module.
> 
> When you run "python 

Re: A question related to the PYTHONPATH

2018-03-26 Thread dieter
oyono  writes:
> ...
> I was thinking, maybe it could have been done this way to enforce not running 
> module files that are supposed to be bundled into packages as "independant" 
> python scripts...Therefore, running "python script.py" should be reserved to 
> effectively independant python scripts that do not import from a user-created 
> package or module.

When you run "python 

Re: A question related to the PYTHONPATH

2018-03-26 Thread oyono
Le lundi 26 mars 2018 08:11:02 UTC+2, dieter a écrit :
> adrien oyono  writes:
> > I have recently read the documentation about how imports work on python,
> > and I was wondering why, when you execute a python file, the current
> > directory is not added by default to the PYTHONPATH ?
> 
> Maybe, to avoid surprises?
> 
> You can invoke a script from different positions in your file system.
> If PYTHONPATH would automatically get ".", the script's behaviour
> could depend on the position from where it is called.
> 
> Prepending "." to "PYTHONPATH" could have dramatic effects:
> assume your script uses module "xxx" and your current working
> directory accidentally has a "xxx.py"; then this "xxx.py" would
> be used and it may behave much differently from another one.
> 
> The problem is not so severe when "." is appended to "PYTHONPATH".
> Nevertheless, it likely is not a good idea to have script behaviour
> depending by default on the execution location.

Thank you Dieter.
I was thinking, maybe it could have been done this way to enforce not running 
module files that are supposed to be bundled into packages as "independant" 
python scripts...Therefore, running "python script.py" should be reserved to 
effectively independant python scripts that do not import from a user-created 
package or module.
I think I need to learn a little bit more about the python cli.
Many thanks again
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: A question related to the PYTHONPATH

2018-03-26 Thread Ian Kelly
On Mon, Mar 26, 2018 at 1:24 PM, Dan Stromberg  wrote:
> On Sun, Mar 25, 2018 at 11:10 PM, dieter  wrote:
>> adrien oyono  writes:
>>> I have recently read the documentation about how imports work on python,
>>> and I was wondering why, when you execute a python file, the current
>>> directory is not added by default to the PYTHONPATH ?
>>
>> Maybe, to avoid surprises?
>>
>> You can invoke a script from different positions in your file system.
>> If PYTHONPATH would automatically get ".", the script's behaviour
>> could depend on the position from where it is called.
>
> IINM, this also has security implications.

It's curious then that the -m invocation does add the current
directory, since it's normally used for running standard library
scripts like timeit or venv.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: A question related to the PYTHONPATH

2018-03-26 Thread Dan Stromberg
On Sun, Mar 25, 2018 at 11:10 PM, dieter  wrote:
> adrien oyono  writes:
>> I have recently read the documentation about how imports work on python,
>> and I was wondering why, when you execute a python file, the current
>> directory is not added by default to the PYTHONPATH ?
>
> Maybe, to avoid surprises?
>
> You can invoke a script from different positions in your file system.
> If PYTHONPATH would automatically get ".", the script's behaviour
> could depend on the position from where it is called.

IINM, this also has security implications.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: A question related to the PYTHONPATH

2018-03-25 Thread dieter
adrien oyono  writes:
> I have recently read the documentation about how imports work on python,
> and I was wondering why, when you execute a python file, the current
> directory is not added by default to the PYTHONPATH ?

Maybe, to avoid surprises?

You can invoke a script from different positions in your file system.
If PYTHONPATH would automatically get ".", the script's behaviour
could depend on the position from where it is called.

Prepending "." to "PYTHONPATH" could have dramatic effects:
assume your script uses module "xxx" and your current working
directory accidentally has a "xxx.py"; then this "xxx.py" would
be used and it may behave much differently from another one.

The problem is not so severe when "." is appended to "PYTHONPATH".
Nevertheless, it likely is not a good idea to have script behaviour
depending by default on the execution location.

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


A question related to the PYTHONPATH

2018-03-25 Thread adrien oyono
Hello everyone,

This is my first email to the python list, I'll try my best to do it well.

TL;DR

I have recently read the documentation about how imports work on python,
and I was wondering why, when you execute a python file, the current
directory is not added by default to the PYTHONPATH ?

Extended:

Let's assume we have this directory structure for a python package:

$ tree A
A
├── B1
│   ├── b1.py
│   ├── C1
│   │   ├── c1_1.py
│   │   ├── c1.py
│   │   └── __init__.py
│   └── __init__.py
├── B2
│   ├── b2.py
│   ├── C2
│   │   ├── c2.py
│   │   └── __init__.py
│   └── __init__.py
├── __init__.py
└── toto.py

4 directories, 11 files


with the file A/B2/C2/c2.py content being:

import sys
print(sys.path)

import A

from A.B2.b2 import PLOP
from A.B1.C1.c1 import TOTO

print(TOTO)


If I do, from the top level directory containing the package A:

$ python A/B2/C2/c2.py

I get an :

['/tmp/A/B2/C2', '/usr/lib/python2.7',
'/usr/lib/python2.7/plat-x86_64-linux-gnu',
'/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old',
'/usr/lib/python2.7/lib-dynload',
'/home/cris/.local/lib/python2.7/site-packages',
'/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages',
'/usr/lib/python2.7/dist-packages/PILcompat', '/usr/lib/python2.7/dist-
packages/gtk-2.0']
Traceback (most recent call last):
  File "A/B2/C2/c2.py", line 9, in 
import A
ImportError: No module named A

Which is normal according to the documentation of Python 2
(https://docs.python.org/2/tutorial/modules.html#the-module-search-path):

When a module named spam is imported, the interpreter first searches for a
> built-in module with that name. If not found, it then searches for a file
> named spam.py in a list of directories given by the variable sys.path
> . sys.path
>  is initialized from
> these locations:
>
>- the directory containing the input script (or the current directory).
>- PYTHONPATH
> (a
>list of directory names, with the same syntax as the shell variable
>PATH).
>- the installation-dependent default.
>
> After initialization, Python programs can modify sys.path
> . The directory
> containing the script being run is placed at the beginning of the search
> path, ahead of the standard library path. This means that scripts in that
> directory will be loaded instead of modules of the same name in the library
> directory. This is an error unless the replacement is intended. See section 
> Standard
> Modules
>  for
> more information.
>

Meanwhile when I do:

$ python -m A.B2.C2.c2

I get the script running correctly:

['', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu',
'/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old',
'/usr/lib/python2.7/lib-dynload',
'/home/cris/.local/lib/python2.7/site-packages',
'/usr/local/lib/python2.7/dist-packages',
'/usr/lib/python2.7/dist-packages',
'/usr/lib/python2.7/dist-packages/PILcompat',
'/usr/lib/python2.7/dist-packages/gtk-2.0']
42

An empty string is now pre-pended to the value of sys.path, which means, if
I correctly interpret the documentation of Python 3, that the current
directory is added to the PYTHONPATH (https://docs.python.org/3/
reference/import.html#path-entry-finders):

The current working directory – denoted by an empty string – is handled
> slightly differently from other entries on sys.path
> . First, if the
> current working directory is found to not exist, no value is stored in
> sys.path_importer_cache
> .
> Second, the value for the current working directory is looked up fresh for
> each module lookup. Third, the path used for sys.path_importer_cache
>  and
> returned by importlib.machinery.PathFinder.find_spec()
> 
> will be the actual current working directory and not the empty string.
>


What I am interested in is what is the reason of this difference ?


P.S.:

   - My english may suck a bit, please blame it on me being a French native
   speaker
   - Sorry if the colours hurt 😅


*Adrien OYONO*
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: A question on modification of a list via a function invocation

2017-09-08 Thread Steve D'Aprano
On Sat, 9 Sep 2017 10:34 am, Gregory Ewing wrote:

> Steve D'Aprano wrote:
>> The paradox of the axe is one illustration of the difficulty in defining "the
>> same" in full generality.
> 
> The axe situation doesn't arise in Python, because "same
> object" in Python is a concept that only applies to objects
> existing at the same time.

Indeed. That's why in an earlier post I mentioned that it wasn't relevant to the
question of `is`. I only mentioned it again because Rustom claimed to not
understand why I mentioned it. I mentioned it because I was *agreeing with him*
about the notion of sameness being hard to define vigorously in FULL
GENERALITY.

Which is irrelevant to the question of "same object". Either the paradoxes
of "sameness" don't apply to Python objects, in which the paradoxes don't
matter, or they apply to everything, in which case we're stuck with them and
shouldn't let them prevent us using the common sense meaning of "same object"
when discussing Python `is`.


> There's no way to even ask a question like "does a refer
> to the same object that b did a second ago", because
> the only way to test object identity is to use the
> 'is' operator, which takes two expressions evaluated
> at the same time.

I wouldn't quite go that far. We could, for example, record the ID, type, and
some representation of the object (repr? str?), and compare them to those of
the existing object. If any of them differ, then we know they aren't (weren't?)
the same object. If all three are the same, we cannot draw any conclusions.


"Is this list I have now identical to the tuple I had five minutes ago?"

"Obviously not, because lists aren't tuples."

But apart from tricks like that, I agree: objects that existed in the past but
no longer exist don't have a meaningful identity in Python.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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


Re: A question on modification of a list via a function invocation

2017-09-08 Thread Gregory Ewing

Steve D'Aprano wrote:

The paradox of the axe is one illustration of the difficulty in defining "the
same" in full generality.


The axe situation doesn't arise in Python, because "same
object" in Python is a concept that only applies to objects
existing at the same time.

There's no way to even ask a question like "does a refer
to the same object that b did a second ago", because
the only way to test object identity is to use the
'is' operator, which takes two expressions evaluated
at the same time.

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


Re: A question on modification of a list via a function invocation

2017-09-08 Thread Gregory Ewing

Steve D'Aprano wrote:


I don't think that talking about the average integer is meaningful.


We're not averaging the integers, we're averaging their numbers
of digits, which are natural numbers.

To do this rigorously you could write down an expression for
the average length of integers up to some finite N, and then
take the limit as N -> infinity. I haven't worked through
that, but I'd expect the sum to diverge.

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


Re: A question on modification of a list via a function invocation

2017-09-08 Thread Pavol Lisy
On 9/8/17, Gregory Ewing  wrote:
> Steve D'Aprano wrote:
>> A harder question is, what if you take a random number from the Integers?
>> How
>> many digits will it have in (say) base 10? I don't have a good answer to
>> that.
>> I think it may be ill-defined.
>
> I think the answer is that on average it has infinitely many
> digits -- despite every actual integer only having finitely
> many digits!
>
> We can prove this by contradiction. Suppose the answer were
> some finite number N. There are only finitely many integers
> with N or fewer digits, but there are infinitely many with
> more than N digits, so including them in the average must
> make it bigger than N. So N cannot be finite.

Sorry that my english is so poor that I could only draft ideas. :/

I think that it probably depends on distribution.

Think something like:

def numbers(e=0.999):
''' random numbers from integers '''
while 1:
r = random.random()
yield int(1/(1-r)**e)

and see:
https://www.wolframalpha.com/input/?i=area+between+y+%3D+1%2Fx%5E0.999+and+y+%3D+0+between+x+%3D+0+and+1

and unbounded (for e==1) ->
https://www.wolframalpha.com/input/?i=area+between+y+%3D+1%2Fx+and+y+%3D+0+between+x+%3D+0+and+1

# if somebody likes to test hipothesis ->
def avg(N=1000):
return sum(itertools.islice(numbers(), 0,N,1))/N
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: A question on modification of a list via a function invocation

2017-09-08 Thread Steve D'Aprano
On Fri, 8 Sep 2017 11:01 pm, Rhodri James wrote:

> On 08/09/17 13:45, Stefan Ram wrote:
>> Gregory Ewing  writes:
>> [a random integer will on average have ]
>>>  infinitely many
>>> digits -- despite every actual integer only having finitely
>>> many digits!
>>This is not possible because every integer has
>>a finite number of digits (in base 10).
> 
> Surely an infinitely large integer has an infinite number of digits?

There are no infinitely large integers. All integers are finite.

We can say that there is no largest integer, that they go on forever -- but no
individual integer is infinite.

We soon run out of notation to write them. There are numbers so inconceivably
huge that ordinary exponential notation isn't big enough, like Graham's Number,
and we can invent numbers even bigger:

let G = Graham's Number
let H = G^^G^^G^^ ... ^^G  # tower of a Graham's Number G's, where
^^ is the tetration (double arrow) operator:

x^^y = x^x^x^...^x  # tower of y x's

but even those inconceivably huge numbers are finite.


That's the thing about infinity. No matter how huge the number is, it is still
falls infinitely short of infinite.




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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


Re: A question on modification of a list via a function invocation

2017-09-08 Thread Steve D'Aprano
very single interminable thread like this
> one, obviously started by a noob asking something genuinely and indicating
> a real confusion disproves your claim to obvious intuition and common sense

The Original Poster wasn't confused by "sameness". The OP was confusing by
scoping and mutation.

You have to go back to 15 August to find the beginning of the thread, but the OP
was having problems reconciling his expectations of how he thought Python
behaved with how it actually behaved. If I understood his initial questions
correctly, he expected that given:


def test(alist):
alist=[3, 6, 9]

def test1(alist):
alist[0] = 3

blist = [1, 2, 3]
test(blist)
test1(blist)


one of two things would happen:

(1) Either alist inside the function test() would alias the global variable
blist (like call by reference), and *both* test() and test1() would change the
value of blist;

(2) Or alist would be a copy of blist (like call by value), and *neither* test()
nor test1() would change the value of blist.


He was confused that *only* test1() changed the value of blist, not about the
question of `is` or "same object". 


> Just to reiterate: Someone asked a question
> Its not clear what (s)he understood from what we have going on and on about
> for 100s of posts

I believe that the OP got their answer long before you started raising
philosophical questions about the nature of "is" and "identity". The OP's last
comment was on the 17th August; your first comment was nearly 12 hours later,
and it was eighteen days later that you claimed:

"Its the “== is id” mess that is at the base of the mess"

I don't know how you reached that conclusion. It seems irrelevant to the OP's
problem.



>> Can you show an actual false positive (two distinct objects for which `is`
>> returns True) or false negative (the same object given as both operands for
>> `is` nevertheless returns False)? In the absence of any actual bugs in the
>> definition, I maintain that it is sufficient.
> 
> You are not paying attention — the example above I gave in which
> python arbitrarily hi-handedly, inconsistently manifests different behavior
> between integer 1 and tuple (1,2)

I don't see the relevance. As you have been told an uncountably infinite number
of times now[3], Python is under no obligation to meet your intuitions about
which immutable objects it caches.


> I am now dropping off this thread [more important things to do]
> with this observation:

I don't know whether to be relieved or disappointed.





[1] The convention in English at least, is to distinguish between uses of a
phrase and mentions of a phrase by quoting or italics. Here quoting is more
convenient. An example of the USE-MENTION distinction is this quine:

"Is a sentence fragment" is a sentence fragment.

Without the quotation marks, it isn't even grammatical, let alone correct.



[2] Try not to faint, and I'll try not to let it happen again *wink*

[3] Not that I would ever exaggerate.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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


Re: A question on modification of a list via a function invocation

2017-09-08 Thread Steve D'Aprano
On Fri, 8 Sep 2017 08:20 pm, Ben Bacarisse wrote:

> Steve D'Aprano  writes:
> 
>> On Fri, 8 Sep 2017 12:28 am, Chris Angelico wrote:
>>
>>> languages without mutable objects don't
>>> really care whether they're pass-by-X or pass-by-Y.
>>
>> Only if you don't care about efficiency.
>>
>> Believe me, the first time you pass a five gigabyte array to a function using
>> pass-by-value, on a machine with only six gigabytes of memory, you'll care.
> 
> I think your general idea to separate language semantics from
> implementation details is a good one, but you've dropped it here.  A
> language with call-by-value semantics need not copy large objects when
> passing them to a function.  The program must behave *as if* there is a
> copy but there need not actually be one.

You're right: I didn't think of the case where a language simulates
pass-by-value semantics without actually copying. I was thinking only of actual
pass-by-value implementations.

Why would any compiler for a language with immutable arrays actually copy them
when passing them to a function? *shrug* Call it a quality of implementation
issue. Lots of compilers have sub-optimal implementations.

One counter-example might be to implement copy-on-write, in which case the
copying can be delayed until the array is written to. (Although Chris did
specify languages with immutable data structures, so that's out.)

But the larger point that I'm making is that we're not actually doing
computation in some abstract, Platonic space of pure mathematics, we're using
real computers that have to shunt actual electrons through wires and
semiconductors at high speed to do anything. Computation has real costs. We can
try to ignore them, but they exist. And even absent mutation, the way you pass
arguments has costs to:

- the overhead of passing arguments to functions adds up; even a tiny
  difference in efficiency can make a big difference to the overall
  speed of the implementation;

- as well as the memory consumption;

- the amount of work the CPU does, hence your electricity bill;

- to say nothing of the Greenhouse gases, the electronic failure rate, etc;

- let's not forget the complexity of the compiler and the possibility of bugs.

See: https://en.wikipedia.org/wiki/Man_or_boy_test

Unless pass-by-X and pass-by-Y have the same costs, somebody somewhere is going
to care about the difference. That was my point. I tried to express it
humorously rather than pedantically.


-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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


Re: A question on modification of a list via a function invocation

2017-09-08 Thread Marko Rauhamaa
r...@zedat.fu-berlin.de (Stefan Ram):

> Marko Rauhamaa  writes:
>>I definitely trust that:
>>a = b
>>assert a is b
>>even when b holds an immutable object.
>
> |Python 3.6.0 ...
> |>>> x = 21568
> |>>> x is 21568
> |False

I wasn't talking about x or 21568. I was talking about a and b.


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


Re: A question on modification of a list via a function invocation

2017-09-08 Thread Antoon Pardon
Op 08-09-17 om 04:09 schreef Steve D'Aprano:
> On Fri, 8 Sep 2017 04:24 am, Rustom Mody wrote:
>
>> On Thursday, September 7, 2017 at 6:52:04 PM UTC+5:30, Gregory Ewing wrote:
>>> Rustom Mody wrote:
>>>
 I said: In that case please restate the definition of 'is' from the manual
 which invokes the notion of 'memory' without bringing in memory.
>>> I don't know whether it's in the manual, but at least for
>>> mutable objects, there is a way to define the notion of
>>> "same object" that doesn't require talking about "memory":
>>>
>>> Two names refer to the same object if and only if mutations
>>> made through one are visible through the other.
>> Seems a sensible comment!
>
> Except that it is wrong, or at least over-generalised. It is trivially easy to
> show false positives:
>
> py> class K: # defines an object
> ... def __init__(self, x):
> ... self.x = x
> ... def append(self, value):
> ... self.x.append(value)
> ...
> py> a = []
> py> b = K(a)
> py> a is b  # these are not the same object (they're different types)
> False
> py> b.append(99)  # but modifying b modifies a
> py> a
> [99]

I don't know if this is a False positive. Yes you have shown a mutation
to one that also shows up in the other. But it is possible to mutate b
in ways that doesn't show up in a.

It seems you have interpreted the phrase: "if and only if mutations
made through one are visible through the other." as if it said: 
"if and only if *some* mutations made through one are visible through
the other." while it seems more natural to me to understand it as:
"if and only if *all* mutations made through one are visible through
the other."

So since it is possible to mutate b in ways that are not reflected in
a, I can't really see this as a false positive.

-- 
Antoon Pardon 

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


Re: A question on modification of a list via a function invocation

2017-09-08 Thread Steve D'Aprano
On Fri, 8 Sep 2017 05:54 pm, Gregory Ewing wrote:

> Steve D'Aprano wrote:
>> py> class K: # defines an object
>> ... def __init__(self, x):
>> ... self.x = x
>> ... def append(self, value):
>> ... self.x.append(value)
>> ...
>> py> a = []
>> py> b = K(a)
>> py> a is b  # these are not the same object (they're different types)
>> False
>> py> b.append(99)  # but modifying b modifies a
>> py> a
>> [99]
> 
> You didn't mutate the object bound to b there,
> you mutated the one bound to b.x, which is
> also bound to a.

Of course I do -- I've mutated one of the parts of the whole, therefore the
whole is mutated too.

Would you argue that if I took a hammer to your computer's motherboard, smashing
it to bits, that I haven't damaged your computer?

My class K is just a minimal sketch of a class that uses dependency injection
and composition, but that's not critical. Any compound object which has
publicly visible mutable parts is subject to the same sort of false positive:

book = Book()
assert book.annotations == []
page = book.pages[15]
assert book is not page  # the whole is not the same as the part
page.annotate(
'Is this the right room for an argument?')  # but if you mutate the part
assert book.annotations == [15]  # the whole mutates too




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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


Re: A question on modification of a list via a function invocation

2017-09-08 Thread Rhodri James

On 08/09/17 13:45, Stefan Ram wrote:

Gregory Ewing  writes:
[a random integer will on average have ]

 infinitely many
digits -- despite every actual integer only having finitely
many digits!

   This is not possible because every integer has
   a finite number of digits (in base 10).


Surely an infinitely large integer has an infinite number of digits?

--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list


Re: A question on modification of a list via a function invocation

2017-09-08 Thread Chris Angelico
On Fri, Sep 8, 2017 at 10:05 PM, Steve D'Aprano
 wrote:
> On Fri, 8 Sep 2017 05:48 pm, Gregory Ewing wrote:
>
>> Steve D'Aprano wrote:
>>> A harder question is, what if you take a random number from the Integers? 
>>> How
>>> many digits will it have in (say) base 10? I don't have a good answer to
>>> that. I think it may be ill-defined.
>>
>> I think the answer is that on average it has infinitely many
>> digits -- despite every actual integer only having finitely
>> many digits!
>
> I don't think that talking about the average integer is meaningful. Assuming 
> we
> are talking about the arithmetic mean, we're dealing with a divergent sum that
> depends on the way you do the summation:
>
> 0 + 1 + -1 + 2 + -2 + 3 + -3 + ... = 0
>
> 0 + 1 + 2 + 3 + 4 + ... + (-1 - 2 - 3 - 4 - ...) = ∞ - ∞ which is undefined.
>
> (Other means have similar problems, they're just harder to write or less
> familiar.)

Here's a different take on the problem. The first integer (zero) has,
let's say, no digits. Then the next 18 (1 through 9 and -1 through -9)
have one digit. The next 180 have two digits (getting us to 99 and
-99). Etcetera. Multiply each digit count by how many numbers have it,
and divide by the grand total:

(0 * 1 + 1 * 18 + 2 * 18 * 10 + 3 * 18 * 100 ...) / (1 + 18 + 18*10 +
18*100 ...)

As you add terms, the earlier terms become diminishingly significant
to the result, and the final term approaches digits/1.1 (in this
example, 3 * 1800 / (1800+180+18+1)). Since digits is tending towards
+∞, so is the sum.

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


Re: A question on modification of a list via a function invocation

2017-09-08 Thread Steve D'Aprano
On Fri, 8 Sep 2017 05:48 pm, Gregory Ewing wrote:

> Steve D'Aprano wrote:
>> A harder question is, what if you take a random number from the Integers? How
>> many digits will it have in (say) base 10? I don't have a good answer to
>> that. I think it may be ill-defined.
> 
> I think the answer is that on average it has infinitely many
> digits -- despite every actual integer only having finitely
> many digits!

I don't think that talking about the average integer is meaningful. Assuming we
are talking about the arithmetic mean, we're dealing with a divergent sum that
depends on the way you do the summation:

0 + 1 + -1 + 2 + -2 + 3 + -3 + ... = 0

0 + 1 + 2 + 3 + 4 + ... + (-1 - 2 - 3 - 4 - ...) = ∞ - ∞ which is undefined.

(Other means have similar problems, they're just harder to write or less
familiar.)

There's even a (legitimate!) argument to be made that the sum of all positive
integers is -1/12.

http://www.slate.com/blogs/bad_astronomy/2014/01/18/follow_up_the_infinite_series_and_the_mind_blowing_result.html

More here:

https://en.wikipedia.org/wiki/1_%2B_2_%2B_3_%2B_4_%2B_%E2%8B%AF

Not to mention the inconvenient fact that we're dividing by infinity:

(sum of all integers (whatever it is!))/∞

I don't think there is any way to select a random integer with equal
probability, but even if we had one, there's no guarantee that the sample means
would converge to the population mean. This is rather like the Cauchy
distribution, where the mean is not defined, and the sample means oscillate
more and more wildly as you sample more values.

So I think that any answer that requires talking about the mean or average is
ill-defined. At least unless we include significantly more rigour than I am
capable of.

If we instead say, "pick a random integer between 0 and N", and then let N
increase without limit, we see that the average number of digits also increases
without limit. But that's not the same as saying that the average number of
digits is infinite!

We *can* say that about choosing a random Real, because the irrational numbers
outnumber the rationals by so much that any random Real we pick is Almost
Always irrational. And irrationals don't have a finite expansion in any integer
base. Hence we can argue that we're almost certain to choose an irrational
number, and irrationals have infinite digits in their expansion.

But we can't say the same thing for integers. As you point out, all integers
have a finite number of digits, so we're on shaky ground to say that the
average integer has infinite digits. That implies that the average is bigger
than all the elements making up the average!

Trying to make sense of divergent series is fraught with traps. Many very simple
sounding questions involving divergent series don't have an answer at all.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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


Re: A question on modification of a list via a function invocation

2017-09-08 Thread Ben Bacarisse
Steve D'Aprano  writes:

> On Fri, 8 Sep 2017 12:28 am, Chris Angelico wrote:
>
>> languages without mutable objects don't
>> really care whether they're pass-by-X or pass-by-Y.
>
> Only if you don't care about efficiency.
>
> Believe me, the first time you pass a five gigabyte array to a function using
> pass-by-value, on a machine with only six gigabytes of memory, you'll care.

I think your general idea to separate language semantics from
implementation details is a good one, but you've dropped it here.  A
language with call-by-value semantics need not copy large objects when
passing them to a function.  The program must behave *as if* there is a
copy but there need not actually be one.


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


Re: A question on modification of a list via a function invocation

2017-09-08 Thread Marko Rauhamaa
Gregory Ewing :

> Marko Rauhamaa wrote:
>> I definitely trust that:
>>
>>a = b
>>assert a is b
>>
>> even when b holds an immutable object.
>
> That's true, but there's rarely a good use case for that
> fact that isn't better addressed with an equality comparison
> rather than an 'is' test.

I use the principle in sentinel objects. I don't care about equality but
identity.

> As an example, back in the days of string exceptions,
> the established idiom was
>
>MyException = "MyException"
>
>   try:
>  ...
>  raise MyException
>  ...
>   except MyException:
>  ...
>
> Which worked, but it was error-prone. Writing
>
>except "MyException":
>
> instead would *probably* work, but wasn't guaranteed.
> If the implementation had matched string exceptions
> by equality rather than identity, that wouldn't have
> been an issue.

I would never have thought of doing that. However, strings are as good
sentinel objects as any (they are trivially printable). Whatever
sentinel object you choose, identity is the name of the game, not
equality.


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


Re: A question on modification of a list via a function invocation

2017-09-08 Thread Gregory Ewing

Marko Rauhamaa wrote:

I definitely trust that:

   a = b
   assert a is b

even when b holds an immutable object.


That's true, but there's rarely a good use case for that
fact that isn't better addressed with an equality comparison
rather than an 'is' test.

As an example, back in the days of string exceptions,
the established idiom was

   MyException = "MyException"

  try:
 ...
 raise MyException
 ...
  except MyException:
 ...

Which worked, but it was error-prone. Writing

   except "MyException":

instead would *probably* work, but wasn't guaranteed.
If the implementation had matched string exceptions
by equality rather than identity, that wouldn't have
been an issue.

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


Re: A question on modification of a list via a function invocation

2017-09-08 Thread Gregory Ewing

Rustom Mody wrote:


Models are needed
Math is one possible model
Machines are another


I'm not sure there's any real distinction between "math" and
"machines". A Turing machine, for example, is an idealised
mathematical model of computation.

Maybe the distiction you're trying to get at is "stateless"
vs. "stateful" models of computation? With lambda calculus
being an example of a stateless model, and a Turing machine
a stateful one.

However, I suspect that the reason you're having trouble
with the concept of "same object" in a mathematical setting
is that you're failing to consider the identity of an
object to be a piece of information in its own right that
needs to be included in the model.

If you see something like this from a Python session:

>>> a
[1, 2]
>>> b
[1, 2]

you *can't tell* just by looking at that whether a and
b are bound to the same object. That's an extra piece of
information that isn't shown in those textual representations.

This is why we have things like the "is" operator and
the id() function -- they provide ways of probing that
hidden information.

If you want to model Python computation purely mathematically,
you need to come up with a way to make that extra information
explicit.

There are many ways that can be done. One way is to draw
a graph. Another might be to assign id numbers to objects
and represent objects as (id, value) tuples. But the
information needs to be there in some form, otherwise
you're not modelling Python.

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


Re: A question on modification of a list via a function invocation

2017-09-08 Thread Gregory Ewing

Rustom Mody wrote:


I'd like to know what these rules are


I can't give you a complete list of them off the top of my
head, but some examples of the kind of rules I have in
mind are:

* After the assigment

   a = b

a and b refer to the same object.

* After

   x = [e1, e2, e3, ...]

x refers to a new object that's not the same as any
other object.

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


Re: A question on modification of a list via a function invocation

2017-09-08 Thread Gregory Ewing

Steve D'Aprano wrote:

py> class K: # defines an object
... def __init__(self, x):
... self.x = x
... def append(self, value):
... self.x.append(value)
...
py> a = []
py> b = K(a)
py> a is b  # these are not the same object (they're different types)
False
py> b.append(99)  # but modifying b modifies a
py> a
[99]


You didn't mutate the object bound to b there,
you mutated the one bound to b.x, which is
also bound to a.

All you've shown is that just because a method
is named "append" doesn't mean it mutates the
object it's a method of. :-)

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


Re: A question on modification of a list via a function invocation

2017-09-08 Thread Gregory Ewing

Steve D'Aprano wrote:

A harder question is, what if you take a random number from the Integers? How
many digits will it have in (say) base 10? I don't have a good answer to that.
I think it may be ill-defined.


I think the answer is that on average it has infinitely many
digits -- despite every actual integer only having finitely
many digits!

We can prove this by contradiction. Suppose the answer were
some finite number N. There are only finitely many integers
with N or fewer digits, but there are infinitely many with
more than N digits, so including them in the average must
make it bigger than N. So N cannot be finite.

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


Re: A question on modification of a list via a function invocation

2017-09-08 Thread Gregory Ewing

Rustom Mody wrote:

2. is — machine representation, too fine to be useful


No, it's *not* machine representation. As I pointed out before,
it's part of the abstract semantics of Python.

And it's not "too fine to be useful". On the contrary, being
aware of which objects are the same and which aren't is vital
to writing Python programs that behave in the intended way.


3. graph (or topological) equality



3 captures pythonistas intuition of same better than 1 or 2


I don't think so, see below.


a = [1,2]
b = [a,a]
c = [[1,2],[1,2]]



p = [1,2]
q = [p,p]
r = [[1,2],[1,2]]



Now the pythonista understands that b and c may be math-= but have different 
structure
Whereas b is graph-equal to q
And c is graph-equal to r

However there is no available operation to show/see that distinction


Because usually it's not particularly important to know
whether two separate structures have the same topology.

On the other hand, it *is* important to know things
such as 'b[0] is b[1]' but 'c[0] is not c[1]', because
it makes a difference to what happens if you mutate
any of those.


The trouble is that graph-isomorphism is NP-complete so the crucial operation
cannot be reasonably implemented


We're fortunate that it's not actually a crucial
operation, then. :-)

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


Re: A question on modification of a list via a function invocation

2017-09-07 Thread Marko Rauhamaa
Gregory Ewing :
> There is more leeway when it comes to immutable objects;
> implementations are free to cache and re-use them, so well-written
> code avoids depending on the result of "is" for immutable objects.

I definitely trust that:

   a = b
   assert a is b

even when b holds an immutable object.

Assignment, argument passing, return value passing and yield (to name a
few) must preserve identity.


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


Re: A question on modification of a list via a function invocation

2017-09-07 Thread Chris Angelico
On Fri, Sep 8, 2017 at 1:01 PM, Rustom Mody  wrote:
>
>> Can you show an actual false positive (two distinct objects for which `is`
>> returns True) or false negative (the same object given as both operands for
>> `is` nevertheless returns False)? In the absence of any actual bugs in the
>> definition, I maintain that it is sufficient.
>
> You are not paying attention — the example above I gave in which
> python arbitrarily hi-handedly, inconsistently manifests different behavior
> between integer 1 and tuple (1,2)

You started with the assumption that the tuple (1,2) is the same as
the tuple (1,2). This is a false assumption; they are equal, but they
are not identical. How does your mathematical model cope with this?

>>> x = 1
>>> y = 1.0
>>> x == y
True
>>> x is y
False

There is no way that a compliant Python implementation can give any
other results for these expressions. These values are equal but not
identical. It's the same with the integers and tuples in your example,
except that there, Python is permitted to optimize by using the same
object.

Stop thinking about mathematics and assuming that (a) it is the
perfect way to explain software, and (b) we all have the same basis
you do. Start thinking about programming languages from a different
basis... you might actually learn something. Or just read what Steve
and I have been saying.

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


Re: A question on modification of a list via a function invocation

2017-09-07 Thread Rustom Mody
On Friday, September 8, 2017 at 7:39:38 AM UTC+5:30, Steve D'Aprano wrote:
> On Fri, 8 Sep 2017 04:24 am, Rustom Mody wrote:
> 
> > On Thursday, September 7, 2017 at 6:52:04 PM UTC+5:30, Gregory Ewing wrote:
> >> Rustom Mody wrote:
> >> 
> >> > I said: In that case please restate the definition of 'is' from the 
> >> > manual
> >> > which invokes the notion of 'memory' without bringing in memory.
> >> 
> >> I don't know whether it's in the manual, but at least for
> >> mutable objects, there is a way to define the notion of
> >> "same object" that doesn't require talking about "memory":
> >> 
> >> Two names refer to the same object if and only if mutations
> >> made through one are visible through the other.
> > 
> > Seems a sensible comment!
> 
> 
> Except that it is wrong, or at least over-generalised. It is trivially easy to
> show false positives:
> 
> py> class K: # defines an object
> ... def __init__(self, x):
> ... self.x = x
> ... def append(self, value):
> ... self.x.append(value)
> ...
> py> a = []
> py> b = K(a)
> py> a is b  # these are not the same object (they're different types)
> False
> py> b.append(99)  # but modifying b modifies a
> py> a
> [99]
> 
> 
> Rustom, I've already given you the definitive answer to your question about 
> how
> to define `is` without talking about memory. You haven't replied or
> acknowledged it, so here is it again:
> 
> `is` compares the two operands for identity. 

Preamble… so far so good

> If the two operands are the same
> object, `is` returns True, if they are distinct objects, `is` returns False.

restated
a is b iff a is b

A more than usually egregious demo of the circularity of defining 
isness/sameness

Models are needed
Math is one possible model
Machines are another
Paper and pen — which Chris keeps referring to — is another

Remove all models and you have frank hopeless circularity

> 
> 
> This does require that we agree on "same object", which as you point out is 
> (in
> its full generality) a difficult thing to define. 

More than difficult, impossible in the fully abstract philosophical case
When concretized to specific models not necessarily
the fundamental circularity then pushed out to the model
1 + 2 = 3
Are these '3's on your and my screen same? Same font? Same time?


E.g. in the past I've raised
> the paradox of My Grandfather's Axe.

Dont see the relevance (here)

> 
> But the intuitive, common-sense notion of "same object" is, I think, 
> sufficient
> here. If you want to argue that it is *not* sufficient, I think it's up to you
> to demonstrate a problem with the definition.
> 

Its not that you cant raise philosophical problems if you want
But when concretized to (basic) math, there are no disputes
so the argument becomes obtuseness to no point

In the case of python data model every single interminable thread like this one,
obviously started by a noob asking something genuinely and indicating
a real confusion disproves your claim to obvious intuition and common sense

Just to reiterate: Someone asked a question
Its not clear what (s)he understood from what we have going on and on about for
100s of posts



> Can you show an actual false positive (two distinct objects for which `is`
> returns True) or false negative (the same object given as both operands for
> `is` nevertheless returns False)? In the absence of any actual bugs in the
> definition, I maintain that it is sufficient.

You are not paying attention — the example above I gave in which
python arbitrarily hi-handedly, inconsistently manifests different behavior
between integer 1 and tuple (1,2)

I am now dropping off this thread [more important things to do]
with this observation:

There are these strange wondrous things in the world called 'mothers'
They take bawling shiing peeing pieces of fleshy exasperation called 'babies'
And convert them into intelligent human beings

Dunno how they do it…

More easily: if I, knowing English, read a German-English dictionary its ok,
a well-founded action — learning unknown-German via known-English

But reading a 'normal' English-English dictionary like Webster, Oxford etc
is borderline infinite recursion…
And occasionally fails — ambiguities, grey areas
Still it mostly works… with enough good faith

However bootstrapping the whole process from absolute zero — the mothers' task 
— 
is frankly beyond my ken

Bare (pure-philosophical, model-less) identity/sameness is analogous

So… what you think is obvious and trivially intuitive — the bald fact of 
semantics and comprehension — is to me quite miraculous
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: A question on modification of a list via a function invocation

2017-09-07 Thread Steve D'Aprano
On Fri, 8 Sep 2017 04:24 am, Rustom Mody wrote:

> On Thursday, September 7, 2017 at 6:52:04 PM UTC+5:30, Gregory Ewing wrote:
>> Rustom Mody wrote:
>> 
>> > I said: In that case please restate the definition of 'is' from the manual
>> > which invokes the notion of 'memory' without bringing in memory.
>> 
>> I don't know whether it's in the manual, but at least for
>> mutable objects, there is a way to define the notion of
>> "same object" that doesn't require talking about "memory":
>> 
>> Two names refer to the same object if and only if mutations
>> made through one are visible through the other.
> 
> Seems a sensible comment!


Except that it is wrong, or at least over-generalised. It is trivially easy to
show false positives:

py> class K: # defines an object
... def __init__(self, x):
... self.x = x
... def append(self, value):
... self.x.append(value)
...
py> a = []
py> b = K(a)
py> a is b  # these are not the same object (they're different types)
False
py> b.append(99)  # but modifying b modifies a
py> a
[99]


Rustom, I've already given you the definitive answer to your question about how
to define `is` without talking about memory. You haven't replied or
acknowledged it, so here is it again:

`is` compares the two operands for identity. If the two operands are the same
object, `is` returns True, if they are distinct objects, `is` returns False.


This does require that we agree on "same object", which as you point out is (in
its full generality) a difficult thing to define. E.g. in the past I've raised
the paradox of My Grandfather's Axe.

But the intuitive, common-sense notion of "same object" is, I think, sufficient
here. If you want to argue that it is *not* sufficient, I think it's up to you
to demonstrate a problem with the definition.

Can you show an actual false positive (two distinct objects for which `is`
returns True) or false negative (the same object given as both operands for
`is` nevertheless returns False)? In the absence of any actual bugs in the
definition, I maintain that it is sufficient.

And if there are still philosophical problems with the concept of "the same
object", they either don't apply to Python objects, or they apply equally to
all objects in the universe and there's nothing we can do about it. Either way,
the problem of defining the Python `is` operator without referring to memory is
solved.


-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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


Re: A question on modification of a list via a function invocation

2017-09-07 Thread Steve D'Aprano
On Fri, 8 Sep 2017 05:15 am, Stefan Ram wrote:

>   It computing newsgroups, for example, people
>   ask about how to compute the number of digits
>   of a number, when, actually, only numerals
>   (representations of numbers in a particular
>   numeral system) have digits.

Um, yes? That's implicit in the question -- and generally the numeral system in
question is implied to be 10. Context is important.

But for what it's worth, if you take a random number from the Reals, then the
answer will be "infinite digits" for Almost All[1] numbers, no matter what
number base you are using.

A harder question is, what if you take a random number from the Integers? How
many digits will it have in (say) base 10? I don't have a good answer to that.
I think it may be ill-defined.




[1] https://en.wikipedia.org/wiki/Almost_all


-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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


Re: A question on modification of a list via a function invocation

2017-09-07 Thread Rustom Mody
On Thursday, September 7, 2017 at 6:52:04 PM UTC+5:30, Gregory Ewing wrote:
> Rustom Mody wrote:
> 
> > I said: In that case please restate the definition of 'is' from the manual 
> > which 
> > invokes the notion of 'memory' without bringing in memory.
> 
> I don't know whether it's in the manual, but at least for
> mutable objects, there is a way to define the notion of
> "same object" that doesn't require talking about "memory":
> 
> Two names refer to the same object if and only if mutations
> made through one are visible through the other.

Seems a sensible comment!

[Aside from the fact that 'visible' is likely ill or circularly defined — my 
other comment to Stefan. But lets just ignore that for now and assume that 
'visible' has no grey/dispute areas]

> 
> Python has definite rules concerning when mutable objects
> will be the same or not, and every correct implementation
> must conform to them. In that sense it's a fundamental
> concept that doesn't depend on implementation.

I'd like to know what these rules are

> 
> There is more leeway when it comes to immutable objects;
> implementations are free to cache and re-use them, so
> well-written code avoids depending on the result of
> "is" for immutable objects.

Which sounds like saying that 'isness' of immutables is ill/un-defined
Not that I object if this is said
My objection is to the claim that the isness of python's is and the isness of
'conceptually-same' are the same.

I believe that your definition of same and the one I earlier gave are similar 
(same?? Not sure)

Repeating here for ease: (with some clarifications)

We say equivalence relation R is coarser than S is
xSy ⇒ xRy

So x is y  ⇒ x == y but not (necessarily) vice versa

However there are not 2 but 3 equivalence relations:
1. == — mathematical, too coarse to understand nuances of python semantics
2. is — machine representation, too fine to be useful
3. graph (or topological) equality which experienced pythonistas have 
internalized
in understanding when two data structures are same or different
[Roughly Anton's diagrams that are beyond my drawing capability!]


And yet pythonistas need 3 to understand python data structures
ie 3 captures pythonistas intuition of same better than 1 or 2

>>> a = [1,2]
>>> b = [a,a]
>>> c = [[1,2],[1,2]]
>>> b == c
True
>>> b is c
False
>>> p = [1,2]
>>> q = [p,p]
>>> r = [[1,2],[1,2]]
>>> q == r
True
>>> q is r
False
>>> b == q
True
>>> b == r
True
>>> b is q
False
>>> b is r
False

Now the pythonista understands that b and c may be math-= but have different 
structure
Whereas b is graph-equal to q
And c is graph-equal to r

However there is no available operation to show/see that distinction

The trouble is that graph-isomorphism is NP-complete so the crucial operation
cannot be reasonably implemented

To make it more clear
≡ is graph-equal, ie 2. The pythonista understands that
b ≢ c ## ≡ is finer than ==
Whereas
b ≡ r
ie ≡ is coarser than is

And b and r are python-equivalent without any memory relation in the sense
that no sequence of valid operations applied to b and to r will tell them apart

— sometimes called 'trace-equivalence'

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


Re: A question on modification of a list via a function invocation

2017-09-07 Thread Rustom Mody
On 06/09/17 14:02, Stefan Ram wrote:
> Chris Angelico writes:
>> The 'is' operator tests if two things are the same thing.
>
>»Roughly speaking, to say of two things that they are
>identical is nonsense, and to say of one thing that it
>is identical with itself is to say nothing at all.«
>
>  Ludwig Wittgenstein, Tractatus Logico-Philosophicus (5.5303)

Someone who is philosophically literate in technical forum: a rare treat! Nice!!

Wittgenstein is a favorite of mine and I often reserve one lecture for his:
“Limits of my language are the limits of my world”

Then amplified by Roman Jacobson’s “Languages differ not in what we can say
but what we must say”

And finally with Whorf's evidence that words can set buildings on fire
https://web.stanford.edu/dept/SUL/library/extra4/sloan/mousesite/Secondary/Whorfframe2.html

[Today it would be send countries to war]

However Wittgenstein's quote above on identity is too terse to properly grasp 
the real difficulty

https://plato.stanford.edu/entries/identity/
shows at some (verbose!) length that identity is and can only be a hopelessly
circular definition.  A problem which has little to do with python, programming 
languages, or CS in general; it is a fundamental universal problem
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: A question on modification of a list via a function invocation

2017-09-07 Thread Steve D'Aprano
On Fri, 8 Sep 2017 02:24 am, Chris Angelico wrote:

> On Fri, Sep 8, 2017 at 1:30 AM, Steve D'Aprano
>  wrote:
>> On Fri, 8 Sep 2017 12:28 am, Chris Angelico wrote:
>>
>>> languages without mutable objects don't
>>> really care whether they're pass-by-X or pass-by-Y.
>>
>> Only if you don't care about efficiency.
>>
>> Believe me, the first time you pass a five gigabyte array to a function using
>> pass-by-value, on a machine with only six gigabytes of memory, you'll care.
[...]
> Right - but sharing (in whatever form) is a pure optimization, with no
> visible semantics.

Apart from the disk activity light on your PC, as it starts thrashing :-)



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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


Re: A question on modification of a list via a function invocation

2017-09-07 Thread Chris Angelico
On Fri, Sep 8, 2017 at 1:30 AM, Steve D'Aprano
 wrote:
> On Fri, 8 Sep 2017 12:28 am, Chris Angelico wrote:
>
>> languages without mutable objects don't
>> really care whether they're pass-by-X or pass-by-Y.
>
> Only if you don't care about efficiency.
>
> Believe me, the first time you pass a five gigabyte array to a function using
> pass-by-value, on a machine with only six gigabytes of memory, you'll care.
>
> Preventing that sort of thing is probably why arrays aren't first-class values
> in C, and you cannot pass an array as argument, only a pointer to an array. 
> But
> Pascal will happily assume you know what you're doing if you declare an array
> parameter without "var", and copy the whole array.

Right - but sharing (in whatever form) is a pure optimization, with no
visible semantics.

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


Re: A question on modification of a list via a function invocation

2017-09-07 Thread Steve D'Aprano
On Fri, 8 Sep 2017 12:28 am, Chris Angelico wrote:

> languages without mutable objects don't
> really care whether they're pass-by-X or pass-by-Y.

Only if you don't care about efficiency.

Believe me, the first time you pass a five gigabyte array to a function using
pass-by-value, on a machine with only six gigabytes of memory, you'll care.

Preventing that sort of thing is probably why arrays aren't first-class values
in C, and you cannot pass an array as argument, only a pointer to an array. But
Pascal will happily assume you know what you're doing if you declare an array
parameter without "var", and copy the whole array.


-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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


Re: A question on modification of a list via a function invocation

2017-09-07 Thread Chris Angelico
On Thu, Sep 7, 2017 at 11:21 PM, Gregory Ewing
 wrote:
> Rustom Mody wrote:
>
>> I said: In that case please restate the definition of 'is' from the manual
>> which invokes the notion of 'memory' without bringing in memory.
>
>
> I don't know whether it's in the manual, but at least for
> mutable objects, there is a way to define the notion of
> "same object" that doesn't require talking about "memory":
>
> Two names refer to the same object if and only if mutations
> made through one are visible through the other.
>
> Python has definite rules concerning when mutable objects
> will be the same or not, and every correct implementation
> must conform to them. In that sense it's a fundamental
> concept that doesn't depend on implementation.

Yep. I'd call this a litmus test rather than a definition, but it's
absolutely true - and it's why languages without mutable objects don't
really care whether they're pass-by-X or pass-by-Y.

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


Re: A question on modification of a list via a function invocation

2017-09-07 Thread Gregory Ewing

Steve D'Aprano wrote:

I think that these two increment procedures will be (more or less?) equivalent:

procedure increment(var n: integer);
  begin
n := n + 1
  end;

procedure increment2(p: intpointer);
  begin
p^ := p^ + 1
  end;


They are, with the proviso that, in standard Pascal, increment2
can only be applied to a heap-allocated instance of intpointer,
whereas increment can be applied to any variable of type
integer.

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


Re: A question on modification of a list via a function invocation

2017-09-07 Thread Gregory Ewing

Rustom Mody wrote:

I said: In that case please restate the definition of 'is' from the manual which 
invokes the notion of 'memory' without bringing in memory.


I don't know whether it's in the manual, but at least for
mutable objects, there is a way to define the notion of
"same object" that doesn't require talking about "memory":

Two names refer to the same object if and only if mutations
made through one are visible through the other.

Python has definite rules concerning when mutable objects
will be the same or not, and every correct implementation
must conform to them. In that sense it's a fundamental
concept that doesn't depend on implementation.

There is more leeway when it comes to immutable objects;
implementations are free to cache and re-use them, so
well-written code avoids depending on the result of
"is" for immutable objects.

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


Re: A question on modification of a list via a function invocation

2017-09-07 Thread Marko Rauhamaa
Chris Angelico :
> *facepalm*
>
> I got nothing to say to you.

Then why say anything?


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


Re: A question on modification of a list via a function invocation

2017-09-07 Thread Antoon Pardon
Op 07-09-17 om 03:27 schreef Steve D'Aprano:
>
>> Yes it is. Pascal VAR parameters are exactly like Python a assignment.
> Proof by assertion?
>
> "It is true, because I say it is true!"

I didn't just assert, I also explained. That you choose to
ignore the explanation doesn't make it a proof by assertion.

Calling a function/procedure with a VAR parameter in Pascal,
makes the parameter an alias of the argument. Just like
a python assignment makes an alias.

This can be shown by the fact that if one mutates the enity
through one alias, the effect can be seen through the other
alias.

Now the counter argument is that if you assign to the parameter
in the function, this change doesn't effect the argument with
which the function was called in Python. But this ignores the
fact that the assignment in python doesn't mutate the entity
it refers to or is bound to or whatever you want to call it.
Instead it makes the parameter now refer/bound to something else.

Expecting that one should be able to write a swap function
should the parameters in python be like VAR parameters in
Pascal is ignoring how assignment semantics in python differ
from the assignment semantics in Pascal.

This can be shown by writing a swap function for lists because
we can simulate a mutating assignment with lists.

def swap(lp1, lp2):
tmp = list(lp1)
lp1[:] = lp2
lp2[:] = tmp

ls1 = [1, 3, 5, 7]
ls2 = [0, 2, 4, 6]

print(id(ls1), ls1)
print(id(ls2), ls2)
print("")

swap(ls1, ls2)
print(id(ls1), ls1)
print(id(ls2), ls2)

Which on my computer produces:

140178186781768 [1, 3, 5, 7]
140178186794632 [0, 2, 4, 6]

140178186781768 [0, 2, 4, 6]
140178186794632 [1, 3, 5, 7]


-- 
Antoon Pardon.


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


Re: A question on modification of a list via a function invocation

2017-09-06 Thread Steve D'Aprano
On Thu, 7 Sep 2017 12:11 am, Antoon Pardon wrote:

[...]
> No it would not translate to the above diagram. It would translate to my
> diagram. All variables in pascal refer to some object (in memory), they don't
> refer to other variables. If you have a pointer variable, you have a variable
> that refers to an object that itself refers to an other object. This later
> object can be one that is refered to directly by another variable, like code
> as above.

I'm afraid that I have no idea what you are talking about -- your explanation is
unclear to me.


[...]
> Yes it is. Pascal VAR parameters are exactly like Python a assignment.

Proof by assertion?

"It is true, because I say it is true!"



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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


Re: A question on modification of a list via a function invocation

2017-09-06 Thread Steve D'Aprano
On Wed, 6 Sep 2017 11:02 pm, Stefan Ram wrote:

> Chris Angelico  writes:
>>The 'is' operator tests if two things are the same thing.
> 
>   »Roughly speaking, to say of two things that they are
>   identical is nonsense, and to say of one thing that it
>   is identical with itself is to say nothing at all.«
> 
> Ludwig Wittgenstein, Tractatus Logico-Philosophicus (5.5303)

"Roughly speaking".

But to be more precise, it is meaningful.

"Was that you yourself I saw yesterday walking down the street, or your
doppelgänger?"

Or to put it another way...

Was the person I saw yesterday identical (in the identity sense) to the person I
am speaking to now?

We don't really use "is identical" (in the identity sense) to compare "two
distinct things" versus "one thing" -- we use it to compare two *operands* and
don't know which situation applies until after we get the answer.

If we already knew they were identical, we wouldn't need to ask.

The same applies to when we are making statements rather than asking questions
(making assertions about identity rather than questioning it). The point of
making the assertion is to pass on information that would otherwise by
ambiguous:

"There is that same (identity) cat again (not merely one that looks like it)."



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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


Re: A question on modification of a list via a function invocation

2017-09-06 Thread Steve D'Aprano
On Wed, 6 Sep 2017 10:11 pm, Rustom Mody wrote:

> On Wednesday, September 6, 2017 at 5:08:20 PM UTC+5:30, Steve D'Aprano wrote:
>> On Wed, 6 Sep 2017 07:13 pm, Rustom Mody wrote:
>> 
>> 
>> > Can you explain what "id" and "is" without talking of memory?
>> 
>> Yes.
>> 
>> id() returns an abstract ID number which is guaranteed to be an integer, and
>> guaranteed to be distinct for all objects which exist at the same time. When
>> an object ceases to exist, its ID number may be re-used.
>> 
>> `is` compares the two operands for identity. If the two operands are the same
>> object, `is` returns True, if they are distinct objects, `is` returns False.
> 
 a = (1,2)
 b = (1,2)
 a is b
> False
 x = 1
 y = 1
 x is y
> True
> 
> a seems to be as 'same' to b as x is to y
> Python seems to think otherwise
> 
> Evidently your ‘same’ is not the same as mine??

You are (intentionally, I think) being obtuse. I am confident that you know very
well that "the same" as a general English term has many meanings, including:

- same in identity ("the same man I saw yesterday");
- closely similar ("the curtains are the same colour as the carpets");
- equal ("I gave the children the same number of lollies each");
- unchanged ("his attitude is the same as ever");
- of like kind ("you are exactly the same as your mother");

while "the same object" has specifically the first meaning.

How do you know that two objects are the same object? It isn't because they are
equal, or that they look vaguely the same. "Equal" is not equivalent to "the
same object":

py> a, b = [], []  # they sure look the same...
py> a == b
True
py> a.append(None)  # insert None into a
py> None in b  # but they aren't the same object
False


The only way to find out if two objects are the same object is to ask Python --
and Python is under no obligation to comply with your naïve intuitions about
objects. As you are well aware, because we've told you many times, Python often
caches objects so that they are reused rather than being recreated from scratch
when needed -- and it is free to do so in implementation and version dependent
ways.



>> > In fact we have got so used to the term 'memory' that it actually seems
>> > strange when someone like Dijkstra grumbles at the anthropomorphism and
>> > asks why its not called 'store'.
>> 
>> And if it were called "store" (grocery store? shoe store? clothes store?)
>> Dijkstra would have grumbled at the metaphor and asked why it wasn't
>> called "memory".
> 
> Memory is an old (middle-English) word.
> Until say 1945 it could be used in sentences like the following
> “I have memories of walking in the woods with my dad”
> “Where are the eggs?”   “Oops! Totally slipped my memory… Sorry"
> “The Dalai Lama has memories of his past lives”

I don't understand why you say "until 1945". You can still use memory in those
ways even today.

> Are you using ‘memory’ in this kind of way?

Yes.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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


Re: A question on modification of a list via a function invocation

2017-09-06 Thread breamoreboy
On Wednesday, September 6, 2017 at 1:12:22 PM UTC+1, Rustom Mody wrote:
> On Wednesday, September 6, 2017 at 5:08:20 PM UTC+5:30, Steve D'Aprano wrote:
> > On Wed, 6 Sep 2017 07:13 pm, Rustom Mody wrote:
> > 
> > 
> > > Can you explain what "id" and "is" without talking of memory?
> > 
> > Yes.
> > 
> > id() returns an abstract ID number which is guaranteed to be an integer, and
> > guaranteed to be distinct for all objects which exist at the same time. 
> > When an
> > object ceases to exist, its ID number may be re-used.
> > 
> > `is` compares the two operands for identity. If the two operands are the 
> > same
> > object, `is` returns True, if they are distinct objects, `is` returns False.
> 
> >>> a = (1,2)
> >>> b = (1,2)
> >>> a is b
> False
> >>> x = 1
> >>> y = 1
> >>> x is y
> True
> 
> a seems to be as 'same' to b as x is to y
> Python seems to think otherwise
> 
> Evidently your ‘same’ is not the same as mine??
> 

This shows your complete ignorance of Python.  One would often suggest putting 
the shovel down, but it is far too late for that.

Kindest regards.

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


Re: A question on modification of a list via a function invocation

2017-09-06 Thread Antoon Pardon
On 06-09-17 15:14, Stefan Ram wrote:
> Steve D'Aprano  writes:
>> or any of the other things we can do in a language with references-as-values,
>> like C or Pascal.
> 
>   I have always taken the stance that one has to use the words
>   as the language specification of the language one talks
>   about does.
> 
But that makes it difficult to point to similar semantics in two languages,
when those languages use different wording to express those semantics.

-- 
Antoon Pardon.

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


Re: A question on modification of a list via a function invocation

2017-09-06 Thread Antoon Pardon
Op 06-09-17 om 14:58 schreef Steve D'Aprano:
> On Wed, 6 Sep 2017 05:12 pm, Antoon Pardon wrote:
>
> [...]
>>> I'm not saying that we should never use this model. Its a good model. But we
>>> should be clear that it is a model of the implementation, and it describes
>>> entities which are not part of the Python language. We cannot do this:
>>>
>>>
>>>  +-+
>>>  | |
>>>  |  5  |
>>>  | |
>>>  +-+
>>> ^
>>> |
>>>
>>> ^
>>> |
>>>
>>>
>>>
>>> or any of the other things we can do in a language with 
>>> references-as-values,
>>> like C or Pascal.
>> I don't agree that the above is an accurate picture of C or Pascal.
> I'm surprised. You can do this in Pascal:
>
> type
>   intpointer = ^integer;
> var
>   x: intpointer;
>   y: ^intpointer;
> begin
>   new(x);  {reserve memory in the heap for an integer, and point x at it}
>   x^ := 5;
>   y := @x;  {y points to the pointer x}
> end.
>
> which would translate to the diagram above. If you don't like the fact that 
> I'm
> using the "address of" operator @ which is non-standard Pascal, I can write
> this instead:

No it would not translate to the above diagram. It would translate to my 
diagram.
All variables in pascal refer to some object (in memory), they don't refer to
other variables. If you have a pointer variable, you have a variable that refers
to an object that itself refers to an other object. This later object can be
one that is refered to directly by another variable, like code as above.

>
>
> type
>   intpointer = ^integer;
> var
>   y: ^intpointer;
> begin
>   new(y);  {reserve memory in the heap for an intpointer, and point y at it}
>   new(y^);  {reserve memory in the heap for an integer, and point y^ at it}
>   y^^ := 5;
> end.
>
> I would be shocked if C were less powerful in this regard than Pascal.

That would be result in the following diagram.


   +-+ +-+  +-+
   | | | |  | |
   |  *--+>|  *--+->|  5  |
   | | | |  | |
   +-+ +-+  +-+
  ^
  |
 

>> And in case of a VAR parameter in Pascal like
>>
>> procedure f(VAR x);
>> f(y)
>>
>> one could use the following, which is the same
>> as after an assignment in python.
>>
>>
>>   +-+
>>   | |
>>   |  7  |
>> --->  | |
>>/  +-+
>>   /
>>  /   ^
>> /|
>>  
> No no no! Pascal VAR parameters are not the same as Python assignment! You
> cannot write a Pascal swap procedure in Python!

Yes it is. Pascal VAR parameters are exactly like Python a assignment. The
fact that you can't write a swap procedure in Python is because the
semantics of the Python assignment differs from the semantics of the Pascal
assignment. Not because the VAR parameter semantics in Pascal differ from
the parameter or assignment semantics in Python. 

The semantics of the VAR parameter in Pascal and the sematics of Python
assignment are both creating a new alias for the same object or however you
want to phrase it.

-- 
Antoon Pardon

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


Re: A question on modification of a list via a function invocation

2017-09-06 Thread Rhodri James

On 06/09/17 14:02, Stefan Ram wrote:

Chris Angelico  writes:

The 'is' operator tests if two things are the same thing.


   »Roughly speaking, to say of two things that they are
   identical is nonsense, and to say of one thing that it
   is identical with itself is to say nothing at all.«

 Ludwig Wittgenstein, Tractatus Logico-Philosophicus (5.5303)


Irrelevant.  We are talking about identity, not identicallity (to coin a 
word).  Or in plainer English, asking if two things are the same thing 
is not the same as asking if two things are identical.


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list


Re: A question on modification of a list via a function invocation

2017-09-06 Thread Chris Angelico
On Wed, Sep 6, 2017 at 11:02 PM, Stefan Ram  wrote:
> Chris Angelico  writes:
>>The 'is' operator tests if two things are the same thing.
>
>   »Roughly speaking, to say of two things that they are
>   identical is nonsense, and to say of one thing that it
>   is identical with itself is to say nothing at all.«
>
> Ludwig Wittgenstein, Tractatus Logico-Philosophicus (5.5303)

Yes, and the expression "x is x" is indeed saying nothing at all. But
it's perfectly reasonable, in English, to make statements like:

"Talldad is my father."

"This is my box." (It's not purrfect, but it's mine. [1])

"The President of the US is FD Roosevelt."

Each one corresponds to a Python statement of identity:

print(talldad is self.father)
print(self is chii.box)
print(usa.president is fdr)

In the case of Talldad, one side is absolute and the other side is
relative. (Yes, my father is my relative. Whodathunk?) For a given
'self', the statement will always be consistent. In the case of the
president of the US, it's an attribute that gets reassigned
periodically, so the statement may be true one day and false another.
But it's still fully reasonable to have an absolute identifier for a
specific person, and to ask if that refers to the same individual as
some relative or time-dependent identifier/alias.

ChrisA

[1] https://www.redbubble.com/people/devicatoutlet/works/27806715-this-is-my-box
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: A question on modification of a list via a function invocation

2017-09-06 Thread Steve D'Aprano
On Wed, 6 Sep 2017 05:12 pm, Antoon Pardon wrote:

[...]
>> I'm not saying that we should never use this model. Its a good model. But we
>> should be clear that it is a model of the implementation, and it describes
>> entities which are not part of the Python language. We cannot do this:
>>
>>
>>  +-+
>>  | |
>>  |  5  |
>>  | |
>>  +-+
>> ^
>> |
>>
>> ^
>> |
>>
>>
>>
>> or any of the other things we can do in a language with references-as-values,
>> like C or Pascal.
> 
> I don't agree that the above is an accurate picture of C or Pascal.

I'm surprised. You can do this in Pascal:

type
  intpointer = ^integer;
var
  x: intpointer;
  y: ^intpointer;
begin
  new(x);  {reserve memory in the heap for an integer, and point x at it}
  x^ := 5;
  y := @x;  {y points to the pointer x}
end.

which would translate to the diagram above. If you don't like the fact that I'm
using the "address of" operator @ which is non-standard Pascal, I can write
this instead:


type
  intpointer = ^integer;
var
  y: ^intpointer;
begin
  new(y);  {reserve memory in the heap for an intpointer, and point y at it}
  new(y^);  {reserve memory in the heap for an integer, and point y^ at it}
  y^^ := 5;
end.

I would be shocked if C were less powerful in this regard than Pascal.

 

> It is more 
> like the following:
> 
>  +-+ +-+
>  | | | |
>  |  5  |<+--*  |
>  | | | |
>  +-+ +-+
> ^   ^
> |   |
> 


That would be equivalent to a different piece of code:

type
  intpointer = ^integer;
var
  x: intpointer;
  y: ^intpointer;
begin
  new(x);  {reserve memory in the heap for an integer, and point x at it}
  x^ := 5;
  new(y);  {reserve memory in the heap for an intpointer, and point y at it}
  y^ := x;  {assignment copies; y^ now points to the same thing as x}
end.


These two are not the same thing.


> And in case of a VAR parameter in Pascal like
> 
> procedure f(VAR x);
> f(y)
> 
> one could use the following, which is the same
> as after an assignment in python.
> 
> 
>   +-+
>   | |
>   |  7  |
> --->  | |
>/  +-+
>   /
>  /   ^
> /|
>  

No no no! Pascal VAR parameters are not the same as Python assignment! You
cannot write a Pascal swap procedure in Python!


Pascal VAR parameters are, in a sense, syntactic sugar for pointer manipulation.
(I'm not sure just how far we can take this analogy, but I think its pretty
far.) That's probably why C didn't bother with VAR parameters: anything you can
do with a VAR parameter, you can do with explicit pointers.

I think that these two increment procedures will be (more or less?) equivalent:


type
  intpointer = ^integer;

procedure increment(var n: integer);
  begin
n := n + 1
  end;

procedure increment2(p: intpointer);
  begin
p^ := p^ + 1
  end;

var
  a: integer;
  b: integer;
begin
  a := 99;
  increment(a);
  writeln(a);  {will print 100}
  b := 99;
  increment2(@b);
  writeln(b);  {will print 100}
end.



If there's a difference, its a subtle one which I haven't found in a short
amount of testing.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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


Re: A question on modification of a list via a function invocation

2017-09-06 Thread Chris Angelico
On Wed, Sep 6, 2017 at 10:44 PM, Rustom Mody  wrote:
> On Wednesday, September 6, 2017 at 5:48:48 PM UTC+5:30, Chris Angelico wrote:
>> On Wed, Sep 6, 2017 at 10:11 PM, Rustom Mody  wrote:
>>  a = (1,2)
>>  b = (1,2)
>>  a is b
>> > False
>>  x = 1
>>  y = 1
>>  x is y
>> > True
>> >
>> > a seems to be as 'same' to b as x is to y
>> > Python seems to think otherwise
>> >
>> > Evidently your ‘same’ is not the same as mine??
>>
>> *facepalm*
>>
>> I got nothing to say to you. Have you been on this list all this time
>> and still don't understand that Python sometimes optimizes immutables?
>
> Losing 'memory' of context Chris?
> Let me erm… remind:
>
> I said 'is' refers to "same in machine representation"
>
> Greg disagreed: « "is" in Python has an abstract definition that
> doesn't depend on machine representation.»
>
> I said: In that case please restate the definition of 'is' from the manual 
> which
> invokes the notion of 'memory' without bringing in memory.
>
> Steven gave his explanation by dropping 'memory' and gave a definition
>
> Which I showed does not match expected common sense
>
> Sure you can bring in the notion (now!) of optimization if you like
> But you cant have it both ways
> - 'is' is a fundamental conceptual notion of sameness
> - 'is' is a machine/implementation specific notion of sameness which changes
>   depending on machine/implementation specific decisions

Okay. Lemme spell it out for you real easy.

The 'is' operator tests if two things are the same thing.

Okay? With me so far? Good. No mention of memory.

Next, we have an optimization:

Sometimes, Python uses the same object more than once. You can't
distinguish one integer 1 from another other than by their ids, so
Python is free to use the same integer object for both uses of 1.

Clear? Still no mention of memory anywhere.

And it doesn't violate any conceptual notion of sameness.

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


Re: A question on modification of a list via a function invocation

2017-09-06 Thread Rustom Mody
On Wednesday, September 6, 2017 at 5:48:48 PM UTC+5:30, Chris Angelico wrote:
> On Wed, Sep 6, 2017 at 10:11 PM, Rustom Mody  wrote:
> > On Wednesday, September 6, 2017 at 5:08:20 PM UTC+5:30, Steve D'Aprano 
> > wrote:
> >> On Wed, 6 Sep 2017 07:13 pm, Rustom Mody wrote:
> >>
> >>
> >> > Can you explain what "id" and "is" without talking of memory?
> >>
> >> Yes.
> >>
> >> id() returns an abstract ID number which is guaranteed to be an integer, 
> >> and
> >> guaranteed to be distinct for all objects which exist at the same time. 
> >> When an
> >> object ceases to exist, its ID number may be re-used.
> >>
> >> `is` compares the two operands for identity. If the two operands are the 
> >> same
> >> object, `is` returns True, if they are distinct objects, `is` returns 
> >> False.
> >
>  a = (1,2)
>  b = (1,2)
>  a is b
> > False
>  x = 1
>  y = 1
>  x is y
> > True
> >
> > a seems to be as 'same' to b as x is to y
> > Python seems to think otherwise
> >
> > Evidently your ‘same’ is not the same as mine??
> 
> *facepalm*
> 
> I got nothing to say to you. Have you been on this list all this time
> and still don't understand that Python sometimes optimizes immutables?

Losing 'memory' of context Chris?
Let me erm… remind:

I said 'is' refers to "same in machine representation"

Greg disagreed: « "is" in Python has an abstract definition that
doesn't depend on machine representation.»

I said: In that case please restate the definition of 'is' from the manual 
which 
invokes the notion of 'memory' without bringing in memory.

Steven gave his explanation by dropping 'memory' and gave a definition

Which I showed does not match expected common sense

Sure you can bring in the notion (now!) of optimization if you like
But you cant have it both ways
- 'is' is a fundamental conceptual notion of sameness
- 'is' is a machine/implementation specific notion of sameness which changes 
  depending on machine/implementation specific decisions

Of course you can have a third hand… Its usually called sophistry

The trouble with sophistrizing is that you get caught in your own net:
You (and Steven) claim that references (and aliases such as pointers) can be
expunged from the language semantics.
If you do that the term 'memory' remains standalone without any semantics.
And when you make a bogus expulsion of that as well, extant behavior becomes
unexplainable…
Except with a… (which I share)


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


Re: A question on modification of a list via a function invocation

2017-09-06 Thread Rustom Mody
On Wednesday, September 6, 2017 at 4:03:40 PM UTC+5:30, ROGER GRAYDON CHRISTMAN 
wrote:
> On 5 Sep 2017 14:28:44,  (Dennis Lee Bier) wrote: 
> > On 5 Sep 2017 17:57:18 GMT,  
> >>  But what does "a C++ reference" refer to?
> >>
> 
> > Per Stroustrup (The C++ Programming Language 4th Ed, page 189)
> 
> > """
> > * ...> * A reference always refers to the object to which it was 
> > initialized.
> > * ...
> 
> > A reference is an alternative name for an object, an alias. ...
> > """
> 
> > {Hmmm, and I see that the syntax can be used outside of parameter
> > declaration -- which is the only place I'd seen it previously... either
> > this is a change from earlier standards, or my classes just didn't feel the
> > need to expose a non-parameter reference -- since, based upon the above
> > book, you can not declare a bare reference "variable"; it MUST be
> > initialized with a real object.}
> 
> I think I can say something about this, having been a teacherof the classes 
> you refer to.   I intentionally avoided reference variables.
> IMO, the 'good' use for declaring a new reference variable (i.e. not 
> parameter)would be when (1) the object to which you refer to is 
> time-consuming to access(2) you plan to refer to this object more then once, 
> and don't want to repeatthat time-consuming process, and (3) you really want 
> a reference, and not a copy.
> The first two years of programming courses really do not have a purposethat 
> meets all three, so can "didn't feel the need" is probably applicable.
> I intentionally avoided them because reference variables simply compoundthe 
> problem of aliasing, so unless you really limit your reference variableto a 
> very tight sandbox, you could be causing more headache than you save.
> I do admit to occasionally defining a method that returned a reference,such 
> as one that overloads the [] operator.   But even so, I would generallybe 
> reluctant to giving an outside client a direct access to my 
> database'sinternal structures.  (Thank you Python for separating __getitem__ 
> and __setitem__)
> Python doesn't eliminate aliasing, of course, since most assignment 
> operationscreate aliases.  But at least it's nice to know that aliasing 
> immutable valuesis harmless.   Hence my unit on building recursive data 
> structures entirelyout of tuples.

The realization that immutability is a significant virtue is now beginning 
to percolate mainstream programming
Ive seen it in recent C# books as a definite recommendation… Something like
- Use value types
- Use getters but no setters

And you have a good design

Python makes this hard by giving less status to immutable types than mutable 
ones
- set comprehensions exist not frozenset comprehensions
- Likewise tuples and lists
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: A question on modification of a list via a function invocation

2017-09-06 Thread nopsidy
https://www.youtube.com/watch?v=pNe1wWeaHOU&list=PLYI8318YYdkCsZ7dsYV01n6TZhXA6Wf9i&index=1
Thank you,
-Alex Goretoy
http://launchpad.net/~a1g


On Wed, Sep 6, 2017 at 7:18 PM, Chris Angelico  wrote:
> On Wed, Sep 6, 2017 at 10:11 PM, Rustom Mody  wrote:
>> On Wednesday, September 6, 2017 at 5:08:20 PM UTC+5:30, Steve D'Aprano wrote:
>>> On Wed, 6 Sep 2017 07:13 pm, Rustom Mody wrote:
>>>
>>>
>>> > Can you explain what "id" and "is" without talking of memory?
>>>
>>> Yes.
>>>
>>> id() returns an abstract ID number which is guaranteed to be an integer, and
>>> guaranteed to be distinct for all objects which exist at the same time. 
>>> When an
>>> object ceases to exist, its ID number may be re-used.
>>>
>>> `is` compares the two operands for identity. If the two operands are the 
>>> same
>>> object, `is` returns True, if they are distinct objects, `is` returns False.
>>
> a = (1,2)
> b = (1,2)
> a is b
>> False
> x = 1
> y = 1
> x is y
>> True
>>
>> a seems to be as 'same' to b as x is to y
>> Python seems to think otherwise
>>
>> Evidently your ‘same’ is not the same as mine??
>
> *facepalm*
>
> I got nothing to say to you. Have you been on this list all this time
> and still don't understand that Python sometimes optimizes immutables?
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: A question on modification of a list via a function invocation

2017-09-06 Thread Chris Angelico
On Wed, Sep 6, 2017 at 10:11 PM, Rustom Mody  wrote:
> On Wednesday, September 6, 2017 at 5:08:20 PM UTC+5:30, Steve D'Aprano wrote:
>> On Wed, 6 Sep 2017 07:13 pm, Rustom Mody wrote:
>>
>>
>> > Can you explain what "id" and "is" without talking of memory?
>>
>> Yes.
>>
>> id() returns an abstract ID number which is guaranteed to be an integer, and
>> guaranteed to be distinct for all objects which exist at the same time. When 
>> an
>> object ceases to exist, its ID number may be re-used.
>>
>> `is` compares the two operands for identity. If the two operands are the same
>> object, `is` returns True, if they are distinct objects, `is` returns False.
>
 a = (1,2)
 b = (1,2)
 a is b
> False
 x = 1
 y = 1
 x is y
> True
>
> a seems to be as 'same' to b as x is to y
> Python seems to think otherwise
>
> Evidently your ‘same’ is not the same as mine??

*facepalm*

I got nothing to say to you. Have you been on this list all this time
and still don't understand that Python sometimes optimizes immutables?

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


Re: A question on modification of a list via a function invocation

2017-09-06 Thread Rustom Mody
On Wednesday, September 6, 2017 at 5:08:20 PM UTC+5:30, Steve D'Aprano wrote:
> On Wed, 6 Sep 2017 07:13 pm, Rustom Mody wrote:
> 
> 
> > Can you explain what "id" and "is" without talking of memory?
> 
> Yes.
> 
> id() returns an abstract ID number which is guaranteed to be an integer, and
> guaranteed to be distinct for all objects which exist at the same time. When 
> an
> object ceases to exist, its ID number may be re-used.
> 
> `is` compares the two operands for identity. If the two operands are the same
> object, `is` returns True, if they are distinct objects, `is` returns False.

>>> a = (1,2)
>>> b = (1,2)
>>> a is b
False
>>> x = 1
>>> y = 1
>>> x is y
True

a seems to be as 'same' to b as x is to y
Python seems to think otherwise

Evidently your ‘same’ is not the same as mine??




> 
> > In fact we have got so used to the term 'memory' that it actually seems
> > strange when someone like Dijkstra grumbles at the anthropomorphism and asks
> > why its not called 'store'.
> 
> And if it were called "store" (grocery store? shoe store? clothes store?)
> Dijkstra would have grumbled at the metaphor and asked why it wasn't
> called "memory".

Memory is an old (middle-English) word.
Until say 1945 it could be used in sentences like the following
“I have memories of walking in the woods with my dad”
“Where are the eggs?”   “Oops! Totally slipped my memory… Sorry"
“The Dalai Lama has memories of his past lives”

Are you using ‘memory’ in this kind of way?
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: A question on modification of a list via a function invocation

2017-09-06 Thread Steve D'Aprano
On Wed, 6 Sep 2017 07:13 pm, Rustom Mody wrote:


> Can you explain what "id" and "is" without talking of memory?

Yes.

id() returns an abstract ID number which is guaranteed to be an integer, and
guaranteed to be distinct for all objects which exist at the same time. When an
object ceases to exist, its ID number may be re-used.

`is` compares the two operands for identity. If the two operands are the same
object, `is` returns True, if they are distinct objects, `is` returns False.



> In fact we have got so used to the term 'memory' that it actually seems
> strange when someone like Dijkstra grumbles at the anthropomorphism and asks
> why its not called 'store'.

And if it were called "store" (grocery store? shoe store? clothes store?)
Dijkstra would have grumbled at the metaphor and asked why it wasn't
called "memory".




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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


Re: A question on modification of a list via a function invocation

2017-09-06 Thread Gregory Ewing

Steven D'Aprano wrote:
Not in standard Pascal, but most actual Pascal compilers let you perform 
pointer arithmetic.


Well, sort of. In the ones I've seen, it's more like
being able to cast a pointer to an integer, do arithmetic
on that and then cast it back. The results are about
as implementation-dependent as that suggests.

C, on the other hand, allows arithmetic operations on
pointers directly and defines their semantics (up to a
point, you can fall off into undefined territory fairly
easily).

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


Re: A question on modification of a list via a function invocation

2017-09-06 Thread Gregory Ewing

Steven D'Aprano wrote:

But many (perhaps even most) people have no problem dealing with location 
as a metaphor, where being in two places (metaphorically) is no problem 
at all:


- I am in love, in trouble and in denial all at once.


Sometimes the word "in" implies physical location, sometimes
it doesn't.

Being a member of more than one list is a familiar enough
concept, for example, although one would probably say
"on a list" rather than "in a list".

However, "on a list" doesn't really conjure up an image
of physical location. We wouldn't picture ourselves standing
on a piece of paper; rather, we would imagine our name or
other piece of identifying information being written on
the paper.

Dare I say... we would think of a *reference* to us being
on the list? :-)



Even when the location is not a state of being but an actual physical 
place, we can be in multiple places at once:


- I am in my home, in Melbourne, and in Australia all at once.


That's only non-weird because there is a nesting relationship
between those locations. It doesn't extend to more general
topologies. For example, if your home is in Melbourne, then
being in your home and Australia but *not* in Melbourne
would be an interesting trick.


Being in two places at once is a common trope in both fantasy and science 
fiction (often involving time travel).


And they're interesting plot devices precisely because they
defy our physical intuition so much. If you're trying to
deconfuse someone about Python semantics, tying their brain
up in knots doesn't seem like a very productive approach!

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


Re: A question on modification of a list via a function invocation

2017-09-06 Thread Rhodri James

On 05/09/17 23:29, Grant Edwards wrote:

On 2017-09-05, Marko Rauhamaa  wrote:


Pointer arithmetics is not an essential part of C. One could argue that
it was a mistake to include it in the language.

One may argue that it was a mistake, but I remember at least one
implementation where pointer arithmetic was hugely more efficient than
indexing into arrays.  Incrementing a pointer through an array was
way, way faster than indexing through the array by incrementing an
array subscript.

But, that was 25 years ago on an 8-bit CPU where where integer
multiplies were expensive.  The last time I compare the two methods
with a recent GCC on a 32-bit CPU, it generated pretty much the same
code either way...


That's the optimiser at work, turning what you wrote into the best fit 
to the processor architecture.  On an ARM, for example, that would 
likely still be incrementing a pointer through an array.


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list


Re: A question on modification of a list via a function invocation

2017-09-06 Thread ROGER GRAYDON CHRISTMAN

On 5 Sep 2017 14:28:44, wlfr...@ix.netcom.com (Dennis Lee Bier) wrote: 
> On 5 Sep 2017 17:57:18 GMT, https://webmail.psu.edu/webmail/retrieve.cgi?mailbox=inbox&start_num=14200&limit=50&sort=0&display=4×tamp=20170906045729&mid=mailman%2e%2e1504662834%2e2732%2epython%2dlist%40python%2eorg#";>r...@zedat.fu-berlin.de
 (Stefan Ram) 
> declaimed the following:

>>  But what does "a C++ reference" refer to?
>>

> Per Stroustrup (The C++ Programming Language 4th Ed, page 189)

> """
> * ...> * A reference always refers to the object to which it was initialized.
> * ...

> A reference is an alternative name for an object, an alias. ...
> """

> {Hmmm, and I see that the syntax can be used outside of parameter
> declaration -- which is the only place I'd seen it previously... either
> this is a change from earlier standards, or my classes just didn't feel the
> need to expose a non-parameter reference -- since, based upon the above
> book, you can not declare a bare reference "variable"; it MUST be
> initialized with a real object.}

I think I can say something about this, having been a teacherof the classes you 
refer to.   I intentionally avoided reference variables.
IMO, the 'good' use for declaring a new reference variable (i.e. not 
parameter)would be when (1) the object to which you refer to is time-consuming 
to access(2) you plan to refer to this object more then once, and don't want to 
repeatthat time-consuming process, and (3) you really want a reference, and not 
a copy.
The first two years of programming courses really do not have a purposethat 
meets all three, so can "didn't feel the need" is probably applicable.
I intentionally avoided them because reference variables simply compoundthe 
problem of aliasing, so unless you really limit your reference variableto a 
very tight sandbox, you could be causing more headache than you save.
I do admit to occasionally defining a method that returned a reference,such as 
one that overloads the [] operator.   But even so, I would generallybe 
reluctant to giving an outside client a direct access to my database'sinternal 
structures.  (Thank you Python for separating __getitem__ and __setitem__)
Python doesn't eliminate aliasing, of course, since most assignment 
operationscreate aliases.  But at least it's nice to know that aliasing 
immutable valuesis harmless.   Hence my unit on building recursive data 
structures entirelyout of tuples.
Roger ChristmanPennsylvania Sate University
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: A question on modification of a list via a function invocation

2017-09-06 Thread Chris Angelico
On Wed, Sep 6, 2017 at 7:13 PM, Rustom Mody  wrote:
> On Wednesday, September 6, 2017 at 12:51:25 PM UTC+5:30, Gregory Ewing wrote:
>> Rustom Mody wrote:
>> > 2. is — machine representation, too fine to be useful
>>
>> Disagree - "is" in Python has an abstract definition that
>> doesn't depend on machine representation.
>>
>> --
>> Greg
>
> There is this (AFAIAC sophistry) in the docs describing the data model
> https://docs.python.org/3/reference/datamodel.html
>
> | Every object has an identity, a type and a value. An object’s identity never
> | changes once it has been created; you may think of it as the object’s 
> address
> | in memory. The ‘is’ operator compares the identity of two objects; the id()
> | function returns an integer representing its identity.
>
> | CPython implementation detail: For CPython, id(x) is the memory address 
> where
> | x is stored.
>
> Can you explain what "id" and "is" without talking of memory?

Yes, easily. Just delete the "CPython implementation detail" section
and the "you may think of it" part from that quote and let the rest
stand alone. None of the rest of that document depends on memory
addresses.

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


Re: A question on modification of a list via a function invocation

2017-09-06 Thread Chris Angelico
On Wed, Sep 6, 2017 at 7:01 PM, Gregory Ewing
 wrote:
> Chris Angelico wrote:
>>
>> You can't do this with Python, since pointer arithmetic fundamentally
>> doesn't exist.
>
>
> Pointer arithmetic doesn't exist in Pascal either, yet
> Pascal most definitely has pointers as a distinct data
> type.
>
> Insisting that only pointer arithmetic counts as
> "manipulating" pointers seems a strange way of defining
> the word.

Understood. I'm withdrawing the assertion that pointer arithmetic is
essential, weakening the demand to the ability to:

1) Take the address of an object (yielding a pointer)
2) Move the pointer around as its own thing, eg pass it as a function parameter
3) Dereference the pointer, to read or write the original object

But you have to be able to prove that #2 is actually looking at the
pointer as its own entity. This has to be distinct from passing around
the object itself in some way.

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


Re: A question on modification of a list via a function invocation

2017-09-06 Thread Rustom Mody
On Wednesday, September 6, 2017 at 12:51:25 PM UTC+5:30, Gregory Ewing wrote:
> Rustom Mody wrote:
> > 2. is — machine representation, too fine to be useful
> 
> Disagree - "is" in Python has an abstract definition that
> doesn't depend on machine representation.
> 
> -- 
> Greg

There is this (AFAIAC sophistry) in the docs describing the data model
https://docs.python.org/3/reference/datamodel.html

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

| CPython implementation detail: For CPython, id(x) is the memory address where 
| x is stored.

Can you explain what "id" and "is" without talking of memory?

In fact we have got so used to the term 'memory' that it actually seems strange 
when 
someone like Dijkstra grumbles at the anthropomorphism and asks why its not 
called 'store'.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: A question on modification of a list via a function invocation

2017-09-06 Thread Gregory Ewing

Chris Angelico wrote:

You can't do this with Python, since pointer arithmetic fundamentally
doesn't exist.


Pointer arithmetic doesn't exist in Pascal either, yet
Pascal most definitely has pointers as a distinct data
type.

Insisting that only pointer arithmetic counts as
"manipulating" pointers seems a strange way of defining
the word.

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


Re: A question on modification of a list via a function invocation

2017-09-06 Thread Gregory Ewing

Steve D'Aprano wrote:

No, they aren't first-class.


Maybe not fully, but you can do a lot more with them
than you can in Pascal or Modula-2.


- Containers of references are not allowed.


You can't have arrays of references, but struct and class
members can be references, so you can certainly build data
structures that contain them.

(A quick experiment suggests that you can even have arrays
of structs that contain references, so I'm not sure why
they're not allowed in arrays directly.)

- Once a reference to an object is created, it cannot be changed to 
  reference another object ("to be reseated").


Actually there is a way to do that, but you have to be
sneaky about it.

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


Re: A question on modification of a list via a function invocation

2017-09-06 Thread Gregory Ewing

Rustom Mody wrote:

2. is — machine representation, too fine to be useful


Disagree - "is" in Python has an abstract definition that
doesn't depend on machine representation.

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


Re: A question on modification of a list via a function invocation

2017-09-06 Thread Antoon Pardon
Op 04-09-17 om 17:43 schreef Steve D'Aprano:
> On Tue, 5 Sep 2017 01:17 am, Rustom Mody wrote:
>
>> Anton gave a picture explaining why/how references are needed and to be
>> understood
> Antoon gave a picture demonstrating one model of Python's semantics.
>
> It's a nice model that has a lot going for it, in particular that it matches 
> the
> most obvious implementation. But it doesn't describe *Python* semantics, it
> describes an overlap between Python the language and the implementation of the
> Python interpreter.
>
> In particular, consider the picture of a name binding to a value:
>
>
>  +-+
>  | |
>  |  5  |
>  | |
>  +-+
> ^
> |
>
>
>
> This picture has three entities, but only two of them exist in Python:
>
> - the object 5;
>
> - the name "x" (names are not values in Python at runtime, but they 
>   are entities which exist in Python source code at compile time).
>
> The third entity is the reference linking the name to the object (the arrow).
> This isn't a runtime value in Python, nor is it a compile time entity that
> exists in source code. It is pure implementation, and as such, exists outside
> of the Python domain.
>
> I'm not saying that we should never use this model. Its a good model. But we
> should be clear that it is a model of the implementation, and it describes
> entities which are not part of the Python language. We cannot do this:
>
>
>  +-+
>  | |
>  |  5  |
>  | |
>  +-+
> ^
> |
>
> ^
> |
>
>
>
> or any of the other things we can do in a language with references-as-values,
> like C or Pascal.

I don't agree that the above is an accurate picture of C or Pascal. It is more
like the following:

 +-+ +-+
 | | | |
 |  5  |<+--*  |
 | | | |
 +-+ +-+
^   ^
|   |


And in case of a VAR parameter in Pascal like 

procedure f(VAR x);
f(y)

one could use the following, which is the same
as after an assignment in python.


  +-+
  | |
  |  7  |
--->  | |
   /  +-+
  /
 /   ^
/|
 


-- 
Antoon Pardon

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


Re: A question on modification of a list via a function invocation

2017-09-05 Thread Steven D'Aprano
On Wed, 06 Sep 2017 01:04:17 +0300, Marko Rauhamaa wrote:

> Chris Angelico :
> 
>> That shows that the Java '==' operator is like the Python 'is'
>> operator, and checks for object identity. You haven't manipulated
>> pointers at all. In contrast, here's a C program that actually
>> MANIPULATES pointers:
>>
>> [...]
>>
>> You can't do this with Python, since pointer arithmetic fundamentally
>> doesn't exist. You can in C. Can you in Java?

A necessary (but not sufficient) condition to be able to do pointer 
arithmetic is to actually have pointers as a data type.

Pointers are not a data type in either Python or Java, so of course you 
can't do pointer arithmetic on them. If you don't have a pointer, you 
can't do arithmetic on it.

Pointer arithmetic itself is not the issue. Java could have been like 
standard Pascal, and allow pointers as a first class data type (you can 
assign them to variables, pass them to functions, return them, have 
pointers to pointers, etc) without allowing pointer arithmetic. But they 
didn't -- Java the language doesn't include pointers as a value at all.

 
> You can't do it in Pascal, either, but Pascal definitely has pointers.

Not in standard Pascal, but most actual Pascal compilers let you perform 
pointer arithmetic.




-- 
Steven D'Aprano
“You are deluded if you think software engineers who can't write 
operating systems or applications without security holes, can write 
virtualization layers without security holes.” —Theo de Raadt
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: A question on modification of a list via a function invocation

2017-09-05 Thread Steven D'Aprano
On Tue, 05 Sep 2017 21:17:30 -0700, Rustom Mody wrote:

> Sure you can say with Steven that this can be 'explained' by saying an
> object can be in two places at one time.
> Others would then say 'Humpty-dumpty!' since you have removed the most
> basic intuition of objects and you are in effect saying that a python
> object means what you ordain it means without further ado/explanation

I have previously agreed that the "multiple places at once" metaphor is 
not to everyone's liking.

But many (perhaps even most) people have no problem dealing with location 
as a metaphor, where being in two places (metaphorically) is no problem 
at all:

- I am in love, in trouble and in denial all at once.

Even when the location is not a state of being but an actual physical 
place, we can be in multiple places at once:

- I am in my home, in Melbourne, and in Australia all at once.

Being in two places at once is a common trope in both fantasy and science 
fiction (often involving time travel). These are not niche genres: they 
are *extremely* popular. One of the Harry Potter movies involved Harry, 
Ron and Hermoine travelling backwards in time a few minutes to watch 
themselves. It's a moderately common trope in stories like Doctor Who, 
where the Doctor frequently interacts with his past (or future) self. I 
recently saw an episode of Dark Matter that used the trope.

Robert Heinlein, one of the greats of SF, wrote a number of classic time 
travel stories involving people being in multiple places at once. (In one 
of them, the protagonist has a sex change and becomes *both* his own 
grandfather and grandmother.)

An object being inside itself is rarer, but its been done at least twice 
that I know of in Doctor Who.

Don't underestimate people's ability to stretch the location metaphor 
beyond actual physical location. We do it all the time for virtual 
locations like IRC channels:

- I'm in #python, #ruby and #javascript all at once.

But if the metaphor isn't for you, I'm not saying you have to use it.



-- 
Steven D'Aprano
“You are deluded if you think software engineers who can't write 
operating systems or applications without security holes, can write 
virtualization layers without security holes.” —Theo de Raadt
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: A question on modification of a list via a function invocation

2017-09-05 Thread Steven D'Aprano
On Wed, 06 Sep 2017 03:42:31 +, Stefan Ram wrote:

>   Well, this /is/ from the PRL:
> 
>   »An object's identity never changes once it has been created;
>   you may think of it as the object's address in memory.«.
>  ¯¯
> - The Python Language Reference, Release 3.6.0;
> 3.1 Objects, values and types
> 
>   It's not called "reference", it's called "identity". But it might
>   agree with your idea of a pointer of an implementation.
>   And you /can/ print it.
> 
 print( id( 'abc' ))
> 4163144


I just tried that in my handy Python interpreter:


steve@runes:~$ jython
Jython 2.5.3 (, Jun 21 2017, 18:05:17) 
[OpenJDK 64-Bit Server VM (Oracle Corporation)] on java1.7.0_151
Type "help", "copyright", "credits" or "license" for more information.
>>> print id("abcd")
2
>>> print id("abcd")
3
>>> print id(None)
4


Do they look like pointers or references to you? They don't to me. I'm 
not aware of any machine where pointers can point to odd numbers 
(although there probably are some) and I'm certainly not aware of any 
where consecutive pointers differ by 1.


I think the manual is badly worded. It is true that we *can* think of IDs 
as the address of objects in memory, we *shouldn't* because that's 
misleading and tempts the reader to draw the wrong conclusion.

IDs in Python are arbitrary integers. They have no meaning except to be 
distinct for any two objects existing at the same time.



-- 
Steven D'Aprano
“You are deluded if you think software engineers who can't write 
operating systems or applications without security holes, can write 
virtualization layers without security holes.” —Theo de Raadt
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: A question on modification of a list via a function invocation

2017-09-05 Thread Marko Rauhamaa
Rustom Mody :

> On Wednesday, September 6, 2017 at 3:34:41 AM UTC+5:30, Marko Rauhamaa wrote:
>> Pointer arithmetics is not an essential part of C. One could argue that
>> it was a mistake to include it in the language.
>
> This is subjective of course… but still I wonder where you are coming from…
>
> You of course know that writing Unix was the genesis and raison d'être
> for C right?
>
> And what is an OS but a thin layer of abstraction on top of bare ISP?
> ie is not a Linux-OS just an x86 hw + some new ‘instructions’ called
> system-calls?

BASIC doesn't have any pointers at all, but it has PEEK and POKE.


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


Re: A question on modification of a list via a function invocation

2017-09-05 Thread Rustom Mody
On Wednesday, September 6, 2017 at 9:55:10 AM UTC+5:30, Chris Angelico wrote:
> On Wed, Sep 6, 2017 at 2:17 PM, Rustom Mody wrote:
> > Well ⅓ the point of pointers may be printing them out — which even in a 
> > language
> > with 1st class pointers like C is rarely done/needed
> 
> But still the useless part. You don't actually *achieve* anything by
> printing out the pointer.
> 
> > Another ⅓ is dereferencing, pointer-arithmetic etc... the various 
> > manifestations
> > of 1st-class pointers
> 
> This is the part that matters.
> 
> > And the third ⅓ is to provide explanations to people asking authentic 
> > questions
> > [like the OP of this thread]
> 
> Only questions that actually relate to one of the previous parts.

[dangling pointer ?¿?¿ ]

> 
> > Sure you can say with Steven that this can be 'explained' by saying an 
> > object
> > can be in two places at one time.
> > Others would then say 'Humpty-dumpty!' since you have removed the most basic
> > intuition of objects and you are in effect saying that a python object
> > means what you ordain it means without further ado/explanation
> >
> > Since you believe a reference-less dictionary can be a model for such 
> > explanations,
> > why not provide that?
> 
> A piece of paper works just fine. However, it's hard to use that
> method of explanation in an email.

I am ready to bet that if ASCII is insufficient then you are drawing pictures

You can call them whatever you like
- pointers, references
- data structure diagrams
- graphs vertices, edges
- I think I'll call them Antoon-art in honor of Antoon Pardon who has the 
  patience to draw them

I believe it was Marko Rauhamaa who have another half dozen metaphors:
- doggies and pussies er.. sorry leashes

Whatever you use, you will have to reify in your explanation the idea of
pointer/graph-edge/etc even and especially because, the language disallows such
a reification
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: A question on modification of a list via a function invocation

2017-09-05 Thread Chris Angelico
On Wed, Sep 6, 2017 at 2:17 PM, Rustom Mody  wrote:
> Well ⅓ the point of pointers may be printing them out — which even in a 
> language
> with 1st class pointers like C is rarely done/needed

But still the useless part. You don't actually *achieve* anything by
printing out the pointer.

> Another ⅓ is dereferencing, pointer-arithmetic etc... the various 
> manifestations
> of 1st-class pointers

This is the part that matters.

> And the third ⅓ is to provide explanations to people asking authentic 
> questions
> [like the OP of this thread]

Only questions that actually relate to one of the previous parts.

> Sure you can say with Steven that this can be 'explained' by saying an object
> can be in two places at one time.
> Others would then say 'Humpty-dumpty!' since you have removed the most basic
> intuition of objects and you are in effect saying that a python object
> means what you ordain it means without further ado/explanation
>
> Since you believe a reference-less dictionary can be a model for such 
> explanations,
> why not provide that?

A piece of paper works just fine. However, it's hard to use that
method of explanation in an email.

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


Re: A question on modification of a list via a function invocation

2017-09-05 Thread Rustom Mody
On Wednesday, September 6, 2017 at 9:22:15 AM UTC+5:30, Chris Angelico wrote:
> On Wed, Sep 6, 2017 at 1:42 PM, Stefan Ram wrote:
> > Steve D'Aprano writes:
> >>So in what sense are references part of the Python language?
> >
> >   It would be possible to describe Python using a concept
> >   called "reference", it's just that the The Python Language
> >   Reference, Release 3.6.0 (PRL) does /not/ do this.
> >   And programming language experts usually use the terms that
> >   the language specification uses with the meaning that the
> >   language specification is giving them. And this is why I say
> >   that JavaScript and Python do not have references.
> >   (Except "attribute references".)
> >
> >>Inside the interpreter, you (probably?) could print out the value of the
> >>pointer, or manipulate it in some fashion.
> >
> >   Well, this /is/ from the PRL:
> >
> >   »An object's identity never changes once it has been created;
> >   you may think of it as the object's address in memory.«.
> >  ¯¯
> > - The Python Language Reference, Release 3.6.0;
> > 3.1 Objects, values and types
> >
> >   It's not called "reference", it's called "identity". But it
> >   might agree with your idea of a pointer of an implementation.
> >   And you /can/ print it.
> >
>  print( id( 'abc' ))
> > 4163144
> 
> Printing out an address is only half the point (pun intended) of a
> pointer - and the useless half. Given a pointer, you need to be able
> to dereference it. How can you, given the id of a Python object,
> access the object itself? The nearest I've ever seen is a function
> that searches every object it can find, looking for one with the same
> id.

Well ⅓ the point of pointers may be printing them out — which even in a 
language 
with 1st class pointers like C is rarely done/needed

Another ⅓ is dereferencing, pointer-arithmetic etc... the various manifestations
of 1st-class pointers

And the third ⅓ is to provide explanations to people asking authentic questions
[like the OP of this thread]

Sure you can say with Steven that this can be 'explained' by saying an object
can be in two places at one time.
Others would then say 'Humpty-dumpty!' since you have removed the most basic
intuition of objects and you are in effect saying that a python object
means what you ordain it means without further ado/explanation

Since you believe a reference-less dictionary can be a model for such 
explanations,
why not provide that?
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: A question on modification of a list via a function invocation

2017-09-05 Thread Chris Angelico
On Wed, Sep 6, 2017 at 1:42 PM, Stefan Ram  wrote:
> Steve D'Aprano  writes:
>>So in what sense are references part of the Python language?
>
>   It would be possible to describe Python using a concept
>   called "reference", it's just that the The Python Language
>   Reference, Release 3.6.0 (PRL) does /not/ do this.
>   And programming language experts usually use the terms that
>   the language specification uses with the meaning that the
>   language specification is giving them. And this is why I say
>   that JavaScript and Python do not have references.
>   (Except "attribute references".)
>
>>Inside the interpreter, you (probably?) could print out the value of the
>>pointer, or manipulate it in some fashion.
>
>   Well, this /is/ from the PRL:
>
>   »An object's identity never changes once it has been created;
>   you may think of it as the object's address in memory.«.
>  ¯¯
> - The Python Language Reference, Release 3.6.0;
> 3.1 Objects, values and types
>
>   It's not called "reference", it's called "identity". But it
>   might agree with your idea of a pointer of an implementation.
>   And you /can/ print it.
>
 print( id( 'abc' ))
> 4163144

Printing out an address is only half the point (pun intended) of a
pointer - and the useless half. Given a pointer, you need to be able
to dereference it. How can you, given the id of a Python object,
access the object itself? The nearest I've ever seen is a function
that searches every object it can find, looking for one with the same
id.

I *might* be able to accept the argument that pointer arithmetic isn't
important (though I'm still of the opinion that without arithmetic,
they're just references/name bindings), but if you want to say that
the id() of a Python object is its pointer, you MUST demonstrate this
more basic feature.

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


Re: A question on modification of a list via a function invocation

2017-09-05 Thread Steve D'Aprano
On Tue, 5 Sep 2017 11:11 pm, Gregory Ewing wrote:

> Steve D'Aprano wrote:
>> The third entity is the reference linking the name to the object (the arrow).
>> This isn't a runtime value in Python, nor is it a compile time entity that
>> exists in source code. It is pure implementation, and as such, exists outside
>> of the Python domain.
> 
> The fact that there is a connection between the name and the
> object is very much part of Python's abstract semantics.
> 
> There are different ways to implement that connection, but
> *any* implementation of Python has to include *some*
> representation of it.

Any *what* of Python? Oh, that's right, you said any *implementation* of Python.

Isn't that what I said? That references are a property of the implementation,
not of the language. You are inadvertently agreeing with me.

- You can't bind a reference to a name in Python. Names are always bound to
objects. 

- You can't have a list or set of references, only lists or sets of objects.

- You can't form a reference to a reference.

- You can't use references to implement pass-by-reference semantics.

- You can't view or inspect references in Python (maybe in ctypes, 
  or in a debugger, but those aren't part of the Python language, 
  they are implementation-specific interfaces to the interpreter).


So in what sense are references part of the Python language?

My answer is that they are not. They're a part of the implementation, which
makes them different from values (ints, floats, strings, lists, and other
objects, whether built-in or not). It makes them different from other
conceptual entities in Python like for-loops, comprehensions, try...except
blocks etc, which aren't values but they are properties of the program (at
least of the source code, if not the byte code).


> There are also different words that can be used to describe
> it. You can say that names are bound to objects, or that
> names refer to objects, or that names hold references to
> objects.

As they used to say in Sesame Street, "One of these things is not like the
others..."


The first two describe a *relationship* between two entities, the name and the
object: being bound to, referring to, are verbs which indicate a relationship.

The third introduces a third entity. There's now two relationships:

- names hold (are bound to, point to) references;

- references refer to (are bound to, point to) objects.

That's an example of reification, "making real", taking an abstract concept or
relationship or verb and treating it as a thing. We often do that in poetic
language: we talk of death or hunger stalking the streets.

In this case, its a bit more complicated because *in a sense* you are right.
Inside the interpreter, there really is a data structure which we might call a
reference: in CPython its a pointer. So you are not entirely being poetic here.
Inside the interpreter, you (probably?) could print out the value of the
pointer, or manipulate it in some fashion.

But at the level of Python code, you are reifying a relationship into a thing.
In Python code, names are bound to objects, and the implementation of that
binding is not part of the language itself. References aren't things, any more
than fatherhood or treason are things (they are states of being that describe a
certain relationships).

That's because Python describes a virtual machine which is abstracted further
away from the machine than C. Part of that abstraction is to remove pointers
(references) from the set of values available to Python code to manipulate.


> These are all equally good ways of talking about 
> the exact same abstract concept.

No they aren't equally good, not if they lead to confusion and terminology
abuse. Earlier I linked to a Stackoverflow question about Java, asking how to
find the address of variables. It must be easy, right, because Java variables
hold pointers to some address. (Actually, no they don't.)

In Python, we still have people asking from time to time how to dereference
pointers (references), or how to pass an int by reference, or a list by value
(making a copy). It must be possible, because Python is pass-by-value for some
values and pass-by-reference for others, right? (No.)

I'm not opposed to the "reference" concept in general. I just want people to be
more clear about what level of abstraction you are talking about when you use
it. I don't want people to say that Python (the language) has references or
pointers, because it doesn't. I don't have any objection to people saying that
the interpreter has references or pointers, and that's how name binding works
behind the scenes, or under the hood.

And I categorically *hate* explanations of Python's argument parsing that
require people to simultaneously believe that the value of x following x=1 is:

1

(the meaning of "value" they actually use in practice), and:

some invisible, unknown, unknowable, implementation-dependent
reference to the actual value

(the meaning they insist 

Re: A question on modification of a list via a function invocation

2017-09-05 Thread Rustom Mody
On Wednesday, September 6, 2017 at 3:34:41 AM UTC+5:30, Marko Rauhamaa wrote:
> Chris Angelico :
> 
> > That shows that the Java '==' operator is like the Python 'is'
> > operator, and checks for object identity. You haven't manipulated
> > pointers at all. In contrast, here's a C program that actually
> > MANIPULATES pointers:
> >
> > [...]
> >
> > You can't do this with Python, since pointer arithmetic fundamentally
> > doesn't exist. You can in C. Can you in Java?
> 
> You can't do it in Pascal, either, but Pascal definitely has pointers.
> 
> Pointer arithmetics is not an essential part of C. One could argue that
> it was a mistake to include it in the language.

This is subjective of course… but still I wonder where you are coming from…

You of course know that writing Unix was the genesis and raison d'être for C 
right?

And what is an OS but a thin layer of abstraction on top of bare ISP?
ie is not a Linux-OS just an x86 hw + some new ‘instructions’ called
system-calls?

Which is to say IMHO being able to punch holes into the hi-level-language 
abstraction seems to be a sine qua non for being suitable as a language for 
writing OSes.
Do you think its reasonable/feasible to do that without easy access to all the 
machine resources eg memory, IO, interrupts etc accessible in the OS-writing 
language?

[BTW I think Microsoft has done a better job than classic C of repeating this 
with C# — C# is almost as high-level as python, lisp etc and as low (or lower)
than C; ie it is effectively two languages, called ‘safe’ and ‘unsafe’ parts
]
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: A question on modification of a list via a function invocation

2017-09-05 Thread Grant Edwards
On 2017-09-05, Marko Rauhamaa  wrote:

> Pointer arithmetics is not an essential part of C. One could argue that
> it was a mistake to include it in the language.

One may argue that it was a mistake, but I remember at least one
implementation where pointer arithmetic was hugely more efficient than
indexing into arrays.  Incrementing a pointer through an array was
way, way faster than indexing through the array by incrementing an
array subscript.

But, that was 25 years ago on an 8-bit CPU where where integer
multiplies were expensive.  The last time I compare the two methods
with a recent GCC on a 32-bit CPU, it generated pretty much the same
code either way...

-- 
Grant Edwards   grant.b.edwardsYow! Someone in DAYTON,
  at   Ohio is selling USED
  gmail.comCARPETS to a SERBO-CROATIAN

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


Re: A question on modification of a list via a function invocation

2017-09-05 Thread Marko Rauhamaa
Chris Angelico :

> That shows that the Java '==' operator is like the Python 'is'
> operator, and checks for object identity. You haven't manipulated
> pointers at all. In contrast, here's a C program that actually
> MANIPULATES pointers:
>
> [...]
>
> You can't do this with Python, since pointer arithmetic fundamentally
> doesn't exist. You can in C. Can you in Java?

You can't do it in Pascal, either, but Pascal definitely has pointers.

Pointer arithmetics is not an essential part of C. One could argue that
it was a mistake to include it in the language.


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


Re: A question on modification of a list via a function invocation

2017-09-05 Thread Chris Angelico
On Wed, Sep 6, 2017 at 6:42 AM, Stefan Ram  wrote:
> Chris Angelico  writes:
>>here's a C program that actually MANIPULATES pointers:
> ...
>>x += 2;
> ...
>>You can in C. Can you in Java?
>
>   »dog = null« in Java would correspond to »x = 0« in C.
>
>   It seems, to you, an assignment of »x + 2« to »x« is
>   "manipulation", while an assignment of »0« to »x« is not.
>
>   Well, if you define the term "manipulation" to get the
>   results you intend, no one can prove you wrong, but your
>   words might be harder to understand when they do not use
>   the English meanings of words (like "manipulate") but your
>   ad-hoc meanings.
>

dog = null in Java corresponds to x = None in Python. It's a null
reference, but that's still a specific "thing". A fully compliant
Python implementation could use a NULL pointer to represent the None
object, as long as it correspondingly interprets such a pointer as
representing None.

In all of your Java examples, you're causing a name to refer to either
an object or null, and everything you do can be explained in terms of
name bindings Python-style.

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


Re: A question on modification of a list via a function invocation

2017-09-05 Thread Chris Angelico
On Wed, Sep 6, 2017 at 5:48 AM, Stefan Ram  wrote:
>   Depends on the meaning of "meaningful". In Java, one can
>   inspect and manipulate pointers like in this program for
>   example:
> [chomp code]

That shows that the Java '==' operator is like the Python 'is'
operator, and checks for object identity. You haven't manipulated
pointers at all. In contrast, here's a C program that actually
MANIPULATES pointers:

#include 
void do_stuff(int *x)
{
printf("x (%p) points to %d\n", x, *x);
x += 2;
printf("Now x (%p) points to %d\n", x, *x);
}
int main()
{
int x[3] = {28, 42, 79};
do_stuff(x); /* or do_stuff(&x[0]); */
return 0;
}

You can't do this with Python, since pointer arithmetic fundamentally
doesn't exist. You can in C. Can you in Java?

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


Re: A question on modification of a list via a function invocation

2017-09-05 Thread MRAB

On 2017-09-05 20:08, Steve D'Aprano wrote:

On Tue, 5 Sep 2017 11:47 pm, Gregory Ewing wrote:


Steve D'Aprano wrote:

[quoting Scott Stanchfield]
Figure 7: (Java) Defining a Dog pointer
Dog d;

When you write that definition, you are defining a pointer to a Dog
object, not a Dog object itself.
[end quote]

Here Scott mixes up what the compiler does (creates a pointer to a Dog
object, and what the programmer's Java code does (creates a Dog).


Um, no. The declaration 'Dog d' on its own does NOT create a Dog,
in any way, shape or form. It only declares something that can
*refer* to a Dog created elsewhere, which is what Scott is
quite correctly saying.


That's not what he said. I quoted him: he quite clearly states that d defines a
pointer to a Dog object. He doesn't say that you're declaring an empty slot
that is waiting to be filled with a pointer to a dog. He says it defines a
pointer.

So which Dog object does this pointer point to? Answer: there isn't one. There
may not even be any Dog object existing in the entire program up to this point.

Even allowing that there were a Dog to be pointed to, how do we inspect or
manipulate that pointer? Answer: you can't, because pointers are not meaningful
values in Java.

There's no(?) Java code you can write that allows this:

 Dog d;
 java.lang.System.out.println( address of variable d );
 java.lang.System.out.println( address of the Dog d points to );

Maybe compiler-specific debugging tools? I don't know enough Java to
*categorically* rule it out, but if it exists at all, it would be unsafe to
rely on the addresses you get.


d is initialised to null. You can check for null:

if (d == null)
java.lang.System.out.println("There's no dog.");
else
d.bark();
--
https://mail.python.org/mailman/listinfo/python-list


Re: A question on modification of a list via a function invocation

2017-09-05 Thread Chris Angelico
On Wed, Sep 6, 2017 at 5:28 AM, Dennis Lee Bieber  wrote:
> On 5 Sep 2017 17:57:18 GMT, r...@zedat.fu-berlin.de (Stefan Ram) declaimed
> the following:
>
>>  But what does "a C++ reference" refer to?
>>
>
> Per Stroustrup (The C++ Programming Language 4th Ed, page 189)
>
> """
> * ...
> * A reference always refers to the object to which it was initialized.
> * ...
>
> A reference is an alternative name for an object, an alias. ...
> """
>
> {Hmmm, and I see that the syntax can be used outside of parameter
> declaration -- which is the only place I'd seen it previously... either
> this is a change from earlier standards, or my classes just didn't feel the
> need to expose a non-parameter reference -- since, based upon the above
> book, you can not declare a bare reference "variable"; it MUST be
> initialized with a real object.}

Outside of parameters, there's very little practical reason for
aliases. Their primary value is that an internal name can be an alias
for an external object, which is achieved with reference parameters.

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


Re: A question on modification of a list via a function invocation

2017-09-05 Thread Steve D'Aprano
On Tue, 5 Sep 2017 11:47 pm, Gregory Ewing wrote:

> Steve D'Aprano wrote:
>> [quoting Scott Stanchfield]
>> Figure 7: (Java) Defining a Dog pointer
>> Dog d;
>> 
>> When you write that definition, you are defining a pointer to a Dog
>> object, not a Dog object itself.
>> [end quote]
>> 
>> Here Scott mixes up what the compiler does (creates a pointer to a Dog
>> object, and what the programmer's Java code does (creates a Dog).
> 
> Um, no. The declaration 'Dog d' on its own does NOT create a Dog,
> in any way, shape or form. It only declares something that can
> *refer* to a Dog created elsewhere, which is what Scott is
> quite correctly saying.

That's not what he said. I quoted him: he quite clearly states that d defines a
pointer to a Dog object. He doesn't say that you're declaring an empty slot
that is waiting to be filled with a pointer to a dog. He says it defines a
pointer.

So which Dog object does this pointer point to? Answer: there isn't one. There
may not even be any Dog object existing in the entire program up to this point.

Even allowing that there were a Dog to be pointed to, how do we inspect or
manipulate that pointer? Answer: you can't, because pointers are not meaningful
values in Java.

There's no(?) Java code you can write that allows this:

Dog d;
java.lang.System.out.println( address of variable d );
java.lang.System.out.println( address of the Dog d points to );

Maybe compiler-specific debugging tools? I don't know enough Java to
*categorically* rule it out, but if it exists at all, it would be unsafe to
rely on the addresses you get.

You're right that I made a mistake. I'm not a Java expert like Scott
Stanchfield, and I was led astray by his misleading explanation, and failed to
notice that d didn't have a value. (What's his excuse for not noticing?)

As Stefan already pointed out, the code Scott gives does not define a value, but
is just a declaration of a variable name. At that point, d has no value at all,
and you get a compile time error if you try to access d. There is no Dog, and
no pointer to a Dog. There's just a name (or variable if you prefer).

So what's the value of d? It doesn't have one. Scott's explanation is
misleading: `Dog d;` does not define *any value at all*, let alone a pointer.

I daresay that Scott could attempt to justify his wording. I imagine it might go
something like this:


Of course d is a pointer to a value. The Java compiler keeps a table
mapping variable names to memory addresses, and the name 'd' is mapped
to some address in the table. That address must hold some value, even
if it is uninitialised memory filled with arbitrary bytes. That address
is a (possibly null, possibly invalid) pointer to a Dog object.
-- Me, channelling what I think Scott *might* say.

Notice how this mixes *three* different abstractions? There's the top-level Java
abstraction, where we declare d as a Dog. There's the compiler abstraction,
where we talk about mapping variable names to memory addresses, and pointers to
Dog objects. And there's an even lower abstraction, where we talk about memory
filled with arbitrary bytes.

And so long as we keep track of which abstraction we're in, this is fine. It
doesn't even have to be explicit: once people gain enough experience, they can
effortlessly and implicitly swap between abstractions and not even notice.
That's sometimes a good thing, but its a bad thing when we lose track of the
abstraction level and confuse others (like me!), or even ourselves, and lead
to "Not Even Wrong" questions like this:

https://stackoverflow.com/questions/1961146/memory-address-of-variables-in-java

(Likewise for people thinking that id() in Python returns a memory address, and
ask how to dereference that address.)

Not all explanations are equally useful, even if they are correct for some
definition of "correct".


In Python, the equivalent to Scott's code `Dog d;` would be something like this:

# --- %< ---

class Dog:
pass

global x
assert isinstance(x, Dog)

# --- %< ---

except that we get a runtime NameError instead of a compile-time error. Would
you like to say that this code "defines a pointer to a Dog"? I should hope not.
How is it different from Scott's example of `Dog d;`?



>> I expect this is because, as a "compiler guy", Scott probably doesn't really
>> believe that objects are values.
> 
> Please stop insulting Scott's intelligence, and that of other
> "compiler guys", by suggesting that they don't understand things
> as well as you do.

Why shouldn't I suggest that Scott got something wrong? What makes him, and
other "compiler guys", so special that they are infallible and can't make
mistakes? Argument by authority is at best the weakest form of argument, if it
isn't an outright fallacy.

https://en.wikipedia.org/wiki/Argument_from_authority

I'm not questioning his intelligence. I'm questioning his *perspective*, and his
failure to distinguish between different lev

Re: A question on modification of a list via a function invocation

2017-09-05 Thread Ned Batchelder


On 9/5/17 1:28 PM, Chris Angelico wrote:
> On Wed, Sep 6, 2017 at 3:15 AM, Ned Batchelder  wrote:
>> On 9/5/17 1:02 PM, Steve D'Aprano wrote:
>>> On Tue, 5 Sep 2017 11:37 pm, Gregory Ewing wrote:
>>>
 Dennis Lee Bieber wrote:
> Pascal, probably Modula-2, Visual BASIC are closer to the C++ reference
> semantics, in that the definition of a function declares how the
> argument(s) are passed.
 Well, sort of. In Pascal and Modula, and also VB I think,
 parameters are the only things that can be declared as having
 reference semantics, whereas references in C++ are first-class
 things that can be stored in any variable.
>>> No, they aren't first-class.
>> Did you mis-read Gregory's claim? He said, "references *in C++* are
>> first-class things".  You seem to be talking below about Python things.
>>
> And everything Steve said was about C++ references, which are a form
> of alias. Not a 'thing'.

I see, I misunderstood. Sorry for the distraction.

>
> ChrisA

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


Re: A question on modification of a list via a function invocation

2017-09-05 Thread Rustom Mody
On Tuesday, September 5, 2017 at 10:45:45 PM UTC+5:30, Ned Batchelder wrote:
> On 9/5/17 1:02 PM, Steve D'Aprano wrote:
> > On Tue, 5 Sep 2017 11:37 pm, Gregory Ewing wrote:
> >
> >> Dennis Lee Bieber wrote:
> >>> Pascal, probably Modula-2, Visual BASIC are closer to the C++ reference
> >>> semantics, in that the definition of a function declares how the
> >>> argument(s) are passed.
> >> Well, sort of. In Pascal and Modula, and also VB I think,
> >> parameters are the only things that can be declared as having
> >> reference semantics, whereas references in C++ are first-class
> >> things that can be stored in any variable.
> > No, they aren't first-class. 
> 
> Did you mis-read Gregory's claim? He said, "references *in C++* are
> first-class things".  You seem to be talking below about Python things.

I think its mostly true of C++
And Steven did say:

(I don't know enough about C++ to distinguish between the last two opinions, but
I'm strongly leaning towards "not values at all".) 

So he seems to be talking of C++ (as analogous to python??)

But I dont see that any of it is relevant

Whether references are 
- first-class (Algol-68, pointers-in-C) or are simply
- second class (C++)
- invisible (python, lisp, ruby, javascript)

has little to do with what we are talking

The question is whether we need the *idea* of references
(modulo humpty-dumpty-fication)
to talk *about* the language; ie it needs to be there in the human/informal
ontology, even if the docs play word-games and try to avoid trigger-words
in honour of PC.

In my view its almost the defining quality of imperative languages that
the semantics of the language is not properly/fully comprehensive without
(something like) references.

[Replace "imperative language" with "assignment and mutation" if you like]
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: A question on modification of a list via a function invocation

2017-09-05 Thread Chris Angelico
On Wed, Sep 6, 2017 at 3:15 AM, Ned Batchelder  wrote:
> On 9/5/17 1:02 PM, Steve D'Aprano wrote:
>> On Tue, 5 Sep 2017 11:37 pm, Gregory Ewing wrote:
>>
>>> Dennis Lee Bieber wrote:
 Pascal, probably Modula-2, Visual BASIC are closer to the C++ reference
 semantics, in that the definition of a function declares how the
 argument(s) are passed.
>>> Well, sort of. In Pascal and Modula, and also VB I think,
>>> parameters are the only things that can be declared as having
>>> reference semantics, whereas references in C++ are first-class
>>> things that can be stored in any variable.
>> No, they aren't first-class.
>
> Did you mis-read Gregory's claim? He said, "references *in C++* are
> first-class things".  You seem to be talking below about Python things.
>

And everything Steve said was about C++ references, which are a form
of alias. Not a 'thing'.

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


Re: A question on modification of a list via a function invocation

2017-09-05 Thread Steve D'Aprano
On Tue, 5 Sep 2017 11:08 pm, Stefan Ram wrote:

> Steve D'Aprano  writes:
>>[quote]
>>The mistake they make is in the definition of
>>Figure 7: (Java) Defining a Dog pointer
>>Dog d;
>>itself. When you write that definition, you are defining a pointer to a Dog
>>object, not a Dog object itself.
>>[end quote]
>>Here Scott mixes up what the compiler does (creates a pointer to a Dog object,
>>and what the programmer's Java code does (creates a Dog).
> 
>   I have not the whole context in mind, and so I might get
>   something wrong here, but if
> 
> Dog d;
> 
>   is supposed to be interpreted as Java, then it neither
>   creates a pointer to a Dog object nor it creates a Dog.
> 
>   Instead, it declares an unitialized variable d.


Thank you Stefan, your correction is noted. I'm not a Java expert like Scott,
and I failed to notice the distinction between:

Dog d;

and

Dog d = new Dog();

so I failed to realise that of course d has no value at all in Scott's example.




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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


Re: A question on modification of a list via a function invocation

2017-09-05 Thread Ned Batchelder
On 9/5/17 1:02 PM, Steve D'Aprano wrote:
> On Tue, 5 Sep 2017 11:37 pm, Gregory Ewing wrote:
>
>> Dennis Lee Bieber wrote:
>>> Pascal, probably Modula-2, Visual BASIC are closer to the C++ reference
>>> semantics, in that the definition of a function declares how the
>>> argument(s) are passed.
>> Well, sort of. In Pascal and Modula, and also VB I think,
>> parameters are the only things that can be declared as having
>> reference semantics, whereas references in C++ are first-class
>> things that can be stored in any variable.
> No, they aren't first-class. 

Did you mis-read Gregory's claim? He said, "references *in C++* are
first-class things".  You seem to be talking below about Python things.

>
> - It is not possible to refer to a reference after it is defined; any 
>   occurrence of its name refers directly to the object it references.
>
> - Since you cannot refer directly to a reference, but only the object
>   it points to, you cannot have a reference to a reference.
>
> - Containers of references are not allowed.
>
> - Once a reference to an object is created, it cannot be changed to 
>   reference another object ("to be reseated").
>
> The last is only a limitation if you think of references as mutable pointers 
> in
> the C sense. But if you think of them as objects in the Python sense, that
> makes them merely immutable.
>
> But the inability to refer to the reference itself, the lack of references to
> references, and the inability to have a container of references, makes them
> second-class values -- or possibly not values at all.
>
> (I don't know enough about C++ to distinguish between the last two opinions, 
> but
> I'm strongly leaning towards "not values at all".)
>
>
>

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


Re: A question on modification of a list via a function invocation

2017-09-05 Thread Steve D'Aprano
On Tue, 5 Sep 2017 11:37 pm, Gregory Ewing wrote:

> Dennis Lee Bieber wrote:
>> Pascal, probably Modula-2, Visual BASIC are closer to the C++ reference
>> semantics, in that the definition of a function declares how the
>> argument(s) are passed.
> 
> Well, sort of. In Pascal and Modula, and also VB I think,
> parameters are the only things that can be declared as having
> reference semantics, whereas references in C++ are first-class
> things that can be stored in any variable.

No, they aren't first-class. 

- It is not possible to refer to a reference after it is defined; any 
  occurrence of its name refers directly to the object it references.

- Since you cannot refer directly to a reference, but only the object
  it points to, you cannot have a reference to a reference.

- Containers of references are not allowed.

- Once a reference to an object is created, it cannot be changed to 
  reference another object ("to be reseated").

The last is only a limitation if you think of references as mutable pointers in
the C sense. But if you think of them as objects in the Python sense, that
makes them merely immutable.

But the inability to refer to the reference itself, the lack of references to
references, and the inability to have a container of references, makes them
second-class values -- or possibly not values at all.

(I don't know enough about C++ to distinguish between the last two opinions, but
I'm strongly leaning towards "not values at all".)



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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


  1   2   3   4   5   6   7   8   >