Re: process.popen with Japanese args => UTF8 JAVA

[Ben Finney]

Jun Tanaka  writes:

> I have tried to process.popen to run java program with Japanese language.
> test.java is compiled with utf8
> '日本語' below means Japanese in Japanese.
> but it does not work.

What are you expecting to happen, and what happens instead? What error
(if any) is produced?

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

Re: How is unicode implemented behind the scenes?

[wxjmfauth]

Le dimanche 9 mars 2014 03:40:28 UTC+1, MRAB a écrit :
> On 2014-03-09 02:08, Dan Stromberg wrote:
> 
> > OK, I know that Unicode data is stored in an encoding on disk.
> 
> >
> 
> > But how is it stored in RAM?
> 
> >
> 
> > I realize I shouldn't write code that depends on any relevant
> 
> > implementation details, but knowing some of the more common
> 
> > implementation options would probably help build an intuition for
> 
> > what's going on internally.
> 
> >
> 
> > I've heard that characters are no longer all c bytes wide internally,
> 
> > so is it sometimes utf-8?
> 
> >
> 
> No.
> 
> 
> 
>  From Python 3.3, it's an array of 1, 2 or 4 bytes per codepoint.
> 
> 
> 
> In Python terms:
> 
> 
> 
> if all(c <= '\xFF' for c in string):
> 
>  use 1 byte per codepoint
> 
> elif all(c <= '\x' for c in string):
> 
>  use 2 bytes per codepoint
> 
> else:
> 
>  use 4 bytes per codepoint

A very, very nice recursive mathematical
absurdity.

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

Re: process.popen with Japanese args => UTF8 JAVA

[Cameron Simpson]

On 09Mar2014 16:52, Jun Tanaka  wrote:
> I have tried to process.popen to run java program with Japanese language.
> test.java is compiled with utf8
> '日本語' below means Japanese in Japanese.
> but it does not work. Anyone who knows this matter well. Please help.
> Jun
> 
> python code>
> sentence = '日本語'
> filename = 'japanese'
> java_file = 'test'
> cmd = "java {0} {1} {2}".format(java_file, sentence, filename)
> proc = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE,
> stderr=subprocess.STDOUT)
> python code end>>

Echoing Ben, what errors do you get? And what expected?

But examining your program, it is possible that any error messages
are being concealed. Details below.

Firstly, I am surprised that the sentence comes before the java
file "test". Try swapping them.

Also, if you're doing this in a UNIX system of some kind, and therefore
your "cmd" variable is actually a shell comment, turn on tracing.
Change this:

  cmd = "java {0} {1} {2}"

to this:

  cmd = "set -x; java {0} {1} {2}"

It will show you the command the shell executes.

Finally, why do you have:

  stderr=subprocess.STDOUT

Normally you would leave stderr alone, so that error messages show
on your terminal. In particular, the shell tracing an any error
messages from your java command go to stderr, and grabbing stderr
like that may well be concealing any useful error messages you ought
to be seeing. I would be inclined to simple get rid of your stderr=
parameter and see what shows up.

Cheers,
-- 
Cameron Simpson 

Processes are like potatoes.- NCR device driver manual
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Balanced trees

[Marko Rauhamaa]

Roy Smith :

>  Marko Rauhamaa  wrote:
>
>> If I had to choose between a hash table and AVL (or RB) tree in the
>> standard library, it would definitely have to be the latter. It is more
>> generally usable, has fewer corner cases and probably has an equal
>> performance even in hash tables' sweet spot.
>
> The C++ folks made that decision, and people spent the next 10 years
> complaining, "Why is there no hash table in STL?"

Well, luckily, nobody should need to choose. Even STL has an
unordered_map now.


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

Re: Balanced trees

[Marko Rauhamaa]

Dan Stromberg :

> On Sat, Mar 8, 2014 at 1:21 PM, Marko Rauhamaa  wrote:
>> If I had to choose between a hash table and AVL (or RB) tree in the
>> standard library, it would definitely have to be the latter. It is more
>> generally usable, has fewer corner cases and probably has an equal
>> performance even in hash tables' sweet spot.
>
> Actually, in the performance comparison I mentioned previously, I
> compared Python dict's to a bunch of different balanced trees and one
> unbalanced tree. The dictionary was much faster, though granted, it
> was the only one in C.

Yes, that is one major detail. There must be many more.


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

Re: Tuples and immutability

[Marko Rauhamaa]

Ian Kelly :

> In my view the second one is wrong. a += b should be understood as
> being equivalent to a = a + b, but with the *possible* and by no means
> guaranteed optimization that the operation may be performed in-place.

Some call it an optimization, others call it a side effect.

Anyway, that's how it has been explicitly defined in the language
specification so that's the reality whether one likes it or not.


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

Re: How is unicode implemented behind the scenes?

[Rustom Mody]

On Sunday, March 9, 2014 2:09:32 PM UTC+5:30, wxjm...@gmail.com wrote:
> Le dimanche 9 mars 2014 03:40:28 UTC+1, MRAB a écrit :
> > On 2014-03-09 02:08, Dan Stromberg wrote:
> > > OK, I know that Unicode data is stored in an encoding on disk.
> > > But how is it stored in RAM?
> > > I realize I shouldn't write code that depends on any relevant
> > > implementation details, but knowing some of the more common
> > > implementation options would probably help build an intuition for
> > > what's going on internally.
> > > I've heard that characters are no longer all c bytes wide internally,
> > > so is it sometimes utf-8?
> > No.
> >  From Python 3.3, it's an array of 1, 2 or 4 bytes per codepoint.
> > In Python terms:
> > if all(c <= '\xFF' for c in string):
> >  use 1 byte per codepoint
> > elif all(c <= '\x' for c in string):
> >  use 2 bytes per codepoint
> > else:
> >  use 4 bytes per codepoint

> A very, very nice recursive mathematical absurdity.

As a profoundly astute mathematician
v v n r m a
can be parsed in 42 different ways (5th catalan number)

Which parse did you intend?


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

[RELEASED] Python 3.3.5

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm very happy to announce
the release of Python 3.3.5.

Python 3.3.5 includes fixes for these important issues:

* a 3.3.4 regression in zipimport (see http://bugs.python.org/issue20621)
* a 3.3.4 regression executing scripts with a coding declared and Windows
  newlines (see http://bugs.python.org/issue20731)
* potential DOS using compression codecs in bytes.decode() (see
  http://bugs.python.org/issue19619 and http://bugs.python.org/issue20404)

and also fixes quite a few other bugs.

Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x.  In total, almost 500 API items
are new or improved in Python 3.3.  For a more extensive list of
changes in the 3.3 series, see

http://docs.python.org/3.3/whatsnew/3.3.html

To download Python 3.3.5 visit:

http://www.python.org/downloads/release/python-335/


This is a production release, please report any bugs to

 http://bugs.python.org/

The final release is scheduled one week from now.


Enjoy!

- -- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlMcRNEACgkQN9GcIYhpnLAVqACeMoOOuuNX5iP6at9zbIZDnkqK
idwAoKb2FxAJlirhs2BmdESEaQiqBDJd
=smeC
-END PGP SIGNATURE-
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problem using py-bt, py-locals, etc. during GDB debugging [solved]

[Wesley]

I hit a problem alike yours.
Cannot fix according your method.

Here is snippet:
root@localhost python]# gdb python 40290
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"...
Reading symbols from python...done.
Attaching to program: /usr/local/bin/python, process 40290
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x0030a98e15c3 in ?? ()
(gdb) py-bt
(gdb) py-list
Unable to locate python frame
(gdb) py-locals
Unable to locate python frame
(gdb) 

I use gdb 7.7, python 2.6.6 , centos 6.5 64bit
Any suggestion?

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

Re: How is unicode implemented behind the scenes?

[Mark Lawrence]

On 09/03/2014 10:32, Rustom Mody wrote:

On Sunday, March 9, 2014 2:09:32 PM UTC+5:30, wxjm...@gmail.com wrote:

Le dimanche 9 mars 2014 03:40:28 UTC+1, MRAB a écrit :

On 2014-03-09 02:08, Dan Stromberg wrote:

OK, I know that Unicode data is stored in an encoding on disk.
But how is it stored in RAM?
I realize I shouldn't write code that depends on any relevant
implementation details, but knowing some of the more common
implementation options would probably help build an intuition for
what's going on internally.
I've heard that characters are no longer all c bytes wide internally,
so is it sometimes utf-8?

No.
  From Python 3.3, it's an array of 1, 2 or 4 bytes per codepoint.
In Python terms:
if all(c <= '\xFF' for c in string):
  use 1 byte per codepoint
elif all(c <= '\x' for c in string):
  use 2 bytes per codepoint
else:
  use 4 bytes per codepoint



A very, very nice recursive mathematical absurdity.


As a profoundly astute mathematician
v v n r m a
can be parsed in 42 different ways (5th catalan number)

Which parse did you intend?




Please don't feed this particular troll, it's a complete waste of time.

--
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: gdb unable to read python frame information

[Mark Lawrence]

On 09/03/2014 03:49, Wesley wrote:

Anybody has suggestions?

This really makes me crazy...



What makes you crazy?  You keep sending messages with no context.  We 
might be smart, but we're not (yet :) mind readers.


--
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

image processing in python and opencv

[Varsha Holla]

i have no idea how to retrieve indexed images stored in ordered dictionary, 
using its values like : blue,green,red mean along with contrast, energy, 
homogeneity and correlation. as i have calculated the euclidean distance and i 
don't know how to display the images which are similar.

thanks in advance
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tuples and immutability

[Joshua Landau]

On 28 February 2014 14:43, Chris Angelico  wrote:
> On Sat, Mar 1, 2014 at 1:41 AM, Joshua Landau  wrote:
>> Would it be better to add a check here, such that if this gets raised
>> to the top-level it includes a warning ("Addition was inplace;
>> variable probably mutated despite assignment failure")?
>
> That'd require figuring out whether or not the variable was actually
> mutated, and that's pretty hard to work out.

It does not. First, the "warning" is actually an attachment to the
exception so is only shown if the exception is uncaught. This should
basically never happen in working code. The warning exists only to
remove likely misunderstanding in these odd cases.

Even if "x = (1,); x[0] += 1" warned "addition was inplace; possible
mutation occurred" or whatever phrasing you wish, this would only
cause a quick check of the results.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tuples and immutability

[Chris Angelico]

On Mon, Mar 10, 2014 at 4:54 AM, Joshua Landau  wrote:
> On 28 February 2014 14:43, Chris Angelico  wrote:
>> On Sat, Mar 1, 2014 at 1:41 AM, Joshua Landau  wrote:
>>> Would it be better to add a check here, such that if this gets raised
>>> to the top-level it includes a warning ("Addition was inplace;
>>> variable probably mutated despite assignment failure")?
>>
>> That'd require figuring out whether or not the variable was actually
>> mutated, and that's pretty hard to work out.
>
> It does not. First, the "warning" is actually an attachment to the
> exception so is only shown if the exception is uncaught. This should
> basically never happen in working code. The warning exists only to
> remove likely misunderstanding in these odd cases.
>
> Even if "x = (1,); x[0] += 1" warned "addition was inplace; possible
> mutation occurred" or whatever phrasing you wish, this would only
> cause a quick check of the results.

I think I see what you're saying here. But ignore "top-level"; this
should just be a part of the exception message, no matter what.
Otherwise things that recreate the REPL (like IDLE) or that isolate
two sections of the code (like a web server framework) wouldn't get
the benefit, because the exception's not caught at the true top-level.

>>> x=1,
>>> x[0]+=0
Traceback (most recent call last):
  File "", line 1, in 
x[0]+=0
TypeError: 'tuple' object does not support item assignment

What you're saying is that this should notice that it's doing an
augmented assignment and give some more text. This can be done; all
you need to do is catch the error and reraise it with more info:

>>> try:
x[0]+=0
except TypeError as e:
if 'does not support item assignment' in e.args[0]:
raise TypeError(e.args[0]+"\nAugmented assignment used;
mutation may have occurred.") from None
raise

Traceback (most recent call last):
  File "", line 5, in 
raise TypeError(e.args[0]+"\nAugmented assignment used; mutation
may have occurred.") from None
TypeError: 'tuple' object does not support item assignment
Augmented assignment used; mutation may have occurred.

Now you can look at writing an import hook that does an AST transform,
locating every instance of item assignment and wrapping it like that.
It's certainly possible. I'm not sure how much benefit you'd get, but
it could be done.

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

Re: gdb unable to read python frame information

[Terry Reedy]

On 3/9/2014 10:57 AM, Mark Lawrence wrote:

On 09/03/2014 03:49, Wesley wrote:

Anybody has suggestions?


Don't expect crazy things.
Send suggestions to the right place (a gdb list for a gdb enhancement).


This really makes me crazy...



What makes you crazy?


The supposed fact that GnuDeBug does not understand Python frames on the 
stack.


> You keep sending messages with no context.  We

might be smart, but we're not (yet :) mind readers.


But we do speculate ;-)

--
Terry Jan Reedy

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

Re: Problem using py-bt, py-locals, etc. during GDB debugging [solved]

[Terry Reedy]

On 3/9/2014 10:46 AM, Wesley wrote:

I hit a problem alike yours.
Cannot fix according your method.

Here is snippet:
root@localhost python]# gdb python 40290
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"...
Reading symbols from python...done.
Attaching to program: /usr/local/bin/python, process 40290
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x0030a98e15c3 in ?? ()


If you want people to attend to your posts and help, don't post line 
after line of irrelevant boilderplate.



(gdb) py-bt
(gdb) py-list
Unable to locate python frame
(gdb) py-locals
Unable to locate python frame
(gdb)

I use gdb 7.7, python 2.6.6 , centos 6.5 64bit
Any suggestion?


See above.

--
Terry Jan Reedy

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

Re: image processing in python and opencv

[Gary Herron]

On 03/09/2014 10:56 AM, Varsha Holla wrote:

i have no idea how to retrieve indexed images stored in ordered dictionary, 
using its values like : blue,green,red mean along with contrast, energy, 
homogeneity and correlation. as i have calculated the euclidean distance and i 
don't know how to display the images which are similar.

thanks in advance


Sorry,  but is there a question here?  And is it Python related? (This 
is a Python list, right?)


And while you're rewording this as a Python related question, please 
take the time to state the problem clearly.  You'll get more help if you 
take the time to tell us what you are doing.  For instance:  You have a 
dictionary.  How was it created?  What values are stored in it?  What 
keys were used?   Why is it an "ordered" dictionary?  Is your trouble 
retrieving images, computing keys for similar images, or displaying 
images?  (All three seem to be implied above.)


Gary Herron


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

Re: Tuples and immutability

[Joshua Landau]

On 9 March 2014 18:13, Chris Angelico  wrote:
> I think I see what you're saying here. But ignore "top-level"; this
> should just be a part of the exception message, no matter what.

I don't think I was clear, but yes. That.

> What you're saying is that this should notice that it's doing an
> augmented assignment and give some more text. This can be done; all
> you need to do is catch the error and reraise it with more info:
> [...]
> Now you can look at writing an import hook that does an AST transform,
> locating every instance of item assignment and wrapping it like that.
> It's certainly possible. I'm not sure how much benefit you'd get, but
> it could be done.

I would probably implement it closer to home. Inside
tuple.__getitem__, there would be something like

if context_is_augmented_assignment():
raise TypeError(message+warning)
else:
raise TypeError(message)

which would have much lower technical costs. It does depend on how
costly "context_is_augmented_assignment" is, though. A speed argument
is totally valid, but I'd hope it's possible to work around.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tuples and immutability

[Chris Angelico]

On Mon, Mar 10, 2014 at 6:57 AM, Joshua Landau  wrote:
> I would probably implement it closer to home. Inside
> tuple.__getitem__, there would be something like
>
> if context_is_augmented_assignment():
> raise TypeError(message+warning)
> else:
> raise TypeError(message)
>
> which would have much lower technical costs. It does depend on how
> costly "context_is_augmented_assignment" is, though. A speed argument
> is totally valid, but I'd hope it's possible to work around.

Yeah, I'm not sure there's an easy way to tell the tuple that it's an
augmented assignment. You might be able to look at the backtrace, but
that's tricky.

In theory, you could catch TypeError after any augmented assignment,
and check several things:
1) The target object does not have __setitem__
2) The object being manipulated does have __iadd__ (or corresponding for others)
3) The error is that item assignment is not possible

and if all three are the case, then add a tag to the message. But this
is best done by catching the exception. Otherwise you'd be limiting
this to tuples and lists; not to mention that this is really only an
issue of error reporting, and correct code shouldn't be tripping this
at all. So put a check like that at the place where you display the
error, if you can. The AST transform that I described would also work.

But I really think it's not worth the effort. If you get this error,
understand that it may have consequences.

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

Re: Balanced trees

[Dan Stromberg]

On Sun, Mar 9, 2014 at 1:27 AM, Marko Rauhamaa  wrote:
> Dan Stromberg :
>
>> On Sat, Mar 8, 2014 at 1:21 PM, Marko Rauhamaa  wrote:
>>> If I had to choose between a hash table and AVL (or RB) tree in the
>>> standard library, it would definitely have to be the latter. It is more
>>> generally usable, has fewer corner cases and probably has an equal
>>> performance even in hash tables' sweet spot.
>>
>> Actually, in the performance comparison I mentioned previously, I
>> compared Python dict's to a bunch of different balanced trees and one
>> unbalanced tree. The dictionary was much faster, though granted, it
>> was the only one in C.
>
> Yes, that is one major detail. There must be many more.

This is not just a detail: O(1) tends to be beat O(logn) pretty easily
for large n.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Balanced trees

[Marko Rauhamaa]

Dan Stromberg :

> This is not just a detail: O(1) tends to be beat O(logn) pretty easily
> for large n.

There is no O(1) hash table.


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

Making Labels from python

[Ulrich Goebel]

Hallo,

has anybody an idea how to make small formated documents redy to print 
with python?


I would like to print address labels as

   firstname lastname
   street and number
   cip and city

The best should be to form a PDF and send it to the label printer. So 
the PDF could be given the pagesize (labelsize) and a minimum format 
(boldface). But may be there is another light-weight-format besides PDF?


Any idea?

Ulrich


--
Ulrich Goebel
Paracelsusstr. 120, 53177 Bonn
--
https://mail.python.org/mailman/listinfo/python-list

Re: Balanced trees

[Dan Stromberg]

On Sun, Mar 9, 2014 at 2:32 PM, Marko Rauhamaa  wrote:
> Dan Stromberg :
>
>> This is not just a detail: O(1) tends to be beat O(logn) pretty easily
>> for large n.
>
> There is no O(1) hash table.

http://stackoverflow.com/questions/2771368/can-hash-tables-really-be-o1
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Balanced trees

[Marko Rauhamaa]

Dan Stromberg :

> On Sun, Mar 9, 2014 at 2:32 PM, Marko Rauhamaa  wrote:
>> There is no O(1) hash table.
>
> http://stackoverflow.com/questions/2771368/can-hash-tables-really-be-o1

Please elaborate.


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

Re: Tuples and immutability

[Gregory Ewing]

Ian Kelly wrote:

In my view the second one is wrong.  a += b should be understood as
being equivalent to a = a + b, but with the *possible* and by no means
guaranteed optimization that the operation may be performed in-place.


This interpretation is at odds with the Language Reference,
section 6.2.1, Augmented Assignment Statements:

"An augmented assignment expression like x += 1 can be rewritten as x = x + 1 to
achieve a similar, but not exactly equal effect... when possible, the actual 
operation is performed

in-place, meaning that rather than creating a new object and assigning that to
the target, the old object is modified instead."

Note that it says "when possible", not "if the implementation
feels like it".


In fact, if you read the documentation for lists, you may notice that
while they clearly cover the + operator and the extend method, they do
not explicitly document the list class's += operator.


The "when possible" clause, together with the fact that lists
are mutable, implies that it *will* be done in-place. There
is no need to document all the in-place operators explicitly
for every type.

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

Re: Making Labels from python

[Gary Herron]

On 03/09/2014 02:29 PM, Ulrich Goebel wrote:

Hallo,

has anybody an idea how to make small formated documents redy to print 
with python?


I would like to print address labels as

   firstname lastname
   street and number
   cip and city

The best should be to form a PDF and send it to the label printer. So 
the PDF could be given the pagesize (labelsize) and a minimum format 
(boldface). But may be there is another light-weight-format besides PDF?


Any idea?

Ulrich




The usual python library for generating PDFs is reportlab.  It has some  
formating capabilities that my be useful for you.


Gary Herron

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

Re: Balanced trees

[Dan Stromberg]

On Sun, Mar 9, 2014 at 2:43 PM, Marko Rauhamaa  wrote:
> Dan Stromberg :
>
>> On Sun, Mar 9, 2014 at 2:32 PM, Marko Rauhamaa  wrote:
>>> There is no O(1) hash table.
>>
>> http://stackoverflow.com/questions/2771368/can-hash-tables-really-be-o1
>
> Please elaborate.

A hash table of fixed size is O(1) until you fill it so full that you
start getting enough collisions to make it O(n), as one bucket becomes
a linked list.  This is because the hash function is O(1), and looking
up a value in a C array is O(1).

A more flexible hash table will not have a fixed size; instead it will
grow itself as needed.  This growth operation tends to be O(n), but
happens vanishingly infrequently as the table grows, so it's still
amortized O(1).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Making Labels from python

[Ben Finney]

Ulrich Goebel  writes:

> has anybody an idea how to make small formated documents redy to print
> with python?

The most reliable “ready to print” document formats are:

* plain text
* PDF

All others, AFAIK, are significantly less reliable for that purpose.

The “ReportLab PDF library” is a comprehensive library for this
https://pypi.python.org/pypi/reportlab/> for general page layout
and PDF generation.

-- 
 \   “The optimist thinks this is the best of all possible worlds. |
  `\   The pessimist fears it is true.” —J. Robert Oppenheimer |
_o__)  |
Ben Finney

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

Re: Balanced trees

[Marko Rauhamaa]

Dan Stromberg :

> On Sun, Mar 9, 2014 at 2:43 PM, Marko Rauhamaa  wrote:
 There is no O(1) hash table.
> [...]
>
> it's still amortized O(1).

So we are in perfect agreement.

Hash tables are a useful family of techniques but involve quite a bit of
cost/benefit heuristics. You can only claim O(1) if your hash table is
at least as large as the number of elements.

As for comparing them with balanced trees, I think one of the main
advantages hash tables have is better CPU cache performance. A tree
involves much more jumping around the RAM than a hash table.

Still, trees have many things going for them:

 * no need to find a good hashing function

 * no need to spend time on calculating the hash value

 * no need to find optimal hash table sizes -- no costly resizing

And of course, the main point:

 * trees are ordered

Note that most key comparisons tend to be very quick as you don't need
to traverse the whole key to locate the element. Also, it is hard to say
if going O(log n) levels deep in the tree is slower than calculating the
hash value, although, as I said, the latter operation tends to benefit
from a cache locality.

Trees are also crucial when you don't have exact matches, but for
example, when you are looking for prefix or wild-card matches.


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

Re: Making Labels from python

[Irmen de Jong]

On 9-3-2014 22:29, Ulrich Goebel wrote:
> Hallo,
> 
> has anybody an idea how to make small formated documents redy to print with 
> python?
> 
> I would like to print address labels as
> 
>firstname lastname
>street and number
>cip and city
> 
> The best should be to form a PDF and send it to the label printer. So the PDF 
> could be
> given the pagesize (labelsize) and a minimum format (boldface). But may be 
> there is
> another light-weight-format besides PDF?
> 
> Any idea?
> 
> Ulrich
> 
> 


If generating PDF is too heavy for your liking, you could generate some simple 
HTML
instead and use appropriate CSS (page-break etc) to make it suitable for correct
printing (which you can do from your web browser). I've used this technique 
rather
successfully myself and generating the HTML for address labels should be fairly 
trivial.
Getting the css right can be a bit of trial and error depending on the browser 
you're using.


Irmen

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

Re: Making Labels from python

[Marko Rauhamaa]

Ben Finney :

> The most reliable “ready to print” document formats are:
>
> * plain text
> * PDF

You might also consider PostScript. It can be emitted from any
programming language without any special support (and any special
support would probably only get in the way).

A possibility is also the xlwt module, which allows you to generate
Excel documents. I have used to great success, but the results may not
be ready to print.


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

Re: Making Labels from python

[Terry Reedy]

On 3/9/2014 5:29 PM, Ulrich Goebel wrote:

Hallo,

has anybody an idea how to make small formated documents redy to print
with python?

I would like to print address labels as

firstname lastname
street and number
cip and city

The best should be to form a PDF and send it to the label printer. So
the PDF could be given the pagesize (labelsize) and a minimum format
(boldface). But may be there is another light-weight-format besides PDF?

Any idea?


Get a label printing program that you can call from python with 
subprocess. Or look at the following

https://pypi.python.org/pypi?%3Aaction=search&term=label+printing&submit=search

The top hit is pylabels, which uses ReportLab.

--
Terry Jan Reedy

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

Re: Making Labels from python

[Ulrich Goebel]

Many thanks for the moment. I will try reportlab the next days.


Am 09.03.2014 22:29, schrieb Ulrich Goebel:

Hallo,

has anybody an idea how to make small formated documents redy to print
with python?

I would like to print address labels as

firstname lastname
street and number
cip and city

The best should be to form a PDF and send it to the label printer. So
the PDF could be given the pagesize (labelsize) and a minimum format
(boldface). But may be there is another light-weight-format besides PDF?

Any idea?

Ulrich




--
Ulrich Goebel
Paracelsusstr. 120, 53177 Bonn
--
https://mail.python.org/mailman/listinfo/python-list

Re: Tuples and immutability

[Terry Reedy]

On 3/9/2014 6:03 PM, Gregory Ewing wrote:

Ian Kelly wrote:

In my view the second one is wrong.  a += b should be understood as
being equivalent to a = a + b, but with the *possible* and by no means
guaranteed optimization that the operation may be performed in-place.


This interpretation is at odds with the Language Reference,
section 6.2.1, Augmented Assignment Statements:

"An augmented assignment expression like x += 1 can be rewritten as x =
x + 1 to
achieve a similar, but not exactly equal effect... when possible, the
actual operation is performed
in-place, meaning that rather than creating a new object and assigning
that to
the target, the old object is modified instead."

Note that it says "when possible", not "if the implementation
feels like it".


In fact, if you read the documentation for lists, you may notice that
while they clearly cover the + operator and the extend method, they do
not explicitly document the list class's += operator.


The "when possible" clause, together with the fact that lists
are mutable, implies that it *will* be done in-place. There
is no need to document all the in-place operators explicitly
for every type.


The discussion of .__iop__ in the datamodel chapter was just revised 
slightly.

http://bugs.python.org/issue19953

--
Terry Jan Reedy

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

Re: better and user friendly IDE recommended?

[Martin Schöön]

Den 2014-02-14 skrev Martin Schöön :
> Den 2014-02-14 skrev Rustom Mody :
>> On Friday, February 14, 2014 2:57:13 AM UTC+5:30, Martin Schöön wrote:
>>> Den 2013-09-17 skrev rusi 
>>> > On Wednesday, September 11, 2013 7:44:04 PM UTC+5:30, 
>>> > mnishpsyched wrote:
>>> > Just saw this
>>> > http://www.youtube.com/watch?v=1-dUkyn_fZA
>>> > Yeah... scientific programming and web programming are hardly the same :-)
>>> > Still it might be worth 20 minutes of your time
>>
>>> I have started testing this. It is early days so too early to pass
>>> judgement.
>>
>>> Anyone out there using Emacs + Python + Orgmode like this?
>>> I might to need ask some questions :-)
>>
>> The speaker -- Kitchin -- is quite active on the org mode list.
>> And a bunch of other babel users. You should try there.
>> And please do report back your findings!
>
> OK, I will dive into the Orgmode pond and I will report back but
> please be patient. This is a pure spare time activity.
>
Here is a first 'report' on this.

First some background on me. My formal programming training dates
back to 1980 and covered Fortran 77 on an IBM mainframe computer.
Later some Pascal and Rocky Mountain Basic was added. I wrote much
of my PhD thesis using vi and LaTeX. Post PhD I used Matlab some
and got exposed to Emacs. I am clearly not a programmer and use
code I write myself very occasionally for supporting my work. I
started to learn Python for fun but have found it useful. All modern
stuff like test drive design, IDEs, object oriented programming
etc are new to me. So now you know why I get things wrong below :-)

Until now I have only used Org-mode in an attempt to organize myself.
I have picked up some neat ideas from Bernt Hansen:
http://doc.norang.ca/org-mode.html
Still my use is very primitive.

Then I came across this thread and the abovementioned talk...

The Orgmode mailing list is a busy place and it seems to me
everyone is very advanced, trying to do things I have problems
fathoming and coding elisp and all. So, I have been lurking and
picking up some ideas on what is possible and I have been
checking them out in the manual and by testing.

My experience of combining Emacs, Orgmode and Python (and
LaTeX) is that it forms a pretty neat system for creating
documented programs, code-enhanced documents and for 
Literate programming. Exporting to PDF and 'tangling' code
seems to work as advertised (so far problems have been my
creations). You can have code with or without row numbers.
You can hide code if you only want to show the results in
your exported document.

What you don't get as far as I can see is code completion,
syntax highlighting etc since Emacs is doing this with
respect to Orgmode and not the programming language you
use.

The following two papers have been helpful/inspiring:

"Acive Documets with Org-mode" by Eric Schulte and 
Dan Davison, Computing in Science & Engineering,
May/June 2011.

"A Multi-Language Computing Environment for Literate
Programming and Reproducible Research" by Eric Schulte,
Dan Davison, Thomas Dye and Carsten Dominik, Journal
of Statistical Software, January 2012, vol. 46, Issue 3.

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

Re: Tuples and immutability

[Ian Kelly]

On Sun, Mar 9, 2014 at 4:03 PM, Gregory Ewing
 wrote:
> Ian Kelly wrote:
>>
>> In my view the second one is wrong.  a += b should be understood as
>> being equivalent to a = a + b, but with the *possible* and by no means
>> guaranteed optimization that the operation may be performed in-place.
>
>
> This interpretation is at odds with the Language Reference,
> section 6.2.1, Augmented Assignment Statements:
>
> "An augmented assignment expression like x += 1 can be rewritten as x = x +
> 1 to
> achieve a similar, but not exactly equal effect... when possible, the actual
> operation is performed
>
> in-place, meaning that rather than creating a new object and assigning that
> to
> the target, the old object is modified instead."
>
> Note that it says "when possible", not "if the implementation
> feels like it".

That's quite vague, and not much stronger a guarantee than "maybe".
It's technically "possible" for this augmented assignment to be
performed in place:

x = 12
x += 4

But it's not done in-place, because ints are meant to be immutable.
In any case, this means that whether the operation is actually
performed in-place is an implementation detail -- if not of the Python
implementation then at least of the class -- and not something the
user should take for granted.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: better and user friendly IDE recommended?

[Michael Weylandt]

On Mar 9, 2014, at 19:58, Michael Weylandt  wrote:

> On Mar 9, 2014, at 19:22, Martin Schöön  wrote:
>> What you don't get as far as I can see is code completion,
>> syntax highlighting etc since Emacs is doing this with
>> respect to Orgmode and not the programming language you
>> use.
> 
> Put 
> 
> (setq org-src-fontify-natively t)
> 
> In your ~/.emacs or ~/.emacs.d/init.el file for syntax highlighting. 
> 
> To get the 'regular' code editing, move point into a BEGIN_SRC block and type 
> "C-c ' " (Control-C followed by single quote). That will give you your normal 
> python setup in a sub-buffer. Getting Python autocompletion in Emacs is a bit 
> tricky, but there are many options. 

For Python, you'll also want

(setq org-src-preserve-indentation t)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: better and user friendly IDE recommended?

[Michael Weylandt]

On Mar 9, 2014, at 19:22, Martin Schöön  wrote:
> What you don't get as far as I can see is code completion,
> syntax highlighting etc since Emacs is doing this with
> respect to Orgmode and not the programming language you
> use.

Put 

(setq org-src-fontify-natively t)

In your ~/.emacs or ~/.emacs.d/init.el file for syntax highlighting. 

To get the 'regular' code editing, move point into a BEGIN_SRC block and type 
"C-c ' " (Control-C followed by single quote). That will give you your normal 
python setup in a sub-buffer. Getting Python autocompletion in Emacs is a bit 
tricky, but there are many options. 

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

Re: Balanced trees

[Ian Kelly]

On Sun, Mar 9, 2014 at 4:08 PM, Dan Stromberg  wrote:
> On Sun, Mar 9, 2014 at 2:43 PM, Marko Rauhamaa  wrote:
>> Dan Stromberg :
>>
>>> On Sun, Mar 9, 2014 at 2:32 PM, Marko Rauhamaa  wrote:
 There is no O(1) hash table.
>>>
>>> http://stackoverflow.com/questions/2771368/can-hash-tables-really-be-o1
>>
>> Please elaborate.
>
> A hash table of fixed size is O(1) until you fill it so full that you
> start getting enough collisions to make it O(n), as one bucket becomes
> a linked list.  This is because the hash function is O(1), and looking
> up a value in a C array is O(1).
>
> A more flexible hash table will not have a fixed size; instead it will
> grow itself as needed.  This growth operation tends to be O(n), but
> happens vanishingly infrequently as the table grows, so it's still
> amortized O(1).

A hash table can also only ever be O(1) in the average case.  Worst
case, everything you put into the hash table has the same hash value,
and so the time to fetch an item is entirely dependent on the
collision resolution scheme -- e.g. O(n) if a linked list or linear
probe is used, or perhaps O(log n) if each bucket is a balanced binary
tree.

There are schemes such as cuckoo hashing that allow true O(1) worst
case access, but they have other drawbacks -- inserts with cuckoo
hashing are amortized O(1), and it is even possible for an insert to
fail entirely after spending exponential time trying to find a way to
arrange things.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: gdb unable to read python frame information

[Wesley]

What's information do you want?

I told the OS, gdb and python version.

And my operation steps.

What do you want more, then, I can type here.

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

Re: gdb unable to read python frame information

[Mark Lawrence]

On 10/03/2014 01:06, Wesley wrote:

What's information do you want?

I told the OS, gdb and python version.

And my operation steps.

What do you want more, then, I can type here.

Wesley



Context, you just keep sending messages like the above which on its own 
is meaningless.  Why should anybody answer your question when you can't 
be bothered to supply all the needed data in one hit?


--
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: Tuples and immutability

[Steven D'Aprano]

On Sun, 09 Mar 2014 17:42:42 -0600, Ian Kelly wrote:

> On Sun, Mar 9, 2014 at 4:03 PM, Gregory Ewing
>  wrote:

>> Note that it says "when possible", not "if the implementation feels
>> like it".
> 
> That's quite vague, and not much stronger a guarantee than "maybe". It's
> technically "possible" for this augmented assignment to be performed in
> place:
> 
> x = 12
> x += 4
>
> But it's not done in-place, because ints are meant to be immutable. 

That's incorrect. Ints aren't merely "meant" to be immutable, which 
implies that's it's optional, they are defined by the language 
specification and the reference implementation as immutable. Any 
interpreter where ints are mutable *is not Python*.


> In any case, this means that whether the operation is actually performed
> in-place is an implementation detail -- if not of the Python
> implementation then at least of the class -- and not something the user
> should take for granted.

Whether += operates in place or not is part of the interface of the 
class, not the implementation.

Would you say that whether list.append operates in place or creates a new 
list is an implementation detail? Whether str.upper() creates a new 
string or modifies the existing one in place? Mutability versus 
immutability is part of the interface, not implementation, not 
withstanding that somebody could create an alternative class with the 
opposite behaviour: a MutableStr, or ImmutableList.




-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: gdb unable to read python frame information

[Wesley]

If you don't read the loop from the top, and don't tell me exactly what you 
want by just keep saying context, please ingore this post.

Thanks.
Wesley

在 2014年3月10日星期一UTC+8上午9时48分41秒，Mark Lawrence写道：
> On 10/03/2014 01:06, Wesley wrote:
> 
> > What's information do you want?
> 
> >
> 
> > I told the OS, gdb and python version.
> 
> >
> 
> > And my operation steps.
> 
> >
> 
> > What do you want more, then, I can type here.
> 
> >
> 
> > Wesley
> 
> >
> 
> 
> 
> Context, you just keep sending messages like the above which on its own 
> 
> is meaningless.  Why should anybody answer your question when you can't 
> 
> be bothered to supply all the needed data in one hit?
> 
> 
> 
> -- 
> 
> 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: gdb unable to read python frame information

[Mark Lawrence]

On 10/03/2014 02:54, Wesley wrote:

If you don't read the loop from the top, and don't tell me exactly what you 
want by just keep saying context, please ingore this post.

Thanks.
Wesley

在 2014年3月10日星期一UTC+8上午9时48分41秒，Mark Lawrence写道：

On 10/03/2014 01:06, Wesley wrote:


What's information do you want?







I told the OS, gdb and python version.







And my operation steps.







What do you want more, then, I can type here.







Wesley








Context, you just keep sending messages like the above which on its own

is meaningless.  Why should anybody answer your question when you can't

be bothered to supply all the needed data in one hit?



--

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




Ah, that explains things, you're using the notoriously bug ridden google 
groups.  You could read and action this 
https://wiki.python.org/moin/GoogleGroupsPython but I'd suggest you 
equip yourself with a decent email client.  Thunderbird comes highly 
recommended.


--
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

Windows installation problem with 3.3.5

[Mark Lawrence]

It looks as if the upgrade from 3.3.4 to 3.3.5 has stolen my copies of 
py.exe and pyw.exe from c:\windows.  Before I raise an issue on the bug 
tracker could someone please confirm this, as it wouldn't be the first 
time I've managed to screw something up.


--
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: Balanced trees

[Steven D'Aprano]

On Sun, 09 Mar 2014 18:04:46 -0600, Ian Kelly wrote:

> On Sun, Mar 9, 2014 at 4:08 PM, Dan Stromberg 
> wrote:
>> On Sun, Mar 9, 2014 at 2:43 PM, Marko Rauhamaa 
>> wrote:
>>> Dan Stromberg :
>>>
 On Sun, Mar 9, 2014 at 2:32 PM, Marko Rauhamaa 
 wrote:
> There is no O(1) hash table.

 http://stackoverflow.com/questions/2771368/can-hash-tables-really-be-
o1
>>>
>>> Please elaborate.
>>
>> A hash table of fixed size is O(1) until you fill it so full that you
>> start getting enough collisions to make it O(n), as one bucket becomes
>> a linked list.  This is because the hash function is O(1), and looking
>> up a value in a C array is O(1).
>>
>> A more flexible hash table will not have a fixed size; instead it will
>> grow itself as needed.  This growth operation tends to be O(n), but
>> happens vanishingly infrequently as the table grows, so it's still
>> amortized O(1).
> 
> A hash table can also only ever be O(1) in the average case.

Since this discussion has apparently devolved into people trying to out-
pedant each other, I'm going to dispute that. That will depend on the 
distribution of hash collisions. With a sufficiently big table, 
sufficiently small set of possible data, a sufficiently good hash 
function, or some combination of the above, a hash table may be O(1) even 
in the worst case.

E.g. if you hash a number n to itself, e.g. hash(42) == 42, your data 
consists of single byte numbers 0 through 255, and your hash table has 
256 slots, *there are no collisions* and every lookup is O(1).

There are technical meanings for Big Oh notation, which can be quite 
complicated. There's Big O, Little o, Big Ω (omega), Little ω (omega), 
Big Θ (theta), although I don't think there's a Little θ. They can refer 
to the best case, worst case, average (mean) case, median case, "typical" 
case where you're making some guess of what occurs typically, and any 
other situation you care about. The algorithmic complexity can apply 
consistently to each and every run of the algorithm, or they can be 
amortized over many runs. If you're doing a technical analysis of an 
algorithm, this pedantic detail is important.

But when people are just talking informally in a hand-wavy manner, they 
usually say "O(foo)" when they actually mean "for typical data under 
typical conditions, the algorithm runs with a complexity of the order of 
foo". And that's perfectly okay, just like it's perfectly okay to 
describe the Earth as a sphere even though a pedant will call it a 
wrinkly asymmetrical oblate spheroid.




-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Balanced trees

[Steven D'Aprano]

On Sun, 09 Mar 2014 23:32:54 +0200, Marko Rauhamaa wrote:

> Dan Stromberg :
> 
>> This is not just a detail: O(1) tends to be beat O(logn) pretty easily
>> for large n.
> 
> There is no O(1) hash table.

Of course there are.

While it is true that hash tables *in general* are not *always* O(1), the 
claim that hash tables are O(1) is *less wrong* than your claim that 
there is "no O(1) hash table".

Proof: I create a hash table that accepts unsigned bytes as keys, where 
the hash is the value of the byte. So byte 0x42 hashes to 0x42, or 
decimal 66. I give the hash table 256 slots, numbered from 0 to 255. 
Every hash takes constant time, there are no collisions at all, lookups, 
insertions and deletions all take constant time regardless of how full 
the table is. The best, worst and average cases are not just O(1) but 
also Ω(1).

Since I have proven that there is *at least one* hash table that is O(1) 
for best, worst and average case, your claim there are no such hash 
tables is completely wrong, and certainly more wrong than the claim that 
Python dicts are O(1) (which is only a little bit wrong, but typically 
right).

See also "The Relativity Of Wrong":

http://chem.tufts.edu/answersinscience/relativityofwrong.htm




-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

golang OO removal, benefits. over python?

[flebber]

I was wondering if a better programmer than I could explain if the removal of 
OO features in golang really does offer an great benefit over python.

An article I was reading ran through a brief overview of golang in respect of 
OO features 
http://areyoufuckingcoding.me/2012/07/25/object-desoriented-language/
.

maybe removing OO features would be a benefit to c++ users or Java users but 
python?

As I have seen an interesting reddit or two of people trying to figure out go 
today it was a ruby user, totally lost with structs.

So anecdotally is actually python and ruby users changing to Go, here is a blog 
and reddit from Rob Pike. http://www.reddit.com/comments/1mue70

Why would a Python user change to go except for new and interesting?

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

Re: golang OO removal, benefits. over python?

[Rustom Mody]

On Monday, March 10, 2014 10:19:20 AM UTC+5:30, flebber wrote:
> I was wondering if a better programmer than I could explain if the removal of 
> OO features in golang really does offer an great benefit over python.

That's a strange locution: You are suggesting that go had OOP and it was removed
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Balanced trees

[Marko Rauhamaa]

Steven D'Aprano :

> Proof: I create a hash table that accepts unsigned bytes as keys, where 

The O(f(n)) notation has no meaning when n is limited.

This thing is not just pedantry. The discussion was how a balanced tree
fares in comparison with hash tables. A simplistic O(1) vs O(log n) was
presented as a proof that balanced trees don't have a chance in practice
or theory. I wasn't so easily convinced.


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