Greg Ewing schrieb:
> So concatenating mutable and immutable should give the
> same result as concatenating two immutables, i.e. an
> immutable. If you need to add something to the end of
> your buffer, while keeping it mutable, you use extend().
>
> This gives us
>
>immutable + immutable ->
Jim Jewett schrieb:
> On 8/7/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
>> If b"..." is immutable, the
>> immutable bytes type is in your face all the time and you'll have to
>> deal with the difference all the time.
>
> There is a conceptual difference between the main use cases for
> mut
The wiki seems to be done, so sorry for the spam.
python -v crashes due to infinite recursion (well, it tried to be
infinite until it got a stack overflow :-) The problem seems to be
that Lib/encodings/latin_1.py is loaded, but it tries to be converted
to latin_1, so it tries to load the module,
>> Now, you seem to talk about different *Linux* systems. On Linux,
>> use UCS-4.
>
> Yes, that's what we want. But Python 2.5 defaults to UCS-2 (at least
> last time I tried), while many distros have used UCS-4. If Linux
> always used UCS-4, that would be fine, but currently there's no
> guarante
>>> This would mean that the Unicode type would acquire all of the ambiquity
>>> currently associated with the 8-bit str type
>> Not necessarily, as this kind of use is typically very localized.
>> Remember practicality beats purity.
>
> Has anyone considered that, depending on the implementation,
On 8/7/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> So concatenating mutable and immutable should give the
> same result as concatenating two immutables, i.e. an
> immutable. If you need to add something to the end of
> your buffer, while keeping it mutable, you use extend().
>
> This gives us
>
>
Talin wrote:
> 4) Literals of both types are available - using a prefix of small 'b'
> for bytes, and capitol B for 'buffer'.
I don't see that it would be really necessary to have a
distinct syntax for a buffer constructor (no literal!)
because you could always write
buffer(b"...")
This is w
Greg Ewing wrote:
> Guido van Rossum wrote:
>
>> That would imply that b"..." should return a mutable bytes object,
>> which many people have objected to.
>>
>
> I'm still very uncomfortable about this. It's so
> completely unlike anything else in the language.
> I have a strong feeling tha
Guido> Fixed now. This was OSX only due to an endianness issue; but the
Guido> bug was universal: we were treating a unicode character using
Guido> structmodule's T_CHAR. Since other similar fields of the dialect
Guido> type were dealt with properly it seems this was merely an
Wow. +1 for pure lucid reasoning.
(Sorry for top-posting; blame the crackberry)
On 8/7/07, Talin <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > Assuming you weren't being sarcastic, array('B') and bytes() are very
> > close except bytes have a literal notation and many string-ish
>
Guido van Rossum wrote:
> Assuming you weren't being sarcastic, array('B') and bytes() are very
> close except bytes have a literal notation and many string-ish
> methods. The buffer objects returned by the buffer() builtin provide a
> read-only view on other objects that happen to have an interna
On 8/7/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> My instinct with regard to sets is the other way around,
> i.e. use immutable sets unless there's a reason they
> need to be mutable. The reason is safety -- accidentally
> trying to mutate an immutable object fails more quickly
> and obviously tha
On 8/7/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Currently the array module can be used for
> > this but I would like to get rid of it in favor of bytes and Travis
> > Oliphant's new buffer API
>
> I thought the plan was to *enhance* the array module
> so that it provi
Guido van Rossum wrote:
> That would imply that b"..." should return a mutable bytes object,
> which many people have objected to.
I'm still very uncomfortable about this. It's so
completely unlike anything else in the language.
I have a strong feeling that it is going to trip
people up a lot, and
Nick Coghlan wrote:
> If __format__ receives both the alignment specifier and the format
> specifier as arguments,
My suggestion would be for it to receive the alignment
spec pre-parsed, since apply_format has to at least
partially parse it itself, and there doesn't seem to
be anything gained by
Ron Adam wrote:
>
> Greg Ewing wrote:
>
>> Some types may recognise when they're being passed
>> a format spec that belongs to another type, and try
>> to convert themselves to that type (e.g. applying
>> 'f' to an int or 'd' to a float).
>
> After thinking about this a bit more, I think specifi
Guido van Rossum wrote:
> Currently the array module can be used for
> this but I would like to get rid of it in favor of bytes and Travis
> Oliphant's new buffer API
I thought the plan was to *enhance* the array module
so that it provides multi-dimensional arrays that
support the new buffer proto
Nick Coghlan wrote:
> I would
> expect the situation to be the same as with sets - you'd use the mutable
> version by default, unless there was some specific reason to want the
> frozen version (usually because you want something that is hashable, or
> easy to share safely amongst multiple clien
Fixed now. This was OSX only due to an endianness issue; but the bug
was universal: we were treating a unicode character using
structmodule's T_CHAR. Since other similar fields of the dialect type
were dealt with properly it seems this was merely an oversight.
On 8/7/07, [EMAIL PROTECTED] <[EMAIL
Guido van Rossum wrote:
> On 8/7/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
>>This would mean that the Unicode type would acquire all of the ambiquity
>>currently associated with the 8-bit str type
>
> Not necessarily, as this kind of use is typically very localized.
> Remember practicality bea
Thanks -- fixed!
Committed revision 56814.
On 8/7/07, Lars Gustäbel <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 07, 2007 at 12:27:40PM -0700, Guido van Rossum wrote:
> > I still get these three failures on Ubuntu dapper:
> >
> >
> > ===
On Tue, Aug 07, 2007 at 12:27:40PM -0700, Guido van Rossum wrote:
> I still get these three failures on Ubuntu dapper:
>
>
> ==
> ERROR: test_fileobj_iter (test.test_tarfile.Bz2UstarReadTest)
> ---
Here's a followup.
We need help from someone with a 64-bit Linux box; these tests are
failing on 64-bit only: test_io, test_largefile, test_ossaudiodev,
test_poll, test_shelve, test_socket_ssl.
I suspect that the _fileio.c module probably is one of the culprits.
Other news:
On 8/6/07, Guido van
On 8/7/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> If b"..." is immutable, the
> immutable bytes type is in your face all the time and you'll have to
> deal with the difference all the time.
There is a conceptual difference between the main use cases for
mutable (a buffer) and the main use
Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> Hmmm. Should we being using the email package to parse HTTP headers?
> RFC 2616 says that HTTP headers follow the "same generic format" as
> RFC 822, but RFC 822 says headers are ASCII and RFC 2616 says headers
> are arbitrary 8-bit values. You'd need to
On 8/7/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/7/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > Could someone please explain to me the conceptual difference between
> > array.array('B'), bytes(), buffer objects and simple lists of
> > integers? I'm confused about when I should use
Talin wrote:
> Ron Adam wrote:
>> Now here's the problem with all of this. As we add the widths back
>> into the format specifications, we are basically saying the idea of a
>> separate field width specifier is wrong.
>>
>> So maybe it's not really a separate independent thing after all, and
I see this too now, but only on OSX.
On 8/7/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> test_csv got removed from the failing list after Guido applied Adam Hupp's
> patch. (I checked in a small update for one thing Adam missed.) I'm still
> getting test failures though:
>
> ==
Greg Ewing wrote:
> Ron Adam wrote:
>> What about mismatched specifiers?
>
> It's not clear exactly what you mean by a "mismatched"
> specifier.
>
> Some types may recognise when they're being passed
> a format spec that belongs to another type, and try
> to convert themselves to that type (e.g
I still get these three failures on Ubuntu dapper:
==
ERROR: test_fileobj_iter (test.test_tarfile.Bz2UstarReadTest)
--
Traceback (most recent call last):
File
On Tue, Aug 07, 2007 at 08:13:07AM +0200, Christian Heimes wrote:
> > test_tarfile
> > Virgin territory again (but different owner :-).
>
> The tarfile should be addressed by either its original author or
> somebody with lots of spare time. As stated earlier it's a beast. I
> tried to fix it sever
On 8/7/07, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> We use the same makefile() object to read the headers and the body.
> We can't trust the body is text. I guess we could change the code to
> use two different makefile() calls--a text one for headers that is
> closed when the headers are done,
Guido van Rossum writes:
> Bizarre. I'm not aware of any HTTP header that requires *binary*
> values. I can imagine though that they may contain *encoded* text and
> that they are leaving the encoding up to separate negotiations between
> client and server, or another header, or specified expl
On 8/7/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/7/07, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> > On 8/7/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > On 8/7/07, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> > > > Hmmm. Should we being using the email package to parse HTTP head
On 8/7/07, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> On 8/7/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 8/7/07, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> > > Hmmm. Should we being using the email package to parse HTTP headers?
> > > RFC 2616 says that HTTP headers follow the "same gen
On 8/7/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/7/07, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> > On 8/6/07, Fred Drake <[EMAIL PROTECTED]> wrote:
> > > On Aug 6, 2007, at 4:46 PM, [EMAIL PROTECTED] wrote:
> > > > I thought rfc822 was going away. From the current module
> > > > docu
On 8/7/07, Thomas Heller <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
> > On 8/7/07, Thomas Heller <[EMAIL PROTECTED]> wrote:
> >> Guido van Rossum schrieb:
> >> > test_ctypes
> >> > Recently one test started failing again, after Martin changed
> >> > PyUnicode_FromStringAndSize() to use
On 8/7/07, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> On 8/6/07, Fred Drake <[EMAIL PROTECTED]> wrote:
> > On Aug 6, 2007, at 4:46 PM, [EMAIL PROTECTED] wrote:
> > > I thought rfc822 was going away. From the current module
> > > documentation:
> > > ...
> > > Shouldn't rfc822 be gone altogether in
Guido> Odd. It passes for me. What platform? What locale? Have you tried
Guido> svn up and rebuilding? Do you have any local changes (svn st)?
I am completely up-to-date:
>>> sys.subversion
('CPython', 'branches/py3k-struni', '56800')
Running on Mac OS X (G4 Powerbook), no local
On 8/7/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On 8/7/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> >> A separate frozenbytes type (with the bytes API instead of the
> >> string API) would solve the problem far more cleanly.
> >
> > But at a cost: an extra data typ
On 8/7/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> Could someone please explain to me the conceptual difference between
> array.array('B'), bytes(), buffer objects and simple lists of
> integers? I'm confused about when I should use which.
Assuming you weren't being sarcastic, array('B') and by
Guido van Rossum wrote:
> On 8/7/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> A separate frozenbytes type (with the bytes API instead of the
>> string API) would solve the problem far more cleanly.
>
> But at a cost: an extra data type, more code to maintain, more docs
> to write, thicker books,
On 8/7/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
> > Code that has been ported to the bytes type probably doesn't use it
> > correctly yet, but to me, the need for a buffery thing where you
> > can allocate some buffer, and then fill it byte-for-byte is quite
> > obvious.
>
On 8/7/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/7/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > This would mean that the Unicode type would acquire all of the ambiquity
> > currently associated with the 8-bit str type: does it contain actual
> > text, or does it contain arbitrary la
On 8/6/07, Fred Drake <[EMAIL PROTECTED]> wrote:
> On Aug 6, 2007, at 4:46 PM, [EMAIL PROTECTED] wrote:
> > I thought rfc822 was going away. From the current module
> > documentation:
> > ...
> > Shouldn't rfc822 be gone altogether in Python 3?
>
> Yes. And the answers to Jeremy's questions about
Guido van Rossum schrieb:
> On 8/7/07, Thomas Heller <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum schrieb:
>> > test_ctypes
>> > Recently one test started failing again, after Martin changed
>> > PyUnicode_FromStringAndSize() to use UTF8 instead of Latin1.
>>
>> I wanted to look into this and not
Guido van Rossum wrote:
> Alas, not for me (Ubuntu 6.06 LTS, UCS2 build):
>
> ==
> ERROR: testEncodings (__main__.MinidomTest)
> --
> Traceback (most recent call
On 07/08/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/7/07, Thomas Heller <[EMAIL PROTECTED]> wrote:
> > I wanted to look into this and noticed that 'import time' on Windows
> > doesn't work anymore on my machine. The reason is that
> > PyUnicode_FromStringAndSize()
> > is called for th
Odd. It passes for me. What platform? What locale? Have you tried svn
up and rebuilding? Do you have any local changes (svn st)?
Note that in s'\x00', the 's' prefix is produced by the repr() of a
str8 object; this may be enough of a hint to track it down. Perhaps
there's a call to PyString_From..
On 8/6/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On 8/6/07, Chris Monson <[EMAIL PROTECTED]> wrote:
> > On 8/6/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > On 8/6/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > > > b) should bytes literals be regular or frozen bytes?
> > >
>
On 8/7/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Yeah, this approach seems to run counter to the whole point of getting
> rid of the current str type: "for binary data use bytes, for text use
> Unicode, unless you need your binary data to be hashable, and then you
> decode it to gibberish Unico
On Mon, Aug 06, 2007, Guido van Rossum wrote:
>
> I've always made a point of suggesting that we're switching to
> returning iterators instead of lists from as many APIs as makes sense
> (I stop at str.split() though, as I can't think of a use case where
> the list would be so big as to be botherso
On 8/6/07, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> On 8/6/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I'm waiting for a show-stopper issue that can't be solved without
> > having an immutable bytes type.
>
> Apologies if this has been answered before, but why are you waiting
> for a sh
On 8/6/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> >>> The most efficient representation of immutable bytes is quite different
> >>> from the most efficient representation of mutable bytes.
> >>
> >> In what way?
> >
> > Well, in some runtime environments (I'm not sure about Python), for
> >
test_csv got removed from the failing list after Guido applied Adam Hupp's
patch. (I checked in a small update for one thing Adam missed.) I'm still
getting test failures though:
==
FAIL: test_reader_attrs (__main__.Test
On 8/7/07, Thomas Heller <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
> > test_ctypes
> > Recently one test started failing again, after Martin changed
> > PyUnicode_FromStringAndSize() to use UTF8 instead of Latin1.
>
> I wanted to look into this and noticed that 'import time' on Windows
Greg Ewing wrote:
> Guido van Rossum wrote:
>> Personally, I still think that converting to the latin-1 encoding is
>> probably just as good for this particular use case.
>
> Although that's a conceptually screwy thing to do
> when your data has nothing to do with characters.
Yeah, this approach
Martin v. Löwis schrieb:
>> One issue with just putting this in the C API docs is that I believe
>> (tell me if I'm wrong) that these haven't been kept up to date in the
>> struni branch so we'll need to make a lot more changes than just this
>> one...
>
> That's certainly the case. However, if we
Guido van Rossum schrieb:
> We're down to 11 failing test in the struni branch. I'd like to get
> this down to zero ASAP so that we can retire the old p3yk (yes, with
> typo!) branch and rename py3k-struni to py3k.
>
> Please help! Here's the list of failing tests:
>
> test_ctypes
> Recently one
Ron Adam wrote:
> What about mismatched specifiers?
It's not clear exactly what you mean by a "mismatched"
specifier.
Some types may recognise when they're being passed
a format spec that belongs to another type, and try
to convert themselves to that type (e.g. applying
'f' to an int or 'd' to a
Martin v. Löwis wrote:
> Code that has been ported to the bytes type probably doesn't use it
> correctly yet, but to me, the need for a buffery thing where you
> can allocate some buffer, and then fill it byte-for-byte is quite
> obvious.
We actually already *have* something like that,
i.e. array.
Jeffrey Yasskin wrote:
> If you have mutable bytes and need an
> immutable object, you could 1) convert it to an int (probably
> big-endian),
That's not a reversible transformation, because you lose
information about leading zero bits.
> 4) use the deprecated str8 type
Which won't exist in Py3k,
Martin v. Löwis wrote:
> That assumes that the mutable bytes type also supports changes to
> its length.
It would be surprising if it didn't, because that would
make it different from all the other builtin mutable
sequences.
--
Greg
___
Python-3000 mail
Martin v. Löwis wrote:
> Now if you say that the dbm files are dicts conceptually,
I wouldn't say they're dicts, rather they're mappings.
Restriction of keys to immutable values is a peculiarity
of dicts, not a required feature of mappings in general.
--
Greg
Guido van Rossum wrote:
> Personally, I still think that converting to the latin-1 encoding is
> probably just as good for this particular use case.
Although that's a conceptually screwy thing to do
when your data has nothing to do with characters.
--
Greg
Guido van Rossum wrote:
> At the same time we still have enough uses of str9
For holding data from 9-track tapes? :-)
--
Greg
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.or
This evening I had a couple hours to spar and happend to read Guido's
plea for help near the beginning of it. I picked up a failing testcase
that no one had claimed and did what I could: it's not finished, but it
fixes approximately 75% of the errors in test_tarfile. I concentrated
on fixing pro
On 8/7/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > This means that I can't distribute Python extensions as binaries.
>
> I think this conclusion is completely wrong. Why do you come to it?
>
> If you want to distribute extension modules for Ubuntu, just distribute
> the UCS-4 module. You n
68 matches
Mail list logo
