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

Groups > comp.programming > #5054 > unrolled thread

python..

Back to article view | Back to comp.programming

Contents

  python.. fir <profesor.fir@gmail.com> - 2015-01-06 06:20 -0800
    Re: python.. malcolm.mclean5@btinternet.com - 2015-01-06 11:24 -0800
      Re: python.. fir <profesor.fir@gmail.com> - 2015-01-06 16:32 -0800
      Re: python.. BartC <bc@freeuk.com> - 2015-01-09 13:02 +0000
    Re: python.. Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-01-12 18:22 +0100
      Re: python.. Mark Carroll <mtbc@bcs.org> - 2015-01-12 17:49 +0000
        Re: python.. malcolm.mclean5@btinternet.com - 2015-01-13 16:09 -0800
          Re: python.. Robert Wessel <robertwessel2@yahoo.com> - 2015-01-15 02:43 -0600
          Re: python.. Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-01-20 13:02 +0100
            Re: python.. Kaz Kylheku <kaz@kylheku.com> - 2015-01-20 19:25 +0000
              Re: python.. Kaz Kylheku <kaz@kylheku.com> - 2015-01-20 19:26 +0000
              Re: python.. malcolm.mclean5@btinternet.com - 2015-01-21 17:39 -0800
                Re: python.. Kaz Kylheku <kaz@kylheku.com> - 2015-01-22 02:29 +0000
      Re: python.. fir <profesor.fir@gmail.com> - 2015-01-12 10:53 -0800
        Re: python.. Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-01-13 18:29 +0100
          Re: python.. BartC <bc@freeuk.com> - 2015-01-13 18:15 +0000
          Re: python.. fir <profesor.fir@gmail.com> - 2015-01-13 15:16 -0800
            Re: python.. Philip Shaw <jnufcvyvuc@tznvy.pbz> - 2015-01-23 04:46 +0000

#5054 — python..

i recently learned python a bit (though not to much, how dictionary looks how classes loooks etc) and try to build some opinion on this..
some opinions maybe?

[toc] | [next] | [standalone]

#5055

On Tuesday, January 6, 2015 2:21:49 PM UTC, fir wrote:
> i recently learned python a bit (though not to much, how dictionary 
> looks how classes loooks etc) and try to build some opinion on this..
> some opinions maybe?
>
It's a language. Some people are very fond of it. I don't know it
well, but it seems to be a sort of interpreted C with objects,
done in a different way to C++, and without pointers.

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

#5059

W dniu wtorek, 6 stycznia 2015 20:24:51 UTC+1 użytkownik malcolm...@btinternet.com napisał:
> On Tuesday, January 6, 2015 2:21:49 PM UTC, fir wrote:
> > i recently learned python a bit (though not to much, how dictionary 
> > looks how classes loooks etc) and try to build some opinion on this..
> > some opinions maybe?
> >
> It's a language. Some people are very fond of it. I don't know it
> well, but it seems to be a sort of interpreted C with objects,
> done in a different way to C++, and without pointers.

probably i wouldnt call python c, 
I think i know what you mean, some part of python is like interpreted c, so maybe indeed there is some strong place of 'resemblance' but c is (all) about control what is doing
on the machine (well maybe except c-lib routines) and python is not

i was asking on other thing, on some opinions about python, i dont know, some opinions

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

#5064

On 06/01/2015 19:24, malcolm.mclean5@btinternet.com wrote:
> On Tuesday, January 6, 2015 2:21:49 PM UTC, fir wrote:
>> i recently learned python a bit (though not to much, how dictionary
>> looks how classes loooks etc) and try to build some opinion on this..
>> some opinions maybe?

(My option is that you should try and do most coding in a high-level 
language such as Python, and use something like C only when you have to.)

> It's a language. Some people are very fond of it. I don't know it
> well, but it seems to be a sort of interpreted C with objects,
> done in a different way to C++, and without pointers.

Python is ... nothing like C! Not even interpreted C.

You've got dynamic typing, a module system, seamlessly integrated big 
integers, direct handling of strings and lists and dictionaries, 
automatic garbage collection, a completely different block syntax...

If C had all that, what would anyone need Python?

-- 
Bartc

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

#5108

Am 06.01.2015 um 15:20 schrieb fir:
> i recently learned python a bit (though not to much, how dictionary looks how classes loooks etc) and try to build some opinion on this..
> some opinions maybe?

If you have algorithms to implement that need big integers, then Python
is in my personal experience the best language to use, since you can
simply employ the common arithmetic operators. In general, Python lets
you to write a code that is fairly closely (more or less) in a
one-to-one correspondence to pseudo-codes of the style that is normally
seen in some books (if you don't employ classes, which is not
necessary). If you come from other programming languages you should
however take care of some differences in sytax, e.g. the for-loop.
Python is normally interpreted, not compiled, but I believe for most
usages of the common people, speed isn't a critical issue with today's
computers. Since Python makes the work of the programmer simpler in
comparison to some other popular programming languages, the probability
of bugs is correspondingly smaller and that is an essential advantage.

There are two Usenet groups: comp.lang.python and
comp.lang.python.announce that are quite active, the first being
for help in syntax problems etc. and the second (moderated) being
for announcements of new software coded in python.

M. K. Shen

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

#5111

Mok-Kong Shen <mok-kong.shen@t-online.de> writes:
(snip)
> If you have algorithms to implement that need big integers, then Python
> is in my personal experience the best language to use, since you can
> simply employ the common arithmetic operators.
(snip)

While I generally agree with the rest of your article, it's worth noting
that this feature isn't actually all that unusual: for instance, I
mentioned Erlang in this thread, that's just the same:

1> 12312425346256765374684238375938743 * 3248593486436262526624534316562252.
39998064782082472270063499350743119830535735017989634112753098129236

Haskell seems to agree,

Prelude> 12312425346256765374684238375938743 * 3248593486436262526624534316562252
39998064782082472270063499350743119830535735017989634112753098129236

and lets you do list comprehensions just as in Python.

One thing that pains me in Java is I can't even easily define a function
that takes Number x and Number y and returns x + y.

-- Mark

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

#5141

On Monday, January 12, 2015 at 5:49:14 PM UTC, Mark Carroll wrote:
> 
> > If you have algorithms to implement that need big integers, then Python
> > is in my personal experience the best language to use, since you can
> > simply employ the common arithmetic operators.
> (snip)
> 
> While I generally agree with the rest of your article, it's worth noting
> that this feature isn't actually all that unusual: for instance, I
> mentioned Erlang in this thread, that's just the same:
> 
Yes, because as soon as you move away from holding variables in 
registers, and thus having only a handful of types, adding high-level
big scalars is as easy as pie.
But it's great for little toy demo programs, not much use practically.
You hardly ever need big integers and arbitrary-precision floats,
and when you do, it's usually in the guts of encryption algorithms,
GUID generators, hashing functions and the like, which are best
written in low-level C.

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

#5143

On Tue, 13 Jan 2015 16:09:15 -0800 (PST),
malcolm.mclean5@btinternet.com wrote:

>On Monday, January 12, 2015 at 5:49:14 PM UTC, Mark Carroll wrote:
>> 
>> > If you have algorithms to implement that need big integers, then Python
>> > is in my personal experience the best language to use, since you can
>> > simply employ the common arithmetic operators.
>> (snip)
>> 
>> While I generally agree with the rest of your article, it's worth noting
>> that this feature isn't actually all that unusual: for instance, I
>> mentioned Erlang in this thread, that's just the same:
>> 
>Yes, because as soon as you move away from holding variables in 
>registers, and thus having only a handful of types, adding high-level
>big scalars is as easy as pie.
>But it's great for little toy demo programs, not much use practically.
>You hardly ever need big integers and arbitrary-precision floats,
>and when you do, it's usually in the guts of encryption algorithms,
>GUID generators, hashing functions and the like, which are best
>written in low-level C.


Dealing with currency is occasionally practical.

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

#5146

Am 14.01.2015 um 01:09 schrieb malcolm.mclean5@btinternet.com:
> On Monday, January 12, 2015 at 5:49:14 PM UTC, Mark Carroll wrote:
>>
>>> If you have algorithms to implement that need big integers, then Python
>>> is in my personal experience the best language to use, since you can
>>> simply employ the common arithmetic operators.
>> (snip)
>>
>> While I generally agree with the rest of your article, it's worth noting
>> that this feature isn't actually all that unusual: for instance, I
>> mentioned Erlang in this thread, that's just the same:
>>
> Yes, because as soon as you move away from holding variables in
> registers, and thus having only a handful of types, adding high-level
> big scalars is as easy as pie.
> But it's great for little toy demo programs, not much use practically.
> You hardly ever need big integers and arbitrary-precision floats,
> and when you do, it's usually in the guts of encryption algorithms,
> GUID generators, hashing functions and the like, which are best
> written in low-level C.
>
Concerning the last half of your last sentence: The programming effort
would IMHO be very much higher than in case a language like Python
is employed, noting also that in some practical contexts efficiency
isn't a very critical issue.

M. K. Shen

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

#5147

On 2015-01-20, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
> Concerning the last half of your last sentence: The programming effort
> would IMHO be very much higher than in case a language like Python
> is employed, noting also that in some practical contexts efficiency
> isn't a very critical issue.

Even when efficiency is critical, it is rarely (almost never) critical in such
a way that nearly every line of an application has to be rewritten in
something else.

(That does occurs when the efficiency is "infinitely bad": the application has
to run where that language is not available, and for some extraordinary
reasons, it is easier to rewrite the application than to port the language
implementation.)

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

#5148

On 2015-01-20, Kaz Kylheku <kaz@kylheku.com> wrote:
> On 2015-01-20, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
>> Concerning the last half of your last sentence: The programming effort
>> would IMHO be very much higher than in case a language like Python
>> is employed, noting also that in some practical contexts efficiency
>> isn't a very critical issue.
>
> Even when efficiency is critical, it is rarely (almost never) critical in such
> a way that nearly every line of an application has to be rewritten in
> something else.
>
> (That does occurs when the efficiency is "infinitely bad": the application has
> to run where that language is not available, and for some extraordinary
                                                            ^^^^^^^^^^^^^
> reasons, it is easier to rewrite the application than to port the language
> implementation.)

Or even ordinary reasons: such as, the language in question happens to be
closed source, and no freeware clone exists, or at least none good enough to
support the application.

Don't use that! :)

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

#5149

On Tuesday, January 20, 2015 at 7:25:16 PM UTC, Kaz Kylheku wrote:
>
> Even when efficiency is critical, it is rarely (almost never)
> critical in such a way that nearly every line of an application 
> has to be rewritten in something else.
> 
Though that's not true for code size efficiency or memory efficiency.
Very commonly, an application that uses 4095 bytes is fine, one
that uses 4097 completely unusable. Also, commonly, designers 
demand more and more features until usage creeps up to a few
bytes above 4K, then everyone scrabbles around desperately trying
to save a few bytes from somewhere get it back down under the limit. 
(You also get a similar phenomenon with frame hitting in video games).

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

#5150

On 2015-01-22, malcolm.mclean5@btinternet.com <malcolm.mclean5@btinternet.com> wrote:
> On Tuesday, January 20, 2015 at 7:25:16 PM UTC, Kaz Kylheku wrote:
>>
>> Even when efficiency is critical, it is rarely (almost never)
>> critical in such a way that nearly every line of an application 
>> has to be rewritten in something else.
>> 
> Though that's not true for code size efficiency or memory efficiency.

Yes it is, because high level languages like Python have excellent size
efficiency compared to low-level languages. You need a page of C to do the
equivalent of one line of something like Python.

So if what you care about is size efficiency, you'd be crazy to even think
about rewriting anything in C from a high level language.

Python will impose some minimum footprint, however, due to its run-time
support: the cruft you need just to do hello, world.

Whether or not you can beat that footprint (python kernel, libs plus python
program) with a C program depends on what the Python program does.  Also, on
whether you can completely eliminate the python materials from the target
system (what if there are numerous other Python applications? They all
have to be rewritten if the run-time support stuff is to be removed.)

Hosted C also has fairly sizeable minimum footprints. A hello executable
may be small, but the library it is linked to isn't all that small.
Making small images in C means using a freestanding implementation.

Converting a Python program which does something moderately complicated to a
freestanding C implementation in which you have to write your own strcpy if you
want it ... haha, have fun!

> Very commonly, an application that uses 4095 bytes is fine, one
> that uses 4097 completely unusable. Also, commonly, designers 

I would say, not very commonly. Today it is false economy to use
such a microcontroller when for pennies more you can have one that
supports a bigger, better, more future-proof application.

If you have to fit code into 4095 bytes, issues like readability and
maintainability pretty much go the window anyway. All that matters is that some
fraction of a dollar is saved per circuit board by not using the higher model
chip that provides 32767 bytes for the program, and over the projected units
sold, that saving more than exceeds the extra salary paid to someone to figure
out how to cram it all into 4095. (If not, it was false economy.)

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

#5113

W dniu poniedziałek, 12 stycznia 2015 18:22:48 UTC+1 użytkownik Mok-Kong Shen napisał:
> Am 06.01.2015 um 15:20 schrieb fir:
> > i recently learned python a bit (though not to much, how dictionary looks how classes loooks etc) and try to build some opinion on this..
> > some opinions maybe?
> 
> If you have algorithms to implement that need big integers, then Python
> is in my personal experience the best language to use, since you can
> simply employ the common arithmetic operators. In general, Python lets
> you to write a code that is fairly closely (more or less) in a
> one-to-one correspondence to pseudo-codes of the style that is normally
> seen in some books (if you don't employ classes, which is not
> necessary). If you come from other programming languages you should
> however take care of some differences in sytax, e.g. the for-loop.
> Python is normally interpreted, not compiled, but I believe for most
> usages of the common people, speed isn't a critical issue with today's
> computers. 

this is not neccessary about speed, more 
about 'system integration', I just like to have
a program in an exe form, it just seem nicer,
feels like real program


Since Python makes the work of the programmer simpler in
> comparison to some other popular programming languages, the probability
> of bugs is correspondingly smaller and that is an essential advantage.
> 


> There are two Usenet groups: comp.lang.python and
> comp.lang.python.announce that are quite active, the first being
> for help in syntax problems etc. and the second (moderated) being
> for announcements of new software coded in python.
> 
> M. K. Shen

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

#5134

Am 12.01.2015 um 19:53 schrieb fir:

> this is not neccessary about speed, more
> about 'system integration', I just like to have
> a program in an exe form, it just seem nicer,
> feels like real program

I am afraid I have not yet properly understood you. Hypothetically
assume that one doesn't know whether interpretation or complilation
is involved in the background and one simply gets something (one
"black box") with which one can obtain a correct result via clicking
on a button somewhere or writing a one-line command, what would be
the difference in feeling in the two cases?

Anyway I personally dislike to run exe-files from other people for
security reasons.

M. K. Shen

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

#5135

On 13/01/2015 17:29, Mok-Kong Shen wrote:
> Am 12.01.2015 um 19:53 schrieb fir:
>
>> this is not neccessary about speed, more
>> about 'system integration', I just like to have
>> a program in an exe form, it just seem nicer,
>> feels like real program
>
> I am afraid I have not yet properly understood you. Hypothetically
> assume that one doesn't know whether interpretation or complilation
> is involved in the background and one simply gets something (one
> "black box") with which one can obtain a correct result via clicking
> on a button somewhere or writing a one-line command, what would be
> the difference in feeling in the two cases?

An executable can be entirely self-contained.

But a program that is in .py form might require a dozen other .py 
modules, and it could make use of any of the Python libraries.

So even if I send you an application as a single .py file, and you don't 
already have Python, you might need to install it first, and 3.1 for 
example seems to comprise 3000 files in 350 directories. A vast, 
sprawling dependency.

So it's tidier to have a program entirely contained within one package 
and which doesn't need an elaborate install. That would mean being able 
to just copy the one file onto a memory stick for example, and just use 
it on another computer as easily as you can with a TXT file.

-- 
Bartc

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

#5138

W dniu wtorek, 13 stycznia 2015 18:29:37 UTC+1 użytkownik Mok-Kong Shen napisał:
> Am 12.01.2015 um 19:53 schrieb fir:
> 
> > this is not neccessary about speed, more
> > about 'system integration', I just like to have
> > a program in an exe form, it just seem nicer,
> > feels like real program
> 
> I am afraid I have not yet properly understood you. Hypothetically
> assume that one doesn't know whether interpretation or complilation
> is involved in the background and one simply gets something (one
> "black box") with which one can obtain a correct result via clicking
> on a button somewhere or writing a one-line command, what would be
> the difference in feeling in the two cases?
> 
> Anyway I personally dislike to run exe-files from other people for
> security reasons.
> 
I like exe's
If i would get exe form python source
i can compare it to c source exe etc
(compilation it is for spped also but
also for this, indeed i very dislike
the interpreter code dependencies and 
also its vulnerability, that it is editable, readable etc exe is exe

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

#5152

On 2015-01-13, fir <profesor.fir@gmail.com> wrote:
> W dniu wtorek, 13 stycznia 2015 18:29:37 UTC+1 użytkownik Mok-Kong Shen napisał:
>> Am 12.01.2015 um 19:53 schrieb fir:
>> 
>> > this is not neccessary about speed, more about 'system
>> > integration', I just like to have a program in an exe form, it
>> > just seem nicer, feels like real program
>> 
>> I am afraid I have not yet properly understood you. Hypothetically
>> assume that one doesn't know whether interpretation or complilation
>> is involved in the background and one simply gets something (one
>> "black box") with which one can obtain a correct result via
>> clicking on a button somewhere or writing a one-line command, what
>> would be the difference in feeling in the two cases?
>> 
>> Anyway I personally dislike to run exe-files from other people for
>> security reasons.
>> 
> I like exe's.
>
> If i would get exe form python source i can compare it to c source
> exe etc (compilation it is for spped also but also for this, indeed
> i very dislike the interpreter code dependencies and also its
> vulnerability, that it is editable, readable etc exe is exe

I have come across perl programs bundled into single-file native
executables (I've never seen such an exe, only ELF and Mach-0, but
there's no reason why the same trick wouldn't work).

What could be done relatively easily is embed a set of pyc (python
bytecode) files into the same executable file (in data segments) as a
stripped-down interpreter, with the module loader modified to look
inside the file. However, although that gets you a single-file
executable which is awkward for the end-user to read, it gets you
little speed advantage over normal python.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web