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
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
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
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
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
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 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
"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 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
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
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
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
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 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 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
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, 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
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 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
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 Jun 22, 2010, at 08:03 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 down the
On 6/21/2010 3:59 PM, Steve Holden wrote:
Terry Reedy wrote:
On 6/21/2010 8:33 AM, Nick Coghlan wrote:
P.S. (We're going to have a tough decision to make somewhere along the
line where docs.python.org is concerned, too - when do we flick the
switch and make a 3.x version of the docs the defaul
On 6/21/2010 4:07 PM, Peng Yu wrote:
Hi,
Current pdf version of python documents don't have bookmarks for
sussubsection. For example, there is no bookmark for the following
section in python_2.6.5_reference.pdf. Also the bookmarks don't have
section numbers in them. I suggest to include the sect
Bill Janssen wrote:
> % make test
> [...]
> test_uuid
> test test_uuid failed -- Traceback (most recent call last):
> File "/private/tmp/Python-2.7rc2/Lib/test/test_uuid.py", line 472, in
> testIssue8621
> self.assertNotEqual(parent_value, child_value)
> AssertionError: '8395a08e40454895be5
On 21 June 2010 23:19, Paul Moore wrote:
> On 21 June 2010 22:57, Michael Foord wrote:
>>> Two of the other failures I'm pretty sure are problems in the test suite
>>> rather than bugs (as Bill said) and I'm not sure about the ctypes issue.
>>> Just starting a full build here.
>>
>> Right now I'm
On 21 June 2010 22:57, Michael Foord wrote:
>> Two of the other failures I'm pretty sure are problems in the test suite
>> rather than bugs (as Bill said) and I'm not sure about the ctypes issue.
>> Just starting a full build here.
>
> Right now I'm *only* seeing these two failures on Mac OS X (10
> There also seem to be a couple of failures left with test_gdb...
Do you mean the compiler and debugger specific issues reported in
http://bugs.python.org/issue8482?
Fixing that properly is messy, and according to Victor's last message,
even the correct conditions for skipping the test aren't co
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
Ah, that one. I definitely think this should *not* block the release:
a) th
On Mon, Jun 21, 2010 at 04:52:08PM -0500, John Arbash Meinel wrote:
>
> ...
> >> IOW, if you're producing output that has to go into another system
> >> that doesn't take unicode, it doesn't matter how
> >> theoretically-correct it would be for your app to process the data in
> >> unicode form. I
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 down the ebytes idea, it is basically a request for a
second strin
On 21/06/2010 22:52, Michael Foord wrote:
On 21/06/2010 22:36, "Martin v. Löwis" wrote:
Bill listed several other failures he saw on the buildbots and I see
the
same set, plus test_posix.
Still, the question would be whether any of these failures can manage
to block a release. Are they regre
On 21/06/2010 22:36, "Martin v. Löwis" wrote:
Bill listed several other failures he saw on the buildbots and I see the
same set, plus test_posix.
Still, the question would be whether any of these failures can manage
to block a release. Are they regressions from 2.6?
The test_posix failure is
...
>> IOW, if you're producing output that has to go into another system
>> that doesn't take unicode, it doesn't matter how
>> theoretically-correct it would be for your app to process the data in
>> unicode form. In that case, unicode is not a feature: it's a bug.
>>
> This is not always true.
On Mon, Jun 21, 2010 at 11:03 PM, Lennart Regebro wrote:
> On Sun, Jun 20, 2010 at 18:20, Laurens Van Houtven wrote:
>> 2.x or 3.x? http://tinyurl.com/py2or3
>
> Wow. That's almost not an improvement... That link doesn't really help
> anyone choose at all.
>
> --
> Lennart Regebro: Python, Zope,
On Mon, Jun 21, 2010 at 04:09:52PM -0400, P.J. Eby wrote:
> At 03:29 PM 6/21/2010 -0400, Toshio Kuratomi wrote:
> >On Mon, Jun 21, 2010 at 01:24:10PM -0400, P.J. Eby wrote:
> >> At 12:34 PM 6/21/2010 -0400, Toshio Kuratomi wrote:
> >> >What do you think of making the encoding attribute a mandatory
Bill listed several other failures he saw on the buildbots and I see the
same set, plus test_posix.
Still, the question would be whether any of these failures can manage to
block a release. Are they regressions from 2.6? That would make them
good candidates for release blockers. Except that I
On Mon, Jun 21, 2010 at 23:26, Simon de Vlieger wrote:
> That part of the topic will be replaced after all feedback is gathered on
> the new article Laurens provided at:
> http://python-commandments.org/python3.html as stated earlier in this
> thread.
OK, great, I missed that!
--
Lennart Regebr
On Jun 21, 2010, at 4:29 PM, M.-A. Lemburg wrote:
Here's a little known fact: by changing the Python2 default
encoding to 'undefined' (yes, that's a real codec !), you can disable
all automatic string coercion in Python2.
I tried that once: half the stdlib stops working if you do (for
example
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 21 jun 2010, at 23:03, Lennart Regebro wrote:
On Sun, Jun 20, 2010 at 18:20, Laurens Van Houtven
wrote:
2.x or 3.x? http://tinyurl.com/py2or3
Wow. That's almost not an improvement... That link doesn't really help
anyone choose at all.
Lenn
On 21/06/2010 22:12, "Martin v. Löwis" wrote:
If OS X is a supported and important platform for Python then fixing all
problems that it reveals (or being willing to) should definitely not be
a pre-requisite of providing a buildbot (which is already a service to
the Python developer community). Fi
Am 21.06.2010 21:45, schrieb Michael Foord:
On 21/06/2010 20:30, Benjamin Peterson wrote:
2010/6/21 Bill Janssen:
They are at the end of the buildbot list, so off-screen if you are using
a normal browser. You have to scroll to see them.
But not on the "stable" view and that's the only one I lo
Antoine Pitrou wrote:
> OS X is only "a supported and important platform" if we have dedicated
> core developers diagnosing or even fixing issues for it (like we
> obviously have for Windows and Linux). Otherwise, I don't think we have
> any moral obligation to support it.
Fair enough.
That bei
If OS X is a supported and important platform for Python then fixing all
problems that it reveals (or being willing to) should definitely not be
a pre-requisite of providing a buildbot (which is already a service to
the Python developer community). Fixing bugs / failures revealed by
Bill's buildbo
On Sun, Jun 20, 2010 at 18:20, Laurens Van Houtven wrote:
> 2.x or 3.x? http://tinyurl.com/py2or3
Wow. That's almost not an improvement... That link doesn't really help
anyone choose at all.
--
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
___
On Sun, Jun 20, 2010 at 02:02, Terry Reedy wrote:
> After reading the discussion in the previous thread, signed in to #python
> and verified that the intro message starts with a lie about python3. I also
> verified that the official #python site links to "Python Commandment Don't
> use Python 3… y
Antoine Pitrou wrote:
> Le lundi 21 juin 2010 à 12:57 -0700, Bill Janssen a écrit :
> >
> > > Apparently some of these buildbots belong to you. Why don't you step
> > > up and investigate?
> >
> > The fact that I'm running some buildbots doesn't mean I have to fix the
> > problems that they reve
Barry Warsaw wrote:
> On Jun 21, 2010, at 12:34 PM, Toshio Kuratomi wrote:
>
>> I like the idea of having encoding information carried with the data.
>> I don't think that an ebytes type that can *optionally* have an encoding
>> attribute makes the situation less confusing, though.
>
> Agreed. I
On Mon, Jun 21, 2010 at 02:46:57PM -0400, P.J. Eby wrote:
> At 02:58 AM 6/22/2010 +0900, Stephen J. Turnbull wrote:
> >Nick alluded to the The One Obvious Way as a change in architecture.
> >
> >Specifically: Decode all bytes to typed objects (str, images, audio,
> >structured objects) at input. D
Le lundi 21 juin 2010 à 21:13 +0100, Michael Foord a écrit :
>
> If OS X is a supported and important platform for Python then fixing all
> problems that it reveals (or being willing to) should definitely not be
> a pre-requisite of providing a buildbot (which is already a service to
> the Pyth
On Jun 21, 2010, at 04:16 PM, P.J. Eby wrote:
>At 04:04 PM 6/21/2010 -0400, Barry Warsaw wrote:
>>On Jun 21, 2010, at 01:24 PM, P.J. Eby wrote:
>>
>> >OTOH, one potential problem with having the encoding on the bytes object
>> >rather than the ebytes object is that then you can't easily take > byt
On Jun 21, 2010, at 01:17 PM, P.J. Eby wrote:
>I'm not really sure how much use the encoding is on a unicode object - what
>would it actually mean?
>
>Hm. I suppose it would effectively mean "this string can be represented in
>this encoding" -- which is useful, in that you could fail operations wh
At 04:04 PM 6/21/2010 -0400, Barry Warsaw wrote:
On Jun 21, 2010, at 01:24 PM, P.J. Eby wrote:
>OTOH, one potential problem with having the encoding on the bytes object
>rather than the ebytes object is that then you can't easily take
bytes from a
>socket and then say what encoding they are, w
On 21/06/2010 21:02, Antoine Pitrou wrote:
Le lundi 21 juin 2010 à 12:57 -0700, Bill Janssen a écrit :
Apparently some of these buildbots belong to you. Why don't you step
up and investigate?
The fact that I'm running some buildbots doesn't mean I have to fix the
problems that
At 03:29 PM 6/21/2010 -0400, Toshio Kuratomi wrote:
On Mon, Jun 21, 2010 at 01:24:10PM -0400, P.J. Eby wrote:
> At 12:34 PM 6/21/2010 -0400, Toshio Kuratomi wrote:
> >What do you think of making the encoding attribute a mandatory part of
> >creating an ebyte object? (ex: ``eb = ebytes(b, 'euc-jp
On Jun 21, 2010, at 03:29 PM, Toshio Kuratomi wrote:
>I wouldn't like this. It brings us back to the python2 problem where
>sometimes you pass an ebyte into a function and it works and other times you
>pass an ebyte into the function and it issues a traceback. The coercion
>must end up with a st
Hi,
Current pdf version of python documents don't have bookmarks for
sussubsection. For example, there is no bookmark for the following
section in python_2.6.5_reference.pdf. Also the bookmarks don't have
section numbers in them. I suggest to include the section numbers.
Could these features be ad
On Monday, June 21, 2010, Barry Warsaw wrote:
> On Jun 21, 2010, at 11:13 AM, Stephan Richter wrote:
> >I really just want to be able to go to PyPI, Click on "Browse packages"
> >and then select "Python 3" (it can currently be accomplished by clicking
> >"Python" and then "3"). Of course, packa
Terry Reedy wrote:
> On 6/21/2010 8:33 AM, Nick Coghlan wrote:
>
>> P.S. (We're going to have a tough decision to make somewhere along the
>> line where docs.python.org is concerned, too - when do we flick the
>> switch and make a 3.x version of the docs the default?
>
> Easy. When 3.2 is release
On Jun 21, 2010, at 01:24 PM, P.J. Eby wrote:
>OTOH, one potential problem with having the encoding on the bytes object
>rather than the ebytes object is that then you can't easily take bytes from a
>socket and then say what encoding they are, without interfering with the
>sockets API (or whatever
Le lundi 21 juin 2010 à 12:57 -0700, Bill Janssen a écrit :
>
> > Apparently some of these buildbots belong to you. Why don't you step
> > up and investigate?
>
> The fact that I'm running some buildbots doesn't mean I have to fix the
> problems that they reveal, I think.
You certainly don't have
On Jun 22, 2010, at 03:08 AM, Stephen J. Turnbull wrote:
>Barry Warsaw writes:
>
> > Would it make sense to have "encoding-carrying" bytes and str
> > types?
>
>Why limit that to bytes and str? Why not have all objects carry their
>serializer/deserializer around with them?
Only because the .enco
Benjamin Peterson wrote:
> 2010/6/21 Bill Janssen :
> > They are at the end of the buildbot list, so off-screen if you are using
> > a normal browser. You have to scroll to see them.
>
> But not on the "stable" view and that's the only one I look at.
Right, and properly so.
Bill
_
Antoine Pitrou wrote:
> Benjamin is not qualified to fix OS X bugs AFAIK (if you are, Benjamin,
> then sorry for misrepresenting you :-)). Actually, neither are most of
> us.
Right. I was thinking that the release manager should however be
responsible for not releasing while there are red build
Laurens Van Houtven wrote:
> On Mon, Jun 21, 2010 at 5:28 PM, Toshio Kuratomi wrote:
>> Fedora 14 is about the same. A nice to have thing that goes along
>> with these would be a table that has packages ported to python3 and which
>> distributions have the python3 version of the package.
>
> Ye
On Jun 21, 2010, at 12:34 PM, Toshio Kuratomi wrote:
>I like the idea of having encoding information carried with the data.
>I don't think that an ebytes type that can *optionally* have an encoding
>attribute makes the situation less confusing, though.
Agreed. I think the attribute should always
On 21/06/2010 20:30, Benjamin Peterson wrote:
2010/6/21 Bill Janssen:
They are at the end of the buildbot list, so off-screen if you are using
a normal browser. You have to scroll to see them.
But not on the "stable" view and that's the only one I look at.
What are the require
On Jun 21, 2010, at 11:13 AM, Stephan Richter wrote:
>I really just want to be able to go to PyPI, Click on "Browse packages" and
>then select "Python 3" (it can currently be accomplished by clicking "Python"
>and then "3"). Of course, package developers need to be encouraged to add
>these Tro
2010/6/21 Bill Janssen :
> They are at the end of the buildbot list, so off-screen if you are using
> a normal browser. You have to scroll to see them.
But not on the "stable" view and that's the only one I look at.
--
Regards,
Benjamin
___
Python-D
On Mon, Jun 21, 2010 at 01:24:10PM -0400, P.J. Eby wrote:
> At 12:34 PM 6/21/2010 -0400, Toshio Kuratomi wrote:
> >What do you think of making the encoding attribute a mandatory part of
> >creating an ebyte object? (ex: ``eb = ebytes(b, 'euc-jp')``).
>
> As long as the coercion rules force str+eb
On Mon, 21 Jun 2010 12:13:05 PDT
Bill Janssen wrote:
>
> > > On OS X Leopard, I'm seeing failures in test_py3kwarn,
> > > test_urllib2_localnet, test_uuid.
> > >
> > > On OS X Tiger, I'm seeing failures in test_pep277, test_py3kwarn,
> > > test_ttk_guionly, and test_urllib2_localnet.
>
> Um -- s
On Jun 21, 2010, at 1:56 PM, Bill Janssen wrote:
> Considering that we've just released 2.7rc2, there are an awful lot of
> red buildbots for 2.7. In fact, I don't remember having seen a green
> buildbot for OS X and 2.7. Shouldn't these be fixed?
>
> On OS X Leopard, I'm seeing failures in tes
At 03:08 AM 6/22/2010 +0900, Stephen J. Turnbull wrote:
Barry Warsaw writes:
> Would it make sense to have "encoding-carrying" bytes and str
> types?
I think the answer is "no", though, because (1) it would constitute an
attractive nuisance (the default would be abused, it would work fine
in
Benjamin Peterson wrote:
> 2010/6/21 Bill Janssen :
> > Considering that we've just released 2.7rc2, there are an awful lot of
> > red buildbots for 2.7. In fact, I don't remember having seen a green
> > buildbot for OS X and 2.7. Shouldn't these be fixed?
>
> It seems most of them are off lin
2010/6/21 Stephen J. Turnbull :
> Robert Collins writes:
>
> > Also, url's are bytestrings - by definition;
>
> Eh? RFC 3896 explicitly says
?Definitions of Managed Objects for the DS3/E3 Interface Type
Perhaps you mean 3986 ? :)
> A URI is an identifier consisting of a sequence of characte
At 02:58 AM 6/22/2010 +0900, Stephen J. Turnbull wrote:
Nick alluded to the The One Obvious Way as a change in architecture.
Specifically: Decode all bytes to typed objects (str, images, audio,
structured objects) at input. Do no manipulations on bytes ever
except decode and encode (both to tex
On 21 June 2010 18:56, Bill Janssen wrote:
> Considering that we've just released 2.7rc2, there are an awful lot of
> red buildbots for 2.7. In fact, I don't remember having seen a green
> buildbot for OS X and 2.7. Shouldn't these be fixed?
Ack! My buildbot has looked fine, but on closer inspe
On Mon, 21 Jun 2010 10:56:59 PDT
Bill Janssen wrote:
> Considering that we've just released 2.7rc2, there are an awful lot of
> red buildbots for 2.7. In fact, I don't remember having seen a green
> buildbot for OS X and 2.7. Shouldn't these be fixed?
>
> On OS X Leopard, I'm seeing failures in
At 01:36 PM 6/21/2010 -0400, Terry Reedy wrote:
On 6/21/2010 11:43 AM, Barry Warsaw wrote:
This is probably a stupid idea, and if so I'll plead Monday morning mindfuzz
for it.
Would it make sense to have "encoding-carrying" bytes and str types?
On 2009-11-5 I posted 'Add encoding attribute t
Ben Finney writes:
> "Stephen J. Turnbull" writes:
>
> > your base URL is gonna be b'mailto:step...@xemacs.org', but the
> > natural thing the UI will want to do is
> >
> > formurl = baseurl + '?subject=うるさいやつだなぁ…'
>
> Incidentally, which irritating person was the topic of this
> Ja
2010/6/21 Bill Janssen :
> Considering that we've just released 2.7rc2, there are an awful lot of
> red buildbots for 2.7. In fact, I don't remember having seen a green
> buildbot for OS X and 2.7. Shouldn't these be fixed?
It seems most of them are off line and there last run was just a failure
At 10:29 AM 6/21/2010 -0700, Guido van Rossum wrote:
Perhaps there are more situations where a polymorphic API would be
helpful. Such APIs are not always so easy to implement, because they
have to be careful with literals or other constants (and even more so
mutable state) used internally -- but
Barry Warsaw writes:
> Would it make sense to have "encoding-carrying" bytes and str
> types?
Why limit that to bytes and str? Why not have all objects carry their
serializer/deserializer around with them?
I think the answer is "no", though, because (1) it would constitute an
attractive nuisa
P.J. Eby writes:
> Note too that this is an argument for symmetry in wrapping the
> inputs and outputs, so that the code doesn't have to "know" what
> it's dealing with!
and
> After all, right now, if a stdlib function might return bytes or
> unicode depending on runtime conditions, I can'
Considering that we've just released 2.7rc2, there are an awful lot of
red buildbots for 2.7. In fact, I don't remember having seen a green
buildbot for OS X and 2.7. Shouldn't these be fixed?
On OS X Leopard, I'm seeing failures in test_py3kwarn,
test_urllib2_localnet, test_uuid.
On OS X Tiger
At 12:56 PM 6/21/2010 -0400, Toshio Kuratomi wrote:
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
On 6/21/2010 8:51 AM, Nick Coghlan wrote:
I don't know that the "all is well" camp actually exists. The camp
that I do see existing is the one that says "without a bug report,
inconsistencies in the standard library's unicode handling won't get
fixed".
The issues picked up by the regression te
On 6/21/2010 11:43 AM, Barry Warsaw wrote:
This is probably a stupid idea, and if so I'll plead Monday morning mindfuzz
for it.
Would it make sense to have "encoding-carrying" bytes and str types?
On 2009-11-5 I posted 'Add encoding attribute to bytes' to python-ideas.
It was shot down at th
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 works around this (Python 3.1 shown):
>>
On Mon, Jun 21, 2010 at 9:46 AM, P.J. Eby wrote:
> At 10:51 PM 6/21/2010 +1000, Nick Coghlan wrote:
>>
>> It may be that there are places where we need to rewrite standard
>> library algorithms to be bytes/str neutral (e.g. by using length one
>> slices instead of indexing). It may be that there a
On Monday, June 21, 2010, Nick Coghlan wrote:
> A decent listing of major packages that already support Python 3 would
> be very handy for the new Python2orPython3 page I created on the wiki,
> and easier to keep up-to-date. (the old Early2to3Migrations page
> didn't look particularly up to date, b
On 6/20/2010 11:56 PM, Terry Reedy wrote:
The specific example is
>>> urllib.parse.parse_qsl('a=b%e0')
[('a', 'b�')]
where the character after 'b' is white ? in dark diamond, indicating an
error.
parse_qsl() splits that input on '=' and sends each piece to
urllib.parse.unquote
unquote() atte
On Tue, Jun 22, 2010 at 01:08:53AM +0900, Stephen J. Turnbull wrote:
> Lennart Regebro writes:
>
> > 2010/6/21 Stephen J. Turnbull :
> > > IMO, the UI is right. "Something" like the above "ought" to work.
> >
> > Right. That said, many times when you want to do urlparse etc they
> > might b
At 12:34 PM 6/21/2010 -0400, Toshio Kuratomi wrote:
What do you think of making the encoding attribute a mandatory part of
creating an ebyte object? (ex: ``eb = ebytes(b, 'euc-jp')``).
As long as the coercion rules force str+ebytes (or str % ebytes,
ebytes % str, etc.) to result in another eb
At 11:43 AM 6/21/2010 -0400, Barry Warsaw wrote:
On Jun 21, 2010, at 10:20 PM, Nick Coghlan wrote:
>Something that may make sense to ease the porting process is for some
>of these "on the boundary" I/O related string manipulation functions
>(such as os.path.join) to grow "encoding" keyword-only a
On behalf of the Python development team, I'm tickled pink to announce the
second release candidate of Python 2.7.
Python 2.7 is scheduled (by Guido and Python-dev) to be the last major version
in the 2.x series. However, 2.7 will have an extended period of bugfix
maintenance.
2.7 includes many f
At 01:08 AM 6/22/2010 +0900, Stephen J. Turnbull wrote:
But if you need that "everywhere", what's so hard about
def urljoin_wrapper (base, subdir):
return urljoin(str(base, 'latin-1'), subdir).encode('latin-1')
Now, note how that pattern fails as soon as you want to use
non-ISO-8859-1 langu
On 21/06/2010 17:46, P.J. Eby wrote:
At 10:51 PM 6/21/2010 +1000, Nick Coghlan wrote:
It may be that there are places where we need to rewrite standard
library algorithms to be bytes/str neutral (e.g. by using length one
slices instead of indexing). It may be that there are more APIs that
need t
At 10:51 PM 6/21/2010 +1000, Nick Coghlan wrote:
It may be that there are places where we need to rewrite standard
library algorithms to be bytes/str neutral (e.g. by using length one
slices instead of indexing). It may be that there are more APIs that
need to grow "encoding" keyword arguments th
On 6/21/2010 11:31 AM, Arc Riley wrote:
Personally, I'd like to celebrate the upcoming Python 3.2 release (which
will hopefully include 3to2) with moving all packages which do not have
the 'Programming Language :: Python :: 3' classifier to a "Legacy"
section of PyPI and offer only Python 3 packa
On Mon, Jun 21, 2010 at 11:43:07AM -0400, Barry Warsaw wrote:
> On Jun 21, 2010, at 10:20 PM, Nick Coghlan wrote:
>
> >Something that may make sense to ease the porting process is for some
> >of these "on the boundary" I/O related string manipulation functions
> >(such as os.path.join) to grow "en
1 - 100 of 120 matches
Mail list logo
