I've attached a very preliminary patch for this. It makes bytes
immutable but doesn't do either of the other suggested changes. It's
enough to make the tests run, but doesn't do anything to make them
pass. The test results so far are:
270 tests OK.
28 tests failed:
test_asynchat test_asyncore
Okay, here's the barebones, scrapped together version. It's ugly. It's
messy. It might eat your kids. On the other hand, it seems to work.
http://umass.glexia.net/mpf.tar.bz2
It provides a module, mpf, with an MPF type and a bunch of methods.
You can directly set the value of an MPF type by setti
[EMAIL PROTECTED] wrote:
> Binary has (like it or not) been the default behavior on all previous
> Pythons running on Unix systems where text and binary were never different
Um, no, *text* has always been the default on all systems.
It's just that on systems where text and binary are the
same, you
Christian Heimes wrote:
> With Python 2.5 the input and output data isn't implicitly
> converted
Are you sure that's always true? What about systems
where newlines aren't \n?
> I recommend that the problem and fix gets documented. Maybe stdin,
> stdout and stderr should get a method that disables
Yeah, the PEP is pretty out of date (perhaps only surpassed by PEP
3135, super()). It's on my list to update it. This should definitely
be added.
On 9/19/07, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> | Changing the
On 9/19/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> I still think that argv[0] is in the "too clever by
> half" category. It has a kind of theoretical elegance
> from a certain point of view, but no practical
> benefit that I can see.
And I still think you're wasting your time on trivia.
--
--Gu
Thomas Wouters wrote:
> The only meaning is by accident of position. For most programs, the very
> same thing goes for the rest of the arguments: 'mv foo bar' assigns a
> different meaning to 'foo' than it does to 'bar'. Notice how sys.argv
> matches what the user typed, including sys.argv[0].
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Changing the mode between text and binary is not feasible (since it
| would have to change the class). But it is perfectly acceptable to use
| sys.std{in,out}.buffer if you need to write a binary transparent
| filter
This is the documentation for PyNumberMethods right now.
PyNumberMethods *tp_as_number;
XXX
I've managed to wrap GNU MP floats and add rich comparisons, but there's a
sore lack of documentation on how to implement the Number interface. Given a
bit of pointers on where to look, an alpha version o
Guido> I agree that binary pipelines are useful and should be
Guido> possible. I just don't think this should be the default behavior
Guido> for stdin/stdout.
Binary has (like it or not) been the default behavior on all previous
Pythons running on Unix systems where text and binary we
On Sep 19, 2007, at 5:00 PM, Guido van Rossum wrote:
> Since the binary stream underlying stdin is readily available as
> sys.stdin.buffer (and ditto for stdout and even stderr) I don't think
> any action needs to be taken. note that the instance variable doesn't
> start with an underscore. It's pa
On 9/19/07, Fred Drake <[EMAIL PROTECTED]> wrote:
> On Sep 19, 2007, at 3:58 PM, Jason Orendorff wrote:
> > Given the context (stdin/stdout/stderr), I'd love to know what you're
> > thinking of here. I can't name a program offhand that wants to
> > operate on binary data via a pipeline. There are
On 9/19/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Guido> You can repeat that until you're blue in the face but it's not
> Guido> going to change. Way more programs (especially simple ones) deal
> Guido> with txet than with binary data.
>
> For us Unix-heads the notion that a
On Sep 19, 2007, at 3:58 PM, Jason Orendorff wrote:
> Given the context (stdin/stdout/stderr), I'd love to know what you're
> thinking of here. I can't name a program offhand that wants to
> operate on binary data via a pipeline. There are a few that *can*,
> like gzip, but my impression is that
Jason> Given the context (stdin/stdout/stderr), I'd love to know what
Jason> you're thinking of here. I can't name a program offhand that
Jason> wants to operate on binary data via a pipeline.
You've obviously never used the netpbm (nee pbmplus, nee pbm) tools. I
still use this pipe
Guido> You can repeat that until you're blue in the face but it's not
Guido> going to change. Way more programs (especially simple ones) deal
Guido> with txet than with binary data.
For us Unix-heads the notion that a file is anything other than a stream of
bytes is rather foreign. I
On 9/19/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > Way more programs (especially simple ones) deal with txet
> > than with binary data.
>
> I'd love to see stats on that, Guido. I'm sure it's true in your
> immediate vicinity, given what you work on, but I don't believe it's
> true in general
> You can repeat that until you're blue in the face but it's not going
> to change.
That happens to me a lot :-).
> Way more programs (especially simple ones) deal with txet
> than with binary data.
I'd love to see stats on that, Guido. I'm sure it's true in your
immediate vicinity, given what
On 9/19/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> This really isn't a UTF-8 problem. It is the problem with file opens
> defaulting to "text" mode instead of "binary" mode rearing its ugly
> head again.
You can repeat that until you're blue in the face but it's not going
to change. Way more p
I think ord() would be fine.
On 9/19/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 9/17/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > This may have passed in a thread where no-one was listening, so I'm
> > repeating it here.
> >
> > I'm considering the following option: bytes would always
On 9/17/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> This may have passed in a thread where no-one was listening, so I'm
> repeating it here.
>
> I'm considering the following option: bytes would always be immutable,
> and for the few places (mostly in io.py) where a mutable bytes buffer
> wou
GvR wrote:
> I wouldn't do the assignments you propose
> though, since that might surprise other code which expects text files.
But presumably that code wouldn't be used in that same program.
This really isn't a UTF-8 problem. It is the problem with file opens
defaulting to "text" mode instead o
Changing the mode between text and binary is not feasible (since it
would have to change the class). But it is perfectly acceptable to use
sys.std{in,out}.buffer if you need to write a binary transparent
filter. Of course you'll be dealing with bytes at that point so the
usual cautions apply. I wou
Today I stumbled over another problem that is related to the unicode and
OS string topic. The new io system - or to be more precisely the
implicit converting of input and output data to UTF-8 makes it
impossible to pipe binary data through Python 3.0.
For example an user wants to write a filter fo
Victor Stinner writes:
> On Thursday 13 September 2007 18:22:12 Marcin 'Qrczak' Kowalczyk wrote:
> > What should happen when a command line argument or an environment
> > variable is not decodable using the system encoding (on Unix where
> > from the OS point of view it is an array of bytes)?
Hi,
On Thursday 13 September 2007 18:22:12 Marcin 'Qrczak' Kowalczyk wrote:
> What should happen when a command line argument or an environment
> variable is not decodable using the system encoding (on Unix where
> from the OS point of view it is an array of bytes)?
On Linux, filenames are *byte*
Hi,
On Tuesday 18 September 2007 04:18:01 Guido van Rossum wrote:
> I'm considering the following option: bytes would always be immutable,
> (...) make b[0] return a bytes array of length 1 instead of a small int
Great idea! That will help migration from Python 2.x to Python 3.0. Choosing
betwee
27 matches
Mail list logo
