Re: [Python-Dev] Module renaming and pickle mechanisms
Benjamin Peterson schrieb: svnmerge is written in Python, so wouldn't it be possible to add support for maintaining such renaming to that tool ? svnmerge.py is mostly a wrapper over svn merge, and svn merge can't handle it, so I don't think is easily possible. I don't think that an administrative problem such as forward- porting patches to 3.x warrants breakage in the 2.x branch. I am a bit worried for the sanity of the Merger, though. Merges into non-existent files are skipped automatically, so it doesn't make life any easier. shameless_advertisingBazaar can handle renames correctly./shameless_advertising So can dozens of other VCSs. Just to keep perspective. Georg ___ 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] Proposal: new environment variable PYTHONSTDOUTENCODING
I'd like to propose a new environment variable PYTHONSTDOUTENCODING. This is meant to solve various problems that people had with Python not detecting their terminal encoding correctly; it would override any detection that Python would use for determining the encoding of stdout (and stdin - but that's less relevant in 2.x). In particular, setting this environment variable would also disable the detection of whether stdout is a terminal. This is desirable for cases as the pydev eclipse plugin, where Python currently fails to detect that the output is a terminal (and technically, what Eclipse provides is not a terminal, but just a pipe, as you can't do pseudoterms in Java). This would have the additional effect that the encoding also gets in effect when redirecting stdout to a file. Whether or not this is a good thing might be debatable; giving the user the control over it (to set or clear that variable) is a good thing, IMO. Naming contest: it probably would be the longest of the PYTHON* variables. I would not want to call it PYTHONENCODING, or PYTHONSTDENCODING, though, because people might infer that it affects sys.getdefaultencoding(), which it shouldn't. 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] Proposal: new environment variable PYTHONSTDOUTENCODING
On 2008-05-20 10:22, Martin v. Löwis wrote: I'd like to propose a new environment variable PYTHONSTDOUTENCODING. This is meant to solve various problems that people had with Python not detecting their terminal encoding correctly; it would override any detection that Python would use for determining the encoding of stdout (and stdin - but that's less relevant in 2.x). How is this relevant for 2.x ? In 2.x, stdin and stdout are just files without any io wrappers around them. Writing Unicode to stdout will still use the default encoding ASCII to convert it to an 8-bit string. All other 8-bit strings will be passed to stdout as-is. For 3.x, I'd like to see a PYTHONSTDINENCODING, because the current way of relying on the terminal encoding does work well... it then falls back to ASCII, which prevents entering e.g. German Umlauts. In particular, setting this environment variable would also disable the detection of whether stdout is a terminal. This is desirable for cases as the pydev eclipse plugin, where Python currently fails to detect that the output is a terminal (and technically, what Eclipse provides is not a terminal, but just a pipe, as you can't do pseudoterms in Java). This would have the additional effect that the encoding also gets in effect when redirecting stdout to a file. Whether or not this is a good thing might be debatable; giving the user the control over it (to set or clear that variable) is a good thing, IMO. Naming contest: it probably would be the longest of the PYTHON* variables. I would not want to call it PYTHONENCODING, or PYTHONSTDENCODING, though, because people might infer that it affects sys.getdefaultencoding(), which it shouldn't. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 20 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] Proposal: new environment variable PYTHONSTDOUTENCODING
On Tue, May 20, 2008 at 10:41 AM, M.-A. Lemburg [EMAIL PROTECTED] wrote: On 2008-05-20 10:22, Martin v. Löwis wrote: I'd like to propose a new environment variable PYTHONSTDOUTENCODING. This is meant to solve various problems that people had with Python not detecting their terminal encoding correctly; it would override any detection that Python would use for determining the encoding of stdout (and stdin - but that's less relevant in 2.x). How is this relevant for 2.x ? In 2.x, stdin and stdout are just files without any io wrappers around them. Writing Unicode to stdout will still use the default encoding ASCII to convert it to an 8-bit string. All other 8-bit strings will be passed to stdout as-is. You're forgetting about print; in Python 2.x, when stdout is connected to a terminal, the locale settings (typically the LANG, LC_ALL and LC_CTYPE environment variables) are taken into account when 'print' writes to sys.stdout. -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] Proposal: new environment variable PYTHONSTDOUTENCODING
On Tue, May 20, 2008 at 12:16 PM, Thomas Wouters [EMAIL PROTECTED] wrote: You're forgetting about print; in Python 2.x, when stdout is connected to a terminal, the locale settings (typically the LANG, LC_ALL and LC_CTYPE environment variables) are taken into account when 'print' writes to sys.stdout. Isn't it then enough to make sure your locale setting are correct? (Never had any problems myself, if works great in Ubuntu). -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ 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] Proposal: new environment variable PYTHONSTDOUTENCODING
On Tue, May 20, 2008 at 10:22:37AM +0200, Martin v. L?wis wrote: I'd like to propose a new environment variable PYTHONSTDOUTENCODING. This is meant to solve various problems that people had with Python not detecting their terminal encoding correctly; it would override any detection that Python would use for determining the encoding of stdout (and stdin - but that's less relevant in 2.x). Is it to override locale settings in case the user wants a different encoding? for such cases as redirected stdout, or windows console (which has an OEM encoding that differs from the locale encoding)? Naming contest: it probably would be the longest of the PYTHON* variables. I would not want to call it PYTHONENCODING, or PYTHONSTDENCODING, though, because people might infer that it affects sys.getdefaultencoding(), which it shouldn't. PYTHONIOENCODING? 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] Proposal: new environment variable PYTHONSTDOUTENCODING
On 2008-05-20 12:16, Thomas Wouters wrote: On Tue, May 20, 2008 at 10:41 AM, M.-A. Lemburg [EMAIL PROTECTED] wrote: On 2008-05-20 10:22, Martin v. Löwis wrote: I'd like to propose a new environment variable PYTHONSTDOUTENCODING. This is meant to solve various problems that people had with Python not detecting their terminal encoding correctly; it would override any detection that Python would use for determining the encoding of stdout (and stdin - but that's less relevant in 2.x). How is this relevant for 2.x ? In 2.x, stdin and stdout are just files without any io wrappers around them. Writing Unicode to stdout will still use the default encoding ASCII to convert it to an 8-bit string. All other 8-bit strings will be passed to stdout as-is. You're forgetting about print; in Python 2.x, when stdout is connected to a terminal, the locale settings (typically the LANG, LC_ALL and LC_CTYPE environment variables) are taken into account when 'print' writes to sys.stdout. Thanks for reminding me. I had forgotten about that special case. So sys.stdout.write(unicode) will always use the default encoding, whereas print unicode uses the sys.stdout.encoding, correct ? Hmm, wouldn't it be better to always use .encoding and also make it adjustable from Python (it is adjustable from C) ?! PYTHONSTDOUTENCODING could then provide the default to sys.stdout.encoding. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 20 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] Proposal: new environment variable PYTHONSTDOUTENCODING
On Tue, May 20, 2008 at 12:48 PM, Oleg Broytmann [EMAIL PROTECTED] wrote: On Tue, May 20, 2008 at 10:22:37AM +0200, Martin v. L?wis wrote: I'd like to propose a new environment variable PYTHONSTDOUTENCODING. This is meant to solve various problems that people had with Python not detecting their terminal encoding correctly; it would override any detection that Python would use for determining the encoding of stdout (and stdin - but that's less relevant in 2.x). Is it to override locale settings in case the user wants a different encoding? for such cases as redirected stdout, or windows console (which has an OEM encoding that differs from the locale encoding)? Naming contest: it probably would be the longest of the PYTHON* variables. I would not want to call it PYTHONENCODING, or PYTHONSTDENCODING, though, because people might infer that it affects sys.getdefaultencoding(), which it shouldn't. PYTHONIOENCODING? What about PYTHONLANG ? or something that tries to reflect which environment variables are used for this ? (LC_CTYPE - PYTHONCTYPE ? if the code uses just LC_CTYPE) http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html#tag_08_02 Just for my own knowledge: why it has to be one word ? can't it be PYTHON_LANG ? Tarek 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/ziade.tarek%40gmail.com -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.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] Addition of pyprocessing module to standard lib.
On Mon, May 19, 2008 at 06:13:11PM -0700, Bill Janssen wrote: And these are all SYSV derivatives, aren't they? So perhaps it's some common fix for all three? This reminds of a Tim-ism: == Just for the record, on AIX, the following C program: Oh no you don't! I followed AIX threads for the first year it came out, but eventually decided there was no future in investing time in baffling discussions that usually ended with oh, never mind -- turns out it's a bug 0.9 wink. Vladimir Marangozov and Tim Peters, 23 Jun 1998 == 10 years later, things don't seem to be much different. For ctypes it looks like libffi often fails to compile when not using GCC; http://bugs.python.org/issue1637120 is an AIX bug report. For the curses module, I've noticed that HP-UX seems to require including additional header files or defining _XOPEN_SOURCE to make curses.h work. So I don't think there's a common problem with all these minority platforms, and we really would need developers on all of them. --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] Addition of pyprocessing module to standard lib.
Bill Janssen wrote: And these are all SYSV derivatives, aren't they? So perhaps it's some common fix for all three? I've never personally had the pleasure(?!) of having to get stuff working on all of AIX/HP-UX/Tru64/Solaris, but what little dealings I've had with people who have suggests that the differences between these platforms make the discrepancies between different Linux distributions look utterly trivial by comparison. 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.
A.M. Kuchling [EMAIL PROTECTED] wrote: On Mon, May 19, 2008 at 08:50:39PM +0200, Thomas Heller wrote: Myself I would rather spend my energy to make ctypes more portable, within my skills and the platforms I have access to. Someone could run Solaris x86 inside a hosted virtual machine and make it available to the Python developers. Is it possible to find similar hosting for HP-UX and AIX? Or might IBM or HP be willing to donate a low-end machine to the PSF for porting use? You can test HPUX and VMS with a (free) HP Testdrive account (along with a bunch of Linuxes and *BSDs) on various hardware platforms. I used it extensively when doing portability testing of another project. http://www.testdrive.hp.com/ Charles -- --- Charles Cazabon GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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.
Charles Cazabon schrieb: A.M. Kuchling [EMAIL PROTECTED] wrote: On Mon, May 19, 2008 at 08:50:39PM +0200, Thomas Heller wrote: Myself I would rather spend my energy to make ctypes more portable, within my skills and the platforms I have access to. Someone could run Solaris x86 inside a hosted virtual machine and make it available to the Python developers. Is it possible to find similar hosting for HP-UX and AIX? Or might IBM or HP be willing to donate a low-end machine to the PSF for porting use? You can test HPUX and VMS with a (free) HP Testdrive account (along with a bunch of Linuxes and *BSDs) on various hardware platforms. I used it extensively when doing portability testing of another project. http://www.testdrive.hp.com/ Charles I'm doing that. From time to time, these systems are a pain to use IMO. A buildbot is s much better... -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Issue 643841: Including a new-style proxy base class in 2.6/3.0
One of the tasks where classic classes are currently far superior to new-style classes is in writing proxy classes like weakref.proxy - cases where nearly all operations need to be delegated to some other object, with only a few being handled via the proxy type object itself. With classic classes, this is trivial, since __getattr__ is always consulted, even for retrieval of special methods. With new-style classes, however, the __getattribute__ machinery can be bypassed, meaning the only way to proxy an arbitrary instance is to define all of the special methods that have C-level slots. This issue was actually first raised five and a half years ago [1], but has never been a particularly pressing problem, as anyone with any sense that needed to write a proxy object just used a classic class instead of a new-style one. In 3.0, with the demise of classic classes, that workaround goes away. So what do people think of including a ProxyBase implementation in 2.6 and 3.0 that explicitly delegates all of the C-level slots to a designated target instance? For some proxy class implementers, it would be possible to use this class as a base-class to get the special method delegation 'for free', and for others with more esoteric needs, it would at least provide a reference for which special methods needed to be provided explicitly by the proxy type. I attached a sample implementation to [1] which is essentially equivalent to weakref.proxy, but with a strong reference to the target, and written in Python rather than C. I expect the target audience for such a feature to be quite small, but without better support for it in the standard library, I also suspect it could prove to be a show-stopper for the affected developers as far as Py3k migration is concerned. Cheers, Nick. [1] http://bugs.python.org/issue643841 -- 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] Issue 643841: Including a new-style proxy base class in 2.6/3.0
Nick Coghlan wrote: One of the tasks where classic classes are currently far superior to new-style classes is in writing proxy classes like weakref.proxy - cases where nearly all operations need to be delegated to some other object, with only a few being handled via the proxy type object itself. I've needed to do this a few times when wrapping libraries. Michael Foord With classic classes, this is trivial, since __getattr__ is always consulted, even for retrieval of special methods. With new-style classes, however, the __getattribute__ machinery can be bypassed, meaning the only way to proxy an arbitrary instance is to define all of the special methods that have C-level slots. This issue was actually first raised five and a half years ago [1], but has never been a particularly pressing problem, as anyone with any sense that needed to write a proxy object just used a classic class instead of a new-style one. In 3.0, with the demise of classic classes, that workaround goes away. So what do people think of including a ProxyBase implementation in 2.6 and 3.0 that explicitly delegates all of the C-level slots to a designated target instance? For some proxy class implementers, it would be possible to use this class as a base-class to get the special method delegation 'for free', and for others with more esoteric needs, it would at least provide a reference for which special methods needed to be provided explicitly by the proxy type. I attached a sample implementation to [1] which is essentially equivalent to weakref.proxy, but with a strong reference to the target, and written in Python rather than C. I expect the target audience for such a feature to be quite small, but without better support for it in the standard library, I also suspect it could prove to be a show-stopper for the affected developers as far as Py3k migration is concerned. Cheers, Nick. [1] http://bugs.python.org/issue643841 ___ 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 Mon, 19 May 2008, Bill Janssen wrote: On Mon, May 19, 2008 at 5:15 PM, Bill Janssen [EMAIL PROTECTED] wrote: If you can run a pure Python module that does not depend on any C extension, then that platform has the support needed to run Python. This is certainly a point of view. One that many end-users wouldn't understand :-). Perhaps, but it's clear-cut. Is OS X not properly supported because it can't run the _winreg module? I just don't like labeling a platform as unsupported just because ctypes doesn't compile on it. I assume _winreg runs everywhere Python is said to run, and there's a Windows registry to examine, so I think it's a different kettle of fish. ctypes doesn't run everywhere Python is said to run, and there are dynamic libraries to call into. I think it would be great if we could get some AIX, HP-UX, and Solaris boxes for Thomas to work on. What would motivate IBM, H-P, and Sun to donate such gear? Perhaps each of the companies have an office somewhere that could help with this resource allocation? For instance, talking to the AIX Collaboration Center of IBM ([EMAIL PROTECTED])? And these are all SYSV derivatives, aren't they? So perhaps it's some common fix for all three? I just spent a semester in Advanced Systems Programming in Unix/C, and all we did was port old software to solaris, hpux, irix, and friends (I don't think we used AIX, but I believe he has one running). Most of these were virtual machines, but they adequately represented the annoyances present in their respective architectures. I've cc'd my professor, hopefully he will let me know if there are any tips he has for setting up a VM. -- Cheers, Leif ___ 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] Proposal: new environment variable PYTHONSTDOUTENCODING
Writing Unicode to stdout will still use the default encoding ASCII to convert it to an 8-bit string. That's not true. 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] Proposal: new environment variable PYTHONSTDOUTENCODING
You're forgetting about print; in Python 2.x, when stdout is connected to a terminal, the locale settings (typically the LANG, LC_ALL and LC_CTYPE environment variables) are taken into account when 'print' writes to sys.stdout. Isn't it then enough to make sure your locale setting are correct? (Never had any problems myself, if works great in Ubuntu). It's much more difficult on OS X, for example, which doesn't really support the concept of locales (at least prior to 10.5). There are other odd cases, like the Eclipse one I mentioned. Setting the locale doesn't help there. 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.
Steve Holden wrote: The more libraries that use ctypes to call into native functionality, the more important it becomes to have ctypes run, even if only to implement platform-specific functionality on the given platforms. I would like being able to call a wide range of native libraries to be a Python claim on all platforms, even when the native libraries are platform-proprietary. Yes, I'd like to see this happen, too. Bill ___ 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] Proposal: new environment variable PYTHONSTDOUTENCODING
PYTHONSTDOUTENCODING could then provide the default to sys.stdout.encoding. Right - that's the proposal. 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
[Python-Dev] Possible bug in re module?
I've just found a strange re behavior:
import re
re.sub((?:ab|b|a), +, cbacbabcabc)
'c++c++c+c'
re.sub((?:ab|b|a){2}, +, cbacbabcabc)
'c+c+c+c'
In the last case |-separated expressions seems don't tried from left to
right. Is it bug or just me?
--
Dmitry Vasiliev dima at hlabs.spb.ru
http://hlabs.spb.ru
signature.asc
Description: OpenPGP digital signature
___
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] Proposal: new environment variable PYTHONSTDOUTENCODING
On 2008-05-20 20:23, Martin v. Löwis wrote: Writing Unicode to stdout will still use the default encoding ASCII to convert it to an 8-bit string. That's not true. Are you sure ? setenv LC_ALL de_DE.utf8 python2.5 Python 2.5 (r25:51908, May 9 2007, 00:53:06) u = u'äöü' sys.stdout.write(u) Traceback (most recent call last): File stdin, line 1, in module UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-2: ordinal not in range(128) print u äöü Only print will set the Py_PRINT_RAW flag to trigger the conversion from Unicode to 8-bit strings using .encoding in PyFile_WriteObject(). If not set, the default encoding is used. I'm not exactly sure why, since using .encoding would be useful in all cases. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 20 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] Proposal: new environment variable PYTHONSTDOUTENCODING
I'm not exactly sure why, since using .encoding would be useful in all cases. Right, I think it should use the file's encoding also for .write. 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] Possible bug in re module?
On Tue, 20 May 2008, Dmitry Vasiliev wrote:
I've just found a strange re behavior:
import re
re.sub((?:ab|b|a), +, cbacbabcabc)
'c++c++c+c'
re.sub((?:ab|b|a){2}, +, cbacbabcabc)
'c+c+c+c'
In the last case |-separated expressions seems don't tried from left to right.
Is it bug or just me?
What were you expecting, 'c+c+cabc'? The re engine should try
everything possible for a match with the entire re, not just match the
first thing it finds for each section.
--
Cheers,
Leif
___
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.
Bill Janssen schrieb: Hmm, perhaps the ctypes documentation could use a more prominent warning that it may not be available on some Unix platforms (HP-UX, AIX, IRIX), and that it may require the use of GCC rather than the vendor compiler on others (Solaris). At the moment, I suspect some projects may be switching to using it without realising the implications for cross-platform portability. I think it's a tad more problematic. As other modules, both in and out of the standard library, move to use ctypes, it implies that *Python* isn't supported on those combinations. Personally, that's fine with me (as long as there's a workaround for Solaris!), but I think that Ulrich is right in saying this should be more prominent. I won't object if anyone adds this notice to the Python docs, so please go ahead. A table of platforms (on the wiki?) where ctypes builds/works or does not may also be helpful. What happens on those platforms where ctypes doesn't work? Does the module fail to import, either because it isn't present, or because it can't load the libffi library? Or does it fail silently in some way? Bill ___ 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] Possible bug in re module?
* Dmitry Vasiliev wrote:
I've just found a strange re behavior:
import re
re.sub((?:ab|b|a), +, cbacbabcabc)
'c++c++c+c'
re.sub((?:ab|b|a){2}, +, cbacbabcabc)
'c+c+c+c'
In the last case |-separated expressions seems don't tried from left to
right. Is it bug or just me?
Looks fine to me.
(Although if I understand that correctly, the userlist would be more
appropriate).
nd
--
Das Verhalten von Gates hatte mir bewiesen, dass ich auf ihn und seine
beiden Gefährten nicht zu zählen brauchte -- Karl May, Winnetou III
Im Westen was neues: http://pub.perlig.de/books.html#apache2
___
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] Proposal: new environment variable PYTHONSTDOUTENCODING
Is it to override locale settings in case the user wants a different encoding? for such cases as redirected stdout, or windows console (which has an OEM encoding that differs from the locale encoding)? On Windows, the setlocale mechanism isn't used at all, since it doesn't support nl_langinfo (let alone CODESET). And yes, that is to override whatever determination Python would make on its own. Naming contest: it probably would be the longest of the PYTHON* variables. I would not want to call it PYTHONENCODING, or PYTHONSTDENCODING, though, because people might infer that it affects sys.getdefaultencoding(), which it shouldn't. PYTHONIOENCODING? Unprecise in a different way (as it is meant to apply only to stdout, not to all IO), but shorter. 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] Proposal: new environment variable PYTHONSTDOUTENCODING
What about PYTHONLANG ? or something that tries to reflect which environment variables are used for this ? (LC_CTYPE - PYTHONCTYPE ? if the code uses just LC_CTYPE) It's not meant to name a locale, but an encoding. In fact, that the encoding is tied to the locale is IMO a misconception in the POSIX locale machinery. http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html#tag_08_02 Just for my own knowledge: why it has to be one word ? can't it be PYTHON_LANG ? No technical reason - just because PYTHONPATH, PYTHONHOME, PYTHONUNBUFFERED, PYTHONVERBOSE, PYTHONSTARTUP, and PYTHONCASEOK don't have underscores, either. 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.
r.m.oudkerk schrieb: 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. I can neither find recvfd in my man pages nor in my header files in /usr/include on Linux (Ubuntu 8.04 i686). I assume recvfd and sendfd aren't syscalls but the proposed names for the functions. (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 do you want to put the named pipes into the _subprocess module? IMHO the socket module is more appropriate for communication channels like name pipes. (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().) Interesting idea. The approach could safe us some trouble. I'm always +1 when it comes to removing ugly hacks. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal: new environment variable PYTHONSTDOUTENCODING
On Tue, May 20, 2008 at 10:22:03PM +0200, Martin v. L?wis wrote: PYTHONIOENCODING? Unprecise in a different way (as it is meant to apply only to stdout, not to all IO), but shorter. I don't think you can make it both precise and short. If you want to be precise and have both PYTHON and STDOUT - shorten ENCODING to ENC. If you agree to sacrifice PYTHON - make it PYSTDOUTENCODING. 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] Addition of pyprocessing module to standard lib.
Ted Leung wrote: On May 19, 2008, at 7:47 PM, Steve Holden wrote: OK, I know people in Sun and possibly H-P I could ask, and I may have an arm or two to twist to get to IBM. But worst-case, what budget would the infrastructure committee need for the hardware and (more importantly) if the hardware materialized, would there be manpower to maintain the platforms as Python supported? You can ask me as far as Sun goes. There are probably a variety of options: 1) Get the open source version of VirtualBox and use it to run a virtualized OpenSolaris 2) I can see if we can get folks access to a box running Solaris 3) I can ask and see if there are people at Sun who would be willing to jump in and help We actually have a couple of Solaris buildbots already - as I understand it, the issue there isn't Solaris as such, it's being able to use the Sun compiler instead of GCC to compile ctypes/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
[Python-Dev] disappearing exceptions
In several places in the C code, there are instances where all exceptions can be completely ignored (akin to a bare except statement.) after a PyObject_GetAttr call. A week ago, I fixed one of these in hasattr (issue 2196) by propagating exceptions that don't inherit Exception (SystemExit, KeyboardInterrupt). However, there is another patch that propagates anything that is not a AttributeError (issue 1574217). How should we approach this? -- Cheers, Benjamin Peterson There's no place like 127.0.0.1. ___ 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 May 20, 2008, at 2:03 PM, Nick Coghlan wrote: We actually have a couple of Solaris buildbots already - as I understand it, the issue there isn't Solaris as such, it's being able to use the Sun compiler instead of GCC to compile ctypes/libffi. Does that mean that we need access to the Sun compiler or that the Sun compiler has bugs which prevent ctypes from compiling? Ted ___ 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] disappearing exceptions
Benjamin Peterson schrieb:
In several places in the C code, there are instances where all
exceptions can be completely ignored (akin to a bare except
statement.) after a PyObject_GetAttr call.
A week ago, I fixed one of these in hasattr (issue 2196) by
propagating exceptions that don't inherit Exception (SystemExit,
KeyboardInterrupt). However, there is another patch that propagates
anything that is not a AttributeError (issue 1574217).
How should we approach this?
Oh, you are bringing something to my mind. In Python 2.x hasattr()
swallows every exception. This is a major issue for applications like
ZODB, because database conflict errors must be propagated to the
conflict resolution machinery.
Shane Hathaway said once:
---
That said, I was surprised to discover that Python 2.3 implements
hasattr this way (from bltinmodule.c):
v = PyObject_GetAttr(v, name);
if (v == NULL) {
PyErr_Clear();
Py_INCREF(Py_False);
return Py_False;
}
Py_DECREF(v);
Py_INCREF(Py_True);
return Py_True;
It should not swallow all errors, especially now that descriptors make
computed attributes quite common. getattr() only recently started
catching only AttributeErrors, but apparently hasattr is lagging behind.
I suggest the consistency between getattr and hasattr should be fixed
in Python, not Zope.
---
Thankfully this issue was fixed in Python 2.6 and 3.0. In newer versions
of Python hasattr() only swallows exception based on the Exception class
but not BaseExceptions. We should make sure all code in the core behaves
the same way. Exceptions based on BaseException must *never* be
swallowed. The behavior may even be worse a macro and it should be
documented in large, friendly and red letters in the C API docs. *wink*
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Addition of pyprocessing module to standard lib.
Ted Leung wrote: On May 20, 2008, at 2:03 PM, Nick Coghlan wrote: We actually have a couple of Solaris buildbots already - as I understand it, the issue there isn't Solaris as such, it's being able to use the Sun compiler instead of GCC to compile ctypes/libffi. Does that mean that we need access to the Sun compiler or that the Sun compiler has bugs which prevent ctypes from compiling? I don't think anyone's mentioned Solaris in this context, but there are claims that libffi doesn't build for AIX and HP-UX. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.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] disappearing exceptions
On Tue, May 20, 2008 at 5:38 PM, Christian Heimes [EMAIL PROTECTED] wrote: Thankfully this issue was fixed in Python 2.6 and 3.0. In newer versions of Python hasattr() only swallows exception based on the Exception class but not BaseExceptions. We should make sure all code in the core behaves the same way. Exceptions based on BaseException must *never* be swallowed. The behavior may even be worse a macro and it should be documented in large, friendly and red letters in the C API docs. *wink* Speaking of the C-API, I was thinking of introducing a new function called PyObject_SafeHasAttr that functions just like PyObject_HasAttr except it can fail. Christian -- Cheers, Benjamin Peterson There's no place like 127.0.0.1. ___ 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.
Does that mean that we need access to the Sun compiler or that the Sun compiler has bugs which prevent ctypes from compiling? I don't think anyone's mentioned Solaris in this context, but there are claims that libffi doesn't build for AIX and HP-UX. I think there was also an issue with using the Sun compiler to build ctypes and/or libffi. Bill ___ 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] disappearing exceptions
Benjamin Peterson schrieb: Speaking of the C-API, I was thinking of introducing a new function called PyObject_SafeHasAttr that functions just like PyObject_HasAttr except it can fail. How do you define fail in this context? Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] disappearing exceptions
On Tue, May 20, 2008 at 6:44 PM, Christian Heimes [EMAIL PROTECTED] wrote: Benjamin Peterson schrieb: Speaking of the C-API, I was thinking of introducing a new function called PyObject_SafeHasAttr that functions just like PyObject_HasAttr except it can fail. How do you define fail in this context? If PyObject_GetAttr raises an exception that is not an AttributeError, it can return -1 to fail. -- Cheers, Benjamin Peterson There's no place like 127.0.0.1. ___ 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] Issue 643841: Including a new-style proxy base class in 2.6/3.0
Nick Coghlan wrote: So what do people think of including a ProxyBase implementation in 2.6 and 3.0 that explicitly delegates all of the C-level slots to a designated target instance? Sounds good to me. -- Greg ___ 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.
Christian Heimes wrote: I assume recvfd and sendfd aren't syscalls but the proposed names for the functions. Yes, the functionality in question is accessed through the sendmsg() and recvmsg() system calls. -- Greg ___ 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] disappearing exceptions
Christian Heimes wrote: Thankfully this issue was fixed in Python 2.6 and 3.0. In newer versions of Python hasattr() only swallows exception based on the Exception class but not BaseExceptions. Shouldn't it only be catching AttributeError, though? We should make sure all code in the core behaves the same way. Exceptions based on BaseException must *never* be swallowed. Seems to me that all code in the core that catches exceptions should only be catching the exceptions it really needs to catch. That requires looking at each case individually rather than a blanket catch Exception recommendation (although that might still be an improvement over the status quo). -- Greg ___ 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] disappearing exceptions
I wrote: Shouldn't it only be catching AttributeError, though? Forget that, I forgot that PyObject_HasAttr can't signal an exception. The Py3 C API should be designed to fix this, I think. -- Greg ___ 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] Issue 643841: Including a new-style proxy base class in 2.6/3.0
Nick Coghlan wrote: So what do people think of including a ProxyBase implementation in 2.6 and 3.0 that explicitly delegates all of the C-level slots to a designated target instance? On May 20, 2008, at 7:55 PM, Greg Ewing wrote: Sounds good to me. Same here. There's an implementation in zope.proxy which might be useful as a starting point: http://pypi.python.org/pypi/zope.proxy/3.4.0 I'd be willing to write the required documentation, since I'm partly to blame for the implementation. The short description of the package on PyPI contains a typo; that's been fixed in Subversion. :-) -Fred -- Fred Drake fdrake at acm.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] disappearing exceptions
Greg writes: Christian Heimes wrote: Thankfully this issue was fixed in Python 2.6 and 3.0. In newer versions of Python hasattr() only swallows exception based on the Exception class but not BaseExceptions. Shouldn't it only be catching AttributeError, though? This has come up before - eg http://www.mail-archive.com/[EMAIL PROTECTED]/msg11630.html - which itself starts with the words This issue has been raised before :) It points at http://bugs.python.org/issue504714 regarding 2.x - however, if you follow that thread above, it seems Guido is against changing this behaviour even for 3k. cheers, Mark ___ 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.
I can neither find recvfd in my man pages nor in my header files in /usr/include on Linux (Ubuntu 8.04 i686). I assume recvfd and sendfd aren't syscalls but the proposed names for the functions. Yes (and no). The system call is sendmsg, with a cmsg_type of SCM_RIGHTS. I don't think there is a plan to add library functions with that name. 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
