Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #56759 > unrolled thread

Python was designed (was Re: Multi-threading in Python vs Java)

Back to article view | Back to comp.lang.python

Contents

  Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-13 09:37 +1100
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-13 03:38 +0000
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-13 15:34 +1100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Roy Smith <roy@panix.com> - 2013-10-13 09:04 -0400
        Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-14 03:39 -0700
    Re: Python was designed (was Re: Multi-threading in Python vs Java) John Nagle <nagle@animats.com> - 2013-10-14 12:18 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-15 09:43 +1100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-15 10:11 +1100
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve@pearwood.info> - 2013-10-15 08:50 +0000
          Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-15 08:48 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Janssen <dreamingforward@gmail.com> - 2013-10-14 18:31 -0700
        Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-14 20:02 -0700
          Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Janssen <dreamingforward@gmail.com> - 2013-10-15 13:26 -0700
            Re: Python was designed (was Re: Multi-threading in Python vs Java) Grant Edwards <invalid@invalid.invalid> - 2013-10-15 21:46 +0000
              Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Janssen <dreamingforward@gmail.com> - 2013-10-16 10:45 -0700
                Re: Python was designed (was Re: Multi-threading in Python vs Java) Grant Edwards <invalid@invalid.invalid> - 2013-10-16 18:42 +0000
            Re: Python was designed (was Re: Multi-threading in Python vs Java) "Rhodri James" <rhodri@wildebst.demon.co.uk> - 2013-10-15 23:01 +0100
              Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-15 21:45 -0700
              Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Janssen <dreamingforward@gmail.com> - 2013-10-16 10:57 -0700
                Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-16 11:25 -0700
                  Re: Python was designed (was Re: Multi-threading in Python vs Java) Skip Montanaro <skip@pobox.com> - 2013-10-16 13:49 -0500
                  Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-17 07:40 +1100
                  Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Janssen <dreamingforward@gmail.com> - 2013-10-16 17:13 -0700
                  Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-17 11:28 +1100
                  Re: Python was designed (was Re: Multi-threading in Python vs Java) Ned Batchelder <ned@nedbatchelder.com> - 2013-10-16 20:47 -0400
                    Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-16 18:30 -0700
                      Re: Python was designed (was Re: Multi-threading in Python vs Java) Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-10-17 11:20 +0300
                  Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Janssen <dreamingforward@gmail.com> - 2013-10-16 17:53 -0700
                    Re: Python was designed Piet van Oostrum <piet@vanoostrum.org> - 2013-10-16 22:33 -0400
                    Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve@pearwood.info> - 2013-10-17 05:24 +0000
                    Re: Python was designed (was Re: Multi-threading in Python vs Java) Grant Edwards <invalid@invalid.invalid> - 2013-10-17 13:43 +0000
                  Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-17 12:01 +1100
                  Re: Python was designed (was Re: Multi-threading in Python vs Java) Ned Batchelder <ned@nedbatchelder.com> - 2013-10-16 22:09 -0400
                  Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-17 08:02 +0100
                  Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Janssen <dreamingforward@gmail.com> - 2013-10-17 07:49 -0700
                    Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-18 01:52 +0000
                      Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Janssen <dreamingforward@gmail.com> - 2013-10-17 19:08 -0700
                        Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-17 20:34 -0700
                        Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-18 03:56 +0000
                  Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-18 02:00 +1100
                  Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-17 16:00 +0100
                Re: Python was designed (was Re: Multi-threading in Python vs Java) Grant Edwards <invalid@invalid.invalid> - 2013-10-16 18:44 +0000
                Re: Python was designed (was Re: Multi-threading in Python vs Java) alex23 <wuwei23@gmail.com> - 2013-10-17 10:26 +1000
            Re: Python was designed Piet van Oostrum <piet@vanoostrum.org> - 2013-10-15 23:20 -0400
            Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-15 20:53 -0700
            Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-17 10:32 -0700
              Re: Python was designed (was Re: Multi-threading in Python vs Java) MRAB <python@mrabarnett.plus.com> - 2013-10-17 18:44 +0100
                Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-17 20:15 -0700
              Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-17 19:08 +0100
              Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Janssen <dreamingforward@gmail.com> - 2013-10-17 12:49 -0700
              Re: Python was designed (was Re: Multi-threading in Python vs Java) Ned Batchelder <ned@nedbatchelder.com> - 2013-10-17 16:57 -0400
              Re: Python was designed (was Re: Multi-threading in Python vs Java) Ethan Furman <ethan@stoneleaf.us> - 2013-10-17 15:10 -0700
              Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Janssen <dreamingforward@gmail.com> - 2013-10-17 18:59 -0700
                Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-18 02:57 +0000
          Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-15 23:48 +0100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Terry Reedy <tjreedy@udel.edu> - 2013-10-14 21:35 -0400
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Roy Smith <roy@panix.com> - 2013-10-14 21:50 -0400
          Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-15 08:21 +0100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-15 12:48 +1100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Janssen <dreamingforward@gmail.com> - 2013-10-14 19:11 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-15 13:19 +1100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-15 03:18 +0000
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-15 14:29 +1100
        Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-14 20:48 -0700
          Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve@pearwood.info> - 2013-10-15 05:51 +0000
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-10-15 09:48 +0200
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-15 19:57 +1100
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-15 15:01 +0000
          Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-16 06:09 +1100
          Re: Python was designed (was Re: Multi-threading in Python vs Java) Tim Chase <python.list@tim.thechases.com> - 2013-10-15 16:17 -0500
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-10-15 12:26 +0200
      Re: Python was designed (was Re: Multi-threading in Python vs Java) wxjmfauth@gmail.com - 2013-10-15 13:11 -0700
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-15 22:00 +0100
          Re: Python was designed (was Re: Multi-threading in Python vs Java) wxjmfauth@gmail.com - 2013-10-24 23:14 -0700
            Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 19:05 +0100
              Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-26 04:46 +0000
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-14 14:11 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-14 22:43 +0100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-15 09:45 +1100
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-15 17:18 -0700
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-16 23:49 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-17 18:15 +1100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-17 05:39 -0700
        Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-17 06:00 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Terry Reedy <tjreedy@udel.edu> - 2013-10-17 16:15 -0400
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-17 21:41 +0100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-18 03:14 +0000
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-18 15:12 +1100
          Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-18 04:45 +0000
            Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-18 15:53 +1100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-19 09:57 +0000
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-19 21:49 +1100
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-17 00:23 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Christian Gollwitzer <auriocus@gmx.de> - 2013-10-17 09:42 +0200
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-17 19:24 +1100
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-18 01:58 +0000
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Piet van Oostrum <piet@vanoostrum.org> - 2013-10-17 12:58 -0400
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-17 12:37 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Roy Smith <roy@panix.com> - 2013-10-17 20:01 -0400
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-18 11:09 +1100
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-17 13:54 -0700
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-18 13:32 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-18 21:41 +0100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-18 22:26 -0700
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-19 16:35 +1100
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-21 02:07 +0000
          Re: Python was designed (was Re: Multi-threading in Python vs Java) Roy Smith <roy@panix.com> - 2013-10-20 22:21 -0400
            Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-20 21:44 -0700
          Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-21 17:56 +1100
            Re: Python was designed (was Re: Multi-threading in Python vs Java) Roy Smith <roy@panix.com> - 2013-10-21 09:05 -0400
              Re: Python was designed (was Re: Multi-threading in Python vs Java) Lele Gaifax <lele@metapensiero.it> - 2013-10-22 09:38 +0200
                Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve@pearwood.info> - 2013-10-23 08:16 +0000
                  Re: Python was designed (was Re: Multi-threading in Python vs Java) Ned Batchelder <ned@nedbatchelder.com> - 2013-10-23 06:36 -0400
                    Re: Python was designed (was Re: Multi-threading in Python vs Java) Grant Edwards <invalid@invalid.invalid> - 2013-10-23 14:21 +0000
                  Re: Python was designed (was Re: Multi-threading in Python vs Java) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-10-24 00:31 +1300
                    Re: Python was designed (was Re: Multi-threading in Python vs Java) Lele Gaifax <lele@metapensiero.it> - 2013-10-23 17:56 +0200
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-18 13:56 -0700
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-20 23:44 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-21 18:01 +1100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-21 08:27 +0100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-21 18:31 +1100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-21 08:39 +0100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-21 18:43 +1100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-21 09:11 +0100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve@pearwood.info> - 2013-10-21 08:24 +0000
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Metallicow <metaliobovinus@gmail.com> - 2013-10-21 01:39 -0700
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-21 01:43 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Metallicow <metaliobovinus@gmail.com> - 2013-10-21 02:17 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-21 05:50 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 02:29 +0000
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Skip Montanaro <skip@pobox.com> - 2013-10-22 07:02 -0500
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Metallicow <metaliobovinus@gmail.com> - 2013-10-23 22:31 -0700
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-21 19:55 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-21 20:19 -0700
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-22 17:13 +1100
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-22 00:51 -0700
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-25 01:12 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-26 06:19 +0000
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-26 17:36 +1100
      Re: Python was designed Paul Rubin <no.email@nospam.invalid> - 2013-10-26 10:36 -0700
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-25 23:59 -0700
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-26 12:24 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-26 22:31 +0100

Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8  Next page →

#56838

On Tue, Oct 15, 2013 at 1:11 PM, Mark Janssen <dreamingforward@gmail.com> wrote:
>> "Naive", in this instance, means executing code exactly as written,
>> without optimizing things (and it's not an insult, btw).
>
> In that case, you're talking about a "non-optimizing" interpreter, but
> then, that what is supposed to happen.  I don't think it's fair to
> call it "naive".  An interpreter can't guess what you mean to do in
> every circumstance (threading?).  It's better to do it right (i.e.
> well-defined), *slowly* than to do it fast, incorrectly.

The only thing that's unfair is the interpretation of "naive" as
meaning somehow inferior.

https://en.wikipedia.org/wiki/Naivety#Science

As you say, it's better to do it right slowly than wrong quickly. The
naive method is more easily proven.

ChrisA

[toc] | [prev] | [next] | [standalone]

#56840

On Mon, 14 Oct 2013 12:18:59 -0700, John Nagle wrote:

>     No, Python went through the usual design screwups.  Look at how
> painful the slow transition to Unicode was, from just "str" to Unicode
> strings, ASCII strings, byte strings, byte arrays, 16 and 31 bit
> character builds, and finally automatic switching between rune widths.

Are you suggesting that Guido van Rossum wasn't omniscient back in 1991 
when he first released Python??? OH MY GOD!!! You ought to blog about 
this, let the world know!!!!

But seriously... although the Unicode standard was began as early as 
1987, the first official release of the standard wasn't until nine months 
after the first public release of Python. Do you really consider it a 
"design screwup" that Guido didn't build support for Unicode into Python 
since the beginning?

Given the constraints of backwards-compatibility, and that Unicode didn't 
even exist when Python was first created, I don't think the history of 
Unicode support in Python is a screw-up in the least. And if it is a 
screw-up, it's *Unicode's* screw-up, because they're the ones that 
thought that 16-bit chars would have been enough in the first place.

While it would have been nice if Python had invented the idea of using 
different rune widths back in Python 2.2, I don't think we can hold it 
against GvR or the other Python devs that they didn't. They're only 
human. As far as I know, only one other language does such a thing, 
namely Pike, which is not exactly high-profile.


> Old-style classes vs. new-style classes.  Adding a boolean type as an
> afterthought (that was avoidable; C went through that painful transition
> before Python was created).    Operator "+" as concatenation for
> built-in arrays but addition for NumPy arrays.
> 
>     Each of those reflects a design error in the type system which
> had to be corrected.

Perhaps the first one -- had GvR not decided in the first place that 
built-in types should be separate from user-defined classes, the old vs 
new style class thing would have been unnecessary. But bools are not an 
example. The decision to leave out bools as a separate type was, and 
remains, a perfectly legitimate decision. Perhaps one might argue that 
Python-with-bools is *better* than Python-without-bools, but we would be 
foolish to argue that Python-without-bools was a screw-up. Bools are a 
nice-to-have, not a must-have.

And as for numpy arrays, well, if a long-standing Python developer such 
as yourself doesn't yet understand that this is a feature, not a mistake, 
there's a serious problem, and it's not with Python. Operator overloading 
exists precisely so that custom classes aren't limited to the exact same 
behaviour as built-ins. The fact that the numpy devs made a different 
decision as to what + means than the Python devs is not a sign that the 
design was screwed up, it is a sign that the system works.

It is true that numpy has a problem with Python operators in that there 
aren't enough of them. There have been various attempts to work out a 
good syntax for adding arbitrary additional operators, so that numpy can 
have *both* element-wise operators and array-wise operators at the same 
time. But the lack of this is not a design screw-up. It's a hard problem 
to solve, and sometimes it is better to do without a feature than to add 
it poorly.


>     The type system is now in good shape. The next step is to
> make Python fast.

Whenever I see somebody describing a *language* as "fast" or "slow", 
especially when the next few sentence reveals that they are aware of the 
existence of multiple *implementations*: 

> Python objects have dynamic operations suited to a
> naive interpreter like CPython.  [...]  That's
> part of why Unladen Swallow failed and why PyPy development is so slow.

as if "fast" and "slow" were objective, concrete and most importantly 
*fixed* standards that are the same for everybody, then I suspect 
trolling.

Or to put it another way: Python is already fast. Using PyPy, you can 
write pure-Python code that is faster than the equivalent optimized C 
code compiled using gcc. Even using vanilla CPython, you can write pure 
Python code that (for example) checks over 12,000 nine-digit integers for 
primality per second, on a relatively old and slow computer. If that's 
not *fast*, nothing is.

Whether it is *fast enough* is a completely different question, and one 
which leads to the question "fast enough for what?". But people who like 
to complain about "Python being slow" don't like that question.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#56841

On Tue, Oct 15, 2013 at 2:18 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Even using vanilla CPython, you can write pure
> Python code that (for example) checks over 12,000 nine-digit integers for
> primality per second, on a relatively old and slow computer. If that's
> not *fast*, nothing is.

Agreed. I used to do my major numeric calculations in OS/2 REXX, which
served me quite well in the 1990s. But Python smokes it, even the
oh-so-slow Python 3 where every integer is a bignum (which is fair
comparison against REXX, where every number is... uhh... a string). A
modern, optimized language, even one that's perceived as "slow", is
able to do many orders of magnitude more calculations per second than
a human can.... okay, that's hardly fair, but it's about the only
absolute we're ever going to get :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#56843

On Tuesday, October 15, 2013 8:48:25 AM UTC+5:30, Steven D'Aprano wrote:
> On Mon, 14 Oct 2013 12:18:59 -0700, John Nagle wrote:
> 
> >     No, Python went through the usual design screwups.  Look at how
> > painful the slow transition to Unicode was, from just "str" to Unicode
> > strings, ASCII strings, byte strings, byte arrays, 16 and 31 bit
> > character builds, and finally automatic switching between rune widths.
> 
> 
> Are you suggesting that Guido van Rossum wasn't omniscient back in 1991 
> when he first released Python??? OH MY GOD!!! You ought to blog about 
> this, let the world know!!!!

You are making a strawman out of John's statements:

> Python went through the usual design screwups.
> [screwup list which perhaps pinche John most]
> Each of those reflects a design error in the type system which had to be corrected. 

The reasonable interpretation of John's statements is that propriety and even truth is a function of time: It was inappropriate for GvR to have put in unicode in 1990. It was appropriate in 2008.  And it was done. You may call that being-human-not-God. I call that being real.

To have reality time-invariant, would imply for example that Abraham Lincoln was a racist because he use the word 'negro': (see speech
http://en.wikipedia.org/wiki/Abraham_Lincoln_and_slavery#Legal_and_political )

Or that it is ok to do so today.

[toc] | [prev] | [next] | [standalone]

#56844

On Mon, 14 Oct 2013 20:48:15 -0700, rusi wrote:

> On Tuesday, October 15, 2013 8:48:25 AM UTC+5:30, Steven D'Aprano wrote:
>> On Mon, 14 Oct 2013 12:18:59 -0700, John Nagle wrote:
>> 
>> >     No, Python went through the usual design screwups.  Look at how
>> > painful the slow transition to Unicode was, from just "str" to
>> > Unicode strings, ASCII strings, byte strings, byte arrays, 16 and 31
>> > bit character builds, and finally automatic switching between rune
>> > widths.
>> 
>> 
>> Are you suggesting that Guido van Rossum wasn't omniscient back in 1991
>> when he first released Python??? OH MY GOD!!! You ought to blog about
>> this, let the world know!!!!
> 
> You are making a strawman out of John's statements:
> 
>> Python went through the usual design screwups. [screwup list which
>> perhaps pinche John most] Each of those reflects a design error in the
>> type system which had to be corrected.
> 
> The reasonable interpretation of John's statements is that propriety and
> even truth is a function of time: It was inappropriate for GvR to have
> put in unicode in 1990. It was appropriate in 2008.  And it was done.
> You may call that being-human-not-God. I call that being real.

And I agree with you! But that's not what John wrote. John called it a 
design screw-up. His very first example was the slow transition to 
Unicode. Not "here's a choice that made sense at the time", but "screw-
up".


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#56846

Op 15-10-13 01:11, Chris Angelico schreef:
> On Tue, Oct 15, 2013 at 6:18 AM, John Nagle <nagle@animats.com> wrote:

> 
>> Operator "+" as concatenation for built-in arrays but addition
>> for NumPy arrays.
> 
> ... NumPy definitely isn't part of the language. It's not even part of
> the standard library, it's fully third-party.

That doesn't matter. Adding and concating are different operations and
their are types in which both occur rather naturally. So as a designer
of such a class you have to choose for which operation you use the
natural python operator and for which operation you have to do it
differently. NumPy is just an example that you can't escape this sort
of incompatibilities in python.

-- 
Antoon Pardon

[toc] | [prev] | [next] | [standalone]

#56849

On Tue, Oct 15, 2013 at 6:48 PM, Antoon Pardon
<antoon.pardon@rece.vub.ac.be> wrote:
> Op 15-10-13 01:11, Chris Angelico schreef:
>> On Tue, Oct 15, 2013 at 6:18 AM, John Nagle <nagle@animats.com> wrote:
>
>>
>>> Operator "+" as concatenation for built-in arrays but addition
>>> for NumPy arrays.
>>
>> ... NumPy definitely isn't part of the language. It's not even part of
>> the standard library, it's fully third-party.
>
> That doesn't matter. Adding and concating are different operations and
> their are types in which both occur rather naturally. So as a designer
> of such a class you have to choose for which operation you use the
> natural python operator and for which operation you have to do it
> differently. NumPy is just an example that you can't escape this sort
> of incompatibilities in python.

So what should "abc" + "def" result in, if addition is different from
concatenation? No, adding strings should concatenate them. And other
arithmetic operators make sense, too; Python doesn't happen to
implement str-str or str/str, but some languages do:

> "abc"+"def"-"abc";
(1) Result: "def"
> "abc"-"b";
(2) Result: "ac"
> "foo bar asdf qwer"/" "*"##";
(3) Result: "foo##bar##asdf##qwer"

PHP has separate addition and concatenation operators, and it doesn't
help anything (granted, the biggest problem is that every other
language we work with uses + to concat strings, so it's an easy source
of bugs); having multiple operators for "add the elements of these
arrays" and "add these arrays together" is really orthogonal to the
general issue of adding and concatenating needing different operators.

But as Steven said, the way different types are free to react
differently to the same operators is *GOOD* design in Python. Java
doesn't let user-defined types override operators, so all those
possibilities are closed. You can argue that it's poor design in NumPy
(and people will argue the contrary position), but it's definitely not
a flaw in Python-the-language.

ChrisA

[toc] | [prev] | [next] | [standalone]

#56852

On Tue, 15 Oct 2013 19:57:50 +1100, Chris Angelico wrote:

> On Tue, Oct 15, 2013 at 6:48 PM, Antoon Pardon
> <antoon.pardon@rece.vub.ac.be> wrote:

>> That doesn't matter. Adding and concating are different operations and
>> their are types in which both occur rather naturally. So as a designer
>> of such a class you have to choose for which operation you use the
>> natural python operator and for which operation you have to do it
>> differently. NumPy is just an example that you can't escape this sort
>> of incompatibilities in python.
> 
> So what should "abc" + "def" result in, if addition is different from
> concatenation? 

TypeError, like any other unsupported operator.


> No, adding strings should concatenate them. And other
> arithmetic operators make sense, too; 

For some definition of "sense".


> Python doesn't happen to implement str-str or str/str, but some
> languages do:

Which languages are you talking about?

For the record, if PHP is one of them, I consider that a good sign that 
it shouldn't be done :-)


>> "abc"+"def"-"abc";
> (1) Result: "def"

Eww. What would "xyz" - "abc" give? How about "cba" - "abc"?

And "abcdabc" - "abc"?

Justify your answers.



>> "abc"-"b";
> (2) Result: "ac"
>> "foo bar asdf qwer"/" "*"##";
> (3) Result: "foo##bar##asdf##qwer"

And what, pray tell, would "foo bar" / " " be on its own?

How about "foo bar" * "*"?

Seems to me that using s/t*u as a way to perform substring replacement is 
too clever by half.


> PHP has separate addition and concatenation operators, and it doesn't
> help anything

That's because PHP is beyond help.


> (granted, the biggest problem is that every other language
> we work with uses + to concat strings, so it's an easy source of bugs);
> having multiple operators for "add the elements of these arrays" and
> "add these arrays together" is really orthogonal to the general issue of
> adding and concatenating needing different operators.

Yes -- string concatenation and array operations are not really related, 
although string concatenation is a special case of array concatenation. 
But it is a wild over-generalisation to assume that because strings are 
arrays, and (numeric) arrays might want separate element-wise 
multiplication and whole-array multiplication operators, therefore 
strings need to support the same too.

Personally, I think string and array concatenation ought to be & rather 
than +. That would free up + for element-wise addition for arrays, while 
still allowing & for concatenation. Of course, the cost would be the loss 
of an element-wise bit-and operator. You win some, you lose some.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#56857

On Wed, Oct 16, 2013 at 2:01 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Tue, 15 Oct 2013 19:57:50 +1100, Chris Angelico wrote:
>> Python doesn't happen to implement str-str or str/str, but some
>> languages do:
>
> Which languages are you talking about?
>
> For the record, if PHP is one of them, I consider that a good sign that
> it shouldn't be done :-)

My examples here are from Pike.

>>> "abc"+"def"-"abc";
>> (1) Result: "def"
>
> Eww. What would "xyz" - "abc" give? How about "cba" - "abc"?
>
> And "abcdabc" - "abc"?
>
> Justify your answers.

> "xyz" - "abc";
(1) Result: "xyz"
> "cba" - "abc";
(2) Result: "cba"
> "abcdabc" - "abc";
(3) Result: "d"

Every instance of the subtracted-out string is removed. It's something
like x.remove(y) in many other languages.

>>> "abc"-"b";
>> (2) Result: "ac"
>>> "foo bar asdf qwer"/" "*"##";
>> (3) Result: "foo##bar##asdf##qwer"
>
> And what, pray tell, would "foo bar" / " " be on its own?

A two-element array "foo","bar":

> "foo bar" / " ";
(4) Result: ({ /* 2 elements */
                "foo",
                "bar"
            })

> How about "foo bar" * "*"?

That's an error (the equivalent of TypeError).

> Seems to me that using s/t*u as a way to perform substring replacement is
> too clever by half.

Maybe :) It looks fancy for something like this. Normally, I use
string division with iteration, but there is a more direct "replace"
function for when that's being done.

> Personally, I think string and array concatenation ought to be & rather
> than +. That would free up + for element-wise addition for arrays, while
> still allowing & for concatenation. Of course, the cost would be the loss
> of an element-wise bit-and operator. You win some, you lose some.

I don't know who was first to implement string+string --> concat, but
since it's swept the world, it's worth keeping just on that basis, in
the same way that the use of octal for character escapes like "\123"
is worth keeping:

>>> ord("\123")
83
>>> 0o123
83

Confused me no end when I came across BIND's use of that syntax to
mean decimal. So if & has its problems and + has its problems, go with
+, as it'll confuse less people.

ChrisA

[toc] | [prev] | [next] | [standalone]

#56861

On 2013-10-16 06:09, Chris Angelico wrote:
> > "xyz" - "abc";  
> (1) Result: "xyz"
> > "cba" - "abc";  
> (2) Result: "cba"
> > "abcdabc" - "abc";  
> (3) Result: "d"
> 
> Every instance of the subtracted-out string is removed. It's
> something like x.remove(y) in many other languages.

Or as one might write x.remove(y) in Python:

  for demo in ("xyz", "cba", "abcdabc"):
    print repr(demo), "->", repr(demo.replace("abc", ""))

> >>> "abc"-"b";  
> >> (2) Result: "ac"  
> >>> "foo bar asdf qwer"/" "*"##";  
> >> (3) Result: "foo##bar##asdf##qwer"  
> >
> > And what, pray tell, would "foo bar" / " " be on its own?  
> 
> A two-element array "foo","bar":
> 
> > "foo bar" / " ";  
> (4) Result: ({ /* 2 elements */
>                 "foo",
>                 "bar"
>             })

which in Python sounds suspiciously like dividend.split(divisor)

So Python's giving both functionalities in ways that are more
readable (and in the case of "-", more flexible, as you can replace
with anything, not just delete the matching content).

While subtraction and division of strings make theoretical sense, I'm
glad I don't have to think about them in my Python code ;-)

-tkc

[toc] | [prev] | [next] | [standalone]

#56851

Op 15-10-13 10:57, Chris Angelico schreef:
> On Tue, Oct 15, 2013 at 6:48 PM, Antoon Pardon
> <antoon.pardon@rece.vub.ac.be> wrote:
>> Op 15-10-13 01:11, Chris Angelico schreef:
>>> On Tue, Oct 15, 2013 at 6:18 AM, John Nagle <nagle@animats.com> wrote:
>>
>>>
>>>> Operator "+" as concatenation for built-in arrays but addition
>>>> for NumPy arrays.
>>>
>>> ... NumPy definitely isn't part of the language. It's not even part of
>>> the standard library, it's fully third-party.
>>
>> That doesn't matter. Adding and concating are different operations and
>> their are types in which both occur rather naturally. So as a designer
>> of such a class you have to choose for which operation you use the
>> natural python operator and for which operation you have to do it
>> differently. NumPy is just an example that you can't escape this sort
>> of incompatibilities in python.
> 
> So what should "abc" + "def" result in, if addition is different from
> concatenation?

A type error.

> No, adding strings should concatenate them. And other
> arithmetic operators make sense, too; Python doesn't happen to
> implement str-str or str/str, but some languages do:
> 
>> "abc"+"def"-"abc";
> (1) Result: "def"
>> "abc"-"b";
> (2) Result: "ac"
>> "foo bar asdf qwer"/" "*"##";
> (3) Result: "foo##bar##asdf##qwer"
> 
> PHP has separate addition and concatenation operators, and it doesn't
> help anything (granted, the biggest problem is that every other
> language we work with uses + to concat strings, so it's an easy source
> of bugs); having multiple operators for "add the elements of these
> arrays" and "add these arrays together" is really orthogonal to the
> general issue of adding and concatenating needing different operators.

No it is not, because adding elements to an array is concatenation.
If you want the array adding operator to be the same as the adding
operator for other types and you want the array concatenating operator
be the same as the concatenating operator for other types, you can
only do that if the two operations use different operators.

Since python use the same, you are forced to introduce some kind
of incompatibility.

If you have a library function that assumes '+' for concatenating
sequences and you have a library function that assumes '+' has
group like properties you can't implement your arrays in a way
they can use both.

-- 
Antoon Pardon

[toc] | [prev] | [next] | [standalone]

#56858

Le lundi 14 octobre 2013 21:18:59 UTC+2, John Nagle a écrit :

----

[...]
> 
>     No, Python went through the usual design screwups.  Look at how
> 
> painful the slow transition to Unicode was, from just "str" to
> 
> Unicode strings, ASCII strings, byte strings, byte arrays,
> 
> 16 and 31 bit character builds, and finally automatic switching
> 
> between rune widths. [...]


Yes, a real disaster.

This "poor" Python is spending its time in reencoding
when necessary, without counting the fact it's necessary to
check if reencoding is needed.

Where is Unicode? Away.

jmf

[toc] | [prev] | [next] | [standalone]

#56860

On 15/10/2013 21:11, wxjmfauth@gmail.com wrote:
> Le lundi 14 octobre 2013 21:18:59 UTC+2, John Nagle a écrit :
>
> ----
>
> [...]
>>
>>      No, Python went through the usual design screwups.  Look at how
>>
>> painful the slow transition to Unicode was, from just "str" to
>>
>> Unicode strings, ASCII strings, byte strings, byte arrays,
>>
>> 16 and 31 bit character builds, and finally automatic switching
>>
>> between rune widths. [...]
>
>
> Yes, a real disaster.
>
> This "poor" Python is spending its time in reencoding
> when necessary, without counting the fact it's necessary to
> check if reencoding is needed.
>
> Where is Unicode? Away.
>
> jmf
>

I very much look forward to seeing your correct Python unicode 
implementation on the bug tracker.

-- 
Roses are red,
Violets are blue,
Most poems rhyme,
But this one doesn't.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#57496

Le mardi 15 octobre 2013 23:00:29 UTC+2, Mark Lawrence a écrit :
> On 15/10/2013 21:11, wxjmfauth@gmail.com wrote:
> 
> > Le lundi 14 octobre 2013 21:18:59 UTC+2, John Nagle a écrit :
> 
> >
> 
> > ----
> 
> >
> 
> > [...]
> 
> >>
> 
> >>      No, Python went through the usual design screwups.  Look at how
> 
> >>
> 
> >> painful the slow transition to Unicode was, from just "str" to
> 
> >>
> 
> >> Unicode strings, ASCII strings, byte strings, byte arrays,
> 
> >>
> 
> >> 16 and 31 bit character builds, and finally automatic switching
> 
> >>
> 
> >> between rune widths. [...]
> 
> >
> 
> >
> 
> > Yes, a real disaster.
> 
> >
> 
> > This "poor" Python is spending its time in reencoding
> 
> > when necessary, without counting the fact it's necessary to
> 
> > check if reencoding is needed.
> 
> >
> 
> > Where is Unicode? Away.
> 
> >

Use one of the coding schemes endorsed by Unicode.

If a dev is not able to see a non ascii char may use 10
bytes more than an ascii char or a dev is not able to
see there may be a regression of a factor 1, 2, 3, 5 or
more simply by using non ascii char, I really do not see
now I can help.

Neither I can force people to understand unicode.

I recieved a ton a private emails, even from core
devs, and as one wrote, this has not been seriously
tested. Even today on the misc. lists some people
are suggesting to write to add more tests.

All the tools I'm aware of, are using unicode very
smoothly (even "utf-8 tools"), Python not.

That's the status. This FSR fails. Period.

jmf

[toc] | [prev] | [next] | [standalone]

#57540

On 25/10/2013 07:14, wxjmfauth@gmail.com wrote:

[snip all the double spaced crap - please read, digest and action this 
https://wiki.python.org/moin/GoogleGroupsPython]

>
> Use one of the coding schemes endorsed by Unicode.

As I personally know nothing about unicode for the unenlightened such as 
myself please explain this statement with respect to the fsr.

>
> If a dev is not able to see a non ascii char may use 10
> bytes more than an ascii char

Are you saying that an ascii char takes a byte but a non ascii char 
takes up to 11?  If yes please state where the evidence of this is.  If 
no please state what you are saying.

> or a dev is not able to
> see there may be a regression of a factor 1, 2, 3, 5 or
> more simply by using non ascii char, I really do not see
> now I can help.

Are you saying that the fsr causes a speed regression of this order?  If 
yes please state where the evidence of this is.  If no please state what 
you are saying.

>
> Neither I can force people to understand unicode.

Very true, I certainly don't.

>
> I recieved a ton a private emails, even from core
> devs

Please provide examples of these.  If you have to name names, out of 
courtesy all you neeed do is ensure that they're given copies of 
anything that you say.

> and as one wrote, this has not been seriously
> tested.

Surely any core dev would simply have raised an issue on the bug 
tracker?  Why are they sending you private emails on this subject?

> Even today on the misc. lists some people
> are suggesting to write to add more tests.

What are these misc. lists?  Why suggest, why not write?

>
> All the tools I'm aware of, are using unicode very
> smoothly (even "utf-8 tools"), Python not.

Please provide evidence to support this statement.

>
> That's the status. This FSR fails. Period.

Please provide evidence to support this statement.

>
> jmf
>

-- 
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#57593

On Fri, 25 Oct 2013 19:05:09 +0100, Mark Lawrence wrote:

> On 25/10/2013 07:14, wxjmfauth@gmail.com wrote:
> 
>> Use one of the coding schemes endorsed by Unicode.
> 
> As I personally know nothing about unicode for the unenlightened such as
> myself please explain this statement with respect to the fsr.

Please don't encourage JMF. You know he'll just continue with his 
ridiculous vendetta against Python 3.3's Unicode handling.


>> If a dev is not able to see a non ascii char may use 10 bytes more than
>> an ascii char
> 
> Are you saying that an ascii char takes a byte but a non ascii char
> takes up to 11?  

He's talking about the fact that strings in Python are objects, and hence 
carry a certain amount of overhead. Just to prove it's not specific to 
Python 3.3, or Unicode, here's an empty byte-string in 2.6:

py> sys.getsizeof('')
24

On the other hand, this overhead becomes trivial as the string gets 
bigger:

py> sys.getsizeof('x'*10**6)
1000024


Unicode is no different. Here is the hated 3.3 again:

py> sys.getsizeof('')  # Unicode, not byte-string
25
py> sys.getsizeof('ó'*10**6)
1000037


Again, a totally trivial amount of overhead. If you aren't willing to pay 
that overhead for the convenience of an OOP language like Python, you 
shouldn't be using an OOP language like Python.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#56823

On Saturday, October 12, 2013 3:37:58 PM UTC-7, Chris Angelico wrote:
> On Sat, Oct 12, 2013 at 7:10 AM, Peter Cacioppi
> 
> <peter.cacioppi@gmail.com> wrote:
> 
> > Along with "batteries included" and "we're all adults", I think Python needs a pithy phrase summarizing how well thought out it is. That is to say, the major design decisions were all carefully considered, and as a result things that might appear to be problematic are actually not barriers in practice. My suggestion for this phrase is "Guido was here".
> 
> 
> 
> "Designed".
> 
> 
> 
> You simply can't get a good clean design if you just let it grow by
> 
> itself, one feature at a time. You'll end up with something where you
> 
> can do the same sort of thing in three different ways, and they all
> 
> have slightly different names:
> 
> 
> 
> http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/#general
> 
> 
> 
> (Note, I'm not here to say that PHP is awful and Python is awesome
> 
> (they are, but I'm not here to say it). It's just that I can point to
> 
> a blog post that shows what I'm saying.)
> 
> 
> 
> Design is why, for instance, Python's builtin types all behave the
> 
> same way with regard to in-place mutator methods: they don't return
> 
> self. I personally happen to quite like the "return self" style, as it
> 
> allows code like this:
> 
> 
> 
> GTK2.MenuBar()
> 
>     ->add(GTK2.MenuItem("_File")->set_submenu(GTK2.Menu()
> 
>         ->add(menuitem("_New Tab",addtab)->add_accelerator(...))
> 
>         ->add(menuitem("Close tab",closetab)->add_accelerator(...))
> 
>         ... etc ...
> 
>     ))
> 
>     ->add(GTK2.MenuItem("_Options")->set_submenu(GTK2.Menu()
> 
>         ->add(menuitem("_Font",fontdlg))
> 
>         ... etc ...
> 
>     ))
> 
>     ... etc ...
> 
> 
> 
> It's a single expression (this is from Pike, semantically similar to
> 
> Python) that creates and sets up the whole menu bar. Most of Pike's
> 
> object methods will return this (aka self) if it's believed to be of
> 
> use. The Python equivalent, since the .add() method on GTK objects
> 
> returns None, is a pile of code with temporary names. But that's a
> 
> smallish point of utility against a large point of consistency;
> 
> newbies can trust that a line like:
> 
> 
> 
> lst = lst.sort()
> 
> 
> 
> will trip them up immediately (since lst is now None), rather than
> 
> surprise them later when they try to make a sorted copy of the list:
> 
> 
> 
> sorted_lst = lst.sort()
> 
> 
> 
> which, if list.sort returned self, would leave you with sorted_lst is
> 
> lst, almost certainly not what the programmer intended.
> 
> 
> 
> Oh, and the use of exceptions everywhere is a sign of design, too.
> 
> Something went wrong that means you can't return a plausible value?
> 
> Raise.
> 
> 
> 
> >>> json.loads("{")
> 
> ValueError: Expecting object: line 1 column 0 (char 0)
> 
> 
> 
> >>> pickle.loads(b"\x80")
> 
> EOFError
> 
> 
> 
> Etcetera. PHP borrows from C in having piles and piles of "was there
> 
> an error" functions; there's no consistency in naming, nor (in many
> 
> cases) in the return values. Pike generally raises exceptions, but I/O
> 
> failure usually results in a zero return and the file object's errno
> 
> attribute set; but at least they're consistent error codes.
> 
> 
> 
> This is design. Python has a king (Guido). It wasn't built by a
> 
> committee. Maybe you won't like some aspect of Python's design, but it
> 
> has one, it's not just sloppily slapped together.
> 
> 
> 
> ChrisA

So Python was designed reasonably well, with a minimum of hacky-screw-ups. This happened because Python's growth was effectively managed by an individual who was well suited to the task. In other words, "Guido was here". 

Good thread, I learned a lot from it, thanks.

[toc] | [prev] | [next] | [standalone]

#56825

On 14/10/2013 22:11, Peter Cacioppi wrote:
>
> So Python was designed reasonably well, with a minimum of hacky-screw-ups. This happened because Python's growth was effectively managed by an individual who was well suited to the task. In other words, "Guido was here".
>
> Good thread, I learned a lot from it, thanks.
>

Would you be kind enough to learn something from this please 
https://wiki.python.org/moin/GoogleGroupsPython

-- 
Roses are red,
Violets are blue,
Most poems rhyme,
But this one doesn't.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#56828

On Tue, Oct 15, 2013 at 8:11 AM, Peter Cacioppi
<peter.cacioppi@gmail.com> wrote:
> So Python was designed reasonably well, with a minimum of hacky-screw-ups. This happened because Python's growth was effectively managed by an individual who was well suited to the task. In other words, "Guido was here".
>
> Good thread, I learned a lot from it, thanks.

Pretty much, yeah. We're saying the same thing, only I'm focusing on
the importance of design rather than deifying the person who designed
it. But yes, that comes to much the same result.

ChrisA

[toc] | [prev] | [next] | [standalone]

#56866

> only I'm focusing on the importance of design rather than deifying 
> the person who designed it.

I'm cool with deification here. I'll happily get on my knees and bow towards Holland while chanting "Guido ...  I'm not worthy" 5 times a day, if that's part of the cult.

Want an odd and ranty thread this one turned into. I think Python is awesome. For me, it literally inspires awe. 

If you don't agree, and yet you're working in Python anyway, I kind of feel bad for you, just a little.

Cheers and thanks again.

[toc] | [prev] | [next] | [standalone]

Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8  Next page →

Back to top | Article view | comp.lang.python

csiph-web