Re: [Python-Dev] [Python-3000] Universal newlines support in Python 3.0

[Adam Hupp]

On Tue, Aug 14, 2007 at 09:58:32AM -0400, Barry Warsaw wrote:
> This was all fine except that some of the tests started  
> failing because of the EOL translation that happens unconditionally  
> now.   The file contained \r\n and the test was ensuring these EOLs  
> were preserved in the parsed text.  I switched back to opening the  
> file in binary mode, and doing a crufty conversion of bytes to  
> strings (which I suspect is error prone but gets me farther along).
> 
> It would have been perfect, I think, if I could have opened the file  
> in text mode so that read() gave me strings, with universal newlines  
> and preservation of line endings (i.e. no translation to \n).

FWIW this same issue (and solution) came up while fixing the csv
tests.

-- 
Adam Hupp | http://hupp.org/adam/

___
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] Planning to switch to new tracker on August 23rd

[Brett Cannon]

Having squashed the final issues, we are now ready to switch over to
the new tracker!  The plan is to do it on the 23rd.  But before I
announce to the community I wanted to make sure there was not some
specific objection by python-dev or python-3000.  If there is please
let me know by midday Monday so that we can postpone to next week if
needed.

-Brett
___
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] Email addresses in PEPs?

[skip]

Is there a policy about putting email addresses in PEPs?  I have the names
and email addresses of a couple platform maintainers to add to PEP 11.
Having the email addresses there would make it handy to contact said
maintainers, but I realize people don't always appreciate the extra exposure
to spammers.

Skip

___
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] More on server-side SSL support

[Bill Janssen]

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_protocol=PROTOCOL_SSLv23)

where the options for "cert_policy" are:

  CERT_NONE -- no certificates will be required or verified
  CERT_OPTIONAL -- cert not required from peer, but if provided is verified
  CERT_REQUIRED -- verifiable cert required from peer

and the options for "ssl_protocol" are:

  PROTOCOL_SSLv2
  PROTOCOL_SSLv3
  PROTOCOL_SSLv23
  PROTOCOL_TLSv1

The "cert_filename" is optional for clients, required for servers; the
"key_filename" can be used to specify another file where the private key
for the certificate is stored, otherwise the key is presumed to be in
the cert file along with the certificate (or certicates; the cert file
may contain a chain of certificates).

In use, the application creates an "SSLSocket" instead of a regular
"socket" if it wishes to use SSL.  If it's client-side, when the
"connect" call is made on the socket, the SSL handshake is performed,
and subsequent reads from and writes to the socket are delegated to
the SSLObject that's returned from the handshake.  If it's
server-side, when the "accept" call is made, the socket returned is
another SSLSocket with the SSLObject already set, so that writes and
reads are processed via the SSLObject.  Actually, "recv", "recvinto",
"send" and "sendall" are the methods delegated; "recv_from" and
"send_to" raise exceptions (and I think using any flags on the other
methods should also raise exceptions).

An instance of SSLSocket will have a method called "getpeercert",
which will return either None, if the socket is not connected, or a
dict containing pertinent fields of the peer's certificate; empty if
the peer did not provide a cert or if the CERT_NONE option was
specified, or filled with fields like "subject", "issuer", etc. if it
did and the cert was verified.  (What fields, exactly?  Seems to me
that it should have subject, issuer, good_after, good_until, but what
else?)

The existing use of "socket.ssl" will continue to work, for backwards
compatibility.

This design should allow SSLSocket to be used in all the various
places where a regular socket is currently used, such as
SimpleHTTPServer, with only a few tweaks.  For instance, here's an SSL
version of TCPServer:

class MySSLTCPServer (TCPServer):

def __init__(self, server_address, RequestHandlerClass, certfile,
 bind_and_activate=True):
"""Constructor.  May be extended, do not override."""
BaseServer.__init__(self, server_address, RequestHandlerClass)
self.socket = socket.SSLSocket(self.address_family,
   self.socket_type,
   certfile=certfile)
if bind_and_activate:
self.server_bind()
self.server_activate()

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] More on server-side SSL support

[Martin v. Löwis]

> 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_protocol=PROTOCOL_SSLv23)

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?

Regards,
Martin
___
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] More on server-side SSL support

[Bill Janssen]

> 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 exported from _ssl.c is still the "ssl"
wrapper, but with more arguments to control its behavior.  So to do
STARTTLS, server-side, you'd do something like

  mooring = socket.socket()
  mooring.bind()
  mooring.listen()
  [... connection request comes in ...]
  fd = mooring.accept() # normal socket
  [... read request for TLS upgrade over socket ...]
  sslobj = socket.ssl(fd, ..., server=True)
  fd = socket.SSLSocket(..., ssl_protocol=PROTOCOL_TLSv1, _sock=fd, 
_sslobj=sslobj)

and continue on with normal use of the socket.  Do you see an easier
way to do it?

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] More on server-side SSL support

[Martin v. Löwis]

> Yes, you're right.  Of course, STARTTLS is properly regarded as a
> terrible hack :-).

I know you mean that jokingly - but I think it is considered as the
*proper* usage of TLS, with all these "let's use a different well-known
port for TLS over X" being those protocols that are hacks. I believe
it's official IETF policy (although I can't find the RFC right now)
that future protocols should prefer connection upgrades for TLS over
introducing separate protocols.

> The actual functionality exported from _ssl.c is still the "ssl"
> wrapper, but with more arguments to control its behavior.  So to do
> STARTTLS, server-side, you'd do something like
> 
>   mooring = socket.socket()
>   mooring.bind()
>   mooring.listen()
>   [... connection request comes in ...]
>   fd = mooring.accept()   # normal socket
>   [... read request for TLS upgrade over socket ...]
>   sslobj = socket.ssl(fd, ..., server=True)
>   fd = socket.SSLSocket(..., ssl_protocol=PROTOCOL_TLSv1, _sock=fd, 
> _sslobj=sslobj)
> 
> and continue on with normal use of the socket.  Do you see an easier
> way to do it?

If you have use cases where you need to pass _sock, anyway, why not
always require a wrapper object (i.e. not support the family/type/proto
arguments). I think there are also cases where you need to set socket
options on the "raw" socket.

I view TLS as a wrapper around / layer on top of TCP, and so I think the
API should look like, as well.

Whatever you design, it will either be complicated to use or
insufficient in reasonable use cases.

Regards,
Martin
___
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] Email addresses in PEPs?

[Guido van Rossum]

Ask the people involved if they're okay with "user at host dot com"
obfuscation. That's used in a few places already (e.g. PEP 0).

On 8/20/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Is there a policy about putting email addresses in PEPs?  I have the names
> and email addresses of a couple platform maintainers to add to PEP 11.
> Having the email addresses there would make it handy to contact said
> maintainers, but I realize people don't always appreciate the extra exposure
> to spammers.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Segfault

[Maciej Fijalkowski]

IMHO this shouldn't segfault:

import thread

while 1:
f = open("/tmp/dupa", "w")
thread.start_new_thread(f.close, ())
f.close()

while it does on cpython 2.5.1, linux box.

May I consider this a bug?
___
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] Email addresses in PEPs?

[Brett Cannon]

On 8/20/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Ask the people involved if they're okay with "user at host dot com"
> obfuscation. That's used in a few places already (e.g. PEP 0).
>

I believe email addresses are automatically obfuscated as part of the
HTML generation process, but one of the PEP editors can correct me if
I am wrong.

-Brett


> On 8/20/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Is there a policy about putting email addresses in PEPs?  I have the names
> > and email addresses of a couple platform maintainers to add to PEP 11.
> > Having the email addresses there would make it handy to contact said
> > maintainers, but I realize people don't always appreciate the extra exposure
> > to spammers.
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> ___
> 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/brett%40python.org
>
___
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] [PEPs] Email addresses in PEPs?

[David Goodger]

On 8/20/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> I believe email addresses are automatically obfuscated as part of the
> HTML generation process, but one of the PEP editors can correct me if
> I am wrong.

Yes, email addresses are obfuscated in PEPs.

For example, in PEPs 0 & 12, my address is encoded as
"goodger at python.org" (the "@" is changed to " at " and
further obfuscated from there).  More tricks could be played, but that
would only decrease the usefulness of addresses for legitimate
purposes.

Spam is a fact of life.  People just have to deal with it.

-- 
David Goodger 
___
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] More on server-side SSL support

[Bill Janssen]

> 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 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 socket.ssl instead?

Perhaps in the sprint, I should just concentrate on widening the
"socket.ssl" interface a bit, and improving the functionality of the
SSLObject a bit.

Suggested improvements:

  *  Allow server-side operation.

  *  Allow specification of particular SSL protocol version.

  *  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 switch
 to allow auto-validation of self-signed certs pretty easily.  I could
 add a parameter to the SSLObject constructor which would be a filepath
 for a file full of root certs (see SSL_CTX_load_verify_locations(3ssl)).

  *  Add a method to retrieve the other side's certificate info.  What's
 a good format for the "notBefore" and "notAfter" dates?  The simplest
 thing to use is the string formatting OpenSSL provides, which is
 always like "Sep 29 16:38:04 2006 GMT", which can easily be parsed
 by the time.strptime() function if the user wants something else.
 On the other hand, figuring out how to use strptime() is always a
 pain, so providing a convenience function wouldn't be a terrible idea.

  *  Add a shutdown() method to stop using SSL on the underlying socket
 without closing the socket.

  *  Make SSLObject conform to the Raw I/O API in PEP 3116.  This one is
 interesting; what should close() do?  Close the underlying socket?  Or
 just do an SSL shutdown?

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] Cannot build new documentation

[Amaury Forgeot d'Arc]

Hello,

The new documentation system is really a major improvement: congratulations!

However, I run into a problem while trying to build the new python docs.
I initially used python2.5 on windows, but Linux seems to have the same problem.
Am I really the only one who gets this error?

The offending code is in Doc\tools\sphinx\builder.py, and looks like this:

>>> from __future__ import with_statement
>>> import codecs
>>> with codecs.open('foo.txt', 'w', 'utf-8') as fp:
... print type(fp), fp
... fp.write(u"\xb6")
...
 
Traceback (most recent call last):
  File "", line 3, in 
UnicodeEncodeError: 'ascii' codec can't encode character u'\xb6' in
position 0: ordinal not in range(128)

Where does the 'ascii' codec come from? I propose the following explanation:

- codecs.open returns a wrapped stream (a codec.StreamReaderWriter).
This object implements some methods (read, write...) and delegates the
others to the underlying file object.
- 'with .. as ..' calls the __enter__ method, and assigns the result to fp.
- but StreamReaderWriter does not define __enter__, so file.__enter__
is called instead
and fp actually references the underlying file!

An obvious workaround is to add the __enter__ method to StreamReaderWriter:
def __enter__(self):
return self
This is not perfect though, because one may want to wrap say a
socket.makefile instead of a file.

It seems like the delegation pattern does not mix well with context managers...
Is there another solution?
Or did I miss something obvious?

-- 
Amaury Forgeot d'Arc
___
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] Cannot build new documentation

[Martin v. Löwis]

> However, I run into a problem while trying to build the new python docs.
> I initially used python2.5 on windows, but Linux seems to have the same 
> problem.
> Am I really the only one who gets this error?

Not sure - but it works fine for me.

 from __future__ import with_statement
 import codecs
 with codecs.open('foo.txt', 'w', 'utf-8') as fp:
> ... print type(fp), fp
> ... fp.write(u"\xb6")
> ...
>  

That is surprising. Are you sure codecs.open is what it should be
on your system? I get

 

> Where does the 'ascii' codec come from? I propose the following explanation:
> 
> - codecs.open returns a wrapped stream (a codec.StreamReaderWriter).
> This object implements some methods (read, write...) and delegates the
> others to the underlying file object.
> - 'with .. as ..' calls the __enter__ method, and assigns the result to fp.
> - but StreamReaderWriter does not define __enter__, so file.__enter__
> is called instead
> and fp actually refrences the underlying file!

Good explanation. I'm using Python 2.5.1, and this may be relevant:


r52518 | georg.brandl | 2006-10-29 09:39:27 +0100 (So, 29 Okt 2006) | 4
lines

Fix codecs.EncodedFile which did not use file_encoding in 2.5.0, and
fix all codecs file wrappers to work correctly with the "with"
statement (bug #1586513).
 (backport from rev. 52517)

> It seems like the delegation pattern does not mix well with context 
> managers...
> Is there another solution?
> Or did I miss something obvious?

I think the obvious thing you missed is that the problem got fixed
already. Whether the documentation system should be more defensive and
work with 2.5.0 also is a different question.

Regards,
Martin
___
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] Cannot build new documentation

[Amaury Forgeot d'Arc]

Hello,

Martin v. Löwis wrote:
> I think the obvious thing you missed is that the problem got fixed
> already. Whether the documentation system should be more defensive and
> work with 2.5.0 also is a different question.

You are right. python 2.5.1 corrected this.
May I still dare propose the following patch:

Index: Doc/tools/sphinx-build.py
===
--- Doc/tools/sphinx-build.py   (revision 57158)
+++ Doc/tools/sphinx-build.py   (working copy)
@@ -11,9 +11,9 @@

 if __name__ == '__main__':

-if sys.version_info[:3] < (2, 5, 0):
+if sys.version_info[:3] < (2, 5, 1):
 print >>sys.stderr, """\
-Error: Sphinx needs to be executed with Python 2.5 or newer.
+Error: Sphinx needs to be executed with Python 2.5.1 or newer.
 (If you run this from the Makefile, you can set the PYTHON variable
 to the path of an alternative interpreter executable.)
 """

--
Amaury Forgeot d'Arc
___
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] Cygwin: Problem detecting subprocess termination after _spawn_posix in distutils?

[Steve Holden]

Steve Holden wrote:
> Martin v. Löwis wrote:
>>> The only environment variables that don't appear in the shell output 
>>> from the env command are INFOPATH, MAKE_MODE and PLAT. I am still flummoxed.
>> At this point, I'd recommend to perform a cygwin update; with Cygwin,
>> these problems often go away with an update.
>>
> I updated Cygwin and did a rebaseall before posting.
> 
>> If that doesn't help, you can ask on the Cygwin list also; to analyse
>> this further, ISTM one will need to debug the internals of cygwin.
>>
> I posted on Cygwin before asking here.
> 
>> One thing you could try is to add -v to the list of gcc options;
>> you can then see whether gcc is progressing correctly.
>>
> I'll do that, though I have reason to believe the gcc *is* terminating 
> and _spawn_posix isn't detecting the end of the process. At the very 
> least we should get another test out of this dreadfully irritating bug.
> 
> Thanks again for looking at this.
> 
A further data point (sorry, I've not had a lot of time to look at 
this). Building Python from the trunk at rev 57076 yielded a system that 
*would* cleanly build the same release of PIL. This is somewhat annoying 
because it appears to put the bug in the past where there's less 
incentive to investigate it. But I may find time to take a look.

Hardly worth it if I'm the only one noticing the issue, though.

regards
  Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd   http://www.holdenweb.com
Skype: holdenweb  http://del.icio.us/steve.holden
--- Asciimercial --
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
--- Thank You for Reading -

___
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] More on server-side SSL support

[Bill Janssen]

>   *  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 switch
>  to allow auto-validation of self-signed certs pretty easily.  I could
>  add a parameter to the SSLObject constructor which would be a filepath
>  for a file full of root certs (see SSL_CTX_load_verify_locations(3ssl)).

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.

The OpenSSL CAcerts file format is just a number of certificates
concatenated together, separated by text headers that identify the
boundary:

-BEGIN CERTIFICATE-
 ... (CA certificate in base64 encoding) ...
-END CERTIFICATE-
-BEGIN CERTIFICATE-
 ... (another CA certificate in base64 encoding) ...
-END CERTIFICATE-
 ...

I suggest we just use that.  Applications which want something fancier
are free to implement something :-).

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

[Andrew Bennetts]

Maciej Fijalkowski wrote:
> IMHO this shouldn't segfault:
> 
> import thread
> 
> while 1:
> f = open("/tmp/dupa", "w")
> thread.start_new_thread(f.close, ())
> f.close()
> 
> while it does on cpython 2.5.1 , linux box.
> 
> May I consider this a bug?

Yes, that's a bug.  Please file it at
http://sourceforge.net/bugs/?group_id=5470.

-Andrew.

___
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] How to interpret get_code from PEP 302?

[Brett Cannon]

PEP 302 ("New Import Hooks") has an optional extensions section so
that tools like py2exe and py2app have an easier time.  Part of the
optional extensions is the method get_code that is to return the code
object for the specified method (if the loader can handle it).

But there is a lack in the definition of how get_code is supposed to
be implemented.  The definition says that the "method should return
the code object associated with the module", which is fine.  But then
it goes on to state that "If the loader doesn't have the code object
but it _does_ have the source code, it should return the compiled
source code".  This throws me as this makes it sound like bytecode
does not need to be used if the loader does not already have a code
object and there is no source to be had; any bytecode can be ignored.

Now I doubt this is how it is supposed to be read.  Does anyone
disagree with that?  If not, I will change the wording to mention that
bytecode must be used if no source is available (and that the magic
number must be verified).

-Brett
___
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] How to interpret get_code from PEP 302?

[Guido van Rossum]

On 8/20/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> PEP 302 ("New Import Hooks") has an optional extensions section so
> that tools like py2exe and py2app have an easier time.  Part of the
> optional extensions is the method get_code that is to return the code
> object for the specified method (if the loader can handle it).
>
> But there is a lack in the definition of how get_code is supposed to
> be implemented.  The definition says that the "method should return
> the code object associated with the module", which is fine.  But then
> it goes on to state that "If the loader doesn't have the code object
> but it _does_ have the source code, it should return the compiled
> source code".  This throws me as this makes it sound like bytecode
> does not need to be used if the loader does not already have a code
> object and there is no source to be had; any bytecode can be ignored.
>
> Now I doubt this is how it is supposed to be read.  Does anyone
> disagree with that?  If not, I will change the wording to mention that
> bytecode must be used if no source is available (and that the magic
> number must be verified).

The only reading that makes sense is that it should always return a
code object (i.e. always byte code) and thet it can either get the
byte code by unmarshaling the equivalent of a .pyc file (after
skipping the first 8 bytes) *or* by calling compile() on the source
code. So, in the specific case of a zip file, it should first look for
a .pyc file, and then for a .py file. This is the opposite of how
things work on the filesystem, where it first looks for a .py, and
then for a .pyc; if both exist, the .pyc is only used if its mtime
matches the timestamp in the .pyc header. (But why am I explaining
this to you? :-) The idea for zip files is that quick loading is
preferred, and that the source is only used if no .pyc is found at all
(or whatever convention is used). This makes it easier to have a zip
that contains both .py and .pyc files -- the .py files are only used
for reference (e.g. one could imagine using them for tracebacks).

But maybe I'm missing a subtlety in your description of the issue?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Cannot build new documentation

[Georg Brandl]

Amaury Forgeot d'Arc schrieb:
> Hello,
> 
> Martin v. Löwis wrote:
>> I think the obvious thing you missed is that the problem got fixed
>> already. Whether the documentation system should be more defensive and
>> work with 2.5.0 also is a different question.
> 
> You are right. python 2.5.1 corrected this.
> May I still dare propose the following patch:
> 
> Index: Doc/tools/sphinx-build.py
> ===
> --- Doc/tools/sphinx-build.py   (revision 57158)
> +++ Doc/tools/sphinx-build.py   (working copy)
> @@ -11,9 +11,9 @@
> 
>  if __name__ == '__main__':
> 
> -if sys.version_info[:3] < (2, 5, 0):
> +if sys.version_info[:3] < (2, 5, 1):
>  print >>sys.stderr, """\
> -Error: Sphinx needs to be executed with Python 2.5 or newer.
> +Error: Sphinx needs to be executed with Python 2.5.1 or newer.
>  (If you run this from the Makefile, you can set the PYTHON variable
>  to the path of an alternative interpreter executable.)
>  """

Yes, this is reasonable.

Georg


-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] More on server-side SSL support

[Martin v. Löwis]

> 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 to find out who the authenticated user
is, to do authorization. Getting that as a pair (client dn, issuer dn)
is the interface that springs to mind first.

Regards,
Martin
___
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