Re: [Python-Dev] [Python-3000] Documentation switch imminent

[Thomas Wouters]

On 8/14/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
>
> Now that the converted documentation is fairly bug-free, I want to
> make the switch.


One thing I miss (and I haven't followed the discussions about the new
layout at all, so I don't know if it came up already) is section numbers. I
very often refer people to "Section 4.7 of the tutorial at
docs.python.org/tut" or "Appendix B of the tutorial" or "Section 3.6.2 of
the library reference", which the new layout doesn't exactly permit. I also
think the index and section headers are less clear, more chaotic, without
the numbering. Any chance we can get something like it back? :)

-- 
Thomas Wouters <[EMAIL PROTECTED]>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
___
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

[Hrvoje Nikšić]

On Mon, 2007-08-20 at 20:27 +0200, Maciej Fijalkowski wrote:
> import thread
> 
> while 1:
> f = open("/tmp/dupa", "w")
> thread.start_new_thread(f.close, ())
> f.close()

file_close inadvertently allows fclose to be called twice on the same
stdio file.  This patch should fix the problem:

Python-2.5.1/Objects/fileobject.c
--- Python-2.5.1.orig/Objects/fileobject.c  2007-01-23 14:54:30.0 
+0100
+++ Python-2.5.1/Objects/fileobject.c   2007-08-21 10:04:18.0 +0200
@@ -440,13 +440,14 @@
 {
int sts = 0;
if (f->f_fp != NULL) {
+   FILE *fp = f->f_fp;
+   f->f_fp = NULL;
if (f->f_close != NULL) {
Py_BEGIN_ALLOW_THREADS
errno = 0;
-   sts = (*f->f_close)(f->f_fp);
+   sts = (*f->f_close)(fp);
Py_END_ALLOW_THREADS
}
-   f->f_fp = NULL;
}
PyMem_Free(f->f_setbuf);
f->f_setbuf = NULL;


___
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

[Ronald Oussoren]

Please create a patch for this in the tracker to ensure that this patch doesn't 
get lost.

Ronald
 
On Tuesday, August 21, 2007, at 10:47AM, "Hrvoje Nik?i?" <[EMAIL PROTECTED]> 
wrote:
>On Mon, 2007-08-20 at 20:27 +0200, Maciej Fijalkowski wrote:
>> import thread
>> 
>> while 1:
>> f = open("/tmp/dupa", "w")
>> thread.start_new_thread(f.close, ())
>> f.close()
>
>file_close inadvertently allows fclose to be called twice on the same
>stdio file.  This patch should fix the problem:
>
>Python-2.5.1/Objects/fileobject.c
>--- Python-2.5.1.orig/Objects/fileobject.c 2007-01-23 14:54:30.0 
>+0100
>+++ Python-2.5.1/Objects/fileobject.c  2007-08-21 10:04:18.0 +0200
>@@ -440,13 +440,14 @@
> {
>   int sts = 0;
>   if (f->f_fp != NULL) {
>+  FILE *fp = f->f_fp;
>+  f->f_fp = NULL;
>   if (f->f_close != NULL) {
>   Py_BEGIN_ALLOW_THREADS
>   errno = 0;
>-  sts = (*f->f_close)(f->f_fp);
>+  sts = (*f->f_close)(fp);
>   Py_END_ALLOW_THREADS
>   }
>-  f->f_fp = NULL;
>   }
>   PyMem_Free(f->f_setbuf);
>   f->f_setbuf = NULL;
>
>
>___
>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/ronaldoussoren%40mac.com
>
>
___
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?

[Paul Moore]

On 21/08/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).

Hmm, yes, that's muddled. Maybe it made sense to me when I wrote it
:-) (I think it was my wording rather than Just's)

get_code must *always* return the same code object that
loader.load_module is using - whether that be bytecode or compiled
source (and it must respect things like file timestamps where
appropriate just like load_module does). What the sentence you quote
is trying to say is that if there's a need to compile source, the
get_code method must do this on behalf of the caller - it can't return
None and expect the caller to try get_source and compile it manually.
Someone who only wants a code object should never need to call
get_source.

I'm not sure that's any clearer! If you need further clarification,
let me know (either on or off list). I'd appreciate it if you can
clear the PEP's wording up.

Paul.
___
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] RFC - proposal for urilib. unified module of urlparse, urllib and urllib2

[Facundo Batista]

2007/8/19, O.R.Senthil Kumaran <[EMAIL PROTECTED]>:

> I am drafting a PEP proposing a module 'urilib', which will be the unified 
> module of urlparse, urllib and urllib2.

Great!!


> a) _all_ functions will include from urlparse,urllib and urllib2.
> b) overlapping functionality between urllib and urllib2 to be ironed out.
> c) RFC3986 and RFC3987 compliant.

Seems good to me. Maybe something from cgi? I always use
cgi.parse_qs() when using urrlib2... Something about this arised in
other thread...


> I would like to know your thoughts on
> - How should we plan to maintain the backward compatiblity?
> - What other features should be kept in mind while designing?

First of all you should draft the PEP, send it here, and put it
somewhere in the web. Then the community could help you to shape it
and get a final proposal.

If too many problems regardgin compatibility arises, you always can
implement it in Py3k...

Regards,

-- 
.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
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] [Python-3000] Documentation switch imminent

[Paul Moore]

On 21/08/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>
>
> On 8/14/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> > Now that the converted documentation is fairly bug-free, I want to
> > make the switch.
>
> One thing I miss (and I haven't followed the discussions about the new
> layout at all, so I don't know if it came up already) is section numbers.

On a partly related note, I am assuming that the Windows Python
installer will come with the documentation in .chm (HTML Help) format,
as previously. It would be nice to see a preview version of this, as
I'm not 100% clear how the new section layout maps into the HTML Help
contents pane (as a specific example, the new "Built In Types" section
of the library reference is a single page - does this imply that the
HTML help won't have any subsections? I often use the HTML Help
contents pane to drill all the way down to (for example) section 3.6.1
"String Methods" and click to get directly to that section.

Paul.
___
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] [Python-3000] Documentation switch imminent

[Georg Brandl]

Paul Moore schrieb:
> On 21/08/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>>
>>
>> On 8/14/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> > Now that the converted documentation is fairly bug-free, I want to
>> > make the switch.
>>
>> One thing I miss (and I haven't followed the discussions about the new
>> layout at all, so I don't know if it came up already) is section numbers.
> 
> On a partly related note, I am assuming that the Windows Python
> installer will come with the documentation in .chm (HTML Help) format,
> as previously. It would be nice to see a preview version of this, as
> I'm not 100% clear how the new section layout maps into the HTML Help
> contents pane (as a specific example, the new "Built In Types" section
> of the library reference is a single page - does this imply that the
> HTML help won't have any subsections? I often use the HTML Help
> contents pane to drill all the way down to (for example) section 3.6.1
> "String Methods" and click to get directly to that section.

I wasn't sure how I had implemented the contents pane, so I've now created
a HTML help version ("make htmlhelp" in python/Doc already does that;
you only need to run HTML Help Workshop over it), and the "String Methods"
indeed have their own contents tree item.

I put the CHM at , if you want
to have a look.

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] [Python-3000] Documentation switch imminent

[Georg Brandl]

Thomas Wouters schrieb:
> 
> 
> On 8/14/07, *Georg Brandl* <[EMAIL PROTECTED] >
> wrote:
> 
> Now that the converted documentation is fairly bug-free, I want to
> make the switch.
> 
> 
> One thing I miss (and I haven't followed the discussions about the new
> layout at all, so I don't know if it came up already) is section
> numbers. I very often refer people to "Section 4.7 of the tutorial at
> docs.python.org/tut " or "Appendix B of the
> tutorial" or "Section 3.6.2 of the library reference", which the new
> layout doesn't exactly permit. I also think the index and section
> headers are less clear, more chaotic, without the numbering. Any chance
> we can get something like it back? :)

You're right, it can be helpful. I'll look into it, how much work it
probably would be.

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] [Python-3000] Documentation switch imminent

[Benji York]

Georg Brandl wrote:
> I put the CHM at , if you want
> to have a look.

Generally looks good.  I did get this error when opening the CHM:

"""
A Runtime Error has occurred.
Do you with to Debug?

Line: 236
Error: Expected identifier, string or number
"""

Nothing happened when I clicked "Yes".  The error is repeated each time 
a new page is opened.

An additional opinion:  The red, appear-on-hover permalink markers don't 
make much sense in a CHM and are somewhat distracting.  Can those be 
hidden, perhaps via CSS?
-- 
Benji York
http://benjiyork.com
___
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] [Python-3000] Documentation switch imminent

[Georg Brandl]

Benji York schrieb:
> Georg Brandl wrote:
>> I put the CHM at , if you want
>> to have a look.
> 
> Generally looks good.  I did get this error when opening the CHM:
> 
> """
> A Runtime Error has occurred.
> Do you with to Debug?
> 
> Line: 236
> Error: Expected identifier, string or number
> """
> 
> Nothing happened when I clicked "Yes".  The error is repeated each time 
> a new page is opened.

Having the JS in the CHM makes no sense anyway, I'll just leave it out.

> An additional opinion:  The red, appear-on-hover permalink markers don't 
> make much sense in a CHM and are somewhat distracting.  Can those be 
> hidden, perhaps via CSS?

Sure.

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

[Nick Coghlan]

Brett Cannon 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.

It also goes on to say *why* this requirement is there:
"(This is so that our caller doesn't also need to check get_source()
  if all it needs is the code object.)"

In terms of *what* get_code() returns, all it needs to do is accurately 
reflect what load_module() actually runs, but it may not be the exact 
same code object (e.g. if the code object isn't cached anywhere by the 
loader, then it will be recreated anew for each call to get_code() or 
load_module()).

> 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 magic number belongs to the pyc file, not the code object. It's up 
to the loader to do whatever checking is needed to decide whether or not 
the code object is sane for the current environment (and it makes no 
difference whether this is done for get_code() or for an actual 
load_module() call).

If load_module() would use some cached bytecode (e.g. a pyc file) in 
preference to recompiling from source (e.g. a py file), then get_code() 
should do the same thing. On the other hand, if load_module() has a 
means for detecting stale bytecode and will recompile in that case, then 
the same check is also needed in get_code().

The important thing is for load_module() and get_code() to be consistent 
  - beyond that, there are no requirements regarding how the source and 
bytecode are stored externally (if they're stored at all). For example, 
you could write a perfectly valid loader which ignored .pyo and .pyc 
files entirely, and always recompiled from the source file (it would be 
slower than the normal one, but it would work).

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.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] [Python-3000] Documentation switch imminent

[Paul Moore]

On 21/08/07, Benji York <[EMAIL PROTECTED]> wrote:
> Georg Brandl wrote:
> > I put the CHM at , if you want
> > to have a look.
>
> Generally looks good.  I did get this error when opening the CHM:
>
> """
> A Runtime Error has occurred.
> Do you with to Debug?
>
> Line: 236
> Error: Expected identifier, string or number
> """
>
> Nothing happened when I clicked "Yes".  The error is repeated each time
> a new page is opened.

I got that as well, in index.html line 264 character 7. I suspect it's
one of the included js files (which I can't get access to).

> An additional opinion:  The red, appear-on-hover permalink markers don't
> make much sense in a CHM and are somewhat distracting.  Can those be
> hidden, perhaps via CSS?

That sounds reasonable.

But I'd agree with Benji that the new CHM file looks fine! Thanks for
all your work on this.

Paul.
___
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]

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

Yes, that's right.  If the cert verifies, its details are then
available, as a mapping, something like this:

{'notBefore': 'Sep 29 16:38:04 2006 GMT',
 'notAfter': 'Dec  7 16:38:04 2008 GMT',
 'issuer':
{'organizationalUnitName': u'UpLib',
 'organizationName': u'PARC',
 'commonName': u'wolfe-64.parc.xerox.com',
 'stateOrProvinceName': u'California',
 'countryName': u'US',
 'localityName': u'Palo Alto'},
 'version': 2,
 'subject':
{'organizationalUnitName': u'UpLib',
 'organizationName': u'PARC',
 'commonName': u'wolfe-64.parc.xerox.com',
 'stateOrProvinceName': u'California',
 'countryName': u'US',
 'localityName': u'Palo Alto'}
 }

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.

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

[Bill Janssen]

> 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
CERT_REQUIRED, they could add them to their rootcerts file.

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

[Neal Norwitz]

On 8/21/07, Hrvoje Nikšić <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-08-20 at 20:27 +0200, Maciej Fijalkowski wrote:
> > import thread
> >
> > while 1:
> > f = open("/tmp/dupa", "w")
> > thread.start_new_thread(f.close, ())
> > f.close()
>
> file_close inadvertently allows fclose to be called twice on the same
> stdio file.  This patch should fix the problem:

The patch is insufficient to prevent all types of crashes that occur
when accessing a file from 2 threads (closing in one and doing
whatever in another).  Almost every place that accesses f_fp is a
problem.  For example, try changing one of the f.close to f.tell.  Or
in the main thread do a write.  With all of these changes to the test
above, I was able to crash python with the patch (until I fixed the
uses of f_fp).

For example:

import thread

while 1:
f = open("/tmp/dupa", "w")
thread.start_new_thread(f.close, ())
try:
  f.write('a')
  f.close()
except: pass

I've attached a patch (against 2.5) that fixes most of the problems,
but there are still a few more.  (Search for Py_BEGIN_ALLOW_THREADS
and check for usage of f_fp within the block.)  I'm not convinced the
attached patch is good enough though.

I think there might already be a bug report about file not being
thread-safe.  (It could have also been socket, but I think Martin
fixed a problem in socket a while ago.)

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

[Graham Horler]

+1 for mutual authentication, I would use this.

Can the TLS handshake be made to respect timeouts on sockets, or would
this require changes deep inside OpenSSL?

Graham
___
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] [Python-3000] Documentation switch imminent

[Georg Brandl]

Paul Moore schrieb:
> On 21/08/07, Benji York <[EMAIL PROTECTED]> wrote:
>> Georg Brandl wrote:
>> > I put the CHM at , if you want
>> > to have a look.
>>
>> Generally looks good.  I did get this error when opening the CHM:
>>
>> """
>> A Runtime Error has occurred.
>> Do you with to Debug?
>>
>> Line: 236
>> Error: Expected identifier, string or number
>> """
>>
>> Nothing happened when I clicked "Yes".  The error is repeated each time
>> a new page is opened.
> 
> I got that as well, in index.html line 264 character 7. I suspect it's
> one of the included js files (which I can't get access to).
> 
>> An additional opinion:  The red, appear-on-hover permalink markers don't
>> make much sense in a CHM and are somewhat distracting.  Can those be
>> hidden, perhaps via CSS?
> 
> That sounds reasonable.

Okay, I uploaded a new version without JavaScript and with hidden permalink
markers.

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

[Bill Janssen]

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

The issue here is the pervasive influence of the socket model.

Take the SocketServer module's BaseRequestHandler.  It has a slot
called "request" which is supposed to contain a socket, not a Raw I/O
stream.  Lots of other modules use that framework, including "pydoc",
"SimpleHTTPServer", "BaseHTTPServer", "SimpleXMLRPCServer", and
"CGIHTTPServer".

I think a few appropriate modifications to BaseRequestHandler and
StreamRequestHandler would do the trick here.

More serious is "asyncore", which is all about sockets.  The
"dispatcher" class in that module is riddled with socket assumptions.
And there's lots of code based on it.  Looking at that, I come back
to the idea that socket.ssl() should return an object which is a
proper subtype of socket.socket.

Probably with a few extra methods:

  read(), write() -- to support existing use of the SSLObject
  getpeercert() -- analogue to "getpeeraddr", but returns cert details
  shutdown() -- to close the SSL channel -- would return the underlying socket 
object

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

[Martin v. Löwis]

> I think there might already be a bug report about file not being
> thread-safe.  (It could have also been socket, but I think Martin
> fixed a problem in socket a while ago.)

This was a different problem, though: the socket object contained
an address structure, which it didn't really need and which wasn't
thread-safe. The (simple) fix was to remove the address from the
object, and move it onto the stack.

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]

> 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 the options there.  I see the code currently selects

   SSL_OP_ALL

to enable all the various bug workarounds, but selects none of the
modifiers.  I'm not currently planning to change that behavior.

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

[Brett Cannon]

[Thanks to Guido, Paul, and Nick for replying; going to just reply to
Paul since everyone said the same thing and it's his fault I didn't
understand the wording.  =)]

On 8/21/07, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 21/08/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).
>
> Hmm, yes, that's muddled. Maybe it made sense to me when I wrote it
> :-) (I think it was my wording rather than Just's)
>
> get_code must *always* return the same code object that
> loader.load_module is using - whether that be bytecode or compiled
> source (and it must respect things like file timestamps where
> appropriate just like load_module does).

Damn, I was afraid you were going to say something like that. =)  I
was hoping for an answer that would allow me to use the source if
available and then use bytecode as a backup.  That might not have the
best performance, but it is the simplest to implement as that skips
the bytecode timestamp check.  This way means I need to refactor some
things to do less import stuff and just do code object creation and
abstract everything else that deals with modules directly to another
function; nothing big but it would have been nice to avoid.  =)

This also means pkgutil is possibly non-compliant as it's get_code
implementation does the above suggestion (tries for source to avoid
timestamp check, and uses bytecode as backup).

> What the sentence you quote
> is trying to say is that if there's a need to compile source, the
> get_code method must do this on behalf of the caller - it can't return
> None and expect the caller to try get_source and compile it manually.
> Someone who only wants a code object should never need to call
> get_source.
>
> I'm not sure that's any clearer! If you need further clarification,
> let me know (either on or off list). I'd appreciate it if you can
> clear the PEP's wording up.

Basically reword it as what you said; the code object returned by
get_code needs to be equivalent to the one load_module would use if
requested to load the same module (e.g., if load_module would use the
bytecode, then it must use the bytecode as it might subtly differ
somehow, like with bytecode optimizations or something).  And mention
that writing out new bytecode is not required (but should it be
optional or not allowed at all?).

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

[Phillip J. Eby]

At 11:22 AM 8/21/2007 -0700, Brett Cannon wrote:
>This also means pkgutil is possibly non-compliant as it's get_code
>implementation does the above suggestion (tries for source to avoid
>timestamp check, and uses bytecode as backup).

That's not actually true, it just *looks* that way.  IIRC, mod_type 
will only be PY_SOURCE if there's no compiled version available.

There's a different bug, though, which is that if you call get_code() 
on an ImpLoader when the module hasn't been loaded, you could get 
out-of-date code, because it's currently relying on imp to do the 
timestamp check and recompile.

___
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] backport new server-side SSL to older Pythons?

[Bill Janssen]

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 scheme says it should be).  The socket module
will then re-export a function from that module as socket.ssl(), which
will continue to do exactly what it does now.  More advanced users will
call functions in the "ssl" module.

Then I can bundle up the new versions of _ssl.c and ssl.py with a
setup.py file, and provide that as an add-on for older Python
installations.

Does this make sense?

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] backport new server-side SSL to older Pythons?

[Guido van Rossum]

On 8/21/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> 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).

> 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 scheme says it should be).  The socket module
> will then re-export a function from that module as socket.ssl(), which
> will continue to do exactly what it does now.  More advanced users will
> call functions in the "ssl" module.
>
> Then I can bundle up the new versions of _ssl.c and ssl.py with a
> setup.py file, and provide that as an add-on for older Python
> installations.
>
> Does this make sense?

I think that it probably can be done, but beware that older Pythons
(and you're going quite a while back!) may use different APIs for
object creation/deletion, so you may end up having to do some work
still. Also, those older versions may have (client-side) ssl support
in their socket module -- isn't that going to conflict? Finally, some
old Python versions may not like new openssl versions (I don't know if
this is the case, but I wouldn't rule it out without testing).

-- 
--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] [Python-3000] Documentation switch imminent

[Paul Moore]

On 21/08/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Okay, I uploaded a new version without JavaScript and with hidden permalink
> markers.

Very nice! Works fine now. Thanks for the quick fix.
Paul
___
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] backport new server-side SSL to older Pythons?

[Bill Janssen]

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

Yes, that was my thinking -- just something for us holdouts to use.

> I think that it probably can be done, but beware that older Pythons
> (and you're going quite a while back!) may use different APIs for
> object creation/deletion, so you may end up having to do some work
> still.

Really?  2.3 to 2.6?  I've looked through the ChangeLog for _ssl.c,
and it does seem extensive.

 Also, those older versions may have (client-side) ssl support
> in their socket module -- isn't that going to conflict?

I don't think so.  Installing this package would upgrade that support
without modifying the existing functionality.

> Finally, some
> old Python versions may not like new openssl versions (I don't know if
> this is the case, but I wouldn't rule it out without testing).

Could be.  But it's the same OpenSSL that we're using to build the new
Python on that platform, so I think it should work.  It's more an
instance of the latest Python not liking older OpenSSL versions.

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

[Greg Ewing]

Paul Moore wrote:
> What the sentence you quote
> is trying to say is that if there's a need to compile source, the
> get_code method must do this on behalf of the caller - it can't return
> None and expect the caller to try get_source and compile it manually.

Why not simply say that it must return a code object?
All the rest follows from that.

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