Paul Moore writes:
> Thanks for the alert. I've killed the stuck test and should see some
> runs going through now. Shame, really, I was getting used to seeing a
> nice page of all green results...
In my experience, my OSX and Windows buildbots need some manual TLC on
an ongoing basis. I kill o
On Tue, 22 Jun 2010 06:09:52 am P.J. Eby wrote:
> However, if you promoted mixed-type operation results to unicode
> instead of ebytes, then you:
>
> 1) can't preserve data that doesn't have a 1:1 mapping to unicode,
Sounds like exactly the sort of thing the Unicode private codepoints
were invent
On Tue, 22 Jun 2010 08:03:58 am Nick Coghlan wrote:
> On Tue, Jun 22, 2010 at 6:16 AM, P.J. Eby
wrote:
> > True, but making it a separate type with a required encoding gets
> > rid of the magical "I don't know" - the "I don't know" encoding is
> > just a plain old bytes object.
>
> So, to boil do
On 6/21/2010 1:29 PM, P.J. Eby wrote:
At 05:49 PM 6/21/2010 +0100, Michael Foord wrote:
Why is your proposed bstr wrapper not practical to implement outside
the core and use in your own libraries and frameworks?
__contains__ doesn't have a converse operation, so you can't code a type
that work
Steven D'Aprano:
> Do any other languages have any equivalent to this ebtyes type?
The String type in Ruby 1.9 is a byte string with an encoding attribute.
Most online Ruby documentation is for 1.8 but the API can be examined here:
http://ruby-doc.org/ruby-1.9/index.html
Here's somethin
On 6/21/2010 1:29 PM, Guido van Rossum wrote:
Actually, the big problem with Python 2 is that if you mix str and
unicode, things work or crash depending on whether any of the str
objects involved contain non-ASCII bytes.
If one API decides to upgrade to Unicode, the result, when passed to
anoth
On 6/21/2010 1:58 PM, Stephen J. Turnbull wrote:
As for "Think Carefully About It Every Time", that is required only in
Porting Programs That Mix Operation On Bytes With Operation On Str.
The 2.x anti-pattern
If you write programs from scratch, however, the decode-process-encode
paradigm qui
On Mon, Jun 22, 2010 at 7:27:31 PM, Steven D'Aprano wrote:
> On Tue, 22 Jun 2010 08:03:58 am Nick Coghlan wrote:
>> So, to boil down the ebytes idea, it is basically a request for a
>> second string type that holds an octet stream plus an encoding name,
>> rather than a Unicode character stream.
>
On Mon, Jun 21, 2010 at 6:39 PM, Paul Moore wrote:
..
> Yes, looks like it's a bug in the test. http://bugs.python.org/issue9055
> raised.
I concur. I've updated the issue with a proposed fix. (The problem
is that proxy host names should have a '.' in them on OSX.) I am
trying to decide wheth
Oh, I thought that was about http://bugs.python.org/issue8455 .
On Mon, Jun 21, 2010 at 9:05 PM, Alexander Belopolsky
wrote:
> On Mon, Jun 21, 2010 at 6:39 PM, Paul Moore wrote:
> ..
>> Yes, looks like it's a bug in the test. http://bugs.python.org/issue9055
>> raised.
>
> I concur. I've updat
Alexander Belopolsky wrote:
> Oh, I thought that was about http://bugs.python.org/issue8455 .
>
> On Mon, Jun 21, 2010 at 9:05 PM, Alexander Belopolsky
> wrote:
> > On Mon, Jun 21, 2010 at 6:39 PM, Paul Moore wrote:
> > ..
> >> Yes, looks like it's a bug in the test. http://bugs.python.org/iss
On Mon, Jun 21, 2010 at 6:16 PM, "Martin v. Löwis" wrote:
>> The test_posix failure is a regression from 2.6 (but it only shows up on
>> some machines - it is caused by a fairly braindead implementation of a
>> couple of posix apis by Apple apparently).
>>
>> http://bugs.python.org/issue7900
>
> A
"Martin v. Löwis" writes:
> Still, the question would be whether any of these failures can manage to
> block a release.
Exactly. Personally, I would say that in a volunteer-maintained
project, "Platform X is supported" means that "There is a bug that
seems to affect only Platform X" is a cand
On 6/21/2010 2:46 PM, P.J. Eby wrote:
This ignores the existence of use cases where what you have is text that
can't be properly encoded in unicode.
I think it depends on what you mean by 'properly'. I will try to explain
with English examples.
1. Unicode represents a finite set of characte
Barry Warsaw writes:
> I'm still not sure ebytes solves the problem,
I don't see how it can. If you have an encoding to stuff into ebytes,
you could just convert to Unicode and guarantee that all internal
string operations will succeed. If you use ebytes instead, every
string operation has to
On Mon, Jun 21, 2010 at 9:26 PM, Bill Janssen wrote:
..
> Though, isn't that behavior of urllib.proxy_bypass another bug?
I don't know. Ask Ronald.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Uns
Toshio Kuratomi writes:
> One comment here -- you can also have uri's that aren't decodable into their
> true textual meaning using a single encoding.
>
> Apache will happily serve out uris that have utf-8, shift-jis, and
> euc-jp components inside of their path but the textual
> representa
Robert Collins writes:
> Perhaps you mean 3986 ? :)
Thank you for the correction.
> > A URI is an identifier consisting of a sequence of characters
> > matching the syntax rule named in Section 3.
> >
> > (where the phrase "sequence of characters" appears in all ancestors I
> > foun
P.J. Eby writes:
> In Kagoshima, you'd use pass in an ebytes with your encoding to a
> stdlib API, and *get back an ebytes with the right encoding*,
> rather than an (incorrect and useless) unicode object which has
> lost data you need.
How does the stdlib do that? Unless it guesses which en
On Jun 21, 2010, at 2:17 PM, P.J. Eby wrote:
> One issue I remember from my "enterprise" days is some of the Asian-language
> developers at NTT/Verio explaining to me that unicode doesn't actually solve
> certain issues -- that there are use cases where you really *do* need "bytes
> plus encodi
101 - 120 of 120 matches
Mail list logo
