Slashdot Mirror

The keyword to enable these changes in Python is from __future__ import . Seven features were introduced during Python 2.x: nested_scopes, generators (which added the keyword yield), division, absolute_import, with_statement (which added the keyword with), print_function (which removed the keyword print), and unicode_literals. Some already default on since 2.6 (nested_scopes, generators, and with_statement). In each case, there's a transition period when a module can choose one behavior or the other, and a module expecting one behavior can call a module expecting another behavior. The only breaking change that doesn't allow this sort of mixing is 2.x to 3.x. No breaking changes that I'm aware of have been introduced in Python 3.x since Python 3.0.

I went through the PHP migration guides and listed incompatible changes to the language itself: 5.1 to 5.2 (change to behavior of $value % 0, change to object-to-string conversion semantics), 5.2 to 5.3 (fatal error when passing a value to a function expecting a reference instead of creating a temporary anonymous variable, change to handling of $this in call_user_func_array(), and some new reserved keywords), and 5.3 to 5.4 (removal of call-time pass-by-reference, removal of computed break and continue statements, and some new reserved keywords). And at all times, all programs must use the syntax and semantics of the installed version of PHP.

Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> from __future__ import division
>>> 1 == 1.0
True
>>> 2 == 2.0
True
>>> 1 / 2 == 1.0 / 2.0
True
>>> 1/2==1/3
False
>>>

True, I "cheated" by including a statement that turns on the "divide correctly" flag, which is off by default in Python 2.7 for compatibility with pre-Python 2.2 code. But it's on by default in Python 3, and there are far fewer such breaking changes to language semantics in Python than in PHP. And in Python, you turn on a language feature in the module, not in an INI file to which a hosting subscriber might not have access.

If you're trying to imply "still nothing uses Python 3", the version of Blender on my PC embeds Python 3. One big problem (doing the right thing with side-by-side Python 2 and 3 on Windows) was solved when Python 3.3 implemented PEP 397.

> the first ones used threads, semaphores through python's multiprocessing.Pipe implementation. the performance was beyond dreadful, it was deeply alarming. after a few seconds performance would drop to zero. strace investigations showed that at heavy load the OS call futex was maxed out near 100%.

uhhm... wait what?

You are aware that python has global interpreter lock, right? And because of that multi-threaded performance in python is actually *worse* than single-threaded? But this is an inherent flaw in python interpreter and has nothing to do with Linux. It also has nothing to do with the topic of this article.

Tons of online books and tutorials. See https://wiki.python.org/moin/P... . Python is my go-to language for just getting stuff done. I use it for damn near everything these days, except mobile apps, which I code natively.

Visual Studio Express is Microsoft's zero-cash programming environment. Why do you want a high-cost office suite with a lousy macro engine to be discounted to free when they already offer their actual development suite pro bono. It's upgradeable to more complete Visual Studio versions later. This will encourage Microsoft-centric code, but that can be avoided and it's less specific of a tie-in than VBA. C#, C, C++, and more are included.

If you don't want to be tied to Microsoft-specific tools even on Windows there are other options. Those include other office suites and other actual development tools.

LibreOffice/OpenOffice have OOBasic and can be scripted with Python and Java if you really want. These things are zero-cash and open source.

You can use Lazarus and FreePascal (Wikipedia article about FreePascal) or Eclipse and Java/C/C++ if you'd rather. Or you could use Eric and Python. Or Padre and Strawberry Perl, complete with MinGW. Some of the IDEs are more or less general and language agnostic, while others are mainly narrowly targeted.

Don't forget MsysGit (git for Windows) if you're not using Cygwin and haven't already chosen a version control system.

Really, you could be teaching with a good programmer's editor rather than specifically with IDEs too. vim, Emacs, jEdit, Gedit, and others are applicable. Some of them are powerful enough to make that line between editors and IDEs very fuzzy.

What, exactly, would a free copy of Word get you that isn't already available?

Programs must be written for people to read, and only incidentally for machines to execute. - H. Abelson

Also Zen of Python has a bunch of interesting points.

Good points on dreams, and disappointments, and continuing hopes.

Here are some rambles of my own thoughts and experiences with OLPC and an independent software developer long interested in education (my wife and I made a free garden simulator in the 1990s).

I got two OLPs via the G1-G1 program. One never even made it out of the box, sadly. (I think of donating them somewhere sometimes, thinking it is better a kid has it than it becomes an unused collector's item.) I made a demo version of some of our plant growth software under Sugar and ported to Python, but did not take it much further. The code is here:
https://github.com/pdfernhout/...

My hopes from 2007:
https://mail.python.org/piperm...

As I see it, the OLPC project shot itself int the foot unfortunately, especially with Sugar. (I've done that to myself enough times, so I know. :-) Sugar was a great idea, and still is, but it was just too much of a stretch and not especially central to the overall OLPC goal. The push to Sugar also just underestimated how fast kids can learn -- contrast with the Hole in The Wall project. As others have said, it would have been better to just get a plain Linux system running Debian and a standard window manager into kids' hands on a low-end ruggedized laptop. Sugar may have had innovative ideas, but it was a real stumbling block, Also not choosing ARM was another stumble. Dumbing down the browser was another stumble, Also promoting Python on low-end hardware was another stumble, as much as I've liked Python; Java or just C would have been a better choice. Or instead of Sugar, just all Squeak on Forth and ditching the OS would have at least been a more innovative plan and improved performance and understandability by ditching Linux. The keyboard also is a problem of usability and reliability. One of the USB ports on the machine we used stopped working quickly, and I can't see how they would really be waterproof anyway. Sugar was also a distraction form finding and organizing existing educational software and content, another stumble. (I know a separate foundation started to do free content for the OLPC, not sure where it went.) Not understanding that a village of often related people works together and could have a networked central facility (with one computer per child who wanted to use it, plus cheap usb storage fobs) is another cultural stumble. It's easy to say with 20/20 hindsight the OLPC group should have know these things as with all after-the-fact comments, but I won't let them off that easily, because people did point such things out from the start, and also you'd expect the team to have some expertise in education and culture and system design. These point to some sort of dysfunctional social process that must have been going on with early decision making.

What it mostly came down to as far as my involvement was that as a developer, why should I make an educational app specific for Sugar to reach an audience of a million (or whatever), going up a painful bleeding edge learning curve dealing with buggy ever-changing Sugar infrastructure, when I can potentially reach an audience of a billion or more writing a JavaScript-powered web app or just a plain cross-platform Linux/Mac/Win app like with Java or C/C++ or even Squeak? And knowing Moore's law means whatever I write now of bigger platforms will be accessible more cheaply in five or ten years? Even as a volunteer, the value proposition is weak.

I wanted the OLPC project to succeed. I even used it as an example here, suggesting the world might be better off if Princeton University dissolved itself and spent the endowment on OLPCs:
http://www.pdfernhout.net/the-...
http://www.pdfernhout.net/post...

Overall, though, just JavaS

One common design pattern for ensuring that unmanaged resources get released is try/finally, which works with JVM, CLR, and CPython, but doesn't work so well with resources held longer than one method.

And this is why it is best practice in Python to use the with statement

This is explicitly a syntactic sugar for the try/finally approach (PEP 343) and shares some of its disadvantages. Like the lifetime of a resource allocated in try and cleaned up in finally, the lifetime of a resource allocated at the start of a with block and cleaned up at the end of said block is limited to the lifetime of that block. If you allocate an object in one method, such as the __init__ method of a class, and retain it, how do you ensure that it gets freed? For example, a class that reads a stream of objects out of a file may implement the iterator protocol: open the file in __init__, return an object in __next__ (next in Python 2), and close the file when?

I am a little confused about your request. On my very modest system, Python takes just under three-minutes to compile from: extract > cd > ./configure > make > make install

I run several Ubuntu derivatives and honestly never considered apt-get - but I also often run more than one version of Python on any given system and compiling manually makes that easier to maintain. If you are a Linux user so stuck on apt-get that you cannot work with source code at all, I highly suggest you download the source from here: https://www.python.org/downloa... and give it a try.

But... but ... they've replaced nice, neat functions like find, index, split, strip... with a poorly documented, crappy, pseudo-regexp load of junk. How can anyone work with that?

I have tried it myself, I actually decided to stick with Python 2 because I ran into plenty of awkward behavior and found that most of the third party modules I was interested in weren't available. Just now, as an example, I've visited this page (note the 3 in the URL). Trying to get up to date GUI library bindings for Python 3, I find the state of them to be quite disheartening. The PyGTK+ binding has been replaced by PyGObject in Python 3, but the PyGTK+ recommends staying with PyGTK+ on Windows. The rest aren't looking much better - our options are Tkinter and Qt if want to be '3 clean'. This exercise actually reminded me of something I discovered the last time I made the attempt to support Python 3 on Windows, the finding that I was explicitly limited to installing particular combinations of Python versions and libraries if I expected the libraries to actually work. Something was severely broken along the way, and I get the impression that it's one of those things that nobody will ever admit to.

The real answer is to make a hash over the image content. The ImageHash python package comes with a program to discover duplicate images. It is more powerful than what is needed here: It can find images that looks similar (different format, resolution, etc.).

I think the ImageHash package uses a better algorithm than findimagedupes (description here, actually you can choose between several), and is shorter in code.

>>> Just use tabs.

How about no. http://www.python.org/dev/peps/pep-0008/#tabs-or-spaces

Four spaces are the specified indentation method. Tabs should be used solely to remain consistent with code that is already indented with tabs. Most Python IDEs will turn a tab into four spaces, and even block indent multiple selected rows with spaces with the press of tab. Dealing with legacy tab code by unknowledgeable devs is a pain, it is much easier to run autopep8 and check in a 100% space diff then deal with editing that code.

Python 3 disallows mixing the use of tabs and spaces for indentation.

Python 2 code indented with a mixture of tabs and spaces should be converted to using spaces exclusively.

Python has a well-defined versioning scheme for interpreters which is documented in detail. In particular, it requires that python2 is a symlink to some version of Python 2.x, and python3 is a symlink to some version of Python 3.x; authors of Python code should author their scripts correspondingly. If someone wrote a 3.x script that starts with #!/usr/bin/python, then they are the problem, and you should whack them with a stick until they fix that.

Also note that this spec requires that python be the same as python2 until further notice, which will happen in 2015 at its earliest. So, again, if you or your distro symlinks python to python3, then that distro is breaking things.

As a user of a package written in Python, you are, of course, not at fault. But it's not a fault of Python language & interpreter developers, either - as you can see, they were well aware of the problem, and came up with a working solution. They can't really help it if distros (which are, ultimately, responsible for installing Python on your system) don't follow that solution, or if app developers who use such distros write bad code.

Of course, that link you gave says: Created: 02-Mar-2011

So prior to 02-Mar-2011, people using say python 2.5.2 (released in 2008) were not being "informed" to write their code using /usr/bin/python2, and so all that old code is now "improper" according to a spec released *3 years* after the code was written. No, while one might argue that won't change until "2015 at the earliest", it is still quite possible that code might well exist that uses /usr/bin/python expecting (and only working with) python2. In which case, one might ask - if the new 'standard' (post 02-Mar-2011) is to use /usr/bin/python3, why would the symlink *ever* change (2015 or after even)?

You've completely missed the part about UNLESS YOU BUILD IT YOURSELF... windows is more or less a "built yourself" installation as there aren't any "system" pythons

That's plainly wrong. Go to the download page for Python and look at the MSI downloads - those are your "system" Pythons. They will, in fact, even register themselves in PATH, and add a global registry key aiding any tools in locating the installation directory.

And yes, Python will use various common search locations by default. But I can't think of any that cannot be overriden via various command line switches and/or environment variables.

In any case, what's the problem with custom-building Python for your app?

If you're a python developer, then you'll very likely have numerous local builds without such issues. For common end users, no one is going to go to all the trouble necessary to side-step the system python, or build their own self-contained version. (an app provider might, but I don't know of *any* that do -- outside windows, and many windows python apps simply include a "step 1: install activestate python x.y.z")

But of course I was talking about the app providers here. The notion that users would set up an isolated Python environment for their app is absurd; that's too much of a burden. But for an enterprise app (which is the kind that would presumably care that much about versioning in the first place), it's a no-brainer, just as they bundle private copies of JRE for Java apps.

The apps that don't require such stringent support but still want versioning should just use the appropriate shebang, i.e. python2.6 rather than just python2, and reference the appropriate version in the package. Sane distros let you do things like running 2.6 and 2.7 side by side, and symlink them accordingly.

(an app provider might, but I don't know of *any* that do -- outside windows, and many windows python apps simply include a "step 1: install activestate python x.y.z")

On Windows, ironically, it's probably the easiest to support system installs, because various Python distros have a standard way of registering themselves for a given version number (in the registry), and startup scripts can then read that registry value and have the full path to python.exe to run for a given X.Y (or lack thereof, at which point they can prompt you to download & install). It's kinda like symlinks on Linux, except that, because on Windows Python installers are provided by Python devs, they work as Python devs intended, and so we can actually rely on that setup being the same on any Windows machine.

Zope 2.x continues to be updated and maintained. It was zope 3.x which was abandoned. You can go to https://pypi.python.org/pypi/Zope2/2.13.21 and download the latest version of zope. It was even discussed to rename zope 2.x to zope 4.x but that was dropped since they thought it would be even more confusing. Zope 2.x has also run on the python 2.7 for a very long time now and so far I have upgraded apps written in zope 2.0 all the way up through 2.13 over the years with very few problems.

From The Zen of Python:

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

From TFS:

Nathan Froyd adds "I think this list of reasons to upgrade misses the larger point in providing software for other people: You do not get to tell your users what to do...."

This is one of the main reasons I hate Python: It's Guido's way or the highway. But, furthermore, Python 3.0 violates this principle as well: If there was one way to do it in 2.x, that way should continue to be the only way to do it in 3.0.

Python has a well-defined versioning scheme for interpreters which is documented in detail. In particular, it requires that python2 is a symlink to some version of Python 2.x, and python3 is a symlink to some version of Python 3.x; authors of Python code should author their scripts correspondingly. If someone wrote a 3.x script that starts with #!/usr/bin/python, then they are the problem, and you should whack them with a stick until they fix that.

Also note that this spec requires that python be the same as python2 until further notice, which will happen in 2015 at its earliest. So, again, if you or your distro symlinks python to python3, then that distro is breaking things.

As a user of a package written in Python, you are, of course, not at fault. But it's not a fault of Python language & interpreter developers, either - as you can see, they were well aware of the problem, and came up with a working solution. They can't really help it if distros (which are, ultimately, responsible for installing Python on your system) don't follow that solution, or if app developers who use such distros write bad code.

What bad habits? Logic of whatever type you want to implement is inherently sequential.

No, it is not. Logic is inherently reflexive and transitive. It's a major failing in math education, that people think it is about performing algorithms in sequence. Most people never learn the relations that allow you to rearrange the equations and create new algorithms.

In programming, the idea of sequential programming has problems. CPython guarantees that only one bytecode is executing at one time, and therefore they find it extremely difficult to remove the Global Interpreter Lock. C guarantees sequence only between sequence points, and makes liberal use of undefined behavior. Even Javascript, with its relatively simple model, has variable hoisting that catches beginners by surprise. Locking limits scalability, and shared-memory multi-threading is so difficult that it's believed that almost nobody knows how to do it properly. I think it was Crockford who said that the programmers who understand multi-threading should be captured and compelled to do systems programming, but I'm not sure.

Declarative and functional programming don't require execution in a particular sequence. The canonical example of this is Haskell, with its lazy evaluation, but logic programming is based on this idea, and even event-driven programming is like programming inside-out for a sequential programmer.

What does Java do that a piece of Python\Perl\Ruby\Lisp script can't do

Run on Java ME phones is one. Acceptable performance through recompilation to native code is another. Last time I checked, Python, Perl, and Ruby were interpreted, with expectation that inner loops would be factored out into a library written in C++ and called through ctypes or the other languages' equivalents. Java threading also beats Python's Global Interpreter Lock.

If you just look at languages that either have enthusiastic big money backers or importance due to legacy, you are generally limited to C/C++, C#, and Java. Companies like IBM, Microsoft, Sony, Google, Oracle, Facebook, or even Amazon don't put an effort behind a language like ruby, which is at least one reason it's more niche. And if you look at what's out there, most of those companies are wedded for one reason or another to one of the languages already in broad use.

Now, if Google ever made a serious effort to push go, perhaps it would gain traction in a serious enterprise kind of way. Likewise, if Facebook were to ever decide to push a language, they might have the clout.

You may be surprised if you actually looked it up at how much Google and YouTube use Python. Here, let me do that for you: http://www.python.org/about/quotes/. Facebook is built on PHP, a language designed to solve the same types as Ruby. Other than Oracle and IBM, none of those companies make much if any use of Java as a core language for any of their products.

Nope, nobody at all http://www.python.org/about/success/

Jeez.

Yes it would, as the Python interpreter is open source: Python License & History

Here's the python dev's own page describing it and how to get to the results.

Or you could've saved weeks of your life by running the pep8 tool on your code, which will tell you all the lines that aren't indented by a multiple of 4, or which lines have tab characters in them, or any number of other formatting problems that aren't recommended by the style guide.

There's a difference in design philosophies which explains the difference perfectly well. From pep-20:

Explicit is better than implicit.

The Python way of doing what you want to do is:
range(len(['a', 'b', 'c']))
That way, someone reading it doesn't have to look up the range function to know why the interpreter treated ['a','b','c'] as equivalent of 3.

By contrast, perl is built with implicit assumptions all over the place so that a programmer experienced in perl doesn't have to type as much. The best known example of this is the $_ variable, which means all sorts of things depending on context.

Neither one is wrong, per se, but the difference reflects different language goals.

I feel that the reasons are evident in the release notes that describe the new features in 3.1, 3.2, 3.3... The more interesting question to me is what he thinks of the serious lag in library support for Py3, which I posted below.

Care to point out some highlights? A little bit of evangelism would not hurt. If you ask Stroustroup what are the cool new features of C++11, he has a good answer ready. Other than the new unicode support, which is very important in some contexts but not everywhere, I see nothing else that's very exciting looking here: http://docs.python.org/3.0/whatsnew/3.0.html.

Python does have abstract classes. They have also been backported to 2.6 for those that want to use them before transitioning to 3.x. See the numbers module for an example of their use.

Python does have abstract classes. They have also been backported to 2.6 for those that want to use them before transitioning to 3.x. See the numbers module for an example of their use.

Apparently this is planned for 3.3, and influenced by Google Engine, twisted tornado and others: http://www.python.org/dev/peps/pep-3156/

A somewhat snarky rebuttal:

What bugs me about operator overloading is how tediously verbose it can get. For example, say you define operator functions for < and ==. You still have to do <=.

Get a better language.

For instance, in Python, functools.total_ordering will give you all six comparison operators when you give it < and ==. In C++, std::rel_ops will do the same thing. (Admittedly, in the C++ version it isn't on a per-class basis without some work because those are function templates, so you either get them for all classes or none.)

Down at the machine level, the computer does not stupidly require 2 separate comparisons to test
Get a better compiler.

Given the code

bool leq_native(int a, int b) {
    return a <= b;
}
 
bool leq_or(int a, int b) {
    return a < b || a == b;
}

GCC at -O1 or -Og or higher and Clang at all optimization levels all produce identical code for the two functions.

(OK, my "get a better compiler" is a bit harsh here. Interestingly, Intel's C++ compiler leaves in a jl/jne sequence at all optimization levels, as does MSVC.)

So if anyone can suggest a programming language to replace PHP I would love to know.

My personal favorite is python. It's easy to work with, logical, and really fits the way I think.

Some resources:
  * Instant python - gives a quick rundown on basic python
  * Ideomatic python - this is more about how one should use the language

Packages:
  * Bottle micro web framework - small and doesn't have the niceties of the larger python frameworks, but it's great if you just want to get your feet wet, and do something right now
  * VirtualEnv - Creates virtual python environments where you are free to experiment with different packages (and python versions) without affecting anything else.
  * PIP - package manager. Works incredibly well with virtualenv, and have some neat features (like making a list of all packages and versions installed in active VirtualEnv)

Well you could with implicit line joining:
def square(x):
        print(
'DEBUG: x=%x' % x)
        return x*x

Note that the print starts indented but since a parenthesis is opened the rest of the statement can continue anywhere on the next line. Until the closing parenthesis whitespace rules are ignored.

http://docs.python.org/3/reference/lexical_analysis.html#implicit-line-joining

But really you should use the logging module and set log levels. Debuggers are good tools as well, but I usually rely on unit tests to track bugs (or rather, not have to track them down).

Go get Hy. https://pypi.python.org/pypi/hy (Python in a LISP-y syntax. Same libraries, same features, no whitespace worries - but the project is still in alpha.) Why should Java developers have all of the LISP fun with Clojure?

This is still wrong in that you have to pass the special "surrogateescape" and use encode/decode.

In the context of handling filenames, you get this by default. As I said, I used os.listdir() and my file whose name contained a character invalid for UTF-8 was in the results, with a surrogate escape code for the illegal character; I was able to open it, rename it, or delete it (I tested all three).

In short, filenames Just Work in Python 3, despite your claims.

I want to be able to store a "Unicode" string that contains a UTF-8 error without an exception being thrown. The exception would be thrown if you attempt to translate the string to UTF-16 or look at the code points (though I also recommend there be ways to avoid the exception).

If you are reading UTF-8 characters from a file, you don't get the surrogate encoding by default; by default it raises an exception, which you could handle. But it is a simple matter to request the surrogate encoding, and then you can easily filter the resulting string and look for the surrogate encoding characters. You may disagree with the default behavior in Python 3.x but I don't think you can claim that it is broken or insane.

And! I didn't realize this until now, but Python 3 also allows you to use a "bytes" object to store raw UTF-8. You can convert a Unicode string representing a directory name to bytes (using the str.encode() method function) and then pass the bytes object to os.listdir(), and the resulting list of filenames will be bytes objects with the raw UTF-8. I believe this is exactly what you said you wanted. (So are the Python guys still "incredible morons"?)

http://docs.python.org/3/howto/unicode.html#unicode-filenames

Their problem is that they seem to think that UTF-16 (or perhaps UTF-32) is somehow "decoded" and UTF-8 is "encoded", while in fact it is the opposite, and they seem to be thrashing around trying to hide the fact they got it wrong with this filesystem stuff.

And your problem is that you haven't studied what Python does or why it does it, yet you write long rants about how wrong it is. (See, I can be all judgmental too.)

In Python 3.x, the concept is "all strings are Unicode". This means that from a Python user's point of view, a string is a sequence of Unicode code points, with an associated set of method functions. All else is implementation details. So, if you are reading a file that contains UTF-8, Python must decode the UTF-8 encoded bytes into Unicode and make the string. If you are writing a file that should be encoded as UTF-8, Python must encode the Unicode characters into UTF-8. Despite your claims, Python is completely consistent: converting from any encoding (UTF-8, UTF-16, UTF-32, Latin-1, etc.) to Unicode string is called "decoding" and converting from a string to any encoding is "encoding". See the above-linked Unicode HOWTO document.

You keep saying they "got it wrong" but I actually tested it and it Just Worked for me, so it doesn't look wrong to me.

On Unix at least a filename is a stream of bytes, and changing the "locale" should not change what file it identifies.

If you just use the Python tools for managing files, they will Just Work. If you override the Python tools and tell them to decode with the wrong codec, you will get a bad result. This is a problem because... why, exactly? Would you also say that Python "got it wrong" because if you read a UTF-8 file but tell Python to use the Latin-1 codec it won't work right?

Even on Windows with NTFS a filename is UTF-16, which is not "decoded" in their terminology,

No, really, it is "decoded" in their terminology.

http://farmdev.com/talks/unicode/

If Python just did not complain and passed invalid UTF-8 around, we could stop using other encodings.

You are flaming pretty hard on this issue... but I don't understand why, because as far as I can understand, what you are proposing here is pretty close to what Python actually does.

Python has an encoding error handler called surrogateescape, and uses it by default in all contexts that involve filenames. Thus if you have a filename that contains an illegal character for UTF-8, Python doesn't complain but just uses a surrogate escape for that illegal character; then when the Python string is converted back to a UTF-8 bytes sequence, the surrogate is converted back to the illegal byte.

A nice discussion with a code sample in the PEP: http://www.python.org/dev/peps/pep-0383/

Figure out how to write something in Python that can rename a file with a "bad" filename (ie invalid UTF-8) to have a "good" filename that is valid UTF-8.

import os
os.rename(illegal_name, legal_name)

And that is not just hand-waving; I just did it. I created a file with a name that is illegal UTF-8, and used os.listdir() to get a list of filenames... result: no error and I got the list. I pulled the filename out of that list and passed it to os.rename()... result: no error and it renamed the file.

I'm really confused because you seem to know about this already and yet in this comment you are making these strange claims that Python can't cope with invalid characters in filenames.

What are you saying? Python has ALWAYS supported braces: http://www.python.org/doc/humor/#python-block-delimited-notation-parsing-explained

JS objects [...] actually only map string->object, whereas Lua tables are actual object->object maps

Python dicts also map objects to objects, but objects used as keys need some immutable property from which the key's hash is derived. This is why the immutable tuple and the mutable list coexist in Python, as do the immutable frozenset and the mutable set. I think the designers of JavaScript chose to serialize keys to a string in order to have something guaranteed to be hashable, as opposed to falling back on object identity (analogous to Python id(something) ) as the key.

The documentation is great in general, you seem to have found one missing link in a relatively obscure class. As a whole, Python's docs are great. They generally explain well and give full examples.

Just compare (not, these are not exactly same thing, just pretty close):

• Qt5 QFile
• Java6+ java.nio.channels.FileChannel
• .NET FileStream
• Python 3 io module

Of these, Python's is least clear and useful in my eyes, by quite a margin. YMMV.

A very important feature of any language still seems to be missing: a sane reference documentation.

In a duck-typed language this is even more important, because compiler/IDE can't really help programmer there. Below is a sample from core library docs, links included. To fully appreciate this, there's no link to this "read()" method, and whole BytesIO class documentation does not contain such method, so you're going be manually searching the page to find documentation for read(). Fortunately it is on the same page, which conveniently documents entire module, so it's really easy to quickly find particular piece of information in that wall of text.

read1()

In BytesIO , this is the same as read()

This vulnerability is in a TON of software. Python 2.X (which most people are still using) doesn't even allow you to verify the CN without adding a bunch of code to make it happen yourself. http://bugs.python.org/issue1589 [python.org] Most APIs allow you to do it both ways, but I think it is time that they stop making it optional. If you want to use SSL, use it properly otherwise it isn't worth wasting your time with it.

No, that's a very different vulnerability. What you're talking about would allow any valid certificate for site A to pose as site B, which means that there is almost no security, but if you can determine whose valid cert is being used, you are likely to have at least some idea who was responsible for it. There's at least a partial audit trail, in other words.

This vulnerability, by contrast, is that any self-signed certificate for site A can pose as site A. The common name must match, but everything else can be complete garbage, including the signature on the cert. This means that there is exactly zero security and zero audit trail.

This is the sort of security I'd expect from someone who knew nothing at all about SSL, and who just thought it was a magic box that made things secure.... :-/ Unfortunately, this class of mistake is painfully common, particularly in the mobile app space. Anyone who is considering overriding SSL chain validation really needs to read the following articles:

• Overriding Chain Validation on iOS
• Overriding Chain Validation on Android

Given how many news reports we see about this sort of thing, I think it is clear that Android needs to do a better job of messaging the importance of doing SSL chain validation right. IMO, it's telling that Android's networking training area does not appear to even mention the need for security anywhere, as far as I could tell. In fact, I'm really not finding any big-picture documentation for Android networking at all. It reminds me of learning POSIX networking by reading the UNIX Socket FAQ. And this is why we keep seeing these sorts of news reports. Just saying.

This vulnerability is in a TON of software. Python 2.X (which most people are still using) doesn't even allow you to verify the CN without adding a bunch of code to make it happen yourself. http://bugs.python.org/issue1589 Most APIs allow you to do it both ways, but I think it is time that they stop making it optional. If you want to use SSL, use it properly otherwise it isn't worth wasting your time with it.

Let's see. What did I say?

Although some very clever Ruby runtime implementers have come along to pick up the slack left by the language's founder (who still pretends the global interpreter lock is a virtue, or so I am told)...

In other words, Ruby's scalability concerns come from a designer with so little care for performance as to sell the GIL as a virtue - scarcely any smarter than this Anonymous Coward. :) By now others have written superior Ruby interpreters, in part because of how bad Matz's is. To this exact point, I linked to a blog post, by the author of JRuby, a Ruby environment which incidentally has no GIL, discussing many serious performance challenges which can never be easily addressed, because they are tied to fundamental language design decisions.

The reason we are still discussing the GIL at all - a solved problem for both Python and Ruby if you are willing to switch runtimes from the "default" - is that initially we heard "If you think scaling can only be done with threads..." - which... just listen to yourself, man.

Do I make any specific recommendation the reader use Python? Not only not, but I am actually not even suggesting avoiding Ruby - merely saying, check it out for yourself, and see it not as some mediocre hack's jealously guarded fetish, but objectively, in the context of other languages. I think "you are unlikely to experience much net gain" vs. Perl or Python, but YMMV. On some projects you actually know scale will never be an issue.

Seen objectively, Ruby has many interesting features, but many are present in other languages. It has some serious problems, some of which are tied inherently to these very features (and therefore cut across languages), but others which are unique to Ruby. Python's problems are a whole separate conversation - not just its own distinct performance issues (at least attacked more vigorously, for longer, and by a larger community), but getting bitten by tabs vs. spaces? :)

Alas, the AC will have to work a bit harder to know his tools and follow the conversation. :)

Huh? Here's Python's lambda expressions. And of course, from the fountain of all knowledge, Python has first class functions. Now, that said, it's still not Scheme.

The Python trademark was registered some time ago in the US but it's unclear why the Python Software Foundation didn't do the same in the EU.

Sorry, but you're wrong: it is. Or did you forget where the PYC files come from? You might want to read the official Python documentation on this one http://docs.python.org/3/glossary.html [python.org] . Go to "interpreted" in case you're too lazy to find it yourself. And by the definition we use over at the electronics department Python is an interpreted language no matter what you wish to claim.

You're conflating implementations with languages.

Not every Python implementation even has .pyc files. When I compile a .py file to java bytecodes and then use gcj to generate linkable object code, that's interpreted? And if you consider the use of psyco+CPython to be interpreted, then I'd humbly suggest that the definition you use over at the electronics department is wildly out of touch with what the computer science community means by "interpreted".

Compiled vs. VM vs. interpreted are artifacts of particular implementations, not of the language itself--Aspen has a perfectly fine Fortran interpreter, and EiC and ch have fine C interpreters.

Sorry, but you're wrong: it is. Or did you forget where the PYC files come from? You might want to read the official Python documentation on this one http://docs.python.org/3/glossary.html . Go to "interpreted" in case you're too lazy to find it yourself. And by the definition we use over at the electronics department Python is an interpreted language no matter what you wish to claim.

How's that threading library in Python 2/3 doing? Still not able to actually make more than one thread and has to spawn new processes instead? Python is quite nice, and I welcome the improvements, but it still has a long way to go. Hopefully this a bit of funding will bring that a little closer to reality.

Are you talking about the thread library that has been around since python 1.4 in 1996 using pthreads? Yeah, you are 16 years too late. http://docs.python.org/release/1.4/lib/node72.html#SECTION00840000000000000000

The problem with even considering the use of pthreads is that interestingly enough, processes seem to work better when you are talking about a large number of compute nodes. Most people encounter problems trying to run one multi-threaded process across 100 compute nodes.

Java and C# are not different languages. They are the same language - much more similar than, for example Medley Common Lisp and Franz Allegro Common Lisp, and those are two implementations which both conform to the same published specification. Java and C# have very slightly different syntax, and slightly different core libraries. But if you can read (or write) one you can read (or write) the other. The compilers work in very much the same way, and even the object code and virtual machines are similar.

Which isn't surprising. Microsoft based C# on its own implementation of Java, changing it (only) just enough to get around legal problems with Sun. It's a very sincere flattery. C# is slightly newer, so it has slightly less legacy cruft. Apart from that, you are comparing apples with apples here. If you want a more interesting comparison, compare Java/C# with Ruby, Python, Lua, JavaScript/EcmaScript or Clojure.