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
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] 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] rename of ConfigParser module?
Martin v. Lowis 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
[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] 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] 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
[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=enie=utf-8oe=utf-8q=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] 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
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] 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] Symbolic errno values in error messages
Yannick Gingras ygingras at 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] 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
Alexander Belopolsky wrote: Yannick Gingras ygingras at 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
On Sat, 17 May 2008 00:15:23 +1000, Nick Coghlan [EMAIL PROTECTED] wrote: Alexander Belopolsky wrote: Yannick Gingras ygingras at 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
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
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: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] 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 2008-05-16 16:15, Nick Coghlan wrote: Alexander Belopolsky wrote: Yannick Gingras ygingras at 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.
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 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.
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 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.
[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] 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] 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] 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] 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] 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] 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] 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
