Re: [Tutor] Python 3 - bugs or installation problem
On 05/03/15 01:53, Phil wrote: I hope this is not another embarrassingly obvious answer to a simple question. Python 3, under Kubuntu. xrange() fails whereas range() is accepted. Could this be an installation problem? There are many incompatible changes in Python v3 compared with v2. Some are obvious like the removal of xrange and raw_input and a few others. Some are slightly more subtle like the change of print from a statement to a function. Still others are simply name changes to improve consistency of naming. The standard library has had a major makeover too and many modules have been reorganised and renamed. If you are moving to v3 you need to keep the documentation handy for the first few weeks to quickly check errors to see if its a bug or a feature! The good news is that once you get used to ut most of the changes are for the better. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Strengths & weaknesses of Python lists compared to "old school" arrays [Was "Fixed Vector Array"]
On 04/03/15 19:10, boB Stepp wrote:
learned of programming via FORTRAN and BASIC (various incarnations).
These used multidimensional array-based thinking.
... I don't recollect anything similar to Python lists
There weren't, and it was a common programming exercise to
create them using arrays and an API. This made sense since it
demonstrated how to enrich the language with a superior
data structure. Unfortunately some courses seem to have
decided that its equally good to go from the rich lists
to simple arrays! Thus removing or replicating built in
functionality.
those languages way back then. In doing physics-related programming it
was not unusual to have a need for 3- or 4-dimensional arrays, and
sometimes more.
That hasn't changed
What are the strengths and weaknesses of Python lists compared to "old
school" arrays?
This will be a somewhat subjective assessment because each programmers
use cases will vary. My summary would be that in 17 years of using
Python I've never felt the need of a traditional array.
It doesn't mean there aren't cases where they might have an edge,
but usually there is a more Pythonic solution. Such as using
a dictionary to create a sparse array simulation, or creating
a class.
1) If the data involved is strictly numerical, does this alter
your answer? Especially if multidimensional matrix calculations are
involved?
No. Numbers are just objects, there is no inherejnt advantage to using
arrays v lists.
2) If either numerical or string data is allowed to be stored,
does this change your answer?
Strictly speaking a traditional array is single typed so you can't have
strings and numbers mixed (although you could have an array of variant
records which achieves the same.)
3) Have "old school" arrays evolved into something more flexible
in most programming languages?
Yes, exactly that's why most modern languages (from about 1990 onwards)
have native collection objects that work more or less like Python lists.
Either as a native data type or via a standard library.
4) Are there other clarifying questions I should be asking on this
topic that are not occurring to me?
Issues such as performance (arrays are usually direct memory access)
and resource consumption (simply memory block arrays with no extra
pointers to maintain) enter into the picture. Also compatibility with
other languages. An array is typically implemented as a simple block
of memory and so can be accessed from most languages. Lists tend
to be much more sophisticated structures requiring an API that
may not be (fully) supported in another language.
What is a complete list of the "things" array-style thinking allow,
but that Python lists don't? And for those "things", what would be a
Python way of handling them?
Hmm, a "complete list" is hard to pinpoint. Especially since
there is nearly always a way round it. Also it depends on which language
you are comparing to. For example C is almost optimised for native
arrays with direct pointer access and pointer arithmetic allowing some
very slick array handling tricks. But in BASIC those things are just not
possible. So are we comparing Python lists
to BASIC arrays (in which case Python wins nearly every time) or Python
lists to C arrays, in which case C has several tricks up its sleeve.
(Note Visual Basic arrays are much more sophisticated that vanilla BASIC
arrays, they are more like Python lists)
Here are some typical concepts:
1) arrays are typically created at compile time so there is no
initialisation cost. Similarly by being fixed size there is no
performance cost in adding new members(up to the fixed size limit)
2) arrays can be empty and sparcely populated.
You cannot do this in Python:
array = [0,1,2,,8,9,,,12]
you need to specify None in the empty slots
But you can use a dictionary:
array = {0:0, 1:1, 2:2, 8:8, 9:9, 12,12}
But that's more cumbersome to create/maintain.
But its just as easy to use...
3) In some language you can create the array as single entities
but then use them in pairs or triples etc. In Python you need a
combination of slicing and helper functions to do that. but
its a fairly esoteric case mainly, in my experience, used
for systems programming in segmented memory architectures.
4) Arrays as memory blocks can be quickly copied or moved or
dumped to disk/networks using byte level operations. This can
be important in high performance applications.
I'm running out of ideas here, I'm sure others will chip in
with more.
wanted to address an item in a 3-dimensional array, I would use
something like (x, y, z) whereas the Python list form amounts to
[x][y][z] .
That's just a syntax thing, Python could have allowed single
bracketing of index, Guido chose to follow his mantra of explicit
is better than implicit. Many array based languages (including C)
also require multiple explicit indices.
addressing pales in comparison to the power and flexibility of the
"s
Re: [Tutor] Strengths & weaknesses of Python lists compared to "old school" arrays [Was "Fixed Vector Array"]
On Wed, Mar 04, 2015 at 01:10:11PM -0600, boB Stepp wrote: > What are the strengths and weaknesses of Python lists compared to "old > school" arrays? Python lists are objects, containing a sequence of objects. Objects are "fatter" than low-level data like machine ints. (They take up more space.) Python lists are over-allocated. E.g. when you create an empty list, Python allocates enough space for (I'm guessing) eight items. When it fills up, and you add another item, the list is *quadrupled* to allow enough space for 32 items. When those items are all full, and you add another item, it quadruples in size again. At some point it stops quadrupling and merely doubles in size, but the over-all result is that *on average* Python lists are about 50% bigger than actually needed. Why do they do that? Because that saves time. Python lists trade off a bit of extra space for extra speed. Resizing the list is expensive, and it can be mathematically proven that by doubling in size like this, appending to a list works out to be approximately constant time on average, regardless of whether the list is nearly empty or full. The technical term used is "constant time amortized". Python lists can hold any arbitrary object. Arrays (from the `array` module) can only hold low-level types like C integers or floats. That saves memory, but is actually slower. > 1) If the data involved is strictly numerical, does this alter > your answer? Especially if multidimensional matrix calculations are > involved? Absolutely. In that case, use numpy, which has powerful numeric functions operating at high speed on low-level C-like arrays. py> import numpy py> L = [1] * 500 py> A = numpy.array(L) py> with Stopwatch(): ... sum(L) ... 500 time taken: 0.098561 seconds py> with Stopwatch(): ... numpy.sum(A) ... 500 time taken: 0.008987 seconds > 2) If either numerical or string data is allowed to be stored, > does this change your answer? If you have mixed data, use lists. > 3) Have "old school" arrays evolved into something more flexible > in most programming languages? I don't know about "most" languages, but generally high-level languages will tend to have something similar to Python lists, while low-level languages tend to have things closer to C arrays. > 4) Are there other clarifying questions I should be asking on this > topic that are not occurring to me? Probably :-) > > If Array returns a fixed size array can't you just always assign to the > > index position. In other words does the array need to be filled > > in a sequential manner or could you have a 'hole' in the middle (one of the > > few things an array allows that a list doesn't - although you can just use a > > dictionary if that's really important! I'm not really sure that arrays can have holes in them. Basic low-level arrays, like found in Pascal, C or Fortran, cannot. There are ways and means of creating so-called "sparse arrays", but they typically don't allow you to just have arbitrary gaps in the array, rather they have some sort of symmetry or pattern, e.g. a two dimensional array like: [ a b c d e f 0 g h i j k 0 0 l m n o 0 0 0 p q r 0 0 0 0 s t 0 0 0 0 0 u ] with all zeroes below the diagonal may be able to be programmed in a more efficient way. > What is a complete list of the "things" array-style thinking allow, > but that Python lists don't? And for those "things", what would be a > Python way of handling them? The biggest -- probably only -- advantage is that with low-level arrays, you can use high-speed C functions that effectively operate on the whole array at once (for some definition of "at once") instead of relatively slow item-at-a-time processing like in Python. For ten items, or ten thousand, the difference is minimal, but for serious number-crunching will millions or hundreds of millions of values, numpy will out-perform anything you can write in pure Python. -- Steve ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Strengths & weaknesses of Python lists compared to "old school" arrays [Was "Fixed Vector Array"]
On 05/03/15 12:20, Steven D'Aprano wrote:
index position. In other words does the array need to be filled
in a sequential manner or could you have a 'hole' in the middle...
I'm not really sure that arrays can have holes in them. Basic low-level
arrays, like found in Pascal, C or Fortran, cannot.
They can in the sense that I originally meant:
You declare the array and at compile time a block of memory
is reserved but it contains random trash, they are not usually
pre-filled with, say zero. (Actually, Pascal may well do that,
it sounds like the kind of thing Pascal would do...)
You can then allocate values to any index within that array,
you don't need to do it sequentially as with a python list
You can fake it in Python by filling the array with a null
value such as zero or None but it takes explicit action and
run time resources to do that, unlike the C/Pascal equivalent.
Alternatively just use a dict.
means of creating so-called "sparse arrays",
I wasn't really thinking of sparse arrays in the pure CS sense,
just a regular C array which does not necessarily have a
specified value at certain positions.
// file: openarray.c
#include
void main(){
static int ia[10];
ia[0] = 3;
ia[9] = 42;
printf("array = %d,%d\n",ia[0],ia[9]);
printf("splat! %d\n",ia[4]);
}
$ make openarray
$ ./openarray
array = 3,42
splat! 4195696
You can of course also initialize to zero by making it a
static array, but that has other consequences that you
may not want.
Hopefully that clarifies what I was thinking about.
Also I should add that this behaviour is rarely a
"Good Thing". Uninitialized values are usually
to be avoided!
PS.
Totally off topic but...
I just checked Pascal - boy am I rusty!
program openarray;
var ia : array[0..9] of integer;
begin
ia[0] := 3;
ia[9] := 42;
writeln('array holds ', ia[0],' and ', ia[9]);
writeln('splat - ',ia[4]);
end.
$ fpc openarray.pas
$ ./openarray
array holds 3 and 42
splat - 0
So yes it does fill with zeros. Thank you Nicholas...
--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Python 3 - bugs or installation problem
On Wed, Mar 4, 2015 at 8:53 PM, Phil wrote:
> phil@Asus:~/Python$ python3
> Python 3.4.2 (default, Oct 8 2014, 13:18:07)
> [GCC 4.9.1] on linux
> Type "help", "copyright", "credits" or "license" for more information.
for row in xrange(0,12):
> ... print(row)
> ...
> Traceback (most recent call last):
> File "", line 1, in
> NameError: name 'xrange' is not defined
That looks like proper python 3 behavior, since xrange was replaced by
range in python 3 (the old behavior of creating an actual list from
range is now spelled list(range(0,12))).
> Under IDLE 3:
>
> for row in xrange(0,12):
> print('test ',row)
>
> xrange() is accepted but prints the following:
>
> ('test ', 0)
> ('test ', 1)
> ('test ', 2)
> ('test ', 3)
> ('test ', 4)
Are you 100% positive that's the python 3 IDLE? Based on the output
you show, that's python 2.
--
Jerry
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Strengths & weaknesses of Python lists compared to "old school" arrays [Was "Fixed Vector Array"]
Thank you very much Alan and Steve for your detailed answers. You have clarified many things and sent me off searching for more information on variant records, tagged and untagged unions, sparse arrays, linked lists, how memory allocation is affected by these topics and some other items. And I would like to throw out a general THANK YOU to all of the "tutors", who so generously donate your time. I know I have gotten many detailed, patient answers to my queries. I just hope I truly absorb and properly utilize the wisdom passed on to me! boB ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Python 3 - bugs or installation problem
On 05/03/2015 08:10, Alan Gauld wrote: On 05/03/15 01:53, Phil wrote: I hope this is not another embarrassingly obvious answer to a simple question. Python 3, under Kubuntu. xrange() fails whereas range() is accepted. Could this be an installation problem? There are many incompatible changes in Python v3 compared with v2. Some are obvious like the removal of xrange and raw_input and a few others. Some are slightly more subtle like the change of print from a statement to a function. Still others are simply name changes to improve consistency of naming. The standard library has had a major makeover too and many modules have been reorganised and renamed. If you are moving to v3 you need to keep the documentation handy for the first few weeks to quickly check errors to see if its a bug or a feature! Starting here https://docs.python.org/3/howto/pyporting.html -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Strengths & weaknesses of Python lists compared to "old school" arrays [Was "Fixed Vector Array"]
On 05/03/2015 10:07, Alan Gauld wrote: On 04/03/15 19:10, boB Stepp wrote: wanted to address an item in a 3-dimensional array, I would use something like (x, y, z) whereas the Python list form amounts to [x][y][z] . That's just a syntax thing, Python could have allowed single bracketing of index, Guido chose to follow his mantra of explicit is better than implicit. Many array based languages (including C) also require multiple explicit indices. You could regard this a code smell in Python. Perhaps the most repeated thing written here by beginners is something like:- for i in range(len(this)): for j in range(len(that)): for k in range(len(other)): if mystruct[i][j][k] then: ... An experienced Pythonista's code would maybe be:- for x in mystruct: for y in x: for z in y: if z: ... -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Strengths & weaknesses of Python lists compared to "old school" arrays [Was "Fixed Vector Array"]
Original Message - > From: Mark Lawrence > To: tutor@python.org > Cc: > Sent: Thursday, March 5, 2015 9:54 PM > Subject: Re: [Tutor] Strengths & weaknesses of Python lists compared to "old > school" arrays [Was "Fixed Vector Array"] > > On 05/03/2015 10:07, Alan Gauld wrote: >> On 04/03/15 19:10, boB Stepp wrote: >>> wanted to address an item in a 3-dimensional array, I would use >>> something like (x, y, z) whereas the Python list form amounts to >>> [x][y][z] . >> >> That's just a syntax thing, Python could have allowed single >> bracketing of index, Guido chose to follow his mantra of explicit >> is better than implicit. Many array based languages (including C) >> also require multiple explicit indices. >> > > You could regard this a code smell in Python. Perhaps the most repeated > thing written here by beginners is something like:- > > for i in range(len(this)): > for j in range(len(that)): > for k in range(len(other)): > if mystruct[i][j][k] then: > ... > > An experienced Pythonista's code would maybe be:- > > for x in mystruct: > for y in x: > for z in y: > if z: > ... > aside from the range(len)) horror: isn't this also a matter of "putting the busiest loop on the inside of nested loops"? See also the book Code Complete: https://books.google.nl/books?id=I-83BAAAQBAJ&pg=PA643&lpg=PA643&dq=%22busiest+loop%22+inside&source=bl&ots=4ER2sPjGcq&sig=UyyxYY5LSDN4Xd5B-u-Ft7zNjpo&hl=nl&sa=X&ei=TM74VLOSBIOuPdfcgFg&ved=0CDgQ6AEwAg#v=onepage&q=%22busiest%20loop%22%20inside&f=false ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
