Re: [Python-Dev] compile extensions under Windows Vista and VS8
> 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
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
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, 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
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=54199&r1=42115&r2=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
> 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
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
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=54199&r1=42115&r2=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
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=54199&r1=42115&r2=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
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
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
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
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
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/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?
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
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?
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
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
