M.-A. Lemburg:
> > 2) Return unicode when the text can not be represented in ASCII. This
> > will cause a change of behaviour for existing code which deals with
> > non-ASCII data.
>
> +1 on this one (s/ASCII/Python's default encoding).
I assume you mean the result of sys.getdefaultencoding()
Patch / Bug Summary
___
Patches : 349 open ( +1) / 2880 closed ( +1) / 3229 total ( +2)
Bugs: 897 open ( -1) / 5119 closed (+16) / 6016 total (+15)
RFE : 194 open ( +1) / 170 closed ( +0) / 364 total ( +1)
New / Reopened Patches
__
PEP 343 d
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
I don't see how that works. Somehow we need to decide whether to put
main in ccpython.o in the first place, don't we?
>>>
>
> You wouldn't have to ask these questions if you had investigated the
> answers yourself.
The
[Michael Hudson]
> --with-fpectl, for example. Does anyone lurking here actually use
> that, know what it does and require the functionality? Inquiring
> minds want to know.
I know what it intends to do: fpectlmodule.c intends to enable the HW
FPU divide-by-0, overflow, and invalid operation tr
Christoph Ludwig wrote:
> Yes, but on ELF/Linux the default configuration should be --without-cxx
> in the first place. If the build instructions make it sufficiently clear that
> you should prefer this configuration whenever possible then this should be a
> non-issue on platforms like ELF/Linux.
David Abrahams wrote:
>>>I don't see how that works. Somehow we need to decide whether to put
>>>main in ccpython.o in the first place, don't we?
>>
>>Yes, that is done through --with-cxx (alone). However, the decision
>>to use CXX for linking is independent on whether --with-cxx was
>>given.
>
>
On Sun, Jul 10, 2005 at 09:35:33AM -0400, David Abrahams wrote:
> Christoph Ludwig <[EMAIL PROTECTED]> writes:
>
> > I do not claim the 2 TUs test will cover all possible scenarios. I am not
> > even
> > sure this decision should be left to an automated test. Because if the test
> > breaks for so
On Sun, Jul 10, 2005 at 09:45:25AM +0200, "Martin v. Löwis" wrote:
> Christoph Ludwig wrote:
> >>I'll describe it once more: *If* a program is compiled with the C++
> >>compiler, is it *then* possible to still link it with the C compiler?
> >>This is the question this test tries to answer.
> >
> >
I wrote:
> I agree with Barry. Not only should they be in the stdlib, but they
> should have very clear warnings in their docstrings and other documentation
> that state that they are ONLY safe to use in single-threaded programs.
>
> This achieves two things: it makes them available to those who ne
On 7/8/05, James Y Knight <[EMAIL PROTECTED]> wrote:
> It is a really bad idea to codify the practice of modifying non-
> threadlocal global state like sys.std[in|out|err] and current
> directory with a context manager. A user can do it to themselves now,
> true, but by putting a context manager fo
I'm in full agreement with Marc-Andre below, except I don't like (1)
at all -- having used other APIs that always return Unicode (like the
Python XML parsers) it bothers me to get Unicode for no reason at all.
OTOH I think Python 3.0 should be using a Unicode model closer to
Java's.
On 7/11/05, M.
Neil Hodgson wrote:
>On unicode versions of Windows, for attributes like os.listdir,
> os.getcwd, sys.argv, and os.environ, which can usefully return unicode
> strings, there are 4 options I see:
>
> 1) Always return unicode. This is the option I'd be happiest to use,
> myself, but expect this
>> Ummm... What's a "context manager"?
Michael> Something that goes
Michael> with ... as var:
Michael> ^ here
Michael> If you have a better name, feel free to suggest it, but please
Michael> catch up on python-dev first (it's been discussed to
Michael> unconsc
M.-A. Lemburg:
> It's naive to assume that all people in Germany using the German
> locale have German names ;-)
That is not an assumption I would make. The assumption I would make
is that if it is important to you to have your account name in a
particular character set then you will normally
Guido van Rossum:
> In some sense the safest approach from this POV would be to return
> Unicode as soon as it can't be encoded using the global default
> encoding. IOW normally this would return Unicode for all names
> containing non-ASCII characters.
On unicode versions of Windows, for attri
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
>>>- the logic is fixed so that linking with g++ is only done if
>>> main is in ccpython.o
>>
>>
>> I don't see how that works. Somehow we need to decide whether to put
>> main in ccpython.o in the first place, don't we?
>
> Yes, that is done throu
On Mon, 2005-07-11 at 01:08, Bob Ippolito wrote:
> A better proposal would probably be another string prefix that means
> "dedent", but I'm still not sold. doc processing software is clearly
> going to have to know how to dedent anyway in order to support
> existing code.
OTOH, adding anot
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> However, you will find that with a), people will still pass --with-cxx,
> because they tend to "enable" all features they can find.
--with-fpectl, for example. Does anyone lurking here actually use
that, know what it does and require the functional
Skip Montanaro <[EMAIL PROTECTED]> writes:
> Ummm... What's a "context manager"?
Something that goes
with ... as var:
^ here
If you have a better name, feel free to suggest it, but please catch
up on python-dev first (it's been discussed to unconsciousness, if not
quite death, in the las
On Monday 11 July 2005 19:32, Michael Hudson wrote:
> Well, again assuming my guess is right, it's probably an OS X bug, but
> really threads vs signals issues are enormously subtle and frequently
> messed up.
I think mwh meant to say "threads vs signals is a platform-dependant
trail of misery, d
Florent Pillet <[EMAIL PROTECTED]> writes:
> On 07/07/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
>>>
>> > But with my threaded Python code, SIGINT doesn't work anymore after my
>> > binding has called tmpfile().
>>
>> Oh, threads.
>>
>> Which version of Python are you using?
>
> 2.3.5, the on
Reinhold Birkenfeld wrote:
> Guido van Rossum wrote:
>
>>On 7/5/05, Andrew Durdin <[EMAIL PROTECTED]> wrote:
>>
>>>I have written a patch that changes the way triple-quoted strings are
>>>scanned so that leading whitespace is ignored in much the same way
>>>that pep 257 handles it for docstrings.
> > I surely find them useful, and see them as a Python originality (a
> > welcome one).
>
> They are indeed an original invention. (One day I looked at the
> similarity between if and while and noticed that there was a use case
> for else after while too.)
>
> The question remains whether Python
Bob Ippolito wrote:
> A better proposal would probably be another string prefix that means
> "dedent", but I'm still not sold. doc processing software is clearly
> going to have to know how to dedent anyway in order to support
> existing code.
Agreed.
It is easy enough for any doc-string e
24 matches
Mail list logo
