Neil Schemenauer writes:
> That's it. After sleeping on it, I'm not sure that's enough Python
> 2.x compatibility to help a lot. I haven't ported much code to 3.x
> yet but I imagine the following are major challenges:
>
> - comparisons between str and bytes always returns unequal
>
> -
On 2014-01-18, Stephen J. Turnbull wrote:
> The above are descriptions of current behavior (ie, unchanged by PEPs
> 460, 461), and this:
[..]
> is the content of this proposal, is that right?
The proposal is that -2 enables the following:
- %r as an alias for %a (i.e. calls ascii())
- %s wil
Neil Schemenauer writes:
> I'd like to try porting code making use of the -2 feature to see how
> helpful it is. The behavior is partway between Python 2.x laziness
> and Python 3.x strictness in terms of specifying encodings.
>
> Python 2.x:
> [...]
> Python 3.x:
> [...]
The above are
Regardless, I still feel the introduction of a switch and all that stuff is
too complicated. I understand you position, since all my applications are
written in Python 2(except 1). However, I don't think this is the best
solution.
On Fri, Jan 17, 2014 at 2:19 PM, Neil Schemenauer wrote:
> On 20
Glenn Linderman wrote:
> -1 overall.
>
> Not worth the extra complexity in documentation and command line
> parameters.
Really? It's less than 20 lines of code to implement, probably
similar to document. With millions maybe billions of lines of
existing Python 2.x code to port, I'm dismayed to
On 2014-01-17, Ryan Gonzalez wrote:
> A command line parameter??
I believe it has to be global flag. A __future__ statement will not
work. Probably we should allow the flag to be set with an
environment variable as well.
> The annoying part would be telling every single user to call Python with
A command line parameter??
The annoying part would be telling every single user to call Python with a
certain argument and hope they read the README.
If it's a library, out of the question.
If it's a program, well, I hope your users read READMEs.
On Fri, Jan 17, 2014 at 4:49 AM, Neil Schemenau
I've refined this idea a little in my latest PEP 461 patch (issue
20284). Continuing to use %s instead of introducing %b seems
better. I've called the commmand-line option -2, it could be used
to enable other similar porting aids.
I'd like to try porting code making use of the -2 feature to see
On 1/17/2014 2:49 AM, Neil Schemenauer wrote:
As I see it, there are two separate goals in adding formatting
methods to bytes. One is to make it easier to write new programs
that manipulate byte data. Another is to make it easier to upgrade
Python 2.x programs to Python 3.x. Here is an idea to
As I see it, there are two separate goals in adding formatting
methods to bytes. One is to make it easier to write new programs
that manipulate byte data. Another is to make it easier to upgrade
Python 2.x programs to Python 3.x. Here is an idea to better
address these separate goals.
Introduce
10 matches
Mail list logo
