Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 internet speed test! ×

Comment Re:Because Programmers Make Bad Decisions (Score 1) 187

Sorry, no. They broke strings entirely in Python 3.0 and that is why people cannot port to them.

Here is how to do strings correctly: use UTF-8 and DO NOT BARF ON ENCODING ERRORS!

It is absolutely 100% a requirement that a program be able to read a random byte stream into a "string", then write it out again, and get the same byte stream.

In Python 2.0 this only barfed if you tried to convert that string to "Unicode" (it would have been nice if it did not barf, but at least you could store, read, and write strings).

In Python 3.0 it will BARF ON READ. This makes it impossible to write reliable software.

Yes you can use "bytes" in Python 3.0. But that really sucks if in fact you expect your bytes to be readable text, with only RARE (but not magically non-existent) errors.

Comment Re:I'm so out of touch (Score 2) 37

Wayland does in fact have support for resolution independence. By this I mean that if a program does nothing about the resolution of the screen, Wayland assumes it is drawing for approximately 100 dpi, and scales the image by 2 if the screen is 200dpi. I think it only does integer scaling but it may be up to the compositor implementation.

If a program actually claims it's drawing for the high-resolution display, then Wayland does not scale. The problem with X (and I think with Windows) was that there was no api so a program could tell the system that it is handling the high resolution, so the compositor had to assume it was.

Comment Re:welcome to python (Score 1) 148

Honestly the changes in Python 3 should not be any obstacle to porting code. Most of it winds up being a find and replace. The major difference is the use of unicode, and if your package really depends heavily on strings not being unicode, you probably did it wrong. The problem is that if one package that lots of people depend on has devs that just say, "I don't wanna," everything breaks down. And more than one package has devs like that.

At this point, if the Python community could make "porting" as simple as adding a header to a .py file, there would still be people that would refuse to do it.

The problem with Python 3 "unicode" is not that text is not Unicode. The problem is that *random binary data* is not Unicode, but when you read data from an unknown source, you MUST assume it is "random binary data". Trusting it to follow some pattern is by far the stupidest thing you can do.

In Python 2 you could put random binary data into a "string" and then write it to disk without any change, and no errors would be produced. Only if you tried to *display* the string would you get an exception. In Python 3 it will immediately throw an exception, at a completely useless point in your program (ie when you are reading data in, not when you are processing it). Changing every "string" to a "bytes" will "fix" it, but then you have to change the type of every single function that is called from "string" to "bytes", and so on, eventually replacing every single "string" in your program with "bytes". And you are out of luck if one of those api's is from a library that you don't control.

Python 3 will NEVER get accepted unless you can put totally arbitrary patterns of 8-bit data into a "string" and get them back out unchanged. All exceptions must be deferred until something actually tries to split the data into Unicode code points. Even then they should be providing a more useful iterator based api that returns an object that says "the code point is this" or "there is a UTF-8 parsing error here and the first byte is this".

Comment Re:An earthquake is an accident waiting to happen (Score 1) 130

I don't know if you are trying to make a joke, but global warming is not going to do too much to the earthquakes. Greenland is already rising steadily due to the loss of the glaciers from the last ice age. It is really slow and will still happen for tens of thousands of years. Even if all the current ice cap disappeared tomorrow it would, at best, speed this up a tiny amount (the current ice cap is a fraction of the ice age ice cap so the amount of lost mass is only a small change). The weight of the new ice added to the ocean is insignificant (if it raised the ocean 30 feet that would still only be a tiny fraction of mass increase, think about how deep the ocean is).

Comment Re:Banking in Space (Score 1) 131

If nothing is holding them up (ie in free fall if they turn off their engines) then the proper bank would be at 90 degrees, not some smaller angle. Also (more importantly) the engines need to fire exactly outward from the turn (basically it will make a circle around some point the engines are pointing toward and cannot do anything else).

Best design for a ship would have the engine firing straight down when the humans are in a comfortable position. A highly maneuverable ship would fly "sideways" during maneuvers, the engine firing crosswise to maximize it's ability to change direction as it approaches an enemy. It would only fly parallel to the engine when accelerating. And it would have to spend an equal amount of time decelerating, and that is what it would likely be doing when approaching an enemy. This also points the engine at the enemy, and considering how fast the exhaust must be (seeing as these ships seem to contain very little reaction mass) that engine is much more powerful and destructive than any other weapon they have.

Slashdot Top Deals

There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann

Working...