Re: [Python-Dev] How best to handle the docs for a renamed module?
On Fri, May 16, 2008 at 5:49 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Raymond Hettinger wrote: >> >> I say leave the new names in 3.0 and let the 2-to-3 tool do its job. >> Why confuse the 2.6 landscape with double naming clutter. > > To increase the common subset of code which can run on both 2.6 and 3.0 > *without* invoking 2to3? > Right. 2.6 is trying to be as much of a reasonable subset of Python 3.0 as possible. This includes module names. > PEP-8'ifying these names also makes them easier for at least me to remember > (since I don't have to worry about whether or not the module name includes > unexpected underscores or strange capitalisation) That too. =) -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 best to handle the docs for a renamed module?
Raymond Hettinger wrote: I say leave the new names in 3.0 and let the 2-to-3 tool do its job. Why confuse the 2.6 landscape with double naming clutter. To increase the common subset of code which can run on both 2.6 and 3.0 *without* invoking 2to3? PEP-8'ifying these names also makes them easier for at least me to remember (since I don't have to worry about whether or not the module name includes unexpected underscores or strange capitalisation) 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] Visual Studio 2008 compiler option EHsc ?
Martin v. Löwis wrote: In building a package with several platforms, I ran across the warning message below from Visual Studio 2008. Should we add the /EHsc option to the compile_options in distutils for MSVC? Or is it more complex than that... Who is "we"? If you have a module that uses C++ exceptions, you should certainly enable compiler support for exceptions, for that module. In my original email, I referred to the patch for distutils at: http://tinyurl.com/63bqo2 Based on that patch, I made the attached patch in distutils to msvc9compiler.py and that made the complaints disappear (and presumably made the exceptions work?). Is there any downside to doing this by default? Or should I parameterize my build_ext for that platform to include that option? Some of the web pages on the topic suggest that this is due to a change in the compiler behavior with VS2008. So this may bite other people as 2.6 rolls out. I am not an expert in structured exception handling and all the nuances so welcome any advice. Thanks - Jim --- msvc9compiler.py.orig 2008-05-16 16:08:01.619640200 -0700 +++ msvc9compiler.py2008-05-15 16:45:47.493969600 -0700 @@ -375,15 +375,15 @@ self.preprocess_options = None if self.__arch == "x86": -self.compile_options = [ '/nologo', '/Ox', '/MD', '/W3', +self.compile_options = [ '/nologo', '/Ox', '/MD', '/W3', '/EHsc', '/DNDEBUG'] -self.compile_options_debug = ['/nologo', '/Od', '/MDd', '/W3', +self.compile_options_debug = ['/nologo', '/Od', '/MDd', '/W3', '/EHsc', '/Z7', '/D_DEBUG'] else: # Win64 -self.compile_options = [ '/nologo', '/Ox', '/MD', '/W3', '/GS-' , +self.compile_options = [ '/nologo', '/Ox', '/MD', '/W3', '/GS-' , '/EHsc', '/DNDEBUG'] -self.compile_options_debug = ['/nologo', '/Od', '/MDd', '/W3', '/GS-', +self.compile_options_debug = ['/nologo', '/Od', '/MDd', '/W3', '/GS-', '/EHsc', '/Z7', '/D_DEBUG'] self.ldflags_shared = ['/DLL', '/nologo', '/INCREMENTAL:NO'] ___ 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] Addition of "pyprocessing" module to standard lib.
On Fri, May 16, 2008 at 1:32 AM, Ulrich Berning <[EMAIL PROTECTED]> wrote: > > As long as the ctypes extension doesn't build on major Un*x platforms (AIX, > HP-UX), I don't like to see ctypes dependend modules included into the > stdlib. Please keep the stdlib as portable as possible. Nice in theory but ctypes already works on at least the top 3 popular platforms. Lets not hold Python's stdlib back because nobody who uses IBM and HP proprietary stuff has contributed the necessary support. Making nice libraries available for other platforms is a good way to encourage people to either pitch in and add support or consider their platform choices in the future. -gps ___ 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 best to handle the docs for a renamed module?
[Brett[ For the sake of argument, let's consider the Queue module. It is now named queue. For 2.6 I plan on having both Queue and queue listed in the index, with Queue deprecated with instructions to use the new name. FWIW, I don't consider this to be a value added backport. Renaming doesn't benefit a 2.6 user. All it does is add confusion and it may break code where users or third-party libraries are already using the new name. I say leave the new names in 3.0 and let the 2-to-3 tool do its job. Why confuse the 2.6 landscape with double naming clutter. Raymond ___ 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] Symbolic errno values in error messages
> Until recently, python had its own cross-platform implementation of > strerror, but it was removed because it was deemed redundant. This > tells me that it should work on windows. That conclusion is incorrect. It works on MSVCRT, but for this specific aspect, using MSVCRT is a bad idea (because it artificially renumbers system errors, just to provide an illusion for what Microsoft considers POSIX). 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] Addition of "pyprocessing" module to standard lib.
> Apart from (1) and (2) which I think are unavoidable, nearly all the C > code is Windows specific. I assume you don't want to bring > in the whole of pywin32 into stdlib... I wouldn't structure it the same way as pywin32, but yes, I have pondered exposing all of Win32 in a module, as part of the standard library. This has somewhat lost relevance with ctypes. 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] Addition of "pyprocessing" module to standard lib.
2008/5/14 "Martin v. Löwis" <[EMAIL PROTECTED]>: >> I really do feel that inclusion of this library offers us the best of >> both worlds - it gives us (as a community) an easy answer to those >> people who would dismiss python due to the GIL and it also allows >> users to easily implement their applications. I am the author of processing -- sorry for arriving late in this thread. > For inclusion into Python, a number of things need to be changed, > in particular with respect to the C code. It duplicates a lot of > code from the socket and os modules, and should (IMO) be merged into > these, rather than being separate - or perhaps merged into the > subprocess module. Now that socket.fromfd() and socket._dup() is available on Windows in 2.6 and 3.0 (after a patch from me) some of the code could be removed. I would also like to see recvfd() and sendfd() get added to the socket module -- these functions allow the transfer of file descriptors between processes over a Unix domain socket. But I am not sure that there is much duplication with the socket module. The Connection type is basically a message oriented version of a socket with builtin pickling/unpickling -- it could be implemented in pure Python but that would *much* slower. I cannot see any opportunity to reuse code from socketmodule.c in implementing the Connection type, particularly given that the code also allows the use of Windows named pipes which are much faster than sockets on Windows. As far as I know there is no duplication with the os modules. Basically the C code separates as follows (1) a Connection type (plus PipeConnection on windows) (2) a "process shared" lock/semaphore type (3) Win32 functions/constants to allow use of named pipes (4) A few other Win32 functions/constants (5) A wrapper making PyObject_AsWriteBuffer() available from Python I suppose (4) and perhaps (3) could sensibly be added/merged with _subprocess.c. (5) could also be moved somewhere else. > Why isn't it possible to implement all this in pure Python, on > top of the subprocess module? I am not sure how much you include when you say "all this" -- (2) certainly cannot be done in pure python, and I certainly believe that (1) needs to be done in C for the sake of performance. On Windows I did use subprocess.py in earlier versions, but I had bug reports saying that in non-console programs it would choke because it was failing to duplicate GetStdHandle(STD_OUTPUT_HANDLE) etc. Using _subprocess.CreateProcess() directly avoided the problem and did not add noticeably to code length. I also found that the Popen.__del__() methods kept raising errors on process shutdown because of unavailable globals, so I was happy to get shot of subprocess.py. (Off-topic but I think that the way that subprocess.Popen.__del__() keeps the object alive if the process has not finished is a little distasteful. The __del__() method and the _cleanup() function are completely unecessary on Windows since Windows does not have zombie processes. On Unix __del__() could simply save the pid to the _active list and _cleanup() could be rewritten to use os.waitpid().) > If there are limitations in Python that make it impossible to > implement such functionality in pure Python - then *those* > limitations should be overcome, rather than including the code > wholesale. Apart from (1) and (2) which I think are unavoidable, nearly all the C code is Windows specific. I assume you don't want to bring in the whole of pywin32 into stdlib... > Regards, > Martin Richard PS. I am more than willing to maintain the code if it goes in. ___ 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 best to handle the docs for a renamed module?
On Fri, May 16, 2008 at 5:43 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > On 2008-05-12 04:34, Brett Cannon wrote: >> >> For the sake of argument, let's consider the Queue module. It is now >> named queue. For 2.6 I plan on having both Queue and queue listed in >> the index, with Queue deprecated with instructions to use the new >> name. >> >> But what to do about all the references. Should we leave them pointing >> at Queue to lessen confusion for people who read about some module on >> some other site that isn't using the new name, or update everything in >> 2.6 to use the new name? > > How hard would it be to add a redirects from the old pages to the > new ones ? > > mod_rewrite does wonders - well, provided you find the right patterns... Well, the problem is that only solves the online docs issue, not offline viewing. And now that the docs can be built easily, I at least find myself referring to the docs mostly offline rather than through docs.python.org. -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] lib2to3, need some light on the imports fixer
On Fri, May 16, 2008 at 10:42 AM, Guilherme Polo <[EMAIL PROTECTED]> wrote: > 2008/5/16 Collin Winter <[EMAIL PROTECTED]>: >> On Fri, May 16, 2008 at 10:30 AM, Guilherme Polo <[EMAIL PROTECTED]> wrote: >>> 2008/5/12 Collin Winter <[EMAIL PROTECTED]>: On Mon, May 12, 2008 at 1:58 PM, Guilherme Polo <[EMAIL PROTECTED]> wrote: > Hello, > > Would someone tell me how can I add a new entry in the MAPPING dict in > the lib2to3/fixes/fix_imports.py that does the following: > > "import A" gets fixed as "import C.D as A" > > Right now it is fixing by doing "import C.D" and changing several > other lines in the code to use this new "C.D" name. I wanted to avoid > these changes if possible. I don't believe there's a way to do that, but adding support for it should be fairly straight-forward. Assign the patch to me for review. >>> >>> Is there something I could read get some 2to3 understanding ? >> >> The README is a very shallow overview, but it needs to be beefed up to >> talk about architecture. Honestly, the best way (currently) is to read >> the existing fixers. Mea culpa. >> >>> How do I construct patterns ? >> >> find_pattern.py is the tool I wrote/use to find patterns. You give it >> some Python code and it spits out the pattern for it. It's hard to >> hand-construct patterns due to some optimizations done to eliminate >> unneeded nodes (nodes with only a single child are eliminated, pulling >> the child to its grandparent). >> > > I see find_pattern.py is only at > http://svn.python.org/projects/sandbox/trunk/2to3. > Now I remember I saw it some time ago, but was trying to find it at > python's repo and couldn't find it =) Please make your changes to http://svn.python.org/projects/sandbox/trunk/2to3; the Python copy should be synced from there, not the other way around. ___ 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] lib2to3, need some light on the imports fixer
2008/5/16 Collin Winter <[EMAIL PROTECTED]>: > On Fri, May 16, 2008 at 10:30 AM, Guilherme Polo <[EMAIL PROTECTED]> wrote: >> 2008/5/12 Collin Winter <[EMAIL PROTECTED]>: >>> On Mon, May 12, 2008 at 1:58 PM, Guilherme Polo <[EMAIL PROTECTED]> wrote: Hello, Would someone tell me how can I add a new entry in the MAPPING dict in the lib2to3/fixes/fix_imports.py that does the following: "import A" gets fixed as "import C.D as A" Right now it is fixing by doing "import C.D" and changing several other lines in the code to use this new "C.D" name. I wanted to avoid these changes if possible. >>> >>> I don't believe there's a way to do that, but adding support for it >>> should be fairly straight-forward. Assign the patch to me for review. >>> >> >> Is there something I could read get some 2to3 understanding ? > > The README is a very shallow overview, but it needs to be beefed up to > talk about architecture. Honestly, the best way (currently) is to read > the existing fixers. Mea culpa. > >> How do I construct patterns ? > > find_pattern.py is the tool I wrote/use to find patterns. You give it > some Python code and it spits out the pattern for it. It's hard to > hand-construct patterns due to some optimizations done to eliminate > unneeded nodes (nodes with only a single child are eliminated, pulling > the child to its grandparent). > I see find_pattern.py is only at http://svn.python.org/projects/sandbox/trunk/2to3. Now I remember I saw it some time ago, but was trying to find it at python's repo and couldn't find it =) Thanks Collin. -- -- Guilherme H. Polo Goncalves ___ 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] lib2to3, need some light on the imports fixer
On Fri, May 16, 2008 at 10:30 AM, Guilherme Polo <[EMAIL PROTECTED]> wrote: > 2008/5/12 Collin Winter <[EMAIL PROTECTED]>: >> On Mon, May 12, 2008 at 1:58 PM, Guilherme Polo <[EMAIL PROTECTED]> wrote: >>> Hello, >>> >>> Would someone tell me how can I add a new entry in the MAPPING dict in >>> the lib2to3/fixes/fix_imports.py that does the following: >>> >>> "import A" gets fixed as "import C.D as A" >>> >>> Right now it is fixing by doing "import C.D" and changing several >>> other lines in the code to use this new "C.D" name. I wanted to avoid >>> these changes if possible. >> >> I don't believe there's a way to do that, but adding support for it >> should be fairly straight-forward. Assign the patch to me for review. >> > > Is there something I could read get some 2to3 understanding ? The README is a very shallow overview, but it needs to be beefed up to talk about architecture. Honestly, the best way (currently) is to read the existing fixers. Mea culpa. > How do I construct patterns ? find_pattern.py is the tool I wrote/use to find patterns. You give it some Python code and it spits out the pattern for it. It's hard to hand-construct patterns due to some optimizations done to eliminate unneeded nodes (nodes with only a single child are eliminated, pulling the child to its grandparent). ___ 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] lib2to3, need some light on the imports fixer
2008/5/12 Collin Winter <[EMAIL PROTECTED]>: > On Mon, May 12, 2008 at 1:58 PM, Guilherme Polo <[EMAIL PROTECTED]> wrote: >> Hello, >> >> Would someone tell me how can I add a new entry in the MAPPING dict in >> the lib2to3/fixes/fix_imports.py that does the following: >> >> "import A" gets fixed as "import C.D as A" >> >> Right now it is fixing by doing "import C.D" and changing several >> other lines in the code to use this new "C.D" name. I wanted to avoid >> these changes if possible. > > I don't believe there's a way to do that, but adding support for it > should be fairly straight-forward. Assign the patch to me for review. > Is there something I could read get some 2to3 understanding ? How do I construct patterns ? > Collin Winter > -- -- Guilherme H. Polo Goncalves ___ 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] Addition of "pyprocessing" module to standard lib.
[Facundo] I think that including in the stdlib a threading-like-API module is a clear win. I also think this is vital and should not wait for Py2.7. Raymond ___ 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] Symbolic errno values in error messages
On Fri, May 16, 2008 at 10:52 AM, Yannick Gingras <[EMAIL PROTECTED]> wrote:
> "Alexander Belopolsky" <[EMAIL PROTECTED]> writes:
>
> try:
>> ...open('/')
>> ... except Exception,e:
>> ...pass
>> ...
> print e
>> [Errno 21] Is a directory
>>
>> So now I am not sure what OP is proposing. Do you want to replace 21
>> with EISDIR in the above?
>
> Yes, that's what I had in mind.
>
Then, check out EnvironmentError_str in Objects/exceptions.c. You
should be able import the errno module and fetch its errorcode
dictionary.
-- Alexandre
___
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] Addition of "pyprocessing" module to standard lib.
2008/5/13 Jesse Noller <[EMAIL PROTECTED]>: > I am looking for any questions, concerns or benchmarks python-dev has > regarding the possible inclusion of the pyprocessing module to the > standard library - preferably in the 2.6 timeline. In March, I began +1 to include this module in the library, if... - it's included in 2.7/3.1 after a stabilization period. - it's stop reinventing the wheel and starts using the already-in-stdlib infrastructure (this is from Martin's post). - a champion appears willing to work with it and maintain it afterwards (which is the opinion of the module owner about this?) I think that including in the stdlib a threading-like-API module is a clear win. Of course, this module won't solve all the problems or necessities of multiprocessing world, but it's an included easy to use start (in the same spirit that SimpleHTTPServer it's not an Apache, but it's very useful if your problem area fits its limitations). 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] Symbolic errno values in error messages
On 2008-05-16 17:02, Alexander Belopolsky wrote: On Fri, May 16, 2008 at 10:52 AM, Yannick Gingras <[EMAIL PROTECTED]> wrote: print e [Errno 21] Is a directory So now I am not sure what OP is proposing. Do you want to replace 21 with EISDIR in the above? Yes, that's what I had in mind. In this case, I have a more drastic proposal. Lets change EnvironmentError errno attribute (myerrno in C) to string. -1 You never want to change an integer field to a string. 'EXYZ' strings can be interned, which will make them more efficient than integers for lookups and comparisons (to literals). A half-way and backward compatible solution would be to stick 'EXYZ' code at the end of the args tuple and add an errnosym attribute. Actually, you don't have to put it into any tuple. Just add it to the error object as attribute. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 16 2008) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ 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] Addition of "pyprocessing" module to standard lib.
On Fri, May 16, 2008 at 11:22 AM, Thomas Heller <[EMAIL PROTECTED]> wrote: > Ulrich Berning schrieb: >> Nick Craig-Wood wrote: >> >>>Jesse Noller <[EMAIL PROTECTED]> wrote: >>> >>> I am looking for any questions, concerns or benchmarks python-dev has regarding the possible inclusion of the pyprocessing module to the standard library - preferably in the 2.6 timeline. In March, I began working on the PEP for the inclusion of the pyprocessing (processing) module into the python standard library[1]. The original email to the stdlib-sig can be found here, it includes a basic overview of the module: http://mail.python.org/pipermail/stdlib-sig/2008-March/000129.html The processing module mirrors/mimics the API of the threading module - and with simple import/subclassing changes depending on the code, allows you to leverage multi core machines via an underlying forking mechanism. The module also supports the sharing of data across groups of networked machines - a feature obviously not part of the core threading module, but useful in a distributed environment. >>> >>>I think processing looks interesting and useful, especially since it >>>works on Windows as well as Un*x. >>> >>>However I'd like to see a review of the security - anything which can >>>run across networks of machines has security implications and I didn't >>>see these spelt out in the documentation. >>> >>>Networked running should certainly be disabled by default and need >>>explicitly enabling by the user - I'd hate for a new version of python >>>to come with a remote exploit by default... >>> >>> >>> >> As long as the ctypes extension doesn't build on major Un*x platforms >> (AIX, HP-UX), I don't like to see ctypes dependend modules included into >> the stdlib. Please keep the stdlib as portable as possible. >> More and more people tend to say "Runs on Un*x" when they really mean >> "Tested on Linux". Un*x is not Linux. > > Hm, I've never looked at the processing module. Does it depend on ctypes? > > Anyway, the trunk version of ctypes is a lot more portable than the > release25-maint > version. I have once tried to build the trunk on HP-UX machines, and, > IIRC, it did build on IA64 and PA machines. Of course only with GCC, not > with the vendor compilers. > > Thomas > Yes, it requires ctypes. ___ 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] Symbolic errno values in error messages
On 2008-05-16 16:15, Nick Coghlan wrote: Alexander Belopolsky wrote: Yannick Gingras ygingras.net> writes: 2) Where can I find the symbolic name in C? Use standard C library char* strerror(int errnum) function. You can see an example usage in Modules/posixmodule.c (posix_strerror). I don't believe that would provide adequate Windows support. Well, there's still the idea of a winerror module: http://bugs.python.org/issue1505257 Perhaps someone can pick it up and turn it into a (generated) C module ?! -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 16 2008) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ 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] Addition of "pyprocessing" module to standard lib.
Ulrich Berning schrieb: > Nick Craig-Wood wrote: > >>Jesse Noller <[EMAIL PROTECTED]> wrote: >> >> >>> I am looking for any questions, concerns or benchmarks python-dev has >>> regarding the possible inclusion of the pyprocessing module to the >>> standard library - preferably in the 2.6 timeline. In March, I began >>> working on the PEP for the inclusion of the pyprocessing (processing) >>> module into the python standard library[1]. The original email to the >>> stdlib-sig can be found here, it includes a basic overview of the >>> module: >>> >>> http://mail.python.org/pipermail/stdlib-sig/2008-March/000129.html >>> >>> The processing module mirrors/mimics the API of the threading module - >>> and with simple import/subclassing changes depending on the code, >>> allows you to leverage multi core machines via an underlying forking >>> mechanism. The module also supports the sharing of data across groups >>> of networked machines - a feature obviously not part of the core >>> threading module, but useful in a distributed environment. >>> >>> >> >>I think processing looks interesting and useful, especially since it >>works on Windows as well as Un*x. >> >>However I'd like to see a review of the security - anything which can >>run across networks of machines has security implications and I didn't >>see these spelt out in the documentation. >> >>Networked running should certainly be disabled by default and need >>explicitly enabling by the user - I'd hate for a new version of python >>to come with a remote exploit by default... >> >> >> > As long as the ctypes extension doesn't build on major Un*x platforms > (AIX, HP-UX), I don't like to see ctypes dependend modules included into > the stdlib. Please keep the stdlib as portable as possible. > More and more people tend to say "Runs on Un*x" when they really mean > "Tested on Linux". Un*x is not Linux. Hm, I've never looked at the processing module. Does it depend on ctypes? Anyway, the trunk version of ctypes is a lot more portable than the release25-maint version. I have once tried to build the trunk on HP-UX machines, and, IIRC, it did build on IA64 and PA machines. Of course only with GCC, not with the vendor compilers. 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] Symbolic errno values in error messages
On Fri, May 16, 2008 at 10:52 AM, Yannick Gingras <[EMAIL PROTECTED]> wrote: > print e >> [Errno 21] Is a directory >> >> So now I am not sure what OP is proposing. Do you want to replace 21 >> with EISDIR in the above? > > Yes, that's what I had in mind. > In this case, I have a more drastic proposal. Lets change EnvironmentError errno attribute (myerrno in C) to string. 'EXYZ' strings can be interned, which will make them more efficient than integers for lookups and comparisons (to literals). A half-way and backward compatible solution would be to stick 'EXYZ' code at the end of the args tuple and add an errnosym attribute. ___ 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] Symbolic errno values in error messages
"Alexander Belopolsky" <[EMAIL PROTECTED]> writes:
try:
> ...open('/')
> ... except Exception,e:
> ...pass
> ...
print e
> [Errno 21] Is a directory
>
> So now I am not sure what OP is proposing. Do you want to replace 21
> with EISDIR in the above?
Yes, that's what I had in mind.
--
Yannick Gingras
___
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] Symbolic errno values in error messages
On Fri, May 16, 2008 at 10:15 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Alexander Belopolsky wrote:
..
>> Use standard C library char* strerror(int errnum) function. You can see
>> an example usage in Modules/posixmodule.c (posix_strerror).
>
> I don't believe that would provide adequate Windows support.
>
Until recently, python had its own cross-platform implementation of
strerror, but it was removed because it was deemed redundant. This
tells me that it should work on windows. On the other hand, IOError
object and in fact EnvironmentError object already has strerror member
which is printed when available:
>>> try:
...open('/')
... except Exception,e:
...pass
...
>>> print e
[Errno 21] Is a directory
So now I am not sure what OP is proposing. Do you want to replace 21
with EISDIR in the above?
___
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] Symbolic errno values in error messages
On Sat, 17 May 2008 00:15:23 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote: Alexander Belopolsky wrote: Yannick Gingras ygingras.net> writes: 2) Where can I find the symbolic name in C? Use standard C library char* strerror(int errnum) function. You can see an example usage in Modules/posixmodule.c (posix_strerror). I don't believe that would provide adequate Windows support. It's not C, but maybe it's interesting to look at anyway: http://twistedmatrix.com/trac/browser/trunk/twisted/python/win32.py?rev=21682#L94 However, neither strerror nor the linked code gives out symbolic names for errnos. They both produce messages like "Interrupted system call", whereas the symbolic name would be "EINTR". Modules/errnomodule.c might be worth looking at, although its solution is somewhat disappointing. 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] Symbolic errno values in error messages
Alexander Belopolsky wrote: Yannick Gingras ygingras.net> writes: 2) Where can I find the symbolic name in C? Use standard C library char* strerror(int errnum) function. You can see an example usage in Modules/posixmodule.c (posix_strerror). I don't believe that would provide adequate Windows support. 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] Symbolic errno values in error messages
Yannick Gingras wrote: 1) Should OSError.__str__() print the symbolic name of errno? +1 (assuming the performance hit for doing so is incurred only when the exception is actually printed) 2) Where can I find the symbolic name in C? Modules/errnomodule.c 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] Symbolic errno values in error messages
Yannick Gingras ygingras.net> writes: .. > > 1) Should OSError.__str__() print the symbolic name of errno? > +1 for the change > 2) Where can I find the symbolic name in C? Use standard C library char* strerror(int errnum) function. You can see an example usage in Modules/posixmodule.c (posix_strerror). ___ 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] [Distutils] Distutils & configparser rename
On 2008-05-16 15:28, Rasmus Andersson wrote: On 16 maj 2008, at 15.00, M.-A. Lemburg wrote: On 2008-05-15 22:33, A.M. Kuchling wrote: So there already is a lot of porting effort needed to support a reasonable number of targets. I don't think it takes a lot of effort to keep distutils running with Python 2.3 and 2.4. Speaking of which; is there any reliable statistics of Python versions and platforms? Would be really interesting! Reliable statistics are hard to obtain, since Python is distributed along with many Unix distributions, as part of many products, and also in source form (where you basically lose any platform or Python version information). FWIW, these are the stats for our OSS Python package egenix-mx-base: Downloads egenix-mx-base 3.0 in 2008: Python 1.5.2: 0 Python 2.0 : 0 Python 2.1 : 31 Python 2.2 : 54 Python 2.3 : 483 Python 2.4 : 3368 Python 2.5 : 7504 Source ZIP : 4238 Source TGZ : 2918 These are just downloads, so likely new installations (the 3.0 version was released about one year ago). It's hard to tell what the installed user base looks like, esp with respect to the used Python versions. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 16 2008) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ 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] Addition of "pyprocessing" module to standard lib.
Ulrich Berning wrote: More and more people tend to say "Runs on Un*x" when they really mean "Tested on Linux". Un*x is not Linux. Hmm, perhaps that would be why there are Solaris, FreeBSD and Tru64 machines amongst the main Python buildbots, to go along with the assorted OS X, Windows and Linux boxes - and as far as I know test_ctypes runs quite happily on all of them. On the specific problems with AIX, HP-UX and ctypes, was it ctypes itself that was failing to build, or the underlying libffi? 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] Addition of "pyprocessing" module to standard lib.
On Fri, May 16, 2008 at 10:32:30AM +0200, Ulrich Berning wrote: > As long as the ctypes extension doesn't build on major Un*x platforms > (AIX, HP-UX), I don't like to see ctypes dependend modules included into > the stdlib. Please keep the stdlib as portable as possible. > More and more people tend to say "Runs on Un*x" when they really mean > "Tested on Linux". Un*x is not Linux. Python development doesn't seem to have any volunteers who use AIX or HP-UX and can fix bugs on these platforms. Searching bugs.python.org, I find about 20 open AIX issues, 4 or 5 HP-UX issues, 6 IRIX bugs, and about 15 Solaris bugs; but I don't know if any of the developers here use these platforms. (There is a Solaris buildbot, at least.) This means that if people didn't use ctypes and wrote C extension modules instead, those extension modules probably wouldn't work on AIX and HP-UX either. I'd rather see a standard library that's as featureful and useful as possible, and not constrain it in order to support platforms that we don't really seem to be supporting anyway. There's a bug report about ctypes on AIX (1637120) and an old one about ctypes on Solaris that looks like it's fixed, but I can't find a report for HP-UX. Part of the problem seems to be that libffi is written for GCC, so using the vendor compiler often causes difficulties. --amk ___ 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] platform module testing
On 2008-05-15 23:54, Benjamin Peterson wrote: At the moment, the test for the platform module merely calls each function. I realize that this is a hard module to test well, but are there some assumptions we can make? For example, if sys.platform is 'java', can it be assumed that java_ver is going to return something which is not empty. When sys.platform is 'darwin' and the gestalt module is present, is it reasonable to require that a empty tuple not be returned? Yes, at least the main elements should be present and filled in. If not, we have to fix platform.py. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 16 2008) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ 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] Distutils & configparser rename
On 2008-05-15 22:33, A.M. Kuchling wrote: Python 2.6 renames the ConfigParser module to be configparser. Distutils imports ConfigParser in various places. I just made a commit updating the import in one places, and then noticed that part of commit r63248, which made the same change, was reverted in order to preserve backward-compatibility. Instead, the default path will include lib-old again to keep the old module name available. I suggest dropping that goal, though. We've preserved compatibility but I'm not aware that anyone uses the Python 2.x Distutils with earlier versions of Python. In particular: * There's no standalone distutils package on PyPI, nor can I find such a package with a general web search. Am I missing it? * I do not see users advising other users to use a later version of Distutils to fix their problems. Is anyone actually benefiting from the effort of maintaining backward compatibility? Yes: all the folks who want to create distutils packages for more than just the current Python version. I've argued for this a couple of times in the past. Some background: In order to build a Python package for a previous Python version, you have to run distutils using that older Python version. Now, as distutils evolves, new features are added, bugs are fixed, etc. so as packager you always want to use the latest distutils version available - even with older Python releases. In some cases, e.g. PyPI registration, this may even be necessary, since the new versions of those commands need to be kept in sync with the PyPI repository. Another aspect is keeping package setup.py files working. If you need to support multiple Python versions, then your setup.py will have to work with multiple different versions of distutils. Since performance doesn't really matter for distutils, it is well possible and easy to keep compatibility with a few releases back. This has worked great in the past and I don't see why we should break this, as recent distutils checkins have done. Note that Python doesn't exactly make it easy to ship Python packages. You have several different dimensions to take into consideration: * Python version * UCS2/UCS4 * Platform and processor type * 32/64-bit So there already is a lot of porting effort needed to support a reasonable number of targets. I don't think it takes a lot of effort to keep distutils running with Python 2.3 and 2.4. In the past I've usually rewritten parts of distutils that were modified in incompatible ways. I haven't been able to that for the recent checkins that broke distutils even on Python 2.4. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 16 2008) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ 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 best to handle the docs for a renamed module?
* M.-A. Lemburg wrote: > On 2008-05-12 04:34, Brett Cannon wrote: > > For the sake of argument, let's consider the Queue module. It is now > > named queue. For 2.6 I plan on having both Queue and queue listed in > > the index, with Queue deprecated with instructions to use the new > > name. > > > > But what to do about all the references. Should we leave them pointing > > at Queue to lessen confusion for people who read about some module on > > some other site that isn't using the new name, or update everything in > > 2.6 to use the new name? > > How hard would it be to add a redirects from the old pages to the > new ones ? > > mod_rewrite does wonders - well, provided you find the right patterns... The "pattern" can be a simple text file maintained in subversion:: oldurl newurl ... And then you can utilize RewriteMap to get that into the apache. nd ___ 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 best to handle the docs for a renamed module?
On 2008-05-12 04:34, Brett Cannon wrote: For the sake of argument, let's consider the Queue module. It is now named queue. For 2.6 I plan on having both Queue and queue listed in the index, with Queue deprecated with instructions to use the new name. But what to do about all the references. Should we leave them pointing at Queue to lessen confusion for people who read about some module on some other site that isn't using the new name, or update everything in 2.6 to use the new name? How hard would it be to add a redirects from the old pages to the new ones ? mod_rewrite does wonders - well, provided you find the right patterns... -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 16 2008) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ 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] SSH connection sharing
Hello! I would like to share a useful tip on how to speedup many short ssh (scp, rsync, svn over ssh) sessions (on Unix). Sorry if this information is widely known; I learned the trick a week ago and I am pretty happy with it. OpenSSH4 on Unix allows connection sharing - utilizing one authenticated TCP connection for a number of SSH sessions. The advantage is that subsequent connections don't need to open a new TCP connections and don't need to pass the authentication phase, thus they initialize a session much faster. This is very useful for running a lot of short ssh sessions (scp, sftp, rsync, svn over ssh). Detailed docs are in man ssh_config; see options ControlMaster and ControlPath. There is a lot of information_ on the web. .. _information: http://www.google.com/search?hl=en&ie=utf-8&oe=utf-8&q=ssh%20ControlPath Add the following to your ~/.ssh/config:: ControlMaster auto ControlPath ~/.ssh/[EMAIL PROTECTED]:%p *ControlMaster auto* means the first client becomes the master, it opens TCP connection, authenticates and opens a unix socket named in ControlPath. Subsequent clients use the unix socket to connect to the server via the already established connection. In case the user tries to close the first (master) client it will wait until all sessions are finished; in case the user kills the master, it kills all its shared sessions. I use all 3 recommended macros, because I use ssh/scp/sftp/rsync/svn to connect to a number of servers. Drawbacks: the subsequent connections inherit some attributes of the master; agent forwarding, e.g. If ssh (or the OS, or even the entire computer) crashes one needs to remove unix sockets manually; to remedy this I changed ControlPath to ~/.ssh/controls/[EMAIL PROTECTED]:%p and added to my crontab:: @reboot rm -f .ssh/controls/* Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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 parallel benchmark
2008/5/16 Hrvoje Nikšić <[EMAIL PROTECTED]>:
> On Fri, 2008-05-16 at 08:04 -0400, Tom Pinckney wrote:
> > Here's one example, albeit from a few years ago
> >
> > http://aspn.activestate.com/ASPN/Mail/Message/numpy-discussion/1625465
>
> Thanks for the pointer. I'm not sure I fully understand Konrad Hinsen's
> concerns, but maybe the problem is that Numpy's "number-crunching" needs
> to call back into Python frequently. The notion of "releasing the GIL
> for number-crunching" assumes that the code is structured like this:
>
> 1. code that works with python objects ...
> 2. acquire pointer to a C struct/array ...
> 3. release GIL
> 4. work with C objects ("crunch the numbers") without calling any Python
> code and without touching Python objects or refcounts
> 5. reacquire GIL
>
> If step 4 needs to call into Python frequently, then this strategy won't
> really work.
>
Hi,
The current version of Numpy releases as soon as possible the GIL. The usual
macros for starting and stopping a GIL release (as advertised in the
documentation) are present for every step 4 work, whenever is possible (for
instance it is the case for universal functions which are used in a lot of
numpy's functions).
Matthieu
--
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher
___
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 parallel benchmark
On Fri, 2008-05-16 at 08:04 -0400, Tom Pinckney wrote:
> Here's one example, albeit from a few years ago
>
> http://aspn.activestate.com/ASPN/Mail/Message/numpy-discussion/1625465
Thanks for the pointer. I'm not sure I fully understand Konrad Hinsen's
concerns, but maybe the problem is that Numpy's "number-crunching" needs
to call back into Python frequently. The notion of "releasing the GIL
for number-crunching" assumes that the code is structured like this:
1. code that works with python objects ...
2. acquire pointer to a C struct/array ...
3. release GIL
4. work with C objects ("crunch the numbers") without calling any Python
code and without touching Python objects or refcounts
5. reacquire GIL
If step 4 needs to call into Python frequently, then this strategy won't
really work.
___
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 parallel benchmark
Here's one example, albeit from a few years ago http://aspn.activestate.com/ASPN/Mail/Message/numpy-discussion/1625465 But, I am a numpy novice and so no idea what it actually does in its current form. On May 16, 2008, at 4:17 AM, Hrvoje Nik?i? wrote: On Thu, 2008-05-15 at 21:02 -0400, Tom Pinckney wrote: I found some other references where people were expressing concern over numpy releasing the GIL due to the fact that other C extensions could call numpy and unexpectedly have the GIL released on them (or something like that). Could you please post links to those? I'm asking because AFAIK that concern doesn't really stand. Any (correct) code that releases the GIL is responsible for reacquiring it before calling *any* Python code, in fact before doing anything that might touch a Python object or its refcount. ___ 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/thomaspinckney3%40gmail.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] Distutils & configparser rename
A.M. Kuchling wrote: * There's no standalone distutils package on PyPI, nor can I find such a package with a general web search. Am I missing it? * I do not see users advising other users to use a later version of Distutils to fix their problems. Is anyone actually benefiting from the effort of maintaining backward compatibility? I remember this discussion coming up before the 2.5 release when the distutils version number was changed to depend on the python instance instead of a static string. MAL was made very upset that the SVN trunk version of distutils could no longer be pulled out seperately. But at that time, you had removed it from PEP 291, officially renouncing this practice. I believe the conclusion was that MAL's request to maintain psuedo-backward-compatibility would be upheld despite not having official status. http://mail.python.org/pipermail/python-dev/2006-August/068250.html -Scott -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ 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] Symbolic errno values in error messages
Hi, I spent some time googleing for "OSError 4" before it occurred to me that "4" was actually an irrelevant implementation detail. As soon as I searched for "EINTR", I found exactly what I was looking for. (not really but this is another story) I jumped to the conclusion that OSError.__str__() should return the symbolic error number instead of the integer value. I was about to write a patch but I just noticed that OSError and friends are implemented in C so I guess it will be a bit harder than expected. The error message comes from EnvironmentError.__str__() which is implemented by EnvironmentError_str() in Objects/exceptions.c. A Python implementation could have replaced self.errno in the format string args by errno.errorcode[self.errno]. However, it's not clear to me if there is such a mapping available in C. Since my fix is not as trivial as I expected, I ask for advice regarding the following questions: 1) Should OSError.__str__() print the symbolic name of errno? 2) Where can I find the symbolic name in C? Best regards, -- Yannick Gingras ___ 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] rename of ConfigParser module?
Martin v. Lo"wis wrote: (Hmm, is changing Modules/Setup enough to sort the Windows build out as well? Or does that need a separate change to some of the Visual Studio files?) The latter. Whenever you add, remove, or rename an extension module, you need to adjust the PCbuild files as well. (technically, you also have to adjust PC/os2emx/Makefile, PC/os2vacpp/makefile.omk, and PC/VC6, but these changes are waived). OS/2 fixes are something I'll address during the betas. -- - Andrew I MacIntyre "These thoughts are mine alone..." E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370 [EMAIL PROTECTED] (alt) |Belconnen ACT 2616 Web:http://www.andymac.org/ |Australia ___ 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] Addition of "pyprocessing" module to standard lib.
Nick Craig-Wood wrote: Jesse Noller <[EMAIL PROTECTED]> wrote: I am looking for any questions, concerns or benchmarks python-dev has regarding the possible inclusion of the pyprocessing module to the standard library - preferably in the 2.6 timeline. In March, I began working on the PEP for the inclusion of the pyprocessing (processing) module into the python standard library[1]. The original email to the stdlib-sig can be found here, it includes a basic overview of the module: http://mail.python.org/pipermail/stdlib-sig/2008-March/000129.html The processing module mirrors/mimics the API of the threading module - and with simple import/subclassing changes depending on the code, allows you to leverage multi core machines via an underlying forking mechanism. The module also supports the sharing of data across groups of networked machines - a feature obviously not part of the core threading module, but useful in a distributed environment. I think processing looks interesting and useful, especially since it works on Windows as well as Un*x. However I'd like to see a review of the security - anything which can run across networks of machines has security implications and I didn't see these spelt out in the documentation. Networked running should certainly be disabled by default and need explicitly enabling by the user - I'd hate for a new version of python to come with a remote exploit by default... As long as the ctypes extension doesn't build on major Un*x platforms (AIX, HP-UX), I don't like to see ctypes dependend modules included into the stdlib. Please keep the stdlib as portable as possible. More and more people tend to say "Runs on Un*x" when they really mean "Tested on Linux". Un*x is not Linux. Ulli ___ 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 parallel benchmark
On Thu, 2008-05-15 at 21:02 -0400, Tom Pinckney wrote: > I found some other references where people were expressing concern > over numpy releasing the GIL due to the fact that other C extensions > could call numpy and unexpectedly have the GIL released on them (or > something like that). Could you please post links to those? I'm asking because AFAIK that concern doesn't really stand. Any (correct) code that releases the GIL is responsible for reacquiring it before calling *any* Python code, in fact before doing anything that might touch a Python object or its refcount. ___ 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] PEP 3138- String representation in Python 3000
2008/5/15 Atsuo Ishimoto <[EMAIL PROTECTED]>:
> With my proposal, print("Hello\u03C8") prints "Hello\u03C8" instead of
> raising an exception. And print(repr("Hello\u03C8")) prints
> "'Hello\u03C8'", so no garbage are printed.
>
> Now, let's say you are Greek and working on Greek version of XP.
> print("Hello\u03C8") prints "Hello"+collect Greek character(GREEK
> SMALL LETTER PSI). And print(repr("Hello\u03C8")) prints
> "'Hello"+collect Greek character+"'". If you have Greek font, you can
> try this if you swich your command prompt by "chcp 1253" (change
> codepage to 1253) on your command prompt.
>
[...]
> Python detects user's capabilities, since Python 2.x(or 1.6? I forgot.)
> On Windows, Python detects user's encoding from codepage. On Unix,
> locale is used to detect encoding.
Ah, thanks. I hadn't realised this - I've had trouble printing Unicode
in the past, and assumed it was a result of Windows' strange console
handling (OEM code pages vs Windows code pages confuse me). I use
Unicode so rarely that it wasn't worth worrying about it, though.
I guess the problem was my understanding, rather than code page
detection not working. Sorry for the confusion.
>> Like it or not, a large proportion of Python's users still work in
>> environments where much of the Unicode character space is not
>> displayed readably.
>>
>
> I agree. So rejecting my proposal as "Not common use-case" might be
> reasonable. But I should argue to get sympathy, anyway:).
As Oleg pointed out, my comment "a large proportion" was a guess, and
an unfounded one at that. And regardless, you definitely have my
sympathy, this is an issue that needs solving :-) (Heck, just the fact
that you have to write your emails to this group in a foreign language
is enough to get you my sympathy!!!)
> I can understand your aware. Perhaps you don't want see your terminal
> flash by escape sequence, beep, endless graphic characters, etc. For
> legacy byte-string applications(whether written in C or Python),
> printing arbitrary string can cause such mess. But this is unlikely to
> happen by printing the Unicode string, since the characters your
> terminal cannot understand will be escaped or be converted to
> character such as '?'.
Ah, that's what the switching of the error mode is for. I understand
more clearly now.
> Hope this helps.
It does - thanks for being patient with me.
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
