Re: Teaching python to non-programmers

[Ian Kelly]

On Mon, Apr 14, 2014 at 12:13 AM, alex23  wrote:
> http://www.ietf.org/rfc/rfc1855.txt
>
> If you are sending a reply to a message or a posting be sure you
> summarize the original at the top of the message, or include just
> enough text of the original to give a context.  This will make
> sure readers understand when they start to read your response.
> Since NetNews, especially, is proliferated by distributing the
> postings from one host to another, it is possible to see a
> response to a message before seeing the original.  Giving context
> helps everyone.  But do not include the entire original!
>
> RFC1855 is the PEP8 of posting online :)

But it also says:

  Don't get involved in flame wars.  Neither post nor respond
  to incendiary material.

So we're already pretty much not in compliance.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Teaching python to non-programmers

[Mark Lawrence]

On 14/04/2014 01:20, Steven D'Aprano wrote:

On Mon, 14 Apr 2014 00:54:02 +0100, Mark Lawrence wrote:


but the powers that be deem fit not
to take any action over.


There is no Internet police. Which is a good thing, for if there were,
this sort of criticism of the Internet police is exactly the sort of
thing that would bring down their wrath onto you.



I've been known on the odd occasion to get my bottom smacked.  The full 
wrath is reserved for Greek internet experts.


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


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Learner looking for assistance

[Anthony Smith]

Hi All

I am probably doing something wrong but don't know what 
Any help would great 

Code below 

the calc_total does not return a estimated_total_weight

if add the estimated_total_weight the rest of the code works 

I am at a lose as to why ?

def calc_total(self):
amount = 0
if self.estimated_weight_hd > 0:
amount = self.number * self.estimated_weight_hd
return amount

def save(self):
self.estimated_total_weight = self.calc_total()
super(SaleNote, self).save()

def calc_total_price(self):
amount_price = 0
if self.sale_head > 0:
amount_price = self.number * self.sale_head
return amount_price
else:
if self.estimated_total_weight > 0:
amount_price = self.estimated_total_weight * self.sale_kg
return amount_price

def save(self):
self.total_price = self.calc_total_price()
super(SaleNote, self).save()

thanks 

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

Re: MemoryError in data conversion

[Peter Otten]

Mok-Kong Shen wrote:

> The code attached below produces in one of the two IMHO similar cases
> (excepting the sizes of the lists involved) MemoryError. Could experts
> kindly tell why that's so and whether there is any work-around feasible.

Here's a simpler way to reproduce the error:

>>> import ast
>>> def nested_list_literal(n):
... return "[" * n + "42" + "]" * n
... 
>>> ast.literal_eval(nested_list_literal(98))
[[42]]
>>> ast.literal_eval(nested_list_literal(99))
s_push: parser stack overflow
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.3/ast.py", line 47, in literal_eval
node_or_string = parse(node_or_string, mode='eval')
  File "/usr/lib/python3.3/ast.py", line 35, in parse
return compile(source, filename, mode, PyCF_ONLY_AST)
MemoryError

You ran into a limitation of the compiler. For us to suggest a workaround 
you'd have to explain why you want to convert the list returned from 
buildhuffmantree() into python source code and back.

> Thanks in advances.
> 
> M. K. Shen
> 
> -
> 
> import ast
> 
> def buildhuffmantree(slist,flist):
>item=slist[:]
>freq=flist[:]
>while len(item)>2:
>  mn=min(freq)
>  id=freq.index(mn)
>  u=item[id]
>  del item[id]
>  del freq[id]
>  mn1=min(freq)
>  id=freq.index(mn1)
>  v=item[id]
>  del item[id]
>  del freq[id]
>  item.append([u,v])
>  freq.append(mn+mn1)
>return(item)
> 
> def processing(slist,flist):
>bintree=buildhuffmantree(slist,flist)
>print(bintree)
>byarray=bytearray(str(bintree),"latin-1")
>bintree1=ast.literal_eval(byarray.decode("latin-1"))
>print(bintree1)
>print(bintree==bintree1)
> 
> slist1=[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 'eof']
> 
> flist1=[18, 16, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1, 1, -1]
> 
> slist2=[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17,
>  18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33,
>  34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49,
>  50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65,
>  66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81,
>  82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97,
>  98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110,
>  111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123,
>  124, 125, 126, 127, 'eof']
> 
> flist2=[2, 2, 0, 2, 0, 0, 1, 2, 1, 0, 2, 0, 0, 1, 1, 0, 2, 0, 0, 0, 1,
>  0, 0, 0, 2, 0, 0, 1, 0, 0, 0, 0, 2, 0, 0, 0, 0, 0, 1, 0, 0, 0,
>  0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
>  0, 1, 0, 2, 0, 0, 1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0,
>  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 0, 0, 0,
>  0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
>  0, 0, -1]
> 
> processing(slist1,flist1)  ### This works fine
> print()
> 
> processing(slist2,flist2)  ### This leads to MemoryError


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

Re: Language summit notes

[wxjmfauth]

Le dimanche 13 avril 2014 22:13:36 UTC+2, Terry Reedy a écrit :
> Everyone, please ignore Jim's unicode/fsr trolling, which started in 
> 
> July 2012. Don't quote it, don't try to answer it.
> 
> 
> 
> -- 
> 
> Terry Jan Reedy

---

FYI:
I was waiting for the final 3.4 release.
I'm only now maintaining interactive interpreters
(with an "s") to toy with unicode (and the coding
of characters) and some other tasks.

Python succeeded to become some kind of an "anti
unicode" tool (in the math sense, "antisymmetric, non
symmetric, symmetric"). Very interesting.

jmf


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

Re: Language summit notes

[wxjmfauth]

-

Unicode <== Coding of the characters (all schemes) <== math.

For those who are interested in that field, I recommand to
try to understand why we (the world) have to live with
all these coding schemes.

jmf

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

Re: Learner looking for assistance

[Ben Finney]

Anthony Smith  writes:

> the calc_total does not return a estimated_total_weight
>
> if add the estimated_total_weight the rest of the code works 
>
> I am at a lose as to why ?

When it's too confusing, simplify. The code you present is fine, but is
more complex than it needs to be for the specific problem.

Also, it's not complete: it appears to be part of some larger program
that we don't have. And, it appears to have suffered re-formatting when
you put it in your message, so it won't run. (Post only in plain text,
not HTML; and copy-paste the code in plain text.)

So: start simple, make something you understand, then gradually build it
up until the point where it exhibits the behaviour you're confused by.

Then, show that simple-as-possible-but-no-simpler version here, complete
with the input you're using and the resulting output.

http://www.sscce.org/>

You may find that this process gives you enough understanding that you
are then able to solve the problem. Great! But, even if not, we'll need
you to go through that process so we can understand. Feel free to post
the simple version here if it still leaves you confused.

-- 
 \ “Nothing worth saying is inoffensive to everyone. Nothing worth |
  `\saying will fail to make you enemies. And nothing worth saying |
_o__)will not produce a confrontation.” —Johann Hari, 2011 |
Ben Finney

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

gdb python core dump file : not in executable format: File format not

[Wesley]

Hi guys,
   Today I am debugging an issue related to memory leak.
I use gdb 7.7 and python 2.7.6 to generate one core dump file from production 
env.

And then, just use gdb to debug the coredump upon the same machine.
Got error that seems not support debug core file using pyton?

Here is snippet:
[root@localhost server]# gdb --core  memleak.core 
GNU gdb (GDB) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word".
[New LWP 25738]
[New LWP 25739]
[New LWP 25740]
[New LWP 25745]
[New LWP 25746]
[New LWP 25747]
[New LWP 25635]
Core was generated by `python'.
#0  0x0030016e15e3 in ?? ()
(gdb) file /root/server/deviceserver.py 
"/root/server/deviceserver.py": not in executable format: File format not 
recognized
(gdb) file /root/server/deviceserver
/root/server/deviceserver: No such file or directory.
(gdb) file /root/server/deviceserver.py 
"/root/server/deviceserver.py": not in executable format: File format not 
recognized
(gdb) 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Learner looking for assistance

[Anthony Smith]

On Monday, 14 April 2014 17:43:41 UTC+10, Anthony Smith  wrote:
> Hi All
> 
> 
> 
> I am probably doing something wrong but don't know what 
> 
> Any help would great 
> 
> 
> 
> Code below 
> 
> 
> 
> the calc_total does not return a estimated_total_weight
> 
> 
> 
> if add the estimated_total_weight the rest of the code works 
> 
> 
> 
> I am at a lose as to why ?
> 
> 
> 
> def calc_total(self):
> 
>   amount = 0
> 
>   if self.estimated_weight_hd > 0:
> 
> amount = self.number * self.estimated_weight_hd
> 
>   return amount
> 
>   
> 
>   def save(self):
> 
>   self.estimated_total_weight = self.calc_total()
> 
>   super(SaleNote, self).save()
> 
>   
> 
> def calc_total_price(self):
> 
>   amount_price = 0
> 
>   if self.sale_head > 0:
> 
>   amount_price = self.number * self.sale_head
> 
> return amount_price
> 
> else:
> 
> if self.estimated_total_weight > 0:
> 
> amount_price = self.estimated_total_weight * self.sale_kg
> 
>   return amount_price
> 
> 
> 
> def save(self):
> 
>   self.total_price = self.calc_total_price()
> 
>   super(SaleNote, self).save()
> 
> 
> 
> thanks 
> 
> 
> 
> anthony

Thanks Ben this involves django as well forgot to mention in ear
lier post Maybe it a django issue rather code. Thats why I posted it here first.

thanks 

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

Re:Learner looking for assistance

[Dave Angel]

Anthony Smith  Wrote in message:
> Hi All
> 
> I am probably doing something wrong but don't know what 
> Any help would great 
> 

As Ben pointed out,  you should be more careful with your
 copy/paste,  and especially with your indentation.  I'll assume
 these are all methods of a single class SaleNote,  and that none
 are nested.  If that's the case,  your problem is most likely
 that the second definition of save hides the first.


> Code below 
> 
> the calc_total does not return a estimated_total_weight

Right,  it returns amount.  If it gets called,  which it doesn't
 from your code here. And it doesn't save that value, it only gets
 saved by the dead code below in the first save method.
 

> 
> if add the estimated_total_weight the rest of the code works 
> 
> I am at a lose as to why ?
> 
> def calc_total(self):
>   amount = 0
>   if self.estimated_weight_hd > 0:
> amount = self.number * self.estimated_weight_hd
>   return amount
>   
>   def save(self):
>   self.estimated_total_weight = self.calc_total()
>   super(SaleNote, self).save()
>   
> def calc_total_price(self):
>   amount_price = 0
>   if self.sale_head > 0:
>   amount_price = self.number * self.sale_head
> return amount_price
> else:
> if self.estimated_total_weight > 0:
> amount_price = self.estimated_total_weight * self.sale_kg
>   return amount_price
> 
> def save(self):
>   self.total_price = self.calc_total_price()
>   super(SaleNote, self).save()
 
> 

To make the rest of the code more readable,  consider using else
 clauses on every if, so that you can more readily spot missing
 cases. Turns out that wasn't your problem,  but it costs every
 reader of your code the time to decide that. 

Personally,  I'd be using the max function,  which would simplify
 the first function to one line. 

-- 
DaveA

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

Re: MemoryError in data conversion

[Mok-Kong Shen]

Am 14.04.2014 09:46, schrieb Peter Otten:


You ran into a limitation of the compiler. For us to suggest a workaround
you'd have to explain why you want to convert the list returned from
buildhuffmantree() into python source code and back.


That list gives the Huffman encoding tree for compressing a given piece
of source text. I am writing a Python code to implement an algorithm
(not new, being first sketched in the literature since decades but yet
having no publically available implementation as far as I am aware) of
encryption processing that has Huffman data compression as its major
constituent. Now, for good security against cryptanalysis, this list
(which has to be included in the ciphertext for decryption by the
recipient) has to be well scrambled in some way. I choose to use 8-bit
bytes as units for the scrambling. Hence I convert the list to a
bytearray for performing scrambling. On decryption I reverse the
scrambling and get back the original bytearray and use ast to recover
from it the list so as to be able to do the decompression. Hopefully
this description is sufficiently clear.

M. K. Shen


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

Re:MemoryError in data conversion

[Dave Angel]

Mok-Kong Shen  Wrote in message:
> 
> The code attached below produces in one of the two IMHO similar cases
> (excepting the sizes of the lists involved) MemoryError. Could experts
> kindly tell why that's so and whether there is any work-around feasible.

Where's your stack trace for the error?  If it happens that it
 gets the error in the Ast call, then examine byarray.  I expect
 it's too large or too complex for the compiler. 




-- 
DaveA

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

Martijn Faassen: The Call of Python 2.8

[Mark Lawrence]

http://blog.startifact.com/posts/the-call-of-python-28.html so in 
response to the last line, who *IS* going to do all of the required work?


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


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: Martijn Faassen: The Call of Python 2.8

[Chris Angelico]

On Mon, Apr 14, 2014 at 10:56 PM, Mark Lawrence  wrote:
> http://blog.startifact.com/posts/the-call-of-python-28.html so in response
> to the last line, who *IS* going to do all of the required work?

Only someone for whom it's less work to build Python 2.8 than it is to
port their code to Python 3. In other words, some organization with a
megantic (that's one step below gigantic, you know [1]) Python
codebase, and some (but not heaps of) resources to put into it.
Personally, I don't see it happening; very little of the code required
will be backportable from Python 3 (in contrast to PEP 466 security
patches), so every bit of that work will be for the 2.x line only; and
any features added in 2.8 can't be used until you're prepared to drop
2.7 support. That means a fair amount of work *and* you have to drop
2.7 support. If you're going to do that, why not just port your code
to 3.x and be done with it? Who has the resources to put hours and
hours of dev time into a 2.8?

ChrisA

[1] Megantic is only +3/+3, but gigantic is 8/8. Look! :)
http://gatherer.wizards.com/Pages/Card/Details.aspx?multiverseid=370794
http://gatherer.wizards.com/Pages/Card/Details.aspx?multiverseid=195627
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Martijn Faassen: The Call of Python 2.8

[Marko Rauhamaa]

Chris Angelico :

> If you're going to do that, why not just port your code to 3.x and be
> done with it? Who has the resources to put hours and hours of dev time
> into a 2.8?

Somewhat related. Only yesterday I ported/reimplemented a software
package to python3. On the finish line, I ran into a problem: xlwt
only supports 2.6, 2.7 and 3.3. My system has python3.2.

So I backtracked to python2.7.

So not only do we have a schism between python2 and python3 but there's
one between 3.0 and 3.3. I can't help but wonder if PEP 414 was a
mistake.

Serves me right for being an "early adopter."


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

Re: MemoryError in data conversion

[Peter Otten]

Mok-Kong Shen wrote:

> Am 14.04.2014 09:46, schrieb Peter Otten:
> 
>> You ran into a limitation of the compiler. For us to suggest a workaround
>> you'd have to explain why you want to convert the list returned from
>> buildhuffmantree() into python source code and back.
> 
> That list gives the Huffman encoding tree for compressing a given piece
> of source text. I am writing a Python code to implement an algorithm
> (not new, being first sketched in the literature since decades but yet
> having no publically available implementation as far as I am aware) of
> encryption processing that has Huffman data compression as its major
> constituent. Now, for good security against cryptanalysis, this list
> (which has to be included in the ciphertext for decryption by the
> recipient) has to be well scrambled in some way. I choose to use 8-bit
> bytes as units for the scrambling. Hence I convert the list to a
> bytearray for performing scrambling. On decryption I reverse the
> scrambling and get back the original bytearray and use ast to recover
> from it the list so as to be able to do the decompression. Hopefully
> this description is sufficiently clear.

You could use json, but you may run into the same problem with that, too 
(only later):

>>> import json
>>> items = []
>>> for i in range(1000):
... s = json.dumps(items)
... items = [items]
... 
Traceback (most recent call last):
  File "", line 2, in 
  File "/usr/lib/python3.3/json/__init__.py", line 236, in dumps
return _default_encoder.encode(obj)
  File "/usr/lib/python3.3/json/encoder.py", line 191, in encode
chunks = self.iterencode(o, _one_shot=True)
  File "/usr/lib/python3.3/json/encoder.py", line 249, in iterencode
return _iterencode(o, 0)
RuntimeError: maximum recursion depth exceeded while encoding a JSON object
>>> i
995

The safest option is probably to serialize the original flist and slist, and 
use them to create the tree on the fly.

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

Re: Martijn Faassen: The Call of Python 2.8

[Chris Angelico]

On Mon, Apr 14, 2014 at 11:51 PM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> If you're going to do that, why not just port your code to 3.x and be
>> done with it? Who has the resources to put hours and hours of dev time
>> into a 2.8?
>
> Somewhat related. Only yesterday I ported/reimplemented a software
> package to python3. On the finish line, I ran into a problem: xlwt
> only supports 2.6, 2.7 and 3.3. My system has python3.2.
>
> So I backtracked to python2.7.
>
> So not only do we have a schism between python2 and python3 but there's
> one between 3.0 and 3.3. I can't help but wonder if PEP 414 was a
> mistake.
>
> Serves me right for being an "early adopter."

So get Python 3.3 for your system, then. It's not that hard. You might
need to build it from source (not hard at all), or grab packages from
a newer version of Debian/RHEL/etc (also not hard, although there
might be additional consequential package requirements). The two
should happily coexist.

Also, the EOL for Python 3.2 is way *way* nearer than EOL of the 2.x
line. If you declare that your package requires 2.6/2.7/3.3
(preferably also support 3.4), so be it. It won't be long before all
supported systems can get 3.3+, so that won't be a problem. PEP 414
was useful because we can confidently target a newer 3.3 and expect
that people will be able to get there before long.

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

Re: Martijn Faassen: The Call of Python 2.8

[Marko Rauhamaa]

Chris Angelico :

> So get Python 3.3 for your system, then.

That'll have to wait till it's time for an OS overhaul. I don't do those
every year.


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

Re: Martijn Faassen: The Call of Python 2.8

[Mark Lawrence]

On 14/04/2014 14:51, Marko Rauhamaa wrote:

Chris Angelico :


If you're going to do that, why not just port your code to 3.x and be
done with it? Who has the resources to put hours and hours of dev time
into a 2.8?


The people who haven't had enough time over the last eight years to plan 
their upgrade path to 3.x.  Eight years comes from the date of the first 
message here https://mail.python.org/pipermail/python-3000/ which was 
21/03/2006, so feel free to come up with a different answer for the time 
span.




Somewhat related. Only yesterday I ported/reimplemented a software
package to python3. On the finish line, I ran into a problem: xlwt
only supports 2.6, 2.7 and 3.3. My system has python3.2.

So I backtracked to python2.7.

So not only do we have a schism between python2 and python3 but there's
one between 3.0 and 3.3. I can't help but wonder if PEP 414 was a
mistake.


I still believe that PEP 404 was the correct thing to do.  PEP 414 was a 
no brainer :)




Serves me right for being an "early adopter."


No, serves the community right for not providing enough support to 
authors in getting their packages updated.





Marko




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


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: Martijn Faassen: The Call of Python 2.8

[Chris Angelico]

On Tue, Apr 15, 2014 at 12:40 AM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> So get Python 3.3 for your system, then.
>
> That'll have to wait till it's time for an OS overhaul. I don't do those
> every year.

What OS? Since getting 3.3 isn't just a matter of "grab the .msi/.dmg
file from python.org", I'm guessing it's neither Windows nor OS X, so
I'd guess you're most likely talking about Linux. On Linux, it's
pretty easy to build Python from source. Debian Wheezy ships Python
3.2, so with that distro you should be able to do this:

# apt-get build-dep python3

and it'll install everything you need to build Python 3.2 (and 3.3
needs the same packages). Then you just grab the source code and do
the classic configure and make.

Or if you don't want to build from source, you could get a package of
3.3 from somewhere. In the case of Debian, that would mean grabbing
the Python package from Jessie:

https://packages.debian.org/jessie/python3.3

I haven't tested, but that package will most likely install happily on
a Debian Wheezy. Chances are you can find an equivalent for other
Linuxes (I don't have much experience with rpm-based distros, but I'm
sure there's some equivalent of "apt-get build-dep"). For non-Linux
systems, I don't know how hard it is to get a newer Python, but it
seems highly unlikely that you're forced to wait for an OS upgrade.

Remember, there's nothing wrong with having lots of versions of Python
installed. The package manager might provide a couple (maybe 3.1 and
3.2), but having 3.3 installed won't break scripts that depend on 3.2
being there, unless you actually switch over what 'python3' does - and
even that's unlikely to break much, since most Linux distros are going
to be depending more on the 2.x version than the 3.x... and those that
depend on 3.x are sufficiently forward-looking to be shipping 3.3 or
even 3.4, so the point is moot.

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

Re: Martijn Faassen: The Call of Python 2.8

[Chris Angelico]

On Tue, Apr 15, 2014 at 12:46 AM, Mark Lawrence  wrote:
>> So not only do we have a schism between python2 and python3 but there's
>> one between 3.0 and 3.3. I can't help but wonder if PEP 414 was a
>> mistake.
>
>
> I still believe that PEP 404 was the correct thing to do.  PEP 414 was a no
> brainer :)

I'm pretty sure the 414 there wasn't a typo, since he's talking about
the schism between 3.0 and 3.3. But let's face it, there's a *lot* of
schism between there, and it's all the same sort of thing: code
written for 3.0 will usually run happily on 3.3, and code written to
take advantage of 3.3's features won't work on 3.0. That's kinda how
new versions work, yaknow...

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

Re: Martijn Faassen: The Call of Python 2.8

[wxjmfauth]

I will most probably backport two quite large applications
to Py27 ("scientific data processing apps").
It's more a question of willingness, than a technical
difficulty. Then basta.
Note: cp1252 is good enough. (latin1/iso8859-1 not!).

jmf

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

Re: Martijn Faassen: The Call of Python 2.8

[Pete Forman]

Mark Lawrence  writes:

> On 14/04/2014 14:51, Marko Rauhamaa wrote:
>> Chris Angelico :
>>
>>> If you're going to do that, why not just port your code to 3.x and
>>> be done with it? Who has the resources to put hours and hours of dev
>>> time into a 2.8?
>
> The people who haven't had enough time over the last eight years to
> plan their upgrade path to 3.x. Eight years comes from the date of the
> first message here https://mail.python.org/pipermail/python-3000/
> which was 21/03/2006, so feel free to come up with a different answer
> for the time span.

Would it help if we adopted a non-numeric name for this product to
support eXisting Python for those who were notified some years ago that
Python 2 would be superseded? How about Python XP?

I thought not ;-)

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

Python hackathon ideas

[Claudiu Popa]

Hello!

I'm planning a Python hackathon in my area, which will be held in a
couple of weeks. Being my first organized hackathon, I don't quite
know on what we will be working. One idea I have is to find a couple
of open source projects and start contributing to them.
Another idea is to work on Python issues from the bug tracker, but
finding easy ones to contribute is not an easy task even for an
intermediate developer like me.
So, what I am looking for is open source Python projects with:

- no tests or very few tests at all
- no documentation or very scarce documentation
- Python 2 only (and we'll try to port them to Python 3)

I know about Python 3 Wall of superpowers, but most of the Python 2
only projects seems too big
for us to tackle in one day. If you know these kind of projects or you
have one which
needs those kind of things, please tell me. Any idea will be appreciated.

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

Re: Martijn Faassen: The Call of Python 2.8

[Ian Kelly]

On Apr 14, 2014 11:46 AM,  wrote:
>
> I will most probably backport two quite large applications
> to Py27 ("scientific data processing apps").

These applications are already on Python 3? Why do you want them on Python
2? Even the people talking about a 2.8 are only seeing it as an upgrade
path to Python 3.

> It's more a question of willingness, than a technical
> difficulty. Then basta.
> Note: cp1252 is good enough. (latin1/iso8859-1 not!).

Because cp1252 includes that holiest of holies, the Euro sign, I assume.

Point of curiosity: if the first 256 codepoints of Unicode happened to
correspond to cp1252 instead of Latin-1, would you still object to the FSR?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Martijn Faassen: The Call of Python 2.8

[Ned Batchelder]

On 4/14/14 2:59 PM, Ian Kelly wrote:

Point of curiosity: if the first 256 codepoints of Unicode happened to
correspond to cp1252 instead of Latin-1, would you still object to the FSR?


Many of us on the list would appreciate it if you didn't open that 
particular can of worms.  You are of course always welcome to write to 
JMF privately, although he has never responded to me over that channel.


--
Ned Batchelder, http://nedbatchelder.com

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

Re: gdb python core dump file : not in executable format: File format not

[david.gar...@gmail.com]

Does this help?

http://plasmodic.github.io/ecto/ecto/usage/external/debugging.html


http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsDebugging


http://downloads.conceptive.be/downloads/camelot/doc/sphinx/build/advanced/debug.html

http://forums.gentoo.org/viewtopic-p-7123814.html


On Mon, Apr 14, 2014 at 1:19 AM, Wesley  wrote:

> Hi guys,
>Today I am debugging an issue related to memory leak.
> I use gdb 7.7 and python 2.7.6 to generate one core dump file from
> production env.
>
> And then, just use gdb to debug the coredump upon the same machine.
> Got error that seems not support debug core file using pyton?
>
> Here is snippet:
> [root@localhost server]# gdb --core  memleak.core
> GNU gdb (GDB) 7.7
> Copyright (C) 2014 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-unknown-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word".
> [New LWP 25738]
> [New LWP 25739]
> [New LWP 25740]
> [New LWP 25745]
> [New LWP 25746]
> [New LWP 25747]
> [New LWP 25635]
> Core was generated by `python'.
> #0  0x0030016e15e3 in ?? ()
> (gdb) file /root/server/deviceserver.py
> "/root/server/deviceserver.py": not in executable format: File format not
> recognized
> (gdb) file /root/server/deviceserver
> /root/server/deviceserver: No such file or directory.
> (gdb) file /root/server/deviceserver.py
> "/root/server/deviceserver.py": not in executable format: File format not
> recognized
> (gdb)
> --
> https://mail.python.org/mailman/listinfo/python-list
>



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

Re: Martijn Faassen: The Call of Python 2.8

[Phil Dobbin]

On 14/04/2014 13:56, Mark Lawrence wrote:

> http://blog.startifact.com/posts/the-call-of-python-28.html so in
> response to the last line, who *IS* going to do all of the required work?
> 

On a related note, Guido announced today that there will be no 2.8 &
that the eol for 2.7 will be 2020.

Cheers,

  Phil...

-- 
currently (ab)using
CentOS 6.5, Debian Squeeze & Wheezy, Fedora 19 & 20, OS X Snow Leopard,
RHEL 7, Ubuntu Precise & Saucy
GnuGPG Key : http://phildobbin.org/publickey.asc
Based in London, UK


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

Re: MemoryError in data conversion

[Mok-Kong Shen]

Am 14.04.2014 15:59, schrieb Peter Otten:


You could use json, but you may run into the same problem with that, too
(only later):


import json
items = []
for i in range(1000):

... s = json.dumps(items)
... items = [items]
...
Traceback (most recent call last):
   File "", line 2, in 
   File "/usr/lib/python3.3/json/__init__.py", line 236, in dumps
 return _default_encoder.encode(obj)
   File "/usr/lib/python3.3/json/encoder.py", line 191, in encode
 chunks = self.iterencode(o, _one_shot=True)
   File "/usr/lib/python3.3/json/encoder.py", line 249, in iterencode
 return _iterencode(o, 0)
RuntimeError: maximum recursion depth exceeded while encoding a JSON object

i

995

The safest option is probably to serialize the original flist and slist, and
use them to create the tree on the fly.


Thank you very much for your efforts to help me.

I have yet a question out of curiosity: Why is my 2nd list structure,
that apparently is too complex for handling by eval and json, seemingly
not a problem for pickle?

M. K. Shen

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

Python, Linux, and the setuid bit

[Ethan Furman]

For anyone in the unenviable position of needing [1] to run Python scripts with the setuid bit on, there is an 
suid-python wrapper [2] that makes this possible.


When I compiled it I was given a couple warnings.  Can any one shed light on 
what they mean?

==
suid-python.c: In function ‘malloc_abort’:
suid-python.c:119:17: warning: format ‘%d’ expects argument of type ‘int’, but 
argument 3 has type ‘size_t’ [-Wformat]
suid-python.c: In function ‘remove_env_prefix’:
suid-python.c:200:32: warning: cast from pointer to integer of different size 
[-Wpointer-to-int-cast]
suid-python.c:201:32: warning: cast from pointer to integer of different size 
[-Wpointer-to-int-cast]
==

and the code segments in question:

==
void *
malloc_abort(size_t size)
{
void *buf;

buf = malloc(size);
if (!buf)
{
fprintf(stderr, "Could not allocate %d bytes.  errno=%d\n",
size, errno);
exit(1);
}

return buf;
}
--
int
remove_env_prefix(char **envp, char *prefix)
{
char **envp_read;
char **envp_write;
int prefix_len = strlen(prefix);
int removed_count = 0;

envp_write = envp;
for (envp_read = envp; *envp_read; envp_read++)
{
if (!strncmp(*envp_read, prefix, prefix_len))
{
/* Step past the environment variable that we don't want. */
removed_count++;
continue;
}

if (envp_read != envp_write)
{
*envp_write = *envp_read;
}

envp_write++;
}

/* Set the remaining slots to NULL. */
if (envp_write < envp_read)
{
memset(envp_write, 0, ((unsigned int) envp_read -
   (unsigned int) envp_write));
}

return removed_count;
}
==

Thanks!

--
~Ethan~

[1] Need, or really really really convenient to have. ;)
[2] http://selliott.org/python/
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Linux, and the setuid bit

[John Gordon]

In  Ethan Furman 
 writes:

>  fprintf(stderr, "Could not allocate %d bytes.  errno=%d\n",
>  size, errno);

%d is not the correct specifier for printing objects of type size_t.

>  char **envp_read;
>  char **envp_write;

>  if (envp_write < envp_read)
>  {
>  memset(envp_write, 0, ((unsigned int) envp_read -
> (unsigned int) envp_write));
>  }

I think it's complaining about casting the char ** objects to unsigned int.

-- 
John Gordon Imagine what it must be like for a real medical doctor to
gor...@panix.comwatch 'House', or a real serial killer to watch 'Dexter'.

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

Re: Python, Linux, and the setuid bit

[Grant Edwards]

On 2014-04-14, John Gordon  wrote:
> In  Ethan Furman 
>  writes:
>
>>  fprintf(stderr, "Could not allocate %d bytes.  errno=%d\n",
>>  size, errno);
>
> %d is not the correct specifier for printing objects of type size_t.

I believe %zu is the correct format specifier for size_t values.

>>  char **envp_read;
>>  char **envp_write;
>
>>  if (envp_write < envp_read)
>>  {
>>  memset(envp_write, 0, ((unsigned int) envp_read -
>> (unsigned int) envp_write));
>>  }
>
> I think it's complaining about casting the char ** objects to unsigned int.

If we assume that the author is trying to clear memory between the
addresses pointed to by the two variables, then it's probably better
be cast to (char *) before the subtracted.  That should result in an
integer value.

-- 
Grant Edwards   grant.b.edwardsYow! Please come home with
  at   me ... I have Tylenol!!
  gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Linux, and the setuid bit

[Grant Edwards]

On 2014-04-14, Grant Edwards  wrote:
> On 2014-04-14, John Gordon  wrote:

>>>  char **envp_read;
>>>  char **envp_write;
>>
>>>  if (envp_write < envp_read)
>>>  {
>>>  memset(envp_write, 0, ((unsigned int) envp_read -
>>> (unsigned int) envp_write));
>>>  }
>>
>> I think it's complaining about casting the char ** objects to unsigned int.
>
> If we assume that the author is trying to clear memory between the
> addresses pointed to by the two variables, then it's probably better
> be cast to (char *) before the subtracted.

Wow, I mangled that sentence.  It should have been something like:

then it's probably better to cast them to (char *) before the
subtraction.

 memset(envp_write, 0, ((char*)envp_read)-((char*)envp_write));

-- 
Grant Edwards   grant.b.edwardsYow! My mind is making
  at   ashtrays in Dayton ...
  gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: MemoryError in data conversion

[Gregory Ewing]

Mok-Kong Shen wrote:

I have yet a question out of curiosity: Why is my 2nd list structure,
that apparently is too complex for handling by eval and json, seemingly
not a problem for pickle?


Pickle is intended for arbitrary data structures, so it
is designed to be able to handle deeply-nested and/or
recursive data. Eval only has to handle nesting to depths
likely to be encountered in source code. Apparently the
json parser also assumes you're not going to be using
very deep nesting.

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

Re: Python, Linux, and the setuid bit

[Chris Angelico]

On Tue, Apr 15, 2014 at 7:13 AM, Ethan Furman  wrote:
> When I compiled it I was given a couple warnings.  Can any one shed light on
> what they mean?

They mean, most likely, that the author compiled the program on his
own computer and not on any other. If I had to make a guess, I'd say
that it would compile nicely on a 32-bit system, and you're running a
64-bit system; according to gcc on my amd64 Debian Wheezy here,
sizeof(short) is 2 bytes, int is 4, long is 8.

Do you feel like patching the program? As Grant says, casting to (char
*) is the more usual way to do this sort of arithmetic. Since they're
being cast to (unsigned int), you'll *probably* get away with this, as
long as the environment doesn't exceed 4GB in size (!!), so you could
just ignore it (it's a warning, not an error, after all); but you can
probably fix it for all platforms by making the two changes Grant
suggested.

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

Re: Python hackathon ideas

[Chris Angelico]

On Tue, Apr 15, 2014 at 4:54 AM, Claudiu Popa  wrote:
> - Python 2 only (and we'll try to port them to Python 3)
>
> I know about Python 3 Wall of superpowers, but most of the Python 2
> only projects seems too big
> for us to tackle in one day.

I suspect that, by now, any Py2 projects that could be ported to Py3
in one day have already been ported, or else nobody cares about them.

Generally, the best way to find a project to contribute to is to find
one that you actively and personally use. Dig into it and find
something that makes you go "Wow, I didn't know you could do that with
it!", and there's a chance for a docs patch. Or dig through the bug
tracker and confirm some bugs; that's more useful than a lot of people
realize. "Bug occurs on X with Y and Z... let's see if it happens for
me too."

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

Re:Python, Linux, and the setuid bit

[Dave Angel]

Ethan Furman  Wrote in message:
> For anyone in the unenviable position of needing [1] to run Python scripts 
> with the setuid bit on, there is an 
> suid-python wrapper [2] that makes this possible.
> 
> When I compiled it I was given a couple warnings.  Can any one shed light on 
> what they mean?
> 
> ==
> suid-python.c: In function �malloc_abort�:
> suid-python.c:119:17: warning: format �%d� expects argument of type �int�, 
> but argument 3 has type �size_t� [-Wformat]
> suid-python.c: In function �remove_env_prefix�:
> suid-python.c:200:32: warning: cast from pointer to integer of different size 
> [-Wpointer-to-int-cast]
> suid-python.c:201:32: warning: cast from pointer to integer of different size 
> [-Wpointer-to-int-cast]
> ==
> 
> and the code segments in question:
> 
> ==
> void *
> malloc_abort(size_t size)
> {
>  void *buf;
> 
>  buf = malloc(size);
>  if (!buf)
>  {
>  fprintf(stderr, "Could not allocate %d bytes.  errno=%d\n",
>  size, errno);

Your variable 'size' is declared as size_t, which is an integer
 the size of a pointer. Not necessarily the same as an int. But if
 your size is reasonable,  no harm done. The correct fix is to use
 some other format rather than % d, I forget what one. Second
 choice is to cast to an int. Third lousy choice,  ignore the
 warning. 


>  exit(1);
>  }
> 
>  return buf;
> }
> --
> int
> remove_env_prefix(char **envp, char *prefix)
> {
>  char **envp_read;
>  char **envp_write;
>  int prefix_len = strlen(prefix);
>  int removed_count = 0;
> 
>  envp_write = envp;
>  for (envp_read = envp; *envp_read; envp_read++)
>  {
>  if (!strncmp(*envp_read, prefix, prefix_len))
>  {
>  /* Step past the environment variable that we don't want. */
>  removed_count++;
>  continue;
>  }
> 
>  if (envp_read != envp_write)
>  {
>  *envp_write = *envp_read;
>  }
> 
>  envp_write++;
>  }
> 
>  /* Set the remaining slots to NULL. */
>  if (envp_write < envp_read)
>  {
>  memset(envp_write, 0, ((unsigned int) envp_read -
> (unsigned int) envp_write));

(you really should have put a comment,  so we'd know this is line
 200, 201)

It's incorrect to cast each pointer to an int, but not the
 difference of two pointers.  Subtract the first,  then cast if
 you must.  But the difference of two pointers is type ptr_diff,
 and that should already be the type mem set is expecting.
 

>
> 
> 


-- 
DaveA

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

Re: Python, Linux, and the setuid bit

[Ethan Furman]

On 04/14/2014 06:33 PM, Dave Angel wrote:


(you really should have put a comment,  so we'd know this is line
  200, 201)


Sorry, not used to asking questions about C code.  ;)  I'll make sure and do 
that next time.

Thanks for the help!

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

Re: Python, Linux, and the setuid bit

[Ethan Furman]

Thanks to everyone for the pointers.  ;)

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

Re: Python, Linux, and the setuid bit

[Chris Angelico]

On Tue, Apr 15, 2014 at 11:38 AM, Ethan Furman  wrote:
> Thanks to everyone for the pointers.  ;)

Pun intended, I hope...?

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

Re: Python hackathon ideas

[Rustom Mody]

On Tuesday, April 15, 2014 12:24:47 AM UTC+5:30, Claudiu Popa wrote:
> Hello!
> 
> I'm planning a Python hackathon in my area, which will be held in a
> couple of weeks. Being my first organized hackathon, I don't quite
> know on what we will be working.

Just yesterday I discovered that kodos that used to work is now not working
probably due to bit rot http://kodos.sourceforge.net/

Its a python-based and python-supporting app to create/debug regular 
expressions.
Whether its a scale suitable for your hackathon I dont really know.

All the best for the hackathon!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Martijn Faassen: The Call of Python 2.8

[Terry Reedy]

On 4/14/2014 9:51 AM, Marko Rauhamaa wrote:

Chris Angelico :


If you're going to do that, why not just port your code to 3.x and be
done with it? Who has the resources to put hours and hours of dev time
into a 2.8?


Somewhat related. Only yesterday I ported/reimplemented a software
package to python3. On the finish line, I ran into a problem: xlwt
only supports 2.6, 2.7 and 3.3. My system has python3.2.

So I backtracked to python2.7.

So not only do we have a schism between python2 and python3 but there's
one between 3.0 and 3.3. I can't help but wonder if PEP 414 was a
mistake.


The 'mistake' is your OS, whatever it is, not providing 3.3. It is 
already so old that it is off bugfix maintenance. Any decent system 
should have 3.4 available now.


In any case, I think PEP 393 (new unicode implementation) is reason 
enough to jump to 3.3.


--
Terry Jan Reedy

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

Re: Martijn Faassen: The Call of Python 2.8

[Terry Reedy]

On 4/14/2014 8:56 AM, Mark Lawrence wrote:

http://blog.startifact.com/posts/the-call-of-python-28.html so in
response to the last line, who *IS* going to do all of the required work?


Steve Dower of Microsoft proposed a similar idea of a migration version 
of 2.7 after talking with people from businesses that use Python. His 
proposal engenders the same question. I don't really care. I just know 
that I am not volunteering my time to help billion-dollar corporations 
with 1000s of employees.


--
Terry Jan Reedy

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

Re: Martijn Faassen: The Call of Python 2.8

[Marko Rauhamaa]

Terry Reedy :

> Any decent system should have 3.4 available now.

Really, now? Which system is that?


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

Re: Martijn Faassen: The Call of Python 2.8

[Ben Finney]

Terry Reedy  writes:

> The 'mistake' is your OS, whatever it is, not providing 3.3. It is
> already so old that it is off bugfix maintenance. Any decent system
> should have 3.4 available now.

I think you mean “… should have Python 3.3 available now”, yes?

-- 
 \ “I wish there was a knob on the TV to turn up the intelligence. |
  `\  There's a knob called ‘brightness’ but it doesn't work.” |
_o__) —Eugene P. Gallagher |
Ben Finney

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