- I'm confused. What part of this causes an eyeroll for you? Did you attempt to read the words in a spiral instead of the standard left-to-right, top-to-bottom style most English readers prefer?
- "Special cases aren't special enough to break the rules."
- As we say so often in the Python commmunity, "Try It And See." Do you use cffi and/or ctypes in your code? Have you run your tests against this newer PyPy?
- You don't sound like a hacker. You sound like somebody who types a lot in order to change the patterns of lights on their monitor.
- I agree with the author entirely.
- It is not up to PyPy to support non-pure-Python libraries; it is up to those libraries to fix themselves by evicting their C and FORTRAN balls and chains.
- Let's define "virtually." There are plenty of websites that don't use JS.
- I hope that you did not flip this around and force yourself to learn PHP and JS based on this philosophy.
- The author appears to not be aware of where the big leagues are. Additionally, as is becoming a recurring theme here, he doesn't know about PyPy nor Twisted. This is continually disappointing.
- Image macros come from Japanese message boards; they are not really related to the faux motivational posters that are commonly known as "demotivationals".
- I politely submit that you have not heard of E.
- "I believe there are two reasons why some people want to disable JavaScript: the feeling of extra privacy and improving page speeds."
I normally get along with Armin, but I feel that he left out a key thing here: Some people disable JS because they feel that JS obfuscates and degrades the Web-browsing experience. Sadly, we are no longer catering to these people: viewing a website without JS enabled should not render the fundamental content of the website unavailable, and we have forsaken that ideal in favor of fancy bells and whistles on our pages.
There's a fourth reason, as well: JS should not be required on grounds of security, not just privacy. Sites should not have to run what is essentially unsafe, privileged, arbitrary code in order to do their daily business. A company might claim that their JS is harmless because it only animates a title bar or powers a dropdown menu, but proving that requires a manual audit of all JS on the page, which amounts to thousands of lines of JS on a modern site. (Have you read through the copy of jQuery being served to you? Probably not.) Common repositories of JS ameliorate the problem somewhat, but it can't be eliminated.
This is not okay, by the way. Requiring JS to read a news article, or upload an image, or view a forum thread, is insane and we should not tolerate it.
You have been misinformed.$ twistd -n web --wsgi your.wsgi.app- I'm obligated to chime in: http://airbr.us/h/tipsum
- So, as far as I can tell, you have failed to demonstrate that Twisted Web with PyPy is not a viable alternative, which is disappointing.
Also, uWSGI's core team doesn't have any faith in their own code; they use Apache instead of dogfooding. (And they're moving all hosting and development to sites like Github.) Twisted, at least, is confident enough in the quality of their code to self-host.
- Stop writing Java code in Python. No. Bad. Stop it.
- You are wrong.
Python's object model is incredibly rich in ways that JavaScript and Lua don't even come close to touching. Let me list some things that you'll see in Python code that you're not gonna see in JS or Lua:
* Objects that don't extend the object hierarchy (you don't have to extend from `object`)
* Types that don't extend the type hierarchy (Python has full metaclassing)
* Any object can elect to become callable; calls are almost message passes
* Two different levels of message-passing method/attribute rewriting (__getattr__ and __getattribute__)
* Descriptors, such as properties (no, real properties) are baked into the object model
* The table of globals can be altered at any time, frustrating static analysis
* The table of locals can be altered too!
* The table of builtins can be altered!! (Is nothing sacred?)
In addition, PyPy did not start out as a partial evaluator and meta-tracing JIT generator. What you're seeing is the result of about a decade of work and a half-dozen iterations. They started out with something much like the thing that you would expect to see, but just like every other Python JIT project, they learned that Python is complex and difficult to optimize.
So, uh, you're wrong. Sorry.
- Python as a language requires the float type to have at least double precision. This is sadly not documented explicitly, but the big four Python implementations all respect this.
On your first paragraph, pondering whether sucrose breaks down into fructose and glucose immediately: No, it doesn't. HFCS makes sugars available to the bloodstream sooner, causing larger swings in overall blood sugar levels. Additionally, this study covers rats which were given strict diets; the idea that HFCS made them fatter because they ate more food is not borne out based on the experiment's premises.
Second paragraph: Irrelevant. Honey is not being discussed here. Additionally, you contradict yourself by noting (correctly) that HFCS is not half-and-half fructose and glucose, like sucrose.
Third paragraph: Inverted appeal to authority. You dismiss the information that science makes available, and then put your own opinion up for offering as if it is informed and accurate. You further confuse the issue by putting a well-accepted opinion (the diets of the USA are overly rich in sugars) next to a dismissal of this study.
Fourth paragraph: A delightful strawman, substituting artificial sweeteners for table sugar.
Fifth: More ignorance of the general study of nutrition, with a sweeping statement that is obviously true and yet completely uninformative.
Please go read the article before commenting further.