Re: python list index - an easy question

[alister]

On Sat, 17 Dec 2016 11:10:22 -0800, John wrote:

> Hi,
> 
>I am new to Python, and I believe it's an easy question. I know R and
>Matlab.
> 
> 
 x=[1,2,3,4,5,6,7]
 x[0]
> 1
 x[1:5]
> [2, 3, 4, 5] *
> 
> My question is: what does x[1:5] mean? By Python's convention, the
> first element of a list is indexed as "0". Doesn't x[1:5] mean a
> sub-list of x, indexed 1,2,3,4,5? If I am right, it should print
> [2,3,4,5,6]. Why does it print only [2,3,4,5]?
> 
>Thanks!!
> 
> John

as well as al the other excellent & detailed explanations
think of the slice working on the gaps between the elements (the ',') & 
not the element itself




-- 
In the long run we are all dead.
-- John Maynard Keynes
-- 
https://mail.python.org/mailman/listinfo/python-list

print() with no newline

[ElChino]

In this snippet:
  import sys
  PY3 = (sys.version_info[0] >= 3)

  def print_no_nl (s):
if PY3:
  print (s, end="")
else:
  print (s),

I'm getting a syntax error in Python2. Python3 is fine.
How can I make this Py2+3 compatible?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: print() with no newline

[Chris Warrick]

On 18 December 2016 at 13:25, ElChino  wrote:
> In this snippet:
>   import sys
>   PY3 = (sys.version_info[0] >= 3)
>
>   def print_no_nl (s):
> if PY3:
>   print (s, end="")
> else:
>   print (s),
>
> I'm getting a syntax error in Python2. Python3 is fine.
> How can I make this Py2+3 compatible?

With a __future__ import, the Python 3 syntax will work with both Pythons:

from __future__ import print_function
print(s, end="")

-- 
Chris Warrick 
PGP: 5EAAEA16
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: print() with no newline

[ElChino]

Chris Warrick wrote:

>> I'm getting a syntax error in Python2. Python3 is fine.
>> How can I make this Py2+3 compatible?
> 
> With a __future__ import, the Python 3 syntax will work with both Pythons:
> 
> from __future__ import print_function
> print(s, end="")

Thanks. Lovely.


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

Re: python list index - an easy question

[Paul Götze]

Hi John,

there is a nice short article by E. W. Dijkstra about why it makes sense
to start numbering at zero (and exclude the upper given bound) while
slicing a list. Might give a bit of additional understanding.

http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF

- paul


http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF


Am 17.12.2016 um 20:10 schrieb John:
> Hi, 
>
>I am new to Python, and I believe it's an easy question. I know R and 
> Matlab.
>
> 
 x=[1,2,3,4,5,6,7]
 x[0]
> 1
 x[1:5]
> [2, 3, 4, 5]
> *
>
> My question is: what does x[1:5] mean? By Python's convention, the first 
> element of a list is indexed as "0". Doesn't x[1:5] mean a sub-list of x, 
> indexed 1,2,3,4,5? If I am right, it should print [2,3,4,5,6]. Why does it 
> print only [2,3,4,5]?
>
>Thanks!!
>
> John


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

Re: python list index - an easy question

[BartC]

On 18/12/2016 10:59, Paul Götze wrote:

Hi John,

there is a nice short article by E. W. Dijkstra about why it makes sense
to start numbering at zero (and exclude the upper given bound) while
slicing a list. Might give a bit of additional understanding.

http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF


(This from somebody who apparently can't use a typewriter?!)

I don't know if the arguments there are that convincing. Both lower 
bounds of 0 and 1 are useful; some languages will use 0, some 1, and 
some can have any lower bound.


But a strong argument for using 1 is that in real life things are 
usually counted from 1 (and measured from 0).


So if you wanted a simple list giving the titles of the chapters in a 
book or on a DVD, on the colour of the front doors for each house in a 
street, usually you wouldn't be able to use element 0.


As for slice notation, I tend to informally use (not for any particulr 
language) A..B for an inclusive range, and A:N for a range of length N 
starting from A.


In Python you can also have a third operand for a range, A:B:C, which 
can mean that B is not necessarily one past the last in the range, and 
that the A <= i < B condition in that paper is no longer quite true.


In fact, A:B:-1 corresponds to A >= i > B, which I think is the same as 
condition (b) in the paper (but backwards), rather (a) which is favoured.


Another little anomaly in Python is that when negative indices are used, 
it suddenly switches to 1-based indexing! Or least, when -index is 
considered:


  x = [-4,-3,-2,-1]

  print x[-1]   # -1  Notice the correspondence here...
  print x[-2]   # -2

  x = [1, 2, 3, 4]

  print x[1]# 2   ...and the lack of it here
  print x[2]# 3


--
Bartc

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

Re: python list index - an easy question

[alister]

On Sun, 18 Dec 2016 16:21:20 +, BartC wrote:

> On 18/12/2016 10:59, Paul Götze wrote:
>> Hi John,
>>
>> there is a nice short article by E. W. Dijkstra about why it makes
>> sense to start numbering at zero (and exclude the upper given bound)
>> while slicing a list. Might give a bit of additional understanding.
>>
>> http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF
> 
> (This from somebody who apparently can't use a typewriter?!)
> 
> I don't know if the arguments there are that convincing. Both lower
> bounds of 0 and 1 are useful; some languages will use 0, some 1, and
> some can have any lower bound.
> 
> But a strong argument for using 1 is that in real life things are
> usually counted from 1 (and measured from 0).
> 
> So if you wanted a simple list giving the titles of the chapters in a
> book or on a DVD, on the colour of the front doors for each house in a
> street, usually you wouldn't be able to use element 0.
> 
> As for slice notation, I tend to informally use (not for any particulr
> language) A..B for an inclusive range, and A:N for a range of length N
> starting from A.
> 
> In Python you can also have a third operand for a range, A:B:C, which
> can mean that B is not necessarily one past the last in the range, and
> that the A <= i < B condition in that paper is no longer quite true.
> 
> In fact, A:B:-1 corresponds to A >= i > B, which I think is the same as
> condition (b) in the paper (but backwards), rather (a) which is
> favoured.
> 
> Another little anomaly in Python is that when negative indices are used,
> it suddenly switches to 1-based indexing! Or least, when -index is
> considered:
> 
>x = [-4,-3,-2,-1]
> 
>print x[-1]   # -1  Notice the correspondence here...
>print x[-2]   # -2
> 
>x = [1, 2, 3, 4]
> 
>print x[1]# 2   ...and the lack of it here print x[2]   
># 3


as I said earlier
take the indicates as being the spaces between the elements & it makes 
much more sense


-- 
falsie salesman, n:
Fuller bust man.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python list index - an easy question

[Michael Torrie]

On 12/18/2016 09:21 AM, BartC wrote:
> On 18/12/2016 10:59, Paul Götze wrote:
>> Hi John,
>>
>> there is a nice short article by E. W. Dijkstra about why it makes sense
>> to start numbering at zero (and exclude the upper given bound) while
>> slicing a list. Might give a bit of additional understanding.
>>
>> http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF
> 
> (This from somebody who apparently can't use a typewriter?!)
> 
> I don't know if the arguments there are that convincing. Both lower 
> bounds of 0 and 1 are useful; some languages will use 0, some 1, and 
> some can have any lower bound.
> 
> But a strong argument for using 1 is that in real life things are 
> usually counted from 1 (and measured from 0).
> 
> So if you wanted a simple list giving the titles of the chapters in a 
> book or on a DVD, on the colour of the front doors for each house in a 
> street, usually you wouldn't be able to use element 0.

It also depends on whether you want to number the spaces between the
objects or the objects themselves. To use your DVD example, the first
chapter will probably be starting at time zero, not time one.

In another example, babies start out at "zero" years old not "one."  But
at the same time we refer the first year of life.  Maybe it's not a
phrase much used these days but it used to be common to say something
like "in my 15th year," meaning when I was 14.  Maybe a more common use
would be "the first year of my employment at this company."

I'm not sure it makes sense to having slicing be zero-based but indexing
itself be 1-based, but I think a case could have been made (though I'm
glad it was not).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: OT - "Soft" ESC key on the new MacBook Pro

[mm0fmf]

On 15/12/2016 18:05, Peter Pearson wrote:

On Wed, 14 Dec 2016 11:50:30 -0600, Skip Montanaro wrote:

On Wed, Dec 14, 2016 at 11:40 AM, Peter Pearson
 wrote:

Train your fingers to use C-[.


As I recall, the location of the Ctrl key was one of the differences
between Sun and PC101 keyboards. Doesn't matter so much now, as Sun
has gone the way of the dodo, but it moved around more for me than ESC
over the years.


Absolutely right.  Random migrations of the Ctrl key annoyed so many
of us set-in-our-ways geezers that Linux distributions always seem to
come with an easily activated option to put the Ctrl key where it
belongs, namely to the left of the A, right where God put it on Adam's
ASR 33.


+1 for knowing where CTRL should be.
Bonus +1 for having used an ASR33.

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

Re: OT - "Soft" ESC key on the new MacBook Pro

[Skip Montanaro]

> +1 for knowing where CTRL should be.
Bonus +1 for having used an ASR33.

;-)


I'm sure I must have used an ASR33, but can't recall what it might have
been connected to. I do remember using card punch machines for IBM 360
input in 1972 at USC, and toggling front panel switches for binary input on
a PDP-11 in one engineering class in grad school at Iowa. Hand assembling
your program isn't terrific fun.

With this polar vortex going on, I'm not sure when I'll have the cojones to
brave the weather for an otherwise unnecessary trip to the Apple Store.

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

Re: OT - "Soft" ESC key on the new MacBook Pro

[Gregory Ewing]

mm0fmf wrote:

+1 for knowing where CTRL should be.
Bonus +1 for having used an ASR33.


And it's quite remarkable that the designers of the ASR33
knew exactly where it would need to be for Emacs users
years later! I think Richard Stallman must have a time
machine as well.

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

Re: Best attack order for groups of numbers trying to destroy each other, given a victory chance for number to number attack.

[skybuck2000]

Dennis wrote:



"
Instead you /now/ have ONE set of R marching down FOUR sets of B

RT  RD  RF  RP  <-  
attackers
BT  BF  BF  BP  
round 1
BF  BD  BP  BF  
round 2
BD  BP  BD  BD  
round 3
BP  BT  BT  BT  
round 4 
"

Yes this is how the problem works.

Also keep in mind that an attack is only valid if the target is still alive, 
otherwise the attacker would move to the next one.

So pre-computing an attack plan/outcome or storing it might not be so usefull 
for on color, since the other color might already be dead and thus attack plan 
was calculated incorrectly potentially.

So it's quite a difficult/complex/dynamic problem !
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python list index - an easy question

[Cameron Simpson]

On 18Dec2016 16:21, BartC  wrote:

On 18/12/2016 10:59, Paul Götze wrote:

there is a nice short article by E. W. Dijkstra about why it makes sense
to start numbering at zero (and exclude the upper given bound) while
slicing a list. Might give a bit of additional understanding.

http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF


(This from somebody who apparently can't use a typewriter?!)

I don't know if the arguments there are that convincing. Both lower 
bounds of 0 and 1 are useful; some languages will use 0, some 1, and 
some can have any lower bound.


0 makes a lot of arithmetic simpler if you think of the index as the offset 
from the start of the array/list.


But a strong argument for using 1 is that in real life things are 
usually counted from 1 (and measured from 0).


Shrug. Yep. But again, if you visualise the index as an offset (== "measure") 
it is a natural fit.


Another little anomaly in Python is that when negative indices are used, it 
suddenly switches to 1-based indexing! Or least, when -index is considered:


Not if you consider it to count from the range end. So range 0:5 (which in 
Python includes indices 0,1,2,3,4); index -1 places you at 5-1 ==> 4, which is 
consistent. Again, this makes a lot of the arithmetic simpler.


See sig quote for another example of a python style range: birth to death.

Cheers,
--
Cameron Simpson 

There's no need to worry about death, it will not happen in your lifetime.
   - Raymond Smullyan
--
https://mail.python.org/mailman/listinfo/python-list

Re: python list index - an easy question

[BartC]

On 18/12/2016 21:04, Michael Torrie wrote:

On 12/18/2016 09:21 AM, BartC wrote:



So if you wanted a simple list giving the titles of the chapters in a
book or on a DVD, on the colour of the front doors for each house in a
street, usually you wouldn't be able to use element 0.


It also depends on whether you want to number the spaces between the
objects or the objects themselves. To use your DVD example, the first
chapter will probably be starting at time zero, not time one.

In another example, babies start out at "zero" years old not "one."  But
at the same time we refer the first year of life.  Maybe it's not a
phrase much used these days but it used to be common to say something
like "in my 15th year," meaning when I was 14.  Maybe a more common use
would be "the first year of my employment at this company."


There's the fence analogy (perhaps similar to what alister said):

You have a fence made up of one-metre-wide panels that fit between two 
posts.


For a 10-metre fence, you need 11 posts, and 10 panels.

The posts can conveniently be numbered from 0 to 11, as that also gives 
you the distance of each one from the start of the fence.


But posts are thin. Panels are wide, and they might as well be 
conventionally numbered from 1, as you can't use the panel number to 
tell you how far it is from the start (is it the left bit of the panel 
or the right bit?).


Panels obviously correspond to the data in each list element; posts are 
harder to place, except perhaps as alister's commas (but then there have 
to be extra invisible commas at each end).


(The fence needs to divide an open area not surround an enclosed space, 
as otherwise the analogy breaks down; you will have N panels and N posts!)



I'm not sure it makes sense to having slicing be zero-based but indexing
itself be 1-based, but I think a case could have been made (though I'm
glad it was not).


They need to be the same.

(Zero-based necessarily has to be used with offsets from pointers from 
example. In C, array indexing is inextricably tied up with 
pointer/offset arithmetic, so indexing /has/ to be zero-based.


But that doesn't apply in other languages where the choice could have 
been different.)


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

Re: python list index - an easy question

[BartC]

On 18/12/2016 22:21, BartC wrote:

On 18/12/2016 21:04, Michael Torrie wrote:

On 12/18/2016 09:21 AM, BartC wrote:



So if you wanted a simple list giving the titles of the chapters in a
book or on a DVD, on the colour of the front doors for each house in a
street, usually you wouldn't be able to use element 0.


It also depends on whether you want to number the spaces between the
objects or the objects themselves. To use your DVD example, the first
chapter will probably be starting at time zero, not time one.

In another example, babies start out at "zero" years old not "one."  But
at the same time we refer the first year of life.  Maybe it's not a
phrase much used these days but it used to be common to say something
like "in my 15th year," meaning when I was 14.  Maybe a more common use
would be "the first year of my employment at this company."


There's the fence analogy (perhaps similar to what alister said):

You have a fence made up of one-metre-wide panels that fit between two
posts.

For a 10-metre fence, you need 11 posts, and 10 panels.

The posts can conveniently be numbered from 0 to 11,


... 0 to 10.

That's the thing with zero-based; it might reduce some off-by-one errors 
but could introduce others.


With the panels you have 10 panels numbered 1 to 10; what could be 
simpler or more intuitive?


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

Re: The right way to 'call' a class attribute inside the same class

[Erik]

NOTE: If you found this message by searching for help on how Python 
works, be aware that it's discussing how JavaScript works, not Python! 
Look elsewhere :)


Chris, this isn't directed at you (I think you get it) - just following 
up with some detail for anyone who might discover this sub-thread when 
searching in future.


On 18/12/16 01:21, Chris Angelico wrote:

On Sun, Dec 18, 2016 at 12:01 PM, Erik  wrote:

I wish I could find the resource I originally learned this stuff from,
because it's quite enlightening and I'd like to link to it here



Sounds like how Michael Schwern introduces his "Git for Ages 4 and Up"
talk


Just in case anyone is remotely interested, I've found a reasonable link 
(but it's not the one I was looking for).


I realise this is off-topic for a Python list, but it has come up 
because of a Python question so I thought why not ... (I wish someone 
had explained this to me in roughly-Python terms when I first had to 
deal with JS ;)).


In short, AIUI, all JS functions have an implicit initial parameter 
which is named 'this'. What that parameter is bound to depends on the 
context of the call to that function object. In Python the callable is 
of a particular type (method, function, generator) but on JS (for the 
purposes of this discussion (pun intended ;)) they are all equal and 
it's the calling context that determines what happens.


A JS function, whether declared with "function Foo(a, b, c) {}" or as an 
expression "function (a, b, c) {}" has an implicit initial parameter 
which is bound to the variable 'this' (so they are really "function 
Foo(this, a, b, c) {}", "function (this, a, b, c) {}").


The value of that initial first parameter is determined by how they are 
called. There are three main ways:


1) Method call:
   "obj.foo(1, 2, 3)" is syntactic sugar for "obj.foo(obj, 1, 2, 3)".

2) Function call:
   "foo(1, 2, 3)" is syntactic sugar for "foo(GLOBAL_OBJECT, 1, 2, 3)" 
where "GLOBAL_OBJECT" is whatever the execution environment defines as 
being the global object. In a browser, I think it's "window", in the JS 
strict mode, I think it's "undefined" (i.e., no object), in Node.js I 
think it might be something else entirely.


3) Constructor call:
   "new foo(1, 2, 3)" is syntactic sugar for "foo(NEWOBJ, 1, 2, 3)" 
where NEWOBJ is a newly allocated, empty object.


The other way of invoking a function object is via its "call" method 
where the initial 'this' parameter can be explicitly given - 
"foo.call(SPAM, 1, 2, 3)" - which is how to implement bound methods and 
that sort of thing.



The main area of confusion seems to be when passing function expressions 
(closures) as a callback to another function:


function Foo() {
  ham(this.a, this.b, function (x) { this.frobnicate(x); });
}

Let's assume this is called with "obj.Foo();". In the function itself, 
'this', is bound to 'obj'. However, in the body of the (anonymous) 
function expression/closure (which sort of looks to be at the same scope 
as everything else) 'this' is bound according to the rules above being 
applied to at the point it is called - the object it is bound to almost 
certainly doesn't have the "frobnicate" method expected.


This is why the following works:

function Foo() {
  _this = this;
  ham(this.a, this.b, function (x) { _this.frobnicate(x); });
}

The closure now knows how to address the 'this' object for the original 
method even though it is called later by whatever 'ham()' does. Using a 
bound function as the callback works in the same way.




Anyway, off-topic as I said, but if it helps other Pythoneers get to 
grips with some of the weird JS semantics, it's all good :)




The link I *did* find (which probably has a bit more depth) is:

https://rainsoft.io/gentle-explanation-of-this-in-javascript/


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

Re: The right way to 'call' a class attribute inside the same class

[Chris Angelico]

On Mon, Dec 19, 2016 at 9:52 AM, Erik  wrote:
>
> 1) Method call:
>"obj.foo(1, 2, 3)" is syntactic sugar for "obj.foo(obj, 1, 2, 3)".

And the bit you have to be REALLY careful of when working with both
Python and JS is that you have to have "obj.foo(...)" as a single
expression. Consider:

# Python
lst = []
func = lst.append
func(1); func(2); func(3)
# lst now holds [1,2,3]

// JavaScript
var arr = []
var func = arr.push.bind(arr) // IMPORTANT
func(1); func(2); func(3)
// arr now contains [1,2,3]

If you just take "arr.push", you don't get a bound method. You get an
unbound method. You have to explicitly bind that back to the array
object, or its "this" pointer won't be set.

This is so important (eg with callback functions) that JS introduced a
new type of function to help deal with the problem...

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

Re: python list index - an easy question

[Ben Bacarisse]

BartC  writes:

> On 18/12/2016 10:59, Paul Götze wrote:
>> there is a nice short article by E. W. Dijkstra about why it makes sense
>> to start numbering at zero (and exclude the upper given bound) while
>> slicing a list. Might give a bit of additional understanding.
>>
>> http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF
>
> (This from somebody who apparently can't use a typewriter?!)
>
> I don't know if the arguments there are that convincing. Both lower
> bounds of 0 and 1 are useful; some languages will use 0, some 1, and
> some can have any lower bound.
>
> But a strong argument for using 1 is that in real life things are
> usually counted from 1 (and measured from 0).

The index of an element is a measure, not a count.


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

read a table and make a basic plot

[metal . suomi]

Hi, I'm learning python and full of extensive tutorials around. Getting a bit 
lost and overflowed in my head with tuples, dictionaries, lists, etc ... etc... 
Everything great, but I'd like to perform some basic task while learning the 
rest. For example, I'm having a hard time to find some practical info to get me 
up to speed. E.g. doing the following list of tasks:

- read a file named 'data.dat' (let's suppose it has 13 columns and n lines) 
and read column 3 and 4

-plot column 3 vs column 4

-write a file 'outcome.txt' which has column 3 and 4

How do I do read and write of files? Is there some extra library I need for 
doing plots? I have read about  matplotlib.pyplot. How can I do the plot above 
using this library? (running python3.5 in OSX).

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