«

Hi!
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?
Thanks!
PS: I don't want to start a flame-war, I just want an advice if it's possible please!

On Sun, Sep 30, 2012 at 10:58 PM, tcgo <> wrote:
> Hi!
> 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?
> Thanks!
> PS: I don't want to start a flame-war, I just want an advice if it's possible please!

I'm not going to touch Ruby, partly because I don't know it, and
partly to avoid a flame war, but here's some good reasons to learn
Python:

* It's a modern, object-oriented, high level language.
* As of version 3.3 (do make sure you grab this one, there's lots of
enhancements), it has absolutely correct AND efficient Unicode string
handling. I know of only one other language that can store "Hello" as
a five-byte string, while simultaneously allowing perfect handling of
the entire Unicode range.
* Python's syntax is clean and easy to handle. Be aware, though, that
some things are distinctly different from C-family languages.
* You get an excellent set of modules. Python has "batteries included"
(the standard library is extensive) and a whole set of custom
batteries on speed dial (check out PyPI).
* Easy networking support. You can write servers or clients for many
popular internet protocols with just a few lines of code. Simple TCP
sockets are also easy.
* Python is an open source project with a permissive license.
* Superb community support. You can ask a question here and get a
response in minutes. You're not going to be left hanging when you
have a problem.
* With very VERY few exceptions, your code will run flawlessly on any
of the many platforms Python supports.

Python does have some issues, though; you'll either appreciate the
syntax or absolutely hate it, and there's no efficient and reliable
way to change/reload code in a running application (not often an
issue).

I'm sure others will add to this list, and there's at least one entry
that someone's likely to disagree with me on, but there's a start!

ChrisA

On 09/30/12 07:58, tcgo wrote:
> So, assuming you'll say me "learn python", why should I learn it
> over Ruby?

For me, most of Chris's answers apply to both Python and Ruby.
Well, I can't speak regarding the Ruby community being as awesome,
but it doesn't seem to scare off folks.

*READABILITY* is my main reason for choosing Python, particularly
over Ruby. I can come back to Python code I wrote 5+ years ago, and
it takes me mere minutes to reorient myself to the code. I can't do
that with most other languages, where it often takes me hours or
days to unwind the code.

-tkc

In article <mailman.1672.1349011558.27098.python->,
Chris Angelico <> wrote:

> there's no efficient and reliable way to change/reload code in a
> running application (not often an issue).

What we do (largely cribbed from django's runserver) is start up a
thread which once a second, looks at all the modules in sys.modules,
checks to see if the modification time for their source files has
changed, and if so, restarts the application. This is hugely convenient
when developing any kind of long-running application. You don't need to
keep restarting the application; just edit the source and changes take
effect (almost) immediately.

Not sure if this is what you had in mind.

On Mon, Oct 1, 2012 at 12:23 AM, Roy Smith <> wrote:
> In article <mailman.1672.1349011558.27098.python->,
> Chris Angelico <> wrote:
>
>> there's no efficient and reliable way to change/reload code in a
>> running application (not often an issue).
>
> What we do (largely cribbed from django's runserver) is start up a
> thread which once a second, looks at all the modules in sys.modules,
> checks to see if the modification time for their source files has
> changed, and if so, restarts the application. This is hugely convenient
> when developing any kind of long-running application. You don't need to
> keep restarting the application; just edit the source and changes take
> effect (almost) immediately.
>
> Not sure if this is what you had in mind.

It's not an _explicit_ restart, but you have to write your application
to keep all its state on disk in some way. What I'm talking about is
having a single process that never terminates, never stops accepting
connections, but at some point new connections begin to be served with
new code - with old ones, if they're still going, continuing to be
handled by the old code. I have one such process that's been going for
(let me check) 115 wk 0d 21:05:21.

For many types of application, restarting is perfectly viable, so this
isn't a major issue with Python.

ChrisA

In article <mailman.1675.1349015755.27098.python->,
Chris Angelico <> wrote:

> On Mon, Oct 1, 2012 at 12:23 AM, Roy Smith <> wrote:
> > In article <mailman.1672.1349011558.27098.python->,
> > Chris Angelico <> wrote:
> >
> >> there's no efficient and reliable way to change/reload code in a
> >> running application (not often an issue).
> >
> > What we do (largely cribbed from django's runserver) is start up a
> > thread which once a second, looks at all the modules in sys.modules,
> > checks to see if the modification time for their source files has
> > changed, and if so, restarts the application. This is hugely convenient
> > when developing any kind of long-running application. You don't need to
> > keep restarting the application; just edit the source and changes take
> > effect (almost) immediately.
> >
> > Not sure if this is what you had in mind.
>
> It's not an _explicit_ restart, but you have to write your application
> to keep all its state on disk in some way.

Well, more strictly, what you need is to keep your state somewhere else.
Doesn't have to be on disk. Could be in memory, if that memory belongs
to another process (memcache, redis, or any of a number of in-memory
databases).

> What I'm talking about is
> having a single process that never terminates, never stops accepting
> connections, but at some point new connections begin to be served with
> new code - with old ones, if they're still going, continuing to be
> handled by the old code. I have one such process that's been going for
> (let me check) 115 wk 0d 21:05:21.

Why does it have to be a single process? I could imagine some front-end
process which accepts connections and hands them off to worker
processes. When you install new code, you could do it in a different
directory tree, and then signal the front end that new code exists. The
front end could then {chdir, munge sys.path, whatever} to the root of
the new tree and keep going. Existing connections stay up with the old
code, new connections get the new code.

If you didn't want to fork a new process every time, you could have a
worker process pool. When a worker signaled it was done with a task,
the front end could either assign it a new connection (if the code it
was running was still current), or kill it off if it was running stale
code.

If you truly needed this to be a single process, I could imagine a
customized module importer which altered the module name to include a
version prefix before registering it in sys.modules. I think that could
be made to work, but would be really ugly and complicated. Or elegant
and nifty, depending on your attitude

On Sep 30, 5:58*pm, tcgo <tomeu...@gmail.com> wrote:
> Hi!
> 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?
> Thanks!
> PS: I don't want to start a flame-war, I just want an advice if it's possible please!

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.

Personal note: I like magic -- as long as its not in a tech area, eg
I'm a fan of Harry Potter.

On Mon, Oct 1, 2012 at 1:01 AM, Roy Smith <> wrote:
> Well, more strictly, what you need is to keep your state somewhere else.
> Doesn't have to be on disk. Could be in memory, if that memory belongs
> to another process (memcache, redis, or any of a number of in-memory
> databases).

Sure. I'll generalize my statement to "Has to be external to the
process". That generally precludes the direct use of complex objects,
requiring some form of serialization or dump format - you can't, for
instance, retain a "socket connection object" across that sort of
reload.

> Why does it have to be a single process? I could imagine some front-end
> process which accepts connections and hands them off to worker
> processes. When you install new code, you could do it in a different
> directory tree, and then signal the front end that new code exists. The
> front end could then {chdir, munge sys.path, whatever} to the root of
> the new tree and keep going. Existing connections stay up with the old
> code, new connections get the new code.

That's also a good model, for situations that can use it. My situation
is a MUD-like system where different clients can affect one another,
so the most logical way to do it is a single process. For instance, we
have a Dungeons and Dragons battle grid that uses a web browser as its
display engine; you go to a particular URL, key in your login details,
and it sends AJAX long polls to the server. Whenever one client moves
a token on the grid, every other client gets notified. I could, of
course, do this across processes, but I'd end up needing a hefty IPC
system; this way, all I need is a lightweight event semaphore that the
threads wait on, and they look at the process's internal structures
(thread-safe, they need only read at that point). I could have done it
in other ways, of course, but this is nice and straightforward.

But this is getting rather off-topic For the bulk of usage
patterns, Python's fine. Most languages don't let you reload code on
the fly, and most applications are never going to be bothered by this
miniscule feature lack!

ChrisA

On 30/09/2012 13:58, tcgo wrote:
> Hi!
> 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?
> Thanks!
> PS: I don't want to start a flame-war, I just want an advice if it's possible please!
>

http://www.gossamer-threads.com/list..._view_threaded

--
Cheers.

Mark Lawrence.

In article <mailman.1677.1349019431.27098.python->,
Chris Angelico <> 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.

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