Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
in [Python]
|
Prev: Python GUI for C program [was: ]
Next: Download Microsoft C/C++ compiler for use with Python 2.6/2.7ASAP
From: Stephen Hansen on 8 Jul 2010 01:30 On 7/7/10 9:46 PM, "Martin v. Löwis" wrote: >> I saw you already mentioned work toward this a few months (years ?) >> ago. Is there some kind of roadmap, or could you use some help ? I >> would really like to solve this issue as much as we possibly can, > > Well, Python 3 has already dropped stdio for its own io library, and > I do want to get rid of the remaining FILE* usage for 3.2. Any other > change needs to be discussed on python-dev first; contributions are welcome. Really? I wasn't entirely aware of this effect of the "io" module. Somehow, without at all paying attention (because certain third party modules blocking me for awhile, I never looked close enough), I just sort of thought the "io" module was mostly thin wrappers around stdio primitives, into a more Pythonic API. This actually makes me long for Python 3 more. And adjust agendas to push my day-job work to 2.7 as soon as possible, and start a preemptive reconfiguration to support a future Py3k migration. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/
From: Christian Heimes on 8 Jul 2010 05:48 > Really? I wasn't entirely aware of this effect of the "io" module. > Somehow, without at all paying attention (because certain third party > modules blocking me for awhile, I never looked close enough), I just > sort of thought the "io" module was mostly thin wrappers around stdio > primitives, into a more Pythonic API. Yes, really. :) The new io modules doesn't use stdio. It operates solely on file descriptors and low level functions like open(2) instead of fopen(3). All high level functions like buffering is implemented in Python (and some C for speed). Christian
From: Neil Hodgson on 8 Jul 2010 20:02 sturlamolden: > Windows did this too (msvcrt.dll) up to the VS2003 release, which came > with msvcr71.dll in addition. Since then, M$ (pronounced Megadollar > Corp.) have published msvcr80.dll, msvcr90.dll, and msvcr100.dll (and > corresponding C++ versions) to annoy C and C++ developers into > converting to C# .NET. (And yes, programs using third-party DLL and > OCX components become unstable from this. You have to check each DLL/ > OCX you use, and each DLL used by each DLL, etc. How fun...) One of the benefits to COM is that it acts as a C runtime firewall - it has its own memory allocation interface (IMalloc / CoGetMalloc) and file I/O is performed through interfaces like IStream. It is quite common to use an OCX compiled with one compiler in an application compiled with another. If you break the rules by using malloc rather than IMalloc for memory that is deallocated by a different component to that which allocated it or try to pass around FILE* objects then you will see failures. So, always follow the COM rules. Neil
From: Tim Roberts on 9 Jul 2010 00:39 Christian Heimes <lists(a)cheimes.de> wrote: >> Yeah, but then we're down to file descriptors, C library locales and such as the >> remaining problems. > >Don't forget errno! Every CRT might have its own errno thread local. I >don't know how its handled on Windows but I suspect it suffers from the >same problem. No. The multi-thread-aware CRT in Visual C++ (which is the only option since VS2008) puts errno in thread-local storage, so it's shared by all CRTs. -- Tim Roberts, timr(a)probo.com Providenza & Boekelheide, Inc.
From: Dave Angel on 9 Jul 2010 03:55
Tim Roberts wrote: > Christian Heimes <lists(a)cheimes.de> wrote: > > >>> Yeah, but then we're down to file descriptors, C library locales and such as the >>> remaining problems. >>> >> Don't forget errno! Every CRT might have its own errno thread local. I >> don't know how its handled on Windows but I suspect it suffers from the >> same problem. >> > > No. The multi-thread-aware CRT in Visual C++ (which is the only option > since VS2008) puts errno in thread-local storage, so it's shared by all > CRTs. > I didn't know specifically that errno is in TLS, but I will disagree with the conclusion that a TLS entry is implicitly shared by all CRT's. Unless the CRT for each DLL explicitly does some extra work to allow sharing, each will have its own set of TLS variables. DaveA |