I've been curious about this for a while now, hopefully this isn't to secretive and some Googlers could give some information about this?
No, see e.g. https://code.google.com/p/or-tools/ which is Python 2 only.
Python is far from the main language at Google anyway, see https://groups.google.com/forum/?fromgroups=#!topic/unladen-swallow/TtvEBvVEZD4
Also, " Today dozens of Google engineers use Python," http://www.python.org/about/quotes/, which is a small fraction of all engineers.
I'm not a Googler, but I'd say the answer is most likely: yes.
After all, Guido van Rossum, creator of Python, has been working for Google since 2005. And it's not really like using Python 3 is such a secretive thing. A language upgrade isn't such a "killer feature" that will sweep all competition off their feet.
Do know that using Python 3 in house is one thing, and providing Python 3 APIs is another.
Case in point: Google has been using Guice since 2006 in its mission critical applications. This means Guice has probably been under development earlier than 2006. Yet, the first public release of Guice has been in March 2007.
There is no reason to believe they aren't doing the same with Python.
As you can see, my answer is highly speculative, but it does use some common sense based on facts and previous Google's moves.
I am not a Google employee, on Google App Engine they still provide Python 2.5
Related
I'm new to CP. So far I've played with MiniZinc and I'm finding this a lot of fun.
Before I commit too much, I want to figure out what CP language & solver is best to start with in terms of most active community, actively being developed and used in research, and best learning resources (examples & tutorials).
The options so far seem to be: MiniZinc, ECLiPSe, and or-tools.
Thanks,
MiniZinc is an excelent starting point. If you are interested in more languages I suggest to study Choco and JaCoP, both can be used as Java libraries, and both have very active communities.
Also take a look at OptaPlanner (Java, open source, Apache License):
daily commits
active community contributors that send in Pull Requests
monthly beta releases and 2 final releases per year
350+ page manual and also javadocced
unit tests, integration tests and stress test
enterprise support by Red hat
For the last few months I have been playing with, as you yet mentioned, the ECLiPSe programming language to solve all sorts of problems ranging from planning problems to arithmetic and logic puzzles and I've been nothing but amazed by the simplicity and power of this language. It is based on the Prolog language, so if you have the basic knowledge of Prolog, it will be pretty easy and fast to adapt to the language and its syntax. A bonus (imo) to the language are the integrated logical loops which make it very convenient to access certain data. Also, the website provides very clear documentation and code tutorials for all of its functionalities and a page with implementations to a bunch of well-known existing problems is provided here. These especially were very helpful to me while learning the language.
What are the current rules for writing python code that will pass cleanly through 2to3 and what are the practices that seem to be best suited to writing code that will not become mired forever in version 2.
I have read from the SciPy/NumPy forums that "100% test coverage" (unit testing) is important for many people, and I am not sure if that would apply to everybody. Certainly having a reasonable set of unit tests to try your code out with after conversion, seems a sane step.
Are there other things? What are skilled Pythonistas doing if they are writing 2.x code that they hope to have come through "cleanly" in the 2to3 process.
I am looking for specific instances of "[don't] do this" as well as some more general "best-practices", but specific instances of "do's and don'ts" are helpful.
Let's assume that frameworks, libraries (Django, SciPy/NumPy), and every other C Extension we need gets ported to Python3 eventually, and I'm asking about how you write and maintain the pure python language code that you write yourself.
Update: It's possible that what I really want is the "style guide" and list of deprecated features that everybody was already staying away from. I cut my teeth on Python 1.5 and moved to 2.0, and then have not really followed much of the 2.5/2.6 era, used them but really my code is more 2.1 era.
I'd say:
Read the "What's new for Python 3.0". Very informative.
In particular, if you care about Unicode or text encodings at all, take the time to understand what has changed for 3.x. That's probably one of the trickier things to change for Python 3.x.
Get Python 2.6 or 2.7, and run your code with the -3 flag. It will tell you about things in your code that will need changing.
Before using 3rd-party packages, check to see if they have a Python 3.x version. If not, check the package web site, mailing lists, version control repositories etc to see how actively the package is being developed and whether there is a roadmap towards Python 3.x support.
Download Python 3.x and try it out! Admittedly, that might not be practical if you care about code that currently depends on packages that don't yet support Python 3.x (e.g. wxPython or Django).
I've recently did some web design as a hobby with a primary motivation to learn interesting things. It was certainly nice to learn Python, but I found out there has just been a Great Python Rewrite too late, so I had to learn both Python 3 and 2.6 essentially.
I'm a newbie, so I'd like people to share what they think the strengths/weaknesses of Python 3 are from the perspective of those who do end-user programming rather than language designers. My question would be more of what people are actually liking to the point of using, or shunning as being unproductive or unpythonic.
For me, with statement is definite plus, while breaking print operator is definitely minus.
Clarification edit: there are many posts that ask whether one should learn Python 2 or 3 or whether there is any difference. I see my question is different: the feedback from people who for whatever reason made the choice of using Python 3 but might have an opinion about what works better, what not.
Another clarification: It has been pointed in the answers that with is backported to 2.*. Apologies.
I'm not using Python 3 "in production", yet, but in playing around with it I've found that print being a function is a superb idea -- for example, I can easily put it in a lambda now, where in 2.* I have to use sys.stdout.write("%s\n" % foo), a bit crufty. Plus, the syntax for such tweaks as using an output file different from sys.stdout or removing the final \n is so much more readable than Python 2.*'s!
BTW, with is also in recent Python 2.* versions, it's not a Python 3 - exclusive.
Well a strong point is the clarification between bytes and string. How many times in your short Python experience have you been confused with the unclear UnicodeDecodeError and UnicodeEncodeError? If you never had troubles with unicode vs bytestrings, well chances are that you are using an ascii-only language, (English? ;) ) but this is usually the concept which is the hardest to grasp for beginners. (by the way, if you're still confused, this link should help for Python 2.x)
I really think that this distinction between str, and bytes, is one of the strong points of Python3.0. Read PEP358 for the formal description, and the diveintopython class for something more end-user oriented. This new feature forces developers to maintain a clear distinction between unicode objects, and bytes objects which are encoded in a specific encoding. I believe that this change will help newcomers understanding more easily the difference between the two structures, and will help experienced developers using sane programming methods.
But of course this change has its own inconvenients: porting 2.x applications is quite difficult, and these str+unicode to str+bytes change is the most annoying thing to change if you are not already clearly separating Unicode and byte strings in your 2.x code. Annoying, but long-needed.
Those breaking changes look annoying to a lot of users, and... are annoying to implement for important librairies/solutions. The current force of Python2.x is the numerous third-party applications/modules: but because it is sometimes not-trivial to port to Python3, those third-party apps will need some time to be ported (and because 2.x is still alive, those applications will need to maintain two versions: one aimed to 2.x clients, and one to 3.x... costly maintenance!) For the next year, the number of fully-fledged application running Python3 will likely be quite low, because of the low number of Python3-compatible third parties. But again, I strongly support these breaking changes: have you read this Monkey, banana, Python(3) and fire hose tale? ;)
I think everything they did was for the best, in the long run. They removed a lot of the deprecated ways to do things, thus enforcing "There's Only One Way to Do It" and increasing consistency. Also, the with statement is awesome.
The obvious problem with using Python 3 is its lack of support for a lot of [big] libraries out there (such as Django). If none of your libraries break with Python 3, there's no reason not to use it.
I really like dictionary comprehension:
{k: v for k, v in stuff}
And extended iterable unpacking:
(head, *rest) = range(5)
This is really subjective. Python3.x is certainly an improvement over 2.x. It contains long anticipated changes like: Dictionary comprehensions, ordered dictionary, more powerful string formatting...etc Not to mention cleaner library.
A renowned PHP user once said: There will be a relaunch in 2 years, anyway.
Those times are gone. Web applications that are older than 5 years are common. With the original developer(s) gone.
The release cycles of the operation system, programming language, and framework are getting in the way of doing real work, if you don't have a big staff.
Is there any way to develop something that doesn't need constant porting to the next level, without the fear of losing support and backing in a community? For people who want to stay in programming instead of climbing the corporate ladder and leaving the problems to the next "generation"?
My company codes almost exclusively in C#, however we have ColdFusion 5 apps still humming along written back in 2001 or so. Theres no need to port them.
If it ain't broke, dont fix it.
Other than security flaws (which are usually handled by an OS/Server Patch, so they dont need code changes), theres no need to change an app just because a new version of the language has come out.
If I'm not mistaken, ColdFusion has had at least 2 new releases since we stopped using it for new code. but that hasn't affected our ColdFusion sites one bit.
Write CGI programs in FORTRAN 77. Should be pretty stable.
Firstly, it is possible to overstate the difficulty in maintaining web applications. In many cases, the changes to a language or platform are expansionary in nature rather than destructive. .NET, python, etc code from several years ago will still run, but new options are being added to make these these tools more powerful for future applications. The case where massive changes occur tends to be on the first or second iteration of a language, e.g. Rails 1 to Rails 2.
Secondly, the still active development of web programming is something to be thankful for.It means that this is a part of the industry that will remain productive and exciting for years to come.
Traditional CGI is stable. It's not sexy, but if your OS continues to be able to run the same binaries or scripts, it's still going to work.
The only programming frameworks that stay stable are those that have been abandoned. A framework that stood still long enough would have no support for, say, AJAX or JSON or even XML.
You're not going to find what you're asking for. The best you can hope for is a mature framework with good support like ASP.net or JSP. And, as #Neil N said, don't keep upgrading unless there's a compelling business need.
The first web programming I ever did was writing Apache modules in C which communicated with a dBase database. I'm fairly sure that code would still run today (if the company I wrote it for still existed).
I do most of my current web-related programming in Perl, which is very stable and has an excellent track record for backwards compatibility. Most, if not all, code written for Perl 4 (released 21 March, 1991) should still run on the latest stable Perl (5.10) - although you might want to update it anyhow to take advantage of the last 18 years of improvements in both software development techniques and language features.
Consider the shearing layers. I've previously worked in large aerospace companies where the same Fortran back-end code and databases have had their front-ends evolve from the paper tape era through mainframe, client server and onto Intranet web sites.
On the outside, you have will typically have CSS and XHTML templates which can be changed to re-skin an application. These change quite rapidly, in large organisations as upper management seems to decide the bike shed should be a different colour every few weeks.
Typically you then have some logic to combine the templates with data from the back-end, and forward user actions to the back-end. This shouldn't change that rapidly, but translate the presentation to calls into the back-end. Expect to refresh this every few years, and rewrite it once a decade. We used Java for this, starting in the late 1990s. Some parts get changed faster than others, but it's not a big issue.
The back-end is usually stable ( some of the aerodynamics code dated from the 1970s; the laws of physics don't change that often ), and will outlast the web UI, as it has all the other UI paradigms. Fortran is forever.
Write your own web server in C then you don't have to worry about a web programming language.
(No, that's not a serious answer)
Have you seriously looked at what TDD, CI, pair-programming, and a solid, rapid development framework (basicaly Django or Rails) can offer to you as a developer vis-a-vis the way you write and design code? There are some really massive benefits that all of those pieces offer to the development process that make it almost a joy to be a programmer again. There are downsides, of course, but the upsides are all in support of the happiness and ease of development for the engineer, which leads to more productivity. In my book, that's a slam dunk win. And the result of my productivity and happiness, has been solid products and great engineering.
YMMV, but if you are having the serious thoughts that you are (and I take them very seriously), I think it's worth you investigating what those tools can offer. By taking the good and leaving the bad from the agile religion plus some of the things I listed above, I've returned to find the joy in programming again this last year, after a good 5 years of a downhill slide of my happiness with this career. It's about finding what works for you. I can only help and lead the way by showing you what worked for me. I'd be more than happy to discuss at length if you want to talk offline, I think this is a really important topic...it lead me to consider a career change many times.
Java Servlets and JSPs have been in use for a decade or so, and they still work the same way like they did in '99. But honestly, can you imagine something uglier than a '90s web application without any rework done since?
The Python web framework web2py promises backward compatibility:
Always backward compatible. We have
not broken backward compatibility
since version 1.0 in 2007, and we
pledge not to break it in the future.
And supports Python versions from 2.4 to 2.7
EDIT: Updated an important project 2 times and every time there was a problem. Well, …
EDIT 2: Needs Python 2.6 to 2.7 now. No support for Python 3.
It's been out for almost five years.
It's got tens of millions of users
I suspect several businesses rely on it.
How is it still "beta"? At what point will it no longer be beta? When it completely owns the e-mail market?
According to a Google spokesman:
"We have very high internal metrics
our consumer products have to meet
before coming out of beta. Our teams
continue to work to improve these
products and provide users with an
even better experience. We believe
beta has a different meaning when
applied to applications on the Web,
where people expect continual
improvements in a product. On the
Web, you don't have to wait for the
next version to be on the shelf or an
update to become available.
Improvements are rolled out as they're
developed. Rather than the packaged,
stagnant software of decades past,
we're moving to a world of regular
updates and constant feature
refinement where applications live in
the cloud."
Wikipedia defines Beta Version as:
A 'beta version' is the first version released outside the organization or community that develops the software, for the purpose of evaluation or real-world black/grey-box testing. The process of delivering a beta version to the users is called beta release. Beta level software generally includes all features, but may also include known issues and bugs of a less serious variety.
So this confirms that Google's use of the word is non-standard. I found this Slashdot article, Has Google Redefined Beta?, to be pretty interesting.
I think Google borrowed the word for their own ends and it shouldn't be taken at face value with the traditional definition of "Beta". It simply looks better to put "Beta" by your apps name instead of, "We are still constantly adding features to this product".
Well it was down for 30 hours about two months ago. Looks like even after five years there are a few kinks to iron out.
Google itself was in beta for years. The founders have much higher standards for their products than other companies.
Just like C++ wasn't a standard for quite a while :)
Also, they continuously add and change features, so it is a beta.
I suspect that beta, in this case, means that they are avoiding the hassles and complications of being accused of being a monopoly. Conspiracy anybody?
It is (at least officially) in perpetual beta state.
http://en.wikipedia.org/wiki/Perpetual_beta
its not in beta anymore since July 2009 - so if you're seeing a 'beta' logo still its because someone enabled the 'back to beta' feature. Yes really...