Slashdot Mirror

Python 3.6 adds type annotations. See https://www.python.org/dev/pep...

Install most linux distros and run 'python'. Odds are overwhelming that it will be python 2.

But at least on UNIX and Linux, you don't have the problem where the part of the filename after the last period determines which interpreter is used. Instead, you have the executable bit, which causes the OS to read the first line of the file to find the interpreter:

#!/usr/bin/env python3

This means use the env program and have it search the PATH for an interpreter called python3.

One reason Python 3.0 through 3.2 didn't gain popularity so fast is that on Windows, .py was still associated to Python 2. It took until 3.3 for the Python team to add the PEP 397 launcher, which looks at the first line to determine which interpreter to use UNIX-style. This way side-by-side installations of Python 2 and 3 work as expected.

Makes even less sense to use spaces in Python or whitespace sensitive languages. Lots of frustration here from merging code bases from multiple people who decided to use a different # spaces to define a tab.

PEP 8 recommends spaces over tabs. Most IDEs will default to four spaces.

https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces

The whitespace issue alone would make it a nightmare as a browser language.

When somebody makes this "argument", it's a sure sign that they've never actually used Python, and that they're just spewing bullshit.

Anyone who has used Python knows that this is totally a non issue. PEP 8 explains very clearly how to avoid and any all problems: "Use 4 spaces per indentation level."

That's all you have to do! Like it says, use 4 spaces per indentation level. It's as simple as that.

The poor record of backwards compatibility doesn't help, either.

When somebody makes this "argument", it's also a sure sign that they've never actually used Python, and that they're just spewing bullshit.

Python has remarkably good backwards compatibility. A number of Python 3 features were actually backported to Python 2. And Python 2 still sees excellent continued support. Python 2.7.11 was released only about 7 months ago, just two days before the latest Python 3 release, 3.5.1!

Anyone who wants to keep using Python 2 can continue to do so. Those who want to use Python 3 are able to do so, too. And there's the excellent "2to3" tool which can quickly and reliably convert nearly all Python 2 code to Python 3 code. Hell, there are many Python libraries that support both Python 2 and 3 with ease!

I'm sorry, son, but you clearly don't know what the fuck you're talking about.

The number of CVEs assigned to Wordpress + plugins vs Plone + addons is a very misleading metric for making this type of claim.

https://wordpress.org/plugins/ shows 45,129 Wordpress plugins.

https://pypi.python.org/pypi?:... shows 3242 Plone addons.

If you assume rough parity in terms of line of code between a Plone addon and a Wordpress plugin (a dangerous assumption), 10x more Wordpress related CVEs would indicate that Wordpress has a lower density of CVEs per LOC than Plone does.

But, of course, even that comparison is a misleading one to make. There are too many other factors that skew these numbers to draw any meaningful conclusions from them. CVEs simply weren't intended to be used for this kind of comparison.

Like PEP 8 clearly says,

Use 4 spaces per indentation level.

That's it. That's all there is to it. It's simpler and clearer than the rules for just about every other programming language out there.

Anyone who can't handle using 4 spaces is a lost cause.

What corporations control Python?

I can think of two possibilities: Python Software Foundation Inc. and Dropbox, which employs Python BDFL Guido van Rossum.

Nobody uses Python? Really?

I think you were blinded before even trying Python and therefore did not "get how it works."

If you have issues reading/comprehending the shorter code then you should probably find a different line of work.

I don't work as a programmer (but I do have an A.S. degree in programming). I typically program in Python. To quote the Zen of Python: "Readability counts."

https://www.python.org/dev/peps/pep-0020/

I guess? Every language with a package manager (like Python's pip) is "vulnerable" to someone pulling the rug on a project.

http://legacy.python.org/downl...

You do realize that SPI master is very easy to implement, after all you never have to react to a clock. Take a quick look for people trying to bit bang a SPI slave under linux not so much success. Yes their are bitbanged drivers find one that has to follow a clock and do that for a non trivial protocol at an appreciable speed. Now sow me something that does this in userspace. The marginal cost to do it "right" for a hobby project is trivial, hell the ESP8266s are cheaper than you can add a network connection to a $5 rpi. You're assuming they are going to write kernel code, compile it for a rpi etc etc etc thats a lot more involved that your typical maker with a rpi is capable of. A more reasonable case for a rpi is userspace code python or whatever.

Since you seem to like links here goes https://pypi.python.org/pypi/R... yup they say flat out entirely unsuitable for anything thats timing critical, use an arduino.

Sure you can use just about anything to do gpio work that does not make it optimal. So an rpi is not realy a reasonable replacement for an arduino, in fact the work together rather well.

Native apps from "garage" developers: zero users on Wii U. Web apps from "garage" developers: greater than zero users on Wii U.

You're not genuinely trying to argue that the Wii U is a significant application platform, are you? It's a games platform for children, and the least successful console of the current generation by a mile. You'd be crazy to target it for applications, native or otherwise.

Even HTML5 game support is weak on the Wii. No support for sound? Does it even have WebGL support? Nope, guess not. And look at this weird non-standard stuff. Effortless support it ain't.

You haven't provided evidence for your claim that web development with all its current limitations, with all the vagaries of differences between browsers is more efficient or productive than native cross platform application development. Some me some real, measurable outcomes instead of making vague assertions.

First, there's the overhead of obtaining hardware on which to test the build for each platform. You essentially have to buy a Mac, buy a copy of Parallels, and buy a retail copy of Windows.

Welcome to professional development. And as you said yourself it's the same deal for web development. What, you got your Wii U for free in a box of cereal or something?

That's fine once your company is big enough to afford "the right development environment".

Many cross platform languages, libraries, and development environments are free. You can use GCC or Rust or Python or Free Pascal and their associated libraries, or use none of them and use something else. You want to do GUI applications? Look, here's an option. Here's another. Use what you want, I don't care.

There are more options available now than ever. Small companies can easily find the right development environment for them for native application development for as much or as little money as they want to spend.

After observing above that Perl and Python have converse philosophies on the point of "There's more than one way to do it," I realized that a Zen of Perl could be formulated by creating the Zen of Python's evil twin:

Ugly is better than beautiful.
Implicit is better than explicit.
Complex is better than simple.
Complicated is better than complex.
Nested is better than flat.
Dense is better than sparse.
Obscurity counts.
Special cases aren't ordinary enough to follow the rules.
Although obtuseness beats clarity.
Errors should sometimes pass silently.
Unless you tell them to die.
In the face of ambiguity, refuse the temptation to delineate.
There's more than one way to do it.
Although those ways may not be obvious at first unless you've consulted the manual.
Fifteen years is better than three.
Although never is often better than *fifteen* years.
If the implementation is hard to explain, it's a good idea.
If the implementation is easy to explain, it may be a bad idea.
Namespaces are one honking good idea -- let's use as many as possible!

Presumably, this applies to Perl 6 as much - if not more - than to Perl 5. Otherwise, exactly what sort of "improvement" is Perl 6?

(with apologies to Tim Peters for applying a little Artistic License to his fine work.)

I too hate formatting my stuff the way my coworkers / teachers / project maintainers / colleagues expect to find it.

Are you suggesting that There should be one-- and preferably only one --obvious way to do it? Geeze, I'm not sure my coworkers / teachers / project maintainers / colleagues can accept that...

How does 'The Go Programming Language' compare to 'The C Programming Language'?

Well, it's about twice as verbose, but it has a vowel, so that might be considered a plus.

Try running Python 3 in a Python 2 environment

Why... would you do that? Python 3 is not a new version of Python 2. Python 3 is "other." I think you're just confused by the (admittedly very poor) naming convention they have adopted. It probably should have been called Serpent or something along those lines, because it really isn't an attempt to "be" Python 2 at all. Furthermore, if your code is tested and running, why would you convert it to Python 3 and then have to re-test? Seems to me the number of good business reasons to do such a thing would be a very small number (of course, you might want to do it for fun or educational value, but that's not really germane.) Python 3 is for new code, if you want to go that way (and you certainly don't have to.) Python 2 is solidly emplaced and not going away. It's a different thing. It's not a "you need to upgrade" thing or a "you have to move your code" thing or a "now Python is this other thing" thing. Python 2 is Python 2, Python 3 is other. That's all you need to know.

Perl is backwards compatible with itself

No, it isn't. For instance, later versions of Perl will choke -- the code will fail and/or act differently -- on various early usage patterns, such as hash references.

Perl has CPAN, the likes of which don't exist in Python.

https://docs.python.org/dev/distributing/index.html

CPAN itself is a bunch of usable Perl. There's a huge amount of usable Python out there as well. It's disingenuous to suggest that CPAN, which is merely a repository, represents a meaningful difference.

Better even than Python for text work and regex.

Meh. I haven't run into any text processing problems that I couldn't solve with Python that made me think, "gee, wish I had X Perl feature." And I wrote in Perl for quite a few years, I know the territory fairly well. Python's got some pretty solid regex handling as well. Python 2. No idea what Python 3 has, could care less. Different language and all that. :)

It's my opinion that for what Perl excels at, one can get off the ground quicker and easier in Perl than in Python

Oh good grief no. Perl is hard to read by nature. Python is easy to read by design. Now, if you had said "for the experienced Perl programmer who knows little or nothing about Python", then sure. But otherwise, just no. Perl is horribly obscure in terms of "getting off the ground." Moving to Python from Perl was like having a huge splinter pulled out my butt for that very reason. I can actually read other people's code and understand it without having to keep in mind a whole raft of special characters and the like. Instead, what is happening is almost always spelled out fairly explicitly in what nearly amounts to plain English, requiring much, much less of my brain to be dealing with the language, and leaving much, much more of it free to be dealing with the program logic.

I've been in IT far longer...

Not the OP, but I've been in IT since ~1972. You may have been at it longer, but I've been at it long enough to come to the conclusion that the objective of a programming language is to solve a problem, and specifically to do it in such a way that the solution is maintainable, effective, and doesn't naturally hide bugs because of ingrained opacity. Something may come along that is better at these things than Python, but I've not run into it yet, which could certainly be a result of me not looking at things that are already out there -- but it isn't a result of not looking at Perl. I've written an enormous amount of Perl, and if there is one thing I will say about it consistently with benefit of hindsight, it is that I wish I'd been able to write it all in Python. Because Python is much, much easier to write, clearer to read later, easier to debug, easier to fix, and yes, actually more fun.

It is highly unlikely that Apple is going to rewrite all that GPL and BSD code at the heart of iOS with Swift. As long as those core projects are based on 'C', they'll stay in 'C'.

Precisely, that's what wrapper code has been for since I started coding back in the early 90s. It always cracks me up when people let fly gold nuggets like "...the Python implementation of OpenCV...". As far as I am aware, nobody rewrote all of OpenCV in Python, they created Python bindings which is a fancy way of saying they created a Python wrapper for OpenCV. Programmers don't always realise that the API's they are using are actually wrappers. I used to use a C++ Linear Algebra library but because I just installed it with yum or apt-get I didn't pay it much thought. it wasn't until I tried to compile it for an embedded computer that I realised the thing was actually a wrapper for a Fortran 77 library that was ported to Fortran 90 and then given a C++ wrapper and that made it a bit of a bitch to compile (largely due to the fact that I didn't know squat about Fortran). Apple will provide Swift wrappers for at least some of the C/C++ libraries and the ObjC stuff if that's necessary (never used Swift myself so I don't know how well ObjC libraries integrate into Swift). Any other approach would have Apple's developers busy doing nothing but rewriting and debugging ported code for the next decade at least. What interests me is how far up shit creek will a developer be if he/she realises that they need a C/C++/ObjC library for his Swift application?

For example in Python the claim is that there's almost always only one way to do something, which either means ugly hacks are not possible, or else there's a lack of imagination amongst the programmers.

You're not being fair to Python.

Python's specific mantra (as listed in PEP 20) is: There should be one -- and preferably only one-- obvious way to do it. Emphasis mine.

Python, like any codebase, has a whole spectrum of "clean code" to "ugly hacks", but the richness of the language (and various libraries), provide a much richer foundation to let you avoid those ugly hacks.

(Unlike Perl, where the richness of the language somehow seems to encourage ugly hacks ^_-)

This is a complete and total lie. There may be one "good" way to do something (for values of good), but there are many ways of doing soemthing.

It's not a "complete and total lie." The Zen of Python, "Python Enhancement Proposal #20", states:

There should be one-- and preferably only one --obvious way to do it.

It's one of the guiding principles of the language's design. Type "import this" into a Python command-line, and PEP20 gets printed out.

I haven't actually used it, but Java 8 adds an API that is very similar to IEnumerable called Streams. It doesn't have the syntax, but I don't actually use the LINQ syntax anyway.

As the sibling points out, Python has list comprehensions and map/filter/reduce along with the itertools package for less common operations.

These are ports of functional language concepts over to imperative languages, so any functional language like Haskell or Ocaml will have similar functionality, but that's probably not what you meant. Although Ocaml is quite usable as an imperative language with a heavily functional bent.

When first announced here Rust looked very interesting, with some bold ideas for making programs better in the lower-level problem domain. Since then it's been under tons of development and community vigour, version 1 looked very different to 0.0.1, I need to reinvestigate!

I used it for a bit a while ago (0.9). It's a pretty nice alternative to C, but needing to explicitly deal with object lifetimes made it a bit too painful to be used as a high level language, which is a little ironic given the significant influence of Haskell in its design. There are ref counted pointers, but last I checked the syntax for them was pretty clunky. (An earlier version used a dedicated operator for them, but that got obsoleted. It's a shame, since that would have made it more usable as a high level language, similar to D.)

The final switch seems like it would be a useful construct. Python doesn't really have good Enums unfortunately, just some approximations such as using namedtuple._make(). Whereas in CoffeeScript you can assign the result of an if-else block to a variable, which allows for silly conditionals always a potential :)

Python has enums as of 3.4, though namedtuple._make() seems to resemble Haskell records more than a C-style enum.

If you can afford it, Jira and WIki from Atlassian (Confluence) are the best out there. If not, i would go with Redmine or Trello. You should also give asana a try. Here's a list that will guide you through what's out there: Freedcamp - Free - https://freedcamp.com/ - Online, doesn't log time directly on the task Velocity - Free and Paid - http://velocity.pm/ (Online) Time Tracking Brigthpod - Free (2 Projects) Paid - http://www.brightpod.com/ - Specify tasks, log work Asana - Free and Paid - https://asana.com/ (Online) - Doesn't log work Moovia - Free (2 members) and Paid - https://site.moovia.com/ (Online) Time tracking, Does not specify tasks Producteev - Free and Paid - https://www.producteev.com/ - Online, Does not specify tasks, doesn't log work Stepsie - Free - http://www.stepsie.com/ - Online, Does not specify tasks, doesn't log work Trello - Free - https://trello.com/ **** SELF HOST Redmine - Free - http://www.redmine.org/ Projects, wiki, issues Chili Project - Fork of Redmine Basecamp - close source - user friendly Open atrium (drupal) - not good issue tracking Collabtive - http://collabtive.o-dyn.de/ Kforge - https://pypi.python.org/pypi/k... ClockingIT - http://wiki.clockingit.com/ Assembla (SaaS Agile) Harvest (SaaS User Friendly) FreshBooks (SaaS) - Not open source - Time tracking invoicing Project Pier - Free - http://www.projectpier.org/ Trac - Free - http://trac.edgewall.org/ 2 plan - Free - http://2-plan.com/ MyCollab - Free - http://community.mycollab.com/... (Self hosted) Manage Yor Team - http://www.manageyourteam.net/ (Self hostes) Kanboard - Free - http://kanboard.net/ (light and self hosted) ProjecQtor - Free - http://www.projeqtor.org/ Task Coach - Free - http://taskcoach.org/ Task Juggler - Free - http://www.taskjuggler.org/ DotProject - Free - http://www.dotproject.net/ Project.net - Free - http://sourceforge.net/project... GanttProject (like MS Project) - Free - http://www.ganttproject.biz/ OpenWorkBench - Free - http://sourceforge.net/project... Codendi - Paid - http://www.codendi.com/ Egroupware 2014 - Paid - http://www.egroupware.org/star... - Atlassian Confluence and Jira - Trial and Paid Britix24 - Trial and Paid - http://www.bitrix24.com/ ProofHub - Trial and Paid - https://www.proofhub.com/ iCoordinator - Paid - http://www.icoordinator.com/en... FengOffice (like MS Project) - Trial and Paid - http://www.fengoffice.com/web/ Bugzilla - Bug tracking Mantis - Bug tracking *** Task Management Task Freak! - http://www.taskfreak.com/

Parsing arbitrary user-written code is more involved than generating code. When you generate code, you deal only with a subset of the language that your generator emits. When you parse code, you have to deal with essentially the entire language.

Sure, but parsing only has to be implemented once, and then everyone can use it.

And, coincidentally, Python contains its own parser in the standard library.

By the way, what is python's way of handling grouped statements like these

Generator expressions or itertools:
for y,x in ((y,x) for y in range(height) for x in range(width)):
        # your code here

from itertools import product
for y,x in product(range(height), range(width)):
        # your code here

Types certainly matter, and Python has types. Yes, feeding the wrong type into a function probably won't work. It'll raise an exception and you'll see a traceback that helps you to fix your code.

If you want to check the types that are supplied to a function, you can do it with assertions. You can even go further and check the things going in have the properties you want. Type checks are a crude form of precondition. A function that expects a tuple will probably work with a list. A function that works with an iterable can accept a whole load of types without all the constipation of an explicitly coded interface to declare for all of them.

If you want the type errors picked up before you execute the code, you might be in luck. You could use the assertions, although I don't know of any tools that do this. There's also a convention for type specifications in docstrings. And official support for function annotations:

https://www.python.org/dev/pep...

None of which addresses static typing as such, which says that after assigning an integer to a variable, you shouldn't be able to reassign it as a float.

There are, still, real advantages to static typing and languages that give you those benefits with type inference, so you don't have to put type declarations all over the place. There are also languages with better generics than void * in C or Object in Java. (C++ and Java are even two of them). Mixing the good features of Python with a good static typing system would certainly be a good thing.

Oh, and I've been programming for a good deal longer than 20 years. I can appreciate different languages for working in different ways.

I've used "indent" many times in the past, and although it's better than nothing, it isn't really a solution for this problem. You have to go fix numerous other small style issues. For example, my employer has a very detailed - though quite eclectic - style. So, indentation and other issues that "indent" can deal with are only a small part of the problem. Also, K&R is my preferredstyle (I personally think Whitesmiths is dopey, but YMMV.) I'll concede my artistic integrity for pay at work, but not for free at home.

Regardless, my primary point (and Guido's, in Python) is that braces lead to a variety of defensible styles. We all have our preferences, but there's really no way to determine which is "best".

Also, for the record, I should mention that Python allows indentation to be any consistent level, with hard tabs counting as 8 spaces. Though it's seemingly contary to the aforementioned principle, that one can be filed under "practicality beats purity."

Tim Peters once said explained such contradictions with something like "the key to any successful philosophy is to allow yourself enough wiggle room to do what you really wanted to do in the first place." [wink]

Python's block structure isn't about saving characters or about saving typing. It's about "There should be one-- and preferably only one --obvious way to do it."

In C, for example, there are multiple ways to place braces. In fact, there's even a lengthy Wikipedia page on that very subject.

In my own case, I have always used the K&R style, but my employer requires the Whitesmiths style. I have a large base of code at home that I wrote and maintain in the K&R style, and it's hard to switch back and forth between the two on a daily basis [sigh].

Python's indentation is utterly Pythonic because it is compact, yet meaningful. It carries blocks to their logical conclusion. I started in Pascal with begin/end, then learned that braces were better in C, then learned that no braces were best in Python. QED.

As I see it, given the universe is probably a simulation (Edward Fredkin talks about this, among others), the issue is not where energy comes from, where the computational matrix came from. This assumes that is indeed a valid question, since philosophically the nature of consciousness may just assume computation or somehow be one with it.

To understand my point, consider if you were to make a simulation of the Milky Way Galaxy colliding with Andromeda, like in this cool video:
"GTC2012 Kepler GPU Demo: When Galaxies Collide "
https://www.youtube.com/watch?...
"In this video, Nvidia's Jen-Hsun Huang and Stephen Jones demonstrate the power of the new Kepler GPU. This astronomy simulation shows that the Milky Way galaxy will collide with the Andromeda galaxy in 4-5 Billion years from now."

When writing the code, you would realize that the total amount of energy you put in the simulation is essentially arbitrary. You can set the kinetic energy of motion of all the individual simulated bits to whatever you wanted (up to the limits of how you store the numbers by flipping bits in silicon). The potential energy of gravitation or electromagnetism you create in the simulation is likewise essentially arbitrary, based on how you place the initial components and how you set gravitational constants and electromagnetic constants. Granted, there are consequences to how you set all those parameters, but that is a different design constraint based on aesthetics or purpose.

So, from my viewpoint, it is quite possible that "energy" and "matter" are probably essentially arbitrary. Someone with control over low-level aspects of the simulation (maybe even humans, someday) could magic matter and energy into existence as easily as a banking computer could magic trillions of dollars into existence by flipping a few bits on a hard drive or computer memory or fiber optic messages somewhere. Granted, there are social consequences to such currency creations, and likely would also be some social consequences somewhere as well to magicking matter and energy. :-)

But, that still leaves the question of where the computational matrix came from. Or, as is mentioned here, what implements the virtual turtles all the way down. :-)
http://science.slashdot.org/co...
https://mail.python.org/piperm...

Still, as another Slashdot story or poster months or years ago said, there is a some finite probability infinity will create itself from absolute nothingness, given the lack of constraints in complete nothingness. So, that could explain it all in that sense. :-)

Granted, my comments and musings on all this is perhaps just like a bacterium trying to make sense of what is happening while it is on the wing of a jetliner -- or no doubt the situation is even stranger. So, just some thoughts and possibilities. And of course, as other posters have said, or Iain Banks in "Excession", this is an "Out-of-context problem" which can not be that well addressed by typical scientific paradigms or rules of inquiry, since we are talking about things beyond the tiny circle of light cast by the comparatively feeble flickering of human mind and society, relative to a vast infinity of infinities and so on.

Still, we don't fully understand the human mind or consciousness either, so who really knows what it is possible to understand or not understand. We don't even know how long "humans" in a sense "live", with life after life as a possibility (like if "life is but a dream" or a game or learning experience we will wake up from and go onto other experiences), and so on.

Again, these all quickly become religious and philosophical questions -- but that does not mean they are not important or interesting. Although it does mean they are not that open to conve

Although Python 3 is objectively better in many ways, the improvements don't seem compelling enough to me to bother to really learn

Well, that is catch-22 in action -- you will probably not really get the improvements unless you actually explore them. If reading about the changes is not enough (though perhaps it is, but you have not read enough), and all the Python developers saying "you should really go to Python 3" is not enough, then perhaps the only thing that will convince you is diving in and experiencing the differences on a deeper level.

For me, as someone who has not grown up in an unambiguous ASCII-society and has felt the pains of handling input in strange encodings, the improved Python 3 string handling is a killer feature on its own. I will not look back.

There are two libraries holding back some of my projects: wxPython (where a Python 3 rewrite is under way) and MySQLdb (a Python 3 rewrite was under way, but has been dead since 2012; today there are several options, though). Those projects stay in the "if it aint broke"-pile until further notice. Other than those (well, only wxPython, really), I have no gripes about missing modules any longer.

And I still kindda like "print" as a statement.

That is probably the most superficial change of them all, fixable by search-and-replace, yet the one that people get stuck on :-) . It makes a lot more sense to have the parenthesized form, immediately allowing automatic string continuation over lines, optional keyword arguments (end='' is quite useful), etc.

> difficult to dump a piece of data to the disk without converting it into text first

Sounds like you need to add some pickle

Python has a PEP (think RFC) for that. It says:

Use 4 spaces per indentation level. [...] Spaces are the preferred indentation method. Tabs should be used solely to remain consistent with code that is already indented with tabs.

That's the the near-universal style almost everyone used anyway, so it was more of a hypothetical than practical issue anyway.

I'd pick VisualBasic over Python as a beginners language.Plus VisualStudio is really good; its a good IDE, good debugger; its stable, its free; its widely used in the 'real world'

And you can use it for Python, with everything that you wrote still being true.

and you can focus 100% on "learning to program" without getting bogged down in configuring your environment or managing your toolchain or phyhon package management, library versions (python 2 vs 3), etc, etc, etc.

For this kind of stuff you really don't need to. I would be extremely surprised if all the tasks that he covers in his class wouldn't be covered even by the base Python install downloaded from http://python.org/ (which PTVS will even tell you to do if it finds that you don't have Python). And if that is not true, then a prepackaged Python distro like Anaconda - again, a single-click install - will surely be enough.

Besides, VB.NET is basically C# with training wheels; so you switch BEGIN and END for curly braces, realize procedures are just functions that return "nothing", and a little bit of other syntax and you are up and running in something that is pretty relevant.

I would argue that the cruft that VB.NET puts on top of C# is mostly useless as training wheels - it's no big difference between IF..END IF and curly braces - and in some cases is actively harmful because it uses its own terminology that is not shared with any other programming language, in lieu of terms that are commonly used throughout the field (like MustOverride/MustInherit instead of abstract).

Basically, if you are teaching people VB, you might as well teach them C# right away. It'll take 1% more effort, but they'll have a more useful skill from the get go, and knowledge of syntax will help them when it'll come to C++, Java, JavaScript etc.

The original code is correct except that you have to define "n" as the limit. Basically it'd be in a function like:
def primes_upto(n):

It uses the functional programming style available in python which allows single liners that can do a lot (though ideally you will split them up a bit for readability).

But what about IronPython? Oh, and there's also the fact that many Python distributions come with TkInter, and it has bindings for the most popular cross-platform GUI toolkits.

I'd love to see *any* "complex construct" that C can do, that Python cannot do in a general computer science/algorithm sense.

Especially since in Python "complex is better than complicated." Although Python programmers sometimes do resort to C, it's always for speed of execution, never to somehow minimize complexity. In fact, since Python provides a simple and elegant system of object-oriented and generic programming, it's also better than C++ for jobs where speed of execution isn't the dominant factor.

The details of the Python license jousting was lead by Eben; there's a good summary of the backstory in his 2.1 FSF e-mail. As Mr. Moglen listed himself then as "Professor of Law & Legal History" at Columbia's law school, you're not going to get very far with cheap personal attacks on his credibility. Not that how you tried to do that with Stallman was very productive either, given he's regularly advised by legal counsel when writing.

Moderation:
-1 Missing angle bracket
+0 Semi-accurate quasi-religious bashing
-1 Accuracy

The FAQ for the Python 1.6 license states that the FSF attorney and Richard Stallman objected to a single clause of the Python 1.6 license specifying a venue for interpretation. I don't know why you would assume that Stallman was speaking without benefit of legal counsel. Also, not being a lawyer does not automatically mean you are unqualified to interpret a license agreement (and vice versa). I would assume that, barring evidence to the contrary, RMS is a subject matter expert in the legal interpretation of the GPL and software licensing in general, seeing as how he's been doing nothing else for the last twenty years.

Aside from ad hominem, do you have any arguments against his expertise in these matters?

Which language is that? Phython? C++? C? Java? A language "does not cut it" ... how retarded.

It's not retarded at all; it's a simple fact that each language comes with its own set of design decisions that make some tasks easier and some tasks more difficult. Thinking that all languages are equivalent would be a newbie mistake.

For example, Python, while it is a great high-level language and easy to learn and use, will almost never produce software that runs at the speed of an equivalent compiled C or C++ program. Furthermore, its continuing reliance on a Global Interpreter Lock means that multithreaded Python programs will not utilize multiple cores efficiently for the forseeable future.

Java, OTOH, avoids those problems but using Java means you'll need to include a Java runtime environment and JIT on any platform you deploy on; that makes it inappropriate for many embedded devices or otherwise constrained environments. Also the non-deterministic timing of the built-in garbage collector makes Java a poor fit for real-time programming.

C/C++, finally, can run mostly anywhere, but their low-level nature makes them a bit harder to learn, and a great deal more conducive to shooting yourself in the foot with (if you don't use them correctly).

For the best reasons to learn Python, see The Zen of Python. If Python happens to pay more, that's just gravy.

That said, it seems hard to believe that people would get paid extra to work in such a pleasant language. If so, maybe Adam Smith had it all wrong when he said:

First, The wages of labour vary with the ease or hardship, the cleanliness or dirtiness, the honourableness or dishonourableness of the employment...The most detestable of all employments, that of public executioner, is, in proportion to the quantity of work done, better paid than any common trade whatever.

Read on a bit more. By paragraph 10 he points to increased wages for jobs requiring skill, by paragraph 20 he's getting into jobs requiring trust.

Pity he living too soon to comment on large software project laborers.

For the best reasons to learn Python, see The Zen of Python. If Python happens to pay more, that's just gravy.

That said, it seems hard to believe that people would get paid extra to work in such a pleasant language. If so, maybe Adam Smith had it all wrong when he said:

First, The wages of labour vary with the ease or hardship, the cleanliness or dirtiness, the honourableness or dishonourableness of the employment...The most detestable of all employments, that of public executioner, is, in proportion to the quantity of work done, better paid than any common trade whatever.

Perhaps florists soon will be making more money than plumbers. Which would really stink.

I see no beauty, simplicity or elegance in the pythonic way variables are handled when shadowed (for example, global scope). You can read them BUT writing them fails silently! Explain how this is intuitive in any way.

For the best reasons to learn Python, see The Zen of Python. If Python happens to pay more, that's just gravy.

That said, it seems hard to believe that people would get paid extra to work in such a pleasant language. If so, maybe Adam Smith had it all wrong when he said:

First, The wages of labour vary with the ease or hardship, the cleanliness or dirtiness, the honourableness or dishonourableness of the employment...The most detestable of all employments, that of public executioner, is, in proportion to the quantity of work done, better paid than any common trade whatever.

Perhaps florists soon will be making more money than plumbers. Which would really stink.

"What kind of people are these that use vulgar, profane language in these posts. Personally, such people's critiques should be ignored and consigned to the local sewage inlet. A very sad comment on contemporary society."

Just as a guess, putting any person-to-person (mis)communication or personality aspects aside, I think a lot of programmers are frustrated with the state-of-the-art in programming. Examples include the proliferation of JavaScript despite its needlessly confusing warts and missing pieces (same and worse for PHP), Java not fulfilling its promise of ease of installation with lots of versions despite stealing Smalltalk's thunder and having vast amounts of money poured into it, C++ being so confusing and easy to shoot yourself in the foot with, a huge proliferation of half-finished languages, Python and Perl splitting with major new not-backwardly-compatible versions, version, a proliferation of mostly similar FOSS licenses and yet incompatibly-licensed code you can't legally use or distribute together, too many buggy libraries that do almost the same thing and much of what you want but have somewhat different bugs, entrenched awkward "scripting" languages with low performance and are not really much easier to use than other languages for anything substantial or that needs to be maintained or debugged, lack of good documentation for so many projects, badly written software that is hard to understand yet does useful things, lack of tests, vast amounts of computing power in hardware but seeing it frittered away or not being able to easily access it or it being wasted on supporting huge amounts of duplicated inefficient code including likely several different interpreters, library dependency hell, bit rot including of FOSS contributions getting left behind, layer upon layer of abstraction ignoring more abstraction can't solve the issue of too much abstraction, confusing conflict-of-interest marketing information to sort through, data encoded in proprietary or unusual formats and so hard to use, a proliferation of confusing or intentionally limited "standards", the frequent ignorance of the history of programming among programmers who have not lived it, and so on.

For anyone who has programmed for decades and seen what it felt like to use Forth, Smalltalk, BASIC on a C64, or even an assembly language monitor, there is some huge mismatch these days between what we *feel* should be possible and the systems we are in practice forced to work with these days either for economic reasons or reasons of trying to get incremental changes adopted. Notice I said "feel should be possible", so it is a feeling or aspiration -- whether it is reasonable expectation is another issue.

That frustration may express itself as profanity when a programmer see resources (including just getting a Slashdot discussion going) going to new projects that don't seem to really address or acknowledge these fundamental issues. Worse, new projects that don't recognize these issues may just be adding further to all the confusion and complexity (yet another syntax to learn and guess at for ambiguities, yet another lack of documentation, yet another maybe great library that is effectively unusable because of the complex interdependencies or choices about context like desktop vs. web, etc.).

Contrast with Alan Kay's Fundamentals of New Computing (FONC) project which at least acknowledges some of these issues even if it may not fully deliver on all or even many of them (and I have my own criticisms on stuff FONC has ignored).
https://mail.python.org/piperm...
https://www.mail-archive.com/f...

I 've suggested it's possible Linus Torvald's profanity also has some of the same roots of frustration at overwhelming complexity and harder-to-manage risks because of it:
"[fonc] Linus Chews Up Kernel Maintainer For Introducing Userspace Bug - Slashdot"

Thanks for correcting some of my semantics. :)

My point was that Python is a VM-backed language, similar to the JVM (more correctly, similar but lacking JIT), and unless you hit the GIL it performs quite well. Same as with Perl.

Here is Python's VM: https://hg.python.org/cpython/file/3.3/Python/ceval.c#l790

I'll attempt to agree with your Java sentiment by saying that Java only became worth a damn in 1.5.

Today it is respectable for a number of use-cases. My favorite use-case is JAX-RS 2.0. Anyone who writes REST interfaces in Node.js or almost anything else just likes to type a lot of unnecessary lines of code, manually injecting request parameters into business logic and manually creating encoded responses, etc. (Webmachine in Erlang, Ruby or Python is almost as respectable as JAX-RS 2.0 & Jersey.) In JAX-RS 2.0, my same web-annotated business objects and structure-annotated value objects can serve application/xml, application/json and application/x-www-form-urlencoded inputs and outputs without me having to write a single line of plumbing or conversion code, letting me focus on the business logic and domain object model alone.

In the event processing system I referred to, we rewrote it in Java and acheived many improvements in speed over Python (due to our I/O bound multithreading and, of course, avoiding IPC-in-Python along the way, which would have helped, as you say).

FWIW, Puppet is moving from Ruby to JRuby... I'm not a huge JVM fanboy, but it has its benefits on occassion, especially if you can avoid all instances of legacy code and legacy APIs. (Java has a done a better job of learning from their mistakes, but the mistakes linger in legacy code.)

PS: It is not well-known, but it is possible to do reified generics in Java with some hackery (with concrete anonymous abstract classes), if you really need some C++ template love in your codebase.

Nice chatting!

So brilliant programming languages do not permit eval($ENV["FOO"])?

Correct, because good programming languages don't have anything like eval().

Normally, in a decent programming language, if you're convinced you really need to execute unknown-until-runtime code, the first step is to get over your misconception. If you're unable to get over the misconception, then you do something like fopen('tmp.c'); fwrite... fclose, system('cc variousflags tmp.c'); system('tmp'); and then you spend the next few weeks worrying about how awful what you did was, and rethink your unnecessary "need" to run generated code.

eval() is not C or C++. It's Bourne Shell, and it's a necessary evil for a Shell language to have. That said:

• Java - http://docs.oracle.com/javase/...
• C# - http://msdn.microsoft.com/en-u...
• Python 2 - https://docs.python.org/2/libr...
• Python 3 - https://docs.python.org/3/libr...
• PERL - http://perldoc.perl.org/functi...
• Windows Powershell (via invoke-expression) - http://en.wikipedia.org/wiki/E...
• and more - http://en.wikipedia.org/wiki/E...

So what again was your point?

So brilliant programming languages do not permit eval($ENV["FOO"])?

Correct, because good programming languages don't have anything like eval().

Normally, in a decent programming language, if you're convinced you really need to execute unknown-until-runtime code, the first step is to get over your misconception. If you're unable to get over the misconception, then you do something like fopen('tmp.c'); fwrite... fclose, system('cc variousflags tmp.c'); system('tmp'); and then you spend the next few weeks worrying about how awful what you did was, and rethink your unnecessary "need" to run generated code.

eval() is not C or C++. It's Bourne Shell, and it's a necessary evil for a Shell language to have. That said:

• Java - http://docs.oracle.com/javase/...
• C# - http://msdn.microsoft.com/en-u...
• Python 2 - https://docs.python.org/2/libr...
• Python 3 - https://docs.python.org/3/libr...
• PERL - http://perldoc.perl.org/functi...
• Windows Powershell (via invoke-expression) - http://en.wikipedia.org/wiki/E...
• and more - http://en.wikipedia.org/wiki/E...

So what again was your point?

any CGI program + any non-Debian Linux => vulnerable

No, only CGI programs that use system/popen/etc to call out to things that may be bash.

Enh, good luck auditing even just a resonably complex CGI program for direct and indirect invocations of the system shell.

For instance, care to guess whether this one is safe?

For once, the PHP programmers are ahead security wise due to the ubiquity of mod_php...)

Well for one most languages the equivalent facility is available and usually used since it is a requirement to scale.

I know, mod_perl and mod_wsgi on Apache, and of course, Fast CGI. But CGI is still common in a lot of setups.

For another, even the silly 'fork and exec' perl or php or python isn't vulnerable if said script avoids system/popen/backticks/whathaveyou.

Even if you don't call out to the shell yourself, the standard library might.

Pop quiz 1: How is the PHP mail function implemented?

Pop quiz 2: What parts of the Python standard library module uuid are safe to use, and what parts will render your CGI script vulnerable?

I guess I was wrong to play down the severity of bash, but my hope was for people to just consider themselves to make a mistake by ever potentially having bash in a cgi context, for reasons beyond this exploit.

It's the system shell. It's everywhere. The real lesson here is to not use a big bulky program like Bash as the system shell.

Answers to pop quiz:

1. popen to execute sendmail program.

2. The following Python CGI script is vulnerable: import uuid (that's it). (uuid uses ctypes.util.find_library, which uses popen).

These examples took me less than 20 minutes of grepping to come up with, and I'm not even trying to hack any computers...

I understand what === means. It's just that sometimes I want a middle ground between "exactly the same type" and "convertible to the same type even if it requires relying on behavior that depends on the default locale". I want to check whether they're equal and have similar types, with a useful definition of similar. For example, Python 2 allowed 8-bit strings and Unicode strings to compare equal, both being of type basestring, and allowed integers, long integers, and floats to compare equal, all being of type numbers.Number, which was informal initially but formalized in PEP 3141.

That and PHP lacks an operator for object identity for arrays. I'm not aware of any practical way to tell whether mutating one array will cause another array to be mutated without (slowly) checking them element-by-element and (potentially unsafely) trying to actually perform the mutation.

The Python GIL

There is currently an enormous discussion going on at python-ideas (see various large threads towards the bottom). Guido himself seems to be in favor of including something like MyPy into Python's standard library, which is allows for optional specification of arguments and return types using function annotation. The main use would be for static/offline code analysis/linting.