Nicholas Bastin wrote:
> You practically always have to use --compiler with distutils when
> building C++ extensions anyhow, and even then it rarely does what I
> would consider 'The Right Thing(tm)'.
I see. In that case, I think something should be done about distutils
as well (assuming somebod
Hi Marc-Andre,
> >With the proposed modification, sys.argv[1] u'\u20ac.txt' is
> > converted through cp1251
>
> Actually, it is not: if you pass in a Unicode argument to
> one of the file I/O functions and the OS supports Unicode
> directly or at least provides the notion of a file system
Terry Reedy wrote:
> "Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
>>The main outcome of the PEP 343 terminology discussion was some proposed
>>documentation I put on the Sourceforge patch tracker ([1]).
>
> Is this a proposal for the Language Reference manual?
Probably late in the game, esp. for an outsider, but I read the
terminology discussion with interest.
FWIW, I do like Philip's use of context, though I feel that it is a
very generic word that may clash with many application-level
classes... For that reason, I also liked "scope" a lot, though
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> The main outcome of the PEP 343 terminology discussion was some proposed
> documentation I put on the Sourceforge patch tracker ([1]).
Is this a proposal for the Language Reference manual?
> [1] http://www.python.org/s
FWIW, I've updated PEP 343 to use @contextmanager and class
ContextWrapper. Please proofread.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
[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.
[Tim, explains what it intends to do]
>> ...
[Michael]
> But do you use it? I know what it intends to do too,
The
On 7/12/05, Christoph Ludwig <[EMAIL PROTECTED]> wrote:
> If distutils builds C++ extensions with the C compiler then I consider this a
> bug in distutils because it is unlikely to work. (Unless the compiler can
> figure out from the source file suffixes in the compilation step *and* some
> info in
Nobody uses it. It should be ripped out. If someone disagrees, let
them speak up.
On 7/12/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
> Tim Peters <[EMAIL PROTECTED]> writes:
>
> > [Michael Hudson]
> >> --with-fpectl, for example. Does anyone lurking here actually use
> >> that, know what it d
QOTF candidate; should add that the default encoding is usually ASCII.
On 7/12/05, Michael Chermside <[EMAIL PROTECTED]> wrote:
> M A Lemburg writes:
> > we should use strings and Unicode
> > like they are supposed to be used (in the context of text
> > data):
> >
> > * strings are fine for text d
M A Lemburg writes:
> we should use strings and Unicode
> like they are supposed to be used (in the context of text
> data):
>
> * strings are fine for text data that is encoded using
> the default encoding
>
> * Unicode should be used for all text data that is not
> or cannot be encoded in the
Skip Montanaro wrote:
> After seeing so many messages about "with" statements my eyes began to glaze
> over, so I stopped following that thread. Then I saw mention of "context
> manager" with no reference to any PEPs or to the with statement to provide
> context.
The main outcome of the PEP 343 t
Tim Peters <[EMAIL PROTECTED]> writes:
> [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:
Surprise!
> fpectlmodule.c intends to enab
Hi Neil,
>>>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() h
Christoph Ludwig wrote:
> If I understood Dave Abraham's reply somewhere above in this thread correctly
> then you can build different C++ extension modules with different C++
> compilers on ELF/Linux. (I don't have the time right now to actually try it,
> sorry.) There is no need to fix the C++ co
On Tue, Jul 12, 2005 at 01:07:56AM +0200, "Martin v. Löwis" wrote:
> 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 wh
16 matches
Mail list logo
