py3k s***s

[Paul Boddie]

Re: py3k s***s

On 16 Apr, 15:16, Marco Mariani <ma...@sferacar ta.comwrote:

>
Do you mean Ruby's track in providing backward compatibility is better
than Python's?
>
Googling for that a bit, I would reckon otherwise.

So would I, but then it isn't the Ruby developers that are *promising*
to break backward compatibility *and* claiming that it's a good thing.
This means that those wanting to sell Ruby as a solution can play the
political game and claim a better roadmap even if they end up causing
more disruption than Python 3.x does: it's like electioneering on a
platform of "no new taxes" and then breaking that promise after
gaining power.

I find myself agreeing strongly with Aaron about this. Lots of things
were considered "wrong" with Python over the years, but I'm
unconvinced about the remedy:

http://wiki.python.org/moin/PythonWarts

There seems to be a lot of "out with the old" in the Free Software
world of late. Another example: KDE 3.x eventually finds itself in
products with widespread distribution; the developers bring out a less
capable version (but with more "bling") that everyone is now
supposedly working on instead; momentum is lost.

Paul

[Carl Banks]

Re: py3k s***s

On Apr 17, 4:41 am, Sverker Nilsson <s...@sncs.sewr ote:

On Apr 17, 12:02 am, Carl Banks <pavlovevide... @gmail.comwrote :
>
>
>

On Apr 16, 12:40 pm, Aaron Watters <aaron.watt...@ gmail.comwrote:

>

On Apr 16, 12:27 pm, Rhamphoryncus <rha...@gmail.c omwrote:

>

On Apr 16, 6:56 am, Aaron Watters <aaron.watt...@ gmail.comwrote:

>

I don't get it. It ain't broke. Don't fix it.

>

So how would you have done the old-style class to new-style class
transition?

>

I'd ignore it. I never understood it and never had
any need for it anyway. New-style classes and metaclasses
were a complicated solution to an unimportant problem in
my opinion. And also a fiendish way to make code
inscrutible -- which I thought was more of a Perl thing
than a Python thing, or should be.

>

I must be missing some of the deeper issues here. Please
educate me.

>

The deeper issue is that you're benefiting from these "unimportan t"
changes even if you never use them yourself.

>

Carl Banks

>
That just seems a BIT categorical for a statement. Who is 'you'?

The Python community, more or less. The person I was replying to,
specifically.

I don't see I benefit from any important or unimportant features in
py3k.

I was talking about the features added in 2.x. Python 3.0 features
haven't benefited many people (yet).


[snip]

Just my 2c.

If you don't mind me saying, I think you've given us quite a bit more
than 2c in this thread.


Carl Banks

[Aaron Watters]

Re: py3k s***s

On Apr 16, 3:33 pm, "sjdevn...@yaho o.com" <sjdevn...@yaho o.comwrote:

>
Wow, I'd venture that the division changes with ints are the only
thing I'm really concerned about...

Oh I forgot about this one. Yes, I think it's a mistake to
adopt a different convention for division than C/C++/java/C#/Fortran/
Basic...
Just another reason to throw your hands up in frustration, in my
book...

The implications of the string conversion is entirely unclear to me.
I'm betting the libraries will also get "improved" during porting,
either intentionally or accidentally
which means I'll have to carefully rewrite
and retest any code which uses the
new and improved libraries ... and the "deprecated/removed"
libs won't work anymore, so I can't just put them into
my package...

sigh.

-- Aaron Watters

===

http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=sigh

[Michael Torrie]

Re: py3k s***s

Aaron Watters wrote:

What I'm saying is that, for example, there are a lot
of cool tools out there for using Python to manipulate
postscript and latex and such. Most of those tools
require no maintenance, and the authors are not paying
any attention to them, and they aren't interested in
messing with them anymore.

What makes you think these tools are all going to mysteriously stop
working? Python 2.x will be around for a long, long time. Currently
there are still Python 1.5 apps that are still in use and circulation
and, with Python 1.5 installed, still work fine. The same for Python
2.x. Honestly I don't understand all this FUD over the move to Python
3.x Those that want/need to migrate will. Others won't have to.
What's the big deal?

Further, 90% of these little, finished utilities are pure python, and so
converting them to Python 3.x is a trivial mechanical conversion if the
maintainer cared.

[Diez B. Roggisch]

Re: py3k s***s

And I have been benefiting from Python in general, so far. Thanks,

community.
>
But now... I'll probably stop posting here for now, & I may stop other
things too.
>
Just my 2c.

You know what I was just wondering about? All these C-written
cross-platform libraries (which Python users benefit from, most probably
including evven you) that run on different unixes & windows, which are a
much greater diversity to handle than the not-even-yet-settled
differences between Py3K & 2.x. How the heck do they do that?

Oh, and these dreaded 64 bit processors, possibly with multi-cores,
which need changes in code as well, to be utilized to their power.

But then, these guys most probably don't whine about diversity and
constant change, and cry out useless threats to people who probably
can't care less.

Fare well, if you must. But getting mad over something which impact you
can't even judge right now is childish. Nothing else.

Diez

[John Machin]

Re: py3k s***s

Diez B. Roggisch wrote:

>And I have been benefiting from Python in general, so far. Thanks,
>community.
>>
>But now... I'll probably stop posting here for now, & I may stop other
>things too.
>>
>Just my 2c.

>
You know what I was just wondering about? All these C-written
cross-platform libraries (which Python users benefit from, most probably
including evven you) that run on different unixes & windows, which are a
much greater diversity to handle than the not-even-yet-settled
differences between Py3K & 2.x. How the heck do they do that?
>
Oh, and these dreaded 64 bit processors, possibly with multi-cores,
which need changes in code as well, to be utilized to their power.
>
But then, these guys most probably don't whine about diversity and
constant change, and cry out useless threats to people who probably
can't care less.
>
Fare well, if you must. But getting mad over something which impact you
can't even judge right now is childish. Nothing else.
>

At the start of this thread I was pondering the possible meaning of the
verb "to sverk". Thanks for the exposition, Diez.

[Sverker Nilsson]

Re: py3k s***s

On Apr 18, 12:59 am, "Diez B. Roggisch" <de...@nospam.w eb.dewrote:

And I have been benefiting from Python in general, so far. Thanks,
community.

>

But now... I'll probably stop posting here for now, & I may stop other
things too.

>

Just my 2c.

>
You know what I was just wondering about? All these C-written
cross-platform libraries (which Python users benefit from, most probably
including evven you) that run on different unixes & windows, which are a
much greater diversity to handle than the not-even-yet-settled
differences between Py3K & 2.x. How the heck do they do that?
>
Oh, and these dreaded 64 bit processors, possibly with multi-cores,
which need changes in code as well, to be utilized to their power.
>
But then, these guys most probably don't whine about diversity and
constant change, and cry out useless threats to people who probably
can't care less.
>
Fare well, if you must. But getting mad over something which impact you
can't even judge right now is childish. Nothing else.
>
Diez

Some whine. Some just don't care. Why not whine?

[Sverker Nilsson]

Re: py3k s***s

On Apr 18, 1:27 am, John Machin <sjmac...@lexic on.netwrote:

Diez B. Roggisch wrote:

And I have been benefiting from Python in general, so far. Thanks,
community.

>

But now... I'll probably stop posting here for now, & I may stop other
things too.

>

Just my 2c.

>

You know what I was just wondering about? All these C-written
cross-platform libraries (which Python users benefit from, most probably
including evven you) that run on different unixes & windows, which are a
much greater diversity to handle than the not-even-yet-settled
differences between Py3K & 2.x. How the heck do they do that?

>

Oh, and these dreaded 64 bit processors, possibly with multi-cores,
which need changes in code as well, to be utilized to their power.

>

But then, these guys most probably don't whine about diversity and
constant change, and cry out useless threats to people who probably
can't care less.

>

Fare well, if you must. But getting mad over something which impact you
can't even judge right now is childish. Nothing else.

>
At the start of this thread I was pondering the possible meaning of the
verb "to sverk". Thanks for the exposition, Diez.

Yah, and I am getting all the more depressed.

Thanks?

[Juergen Kareta]

Re: py3k s***s

Diez B. Roggisch schrieb:

>And I have been benefiting from Python in general, so far. Thanks,
>community.
>>
>But now... I'll probably stop posting here for now, & I may stop other
>things too.
>>
>Just my 2c.

>
You know what I was just wondering about? All these C-written
cross-platform libraries (which Python users benefit from, most probably
including evven you) that run on different unixes & windows, which are a
much greater diversity to handle than the not-even-yet-settled
differences between Py3K & 2.x. How the heck do they do that?
>
Oh, and these dreaded 64 bit processors, possibly with multi-cores,
which need changes in code as well, to be utilized to their power.
>
But then, these guys most probably don't whine about diversity and
constant change, and cry out useless threats to people who probably
can't care less.
>
Fare well, if you must. But getting mad over something which impact you
can't even judge right now is childish. Nothing else.
>
Diez

1+

[Robin Becker]

Re: py3k s***s

Diez B. Roggisch wrote:
..

You know what I was just wondering about? All these C-written
cross-platform libraries (which Python users benefit from, most probably
including evven you) that run on different unixes & windows, which are a
much greater diversity to handle than the not-even-yet-settled
differences between Py3K & 2.x. How the heck do they do that?

..
I'm in the process of attempting a straightforward port of a relatively simple
package which does most of its work by writing out files with a more or less
complicated set of possible encodings. So far I have used all the 2to3 tools and
a lot of effort, but still don't have a working version. This must be the worst
way to convert people to unicode. When tcl went through this they chose the
eminently sensible route of not choosing a separate unicode type (they used utf8
byte strings instead). Not only has python chosen to burden itself with two
string types, but with 3 they've swapped roles. This is certainly the first time
I've had to decide on an encoding before writing simple text to a file.

Of course we may end up with a better language, but it will be a worse(more
complex) tool for many simple tasks. Using a complex writing with many glyphs
costs effort no matter how you do it, but I just use ascii :( and it's still an
effort.

I find the differences in C/OS less hard to understand than why I need
bytes(x,'encodi ng') everywhere I just used to use str(x).
-old fart-ly yrs-
Robin Becker

[Diez B. Roggisch]

Re: py3k s***s

Robin Becker schrieb:

I'm in the process of attempting a straightforward port of a relatively
simple package which does most of its work by writing out files with a
more or less complicated set of possible encodings. So far I have used
all the 2to3 tools and a lot of effort, but still don't have a working
version. This must be the worst way to convert people to unicode. When
tcl went through this they chose the eminently sensible route of not
choosing a separate unicode type (they used utf8 byte strings instead).
Not only has python chosen to burden itself with two string types, but
with 3 they've swapped roles. This is certainly the first time I've had
to decide on an encoding before writing simple text to a file.

Which is the EXACT RIGHT THING TO DO! see below.

>
Of course we may end up with a better language, but it will be a
worse(more complex) tool for many simple tasks. Using a complex writing
with many glyphs costs effort no matter how you do it, but I just use
ascii :( and it's still an effort.
>
I find the differences in C/OS less hard to understand than why I need
bytes(x,'encodi ng') everywhere I just used to use str(x).

If you google my name + unicode, you see that I'm often answering
questions regarding unicode. I wouldn't say I'm a recognized expert on
the subject, but I certainly do know enough to deal with it whenever I
encounter it.

And from my experience with the problems in general, and specificly in
python, as well as trying to help others I can say that:

- 95% of the times, the problem is in front of the keyboard.

- programmers stubbornly refuse to *learn* what unicode is, and what
an encoding is, and what role utf-8 plays. Instead, the resort to a
voodoo-approach of throwing in various encode/decode-calls + a good deal
of cat's feces in hope of wriggling themselves out of the problem.

- it is NOT sensible to use utf8 as unicode-"type" - that is as bad as
it can get because you don't see the errors, but instead mangle your
data and end up with a byte-string-mess. If that is your road to heaven,
by all means chose it - and don't use unicode at all. and be prepared
for damnation :)

If your programs worked for now, but don't do anymore because of Py3K
introducing mandatory unicode-objects for string-literals it pretty much
follows that they *seem* to work, but very, very probably fail in the
face of actual i18nized data.

The *only* sensible thing to do is follow these simple rules - and these
apply with python 2.x, and will be enforced by 3k which is a good thing
IMHO:

- when you read data from somewhere, make sure you know which encoding
it has, and *immediatly* convert it to unicode

- when you write data, make sure you know which encoding you want it
to have (in doubt, chose utf-8 to prevent loss of data) and apply it.

- XML-parsers take byte-strings & spit out unicode. Period.

I neither want to imply that you are an Idiot nor that unicode doesn't
have it's complexities. And I'd love to say that Python wouldn't add to
these by having two string-types.

But the *real* problem is that it used to have only bytestrings, and
finally Py3K will solve that issue.

Diez

[Istvan Albert]

Re: py3k s***s

On Apr 18, 1:39 am, Sverker Nilsson <s...@sncs.sewr ote:

Some whine. Some just don't care. Why not whine?

Whining and ranting is actually good for the psyche. It is better to
get it out of your system.

As for your original post, no doubt there are substantial downsides to
introducing Py3K, but as Guido put it every language must "change or
die".

Of course we could end up with "change and die" as well. I for one am
an optimist, I think there are several substantial improvements to the
language that today may not be apparent for a casual observer, yet
will allow it to evolve into an even more powerful and fun language

i.

[Aaron Watters]

Re: py3k s***s

On Apr 17, 12:27 pm, Michael Torrie <torr...@gmail. comwrote:

What's the big deal?

The big deal is that I would love to see Django
become the standard platform for web development,
for example. That will be much less likely if
60% of the contributed tools for Django don't work
for Python 3000 and 20% don't work for Python 2.6.
Expecting volunteer contributors
to support both is not realistic. It's hard enough
to support one adequately. Even if you could hope
to support both with the same code, just testing in
both environments would be onerous.

It would be another matter entirely if py3k offered
major new functionality like full stackless microthreads
but it doesn't (afaik -- correct me please).
From my perspective it's just a pain in the @$$.
By the way, full stackless microthreads don't seem
to require breaking most (or any) existing code.

I really like developing in Python -- but it's hard
to keep doing it when the growth curve is so slow
and a so many people have deep reservations about it,
inspired in part, justifiably, by nonsense like this.
In fact, I basically stopped. Then I came back. Now
I'm wondering if it was such a good idea...

-- Aaron Watters

====

http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=stupid+bug

[Ivan Illarionov]

Re: py3k s***s

On Fri, 18 Apr 2008 07:16:35 -0700, Aaron Watters wrote:

The big deal is that I would love to see Django become the standard
platform for web development, for example. That will be much less
likely if 60% of the contributed tools for Django don't work for Python
3000 and 20% don't work for Python 2.6. Expecting volunteer contributors
to support both is not realistic. It's hard enough to support one
adequately. Even if you could hope to support both with the same code,
just testing in both environments would be onerous.

You shouldn't worry about Django. Python 3000 port has already started
[1]. And the assumption that "to support both is not realistic" may be
wrong [2] in this case.

[1] http://wiki.python.org/moin/PortingDjangoTo3k
[2] http://groups.google.com/group/djang...f399820ee07ce5

--
Ivan

[Nick Stinemates]

Re: py3k s***s

On Mon, Apr 14, 2008 at 04:10:48PM -0700, Sverker Nilsson wrote:

do i dare to open a thread about this?
>
come on you braver men
>
we are at least not bought by g***le
>
but why? others have said it so many times i think
>
:-////
>
but why? a few syntactic 'cleanups' for the cost of a huge rewrite of
all the code that have been builtup from all the beginning when the
once great Python came along and people began to use it and write code
for it. Like all that code would have to be rewritten. blaah.
and i have perhaps been drinking but i have been p**d all week since i
began look into this:-(
--
http://mail.python.org/mailman/listinfo/python-list

Yo, no one here is a child so don't litter your title and text with hard
to read bullshit.

--
Nick Stinemates (nick@stinemate s.org)

http://nick.stinemates.org