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 tha
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 determini
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
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
>
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 P
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 P
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
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
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 tha
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
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 Sol
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 clas
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
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 material
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 certai
> 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:
>> 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
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"
> 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.
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
http
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
> 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
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
> 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 t
* 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.
On 2008-05-20 21:34, Martin v. Löwis wrote:
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.
Could you add that to the proposal ?!
Please also add the ability to set the .encoding on file objects.
>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_la
> 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 misconcep
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 descr
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 PYT
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 ha
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,
Keyboar
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 S
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
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
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 behav
> > 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 i
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
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 "fai
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@
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-D
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 beha
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
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 i
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
> 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
>> 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 bu
Martin v. Löwis schrieb:
>>> 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
> Could it be a solution to build libffi with gcc, then configure Python
> with '--with-system--ffi' and compile with the sun compiler, or would this
> introduce the dependencies on libgcc or whatever again that Ulrich wanted
> to avoid?
It depends on the processor and the code, but chances are hi
49 matches
Mail list logo
