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

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

Re: Python Worst Practices

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Python Worst Practices Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-02-28 15:33 +0000
    Re: Python Worst Practices BartC <bc@freeuk.com> - 2015-02-28 17:55 +0000
      Re: Python Worst Practices Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-02-28 18:38 +0000
      Re: Python Worst Practices Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-01 13:08 +1100
        Re: Python Worst Practices Chris Angelico <rosuav@gmail.com> - 2015-03-01 13:43 +1100
        Re: Python Worst Practices BartC <bc@freeuk.com> - 2015-03-01 12:47 +0000
        Re: Python Worst Practices Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-03-01 20:37 -0500
        Re: Python Worst Practices MRAB <python@mrabarnett.plus.com> - 2015-03-02 01:59 +0000
        Re: Python Worst Practices Dave Angel <davea@davea.name> - 2015-03-01 23:49 -0500
        Re: Python Worst Practices MRAB <python@mrabarnett.plus.com> - 2015-03-02 12:38 +0000
        Re: Python Worst Practices Dave Angel <davea@davea.name> - 2015-03-02 08:12 -0500
        Re: Python Worst Practices Jonas Wielicki <jonas@wielicki.name> - 2015-03-06 07:58 +0100
        Re: Python Worst Practices Chris Angelico <rosuav@gmail.com> - 2015-03-06 21:09 +1100
          Re: Python Worst Practices Mario Figueiredo <marfig@gmail.com> - 2015-03-07 16:11 +0100

#86622 — Re: Python Worst Practices

On 27/02/2015 21:40, Chris Angelico wrote:
> On Sat, Feb 28, 2015 at 8:37 AM, Dave Angel <davea@davea.name> wrote:
>> Right.  In C and C++, instead of being the first slide, it'd be the first 3
>> or 4.  Between header file conflicts (especially good because the stdlib
>> itself has many multiply-defined symbols, duplicate header files, and
>> contradictory include path patterns)
>
> Yeah, Python has some issues with sys.path and how your local module
> can unexpectedly shadow a stdlib one, but at least the stdlib itself
> doesn't have any conflicts. I should not ever have to do this dance:
>
> #include <somefile.h>
> #undef SOME_SYMBOL
> #include <otherfile.h>
>
> But sadly, I do.
>
> ChrisA
>

As you typed the above up I wonder how many developers around the world 
were battling with the fun and games caused, particularly when writing 
cross platform code?

It also makes me wonder what idiot decided to use C as the language for 
the first Python implementation? Or was it written in something else and 
then ported?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [next] | [standalone]

#86630

On 28/02/2015 15:33, Mark Lawrence wrote:

> It also makes me wonder what idiot decided to use C as the language for
> the first Python implementation? Or was it written in something else and
> then ported?

Python was already slow enough even written in C. With any other 
implementation language, it would have ground to a halt.

-- 
Bartc

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

#86634

On 28/02/2015 17:55, BartC wrote:
> On 28/02/2015 15:33, Mark Lawrence wrote:
>
>> It also makes me wonder what idiot decided to use C as the language for
>> the first Python implementation? Or was it written in something else and
>> then ported?
>
> Python was already slow enough even written in C. With any other
> implementation language, it would have ground to a halt.
>

I'm disappointed with the catch so far, this is only the second for my 
keep net.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#86639

BartC wrote:

> On 28/02/2015 15:33, Mark Lawrence wrote:
> 
>> It also makes me wonder what idiot decided to use C as the language for
>> the first Python implementation? Or was it written in something else and
>> then ported?
> 
> Python was already slow enough even written in C.


Tell that to the IronPython developers. 


Of course, benchmarks are very variable, depending on what you wish to do,
and a few things (like exceptions) are very much slower in IronPython:

http://ironpython.codeplex.com/wikipage?title=IP27A1VsCPy27Perf&referringTitle=IronPython%20Performance

but overall, I think it's fair to say that IronPython is about 1.8 times the
speed of CPython.


> With any other implementation language, it would have ground to a halt.

That's laughably inaccurate.




-- 
Steven

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

#86641

On Sun, Mar 1, 2015 at 1:08 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> but overall, I think it's fair to say that IronPython is about 1.8 times the
> speed of CPython.
>
>
>> With any other implementation language, it would have ground to a halt.
>
> That's laughably inaccurate.

I'm sure that Python could have been implemented in FORTRAN without
losing performance. Conversely, I'm sure Python could also have been
implemented on top of BASIC if someone felt like it, though what the
advantages might be I have no idea. But performance is not (or should
not be) the primary reason for choosing a language. Imagine if all
your Python code ran twice as fast (that's slightly better than the
IronPython figure quoted!), but worked only on BSD Unix and Mac OS. Is
that something that'll make a fledgling language succeed? Or would
universality, even at the cost of performance, lead to a greater
userbase and development team, which ultimately would result in far
greater improvements in both functionality and performance?

ChrisA

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

#86654

On 01/03/2015 02:08, Steven D'Aprano wrote:
> BartC wrote:
>
>> On 28/02/2015 15:33, Mark Lawrence wrote:
>>
>>> It also makes me wonder what idiot decided to use C as the language for
>>> the first Python implementation? Or was it written in something else and
>>> then ported?
>>
>> Python was already slow enough even written in C.
>
>
> Tell that to the IronPython developers.

This was about the first implementation of Python. Wikipedia tells me 
that Python first appeared in 1991, while IronPython dates from 2006, 
and is apparently written in C# which came out in 2000.

 > Of course, benchmarks are very variable, depending on what you wish 
to do,
 > and a few things (like exceptions) are very much slower in IronPython:
 >
 > 
http://ironpython.codeplex.com/wikipage?title=IP27A1VsCPy27Perf&referringTitle=IronPython%20Performance

And Hello World seems to be about 15 times slower. (Actually how can any 
Hello World program take more than a second to run?)

-- 
Bartc

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

#86691

On Sun, 1 Mar 2015 13:43:50 +1100, Chris Angelico <rosuav@gmail.com>
declaimed the following:

>losing performance. Conversely, I'm sure Python could also have been
>implemented on top of BASIC if someone felt like it, though what the
>advantages might be I have no idea. But performance is not (or should

	You'd be able to run it on a TI99/4 (in which the BASIC interpreter,
itself, was run on an interpreter... nothing like taking the first "16-bit"
home computer and shackling it with an interpreted language that was run on
an interpreted language)
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#86693

On 2015-03-02 01:37, Dennis Lee Bieber wrote:
> On Sun, 1 Mar 2015 13:43:50 +1100, Chris Angelico <rosuav@gmail.com>
> declaimed the following:
>
>>losing performance. Conversely, I'm sure Python could also have been
>>implemented on top of BASIC if someone felt like it, though what the
>>advantages might be I have no idea. But performance is not (or should
>
> 	You'd be able to run it on a TI99/4 (in which the BASIC interpreter,
> itself, was run on an interpreter... nothing like taking the first "16-bit"
> home computer and shackling it with an interpreted language that was run on
> an interpreted language)
>
The "16-bit" CPU had a 16-bit address bus (64K address space). If you
were going to switch from an 8-bit processor to a 16-bit processor, one
of the pluses you'd be looking for would the ability to directly
address more than 64K.

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

#86699

On 03/01/2015 08:59 PM, MRAB wrote:
> On 2015-03-02 01:37, Dennis Lee Bieber wrote
>>
>>     You'd be able to run it on a TI99/4 (in which the BASIC interpreter,
>> itself, was run on an interpreter... nothing like taking the first
>> "16-bit"
>> home computer and shackling it with an interpreted language that was
>> run on
>> an interpreted language)
>>
> The "16-bit" CPU had a 16-bit address bus (64K address space). If you
> were going to switch from an 8-bit processor to a 16-bit processor, one
> of the pluses you'd be looking for would the ability to directly
> address more than 64K.
>

The 16 bit address bus permitted addressing of 64k words.  On most 
processors, that was 64k bytes, though I know one Harris had no bytes, 
but every memory access was 16 bits.  It therefore had the equivalent of 
128k bytes.  Likewise I believe some of the DEC and DG minis had 128k 
bytes of addressability.

Usually, the term 8bit processor was referring to the size of the 
register(s), not the address bus.  All the 8 bit micro-processors had 16 
bit address buses.  In fact, 4 bit processors generally had 12 to 16 bit 
address buses as well.  So a 4 bit processor with a 16 bit address bus 
could address 32k bytes, a half byte (a nybble) at a time).

The IBM PC's 8088 had an 8 bit data-bus and 20 address lines.  But they 
called it a 16bit processor, to try to distinguish it from 8 bit 
processors like the 8080.  Anyway, it was code compatible with the 8086, 
which really did have a 16bit data bus and 20 bit address bus.

-- 
DaveA

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

#86730

On 2015-03-02 04:49, Dave Angel wrote:
> On 03/01/2015 08:59 PM, MRAB wrote:
>> On 2015-03-02 01:37, Dennis Lee Bieber wrote
>>>
>>>     You'd be able to run it on a TI99/4 (in which the BASIC interpreter,
>>> itself, was run on an interpreter... nothing like taking the first
>>> "16-bit"
>>> home computer and shackling it with an interpreted language that was
>>> run on
>>> an interpreted language)
>>>
>> The "16-bit" CPU had a 16-bit address bus (64K address space). If you
>> were going to switch from an 8-bit processor to a 16-bit processor, one
>> of the pluses you'd be looking for would the ability to directly
>> address more than 64K.
>>
>
> The 16 bit address bus permitted addressing of 64k words.  On most
> processors, that was 64k bytes, though I know one Harris had no bytes,
> but every memory access was 16 bits.  It therefore had the equivalent of
> 128k bytes.  Likewise I believe some of the DEC and DG minis had 128k
> bytes of addressability.
>
I have (or had, not sure where it is!) a manual of the TMS9900
processor, and I'm sure it addresses 64k _bytes_.

Wikipedia says "65,536 bytes or 32,768 words".

> Usually, the term 8bit processor was referring to the size of the
> register(s), not the address bus.  All the 8 bit micro-processors had 16
> bit address buses.  In fact, 4 bit processors generally had 12 to 16 bit
> address buses as well.  So a 4 bit processor with a 16 bit address bus
> could address 32k bytes, a half byte (a nybble) at a time).
>
> The IBM PC's 8088 had an 8 bit data-bus and 20 address lines.  But they
> called it a 16bit processor, to try to distinguish it from 8 bit
> processors like the 8080.  Anyway, it was code compatible with the 8086,
> which really did have a 16bit data bus and 20 bit address bus.
>

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

#86733

On 03/02/2015 07:38 AM, MRAB wrote:
> On 2015-03-02 04:49, Dave Angel wrote:
>> On 03/01/2015 08:59 PM, MRAB wrote:
>>> On 2015-03-02 01:37, Dennis Lee Bieber wrote
>>>>

>>
>> The 16 bit address bus permitted addressing of 64k words.  On most
>> processors, that was 64k bytes, though I know one Harris had no bytes,
>> but every memory access was 16 bits.  It therefore had the equivalent of
>> 128k bytes.  Likewise I believe some of the DEC and DG minis had 128k
>> bytes of addressability.
>>
> I have (or had, not sure where it is!) a manual of the TMS9900
> processor, and I'm sure it addresses 64k _bytes_.
>
> Wikipedia says "65,536 bytes or 32,768 words".
>

Like I said, on most processors, it was 64k bytes.

interestingly enough I know of one architecture which used 128k for the 
8-bit Z80, even though that processor only had 16 address lines.  Being 
a server, the code was mostly static, and fit in 64k.  But they also 
wanted 64k for data.  So they used one of the processor status lines as 
a select between two banks of memory. When the processor was fetching an 
instruction, it got it from bank 0, while if it was fetching or writing 
data, it went to bank 1.  Obviously they had a mode where it read and 
wrote from bank 0 as data, both for bootstrapping, and for overlays or 
whatever.


-- 
DaveA

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

#86991

On 01.03.2015 03:43, Chris Angelico wrote:
> Imagine if all
> your Python code ran twice as fast (that's slightly better than the
> IronPython figure quoted!), but worked only on BSD Unix and Mac OS. Is
> that something that'll make a fledgling language succeed? 

I heard that Swift and Objective-C are quite popular these days.

regards,
jwi

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

#87010

On Fri, Mar 6, 2015 at 5:58 PM, Jonas Wielicki <jonas@wielicki.name> wrote:
> On 01.03.2015 03:43, Chris Angelico wrote:
>> Imagine if all
>> your Python code ran twice as fast (that's slightly better than the
>> IronPython figure quoted!), but worked only on BSD Unix and Mac OS. Is
>> that something that'll make a fledgling language succeed?
>
> I heard that Swift and Objective-C are quite popular these days.
>
> regards,
> jwi

In other words, it requires major pushing from the platform vendor.
It'd be impossible for some third-party to make a language that
successful, I expect. And even *with* that kind of pushing, it's
pretty chancy; there was a time (maybe times, I don't remember) when
Microsoft tried hard to require "managed code" everywhere (aka ".NET
runtime only"), and the push-back was so strong that they had to
abandon the requirement. But somehow, people accept rules about phone
apps that they wouldn't accept about desktop apps... crazy stuff.

ChrisA

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

#87089

On Fri, 6 Mar 2015 21:09:24 +1100, Chris Angelico <rosuav@gmail.com>
wrote:
>
>there was a time (maybe times, I don't remember) when
>Microsoft tried hard to require "managed code" everywhere (aka ".NET
>runtime only"), and the push-back was so strong that they had to
>abandon the requirement. But somehow, people accept rules about phone
>apps that they wouldn't accept about desktop apps... crazy stuff.
>

I think the Apple mobile ecosystem was just a special case. Due to the
popularity and lack of competition it enjoyed in the yearly years
(really a byproduct of the fact they basically created the computing
platform) it became possible for Apple to impose those absurd rules to
quite a degree of success. No doubt with the help of the genius
invention of curated app stores.

But history is bound to repeat itself. Just like with the desktop
market when Apple enjoyed sudden growth in the 80s and the early 90s,
it was its all-around closed architecture that enventually removed it
from mainstream computing. And we are already witnessing the same
happening to its mobile sector.

Perhaps just not with the dramatic results of its desktop counterpart,
due to the fact Apple introduced mobile computing to an already
established and massified computing marketplace and was so able to
create a larger share. But an all-around closed architecture is still
one of the things that is putting Apple behind.

I think that open systems eventually dominate over closed ones as soon
as they become available. The mobile market, still in its infancy,
allows for some walled gardens. But they will just wither and die.

[toc] | [prev] | [standalone]

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

csiph-web