[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.programming

python..

kenobi

1/6/2015 2:21:00 PM

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?
17 Answers

Malcolm McLean

1/6/2015 7:25:00 PM

0

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.

kenobi

1/7/2015 12:32:00 AM

0

W dniu wtorek, 6 stycznia 2015 20:24:51 UTC+1 uzytkownik malcolm...@btinternet.com napisal:
> 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

Bartc

1/9/2015 1:03:00 PM

0

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

Mok-Kong Shen

1/12/2015 5:23:00 PM

0

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

Mark Carroll

1/12/2015 5:49:00 PM

0

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

kenobi

1/12/2015 6:54:00 PM

0

W dniu poniedzialek, 12 stycznia 2015 18:22:48 UTC+1 uzytkownik Mok-Kong Shen napisal:
> 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

Mok-Kong Shen

1/13/2015 5:30:00 PM

0

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

Bartc

1/13/2015 6:16:00 PM

0

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

kenobi

1/13/2015 11:17:00 PM

0

W dniu wtorek, 13 stycznia 2015 18:29:37 UTC+1 uzytkownik Mok-Kong Shen napisal:
> 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

Malcolm McLean

1/14/2015 12:09:00 AM

0

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.