Python 3.4 Released 196
New submitter gadfium writes:
"Python 3.4 has been released. It adds new library features, bug fixes, and security improvements. It includes: at standardized implementation of enumeration types, a statistics module, improvements to object finalization, a more secure and interchangeable hash algorithm for strings and binary data, asynchronous I/O support, and an installer for the pip package manager."
Ubuntu Install? (Score:3)
Re: (Score:2)
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 sou
Re:Ubuntu Install? (Score:4, Insightful)
Re: (Score:2)
Applications written in Python (Score:2)
Then why the hell are they downloading python - a programming language???
To run an application written in that programming language. For the same reason that\ downloads Flash Player to run SWFs and Java to run JARs and a web browser to run web applications, one downloads Python to run Python applications.
Re: (Score:2)
cd ~/Downloads
tar -zxvf Python-3.4.0.tgz
cd Python-3.4.0
make
sudo make install
This harmless method will only install python in the directory you built it in. So if you type "python" you will still get the old interpreter. If you type
Re: (Score:2)
Re: (Score:2)
Ubuntu Server is pretty nice actually.
and... (Score:5, Insightful)
And everyone will keep using 2.6/2.7, the windows XP of python.
Re: (Score:2)
Re: (Score:2)
In fairness Python 3 isn't really as widespread as it should be. I think people have found the 2.7 branch just works well for them.
With that said I do wish people WOULD move to python 3. 2.7's unicode handling is infinitely awful and fragile compared to 3.
Re: and... (Score:2)
Paraphrasing other Slashdot posts I have seen, there are no compelling reasons to upgrade to Python 3. Removing the global interpreter lock would be one major reason to, but no one has submitted a good patch for that, and besides, someone would probably just backport it to Python 2.7.
Re: and... (Score:5, Insightful)
There are plenty of good reasons to use Python 3, it is way more elegant and consistent. The way text and binary data is dealt with is incomparably better. I doubt that anyone who ever had done any serious coding in Python 2 escaped from the mindfuckery of mixing unicode and ascii.
The problem for a wider acceptance continues to be the libraries... for instance, Twisted. It is good that there is an async module in the standard library now, but too bad that my code already relies heavily on Twisted.
And about the GIL: if you are complaining about it, you most probably are not using the right language for the job.
Re: (Score:2)
Re: and... (Score:4, Informative)
This exactly.
If your UTF-8 string is not completely valid, Python 3 barfs in useless and unpredictable ways. This is not a problem with Python 2.x.
Until they fix the string so that an arbitrary sequence of bytes can be put into it and pulled out *UNCHANGED* without it throwing an exception then it cannot be used for any serious work. Bonus points if this is actually efficient (ie it is done by storing the bytes with a block copy).
Furthermore it would help if "\xNN" produced raw byte values rather than the UTF-8 encoding of "\u00NN" which I can get by typing (gasp!) "\u00NN".
Re: and... (Score:5, Informative)
This is why there's a bytes type.
If what you have is not text, don't use the text type.
Re: (Score:3)
No, all that means is that EVERYTHING has to be changed to use the bytes type.
I mean every single library function that takes a unicode string, every use of ParseTuple that translates to a string, etc. Pretty much the entire Python library must be rewritten, or a wrapper added around every function that takes a string argument.
Everybody saying that "it's good to catch the error earlier" obviously has ZERO experience programming. Let's see, would it be a good idea if attempting to read a text file failed if
Re: (Score:2)
If it's not UTF-8, why do you claim it's UTF-8?
That's like arguing that XML parsers should allow unclosed tags, because otherwise, they just throw exceptions and can't be used for serious work.
You're probably the guy we have to thank for "tag soup". Asshole.
Interoperating with invalid data (Score:2)
Re: (Score:2)
The program should produce an error AT THE MOMENT IT TRIES TO EXTRACT A Unicode CODE POINT. Not before, and not after.
If the program reds the invalid string from one file and does not check it and writes it to another file, I expect, and REQUIRE, that the invalid byte sequence be written to the new file. It should not be considered any more of a problem than the fact that programs don't fix spelling mistakes when copying strings from one place to another.
Re: (Score:2)
The program should produce an error AT THE MOMENT IT TRIES TO EXTRACT A Unicode CODE POINT. Not before, and not after.
Which leaves open the question of how best to clean up all the tens of thousands of existing records that may not be valid UTF-8. Otherwise: "This product is unavailable for purchase because its description contains invalid data. This problem has been reported to the store owner."
Re: (Score:2)
Well the first thing you need to do to clean up the invalid UTF-8, for instance in filenames, is to detect it.
If reading the filename causes it to immediatly throw an exception and dispose of the filename, I think we have a problem. Right now you cannot do this in Python unless you declare it "bytes" and give up on actually looking at the Unicode in the vast majority of filenames that *are* correct.
It is also necessary to pass the incorrect filename to the rename() function, along with the correction. That
Re: (Score:2)
Hey, I figured out what your problem is, where you went wrong. You think that a string and a bunch of bytes are the same thing. They're not. If you have a bunch of bytes, treat it as a bunch of bytes. If you have a string, treat it as a string.
Java, for example, stores strings internally as UTF-16 (or UCS-2, opinions differ). .NET stores them internally as UCS-2.
This is also why there's a difference between CHAR and NCHAR in databases.
There is not a one-to-one mapping from a given string to a given set of b
Re: (Score:2)
Pretty much every string operation is going to require decoding. Things like substr(), replace(), split(), join(), etc are all going to require decoding the string.
Re: (Score:2)
Aha! Somebody who really does not have a clue.
No, substr() does not require decoding, because offsets can be in code units.
No, replace() does not require decoding, because pattern matching does not require decoding, since UTF-8 is self-synchronizing.
No split() does not require decoding because offsets can be in code units
No, join() does not require decoding (and in fact I cannot think of any reason you would think it does, at least the above have beginning-programmer mistakes/assumptions).
Re: (Score:2)
Stupid software that thinks it has to convert to UTF-16 is about 95% of the problem.
UTF-16 cannot losslessly store invalid UTF-8. It also cannot losslessly store an odd subset of arrangements of Unicode code points (it can't store a low surrogate followed by a high surrogate, because this pattern is reserved to mean a non-BMP code point). It also forces a weird cutoff at 0x10FFFF which a lot of programmers get wrong (either using 0x1FFFF or 0x1FFFFF). UTF-16 is also variable sized and has invalid sequences,
Re: (Score:2)
Maybe you should design your own platform where strings will be represented internally as UTF-8. It would be an interesting exercise.
Re: (Score:2)
Well, yeah, but that would completely change the way these things work. What if your split() worked on code units, and you broke up a code point? That certainly wouldn't produce results that anyone would consider optimal, or even useful.
You can continue to pretend that byte arrays are strings, and strings are byte arrays, but you're not going to get anywhere. The rest of the world decided that we want a useful abstraction over the underlying data structure. When we're working with strings, we care about cha
Re: (Score:2)
The text is 99.9999999% UTF-8.
What I want to do is gracefully handle tiny mistakes in the UTF-8 without having to rewrite every function and every library function it calls to take a "bytes" instead of a "string", and thus completely abandon useful Unicode handling!
Come on, it is blindingly obvious why this is needed, and I cannot figure out why people like you seem to think that physically possible arrangements of bytes will not appear in files. The fact that all serious software cannot use Unicode and has
Re: (Score:2)
There's your problem right there. There are no "tiny mistakes" in UTF-8. Either it's valid UTF-8, or it's not. It's valid XML, or it's not. It's valid JSON, or it's not. It's valid HL7, or it's not. There is no "graceful" handling of invalid data, not in the general case.
Physically possible arrangements of bytes will appear in files, yes, but those files are not necessarily UTF-8.
Oh, and all *my* serious software can handle Unicode just fine (in all its various encodings), because I use a platform that was
Re: (Score:2)
I'm arguing against a design that is the equivalent of saying "you can't run cp on this file because it contains invalid XML".
There is nothing wrong with the xml interpreter throwing an error AT THE MOMENT YOU TRY TO READ DATA FROM THE STRING.
There is a serious problem that just saying "this buffer is XML" causes an immediate crash if you put non-xml into it.
Re: (Score:2)
Re: (Score:2)
God damn you people are stupid.
I am trying to PREVENT denial of service bugs. If a program throws an unexpected exception on a byte sequence that it is doing nothing with except reading into a buffer, then it is a denial of service. If you really thing that invalid UTF-8 can lead to an exploit you seem to completely misunderstand how things work. All decoders throw errors when they decode UTF-8, including for overlong sequences and ll other such bugs. So any code looking at the unicode code points will stil
Re: and... (Score:5, Informative)
The inconsistencies are fully within Python 2. My experience is closer to full-scale horror when having to consider different encodings in Python 2, and since I am from a country that actually needs these "bells and whistles" regarding encoding for regular I/O on a regular basis, I have met these issues many times. Using chains of codecs to read and write files, having to intercept exceptions and .encode() .decode() in differing combinations to be able to avoid Python 2 "double-crashing" when reporting an exception, deep level hacking to reinitialize sys.stdout before output on certain machines, etc.
In Python 3, it does not "just work", but that is because character encoding is never a "just works" problem, and languages that say it is fail miserably in this regard as soon as it meets real world international encodings. Python 3 defines the problem correctly, and solves it natively in the best way I can imagine, by always being aware of the problem. No more prepending the u qualifier to every single string that might or might not be output (or combined with any other string that might or might not be output). Python 3 solves it correctly, by acknowledging character encoding as something that is actually an issue, and it does not make the silly assumption that ASCII is the way of the world. This assumption has been silly for at least 40 years, but many products were developed in ASCII centric regions, or at least in regions where you seldom saw more than one encoding, and never fully addressed the problem.
The Python 3 standard library does strings right , and should get credit for it. Instead it gets flac from programmers who do not like that it does not inherit the quirks from Python 2 that we have become accustomed to (and are still miles better than in many other languages; PHP and unicode, anyone?).
Heck, the number one reason that I have converted as many projects as I can to Python 3 is because of the blocks of encoding centered Python 2 code I can just throw out the window, and ease future maintenance. There are still some big module holdouts, but that was a much larger problem in ~2010. Today, the ones I miss in Python 3 are e.g. WXPython (where work is ongoing in the Phoenix project) and MySQLdb (the MySQL connection alternatives for Python 3 are outright silly -- either non-functional or non-documented).
There are several introductory programming courses I know of that focuses on Python, and they all use Python 3 by default. I am sincerely looking forward to the day when Python 3 is the natural order.
It takes a lot of motivation to change language structures from Python 2, and those working on the drafts are certainly top-class in their fields, so if one finds any design changes weird, the first instinct should be to read up on the rationales for the decisions. I have yet to encounter a change that seems "silly" or unnecessary after reading about the process.
Also, for the early adopters, not that Python 3.3 (och 3.4, as this article is about) is not 3.0 or 3.1. There is a lot of things that have been fixed along the way.
Re: (Score:2)
What's wrong with simply presenting everything with Unicode? It might not be the most efficient possible way of representing text, but that's unlikely to matter much, given that you're using Python.
Re: (Score:2)
Re: and... (Score:4, Insightful)
> Unless you're a framework author, chances are you'll have to care very little about mucking with bytes.
Right, because none of us write code that interacts with other code or systems that use bytes.
Like C libraries.
Or binary files.
Or network protocols.
Re: (Score:3)
Support on shared web hosts (Score:2)
There are plenty of languages that are equally expressive while still being far faster and more efficient.
And available on entry-level web hosting? The only language I know of that's more widely supported on shared hosting is one that's been called a fractal of bad design [veekun.com].
Re: (Score:2)
I'm legitimately curious, what are some that come to mind?
IronPython? :-)
Re: (Score:2)
BASIC!!
Just kidding
Re: (Score:2)
Chinese or Hindi (Score:2)
various internal applications and systems not needing to support more than one language
If a program supports just one language, and that one language is either standard written Chinese or Hindi, then how should it work with even one language without Unicode?
Religeous arguments abound (Score:5, Interesting)
Now module after module is going 3.x but the other problem is that for most people having two pythons on their machine is a pain in the ass. I know there are tools to make this less painful but I can tell you an easy way to make it painless, Don't have two versions.
Then there is this call that you should begin new projects in 3.x; but the problem again is the two versions issue.
What bothers me about all this is that I come from a C++ / PHP world. With C++ I have upgraded countless times over many years and had close to zero problems with my code. I don't even know which compiler XCode is even using right now. With PHP my various upgrades have broken exactly one module and I hear rumours that the next big version of PHP will break one module in my older code. But I don't care as I am replacing my PHP with Python.
Where I am worried is that the core Python people will do something stupid like announce an end of support date for 2.7. The problem there is that it might be easier for some people to install a whole different language to sit alongside Python 2.7 and start playing with that instead of smashing their machine in the teeth and simultaneously installing 3.x.
Re: (Score:2)
Python is 4 years older than Java, PHP and Ruby.
Re: (Score:2)
Technically this is true. However the Python that you know and love is actually younger than the three languages you mentioned. Let me explain:
Python 2.0 was released on October 2000. This is where it gain features that actually made it useful outside of the Ameoba OS. Prior to this release, the other languages were already making themselves useful on more mainstream OS like:
Ruby 1.0 which was released on December 1996 (It implemented most of the features
Re: (Score:2)
In a way I see Python prior to 8 years ago as a language before its time. On a computer before that it was just too damn slow. But now with regular desktop computers pushing into the Teraflop range the speed of the computer will usually make up for any speed problems with Python. So development time is the only speed that most should worry about. Then if something does need optimization you c
Re: (Score:2)
Parallel 2/3 didn't work in Windows until 3.3 (Score:2)
Most Linux distributions are shipping 2.x and 3x in parallel and have been doing so for years without issues.
That's fine if your audience is willing to install Linux, either as a dual boot or in a VM. It took until Python 3.3 before Windows could practically run 2.x and 3.x in parallel.
Re: (Score:2)
OK, it took until 3.3 before this was straighforward in Windows. Why is that still relevant today? Python 3.0 came out at the end of 2008, and several parts of the 2.X transition were still pretty rough then. A poster above made a nice comment about how that's played out: "Python 3.3 (or 3.4, as this article is about) is not 3.0 or 3.1. There is a lot of things that have been fixed along the way." Having an upgrade path that's possible to follow smoothly has been a design goal of 3.0 since its early da
Re: (Score:2)
Re: (Score:2)
Yes, but that unofficial page really does have almost everything on it :)
Re: (Score:2)
The problem is that 2.7's unicode is a hack that doesn't play nice with legacy code or 2to3. If you have any legacy code or third party library that expects string to behave like a bytes object, 2to3 will turn them into incompatible unicode strings. If you import unicode_strings from __future__, you get a monkeypatched string class which will cause problems with the existing 2.x code that expects string to behave like a bytes object.
The biggest barrier to the Python 3 transition has been the lack of support
Re: (Score:3)
There are very few reasons to stick with the old model. Sure, it takes a bit to get used to some of the changes, but it is not that hard. And most good libraries have already moved over or are compatible with both.
Re: (Score:2)
Re: (Score:2)
I take issue with your "musts". The way I see it, if I want a real answer to x/y I use x/y. If I want some special meaning of / (like integer division or rounded answers or blah blah), I use //. That is good design.
The type of the result (Score:2)
If a, b and c can be int or float, how can a programmer implement "a = b divide c" without a lot of ugly type checking?
By determining what type you want in the result and choosing the operator that produces that type. And you can get Python 3 division behavior in Python 2.6 or 2.7 using from __future__ import division.
Re: (Score:2)
But that's the point, sometimes the programmer implementing "a = b div c" does not know whether the result "a" is int or float because he's writing a general library function where depending on the application "a" may be int or it be float. In python 2, he does not have to know and write "a = b / c". But that won't work in Python 3 without a lot of ugly type checking.
From reading the PEP for the "// oper
The use case for a variable result type (Score:2)
sometimes the programmer implementing "a = b div c" does not know whether the result "a" is int or float because he's writing a general library function
If the output of the general library function shall be a float, then use /. If the output of the general library function shall be an integer, then use //. If the output of the general function shall depend on the types of the arguments, then I'm having trouble understanding in what sort of case this would prove useful.
where depending on the application "a" may be int or it be float.
On what aspect of the application would it depend? As far as I can tell, whether a should be int or float depends on what kind of quantity b is intended to represent and what kind of quantity
Re: (Score:2)
Let's take this example: Write a function that computes the average of a list (or sequence, generally speaking) of numbers. The list may contain elements that are all either integers, floats or complex numbers. The result should have the same type as an individual element of the list
average([10, 11]) (Score:2)
def average(seq): return sum(seq) / len(seq)
Or in Python 3.4 or later: from statistics import mean as average
Can you implement a simple average() function in Python 3 that satisfies the specifications mentioned above?
I'm not clear what average([-10, -11]) should return under your specification. Or would it raise a ValueError? In general, the average of integers is not an integer but a rational, because integers are not closed [wikipedia.org] under mean. Mean would have to promote to a type capable of representing (or at least approximating) rationals. Python has no built-in exact rational type, but it does have float.
Re: (Score:2)
I don't have 3.4, but it would be better if you could implement average using just the sum() function just so you can experience the split personality of the division operators in python 3.
As mentioned in the spec, int list should return an int. There's no confusion and no rationals because most computer programs either deal with integers or floating point numbers
average([10, 12.0]) (Score:2)
As mentioned in the spec, int list should return an int.
Please clarify the spec further: If the list contains an int and a float (such as average([10, 12.0])), should the result be returning a float or raising a ValueError? I admit that my process of requirements elicitation [wikipedia.org] sounds like I'm asking a lot of nitpicky questions, but it's necessary to avoid an underspecified function. "What Python used to do prior to the addition of true division in 2.2" is still underspecified if the function is ported to any language other than Python.
So your function should return func([-10,-11]) --> (-10-11)/2 = -11 under the rules of integer division.
Until now you have left "the
Re: (Score:2)
No need to care about mixed types. But if you want to be that specific:
a) if all elements are ints, result should be an int
b) if any element is a float, result should be a float
c) if any element is complex, result should be complex.
Rule (c) has higher priority over (b), which has higher priority over (a).
average([2000000000]*4) (Score:2)
Re: (Score:2)
In the real world, 5 / 2 == 2.5. This is true whether the operands are integers or floats.
In some discrete math systems, 5 / 2 == 2.
A language has no way to really know what kind of problem you are working on and which calculation would be more appropriate. Python 2 made the assumption that if you fed in two integers, then you were working in a discrete math system. This turns out to not usually be the case, and was a source of surprise and bugs for many people. (Python 2's division was modeled after C, whi
Re: (Score:2)
Personally, if I have to divide up five children between two parents, I don't consider 2.5 to be an acceptable answer.
Acceptable to you or not, that's how it would be done physically.
Your acceptable solution involves a discrete math system. That's fine, but the safety of those children still shouldn't magically depend on whether you allocated them as Python ints or floats.
Re: (Score:2)
You've decided for yourself that integer division must return an integer result even though it isn't always mathematically correct. You don't have to use truncating division unless you need it. On the other hand, unexpected truncation can cause a wide assortment of problems. If you want guaranteed integer division use //. It's been there since 2.2.
The Python 3 division system is more consistent because you always get the correct result and have the choice to throw away precision when it is unwanted. The tru
Re: (Score:3)
Adding new features to a language has always been a rather controversial idea, with many feeling that languages themselves should remain limited and stable with libraries being the place new features should be added.
Ob (Score:5, Funny)
Have they fixed the whitespace bug yet?
Re:And it still has the GIL (Score:5, Insightful)
You make it sound as if it were no big deal to remove the GIL. It has been tried, and Python got 2x slower, so that attempt was abandoned. Python 3.2 gained a different implementation of the GIL, and that fixed some problems, but other problems still occur.
The GIL is Python's hardest problem.
https://www.jeffknupp.com/blog/2012/03/31/pythons-hardest-problem/ [jeffknupp.com]
https://www.jeffknupp.com/blog/2013/06/30/pythons-hardest-problem-revisited/ [jeffknupp.com]
As noted in the above referenced blog, you can use Jython or IronPython to avoid the GIL; PyPy will be using Software Transactional Memory to avoid the GIL; and you can use the multiprocessing module to use multiple cores without GIL problems. You do have options other than just using CPython.
If removing the GIL was as easy as you seem to think, it would be gone now, at least in a fork of CPython. Yet still it remains.
Re: (Score:2)
If you call C code from python the GIL is released so it can run in parallel in normal python threads. Many of the libraries and most of the core of the language are written in C. How much parallelism that nets you depends on your application, but simply using python threads does provide some parallelism.
Not all C libraries release the GIL (Score:2)
If you call C code from python the GIL is released
Only if the library explicitly releases the GIL. Pillow (Python Imaging Library), for one, happens not to [stackoverflow.com].
Re: (Score:2)
I was not aware the library needed to explicitly release the GIL. I thought that any C call would release the GIL.
Re: (Score:2)
Any C library can touch Python objects any time it likes, by nature of being linked to the Python C-API. However, you can only safely access Python objects while holding the GIL. CPython libraries are entered into with the GIL held (otherwise you couldn't even interact with the arguments given to the function), and they may decide to release the GIL some time later (and promise not to touch the Python API while the GIL is not held).
*Many* CPython release the GIL during operations that may be long-running, s
Re: (Score:2)
You actually have two complaints, not really related.
One complaint is the GIL. As I understand it, the GIL is mainly needed because the CPython reference counting model needs to touch a whole bunch of reference counts when churning objects, and this needs to not screw up. Thus Jython and IronPython, leveraging the garbage collection of their respective underlying VM platforms, didn't need a GIL.
The other complaint is that the language is too dynamic. That's just part of the design of the language. I can
Re: (Score:2)
Yeah, it would be nice if there was some way of *voluntary* declaring the type of a variable - i.e. state that this variable wil ONLY accept an Integer etc. - and that trying to store something else in the variable would raise a TypeError. Same goes for function arguments.
That could lead to
(1) safer code where the mistake is caugth earlier and at the point where the data is stored as the unexpected type, not when you in a completely different piece of code do some operation on it which expects it to be a di
Reference counting and unmanaged resources (Score:2)
As I understand it, the GIL is mainly needed because the CPython reference counting model needs to touch a whole bunch of reference counts when churning objects, and this needs to not screw up. Thus Jython and IronPython, leveraging the garbage collection of their respective underlying VM platforms, didn't need a GIL.
But these implementations pay a penalty for relying on the VM's tracing garbage collection, and this penalty is loss of finalizer functionality.
Memory managed by the VM isn't the only resource that a program uses, but it's the only resource that some garbage collectors anticipate. Other resources include open files, open network connections, open database connections, and the like. One common design pattern for ensuring that unmanaged resources get released is try/finally, which works with JVM, CLR, and
Re:Reference counting and unmanaged resources (Score:4, Insightful)
these implementations pay a penalty for relying on the VM's tracing garbage collection, and this penalty is loss of finalizer functionality.
And this is why it is best practice in Python to use the with statement, to make sure that things get cleaned up when you are done with them.
In CPython you can get away with just dropping your objects on the floor, and the reference counting will clean them up for you. In other implementations, not so much.
This works okay in CPython:
def read_data(fname):
f = open(fname)
return f.read()
In CPython, with no references to f it gets cleaned up, and the open file gets closed.
In any version of Python, this works great:
def read_data(fname):
with open(fname) as f:
return f.read()
The with statement ensures that the open file will be closed, no matter how the function is exited (including by exception).
And I actually prefer the with statement these days... I like how it makes the lifetime explicit for the stuff it wraps.
Raymond Hettinger has expressed the opinion that the with statement is one of the really best ideas in Python. I think that was during his PyCon session where he listed his favorite things in Python.
with, try/finally, and long-lived resources (Score:2)
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 [python.org]) 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
Deallocating resources when the caller breaks (Score:2)
If you are writing an object designed to work with with, you do the cleanup in its __exit__() method function.
So how does the object ensure that every other object that owns it wraps its allocation with with?
sugar can be sweet. I think it's an improvement
I agree with you that with is a syntactic improvement. I was arguing about program semantics that make with necessary, especially when object lifetimes don't correspond directly to program blocks.
You would close the file inside __next__() when you hit end-of-file and right before you raise the StopIteration exception. Am I overlooking something?
You are overlooking the case in which the caller stops using the iterator before the iterator completes, such as a for loop that hits a break statement or an exception not caught within the loop.
Re: (Score:2)
Re: (Score:2)
actual language speed = the time it takes the program to run + the time it takes the program to be written.
Sure Python might be 100x or more slower than C, but the total time is usually faster. For people that need speed, they should check out Julia [julialang.org]. It's a scripting language designed mainly for technical computing (although it is perfectly general-purpose) that is fast due to good type inference and JIT. Usually within 2x of C. It also can call Python libraries as easily as within Python.
There is something called multi-process you know (Score:4, Interesting)
And python has supported it (at least on unix) virtually since it was first released.
I've never really seen much virtue in multi threading - its useful in a limited number of cases but usually it creates more problems than it solves (compared to multi process) and is usually used by people who don't really know what they're doing. Essentially multi threading takes all the advantages of protected process virtual memory and throws them in the bin.
Re: (Score:2)
"Of course I know about multiprocessing. Why have one copy of the interpreter and libraries loaded when you can have N, plus its so much more efficient to marshal data across process boundaries than to access a global shared memory block. "
*snort* You obviously don't have a clue about multiprocess. Look up copy-on-write then get back to me.
As for a shared memory block , uuuh , guess what , theres something called "shared memory" specificially for multiprocess access. Its been around since the 70s in unix bu
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
Which isn't a bad thing. Perl, Python, and Ruby do not run natively within a CPU. Both Python and Ruby settled on a GIL so that the interpreter could have multiple threads of execution. Perl decided that it would be faster to just give each thread its own interpreter and they were right. You can also do cool things like detach long lived threads and whatever.
You can still fork in Python, Perl, and Ruby and give each process its own independent address spa
Re: (Score:3)
import multiprocessing (Score:2)
Perl clones the entire interpreter for every thread.
So does Python if you import multiprocessing. But then you run into other problems, such as it being hard to send objects back and forth between processes unless they're small and simple.
In a pickle (Score:2)
Another problem is that anything sent through a connection between processes has to be picklable with a bytes representation smaller than about 32 MB, so no passing big images around. Does this cause an actual problem in practice?
Re: (Score:3, Insightful)
it shouldn't have been a surprise that it would spell doom for Python to fork it into two incompatible branches for a couple of "it would be nice" type features.
No.
The Python community, overall, approves of Python 3.x. The major breakages have to do with Unicode, but that's because Python 3.x does it right and Python 2.x didn't.
If you don't think Unicode matters, my guess is you are an English-speaking American. Others disagree.
There are efforts underway to port the major Python projects to support 3.x.
Re: (Score:2)
Re: (Score:2)
Optimize for the hardware you have (Score:2)
There's the old parable about two programmers that are told to double the speed of their program. One guy spends a month rewriting the core in assembly and using hardware acceleration. The other guy waits 6 months and buys a new computer.
The second guy failed because the deadline was in three months. Or the second guy failed because other customers running the program on their own computers weren't likewise willing to buy a new computer just to run one program.
Re: (Score:2)
New computers are not 'multithreaded', they just have more cores, which Python is more then capable of taking advantage of. The GIL causes problems for one specific threading technique, and that technique is essentially the GOTO of threading. It can speed up development, but it was probably never a good idea outside some very specific use cases.
Hyper-Threading Technology (Score:2)
New computers are not 'multithreaded'
Tell that to the single-core yet simultaneous-multithreaded [wikipedia.org] Atom N450 in my laptop, which injects the second thread's instructions into the first thread's pipeline bubbles and vice versa.
Re: (Score:2)
Re: (Score:2)
VPS (Score:2)