Re: Can Python function return multiple data?

[Dave Farrance]

Rustom Mody  wrote:

>On Saturday, June 6, 2015 at 10:20:49 AM UTC+5:30, Steven D'Aprano wrote:
>> On Sat, 6 Jun 2015 01:20 pm, Rustom Mody wrote:
>> > As a parallel here is Dijkstra making fun of AI-ers use of the word
>> > 'intelligent'
>> >  http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD618.html
>> 
>> Nice rant, but as is typical of so many rants by Dijkstra, it's overflowing
>> with smugness at his own cleverness, and very light on actual reasoning or
>> sense.
>
>The cleverness and smugness has made you miss the point:
>Post-computers 'intelligent' has a new meaning on account of abuse of langauge

Hmm.  I've just read that and I have to say that I've no idea what point
the author was trying to make -- presumably because I'm not intelligent
enough.  I get that he's doing his best to make "Artificial
Intelligentsia" a pejorative term for some reason, but exactly what he's
got against this (imagined?) community or exactly what he imagines their
sin to be is hard to figure out.  I'll note that my own observation of
the common usage of the term "intelligent" in the mentioned context is
that you might indeed describe a terminal an "intelligent terminal" if
it has processor functions, but if you were to describe it as a
"terminal with artificial intelligence", then that would imply a whole
lot more -- which is indeed a language oddity, but that seems to be the
way it is now.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to inverse a particle emitter

[Chris Angelico]

On Sat, Jun 6, 2015 at 10:10 AM, Dennis Lee Bieber
 wrote:
> That is in the same class as the "lunar lander" game on my college
> mainframe...
>
> It did not do validity checking of inputs, with the result that one
> could do
>
> -10 lbs thrust at 180 degrees
>
> and GAIN fuel while decelerating.

Hah! The version I played didn't allow you to specify 180 degrees,
although it did allow negative burns. So you could tweak your fuel
supply by careful negative burning, but it required some balancing
work to actually come to a safe landing.

Of course, if you wanted to just quit out in a hurry, all you have to
do is a straight-down burn of -999, and bam, you're on the ground,
with a Captain Haddock style of "We shall end up by arriving, I
suppose".

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

Re: Can Python function return multiple data?

[Chris Angelico]

On Sat, Jun 6, 2015 at 3:28 PM, Rustom Mody  wrote:
> You just repeated what Chris said, replacing 'immutable' with 'same'
> There was a list: [1,2,3]
> At some point that list is found to be(come) [1,2,3,4]
> They dont look same to me.

"I'm going shopping, can you get me the shopping list please?"
*goes and fetches a piece of paper from the kitchen*
"Wait, this isn't the right list! This one has more things on it!"

The question of whether or not the thing fetched is indeed the
shopping list is independent of the items on it. The list has an
identity and it has a value (the items needed). If I hand you an empty
list on the basis that the shopping list you placed there last week
was empty, I've destroyed the value of the posted shopping list -
people have added things to it during the week, and they expect those
things to be on the list that gets referenced to make purchases.

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

Re: Can Python function return multiple data?

[Rustom Mody]

On Saturday, June 6, 2015 at 10:20:49 AM UTC+5:30, Steven D'Aprano wrote:
> On Sat, 6 Jun 2015 01:20 pm, Rustom Mody wrote:
> > As a parallel here is Dijkstra making fun of AI-ers use of the word
> > 'intelligent'
> >  http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD618.html
> 
> Nice rant, but as is typical of so many rants by Dijkstra, it's overflowing
> with smugness at his own cleverness, and very light on actual reasoning or
> sense.

The cleverness and smugness has made you miss the point:
Post-computers 'intelligent' has a new meaning on account of abuse of langauge
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Can Python function return multiple data?

[Rustom Mody]

On Saturday, June 6, 2015 at 8:58:13 AM UTC+5:30, rand...@fastmail.us wrote:
> On Fri, Jun 5, 2015, at 23:20, Rustom Mody wrote:
> > The word immutuable happens to have existed in English before python.
> > I also happen to have used it before I knew of python
> > The two meanings do not match
> > I am surprised
> > Is that surprising?
> 
> They don't match only if you consider the objects a tuple references to
> be part of the tuple.
> 
> You cannot change the reference. It will always point to the same list.

You just repeated what Chris said, replacing 'immutable' with 'same'
There was a list: [1,2,3]
At some point that list is found to be(come) [1,2,3,4]
They dont look same to me.

IOW if immutable₂ is to have cognitive resonance with immutable₁ it needs to be
'deep-immutable' in analogy to deep-copy.

Anyways... All this is rather far from my original point
Python may or may not have genuine immutables and we may call skin-immutable 
as 'immutable'
We have muddled along thusly for the last 60 years and its called
'imperative programming'.

My point is that without a common conceptual basis there is neither
communication nor understanding.
That common base is usually called math/logic:
Your '1/2/3' matches mine
Your 'and/or/not' matches mine
They are immutable₁ therefore we can think and communicate with them

With [1,2,3] ([1,2],[1,2]) that is not the case
I regard that as unfortunate
[You are of course free to regard that as ok]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Can Python function return multiple data?

[Chris Angelico]

On Sat, Jun 6, 2015 at 2:50 PM, Steven D'Aprano  wrote:
> This does not happen:
>
> mylist = []
> mytuple = (None, 1, mylist)
> mylist.append(0)
> => raises an exception
>
> The *tuple* is immutable, not the list.

What you could have is a "FrozenList" (by analogy with frozenset),
something like this:

class FrozenList(tuple):
def __new__(*a, **kw):
self = tuple.__new__(*a, **kw)
hash(self) # If error, disallow construction
return self

That would raise the error at the moment of mytuple's creation, not at
mylist's mutation, but that's about as close as I can think of to a
"this truly must be immutable" object in Python. And of course, any
object can lie (or be mistaken) about its hashability and mutability:

>>> def adder(x, inc=1): return x+inc
...
>>> hash(adder)
-9223363254790714706
>>> FrozenList((adder,))
(,)
>>> descr = {adder: "Add 1 to a number"}

Looks immutable to me.

>>> adder.__defaults__=2,
>>> next(iter(descr))(6)
8

Oops.

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

Re: Can Python function return multiple data?

[Steven D'Aprano]

On Sat, 6 Jun 2015 01:20 pm, Rustom Mody wrote:

> On Saturday, June 6, 2015 at 3:30:23 AM UTC+5:30, Chris Angelico wrote:

>> Congrats! You just proved that an object can itself be immutable, but
>> can contain references to mutables. Ain't that awesome?
>> 
>> Did you have a point?
> 
> [Under assumption you are not being facetious...]
> The word immutuable happens to have existed in English before python.
> I also happen to have used it before I knew of python
> The two meanings do not match
> I am surprised
> Is that surprising?

Yes, I am surprised that you are surprised. You have been a regular, and
prolific, contributor on this forum for some years now, teach Python, blog
about it. You're quite obviously well-read and experienced. How is it that
you are surprised by such a fundamental part of not just Python's object
model, but of real life objects too?

I suspect you are pretending to be surprised to make a rhetorical point.

Like many English words, "immutable" has a few meanings in plain English.
Bouvier's Law Dictionary included in 1856 this definition:

IMMUTABLE. What cannot be removed, what is unchangeable.
The laws of God peing perfect, are immutable, but no 
human law can be so considered.

Clearly tuples can be removed. They are garbage-collected like any other
values in Python. If nothing else, you can turn the computer off, remove
the RAM, grind it down into the finest powder, and scatter it to the winds.
That surely is enough to remove the tuples  

So according to Bouvier's definition, tuples are not immutable. But I trust
that we can agree that Bouvier's definition is not useful here.

In object-oriented programming circles, including Python, the relevant
definition is that you cannot add or remove elements from the tuple once it
is instantiated. That is all. If those elements happen to be mutable
themselves, they don't cease to be mutable just because you happen to have
put them in a tuple. This does not happen:

mylist = []
mytuple = (None, 1, mylist)
mylist.append(0)
=> raises an exception

The *tuple* is immutable, not the list. The elements of the list are not
elements of the tuple and don't participate in the guarantee of
tuple-immutability.


> As a parallel here is Dijkstra making fun of AI-ers use of the word
> 'intelligent'
>  http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD618.html

Nice rant, but as is typical of so many rants by Dijkstra, it's overflowing
with smugness at his own cleverness, and very light on actual reasoning or
sense.


-- 
Steven

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

Re: Can Python function return multiple data?

[Chris Angelico]

On Sat, Jun 6, 2015 at 1:28 PM,   wrote:
> On Fri, Jun 5, 2015, at 23:20, Rustom Mody wrote:
>> The word immutuable happens to have existed in English before python.
>> I also happen to have used it before I knew of python
>> The two meanings do not match
>> I am surprised
>> Is that surprising?
>
> They don't match only if you consider the objects a tuple references to
> be part of the tuple.
>
> You cannot change the reference. It will always point to the same list.

Precisely. I can use indelible ink to write a phone number on a piece
of paper, but that's no guarantee that the same person will always
answer that phone. Doesn't change the indelibility of the writing. If
you want something truly immutable, you have to be careful to
reference only other immutables. In Python, hashability is pretty much
that, but I don't think English has such a concept.

Even if there is a word in English with a slightly different meaning
from its Python meaning, is that so hard to believe? In common usage,
a "dictionary" is something which maps words to their meanings, is
ordered ("dictionary order" being a variant of alphabetical order
which takes into account non-alphabetic characters, diacriticals,
etc), and may have additional information that isn't strictly part of
the mapping. In Python, a "dictionary" is something which maps
hashable values to objects. That's pretty different, but clearly
connected. In many languages, "integer" actually means "integer less
than X" (eg X = 2**32), but people don't complain that that means
they're not integers.

In Python, immutables can contain references to mutables, and the
perceived behaviour of a tuple may be affected by those objects.
They're still immutable.

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

Re: Can Python function return multiple data?

[random832]

On Fri, Jun 5, 2015, at 23:20, Rustom Mody wrote:
> The word immutuable happens to have existed in English before python.
> I also happen to have used it before I knew of python
> The two meanings do not match
> I am surprised
> Is that surprising?

They don't match only if you consider the objects a tuple references to
be part of the tuple.

You cannot change the reference. It will always point to the same list.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Can Python function return multiple data?

[Rustom Mody]

On Saturday, June 6, 2015 at 3:30:23 AM UTC+5:30, Chris Angelico wrote:
> On Fri, Jun 5, 2015 at 11:29 PM, Rustom Mody wrote:
> > On Friday, June 5, 2015 at 4:36:35 PM UTC+5:30, Steven D'Aprano wrote:
> >> On Fri, 5 Jun 2015 01:16 pm, Rustom Mody wrote:
> >> > The abstract platonic immutable list is non-existent in python
> >>
> >> Just pretend that "immutable list" is spelled "tuple".
> >
> > Ok lets say I make no fuss about the need to 'pretend'.
> >
> > And I try...
> >
>  a=[1,2,3]
>  b=(a,a)
>  a
> > [1, 2, 3]
>  b
> > ([1, 2, 3], [1, 2, 3])
>  a.append(4)
>  b
> > ([1, 2, 3, 4], [1, 2, 3, 4])
> 
> Congrats! You just proved that an object can itself be immutable, but
> can contain references to mutables. Ain't that awesome?
> 
> Did you have a point?

[Under assumption you are not being facetious...]
The word immutuable happens to have existed in English before python.
I also happen to have used it before I knew of python
The two meanings do not match
I am surprised
Is that surprising?

As a parallel here is Dijkstra making fun of AI-ers use of the word
'intelligent'
 http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD618.html
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Get html DOM tree by only basic builtin moudles

[Wesley]

> On Fri, Jun 5, 2015 at 12:10 PM, Wesley  wrote:
> > Hi Laura,
> >   Sure, I got special requirement that just parse html file into DOM tree, 
> > by only general basic modules, and based on my DOM tree structure, draft an 
> > bitmap.
> >
> >   So, could you give me an direction how to get the DOM tree?
> > Currently, I just think out to use something like stack, I mean, maybe read 
> > the file line by line, adding to a stack data structure(list for example), 
> > and, then, got the parent/child relation .etc
> >
> > I don't know if what I said is easy to achieve, I am just trying.
> > Any better suggestions will be great appreciated.
> 
> If you want to recreate the same DOM structure that would be created
> by a browser, the standardized algorithm to do so is very complicated,
> but you can find it at
> http://www.w3.org/TR/2011/WD-html5-20110113/parsing.html.
> 
> If you're not necessarily seeking perfect fidelity, I would encourage
> you to try to find some way to incorporate beautifulsoup into your
> project. It likely won't produce the same structure that a real
> browser would, but it should do well enough to scrape from even badly
> malformed html.
> 
> I recommend against using an XML parser, because HTML isn't XML, and
> such a parser may choke even on perfectly valid HTML such as this:
> 
> 
> 
>   Document
>   
> First line
> 
> Second line
>   
> 

Hi,
  Hmm, it's really complex.
Currently, I don't need to involve all error handling,and assume html is well 
formatted, then, generate the DOM tree.

Html sample below:



  
  About - Opera Software
  http://d2jc9zwbrclgz3.cloudfront.net/static-heap/da/dafd15591b35d4f81ca96cf7de6582d705850ff0/apple-touch-icon-57x57.png";>




  
http://operamediaworks.com/";>Opera Mediaworks
  


Who we are, what we do  
  
  


Vision
We strive to develop superior products and services for our users around the 
world, through state-of-the-art technology, innovation, leadership and 
partnerships.http://www.operasoftware.com/company/vision"; 
target="_self">Find out more.







  Page language
  


  
  Select your language:
  English
  

  



Copyright ? 2014 Opera Software ASA. All rights 
reserved.
http://www.opera.com/privacy";>Privacy. http://www.opera.com/terms";>Terms of Use.




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

Re: Can Python function return multiple data?

[Chris Angelico]

On Fri, Jun 5, 2015 at 11:29 PM, Rustom Mody  wrote:
> On Friday, June 5, 2015 at 4:36:35 PM UTC+5:30, Steven D'Aprano wrote:
>> On Fri, 5 Jun 2015 01:16 pm, Rustom Mody wrote:
>> > The abstract platonic immutable list is non-existent in python
>>
>> Just pretend that "immutable list" is spelled "tuple".
>
> Ok lets say I make no fuss about the need to 'pretend'.
>
> And I try...
>
 a=[1,2,3]
 b=(a,a)
 a
> [1, 2, 3]
 b
> ([1, 2, 3], [1, 2, 3])
 a.append(4)
 b
> ([1, 2, 3, 4], [1, 2, 3, 4])

Congrats! You just proved that an object can itself be immutable, but
can contain references to mutables. Ain't that awesome?

Did you have a point?

> It was an analogy.
> C programmers use lists all right all the time.
> However until they see something like python, they dont know that they never
> REALLY saw lists. ie lists in python are more first-class than C.

If you're talking about the things C programmers use all the time,
they're not linked lists, they're arrays - identified by base pointer
and element count. Linked lists are common in LISPy languages, but not
all that common in C, nor C-derived APIs. Most APIs designed for C
usage are either array-based or generator-based.

http://www.gnu.org/software/libc/manual/html_node/Scanning-Directory-Content.html
Array-based: scandir accepts a pointer-to-pointer, which it populates
with a pointer to freshly-allocated data, and it returns the number of
entries stashed there.

http://www.gnu.org/software/libc/manual/html_node/Opening-a-Directory.html
http://www.gnu.org/software/libc/manual/html_node/Reading_002fClosing-Directory.html
Generator-based: opendir returns a generator, readdir gives the next
result or NULL

http://www.gnu.org/software/libc/manual/html_node/Array-Sort-Function.html
Array-based: pass it a base pointer and a count (and an object size,
since it's completely generic), and it sorts the elements.

Your point is still broadly valid, though; these arrays are not
first-class objects. They do have their own little quirks; so long as
the original array isn't deallocated, you can efficiently work with
views by simply using a base pointer inside the original array and a
length that's shorter than the whole array. Very convenient if you
need it, but most certainly not first-class lists, and can cause
problems if you're not careful. Python lists truly are first-class
objects; "more first-class than C" in the sense that 1 is more true
than 0.

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

Re: Get html DOM tree by only basic builtin moudles

[Ian Kelly]

On Fri, Jun 5, 2015 at 12:10 PM, Wesley  wrote:
> Hi Laura,
>   Sure, I got special requirement that just parse html file into DOM tree, by 
> only general basic modules, and based on my DOM tree structure, draft an 
> bitmap.
>
>   So, could you give me an direction how to get the DOM tree?
> Currently, I just think out to use something like stack, I mean, maybe read 
> the file line by line, adding to a stack data structure(list for example), 
> and, then, got the parent/child relation .etc
>
> I don't know if what I said is easy to achieve, I am just trying.
> Any better suggestions will be great appreciated.

If you want to recreate the same DOM structure that would be created
by a browser, the standardized algorithm to do so is very complicated,
but you can find it at
http://www.w3.org/TR/2011/WD-html5-20110113/parsing.html.

If you're not necessarily seeking perfect fidelity, I would encourage
you to try to find some way to incorporate beautifulsoup into your
project. It likely won't produce the same structure that a real
browser would, but it should do well enough to scrape from even badly
malformed html.

I recommend against using an XML parser, because HTML isn't XML, and
such a parser may choke even on perfectly valid HTML such as this:



  Document
  
First line

Second line
  

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

Re: Can Python function return multiple data?

[sohcahtoa82]

On Wednesday, June 3, 2015 at 2:57:00 PM UTC-7, Mark Lawrence wrote:
> On 03/06/2015 22:35, Chris Angelico wrote:
> > On Wed, Jun 3, 2015 at 11:56 PM, Thomas Rachel
> > 
> > wrote:
> >> Am 03.06.2015 um 01:56 schrieb Chris Angelico:
> >>
> >>> and it's pretty convenient. In C, the nearest equivalent is passing a
> >>> number of pointers as parameters, and having the function fill out
> >>> values. Python's model is a lot closer to what you're saying than C's
> >>> model is :)
> >>
> >>
> >> At least, C functions can return structs...
> >
> > Oh, yes, I forgot about that. Thought that was C++ but not C, partly
> > because I never do it in either language. Although in a sense, a
> > struct is still a single "thing".
> >
> > ChrisA
> >
> 
> Don't forget that C functions can accept structs as input.  Possibly not 
> a good idea as I found out many years ago pre ANSIC when I forgot that 
> little old ampersand, so the compiler didn't pick it up, but then with 
> modern computers having so much memory who really cares if you burn a 
> little bit of stack on structures rather than pointers to structures?
> 
> Now does Python pass by value or by reference?  Happily sits back and 
> waits for 10**6 emails to arrive as this is discussed for the 10**6th time.
> 
> -- 
> My fellow Pythonistas, ask not what our language can do for you, ask
> what you can do for our language.
> 
> Mark Lawrence

Boy, you really called it on the 10**6 emails thing.  This thread certainly 
exploded.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Get html DOM tree by only basic builtin moudles

[Wesley]

Hi Laura,
  Sure, I got special requirement that just parse html file into DOM tree, by 
only general basic modules, and based on my DOM tree structure, draft an bitmap.

  So, could you give me an direction how to get the DOM tree?
Currently, I just think out to use something like stack, I mean, maybe read the 
file line by line, adding to a stack data structure(list for example), and, 
then, got the parent/child relation .etc

I don't know if what I said is easy to achieve, I am just trying.
Any better suggestions will be great appreciated.

Thanks.
Wesley

> Elementtree is part of the Python standard library.  You are better off
> using it than rolling your own.   (If you were one of the rare people who
> have some very strange requirements that make you better off writing your
> own, you wouldn't be asking us.  You'd already know.)
> 
> https://docs.python.org/2.7/library/xml.etree.elementtree.html#module-xml.etree.ElementTree
> https://docs.python.org/3.4/library/xml.etree.elementtree.html

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

Re: Python.exe has stopped working

[Stephen Hansen]

On Fri, Jun 5, 2015, at 02:03 AM, Alexis Dubois wrote:
> Anyone else for an idea on that?

Sorry, I have no idea.

Have you tried asking on the PyQT mailing list where there is likely
more of a concentration of PyQT expertise?
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

-- 
Stephen Hansen
  m e @ i x o k a i . i o
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to inverse a particle emitter

[alister]

On Thu, 04 Jun 2015 16:15:20 -0700, stephenppraneel7 wrote:

> hey, i really need help, im a straight up beginner in scripting and i
> need to figure out how to make an inverted particle emitter using python
> in maya

Some very goo pointers from the Python team

https://www.youtube.com/watch?v=tNfGyIW7aHM




-- 
"When in doubt, print 'em out."
-- Karl's Programming Proverb 0x7
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Sorting in reverse is not the same as sorting then reversing

[Skip Montanaro]

On Fri, Jun 5, 2015 at 9:50 AM, Stefan Behnel  wrote:
> [Stable sorting is] a general property of Python's sort algorithm.

And at times an extremely valuable property.

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

Re: Sorting in reverse is not the same as sorting then reversing

[Peter Otten]

Steven D'Aprano wrote:

> Sorting in reverse does not give the same result as sorting then
> reversing.
> 
> It's easiest to see with a key function:
> 
> 
> py> a = ['fox', 'dog', 'DOG', 'cat', 'ape']
> py> b = a[:]
> py> a.sort(key=str.lower, reverse=True)
> py> b.sort(key=str.lower)
> py> b.reverse()
> py> a
> ['fox', 'dog', 'DOG', 'cat', 'ape']
> py> b
> ['fox', 'DOG', 'dog', 'cat', 'ape']
> 
> 
> Sorting in reverse keeps the initial order of any equal elements
> unchanged. Sorting, then reversing, reverses them.

If there were no reverse flag you could reverse, then sort, then reverse 
again.

> (Thanks to Tim Peters for the tip.)


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

Re: Sorting in reverse is not the same as sorting then reversing

[Stefan Behnel]

Steven D'Aprano schrieb am 05.06.2015 um 16:07:
> Sorting in reverse does not give the same result as sorting then reversing.
> 
> It's easiest to see with a key function:
> 
> py> a = ['fox', 'dog', 'DOG', 'cat', 'ape']
> py> b = a[:]
> py> a.sort(key=str.lower, reverse=True)
> py> b.sort(key=str.lower)
> py> b.reverse()
> py> a
> ['fox', 'dog', 'DOG', 'cat', 'ape']
> py> b
> ['fox', 'DOG', 'dog', 'cat', 'ape']
> 
> Sorting in reverse keeps the initial order of any equal elements unchanged.
> Sorting, then reversing, reverses them.
> 
> (Thanks to Tim Peters for the tip.)

... and for implementing this in the first place. :)

For those of you who didn't know and now got interested, the relevant term
here is "stable sorting". It means that elements that compare equal keep
their relative order. That's a general property of Python's sort algorithm.
All that "reverse=True" does is to change "lower than" into "greater than"
and vice versa for elements that compare unequal. It does not change the
behaviour for elements that compare equal, which means that they keep the
same relative order in both cases (reversed/non-reversed).

Stefan


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

Re: How to inverse a particle emitter

[Grant Edwards]

On 2015-06-04, stephenpprane...@gmail.com  wrote:

> hey, i really need help, im a straight up beginner in scripting and i
> need to figure out how to make an inverted particle emitter using
> python in maya

1) Build a particle emitter

2) Turn it upside down

-- 
Grant Edwards   grant.b.edwardsYow! HELLO, everybody,
  at   I'm a HUMAN!!
  gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: So what's happening here?

[Nobody]

On Fri, 05 Jun 2015 13:11:13 +, Paul Appleby wrote:

> (I'd have thought that id(a[1]) and id(b[1]) would be the same if they
> were the same element via different "views", but the id's seem to change
> according to rules that I can't fathom.)

First, a[1] and b[1] aren't views, they're scalars.

Second, different views on the same data are different objects, they just
share the same underlying data. Consider the case where the slice doesn't
cover the entire range:

> a = np.array([1,2,3])
> b = a[:2]
> a
array([1, 2, 3])
> b
array([1, 2])
> id(a)
139682716078288
> id(b)
139682716078368
> b[0] = 99
> a
array([99,  2,  3])
> b
array([99,  2])

The case where a slice *does* cover the entire range isn't special; the
resulting view is still a different object.

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

Sorting in reverse is not the same as sorting then reversing

[Steven D'Aprano]

Sorting in reverse does not give the same result as sorting then reversing.

It's easiest to see with a key function:


py> a = ['fox', 'dog', 'DOG', 'cat', 'ape']
py> b = a[:]
py> a.sort(key=str.lower, reverse=True)
py> b.sort(key=str.lower)
py> b.reverse()
py> a
['fox', 'dog', 'DOG', 'cat', 'ape']
py> b
['fox', 'DOG', 'dog', 'cat', 'ape']


Sorting in reverse keeps the initial order of any equal elements unchanged.
Sorting, then reversing, reverses them.


(Thanks to Tim Peters for the tip.)


-- 
Steven

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

Re: So what's happening here?

[Gary Herron]

On 06/05/2015 06:39 AM, Todd wrote:
On Fri, Jun 5, 2015 at 3:23 PM, Gary Herron 
> wrote:


On 06/05/2015 06:11 AM, Paul Appleby wrote:

On Fri, 05 Jun 2015 14:55:11 +0200, Todd wrote:

Numpy arrays are not lists, they are numpy arrays. They
are two
different data types with different behaviors.  In lists,
slicing is a
copy.  In numpy arrays, it is a view (a data structure
representing some
part of another data structure).  You need to explicitly
copy the numpy
array using the "copy" method to get a copy rather than a
view:

OK, thanks.  I see.

(I'd have thought that id(a[1]) and id(b[1]) would be the same
if they
were the same element via different "views", but the id's seem
to change
according to rules that I can't fathom.)

Nope.  It's odder than that.  a[1] is still a view into the
inderlying numpy array, and your id is the id of that view. Each
such index produces a new such view object. Check this out:

>>> import numpy
>>> a = numpy.array([1,2,3])
>>> id(a[1])
28392768
>>> id(a[1])
28409872

This produces two different view of the same underlying object.


a[1] and b[1] are not views:

>>> a[1].flags['OWNDATA']
True
>>> b[1].flags['OWNDATA']
True
>>> a[1:2].flags['OWNDATA']
False


Right.  My bad.  Each execution of a[1] creates a new numpy.int64 object 
with the value from the array.


>>> type(a[1])


Each execution of id(a[1]) creates an int64 object which is immediately 
used and then deleted.  Two successive executions of id(a[1]) may or may 
not reuse the same piece of memory, depending on what else is going on 
in memory.  Indeed when I produced the above example with id(a[1]), a 
third and fourth runs of id(a[1]) did indeed repeat 28409872, but they 
are all new creations of an int64 object which happen to use the same 
recently freed bit of memory.


Gary Herron












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

Re: So what's happening here?

[Steven D'Aprano]

On Fri, 5 Jun 2015 11:11 pm, Paul Appleby wrote:

> On Fri, 05 Jun 2015 14:55:11 +0200, Todd wrote:
> 
>> Numpy arrays are not lists, they are numpy arrays. They are two
>> different data types with different behaviors.  In lists, slicing is a
>> copy.  In numpy arrays, it is a view (a data structure representing some
>> part of another data structure).  You need to explicitly copy the numpy
>> array using the "copy" method to get a copy rather than a view:
> 
> OK, thanks.  I see.
> 
> (I'd have thought that id(a[1]) and id(b[1]) would be the same if they
> were the same element via different "views", but the id's seem to change
> according to rules that I can't fathom.)

They're the same element, but not the same object.

The id() function operates on an object, and returns some arbitrary ID
number for that object. The only thing promised about that ID number is
that for any two distinct objects existing at the same time, they will have
distinct IDs.

Now, let's see what happens when we extract elements from a regular Python
list:

py> a = [1, 2, 3]
py> x = a[0]
py> y = a[0]
py> x is y
True
py> id(x) == id(y)
True

This tells us that extracting the first (or zeroth, if you prefer) element
from the list gives us the same object each time.

Now let's try it with a numpy array:

py> import numpy as np
py> b = np.array([1, 2, 3])
py> x = b[0]
py> y = b[0]
py> x is y
False
py> id(x), id(y)
(149859472, 151810312)


The IDs are clearly different, therefore they are different objects. What's
going on?

The secret is that lists contain objects, so when you extract the zeroth
item using a[0], you get the same object each time. But numpy arrays do not
contain objects, they are a wrapper around a C array of machine ints.

(The numpy array itself is an object, but the elements of that array are
not.)

This is one of the reasons why numpy is so fast: it can bypass all the
high-level Python object-oriented machinery, and perform calculations using
high-speed, low-level C code taking advantage of unboxed machine primitive
values.

But when you extract an element using b[0], numpy has to give you an object.
(Python itself has no concept of low-level machine values.) So it grabs the
32-bit integer at offset 0, converts it into an object, and returns that.
When you do it again, numpy goes through the same process, and returns a
second object with the same numeric value. Hence, the IDs are different.



-- 
Steven

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

Re: So what's happening here?

[Todd]

On Fri, Jun 5, 2015 at 3:23 PM, Gary Herron 
wrote:

> On 06/05/2015 06:11 AM, Paul Appleby wrote:
>
>> On Fri, 05 Jun 2015 14:55:11 +0200, Todd wrote:
>>
>>  Numpy arrays are not lists, they are numpy arrays. They are two
>>> different data types with different behaviors.  In lists, slicing is a
>>> copy.  In numpy arrays, it is a view (a data structure representing some
>>> part of another data structure).  You need to explicitly copy the numpy
>>> array using the "copy" method to get a copy rather than a view:
>>>
>> OK, thanks.  I see.
>>
>> (I'd have thought that id(a[1]) and id(b[1]) would be the same if they
>> were the same element via different "views", but the id's seem to change
>> according to rules that I can't fathom.)
>>
> Nope.  It's odder than that.  a[1] is still a view into the inderlying
> numpy array, and your id is the id of that view. Each such index produces a
> new such view object.  Check this out:
>
> >>> import numpy
> >>> a = numpy.array([1,2,3])
> >>> id(a[1])
> 28392768
> >>> id(a[1])
> 28409872
>
> This produces two different view of the same underlying object.
>

a[1] and b[1] are not views:

>>> a[1].flags['OWNDATA']
True
>>> b[1].flags['OWNDATA']
True
>>> a[1:2].flags['OWNDATA']
False
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Can Python function return multiple data?

[Marko Rauhamaa]

random...@fastmail.us:

> The normal human-readable representation of a reference is an arrow on
> a diagram, pointing from a box that represents the variable to a box
> that represents the object. But I can't exactly put that in a
> text-based email.

An *lvalue* is anything that can be assigned to:

   x = 3
   a[3] = 2
   d['hello'] = 'world'

An *rvalue* is anything that can be assigned to an lvalue.

In Python, every rvalue is a *reference* to an *object*.

So your first box is an lvalue, your arrow is an rvalue and your second
box is an object.

The words "lvalue" and "rvalue" smell like C, so Python people tend to
want to find loftier terms at the expense of clarity. Thus instead of
saying,

The lvalue contains a reference to an object.

they prefer saying,

The reference is bound to an object.

Unfortunately, that practice renders the meaning of a "reference"
ambiguous.


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

Re: So what's happening here?

[Gary Herron]

On 06/05/2015 06:11 AM, Paul Appleby wrote:

On Fri, 05 Jun 2015 14:55:11 +0200, Todd wrote:


Numpy arrays are not lists, they are numpy arrays. They are two
different data types with different behaviors.  In lists, slicing is a
copy.  In numpy arrays, it is a view (a data structure representing some
part of another data structure).  You need to explicitly copy the numpy
array using the "copy" method to get a copy rather than a view:

OK, thanks.  I see.

(I'd have thought that id(a[1]) and id(b[1]) would be the same if they
were the same element via different "views", but the id's seem to change
according to rules that I can't fathom.)
Nope.  It's odder than that.  a[1] is still a view into the inderlying 
numpy array, and your id is the id of that view. Each such index 
produces a new such view object.  Check this out:


>>> import numpy
>>> a = numpy.array([1,2,3])
>>> id(a[1])
28392768
>>> id(a[1])
28409872

This produces two different view of the same underlying object.

Gary Herron





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

Re: Can Python function return multiple data?

[Rustom Mody]

On Friday, June 5, 2015 at 4:36:35 PM UTC+5:30, Steven D'Aprano wrote:
> On Fri, 5 Jun 2015 01:16 pm, Rustom Mody wrote:
> > The abstract platonic immutable list is non-existent in python
> 
> Just pretend that "immutable list" is spelled "tuple".

Ok lets say I make no fuss about the need to 'pretend'.

And I try...

>>> a=[1,2,3]
>>> b=(a,a)
>>> a
[1, 2, 3]
>>> b
([1, 2, 3], [1, 2, 3])
>>> a.append(4)
>>> b
([1, 2, 3, 4], [1, 2, 3, 4])

> 
> 
> > Use no mutation and the pretence that the list [1,2] *is* the list [1,2]
> > works.
> > 
> > Start using mutation and the ground starts wobbling.
> 
> Mutation is irrelevant here. Some objects are immutable, others are mutable,
> but the language semantics are the same for both.
> 
> In particular, Python provides as a language feature two ways to compare
> objects for identity. Python makes no promises as to when it will re-use
> immutable objects, but it does promise that you can always test for re-use
> by using `is` or `id()`. So there's no "wobbly ground" here. You can
> *always* tell if (supposedly) two objects are in fact the same object or
> not, since `is` cannot be shadowed or monkey-patched.
> 
> 
> > The only way to stay steady (that I know) in this wobbly world is to hold
> > to two concepts:
> > 1. The abstract platonic immutable type -- good to think with, supported
> > by python in only a half-assed way
> > 
> > 2. The 'maybe-reference-maybe-value' actual mess
> > 
> > And to keep dancing between these
> 
> All the words are in English, but I have no idea what you are trying to say
> here.

It was an analogy.
C programmers use lists all right all the time.
However until they see something like python, they dont know that they never
REALLY saw lists. ie lists in python are more first-class than C.

Analogously immutable lists are more first-class than python lists.

Of course the language (we are conversing in) is itself very misleading.
We dont call a number an 'immutable' number. In
x = 3
x = x - 1
it is x that changes, not 3.

Whatever would/could it mean that 3 becomes 2?

If 3 becomes 2 does π become 2.142? Do circles look different?
Does the normal curve (with a π in the denominator) start wiggling?

What I am driving at is that immutable numbers are so deeply enshrined in our
culture that anything else is inconceivable.

Yet for lists one needs to spell out
immutable → tuple
mutable → list
This means that in our culture lists have not reached the first-class status 
that numbers have.  Python is just following the culture
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: So what's happening here?

[Todd]

On Fri, Jun 5, 2015 at 3:11 PM, Paul Appleby  wrote:

> On Fri, 05 Jun 2015 14:55:11 +0200, Todd wrote:
>
> > Numpy arrays are not lists, they are numpy arrays. They are two
> > different data types with different behaviors.  In lists, slicing is a
> > copy.  In numpy arrays, it is a view (a data structure representing some
> > part of another data structure).  You need to explicitly copy the numpy
> > array using the "copy" method to get a copy rather than a view:
>
> OK, thanks.  I see.
>
> (I'd have thought that id(a[1]) and id(b[1]) would be the same if they
> were the same element via different "views", but the id's seem to change
> according to rules that I can't fathom.)
>
>
a[1] and b[1] are NOT views.   Slices are views, single elements are not.
They are numpy scalars, which are immutable, so returning a view wouldn't
make sense in such a case since you can't modify it anyway.

Taking a slice creates a new view.  It is looking at the same underlying
data, but it is a new object.  So "a[1:] is b[1:]" is False, as is "a[:] is
b".
-- 
https://mail.python.org/mailman/listinfo/python-list

GCJ Watersheds

[neng . zhou]

I just posted a program in Picat for the GCJ Watersheds problem. I am wondering 
how many lines a Python program would require. 

https://groups.google.com/forum/#!topic/picat-lang/1QC3KWwfyA8 

Cheers, 
Neng-Fa 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: So what's happening here?

[Paul Appleby]

On Fri, 05 Jun 2015 14:55:11 +0200, Todd wrote:

> Numpy arrays are not lists, they are numpy arrays. They are two
> different data types with different behaviors.  In lists, slicing is a
> copy.  In numpy arrays, it is a view (a data structure representing some
> part of another data structure).  You need to explicitly copy the numpy
> array using the "copy" method to get a copy rather than a view:

OK, thanks.  I see. 

(I'd have thought that id(a[1]) and id(b[1]) would be the same if they 
were the same element via different "views", but the id's seem to change 
according to rules that I can't fathom.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: So what's happening here?

[Peter Otten]

Paul Appleby wrote:

> I saw somewhere on the net that you can copy a list with slicing. So
> what's happening when I try it with a numpy array?
> 
 a = numpy.array([1,2,3])
 b = a[:]
 a is b
> False
 b[1] = 9
 a
> array([1, 9, 3])

Copy or view -- have a look under the hood:

>>> a = numpy.array([1,2,3])
>>> v = a.view()
>>> c = a.copy()
>>> s = a[:]
>>> a.flags["OWNDATA"]
True
>>> v.flags["OWNDATA"]
False
>>> c.flags["OWNDATA"]
True
>>> s.flags["OWNDATA"]
False

You only get a copy if you ask for one; slicing produces a view.

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

Re: So what's happening here?

[Todd]

On Fri, Jun 5, 2015 at 2:46 PM, Paul Appleby  wrote:

> I saw somewhere on the net that you can copy a list with slicing. So
> what's happening when I try it with a numpy array?
>
> >>> a = numpy.array([1,2,3])
> >>> b = a[:]
> >>> a is b
> False
> >>> b[1] = 9
> >>> a
> array([1, 9, 3])
>
>
Numpy arrays are not lists, they are numpy arrays. They are two different
data types with different behaviors.  In lists, slicing is a copy.  In
numpy arrays, it is a view (a data structure representing some part of
another data structure).  You need to explicitly copy the numpy array using
the "copy" method to get a copy rather than a view:

>>> a = numpy.array([1,2,3])
>>> b = a.copy()
>>> a is b
False
>>> b[1] = 9
>>> a
array([1, 2, 3])

Here is how it works with lists:

>>> a = [1,2,3]
>>> b = a[:]
>>> a is b
False
>>> b[1] = 9
>>> a
[1, 2, 3]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: So what's happening here?

[Larry Martell]

On Fri, Jun 5, 2015 at 8:46 AM, Paul Appleby  wrote:
> I saw somewhere on the net that you can copy a list with slicing. So
> what's happening when I try it with a numpy array?
>
 a = numpy.array([1,2,3])
 b = a[:]
 a is b
> False
 b[1] = 9
 a
> array([1, 9, 3])

is is identity testing, == is equality testing

>>> a = numpy.array([1,2,3])
>>> b = a[:]
>>> a == b
array([ True,  True,  True], dtype=bool)
>>> id(a)
4510409872
>>> id(b)
4510410192
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: So what's happening here?

[Fabien]

On 06/05/2015 02:46 PM, Paul Appleby wrote:

I saw somewhere on the net that you can copy a list with slicing. So
what's happening when I try it with a numpy array?


Python lists and numpy arrays are NOT the same thing. This is one of the 
reasons why numpy was developed in the first place. Numpy uses views, 
not copies. There is however a .copy() method on numpy arrays


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

So what's happening here?

[Paul Appleby]

I saw somewhere on the net that you can copy a list with slicing. So 
what's happening when I try it with a numpy array?

>>> a = numpy.array([1,2,3])
>>> b = a[:]
>>> a is b
False
>>> b[1] = 9
>>> a
array([1, 9, 3])
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Can Python function return multiple data?

[random832]

On Thu, Jun 4, 2015, at 22:37, Steven D'Aprano wrote:

> That's not a reference to the value. That's a string that describes the
> object.

Well, of course. None of these things are strings.

The normal human-readable representation of a reference is an arrow on a
diagram, pointing from a box that represents the variable to a box that
represents the object. But I can't exactly put that in a text-based
email.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Can Python function return multiple data?

[Alain Ketterlin]

Marko Rauhamaa  writes:

> Alain Ketterlin :
>
>> Grant Edwards  writes:
>>
>> [...]
>>> Or to be a bit obtuse: Python parameters are passed by value, but all
>>> values are references.
>>
>> Exactly, that's a perfect description. There's is no need for a new
>> name. As a corollary, all names (including "variables" and object
>> attributes) are references.
>
> We are all confusing each other because of the word "reference" means so
> many things.
>
> In Grant's explanation, a "reference" is a pointer, the invisible gluons
> that bind, say, a variable to an object.
>
> In Alain's sentence a "reference" is a variable or any other "lvalue"
> that can be bound to an object.
>
> Thus, the statement
>
> a[3] = 4
>
> contains the reference[Alain] "a[3]". After the statement is executed,
> the reference[Alain] contains a reference[Grant] to an int object 4.

You're right, my wording is imprecise, your interpretation is absolutely
correct.

> Now, is it useful to make the distinction and use the verb "contain?"
>
> Yes, it is. Consider these statements:
>
> a[0] = 4
> a[1] = 4
> a[2] = a[1]
>
> Now, "a[0]", "a[1]" and "a[2]" are three separate references[Alain].
> However between the three, they contain a maximum of two distinct
> references[Grant], which can be ascertained with an "is" test:
>
> a[2] is a[1]
> => True
>
> So while the references[Grant] are identical, the references[Alain] are
> not. If I'm not mistaken, Python has no means of comparing the
> identities of references[Alain].

Right.

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

Re: Can Python function return multiple data?

[Steven D'Aprano]

On Fri, 5 Jun 2015 01:16 pm, Rustom Mody wrote:

> Consider the C canonical linked-list example (of some type T):
> 
> struct node
> {
>T elem;
>struct node *next;
> };
> 
> Is the list in C to be identified with 'struct node'?

Lists in C are not first class values. There is no one thing which can be
identified as the entire list, because the C language gives you the tools
to break any "list" abstraction.

In C, there is no single thing which refers to the entire list, *except by
convention*. There is *at least* one node which represents the head of the
list, followed by other nodes:


node->node->node->node->node
 ^
 |
node->node---

(ASCII diagram best viewed in a monospaced font)

But there is nothing which encapsulates the entire list, and indeed the
concept "the list" is ill-defined, as in the above diagram. We can use the
convention that "the list" means "the sequence of nodes, starting from this
node, which we assume is the head of the list", but that's about it. You
might even find some clever way of tracking which node is the head and
which are not in your own code, but C won't do it for you. You might refuse
to create such double-headed lists as shown above, but C won't enforce that
rule for you, you have to enforce it yourself. In short, C doesn't have the
concept of lists as first class values and so anything you do with it is
entirely in your own hands.


[...]
> My conclusion: C does not support lists at all in a first class way.

Exactly!


> The same situation obtains here in python:

Not so.

In Python, lists *are* first class values, and the Python language manages
all the book-keeping for you to ensure that when you look at a list, it is
the whole list, regardless of implementation. From your Python code, you
don't have to do any book-keeping, you don't have to be careful not to
create double-headed lists, or accidentally start in the middle of the
list, since Python simply doesn't allow you to do so from pure Python code,
unlike C. So in Python, we can always consider the list as a encapsulated
whole, regardless of how it is implemented.

(CPython documents that lists are actually arrays of pointers to objects,
but that's an implementation detail we can ignore.)


> The abstract platonic immutable list is non-existent in python

Just pretend that "immutable list" is spelled "tuple".


> Use no mutation and the pretence that the list [1,2] *is* the list [1,2]
> works.
> 
> Start using mutation and the ground starts wobbling.

Mutation is irrelevant here. Some objects are immutable, others are mutable,
but the language semantics are the same for both.

In particular, Python provides as a language feature two ways to compare
objects for identity. Python makes no promises as to when it will re-use
immutable objects, but it does promise that you can always test for re-use
by using `is` or `id()`. So there's no "wobbly ground" here. You can
*always* tell if (supposedly) two objects are in fact the same object or
not, since `is` cannot be shadowed or monkey-patched.


> The only way to stay steady (that I know) in this wobbly world is to hold
> to two concepts:
> 1. The abstract platonic immutable type -- good to think with, supported
> by python in only a half-assed way
> 
> 2. The 'maybe-reference-maybe-value' actual mess
> 
> And to keep dancing between these

All the words are in English, but I have no idea what you are trying to say
here.


-- 
Steven

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

Re: How to inverse a particle emitter

[Laura Creighton]

In a message of Thu, 04 Jun 2015 16:15:20 -0700, stephenpprane...@gmail.com wri
tes:
>hey, i really need help, im a straight up beginner in scripting and i need to 
>figure out how to make an inverted particle emitter using python in maya
>-- 
>https://mail.python.org/mailman/listinfo/python-list
You need the maya-vi mailing list, not this one.
It's here:
https://lists.sourceforge.net/lists/listinfo/mayavi-users

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

Re: Can Python function return multiple data?

[BartC]

On 05/06/2015 02:48, Steven D'Aprano wrote:

On Fri, 5 Jun 2015 11:40 am, Mark Lawrence wrote:


On 05/06/2015 01:16, BartC wrote:

On 05/06/2015 00:13, Steven D'Aprano wrote:

On Fri, 5 Jun 2015 06:52 am, BartC wrote:


On 04/06/2015 18:11, Steven D'Aprano wrote:


If there is
any language where assignment uses one style and argument passing
always
uses another, I've never come across it.


My language does that. I'd be very surprised if it was the only one in
existence that does so.


[...]


Really?


Probably. I can't be sure, because I've never used Bart's language. But
surely he has no reason to lie about his language, and I'm pretty sure you
can't disprove any claims about his language by running Python code.


Well, my language does assignments differently.

Using tmp=x[:], the Python example will emulate the behaviour better.

(This is actually what I've always had trouble getting my head around. 
For example:


x=[10,20]
y=[x,x,x]
print (y)

gives:

  [[10,20],[10,20],[10,20]]

So far so good. But now, thousands of lines and minutes of runtime later 
so that everyone's forgotten that exactly y was from x:


 x[0]="Cat"
 print (y)

gives:

   [['Cat',20],['Cat',20],['Cat',20]]

WTF?!

Or:

  y[0][0]=99  # change one element, you think
  print (y)

=> [[99,20],[99,20],[99,20]]  # no, you change half of them!

Anyway, I am now upgrading my language to work the same way, *and* 
getting rid of explicit pointers, references and full pass-by-reference, 
because Python seems to manage without them. I'll find out in few weeks 
if I've made a big mistake!)


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

Re: Can Python function return multiple data?

[BartC]

On 04/06/2015 15:37, Grant Edwards wrote:

On 2015-06-04, Marko Rauhamaa  wrote:

Steven D'Aprano :


But you still find a few people here and there who have been exposed
to Java foolishness, and will argue that Python is "pass by value,
where the value is an implementation dependent reference to the thing
that you thought was the value".


Why fight terminology? Definitions can't be proved right or wrong.

Anyway, I would say Python definitely is in the classic pass-by-value
camp. Here's a simple test:

def f(x):
x = 3

y = 1
f(y)
print(y)

If it prints 1, it's pass by value. If it prints 3, it's pass by
reference.


Somebody else might just as honestly say that it's pass by reference:

def f(x):
 x[2] = 2;

x = ['a','b','c']
f(x)
print(x)

If it prints ['a','b','c'], it's pass by value.  If it's pass by
reference, it prints ['a', 'b', 2].

IMO, it's pass by reference.


No, it's not. Pass-by-reference specifically means (as Steven D'Aprano 
pointed out some weeks back in another thread) that you can directly 
change the caller's 'variable' so that it becomes something else, such 
as a string.


In your example, the caller's x is still a list. And the same list 
(assign it to y before the call. y will be ['a','b','2'] too, and (x is 
y) is True).


To modify, mutate or in any way update the data associated with the 
caller's argument, pass-by-reference is not needed. But it's not exactly 
pass-by-value either.


In a language like Python, such a limited choice would be too naive, 
because pointers and references are also used internally and 
transparently, and they help to confuse matters.


If you want to call it something, perhaps call it call-by-handle. 
Because a handle to the data is being passed. In the same way that if X 
is a handle to a file, a window, image, or any external resource, then:


  func(X)

might update the file, draw into the window or image or whatever, but 
no-one would be talking about whether that file or window is passed by 
value or by reference!


--
Bartc

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

Re: Can Python function return multiple data?

[Marko Rauhamaa]

Alain Ketterlin :

> Grant Edwards  writes:
>
> [...]
>> Or to be a bit obtuse: Python parameters are passed by value, but all
>> values are references.
>
> Exactly, that's a perfect description. There's is no need for a new
> name. As a corollary, all names (including "variables" and object
> attributes) are references.

We are all confusing each other because of the word "reference" means so
many things.

In Grant's explanation, a "reference" is a pointer, the invisible gluons
that bind, say, a variable to an object.

In Alain's sentence a "reference" is a variable or any other "lvalue"
that can be bound to an object.

Thus, the statement

a[3] = 4

contains the reference[Alain] "a[3]". After the statement is executed,
the reference[Alain] contains a reference[Grant] to an int object 4.

Now, is it useful to make the distinction and use the verb "contain?"

Yes, it is. Consider these statements:

a[0] = 4
a[1] = 4
a[2] = a[1]

Now, "a[0]", "a[1]" and "a[2]" are three separate references[Alain].
However between the three, they contain a maximum of two distinct
references[Grant], which can be ascertained with an "is" test:

a[2] is a[1]
=> True

So while the references[Grant] are identical, the references[Alain] are
not. If I'm not mistaken, Python has no means of comparing the
identities of references[Alain].


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

Re: Python.exe has stopped working

[Christian Gollwitzer]

Am 05.06.15 um 11:03 schrieb Alexis Dubois:

Anyone else for an idea on that?

Well, it is a crash on exit. Looks like a memory error inside of PyQT. 
If you've got the time, you could run it inside of a debugger, or 
better, a memory checker like AppVerifier to find the culprit. These 
things are usually quite hard to diagnose, and unless someone has seen 
it here already, the fun starts now ;) Another possible reason might be 
mixing up DLLs from PyQT and another QT installation. You can find out 
by listing all loaded DLLs when the program is running, e.g. from a 
debugger or this tool: 
https://technet.microsoft.com/sysinternals/bb896653.aspx


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

Re: Python.exe has stopped working

[Alexis Dubois]

Anyone else for an idea on that?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Find in ipython3

[Cecil Westerhof]

Op Thursday 4 Jun 2015 22:13 CEST schreef random:

> On Tue, Jun 2, 2015, at 12:13, Cecil Westerhof wrote:
>> I am thinking about using ipython3 instead of bash. When I want to
>> find a file I can do the following:
>> !find ~ -iname '*python*.pdf'
>> but is there a python way?
>
> Python really isn't a good substitute for a shell, but the normal
> python way to do this task is:
>
> import os, os.path, fnmatch
>
> home = os.path.expanduser('~')  # only needed since you used ~
> for dirpath, dirnames, filenames in os.walk(home):
> print(dirpath)
> for filename in filenames:
> if(fnmatch.fnmatch(filename.lower(), '*python*.pdf')):
> print(os.path.join(dirpath, filename))

I was already thinking along those lines. I made it:
def find(directory, to_match):
to_match = to_match.lower()
results = []
for dirpath, dirnames, filenames in os.walk(expanduser(directory)):
for filename in filenames:
if(fnmatch(filename.lower(), to_match)):
results.append(os.path.join(dirpath, filename))
return results

> Note that if you have filenames with invalid unicode characters (or
> any non-ASCII characters at all on Windows) you may have to do
> additional processing to the filename before printing it. And of
> course instead of printing it you may want to store the filenames in
> a list for further processing. But these are the basic building
> blocks.

I have to look into it further. For one thing default the match should
be case dependent and an option used to make it independent.


> I don't use ipython, so I don't know what it provides if anything to
> make any of this easier.

I think it is useful to have it in Python also, so I should not use
ipython specific things.

In ‘~/.ipython/profile_default/startup/00-init.ipy’ I have:
from utilDecebal import find

and now ‘find('~', '*Python*.pdf')’ gives what I want.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Can Python function return multiple data?

[Alain Ketterlin]

Grant Edwards  writes:

[...]
> Or to be a bit obtuse: Python parameters are passed by value, but all
> values are references.

Exactly, that's a perfect description. There's is no need for a new
name. As a corollary, all names (including "variables" and object
attributes) are references.

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

Re: Can Python function return multiple data?

[Alain Ketterlin]

Steven D'Aprano  writes:

> On Fri, 5 Jun 2015 04:17 am, Alain Ketterlin wrote:
>
>> Steven D'Aprano  writes:
>> 
>> [...]
>>> But you still find a few people here and there who have been exposed to
>>> Java foolishness, and will argue that Python is "pass by value, where the
>>> value is an implementation dependent reference to the thing that you
>>> thought was the value".
>> 
>> I find this clear and concise. Can you exhibit an example that would not
>> match this description?
>> 
>>> In other words, according to this Java philosophy, following `x = 23`,
>>> the value of x is not 23 like any sane person would expect, but some
>>> invisible and unknown, and unknowable, reference to 23.
>> 
>> No, Java doesn't work like that for primitive types (assuming that by
>> "Java" you mean the language and execution environment defined in
>> reference documents).
>
> Perhaps the fact that I used Python syntax was too ambiguous  but I
> was talking about Python. However, the same applies to Java, if you
> substitute an object for the primitive value:
>
> Integer x = new Integer(23);
>
> According to the Java philosophy, the value of x is not the object
> Integer(23) like any sane person would expect,

Yes, clear (except for sanity).

> but some invisible and unknown reference to that object.

I think Python does exactly this (Grant Edwards has a good explanation
of it els ethread).

At least, that is how I understand it, and that is how I teach it, and I
have never met a single case where it failed to describe and explain the
actual behavior of the program.

That's why I was asking for an example to motivate your claim on sanity.

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