Re: [Python-Dev] compile extensions under Windows Vista and VS8

2007-10-19 Thread Martin v. Löwis
 Does anyone know, why setuptools cannot find VS8? 

Python 2.5 does not support being built with VS8, and distutils
knows that. The official compiler to build Python 2.5 is
VS 7.1.

There are environment variables to tell distutils otherwise;
see the documentation or the source for details. This question
is off-topic for python-dev.

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] Fwd: Deadlock by a second import in a thread

2007-10-19 Thread Adam Olsen
On 10/19/07, Facundo Batista [EMAIL PROTECTED] wrote:
 2007/10/19, Adam Olsen [EMAIL PROTECTED]:

  The solution then is, if your python file will ever be imported, you
  must write a main function and do all the work there instead.  Do not
  write it in the style of a script (with significant work in the global
  scope.)

 I had this a as a good coding style, not so mandatory.

 I agree with you that the OP shouldn't be doing that, but note that
 the main problem arises here because it's completely unpredictable the
 import in strptime for an external user.

 Do you recommend to close the bug as won't fix saying something like...

 The deadlock happens because strptime has an import inside it, and
 recursive imports are not allowed in different threads.

 As a general rule and good coding style, don't run your code when the
 module is imported, but put it in a function like main in the second 
 file,
 import it and call it from the first one. This will solve your problem.

 Note that this happens to you with strptime, but could happen with a lot
 of functions that do this internal import of something else. So,
 you'll never
 be sure.

 What do you think?

Whether this is a minor problem due to poor style or a major problem
due to a language defect is a matter of perspective.  I'm working on
redesigning Python's threading support, expecting it to be used a
great deal more, which'd push it into the major problem category.

For now I'd leave it open.

-- 
Adam Olsen, aka Rhamphoryncus
___
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] Deadlock by a second import in a thread

2007-10-19 Thread Facundo Batista
Hi!

I was looking to this bug:   http://bugs.python.org/issue1255

It basically creates a deadlock in Python by doing the following:

- aa.py imports bb.py
- bb.py imports time and generates a thread
- the thread uses time.strptime

The deadlock is because the strptime function imports another module,
line 517 of timemodule.c:

  PyObject *strptime_module = PyImport_ImportModule(_strptime);

This situation is well known, found a lot of references to this
import-thread-import problem in discussions and previous bugs (i.e.:
http://bugs.python.org/issue683658).

What I did *not* find, and why I'm asking here, is how to solve it.

Exists a known solution to this?

Thank you!

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


[Python-Dev] Fwd: Deadlock by a second import in a thread

2007-10-19 Thread Facundo Batista
2007/10/19, Adam Olsen [EMAIL PROTECTED]:

 The solution then is, if your python file will ever be imported, you
 must write a main function and do all the work there instead.  Do not
 write it in the style of a script (with significant work in the global
 scope.)

I had this a as a good coding style, not so mandatory.

I agree with you that the OP shouldn't be doing that, but note that
the main problem arises here because it's completely unpredictable the
import in strptime for an external user.

Do you recommend to close the bug as won't fix saying something like...

The deadlock happens because strptime has an import inside it, and
recursive imports are not allowed in different threads.

As a general rule and good coding style, don't run your code when the
module is imported, but put it in a function like main in the second file,
import it and call it from the first one. This will solve your problem.

Note that this happens to you with strptime, but could happen with a lot
of functions that do this internal import of something else. So,
you'll never
be sure.

What do you think?

Thank you!

--
.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] incompatible unittest changes

2007-10-19 Thread Jean-Paul Calderone
On Fri, 19 Oct 2007 15:51:51 -0700, Collin Winter [EMAIL PROTECTED] wrote:
On 10/19/07, Jean-Paul Calderone [EMAIL PROTECTED] wrote:
 In trunk after 2.5, equality and hashing for TestCase were added, changing 
 the behavior so that two instances of TestCase for the same test method hash 
 the same and compare equal.  This means two instances of TestCase for the 
 same test method cannot be added to a single set.

 Here's the change:

 http://svn.python.org/view/python/trunk/Lib/unittest.py?rev=54199r1=42115r2=54199

 The implementations aren't even very good, since they prevent another type 
 from deciding that it wants to customize comparison against TestCase (or 
 TestSuite,
 or FunctionTestCase) instances.

The implementations have been changed in a more recent revision.

Not in http://svn.python.org/projects/python/trunk/Lib/[EMAIL PROTECTED]


 Is there a real use case for this functionality?  If not, I'd like it to be
 removed to restore the old behavior.

The use-case was problems I encountered when writing the test suite
for unittest. If you can find a way to implement the functionality you
want *and* keep the test suite reasonably straightforward, I'll be
happy to review your patch.

The test suite can implement the comparison which is currently on the
unittest classes and invoke that functionality instead of using == and
!=.

Jean-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] Buildbot failure AMD64 trunk

2007-10-19 Thread Martin v. Löwis
 The 64-bit windows trunk buildbot now only fails the test_winsound test.
 This is because for whatever reasons the machine cannot play any sounds.
 I have no idea why this is so, and I'm not too inclined to fix this.  The
 buildbot is running Window XP 64-bit in a vmware image running under ubuntu.
 
 Is there a way to display the winsound test on this machine?  I'm annoyed
 by the red color ;-).

If you uninstall the sound driver, then the test should determine that
there is no sound card, and skip it.

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] Deadlock by a second import in a thread

2007-10-19 Thread Adam Olsen
On 10/19/07, Facundo Batista [EMAIL PROTECTED] wrote:
 Hi!

 I was looking to this bug:   http://bugs.python.org/issue1255

 It basically creates a deadlock in Python by doing the following:

 - aa.py imports bb.py
 - bb.py imports time and generates a thread
 - the thread uses time.strptime

 The deadlock is because the strptime function imports another module,
 line 517 of timemodule.c:

   PyObject *strptime_module = PyImport_ImportModule(_strptime);

 This situation is well known, found a lot of references to this
 import-thread-import problem in discussions and previous bugs (i.e.:
 http://bugs.python.org/issue683658).

 What I did *not* find, and why I'm asking here, is how to solve it.

 Exists a known solution to this?

When python encounters a recursive import within a single thread it
allows you to get access to partially-imported modules, making the
assumption that you won't do any significant work until the entire
import process completes.

Only one thread is allowed to do an import at a time though, as
they'll do significant work with it immediately, so being
partially-imported would be a race condition.

Writing a python file as a script means you do significant work in the
body, rather than in a function called after importing completes.
Importing this python file then violates the assumption for
single-threaded recursive imports, and creating threads then violates
their safety assumptions.

The solution then is, if your python file will ever be imported, you
must write a main function and do all the work there instead.  Do not
write it in the style of a script (with significant work in the global
scope.)

-- 
Adam Olsen, aka Rhamphoryncus
___
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] incompatible unittest changes

2007-10-19 Thread Collin Winter
On 10/19/07, Jean-Paul Calderone [EMAIL PROTECTED] wrote:
 In trunk after 2.5, equality and hashing for TestCase were added, changing 
 the behavior so that two instances of TestCase for the same test method hash 
 the same and compare equal.  This means two instances of TestCase for the 
 same test method cannot be added to a single set.

 Here's the change:

 http://svn.python.org/view/python/trunk/Lib/unittest.py?rev=54199r1=42115r2=54199

 The implementations aren't even very good, since they prevent another type 
 from deciding that it wants to customize comparison against TestCase (or 
 TestSuite,
 or FunctionTestCase) instances.

The implementations have been changed in a more recent revision.

 Is there a real use case for this functionality?  If not, I'd like it to be
 removed to restore the old behavior.

The use-case was problems I encountered when writing the test suite
for unittest. If you can find a way to implement the functionality you
want *and* keep the test suite reasonably straightforward, I'll be
happy to review your patch.

Collin Winter
___
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] incompatible unittest changes

2007-10-19 Thread Jean-Paul Calderone
In trunk after 2.5, equality and hashing for TestCase were added, changing the 
behavior so that two instances of TestCase for the same test method hash the 
same and compare equal.  This means two instances of TestCase for the same test 
method cannot be added to a single set.

Here's the change:

http://svn.python.org/view/python/trunk/Lib/unittest.py?rev=54199r1=42115r2=54199

The implementations aren't even very good, since they prevent another type from 
deciding that it wants to customize comparison against TestCase (or TestSuite,
or FunctionTestCase) instances.

Is there a real use case for this functionality?  If not, I'd like it to be
removed to restore the old behavior.

Jean-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] Deadlock by a second import in a thread

2007-10-19 Thread Nick Coghlan
Facundo Batista wrote:
 Hi!
 
 I was looking to this bug:   http://bugs.python.org/issue1255
 
 It basically creates a deadlock in Python by doing the following:
 
 - aa.py imports bb.py
 - bb.py imports time and generates a thread

bb.py is broken - importing a module should never spawn a new thread as 
a side effect (precisely because it will deadlock if the spawned thread 
tries to do an import, which can happen in a myriad of ways).

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] Buildbot failure AMD64 trunk

2007-10-19 Thread Thomas Heller
Thomas Heller schrieb:
 The 64-bit windows trunk buildbot now only fails the test_winsound test.
 This is because for whatever reasons the machine cannot play any sounds.
 I have no idea why this is so, and I'm not too inclined to fix this.  The
 buildbot is running Window XP 64-bit in a vmware image running under ubuntu.
 
 Is there a way to display the winsound test on this machine?  I'm annoyed
 by the red color ;-).

I mean: Is there a way to DISABLE the winsound test?

Sorry for the confusion...

___
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] compile extensions under Windows Vista and VS8

2007-10-19 Thread Sebastian Wehrmann
Hi all,

I've got a tricky problem with a self-compiled python2.4.4 under Windows 
Vista. I compiled with Visual Studio 8 Standard (.NET 2005).

Python greets with the right header:

   Python 2.4.4 (#71, Oct 19 2007, 18:49:44) [MSC v.1400 32 bit (Intel)]
   on win32

I started the Visual Studio Shell and tried to get some extensions using 
setuptools (easy_install):

   python ez_setup.py readline
   [...]
   Best match: readline 2.4.2
   [..Downloading..]
   Running readline-2.4.2\setup.py -q bdist_egg --dist-dir
   c:\users\sweh\appdata\local\temp\easy_install-nnn9di\
   readline-2.4.2\egg-dist-tmp-fqezb_
   error: Setup script exited with error: Python was built with version
   8.0 of Visual Studio, and extensions need to be built with the same
   version of the compiler, but it isn't installed.

Does anyone know, why setuptools cannot find VS8? I'm sure the system 
variables are set correctly as in %VCDIR%\bin\vcvars32.bat.

regards,
-- 
Sebastian Wehrmann

gocept gmbh  co. kg · forsterstrasse 29 · 06112 halle/saale · germany
www.gocept.com · work. +49 345 122988912 · fax. +49 345 12298891
___
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

2007-10-19 Thread Tracker

ACTIVITY SUMMARY (10/12/07 - 10/19/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.


 1312 open (+23) / 11472 closed ( +5) / 12784 total (+28)

Open issues with patches:   420

Average duration of open issues: 680 days.
Median duration of open issues: 752 days.

Open Issues Breakdown
   open  1307 (+23)
pending 5 ( +0)

Issues Created Or Reopened (28)
___

doctest fails to run file based tests with 8bit paths10/12/07
   http://bugs.python.org/issue1274created  bear 
   patch   

bsddb closing a DB object before all DBCursors using it are clos 10/12/07
   http://bugs.python.org/issue1275created  gregory.p.smith  
   

LookupError: unknown encoding: X-MAC-JAPANESE10/13/07
   http://bugs.python.org/issue1276created  josm 
   patch   

mailbox.Maildir: factory not used10/14/07
   http://bugs.python.org/issue1277created  bwurst   
   

imp.find_module() ignores -*- coding: Latin-1 -*-10/15/07
   http://bugs.python.org/issue1278created  tiran
   

os.system() oddity under Windows XP SP2  10/15/07
   http://bugs.python.org/issue1279created  pythonmeister
   

PEP 3137: Make PyString's indexing and iteration return integers 10/15/07
   http://bugs.python.org/issue1280created  alexandre.vassalotti 
   patch   

typo in documentation - lib ref section 14.3.3.4 10/15/07
CLOSED http://bugs.python.org/issue1281created  bsherman 
   

re module needs to support bytes / memoryview well   10/15/07
   http://bugs.python.org/issue1282created  gvanrossum   
   

PyBytes (buffer) .extend method needs to accept any iterable of  10/16/07
   http://bugs.python.org/issue1283created  gregory.p.smith  
   py3k

typo in lib doc 7.3.2.1 MaildirMessage   10/16/07
   http://bugs.python.org/issue1284created  encoded  
   

setp.py error The process cannot access the file ...   10/16/07
   http://bugs.python.org/issue1285created  uweber4711   
   

fileinput, StringIO, and cStringIO do not support the with proto 10/16/07
   http://bugs.python.org/issue1286created  ygale
   

os.environ.pop doesn't work  10/16/07
   http://bugs.python.org/issue1287created  niemeyer 
   

dict.fromkeys - Odd logic when passing second dict.fromkeys as v 10/16/07
CLOSED http://bugs.python.org/issue1288created  dohertywa
   

Typo in Context Manager Types10/18/07
CLOSED http://bugs.python.org/issue1289created  nhaines  
   

xml.dom.minidom not able to handle utf-8 data10/18/07
CLOSED http://bugs.python.org/issue1290created  sharmila 
   

test_resource fails on recent linux systems (10/18/07
   http://bugs.python.org/issue1291created  doko 
   

libffi needs an update to support mips64, arm and armeabi on lin 10/18/07
   http://bugs.python.org/issue1292created  doko 
   

Trailing slash in sys.path cause import failure  10/18/07
 

[Python-Dev] Buildbot failure AMD64 trunk

2007-10-19 Thread Thomas Heller
The 64-bit windows trunk buildbot now only fails the test_winsound test.
This is because for whatever reasons the machine cannot play any sounds.
I have no idea why this is so, and I'm not too inclined to fix this.  The
buildbot is running Window XP 64-bit in a vmware image running under ubuntu.

Is there a way to display the winsound test on this machine?  I'm annoyed
by the red color ;-).

Thanks,
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] C Decimal - is there any interest?

2007-10-19 Thread Facundo Batista
2007/10/16, Daniel Stutzbach [EMAIL PROTECTED]:

 I agree.  A basic subquadratic radix conversion algorithm isn't much
 more complex than the existing quadratic code.  I just whipped
 together a Python prototype and it's only 15 lines.

Do you have a patch for decimal.py of current trunk?

Don't be afraid of submitting it in the Tracker and assign it to me...

Thank you!

-- 
.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] C Decimal - is there any interest?

2007-10-19 Thread Daniel Stutzbach
On 10/16/07, Mark Dickinson [EMAIL PROTECTED] wrote:
  Radix conversion can be done in O(n log**2 n) time using a divide and
  conquer algorithm.

 Isn't there a log(log n) missing here?

Possibly, but who's counting?  :-)

 In any case, it seems to me
 that achieving this sort of complexity is probably best left to GMP
 and the like.  But a basic subquadratic division based on Burnikel and
 Ziegler's 'Fast Recursive Division' paper seems within reach---this
 would give division and radix conversion essentially the same
 complexity as  Karatsuba multiplication.

I agree.  A basic subquadratic radix conversion algorithm isn't much
more complex than the existing quadratic code.  I just whipped
together a Python prototype and it's only 15 lines.

The quadratic algorithm is basically a divide-and-conquer algorithm,
too, except it's the bad kind that  breaks the input into pieces of
size O(1) and size O(n) instead of pieces of size O(n/2). :-)
(where n is number of digits)

-- 
Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises LLC
___
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] Python help desired

2007-10-19 Thread Collis, Chris
Guido van Rossum suggested I forward this email to you.  I contacted him 
earlier this week regarding the inquiry below.  Please read.
 
 Our company produces hardware for both wired and wireless
 device networking.  We recently launched a wireless gateway that supports
 Python for programmability.  Our customers use this gateway as part of an
 end-to-end wireless sensor network and Python to add application-specific
 data intelligence.  We are looking to assemble a group of third party Python
 developers or Python shops that we can refer customers to who need support
 in developing scripts to support their intended application.

 Do you have any organizations/individuals you might recommend who could
 partner with us in such a capacity or another resource I might pursue to
 find such partners?  We are a global company and ideally would like partners
 who can support global opportunities or partners in North America, Europe
 and Asia who specialize in those regions.

 Feel free to contact me directly if you would like further information or
 clarification.

 Thanks much,
 Chris Collis
 Digi Int'l
 Product Marketing
 952 912 3150

___
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] C Decimal - is there any interest?

2007-10-19 Thread Daniel Stutzbach
On 10/16/07, Mark Dickinson [EMAIL PROTECTED] wrote:
 I'm almost sure that adding 4 digit numbers together is not what
 Decimal was intended to be used for, but it still seems unreasonable
 that it takes almost 5 seconds to do such an addition.  The reason for
 the quadratic behaviour is that almost all the arithmetic routines in
 decimal.py, at some point, convert the coefficient of their
 argument(s) from a tuple of digits to a Python integer, and then do
 the reverse conversion to get a Decimal result;  both of these
 conversions (tuple of digits - integer) take time quadratic in the
 size of the tuple/integer.

Instead of (or in addition to) porting to C, wouldn't it be better to
improve the conversion algorithm?

Radix conversion can be done in O(n log**2 n) time using a divide and
conquer algorithm.

Such an algorithm can be found at the link below (search for Radix
conversion):
http://people.cis.ksu.edu/~rhowell/calculator/comparison.html

-- 
Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises LLC
___
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] Deadlock by a second import in a thread

2007-10-19 Thread Christian Heimes
Facundo Batista wrote:
 What I did *not* find, and why I'm asking here, is how to solve it.
 
 Exists a known solution to this?

I know a possible solution. You could write a patch that moves the
imports in C code to the module init function and stores the modules in
a global static variable.

Christian

___
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