Python 2.6 Quick Reference Style chooser: Modern, Modern B&W, Modern Colored, Classic, High contrast or Printing [Hint: Use styles Modern B&W or Printing to print. If you get problems, try printing the PDF versions instead] Contents Front matter Version 2.6 (What's new?) Creative Commons License. Last updated on July 31, 2010. Feb 10, 2009 upgraded by Richard Gruet and Josh Stone for Python 2.6 Dec 14, 2006 upgraded by Richard Gruet for Python 2.5 Feb 17, 2005, upgraded by Richard Gruet for Python 2.4 Oct 3, 2003 upgraded by Richard Gruet for Python 2.3 May 11, 2003, rev 4 upgraded by Richard Gruet for Python 2.2 (restyled by Andrei) Aug 7, 2001 upgraded by Simon Brunning for Python 2.1 May 16, 2001 upgraded by Richard Gruet and Simon Brunning for Python 2.0 Jun 18, 2000 upgraded by Richard Gruet for Python 1.5.2 Oct 20, 1995 created by Chris Hoffmann for Python 1.3 Color coding: Features added in 2.6 since 2.5 Features added in 2.5 since 2.4 Features added in 2.4 since 2.3 A link Invocation Options python[w] [-BdEhimOQsStuUvVWxX3?]
BeginnersGuide/NonProgrammers Python for Non-Programmers If you've never programmed before, the tutorials on this page are recommended for you; they don't assume that you have previous experience. If you have programming experience, also check out the BeginnersGuide/Programmers page. Books Each of these books can be purchased online but is also available as free textual, website, or video content. Automate the Boring Stuff with Python - Practical Programming for Total Beginners by Al Sweigart is "written for office workers, students, administrators, and anyone who uses a computer to learn how to code small, practical programs to automate tasks on their computer." You can find many free Python books online. Interactive Courses These sites give you instant feedback on programming problems that you can solve in your browser. CheckiO is a gamified website containing programming tasks that can be solved in Python 3. Resources for Younger Learners Tutorials and Websites Tutorial Aggregators / lists Apps Videos Email Academies Tools
Inversion of Control Containers and the Dependency Injection pattern In the Java community there's been a rush of lightweight containers that help to assemble components from different projects into a cohesive application. Underlying these containers is a common pattern to how they perform the wiring, a concept they refer under the very generic name of "Inversion of Control". In this article I dig into how this pattern works, under the more specific name of "Dependency Injection", and contrast it with the Service Locator alternative. The choice between them is less important than the principle of separating configuration from use. One of the entertaining things about the enterprise Java world is the huge amount of activity in building alternatives to the mainstream J2EE technologies, much of it happening in open source. Underlying these containers are a number of interesting design principles, things that go beyond both these specific containers and indeed the Java platform. Components and Services A Naive Example class MovieLister... Inversion of Control
Build Rails Apps Which Build Rails Apps For You Many sites, including my current project, use Omniture for page tracking and analytics. In practical terms, this means somebody has to build JavaScript identifying each page in Omniture's terms, which can involve a mind-numbing amount of repetitive, beauraucratic code. If you take a look, you'll see that many of these variables have identical values, and few of them have semantically significant names. Nobody who's worked in technology for any length of time will be surprised to learn that this combination resulted in tedious, tangled code on the Rails side, specifically in the helpers, or that the Rails helpers which generated this JavaScript from within various Rails apps all operated more or less independently, without a great deal of co-ordination, leading to an inevitable maintenance nightmare. The temptation here is to complain, read Slashdot, and put Dilbert cartoons on your cubicle wall. Our existing Omniture code did not have the virtue of simplicity. (The send and respond_to?
Data Science Toolkit (the eff-bot guide to) The Standard Python Library Overviews (15) Core Modules [core-modules-index]Data Representation [data-representation-index]Data Storage [data-storage-index]File Formats [file-formats-index]Implementation Support Modules [implementation-support-modules-index]Internationalization [internationalization-index]Mail and News Message Processing [mail-and-news-message-processing-index]More Standard Modules [more-standard-modules-index]Multimedia Modules [multimedia-modules-index]Network Protocols [network-protocols-index]Other Modules [other-modules-index]Platform Specific Modules [platform-specific-modules-index]Preface [preface-index]Threads and Processes [threads-and-processes-index]Tools and Utilities [tools-and-utilities-index] Articles (249) The aifc module [aifc]The anydbm module [anydbm]The array module [array]The asynchat module [asynchat]The asyncore module [asyncore]The atexit module [atexit]The audiodev module [audiodev] The keyword module [keyword]The knee module [knee]
P of EAA This book started after Dave Rice and I gave some talks on J2EE architecture and mulled over how the concepts we had learned in C++, Forte, CORBA, and Smalltalk had been crucial to us developing good designs in Java. With this book I wanted to set many of these patterns down to help developers whatever their platform. These turned out to be very valuable when we started to use .NET in 2002 and Ruby in 2007. The book is a Duplex Book. Each pattern describes details of how it works and when to use it, together with code examples in Java, C# or both. The main topic areas are: how to layer an enterprise application, how to organize domain logic, how to tie that logic to a relational database, how to design a web based presentation, some important principles in distributed design, and handling of what we call "offline concurrency" - concurrency that spans transactions. I wrote this book in the early noughties, but my colleagues and I find the patterns are still relevant today.
Actor model History[edit] Major software implementation work was done by Russ Atkinson, Giuseppe Attardi, Henry Baker, Gerry Barber, Peter Bishop, Peter de Jong, Ken Kahn, Henry Lieberman, Carl Manning, Tom Reinhardt, Richard Steiger and Dan Theriault in the Message Passing Semantics Group at Massachusetts Institute of Technology (MIT). Research groups led by Chuck Seitz at California Institute of Technology (Caltech) and Bill Dally at MIT constructed computer architectures that further developed the message passing in the model. See Actor model implementation. Research on the Actor model has been carried out at California Institute of Technology, Kyoto University Tokoro Laboratory, MCC, MIT Artificial Intelligence Laboratory, SRI, Stanford University, University of Illinois at Urbana-Champaign,[6] Pierre and Marie Curie University (University of Paris 6), University of Pisa, University of Tokyo Yonezawa Laboratory and elsewhere. Fundamental concepts[edit] Formal systems[edit] Applications[edit]
Learning Python, Linux, Java, Ruby and more with Videos, Tutorials and Screencasts Is Design Dead? For many that come briefly into contact with Extreme Programming, it seems that XP calls for the death of software design. Not just is much design activity ridiculed as "Big Up Front Design", but such design techniques as the UML, flexible frameworks, and even patterns are de-emphasized or downright ignored. In fact XP involves a lot of design, but does it in a different way than established software processes. XP has rejuvenated the notion of evolutionary design with practices that allow evolution to become a viable design strategy. It also provides new challenges and skills as designers need to learn how to do a simple design, how to use refactoring to keep a design clean, and how to use patterns in an evolutionary style. Extreme Programming (XP) challenges many of the common assumptions about software development. I find myself at the center of this argument. Well I'm not going to expect that I can leave you dangling on the hook of dramatic tension. Planned and Evolutionary Design
The "Option" Pattern 7 Apr 2008 As I’ve gotten to know Scala better, I’ve begun to appreciate its simple power in ways which have caught me by surprise. When I picked up the language, I was expecting to be wowed by things like type inference and a more concise syntax. I wasn’t expecting to fall in love with Option. The Option Monad In case you don’t know, Option is a class in the Scala core libraries. Pretty straightforward stuff. Nothing earth-shattering in the mathematical realm, but it provides a useful illustration. Instead of getting an integer result wrapped in an enclosing class, we get an instance of a totally different class which doesn’t appear to encapsulate any value at all. Retrieving a value from an instance of Option can be done in one of two ways. Pattern matching allows us to deconstruct Option values in a type-safe manner without the risk of trying to access a value which really isn’t there. Compared to null This is very similar to a common pattern in C++ and Java. Option in Java Conclusion
SOLID (object-oriented design) In computer programming, SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion) is a mnemonic acronym introduced by Michael Feathers for the "first five principles" named by Robert C. Martin[1][2] in the early 2000s[3] that stands for five basic principles of object-oriented programming and design. The principles when applied together intend to make it more likely that a programmer will create a system that is easy to maintain and extend over time.[3] The principles of SOLID are guidelines that can be applied while working on software to remove code smells by causing the programmer to refactor the software's source code until it is both legible and extensible. It is part of an overall strategy of agile and adaptive programming.[3]
Design patterns of 1972 Design patterns of 1972 "Patterns" that are used recurringly in one language may be invisible or trivial in a different language. Extended Example: "object-oriented class" C programmers have a pattern that might be called "Object-oriented class". In this pattern, an object is an instance of a C struct. struct st_employee_object *emp; Or, given a suitable typedef: EMPLOYEE emp; Some of the struct members are function pointers. emp->method(emp, args Each struct definition defines a class; objects in the same class have the same member data and support the same methods. There are a bunch of variations on this. struct st_employee_object { unsigned salary; struct st_manager_object *boss; METHOD fire, transfer, competence; }; The other defines only the interface: struct st_employee_object { char __SECRET_MEMBER_DATA_DO_NOT_TOUCH[4]; struct st_manager_object *boss; METHOD fire, transfer, competence; }; And then files include one or the other as appropriate. void _abstract() { abort(); } Invisible Formal