On Fri, 18 Jun 2010 18:52:45 -, l...@rmi.net wrote:
> What I'm suggesting is that extreme caution be exercised from
> this point forward with all things 3.X-related. Whether you
> wish to accept this or not, 3.X has a negative image to many.
> This suggestion specifically includes not abandoni
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Glyph Lefkowitz wrote:
> I don't speak for Tres, but I don't think he wasn't talking about
> optimism about *adoption*, overall, but optimism about adoption
> *rates*. And I don't think he was talking about it coming from Guido
> :).
You channel me
On Jun 23, 2010, at 8:17 AM, Steve Holden wrote:
> Guido van Rossum wrote:
>> On Tue, Jun 22, 2010 at 9:37 AM, Tres Seaver wrote:
>>> Any "turdiness" (which I am *not* arguing for) is a natural consequence
>>> of the kinds of backward incompatibilities which were *not* ruled out
>>> for Python 3
Guido van Rossum wrote:
> On Tue, Jun 22, 2010 at 9:37 AM, Tres Seaver wrote:
>> Any "turdiness" (which I am *not* arguing for) is a natural consequence
>> of the kinds of backward incompatibilities which were *not* ruled out
>> for Python 3, along with the (early, now waning) "build it and they w
On Tue, Jun 22, 2010 at 15:32, Terry Reedy wrote:
> On 6/22/2010 9:24 AM, Michael Urman wrote:
>> These are trivial functions;
>> I just don't fully understand why the capability isn't baked in.
>
> Possible reasons: They are special purpose functions easily built on the
> basic functions provided
On Tue, Jun 22, 2010 at 9:37 AM, Tres Seaver wrote:
> Any "turdiness" (which I am *not* arguing for) is a natural consequence
> of the kinds of backward incompatibilities which were *not* ruled out
> for Python 3, along with the (early, now waning) "build it and they will
> come" optimism about a
Tres, I am a Python3 enthusiast and realist. I did not expect major
adoption for about 3 years (more optimistic than the 5 years of some).
If you are feeling pressured to 'move' to Python3, it is not from me. I
am sure you will do so on your own, perhaps even with enthusiasm, when
it will be g
On 6/22/2010 9:24 AM, Michael Urman wrote:
By idempotent-when-possible, I mean to_bytes(str_or_bytes, encoding,
errors) that would pass an instance of bytes through, or encode an
instance of str. And of course a to_str that performs similarly,
passing str through and decoding bytes. While bytes(
On Tue, Jun 22, 2010 at 08:24:28AM -0500, Michael Urman wrote:
> On Tue, Jun 22, 2010 at 00:28, Stephen J. Turnbull wrote:
> > Michael Urman writes:
> >
> > > It is somewhat troublesome that there doesn't appear to be an obvious
> > > built-in idempotent-when-possible function that gives back th
On Mon, Jun 21, 2010 at 10:28 PM, Stephen J. Turnbull
wrote:
> Michael Urman writes:
>
> > It is somewhat troublesome that there doesn't appear to be an obvious
> > built-in idempotent-when-possible function that gives back the
> > provided bytes/str,
>
> If you want something idempotent, it's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Noller wrote:
>
> On Jun 19, 2010, at 10:13 AM, Tres Seaver wrote:
>>> Nothing is set in stone; if something is incredibly painful, or worse
>>> yet broken, then someone needs to file a bug, bring it to this list,
>>> or bring up a patch.
>> O
On Tue, Jun 22, 2010 at 00:28, Stephen J. Turnbull wrote:
> Michael Urman writes:
>
> > It is somewhat troublesome that there doesn't appear to be an obvious
> > built-in idempotent-when-possible function that gives back the
> > provided bytes/str,
>
> If you want something idempotent, it's alr
Nick Coghlan writes:
> On Tue, Jun 22, 2010 at 4:49 PM, Stephen J. Turnbull
> wrote:
> > > Which works if and only if your outputs are truly unicode-able.
> >
> > With PEP 383, they always are, as long as you allow Unicode to be
> > decoded to the same garbage your bytes-based program woul
On Tue, Jun 22, 2010 at 4:49 PM, Stephen J. Turnbull wrote:
> > Which works if and only if your outputs are truly unicode-able.
>
> With PEP 383, they always are, as long as you allow Unicode to be
> decoded to the same garbage your bytes-based program would have
> produced anyway.
Could it be t
P.J. Eby writes:
> I know, it's a hard thing to wrap one's head around, since on the
> surface it sounds like unicode is the programmer's savior.
I don't need to wrap my head around it. It's been deeply embedded,
point first, and the nasty barbs ensure that I have no desire to pull
it back out
Michael Urman writes:
> It is somewhat troublesome that there doesn't appear to be an obvious
> built-in idempotent-when-possible function that gives back the
> provided bytes/str,
If you want something idempotent, it's already the case that
bytes(b'abc') => b'abc'. What might be desirable is
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
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
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
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 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
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 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
...
>> 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 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 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
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
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
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
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
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
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 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
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
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
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
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'
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 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 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 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
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
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 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
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 individual characters can't be given bytes
and have it work.
That
On Mon, 21 Jun 2010 08:01:08 am Laurens Van Houtven wrote:
> I think doing unicode/str properly in 2.x is very important, #python
> stresses it quite often, I think Py3k's strictness is a good idea
> because people very often write something that appears to work for a
> long time, and then someone
On Jun 20, 2010, at 6:21 PM, Terry Reedy wrote:
On 6/20/2010 4:10 PM, Jesse Noller wrote:
On Sun, Jun 20, 2010 at 2:40 PM, P.J. Eby
wrote:
While reading over this thread, I'm wondering whether at least my
(WSGI-related) problems in this area would be solved by the
availability of
a ty
On 6/20/2010 4:10 PM, Jesse Noller wrote:
On Sun, Jun 20, 2010 at 2:40 PM, P.J. Eby wrote:
While reading over this thread, I'm wondering whether at least my
(WSGI-related) problems in this area would be solved by the availability of
a type (say "bstr") that was simply a wrapper providing stri
> I hate to reply with a simple +1 - but I've heard this pain and
> proposal from a frightening number of people, something which allowed
> you to use bytes with some of the sting methods would go a really long
> way to solving a lot of peoples python 3 pain. I don't relish the idea
> that once peo
On Sun, Jun 20, 2010 at 11:30 PM, Terry Reedy wrote:
> On 6/20/2010 8:26 AM, Giampaolo Rodolà wrote:
>
>> I attempted to port pyftpdlib to python 3 several times and the
>> biggest show stopper has always been the bytes / string difference
>> introduced by Python 3 which forces you to *know* and *
On 6/20/2010 1:30 PM, Stephen J. Turnbull wrote:
The topic on #python seems unlikely to change at this point
I just verified that, thanks to Laurens and whoever, it has been.
It is now rather good.
Terry Jan Reedy
___
Python-Dev mailing list
Python-
On 6/20/2010 8:26 AM, Giampaolo Rodolà wrote:
I attempted to port pyftpdlib to python 3 several times and the
biggest show stopper has always been the bytes / string difference
introduced by Python 3 which forces you to *know* and *use* Unicode
every time you deal with some text and 2to3 is comp
On Sun, Jun 20, 2010 at 10:57:05AM -0700, Guido van Rossum wrote:
> Education is needed. When you search Google (or Bing, for that matter
> :-) for "python unicode" the first hit is
> http://www.amk.ca/python/howto/unicode, which is highly detailed but
> probably too much information for the typica
On Sun, Jun 20, 2010 at 2:40 PM, P.J. Eby wrote:
> At 10:57 AM 6/20/2010 -0700, Guido van Rossum wrote:
>>
>> The problem comes exactly where you find it: when *porting* existing
>> code that uses aforementioned ways to alleviate the pain, you find
>> that the hacks no longer work and a properly l
At 10:57 AM 6/20/2010 -0700, Guido van Rossum wrote:
The problem comes exactly where you find it: when *porting* existing
code that uses aforementioned ways to alleviate the pain, you find
that the hacks no longer work and a properly layered design is needed
that clearly distinguishes between whi
Guido van Rossum writes:
> On the #python issue, I expect that IRC is much less influential that
> some here fear (and than some fervent IRC users believe). I don't see
> reason for panic or heavy-handed interference. OTOH engaging the
> channel operators more in python-dev sounds like a usefu
On Sun, Jun 20, 2010 at 7:30 PM, Stephen J. Turnbull wrote:
> Antoine Pitrou writes:
> But we have a PR problem *now*. The loyal opposition clearly intend
> to continue trash-talking Python 3 until the libraries get to 100% (or
> a government-approved approximation of 100%). The topic on #python
Pass the ketchup, I need to eat my words.
I wrote:
> The loyal opposition clearly intend to continue trash-talking
> Python 3 until the libraries get to 100% (or a government-approved
> approximation of 100%). The topic on #python seems unlikely to
> change at this point, with both Glyph and
On Sun, Jun 20, 2010 at 5:26 AM, Giampaolo Rodolà wrote:
> 2010/6/20 Steven D'Aprano :
>> Python 2.x introduced Unicode strings. Python 3.x merely makes them the
>> default.
>
> "Merely"? To me this looks as the main reason why a lot of projects
> haven't been ported to Python 3 yet.
> I attempted
On Sun, 20 Jun 2010 14:26:28 +0200
Giampaolo Rodolà wrote:
> I attempted to port pyftpdlib to python 3 several times and the
> biggest show stopper has always been the bytes / string difference
> introduced by Python 3 which forces you to *know* and *use* Unicode
> every time you deal with some te
On Mon, 21 Jun 2010 02:30:17 +0900
"Stephen J. Turnbull" wrote:
> Antoine Pitrou writes:
>
> > I think it's an unfortunate analogy.
>
> Propose a better one, then. I'm definitely not wedded to the ones
> I've proposed!
I'm not sure why you want an analogy. Python 3 improves the language
and d
I can only imagine how difficult can it be to do such a conversion in
a project like Twisted or Django where the I/O plays a fundamental
role.
For Django, you don't need to imagine, but can look at the actual changes:
http://bitbucket.org/loewis/django-3k/
The choice of forcing the user to us
Antoine Pitrou writes:
> I think it's an unfortunate analogy.
Propose a better one, then. I'm definitely not wedded to the ones
I've proposed!
But we have a PR problem *now*. The loyal opposition clearly intend
to continue trash-talking Python 3 until the libraries get to 100% (or
a governmen
2010/6/20 Steven D'Aprano :
> Python 2.x introduced Unicode strings. Python 3.x merely makes them the
> default.
"Merely"? To me this looks as the main reason why a lot of projects
haven't been ported to Python 3 yet.
I attempted to port pyftpdlib to python 3 several times and the
biggest show sto
On Sun, Jun 20, 2010 at 7:32 PM, Antoine Pitrou wrote:
>> True, C++ does introduce a
>> lot of new features, but most programmers migrating from C to C++
>> don't learn to use them properly for years, if ever, I'm told.
>
> I don't see how Python 3 has that problem. You can be productive here
> an
On Sun, 20 Jun 2010 18:14:02 +0900
"Stephen J. Turnbull" wrote:
>
> > had my experience would have been different. It's bad enough to have to
> > tell people "Python 3 is currently lacking some critical libraries,
> > particularly third-party libraries" without also telling them (wrongly
>
Steven D'Aprano writes:
> Frankly, I believe that pushing the meme that "Python 3 is different" is
> a strategic mistake.
I agree that it's strategically undesirable. Unfortunately, the
genuine backward incompatibility, as well as the huge mind-share
already garnered by what I consider wrong-
On Sun, 20 Jun 2010 12:13:34 am Tres Seaver wrote:
> > I guess tutorial welcome, rather than patch welcome then ;)
>
> The only folks who can write the tutorial are the ones who have
> already drunk the koolaid. Note that I've been making my living with
> Python for about twelve years now, and wo
On Sat, 19 Jun 2010 11:55:29 pm Stephen J. Turnbull wrote:
> If you want to do Python 3 a favor,
> make sure that they understand that Python 3 is *not* an "upgrade" of
> Python 2.
[...]
> Python 3 is a Python-2-like language, but even though it's built on
> the same design principles, and uses ne
On Jun 18, 2010, at 7:39 PM, Terry Reedy wrote:
> On 6/18/2010 6:51 PM, Raymond Hettinger wrote:
>> There has been a disappointing
>> lack of bug reports across the board for 3.x.
>
> Here is one from this week involving the interaction of array and bytearray.
> It needs a comment from someone
At 10:55 PM 6/19/2010 +0900, Stephen J. Turnbull wrote:
They really don't care that writing Python 3 was fun, and that
programming in Python 3 is more fun than ever. That doesn't
compensate for even one lingering str/bytes bogosity to most of
them, and since they don't get paid for fixing Pyth
On Sat, Jun 19, 2010 at 10:59 AM, Jesse Noller wrote:
>
>
> On Jun 19, 2010, at 10:13 AM, Tres Seaver wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Jesse Noller wrote:
>>>
>>> On Fri, Jun 18, 2010 at 4:48 PM, P.J. Eby wrote:
At 05:22 PM 6/18/2010 +, l...@rmi.ne
On Jun 19, 2010, at 10:13 AM, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Noller wrote:
On Fri, Jun 18, 2010 at 4:48 PM, P.J. Eby
wrote:
At 05:22 PM 6/18/2010 +, l...@rmi.net wrote:
So here it is: The prevailing view is that 3.X developers hoisted
things
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Noller wrote:
> On Fri, Jun 18, 2010 at 4:48 PM, P.J. Eby wrote:
>> At 05:22 PM 6/18/2010 +, l...@rmi.net wrote:
>>> So here it is: The prevailing view is that 3.X developers hoisted things
>>> on users that they did not fully work through t
l...@rmi.net writes:
> I agree that 3.X isn't all bad, and I very much hope it succeeds. And
> no, I have no answers; I'm just reporting the perception from downwind.
The fact is, though, that many of your "downwind" readers are not the
audience for Python 3, not yet. If you want to do Pytho
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael Foord wrote:
> I didn't make myself clear. The expected disappointment I was referring
> to was about the rate of adoption, not about the quality of the product.
>
> I'm still baffled as to how a bug in the cgi module (along with the
> ackn
On 6/18/2010 6:51 PM, Raymond Hettinger wrote:
There has been a disappointing
lack of bug reports across the board for 3.x.
Here is one from this week involving the interaction of array and
bytearray. It needs a comment from someone who can understand the C-API
based patch, which is beyond me
On 18/06/2010 23:51, Raymond Hettinger wrote:
On Jun 18, 2010, at 3:08 PM, Michael Foord wrote:
I'm still baffled as to how a bug in the cgi module (along with the
acknowledged email problems) is such a big deal. Was it reported and then
languished in the bug tracker? That would be bad io
On Jun 18, 2010, at 3:08 PM, Michael Foord wrote:
> I'm still baffled as to how a bug in the cgi module (along with the
> acknowledged email problems) is such a big deal. Was it reported and then
> languished in the bug tracker? That would be bad ion its own but if it was
> only recently disco
Michael Foord:
> Python 3.0 was *declared* to be an experimental release, and by most
> standards 3.1 (in terms of the core language and functionality) was a solid
> release.
That looks to me like an after-the-event rationalization. The
release note for Python 3.0 (and the "What's new") gives
e time to port seems
like it may be just enough to tip the scales altogether.
--Mark Lutz (http://learning-python.com, http://rmi.net/~lutz)
-Original Message-
From: Michael Foord
To: l...@rmi.net
Subject: Re: [Python-Dev] email package status in 3.X
Date: Fri, 18 Jun 2010 18:27:46
On Fri, Jun 18, 2010 at 4:48 PM, P.J. Eby wrote:
> At 05:22 PM 6/18/2010 +, l...@rmi.net wrote:
>>
>> So here it is: The prevailing view is that 3.X developers hoisted things
>> on users that they did not fully work through themselves. Unicode is
>> prime among these: for all the talk here ab
At 05:22 PM 6/18/2010 +, l...@rmi.net wrote:
So here it is: The prevailing view is that 3.X developers hoisted things
on users that they did not fully work through themselves. Unicode is
prime among these: for all the talk here about how 2.X was broken in
this regard, the implications of the
gh to tip the scales altogether.
--Mark Lutz (http://learning-python.com, http://rmi.net/~lutz)
> -Original Message-
> From: Michael Foord
> To: l...@rmi.net
> Subject: Re: [Python-Dev] email package status in 3.X
> Date: Fri, 18 Jun 2010 18:27:46 +0100
>
> On 18/06/20
2010/6/18 Bill Janssen :
> Giampaolo Rodolà wrote:
>
>> 2010/6/17 Bill Janssen :
>>
>> > There's a related meta-issue having to do with antique protocols.
>>
>> Can I know what meta-issue are you talking about exactly?
>
> Giampaolo, I believe that you and I have already discussed this on one
> of
Giampaolo Rodolà wrote:
> 2010/6/17 Bill Janssen :
>
> > There's a related meta-issue having to do with antique protocols.
>
> Can I know what meta-issue are you talking about exactly?
Giampaolo, I believe that you and I have already discussed this on one
of the FTP issues.
Bill
On 18/06/2010 18:22, l...@rmi.net wrote:
Python 3.0 was *declared* to be an experimental release, and by most
standards 3.1 (in terms of the core language and functionality) was a
solid release.
Any reasonable expectation about Python 3 adoption predicted that it
would take years, and would incl
> Python 3.0 was *declared* to be an experimental release, and by most
> standards 3.1 (in terms of the core language and functionality) was a
> solid release.
>
> Any reasonable expectation about Python 3 adoption predicted that it
> would take years, and would include going through a phase of
On 18/06/2010 16:09, l...@rmi.net wrote:
Replying en masse to save bandwidth here...
Barry Warsaw writes:
We know it, we have extensively discussed how to fix it, we have IMO a good
design, and we even have someone willing and able to tackle the problem. We
need to find a sufficient sourc
Replying en masse to save bandwidth here...
Barry Warsaw writes:
> We know it, we have extensively discussed how to fix it, we have IMO a good
> design, and we even have someone willing and able to tackle the problem. We
> need to find a sufficient source of funding to enable him to do the work
1 - 100 of 109 matches
Mail list logo
