Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Can somebody give me an advice about what to learn?

Reply
Thread Tools

Can somebody give me an advice about what to learn?

 
 
Roy Smith
Guest
Posts: n/a
 
      09-30-2012
In article
<(E-Mail Removed)>,
rusi <(E-Mail Removed)> wrote:

> Here's a test to help you decide: How do you respond to the word
> 'magic'? If positive you will like Ruby, if not you may prefer
> Python.


Some might say that magic underscores a lot of the really fun stuff in
Python. See http://www.rafekettler.com/magicmethods.html
 
Reply With Quote
 
 
 
 
Chris Angelico
Guest
Posts: n/a
 
      09-30-2012
On Mon, Oct 1, 2012 at 8:14 AM, Roy Smith <(E-Mail Removed)> wrote:
> Yeah, that's a problem. There's nothing fundamental about a TCP
> connection endpoint which precludes it being serialized and passed
> around. The amount of state involved is pretty small. Unless I've
> forgotten something, 2 IP addresses, 2 port numbers, a few bits worth of
> TCP protocol state, and, for open connections, 2 sequence numbers.
> Maybe a couple of timers, but I don't think they're strictly necessary.
> The problem is, most of that state is private to the kernel.


And can change at a moment's notice, with no userspace interaction.
The socket connection also needs to retain sent-but-not-acknowledged
and received-but-not-in-order data, so those buffers need to exist.
The only way would be for the kernel to export something representing
a socket - which would be the file handle.

And then you have to worry about any other state, eg if you're reading
line by line and are retaining a partial line... not really something
that can be patched in five seconds, and not IMHO worth trying to do.
Easier to simply retain the process ID.

Oh, and if the pid changes on a live connection, what will that do
with iptables controls, which can look at the originating process's
user id and such? Hrm.

ChrisA
 
Reply With Quote
 
 
 
 
Steven D'Aprano
Guest
Posts: n/a
 
      09-30-2012
On Sun, 30 Sep 2012 18:17:17 -0400, Roy Smith wrote:

> In article
> <(E-Mail Removed)>,
> rusi <(E-Mail Removed)> wrote:
>
>> Here's a test to help you decide: How do you respond to the word
>> 'magic'? If positive you will like Ruby, if not you may prefer Python.

>
> Some might say that magic underscores a lot of the really fun stuff in
> Python. See http://www.rafekettler.com/magicmethods.html


And they would be wrong.

The word they want is "special", not magic. There's nothing[1] magic
about double leading-and-trailing underscore methods. They are just
ordinary methods that are treated specially by Python to implement syntax
such as + (the __add__ and __radd__ methods), len() (the __len__ method)
and similar.

The article you link to starts off with this:

[quote]
What are magic methods? They're everything in object-oriented
Python. They're special methods that you can define to add
"magic" to your classes.
[end quote]

Being able to add two values, or get the number of items in a container,
is hardly magic. They're *special*, because the compiler looks for
methods of those names, but that's all.

[quote]
They're also not as well documented as they need to be. All of
the magic methods for Python appear in the same section in the
Python docs, but they're scattered about and only loosely organized.
[end quote]

You got that? They're all in the same section, AND they are scattered
about at the same time! Now that's truly magic! *wink*

Special is not magic. Magic means that the normal behaviour of the
language is broken for some arbitrary cases. Here's an example in
hardware of "magic":

http://catb.org/jargon/html/magic-story.html

Now imagine that in software: it can't possibly work, and yet it does.

I dare say nearly all non-toy languages have *some* magic. But some
languages have more than others: they are full of unique cases, every one
different, where the same code behaves differently that you would expect.
There *is* some magic in Python:

* Methods and attributes that start with a double underscore, but do not
end with a double underscore, have their name mangled by the compiler.
So your source code says "MyClass.__method", but the method actually
created is "MyClass.__MyClass_method".

This is magic because __names everywhere else do not work that way,
nor do names that don't start with double-underscores.

* In Python 3, if you call super() with no arguments inside a class,
the compiler runs some voodoo to determine the class it belongs to
and the instance it is called from. Outside of a class, super()
with no arguments behaves like any other function.

This is magic because the normal behaviour of a function with two
required arguments is to fail if you don't provide the arguments.
But super() can, somehow, determine the arguments itself, partially
at compile-time and partially at run-time.

* The relationship between built-ins type() and object() is magic.
object is a type. But type is itself an object. You can't define
object until type exists, and you can't define type until object
exists. But the compiler magically bootstraps them into existence.

This is magic because it is impossible[2] for pure Python code to
bootstrap such mutually-defined types into existence.

Off the top of my head, I can't really think of anything else that is
magic in Python.

Note that individual uses of magic are generally done for good reasons,
or at least what seems like a good reason. For example, super's magic
class detection is useful and prevents bugs. But *in general* magic is a
bad thing, because it makes the language incomprehensible and code
surprising. Languages with a lot of magic tend towards code which is hard
to maintain and debug.

Note also that "magic" is different from "deep magic" and "black magic":

http://catb.org/jargon/html/M/magic.html




[1] Perhaps not quite *nothing*, arguably there is a *tiny* bit of magic
in that Python bypasses the instance when looking up __dunder__ methods
as a speed optimization. But that's more like a sprinkle of fairy dust
than real magic.

[2] Or at least tricky and messy.


--
Steven
 
Reply With Quote
 
Hans Mulder
Guest
Posts: n/a
 
      10-03-2012
On 1/10/12 00:14:29, Roy Smith wrote:
> In article <(E-Mail Removed)>,
> Chris Angelico <(E-Mail Removed)> wrote:
>
>> you can't, for instance, retain a "socket connection object" across
>> that sort of reload.

>
> Yeah, that's a problem. There's nothing fundamental about a TCP
> connection endpoint which precludes it being serialized and passed
> around. The amount of state involved is pretty small. Unless I've
> forgotten something, 2 IP addresses, 2 port numbers, a few bits worth of
> TCP protocol state, and, for open connections, 2 sequence numbers.
> Maybe a couple of timers, but I don't think they're strictly necessary.
> The problem is, most of that state is private to the kernel.


You're looking at the wrong abstraction level. A socket connection
object is a thin wrapper around a file descriptor. Most posix platforms
allow you to pass file descriptors to other processes running on the
same box. Thus, most posix platforms *do* allow you to pass socket
connection objects around, though you won't win prizes for portability.

> On the other hand, you could do what "screen" does, and spawn a process
> per connection to hold the connection open


That won't work for the sort of application we're discussing, because
it creates too many processes. A pool of processes, each handling
many connections, might work though.

-- HansM
 
Reply With Quote
 
Chris Rebert
Guest
Posts: n/a
 
      10-04-2012
On Wed, Oct 3, 2012 at 11:31 AM, Wolfgang Keller <(E-Mail Removed)> wrote:
>> I'm really new to Usenet/Newsgroups, but... I'd like to learn some
>> new programming language, because I learnt a bit of Perl though its
>> OOP is ugly. So, after searching a bit, I found Python and Ruby, and
>> both of they are cute. So, assuming you'll say me "learn python", why
>> should I learn it over Ruby?

>
> The point why Ruby was started (perceived deficit of object-orientation)
> has been remedied since Python 2.2.


Not completely. At the least, there's arguably still the issue of
len() and friends (vs. `.length` etc.), and also of `self` being
explicit.

Cheers,
Chris
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      10-04-2012
On Wed, 03 Oct 2012 21:47:33 -0700, Chris Rebert wrote:

> On Wed, Oct 3, 2012 at 11:31 AM, Wolfgang Keller <(E-Mail Removed)>
> wrote:
>>> I'm really new to Usenet/Newsgroups, but... I'd like to learn some new
>>> programming language, because I learnt a bit of Perl though its OOP is
>>> ugly. So, after searching a bit, I found Python and Ruby, and both of
>>> they are cute. So, assuming you'll say me "learn python", why should I
>>> learn it over Ruby?

>>
>> The point why Ruby was started (perceived deficit of
>> object-orientation) has been remedied since Python 2.2.

>
> Not completely. At the least, there's arguably still the issue of len()
> and friends (vs. `.length` etc.), and also of `self` being explicit.


I'm not entirely sure which "perceived deficit of object-orientation" is
being talked about, or why anyone but OOP purists would consider that a
problem.

Python is *more* object-oriented than Java, and I don't hear anyone
complaining that Java isn't object-oriented. Everything[1] in Python is
an object. *Everything*. Ints are objects. Strings are objects. Arrays
are objects. There's no distinction between "boxed" and "unboxed" ints,
like in Java or Haskell -- Python just has ints, and they're always
objects.

As for len() and friends, that's a red-herring. Just because the syntax
is written len(x) instead of x.len() doesn't make Python less object-
oriented. It's just syntax: "a + b" is no less OO than "a.plus(b)".

Somebody might not *like* the syntax "a + b", or "len(x)", but they
should just say so, and not pretend that it isn't OO.

Likewise self. Explicit or implicit, how does that make a language less
or more object-oriented? That's as foolish as saying that Python isn't
object-oriented because you don't have to declare the type of variables:

x = (float)1.234

Again, there are arguments for and against explicit self, but "explicit
self is not OO" is not a valid argument.

Being object-oriented has both costs and benefits. Java compromises on
the idea of OOP for performance: native, non-object ints are faster than
object ints. All these people complaining that Python isn't OO enough
because you have to write "self" in method declarations, why aren't they
complaining that Java isn't OO enough because ints are unboxed primitive
types?



[1] Emphasis on the *thing* part. Control structures aren't things in
that sense, they aren't values at all, they are actions that takes place
during execution.


--
Steven
 
Reply With Quote
 
Wolfgang Keller
Guest
Posts: n/a
 
      10-04-2012
> >> The point why Ruby was started (perceived deficit of
> >> object-orientation) has been remedied since Python 2.2.

> >
> > Not completely. At the least, there's arguably still the issue of
> > len() and friends (vs. `.length` etc.), and also of `self` being
> > explicit.

>
> I'm not entirely sure which "perceived deficit of object-orientation"
> is being talked about, or why anyone but OOP purists would consider
> that a problem.


Yukihiro Matsumoto did. I myself never perceived any lack of
object-orientation with Python, since I've learned programming with
Pascal anyway. >;->

I just wanted to point out that given the state of Python today, no one
would probably consider starting Ruby any more.

Sincerely,

Wolfgang
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Can somebody give me a python code for this? hg Python 5 02-07-2007 08:56 PM
We dont give only job... We give you the Job Satisfaction....... Anuj Digital Photography 0 01-02-2007 06:35 PM
GIVE ME FILM OR GIVE ME DEATH l#vfgsgEg@AO1.com DVD Video 4 07-14-2005 03:10 PM
Give us 3 minutes; we give you the whole library lib Computer Support 1 02-04-2005 03:16 AM
Give us 3 minutes; we give you the whole library lib Computer Support 0 01-27-2005 07:52 AM



Advertisments