Help for a newbie regarding code & physical switches

[Howard Spink]

I have a Pi + SD card with Pi OS + PiTfT screen

I am trying to display specific JPEGs when certain combination of GP10 inputs 
are HIGH. I would like to use Python, I have no background in programming. Can 
someone point me on the right tracks? 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Slices time complexity

[Marko Rauhamaa]

Rustom Mody :

> In short any language that is implemented on von Neumann hw will need
> to address memory.

I don't think von Neumann hardware plays a role here. I think the data
model is inherent in Python/Java/Lisp regardless of the underlying
formalism (which could be SKI combinatory calculus or any other
Turing-complete formalism).

> And although they are equal as in '==' they are not equal as in
> behavior, memory usage etc, a fact that can only be elucidated by
> box-n-arrow diagrams.

That's what I meant when I asked if you can get Python without getting
something like C first. It seems the answer is, you probably can't.


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

Help a newbie with basic coding involving physical switches

[Howard Spink]

I have ordered a Pi + SD card + PiTfT screen.

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

Re: Slices time complexity

[Rustom Mody]

On Wednesday, May 20, 2015 at 11:27:56 AM UTC+5:30, Steven D'Aprano wrote:
> On Wednesday 20 May 2015 14:30, Rustom Mody wrote:
> 
> > And what about Java?
> > http://stackoverflow.com/questions/166033/value-semantics-and-pointer-
> semantics
> 
> Congratulations, you have found yet another example of the Java community's 
> collective delusion and insistence on misusing terms for the maximum 
> confusion possible.
> 
> The mental gymnastics they go through to force the round peg of pass-by-
> sharing object semantics into the false dichotomy "pass-by-value versus 
> pass-by-reference" is just crazy.
> 
> One consequence of this is that the meaning of "call by value" depends on 
> whether the value you are talking about is a boxed or unboxed value. Unboxed 
> values are copied. Boxed values are not. Except that they are, if you 
> understand that "the value" doesn't refer to the actual value, but to some 
> hidden and implementation-dependent reference to the value.
> 
> To quote Fredrik Lundh:
> 
> well, I guess you can, in theory, value an artificial number 
> assigned to an object as much as the object itself.
> 
> "Joe, I think our son might be lost in the woods"
> "Don't worry, I have his social security number"
> 
> 
> http://effbot.org/zone/call-by-object.htm
> 
> 
> Rustom, if you are serious about this approach, then the implication is that 
> if I execute "x = 23" in Python, and I ask you what the value of x is, you 
> should answer something like "146588120" (that's the implementation 
> dependent "value", i.e. the address of the int 23).
> 
> It's just *nuts*, and all because the Java folks are unwilling or unable to 
> distinguish between the language semantics and the implementation of the 
> language. And you're falling into the same hole.

I am not arguing for the java-folks terminology or outlook.
I am arguing that for languages that execute on von Neumann machines memory
is not an optional negotiable concept.

And pointer is just first-classed memory as lambda is first-classed function.
Some languages firstclass it -- most notably C, also C# which increasingly 
fascinates me in its choices.
Others try to to unfirstclass , ie hide it in various half-assed ways -- 
Python, Java, Lisp.
Others try to hide it in the most heavy-handed way possible -- haskell

But you can never really hide it [law of leaky abstractions]

eg in haskell one makes an infinite list of ones thus

ones = 1 : ones

Now if you generalize this to

repeat x = x : repeat x
and then do
ones = repeat 1
you get poorer performance because the ones makes a box-n-arrow loop which the 
repeat does not achieve.

To get round that we do
repeat x = repeatx 
  where repeatx = x : repeatx

In short any language that is implemented on von Neumann hw will need to address
memory. The language-designer may believe that there is a choice to 
'unfirstclass' it. However people discussing language have no such choice:
If you dont have it in the formal implemented language, you must have it in the
informal discussion-language
[With a large amount of wild waving of hands] 


I dont like teaching this. viz that in python
x = [[1,2],[1,2]]
is equal to y defined as
z = [1,2]
y = [z,z]
And although they are equal as in '==' they are not equal as in behavior, 
memory usage etc, a fact that can only be elucidated by box-n-arrow diagrams.

So as far as I can I teach by tabooing extend,append and all such mutablers

In the end though this is cheating

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

Re: Slices time complexity

[Marko Rauhamaa]

Steven D'Aprano :

> Rustom, if you are serious about this approach, then the implication
> is that if I execute "x = 23" in Python, and I ask you what the value
> of x is, you should answer something like "146588120" (that's the
> implementation dependent "value", i.e. the address of the int 23).

Steven, you are trying to be facetious but end up making good points.

The "canonical" Python semantics actually states that

   x = 23

means:

   An int object with the numeric value 23 is constructed or fetched
   from a cache. A reference to the object is assigned to a variable
   whose name is "x".

> it's just *nuts*, and all because the Java folks are unwilling or
> unable to distinguish between the language semantics and the
> implementation of the language. And you're falling into the same hole.

I have yet to see a high-level language that has defined its data model
without resorting to "locations", "slots" and pointers of sorts. It
certainly is possible (lambda calculus doesn't make any reference to
objects or pointers) but hardly any alternative explanation is more
appealing to programmers' tastes and imagination than the concrete image
of boxes and arrows.


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

Re: Slices time complexity

[Steven D'Aprano]

On Wednesday 20 May 2015 15:33, Steven D'Aprano wrote:


> Someone sufficiently killed with an abacus

Er, *skilled*.


-- 
Steve

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

Re: Slices time complexity

[Steven D'Aprano]

On Wednesday 20 May 2015 14:30, Rustom Mody wrote:

> And what about Java?
> http://stackoverflow.com/questions/166033/value-semantics-and-pointer-
semantics

Congratulations, you have found yet another example of the Java community's 
collective delusion and insistence on misusing terms for the maximum 
confusion possible.

The mental gymnastics they go through to force the round peg of pass-by-
sharing object semantics into the false dichotomy "pass-by-value versus 
pass-by-reference" is just crazy.

One consequence of this is that the meaning of "call by value" depends on 
whether the value you are talking about is a boxed or unboxed value. Unboxed 
values are copied. Boxed values are not. Except that they are, if you 
understand that "the value" doesn't refer to the actual value, but to some 
hidden and implementation-dependent reference to the value.

To quote Fredrik Lundh:

well, I guess you can, in theory, value an artificial number 
assigned to an object as much as the object itself.

"Joe, I think our son might be lost in the woods"
"Don't worry, I have his social security number"


http://effbot.org/zone/call-by-object.htm


Rustom, if you are serious about this approach, then the implication is that 
if I execute "x = 23" in Python, and I ask you what the value of x is, you 
should answer something like "146588120" (that's the implementation 
dependent "value", i.e. the address of the int 23).

It's just *nuts*, and all because the Java folks are unwilling or unable to 
distinguish between the language semantics and the implementation of the 
language. And you're falling into the same hole.



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

Re: Sftp error New Help

[dieter]

ejmmann...@gmail.com writes:

> Traceback (most recent call last):
>   File "Juniper.py", line 66, in 
> device_information()
>   File "Juniper.py", line 26, in device_information
> device_connection(dev_ip,dev_username,dev_password)
>   File "Juniper.py", line 54, in device_connection
> sftp_transfer(r)
>   File "Juniper.py", line 61, in sftp_transfer
> c.put("%r" %r)
>   File "/usr/local/lib/python2.7/dist-packages/pysftp.py", line 349, in put
> confirm=confirm)
>   File "/usr/local/lib/python2.7/dist-packages/paramiko/sftp_client.py", line 
> 667, in put
> file_size = os.stat(localpath).st_size
> OSError: [Errno 2] No such file or directory: " 'juniper-results20150519-191928.txt', mode 'a' at 0x24a0780>"

Apparently, you pass to "sftp_transfer" a parameter with an unexpected
type. Looks as if it would expect a file name (and you pass a
file descriptor, referencing a closed file). Thus, pass the filename
and try again.

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

Re: Slices time complexity

[Steven D'Aprano]

On Wednesday 20 May 2015 14:30, Marko Rauhamaa wrote:

> Steven D'Aprano :
> 
>> There is a little magic elf hiding inside the computer, and when you
>> type an expression like '2 + 3', little tiny hammers bang it out in
>> Morse Code on the elf's head; in response, the elf calculates the
>> answer on his teeny tiny abacus and passes it back to the interpreter.
> 
> That would be a perfectly valid semantic explanation if it really
> predicted the output.

Which it does. State any mathematical expression involving operators and 
operands supported by Python, and I can express it in Morse code, and tell 
you exactly what result the elf will calculate.

Someone sufficiently killed with an abacus can probably even calculate it 
*using the same algorithms* that the elf will use. Being hit on the head by 
hammers is not compulsory.


>> Since this explanation explains the observed behaviour, according to
>> you it is equally valid as one involving, you know, actual facts.
> 
> It doesn't explain the observed behavior. It doesn't differentiate
> between correct and incorrect outcomes.

Perhaps when I wrote "the elf calculates the answer" it was unclear that I 
meant the *correct* answer rather than some arbitrary value which is not 
actually the answer. I will try to be more clear in the future.


-- 
Steve

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

Re: Slightly OT: Seeking (python-based) project diary tool, or framework to write one

[Frank Millman]

"jkn"  wrote in message 
news:99067d97-cad4-42f8-8fd1-b1884bed7...@googlegroups.com...
> Hi All
>as in the title, this is a little bit OT - but since ideally I'd like a
> tool written in Python, and I know readers here have wide experience of
> development/collaborative workflows etc ...
>

Have you looked at this one? -

http://taskcoach.org/

>From their home page -

"Task Coach is a simple open source todo manager to keep track of personal 
tasks and todo lists. It is designed for composite tasks, and also offers 
effort tracking, categories, notes and more."



There seems to be at least some overlap with your requirements, so it may be 
worth a look.


It uses wxPython. According to their download page it only works with Python 
2.x, but as wxPython for Python3 is getting closer, hopefully it is on their 
roadmap to target Python3 as well.

Frank Millman



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

Re: Writing a function to calculate scores

[Rustom Mody]

On Wednesday, May 20, 2015 at 9:21:51 AM UTC+5:30, Grace Anne St Clair-Bates 
wrote:
> Hello! I am trying to write a funtion that calculates scores of three random 
> dots on a "bean-bag" board that land on different holes. Each hole holds a 
> certain amount of point. I need to take where the computer has randomly 
> places three points in my turtle graphic and calculate the total score. I 
> have no idea how to do this. Please help if you can! Its really hard to 
> explain it, but if anyone has the slightest idea please let me know. Thanks!

Lets say your board of 3 rows and 4 columns has points thusly:

2 4 6 5
1 2 1 7
3 4 5 8

You could represent it in python like so

board = [[2,4,6,5],[1,2,1,7],[3,4,5,8]]

And you can get to the 7 with the expression:  board[1][3]

(Remember in programming we usually count from 0 not 1)

Does this help any?
-- 
https://mail.python.org/mailman/listinfo/python-list

Sftp error New Help

[ejmmanning]

Traceback (most recent call last):
  File "Juniper.py", line 66, in 
device_information()
  File "Juniper.py", line 26, in device_information
device_connection(dev_ip,dev_username,dev_password)
  File "Juniper.py", line 54, in device_connection
sftp_transfer(r)
  File "Juniper.py", line 61, in sftp_transfer
c.put("%r" %r)
  File "/usr/local/lib/python2.7/dist-packages/pysftp.py", line 349, in put
confirm=confirm)
  File "/usr/local/lib/python2.7/dist-packages/paramiko/sftp_client.py", line 
667, in put
file_size = os.stat(localpath).st_size
OSError: [Errno 2] No such file or directory: ""





import sys
import pysftp
import datetime
import sys
import os



from jnpr.junos import Device

def device_information():
while True:
dev_ip = raw_input("Please enter Host IP? ")
if dev_ip != "":
while True:
dev_username = raw_input("Please enter username? ")
if dev_username !="":
while True:
dev_password = raw_input("Please enter password? ")
if dev_password !="":
device_connection(dev_ip,dev_username,dev_password)

return

else:
   print(" Please enter a valid password?")

else:
print(" Please enter a valid Username?")
else:
print(" Please enter a valid Host IP?")



def device_connection(dev_ip,dev_username,dev_password):
file = datetime.datetime.now().strftime("%Y%m%d-%H%M%S")
dev = Device(host = dev_ip,user = dev_username, password = dev_password)
dev.open()
f = open('show-command.txt')

for line in iter(f):
show_command = dev.cli(line)
r = open("juniper-results" + file + ".txt",'a')
r.write("***"+ line)
r.write(show_command)
r.write('\n')
r.close()

sftp_transfer(r)
return


def sftp_transfer(r):

c = pysftp.Connection(host = "10.72.129.35",port = 22, username = 
"Anonymous" , password = "Anonymous" )
c.put("%r" %r)
return

#sftp_transfer()

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

Re: Slices time complexity

[Mark Lawrence]

On 20/05/2015 05:30, Rustom Mody wrote:

On Wednesday, May 20, 2015 at 9:54:57 AM UTC+5:30, Marko Rauhamaa wrote:

Ben Finney :


Right. So the box with an arrow coming out of it is a good metaphor for
pointers -- *in languages that have pointers*, which Python does not.

A box with an arrow coming out of it is a poor metaphor for Python's
references, since a Python reference doesn't contain anything accessible
to the programmer.


Lisp doesn't have pointers. However:

   http://upload.wikimedia.org/wikipedia/commons/1/1b/Cons-cells.svg>

   http://cs.gmu.edu/~sean/lisp/cons/>

   http://www.csee.umbc.edu/courses/331/fall11/notes/scheme/scheme2.ppt>



And what about Java?
http://stackoverflow.com/questions/166033/value-semantics-and-pointer-semantics



And what about CORAL66/250?  How do you explain Python in terms of the 
original 66 and the 250 derivative?  What is the unladen air speed 
velocity of a swallow in flight?  Who actually gives a stuff?


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: Slices time complexity

[Marko Rauhamaa]

Steven D'Aprano :

> There is a little magic elf hiding inside the computer, and when you
> type an expression like '2 + 3', little tiny hammers bang it out in
> Morse Code on the elf's head; in response, the elf calculates the
> answer on his teeny tiny abacus and passes it back to the interpreter.

That would be a perfectly valid semantic explanation if it really
predicted the output.

> Since this explanation explains the observed behaviour, according to
> you it is equally valid as one involving, you know, actual facts.

It doesn't explain the observed behavior. It doesn't differentiate
between correct and incorrect outcomes.


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

Re: Slices time complexity

[Rustom Mody]

On Wednesday, May 20, 2015 at 9:54:57 AM UTC+5:30, Marko Rauhamaa wrote:
> Ben Finney :
> 
> > Right. So the box with an arrow coming out of it is a good metaphor for
> > pointers -- *in languages that have pointers*, which Python does not.
> >
> > A box with an arrow coming out of it is a poor metaphor for Python's
> > references, since a Python reference doesn't contain anything accessible
> > to the programmer.
> 
> Lisp doesn't have pointers. However:
> 
>   http://upload.wikimedia.org/wikipedia/commons/1/1b/Cons-cells.svg>
> 
>   http://cs.gmu.edu/~sean/lisp/cons/>
> 
>   http://www.csee.umbc.edu/courses/331/fall11/notes/scheme/scheme2.ppt>
> 

And what about Java?
http://stackoverflow.com/questions/166033/value-semantics-and-pointer-semantics
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Slices time complexity

[Marko Rauhamaa]

Ben Finney :

> Right. So the box with an arrow coming out of it is a good metaphor for
> pointers — *in languages that have pointers*, which Python does not.
>
> A box with an arrow coming out of it is a poor metaphor for Python's
> references, since a Python reference doesn't contain anything accessible
> to the programmer.

Lisp doesn't have pointers. However:

  http://upload.wikimedia.org/wikipedia/commons/1/1b/Cons-cells.svg>

  http://cs.gmu.edu/~sean/lisp/cons/>

  http://www.csee.umbc.edu/courses/331/fall11/notes/scheme/scheme2.ppt>


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

Writing a function to calculate scores

[Grace Anne St Clair-Bates]

Hello! I am trying to write a funtion that calculates scores of three random 
dots on a "bean-bag" board that land on different holes. Each hole holds a 
certain amount of point. I need to take where the computer has randomly places 
three points in my turtle graphic and calculate the total score. I have no idea 
how to do this. Please help if you can! Its really hard to explain it, but if 
anyone has the slightest idea please let me know. Thanks! 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rule of order for dot operators?

[Chris Angelico]

On Wed, May 20, 2015 at 12:24 PM, Thomas 'PointedEars' Lahn
 wrote:
> And who appointed you moderator?  I would not mind if you *asked* people
> publicly for politeness as I do that myself sometimes, but I do mind the
> overall tone of your off-topic comments, your apparently trying to dictate
> what people are allowed to say here.  If that’s the way this newsgroup
> works, I am off here.  (But I seriously doubt it.)  Because that is _not_
> how Usenet is supposed to work.

Usually, the people who threaten to leave are the ones we will least
miss. Go ahead, leave if you don't like Ned asking you to be more
polite.

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

Re: Slices time complexity

[Rustom Mody]

On Wednesday, May 20, 2015 at 7:56:43 AM UTC+5:30, Steven D'Aprano wrote:
> On Wed, 20 May 2015 10:31 am, Gregory Ewing wrote:
> 
> > Steven D'Aprano wrote:
> >> Chris, that is one of the best explanations for why "references equals
> >> pointers" is *not* a good explanation for Python's behaviour.
> > 
> > Many people here seem to have lost sight of the
> > fact that the word "pointer" existed in the English
> > language long before C, and even long before computers.
> 
> Many people here seem to have lost sight of the fact that the
> word "computer" existed in the English language long before ENIAC and
> Colossus, and even before Babbage's Difference Engine.
> 
> 
> > If I draw two boxes on a blackboard with an arrow
> > between them, I think it's perfectly reasonable to
> > call that arrow a pointer.
> 
> Given how rich the English language is, and how many other words people
> could use (arrow, cue, finger, guide, index, indicator, lead, needle,
> signpost...) but don't, I think it is quite disingenuous to claim that
> people describing Python references as "pointers" mean it in the generic
> sense rather than the computer science sense.
> 
> Especially when those people often explicitly state that they are
> using "pointer" in order to make it easier for C programmers to understand.


So...

Pascal is not Niklaus Wirth's Pascal but some vague pidgin extension(s) of it.
Whereas pointer is a specific C semantics, not a broader implication from C, 
nothing connected with the general English usage.  

Playing humpty dumpty arent we?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rule of order for dot operators?

[Ned Batchelder]

On Tuesday, May 19, 2015 at 10:26:56 PM UTC-4, Thomas 'PointedEars' Lahn wrote:
> 
> And who appointed you moderator?  I would not mind if you *asked* people 
> publicly for politeness as I do that myself sometimes, but I do mind the 
> overall tone of your off-topic comments, your apparently trying to dictate 
> what people are allowed to say here.  If that's the way this newsgroup 
> works, I am off here.  (But I seriously doubt it.)  Because that is _not_ 
> how Usenet is supposed to work.

I am not a moderator, just someone who cares about the tone
in the group.  

The Python community has a code of conduct
(https://www.python.org/psf/codeofconduct/), and people on this
mailing list are expected to adhere to it.  It is where I got
the words "respectful" and "considerate".  The code of conduct
is how the Python community is supposed to work.

I'm sorry my post seemed too pushy.  Consider it a request for
polite discourse.

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

Re: Slices time complexity

[Chris Angelico]

On Wed, May 20, 2015 at 12:26 PM, Steven D'Aprano
 wrote:
> On Wed, 20 May 2015 10:31 am, Gregory Ewing wrote:
>
>> Steven D'Aprano wrote:
>>> Chris, that is one of the best explanations for why "references equals
>>> pointers" is *not* a good explanation for Python's behaviour.
>>
>> Many people here seem to have lost sight of the
>> fact that the word "pointer" existed in the English
>> language long before C, and even long before computers.
>
> Many people here seem to have lost sight of the fact that the
> word "computer" existed in the English language long before ENIAC and
> Colossus, and even before Babbage's Difference Engine.

I have a laser printer. Its address is 192.168.0.119. I also have a
laser pointer; is it equal to 192.168.0.119?

Ahh, English. So rich with equivocations.

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

Re: Rule of order for dot operators?

[Steven D'Aprano]

On Wed, 20 May 2015 11:36 am, Ned Batchelder wrote:

> Steven and Denis: you were too blunt in your objections.

Fair enough.

In my defence, I'm from Australia, and we're notorious for calling a spade a
bloody shovel.

> Be considerate. Be respectful.



-- 
Steven

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

Re: Rule of order for dot operators?

[Thomas 'PointedEars' Lahn]

Ned Batchelder wrote:

> On Tuesday, May 19, 2015 at 6:33:46 PM UTC-4, Thomas 'PointedEars' Lahn
> wrote:
>> Denis McMahon wrote:
>> > On Sun, 17 May 2015 11:45:02 +1000, Steven D'Aprano wrote:
>> >> On Sun, 17 May 2015 05:40 am, Thomas 'PointedEars' Lahn wrote:
>> >>> C.D. Reimer wrote:
>> >>> 
>> >>> Who?
>> >> Don't be a dick, Thomas.
>> > 
>> > Thomas is a professional dick, he can't help it, he's been a
>> > professional dick for years in php and javascript groups, and now he's
>> > obviously spreading himself further afield. He usually confines his
>> > wisdom to pointing out faults in other's posts, rather than offering
>> > any constructive input himself.
>> 
>> Yes, I am a professional, while you are just a dick.  Every single time.
> 
> Everyone should stop calling people names.
> 
> Thomas, you were obnoxious to the OP, and now you are being obnoxious (and
> factually incorrect) to Denis.
> 
> Steven and Denis: you were too blunt in your objections.
> 
> Be considerate. Be respectful.

Yes, I could have skipped this comment, and I am not in the habit of calling 
names; but frankly, enough is enough.  Denis is posting libellous statements 
about me in every Big 8 newsgroup in which I participate because he often 
posts awfully wrong technically statements and just cannot stand being 
corrected by me.

And who appointed you moderator?  I would not mind if you *asked* people 
publicly for politeness as I do that myself sometimes, but I do mind the 
overall tone of your off-topic comments, your apparently trying to dictate 
what people are allowed to say here.  If that’s the way this newsgroup 
works, I am off here.  (But I seriously doubt it.)  Because that is _not_ 
how Usenet is supposed to work.

For now, just EOD for me, and F'up2 poster.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Slices time complexity

[Steven D'Aprano]

On Wed, 20 May 2015 10:31 am, Gregory Ewing wrote:

> Steven D'Aprano wrote:
>> Chris, that is one of the best explanations for why "references equals
>> pointers" is *not* a good explanation for Python's behaviour.
> 
> Many people here seem to have lost sight of the
> fact that the word "pointer" existed in the English
> language long before C, and even long before computers.

Many people here seem to have lost sight of the fact that the
word "computer" existed in the English language long before ENIAC and
Colossus, and even before Babbage's Difference Engine.


> If I draw two boxes on a blackboard with an arrow
> between them, I think it's perfectly reasonable to
> call that arrow a pointer.

Given how rich the English language is, and how many other words people
could use (arrow, cue, finger, guide, index, indicator, lead, needle,
signpost...) but don't, I think it is quite disingenuous to claim that
people describing Python references as "pointers" mean it in the generic
sense rather than the computer science sense.

Especially when those people often explicitly state that they are
using "pointer" in order to make it easier for C programmers to understand.



-- 
Steven

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

Re: Convert c file to csv file(unix format) in python

[Denis McMahon]

On Tue, 19 May 2015 12:26:05 -0700, umasrinath88 wrote:

> I have shared c file with you.Iorder to convert to unix format csv,
> below are the main steps we can follow.

What you're trying to do doesn't match with what you're explaining here.

What you're actually trying to do is extract a constant data declaration 
from a c source code file and output it in a different format.

You haven't explained whether you want the hexadecimal values converted 
to decimal integers or not.

Nor have you stated whether you want the hexadecimal values as quoted 
strings or not.

I believe I have a short program that does what you require based on the 
file you sent me and what I think is the output you're looking for. 
However, before I show you my solution, I'd like to see evidence of your 
own attempt to solve the problem.

Based on the sample you sent, the output csv file is 1657 lines in 
length, and the first and last lines are:

16,0x0800,0xCC,0x16,0x00,0x20,0x35,0x15,0x00,0x08,0x29,0x15,0x00,0x08,0x2D,0x15,0x00,0x08

12,0x08006780,0x40,0x00,0x00,0x00,0x01,0x00,0x00,0x00,0xFF,0x00,0x00,0x00

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

Re: Slices time complexity

[Steven D'Aprano]

On Tue, 19 May 2015 09:00 pm, Gregory Ewing wrote:

> Chris Angelico wrote:
>> 1) Pointer arithmetic simply doesn't exist in Python. Arrays/lists are
>> not just pointers to their first elements, and subscripting is most
>> definitely NOT "add to pointer and dereference".
>> 2) In fact, dereferencing as a whole isn't really a 'thing' either. At
>> best, it happens automatically.
>> 3) References actually mean something. Copying a pointer doesn't.
>> Whether the Python you're using is refcounted (CPython) or
>> mark-and-sweep (uPy, I think) or some other model, an additional
>> reference to the same object will prevent it from being disposed of,
>> which isn't the case in C.
>> 4) A pointer is itself a value. You can pass a
>> pointer-to-local-variable to another function and have that function
>> change a local variable.
>> 5) Furthermore, since a pointer is a value, you can have pointers to
>> pointers, etc. Doesn't make any sense in Python.
> 
> FWIW, most of those things are peculiar to C, and are not
> necessarily shared even with other languages that have
> explicit pointers. In Pascal, for example, there is no
> pointer arithmetic, 

That's true in theory, but I don't think that's right in practice. All the
Pascal compilers that I know of which are still in common use support
pointer arithmetic: Turbo Pascal, GNU Pascal, Free Pascal and Delphi. Some
compilers support an "inc" [increment] function to advance the pointer
safely. For those compilers that don't provide either, there's the
possibility of typecasting the pointer to a longint and back. Back in the
1990s, I used Lightspeed Pascal, and it supported typecasting pointers. For
those which don't even support that, you can usually abuse variant records
to get around the type system.

(Niklaus Wirth hated this, and made sure that this hack didn't work in his
later language Oberon.)

And finally, if all else fails, many Pascal compilers support embedding
assembly language, which obviously lets you do arithmetic on pointers.

The larger point is, the failure to allow pointer arithmetic in standard
Pascal is a design choice of the designer, not a fundamental restriction on
the pointer concept. Wirth didn't include pointer arithmetic in standard
Pascal because *he thought it was a bad idea*, not because Pascal pointers
are incapable of having arithmetic done to them. They're just an
abstraction over *numeric* memory addresses, just like in C, and there's
nothing more fundamental to numbers than arithmetic. You can't do
arithmetic on pointers in standard Pascal because the compiler stops you,
not because the operation makes no sense.

Bringing this back to Python, references in Python are *not* abstractions
over memory addresses. There is nothing in the Python model of computation
that requires values to even have such a thing as a memory address, let
alone pointers. The "references are pointers" explanation only gets you so
far, and not very far at that.


> and (at least not without nonstandard 
> extension) you can't make a pointer point into the middle
> of a stack frame or array or record, etc. (You *can* have
> a pointer to a pointer, but only by heap-allocating a
> memory block containing a single pointer, which is not
> useful very often).

Pascal programming on classic Macintosh used pointers-to-pointers
extensively, so much so that they had a name, "handle". Technically though
handles were managed by the Macintosh Toolbox routines, so slightly
different from what you are talking about. But in standard Pascal, you
certainly could create pointers to pointers.



-- 
Steven

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

Re: Rule of order for dot operators?

[Ned Batchelder]

On Tuesday, May 19, 2015 at 6:33:46 PM UTC-4, Thomas 'PointedEars' Lahn wrote:
> Denis McMahon wrote:
> 
> > On Sun, 17 May 2015 11:45:02 +1000, Steven D'Aprano wrote:
> >> On Sun, 17 May 2015 05:40 am, Thomas 'PointedEars' Lahn wrote:
> >>> C.D. Reimer wrote:
> >>> 
> >>> Who?
> >> Don't be a dick, Thomas.
> > 
> > Thomas is a professional dick, he can't help it, he's been a professional
> > dick for years in php and javascript groups, and now he's obviously
> > spreading himself further afield. He usually confines his wisdom to
> > pointing out faults in other's posts, rather than offering any
> > constructive input himself.
> 
> Yes, I am a professional, while you are just a dick.  Every single time.

Everyone should stop calling people names.

Thomas, you were obnoxious to the OP, and now you are being obnoxious (and 
factually incorrect) to Denis.

Steven and Denis: you were too blunt in your objections.

Be considerate. Be respectful.

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

Re: Best way to rewrite Popen

[Thomas 'PointedEars' Lahn]

Cecil Westerhof wrote:

> At the moment I am playing with things like:
> p = subprocess.Popen('ls -l', shell = True, stdout = subprocess.PIPE)
> 
> I think that most of the times this are the values I want. So it would
> be nice to overrule the defaults. What is the best way to do this?
> So creating a function that is exactly the same except for the defaults
> for shell and stdout (and maybe stderr).

As always in OOP: override the method and call that of the superclass 
in yours.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to rewrite Popen

[Thomas 'PointedEars' Lahn]

Cecil Westerhof wrote:

> At the moment I am playing with things like:
> p = subprocess.Popen('ls -l', shell = True, stdout = subprocess.PIPE)
> 
> I think that most of the times this are the values I want. So it would
> be nice to overrule the defaults. What is the best way to do this?
> So creating a function that is exactly the same except for the defaults
> for shell and stdout (and maybe stderr).

As always in OOP, override the constructor and call that of the superclass 
in yours.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: fork/exec & close file descriptors

[Gregory Ewing]

On Tue, May 19, 2015 at 8:54 AM, Chris Angelico > wrote:


On Linux (and possibly some other Unixes), /proc/self/fd may be of
use.


On MacOSX, /dev/fd seems to be the equivalent of this.

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

Re: Slices time complexity

[Steven D'Aprano]

On Wed, 20 May 2015 04:19 am, Marko Rauhamaa wrote:

> Steven D'Aprano :
> 
>> On Wed, 20 May 2015 01:59 am, Marko Rauhamaa wrote:
>>> You're slaying straw men.
>>
>> "I was wrong, but I don't want to admit it" is not spelled "straw man".
>>
>> You made a claim that was not defensible, and I tore that claim to
>> shreds. Have the good grace to admit that your earlier position:
>>
>> "it doesn't matter what semantic description you give Python
>> constructs as long as the observed behavior is correct"
> 
> I stand by that position and haven't changed it.
> 
>> doesn't stand up to scrutiny.
> 
> But it does.


Right. So you stand by the position that this explanation for how the Python
interpreter does integer arithmetic is equally good as any other:

There is a little magic elf hiding inside the computer, and when you type an
expression like '2 + 3', little tiny hammers bang it out in Morse Code on
the elf's head; in response, the elf calculates the answer on his teeny
tiny abacus and passes it back to the interpreter.

The elf also does calculations with decimal numbers like '1.1*2.3', but
they're harder which explains why sometimes the elf gets the calculations
slightly wrong.

Since this explanation explains the observed behaviour, according to you it
is equally valid as one involving, you know, actual facts.

Why am I talking to you?



-- 
Steven

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

Re: Slices time complexity

[Ben Finney]

Gregory Ewing  writes:

> If I draw two boxes on a blackboard with an arrow between them, I
> think it's perfectly reasonable to call that arrow a pointer.

Right. So the box with an arrow coming out of it is a good metaphor for
pointers — *in languages that have pointers*, which Python does not.

A box with an arrow coming out of it is a poor metaphor for Python's
references, since a Python reference doesn't contain anything accessible
to the programmer.

Instead, to avoid giving the false impression that Python's references
are boxes containing things, write a bare name (or other reference) on
the blackboard, referring to the box that *does* contain a value
accessible to the programmer.

-- 
 \   “The Vatican is not a state.… a state must have people. There |
  `\are no Vaticanians.… No-one gets born in the Vatican except by |
_o__)an unfortunate accident.” —Geoffrey Robertson, 2010-09-18 |
Ben Finney

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

Re: Best way to rewrite Popen

[Cecil Westerhof]

Op Wednesday 20 May 2015 01:20 CEST schreef MRAB:

> On 2015-05-19 23:23, Cecil Westerhof wrote:
>> Op Tuesday 19 May 2015 23:28 CEST schreef Jon Ribbens:
>>
>>> On 2015-05-19, Cecil Westerhof  wrote:
 It looks like that this does what I want (the dot is needed so
 that it also works with 2.7): files = sorted(os.listdir('.')) p =
 re.compile('actions-2015-05-[0-9][0-9].sql$') current_month = [
 file for file in files if p.match(file) ]
>>>
>>> You could instead do (in Python 2 or 3):
>>>
>>> files = glob.glob("actions-2015-05-[0-9][0-9].sql")
>>> files.sort()
>>
>> Something to remember.
>>
>> But in this case I also need the previous month. So I have:
>> files   = sorted(os.listdir('.'))
>> p   = re.compile('actions-2015-05-[0-9][0-9].sql$')
>> current_month   = [ file for file in files if p.match(file) ]
>> p   = re.compile('actions-2015-04-[0-9][0-9].sql$')
>> previous_month  = [ file for file in files if p.match(file) ]
>>
>> Of-course I will not hard-code the months in the real code.
>>
> In a regex, '.' will match any character except '\n', or any
> character at all if the DOTALL ('(?s)') flag in turned on. If you
> want to match an actual '.', you should escape it like this: r'\.'.
> (And if you're using backslashes in a string literal, make it a raw
> string literal!)
>
> p = re.compile(r'actions-2015-05-[0-9][0-9]\.sql$')

Oops, you are correct.

It is now:
start   = database + '-'
end = r'-[0-9][0-9]\.sql$'
p   = re.compile(start + current_month  + end)
current_month_lst   = [ file for file in files if p.match(file) ]
p   = re.compile(start + previous_month + end)
previous_month_lst  = [ file for file in files if p.match(file) ]

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

Re: Slices time complexity

[Gregory Ewing]

Steven D'Aprano wrote:

Chris, that is one of the best explanations for why "references equals
pointers" is *not* a good explanation for Python's behaviour.


Many people here seem to have lost sight of the
fact that the word "pointer" existed in the English
language long before C, and even long before computers.

If I draw two boxes on a blackboard with an arrow
between them, I think it's perfectly reasonable to
call that arrow a pointer.

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

Re: Best way to rewrite Popen

[MRAB]

On 2015-05-19 23:23, Cecil Westerhof wrote:

Op Tuesday 19 May 2015 23:28 CEST schreef Jon Ribbens:


On 2015-05-19, Cecil Westerhof  wrote:

It looks like that this does what I want (the dot is needed so that
it also works with 2.7): files = sorted(os.listdir('.')) p =
re.compile('actions-2015-05-[0-9][0-9].sql$') current_month = [
file for file in files if p.match(file) ]


You could instead do (in Python 2 or 3):

files = glob.glob("actions-2015-05-[0-9][0-9].sql")
files.sort()


Something to remember.

But in this case I also need the previous month. So I have:
 files   = sorted(os.listdir('.'))
 p   = re.compile('actions-2015-05-[0-9][0-9].sql$')
 current_month   = [ file for file in files if p.match(file) ]
 p   = re.compile('actions-2015-04-[0-9][0-9].sql$')
 previous_month  = [ file for file in files if p.match(file) ]

Of-course I will not hard-code the months in the real code.


In a regex, '.' will match any character except '\n', or any character
at all if the DOTALL ('(?s)') flag in turned on. If you want to match
an actual '.', you should escape it like this: r'\.'. (And if you're
using backslashes in a string literal, make it a raw string literal!)

p = re.compile(r'actions-2015-05-[0-9][0-9]\.sql$')

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

Re: Best way to rewrite Popen

[Cecil Westerhof]

Op Tuesday 19 May 2015 23:28 CEST schreef Jon Ribbens:

> On 2015-05-19, Cecil Westerhof  wrote:
>> It looks like that this does what I want (the dot is needed so that
>> it also works with 2.7): files = sorted(os.listdir('.')) p =
>> re.compile('actions-2015-05-[0-9][0-9].sql$') current_month = [
>> file for file in files if p.match(file) ]
>
> You could instead do (in Python 2 or 3):
>
> files = glob.glob("actions-2015-05-[0-9][0-9].sql")
> files.sort()

Something to remember.

But in this case I also need the previous month. So I have:
files   = sorted(os.listdir('.'))
p   = re.compile('actions-2015-05-[0-9][0-9].sql$')
current_month   = [ file for file in files if p.match(file) ]
p   = re.compile('actions-2015-04-[0-9][0-9].sql$')
previous_month  = [ file for file in files if p.match(file) ]

Of-course I will not hard-code the months in the real code.

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

Re: Rule of order for dot operators?

[Thomas 'PointedEars' Lahn]

Denis McMahon wrote:

> On Sun, 17 May 2015 11:45:02 +1000, Steven D'Aprano wrote:
>> On Sun, 17 May 2015 05:40 am, Thomas 'PointedEars' Lahn wrote:
>>> C.D. Reimer wrote:
>>> 
>>> Who?
>> Don't be a dick, Thomas.
> 
> Thomas is a professional dick, he can't help it, he's been a professional
> dick for years in php and javascript groups, and now he's obviously
> spreading himself further afield. He usually confines his wisdom to
> pointing out faults in other's posts, rather than offering any
> constructive input himself.

Yes, I am a professional, while you are just a dick.  Every single time.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
-- 
https://mail.python.org/mailman/listinfo/python-list

نتيجة الشهادة الابتدائية 2015

[محمود]

نتيجة الشهادة الابتدائية 2015


https://www.facebook.com/pages/%D9%86%D8%AA%D8%A7%D8%A6%D8%AC-%D8%A7%D9%84%D8%A7%D9%85%D8%AA%D8%AD%D8%A7%D9%86%D8%A7%D8%AA-%D9%88%D8%A7%D9%84%D8%AC%D8%A7%D9%85%D8%B9%D8%A7%D8%AA-%D9%88%D8%A7%D8%AC%D8%AA%D9%85%D8%A7%D8%B9%D9%8A%D8%A7%D8%AA/299719160065550?fref=ts
-- 
https://mail.python.org/mailman/listinfo/python-list

نتيجة الشهادة الابتدائية 2015 معرفة النتيجة برقم الجلوس اليوم السابع

[شيسبس]

نتيجة الشهادة الابتدائية 2015 معرفة النتيجة برقم الجلوس اليوم السابع


https://www.facebook.com/pages/%D9%86%D8%AA%D8%A7%D8%A6%D8%AC-%D8%A7%D9%84%D8%A7%D9%85%D8%AA%D8%AD%D8%A7%D9%86%D8%A7%D8%AA-%D9%88%D8%A7%D9%84%D8%AC%D8%A7%D9%85%D8%B9%D8%A7%D8%AA-%D9%88%D8%A7%D8%AC%D8%AA%D9%85%D8%A7%D8%B9%D9%8A%D8%A7%D8%AA/299719160065550?fref=ts
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to rewrite Popen

[Jon Ribbens]

On 2015-05-19, Cecil Westerhof  wrote:
> It looks like that this does what I want (the dot is needed so that it
> also works with 2.7):
> files = sorted(os.listdir('.'))
> p = re.compile('actions-2015-05-[0-9][0-9].sql$')
> current_month = [ file for file in files if p.match(file) ]

You could instead do (in Python 2 or 3):

  files = glob.glob("actions-2015-05-[0-9][0-9].sql")
  files.sort()
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Help with Regular Expression

[Tim Chase]

On 2015-05-19 06:42, massi_...@msn.com wrote:
> I succesfully wrote a regex in python in order to substitute all
> the occurences in the form $"somechars" with another string. Here
> it is:
> 
> re.sub(ur"""(?u)(\$\"[^\"\\]*(?:\\.[^\"\\]*)*\")""", newstring,
> string)

The expression is a little more precise than you describe it, but the
general idea is correct.

For the record, the "(?u)" happens to be unneeded here, and I find it
more clear if you pass the re.UNICODE flag to the function.

> Now I would need to exclude from the match all the string in the
> form $", ", can anyone help me to modufy it? Thanks in advance!

If you don't want commas or spaces, you should be able to just insert
them into your various negated character-classes:

  r"""(?u)(\$\"[^\"\\, ]*(?:\\.[^\"\\, ]*)*\")"""

Unless you want to allow commas and/or spaces, but disallow commas
followed by spaces.  That's a lot uglier.  If that's the case, it
would help to have a test-harness of your expected inputs and results:

  re_to_test = r"""(?u)(\$\"[^\"\\, ]*(?:\\.[^\"\\, ]*)*\")"""
  for test, expected in [
 ('Hello $"who"!', 'Hello world!'),
 ('Hello $"who.who"!', 'Hello world!'),
 ('Hello $"who.is.it"!', 'Hello world!'),
 ('Hello $"who, what"!', 'Hello world!'),
 ('Hello $"who,what,where"!', 'Hello world!'),
 ('Hello $"who, what, where"!', 'Hello $"who, what, where"!'),
 ('Hello $"who is it"!', 'Hello world!'),
 ]:
result = re.sub(re_to_test, "world", test, re.UNICODE)
if result == expected:
  report_passing(...)
else:
  report_failure(...)

-tkc







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

Re: Best way to rewrite Popen

[Cecil Westerhof]

Op Tuesday 19 May 2015 21:13 CEST schreef Cecil Westerhof:

> Op Tuesday 19 May 2015 19:36 CEST schreef Jon Ribbens:
>
>> On 2015-05-19, Cecil Westerhof  wrote:
>>> At the moment I am playing with things like: p =
>>> subprocess.Popen('ls -l', shell = True, stdout = subprocess.PIPE)
>>>
>>> I think that most of the times this are the values I want. So it
>>> would be nice to overrule the defaults. What is the best way to do
>>> this? So creating a function that is exactly the same except for
>>> the defaults for shell and stdout (and maybe stderr).
>>
>> Yes.
>>
>> def shellprocess(cmd, **kwargs):
>> return subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE,
>> **kwargs)
>
> Will that not go wrong if I call it with?
> shellprocess('ls -1', shell = False)
>
>
>>> It is a little less important as I first thought, because I found
>>> the following: error, output = subprocess.getstatusoutput('ls -1')
>>> files_new = output.splitlines() But it is still nice to know.
>>
>> Why are you doing this anyway, rather than using os.listdir()?
>> Invoking subprocesses via the shell is very rarely a good idea.
>
> I want to rewrite a Bash script into a Python script. The 'ls -1' is
> only an example. But Popen and listdir give a different output. The
> sorting is different. But I could sort it myself.
>
> Another problem is that I work with a filter later on. But I could
> do that with Python also of-course. So maybe I should rethink what I
> want to do. ;-)

It looks like that this does what I want (the dot is needed so that it
also works with 2.7):
files = sorted(os.listdir('.'))
p = re.compile('actions-2015-05-[0-9][0-9].sql$')
current_month = [ file for file in files if p.match(file) ]

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

Re: Best way to rewrite Popen

[Jon Ribbens]

On 2015-05-19, Cecil Westerhof  wrote:
> Op Tuesday 19 May 2015 19:36 CEST schreef Jon Ribbens:
>
>> On 2015-05-19, Cecil Westerhof  wrote:
>>> At the moment I am playing with things like: p =
>>> subprocess.Popen('ls -l', shell = True, stdout = subprocess.PIPE)
>>>
>>> I think that most of the times this are the values I want. So it
>>> would be nice to overrule the defaults. What is the best way to do
>>> this? So creating a function that is exactly the same except for
>>> the defaults for shell and stdout (and maybe stderr).
>>
>> Yes.
>>
>> def shellprocess(cmd, **kwargs):
>> return subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE,
>> **kwargs)
>
> Will that not go wrong if I call it with?
> shellprocess('ls -1', shell = False)

Yes. I thought you wanted a function that was specific to your
purpose, rather than one that was identical to Popen but with
different defaults. For that I suppose you could do:

  def shellprocess(args, **kwargs):
  kwargs.setdefault("shell", True)
  kwargs.setdefault("stdout", subprocess.PIPE)
  return subprocess.Popen(args, **kwargs)

> I want to rewrite a Bash script into a Python script. The 'ls -1' is
> only an example. But Popen and listdir give a different output. The
> sorting is different. But I could sort it myself.
>
> Another problem is that I work with a filter later on. But I could do
> that with Python also of-course. So maybe I should rethink what I want
> to do. ;-)

Indeed, porting a script from bash to Python is probably best done by
writing the identical functionality in the style of Python, rather
than doing a line-by-line literal conversion.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Slices time complexity

[Serhiy Storchaka]

On 19.05.15 18:15, Ian Kelly wrote:

On May 19, 2015 4:16 AM, "Serhiy Storchaka" mailto:storch...@gmail.com>> wrote:
 >
 > On 19.05.15 12:45, Steven D'Aprano wrote:
 >>
 >> On Tuesday 19 May 2015 05:23, Mario Figueiredo wrote:
 >>>
 >>>  From the above link it seems slices work in linear time on all cases.
 >>
 >>
 >> I wouldn't trust that is always the case, e.g. deleting a contiguous
slice
 >> from the end of a list could be O(1).
 >
 >
 > It always has linear complexity. You need to decref removed elements.

Only in CPython. The operation might be O(1) in Pypy or Jython.


In any case you need linear time to free all objects.

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

Re: Best way to rewrite Popen

[Cecil Westerhof]

Op Tuesday 19 May 2015 19:36 CEST schreef Jon Ribbens:

> On 2015-05-19, Cecil Westerhof  wrote:
>> At the moment I am playing with things like: p =
>> subprocess.Popen('ls -l', shell = True, stdout = subprocess.PIPE)
>>
>> I think that most of the times this are the values I want. So it
>> would be nice to overrule the defaults. What is the best way to do
>> this? So creating a function that is exactly the same except for
>> the defaults for shell and stdout (and maybe stderr).
>
> Yes.
>
> def shellprocess(cmd, **kwargs):
> return subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE,
> **kwargs)

Will that not go wrong if I call it with?
shellprocess('ls -1', shell = False)


>> It is a little less important as I first thought, because I found
>> the following: error, output = subprocess.getstatusoutput('ls -1')
>> files_new = output.splitlines() But it is still nice to know.
>
> Why are you doing this anyway, rather than using os.listdir()?
> Invoking subprocesses via the shell is very rarely a good idea.

I want to rewrite a Bash script into a Python script. The 'ls -1' is
only an example. But Popen and listdir give a different output. The
sorting is different. But I could sort it myself.

Another problem is that I work with a filter later on. But I could do
that with Python also of-course. So maybe I should rethink what I want
to do. ;-)

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

Re: subprocess.getstatusoutput does not exist in 2.7

[Cecil Westerhof]

Op Tuesday 19 May 2015 19:37 CEST schreef Jon Ribbens:

> On 2015-05-19, Cecil Westerhof  wrote:
>> At the moment I want my code to run with 2.7 and 3.4+.
>>
>> But the command: subprocess.getstatusoutput does not exist in 2.7.
>> Is this an oversight or is there a reason for it?
>>
>> I can rewrite the code (back) to work with Popen again, but I found
>> the getstatusoutput elegant.
>
> It's in the 'commands' module in Python 2. You could use the
> following:
>
> try:
> from subprocess import getstatusoutput
> except ImportError:
> from commands import getstatusoutput

Works like a charm. Thanks.

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

Re: Convert c file to csv file(unix format) in python

[Grant Edwards]

On 2015-05-19, umasrinat...@gmail.com  wrote:

> I have a python script file which converts .hex file  to c file.
>
> Can anyone help me in converting .c file to csv file (unix format).


#import os,sys
os.rename(sys.argv[1],sys.argv[1].replace('.c','.csv'))


-- 
Grant Edwards   grant.b.edwardsYow! I want a WESSON OIL
  at   lease!!
  gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Convert c file to csv file(unix format) in python

[umasrinath88]

On Tuesday, May 19, 2015 at 11:51:20 PM UTC+5:30, Denis McMahon wrote:
> On Tue, 19 May 2015 09:30:15 -0700, umasrinath88 wrote:
> 
> > I have a python script file which converts .hex file  to c file.
> 
> Hex is generally an ascii file containing hexadecimal values.
> 
> .c is generally an ascii file formatted in a way that corrsponds to the 
> structures of the c programming language.
> 
> > Can anyone help me in converting .c file to csv file (unix format).
> 
> csv is generally a way of exchanging data between different software 
> applications in a generally human readable format.
> 
> I'm unsure as to the translations you expect to be made to convert a .c 
> file into a csv file. Perhaps you could elaborate on these.
> 
> -- 
> Denis McMahon, denismfmcma...@gmail.com

Hi Denis,

I agree to you point.

I have shared c file with you.Iorder to convert to unix format csv, below are 
the main steps we can follow.

1 Remove the 23 first lines
2.Remove all empty lines
3.Remove spaces at the beginning of each line
4.Replace ,\r\r\n with \n [commaCRCRLF replace with LF]
5.Rename and save this file as csv.

Can you help me in writing a python code for this. Which takes stm32Image.c 
file as input and generates stm32Image.csv

Regards,
Uma
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Convert c file to csv file(unix format) in python

[Denis McMahon]

On Tue, 19 May 2015 09:30:15 -0700, umasrinath88 wrote:

> I have a python script file which converts .hex file  to c file.

Hex is generally an ascii file containing hexadecimal values.

.c is generally an ascii file formatted in a way that corrsponds to the 
structures of the c programming language.

> Can anyone help me in converting .c file to csv file (unix format).

csv is generally a way of exchanging data between different software 
applications in a generally human readable format.

I'm unsure as to the translations you expect to be made to convert a .c 
file into a csv file. Perhaps you could elaborate on these.

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

Re: Slices time complexity

[Marko Rauhamaa]

Steven D'Aprano :

> On Wed, 20 May 2015 01:59 am, Marko Rauhamaa wrote:
>> You're slaying straw men.
>
> "I was wrong, but I don't want to admit it" is not spelled "straw man".
>
> You made a claim that was not defensible, and I tore that claim to shreds.
> Have the good grace to admit that your earlier position:
>
> "it doesn't matter what semantic description you give Python 
> constructs as long as the observed behavior is correct"

I stand by that position and haven't changed it.

> doesn't stand up to scrutiny.

But it does.

>> Jython, CPython and IronPython are supposed to be semantically
>> equivalent. So any valid CPython model is also a valid model for
>> Jython and IronPython.
>
> They are only supposed to equivalent in regards to behaviour specified by
> the language specifications,

Naturally.

> One such implementation-dependent behaviour is whether Python objects
> have a fixed location or not.

Whatever that means.

> CPython objects currently do.

As far as the process's virtual memory goes...

> Jython and IronPython objects do not, they can move in memory, so
> references in those two implementations cannot be implemented as
> pointers or memory addresses.

Semantics can be given in terms of memory addresses even if the
implementation does not have memory addresses (in the sense you're
describing).

>>> Mixing descriptions of a specific implementation with descriptions
>>> of the high level semantics is sometimes useful but often
>>> misleading, and one needs to be careful how and when one does it.
>> 
>> Nobody has proposed doing that.
>
> You did. Pointers are the CPython implementation, they are not the
> high level semantics.

The semantics can be expressed in any manner whatsoever regardless of
how Python has been "really" implemented. Formally, informally. In
English. In Russian. Using Turing machines, using x86 machine language,
using Forth. There's an infinitum of isomorphic descriptions, some
instructive, some confusing.

The touchstone is the observed behavior.


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

Re: Best way to rewrite Popen

[Chris Angelico]

On Wed, May 20, 2015 at 3:55 AM, Zachary Ware
 wrote:
>> def capture_stdout(*a, **kw):
>> if 'stdout' not in kw: kw['stdout'] = subprocess.PIPE
>
> Just a quick note that this line can be simplified nicely to:
>
> kw.setdefault('stdout', subprocess.PIPE)

Yes, in the simple case. That does require pre-evaluating
subprocess.PIPE though, which in some situations is an important
distinction. But you're right, for something this simple, the
repetition is superfluous. Good catch.

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

Re: Slices time complexity

[Chris Angelico]

On Wed, May 20, 2015 at 3:46 AM, Steven D'Aprano
 wrote:
> On Wed, 20 May 2015 01:59 am, Marko Rauhamaa wrote:
>
>> Steven D'Aprano :
>>
>>> To be useful, explanations ought to give the user *predictive power*
>>> -- if I calculate 32767 + 1, what will Python do?
>>>
>>> Explanation #1 predicts that Python will return 32768.
>>> Explanation #2 makes no prediction at all.
>>
>> Any semantic ruleset that correctly predicts the behavior of any given
>> Python program is equally valid.
>
> This is a more reasonable position to take than your earlier stance that the
> only thing that matters is whether it explains observed behaviour. It's
> still wrong, but at least it is defensible in the sense that sometimes a
> ruleset which is objectively wrong but still gives the right answer might
> be *preferred* over one which is objectively correct but hard to
> understand.

Perfect parallel with Magic: The Gathering, where a card may have
reminder text on it which is, in the strictest sense of the
definition, inaccurate, but covers 99%+ of situations without being
horrendously wordy. The fundamental rulebook (the "Comp Rules") goes
into excruciating detail, and is about as readable as the CPython
source code (that is: pretty readable, but too verbose to use as
documentation).

For example, the "First Strike" ability is described simply as "This
creature deals combat damage before creatures without first strike"
[1], but the Comp Rules explain how there are two combat damage steps,
and detail what happens if a creature gains or loses First Strike
during combat.

Even worse, "Madness" is described as "If you discard this card, you
may cast it for its madness cost instead of putting it into your
graveyard" [2]; the Comp Rules divide this into two parts, explaining
in full how the card actually gets from one place to another, where
it's cast from, and so on.

Both of these reminder texts are technically inaccurate, but are
massively preferred over the full text, because they actually fit
inside your brain. Same thing happens with networking; when you go to
https://www.python.org/ in a web browser, your browser establishes an
encrypted connection with the server at www.python.org, and requests
the "/" page. Well, actually, first there are DNS lookups, and IP
routing, and TCP handshakes, and then the whole "establishes an
encrypted connection" bit elides a ton of work involving certificate
checks and so on... but it's much easier to just talk in very high
level terms, even if it's not perfectly accurate. As predictive power
goes, this explanation will adequately tell you what to expect a
request for https://github.com/Rosuav to do; that makes it useful.

An explanation that's more accurate is better than one that's less
accurate; an explanation that's more complicated is worse than one
that's simpler. Somewhere in the middle is an optimal descriptive
style for a given situation.

ChrisA

[1] http://gatherer.wizards.com/Pages/Card/Details.aspx?multiverseid=134753
[2] http://gatherer.wizards.com/Pages/Card/Details.aspx?multiverseid=382849
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rule of order for dot operators?

[Ron Adam]

On 05/19/2015 02:25 AM, Chris Angelico wrote:

On Tue, May 19, 2015 at 12:43 PM, Ron Adam  wrote:

>Having just implementing something similar for nested scopes, it turns out
>it can't be operators because if it was, then the names y and z would be
>resolved in the wrong scope.
>
>  y = "m"
>  z = "n"
>  a = x . y . z
>
>Which of course wouldn't do what we want.
>
>  a = x . "m" . "n"
>
>And most likely this would give an error.



If you want to implement the dot as an operator, you could do it by
having a special syntactic element called an "atom", which is used for
these kinds of identifier-like tokens. The dot operator could then
take an object and an atom, and effectively return getattr(obj,
stringify(atom)). I'm fairly sure this would result in the same syntax
as Python uses.


I think it's better not to.   What practical things can be done if the dot 
was an operator and names after dots where parsed as atoms?


What I did was parse a name to a subtype of tuple with elements of strings. 
 [return name.with.dots] becomes this in memory after parsing.


[keyword_object name_object]

Using dots as operators would make that...

[keyword_object name_object dot_object atom_object dot_object
 atom_object]

This would require the interpreter to do in steps what a single function 
call can do all at once.


Cheers,
   Ron






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

Re: Best way to rewrite Popen

[Zachary Ware]

On May 19, 2015 12:48 PM, "Chris Angelico"  wrote:
>
> On Wed, May 20, 2015 at 3:01 AM, Cecil Westerhof  wrote:
> > At the moment I am playing with things like:
> > p = subprocess.Popen('ls -l', shell = True, stdout =
subprocess.PIPE)
> >
> > I think that most of the times this are the values I want. So it would
> > be nice to overrule the defaults. What is the best way to do this? So
> > creating a function that is exactly the same except for the defaults
> > for shell and stdout (and maybe stderr).
>
> Well... I would have to start by saying that you probably _don't_ want
> to use shell=True by default. Putting it explicitly on the cases where
> you need it helps you remember its danger. You also don't need it for
> simple cases like that one; improve your reliability by providing a
> list instead of a string, and then you can leave shell=False:
>
> p = subprocess.Popen(['ls','-l'], stdout=subprocess.PIPE)
>
> Running everything via the shell is unnecessary, and a dangerous
> default. (Maybe it's not a problem when you use a string literal as
> the command, but if you make that the default, you'll end up exposing
> yourself in some situation where it isn't hard-coded.) With that
> change, there's really only one parameter that you're defaulting, so
> there's not as much point making the change, but the technique still
> works, and maybe you'll add more to the setup:
>
> @functools.wraps(subprocess.Popen)
> def Popen(*a, **kw):
> if 'stdout' not in kw: kw['stdout'] = subprocess.PIPE
> return subprocess.Popen(*a, **kw)
>
> That's a simple way to patch in some function defaults. But
> personally, I'd probably end up doing something like this:
>
> def capture_stdout(*a, **kw):
> if 'stdout' not in kw: kw['stdout'] = subprocess.PIPE

Just a quick note that this line can be simplified nicely to:

kw.setdefault('stdout', subprocess.PIPE)

Regards,
--
Zach
(on a phone)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Slices time complexity

[Steven D'Aprano]

On Wed, 20 May 2015 01:59 am, Marko Rauhamaa wrote:

> Steven D'Aprano :
> 
>> To be useful, explanations ought to give the user *predictive power*
>> -- if I calculate 32767 + 1, what will Python do?
>>
>> Explanation #1 predicts that Python will return 32768.
>> Explanation #2 makes no prediction at all.
> 
> Any semantic ruleset that correctly predicts the behavior of any given
> Python program is equally valid.

This is a more reasonable position to take than your earlier stance that the
only thing that matters is whether it explains observed behaviour. It's
still wrong, but at least it is defensible in the sense that sometimes a
ruleset which is objectively wrong but still gives the right answer might
be *preferred* over one which is objectively correct but hard to
understand.

But some rulesets may have perfect predictive power, and still be rejected:

http://star.psy.ohio-state.edu/coglab/Pictures/miracle.gif

Unlike scientific theories about the universe, where we have to hypothesise
what the rules are, we can actually look at the source code for the Python
interpreter and see exactly what the rules are. We don't have to guess how
list.sort() works, we have the documentation, we have the source code, we
can ask the author, and if all else fails, we can run the interpreter in a
debugger and watch what it does.

A ruleset which corresponds to the facts of how list.sort() works is more
valid than a counter-factual ruleset which does not. "Python uses timsort"
is usually to be preferred over "Python uses bubblesort" because at least
two interpreters (CPython and Jython) use timsort, while no interpreter
uses bubblesort. (Here, "Python" is to be understood as referring to a
specific interpreter, not the language itself.)



>> Only one of these models for Python allows you to make correct
>> predictions, even though all three explain the observations given.
> 
> You're slaying straw men.

"I was wrong, but I don't want to admit it" is not spelled "straw man".

You made a claim that was not defensible, and I tore that claim to shreds.
Have the good grace to admit that your earlier position:

"it doesn't matter what semantic description you give Python 
constructs as long as the observed behavior is correct"

doesn't stand up to scrutiny. If you can't do that, at least let it pass in
silence without trying to pretend that you never made that argument and
falsely accusing me of misrepresenting you.



>>> For example, you could explain Python's object references as pointers
>>> (memory addresses) if you considered that helpful. (That's how Lisp
>>> textbooks often explain cons cells.)
>>
>> Well, you could do that, but it would fail to explain the behaviour of
>> Jython and IronPython.
> 
> Jython, CPython and IronPython are supposed to be semantically
> equivalent. So any valid CPython model is also a valid model for Jython
> and IronPython.

They are only supposed to equivalent in regards to behaviour specified by
the language specifications, and that gives plenty of opportunity for
implementation-dependent behaviour. And of course performance and memory
use is a measure of quality of implementation.

One such implementation-dependent behaviour is whether Python objects have a
fixed location or not. CPython objects currently do. Jython and IronPython
objects do not, they can move in memory, so references in those two
implementations cannot be implemented as pointers or memory addresses.

PyPy objects don't even have a fixed existence, there are circumstances
where objects in PyPy can disappear, only to be recreated (possibly in a
new location).


>> Mixing descriptions of a specific implementation with descriptions of
>> the high level semantics is sometimes useful but often misleading, and
>> one needs to be careful how and when one does it.
> 
> Nobody has proposed doing that.

You did. Pointers are the CPython implementation, they are not the high
level semantics.




-- 
Steven

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

Re: Best way to rewrite Popen

[Chris Angelico]

On Wed, May 20, 2015 at 3:01 AM, Cecil Westerhof  wrote:
> At the moment I am playing with things like:
> p = subprocess.Popen('ls -l', shell = True, stdout = subprocess.PIPE)
>
> I think that most of the times this are the values I want. So it would
> be nice to overrule the defaults. What is the best way to do this? So
> creating a function that is exactly the same except for the defaults
> for shell and stdout (and maybe stderr).

Well... I would have to start by saying that you probably _don't_ want
to use shell=True by default. Putting it explicitly on the cases where
you need it helps you remember its danger. You also don't need it for
simple cases like that one; improve your reliability by providing a
list instead of a string, and then you can leave shell=False:

p = subprocess.Popen(['ls','-l'], stdout=subprocess.PIPE)

Running everything via the shell is unnecessary, and a dangerous
default. (Maybe it's not a problem when you use a string literal as
the command, but if you make that the default, you'll end up exposing
yourself in some situation where it isn't hard-coded.) With that
change, there's really only one parameter that you're defaulting, so
there's not as much point making the change, but the technique still
works, and maybe you'll add more to the setup:

@functools.wraps(subprocess.Popen)
def Popen(*a, **kw):
if 'stdout' not in kw: kw['stdout'] = subprocess.PIPE
return subprocess.Popen(*a, **kw)

That's a simple way to patch in some function defaults. But
personally, I'd probably end up doing something like this:

def capture_stdout(*a, **kw):
if 'stdout' not in kw: kw['stdout'] = subprocess.PIPE
return subprocess.Popen(*a, **kw).stdout

so I can directly iterate over the thing. Or something else. One
change isn't really enough to justify the extra layer of indirection.

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

Re: Best way to rewrite Popen

[Jonas Wielicki]

On 19.05.2015 19:01, Cecil Westerhof wrote:
> At the moment I am playing with things like:
> p = subprocess.Popen('ls -l', shell = True, stdout = subprocess.PIPE)
> 
> I think that most of the times this are the values I want. So it would
> be nice to overrule the defaults. What is the best way to do this? 

I would like to answer with a counter-question: Why do you want to do
this? What is the reason to use ls -l if you could also be using
os.listdir() or os.scandir()?

There are some reasons against screenscraping `ls` (locale-specifities
and environment variable dependencies of ls) and using shell=True (with
shells being huge complex beasts which may have unexpected security
issues, see Shellshock), so I’m not sure why you would want to do that.

regards,
jwi



signature.asc
Description: OpenPGP digital signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: subprocess.getstatusoutput does not exist in 2.7

[Jon Ribbens]

On 2015-05-19, Cecil Westerhof  wrote:
> At the moment I want my code to run with 2.7 and 3.4+.
>
> But the command:
> subprocess.getstatusoutput
> does not exist in 2.7. Is this an oversight or is there a reason for
> it?
>
> I can rewrite the code (back) to work with Popen again, but I found
> the getstatusoutput elegant.

It's in the 'commands' module in Python 2. You could use the
following:

  try:
  from subprocess import getstatusoutput
  except ImportError:
  from commands import getstatusoutput
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to rewrite Popen

[Jon Ribbens]

On 2015-05-19, Cecil Westerhof  wrote:
> At the moment I am playing with things like:
> p = subprocess.Popen('ls -l', shell = True, stdout = subprocess.PIPE)
>
> I think that most of the times this are the values I want. So it would
> be nice to overrule the defaults. What is the best way to do this? So
> creating a function that is exactly the same except for the defaults
> for shell and stdout (and maybe stderr).

Yes.

  def shellprocess(cmd, **kwargs):
  return subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE,
  **kwargs)

> It is a little less important as I first thought, because I found the
> following:
> error, output = subprocess.getstatusoutput('ls -1')
> files_new = output.splitlines()
> But it is still nice to know.

Why are you doing this anyway, rather than using os.listdir()?
Invoking subprocesses via the shell is very rarely a good idea.
-- 
https://mail.python.org/mailman/listinfo/python-list

subprocess.getstatusoutput does not exist in 2.7

[Cecil Westerhof]

At the moment I want my code to run with 2.7 and 3.4+.

But the command:
subprocess.getstatusoutput
does not exist in 2.7. Is this an oversight or is there a reason for
it?

I can rewrite the code (back) to work with Popen again, but I found
the getstatusoutput elegant.

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

Best way to rewrite Popen

[Cecil Westerhof]

At the moment I am playing with things like:
p = subprocess.Popen('ls -l', shell = True, stdout = subprocess.PIPE)

I think that most of the times this are the values I want. So it would
be nice to overrule the defaults. What is the best way to do this? So
creating a function that is exactly the same except for the defaults
for shell and stdout (and maybe stderr).


It is a little less important as I first thought, because I found the
following:
error, output = subprocess.getstatusoutput('ls -1')
files_new = output.splitlines()
But it is still nice to know.

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

Re: Slices time complexity

[Chris Angelico]

On Wed, May 20, 2015 at 3:07 AM, Steven D'Aprano
 wrote:
> True confession time: I've been using Python for over 15 years. For at least
> 12 of those years, I've found myself feeling guilty every time I write a
> loop like "for x in seq[1:]" to skip the first element, because I'm worried
> about copying a huge list. Every single time I think "I really ought to
> write a list view." And then I think about the effort involved (minor)
> versus the benefit (even smaller) and I think "screw it, I'll just make a
> copy".
>
> And in 12 years, this lazy "put off until tomorrow" attitude to list views
> has failed me exactly *zero* times. I won't say You're Not Gonna Need It,
> but I will say *I've* Never Needed It Yet.

I can't think of many times when I've needed to do this on a large
list - usually it's either a generic iterable handler (so it has to
call iter() and then next(), and then iterate over what's left), or
it's sys.argv. I literally cannot think of any other situation where
I've iterated over seq[1:] than sys.argv. And if you're passing a
million args to a program, frankly, you have more to worry about than
the cost of trimming off the self-name to iterate over the rest of the
args. Worries like, yaknow, actually doing some work with whatever was
passed in as args, which is likely to dwarf the list slicing time.

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

Re: Convert c file to csv file(unix format) in python

[umasrinath88]

On Tuesday, May 19, 2015 at 10:15:43 PM UTC+5:30, Mihamina Rakotomandimby wrote:
> On 05/19/2015 07:30 PM, umasrinat...@gmail.com wrote:
> > Can anyone help me in converting .c file to csv file (unix format).
> >
> >
> Would you give a sample?

Hi Mihamina,

I have sent you the complete work folder.

thyncHextoC.py is python script used to convert .hex to .c structure file

Open command prompt window and type below command.


>python thyncHextoC.py 

example:  python thyncHextoC.py 18052015_1640_STM_5_08_DVT.hex

stm32Image.c file is created.

this .c file has to be converted to csv file.

I was following manual steps as below:(But want to automate now)

3)Open stm32Image.c file in notepad++
Delete  first 23 lines of data in the file(including this line "const 
flashImage_tflashImageData[] ={")

The .C file must contain only hex bytes now.

4)Select all the hex bytes and go to edit option->Blank operation-> Remove 
leading and trailing spaces

next go again edit option->Line operations-> Remove empty lines containing 
blank characters

Remove the comma(,) from last hex byte till end of the file.
This can be achieved using Alt+Shift+end and scroll down until the last hex 
byte.

Note:Donot modify last line 0,0,0 }; of the file. Let it  remain as it is.

5)Once all the above steps are done, Save the file and in command prompt 
execute below command for converting .c to .csv file

>ren stm32Image.c 

example:ren stm32Image.c 28022015_1140_EVT.csv
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why does the first loop go wrong with Python3

[Chris Angelico]

On Wed, May 20, 2015 at 2:39 AM, Cecil Westerhof  wrote:
> By the way, what also works is:
> p = None
>
> But it was just a try in ipython3. I would never do this in real code.
> I was just curious if this would be handled correctly and it is. :-)

That _may_ work, but it depends on their not being any other
references to it, and also depends on it being garbage-collected
promptly. Neither is guaranteed. Explicitly wait()ing on it is a
guarantee.

Simply dropping the object is a good way to "probably dispose" of
something that you don't care about. For instance, you asynchronously
invoke VLC to play some audio alert, and the subprocess might finish
before you're done with the current function, or might finish after.
You don't really care about its actual termination, and certainly
don't want to delay anything waiting for it, but you do want to clean
up resources at some point. Dropping the object (keeping no references
to it, returning from the function you called it from, unsetting any
references you have, whatever makes sense) will normally mean that it
gets garbage collected and cleaned up _at some point_, without really
guaranteeing exactly when; for instance, if you have an alert like
this once per hour and watch 'top' for the number of zombies, you'll
probably see some now and then, but they'll never get to apocalyptic
numbers.

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

Re: Slices time complexity

[Steven D'Aprano]

On Wed, 20 May 2015 12:52 am, Bartc wrote:

> "Steven D'Aprano"  wrote in message
> news:555b0621$0$2753$c3e8da3$76491...@news.astraweb.com...
[...]
>> I'm sure that lots of things surprise people who assume that every
>> language's performance characteristics are identical.
>>
>> Python is not Lisp. Lisp is not Java. Java is not Forth. Forth is not
>> Lua. Lua is not Fortran. Fortran is not PHP. Do you see a pattern yet?
>> :-)
> 
> But sometimes you want an algorithm that works perfectly well in one
> language to work just as well in another.

Yeah, and I want a million dollars, a pony, and the ability to eat as much
as I like without getting fat too. Life is cruel, and then you die.


[...]
> I'm surprised about the slice thing too; I was getting used to the idea of
> Python only passing around references, even to small integer values, and
> now here it goes and does a copy!

Yes. And? Are you surprised that dict.copy() makes a copy? Presumably not.
Well, the way we spell list.copy() is list[:]


> But apparently only a shallow (top-level) copy. Still, it sounds expensive
> if you just want to pass part of a list to a function, not the whole
> thing, a function which is not going to write into the list (like the OP's
> example).

Yes, a slice can be expensive, if you have (say) a ten billion element list,
and take a slice list[1:]. And, to be perfectly honest, there's no real
good solution for that in standard Python. Numpy arrays implement slicing
and cloning of arrays as views, but the Python standard library doesn't
have anything that does the same.

But, really... if you're serious about dealing with huge arrays of data, you
want something like numpy, not Python lists. So *in practice* the lack of
views for lists is a minor nuisance, if that. Having list slices return
copies rather than views avoids more problems than it causes.

On the other hand, if Python implementations would implement slices with
copy-on-write, that would give us the best of both worlds!


>>> Is there any reason why Python 3.4 implementation of slices cannot be
>>> a near constant operation?
>>
>> Yes. (1) Backwards compatibility. (2) That would go against the design of
>> Python slices that they are copies. (3) That would upset those who want
>> and
>> expect a slice to be a copy.
> 
> Or you could just have a different kind of slice that is just a 'view'.

Sure. And you can program it yourself, if you like.

True confession time: I've been using Python for over 15 years. For at least
12 of those years, I've found myself feeling guilty every time I write a
loop like "for x in seq[1:]" to skip the first element, because I'm worried
about copying a huge list. Every single time I think "I really ought to
write a list view." And then I think about the effort involved (minor)
versus the benefit (even smaller) and I think "screw it, I'll just make a
copy".

And in 12 years, this lazy "put off until tomorrow" attitude to list views
has failed me exactly *zero* times. I won't say You're Not Gonna Need It,
but I will say *I've* Never Needed It Yet.

I think that's why Python doesn't have a generalised sequence slice view.
It's not that the core developers are against the idea. It's just that,
weighing up the disadvantages, the advantages, and the effort involved, a
slice view has never been high enough on their priority list to get
included. The people who really need it already have numpy.

What will be off the table is changing the behaviour of list slicing. But
adding a sequence view? That's plausible. It just needs somebody to do the
work first.


>> I'll tell you what -- Python slices have worked this way for over 20
>> years.
>> You should propose to the Go designers that Go is confusing because it
>> doesn't match Python's behaviour, and they should change the meaning of
>> slices in Go to match Python. There's not as much Go code in the world as
>> Python code, so that will be far less disruptive. Tell them that Go
>> should be just like Python, otherwise it will confuse users who expect Go
>> slices to
>> behave like Python slices.
> 
> I agree with the OP, the way slices work in Python is confusing to those
> who expect them to work like array assignments. So if B is a
> million-element list, then A=B does not copy a million elements, neither
> shallow or deep.

Why would you expect slicing to be the same as assignment? Do you expect
list.append to be the same as assignment?

mylist = list(range(40))
mylist[3:26:3] = [1, 2, 3, 4, 5, 6, 7, 8]

How do you expect that to work, if not by copying?


> But A=B[1:] copies 99 shallow elements. (Pointers I expect, and might
> need to change the reference counts of those 99 elements. And when
> that slice is discarded after perhaps a handful of accesses, it might need
> to change them all back.

You say that as if it were expensive.



-- 
Steven

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

Re: Slightly OT: Seeking (python-based) project diary tool, or framework to write one

[jkn]

Hi Rustom

On Tuesday, May 19, 2015 at 5:50:11 PM UTC+1, Rustom Mody wrote:
> On Tuesday, May 19, 2015 at 9:59:16 PM UTC+5:30, jkn wrote:
> > Hi All
> > as in the title, this is a little bit OT - but since ideally I'd like a
> > tool written in Python, and I know readers here have wide experience of
> > development/collaborative workflows etc ...
> 
> Occasionally the author of leo posts announcements out here
> http://leoeditor.com/
> 
> [Thats about as much as I know of it]

Thanks - actually, I'm pretty familiar with Leo, and it _might_ be bent a bit
to suit my needs ... but I am thinking of something a bit more 'traditional'
in appearance, at least.

Cheers
Jon N
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why does the first loop go wrong with Python3

[Cecil Westerhof]

Op Tuesday 19 May 2015 17:49 CEST schreef Ian Kelly:

> On Tue, May 19, 2015 at 8:44 AM, Cecil Westerhof  wrote:
>> I looked at the documentation. Is it necessary to do a:
>> p.wait()
>> afterwards?
>
> It's good practice to clean up zombie processes by waiting on them,
> but they will also get cleaned up when your script exits.

You are right. I played a little with ipython3, which made finding
things out a lot easier. ;-)

In my case it is a script, that terminates very soon after being
finished with p, but it is certainly good practise to do it myself.

I always did a free in my C programming days. I was always told it was
not necessary, but I found it better to do it anyway.


By the way, what also works is:
p = None

But it was just a try in ipython3. I would never do this in real code.
I was just curious if this would be handled correctly and it is. :-)

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

Re: Slightly OT: Seeking (python-based) project diary tool, or framework to write one

[Rustom Mody]

On Tuesday, May 19, 2015 at 9:59:16 PM UTC+5:30, jkn wrote:
> Hi All
> as in the title, this is a little bit OT - but since ideally I'd like a
> tool written in Python, and I know readers here have wide experience of
> development/collaborative workflows etc ...

Occasionally the author of leo posts announcements out here
http://leoeditor.com/

[Thats about as much as I know of it]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Convert c file to csv file(unix format) in python

[Mihamina Rakotomandimby]

On 05/19/2015 07:30 PM, umasrinat...@gmail.com wrote:

Can anyone help me in converting .c file to csv file (unix format).



Would you give a sample?

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

Re: fork/exec & close file descriptors

[Ethan Furman]

On 05/19/2015 05:59 AM, Skip Montanaro wrote:


Due to presumed bugs in an underlying library over which I have no control, I'm 
considering a restart in the wee hours of the morning. The basic fork/exec 
dance is not a problem, but how do I discover
all the open file descriptors in the new child process to make sure they get 
closed? Do I simply start at fd 3 and call os.close() on everything up to some 
largish fd number? Some of these file
descriptors will have been opened by stuff well below the Python level, so I 
don't know them a priori.


Pandaemonium [1] (and I believe Ben Finney's daemon [2]) use something akin to 
the following:

def close_open_files(exclude):
max_files = resource.getrlimit(resource.RLIMIT_NOFILE)[1]
keep = set()
for file in exclude:
if isinstance(file, baseint):
keep.add(file)
elif hasattr(file, 'fileno'):
keep.add(file.fileno())
else:
raise ValueError(
'files to not close should be either an file descriptor, '
'or a file-type object, not %r (%s)' % (type(file), file))
for fd in range(max_files, -1, -1):
if fd in keep:
continue
try:
os.close(fd)
except OSError:
exc = sys.exc_info()[1]
if exc.errno == errno.EBADF:
continue
raise

So, yeah, basically a brute-force method.

--
~Ethan~


[1] https://pypi.python.org/pypi/pandaemonium
[2] https://pypi.python.org/pypi/python-daemon
--
https://mail.python.org/mailman/listinfo/python-list

Convert c file to csv file(unix format) in python

[umasrinath88]

Hi All,

I have a python script file which converts .hex file  to c file.

Can anyone help me in converting .c file to csv file (unix format).


Regards,
Uma
-- 
https://mail.python.org/mailman/listinfo/python-list

Slightly OT: Seeking (python-based) project diary tool, or framework to write one

[jkn]

Hi All
as in the title, this is a little bit OT - but since ideally I'd like a
tool written in Python, and I know readers here have wide experience of
development/collaborative workflows etc ...

A few jobs ago the company I was with used a 'Project Diary' tool which I found
very useful. It was written in-house (in VB, I believe ;-o). I am looking for a
more widely available tool that gives similar features. 

It created and read a database which contained a series of projects. In this
context, a project was a discrete unit of development effort (eg. for a single
customer, say), and lasting from a couple of weeks to a year or more.

For each project you have a main view window which listed the 'items' in that
project. You could create a new item which was one of a large-ish number of
types. When you created a new item you were given the ability to edit a variety
of parameters, appropriate to the item type:

- info item:freeform text/HTML
- contact item: a form with email, telephone number fields
- datasheet item:   maybe a link to a PDF
- diary itemdated freeform
- task item had title & fields like 'completion date', 'completion
 percentage, etc.
- query item
- document refrence
- etc. etc.

(items could also be updated once created)

As a project develops, more and more items are added. There were sorting and
searchinf facilities to allow you to quickly find a particular item, and you
could generate custom reports based on seleted items, or date ranges,and so on.

I found this very useful and would like to find something similar, or create
something similar for my own purposes. I currently use an Excel spreadsheet
but this is a bit clunky. I am a moderately experienced Python programmer
(command line, Linux interfacing) but less experienced on the
Gui/framework/database side.

I would be interested in either pointers to something like this which might
already exists, or suggestions as to a framework that I might be able to use to
create something like this.

Other nice-to-haves for a possibly already-existing tool:

-   multiplatform
-   free, open source
-   written in Python
-   web-based probably OK.
-   extendible
-   etc. etc.

Thanks for your thoughts and any suggestions

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

Re: Slices time complexity

[Marko Rauhamaa]

Steven D'Aprano :

> To be useful, explanations ought to give the user *predictive power*
> -- if I calculate 32767 + 1, what will Python do?
>
> Explanation #1 predicts that Python will return 32768.
> Explanation #2 makes no prediction at all.

Any semantic ruleset that correctly predicts the behavior of any given
Python program is equally valid.

> Only one of these models for Python allows you to make correct
> predictions, even though all three explain the observations given.

You're slaying straw men.

>> For example, you could explain Python's object references as pointers
>> (memory addresses) if you considered that helpful. (That's how Lisp
>> textbooks often explain cons cells.)
>
> Well, you could do that, but it would fail to explain the behaviour of 
> Jython and IronPython.

Jython, CPython and IronPython are supposed to be semantically
equivalent. So any valid CPython model is also a valid model for Jython
and IronPython.

Coincidentally:

   The reference values (often just references) are pointers to these
   objects, and a special null reference, which refers to no object.

   https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.htm
   l#jls-4.3.1>

(without any explanation as to what a "pointer" might be).

> Mixing descriptions of a specific implementation with descriptions of
> the high level semantics is sometimes useful but often misleading, and
> one needs to be careful how and when one does it.

Nobody has proposed doing that.


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

Re: Why does the first loop go wrong with Python3

[Ian Kelly]

On Tue, May 19, 2015 at 8:44 AM, Cecil Westerhof  wrote:
> I looked at the documentation. Is it necessary to do a:
> p.wait()
> afterwards?

It's good practice to clean up zombie processes by waiting on them,
but they will also get cleaned up when your script exits.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Slices time complexity

[Ian Kelly]

On May 19, 2015 4:16 AM, "Serhiy Storchaka"  wrote:
>
> On 19.05.15 12:45, Steven D'Aprano wrote:
>>
>> On Tuesday 19 May 2015 05:23, Mario Figueiredo wrote:
>>>
>>>  From the above link it seems slices work in linear time on all cases.
>>
>>
>> I wouldn't trust that is always the case, e.g. deleting a contiguous
slice
>> from the end of a list could be O(1).
>
>
> It always has linear complexity. You need to decref removed elements.

Only in CPython. The operation might be O(1) in Pypy or Jython.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: fork/exec & close file descriptors

[Chris Angelico]

On Wed, May 20, 2015 at 12:31 AM, Skip Montanaro
 wrote:
> On Tue, May 19, 2015 at 8:54 AM, Chris Angelico  wrote:
>>
>> On Linux (and possibly some other Unixes), /proc/self/fd may be of
>> use.
>
>
> Good point. Yes, /proc/PID/fd appears to contain all the entries for open
> file descriptors (I am on Linux).

Yes, and /proc/self is usually a magic symlink to /proc/ so
you can just look at /proc/self/fd instead of explicitly calling up
your own PID.

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

Re: Why does the first loop go wrong with Python3

[Cecil Westerhof]

Op Tuesday 19 May 2015 15:16 CEST schreef Oscar Benjamin:

> On 19 May 2015 at 13:24, Cecil Westerhof  wrote:
>> I have the following code:
>> from __future__ import division, print_function
>>
>> import subprocess
>>
>> p = subprocess.Popen('ls -l', shell = True, stdout =
>> subprocess.PIPE) for line in iter(p.stdout.readline, ''):
>> print(line.rstrip().decode('utf-8'))
>>
>> p = subprocess.Popen('ls -l', shell = True, stdout =
>> subprocess.PIPE) for line in p.stdout.readlines():
>> print(line.rstrip().decode('utf-8'))
>>
>> This works in Python2. (Both give the same output.)
>>
>> But when I execute this in Python3, then the first loop is stuck in
>> a loop where it continually prints a empty string. The second loop
>> is executed correctly in Python3.
>>
>> In the current case it is not a problem for me, but when the output
>> becomes big, the second solution will need more memory. How can I
>> get the first version working in Python3?
>
> The problem is that Python 3 carefully distinguishes between the
> bytes that come when reading from the stdout of a process and text
> which must be decoded from the bytes. You're using iter(f, sentinel)
> and checking for a sentinel value of ''. However in Python 3 the
> sentinel returned will be b''.
>
> Consider: $ python3 Python 3.2.3 (default, Feb 27 2014, 21:31:18)
> [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or
> "license" for more information.
 '' == b''
> False
>
> If you change it from '' to b'' it will work.
>
> However the normal way to do this is to iterate over stdout
> directly:
>
> p = subprocess.Popen('ls -l', shell = True, stdout =
> subprocess.PIPE) for line in p.stdout:
> print(line.rstrip().decode('utf-8'))

Works like a charm.

I looked at the documentation. Is it necessary to do a:
p.wait()
afterwards?

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

Re: Why does the first loop go wrong with Python3

[Thomas Rachel]

Am 19.05.2015 um 15:16 schrieb Oscar Benjamin:


However the normal way to do this is to iterate over stdout directly:


Depends. There may be differences when it comes to buffering etc...


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

Re: fork/exec & close file descriptors

[Jon Ribbens]

On 2015-05-19, Skip Montanaro  wrote:
> Yeah, I'm still on 2.7, and am aware of PEP 446. Note that many of the file
> descriptors will not have been created by my Python code. They will have
> been created by underlying C/C++ libraries, so I can't guarantee which
> flags were set on file open.

There is no portable way to do this, the problem is Unix not Python.
The below code is a reasonable stab at it, but there is no 100%
guaranteed method. The code is untested but you get the idea.


  import errno
  import os


  def closeall(min=0, max=4096, keep=frozenset()):
  """Close all open file descriptors except for the given exceptions.

  Any file descriptors below or equal to `min`, or in the set `keep`
  will not be closed. Any file descriptors above `max` *might* not be
  closed.
  """
  # First try /proc/$$/pid
  try:
  for fd in os.listdir("/proc/%d/fd" % (os.getpid())):
  try:
  fd = int(fd)
  except ValueError:
  continue
  if fd >= min and fd not in keep:
  os.close(int(fd))
  return
  except OSError as exc:
  if exc[0] != errno.ENOENT:
  raise
  # If /proc was not available, fall back to closing a lot of descriptors.
  for fd in range(min, max):
  if fd not in keep:
  try:
  os.close(fd)
  except OSError as exc:
  if exc[0] != errno.EBADF:
  raise
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: fork/exec & close file descriptors

[Skip Montanaro]

On Tue, May 19, 2015 at 8:54 AM, Chris Angelico  wrote:

> On Linux (and possibly some other Unixes), /proc/self/fd may be of
> use.
>

Good point. Yes, /proc/PID/fd appears to contain all the entries for open
file descriptors (I am on Linux).

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

Re: Slices time complexity

[Oscar Benjamin]

On 19 May 2015 at 09:50, Chris Angelico  wrote:
> On Tue, May 19, 2015 at 6:39 PM, Marko Rauhamaa  wrote:
>> For example, you could explain Python's object references as pointers
>> (memory addresses) if you considered that helpful. (That's how Lisp
>> textbooks often explain cons cells.)
>
> Sorta-kinda-maybe, but if a C programmer's idea of pointers is invoked
> to explain Python's object references, the differences will start to
> be problematic:
>
> 1) Pointer arithmetic simply doesn't exist in Python. Arrays/lists are
> not just pointers to their first elements, and subscripting is most
> definitely NOT "add to pointer and dereference".
> 2) In fact, dereferencing as a whole isn't really a 'thing' either. At
> best, it happens automatically.
> 3) References actually mean something. Copying a pointer doesn't.
> Whether the Python you're using is refcounted (CPython) or
> mark-and-sweep (uPy, I think) or some other model, an additional
> reference to the same object will prevent it from being disposed of,
> which isn't the case in C.
> 4) A pointer is itself a value. You can pass a
> pointer-to-local-variable to another function and have that function
> change a local variable.

I think this is actually one of those areas where the analogy does
make sense. In Python if I pass an object as an argument to another
function I can mutate the object but I can't rebind the name in the
parent frame. Similarly in C I can pass a pointer to anything into
another function and the other function will be able to mutate the
pointed-to variable but not change the value of the pointer in the
parent frame.

int b = 2;

void f(int* d)
{
*d = 3; // Changes a which is pointed to by c and d.
d = &b; // Doesn't affect c.
*d = 4;  // Changes b
}

int main(int argc, char *argv[])
{
int a = 1;
int *c = &a;  // a and *c are the same object
f(c);
// c still points to a but a is now 3.
printf("*c = %d\n", *c);
return 0;
}

The effect is the same in Python except that I can't use an int for
the demo since they're immutable:

b = [2]

def g(d):
d[0] = 3 # Changes a which is also c and d
d = b # Doesn't affect a or c
d[0] = 4 # Changes b

def main():
a = [1]
c = a   # a and c are the same object
f(c)
# c is still a but a is now [3]
print("c =", c)

main()


Having taught beginners to program with C as a first programming
language and with Python as a first programming language I would say
that in either case this is an important fundamental concept that
beginners need to get their heads round. If a C programmer finds it
easier to understand how Python handles it by relating it to pointers
then that's great.


> 5) Furthermore, since a pointer is a value, you can have pointers to
> pointers, etc. Doesn't make any sense in Python.

You can have a reference to a container object which references other
objects. The effect is more or less the same if you want to understand
how something like this works:

a = [[0] * 5] * 5


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

Re: fork/exec & close file descriptors

[Chris Angelico]

On Tue, May 19, 2015 at 11:44 PM, Skip Montanaro
 wrote:
>
> On Tue, May 19, 2015 at 8:33 AM, Chris Angelico  wrote:
>>
>> What Python version are you targeting? Are you aware of PEP 446?
>
>
> Yeah, I'm still on 2.7, and am aware of PEP 446. Note that many of the file
> descriptors will not have been created by my Python code. They will have
> been created by underlying C/C++ libraries, so I can't guarantee which flags
> were set on file open.
>
> I'm going to continue to pursue solutions which won't require a restart for
> now, but would like to have a sane restart option in my back pocket should
> it become necessary.

Fair enough. What you MAY be able to do is preempt it by going through
your FDs and setting them all CLOEXEC, but it won't make a lot of
difference compared to just going through them all and closing them
between fork and exec.

On Linux (and possibly some other Unixes), /proc/self/fd may be of
use. Enumerating files in that should tell you about your open files.
How useful that is I don't know, though.

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

Re: Slices time complexity

[Bartc]

"Steven D'Aprano"  wrote in message
news:555b0621$0$2753$c3e8da3$76491...@news.astraweb.com...
> On Tuesday 19 May 2015 05:23, Mario Figueiredo wrote:

>> And this really has a big impact on certain operations. For instance,
>> the code below may surprise some people when they realize it doesn't
>> run in linear time on 3.4:
>
> I'm sure that lots of things surprise people who assume that every
> language's performance characteristics are identical.
>
> Python is not Lisp. Lisp is not Java. Java is not Forth. Forth is not Lua.
> Lua is not Fortran. Fortran is not PHP. Do you see a pattern yet? :-)

But sometimes you want an algorithm that works perfectly well in one
language to work just as well in another. (Subject to understood factors,
eg, one language is implemented as native code, another byte-code.)

>> Other languages implement slices. I'm currently being faced with a Go
>> snippet that mirrors the exact code above and it does run in linear
>> time.
>
> I spot a terminology error here. What Go calls a slice and what Python
> calls
> a slice are *not the same thing*. A Go slice is a view into an array.
> Python
> slicing is a *method call* to copy, assign, or delete part of a sequence.
>
> Also, Python slices can accept three arguments, not just two, which may be
> arbitrary objects. Go slices cannot.

I'm surprised about the slice thing too; I was getting used to the idea of
Python only passing around references, even to small integer values, and now
here it goes and does a copy!

But apparently only a shallow (top-level) copy. Still, it sounds expensive
if you just want to pass part of a list to a function, not the whole thing,
a function which is not going to write into the list (like the OP's
example).

>> Is there any reason why Python 3.4 implementation of slices cannot be
>> a near constant operation?
>
> Yes. (1) Backwards compatibility. (2) That would go against the design of
> Python slices that they are copies. (3) That would upset those who want
> and
> expect a slice to be a copy.

Or you could just have a different kind of slice that is just a 'view'.
(Python is a big language to which almost everything else has been bolted
on, so why not?)

> I'll tell you what -- Python slices have worked this way for over 20
> years.
> You should propose to the Go designers that Go is confusing because it
> doesn't match Python's behaviour, and they should change the meaning of
> slices in Go to match Python. There's not as much Go code in the world as
> Python code, so that will be far less disruptive. Tell them that Go should
> be just like Python, otherwise it will confuse users who expect Go slices
> to
> behave like Python slices.

I agree with the OP, the way slices work in Python is confusing to those who
expect them to work like array assignments. So if B is a million-element
list, then A=B does not copy a million elements, neither shallow or deep.

But A=B[1:] copies 99 shallow elements. (Pointers I expect, and might
need to change the reference counts of those 99 elements. And when that
slice is discarded after perhaps a handful of accesses, it might need to
change them all back. if that is the case, then a 'view' kind of slice would
have been better, with an explicit copy operation if needed.)

-- 
Bartc



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

Re: Slices time complexity

[Steven D'Aprano]

On Tue, 19 May 2015 07:35 pm, Marko Rauhamaa wrote:

> Chris Angelico :
> 
>> Sorta-kinda-maybe, but if a C programmer's idea of pointers is invoked
>> to explain Python's object references, the differences will start to
>> be problematic:
>>
>> 1) Pointer arithmetic simply doesn't exist in Python. Arrays/lists are
>> not just pointers to their first elements, and subscripting is most
>> definitely NOT "add to pointer and dereference".
> 
> Barely an issue.
> 
>> 2) In fact, dereferencing as a whole isn't really a 'thing' either. At
>> best, it happens automatically.
> 
> Yes, you could say to a C programmer: "Python's . corresponds to C's ->"
> and be done with it.


You could say that, but you would be wrong. The amount of stuff that happens
with a dot in Python is far more than a pointer dereference. I can't think
of *any* part of Python's actual behaviour relating to attribute lookup
which it models correctly.

Among other issues, it fails to explain common behaviour like inheritance,
dynamic attribute access (__getattr__ and friends), and descriptors
(properties, methods, etc), never mind about *complicated* stuff like
metaclasses.


>> 3) References actually mean something. Copying a pointer doesn't.
>> Whether the Python you're using is refcounted (CPython) or
>> mark-and-sweep (uPy, I think) or some other model, an additional
>> reference to the same object will prevent it from being disposed of,
>> which isn't the case in C.
> 
> "Disposing of" shouldn't concern a beginning Python programmer. Note
> that Scheme does not address the whole topic in its standard. The memory
> model is infinite if you will.

Beginning Python programmers are not necessarily newbies to programming. If
Susan is a guru-level programmer with thirty years experience in C, C#,
Javascript, Lisp and Forth, but today is her first day using Python, are
you going to try to tell her that Python has infinite memory when she asks
what sort of memory management Python uses?

Even beginners to programming may be capable of intuiting for themselves
that disposal is an issue to be considered. "I know my computer has 4GB of
RAM, and I've just created a list of two billion strings. My computer is
running a bit slow. Maybe this has something to do with memory? How do I
dispose of those strings so they aren't using up memory?"


>> 4) A pointer is itself a value. You can pass a
>> pointer-to-local-variable to another function and have that function
>> change a local variable.
> 
> Correct, variables are not first-class objects in Python. In C, they
> are. Functions are not first-class objects in C. In Python, they are.

Variables are not first class values in C. (I assume you meant *values*
rather than "objects", on account of C not being an OOP language.) There is
no way, for example, to set x to *the variable y* in either C or Python. If
you could, that would imply something like this:

y = 42  # regular assignment
x ::= y  # set x to be the variable y, not the value of y
assert x == y  # naturally, since x and y are now two different 
   # names for the same variable
x = 23  # regular assignment
assert y == 23  # since y is just another name for x

You should note carefully that my example doesn't involve calling setter
functions, explicitly manipulating a namespace, pointer dereferences or any
other form of indirect assignment. It just uses name binding: a name on the
left, a value on the right.

You cannot do that in C or Python.

I'm not aware of any language which treats variables as first class values.


> Still, that doesn't make the pointer semantics any less applicable to
> Python.
> 
>> 5) Furthermore, since a pointer is a value, you can have pointers to
>> pointers, etc. Doesn't make any sense in Python.
> 
> What you are saying is that references in general are not first-class
> objects in Python. In C, they are.

References in Python are not values at all, so they are not first-class
values.

Pointers in C are values, and first-class values at that.

Arrays, on the other hand, are values but not first-class values in C: you
cannot do array assignment, pass an entire array by value, or return an
array from a function.



-- 
Steven

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

Help with Regular Expression

[massi_srb]

Hi everyone,

I succesfully wrote a regex in python in order to substitute all the occurences 
in the form $"somechars" with another string. Here it is:

re.sub(ur"""(?u)(\$\"[^\"\\]*(?:\\.[^\"\\]*)*\")""", newstring, string)

Now I would need to exclude from the match all the string in the form $", ", 
can anyone help me to modufy it?
Thanks in advance!

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

Re: fork/exec & close file descriptors

[Skip Montanaro]

On Tue, May 19, 2015 at 8:33 AM, Chris Angelico  wrote:

> What Python version are you targeting? Are you aware of PEP 446?


Yeah, I'm still on 2.7, and am aware of PEP 446. Note that many of the file
descriptors will not have been created by my Python code. They will have
been created by underlying C/C++ libraries, so I can't guarantee which
flags were set on file open.

I'm going to continue to pursue solutions which won't require a restart for
now, but would like to have a sane restart option in my back pocket should
it become necessary.

Thx,

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

Re: fork/exec & close file descriptors

[Chris Angelico]

On Tue, May 19, 2015 at 10:59 PM, Skip Montanaro
 wrote:
> Due to presumed bugs in an underlying library over which I have no control,
> I'm considering a restart in the wee hours of the morning. The basic
> fork/exec dance is not a problem, but how do I discover all the open file
> descriptors in the new child process to make sure they get closed? Do I
> simply start at fd 3 and call os.close() on everything up to some largish fd
> number? Some of these file descriptors will have been opened by stuff well
> below the Python level, so I don't know them a priori.

What Python version are you targeting? Are you aware of PEP 446?

https://www.python.org/dev/peps/pep-0446/

tl;dr: As of Python 3.4, the default is to close file descriptors on
exec automatically - and atomically, where possible.

I'm not sure if there's a 2.7 backport available, though even if there
is, you'll need to manually set your files non-inheritable; AIUI the
default in 2.7 can't be changed for backward compatibility reasons
(the change in 3.4 *will* break code that was relying on automatic
inheritability of FDs - they now have to be explicitly tagged).

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

Re: Slices time complexity

[Chris Angelico]

On Tue, May 19, 2015 at 10:42 PM, Steven D'Aprano
 wrote:
> On Tue, 19 May 2015 06:50 pm, Chris Angelico wrote:
>
>> On Tue, May 19, 2015 at 6:39 PM, Marko Rauhamaa  wrote:
>>> For example, you could explain Python's object references as pointers
>>> (memory addresses) if you considered that helpful. (That's how Lisp
>>> textbooks often explain cons cells.)
>>
>> Sorta-kinda-maybe, but if a C programmer's idea of pointers is invoked
>> to explain Python's object references, the differences will start to
>> be problematic:
>>
>> 1) Pointer arithmetic simply doesn't exist in Python. Arrays/lists are
>> not just pointers to their first elements, and subscripting is most
>> definitely NOT "add to pointer and dereference".
>> 2) In fact, dereferencing as a whole isn't really a 'thing' either. At
>> best, it happens automatically.
>> 3) References actually mean something. Copying a pointer doesn't.
>> Whether the Python you're using is refcounted (CPython) or
>> mark-and-sweep (uPy, I think) or some other model, an additional
>> reference to the same object will prevent it from being disposed of,
>> which isn't the case in C.
>> 4) A pointer is itself a value. You can pass a
>> pointer-to-local-variable to another function and have that function
>> change a local variable.
>> 5) Furthermore, since a pointer is a value, you can have pointers to
>> pointers, etc. Doesn't make any sense in Python.
>
> Chris, that is one of the best explanations for why "references equals
> pointers" is *not* a good explanation for Python's behaviour. I may have to
> steal it :-)

:) They say that turnabout is fair play. I stole your "Python vs
MATLAB" python-tutor post about call-by-value vs call-by-reference vs
object semantics for years (until some other pages picked up the same
content). Go for it!

That said, though, I was specifically referring to C's pointer
semantics. As Gregory pointed out, Pascal has rather different pointer
semantics; but if you're talking about Python references and
considering using any concept of object addressing and pointers, it's
most likely going to be something similar to C/assembly, where a
pointer is a dereferenceable integer storing an offset into memory.

(But don't even get *started* on near vs far pointers, code vs data
segments and the thunks required to transform between them,
memory-mapped disk, virtual segments, overlapping segments, shared
memory, memory-mapped I/O, and all those other things that C
programmers sometimes contend with. Fun, but hardly anything to do
with Python objects. :) )

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

Re: Why does the first loop go wrong with Python3

[Oscar Benjamin]

On 19 May 2015 at 13:24, Cecil Westerhof  wrote:
> I have the following code:
> from __future__ import division, print_function
>
> import subprocess
>
> p = subprocess.Popen('ls -l', shell = True, stdout = subprocess.PIPE)
> for line in iter(p.stdout.readline, ''):
> print(line.rstrip().decode('utf-8'))
>
> p = subprocess.Popen('ls -l', shell = True, stdout = subprocess.PIPE)
> for line in p.stdout.readlines():
> print(line.rstrip().decode('utf-8'))
>
> This works in Python2. (Both give the same output.)
>
> But when I execute this in Python3, then the first loop is stuck in a
> loop where it continually prints a empty string. The second loop is
> executed correctly in Python3.
>
> In the current case it is not a problem for me, but when the output
> becomes big, the second solution will need more memory. How can I get
> the first version working in Python3?

The problem is that Python 3 carefully distinguishes between the bytes
that come when reading from the stdout of a process and text which
must be decoded from the bytes. You're using iter(f, sentinel) and
checking for a sentinel value of ''. However in Python 3 the sentinel
returned will be b''.

Consider:
$ python3
Python 3.2.3 (default, Feb 27 2014, 21:31:18)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> '' == b''
False

If you change it from '' to b'' it will work.

However the normal way to do this is to iterate over stdout directly:

 p = subprocess.Popen('ls -l', shell = True, stdout = subprocess.PIPE)
 for line in p.stdout:
 print(line.rstrip().decode('utf-8'))


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

fork/exec & close file descriptors

[Skip Montanaro]

Due to presumed bugs in an underlying library over which I have no control,
I'm considering a restart in the wee hours of the morning. The basic
fork/exec dance is not a problem, but how do I discover all the open file
descriptors in the new child process to make sure they get closed? Do I
simply start at fd 3 and call os.close() on everything up to some largish
fd number? Some of these file descriptors will have been opened by stuff
well below the Python level, so I don't know them a priori.

Thx,

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

Re: Slices time complexity

[Steven D'Aprano]

On Tue, 19 May 2015 06:50 pm, Chris Angelico wrote:

> On Tue, May 19, 2015 at 6:39 PM, Marko Rauhamaa  wrote:
>> For example, you could explain Python's object references as pointers
>> (memory addresses) if you considered that helpful. (That's how Lisp
>> textbooks often explain cons cells.)
> 
> Sorta-kinda-maybe, but if a C programmer's idea of pointers is invoked
> to explain Python's object references, the differences will start to
> be problematic:
> 
> 1) Pointer arithmetic simply doesn't exist in Python. Arrays/lists are
> not just pointers to their first elements, and subscripting is most
> definitely NOT "add to pointer and dereference".
> 2) In fact, dereferencing as a whole isn't really a 'thing' either. At
> best, it happens automatically.
> 3) References actually mean something. Copying a pointer doesn't.
> Whether the Python you're using is refcounted (CPython) or
> mark-and-sweep (uPy, I think) or some other model, an additional
> reference to the same object will prevent it from being disposed of,
> which isn't the case in C.
> 4) A pointer is itself a value. You can pass a
> pointer-to-local-variable to another function and have that function
> change a local variable.
> 5) Furthermore, since a pointer is a value, you can have pointers to
> pointers, etc. Doesn't make any sense in Python.

Chris, that is one of the best explanations for why "references equals
pointers" is *not* a good explanation for Python's behaviour. I may have to
steal it :-)



-- 
Steven

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

Why does the first loop go wrong with Python3

[Cecil Westerhof]

I have the following code:
from __future__ import division, print_function

import subprocess

p = subprocess.Popen('ls -l', shell = True, stdout = subprocess.PIPE)
for line in iter(p.stdout.readline, ''):
print(line.rstrip().decode('utf-8'))

p = subprocess.Popen('ls -l', shell = True, stdout = subprocess.PIPE)
for line in p.stdout.readlines():
print(line.rstrip().decode('utf-8'))

This works in Python2. (Both give the same output.)

But when I execute this in Python3, then the first loop is stuck in a
loop where it continually prints a empty string. The second loop is
executed correctly in Python3.

In the current case it is not a problem for me, but when the output
becomes big, the second solution will need more memory. How can I get
the first version working in Python3?

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

Re: Slices time complexity

[Rustom Mody]

On Tuesday, May 19, 2015 at 5:16:29 PM UTC+5:30, Rustom Mody wrote:
> On Tuesday, May 19, 2015 at 12:42:50 PM UTC+5:30, Marko Rauhamaa wrote:
> > I sympathize. Can you get Python without getting a language like C
> > first? Can a baby be born without an umbilical cord? Can you skip Newton
> > and go straight to quantum mechanics and relativity? I have noticed some
> > experienced Java programmers are a bit lost in the woods because they
> > don't have an idea of what is going on under the hood.
> 
> And how would you classify C# in this scheme (pun unintended)?
> 
> Note that C# is in .Net what C is in Unix -- the primary building block 
> language.
> 
> But C# also has claims to being higher level than C like java/python etc.

To be fair (and to make the opposite point of what I was making above)
I should describe a recent encounter with some C# folks.
They were doing something in what needed to be a fast loop.
Looking over the code I found some dictionary lookups.
I suggested digesting the dict-key into an int and using arrays instead of 
dicts.

They did it and got a 10x speedup.

So C# (just as your above cited typical Java programmers) certainly can produce
programmers who are clueless of what's 'under the hood'
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Slices time complexity

[Rustom Mody]

On Tuesday, May 19, 2015 at 12:42:50 PM UTC+5:30, Marko Rauhamaa wrote:
> Rustom Mody :
> 
> > However conceptually/pedagogically making a fundamenal distinction of
> > timeless | time
> > value | object
> > immutable | mutable
> > expression | statement
> > function | procedure
> >
> > is key to getting programming [and is something that Pascal got better
> > than most of its successors].
> >
> > The FPers want to squeeze the whole world into column 1
> > The OOPers want to do the opposite and are embarrassed by the existence of
> > column-1 [status of int in java etc]
> > Unless one is committed to some philosophical extreme position --
> > Only One True Way -- I believe accepting two fundamentals is the most
> > sane choice
> 
> I sympathize. Can you get Python without getting a language like C
> first? Can a baby be born without an umbilical cord? Can you skip Newton
> and go straight to quantum mechanics and relativity? I have noticed some
> experienced Java programmers are a bit lost in the woods because they
> don't have an idea of what is going on under the hood.

And how would you classify C# in this scheme (pun unintended)?

Note that C# is in .Net what C is in Unix -- the primary building block 
language.

But C# also has claims to being higher level than C like java/python etc.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Slices time complexity

[Steven D'Aprano]

On Tuesday 19 May 2015 18:39, Marko Rauhamaa wrote:

> What I'm saying is that it doesn't matter what semantic description you
> give Python constructs as long as the observed behavior is correct.

You really think that it doesn't matter which of the following two 
explanations I give for this behaviour?

x = 2
y = 3
print x+y  # prints 5

Explanation #1:

"Python adds 2 and 3 together and prints 5."

Explanation #2:

"Python takes the 2nd decimal place of pi (4), and the 3rd decimal place of 
e (8), multiplies them (32), then prints the sum of the digits (5)."

The first explanation has the advantage that it actually describes Python's 
semantic model for the + operator, and consequently it is far more likely to 
allow the user to predict the output of (say) 5+2. The second explanation 
explains the observed behaviour, but doesn't have any predictive power:

Explanation #2 continued:

"Of course Python only does that when the arguments are 2 and 3. With 
arguments 5 and 2, it takes the tenth decimal place of pi (5), the 9th 
decimal place of e**2 (8), and subtracts them from 20 (7)."

Explanations shouldn't just explain the observed behaviour. Any semi-
arbitrary collection of special cases can do that. To be useful, 
explanations ought to give the user *predictive power* -- if I calculate 
32767 + 1, what will Python do?

Explanation #1 predicts that Python will return 32768.
Explanation #2 makes no prediction at all.

Explanation #3, assuming that Python follows the same rules as C, might 
predict overflow to -32768, saturation (32767 + 1 = 32767), or "undefined 
behaviour" up to and including erasing your hard drive.

Only one of these models for Python allows you to make correct predictions, 
even though all three explain the observations given.

Having a good, consistent model for the programming language allows one to 
predict not just *what* it will do, but (in a rough and ready fashion) *how* 
it will do it. Having the *right* model allows you to predict *correctly*.


> For example, you could explain Python's object references as pointers
> (memory addresses) if you considered that helpful. (That's how Lisp
> textbooks often explain cons cells.)

Well, you could do that, but it would fail to explain the behaviour of 
Jython and IronPython.

Mixing descriptions of a specific implementation with descriptions of the 
high level semantics is sometimes useful but often misleading, and one needs 
to be careful how and when one does it.



-- 
Steve

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

Re: Slices time complexity

[Rustom Mody]

On Tuesday, May 19, 2015 at 1:49:31 PM UTC+5:30, Steven D'Aprano wrote:
> On Tuesday 19 May 2015 15:33, Rustom Mody wrote:
> 
> > However conceptually/pedagogically making a fundamenal distinction of
> > timeless | time
> > value | object
> > immutable | mutable
> > expression | statement
> > function | procedure
> > 
> > is key to getting programming [and is something that Pascal got better
> > than most of its successors].
> 
> Hmmm. Well, I don't quite know what distinction you are making between 
> timeless and time, that's ambiguous, and I strongly disagree with the 
> value/object distinction, but the rest seems reasonable.

Take Pascal and the statement:

y := x+1

A Pascal programmer (and more generally any imperative language programmer)
understands this in two frames:

The 'x+1' is understood mathematically; ie we dont need or wish or encourage
to think of it in terms of machine instructions.

OTOH the 'y := ' is to be understood procedurally or algorithmically or
in terms of some (maybe half-assed) machine abstraction.

It is only after learning to juggle these two framings that we can deal with
things like
x := x+1

C messes all this badly
1. Illegitimately coopting the '=' symbol for the assignment
2. By making expressions like ++ which are enough to confuse everyone
[ including the compiler eg  i = i++ --- does that increment or is it a no-op?]
3. Expressions are statement-ified by a ';' which discards the top-level value

Python is in some respects better than C -- at least assignment is a statement
In some its worse.  Think how frequent are questions out here on/around
- mixing up list.extend with +; sorted with sort
- comprehensions with side-effecting expressions etc

Think of the straigtforwardness of this error
>>> x = while
  File "", line 1
x = while
^
SyntaxError: invalid syntax



with clueless silence of this one:

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

Most answers to issues like the second focus on the fact that None at
top-level vanishes.  A minor nuisance compared the to the real culprit, viz
the append allowable as an rhs.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Slices time complexity

[Oscar Benjamin]

On 19 May 2015 at 11:15, Serhiy Storchaka  wrote:
> On 19.05.15 12:45, Steven D'Aprano wrote:
>>
>> On Tuesday 19 May 2015 05:23, Mario Figueiredo wrote:
>>>
>>>  From the above link it seems slices work in linear time on all cases.
>>
>>
>> I wouldn't trust that is always the case, e.g. deleting a contiguous slice
>> from the end of a list could be O(1).
>
> It always has linear complexity. You need to decref removed elements.

It has linear complexity in the length of the removed slice but not in
the length of the list. So deleting k elements from the end of a list
of length N is O(k) rather than O(N) which could be a big difference.
An algorithm that repeatedly deletes slices from the end until the
entire list was gone would still be O(N) whereas one that deletes from
the beginning would probably be O(N**2).

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

Re: Slices time complexity

[Gregory Ewing]

Chris Angelico wrote:

1) Pointer arithmetic simply doesn't exist in Python. Arrays/lists are
not just pointers to their first elements, and subscripting is most
definitely NOT "add to pointer and dereference".
2) In fact, dereferencing as a whole isn't really a 'thing' either. At
best, it happens automatically.
3) References actually mean something. Copying a pointer doesn't.
Whether the Python you're using is refcounted (CPython) or
mark-and-sweep (uPy, I think) or some other model, an additional
reference to the same object will prevent it from being disposed of,
which isn't the case in C.
4) A pointer is itself a value. You can pass a
pointer-to-local-variable to another function and have that function
change a local variable.
5) Furthermore, since a pointer is a value, you can have pointers to
pointers, etc. Doesn't make any sense in Python.


FWIW, most of those things are peculiar to C, and are not
necessarily shared even with other languages that have
explicit pointers. In Pascal, for example, there is no
pointer arithmetic, and (at least not without nonstandard
extension) you can't make a pointer point into the middle
of a stack frame or array or record, etc. (You *can* have
a pointer to a pointer, but only by heap-allocating a
memory block containing a single pointer, which is not
useful very often).

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

Re: Slices time complexity

[Serhiy Storchaka]

On 19.05.15 12:45, Steven D'Aprano wrote:

On Tuesday 19 May 2015 05:23, Mario Figueiredo wrote:

 From the above link it seems slices work in linear time on all cases.


I wouldn't trust that is always the case, e.g. deleting a contiguous slice
from the end of a list could be O(1).


It always has linear complexity. You need to decref removed elements.


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

Re: Slices time complexity

[Steven D'Aprano]

On Tuesday 19 May 2015 05:23, Mario Figueiredo wrote:

> I'd like to understand what I'm being told about slices in
> https://wiki.python.org/moin/TimeComplexity
> 
> Particularly, what's a 'del slice' and a 'set slice' and whether this
> information pertains to both CPython 2.7 and 3.4.


Get a slice: x = mylist[2:15]

Set a slice: mylist[2:15] = [2, 4, 6, 8]

Del a slice: del mylist[2:15]

 
> From the above link it seems slices work in linear time on all cases.

I wouldn't trust that is always the case, e.g. deleting a contiguous slice 
from the end of a list could be O(1).


> And this really has a big impact on certain operations. For instance,
> the code below may surprise some people when they realize it doesn't
> run in linear time on 3.4:

I'm sure that lots of things surprise people who assume that every 
language's performance characteristics are identical.

Python is not Lisp. Lisp is not Java. Java is not Forth. Forth is not Lua. 
Lua is not Fortran. Fortran is not PHP. Do you see a pattern yet? :-)


> def minimum(values):
> if len(values) == 1:
> return values[0]
> else:
> m = minimum(values[1:])
> return m if m < values[0] else values[0]
> 
> Other languages implement slices. I'm currently being faced with a Go
> snippet that mirrors the exact code above and it does run in linear
> time.

I spot a terminology error here. What Go calls a slice and what Python calls 
a slice are *not the same thing*. A Go slice is a view into an array. Python 
slicing is a *method call* to copy, assign, or delete part of a sequence.

Also, Python slices can accept three arguments, not just two, which may be 
arbitrary objects. Go slices cannot.


> Is there any reason why Python 3.4 implementation of slices cannot be
> a near constant operation?

Yes. (1) Backwards compatibility. (2) That would go against the design of 
Python slices that they are copies. (3) That would upset those who want and 
expect a slice to be a copy.

I'll tell you what -- Python slices have worked this way for over 20 years. 
You should propose to the Go designers that Go is confusing because it 
doesn't match Python's behaviour, and they should change the meaning of 
slices in Go to match Python. There's not as much Go code in the world as 
Python code, so that will be far less disruptive. Tell them that Go should 
be just like Python, otherwise it will confuse users who expect Go slices to 
behave like Python slices.

Do let us know what the Go designers say.



-- 
Steven

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