Re: [Python-Dev] cpython: Added SSL test for HTTPHandler.

2011-05-21 Thread Antoine Pitrou
On Sat, 21 May 2011 12:32:21 +0200
vinay.sajip  wrote:
> +if secure:
> +import ssl
> +fd, fn = tempfile.mkstemp()
> +os.close(fd)
> +with open(fn, 'w') as f:
> +f.write(self.PEMFILE)
> +sslctx = ssl.SSLContext(ssl.PROTOCOL_SSLv23)
> +sslctx.load_cert_chain(fn)

We already bundle a couple of cert files in Lib/test, so you shouldn't
have to use your own (see e.g. Lib/test/keycert.pem).

> +self.h_hdlr = logging.handlers.HTTPHandler(host, '/frob', 
> secure=secure)

If you want real security, HTTPHandler should configure its SSLContext
in CERT_REQUIRED mode (and be given the proper root certificate(s)).
Otherwise you are vulnerable to man-in-the-middle attacks.

See the "context" and "check_hostname" arguments to HTTPSConnection:
http://docs.python.org/dev/library/http.client.html#http.client.HTTPSConnection

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Hello!

2011-05-21 Thread Antoine Pitrou
On Fri, 20 May 2011 19:01:26 +0200
Charles-François Natali  wrote:

> Hi,
> 
> My name is Charles-François Natali, I've been using Python for a
> couple years, and I've recently been granted commit priviledge.
> I just wanted to say hi to everyone on this list, and let you know
> that I'm really happy and proud of joining this great community.

Welcome, and keep up the good work.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] Stable buildbots update

2011-05-21 Thread Antoine Pitrou

Hello,

We recently got a couple of new stable buildbots:
- R. David Murray's "x86 Gentoo" machine, which builds in non-debug
  mode and therefore checks that release Pythons work fine
- Stefan Krah's "AMD64 FreeBSD 8.2" machine
- Bill Janssen's "AMD64 Snow Leopard" machine

Many stable buildbots on the default branch (*) are currently red
because of test_packaging issues.
(*) http://www.python.org/dev/buildbot/all/waterfall?category=3.x.stable

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] The socket HOWTO

2011-05-21 Thread Antoine Pitrou

Hello,

I would like to suggest that we remove the socket HOWTO (currently at
http://docs.python.org/dev/howto/sockets.html)

My main issue with this document is that it doesn't seem to have
a well-defined destination:
- people who know sockets won't learn anything from it
- but people who don't know sockets will probably find it clear as mud
(for example, what's an "INET" or "STREAM" socket? what's "select"?)

I have other issues, such as the style/tone it's written in. I'm sure
the author had fun writing it but it doesn't fit well with the rest of
the documentation. Also, the author gives a lot of "advice" without
explaining or justifying it ("if somewhere in those input lists of
sockets is one which has died a nasty death, the select will fail" ->
is that really true? what is a "nasty death" and how is that supposed to
happen? couldn't the author have put a 3-line example to demonstrate
this supposed drawback and how it manifests?).

And, finally, many statements seem arbitrary ("There’s no question that
the fastest sockets code uses non-blocking sockets and select to
multiplex them") or plain wrong ("threading support in Unixes varies
both in API and quality. So the normal Unix solution is to fork a
subprocess to deal with each connection"). I don't think giving
misleading advice to users is really a good idea. And suggesting
beginners they use non-blocking sockets without even *showing* how (or
pointing to asyncore or Twisted) is a very bad idea. select() is not
enough, you still have to be prepared to get EAGAIN or EWOULDBLOCK when
calling recv() or send() (i.e. select() can give false positives).

Oh and I think it's obsolete too, because the "class mysocket"
concatenates the output of recv() with a str rather than a bytes
object. Not to mention that features of the "class mysocket" can be had
using a buffered socket.makefile() instead of writing custom code.

(followed up from http://bugs.python.org/issue12126 at Eli's request)

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] The socket HOWTO

2011-05-21 Thread Georg Brandl
On 05/21/11 17:07, Antoine Pitrou wrote:
> 
> Hello,
> 
> I would like to suggest that we remove the socket HOWTO (currently at
> http://docs.python.org/dev/howto/sockets.html)

+1, or a big rewrite.

Georg

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] The socket HOWTO

2011-05-21 Thread Eli Bendersky
> I would like to suggest that we remove the socket HOWTO (currently at
> http://docs.python.org/dev/howto/sockets.html)
>
> My main issue with this document is that it doesn't seem to have
> a well-defined destination:
> - people who know sockets won't learn anything from it
> - but people who don't know sockets will probably find it clear as mud
> (for example, what's an "INET" or "STREAM" socket? what's "select"?)
>


I definitely recall finding this document useful when I first learned
Python. I knew socket programming from other languages, and the
document helped to see how it maps to Python. That said, I must agree
that there is probably no place for such a tutorial in Python's
official documentation. Python is a widely-general purpose language,
and sockets programming is just one of a plethora of things it
supports, so a special treatment for sockets probably isn't warranted,
especially given that the `socket` module itself is a relatively thin
wrapper over the OS socket interface.

I don't think a rewrite will help either. To describe socket
programming in full, without missing anything and being accurate will
require no less than a small book (and in fact many such books already
exist).

Therefore, I'm +1 on removing it from the official docs. It can be
relegated to the Python wiki, where it can be improved if someone
wishes to contribute to that.

Eli
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] The socket HOWTO

2011-05-21 Thread Ross Lagerwall
On Sat, 2011-05-21 at 17:07 +0200, Antoine Pitrou wrote:
> Hello,
> 
> I would like to suggest that we remove the socket HOWTO (currently at
> http://docs.python.org/dev/howto/sockets.html)
> 
> My main issue with this document is that it doesn't seem to have
> a well-defined destination:
> - people who know sockets won't learn anything from it
> - but people who don't know sockets will probably find it clear as mud
> (for example, what's an "INET" or "STREAM" socket? what's "select"?)
> 
> I have other issues, such as the style/tone it's written in. I'm sure
> the author had fun writing it but it doesn't fit well with the rest of
> the documentation. Also, the author gives a lot of "advice" without
> explaining or justifying it ("if somewhere in those input lists of
> sockets is one which has died a nasty death, the select will fail" ->
> is that really true? what is a "nasty death" and how is that supposed to
> happen? couldn't the author have put a 3-line example to demonstrate
> this supposed drawback and how it manifests?).
> 
> And, finally, many statements seem arbitrary ("There’s no question that
> the fastest sockets code uses non-blocking sockets and select to
> multiplex them") or plain wrong ("threading support in Unixes varies
> both in API and quality. So the normal Unix solution is to fork a
> subprocess to deal with each connection"). I don't think giving
> misleading advice to users is really a good idea. And suggesting
> beginners they use non-blocking sockets without even *showing* how (or
> pointing to asyncore or Twisted) is a very bad idea. select() is not
> enough, you still have to be prepared to get EAGAIN or EWOULDBLOCK when
> calling recv() or send() (i.e. select() can give false positives).
> 
> Oh and I think it's obsolete too, because the "class mysocket"
> concatenates the output of recv() with a str rather than a bytes
> object. Not to mention that features of the "class mysocket" can be had
> using a buffered socket.makefile() instead of writing custom code.
> 
> (followed up from http://bugs.python.org/issue12126 at Eli's request)

While I agree with most of what you said, I actually did find it very
useful when first learning sockets.
It's in the top page on google for "socket programming" or "socket how
to". Also, it hinted at some concepts that could then be googled for
more information like select, nonblocking sockets, etc.

However, I would agree that this should be moved out of the
documentation and as suggested in the issue, into the wiki.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] The socket HOWTO

2011-05-21 Thread Senthil Kumaran
On Sat, May 21, 2011 at 05:37:05PM +0200, Georg Brandl wrote:
> > 
> > I would like to suggest that we remove the socket HOWTO (currently at
> > http://docs.python.org/dev/howto/sockets.html)
> 
> +1, or a big rewrite.
> 

I favor a rewrite over removal. I have read it once/twice and have
never revisited it (the probably the reason that it was not helpful
enough for a revisit), but still gives some important pointers.

One document cannot cover it all, there are many pointers (examples at
effbot.org, Python MoTW docs) all serve as good introduction to
sockets in python.

So a rewrite with good pointers would be more appropriate.

-- 
Senthil

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] The socket HOWTO

2011-05-21 Thread Georg Brandl
On 05/21/11 18:01, Senthil Kumaran wrote:
> On Sat, May 21, 2011 at 05:37:05PM +0200, Georg Brandl wrote:
>> > 
>> > I would like to suggest that we remove the socket HOWTO (currently at
>> > http://docs.python.org/dev/howto/sockets.html)
>> 
>> +1, or a big rewrite.
>> 
> 
> I favor a rewrite over removal. I have read it once/twice and have
> never revisited it (the probably the reason that it was not helpful
> enough for a revisit), but still gives some important pointers.
> 
> One document cannot cover it all, there are many pointers (examples at
> effbot.org, Python MoTW docs) all serve as good introduction to
> sockets in python.
> 
> So a rewrite with good pointers would be more appropriate.

Even then, it's better off in the Wiki until the rewrite is complete.

Georg

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Stable buildbots update

2011-05-21 Thread Tarek Ziadé
On Sat, May 21, 2011 at 4:37 PM, Antoine Pitrou  wrote:
>
> Hello,
>
> We recently got a couple of new stable buildbots:
> - R. David Murray's "x86 Gentoo" machine, which builds in non-debug
>  mode and therefore checks that release Pythons work fine
> - Stefan Krah's "AMD64 FreeBSD 8.2" machine
> - Bill Janssen's "AMD64 Snow Leopard" machine
>
> Many stable buildbots on the default branch (*) are currently red
> because of test_packaging issues.
> (*) http://www.python.org/dev/buildbot/all/waterfall?category=3.x.stable

Yes, I am aware of this. I have fixed today most remaining issues, and
fixing the final ones right now.


>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com
>



-- 
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] CPython optimization: storing reference counters outside of objects

2011-05-21 Thread Artur Siekielski
Hi.
The problem with reference counters is that they are very often
incremented/decremented, even for read-only algorithms (like traversal
of a list). It has two drawbacks:
1. CPU cache lines (64 bytes on X86) containing a beginning of a
PyObject are very often invalidated, resulting in loosing many chances
to use the CPU caches
2. The copy-on-write after fork() optimization (Linux) is almost
useless in CPython, because even if you don't modify data directly,
refcounts are modified, and PyObjects with refcounts inside are spread
all over process' memory (and one small refcount modification causes
the whole page - 4kB - to be copied into a child process).

So an idea I would like to try is to move reference counts outside of
PyObjects, to a contiguous block(s) of memory. PyObjects would have a
pointer to a reference count inside this block. Doing this I think
that
1. The beginning of PyObject structs could be CPU-cached for a much
longer time (small objects like ints could be fully cached). I don't
know if having localized writes into the block with refcounts also
help performance?
2. copy-on-write after fork() will work much better, only the block
with refcounts would be copied into a child process (for read-only
algorithms)

However the drawback is that such design introduces a new level of
indirection which is a pointer inside a PyObject instead of a direct
value. Also it seems that the "block" with refcounts would have to be
a non-trivial data structure.

I'm not a compiler/profiling expert so the main question is if such
design can work, and maybe someone was thinking about something
similar? And if CPython was profiled for CPU cache usage?
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com