Re: [Python-Dev] frozenset C API?

[Aahz]

On Thu, Sep 06, 2007, Bill Janssen wrote:
>
> By the way, I think the hostname matching provisions of 2818 (which
> is, after all, only an informational RFC, not a standard) are poorly
> thought out.  Many machines have more hostnames than you can shake a
> stick at, and often provide certs with the wrong hostname in them
> (usually because they have no way to determine what the *right*
> hostname is, from inside that machine).

...which is why you pretty much need to have a canonical hostname mapped
to each IP you're using on a machine.  Basically, you need to map the
hostname you intend to use to an IP, then do reverse-DNS to find out
whether the hostname is in fact the canonical hostname.  If not, you're
using the wrong hostname on your cert.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"Many customs in this life persist because they ease friction and promote
productivity as a result of universal agreement, and whether they are
precisely the optimal choices is much less important." --Henry Spencer
http://www.lysator.liu.se/c/ten-commandments.html
___
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] SSL package for Python 2.3 to 2.5

[Bill Janssen]

> I've put up an initial source package at
> http://www.parc.com/janssen/transient/ssl-1.0.tar.gz which I've tested
> with Python 2.3.5 on Mac OS X 10.4.10 (Intel) and Python 2.5 on Fedora
> Core 7.  Please send bugs you find to me at [EMAIL PROTECTED]
> 
> Try "python setup.py build", then "python setup.py test".

There was a bug for 2.5.1 in the package (the socket data structure
changed with 2.5.1), so I've put up a different version,
http://www.parc.com/janssen/transient/ssl-1.1.tar.gz which I've tested
with 2.3.5 and 2.5.1 on OS X.

Same drill:  try "python setup.py build", then "python setup.py test".
Report bugs to [EMAIL PROTECTED]

Thanks to Collin Winter for reporting this problem with 2.5.1.

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] what versions of Python don't have the "addr" field in the socket object?

[Bill Janssen]

Looks like this change is bothering the error returns from my
backported SSL code.  I believe this is only in 2.5.1 and later -- can
anyone confirm that?

Bill


r52906 | martin.v.loewis | 2006-12-03 03:23:45 -0800 (Sun, 03 Dec 2006) | 4 
lines

Patch #1544279: Improve thread-safety of the socket module by moving
the sock_addr_t storage out of the socket object.
Will backport to 2.5.

___
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] Removing the GIL (Me, not you!)

[Greg Ewing]

Martin v. Löwis wrote:
> Sure - but those things don't get modified that often, except for their
> reference count.

The reference count is the killer, though -- you have
to lock the object even to do that. And it happens
a LOT, to all objects, including immutable ones.

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

Re: [Python-Dev] Removing the GIL (Me, not you!)

[Greg Ewing]

Phillip J. Eby wrote:
> It's also every built-in type 
> structure, builtin module, builtin function...  any Python object 
> that's a built-in, period.

Where "built-in" in this context means anything implemented
in C (i.e. it includes extension modules).

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

Re: [Python-Dev] re-using the Python setup.py file?

[Gregory P. Smith]

On 9/11/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
>
> I see that the setup.py at the top level of the Python distribution
> does a lot of things wrt sensing compiler options, etc, that I'd like
> to re-use in my SSL setup.py distribution file.  I'm a bit curious
> as to why this framework isn't in the distutils package?


I suspect a combo of (a) nobody has done it yet and (b) many of the things
done there felt too hackish to the person writing them.  Regardless of (b)
I'd place my money on (a).

In maintaining external bsddb and hashlib module distributions for use on
older pythons I have so far just pasted code as appropriate to/from the
python setup.py and the separate distribution ones.  Not ideal but trivial
since once settled upon setup didn't change much.
___
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] SSL package for Python 2.3 to 2.5

[Bill Janssen]

I've put up an initial source package at
http://www.parc.com/janssen/transient/ssl-1.0.tar.gz which I've tested
with Python 2.3.5 on Mac OS X 10.4.10 (Intel) and Python 2.5 on Fedora
Core 7.  Please send bugs you find to me at [EMAIL PROTECTED]

Try "python setup.py build", then "python setup.py test".

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] Removing the GIL (Me, not you!)

[Martin v. Löwis]

> We should probably document where all of these globals lists are
> instead of relying on looking for all file level static declarations
> or something.

I'm not sure what would be gained here, except for people occasionally
(i.e. every three years) asking how they can best get rid of the GIL.

> Or would there be benefit to moving things like this to
> the interpreter struct so that threads within a single interpreter
> call are locked but interpreters can act much more independently?

The "multiple interpreter" feature doesn't quite work, and likely
won't for a foreseeable future; specifically, objects can easily
leak across interpreters. That's actually not a problem for immutable
objects, like the strings, but here come the global objects into
play which PJE mentions: types, including exceptions. Making them
per-interpreter would probably break quite some code.

As for the cached strings - it would be easy to make a global table
of these, e.g. calling them _PyS__init__, _PyS__add__, and so on.
These could be initialized at startup, simplifying the code that
uses them because they don't have to worry about failures.

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] Removing the GIL (Me, not you!)

[James Y Knight]

On Sep 11, 2007, at 3:30 PM, Brett Cannon wrote:
> We should probably document where all of these globals lists are
> instead of relying on looking for all file level static declarations
> or something.  Or would there be benefit to moving things like this to
> the interpreter struct so that threads within a single interpreter
> call are locked but interpreters can act much more independently?

This would be nice. It would be really nice if python was embeddable  
more like TCL: separate interpreters really are separate, and don't  
share state. That means basically everything has to be stored in an  
interp-specific data structure, not in static variables.

But this has been raised before, and was rejected as not worth the  
amount of work that would be required to achieve it. (it's certainly  
not worth it enough for *me* to do the work, so I can't blame anyone  
else for making the same determination.)

James
___
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] Removing the GIL (Me, not you!)

[Martin v. Löwis]

> It's not just caches and counters.  It's also every built-in type
> structure, builtin module, builtin function...  any Python object that's
> a built-in, period.  That includes things like None, True, and False.

Sure - but those things don't get modified that often, except for their
reference count. In addition, they are objects, and Justin seems to
believe that things are easier if they are objects.

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] re-using the Python setup.py file?

[Bill Janssen]

I see that the setup.py at the top level of the Python distribution
does a lot of things wrt sensing compiler options, etc, that I'd like
to re-use in my SSL setup.py distribution file.  I'm a bit curious
as to why this framework isn't in the distutils package?

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] adding a "test" fork to a setup.py package

[Bill Janssen]

It's actually not bad.  I put the test code and the data files in a
"test" subdirectory of my distribution, then added the following to
the setup.py file:

class Test (Command):

user_options = []

def initialize_options(self):
pass

def finalize_options(self):
pass

def run (self):

"""Run the regrtest module appropriately"""

# figure out where the _ssl2 extension will be put
b = build(self.distribution)
b.initialize_options()
b.finalize_options()
extdir = os.path.abspath(b.build_platlib)

# now set up the load path
topdir = os.path.dirname(os.path.abspath(__file__))
localtestdir = os.path.join(topdir, "test")
sys.path.insert(0, topdir)# for ssl package
sys.path.insert(0, localtestdir)  # for test module
sys.path.insert(0, extdir)# for _ssl2 extension

# make sure the network is enabled
import test.test_support
test.test_support.use_resources = ["network"]

# and load the test and run it
os.chdir(localtestdir)
the_module = __import__("test_ssl", globals(), locals(), [])
# Most tests run to completion simply as a side-effect of
# being imported.  For the benefit of tests that can't run
# that way (like test_threaded_import), explicitly invoke
# their test_main() function (if it exists).
indirect_test = getattr(the_module, "test_main", None)
if indirect_test is not None:
indirect_test()

and added 

  cmdclass={'test': Test},

to the setup call.  Irritating that you have to manually install the
test files as data_files.  Also irritating that data_files aren't
automatically added to the manifest, and that Test has to have null
initialize_options and finalize_options.  And that there's no easy
way to figure out where the build process left the extension.

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] Removing the GIL (Me, not you!)

[Brett Cannon]

On 9/11/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > It's the interpreter and thread state itself (pystate.h), for the thread
> > state, also _PyThreadState_Current. Then there is the GC state, in
> > particular "generations". There are various caches and counters also.
> >
> >
> > Caches seem like they definitely might be a problem. Would you mind
> > expanding on this a little? What gets cached and why?
>
> Depends on the Python version what precisely gets cached. Several types
> preserve a pool of preallocated objects, to speed up allocation.
> Examples are intobject.c (block_list, free_list), frameobject.c
> (free_list), listobject.c (free_list), methodobject.c (free_list),
> float_object.c (block_list, free_list), classobject.c (free_list).
>
> Plus there are tons of variables caching string objects. From
> classobject.c alone: getattrstr, setattrstr, delattrs, docstr,
> modstr, namestr, initstr, delstr, reprstr, strstr, hashstr, eqstr,
> cmpstr, getitemstr, setitemstr, delitemstr, lenstr, iterstr, nextstr,
> getslicestr, setslicestr, delslicestr, __contains__, all arguments
> to UNARY, UNARY_FB, BINARY, BINARY_INPLACE (e.g. instance_neg,
> instance_or, instance_ior, then cmp_obj, nonzerostr, indexstr.
> (admittedly, classobject.c is extreme here).
>
> There are probably more classes which I just forgot.

We should probably document where all of these globals lists are
instead of relying on looking for all file level static declarations
or something.  Or would there be benefit to moving things like this to
the interpreter struct so that threads within a single interpreter
call are locked but interpreters can act much more independently?

-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] Removing the GIL (Me, not you!)

[Phillip J. Eby]

At 10:07 AM 9/11/2007 -0500, Justin Tulloss wrote:


>On 9/11/07, "Martin v. Löwis" 
><[EMAIL PROTECTED]> wrote:
> > 1. Some global interpreter state/modules are protected (where are these
> > globals at?)
>
>It's the interpreter and thread state itself (pystate.h), for the thread
>state, also _PyThreadState_Current. Then there is the GC state, in
>particular "generations". There are various caches and counters also.
>
>
>Caches seem like they definitely might be a problem. Would you mind 
>expanding on this a little? What gets cached and why?

It's not just caches and counters.  It's also every built-in type 
structure, builtin module, builtin function...  any Python object 
that's a built-in, period.  That includes things like None, True, and False.

Caches would include such things as the pre-created integers -100 
through 255, the 1-byte character strings for chr(0)-chr(255), and 
the interned strings cache, to name a few.

Most of these things I've mentioned are truly global, and not 
specific to an individual interpreter.

___
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] Making directories and zip files executable

[Phillip J. Eby]

At 10:48 AM 9/11/2007 -0700, Guido van Rossum wrote:
>I could use a refresher on how PJE's patch solves Andy's problem.

It does the same thing, but with __main__ instead of __zipmain__, and 
without needing the -z.  So instead of "python -z foo.zip" you can 
just do "python foo.zip".  This means you can use a reasonably 
cross-platform #! header that invokes Python via "env".

If you tried to use -z with env, Andy's approach would either only 
work on BSDish platforms that support multiple options to a #! 
command, or else you'd have to ditch the "env" and hardcode the patht 
to Python.  So not needing a command-line option improves the 
effective portability/usability of the executable zip file.

Also, being able to run "python directory_to_be_zipped_later" also 
lets you test/develop your program without it needing to be zipped first.


>On 9/11/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > The local patch I have for PEP 366 is somewhat stale, and before I bring
> > it up to date with SVN head, I'd like to close out the issue raised a
> > while back regarding making zip files executable [1].
> >
> > The original proposal was for a new command line switch, but PJE came up
> > with a patch (attached to the roundup tracker item) that uses the
> > existing import machinery to avoid the need for the extra command line
> > switch (by checking if the argument is a valid sys.path entry before
> > checking to see if it is an executable script).
> >
> > I personally like the idea (and PJE's approach), and the performance
> > impact on script startup time appears to be negligible (although I
> > haven't performed any high precision measurements - I'm just using the
> > Linux time utility on a short test script with and without the patch).
> >
> > Are there any objections to my committing this?
> >
> > Cheers,
> > Nick.
> >
> > [1] http://bugs.python.org/issue1739468

___
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] adding a "test" fork to a setup.py package

[Thomas Heller]

Barry Warsaw schrieb:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Sep 11, 2007, at 2:12 PM, Bill Janssen wrote:
> 
>> I'm packaging up the SSL support for Python 2.3, and I'd like to be
>> able to include the unit test for it along with the package.  Ideally,
>> I'd like to be able to say
>>
>> % python setup.py build
>> % python setup.py test
>>
>> and have the regrtest.py module run my tests.  Any ideas (examples) of
>> how to do that?
> 
> The email package does something like this by having most of the  
> tests in a subpackage of enum, with a shim in Lib/test for regrtest.   
> The standalone package has a testall script, but that should really  
> be converted to nosetests or some such.

ctypes does it in a similar way.  Tests are in the Lib/ctypes/test package.

Thomas

___
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] Compiler Python

[Terry Reedy]

"Carlos Martínez" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
| Someone knows since as I can obtain the information detailed about the
| compiler of Python? (Table of tokens, lists of productions of the 
syntactic
| one , semantic restrictions...)

Ask this sort of question on the python-list mailing list or the
comp.lang.python or gmane.comp.python.general newsgroups.
And check the source code. 



___
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] adding a "test" fork to a setup.py package

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sep 11, 2007, at 2:12 PM, Bill Janssen wrote:

> I'm packaging up the SSL support for Python 2.3, and I'd like to be
> able to include the unit test for it along with the package.  Ideally,
> I'd like to be able to say
>
> % python setup.py build
> % python setup.py test
>
> and have the regrtest.py module run my tests.  Any ideas (examples) of
> how to do that?

The email package does something like this by having most of the  
tests in a subpackage of enum, with a shim in Lib/test for regrtest.   
The standalone package has a testall script, but that should really  
be converted to nosetests or some such.

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBRubgtXEjvBPtnXfVAQIGJgP/aeCOlybJj0sA3k6WOWMCOhugggLHHtO2
lu5v7hZZG5nqe5iApwxjbiylxvMRfRB6HS7dgEABx1D5OC3uFssn3kUzokfBtsxy
I/e4qYiTSCG3WZacqytAqmjKt3FkceIo+l6YKx29FjPlaoHHz0UzCJIdW9AuJp4a
Ussk9AOPIXo=
=FMDE
-END PGP SIGNATURE-
___
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] Compiler Python

[Carlos Martínez]

Hello

 

Someone knows since as I can obtain the information detailed about the
compiler of Python? (Table of tokens, lists of productions of the syntactic
one , semantic restrictions...)

 

Thanks.

___
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] adding a "test" fork to a setup.py package

[Bill Janssen]

I'm packaging up the SSL support for Python 2.3, and I'd like to be
able to include the unit test for it along with the package.  Ideally,
I'd like to be able to say

% python setup.py build
% python setup.py test

and have the regrtest.py module run my tests.  Any ideas (examples) of
how to do that?

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] Making directories and zip files executable

[Guido van Rossum]

I could use a refresher on how PJE's patch solves Andy's problem.

On 9/11/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> The local patch I have for PEP 366 is somewhat stale, and before I bring
> it up to date with SVN head, I'd like to close out the issue raised a
> while back regarding making zip files executable [1].
>
> The original proposal was for a new command line switch, but PJE came up
> with a patch (attached to the roundup tracker item) that uses the
> existing import machinery to avoid the need for the extra command line
> switch (by checking if the argument is a valid sys.path entry before
> checking to see if it is an executable script).
>
> I personally like the idea (and PJE's approach), and the performance
> impact on script startup time appears to be negligible (although I
> haven't performed any high precision measurements - I'm just using the
> Linux time utility on a short test script with and without the patch).
>
> Are there any objections to my committing this?
>
> Cheers,
> Nick.
>
> [1] http://bugs.python.org/issue1739468
>
> --
> 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/guido%40python.org
>


-- 
--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] Summary of Tracker Issues

[Tracker]

ACTIVITY SUMMARY (09/04/07 - 09/11/07)
Tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue 
number.  Do NOT respond to this message.


 1274 open (+31) / 11356 closed (+16) / 12630 total (+47)

Average duration of open issues: 673 days.
Median duration of open issues: 635 days.

Open Issues Breakdown
   open  1271 (+31)
pending 3 ( +0)

Issues Created Or Reopened (47)
___

Is there just no PRINT statement any more? Or it just doesn't wo 09/06/07
CLOSED http://bugs.python.org/issue1101reopened loewis   

Add support for _msi.Record.GetString() and _msi.Record.GetInteg 09/04/07
   http://bugs.python.org/issue1102created  atuining 

Typo in dummy_threading documentation09/04/07
CLOSED http://bugs.python.org/issue1103created  dthomasset   

msilib.SummaryInfo.GetProperty() truncates the string by one cha 09/04/07
   http://bugs.python.org/issue1104created  atuining 

patch for readme.txt in PCbuild8 09/05/07
CLOSED http://bugs.python.org/issue1105created  chipped  

Error in random.shuffle  09/05/07
CLOSED http://bugs.python.org/issue1106created  Viscaynot

2to3,   lambda with non-tuple argument inside parenthesis09/05/07
CLOSED http://bugs.python.org/issue1107created  falsetru 

Problem with doctest and decorated functions 09/05/07
   http://bugs.python.org/issue1108created  danilo   

Warning required when calling register() on an ABCMeta subclass  09/05/07
   http://bugs.python.org/issue1109created  mark 

Problems with the msi installer - python-3.0a1.msi   09/05/07
   http://bugs.python.org/issue1110created  vbr  

Users' directories information   09/05/07
CLOSED http://bugs.python.org/issuecreated  uzytkownik   

Test debug assertion in bsddb test_1413192.py09/05/07
CLOSED http://bugs.python.org/issue1112created  db3l 

interrupt_main() fails to interrupt raw_input()  09/05/07
CLOSED http://bugs.python.org/issue1113created  anand

_curses issues on 64-bit big-endian (e.g, AIX)   09/06/07
   http://bugs.python.org/issue1114created  lukemewburn  

Minor Change For Better cross compile09/06/07
   http://bugs.python.org/issue1115created  zengbo   

reference in extending doc to non-existing file  09/06/07
CLOSED http://bugs.python.org/issue1116created  anthon   

Spurious warning about missing _sha256 and _sha512 when not need 09/06/07
CLOSED http://bugs.python.org/issue1117created  dripton  

hashlib module fails with TypeError  09/06/07
CLOSED http://bugs.python.org/issue1118created  dripton  

Search index is messed up after partial rebuilding   09/06/07
CLOSED http://bugs.python.org/issue1119created  lars.gustaebel   

"make altinstall" installs pydoc, idle, smtpd.py with broken she 09/06/07
   http://bugs.python.org/issue1120created  dripton  

Document inspect.getfullargspec()09/06/07
   http://bugs.python.org/issue1121created  brett.cannon 

PyTuple_Size and PyTuple_GET_SIZE return type documentation inco 09/07/07
   http://bugs.python.org/issue1122created  gaul 

split(None, maxsplit) does not strip whitespace correctly09/07/07
   http://bugs.python.org/issue1123created  nirs 

Webchecker not parsing css "@import url" 09/07/07
   http://bugs.python.org/issue1124created  ready.eddy   

bytes.split shold have same interface as str.split, or different 09/07/07
CLOSED http://bugs.python.org/issue1125created  nirs 

file.fileno and file.isatty() should be implementable by any fil 09/07/07
   http://bugs.python.org/issue1126created  nirs 

No tests for inspect.getfullargspec()09/07/07
   http://bugs.python.org/issue1127created  brett.cannon 

msilib.Directory.make_short only handles file names with a singl 09/07/07
   http://bugs.python.org/issue1128created  atuining 

OpenSSL detection broken for Python 3.0a109/07/07
CLOSED http://bugs.python.org/issue1129created  pythonmeister

Idle - Save (buffer) - closes IDLE and does not save file (Windo 09/08/07
   http://bugs.pyt

Re: [Python-Dev] Removing the GIL (Me, not you!)

[Martin v. Löwis]

> It's the interpreter and thread state itself (pystate.h), for the thread
> state, also _PyThreadState_Current. Then there is the GC state, in
> particular "generations". There are various caches and counters also.
> 
> 
> Caches seem like they definitely might be a problem. Would you mind
> expanding on this a little? What gets cached and why?

Depends on the Python version what precisely gets cached. Several types
preserve a pool of preallocated objects, to speed up allocation.
Examples are intobject.c (block_list, free_list), frameobject.c
(free_list), listobject.c (free_list), methodobject.c (free_list),
float_object.c (block_list, free_list), classobject.c (free_list).

Plus there are tons of variables caching string objects. From
classobject.c alone: getattrstr, setattrstr, delattrs, docstr,
modstr, namestr, initstr, delstr, reprstr, strstr, hashstr, eqstr,
cmpstr, getitemstr, setitemstr, delitemstr, lenstr, iterstr, nextstr,
getslicestr, setslicestr, delslicestr, __contains__, all arguments
to UNARY, UNARY_FB, BINARY, BINARY_INPLACE (e.g. instance_neg,
instance_or, instance_ior, then cmp_obj, nonzerostr, indexstr.
(admittedly, classobject.c is extreme here).

There are probably more classes which I just forgot.

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] Removing the GIL (Me, not you!)

[skip]

Justin> Caches seem like they definitely might be a problem. Would you
Justin> mind expanding on this a little? What gets cached and why?

I believe the integer free list falls into this category.

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] Removing the GIL (Me, not you!)

[Justin Tulloss]

On 9/11/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> > 1. Some global interpreter state/modules are protected (where are these
> > globals at?)
>
> It's the interpreter and thread state itself (pystate.h), for the thread
> state, also _PyThreadState_Current. Then there is the GC state, in
> particular "generations". There are various caches and counters also.


Caches seem like they definitely might be a problem. Would you mind
expanding on this a little? What gets cached and why?

Justin
___
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] [issue1056] test_cmd_line starts python without -E

[Thomas Wouters]

On 9/11/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:

> (Is the head still being merged to the py3k branch? Or does this need to
> be forward-ported manually?)


No worries, the trunk is still being merged to py3k. I doubt we'll ever stop
doing that, unless the trunk becomes py3k and 2.x development is done on a
branch (in which case I imagine we'd merge between those two in some way :-)


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

[Python-Dev] Making directories and zip files executable

[Nick Coghlan]

The local patch I have for PEP 366 is somewhat stale, and before I bring 
it up to date with SVN head, I'd like to close out the issue raised a 
while back regarding making zip files executable [1].

The original proposal was for a new command line switch, but PJE came up 
with a patch (attached to the roundup tracker item) that uses the 
existing import machinery to avoid the need for the extra command line 
switch (by checking if the argument is a valid sys.path entry before 
checking to see if it is an executable script).

I personally like the idea (and PJE's approach), and the performance 
impact on script startup time appears to be negligible (although I 
haven't performed any high precision measurements - I'm just using the 
Linux time utility on a short test script with and without the patch).

Are there any objections to my committing this?

Cheers,
Nick.

[1] http://bugs.python.org/issue1739468

-- 
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] Removing the GIL (Me, not you!)

[Aahz]

On Tue, Sep 11, 2007, Justin Tulloss wrote:
>
> I had a whole long email about exactly what I was doing, but I think
> I'll get to the point instead. I'm trying to implement a python
> concurrency API and would like to use cpython to do it. To do that, I
> would like to remove the GIL.

You should review the work Greg Stein did to remove the GIL in 1.5.2;
although the interpreter core has changed considerably since then, I
believe the basic principles of the GIL are the same.  
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"Many customs in this life persist because they ease friction and promote
productivity as a result of universal agreement, and whether they are
precisely the optimal choices is much less important." --Henry Spencer
http://www.lysator.liu.se/c/ten-commandments.html
___
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] testing in a Python --without-threads build

[Aahz]

On Tue, Sep 11, 2007, "Martin v. L?wis" wrote:
>
>>> No. IIUC, "expected skips" are a platform property. For your platform,
>>> support for threads is expected (whatever your platform is as log as
>>> it was built in this millenium).
>> 
>> Really?  I thought NetBSD was still iffy WRT threading.
> 
> Ah, right. Still, it seems that people expect that thread support is
> available on NetBSD. The list of expected skips does not mention
> test_thread for 'netbsd3' (it only does so for 'sco_sv3' and 'riscos')

I'm assuming that's because NetBSD has threads, they just don't work.  So
we don't want that to put NetBSD on the list of expected skips so that we
find out when threads do work.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"Many customs in this life persist because they ease friction and promote
productivity as a result of universal agreement, and whether they are
precisely the optimal choices is much less important." --Henry Spencer
http://www.lysator.liu.se/c/ten-commandments.html
___
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] which SSL client protocols work with which server protocols?

[Matt Goodall]

Bill Janssen wrote:
> Here's the updated connection table:
> 
>   SSL2SSL3SS23TLS1
> SSL2  yes no  yes no
> SSL3  yes yes yes no
> SSL23 yes no  yes no
> TLS1  no  no  yes yes
> 
> Given this, I think the client-side default should be changed from
> SSLv23 to SSLv3, and the server-side default should be SSLv23.

I believe you are correct.

I did some experiments with this a while ago after hitting problems
connecting to some SSL servers although I can't remember the exact
results now.

More importantly, what you recommend is what Twisted does and I'd
believe them more than me any time ;-).

See Twisted's DefaultOpenSSLContextFactory [1] for the server side and
ClientContextFactory [2] for the client side.


Cheers, Matt


[1] DefaultOpenSSLContextFactory,
http://twistedmatrix.com/trac/browser/trunk/twisted/internet/ssl.py#L67

[2] ClientContextFactory,
http://twistedmatrix.com/trac/browser/trunk/twisted/internet/ssl.py#L102

-- 
Matt Goodall, Pollenation Internet Ltd
Technology House, 237 Lidgett Lane, Leeds LS17 6QR
Registered No 4382123
A member of the Brunswick MCL Group of Companies
w: http://www.pollenation.net/
e: [EMAIL PROTECTED]
t: +44 113 2252500
___
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] Compiling Python 2.5 and settinf UCS2 flag

[Thomas Wouters]

On 9/11/07, Tennessee Leeuwenburg <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> I have an unusual use case in which some software I work on compiles a
> version of Python for distribution. I'm not 100% across this as it's not at
> all my area of responsibility, but I have been having some issues lately.
>
> My hand-compiled version of Python 2.5 works just fine, and in turn uses a
> hand-compiled Tcl/Tk with threading disabled.
>
> The system then re-compiles Python2.5 for its own purposes. At this point,
> it appears to ignore some of the options originally set using configure for
> Python.
>
> I have enough knowledge/control over the system to pass in some additional
> compiler flags. I would like to try to force some behaviour normally set as
> a flag to the configure script.
>
> Is there a C compiler flag I can use to force the use of UCS2 unicode?


This isn't really a python-dev question, more a python-list one. Python dev
is for the development of Python, not with Python or your system ;)

The choice between UCS2 and UCS4 is made by configure, based on two things:
what you pass with the --enable-unicode argument (if anything), and what the
version of Tcl you're linking against seems to use. Tcl's choice is only
used if no explicit choice is given. configure also determines the proper
type for the actual UCS2/UCS4 data -- wchar_t, unsigned short or unsigned
long. Both choices are stored in pyconfig.h as is usual for configure. You
can't override them with C compiler flags, but you can edit pyconfig.h if
you can't change the configure flags. Keep in mind that you change both of
those (you probably want to just diff the two pyconfig.h's to see what else
is different.)

-- 
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] Removing the GIL (Me, not you!)

[Martin v. Löwis]

> 1. Some global interpreter state/modules are protected (where are these
> globals at?)

It's the interpreter and thread state itself (pystate.h), for the thread
state, also _PyThreadState_Current. Then there is the GC state, in
particular "generations". There are various caches and counters also.

> 2. When writing C extensions I can change the state of my python object
> without worrying about synchronization
> 3. When writing C extensions I can change my own internal C state
> without worrying about synchronization (unless I have other, non-python
> threads running)
4. The builtin container types are protected by the GIL, and various
   other builtin objects
5. Reference counting is protected by the GIL
6. PyMalloc is protected by the GIL.

> Does anyone know of a place where the GIL is required when not operating
> on a python object?

See 6 above, also (obviously) 1.

> I've only started looking at the code recently, so please forgive my
> naivety. I'm still learning how the interpreter works on a high level,
> let alone all the nitty gritty details!

Good luck!

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] Removing the GIL (Me, not you!)

[Justin Tulloss]

Hi,

I had a whole long email about exactly what I was doing, but I think I'll
get to the point instead. I'm trying to implement a python concurrency API
and would like to use cpython to do it. To do that, I would like to remove
the GIL.

So, since I'm new to interpreter hacking, some help would be appreciated.
I've listed what I think the GIL does; if you guys could add to this list or
refine it, I would very much appreciate it.

Roles of the GIL:
1. Some global interpreter state/modules are protected (where are these
globals at?)
2. When writing C extensions I can change the state of my python object
without worrying about synchronization
3. When writing C extensions I can change my own internal C state without
worrying about synchronization (unless I have other, non-python threads
running)

Does anyone know of a place where the GIL is required when not operating on
a python object? It seems like this would never happen, and would make
replacing the GIL somewhat easier.

I've only started looking at the code recently, so please forgive my
naivety. I'm still learning how the interpreter works on a high level, let
alone all the nitty gritty details!

Thanks,
Justin
___
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