Troll Tech can say anything that they like. But their permission to let you write GPLed software doesn't make it legal to distribute said software along with QT.
Go read the description of the conflict for yourself.
You are absolutely right that reverse DNS will fail miserably. That is intended. The resource use would also be very large. Which gives them the opportunity to bring home to the court exactly what they mean when they say that blocking selectively for French users, "is not technically feasible."
IOW Yahoo can go out of the way to block all of France from the auction site, come up with some publicity, French people will still have no trouble reaching them, and they can then talk about how much they are spending and how ineffective it is.
People theoretically see the need for lots of nice protections. Then they go ahead and cut corners unless someone has been burned and the memory is fresh.
I cannot think of any area of technology from automobile design to nuclear power plants to office suites where this principle of human nature has not been operational. I can personally list examples from NASA to genetics research to the SNMP spec. (It was nicknamed Security - Not My Problem for a reason!)
IMNSHO anyone who thinks that nano has the potential to be any different is just kidding themselves about human nature...
Blocked all *.fr addresses, directing them to a page saying something like Nos excuses. Ces pages sont actuel bloquées des utilisateurs français pour nous introduire dans la conformité à une décision récente de cour.
Then they could honestly tell the French court that they were making a sincere attempt to comply with the ruling...
Hmm...perhaps they should also include contact information for the case, and a link to an explanation of what their position was.
The comments on how to have different platforms be binary compatible are interesting in their own right. What I find interesting is how the same idea in a different form is implicit in what Torvalds writes. For instance read his essay on the kernel from Open Sources carefully. Here is a more technical explanation. In both cases you abstract out from the architecture, OS, library, whatever the interface you want to program to, and then (with appropriate macros etc) set up that interface. Then when you go to port it, you merely need to figure out how to set up all of your macros and the bulk of the code remains untouched.
Look at that sideways. That is *exactly* what IBM did to make code binary portable. That is the principle that the AS400 uses. If you peek in well-known and widely ported projects (eg Perl) you will often find that they take the same approach. (For good reason!)
The key to wisdom lies in seeing how good ideas about foo look like good ideas about bar and then trying to apply that. There is a good lesson here about portability...
It really is a nice construct though. I am a big fan of anonymous functions. For instance you need to emit errors from a module that will be used various places for various things. Have a package variable with an error sub, by default "croak" but overrideable. That is fine for development and interactive scripts. Now if someone wants to use that in a cron, they can replace your croaks with a routine to page someone before dying...
Sad. But he and Tom C had one too many flamewars and he has left.
Incidentally Perl has a standard. It is the documentation. The cause of said flamewars is that Tom considers the documentation a standard and Ilya constantly wanted to play around with new features, add new constructs, etc.
Cheers, Ben
PS Trivia. If $a is an anonymous subroutine then $a->(@args) calls the subroutine with those arguments. This is very useful because $handler{$foo}->($bar) is far cleaner and more understandable than &{$handler{$foo}}($bar). OTOH I am amused that such a nice feature got included in Perl on a bar bet...
First of all I would like to point out that the underlying cause of this is that Linux is moving towards having two security models. One is the traditional, "Root is GOD but can setuid" model and the other is "POSIX capabilities". This is a situation where an operation that should have worked under the old but which due to an oversight was insecure on the new. This may not be the last thinko of this sort. OTOH POSIX capabilities are an improvement on the old model so this is good in the long run.
Now why am I saying POSIX capabilities? Well here is a FAQ that goes into what is in the kernel. The traditional definition of capabilities are used by, for instance, EROS. This is incredibly secure. So when the POSIX standard was being developed for improving security by borrowing VMS' "privileges" they deliberately called them "capabilities" to introduce confusion and make people think they were better than they are. (Not that they are not an improvement on the old...)
Now the good sendmail folks have at this point every reason to believe that this particular thinko is likely not limited to Linux. Hence their check which they would hope will catch other current examples, and future ones if other people mess up. If they didn't do something like this then their (already pretty bad) reputation for security would get worse as they are an obvious target for taking advantage of setuid bugs.
I am a voting adult. I think that this is a great idea!
Make something remotely like the above available as a petition and I will cheerfully sign it. A donation is not out of the question. My vote in the next federal election is already spoken for as long as it looks like Bush is likely to let Microsoft off the hook and Gore is neutral. (Heck, that could be seen as the best way I can see to vote for the above.)
But leave it at an article here and nothing significant will happen. Nor do I have the time or energy to do any significant organizing.
I went through and methodically used my instead of local, foreach loops instead of for, stopped changing the array base, stopped worrying about whether you had numbers or strings, used the list oriented nature of the language a little, and got decent speed increases across the board.
The biggest benefit being the incr_loop test:
$n = shift || 50000;
foreach (1..$n) { ++$sum; } print "$sum\n";
I sent my modified version to the author along with pointers to what and why the style changes were made. (Every last one has maintainability as its primary goal. The speed increase comes because more maintainable code pushes more work checking boundary conditions etc down to Perl, which is both less likely to mess up and is faster than your code written in Perl.)
On a 32-bit system you cannot have pointers into an arbitrary location in, say, 8 GB of data.
Depending on your needs this may not be an issue. Certainly the people hitting the RAM barrier today are mainly database people who find the support for 64 GB quite nice. But that won't work for many other types of applications, and this is why Intel is biting the bullet and preparing for the end of the x86 world.
I said directly that moving to a 64-bit processor does not solve the 2038 problem because the C standard defines time as a long and a long as 32 bits. Breaking either breaks working programs. Here is an idea of what needs to happen.
As for large amounts of data, yes I have had to worry about the 2 GB limit on production systems. I have in the past gone to contortions to break up files so that they would avoid that limit. I am perfectly aware of the issues, and your glib claim that you would just fix the issue with any code you used is utter idiocy from someone who clearly doesn't understand the issues.
For instance large file support in Perl (and hence any program written in Perl) is a new feature that you can choose to compile perl 5.6.0 with. (If you choose to install on a production system, install the latest patches as well. I am serious about this.) Giving Perl that support took a fair amount of work. (Hint, you need to make sure it never tries to seek when it can't...) If you have any older version of Perl, I really recommend that you open a pipe to or from from a program (eg cat) that understood 64-bit files. Guess why I know this?
As for development vs production kernels, it depends what you are doing. For most production purposes, most people should not be using development kernels. If you have any brains you don't use.0 releases either, you let the distributers hit the main bugs first.
As for ReiserFS, it supports files larger than 2 GB. Whoop-te-do. So does Ext 2. Has for years. That doesn't mean that on a 32-bit system you can actually address the bit on the end...
If you don't know the difference between a development and a production kernel then you shouldn't be anywhere near any production system.
Come to think of it, you probably aren't.
Anyways, someone asked a direct question about whether a problem was fixed. I explained that that was in theory only. In practice more needs to be done and the fixes in Linux should not be used in production.
I also made the rather important point that just because the OS understands what a 3 GB file doesn't mean all of your programs will understand it.
So the fix still has gotchas, and the Linux version is not ready for production.
If you want to try it on a boot partition, don't try to use LILO, use GRUB. If you have a complicated booting situation, you probably should be using GRUB anyways...
I won't use it until it is 2.4.6 or so. I have no need to.
There will be production Linux systems for years with a 2 GB file-size limit.
And it will probably take longer than that for all of the utilities that can only seek within a 2 GB file to figure out how to properly handle a large file...
Oh, don't forget. On 32-bit architectures you cannot have a process that can address more than 2 GB of data. (Yes, you can have more data than that - but AFAIK it has to be mmapped files kept as anonymous pages. Your *process* runs into addressing limitations because of the length of a pointer.)
This will take some time to sort out. Longer than you think - longs are remaining 32 bit on most systems for backwards compatibility reasons. Time is defined to be a long. That won't work forever...(No. Just using a 64 bit machine does not solve the problem.)
First of all when I say "basic programming notion" I mean in general. Not for one language or another, but rather a notion that will come up in many languages.
It doesn't happen in C. It does in JavaScript. It doesn't in Java. It does in Smalltalk. It doesn't in Python. It does in Perl. It doesn't in VB. It does in Lisp.
Perl is specifically designed to allow "baby-talk". This is considered a feature. So you can program in Perl without knowing what a closure is. But if you don't know what a closure is, you won't know what lexical scope is. If you don't understand the difference between lexical and dynamic scope then you won't understand what the different between my and local is. If you don't understand that difference then you won't understand why Perl gurus keep on telling people to use my instead of local, and why use strict encourages people very strongly to do that. And if you don't understand that, then you will suffer needless pain from time to time.
As for what/. is, yes it is a forum with many people of different backgrounds. Like it or not, sometimes someone will have a point to make and that point will make no sense to people who do not understand a lot of concepts like "closure", "lexical scope", and "functional programming". There are lots of people who understand all that, and lots who do not. So I specifically said that my comment was one that would only make sense to people who had been exposed to functional programming.
First I think that few people who didn't already know what closures are could make heads or tails of your description. Certainly the concept of having multiple functions out there returned from the same one, each with independent data takes getting used to. The related idea of having multiple functions, each sharing specified data while not sharing other data is even more complex.
As for OO vs closures - that is really a question of philosophy. An OO philosophy encourages a particular structure on your code where all of your configuration information winds up scattered across your various class definitions. But in real life often you want to have some of that per class configuration information hidden away, but you would like to centralize other parts of it.
For instance when you are dealing with reports, the per field definition of where that field is coming from, what data validity checks you have on it, etc is all stuff that really should be centralized. OTOH per field information about how its display should be formatted, what column headings to use, etc is stuff that you want to centralize, periodically reorganize, etc.
I personally find that a functional approach lends itself more naturally for me to choosing to centralize display information into a single nested data structure. Yes, there are OO patterns to do the same thing. They look very ugly to me. For me having that choice is a win. But explaining that is more than a question about length of code. It is a philosophical comment
I have a friend who migrated from Perl to Python back when Python was able to treat regular expressions as first class objects and Perl did not. (It does now.) He commented to me a while ago that Python people claimed that anything you could do with closures you could do just as well without them in Python. He doesn't quite agree. Here are his thoughts.
If a programmer wants to fully exploit the available CPU power of multiple processors, then indeed they have to put in extra work. This is not necessarily a big deal. If you are already forking processes, then you have already done that work. Likewise if you are running a server that runs multiple processes in parallel (eg Apache), then the work has been done for you.
And, of course, for many things the end user doesn't care that the program is an efficient hog of multiple CPUs. If I background one process and turn to doing other things, I have already won if the backgrounded process has a minimal impact on my observed performance.
For all of these reasons people find wins running dual-processor systems even though they are mostly running programs whose programmers were not explicitly writing programs that take advantage of multiple processors.
Seriously, closures are a very specific notion. If you have not seen them it will take you a while to understand what they are, and longer to see why people want them.
Why not start with some documenta tion? I have neither the ability nor the desire to fully explain an entire philosophy of programming in a brief post. Go and read a FAQ if you want to start down that path.
If this seems needlessly arrogant, ask yourself a question. If you wanted to make a comment on the calculus in a forum where some are mathematicians and some are high-school students, would you feel it sufficient to mention that your comment only will make sense to people who understand calculus? This situation is exactly parallel to that.
Today CPUs spend a lot of energy trying to extract parallelism out of code designed to be run linearly. The ability to take advantage of parallelism is strongly limited by your ability to find it, rather than the ability of the chip to carry out instructions in parallel.
Well if the chip is emulating a dual processor machine, then you have pushed a lot of that work down to having the OS identify 2 processes that can run in parallel. I would think that this would be a huge win.
Make a "dust particle" the size of the Moon, stick it in deep space, and you have a lot of mass for your visible cross-section.
Nobody really knows how much of that stuff is out there. We know something is there that we don't see from the gravity puts out, but that doesn't mean it has to be something truly exotic.:-)
The major problems that happen with multi-threading are largely due to the potential for unexpected interactions. If it is easy to show that there are no undocumented side-effects of a given piece of code, then it is far easier for an optimizer to move around when and where it is executed.
If there are potential side-effects then it can't do that unless it can prove that the side-effects in point A don't have any interaction (intended or unintended) with side-effects in point B.
Please do not confuse conciseness with lack of information. Python does not support a basic programming notion that Perl does, one which is key for a well-known and powerful style of programming. That is a significant difference.
Slashdot Mirror
Troll Tech can say anything that they like. But their permission to let you write GPLed software doesn't make it legal to distribute said software along with QT.
Go read the description of the conflict for yourself.
Regards,
Ben
You are absolutely right that reverse DNS will fail miserably. That is intended. The resource use would also be very large. Which gives them the opportunity to bring home to the court exactly what they mean when they say that blocking selectively for French users, "is not technically feasible."
IOW Yahoo can go out of the way to block all of France from the auction site, come up with some publicity, French people will still have no trouble reaching them, and they can then talk about how much they are spending and how ineffective it is.
Cheers,
Ben
People theoretically see the need for lots of nice protections. Then they go ahead and cut corners unless someone has been burned and the memory is fresh.
I cannot think of any area of technology from automobile design to nuclear power plants to office suites where this principle of human nature has not been operational. I can personally list examples from NASA to genetics research to the SNMP spec. (It was nicknamed Security - Not My Problem for a reason!)
IMNSHO anyone who thinks that nano has the potential to be any different is just kidding themselves about human nature...
Cheers,
Ben
Blocked all *.fr addresses, directing them to a page saying something like Nos excuses. Ces pages sont actuel bloquées des utilisateurs français pour nous introduire dans la conformité à une décision récente de cour.
Then they could honestly tell the French court that they were making a sincere attempt to comply with the ruling...
Hmm...perhaps they should also include contact information for the case, and a link to an explanation of what their position was.
Cheers,
Ben
The comments on how to have different platforms be binary compatible are interesting in their own right. What I find interesting is how the same idea in a different form is implicit in what Torvalds writes. For instance read his essay on the kernel from Open Sources carefully. Here is a more technical explanation. In both cases you abstract out from the architecture, OS, library, whatever the interface you want to program to, and then (with appropriate macros etc) set up that interface. Then when you go to port it, you merely need to figure out how to set up all of your macros and the bulk of the code remains untouched.
Look at that sideways. That is *exactly* what IBM did to make code binary portable. That is the principle that the AS400 uses. If you peek in well-known and widely ported projects (eg Perl) you will often find that they take the same approach. (For good reason!)
The key to wisdom lies in seeing how good ideas about foo look like good ideas about bar and then trying to apply that. There is a good lesson here about portability...
Cheers,
Ben
Right here.
It really is a nice construct though. I am a big fan of anonymous functions. For instance you need to emit errors from a module that will be used various places for various things. Have a package variable with an error sub, by default "croak" but overrideable. That is fine for development and interactive scripts. Now if someone wants to use that in a cron, they can replace your croaks with a routine to page someone before dying...
Cheers,
Ben
His parting message.
Sad. But he and Tom C had one too many flamewars and he has left.
Incidentally Perl has a standard. It is the documentation. The cause of said flamewars is that Tom considers the documentation a standard and Ilya constantly wanted to play around with new features, add new constructs, etc.
Cheers,
Ben
PS Trivia. If $a is an anonymous subroutine then $a->(@args) calls the subroutine with those arguments. This is very useful because $handler{$foo}->($bar) is far cleaner and more understandable than &{$handler{$foo}}($bar). OTOH I am amused that such a nice feature got included in Perl on a bar bet...
First of all I would like to point out that the underlying cause of this is that Linux is moving towards having two security models. One is the traditional, "Root is GOD but can setuid" model and the other is "POSIX capabilities". This is a situation where an operation that should have worked under the old but which due to an oversight was insecure on the new. This may not be the last thinko of this sort. OTOH POSIX capabilities are an improvement on the old model so this is good in the long run.
Now why am I saying POSIX capabilities? Well here is a FAQ that goes into what is in the kernel. The traditional definition of capabilities are used by, for instance, EROS. This is incredibly secure. So when the POSIX standard was being developed for improving security by borrowing VMS' "privileges" they deliberately called them "capabilities" to introduce confusion and make people think they were better than they are. (Not that they are not an improvement on the old...)
Now the good sendmail folks have at this point every reason to believe that this particular thinko is likely not limited to Linux. Hence their check which they would hope will catch other current examples, and future ones if other people mess up. If they didn't do something like this then their (already pretty bad) reputation for security would get worse as they are an obvious target for taking advantage of setuid bugs.
Cheers,
Ben
I am a voting adult. I think that this is a great idea!
Make something remotely like the above available as a petition and I will cheerfully sign it. A donation is not out of the question. My vote in the next federal election is already spoken for as long as it looks like Bush is likely to let Microsoft off the hook and Gore is neutral. (Heck, that could be seen as the best way I can see to vote for the above.)
But leave it at an article here and nothing significant will happen. Nor do I have the time or energy to do any significant organizing.
I doubt I am alone...
Cheers,
Ben
I just timed and got a better improvement on the string test:
$s = "abcdefghij";
$n = shift || 50000;
foreach (1..$n) {
push @X, $s ;
}
foreach my $str (@X) {
push @Y, $str . " ";
}
I went through and methodically used my instead of local, foreach loops instead of for, stopped changing the array base, stopped worrying about whether you had numbers or strings, used the list oriented nature of the language a little, and got decent speed increases across the board.
The biggest benefit being the incr_loop test:
$n = shift || 50000;
foreach (1..$n) {
++$sum;
}
print "$sum\n";
I sent my modified version to the author along with pointers to what and why the style changes were made. (Every last one has maintainability as its primary goal. The speed increase comes because more maintainable code pushes more work checking boundary conditions etc down to Perl, which is both less likely to mess up and is faster than your code written in Perl.)
I hope he redoes the Perl tests...
Cheers,
Ben
Just curious.
I know a number of people with odd booting situations and they often find that GRUB can handle situations LILO has trouble with.
Cheers,
Ben
On a 32-bit system you cannot have pointers into an arbitrary location in, say, 8 GB of data.
Depending on your needs this may not be an issue. Certainly the people hitting the RAM barrier today are mainly database people who find the support for 64 GB quite nice. But that won't work for many other types of applications, and this is why Intel is biting the bullet and preparing for the end of the x86 world.
Regards,
Ben
I said directly that moving to a 64-bit processor does not solve the 2038 problem because the C standard defines time as a long and a long as 32 bits. Breaking either breaks working programs. Here is an idea of what needs to happen.
.0 releases either, you let the distributers hit the main bugs first.
As for large amounts of data, yes I have had to worry about the 2 GB limit on production systems. I have in the past gone to contortions to break up files so that they would avoid that limit. I am perfectly aware of the issues, and your glib claim that you would just fix the issue with any code you used is utter idiocy from someone who clearly doesn't understand the issues.
For instance large file support in Perl (and hence any program written in Perl) is a new feature that you can choose to compile perl 5.6.0 with. (If you choose to install on a production system, install the latest patches as well. I am serious about this.) Giving Perl that support took a fair amount of work. (Hint, you need to make sure it never tries to seek when it can't...) If you have any older version of Perl, I really recommend that you open a pipe to or from from a program (eg cat) that understood 64-bit files. Guess why I know this?
As for development vs production kernels, it depends what you are doing. For most production purposes, most people should not be using development kernels. If you have any brains you don't use
As for ReiserFS, it supports files larger than 2 GB. Whoop-te-do. So does Ext 2. Has for years. That doesn't mean that on a 32-bit system you can actually address the bit on the end...
Regards,
Ben
Use FreeBSD.
If you don't know the difference between a development and a production kernel then you shouldn't be anywhere near any production system.
Come to think of it, you probably aren't.
Anyways, someone asked a direct question about whether a problem was fixed. I explained that that was in theory only. In practice more needs to be done and the fixes in Linux should not be used in production.
I also made the rather important point that just because the OS understands what a 3 GB file doesn't mean all of your programs will understand it.
So the fix still has gotchas, and the Linux version is not ready for production.
Cheers,
Ben
If you want to try it on a boot partition, don't try to use LILO, use GRUB. If you have a complicated booting situation, you probably should be using GRUB anyways...
Cheers,
Ben
Me neither.
I won't use it until it is 2.4.6 or so. I have no need to.
There will be production Linux systems for years with a 2 GB file-size limit.
And it will probably take longer than that for all of the utilities that can only seek within a 2 GB file to figure out how to properly handle a large file...
Oh, don't forget. On 32-bit architectures you cannot have a process that can address more than 2 GB of data. (Yes, you can have more data than that - but AFAIK it has to be mmapped files kept as anonymous pages. Your *process* runs into addressing limitations because of the length of a pointer.)
This will take some time to sort out. Longer than you think - longs are remaining 32 bit on most systems for backwards compatibility reasons. Time is defined to be a long. That won't work forever...(No. Just using a 64 bit machine does not solve the problem.)
Cheers,
Ben
Fooled me!
/. is, yes it is a forum with many people of different backgrounds. Like it or not, sometimes someone will have a point to make and that point will make no sense to people who do not understand a lot of concepts like "closure", "lexical scope", and "functional programming". There are lots of people who understand all that, and lots who do not. So I specifically said that my comment was one that would only make sense to people who had been exposed to functional programming.
First of all when I say "basic programming notion" I mean in general. Not for one language or another, but rather a notion that will come up in many languages.
It doesn't happen in C. It does in JavaScript. It doesn't in Java. It does in Smalltalk. It doesn't in Python. It does in Perl. It doesn't in VB. It does in Lisp.
Perl is specifically designed to allow "baby-talk". This is considered a feature. So you can program in Perl without knowing what a closure is. But if you don't know what a closure is, you won't know what lexical scope is. If you don't understand the difference between lexical and dynamic scope then you won't understand what the different between my and local is. If you don't understand that difference then you won't understand why Perl gurus keep on telling people to use my instead of local, and why use strict encourages people very strongly to do that. And if you don't understand that, then you will suffer needless pain from time to time.
As for what
Regards,
Ben
First I think that few people who didn't already know what closures are could make heads or tails of your description. Certainly the concept of having multiple functions out there returned from the same one, each with independent data takes getting used to. The related idea of having multiple functions, each sharing specified data while not sharing other data is even more complex.
As for OO vs closures - that is really a question of philosophy. An OO philosophy encourages a particular structure on your code where all of your configuration information winds up scattered across your various class definitions. But in real life often you want to have some of that per class configuration information hidden away, but you would like to centralize other parts of it.
For instance when you are dealing with reports, the per field definition of where that field is coming from, what data validity checks you have on it, etc is all stuff that really should be centralized. OTOH per field information about how its display should be formatted, what column headings to use, etc is stuff that you want to centralize, periodically reorganize, etc.
I personally find that a functional approach lends itself more naturally for me to choosing to centralize display information into a single nested data structure. Yes, there are OO patterns to do the same thing. They look very ugly to me. For me having that choice is a win. But explaining that is more than a question about length of code. It is a philosophical comment
I have a friend who migrated from Perl to Python back when Python was able to treat regular expressions as first class objects and Perl did not. (It does now.) He commented to me a while ago that Python people claimed that anything you could do with closures you could do just as well without them in Python. He doesn't quite agree. Here are his thoughts.
Cheers,
Ben
If a programmer wants to fully exploit the available CPU power of multiple processors, then indeed they have to put in extra work. This is not necessarily a big deal. If you are already forking processes, then you have already done that work. Likewise if you are running a server that runs multiple processes in parallel (eg Apache), then the work has been done for you.
And, of course, for many things the end user doesn't care that the program is an efficient hog of multiple CPUs. If I background one process and turn to doing other things, I have already won if the backgrounded process has a minimal impact on my observed performance.
For all of these reasons people find wins running dual-processor systems even though they are mostly running programs whose programmers were not explicitly writing programs that take advantage of multiple processors.
Cheers,
Ben
Seriously, closures are a very specific notion. If you have not seen them it will take you a while to understand what they are, and longer to see why people want them.
Why not start with some documenta tion? I have neither the ability nor the desire to fully explain an entire philosophy of programming in a brief post. Go and read a FAQ if you want to start down that path.
If this seems needlessly arrogant, ask yourself a question. If you wanted to make a comment on the calculus in a forum where some are mathematicians and some are high-school students, would you feel it sufficient to mention that your comment only will make sense to people who understand calculus? This situation is exactly parallel to that.
Cheers,
Ben
Today CPUs spend a lot of energy trying to extract parallelism out of code designed to be run linearly. The ability to take advantage of parallelism is strongly limited by your ability to find it, rather than the ability of the chip to carry out instructions in parallel.
Well if the chip is emulating a dual processor machine, then you have pushed a lot of that work down to having the OS identify 2 processes that can run in parallel. I would think that this would be a huge win.
Is there something obvious that I am missing?
Cheers,
Ben
Make a "dust particle" the size of the Moon, stick it in deep space, and you have a lot of mass for your visible cross-section.
:-)
Nobody really knows how much of that stuff is out there. We know something is there that we don't see from the gravity puts out, but that doesn't mean it has to be something truly exotic.
Cheers,
Ben
The major problems that happen with multi-threading are largely due to the potential for unexpected interactions. If it is easy to show that there are no undocumented side-effects of a given piece of code, then it is far easier for an optimizer to move around when and where it is executed.
If there are potential side-effects then it can't do that unless it can prove that the side-effects in point A don't have any interaction (intended or unintended) with side-effects in point B.
Cheers,
Ben
Please do not confuse conciseness with lack of information. Python does not support a basic programming notion that Perl does, one which is key for a well-known and powerful style of programming. That is a significant difference.
What more should I have said?
Regards,
Ben