Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mongrel2 Says, "Goodbye Python"

sheddingbikes.com

Post reply on HN
Print view View original

231–240 of 251 posts

Re: Mongrel2 Says, "Goodbye Python"

#231

Post by alexkay »

gaius wrote: post #18
dagw wrote: post #11

Earlier quoted context omitted.

Shit can and will break if you mess with your OS. Updating a program I use should never constitute "messing" with my OS, it should constitute "using". Why should I as an OS user have to constantly worry about upsetting the OS maker? Why should I have to jump through obscure hoops just to install some software without breaking my OS? Wouldn't a better solution be for the OS makers to wall off their magic python behind…

In the ancient days, stuff the OS relied on was in /usr/sbin and stuff that was "yours" was in /usr/local/bin (or /opt) and stuff that no-one was quite sure whose it was was in /usr/bin. And lo, peace and harmony did reign upon the face of Unix. And the sysadmin did lie down with the developer, and it was good. Who even knows how it works these days?

It's still like that in all BSDs.

Re: Mongrel2 Says, "Goodbye Python"

#232

Post by wwortiz »

nailer wrote: post #211
wwortiz wrote: post #117

Earlier quoted context omitted.

It depends on what you are using the server for and who is using the server. Ubuntu and debian are used by plenty of people in production and are probably the better choice for learning how to set up a server if you already use ubuntu. Apt is also a great package manager.

Apt and yum are not very different. In the early 2000s, before yum Debian was a clear choice for packaging alone, but things have changed these days. (I'm an Arch guy these days, but hey...)

Every time I set up a server with yum I have to look up how to install development tools, groupinstall just doesn't really click with me.

Pacman and apt are both better imo, and apt-get build-dep is really great when you need to do a source install but can still use normal dependencies.

(I do use aptitude now instead of apt though)

Re: Mongrel2 Says, "Goodbye Python"

#233

Post by SapphireSun »

jacobolus wrote: post #144
avar wrote: post #124

Earlier quoted context omitted.

I should have said: They haven't been fixed by default . Perl is also moving forward, it's just doing so differently than Python. Python has major releases like 2.6 and 3.0 where they explicitly break old code in the default installation. Perl however doesn't break any of the old warts by default, but developers can easily do so by importing modules like Moose and perl5i in their own code. See http://search.cpan.org/…

Which code was explicitly broken by Python 2.6?

iirc nothing was, but it made available some features that would be used in 3.0 and 2.7 is essentially a back-port of stuff the 3.0 people found useful. I believe the idea is that in a major version number, everything is back compatible.

Re: Mongrel2 Says, "Goodbye Python"

#234

Post by aidenn0 »

jedbrown wrote: post #190
fauigerzigerk wrote: post #82

He's absolutely right. I have come to the conclusion that we must do one thing: Stop sharing. Shared libraries and language runtimes are a relic of the past when memory and storage were orders of magnitude smaller. Bundle all dependencies and throw out the package managers!

And reinstall your entire operating system when a core library needs a security patch.

You mean upgrade applications that depend on that core library. Which you have to do anyway since a patched library will not be bug-compatible with the old one.

That's the biggest issue, if you test with library version X and run with library version Y, then any sufficiently complicated program will have bugs that would have been found by testing with the same version of the library you run with.

Re: Mongrel2 Says, "Goodbye Python"

#235

Post by cdavid »

cookiecaper wrote: post #202
cdavid wrote: post #104

Earlier quoted context omitted.

If you build yourself a new python, what's the point of virtualenv ? Compiling python is of course possible, although quite a chore if all you want is to configure some software. Concerning the need to obtain a new python if you want to use a newer python: yes, it is more or less evident, but that's Zed Shaw's point, not mine. Where he has a point IMO is about the brokenness of the installed python - many distributio…

The point is that building a new Python just to generate virtualenvs from is not disruptive to anything else. Zed says they had to move away from Python because the system would get messed up if you replaced the distro-supplied Python. Building a new Python and merely using it from the build directory to generate virtualenvs doesn't disrupt anything in the system. We have done this on several CentOS systems and had n…

But if you rebuild python from scratch, you loose every single software packaged by your distribution. If you depend on modules with C extensions, it quickly becomes intractable. Building python is easy - building a recent pyqt on RHEL 5, not so much.

Also, virtualenv is hard to sell for people who do not know so much about python.

Re: Mongrel2 Says, "Goodbye Python"

#236

Post by zaphar »

lygaret wrote: post #224
points wrote: post #180

Earlier quoted context omitted.

I agree to an extent. That stuff matters when you're starting out and just learning. But after you get to a certain level the 'language ecosystem' isn't important at all IMHO.

Massively disagree: once I get to a certain level, there's no way in hell I want to waste my time implementing all of (java) commons-lang, or my own sqlite bindings, etc. When the languages ecosystem is flourishing, I am productive. When it's not, I'm shaving yaks that prefer not to be shaved.

snarky aside

No one wants to implement all of java commons-lang in their language of choice because they'd be lynched by the languages users. I no of no other language with a standard library as annoyingly verbose and complicated as java.

Re: Mongrel2 Says, "Goodbye Python"

#237

Post by pdonis »

rbanffy wrote: post #217
zedshaw wrote: post #183

Earlier quoted context omitted.

generators

I know that if I really need generators, then I really need to install something newer than the 2.4 that comes with RHEL/CentOS 4. Generators is 2.6+, right? BTW, an ugly approach I used (more or less as a joke) was to check for generator availability and, in case I can't use them, use a list comprehension instead. There is a performance/memory hit but, depending on what you are doing, it's a usable alternative. And…

Um...generators are Python 2.2+ (introduction of the yield statement):

http://docs.python.org/release/2.2/ref/yield.html

Generator expressions are 2.4+:

http://docs.python.org/release/2.4/ref/genexpr.html

That said, I don't disagree with removing the Python dependency from the "core" of Mongrel2. As was noted in an earlier comment, people can always write a config file management tool in any language they want (or Mongrel2 bindings in general, for that matter).

Re: Mongrel2 Says, "Goodbye Python"

#238

Post by phaylon »

jacobolus wrote: post #143
avar wrote: post #91

Earlier quoted context omitted.

My impression is that the difference between Perl-5.6 and Perl-5.12 is much less than between these versions of Python and recent releases. Your impression is correct. Perl is a more mature platform than Python, and backwards compatibility is taken more seriously. The latest Perl 5.12 release can still run most of the test suite for Perl 1 released back in 1987. That and its wide availability and portability make it…

> Perl is a more mature platform than Python, and backwards compatibility is taken more seriously. That's a silly thing to say w/r/t Python 2.x. What makes people’s Python 2.5 code not run on Python 2.2 (or 1.x) is that new features were added in the mean time. New very shiny happy features that make life a lot easier for developers. Almost all python code continues to work from one version to the next, and it’s easy…

So did Perl 5. The difference seems to be that for the newer Perl features you have to either declare the version of Perl you're depending on or import the feature explicitly.

Re: Mongrel2 Says, "Goodbye Python"

#239

Post by jedbrown »

aidenn0 wrote: post #234
jedbrown wrote: post #190

Earlier quoted context omitted.

And reinstall your entire operating system when a core library needs a security patch.

You mean upgrade applications that depend on that core library. Which you have to do anyway since a patched library will not be bug-compatible with the old one. That's the biggest issue, if you test with library version X and run with library version Y, then any sufficiently complicated program will have bugs that would have been found by testing with the same version of the library you run with.

Responsible library maintainers ensure that security fixes and subminor releases are drop-in replacements. No distro rebuilds the world under these circumstances.

Re: Mongrel2 Says, "Goodbye Python"

#240

Post by pygy_ »

zedshaw wrote: post #157
mahmud wrote: post #76

Instead of inventing your own syntax, why didn't you use a portable syntax like XML, JSON, YAML, or better yet, libconfig[1]? Please compare the libconfig test file to the mongrel configuration file: http://www.hyperrealm.com/libconfig/test.cfg.txt http://mongrel2.org/doc/tip/docs/manual/book.wiki#x1-190003.... The mongrel conf is a subset of libconfig; it doesn't use the more advanced features. Plus libconfig has bi…

I thought about something like that, but wanted to duplicate the existing config file format so that people's configs would keep working (mostly). It actually had some cool advantages, like a nice psuedo variable system letting you setup variables for reuse in different parts of the config file. I haven't really seen that in other config formats, and it is damn handy.

YAML has a variable system: http://www.yaml.org/spec/1.2/spec.html#id2786196
Post reply on HN