I'm not sure what a Freetard is outside the Register website's jokes.
The non-existence of strongly enforced data hiding and the inability to make unreadable and unmodifiable object code is, as you point out, a mixed bag. On the one hand, it makes it difficult to deploy software in the proprietary way which removes a possible choice from the programmer, or at least frustrates the application of that choice.
This makes sense but I find this argument unconvincing because if these two missing features were really needed, someone would have implemented them as a third party extension module which would have then become widely popular.
Furthermore, the lack of these traditional features of proprietary software has no doubt tipped many projects into open-source that would have perhaps not otherwise have thought about the idea. Having more open source Python modules is a benefit to everyone else because there is more open source software to build new software upon.
I can only think of half a dozen prominent proprietary Python programs, and all of these make heavy use of open source software underneath, (as is their right). So both approaches, proprietary and open-source, benefit from their being more open source modules to build upon.
In Economics, this is called a 'positive externality', and so the economic question is whether the benefits of this positive externality outweighs the inconvenience of not having these two features. The fact you are using Python (itself a stack of open source software) implies it does.
Freetard is an epithet for open source enthusiasts (a company I number myself amongst) used most frequently on the Fake Steve Jobs blog.
Actually for CPython you *can* just distribute pyc files - (using py2exe to create standard windows applications). Many commercial projects using CPython do exactly this. (Which is the correct response to people asking this question on the mailing list rather than telling them they shouldn't do it and can't do it.)
'Data hiding' (private members) is not something you can just bolt onto the language. You can achieve it by implementing your code in C as an extension rather than writing it in Python. This is in fact what some people do.
I imagine most people are writing Python code for internal corporate projects or for serverside web applications, so in these cases it does not matter.
As you say, distributing .pyc files alone and/or refactoring sensitive algorithms into C is probably quite enough for most of the minority that need this.
I guess I didn't make it clear. The point of my blog entry was not really that Python should provide ways of achieving these things - but about how the community views the questions.
Hi Michael,
Two points:
1. Is IronPython part of the Python community. You seem to be divorcing it.
2. You seem to be insulting your readership, from the definitions I found here: http://www.urbandictionary.com/d...p?
term=Freetard .
You could change the spin of your article and say that with IronPython (and maybe Jython and PyPy) there are alternatives not found in CPython that fit your way of working.
I've posted a response of sorts:
http://ramblings.timgolden.me.uk...you-do-need-it/
Paddy:
The first definition of freetard is the one intended: "A derogatory term aimed at zealous open-source proponents and their ilk.", the irony being that this definition strongly includes me of course.
As mentioned in the other comments I've made here, this article isn't a criticism of CPython - more of the way questions get answered by the CPython community at times.
I may update the post to make this clearer.
Michael
I'm not entirely sure what benefits you get from obsfucating code through only supplying the bytecode. At least in java land, decompiling with a tool like jad can give amazing results, and get you out of stickly situations with under-documented libraries.
Laurence - tools for decompiling Python bytecode from a modern version of Python are not easily available. 'Decompyle' last worked on Python 2.3 I believe.
The reason that they are not often needed is that it is *far* more common to ship libraries as source. Shipping bytecode only is actually quite rare...
Paddy: I missed one of your questions (although I'm not sure that it is particularly relevant to my entry). I think most IronPython users think of themselves as members of the .NET community *rather* than the Python community (i.e. they come to IronPython from C# rather than from CPython). The most *vocal* members of the IronPython community tend to also be Python users - go figure...
I thought having private implementation details was pretty fundamental to object oriented programming...without a private part of a class there effectively is no implementation detail it is all part of the public interface. Must make it hard to refactor larger Python code sets?
Encapsulation is the fundamental concept - and Python's object model certainly provide that.
In C++ / C# / Java there are all techniques for getting at 'private' data (reflection etc).
Python has a strong convention that members named with a leading underscore are private and not to be used externally. This works fine in 99.9(9?)% of cases. The need for language enforcement of this convention is *much* less than you would assume...
That said, you sometimes come across situations where it would be nice - but proxying or using the bridge pattern can get you as close to that as you probably need to get.
Hi again Michail,
Your writing a book about IronPython, yes?
Most users of IronPython are from the C# and .NET community, yes?
Then I think you might like to take time in your book weaning your .NET savvy readership into the Dynamic language way of doing things. I so often reiterate that the stars don't wink out if their are no type checks on function arguments; and that strong typing doesn't have to be statically checked. You of course have the right background to show that dynamic languages can scale.
I guess for a lot of C# programmers, some hard-learned practices just do not translate.
Good luck with the book, by the way.
- Paddy.
"Freetard is an epithet for open source enthusiasts"
I didn't notice this before, but feel obliged to comment on this now. Andrew Orlowski, who seems to be a prolific user of the term (and a lot more relevant than some guy pretending to be a CEO - is he even doing it any more?) has this to say about his usage of the term:
"But it seems so much more apt for free content militants, who nobly refuse to pay creators for music, TV and film - as a point of principle."
http://www.theregister.co.uk/200.../fotw_paytards/
The flame of the week in the referenced article is worth a read just for the laughs, as is the following terminology-introducing article:
http://www.theregister.co.uk/200...co_mp3_mailbag/
Orlowski, interestingly, seems to be favourable towards the FSF:
http://www.theregister.co.uk/200...9/02/gnu_at_25/
So it's worth knowing what he probably means when he uses the term, at least.
Commenting by HaloScan
