Robert Collins writes:
> Also, url's are bytestrings - by definition;
Eh? RFC 3896 explicitly says
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
found ba
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 be binary, and you might want binary. So maybe the methods
should work with both?
--
Lennart Regebro: http://regebro.wordp
On Mon, Jun 21, 2010 at 11:58 AM, P.J. Eby wrote:
> At 08:08 AM 6/21/2010 +1000, Nick Coghlan wrote:
>>
>> Perhaps if people could identify which specific string methods are
>> causing problems?
>
> __getitem__(int) returns an integer rather than a bytestring, so anything
> that manipulates indivi
On Mon, Jun 21, 2010 at 9:06 AM, Laurens Van Houtven wrote:
> Okay cool, we fixed it: http://python-commandments.org/python3.html
>
> People are otherwise happy with the text?
Yep, looks pretty good to me.
I hope you don't mind, but I actually borrowed your text to seed a
corresponding page on t
On Mon, Jun 21, 2010 at 12:30 PM, P.J. Eby wrote:
> I also find it weird that there seem to be two camps on this subject, one of
> which claims that All Is Well And There Is No Problem -- but I do not recall
> seeing anyone who was in the "What do I do; this doesn't seem ready" camp
> who switched
"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
Japanese-language message to you?
(The subject
I would suggest that if packages that do not have Python 3 support yet are
listed, then their alternatives should also.
PyQt has had Py3 support for some time.
PostgreSQL and SQLite do (as does SQLAlchemy)
CherryPy has had Py3 support for the last release cycle
libxml2 does not, but lxml does.
Al
On Jun 21, 2010, at 09:37 AM, Arc Riley wrote:
>Also, under where it mentions that most OS's do not include Python 3, it
>should be noted which have good support for it. Gentoo (for example) has
>excellent support for Python 3, automatically installing Python packages
>which have Py3 support for
On Mon, Jun 21, 2010 at 11:37 PM, Arc Riley wrote:
> I would suggest that if packages that do not have Python 3 support yet are
> listed, then their alternatives should also.
>
> PyQt has had Py3 support for some time.
> PostgreSQL and SQLite do (as does SQLAlchemy)
> CherryPy has had Py3 support
On Mon, Jun 21, 2010 at 11:17 PM, Ben Finney wrote:
> "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
> Given what he said about the base URL, it would appear to be a
> self-deprecating self-description. Nicely done :)
Gah, no it isn't, you're right, the message leaves it unspecified. OK,
no more posting after midnight for me... (well, not tonight, anyway)
Cheers,
Nick.
--
Nick Coghlan | nc
At 10:20 PM 6/21/2010 +1000, Nick Coghlan wrote:
For the idea of avoiding excess copying of bytes through multiple
encoding/decoding calls... isn't that meant to be handled at an
architectural level (i.e. decode once on the way in, encode once on
the way out)? Optimising the single-byte codec cas
On Mon, Jun 21, 2010 at 09:57:30AM -0400, Barry Warsaw wrote:
> On Jun 21, 2010, at 09:37 AM, Arc Riley wrote:
>
> >Also, under where it mentions that most OS's do not include Python 3, it
> >should be noted which have good support for it. Gentoo (for example) has
> >excellent support for Python
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 packages otherwise. Of course put a banner at
On Mon, Jun 21, 2010 at 3:37 PM, Arc Riley wrote:
> I would suggest that if packages that do not have Python 3 support yet are
> listed, then their alternatives should also.
Okay, this is being worked on.
> PyQt has had Py3 support for some time.
Added, as well as PySide.
> PostgreSQL and SQLi
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.
Yeah, this is exactly why I'd prefer t
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 arguments. The
>recommended approach would be to pr
On Mon, Jun 21, 2010 at 09:51, P.J. Eby wrote:
> The issue is, I'd like to have an idempotent incantation that I can use to
> make the inputs and outputs to stdlib functions behave in a type-safe manner
> with respect to bytes, in cases where bytes are really what I want operated
> on.
>
> Note to
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 be binary, and you might want binary. So maybe the methods
> should work with both?
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 released. When 2.7 is released, 3.2 beco
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
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
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 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 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 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 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
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
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
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 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 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
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 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
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
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
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
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'
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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 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
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 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
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
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
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
_
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
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 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
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 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
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 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
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 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 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 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
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
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 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
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
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
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
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
___
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
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
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
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
-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 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
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
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 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
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,
...
>> 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 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
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 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 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
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
> 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
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
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
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 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
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 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
1 - 100 of 120 matches
Mail list logo
