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 URI in Section 3.
(where the phrase sequence of characters appears in all ancestors I
found
2010/6/21 Stephen J. Turnbull step...@xemacs.org:
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:
On Mon, Jun 21, 2010 at 11:58 AM, P.J. Eby p...@telecommunity.com 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
On Mon, Jun 21, 2010 at 9:06 AM, Laurens Van Houtven l...@laurensvh.be 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
On Mon, Jun 21, 2010 at 12:30 PM, P.J. Eby p...@telecommunity.com 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
Stephen J. Turnbull step...@xemacs.org 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?
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.
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 arcri...@gmail.com 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
On Mon, Jun 21, 2010 at 11:17 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Stephen J. Turnbull step...@xemacs.org 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,
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 |
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
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 3,
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 arcri...@gmail.com 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.
On Mon, Jun 21, 2010 at 5:28 PM, Toshio Kuratomi a.bad...@gmail.com wrote:
nod 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
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 provide
On Mon, Jun 21, 2010 at 09:51, P.J. Eby p...@telecommunity.com 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
Lennart Regebro writes:
2010/6/21 Stephen J. Turnbull step...@xemacs.org:
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
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
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 encoding
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
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
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
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
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
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
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
On Tue, Jun 22, 2010 at 01:08:53AM +0900, Stephen J. Turnbull wrote:
Lennart Regebro writes:
2010/6/21 Stephen J. Turnbull step...@xemacs.org:
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
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()
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, but
On Mon, Jun 21, 2010 at 9:46 AM, P.J. Eby p...@telecommunity.com 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
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 the
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 test
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
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
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't even
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 nuisance
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 jans...@parc.com:
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
Ben Finney writes:
Stephen J. Turnbull step...@xemacs.org 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
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 to
On Mon, 21 Jun 2010 10:56:59 PDT
Bill Janssen jans...@parc.com 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
On 21 June 2010 18:56, Bill Janssen jans...@parc.com 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
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
2010/6/21 Stephen J. Turnbull step...@xemacs.org:
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
Benjamin Peterson benja...@python.org wrote:
2010/6/21 Bill Janssen jans...@parc.com:
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
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
On Mon, 21 Jun 2010 12:13:05 PDT
Bill Janssen jans...@parc.com 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 --
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+ebytes
2010/6/21 Bill Janssen jans...@parc.com:
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
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 Trove
On 21/06/2010 20:30, Benjamin Peterson wrote:
2010/6/21 Bill Janssenjans...@parc.com:
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
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 a.bad...@gmail.com wrote:
nod 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
Antoine Pitrou solip...@pitrou.net 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
Benjamin Peterson benja...@python.org wrote:
2010/6/21 Bill Janssen jans...@parc.com:
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
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 .encoding
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 to.
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 released. When
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, package developers
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
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 str
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,
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
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,
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 when
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 bytes
from a
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 Python
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. Do no
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 think
Antoine Pitrou solip...@pitrou.net 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
On Sun, Jun 20, 2010 at 02:02, Terry Reedy tjre...@udel.edu 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
On Sun, Jun 20, 2010 at 18:20, Laurens Van Houtven l...@laurensvh.be 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
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
Antoine Pitrou solip...@pitrou.net 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
Am 21.06.2010 21:45, schrieb Michael Foord:
On 21/06/2010 20:30, Benjamin Peterson wrote:
2010/6/21 Bill Janssenjans...@parc.com:
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
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).
-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
l...@laurensvh.be wrote:
2.x or 3.x? http://tinyurl.com/py2or3
Wow. That's almost not an improvement... That link doesn't really help
anyone
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
On Mon, Jun 21, 2010 at 23:26, Simon de Vlieger si...@ikanobori.jp 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!
--
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 part of
On Mon, Jun 21, 2010 at 11:03 PM, Lennart Regebro rege...@gmail.com wrote:
On Sun, Jun 20, 2010 at 18:20, Laurens Van Houtven l...@laurensvh.be 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.
--
...
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. If you
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
On Tue, Jun 22, 2010 at 6:16 AM, P.J. Eby p...@telecommunity.com 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
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. In that case,
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
On 21 June 2010 22:57, Michael Foord fuzzy...@voidspace.org.uk 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
On 21 June 2010 23:19, Paul Moore p.f.mo...@gmail.com wrote:
On 21 June 2010 22:57, Michael Foord fuzzy...@voidspace.org.uk 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
Bill Janssen jans...@parc.com 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:
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
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
Paul Moore p.f.mo...@gmail.com 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
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 invented
1 - 100 of 118 matches
Mail list logo
