Re: [Python-Dev] bytes / unicode

Tres Seaver wrote: > Stephen J. Turnbull wrote: > > > We do need str-based implementations of modules like urllib. > > Why would that be? URLs aren't text, and never will be. The fact that > to the eye they may seem to be text-ish doesn't make them text. This URLs are exactly text (strings,

Re: [Python-Dev] bytes / unicode

Guido van Rossum wrote: > So I propose that we drop the discussion "are URLs text or bytes" and > try to find something more pragmatic to discuss. > > For example: how we can make the suite of functions used for URL > processing more polymorphic, so that each developer can choose for > herself h

Re: [Python-Dev] os.getgroups() on MacOS X Was: red buildbots on 2.7

See also http://gimper.net/viewtopic.php?f=18&t=3185. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] thoughts on the bytes/string discussion

Here are a couple of ideas I'm taking away from the bytes/string discussion. First, it would probably be a good idea to have a String ABC. Secondly, maybe the string situation in 2.x wasn't as broken as we thought it was. In particular, those who deal with lots of encoded strings seemed to find

Re: [Python-Dev] thoughts on the bytes/string discussion

Guido van Rossum wrote: > On Fri, Jun 25, 2010 at 1:43 PM, Glyph Lefkowitz > wrote: > > > > On Jun 24, 2010, at 4:59 PM, Guido van Rossum wrote: > > > > Regarding the proposal of a String ABC, I hope this isn't going to > > become a backdoor to reintroduce the Python 2 madness of allowing > > eq

[Python-Dev] OS X buildbots: why am I skipping these tests?

My Leopard and Tiger PPC buildbots are momentarily green! But I'm looking into why I'm skipping some tests. My buildbots are up-to-date OS-wise and very vanilla, with the latest applicable Xcode. 4 skips unexpected on darwin: test_gdb test_ioctl test_readline test_ttk_guionly Three of these

Re: [Python-Dev] OS X buildbots: why am I skipping these tests?

Guido van Rossum wrote: > On Tue, Jun 29, 2010 at 7:55 PM, Bill Janssen wrote: > > My Leopard and Tiger PPC buildbots are momentarily green!  But I'm > > looking into why I'm skipping some tests.  My buildbots are up-to-date > > OS-wise and very vanilla, w

Re: [Python-Dev] OS X buildbots: why am I skipping these tests?

Martin v. Löwis wrote: > > Seems to work fine. So this I don't understand. Any ideas, anyone? > > Didn't we discuss this before? Possibly, but I don't recall doing so. > The buildbot slave has no controlling > terminal anymore, hence it cannot open /dev/tty. If you are curious, > just patch

Re: [Python-Dev] OS X buildbots: why am I skipping these tests?

exar...@twistedmatrix.com wrote: > Could the test be rewritten (or supplemented) to use a pty? Most or > perhaps all of the same operations should be supported. Buildbot seems to be explicitly not using a PTY. From the the top of the test output: make buildbottest in dir /Users/buildbot/build

Re: [Python-Dev] OS X buildbots: why am I skipping these tests?

Martin v. Löwis wrote: > > The whole "unexpected" skipping is somewhat of a mess. In an ideal > > situation modules that are optionally built should be allowed to skip, > > While this may be the wide-spread interpretation, it is definitely *not* > the original intention of the feature. > > When

Re: [Python-Dev] Can ftp url start with file:// ?

Senthil Kumaran wrote: > On Fri, Jul 09, 2010 at 02:23:40PM +1000, Steven D'Aprano wrote: > > > Is this is valid ftp url? > > > > > > # file://ftp.example.com/blah.txt (an ftp URL) > > > > > > My answer is no. When we have the scheme specifically mentioned as > > > file:// it is no point in consi

Re: [Python-Dev] Can ftp url start with file:// ?

Tim Lesher wrote: > On Fri, Jul 9, 2010 at 12:41, Bill Janssen wrote: > > > So, FTP is *not* the "default protocol". On the other hand, if > > actually begins with "ftp.", it's a pretty good guess that FTP will > > work. > > >

Re: [Python-Dev] Removing IDLE from the standard library

Tal Einat wrote: > Although several people say that they think having IDLE in the stdlib > is important, the fact is that IDLE is considered quite unimportant by > most of the Python community. Having IDLE in the stdlib may be > convenient for a few people, but most never use it and don't care >

Re: [Python-Dev] Can ftp url start with file:// ?

Fred Drake wrote: > On Sat, Jul 10, 2010 at 11:56 PM, Senthil Kumaran wro= > te: > > I see the reason. But I doubt if this is a reliable approach. =A0Also > > when the scheme begins with file:// it should not be confused with > > ftp, so I think, that portion of code in urllib which work that wa

Re: [Python-Dev] Removing IDLE from the standard library

Stephen Hansen wrote: > On Sun, Jul 11, 2010 at 4:53 PM, Steve Holden wrote: > > > Stephen Hansen wrote: > > > On Sat, Jul 10, 2010 at 9:23 PM, Guilherme Polo > > > wrote: > > > > > > By "never had a problem" do you mean using some of the latest > > versions > > >

Re: [Python-Dev] mkdir -p in python

Michael Foord wrote: > On 20/07/2010 14:43, Nick Coghlan wrote: > > On Tue, Jul 20, 2010 at 11:09 PM, Steven D'Aprano > > wrote: > > > >> I'm -0 on adding an argument to os.makedirs, +0 on adding a variant > >> function to os, and +0.5 on adding the variant to the shutil module. > >>

Re: [Python-Dev] Python Language Summit EuroPython 2010

Tim, thanks for this write-up! Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rework nntlib?

Jesse Noller wrote: > no one seems to take the betas or alphas for serious test drives (to > be expected) with real code I wonder if there's some way to improve that situation -- perhaps by some engineering of the Python packaging, or some such? Bill

Re: [Python-Dev] Rework nntlib?

Interesting. I personally use nis and poplib quite a bit, but I can see how that would be very location-dependent. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python

[Python-Dev] PPC Leopard build slave going down for an upgrade

I'm replacing the PPC Leopard build slave with a dual 2GHz G5 machine... Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40m

[Python-Dev] the "PPC Leopard" buildbot is back online

I've finished upgrading the PPC Leopard builder to a dual 2 GHz G5 machine. Tests should run a bit faster now that the eMac is out of the loop :-). I'm looking for a faster machine for the PPC Tiger buildbot. Bill ___ Python-Dev mailing list Python-Dev

[Python-Dev] sad state of OS X Python testing...

Folks, I was looking at the buildbots again. Do you realize that we have no OS X Snow Leopard buildbot? No Intel Leopard buildbot? Well over half of Mac users are using Snow Leopard, and we're not testing on that platform. In fact, the only Intel OS X machine we're testing on is a Core Duo, not

[Python-Dev] PPC Tiger buildbot going down for an upgrade

I've found a dual-processor G4 to run the PPC Tiger buildbot on (it's currently an old e Mac), and I plan to take this buildbot down tomorrow, Wednesday, to upgrade. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.or

Re: [Python-Dev] sad state of OS X Python testing...

Sorry to drop out like that -- I've been having some email issues. Stephen, great job; thanks for providing that Snow Leopard buildbot. I think what we're missing now is an Intel Leopard buildbot. 35% of Mac users are still running Leopard. I'm running it myself on some machines, due to the NIS

[Python-Dev] PPC Tiger is back up

I've moved the OS X buildbot parc-tiger-1 (PPC Tiger) to new hardware, a MDD dual-G4 PowerMac with more memory. Should move considerably faster. Enjoy! Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/pytho

[Python-Dev] PPC Leopard buildbot failing sqlite test for Python 3.2

There was a test added to the sqlite suite between 3.1 and the current 3.x trunk, TestInTransaction. It's failing pretty consistently on the PPC Leopard buildbot (2.7 and 3.1 are testing OK). Calling sqlite3.sqlite_version returns 3.4.0. A couple of things come to mind: * Does this require a dif

Re: [Python-Dev] PPC Leopard buildbot failing sqlite test for Python 3.2

R. David Murray wrote: > On Sat, 16 Oct 2010 13:14:20 -0700, Bill Janssen wrote: > > There was a test added to the sqlite suite between 3.1 and the current > > 3.x trunk, TestInTransaction. It's failing pretty consistently on the > > PPC Leopard buildbot (

Re: [Python-Dev] Continuing 2.x

Kristján Valur Jónsson wrote: > Let's move the current 'trunk' into /branches/afterlife-27. Open it > for submissions from people such as myself that use 2.7 on a regular > basis and are willing to give it some extra love. Though I'm not personally convinced it's a good idea, I can see where so

Re: [Python-Dev] [Python-checkins] r86441 - python/branches/py3k/Lib/test/test_nntplib.py

Antoine Pitrou wrote: > On Sat, 13 Nov 2010 07:30:05 -0500 > James Y Knight wrote: > > On Nov 13, 2010, at 7:08 AM, Antoine Pitrou wrote: > > > Funny, it shows that the NNTP SSL tests don't check the certificate, > > > then. > > > > Unsurprising, given that you need 140 lines of pretty non-obvi

Re: [Python-Dev] Stable buildbots

Both the Tiger buildbots are suddenly failing 3.x on test_cmd_line. Looking at the changes since the last success, I can't see anything which would obviously affect that... Any suspects? Here's what's failing: == ERROR: test_run

Re: [Python-Dev] Stable buildbots

Ned Deily wrote: > In article <30929.1289879...@parc.com>, Bill Janssen > wrote: > > > Both the Tiger buildbots are suddenly failing 3.x on test_cmd_line. > > Looking at the changes since the last success, I can't see anything > > which would obviously

Re: [Python-Dev] Help deploying a new buildbot running OpenIndiana/x86

Jesus Cea wrote: > On 17/11/10 17:23, Antoine Pitrou wrote: > > There is no incoming connection; however, a bunch of outgoing > > connections are made to various hosts by various tests, so it's better > > if there's no overzealous firewall in-between. For those of us who can't do that, there's a

Re: [Python-Dev] constant/enum type in stdlib

Isaac Morland wrote: > On Tue, 23 Nov 2010, Antoine Pitrou wrote: > > > Le mardi 23 novembre 2010 à 12:32 -0500, Isaac Morland a écrit : > >> On Tue, 23 Nov 2010, Antoine Pitrou wrote: > >> > >>> We already have a bunch of bizarrely unrelated stuff in collections > >>> (such as Callable), so we

Re: [Python-Dev] The "lazy strings" patch

See also the Cedar Ropes work: http://www.cs.ubc.ca/local/reading/proceedings/spe91-95/spe/vol25/issue12/spe986.pdf Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.pytho

Re: [Python-Dev] Python and the Linux Standard Base (LSB)

Perhaps "pyinstall"? Bill > On Nov 30, 2006, at 9:49 AM, Talin wrote: > > > I really don't like all these "cute" names, simply because they are > > obscure. Names that only make sense once you've gotten the joke may > > be self-gratifying but not good HCI. > > Warsaw's Fifth Law :) > > > H

Re: [Python-Dev] [NPERS] Re: a feature i'd like to see in python #2: indexing of match objects

> Maybe instead of considering a match object to be a sequence, a match > object should be considered a map? After all, we do have named, as well > as numbered, groups...? To me, that makes a lot more sense. Bill ___ Python-Dev mailing list Python-Dev

Re: [Python-Dev] Trial balloon: microthreads library in stdlib

> If this sounds like a terrible idea, let fly the n00b-seeking missiles. Sounds like a good idea. We did this with ILU, and it helped manage the overhead of threads quite a bit. Brett's comments on "the next step" are right on target. Bill ___ Python

Re: [Python-Dev] Adding socket timeout to urllib2

> > Guido> Since "idel timeout" is not a commonly understood term it would > Guido> be even better if it was explained without using it. > > I think it's commonly understood, but it doesn't mean what the socket > timeout is used for. It's how long a connection can be idle (the client > d

Re: [Python-Dev] I vote to reject: Adding timeout to socket.py and httplib.py.

Guido van Rossum wrote: > > > Is it time for a sockettools module, maybe? > > > > +1! > > -1. The new module would be just as much a jumble of unrelated APIs as > the socket module already is, so there's no particularly good reason > to create an arbitrary separation. Also, KISS. I agree with Gui

Re: [Python-Dev] Using logging in the stdlib and its unit tests

Glenn Linderman wrote: > On 12/10/2010 12:06 AM, Vinay Sajip wrote: > >> > This simplistic easy usage somewhat echo's Glenn's comment on this > >> > thread > > about logging seeming way to daunting as presented today. It needn't be. > >> > > > Indeed, and the very first code sample in the lo

Re: [Python-Dev] Using logging in the stdlib and its unit tests

Guido van Rossum wrote: > And yet, I have helped many people who were baffled by exactly what > Bill observed: logging.info() didn't do anything. Maybe the default > should be INFO? Yeah, I was curious enough to read the code and find out why. But many won't. By the way, I tried reading the 2.

Re: [Python-Dev] Using logging in the stdlib and its unit tests

Glenn Linderman wrote: > 1) simple example for one file programs, include an example of > specifying output severity threshold. I'm with Antoine here on my > expectations. Yes, once I put logging.basicConfig(stream=sys.stdout, level=logging.DEBUG) in my main(), I got what I thought I'd ge

Re: [Python-Dev] PEP 3333: wsgi_string() function

P.J. Eby wrote: > Right. Also, it should be mentioned that none of this would be > necessary if we could've gotten a "bytes of a known encoding" type. Indeed! Or even "string using a known encoding"... > If you look back to the last big Python-Dev discussion on > bytes/unicode and stdlib API

Re: [Python-Dev] devguide: Cover how to (un-)apply a patch.

Steven D'Aprano wrote: > s...@pobox.com wrote: > > > I realize the world is passing me by and that I'm rapidly turning into a > > dinosaur w.r.t. distributed version control, but as you write/update the > > developer's guide remember that proficiency in Python does not necessarily > > equate to

Re: [Python-Dev] Python merge module

Martin v. Löwis wrote: > The Installer COM object is the platform standard > mechanism, and that's what msilib uses. I really see no need to move > away from that - it can create arbitrary MSI files. I've used it to package UpLib for Windows -- see http://uplib.parc.com/hg/uplib/file/e29e36f751f

Re: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py

Giampaolo Rodolà wrote: > Although I don't use it, it seems that Twisted managed to do this by > splitting the concepts of "transport" and "protocol" / "application" > and by using zope.interface. You might want to look at the ILU core, too, just for ideas. Somewhat to my surprise, the link htt

[Python-Dev] funky buildbot

I'm trying to get a new buildbot in the swim of things, and it keeps getting into this state where the buildslave process seems caught in an endless loop. Perhaps someone here knows why? It's a new Mac Mini running the latest Snow Leopard, with Python 2.6.1 (the /usr/bin/python) and buildslave 0.

Re: [Python-Dev] funky buildbot

David Bolen wrote: > Bill Janssen writes: > > > I'm trying to get a new buildbot in the swim of things, and it keeps > > getting into this state where the buildslave process seems caught in an > > endless loop. Perhaps someone here knows why? > > Do you ha

Re: [Python-Dev] funky buildbot

David Bolen wrote: > There used to be a way to request a "ping" from the master side (I > think on the same page you could manually run a build from) that I > would used to force it to recognize a slave was really down, but after > the web interface got rearranged a while back, I can't seem to fi

Re: [Python-Dev] funky buildbot

My Intel Snow Leopard buildbot failed again last night. Here's what I see in twistd.log. Any of this look familiar to some one? Failed at about 19:58 (PST?). I don't see any reason for these failures, but they seem to happen about once a week. This is the standard Snow Leopard Python 2.6.1, and

[Python-Dev] funky buildbot problems again...

My Intel Snow Leopard 2 build slave has gone into outer-space again. When I look at it, I see buildslave taking up most of a CPU (80%), and nothing much else going on. The twistd log says: [... much omitted ...] 2011-04-04 08:35:47-0700 [-] sending app-level keepalive 2011-04-04 08:45:47-0700 [-

Re: [Python-Dev] funky buildbot problems again...

Michael Foord wrote: > On 07/04/2011 21:31, Bill Janssen wrote: > > My Intel Snow Leopard 2 build slave has gone into outer-space again. > > [snip...] > > So it's been spinning its wheels for 3 days. > > > > Sure looks like the connection attempt is faili

Re: [Python-Dev] funky buildbot problems again...

exar...@twistedmatrix.com wrote: > On 08:31 pm, jans...@parc.com wrote: > >My Intel Snow Leopard 2 build slave has gone into outer-space again. > > > >When I look at it, I see buildslave taking up most of a CPU (80%), and > >nothing much else going on. The twistd log says: > > > >[... much omitte

Re: [Python-Dev] Simple XML-RPC server over SSL/TLS

Éric Araujo wrote: > Hi, > > > But what I would like to know, is if is there any reason why XML-RPC can't > > optionally work over TLS/SSL using Python's ssl module. I'll create a > > ticket, and send a patch, but I was wondering if it was a reason why this > > was not implemented. > > I think

Re: [Python-Dev] Python 3.x and bytes

Georg Brandl wrote: > We do have > > bytes.fromhex('deadbeef') Sort of reminds me of Java's Integer.parseInt(), and not in a good way. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubsc

Re: [Python-Dev] Stable buildbots update

Tarek Ziadé wrote: > Yes, I am aware of this. I have fixed today most remaining issues, and > fixing the final ones right now. Just FYI: the "AMD64 Snow Leopard" buildbot and "PPC Leopard" buildbots are now green, but the "PPC Tiger" buildbot is still failing for all branches because of packagi

Re: [Python-Dev] Stable buildbots update

Ned Deily wrote: > In article <87zkmcalt8@uwakimon.sk.tsukuba.ac.jp>, > "Stephen J. Turnbull" wrote: > > Are you saying you expect Mac OS X 10.4 "Tiger" to go green once the > > bots update? If so, I'm impressed, and "thank you!" to all involved. > > Apple and MacPorts have long since wash

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

Nick Coghlan wrote: > And no, the fact that methods can be treated as attributes is not a > minor detail. It is *fundamental* to Python's object model that > *methods are not a special case of attribute access*. All attributes > work the same way, it is just the way functions implement the > desc

[Python-Dev] Snow Leopard buildbot failing again...

I see that parc-snowleopard-1 went down again. I've done a software update, rebooted, and installed the latest buildslave, 0.8.4. I can ping dinsdale.python.org successfully from the machine. However, when I start the buildslave, I get this: $ buildslave start ~/buildarea/ /Library/Python/2.6/s

Re: [Python-Dev] Snow Leopard buildbot failing again...

exar...@twistedmatrix.com wrote: > On 05:01 pm, jans...@parc.com wrote: > >I see that parc-snowleopard-1 went down again. I've done a software > >update, rebooted, and installed the latest buildslave, 0.8.4. I can > > ping dinsdale.python.org successfully from the machine. However, > > when I >

Re: [Python-Dev] Snow Leopard buildbot failing again...

I also find interesting, because it seems a good explanation of why the build slave might go into the zombie state of attempting to reconnect to the master. Bill ___ Python-Dev mailing list Python-Dev@python.org htt

Re: [Python-Dev] Snow Leopard buildbot failing again...

Antoine Pitrou wrote: > On Mon, 27 Jun 2011 10:01:13 PDT > Bill Janssen wrote: > > I see that parc-snowleopard-1 went down again. I've done a software > > update, rebooted, and installed the latest buildslave, 0.8.4. I can > > ping dinsdale.python.org successful

Re: [Python-Dev] open(): set the default encoding to 'utf-8' in Python 3.3?

M.-A. Lemburg wrote: > How about a more radical change: have open() in Py3 default to > opening the file in binary mode, if no encoding is given (even > if the mode doesn't include 'b') ? +1. > That'll make it compatible to the Py2 world again and avoid > all the encoding guessing. Yep. Bill

Re: [Python-Dev] open(): set the default encoding to 'utf-8' in Python 3.3?

Terry Reedy wrote: > > Making such default encodings depend on the locale has already > > failed to work when we first introduced a default encoding in > > Py2, so I don't understand why we are repeating the same > > mistake again in Py3 (only in a different area). > > I do not remember any prop

Re: [Python-Dev] EuroPython Language Summit report

Michael Foord wrote: > The new regex library has some great improvements: > > http://bugs.python.org/issue2636 > > It also has users and committed maintainers, so I hope we can bring it > into 3.3. It wasn't easy to tell from skimming the change notes that > Unicode character classes are am

Re: [Python-Dev] EuroPython Language Summit report

Michael Foord wrote: > Thanks. Support for Unicode character classes was one of the > improvements needed in the re module reported from the language summit > - > so I wonder if the changes in regex are sufficient. I guess it depends on what you're asking -- what does "support for Unicode chara

Re: [Python-Dev] The docs, reloaded

> Could this be a language-independent documenting toolkit? Could > we document LISP or Ruby code with it? Might want to look at "noweb", http://www.eecs.harvard.edu/~nr/noweb/: ``...noweb works ``out of the box'' with any programming language, and supports TeX, latex, HTML, and troff back ends.

Re: [Python-Dev] The docs, reloaded

> We are developing a programming language here, not a typesetting > system. Good point, Martin. Are you implying that the documentation should be kept in LaTeX, a widely-accepted widely-disseminated stable documentation language, which someone else maintains, rather than ReST, which elements of

Re: [Python-Dev] Two spaces or one?

> Emacs will probably go the way of the vinyl record (though the latter > is seeing a resurgence lately :). Doubt it. Even as we speak, there's probably a student planning to implement Python 3 in ELisp as a SOC project... Bill ___ Python-Dev mailin

Re: [Python-Dev] Two spaces or one?

> The term "French Spacing" is used for two spaces after a period ending > a sentence, for those wishing to do more research. I have not found > any authoritative answer. This phrase sounded to me like one of the slurs the English invented during their various wars with the Dutch and the French (

Re: [Python-Dev] [Python-3000] Python 3000 Sprint @ Google

I'd really like an excuse to implement server-side SSL support one of these days. Could that be a sprint activity? Probably against 2.6 (I doubt the Modules/_ssl.c file will change much for 3K). The idea is that if you call socket.ssl() on a socket that's bound to an address, the socket is assum

Re: [Python-Dev] [Python-3000] Python 3000 Sprint @ Google

> Sounds like a good plan. I'm not a great coach though since I didn't > write _ssl.c and I've never used openssl directly. But I can help you > with the Python stuff of course! Thanks (though I think I can handle the Python end of it, too :-). It's been a while since I wrote any Python C code, t

Re: [Python-Dev] [Python-3000] Python 3000 Sprint @ Google

Barry Warsaw suggested: > > It's been a while since I wrote any Python C code, though -- are there > > better tools these days for debugging reference counting? Anyone > > know? > > No, but /that/ would make an awesome sprint topic . Indeed! Bill __

Re: [Python-Dev] [Python-3000] Python 3000 Sprint @ Google

> Maybe one of the three existing Python/SSL libraries should be stdlib- > ified instead of starting another new one from scratch? Yep, that's my intent. This should just be a change to _ssl.c. Bill ___ Python-Dev mailing list Python-Dev@python.org ht

[Python-Dev] More on server-side SSL support

> The idea is that if you call socket.ssl() on a socket that's bound to > an address, the socket is assumed to be server-side, the cert passed > in is assumed to be a server-side cert, and the SSLObject returned has > a couple of extra methods, listen() and accept(). Calling accept() does > the SS

Re: [Python-Dev] More on server-side SSL support

> I'm very tempted to add an optional parameter to socket.ssl(), which > will be a callback function which will be passed the remote side's IP > address and credentials, and which may raise an exception if it > doesn't like the credentials. The exception would then be re-raised > from socket.ssl()

Re: [Python-Dev] More on server-side SSL support

All right, here's my current design :-). We add to the socket module a subtype of socket.socket, socket.SSLSocket. It has the following constructor: SSLSocket (family=AF_INET, type=SOCK_STREAM, proto=0, cert_filename=None, key_filename=None, cert_policy=CERT_NONE, ssl

Re: [Python-Dev] More on server-side SSL support

> That's somewhat limiting - you should be able to do connection > upgrades (e.g. SMTP STARTTLS, or HTTP Connection: Upgrade); with > that design, such usages would not be possible, no? Yes, you're right. Of course, STARTTLS is properly regarded as a terrible hack :-). The actual functionality e

Re: [Python-Dev] More on server-side SSL support

> I view TLS as a wrapper around / layer on top of TCP, and so I think the > API should look like, as well. I think Martin raises a valid point here, which should at least be discussed more thoroughly. Should there be an "SSL socket", which is just like a regular socket? Does that really provide

Re: [Python-Dev] More on server-side SSL support

> * Allow certificate validation. This is a bit tricky; typically > certs are validated against some database of root certificates, so you > need a whole infrastructure to maintain that database. Currently, we > don't have one, so no certs can be validated. We could add a switc

Re: [Python-Dev] More on server-side SSL support

> > The simplest way to do verification is to allow the application to > > provide a set of root certs that it would like to verify against, and > > use the built-in OpenSSL verification procedure. > > That's good. I don't recall whether you planned for this, however, > it would then be necessary

Re: [Python-Dev] More on server-side SSL support

> This is a self-signed cert, and it's still an open question whether > they should verify, and under what circumstances. I'm currently > thinking that in the CERT_OPTIONAL regime, they could, but with > CERT_REQUIRED, they shouldn't. If an application wanted self-signed certs to verify under CER

Re: [Python-Dev] More on server-side SSL support

> Should there be an "SSL socket", which is > just like a regular socket? Does that really provide any additional > functionality to anyone? Most apps and classes that use TCP sockets > wrap the socket with socket._fileobject() to get "read" and "write", > anyway -- can't they just wrap it with s

Re: [Python-Dev] More on server-side SSL support

> Can the TLS handshake be made to respect timeouts on sockets, or would > this require changes deep inside OpenSSL? I'm not sure. Good test case to try. I believe it will work. By the way, interested parties should read http://www.openssl.org/docs/ssl/SSL_CTX_set_options.html and think about

[Python-Dev] backport new server-side SSL to older Pythons?

I'd like to be able to backport this server-side SSL support to older Pythons, like the 2.3.4 in CentOS 4 and the 2.3.5 in OS X 10.4. So I'd like to move all the SSL stuff out of the "socket" module, and add a new top-level module called "ssl" (or "networking.ssl", or whatever the Py3K naming sche

Re: [Python-Dev] backport new server-side SSL to older Pythons?

> > I'd like to be able to backport this server-side SSL support to older > > Pythons, like the 2.3.4 in CentOS 4 and the 2.3.5 in OS X 10.4. > > That would have to be a private fork or a 3rd party extension module; > python.org is committed to keeping existing releases stable > (feature-wise). Y

Re: [Python-Dev] More on server-side SSL support

> getpeercert() -- analogue to "getpeeraddr", but returns cert details This would return three kinds of values: No certificate received --> None Certificate received but not validated --> {} Certificate received and validated --> { full details } Bill __

Re: [Python-Dev] More on server-side SSL support

For those of you following along at home, there's now a patch at http://bill.janssen.org/python/ssl-update-diff which applies against the current trunk. Working code, though I still need to tweak some import statements for backwards compatibility. I've started updating the test suite, see Lib/tes

[Python-Dev] new bug tracker broken?

I've been trying to reset my password on the new RoundUp tracker, and it isn't working. Then I tried to register for a new account, and I got mail from [EMAIL PROTECTED] to confirm. When I did, I got access to a small 27-issue tracker, which seems to be the bug-tracker for the bug-tracker.

[Python-Dev] issue 1024 contains documentation patch for SSL work

I've created the documentation patch for the new SSL module. It's attached to issue 1024. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/pyth

[Python-Dev] Other SSL issues in the tracker have been marked

I've gone through the other open SSL issues. Looks like some can be closed with the adoption of 1018 and 1024: 1027394 4 months agosocket.ssl should explain that it is a 2/3 connection 889813 4 months agomaking the version of SSL configurable when creating sockets 1583946 9 months ago

Re: [Python-Dev] Other SSL issues in the tracker have been marked

> This occurs on at least 3 of the buildbots (ubuntu and debian on ia64, > ppc, and hppa). Here's one example: Unfortunately, I don't have Ubuntu or Debian machines. But I'd bet it's a variation in the specific version of OpenSSL being used. I just tested on Fedora Core 7, though, and test_ssl

Re: [Python-Dev] Other SSL issues in the tracker have been marked

> This occurs on at least 3 of the buildbots (ubuntu and debian on ia64, > ppc, and hppa). Here's one example: > > http://python.org/dev/buildbot/all/ia64%20Ubuntu%20trunk%20trunk/builds/832/step-test/0 If I'm reading this right, it's passing tests on "amd64 gentoo trunk", "x86 gentoo trunk", "g

Re: [Python-Dev] Other SSL issues in the tracker have been marked

> But I think this exposes a more generic bug in test_ssl.py, which is > that the server thread doesn't die when one of these failures occurs. > It probably should. I'll make a patch -- but I don't have a system > that this fails on, how will I test it? Here's a patch which makes test_ssl a bette

Re: [Python-Dev] Other SSL issues in the tracker have been marked

> Yeah, I know this is difficult. Hopefully someone with WIndows will > step up to help. We can at least make the test more robust and verify > the files exist and are non-zero in size. I will do that now. At > least the it shouldn't cause the test to time out. Yes, the patch I sent out should

Re: [Python-Dev] Other SSL issues in the tracker have been marked

Well, as long as you have your ears on, here's another patch to test_ssl. 1) Fixes the bug that two class names are initial-lower-case. 2) Replaces the poll waiting for the server to become ready with a threading.Event signal. Bill Index: Lib/test/test_ssl.py =

Re: [Python-Dev] Other SSL issues in the tracker have been marked

> Traceback (most recent call last): > File "/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/threading.py", > line 486, in __bootstrap_inner > self.run() > File > "/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/test/test_ssl.py", > line 144, in run > cert_reqs=self.ser

Re: [Python-Dev] Other SSL issues in the tracker have been marked

Now it looks as if both the Debian and Ubuntu failures are failing because they can't create a certificate, just like the Windows test. I'll go out on a limb here and guess that it's because "openssl" isn't on the path of the user running the tests. That would also account for the other stack trac

Re: [Python-Dev] Other SSL issues in the tracker have been marked

Here's a patch that will turn the buildbots green, by not trying the connected tests if the certificate can't be created. It also shows the created cert if run in verbose mode. We still need a working os.system command for Windows. Bill Index: Lib/test/test_ssl.py =

Re: [Python-Dev] Other SSL issues in the tracker have been marked

> apt-get install openssl will fix that on those systems. on windows you're > unlikely to ever have an openssl binary present and available to execute. Well, if you have OpenSSL in the first place, you'll have the binary, won't you? But I agree it's unlikely to be on your path. As for Ubuntu a

<    1   2   3   4   5   6   >