java中 ok的用法,Java中利用Response.ok().build()操作response的statuscode的用法例子

系统环境

JDK 1.7.0_09

Glassfish 3.1.2

利用javax.ws.rs.core.Response

代码例子

package com.cft.ui.service;

import java.net.URI;

import java.net.URISyntaxException;

import java.util.ArrayList;

import javax.servlet.http.HttpServletRequest;

import javax.ws.rs.GET;

import javax.ws.rs.Path;

import javax.ws.rs.core.Context;

import javax.ws.rs.core.Response;

import javax.ws.rs.core.Variant;

import com.sun.jersey.api.client.ClientResponse.Status;

@Path("/service/response")

public class ResponseService {

private static final String REDIRECT_PATH = "http://xxx:9090/";

@Context

private HttpServletRequest request = null;

@Path("seeOther")

@GET

public Response seeOther() throws URISyntaxException {

Response response = Response.seeOther(new URI(REDIRECT_PATH)).build();

System.out.println(request.getRequestURI());

System.out.println(response.getStatus());

return response;

}

@Path("temporaryRedirect")

@GET

public Response temporaryRedirect() throws URISyntaxException {

Response response = Response.temporaryRedirect(new URI(REDIRECT_PATH)).build();

System.out.println(request.getRequestURI());

System.out.println(response.getStatus());

return response;

}

@Path("created")

@GET

public Response created() throws URISyntaxException {

Response response = Response.created(new URI(REDIRECT_PATH)).build();

System.out.println(request.getRequestURI());

System.out.println(response.getStatus());

return response;

}

@Path("fromResponse")

@GET

public Response fromResponse() throws URISyntaxException {

Response response = Response.fromResponse(seeOther()).build();

System.out.println(request.getRequestURI());

System.out.println(response.getStatus());

return response;

}

@Path("noContent")

@GET

public Response noContent() throws URISyntaxException {

Response response = Response.noContent().build();

System.out.println(request.getRequestURI());

System.out.println(response.getStatus());

return response;

}

@Path("notAcceptable")

@GET

public Response notAcceptable() throws URISyntaxException {

Response response = Response.notAcceptable(new ArrayList()).build();

System.out.println(request.getRequestURI());

System.out.println(response.getStatus());

return response;

}

@Path("notModified")

@GET

public Response notModified() throws URISyntaxException {

Response response = Response.notModified().build();

System.out.println(request.getRequestURI());

System.out.println(response.getStatus());

return response;

}

@Path("ok")

@GET

public Response ok() throws URISyntaxException {

Response response = Response.ok().build();

System.out.println(request.getRequestURI());

System.out.println(response.getStatus());

return response;

}

@Path("serverError")

@GET

public Response serverError() throws URISyntaxException {

Response response = Response.serverError().build();

System.out.println(request.getRequestURI());

System.out.println(response.getStatus());

return response;

}

@Path("status")

@GET

public Response status() throws URISyntaxException {

Response response = Response.status(Status.BAD_GATEWAY).build();

System.out.println(request.getRequestURI());

System.out.println(response.getStatus());

return response;

}

}

JSP页面返回

@Path("ok2")

@GET

@Produces(MediaType.TEXT_HTML)

public Response ok2() throws URISyntaxException {

Viewable view = new Viewable("/sample.jsp", new SampleJspBean("test", 1986));

Response response = Response.ok().entity(view).type(MediaType.TEXT_HTML).build();

System.out.println(request.getRequestURI());

System.out.println(response.getStatus());

return response;

}

另外写法

@Path("ok2")

@GET

@Produces(MediaType.TEXT_HTML)

public Response ok2() {

return new Viewable("/sample.jsp", new SampleJspBean("test", 1986));

}

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
I. Spring Boot Documentation 1. About the Documentation 2. Getting Help 3. First Steps 4. Working with Spring Boot 5. Learning about Spring Boot Features 6. Moving to Production 7. Advanced Topics II. Getting Started 8. Introducing Spring Boot 9. System Requirements 9.1. Servlet Containers 10. Installing Spring Boot 10.1. Installation Instructions for the Java Developer 10.1.1. Maven Installation 10.1.2. Gradle Installation 10.2. Installing the Spring Boot CLI 10.2.1. Manual Installation 10.2.2. Installation with SDKMAN! 10.2.3. OSX Homebrew Installation 10.2.4. MacPorts Installation 10.2.5. Command-line Completion 10.2.6. Quick-start Spring CLI Example 10.3. Upgrading from an Earlier Version of Spring Boot 11. Developing Your First Spring Boot Application 11.1. Creating the POM 11.2. Adding Classpath Dependencies 11.3. Writing the Code 11.3.1. The @RestController and @RequestMapping Annotations 11.3.2. The @EnableAutoConfiguration Annotation 11.3.3. The “main” Method 11.4. Running the Example 11.5. Creating an Executable Jar 12. What to Read Next III. Using Spring Boot 13. Build Systems 13.1. Dependency Management 13.2. Maven 13.2.1. Inheriting the Starter Parent 13.2.2. Using Spring Boot without the Parent POM 13.2.3. Using the Spring Boot Maven Plugin 13.3. Gradle 13.4. Ant 13.5. Starters 14. Structuring Your Code 14.1. Using the “default” Package 14.2. Locating the Main Application Class 15. Configuration Classes 15.1. Importing Additional Configuration Classes 15.2. Importing XML Configuration 16. Auto-configuration 16.1. Gradually Replacing Auto-configuration 16.2. Disabling Specific Auto-configuration Classes 17. Spring Beans and Dependency Injection 18. Using the @SpringBootApplication Annotation 19. Running Your Application 19.1. Running from an IDE 19.2. Running as a Packaged Application 19.3. Using the Maven Plugin 19.4. Using the Gradle Plugin 19.5. Hot Swapping 20. Developer Tools 20.1. Property Defaults 20.2. Automatic Restart 20.2.1. Logging changes in condition evaluation 20.2.2. Excluding Resources 20.2.3. Watching Additional Paths 20.2.4. Disabling Restart 20.2.5. Using a Trigger File 20.2.6. Customizing the Restart Classloader 20.2.7. Known Limitations 20.3. LiveReload 20.4. Global Settings 20.5. Remote Applications 20.5.1. Running the Remote Client Application 20.5.2. Remote Update 21. Packaging Your Application for Production 22. What to Read Next IV. Spring Boot features 23. SpringApplication 23.1. Startup Failure 23.2. Customizing the Banner 23.3. Customizing SpringApplication 23.4. Fluent Builder API 23.5. Application Events and Listeners 23.6. Web Environment 23.7. Accessing Application Arguments 23.8. Using the ApplicationRunner or CommandLineRunner 23.9. Application Exit 23.10. Admin Features 24. Externalized Configuration 24.1. Configuring Random Values 24.2. Accessing Command Line Properties 24.3. Application Property Files 24.4. Profile-specific Properties 24.5. Placeholders in Properties 24.6. Using YAML Instead of Properties 24.6.1. Loading YAML 24.6.2. Exposing YAML as Properties in the Spring Environment 24.6.3. Multi-profile YAML Documents 24.6.4. YAML Shortcomings 24.7. Type-safe Configuration Properties 24.7.1. Third-party Configuration 24.7.2. Relaxed Binding 24.7.3. Merging Complex Types 24.7.4. Properties Conversion Converting durations 24.7.5. @ConfigurationProperties Validation 24.7.6. @ConfigurationProperties vs. @Value 25. Profiles 25.1. Adding Active Profiles 25.2. Programmatically Setting Profiles 25.3. Profile-specific Configuration Files 26. Logging 26.1. Log Format 26.2. Console Output 26.2.1. Color-coded Output 26.3. File Output 26.4. Log Levels 26.5. Custom Log Configuration 26.6. Logback Extensions 26.6.1. Profile-specific Configuration 26.6.2. Environment Properties 27. Developing Web Applications 27.1. The “Spring Web MVC Framework” 27.1.1. Spring MVC Auto-configuration 27.1.2. HttpMessageConverters 27.1.3. Custom JSON Serializers and Deserializers 27.1.4. MessageCodesResolver 27.1.5. Static Content 27.1.6. Welcome Page 27.1.7. Custom Favicon 27.1.8. Path Matching and Content Negotiation 27.1.9. ConfigurableWebBindingInitializer 27.1.10. Template Engines 27.1.11. Error Handling Custom Error Pages Mapping Error Pages outside of Spring MVC 27.1.12. Spring HATEOAS 27.1.13. CORS Support 27.2. The “Spring WebFlux Framework” 27.2.1. Spring WebFlux Auto-configuration 27.2.2. HTTP Codecs with HttpMessageReaders and HttpMessageWriters 27.2.3. Static Content 27.2.4. Template Engines 27.2.5. Error Handling Custom Error Pages 27.2.6. Web Filters 27.3. JAX-RS and Jersey 27.4. Embedded Servlet Container Support 27.4.1. Servlets, Filters, and listeners Registering Servlets, Filters, and Listeners as Spring Beans 27.4.2. Servlet Context Initialization Scanning for Servlets, Filters, and listeners 27.4.3. The ServletWebServerApplicationContext 27.4.4. Customizing Embedded Servlet Containers Programmatic Customization Customizing ConfigurableServletWebServerFactory Directly 27.4.5. JSP Limitations 28. Security 28.1. MVC Security 28.2. WebFlux Security 28.3. OAuth2 28.3.1. Client 28.3.2. Server 28.4. Actuator Security 28.4.1. Cross Site Request Forgery Protection 29. Working with SQL Databases 29.1. Configure a DataSource 29.1.1. Embedded Database Support 29.1.2. Connection to a Production Database 29.1.3. Connection to a JNDI DataSource 29.2. Using JdbcTemplate 29.3. JPA and “Spring Data” 29.3.1. Entity Classes 29.3.2. Spring Data JPA Repositories 29.3.3. Creating and Dropping JPA Databases 29.3.4. Open EntityManager in View 29.4. Using H2’s Web Console 29.4.1. Changing the H2 Console’s Path 29.5. Using jOOQ 29.5.1. Code Generation 29.5.2. Using DSLContext 29.5.3. jOOQ SQL Dialect 29.5.4. Customizing jOOQ 30. Working with NoSQL Technologies 30.1. Redis 30.1.1. Connecting to Redis 30.2. MongoDB 30.2.1. Connecting to a MongoDB Database 30.2.2. MongoTemplate 30.2.3. Spring Data MongoDB Repositories 30.2.4. Embedded Mongo 30.3. Neo4j 30.3.1. Connecting to a Neo4j Database 30.3.2. Using the Embedded Mode 30.3.3. Neo4jSession 30.3.4. Spring Data Neo4j Repositories 30.3.5. Repository Example 30.4. Gemfire 30.5. Solr 30.5.1. Connecting to Solr 30.5.2. Spring Data Solr Repositories 30.6. Elasticsearch 30.6.1. Connecting to Elasticsearch by Using Jest 30.6.2. Connecting to Elasticsearch by Using Spring Data 30.6.3. Spring Data Elasticsearch Repositories 30.7. Cassandra 30.7.1. Connecting to Cassandra 30.7.2. Spring Data Cassandra Repositories 30.8. Couchbase 30.8.1. Connecting to Couchbase 30.8.2. Spring Data Couchbase Repositories 30.9. LDAP 30.9.1. Connecting to an LDAP Server 30.9.2. Spring Data LDAP Repositories 30.9.3. Embedded In-memory LDAP Server 30.10. InfluxDB 30.10.1. Connecting to InfluxDB 31. Caching 31.1. Supported Cache Providers 31.1.1. Generic 31.1.2. JCache (JSR-107) 31.1.3. EhCache 2.x 31.1.4. Hazelcast 31.1.5. Infinispan 31.1.6. Couchbase 31.1.7. Redis 31.1.8. Caffeine 31.1.9. Simple 31.1.10. None 32. Messaging 32.1. JMS 32.1.1. ActiveMQ Support 32.1.2. Artemis Support 32.1.3. Using a JNDI ConnectionFactory 32.1.4. Sending a Message 32.1.5. Receiving a Message 32.2. AMQP 32.2.1. RabbitMQ support 32.2.2. Sending a Message 32.2.3. Receiving a Message 32.3. Apache Kafka Support 32.3.1. Sending a Message 32.3.2. Receiving a Message 32.3.3. Additional Kafka Properties 33. Calling REST Services with RestTemplate 33.1. RestTemplate Customization 34. Calling REST Services with WebClient 34.1. WebClient Customization 35. Validation 36. Sending Email 37. Distributed Transactions with JTA 37.1. Using an Atomikos Transaction Manager 37.2. Using a Bitronix Transaction Manager 37.3. Using a Narayana Transaction Manager 37.4. Using a Java EE Managed Transaction Manager 37.5. Mixing XA and Non-XA JMS Connections 37.6. Supporting an Alternative Embedded Transaction Manager 38. Hazelcast 39. Quartz Scheduler 40. Spring Integration 41. Spring Session 42. Monitoring and Management over JMX 43. Testing 43.1. Test Scope Dependencies 43.2. Testing Spring Applications 43.3. Testing Spring Boot Applications 43.3.1. Detecting Web Application Type 43.3.2. Detecting Test Configuration 43.3.3. Excluding Test Configuration 43.3.4. Testing with a running server 43.3.5. Using JMX 43.3.6. Mocking and Spying Beans 43.3.7. Auto-configured Tests 43.3.8. Auto-configured JSON Tests 43.3.9. Auto-configured Spring MVC Tests 43.3.10. Auto-configured Spring WebFlux Tests 43.3.11. Auto-configured Data JPA Tests 43.3.12. Auto-configured JDBC Tests 43.3.13. Auto-configured jOOQ Tests 43.3.14. Auto-configured Data MongoDB Tests 43.3.15. Auto-configured Data Neo4j Tests 43.3.16. Auto-configured Data Redis Tests 43.3.17. Auto-configured Data LDAP Tests 43.3.18. Auto-configured REST Clients 43.3.19. Auto-configured Spring REST Docs Tests Auto-configured Spring REST Docs Tests with Mock MVC Auto-configured Spring REST Docs Tests with REST Assured 43.3.20. User Configuration and Slicing 43.3.21. Using Spock to Test Spring Boot Applications 43.4. Test Utilities 43.4.1. ConfigFileApplicationContextInitializer 43.4.2. TestPropertyValues 43.4.3. OutputCapture 43.4.4. TestRestTemplate 44. WebSockets 45. Web Services 46. Creating Your Own Auto-configuration 46.1. Understanding Auto-configured Beans 46.2. Locating Auto-configuration Candidates 46.3. Condition Annotations 46.3.1. Class Conditions 46.3.2. Bean Conditions 46.3.3. Property Conditions 46.3.4. Resource Conditions 46.3.5. Web Application Conditions 46.3.6. SpEL Expression Conditions 46.4. Testing your Auto-configuration 46.4.1. Simulating a Web Context 46.4.2. Overriding the Classpath 46.5. Creating Your Own Starter 46.5.1. Naming 46.5.2. autoconfigure Module 46.5.3. Starter Module 47. Kotlin support 47.1. Requirements 47.2. Null-safety 47.3. Kotlin API 47.3.1. runApplication 47.3.2. Extensions 47.4. Dependency management 47.5. @ConfigurationProperties 47.6. Testing 47.7. Resources 47.7.1. Further reading 47.7.2. Examples 48. What to Read Next V. Spring Boot Actuator: Production-ready features 49. Enabling Production-ready Features 50. Endpoints 50.1. Enabling Endpoints 50.2. Exposing Endpoints 50.3. Securing HTTP Endpoints 50.4. Configuring Endpoints 50.5. Hypermedia for Actuator Web Endpoints 50.6. Actuator Web Endpoint Paths 50.7. CORS Support 50.8. Implementing Custom Endpoints 50.8.1. Receiving Input Input type conversion 50.8.2. Custom Web Endpoints Web Endpoint Request Predicates Path HTTP method Consumes Produces Web Endpoint Response Status Web Endpoint Range Requests Web Endpoint Security 50.8.3. Servlet endpoints 50.8.4. Controller endpoints 50.9. Health Information 50.9.1. Auto-configured HealthIndicators 50.9.2. Writing Custom HealthIndicators 50.9.3. Reactive Health Indicators 50.9.4. Auto-configured ReactiveHealthIndicators 50.10. Application Information 50.10.1. Auto-configured InfoContributors 50.10.2. Custom Application Information 50.10.3. Git Commit Information 50.10.4. Build Information 50.10.5. Writing Custom InfoContributors 51. Monitoring and Management over HTTP 51.1. Customizing the Management Endpoint Paths 51.2. Customizing the Management Server Port 51.3. Configuring Management-specific SSL 51.4. Customizing the Management Server Address 51.5. Disabling HTTP Endpoints 52. Monitoring and Management over JMX 52.1. Customizing MBean Names 52.2. Disabling JMX Endpoints 52.3. Using Jolokia for JMX over HTTP 52.3.1. Customizing Jolokia 52.3.2. Disabling Jolokia 53. Loggers 53.1. Configure a Logger 54. Metrics 54.1. Getting started 54.2. Supported monitoring systems 54.2.1. Atlas 54.2.2. Datadog 54.2.3. Ganglia 54.2.4. Graphite 54.2.5. Influx 54.2.6. JMX 54.2.7. New Relic 54.2.8. Prometheus 54.2.9. SignalFx 54.2.10. Simple 54.2.11. StatsD 54.2.12. Wavefront 54.3. Supported Metrics 54.3.1. Spring MVC Metrics 54.3.2. Spring WebFlux Metrics 54.3.3. RestTemplate Metrics 54.3.4. Cache Metrics 54.3.5. DataSource Metrics 54.3.6. RabbitMQ Metrics 54.4. Registering custom metrics 54.5. Customizing individual metrics 54.5.1. Per-meter properties 54.6. Metrics endpoint 55. Auditing 56. HTTP Tracing 56.1. Custom HTTP tracing 57. Process Monitoring 57.1. Extending Configuration 57.2. Programmatically 58. Cloud Foundry Support 58.1. Disabling Extended Cloud Foundry Actuator Support 58.2. Cloud Foundry Self-signed Certificates 58.3. Custom context path 59. What to Read Next VI. Deploying Spring Boot Applications 60. Deploying to the Cloud 60.1. Cloud Foundry 60.1.1. Binding to Services 60.2. Heroku 60.3. OpenShift 60.4. Amazon Web Services (AWS) 60.4.1. AWS Elastic Beanstalk Using the Tomcat Platform Using the Java SE Platform 60.4.2. Summary 60.5. Boxfuse and Amazon Web Services 60.6. Google Cloud 61. Installing Spring Boot Applications 61.1. Supported Operating Systems 61.2. Unix/Linux Services 61.2.1. Installation as an init.d Service (System V) Securing an init.d Service 61.2.2. Installation as a systemd Service 61.2.3. Customizing the Startup Script Customizing the Start Script when It Is Written Customizing a Script When It Runs 61.3. Microsoft Windows Services 62. What to Read Next VII. Spring Boot CLI 63. Installing the CLI 64. Using the CLI 64.1. Running Applications with the CLI 64.1.1. Deduced “grab” Dependencies 64.1.2. Deduced “grab” Coordinates 64.1.3. Default Import Statements 64.1.4. Automatic Main Method 64.1.5. Custom Dependency Management 64.2. Applications with Multiple Source Files 64.3. Packaging Your Application 64.4. Initialize a New Project 64.5. Using the Embedded Shell 64.6. Adding Extensions to the CLI 65. Developing Applications with the Groovy Beans DSL 66. Configuring the CLI with settings.xml 67. What to Read Next VIII. Build tool plugins 68. Spring Boot Maven Plugin 68.1. Including the Plugin 68.2. Packaging Executable Jar and War Files 69. Spring Boot Gradle Plugin 70. Spring Boot AntLib Module 70.1. Spring Boot Ant Tasks 70.1.1. spring-boot:exejar 70.1.2. Examples 70.2. spring-boot:findmainclass 70.2.1. Examples 71. Supporting Other Build Systems 71.1. Repackaging Archives 71.2. Nested Libraries 71.3. Finding a Main Class 71.4. Example Repackage Implementation 72. What to Read Next IX. ‘How-to’ guides 73. Spring Boot Application 73.1. Create Your Own FailureAnalyzer 73.2. Troubleshoot Auto-configuration 73.3. Customize the Environment or ApplicationContext Before It Starts 73.4. Build an ApplicationContext Hierarchy (Adding a Parent or Root Context) 73.5. Create a Non-web Application 74. Properties and Configuration 74.1. Automatically Expand Properties at Build Time 74.1.1. Automatic Property Expansion Using Maven 74.1.2. Automatic Property Expansion Using Gradle 74.2. Externalize the Configuration of SpringApplication 74.3. Change the Location of External Properties of an Application 74.4. Use ‘Short’ Command Line Arguments 74.5. Use YAML for External Properties 74.6. Set the Active Spring Profiles 74.7. Change Configuration Depending on the Environment 74.8. Discover Built-in Options for External Properties 75. Embedded Web Servers 75.1. Use Another Web Server 75.2. Disabling the Web Server 75.3. Configure Jetty 75.4. Add a Servlet, Filter, or Listener to an Application 75.4.1. Add a Servlet, Filter, or Listener by Using a Spring Bean Disable Registration of a Servlet or Filter 75.4.2. Add Servlets, Filters, and Listeners by Using Classpath Scanning 75.5. Change the HTTP Port 75.6. Use a Random Unassigned HTTP Port 75.7. Discover the HTTP Port at Runtime 75.8. Configure SSL 75.9. Configure HTTP/2 75.9.1. HTTP/2 with Undertow 75.9.2. HTTP/2 with Jetty 75.9.3. HTTP/2 with Tomcat 75.10. Configure Access Logging 75.11. Running Behind a Front-end Proxy Server 75.11.1. Customize Tomcat’s Proxy Configuration 75.12. Configure Tomcat 75.13. Enable Multiple Connectors with Tomcat 75.14. Use Tomcat’s LegacyCookieProcessor 75.15. Configure Undertow 75.16. Enable Multiple Listeners with Undertow 75.17. Create WebSocket Endpoints Using @ServerEndpoint 75.18. Enable HTTP Response Compression 76. Spring MVC 76.1. Write a JSON REST Service 76.2. Write an XML REST Service 76.3. Customize the Jackson ObjectMapper 76.4. Customize the @ResponseBody Rendering 76.5. Handling Multipart File Uploads 76.6. Switch Off the Spring MVC DispatcherServlet 76.7. Switch off the Default MVC Configuration 76.8. Customize ViewResolvers 77. HTTP Clients 77.1. Configure RestTemplate to Use a Proxy 78. Logging 78.1. Configure Logback for Logging 78.1.1. Configure Logback for File-only Output 78.2. Configure Log4j for Logging 78.2.1. Use YAML or JSON to Configure Log4j 2 79. Data Access 79.1. Configure a Custom DataSource 79.2. Configure Two DataSources 79.3. Use Spring Data Repositories 79.4. Separate @Entity Definitions from Spring Configuration 79.5. Configure JPA Properties 79.6. Configure Hibernate Naming Strategy 79.7. Use a Custom EntityManagerFactory 79.8. Use Two EntityManagers 79.9. Use a Traditional persistence.xml File 79.10. Use Spring Data JPA and Mongo Repositories 79.11. Expose Spring Data Repositories as REST Endpoint 79.12. Configure a Component that is Used by JPA 79.13. Configure jOOQ with Two DataSources 80. Database Initialization 80.1. Initialize a Database Using JPA 80.2. Initialize a Database Using Hibernate 80.3. Initialize a Database 80.4. Initialize a Spring Batch Database 80.5. Use a Higher-level Database Migration Tool 80.5.1. Execute Flyway Database Migrations on Startup 80.5.2. Execute Liquibase Database Migrations on Startup 81. Messaging 81.1. Disable Transacted JMS Session 82. Batch Applications 82.1. Execute Spring Batch Jobs on Startup 83. Actuator 83.1. Change the HTTP Port or Address of the Actuator Endpoints 83.2. Customize the ‘whitelabel’ Error Page 84. Security 84.1. Switch off the Spring Boot Security Configuration 84.2. Change the UserDetailsService and Add User Accounts 84.3. Enable HTTPS When Running behind a Proxy Server 85. Hot Swapping 85.1. Reload Static Content 85.2. Reload Templates without Restarting the Container 85.2.1. Thymeleaf Templates 85.2.2. FreeMarker Templates 85.2.3. Groovy Templates 85.3. Fast Application Restarts 85.4. Reload Java Classes without Restarting the Container 86. Build 86.1. Generate Build Information 86.2. Generate Git Information 86.3. Customize Dependency Versions 86.4. Create an Executable JAR with Maven 86.5. Use a Spring Boot Application as a Dependency 86.6. Extract Specific Libraries When an Executable Jar Runs 86.7. Create a Non-executable JAR with Exclusions 86.8. Remote Debug a Spring Boot Application Started with Maven 86.9. Build an Executable Archive from Ant without Using spring-boot-antlib 87. Traditional Deployment 87.1. Create a Deployable War File 87.2. Convert an Existing Application to Spring Boot 87.3. Deploying a WAR to WebLogic 87.4. Use Jedis Instead of Lettuce X. Appendices A. Common application properties B. Configuration Metadata B.1. Metadata Format B.1.1. Group Attributes B.1.2. Property Attributes B.1.3. Hint Attributes B.1.4. Repeated Metadata Items B.2. Providing Manual Hints B.2.1. Value Hint B.2.2. Value Providers Any Class Reference Handle As Logger Name Spring Bean Reference Spring Profile Name B.3. Generating Your Own Metadata by Using the Annotation Processor B.3.1. Nested Properties B.3.2. Adding Additional Metadata C. Auto-configuration classes C.1. From the “spring-boot-autoconfigure” module C.2. From the “spring-boot-actuator-autoconfigure” module D. Test auto-configuration annotations E. The Executable Jar Format E.1. Nested JARs E.1.1. The Executable Jar File Structure E.1.2. The Executable War File Structure E.2. Spring Boot’s “JarFile” Class E.2.1. Compatibility with the Standard Java “JarFile” E.3. Launching Executable Jars E.3.1. Launcher Manifest E.3.2. Exploded Archives E.4. PropertiesLauncher Features E.5. Executable Jar Restrictions E.6. Alternative Single Jar Solutions F. Dependency versions
A project model for the FreeBSD Project Niklas Saers Copyright © 2002-2005 Niklas Saers [ Split HTML / Single HTML ] Table of Contents Foreword 1 Overview 2 Definitions 2.1. Activity 2.2. Process 2.3. Hat 2.4. Outcome 2.5. FreeBSD 3 Organisational structure 4 Methodology model 4.1. Development model 4.2. Release branches 4.3. Model summary 5 Hats 5.1. General Hats 5.1.1. Contributor 5.1.2. Committer 5.1.3. Core Team 5.1.4. Maintainership 5.2. Official Hats 5.2.1. Documentation project manager 5.2.2. CVSup Mirror Site Coordinator 5.2.3. Internationalisation 5.2.4. Postmaster 5.2.5. Quality Assurance 5.2.6. Release Coordination 5.2.7. Public Relations & Corporate Liaison 5.2.8. Security Officer 5.2.9. Source Repository Manager 5.2.10. Election Manager 5.2.11. Web site Management 5.2.12. Ports Manager 5.2.13. Standards 5.2.14. Core Secretary 5.2.15. GNATS Administrator 5.2.16. Bugmeister 5.2.17. Donations Liaison Officer 5.2.18. Admin 5.3. Process dependent hats 5.3.1. Report originator 5.3.2. Bugbuster 5.3.3. Mentor 5.3.4. Vendor 5.3.5. Reviewers 5.3.6. CVSup Mirror Site Admin 6 Processes 6.1. Adding new and removing old committers 6.2. Adding/Removing an official CVSup Mirror 6.3. Committing code 6.4. Core election 6.5. Development of new features 6.6. Maintenance 6.7. Problem reporting 6.8. Reacting to misbehaviour 6.9. Release engineering 7 Tools 7.1. Concurrent Versions System (CVS) 7.2. CVSup 7.3. GNATS 7.4. Mailman 7.5. Perforce 7.6. Pretty Good Privacy 7.7. Secure Shell 8 Sub-projects 8.1. The Ports Subproject 8.2. The FreeBSD Documentation Project References List of Figures 3-1. The FreeBSD Project's structure 3-2. The FreeBSD Project's structure with committers in categories 4-1. Jørgenssen's model for change integration 4-2. The FreeBSD release tree 4-3. The overall development model 5-1. Overview of official hats 6-1. Process summary: adding a new committer 6-2. Process summary: removing a committer 6-3. Process summary: adding a CVSup mirror 6-4. Process summary: A committer commits code 6-5. Process summary: A contributor commits code 6-6. Process summary: Core elections 6-7. Jørgenssen's model for change integration 6-8. Process summary: problem reporting 6-9. Process summary: release engineering 8-1. Number of ports added between 1996 and 2005 Foreword Up until now, the FreeBSD project has released a number of described techniques to do different parts of work. However, a project model summarising how the project is structured is needed because of the increasing amount of project members. [1] This paper will provide such a project model and is donated to the FreeBSD Documentation project where it can evolve together with the project so that it can at any point in time reflect the way the project works. It is based on [Saers, 2003]. I would like to thank the following people for taking the time to explain things that were unclear to me and for proofreading the document. Andrey A. Chernov <[email protected]> Bruce A. Mah <[email protected]> Dag-Erling Smørgrav <[email protected]> Giorgos Keramidas<[email protected]> Ingvil Hovig <[email protected]> Jesper Holck<[email protected]> John Baldwin <[email protected]> John Polstra <[email protected]> Kirk McKusick <[email protected]> Mark Linimon <[email protected]> Marleen Devos Niels Jørgenssen<[email protected]> Nik Clayton <[email protected]> Poul-Henning Kamp <[email protected]> Simon L. Nielsen <[email protected]> Chapter 1 Overview A project model is a means to reduce the communications overhead in a project. As shown by [Brooks, 1995], increasing the number of project participants increases the communication in the project exponentionally. FreeBSD has during the past few year increased both its mass of active users and committers, and the communication in the project has risen accordingly. This project model will serve to reduce this overhead by providing an up-to-date description of the project. During the Core elections in 2002, Mark Murray stated “I am opposed to a long rule-book, as that satisfies lawyer-tendencies, and is counter to the technocentricity that the project so badly needs.” [FreeBSD, 2002B]. This project model is not meant to be a tool to justify creating impositions for developers, but as a tool to facilitate coordination. It is meant as a description of the project, with an overview of how the different processes are executed. It is an introduction to how the FreeBSD project works. The FreeBSD project model will be described as of July 1st, 2004. It is based on the Niels Jørgensen's paper [Jørgensen, 2001], FreeBSD's official documents, discussions on FreeBSD mailing lists and interviews with developers. After providing definitions of terms used, this document will outline the organisational structure (including role descriptions and communication lines), discuss the methodology model and after presenting the tools used for process control, it will present the defined processes. Finally it will outline major sub-projects of the FreeBSD project. [FreeBSD, 2002A, Section 1.2 and 1.3] give the vision and the architectural guidelines for the project. The vision is “To produce the best UNIX-like operating system package possible, with due respect to the original software tools ideology as well as usability, performance and stability.” The architectural guidelines help determine whether a problem that someone wants to be solved is within the scope of the project Chapter 2 Definitions 2.1. Activity An “activity” is an element of work performed during the course of a project [PMI, 2000]. It has an output and leads towards an outcome. Such an output can either be an input to another activity or a part of the process' delivery. 2.2. Process A “process” is a series of activities that lead towards a particular outcome. A process can consist of one or more sub-processes. An example of a process is software design. 2.3. Hat A “hat” is synonymous with role. A hat has certain responsibilities in a process and for the process outcome. The hat executes activities. It is well defined what issues the hat should be contacted about by the project members and people outside the project. 2.4. Outcome An “outcome” is the final output of the process. This is synonymous with deliverable, that is defined as “any measurable, tangible, verifiable outcome, result or item that must be produced to complete a project or part of a project. Often used more narrowly in reference to an external deliverable, which is a deliverable that is subject to approval by the project sponsor or customer” by [PMI, 2000]. Examples of outcomes are a piece of software, a decision made or a report written. 2.5. FreeBSD When saying “FreeBSD” we will mean the BSD derivative UNIX-like operating system FreeBSD, whereas when saying “the FreeBSD Project” we will mean the project organisation. Chapter 3 Organisational structure While no-one takes ownership of FreeBSD, the FreeBSD organisation is divided into core, committers and contributors and is part of the FreeBSD community that lives around it. Figure 3-1. The FreeBSD Project's structure Number of committers has been determined by going through CVS logs from January 1st, 2004 to December 31st, 2004 and contributors by going through the list of contributions and problem reports. The main resource in the FreeBSD community is its developers: the committers and contributors. It is with their contributions that the project can move forward. Regular developers are referred to as contributors. As by January 1st, 2003, there are an estimated 5500 contributors on the project. Committers are developers with the privilege of being able to commit changes. These are usually the most active developers who are willing to spend their time not only integrating their own code but integrating code submitted by the developers who do not have this privilege. They are also the developers who elect the core team, and they have access to closed discussions. The project can be grouped into four distinct separate parts, and most developers will focus their involvement in one part of FreeBSD. The four parts are kernel development, userland development, ports and documentation. When referring to the base system, both kernel and userland is meant. This split changes our triangle to look like this: Figure 3-2. The FreeBSD Project's structure with committers in categories Number of committers per area has been determined by going through CVS logs from January 1st, 2004 to December 31st, 2004. Note that many committers work in multiple areas, making the total number higher than the real number of committers. The total number of committers at that time was 269. Committers fall into three groups: committers who are only concerned with one area of the project (for instance file systems), committers who are involved only with one sub-project and committers who commit to different parts of the code, including sub-projects. Because some committers work on different parts, the total number in the committers section of the triangle is higher than in the above triangle. The kernel is the main building block of FreeBSD. While the userland applications are protected against faults in other userland applications, the entire system is vulnerable to errors in the kernel. This, combined with the vast amount of dependencies in the kernel and that it is not easy to see all the consequences of a kernel change, demands developers with a relative full understanding of the kernel. Multiple development efforts in the kernel also requires a closer coordination than userland applications do. The core utilities, known as userland, provide the interface that identifies FreeBSD, both user interface, shared libraries and external interfaces to connecting clients. Currently, 162 people are involved in userland development and maintenance, many being maintainers for their own part of the code. Maintainership will be discussed in the Maintainership section. Documentation is handled by The FreeBSD Documentation Project and includes all documents surrounding the FreeBSD project, including the web pages. There were during 2004 101 people making commits to the FreeBSD Documentation Project. Ports is the collection of meta-data that is needed to make software packages build correctly on FreeBSD. An example of a port is the port for the web-browser Mozilla. It contains information about where to fetch the source, what patches to apply and how, and how the package should be installed on the system. This allows automated tools to fetch, build and install the package. As of this writing, there are more than 12600 ports available. [2] , ranging from web servers to games, programming languages and most of the application types that are in use on modern computers. Ports will be discussed further in the section The Ports Subproject. Chapter 4 Methodology model 4.1. Development model There is no defined model for how people write code in FreeBSD. However, Niels Jørgenssen has suggested a model of how written code is integrated into the project. Figure 4-1. Jørgenssen's model for change integration The “development release” is the FreeBSD-CURRENT ("-CURRENT") branch and the “production release” is the FreeBSD-STABLE branch ("-STABLE") [Jørgensen, 2001]. This is a model for one change, and shows that after coding, developers seek community review and try integrating it with their own systems. After integrating the change into the development release, called FreeBSD-CURRENT, it is tested by many users and developers in the FreeBSD community. After it has gone through enough testing, it is merged into the production release, called FreeBSD-STABLE. Unless each stage is finished successfully, the developer needs to go back and make modifications in the code and restart the process. To integrate a change with either -CURRENT or -STABLE is called making a commit. Jørgensen found that most FreeBSD developers work individually, meaning that this model is used in parallel by many developers on the different ongoing development efforts. A developer can also be working on multiple changes, so that while he is waiting for review or people to test one or more of his changes, he may be writing another change. As each commit represents an increment, this is a massively incremental model. The commits are in fact so frequent that during one year [3] , 85427 commits were made, making a daily average of 233 commits. Within the “code” bracket in Jørgensen's figure, each programmer has his own working style and follows his own development models. The bracket could very well have been called “development” as it includes requirements gathering and analysis, system and detailed design, implementation and verification. However, the only output from these stages is the source code or system documentation. From a stepwise model's perspective (such as the waterfall model), the other brackets can be seen as further verification and system integration. This system integration is also important to see if a change is accepted by the community. Up until the code is committed, the developer is free to choose how much to communicate about it to the rest of the project. In order for -CURRENT to work as a buffer (so that bright ideas that had some undiscovered drawbacks can be backed out) the minimum time a commit should be in -CURRENT before merging it to -STABLE is 3 days. Such a merge is referred to as an MFC (Merge From Current). It is important to notice the word “change”. Most commits do not contain radical new features, but are maintenance updates. The only exceptions from this model are security fixes and changes to features that are deprecated in the -CURRENT branch. In these cases, changes can be committed directly to the -STABLE branch. In addition to many people working on the project, there are many related projects to the FreeBSD Project. These are either projects developing brand new features, sub-projects or projects whose outcome is incorporated into FreeBSD [4]. These projects fit into the FreeBSD Project just like regular development efforts: they produce code that is integrated with the FreeBSD Project. However, some of them (like Ports and Documentation) have the privilege of being applicable to both branches or commit directly to both -CURRENT and -STABLE. There is no standards to how design should be done, nor is design collected in a centralised repository. The main design is that of 4.4BSD. [5] As design is a part of the “Code” bracket in Jørgenssen's model, it is up to every developer or sub-project how this should be done. Even if the design should be stored in a central repository, the output from the design stages would be of limited use as the differences of methodologies would make them poorly if at all interoperable. For the overall design of the project, the project relies on the sub-projects to negotiate fit interfaces between each other rather than to dictate interfacing. 4.2. Release branches The releases of FreeBSD is best illustrated by a tree with many branches where each major branch represents a major version. Minor versions are represented by branches of the major branches. In the following release tree, arrows that follow one-another in a particular direction represent a branch. Boxes with full lines and diamonds represent official releases. Boxes with dotted lines represent the development branch at that time. Security branches are represented by ovals. Diamonds differ from boxes in that they represent a fork, meaning a place where a branch splits into two branches where one of the branches becomes a sub-branch. For example, at 4.0-RELEASE the 4.0-CURRENT branch split into 4-STABLE and 5.0-CURRENT. At 4.5-RELEASE, the branch forked off a security branch called RELENG_4_5. Figure 4-2. The FreeBSD release tree The latest -CURRENT version is always referred to as -CURRENT, while the latest -STABLE release is always referred to as -STABLE. In this figure, -STABLE refers to 4-STABLE while -CURRENT refers to 5.0-CURRENT following 5.0-RELEASE. [FreeBSD, 2002E] A “major release” is always made from the -CURRENT branch. However, the -CURRENT branch does not need to fork at that point in time, but can focus on stabilising. An example of this is that following 3.0-RELEASE, 3.1-RELEASE was also a continuation of the -CURRENT-branch, and -CURRENT did not become a true development branch until this version was released and the 3-STABLE branch was forked. When -CURRENT returns to becoming a development branch, it can only be followed by a major release. 5-STABLE is predicted to be forked off 5.0-CURRENT at around 5.3-RELEASE. It is not until 5-STABLE is forked that the development branch will be branded 6.0-CURRENT. A “minor release” is made from the -CURRENT branch following a major release, or from the -STABLE branch. Following and including, 4.3-RELEASE[6], when a minor release has been made, it becomes a “security branch”. This is meant for organisations that do not want to follow the -STABLE branch and the potential new/changed features it offers, but instead require an absolutely stable environment, only updating to implement security updates. [7] Each update to a security branch is called a “patchlevel”. For every security enhancement that is done, the patchlevel number is increased, making it easy for people tracking the branch to see what security enhancements they have implemented. In cases where there have been especially serious security flaws, an entire new release can be made from a security branch. An example of this is 4.6.2-RELEASE. 4.3. Model summary To summarise, the development model of FreeBSD can be seen as the following tree: Figure 4-3. The overall development model The tree of the FreeBSD development with ongoing development efforts and continuous integration. The tree symbolises the release versions with major versions spawning new main branches and minor versions being versions of the main branch. The top branch is the -CURRENT branch where all new development is integrated, and the -STABLE branch is the branch directly below it. Clouds of development efforts hang over the project where developers use the development models they see fit. The product of their work is then integrated into -CURRENT where it undergoes parallel debugging and is finally merged from -CURRENT into -STABLE. Security fixes are merged from -STABLE to the security branches. Chapter 5 Hats Many committers have a special area of responsibility. These roles are called hats [Losh, 2002]. These hats can be either project roles, such as public relations officer, or maintainer for a certain area of the code. Because this is a project where people give voluntarily of their spare time, people with assigned hats are not always available. They must therefore appoint a deputy that can perform the hat's role in his or her absence. The other option is to have the role held by a group. Many of these hats are not formalised. Formalised hats have a charter stating the exact purpose of the hat along with its privileges and responsibilities. The writing of such charters is a new part of the project, and has thus yet to be completed for all hats. These hat descriptions are not such a formalisation, rather a summary of the role with links to the charter where available and contact addresses, 5.1. General Hats 5.1.1. Contributor A Contributor contributes to the FreeBSD project either as a developer, as an author, by sending problem reports, or in other ways contributing to the progress of the project. A contributor has no special privileges in the FreeBSD project. [FreeBSD, 2002F] 5.1.2. Committer A person who has the required privileges to add his code or documentation to the repository. A committer has made a commit within the past 12 months. [FreeBSD, 2000A] An active committer is a committer who has made an average of one commit per month during that time. It is worth noting that there are no technical barriers to prevent someone, once having gained commit privileges to the main- or a sub-project, to make commits in parts of that project's source the committer did not specifically get permission to modify. However, when wanting to make modifications to parts a committer has not been involved in before, he/she should read the logs to see what has happened in this area before, and also read the MAINTAINER file to see if the maintainer of this part has any special requests on how changes in the code should be made 5.1.3. Core Team The core team is elected by the committers from the pool of committers and serves as the board of directors of the FreeBSD project. It promotes active contributors to committers, assigns people to well-defined hats, and is the final arbiter of decisions involving which way the project should be heading. As by July 1st, 2004, core consisted of 9 members. Elections are held every two years. 5.1.4. Maintainership Maintainership means that that person is responsible for what is allowed to go into that area of the code and has the final say should disagreements over the code occur. This involves involves proactive work aimed at stimulating contributions and reactive work in reviewing commits. With the FreeBSD source comes the MAINTAINERS file that contains a one-line summary of how each maintainer would like contributions to be made. Having this notice and contact information enables developers to focus on the development effort rather than being stuck in a slow correspondence should the maintainer be unavailable for some time. If the maintainer is unavailable for an unreasonably long period of time, and other people do a significant amount of work, maintainership may be switched without the maintainer's approval. This is based on the stance that maintainership should be demonstrated, not declared. Maintainership of a particular piece of code is a hat that is not held as a group. 5.2. Official Hats The official hats in the FreeBSD Project are hats that are more or less formalised and mainly administrative roles. They have the authority and responsibility for their area. The following illustration shows the responsibility lines. After this follows a description of each hat, including who it is held by. Figure 5-1. Overview of official hats All boxes consist of groups of committers, except for the dotted boxes where the holders are not necessarily committers. The flattened circles are sub-projects and consist of both committers and non-committers of the main project. 5.2.1. Documentation project manager The FreeBSD Documentation Project architect is responsible for defining and following up documentation goals for the committers in the Documentation project. Hat held by: The DocEng team <[email protected]>. The DocEng Charter. 5.2.2. CVSup Mirror Site Coordinator The CVSup Mirror Site Coordinator coordinates all the CVSup Mirror Site Admins to ensure that they are distributing current versions of the software, that they have the capacity to update themselves when major updates are in progress, and making it easy for the general public to find their closest CVSup mirror. Hat currently held by: John Polstra <[email protected]>. 5.2.3. Internationalisation The Internationalisation hat is responsible for coordinating the localisation efforts of the FreeBSD kernel and userland utilities. The translation effort are coordinated by The FreeBSD Documentation Project. The Internationalisation hat should suggest and promote standards and guidelines for writing and maintaining the software in a fashion that makes it easier to translate. Hat currently available. 5.2.4. Postmaster The Postmaster is responsible for mail being correctly delivered to the committers' email address. He is also responsible for ensuring that the mailing lists work and should take measures against possible disruptions of mail such as having troll-, spam- and virus-filters. Hat currently held by: David Wolfskill <[email protected]>. 5.2.5. Quality Assurance The responsibilities of this role are to manage the quality assurance measures. Hat currently held by: Robert Watson <[email protected]>. 5.2.6. Release Coordination The responsibilities of the Release Engineering Team are Setting, publishing and following a release schedule for official releases Documenting and formalising release engineering procedures Creation and maintenance of code branches Coordinating with the Ports and Documentation teams to have an updated set of packages and documentation released with the new releases Coordinating with the Security team so that pending releases are not affected by recently disclosed vulnerabilities. Further information about the development process is available in the release engineering section. Hat held by: the Release Engineering team <[email protected]>, currently headed by Murray Stokely <[email protected]>. The Release Engineering Charter. 5.2.7. Public Relations & Corporate Liaison The Public Relations & Corporate Liaison's responsibilities are: Making press statements when happenings that are important to the FreeBSD Project happen. Being the official contact person for corporations that are working close with the FreeBSD Project. Take steps to promote FreeBSD within both the Open Source community and the corporate world. Handle the “freebsd-advocacy” mailing list. This hat is currently not occupied. 5.2.8. Security Officer The Security Officer's main responsibility is to coordinate information exchange with others in the security community and in the FreeBSD project. The Security Officer is also responsible for taking action when security problems are reported and promoting proactive development behaviour when it comes to security. Because of the fear that information about vulnerabilities may leak out to people with malicious intent before a patch is available, only the Security Officer, consisting of an officer, a deputy and two Core team members, receive sensitive information about security issues. However, to create or implement a patch, the Security Officer has the Security Officer Team <[email protected]> to help do the work. Hat held by: the Security Officer <[email protected]>, currently headed by Colin Percival <[email protected]>. The Security Officer and The Security Officer Team's charter. 5.2.9. Source Repository Manager The Source Repository Manager is the only one who is allowed to directly modify the repository without using the CVS tool. It is his/her responsibility to ensure that technical problems that arise in the repository are resolved quickly. The source repository manager has the authority to back out commits if this is necessary to resolve a CVS technical problem. Hat held by: the Source Repository Manager <[email protected]>, currently headed by Peter Wemm <[email protected]>. 5.2.10. Election Manager The Election Manager is responsible for the Core election process. The manager is responsible for running and maintaining the election system, and is the final authority should minor unforseen events happen in the election process. Major unforseen events have to be discussed with the Core team Hat held only during elections. 5.2.11. Web site Management The Web site Management hat is responsible for coordinating the rollout of updated web pages on mirrors around the world, for the overall structure of the primary web site and the system it is running upon. The management needs to coordinate the content with The FreeBSD Documentation Project and acts as maintainer for the “www” tree. Hat held by: the FreeBSD Webmasters <[email protected]>. 5.2.12. Ports Manager The Ports Manager acts as a liaison between The Ports Subproject and the core project, and all requests from the project should go to the ports manager. Hat held by: the Ports Management Team <[email protected]>, 5.2.13. Standards The Standards hat is responsible for ensuring that FreeBSD complies with the standards it is committed to , keeping up to date on the development of these standards and notifying FreeBSD developers of important changes that allows them to take a proactive role and decrease the time between a standards update and FreeBSD's compliancy. Hat currently held by: Garrett Wollman <[email protected]>. 5.2.14. Core Secretary The Core Secretary's main responsibility is to write drafts to and publish the final Core Reports. The secretary also keeps the core agenda, thus ensuring that no balls are dropped unresolved. Hat currently held by: Joel Dahl <[email protected]>. 5.2.15. GNATS Administrator The GNATS Administrator is responsible for ensuring that the maintenance database is in working order, that the entries are correctly categorised and that there are no invalid entries. Hat currently held by: Ceri Davies <[email protected]> and Mark Linimon <[email protected]>. 5.2.16. Bugmeister The Bugmeister is the person in charge of the problem report group. Hat currently held by: Ceri Davies <[email protected]> and Mark Linimon <[email protected]>. 5.2.17. Donations Liaison Officer The task of the donations liason officer is to match the developers with needs with people or organisations willing to make a donation. The Donations Liason Charter is available here Hat held by: the Donations Liaison Office <[email protected]>, currently headed by Michael W. Lucas <[email protected]>. 5.2.18. Admin (Also called “FreeBSD Cluster Admin”) The admin team consists of the people responsible for administrating the computers that the project relies on for its distributed work and communication to be synchronised. It consists mainly of those people who have physical access to the servers. Hat held by: the Admin team <[email protected]>, currently headed by Mark Murray <[email protected]> 5.3. Process dependent hats 5.3.1. Report originator The person originally responsible for filing a Problem Report. 5.3.2. Bugbuster A person who will either find the right person to solve the problem, or close the PR if it is a duplicate or otherwise not an interesting one. 5.3.3. Mentor A mentor is a committer who takes it upon him/her to introduce a new committer to the project, both in terms of ensuring the new committers setup is valid, that the new committer knows the available tools required in his/her work and that the new committer knows what is expected of him/her in terms of behaviour. 5.3.4. Vendor The person(s) or organisation whom external code comes from and whom patches are sent to. 5.3.5. Reviewers People on the mailing list where the request for review is posted. 5.3.6. CVSup Mirror Site Admin A CVSup Mirror Site Admin has accesses to a server that he/she uses to mirror the CVS repository. The admin works with the CVSup Mirror Site Coordinator to ensure the site remains up-to-date and is following the general policy of official mirror sites. Chapter 6 Processes The following section will describe the defined project processes. Issues that are not handled by these processes happen on an ad-hoc basis based on what has been customary to do in similar cases. 6.1. Adding new and removing old committers The Core team has the responsibility of giving and removing commit privileges to contributors. This can only be done through a vote on the core mailing list. The ports and documentation sub-projects can give commit privileges to people working on these projects, but have to date not removed such privileges. Normally a contributor is recommended to core by a committer. For contributors or outsiders to contact core asking to be a committer is not well thought of and is usually rejected. If the area of particular interest for the developer potentially overlaps with other committers' area of maintainership, the opinion of those maintainers is sought. However, it is frequently this committer that recommends the developer. When a contributor is given committer status, he is assigned a mentor. The committer who recommended the new committer will, in the general case, take it upon himself to be the new committers mentor. When a contributor is given his commit bit, a PGP-signed email is sent from either Core Secretary, Ports Manager or [email protected] to both [email protected], the assigned mentor, the new committer and core confirming the approval of a new account. The mentor then gathers a password line, SSH 2 public key and PGP key from the new committer and sends them to Admin. When the new account is created, the mentor activates the commit bit and guides the new committer through the rest of the initial process. Figure 6-1. Process summary: adding a new committer When a contributor sends a piece of code, the receiving committer may choose to recommend that the contributor is given commit privileges. If he recommends this to core, they will vote on this recommendation. If they vote in favour, a mentor is assigned the new committer and the new committer has to email his details to the administrators for an account to be created. After this, the new committer is all set to make his first commit. By tradition, this is by adding his name to the committers list. Recall that a committer is considered to be someone who has committed code during the past 12 months. However, it is not until after 18 months of inactivity have passed that commit privileges are eligible to be revoked. [FreeBSD, 2002H] There are, however, no automatic procedures for doing this. For reactions concerning commit privileges not triggered by time, see section 1.5.8. Figure 6-2. Process summary: removing a committer When Core decides to clean up the committers list, they check who has not made a commit for the past 18 months. Committers who have not done so have their commit bits revoked. It is also possible for committers to request that their commit bit be retired if for some reason they are no longer going to be actively committing to the project. In this case, it can also be restored at a later time by core, should the committer ask. Roles in this process: Core team Contributor Committer Maintainership Mentor [FreeBSD, 2000A] [FreeBSD, 2002H] [FreeBSD, 2002I] 6.2. Adding/Removing an official CVSup Mirror A CVSup mirror is a replica of the official CVSup master that contains all the up-to-date source code for all the branches in the FreeBSD project, ports and documentation. Adding an official CVSup mirror starts with the potential CVSup Mirror Site Admin installing the “cvsup-mirror” package. Having done this and updated the source code with a mirror site, he now runs a fairly recent unofficial CVSup mirror. Deciding he has a stable environment, the processing power, the network capacity and the storage capacity to run an official mirror, he mails the CVSup Mirror Site Coordinator who decides whether the mirror should become an official mirror or not. In making this decision, the CVSup Mirror Site Coordinator has to determine whether that geographical area needs another mirror site, if the mirror administrator has the skills to run it reliably, if the network bandwidth is adequate and if the master server has the capacity to server another mirror. If CVSup Mirror Site Coordinator decides that the mirror should become an official mirror, he obtains an authentication key from the mirror admin that he installs so the mirror admin can update the mirror from the master server. Figure 6-3. Process summary: adding a CVSup mirror When a CVSup mirror administrator of an unofficial mirror offers to become an official mirror site, the CVSup coordinator decides if another mirror is needed and if there is sufficient capacity to accommodate it. If so, an authorisation key is requested and the mirror is given access to the main distribution site and added to the list of official mirrors. Tools used in this process: CVSup SSH 2 Hats involved in this process: CVSup Mirror Site Coordinator CVSup Mirror Site Admin 6.3. Committing code The committing of new or modified code is one of the most frequent processes in the FreeBSD project and will usually happen many times a day. Committing of code can only be done by a “committer”. Committers commit either code written by themselves, code submitted to them or code submitted through a problem report. When code is written by the developer that is non-trivial, he should seek a code review from the community. This is done by sending mail to the relevant list asking for review. Before submitting the code for review, he should ensure it compiles correctly with the entire tree and that all relevant tests run. This is called “pre-commit test”. When contributed code is received, it should be reviewed by the committer and tested the same way. When a change is committed to a part of the source that has been contributed from an outside Vendor, the maintainer should ensure that the patch is contributed back to the vendor. This is in line with the open source philosophy and makes it easier to stay in sync with outside projects as the patches do not have to be reapplied every time a new release is made. After the code has been available for review and no further changes are necessary, the code is committed into the development branch, -CURRENT. If the change applies for the -STABLE branch or the other branches as well, a “Merge From Current” ("MFC") countdown is set by the committer. After the number of days the committer chose when setting the MFC have passed, an email will automatically be sent to the committer reminding him to commit it to the -STABLE branch (and possibly security branches as well). Only security critical changes should be merged to security branches. Delaying the commit to -STABLE and other branches allows for “parallel debugging” where the committed code is tested on a wide range of configurations. This makes changes to -STABLE to contain fewer faults and thus giving the branch its name. Figure 6-4. Process summary: A committer commits code When a committer has written a piece of code and wants to commit it, he first needs to determine if it is trivial enough to go in without prior review or if it should first be reviewed by the developer community. If the code is trivial or has been reviewed and the committer is not the maintainer, he should consult the maintainer before proceeding. If the code is contributed by an outside vendor, the maintainer should create a patch that is sent back to the vendor. The code is then committed and the deployed by the users. Should they find problems with the code, this will be reported and the committer can go back to writing a patch. If a vendor is affected, he can choose to implement or ignore the patch. Figure 6-5. Process summary: A contributor commits code The difference when a contributor makes a code contribution is that he submits the code through the send-pr program. This report is picked up by the maintainer who reviews the code and commits it. Hats included in this process are: Committer Contributor Vendor Reviewer [FreeBSD, 2001] [Jørgensen, 2001] 6.4. Core election Core elections are held at least every two years. [8] Nine core members are elected. New elections are held if the number of core members drops below seven. New elections can also be held should at least 1/3 of the active committers demand this. When an election is to take place, core announces this at least 6 weeks in advance, and appoints an election manager to run the elections. Only committers can be elected into core. The candidates need to submit their candidacy at least one week before the election starts, but can refine their statements until the voting starts. They are presented in the candidates list. When writing their election statements, the candidates must answer a few standard questions submitted by the election manager. During elections, the rule that a committer must have committed during the 12 past months is followed strictly. Only these committers are eligible to vote. When voting, the committer may vote once in support of up to nine nominees. The voting is done over a period of four weeks with reminders being posted on “developers” mailing list that is available to all committers. The election results are released one week after the election ends, and the new core team takes office one week after the results have been posted. Should there be a voting tie, this will be resolved by the new, unambiguously elected core members. Votes and candidate statements are archived, but the archives are not publicly available. Figure 6-6. Process summary: Core elections Core announces the election and selects an election manager. He prepares the elections, and when ready, candidates can announce their candidacies through submitting their statements. The committers then vote. After the vote is over, the election results are announced and the new core team takes office. Hats in core elections are: Core team Committer Election Manager [FreeBSD, 2000A] [FreeBSD, 2002B] [FreeBSD, 2002G] 6.5. Development of new features Within the project there are sub-projects that are working on new features. These projects are generally done by one person [Jørgensen, 2001]. Every project is free to organise development as it sees fit. However, when the project is merged to the -CURRENT branch it must follow the project guidelines. When the code has been well tested in the -CURRENT branch and deemed stable enough and relevant to the -STABLE branch, it is merged to the -STABLE branch. The requirements of the project are given by developer wishes, requests from the community in terms of direct requests by mail, Problem Reports, commercial funding for the development of features, or contributions by the scientific community. The wishes that come within the responsibility of a developer are given to that developer who prioritises his time between the request and his wishes. A common way to do this is maintain a TODO-list maintained by the project. Items that do not come within someone's responsibility are collected on TODO-lists unless someone volunteers to take the responsibility. All requests, their distribution and follow-up are handled by the GNATS tool. Requirements analysis happens in two ways. The requests that come in are discussed on mailing lists, both within the main project and in the sub-project that the request belongs to or is spawned by the request. Furthermore, individual developers on the sub-project will evaluate the feasibility of the requests and determine the prioritisation between them. Other than archives of the discussions that have taken place, no outcome is created by this phase that is merged into the main project. As the requests are prioritised by the individual developers on the basis of doing what they find interesting, necessary or are funded to do, there is no overall strategy or priorisation of what requests to regard as requirements and following up their correct implementation. However, most developers have some shared vision of what issues are more important, and they can ask for guidelines from the release engineering team. The verification phase of the project is two-fold. Before committing code to the current-branch, developers request their code to be reviewed by their peers. This review is for the most part done by functional testing, but also code review is important. When the code is committed to the branch, a broader functional testing will happen, that may trigger further code review and debugging should the code not behave as expected. This second verification form may be regarded as structural verification. Although the sub-projects themselves may write formal tests such as unit tests, these are usually not collected by the main project and are usually removed before the code is committed to the current branch. [9] 6.6. Maintenance It is an advantage to the project to for each area of the source have at least one person that knows this area well. Some parts of the code have designated maintainers. Others have de-facto maintainers, and some parts of the system do not have maintainers. The maintainer is usually a person from the sub-project that wrote and integrated the code, or someone who has ported it from the platform it was written for. [10] The maintainer's job is to make sure the code is in sync with the project the code comes from if it is contributed code, and apply patches submitted by the community or write fixes to issues that are discovered. The main bulk of work that is put into the FreeBSD project is maintenance. [Jørgensen, 2001] has made a figure showing the life cycle of changes. Figure 6-7. Jørgenssen's model for change integration Here “development release” refers to the -CURRENT branch while “production release” refers to the -STABLE branch. The “pre-commit test” is the functional testing by peer developers when asked to do so or trying out the code to determine the status of the sub-project. “Parallel debugging” is the functional testing that can trigger more review, and debugging when the code is included in the -CURRENT branch. As of this writing, there were 269 committers in the project. When they commit a change to a branch, that constitutes a new release. It is very common for users in the community to track a particular branch. The immediate existence of a new release makes the changes widely available right away and allows for rapid feedback from the community. This also gives the community the response time they expect on issues that are of importance to them. This makes the community more engaged, and thus allows for more and better feedback that again spurs more maintenance and ultimately should create a better product. Before making changes to code in parts of the tree that has a history unknown to the committer, the committer is required to read the commit logs to see why certain features are implemented the way they are in order not to make mistakes that have previously either been thought through or resolved. 6.7. Problem reporting FreeBSD comes with a problem reporting tool called “send-pr” that is a part of the GNATS package. All users and developers are encouraged to use this tool for reporting problems in software they do not maintain. Problems include bug reports, feature requests, features that should be enhanced and notices of new versions of external software that is included in the project. Problem reports are sent to an email address where it is inserted into the GNATS maintenance database. A Bugbuster classifies the problem and sends it to the correct group or maintainer within the project. After someone has taken responsibility for the report, the report is being analysed. This analysis includes verifying the problem and thinking out a solution for the problem. Often feedback is required from the report originator or even from the FreeBSD community. Once a patch for the problem is made, the originator may be asked to try it out. Finally, the working patch is integrated into the project, and documented if applicable. It there goes through the regular maintenance cycle as described in section maintenance. These are the states a problem report can be in: open, analyzed, feedback, patched, suspended and closed. The suspended state is for when further progress is not possible due to the lack of information or for when the task would require so much work that nobody is working on it at the moment. Figure 6-8. Process summary: problem reporting A problem is reported by the report originator. It is then classified by a bugbuster and handed to the correct maintainer. He verifies the problem and discusses the problem with the originator until he has enough information to create a working patch. This patch is then committed and the problem report is closed. The roles included in this process are: Report originator Maintainership Bugbuster [FreeBSD, 2002C]. [FreeBSD, 2002D] 6.8. Reacting to misbehaviour [FreeBSD, 2001] has a number of rules that committers should follow. However, it happens that these rules are broken. The following rules exist in order to be able to react to misbehaviour. They specify what actions will result in how long a suspension the committer's commit privileges. Committing during code freezes without the approval of the Release Engineering team - 2 days Committing to a security branch without approval - 2 days Commit wars - 5 days to all participating parties Impolite or inappropriate behaviour - 5 days [Lehey, 2002] For the suspensions to be efficient, any single core member can implement a suspension before discussing it on the “core” mailing list. Repeat offenders can, with a 2/3 vote by core, receive harsher penalties, including permanent removal of commit privileges. (However, the latter is always viewed as a last resort, due to its inherent tendency to create controversy). All suspensions are posted to the “developers” mailing list, a list available to committers only. It is important that you cannot be suspended for making technical errors. All penalties come from breaking social etiquette. Hats involved in this process: Core team Committer 6.9. Release engineering The FreeBSD project has a Release Engineering team with a principal release engineer that is responsible for creating releases of FreeBSD that can be brought out to the user community via the net or sold in retail outlets. Since FreeBSD is available on multiple platforms and releases for the different architectures are made available at the same time, the team has one person in charge of each architecture. Also, there are roles in the team responsible for coordinating quality assurance efforts, building a package set and for having an updated set of documents. When referring to the release engineer, a representative for the release engineering team is meant. When a release is coming, the FreeBSD project changes shape somewhat. A release schedule is made containing feature- and code-freezes, release of interim releases and the final release. A feature-freeze means no new features are allowed to be committed to the branch without the release engineers' explicit consent. Code-freeze means no changes to the code (like bugs-fixes) are allowed to be committed without the release engineers explicit consent. This feature- and code-freeze is known as stabilising. During the release process, the release engineer has the full authority to revert to older versions of code and thus "back out" changes should he find that the changes are not suitable to be included in the release. There are three different kinds of releases: .0 releases are the first release of a major version. These are branched of the -CURRENT branch and have a significantly longer release engineering cycle due to the unstable nature of the -CURRENT branch .X releases are releases of the -STABLE branch. They are scheduled to come out every 4 months. .X.Y releases are security releases that follow the .X branch. These come out only when sufficient security fixes have been merged since the last release on that branch. New features are rarely included, and the security team is far more involved in these than in regular releases. For releases of the -STABLE-branch, the release process starts 45 days before the anticipated release date. During the first phase, the first 15 days, the developers merge what changes they have had in -CURRENT that they want to have in the release to the release branch. When this period is over, the code enters a 15 day code freeze in which only bug fixes, documentation updates, security-related fixes and minor device driver changes are allowed. These changes must be approved by the release engineer in advance. At the beginning of the last 15 day period a release candidate is created for widespread testing. Updates are less likely to be allowed during this period, except for important bug fixes and security updates. In this final period, all releases are considered release candidates. At the end of the release process, a release is created with the new version number, including binary distributions on web sites and the creation of a CD-ROM images. However, the release is not considered "really released" until a PGP-signed message stating exactly that, is sent to the mailing list freebsd-announce; anything labelled as a "release" before that may well be in-process and subject to change before the PGP-signed message is sent. [11]. The releases of the -CURRENT-branch (that is, all releases that end with “.0”) are very similar, but with twice as long timeframe. It starts 8 weeks prior to the release with announcement of the release time line. Two weeks into the release process, the feature freeze is initiated and performance tweaks should be kept to a minimum. Four weeks prior to the release, an official beta version is made available. Two weeks prior to release, the code is officially branched into a new version. This version is given release candidate status, and as with the release engineering of -STABLE, the code freeze of the release candidate is hardened. However, development on the main development branch can continue. Other than these differences, the release engineering processes are alike. .0 releases go into their own branch and are aimed mainly at early adopters. The branch then goes through a period of stabilisation, and it is not until the Release Engineering Team> decides the demands to stability have been satisfied that the branch becomes -STABLE and -CURRENT targets the next major version. While this for the majority has been with .1 versions, this is not a demand. Most releases are made when a given date that has been deemed a long enough time since the previous release comes. A target is set for having major releases every 18 months and minor releases every 4 months. The user community has made it very clear that security and stability cannot be sacrificed by self-imposed deadlines and target release dates. For slips of time not to become too long with regards to security and stability issues, extra discipline is required when committing changes to -STABLE. Figure 6-9. Process summary: release engineering These are the stages in the release engineering process. Multiple release candidates may be created until the release is deemed stable enough to be released. [FreeBSD, 2002E] Chapter 7 Tools The major support tools for supporting the development process are CVS, CVSup, Perforce, GNATS, Mailman and OpenSSH. Except for CVSup, these are externally developed tools. These tools are commonly used in the open source world. 7.1. Concurrent Versions System (CVS) Concurrent Versions System or simply “CVS” is a system to handle multiple versions of text files and tracking who committed what changes and why. A project lives within a “repository” and different versions are considered different “branches”. 7.2. CVSup CVSup is a software package for distributing and updating collections of files across a network. It consists of a client program, cvsup, and a server program, cvsupd. The package is tailored specifically for distributing CVS repositories, and by taking advantage of CVS' properties, it performs updates much faster than traditional systems. 7.3. GNATS GNATS is a maintenance database consisting of a set of tools to track bugs at a central site. It supports the bug tracking process for sending and handling bugs as well as querying and updating the database and editing bug reports. The project uses one of its many client interfaces, “send-pr”, to send “Problem Reports” by email to the projects central GNATS server. The committers have also web and command-line clients available. 7.4. Mailman Mailman is a program that automates the management of mailing lists. The FreeBSD Project uses it to run 16 general lists, 60 technical lists, 4 limited lists and 5 lists with CVS commit logs. It is also used for many mailing lists set up and used by other people and projects in the FreeBSD community. General lists are lists for the general public, technical lists are mainly for the development of specific areas of interest, and closed lists are for internal communication not intended for the general public. The majority of all the communication in the project goes through these 85 lists [FreeBSD, 2003A, Appendix C]. 7.5. Perforce Perforce is a commercial software configuration management system developed by Perforce Systems that is available on over 50 operating systems. It is a collection of clients built around the Perforce server that contains the central file repository and tracks the operations done upon it. The clients are both clients for accessing the repository and administration of its configuration. 7.6. Pretty Good Privacy Pretty Good Privacy, better known as PGP, is a cryptosystem using a public key architecture to allow people to digitally sign and/or encrypt information in order to ensure secure communication between two parties. A signature is used when sending information out many recipients, enabling them to verify that the information has not been tampered with before they received it. In the FreeBSD Project this is the primary means of ensuring that information has been written by the person who claims to have written it, and not altered in transit. 7.7. Secure Shell Secure Shell is a standard for securely logging into a remote system and for executing commands on the remote system. It allows other connections, called tunnels, to be established and protected between the two involved systems. This standard exists in two primary versions, and only version two is used for the FreeBSD Project. The most common implementation of the standard is OpenSSH that is a part of the project's main distribution. Since its source is updated more often than FreeBSD releases, the latest version is also available in the ports tree. Chapter 8 Sub-projects Sub-projects are formed to reduce the amount of communication needed to coordinate the group of developers. When a problem area is sufficiently isolated, most communication would be within the group focusing on the problem, requiring less communication with the groups they communicate with than were the group not isolated. 8.1. The Ports Subproject A “port” is a set of meta-data and patches that are needed to fetch, compile and install correctly an external piece of software on a FreeBSD system. The amount of ports have grown at a tremendous rate, as shown by the following figure. Figure 8-1. Number of ports added between 1996 and 2005 Figure 8-1 is taken from the FreeBSD web site. It shows the number of ports available to FreeBSD in the period 1995 to 2005. It looks like the curve has first grown exponentionally, and then since the middle of 2001 grown linerly. As the external software described by the port often is under continued development, the amount of work required to maintain the ports is already large, and increasing. This has led to the ports part of the FreeBSD project gaining a more empowered structure, and is more and more becoming a sub-project of the FreeBSD project. Ports has its own core team with the Ports Manager as its leader, and this team can appoint committers without FreeBSD Core's approval. Unlike in the FreeBSD Project, where a lot of maintenance frequently is rewarded with a commit bit, the ports sub-project contains many active maintainers that are not committers. Unlike the main project, the ports tree is not branched. Every release of FreeBSD follows the current ports collection and has thus available updated information on where to find programs and how to build them. This, however, means that a port that makes dependencies on the system may need to have variations depending on what version of FreeBSD it runs on. With an unbranched ports repository it is not possible to guarantee that any port will run on anything other than -CURRENT and -STABLE, in particular older, minor releases. There is neither the infrastructure nor volunteer time needed to guarantee this. For efficiency of communication, teams depending on Ports, such as the release engineering team, have their own ports liaisons. 8.2. The FreeBSD Documentation Project The FreeBSD Documentation project was started January 1995. From the initial group of a project leader, four team leaders and 16 members, they are now a total of 44 committers. The documentation mailing list has just under 300 members, indicating that there is quite a large community around it. The goal of the Documentation project is to provide good and useful documentation of the FreeBSD project, thus making it easier for new users to get familiar with the system and detailing advanced features for the users. The main tasks in the Documentation project are to work on current projects in the “FreeBSD Documentation Set”, and translate the documentation to other languages. Like the FreeBSD Project, documentation is split in the same branches. This is done so that there is always an updated version of the documentation for each version. Only documentation errors are corrected in the security branches. Like the ports sub-project, the Documentation project can appoint documentation committers without FreeBSD Core's approval. [FreeBSD, 2003B]. The Documentation project has a primer. This is used both to introduce new project members to the standard tools and syntaxes and acts as a reference when working on the project. References [Brooks, 1995] Frederick P. Brooks, 1975, 1995, 0201835959, Addison-Wesley Pub Co, The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition). [Saers, 2003] Niklas Saers, 2003, A project model for the FreeBSD Project: Candidatus Scientiarum thesis. [Jørgensen, 2001] Niels Jørgensen, 2001, Putting it All in the Trunk: Incremental Software Development in the FreeBSD Open Source Project. [PMI, 2000] Project Management Institute, 1996, 2000, 1-880410-23-0, Project Management Institute, Pennsylvania, PMBOK Guide: A Guide to the Project Management Body of Knowledge, 2000 Edition. [FreeBSD, 2000A] 2002, Core Bylaws. [FreeBSD, 2002A] 2002, FreeBSD Developer's Handbook. [FreeBSD, 2002B] 2002, Core team election 2002. [Losh, 2002] Warner Losh, 2002, Working with Hats. [FreeBSD, 2002C] Dag-Erling Smørgrav and Hiten Pandya, 2002, The FreeBSD Documentation Project, Problem Report Handling Guidelines. [FreeBSD, 2002D] Dag-Erling Smørgrav, 2002, The FreeBSD Documentation Project, Writing FreeBSD Problem Reports. [FreeBSD, 2001] 2001, The FreeBSD Documentation Project, Committers Guide. [FreeBSD, 2002E] Murray Stokely, 2002, The FreeBSD Documentation Project, FreeBSD Release Engineering. [FreeBSD, 2003A] The FreeBSD Documentation Project, FreeBSD Handbook. [FreeBSD, 2002F] 2002, The FreeBSD Documentation Project, Contributors to FreeBSD. [FreeBSD, 2002G] 2002, The FreeBSD Project, Core team elections 2002. [FreeBSD, 2002H] 2002, The FreeBSD Project, Commit Bit Expiration Policy: 2002/04/06 15:35:30. [FreeBSD, 2002I] 2002, The FreeBSD Project, New Account Creation Procedure: 2002/08/19 17:11:27. [FreeBSD, 2003B] 2002, The FreeBSD Documentation Project, FreeBSD DocEng Team Charter: 2003/03/16 12:17. [Lehey, 2002] Greg Lehey, 2002, Greg Lehey, Two years in the trenches: The evolution of a software project. Notes [1] This goes hand-in-hand with Brooks' law that “adding another person to a late project will make it later” since it will increase the communication needs Brooks, 1995. A project model is a tool to reduce the communication needs. [2] Statistics are generated by counting the number of entries in the file fetched by portsdb by April 1st, 2005. portsdb is a part of the port sysutils/portupgrade. [3] The period from January 1st, 2004 to December 31st, 2004 was examined to find this number. [4] For instance, the development of the Bluetooth stack started as a sub-project until it was deemed stable enough to be merged into the -CURRENT branch. Now it is a part of the core FreeBSD system. [5] According to Kirk McKusick, after 20 years of developing UNIX operating systems, the interfaces are for the most part figured out. There is therefore no need for much design. However, new applications of the system and new hardware leads to some implementations being more beneficial than those that used to be preferred. One example is the introduction of web browsing that made the normal TCP/IP connection a short burst of data rather than a steady stream over a longer period of time. [6] The first release this actually happened for was 4.5-RELEASE, but security branches were at the same time created for 4.3-RELEASE and 4.4-RELEASE. [7] There is a terminology overlap with respect to the word "stable", which leads to some confusion. The -STABLE branch is still a development branch, whose goal is to be useful for most people. If it is never acceptable for a system to get changes that are not announced at the time it is deployed, that system should run a security branch. [8] The first Core election was held September 2000 [9] More and more tests are however performed when building the system &
Python参考手册,官方正式版参考手册,chm版。以下摘取部分内容:Navigation index modules | next | Python » 3.6.5 Documentation » Python Documentation contents What’s New in Python What’s New In Python 3.6 Summary – Release highlights New Features PEP 498: Formatted string literals PEP 526: Syntax for variable annotations PEP 515: Underscores in Numeric Literals PEP 525: Asynchronous Generators PEP 530: Asynchronous Comprehensions PEP 487: Simpler customization of class creation PEP 487: Descriptor Protocol Enhancements PEP 519: Adding a file system path protocol PEP 495: Local Time Disambiguation PEP 529: Change Windows filesystem encoding to UTF-8 PEP 528: Change Windows console encoding to UTF-8 PEP 520: Preserving Class Attribute Definition Order PEP 468: Preserving Keyword Argument Order New dict implementation PEP 523: Adding a frame evaluation API to CPython PYTHONMALLOC environment variable DTrace and SystemTap probing support Other Language Changes New Modules secrets Improved Modules array ast asyncio binascii cmath collections concurrent.futures contextlib datetime decimal distutils email encodings enum faulthandler fileinput hashlib http.client idlelib and IDLE importlib inspect json logging math multiprocessing os pathlib pdb pickle pickletools pydoc random re readline rlcompleter shlex site sqlite3 socket socketserver ssl statistics struct subprocess sys telnetlib time timeit tkinter traceback tracemalloc typing unicodedata unittest.mock urllib.request urllib.robotparser venv warnings winreg winsound xmlrpc.client zipfile zlib Optimizations Build and C API Changes Other Improvements Deprecated New Keywords Deprecated Python behavior Deprecated Python modules, functions and methods asynchat asyncore dbm distutils grp importlib os re ssl tkinter venv Deprecated functions and types of the C API Deprecated Build Options Removed API and Feature Removals Porting to Python 3.6 Changes in ‘python’ Command Behavior Changes in the Python API Changes in the C API CPython bytecode changes Notable changes in Python 3.6.2 New make regen-all build target Removal of make touch build target Notable changes in Python 3.6.5 What’s New In Python 3.5 Summary – Release highlights New Features PEP 492 - Coroutines with async and await syntax PEP 465 - A dedicated infix operator for matrix multiplication PEP 448 - Additional Unpacking Generalizations PEP 461 - percent formatting support for bytes and bytearray PEP 484 - Type Hints PEP 471 - os.scandir() function – a better and faster directory iterator PEP 475: Retry system calls failing with EINTR PEP 479: Change StopIteration handling inside generators PEP 485: A function for testing approximate equality PEP 486: Make the Python Launcher aware of virtual environments PEP 488: Elimination of PYO files PEP 489: Multi-phase extension module initialization Other Language Changes New Modules typing zipapp Improved Modules argparse asyncio bz2 cgi cmath code collections collections.abc compileall concurrent.futures configparser contextlib csv curses dbm difflib distutils doctest email enum faulthandler functools glob gzip heapq http http.client idlelib and IDLE imaplib imghdr importlib inspect io ipaddress json linecache locale logging lzma math multiprocessing operator os pathlib pickle poplib re readline selectors shutil signal smtpd smtplib sndhdr socket ssl Memory BIO Support Application-Layer Protocol Negotiation Support Other Changes sqlite3 subprocess sys sysconfig tarfile threading time timeit tkinter traceback types unicodedata unittest unittest.mock urllib wsgiref xmlrpc xml.sax zipfile Other module-level changes Optimizations Build and C API Changes Deprecated New Keywords Deprecated Python Behavior Unsupported Operating Systems Deprecated Python modules, functions and methods Removed API and Feature Removals Porting to Python 3.5 Changes in Python behavior Changes in the Python API Changes in the C API What’s New In Python 3.4 Summary – Release Highlights New Features PEP 453: Explicit Bootstrapping of PIP in Python Installations Bootstrapping pip By Default Documentation Changes PEP 446: Newly Created File Descriptors Are Non-Inheritable Improvements to Codec Handling PEP 451: A ModuleSpec Type for the Import System Other Language Changes New Modules asyncio ensurepip enum pathlib selectors statistics tracemalloc Improved Modules abc aifc argparse audioop base64 collections colorsys contextlib dbm dis doctest email filecmp functools gc glob hashlib hmac html http idlelib and IDLE importlib inspect ipaddress logging marshal mmap multiprocessing operator os pdb pickle plistlib poplib pprint pty pydoc re resource select shelve shutil smtpd smtplib socket sqlite3 ssl stat struct subprocess sunau sys tarfile textwrap threading traceback types urllib unittest venv wave weakref xml.etree zipfile CPython Implementation Changes PEP 445: Customization of CPython Memory Allocators PEP 442: Safe Object Finalization PEP 456: Secure and Interchangeable Hash Algorithm PEP 436: Argument Clinic Other Build and C API Changes Other Improvements Significant Optimizations Deprecated Deprecations in the Python API Deprecated Features Removed Operating Systems No Longer Supported API and Feature Removals Code Cleanups Porting to Python 3.4 Changes in ‘python’ Command Behavior Changes in the Python API Changes in the C API Changed in 3.4.3 PEP 476: Enabling certificate verification by default for stdlib http clients What’s New In Python 3.3 Summary – Release highlights PEP 405: Virtual Environments PEP 420: Implicit Namespace Packages PEP 3118: New memoryview implementation and buffer protocol documentation Features API changes PEP 393: Flexible String Representation Functionality Performance and resource usage PEP 397: Python Launcher for Windows PEP 3151: Reworking the OS and IO exception hierarchy PEP 380: Syntax for Delegating to a Subgenerator PEP 409: Suppressing exception context PEP 414: Explicit Unicode literals PEP 3155: Qualified name for classes and functions PEP 412: Key-Sharing Dictionary PEP 362: Function Signature Object PEP 421: Adding sys.implementation SimpleNamespace Using importlib as the Implementation of Import New APIs Visible Changes Other Language Changes A Finer-Grained Import Lock Builtin functions and types New Modules faulthandler ipaddress lzma Improved Modules abc array base64 binascii bz2 codecs collections contextlib crypt curses datetime decimal Features API changes email Policy Framework Provisional Policy with New Header API Other API Changes ftplib functools gc hmac http html imaplib inspect io itertools logging math mmap multiprocessing nntplib os pdb pickle pydoc re sched select shlex shutil signal smtpd smtplib socket socketserver sqlite3 ssl stat struct subprocess sys tarfile tempfile textwrap threading time types unittest urllib webbrowser xml.etree.ElementTree zlib Optimizations Build and C API Changes Deprecated Unsupported Operating Systems Deprecated Python modules, functions and methods Deprecated functions and types of the C API Deprecated features Porting to Python 3.3 Porting Python code Porting C code Building C extensions Command Line Switch Changes What’s New In Python 3.2 PEP 384: Defining a Stable ABI PEP 389: Argparse Command Line Parsing Module PEP 391: Dictionary Based Configuration for Logging PEP 3148: The concurrent.futures module PEP 3147: PYC Repository Directories PEP 3149: ABI Version Tagged .so Files PEP 3333: Python Web Server Gateway Interface v1.0.1 Other Language Changes New, Improved, and Deprecated Modules email elementtree functools itertools collections threading datetime and time math abc io reprlib logging csv contextlib decimal and fractions ftp popen select gzip and zipfile tarfile hashlib ast os shutil sqlite3 html socket ssl nntp certificates imaplib http.client unittest random poplib asyncore tempfile inspect pydoc dis dbm ctypes site sysconfig pdb configparser urllib.parse mailbox turtledemo Multi-threading Optimizations Unicode Codecs Documentation IDLE Code Repository Build and C API Changes Porting to Python 3.2 What’s New In Python 3.1 PEP 372: Ordered Dictionaries PEP 378: Format Specifier for Thousands Separator Other Language Changes New, Improved, and Deprecated Modules Optimizations IDLE Build and C API Changes Porting to Python 3.1 What’s New In Python 3.0 Common Stumbling Blocks Print Is A Function Views And Iterators Instead Of Lists Ordering Comparisons Integers Text Vs. Data Instead Of Unicode Vs. 8-bit Overview Of Syntax Changes New Syntax Changed Syntax Removed Syntax Changes Already Present In Python 2.6 Library Changes PEP 3101: A New Approach To String Formatting Changes To Exceptions Miscellaneous Other Changes Operators And Special Methods Builtins Build and C API Changes Performance Porting To Python 3.0 What’s New in Python 2.7 The Future for Python 2.x Changes to the Handling of Deprecation Warnings Python 3.1 Features PEP 372: Adding an Ordered Dictionary to collections PEP 378: Format Specifier for Thousands Separator PEP 389: The argparse Module for Parsing Command Lines PEP 391: Dictionary-Based Configuration For Logging PEP 3106: Dictionary Views PEP 3137: The memoryview Object Other Language Changes Interpreter Changes Optimizations New and Improved Modules New module: importlib New module: sysconfig ttk: Themed Widgets for Tk Updated module: unittest Updated module: ElementTree 1.3 Build and C API Changes Capsules Port-Specific Changes: Windows Port-Specific Changes: Mac OS X Port-Specific Changes: FreeBSD Other Changes and Fixes Porting to Python 2.7 New Features Added to Python 2.7 Maintenance Releases PEP 434: IDLE Enhancement Exception for All Branches PEP 466: Network Security Enhancements for Python 2.7 Acknowledgements What’s New in Python 2.6 Python 3.0 Changes to the Development Process New Issue Tracker: Roundup New Documentation Format: reStructuredText Using Sphinx PEP 343: The ‘with’ statement Writing Context Managers The contextlib module PEP 366: Explicit Relative Imports From a Main Module PEP 370: Per-user site-packages Directory PEP 371: The multiprocessing Package PEP 3101: Advanced String Formatting PEP 3105: print As a Function PEP 3110: Exception-Handling Changes PEP 3112: Byte Literals PEP 3116: New I/O Library PEP 3118: Revised Buffer Protocol PEP 3119: Abstract Base Classes PEP 3127: Integer Literal Support and Syntax PEP 3129: Class Decorators PEP 3141: A Type Hierarchy for Numbers The fractions Module Other Language Changes Optimizations Interpreter Changes New and Improved Modules The ast module The future_builtins module The json module: JavaScript Object Notation The plistlib module: A Property-List Parser ctypes Enhancements Improved SSL Support Deprecations and Removals Build and C API Changes Port-Specific Changes: Windows Port-Specific Changes: Mac OS X Port-Specific Changes: IRIX Porting to Python 2.6 Acknowledgements What’s New in Python 2.5 PEP 308: Conditional Expressions PEP 309: Partial Function Application PEP 314: Metadata for Python Software Packages v1.1 PEP 328: Absolute and Relative Imports PEP 338: Executing Modules as Scripts PEP 341: Unified try/except/finally PEP 342: New Generator Features PEP 343: The ‘with’ statement Writing Context Managers The contextlib module PEP 352: Exceptions as New-Style Classes PEP 353: Using ssize_t as the index type PEP 357: The ‘__index__’ method Other Language Changes Interactive Interpreter Changes Optimizations New, Improved, and Removed Modules The ctypes package The ElementTree package The hashlib package The sqlite3 package The wsgiref package Build and C API Changes Port-Specific Changes Porting to Python 2.5 Acknowledgements What’s New in Python 2.4 PEP 218: Built-In Set Objects PEP 237: Unifying Long Integers and Integers PEP 289: Generator Expressions PEP 292: Simpler String Substitutions PEP 318: Decorators for Functions and Methods PEP 322: Reverse Iteration PEP 324: New subprocess Module PEP 327: Decimal Data Type Why is Decimal needed? The Decimal type The Context type PEP 328: Multi-line Imports PEP 331: Locale-Independent Float/String Conversions Other Language Changes Optimizations New, Improved, and Deprecated Modules cookielib doctest Build and C API Changes Port-Specific Changes Porting to Python 2.4 Acknowledgements What’s New in Python 2.3 PEP 218: A Standard Set Datatype PEP 255: Simple Generators PEP 263: Source Code Encodings PEP 273: Importing Modules from ZIP Archives PEP 277: Unicode file name support for Windows NT PEP 278: Universal Newline Support PEP 279: enumerate() PEP 282: The logging Package PEP 285: A Boolean Type PEP 293: Codec Error Handling Callbacks PEP 301: Package Index and Metadata for Distutils PEP 302: New Import Hooks PEP 305: Comma-separated Files PEP 307: Pickle Enhancements Extended Slices Other Language Changes String Changes Optimizations New, Improved, and Deprecated Modules Date/Time Type The optparse Module Pymalloc: A Specialized Object Allocator Build and C API Changes Port-Specific Changes Other Changes and Fixes Porting to Python 2.3 Acknowledgements What’s New in Python 2.2 Introduction PEPs 252 and 253: Type and Class Changes Old and New Classes Descriptors Multiple Inheritance: The Diamond Rule Attribute Access Related Links PEP 234: Iterators PEP 255: Simple Generators PEP 237: Unifying Long Integers and Integers PEP 238: Changing the Division Operator Unicode Changes PEP 227: Nested Scopes New and Improved Modules Interpreter Changes and Fixes Other Changes and Fixes Acknowledgements What’s New in Python 2.1 Introduction PEP 227: Nested Scopes PEP 236: __future__ Directives PEP 207: Rich Comparisons PEP 230: Warning Framework PEP 229: New Build System PEP 205: Weak References PEP 232: Function Attributes PEP 235: Importing Modules on Case-Insensitive Platforms PEP 217: Interactive Display Hook PEP 208: New Coercion Model PEP 241: Metadata in Python Packages New and Improved Modules Other Changes and Fixes Acknowledgements What’s New in Python 2.0 Introduction What About Python 1.6? New Development Process Unicode List Comprehensions Augmented Assignment String Methods Garbage Collection of Cycles Other Core Changes Minor Language Changes Changes to Built-in Functions Porting to 2.0 Extending/Embedding Changes Distutils: Making Modules Easy to Install XML Modules SAX2 Support DOM Support Relationship to PyXML Module changes New modules IDLE Improvements Deleted and Deprecated Modules Acknowledgements Changelog Python 3.6.5 final? Tests Build Python 3.6.5 release candidate 1? Security Core and Builtins Library Documentation Tests Build Windows macOS IDLE Tools/Demos C API Python 3.6.4 final? Python 3.6.4 release candidate 1? Core and Builtins Library Documentation Tests Build Windows macOS IDLE Tools/Demos C API Python 3.6.3 final? Library Build Python 3.6.3 release candidate 1? Security Core and Builtins Library Documentation Tests Build Windows IDLE Tools/Demos Python 3.6.2 final? Python 3.6.2 release candidate 2? Security Python 3.6.2 release candidate 1? Core and Builtins Library Security Library IDLE C API Build Documentation Tools/Demos Tests Windows Python 3.6.1 final? Core and Builtins Build Python 3.6.1 release candidate 1? Core and Builtins Library IDLE Windows C API Documentation Tests Build Python 3.6.0 final? Python 3.6.0 release candidate 2? Core and Builtins Tools/Demos Windows Build Python 3.6.0 release candidate 1? Core and Builtins Library C API Documentation Tools/Demos Python 3.6.0 beta 4? Core and Builtins Library Documentation Tests Build Python 3.6.0 beta 3? Core and Builtins Library Windows Build Tests Python 3.6.0 beta 2? Core and Builtins Library Windows C API Build Tests Python 3.6.0 beta 1? Core and Builtins Library IDLE C API Tests Build Tools/Demos Windows Python 3.6.0 alpha 4? Core and Builtins Library IDLE Tests Windows Build Python 3.6.0 alpha 3? Core and Builtins Library Security Library Security Library IDLE C API Build Tools/Demos Documentation Tests Python 3.6.0 alpha 2? Core and Builtins Library Security Library Security Library IDLE Documentation Tests Windows Build Windows C API Tools/Demos Python 3.6.0 alpha 1? Core and Builtins Library Security Library Security Library Security Library IDLE Documentation Tests Build Windows Tools/Demos C API Python 3.5.3 final? Python 3.5.3 release candidate 1? Core and Builtins Library Security Library Security Library IDLE C API Documentation Tests Tools/Demos Windows Build Python 3.5.2 final? Core and Builtins Tests IDLE Python 3.5.2 release candidate 1? Core and Builtins Security Library Security Library Security Library Security Library Security Library IDLE Documentation Tests Build Windows Tools/Demos Windows Python 3.5.1 final? Core and Builtins Windows Python 3.5.1 release candidate 1? Core and Builtins Library IDLE Documentation Tests Build Windows Tools/Demos Python 3.5.0 final? Build Python 3.5.0 release candidate 4? Library Build Python 3.5.0 release candidate 3? Core and Builtins Library Python 3.5.0 release candidate 2? Core and Builtins Library Python 3.5.0 release candidate 1? Core and Builtins Library IDLE Documentation Tests Python 3.5.0 beta 4? Core and Builtins Library Build Python 3.5.0 beta 3? Core and Builtins Library Tests Documentation Build Python 3.5.0 beta 2? Core and Builtins Library Python 3.5.0 beta 1? Core and Builtins Library IDLE Tests Documentation Tools/Demos Python 3.5.0 alpha 4? Core and Builtins Library Build Tests Tools/Demos C API Python 3.5.0 alpha 3? Core and Builtins Library Build Tests Tools/Demos Python 3.5.0 alpha 2? Core and Builtins Library Build C API Windows Python 3.5.0 alpha 1? Core and Builtins Library IDLE Build C API Documentation Tests Tools/Demos Windows The Python Tutorial 1. Whetting Your Appetite 2. Using the Python Interpreter 2.1. Invoking the Interpreter 2.1.1. Argument Passing 2.1.2. Interactive Mode 2.2. The Interpreter and Its Environment 2.2.1. Source Code Encoding 3. An Informal Introduction to Python 3.1. Using Python as a Calculator 3.1.1. Numbers 3.1.2. Strings 3.1.3. Lists 3.2. First Steps Towards Programming 4. More Control Flow Tools 4.1. if Statements 4.2. for Statements 4.3. The range() Function 4.4. break and continue Statements, and else Clauses on Loops 4.5. pass Statements 4.6. Defining Functions 4.7. More on Defining Functions 4.7.1. Default Argument Values 4.7.2. Keyword Arguments 4.7.3. Arbitrary Argument Lists 4.7.4. Unpacking Argument Lists 4.7.5. Lambda Expressions 4.7.6. Documentation Strings 4.7.7. Function Annotations 4.8. Intermezzo: Coding Style 5. Data Structures 5.1. More on Lists 5.1.1. Using Lists as Stacks 5.1.2. Using Lists as Queues 5.1.3. List Comprehensions 5.1.4. Nested List Comprehensions 5.2. The del statement 5.3. Tuples and Sequences 5.4. Sets 5.5. Dictionaries 5.6. Looping Techniques 5.7. More on Conditions 5.8. Comparing Sequences and Other Types 6. Modules 6.1. More on Modules 6.1.1. Executing modules as scripts 6.1.2. The Module Search Path 6.1.3. “Compiled” Python files 6.2. Standard Modules 6.3. The dir() Function 6.4. Packages 6.4.1. Importing * From a Package 6.4.2. Intra-package References 6.4.3. Packages in Multiple Directories 7. Input and Output 7.1. Fancier Output Formatting 7.1.1. Old string formatting 7.2. Reading and Writing Files 7.2.1. Methods of File Objects 7.2.2. Saving structured data with json 8. Errors and Exceptions 8.1. Syntax Errors 8.2. Exceptions 8.3. Handling Exceptions 8.4. Raising Exceptions 8.5. User-defined Exceptions 8.6. Defining Clean-up Actions 8.7. Predefined Clean-up Actions 9. Classes 9.1. A Word About Names and Objects 9.2. Python Scopes and Namespaces 9.2.1. Scopes and Namespaces Example 9.3. A First Look at Classes 9.3.1. Class Definition Syntax 9.3.2. Class Objects 9.3.3. Instance Objects 9.3.4. Method Objects 9.3.5. Class and Instance Variables 9.4. Random Remarks 9.5. Inheritance 9.5.1. Multiple Inheritance 9.6. Private Variables 9.7. Odds and Ends 9.8. Iterators 9.9. Generators 9.10. Generator Expressions 10. Brief Tour of the Standard Library 10.1. Operating System Interface 10.2. File Wildcards 10.3. Command Line Arguments 10.4. Error Output Redirection and Program Termination 10.5. String Pattern Matching 10.6. Mathematics 10.7. Internet Access 10.8. Dates and Times 10.9. Data Compression 10.10. Performance Measurement 10.11. Quality Control 10.12. Batteries Included 11. Brief Tour of the Standard Library — Part II 11.1. Output Formatting 11.2. Templating 11.3. Working with Binary Data Record Layouts 11.4. Multi-threading 11.5. Logging 11.6. Weak References 11.7. Tools for Working with Lists 11.8. Decimal Floating Point Arithmetic 12. Virtual Environments and Packages 12.1. Introduction 12.2. Creating Virtual Environments 12.3. Managing Packages with pip 13. What Now? 14. Interactive Input Editing and History Substitution 14.1. Tab Completion and History Editing 14.2. Alternatives to the Interactive Interpreter 15. Floating Point Arithmetic: Issues and Limitations 15.1. Representation Error 16. Appendix 16.1. Interactive Mode 16.1.1. Error Handling 16.1.2. Executable Python Scripts 16.1.3. The Interactive Startup File 16.1.4. The Customization Modules Python Setup and Usage 1. Command line and environment 1.1. Command line 1.1.1. Interface options 1.1.2. Generic options 1.1.3. Miscellaneous options 1.1.4. Options you shouldn’t use 1.2. Environment variables 1.2.1. Debug-mode variables 2. Using Python on Unix platforms 2.1. Getting and installing the latest version of Python 2.1.1. On Linux 2.1.2. On FreeBSD and OpenBSD 2.1.3. On OpenSolaris 2.2. Building Python 2.3. Python-related paths and files 2.4. Miscellaneous 2.5. Editors and IDEs 3. Using Python on Windows 3.1. Installing Python 3.1.1. Supported Versions 3.1.2. Installation Steps 3.1.3. Removing the MAX_PATH Limitation 3.1.4. Installing Without UI 3.1.5. Installing Without Downloading 3.1.6. Modifying an install 3.1.7. Other Platforms 3.2. Alternative bundles 3.3. Configuring Python 3.3.1. Excursus: Setting environment variables 3.3.2. Finding the Python executable 3.4. Python Launcher for Windows 3.4.1. Getting started 3.4.1.1. From the command-line 3.4.1.2. Virtual environments 3.4.1.3. From a script 3.4.1.4. From file associations 3.4.2. Shebang Lines 3.4.3. Arguments in shebang lines 3.4.4. Customization 3.4.4.1. Customization via INI files 3.4.4.2. Customizing default Python versions 3.4.5. Diagnostics 3.5. Finding modules 3.6. Additional modules 3.6.1. PyWin32 3.6.2. cx_Freeze 3.6.3. WConio 3.7. Compiling Python on Windows 3.8. Embedded Distribution 3.8.1. Python Application 3.8.2. Embedding Python 3.9. Other resources 4. Using Python on a Macintosh 4.1. Getting and Installing MacPython 4.1.1. How to run a Python script 4.1.2. Running scripts with a GUI 4.1.3. Configuration 4.2. The IDE 4.3. Installing Additional Python Packages 4.4. GUI Programming on the Mac 4.5. Distributing Python Applications on the Mac 4.6. Other Resources The Python Language Reference 1. Introduction 1.1. Alternate Implementations 1.2. Notation 2. Lexical analysis 2.1. Line structure 2.1.1. Logical lines 2.1.2. Physical lines 2.1.3. Comments 2.1.4. Encoding declarations 2.1.5. Explicit line joining 2.1.6. Implicit line joining 2.1.7. Blank lines 2.1.8. Indentation 2.1.9. Whitespace between tokens 2.2. Other tokens 2.3. Identifiers and keywords 2.3.1. Keywords 2.3.2. Reserved classes of identifiers 2.4. Literals 2.4.1. String and Bytes literals 2.4.2. String literal concatenation 2.4.3. Formatted string literals 2.4.4. Numeric literals 2.4.5. Integer literals 2.4.6. Floating point literals 2.4.7. Imaginary literals 2.5. Operators 2.6. Delimiters 3. Data model 3.1. Objects, values and types 3.2. The standard type hierarchy 3.3. Special method names 3.3.1. Basic customization 3.3.2. Customizing attribute access 3.3.2.1. Customizing module attribute access 3.3.2.2. Implementing Descriptors 3.3.2.3. Invoking Descriptors 3.3.2.4. __slots__ 3.3.2.4.1. Notes on using __slots__ 3.3.3. Customizing class creation 3.3.3.1. Metaclasses 3.3.3.2. Determining the appropriate metaclass 3.3.3.3. Preparing the class namespace 3.3.3.4. Executing the class body 3.3.3.5. Creating the class object 3.3.3.6. Metaclass example 3.3.4. Customizing instance and subclass checks 3.3.5. Emulating callable objects 3.3.6. Emulating container types 3.3.7. Emulating numeric types 3.3.8. With Statement Context Managers 3.3.9. Special method lookup 3.4. Coroutines 3.4.1. Awaitable Objects 3.4.2. Coroutine Objects 3.4.3. Asynchronous Iterators 3.4.4. Asynchronous Context Managers 4. Execution model 4.1. Structure of a program 4.2. Naming and binding 4.2.1. Binding of names 4.2.2. Resolution of names 4.2.3. Builtins and restricted execution 4.2.4. Interaction with dynamic features 4.3. Exceptions 5. The import system 5.1. importlib 5.2. Packages 5.2.1. Regular packages 5.2.2. Namespace packages 5.3. Searching 5.3.1. The module cache 5.3.2. Finders and loaders 5.3.3. Import hooks 5.3.4. The meta path 5.4. Loading 5.4.1. Loaders 5.4.2. Submodules 5.4.3. Module spec 5.4.4. Import-related module attributes 5.4.5. module.__path__ 5.4.6. Module reprs 5.5. The Path Based Finder 5.5.1. Path entry finders 5.5.2. Path entry finder protocol 5.6. Replacing the standard import system 5.7. Special considerations for __main__ 5.7.1. __main__.__spec__ 5.8. Open issues 5.9. References 6. Expressions 6.1. Arithmetic conversions 6.2. Atoms 6.2.1. Identifiers (Names) 6.2.2. Literals 6.2.3. Parenthesized forms 6.2.4. Displays for lists, sets and dictionaries 6.2.5. List displays 6.2.6. Set displays 6.2.7. Dictionary displays 6.2.8. Generator expressions 6.2.9. Yield expressions 6.2.9.1. Generator-iterator methods 6.2.9.2. Examples 6.2.9.3. Asynchronous generator functions 6.2.9.4. Asynchronous generator-iterator methods 6.3. Primaries 6.3.1. Attribute references 6.3.2. Subscriptions 6.3.3. Slicings 6.3.4. Calls 6.4. Await expression 6.5. The power operator 6.6. Unary arithmetic and bitwise operations 6.7. Binary arithmetic operations 6.8. Shifting operations 6.9. Binary bitwise operations 6.10. Comparisons 6.10.1. Value comparisons 6.10.2. Membership test operations 6.10.3. Identity comparisons 6.11. Boolean operations 6.12. Conditional expressions 6.13. Lambdas 6.14. Expression lists 6.15. Evaluation order 6.16. Operator precedence 7. Simple statements 7.1. Expression statements 7.2. Assignment statements 7.2.1. Augmented assignment statements 7.2.2. Annotated assignment statements 7.3. The assert statement 7.4. The pass statement 7.5. The del statement 7.6. The return statement 7.7. The yield statement 7.8. The raise statement 7.9. The break statement 7.10. The continue statement 7.11. The import statement 7.11.1. Future statements 7.12. The global statement 7.13. The nonlocal statement 8. Compound statements 8.1. The if statement 8.2. The while statement 8.3. The for statement 8.4. The try statement 8.5. The with statement 8.6. Function definitions 8.7. Class definitions 8.8. Coroutines 8.8.1. Coroutine function definition 8.8.2. The async for statement 8.8.3. The async with statement 9. Top-level components 9.1. Complete Python programs 9.2. File input 9.3. Interactive input 9.4. Expression input 10. Full Grammar specification The Python Standard Library 1. Introduction 2. Built-in Functions 3. Built-in Constants 3.1. Constants added by the site module 4. Built-in Types 4.1. Truth Value Testing 4.2. Boolean Operations — and, or, not 4.3. Comparisons 4.4. Numeric Types — int, float, complex 4.4.1. Bitwise Operations on Integer Types 4.4.2. Additional Methods on Integer Types 4.4.3. Additional Methods on Float 4.4.4. Hashing of numeric types 4.5. Iterator Types 4.5.1. Generator Types 4.6. Sequence Types — list, tuple, range 4.6.1. Common Sequence Operations 4.6.2. Immutable Sequence Types 4.6.3. Mutable Sequence Types 4.6.4. Lists 4.6.5. Tuples 4.6.6. Ranges 4.7. Text Sequence Type — str 4.7.1. String Methods 4.7.2. printf-style String Formatting 4.8. Binary Sequence Types — bytes, bytearray, memoryview 4.8.1. Bytes Objects 4.8.2. Bytearray Objects 4.8.3. Bytes and Bytearray Operations 4.8.4. printf-style Bytes Formatting 4.8.5. Memory Views 4.9. Set Types — set, frozenset 4.10. Mapping Types — dict 4.10.1. Dictionary view objects 4.11. Context Manager Types 4.12. Other Built-in Types 4.12.1. Modules 4.12.2. Classes and Class Instances 4.12.3. Functions 4.12.4. Methods 4.12.5. Code Objects 4.12.6. Type Objects 4.12.7. The Null Object 4.12.8. The Ellipsis Object 4.12.9. The NotImplemented Object 4.12.10. Boolean Values 4.12.11. Internal Objects 4.13. Special Attributes 5. Built-in Exceptions 5.1. Base classes 5.2. Concrete exceptions 5.2.1. OS exceptions 5.3. Warnings 5.4. Exception hierarchy 6. Text Processing Services 6.1. string — Common string operations 6.1.1. String constants 6.1.2. Custom String Formatting 6.1.3. Format String Syntax 6.1.3.1. Format Specification Mini-Language 6.1.3.2. Format examples 6.1.4. Template strings 6.1.5. Helper functions 6.2. re — Regular expression operations 6.2.1. Regular Expression Syntax 6.2.2. Module Contents 6.2.3. Regular Expression Objects 6.2.4. Match Objects 6.2.5. Regular Expression Examples 6.2.5.1. Checking for a Pair 6.2.5.2. Simulating scanf() 6.2.5.3. search() vs. match() 6.2.5.4. Making a Phonebook 6.2.5.5. Text Munging 6.2.5.6. Finding all Adverbs 6.2.5.7. Finding all Adverbs and their Positions 6.2.5.8. Raw String Notation 6.2.5.9. Writing a Tokenizer 6.3. difflib — Helpers for computing deltas 6.3.1. SequenceMatcher Objects 6.3.2. SequenceMatcher Examples 6.3.3. Differ Objects 6.3.4. Differ Example 6.3.5. A command-line interface to difflib 6.4. textwrap — Text wrapping and filling 6.5. unicodedata — Unicode Database 6.6. stringprep — Internet String Preparation 6.7. readline — GNU readline interface 6.7.1. Init file 6.7.2. Line buffer 6.7.3. History file 6.7.4. History list 6.7.5. Startup hooks 6.7.6. Completion 6.7.7. Example 6.8. rlcompleter — Completion function for GNU readline 6.8.1. Completer Objects 7. Binary Data Services 7.1. struct — Interpret bytes as packed binary data 7.1.1. Functions and Exceptions 7.1.2. Format Strings 7.1.2.1. Byte Order, Size, and Alignment 7.1.2.2. Format Characters 7.1.2.3. Examples 7.1.3. Classes 7.2. codecs — Codec registry and base classes 7.2.1. Codec Base Classes 7.2.1.1. Error Handlers 7.2.1.2. Stateless Encoding and Decoding 7.2.1.3. Incremental Encoding and Decoding 7.2.1.3.1. IncrementalEncoder Objects 7.2.1.3.2. IncrementalDecoder Objects 7.2.1.4. Stream Encoding and Decoding 7.2.1.4.1. StreamWriter Objects 7.2.1.4.2. StreamReader Objects 7.2.1.4.3. StreamReaderWriter Objects 7.2.1.4.4. StreamRecoder Objects 7.2.2. Encodings and Unicode 7.2.3. Standard Encodings 7.2.4. Python Specific Encodings 7.2.4.1. Text Encodings 7.2.4.2. Binary Transforms 7.2.4.3. Text Transforms 7.2.5. encodings.idna — Internationalized Domain Names in Applications 7.2.6. encodings.mbcs — Windows ANSI codepage 7.2.7. encodings.utf_8_sig — UTF-8 codec with BOM signature 8. Data Types 8.1. datetime — Basic date and time types 8.1.1. Available Types 8.1.2. timedelta Objects 8.1.3. date Objects 8.1.4. datetime Objects 8.1.5. time Objects 8.1.6. tzinfo Objects 8.1.7. timezone Objects 8.1.8. strftime() and strptime() Behavior 8.2. calendar — General calendar-related functions 8.3. collections — Container datatypes 8.3.1. ChainMap objects 8.3.1.1. ChainMap Examples and Recipes 8.3.2. Counter objects 8.3.3. deque objects 8.3.3.1. deque Recipes 8.3.4. defaultdict objects 8.3.4.1. defaultdict Examples 8.3.5. namedtuple() Factory Function for Tuples with Named Fields 8.3.6. OrderedDict objects 8.3.6.1. OrderedDict Examples and Recipes 8.3.7. UserDict objects 8.3.8. UserList objects 8.3.9. UserString objects 8.4. collections.abc — Abstract Base Classes for Containers 8.4.1. Collections Abstract Base Classes 8.5. heapq — Heap queue algorithm 8.5.1. Basic Examples 8.5.2. Priority Queue Implementation Notes 8.5.3. Theory 8.6. bisect — Array bisection algorithm 8.6.1. Searching Sorted Lists 8.6.2. Other Examples 8.7. array — Efficient arrays of numeric values 8.8. weakref — Weak references 8.8.1. Weak Reference Objects 8.8.2. Example 8.8.3. Finalizer Objects 8.8.4. Comparing finalizers with __del__() methods 8.9. types — Dynamic type creation and names for built-in types 8.9.1. Dynamic Type Creation 8.9.2. Standard Interpreter Types 8.9.3. Additional Utility Classes and Functions 8.9.4. Coroutine Utility Functions 8.10. copy — Shallow and deep copy operations 8.11. pprint — Data pretty printer 8.11.1. PrettyPrinter Objects 8.11.2. Example 8.12. reprlib — Alternate repr() implementation 8.12.1. Repr Objects 8.12.2. Subclassing Repr Objects 8.13. enum — Support for enumerations 8.13.1. Module Contents 8.13.2. Creating an Enum 8.13.3. Programmatic access to enumeration members and their attributes 8.13.4. Duplicating enum members and values 8.13.5. Ensuring unique enumeration values 8.13.6. Using automatic values 8.13.7. Iteration 8.13.8. Comparisons 8.13.9. Allowed members and attributes of enumerations 8.13.10. Restricted subclassing of enumerations 8.13.11. Pickling 8.13.12. Functional API 8.13.13. Derived Enumerations 8.13.13.1. IntEnum 8.13.13.2. IntFlag 8.13.13.3. Flag 8.13.13.4. Others 8.13.14. Interesting examples 8.13.14.1. Omitting values 8.13.14.1.1. Using auto 8.13.14.1.2. Using object 8.13.14.1.3. Using a descriptive string 8.13.14.1.4. Using a custom __new__() 8.13.14.2. OrderedEnum 8.13.14.3. DuplicateFreeEnum 8.13.14.4. Planet 8.13.15. How are Enums different? 8.13.15.1. Enum Classes 8.13.15.2. Enum Members (aka instances) 8.13.15.3. Finer Points 8.13.15.3.1. Supported __dunder__ names 8.13.15.3.2. Supported _sunder_ names 8.13.15.3.3. Enum member type 8.13.15.3.4. Boolean value of Enum classes and members 8.13.15.3.5. Enum classes with methods 8.13.15.3.6. Combining members of Flag 9. Numeric and Mathematical Modules 9.1. numbers — Numeric abstract base classes 9.1.1. The numeric tower 9.1.2. Notes for type implementors 9.1.2.1. Adding More Numeric ABCs 9.1.2.2. Implementing the arithmetic operations 9.2. math — Mathematical functions 9.2.1. Number-theoretic and representation functions 9.2.2. Power and logarithmic functions 9.2.3. Trigonometric functions 9.2.4. Angular conversion 9.2.5. Hyperbolic functions 9.2.6. Special functions 9.2.7. Constants 9.3. cmath — Mathematical functions for complex numbers 9.3.1. Conversions to and from polar coordinates 9.3.2. Power and logarithmic functions 9.3.3. Trigonometric functions 9.3.4. Hyperbolic functions 9.3.5. Classification functions 9.3.6. Constants 9.4. decimal — Decimal fixed point and floating point arithmetic 9.4.1. Quick-start Tutorial 9.4.2. Decimal objects 9.4.2.1. Logical operands 9.4.3. Context objects 9.4.4. Constants 9.4.5. Rounding modes 9.4.6. Signals 9.4.7. Floating Point Notes 9.4.7.1. Mitigating round-off error with increased precision 9.4.7.2. Special values 9.4.8. Working with threads 9.4.9. Recipes 9.4.10. Decimal FAQ 9.5. fractions — Rational numbers 9.6. random — Generate pseudo-random numbers 9.6.1. Bookkeeping functions 9.6.2. Functions for integers 9.6.3. Functions for sequences 9.6.4. Real-valued distributions 9.6.5. Alternative Generator 9.6.6. Notes on Reproducibility 9.6.7. Examples and Recipes 9.7. statistics — Mathematical statistics functions 9.7.1. Averages and measures of central location 9.7.2. Measures of spread 9.7.3. Function details 9.7.4. Exceptions 10. Functional Programming Modules 10.1. itertools — Functions creating iterators for efficient looping 10.1.1. Itertool functions 10.1.2. Itertools Recipes 10.2. functools — Higher-order functions and operations on callable objects 10.2.1. partial Objects 10.3. operator — Standard operators as functions 10.3.1. Mapping Operators to Functions 10.3.2. Inplace Operators 11. File and Directory Access 11.1. pathlib — Object-oriented filesystem paths 11.1.1. Basic use 11.1.2. Pure paths 11.1.2.1. General properties 11.1.2.2. Operators 11.1.2.3. Accessing individual parts 11.1.2.4. Methods and properties 11.1.3. Concrete paths 11.1.3.1. Methods 11.2. os.path — Common pathname manipulations 11.3. fileinput — Iterate over lines from multiple input streams 11.4. stat — Interpreting stat() results 11.5. filecmp — File and Directory Comparisons 11.5.1. The dircmp class 11.6. tempfile — Generate temporary files and directories 11.6.1. Examples 11.6.2. Deprecated functions and variables 11.7. glob — Unix style pathname pattern expansion 11.8. fnmatch — Unix filename pattern matching 11.9. linecache — Random access to text lines 11.10. shutil — High-level file operations 11.10.1. Directory and files operations 11.10.1.1. copytree example 11.10.1.2. rmtree example 11.10.2. Archiving operations 11.10.2.1. Archiving example 11.10.3. Querying the size of the output terminal 11.11. macpath — Mac OS 9 path manipulation functions 12. Data Persistence 12.1. pickle — Python object serialization 12.1.1. Relationship to other Python modules 12.1.1.1. Comparison with marshal 12.1.1.2. Comparison with json 12.1.2. Data stream format 12.1.3. Module Interface 12.1.4. What can be pickled and unpickled? 12.1.5. Pickling Class Instances 12.1.5.1. Persistence of External Objects 12.1.5.2. Dispatch Tables 12.1.5.3. Handling Stateful Objects 12.1.6. Restricting Globals 12.1.7. Performance 12.1.8. Examples 12.2. copyreg — Register pickle support functions 12.2.1. Example 12.3. shelve — Python object persistence 12.3.1. Restrictions 12.3.2. Example 12.4. marshal — Internal Python object serialization 12.5. dbm — Interfaces to Unix “databases” 12.5.1. dbm.gnu — GNU’s reinterpretation of dbm 12.5.2. dbm.ndbm — Interface based on ndbm 12.5.3. dbm.dumb — Portable DBM implementation 12.6. sqlite3 — DB-API 2.0 interface for SQLite databases 12.6.1. Module functions and constants 12.6.2. Connection Objects 12.6.3. Cursor Objects 12.6.4. Row Objects 12.6.5. Exceptions 12.6.6. SQLite and Python types 12.6.6.1. Introduction 12.6.6.2. Using adapters to store additional Python types in SQLite databases 12.6.6.2.1. Letting your object adapt itself 12.6.6.2.2. Registering an adapter callable 12.6.6.3. Converting SQLite values to custom Python types 12.6.6.4. Default adapters and converters 12.6.7. Controlling Transactions 12.6.8. Using sqlite3 efficiently 12.6.8.1. Using shortcut methods 12.6.8.2. Accessing columns by name instead of by index 12.6.8.3. Using the connection as a context manager 12.6.9. Common issues 12.6.9.1. Multithreading 13. Data Compression and Archiving 13.1. zlib — Compression compatible with gzip 13.2. gzip — Support for gzip files 13.2.1. Examples of usage 13.3. bz2 — Support for bzip2 compression 13.3.1. (De)compression of files 13.3.2. Incremental (de)compression 13.3.3. One-shot (de)compression 13.4. lzma — Compression using the LZMA algorithm 13.4.1. Reading and writing compressed files 13.4.2. Compressing and decompressing data in memory 13.4.3. Miscellaneous 13.4.4. Specifying custom filter chains 13.4.5. Examples 13.5. zipfile — Work with ZIP archives 13.5.1. ZipFile Objects 13.5.2. PyZipFile Objects 13.5.3. ZipInfo Objects 13.5.4. Command-Line Interface 13.5.4.1. Command-line options 13.6. tarfile — Read and write tar archive files 13.6.1. TarFile Objects 13.6.2. TarInfo Objects 13.6.3. Command-Line Interface 13.6.3.1. Command-line options 13.6.4. Examples 13.6.5. Supported tar formats 13.6.6. Unicode issues 14. File Formats 14.1. csv — CSV File Reading and Writing 14.1.1. Module Contents 14.1.2. Dialects and Formatting Parameters 14.1.3. Reader Objects 14.1.4. Writer Objects 14.1.5. Examples 14.2. configparser — Configuration file parser 14.2.1. Quick Start 14.2.2. Supported Datatypes 14.2.3. Fallback Values 14.2.4. Supported INI File Structure 14.2.5. Interpolation of values 14.2.6. Mapping Protocol Access 14.2.7. Customizing Parser Behaviour 14.2.8. Legacy API Examples 14.2.9. ConfigParser Objects 14.2.10. RawConfigParser Objects 14.2.11. Exceptions 14.3. netrc — netrc file processing 14.3.1. netrc Objects 14.4. xdrlib — Encode and decode XDR data 14.4.1. Packer Objects 14.4.2. Unpacker Objects 14.4.3. Exceptions 14.5. plistlib — Generate and parse Mac OS X .plist files 14.5.1. Examples 15. Cryptographic Services 15.1. hashlib — Secure hashes and message digests 15.1.1. Hash algorithms 15.1.2. SHAKE variable length digests 15.1.3. Key derivation 15.1.4. BLAKE2 15.1.4.1. Creating hash objects 15.1.4.2. Constants 15.1.4.3. Examples 15.1.4.3.1. Simple hashing 15.1.4.3.2. Using different digest sizes 15.1.4.3.3. Keyed hashing 15.1.4.3.4. Randomized hashing 15.1.4.3.5. Personalization 15.1.4.3.6. Tree mode 15.1.4.4. Credits 15.2. hmac — Keyed-Hashing for Message Authentication 15.3. secrets — Generate secure random numbers for managing secrets 15.3.1. Random numbers 15.3.2. Generating tokens 15.3.2.1. How many bytes should tokens use? 15.3.3. Other functions 15.3.4. Recipes and best practices 16. Generic Operating System Services 16.1. os — Miscellaneous operating system interfaces 16.1.1. File Names, Command Line Arguments, and Environment Variables 16.1.2. Process Parameters 16.1.3. File Object Creation 16.1.4. File Descriptor Operations 16.1.4.1. Querying the size of a terminal 16.1.4.2. Inheritance of File Descriptors 16.1.5. Files and Directories 16.1.5.1. Linux extended attributes 16.1.6. Process Management 16.1.7. Interface to the scheduler 16.1.8. Miscellaneous System Information 16.1.9. Random numbers 16.2. io — Core tools for working with streams 16.2.1. Overview 16.2.1.1. Text I/O 16.2.1.2. Binary I/O 16.2.1.3. Raw I/O 16.2.2. High-level Module Interface 16.2.2.1. In-memory streams 16.2.3. Class hierarchy 16.2.3.1. I/O Base Classes 16.2.3.2. Raw File I/O 16.2.3.3. Buffered Streams 16.2.3.4. Text I/O 16.2.4. Performance 16.2.4.1. Binary I/O 16.2.4.2. Text I/O 16.2.4.3. Multi-threading 16.2.4.4. Reentrancy 16.3. time — Time access and conversions 16.3.1. Functions 16.3.2. Clock ID Constants 16.3.3. Timezone Constants 16.4. argparse — Parser for command-line options, arguments and sub-commands 16.4.1. Example 16.4.1.1. Creating a parser 16.4.1.2. Adding arguments 16.4.1.3. Parsing arguments 16.4.2. ArgumentParser objects 16.4.2.1. prog 16.4.2.2. usage 16.4.2.3. description 16.4.2.4. epilog 16.4.2.5. parents 16.4.2.6. formatter_class 16.4.2.7. prefix_chars 16.4.2.8. fromfile_prefix_chars 16.4.2.9. argument_default 16.4.2.10. allow_abbrev 16.4.2.11. conflict_handler 16.4.2.12. add_help 16.4.3. The add_argument() method 16.4.3.1. name or flags 16.4.3.2. action 16.4.3.3. nargs 16.4.3.4. const 16.4.3.5. default 16.4.3.6. type 16.4.3.7. choices 16.4.3.8. required 16.4.3.9. help 16.4.3.10. metavar 16.4.3.11. dest 16.4.3.12. Action classes 16.4.4. The parse_args() method 16.4.4.1. Option value syntax 16.4.4.2. Invalid arguments 16.4.4.3. Arguments containing - 16.4.4.4. Argument abbreviations (prefix matching) 16.4.4.5. Beyond sys.argv 16.4.4.6. The Namespace object 16.4.5. Other utilities 16.4.5.1. Sub-commands 16.4.5.2. FileType objects 16.4.5.3. Argument groups 16.4.5.4. Mutual exclusion 16.4.5.5. Parser defaults 16.4.5.6. Printing help 16.4.5.7. Partial parsing 16.4.5.8. Customizing file parsing 16.4.5.9. Exiting methods 16.4.6. Upgrading optparse code 16.5. getopt — C-style parser for command line options 16.6. logging — Logging facility for Python 16.6.1. Logger Objects 16.6.2. Logging Levels 16.6.3. Handler Objects 16.6.4. Formatter Objects 16.6.5. Filter Objects 16.6.6. LogRecord Objects 16.6.7. LogRecord attributes 16.6.8. LoggerAdapter Objects 16.6.9. Thread Safety 16.6.10. Module-Level Functions 16.6.11. Module-Level Attributes 16.6.12. Integration with the warnings module 16.7. logging.config — Logging configuration 16.7.1. Configuration functions 16.7.2. Configuration dictionary schema 16.7.2.1. Dictionary Schema Details 16.7.2.2. Incremental Configuration 16.7.2.3. Object connections 16.7.2.4. User-defined objects 16.7.2.5. Access to external objects 16.7.2.6. Access to internal objects 16.7.2.7. Import resolution and custom importers 16.7.3. Configuration file format 16.8. logging.handlers — Logging handlers 16.8.1. StreamHandler 16.8.2. FileHandler 16.8.3. NullHandler 16.8.4. WatchedFileHandler 16.8.5. BaseRotatingHandler 16.8.6. RotatingFileHandler 16.8.7. TimedRotatingFileHandler 16.8.8. SocketHandler 16.8.9. DatagramHandler 16.8.10. SysLogHandler 16.8.11. NTEventLogHandler 16.8.12. SMTPHandler 16.8.13. MemoryHandler 16.8.14. HTTPHandler 16.8.15. QueueHandler 16.8.16. QueueListener 16.9. getpass — Portable password input 16.10. curses — Terminal handling for character-cell displays 16.10.1. Functions 16.10.2. Window Objects 16.10.3. Constants 16.11. curses.textpad — Text input widget for curses programs 16.11.1. Textbox objects 16.12. curses.ascii — Utilities for ASCII characters 16.13. curses.panel — A panel stack extension for curses 16.13.1. Functions 16.13.2. Panel Objects 16.14. platform — Access to underlying platform’s identifying data 16.14.1. Cross Platform 16.14.2. Java Platform 16.14.3. Windows Platform 16.14.3.1. Win95/98 specific 16.14.4. Mac OS Platform 16.14.5. Unix Platforms 16.15. errno — Standard errno system symbols 16.16. ctypes — A foreign function library for Python 16.16.1. ctypes tutorial 16.16.1.1. Loading dynamic link libraries 16.16.1.2. Accessing functions from loaded dlls 16.16.1.3. Calling functions 16.16.1.4. Fundamental data types 16.16.1.5. Calling functions, continued 16.16.1.6. Calling functions with your own custom data types 16.16.1.7. Specifying the required argument types (function prototypes) 16.16.1.8. Return types 16.16.1.9. Passing pointers (or: passing parameters by reference) 16.16.1.10. Structures and unions 16.16.1.11. Structure/union alignment and byte order 16.16.1.12. Bit fields in structures and unions 16.16.1.13. Arrays 16.16.1.14. Pointers 16.16.1.15. Type conversions 16.16.1.16. Incomplete Types 16.16.1.17. Callback functions 16.16.1.18. Accessing values exported from dlls 16.16.1.19. Surprises 16.16.1.20. Variable-sized data types 16.16.2. ctypes reference 16.16.2.1. Finding shared libraries 16.16.2.2. Loading shared libraries 16.16.2.3. Foreign functions 16.16.2.4. Function prototypes 16.16.2.5. Utility functions 16.16.2.6. Data types 16.16.2.7. Fundamental data types 16.16.2.8. Structured data types 16.16.2.9. Arrays and pointers 17. Concurrent Execution 17.1. threading — Thread-based parallelism 17.1.1. Thread-Local Data 17.1.2. Thread Objects 17.1.3. Lock Objects 17.1.4. RLock Objects 17.1.5. Condition Objects 17.1.6. Semaphore Objects 17.1.6.1. Semaphore Example 17.1.7. Event Objects 17.1.8. Timer Objects 17.1.9. Barrier Objects 17.1.10. Using locks, conditions, and semaphores in the with statement 17.2. multiprocessing — Process-based parallelism 17.2.1. Introduction 17.2.1.1. The Process class 17.2.1.2. Contexts and start methods 17.2.1.3. Exchanging objects between processes 17.2.1.4. Synchronization between processes 17.2.1.5. Sharing state between processes 17.2.1.6. Using a pool of workers 17.2.2. Reference 17.2.2.1. Process and exceptions 17.2.2.2. Pipes and Queues 17.2.2.3. Miscellaneous 17.2.2.4. Connection Objects 17.2.2.5. Synchronization primitives 17.2.2.6. Shared ctypes Objects 17.2.2.6.1. The multiprocessing.sharedctypes module 17.2.2.7. Managers 17.2.2.7.1. Customized managers 17.2.2.7.2. Using a remote manager 17.2.2.8. Proxy Objects 17.2.2.8.1. Cleanup 17.2.2.9. Process Pools 17.2.2.10. Listeners and Clients 17.2.2.10.1. Address Formats 17.2.2.11. Authentication keys 17.2.2.12. Logging 17.2.2.13. The multiprocessing.dummy module 17.2.3. Programming guidelines 17.2.3.1. All start methods 17.2.3.2. The spawn and forkserver start methods 17.2.4. Examples 17.3. The concurrent package 17.4. concurrent.futures — Launching parallel tasks 17.4.1. Executor Objects 17.4.2. ThreadPoolExecutor 17.4.2.1. ThreadPoolExecutor Example 17.4.3. ProcessPoolExecutor 17.4.3.1. ProcessPoolExecutor Example 17.4.4. Future Objects 17.4.5. Module Functions 17.4.6. Exception classes 17.5. subprocess — Subprocess management 17.5.1. Using the subprocess Module 17.5.1.1. Frequently Used Arguments 17.5.1.2. Popen Constructor 17.5.1.3. Exceptions 17.5.2. Security Considerations 17.5.3. Popen Objects 17.5.4. Windows Popen Helpers 17.5.4.1. Constants 17.5.5. Older high-level API 17.5.6. Replacing Older Functions with the subprocess Module 17.5.6.1. Replacing /bin/sh shell backquote 17.5.6.2. Replacing shell pipeline 17.5.6.3. Replacing os.system() 17.5.6.4. Replacing the os.spawn family 17.5.6.5. Replacing os.popen(), os.popen2(), os.popen3() 17.5.6.6. Replacing functions from the popen2 module 17.5.7. Legacy Shell Invocation Functions 17.5.8. Notes 17.5.8.1. Converting an argument sequence to a string on Windows 17.6. sched — Event scheduler 17.6.1. Scheduler Objects 17.7. queue — A synchronized queue class 17.7.1. Queue Objects 17.8. dummy_threading — Drop-in replacement for the threading module 17.9. _thread — Low-level threading API 17.10. _dummy_thread — Drop-in replacement for the _thread module 18. Interprocess Communication and Networking 18.1. socket — Low-level networking interface 18.1.1. Socket families 18.1.2. Module contents 18.1.2.1. Exceptions 18.1.2.2. Constants 18.1.2.3. Functions 18.1.2.3.1. Creating sockets 18.1.2.3.2. Other functions 18.1.3. Socket Objects 18.1.4. Notes on socket timeouts 18.1.4.1. Timeouts and the connect method 18.1.4.2. Timeouts and the accept method 18.1.5. Example 18.2. ssl — TLS/SSL wrapper for socket objects 18.2.1. Functions, Constants, and Exceptions 18.2.1.1. Socket creation 18.2.1.2. Context creation 18.2.1.3. Random generation 18.2.1.4. Certificate handling 18.2.1.5. Constants 18.2.2. SSL Sockets 18.2.3. SSL Contexts 18.2.4. Certificates 18.2.4.1. Certificate chains 18.2.4.2. CA certificates 18.2.4.3. Combined key and certificate 18.2.4.4. Self-signed certificates 18.2.5. Examples 18.2.5.1. Testing for SSL support 18.2.5.2. Client-side operation 18.2.5.3. Server-side operation 18.2.6. Notes on non-blocking sockets 18.2.7. Memory BIO Support 18.2.8. SSL session 18.2.9. Security considerations 18.2.9.1. Best defaults 18.2.9.2. Manual settings 18.2.9.2.1. Verifying certificates 18.2.9.2.2. Protocol versions 18.2.9.2.3. Cipher selection 18.2.9.3. Multi-processing 18.2.10. LibreSSL support 18.3. select — Waiting for I/O completion 18.3.1. /dev/poll Polling Objects 18.3.2. Edge and Level Trigger Polling (epoll) Objects 18.3.3. Polling Objects 18.3.4. Kqueue Objects 18.3.5. Kevent Objects 18.4. selectors — High-level I/O multiplexing 18.4.1. Introduction 18.4.2. Classes 18.4.3. Examples 18.5. asyncio — Asynchronous I/O, event loop, coroutines and tasks 18.5.1. Base Event Loop 18.5.1.1. Run an event loop 18.5.1.2. Calls 18.5.1.3. Delayed calls 18.5.1.4. Futures 18.5.1.5. Tasks 18.5.1.6. Creating connections 18.5.1.7. Creating listening connections 18.5.1.8. Watch file descriptors 18.5.1.9. Low-level socket operations 18.5.1.10. Resolve host name 18.5.1.11. Connect pipes 18.5.1.12. UNIX signals 18.5.1.13. Executor 18.5.1.14. Error Handling API 18.5.1.15. Debug mode 18.5.1.16. Server 18.5.1.17. Handle 18.5.1.18. Event loop examples 18.5.1.18.1. Hello World with call_soon() 18.5.1.18.2. Display the current date with call_later() 18.5.1.18.3. Watch a file descriptor for read events 18.5.1.18.4. Set signal handlers for SIGINT and SIGTERM 18.5.2. Event loops 18.5.2.1. Event loop functions 18.5.2.2. Available event loops 18.5.2.3. Platform support 18.5.2.3.1. Windows 18.5.2.3.2. Mac OS X 18.5.2.4. Event loop policies and the default policy 18.5.2.5. Event loop policy interface 18.5.2.6. Access to the global loop policy 18.5.2.7. Customizing the event loop policy 18.5.3. Tasks and coroutines 18.5.3.1. Coroutines 18.5.3.1.1. Example: Hello World coroutine 18.5.3.1.2. Example: Coroutine displaying the current date 18.5.3.1.3. Example: Chain coroutines 18.5.3.2. InvalidStateError 18.5.3.3. TimeoutError 18.5.3.4. Future 18.5.3.4.1. Example: Future with run_until_complete() 18.5.3.4.2. Example: Future with run_forever() 18.5.3.5. Task 18.5.3.5.1. Example: Parallel execution of tasks 18.5.3.6. Task functions 18.5.4. Transports and protocols (callback based API) 18.5.4.1. Transports 18.5.4.1.1. BaseTransport 18.5.4.1.2. ReadTransport 18.5.4.1.3. WriteTransport 18.5.4.1.4. DatagramTransport 18.5.4.1.5. BaseSubprocessTransport 18.5.4.2. Protocols 18.5.4.2.1. Protocol classes 18.5.4.2.2. Connection callbacks 18.5.4.2.3. Streaming protocols 18.5.4.2.4. Datagram protocols 18.5.4.2.5. Flow control callbacks 18.5.4.2.6. Coroutines and protocols 18.5.4.3. Protocol examples 18.5.4.3.1. TCP echo client protocol 18.5.4.3.2. TCP echo server protocol 18.5.4.3.3. UDP echo client protocol 18.5.4.3.4. UDP echo server protocol 18.5.4.3.5. Register an open socket to wait for data using a protocol 18.5.5. Streams (coroutine based API) 18.5.5.1. Stream functions 18.5.5.2. StreamReader 18.5.5.3. StreamWriter 18.5.5.4. StreamReaderProtocol 18.5.5.5. IncompleteReadError 18.5.5.6. LimitOverrunError 18.5.5.7. Stream examples 18.5.5.7.1. TCP echo client using streams 18.5.5.7.2. TCP echo server using streams 18.5.5.7.3. Get HTTP headers 18.5.5.7.4. Register an open socket to wait for data using streams 18.5.6. Subprocess 18.5.6.1. Windows event loop 18.5.6.2. Create a subprocess: high-level API using Process 18.5.6.3. Create a subprocess: low-level API using subprocess.Popen 18.5.6.4. Constants 18.5.6.5. Process 18.5.6.6. Subprocess and threads 18.5.6.7. Subprocess examples 18.5.6.7.1. Subprocess using transport and protocol 18.5.6.7.2. Subprocess using streams 18.5.7. Synchronization primitives 18.5.7.1. Locks 18.5.7.1.1. Lock 18.5.7.1.2. Event 18.5.7.1.3. Condition 18.5.7.2. Semaphores 18.5.7.2.1. Semaphore 18.5.7.2.2. BoundedSemaphore 18.5.8. Queues 18.5.8.1. Queue 18.5.8.2. PriorityQueue 18.5.8.3. LifoQueue 18.5.8.3.1. Exceptions 18.5.9. Develop with asyncio 18.5.9.1. Debug mode of asyncio 18.5.9.2. Cancellation 18.5.9.3. Concurrency and multithreading 18.5.9.4. Handle blocking functions correctly 18.5.9.5. Logging 18.5.9.6. Detect coroutine objects never scheduled 18.5.9.7. Detect exceptions never consumed 18.5.9.8. Chain coroutines correctly 18.5.9.9. Pending task destroyed 18.5.9.10. Close transports and event loops 18.6. asyncore — Asynchronous socket handler 18.6.1. asyncore Example basic HTTP client 18.6.2. asyncore Example basic echo server 18.7. asynchat — Asynchronous socket command/response handler 18.7.1. asynchat Example 18.8. signal — Set handlers for asynchronous events 18.8.1. General rules 18.8.1.1. Execution of Python signal handlers 18.8.1.2. Signals and threads 18.8.2. Module contents 18.8.3. Example 18.9. mmap — Memory-mapped file support 19. Internet Data Handling 19.1. email — An email and MIME handling package 19.1.1. email.message: Representing an email message 19.1.2. email.parser: Parsing email messages 19.1.2.1. FeedParser API 19.1.2.2. Parser API 19.1.2.3. Additional notes 19.1.3. email.generator: Generating MIME documents 19.1.4. email.policy: Policy Objects 19.1.5. email.errors: Exception and Defect classes 19.1.6. email.headerregistry: Custom Header Objects 19.1.7. email.contentmanager: Managing MIME Content 19.1.7.1. Content Manager Instances 19.1.8. email: Examples 19.1.9. email.message.Message: Representing an email message using the compat32 API 19.1.10. email.mime: Creating email and MIME objects from scratch 19.1.11. email.header: Internationalized headers 19.1.12. email.charset: Representing character sets 19.1.13. email.encoders: Encoders 19.1.14. email.utils: Miscellaneous utilities 19.1.15. email.iterators: Iterators 19.2. json — JSON encoder and decoder 19.2.1. Basic Usage 19.2.2. Encoders and Decoders 19.2.3. Exceptions 19.2.4. Standard Compliance and Interoperability 19.2.4.1. Character Encodings 19.2.4.2. Infinite and NaN Number Values 19.2.4.3. Repeated Names Within an Object 19.2.4.4. Top-level Non-Object, Non-Array Values 19.2.4.5. Implementation Limitations 19.2.5. Command Line Interface 19.2.5.1. Command line options 19.3. mailcap — Mailcap file handling 19.4. mailbox — Manipulate mailboxes in various formats 19.4.1. Mailbox objects 19.4.1.1. Maildir 19.4.1.2. mbox 19.4.1.3. MH 19.4.1.4. Babyl 19.4.1.5. MMDF 19.4.2. Message objects 19.4.2.1. MaildirMessage 19.4.2.2. mboxMessage 19.4.2.3. MHMessage 19.4.2.4. BabylMessage 19.4.2.5. MMDFMessage 19.4.3. Exceptions 19.4.4. Examples 19.5. mimetypes — Map filenames to MIME types 19.5.1. MimeTypes Objects 19.6. base64 — Base16, Base32, Base64, Base85 Data Encodings 19.7. binhex — Encode and decode binhex4 files 19.7.1. Notes 19.8. binascii — Convert between binary and ASCII 19.9. quopri — Encode and decode MIME quoted-printable data 19.10. uu — Encode and decode uuencode files 20. Structured Markup Processing Tools 20.1. html — HyperText Markup Language support 20.2. html.parser — Simple HTML and XHTML parser 20.2.1. Example HTML Parser Application 20.2.2. HTMLParser Methods 20.2.3. Examples 20.3. html.entities — Definitions of HTML general entities 20.4. XML Processing Modules 20.4.1. XML vulnerabilities 20.4.2. The defusedxml and defusedexpat Packages 20.5. xml.etree.ElementTree — The ElementTree XML API 20.5.1. Tutorial 20.5.1.1. XML tree and elements 20.5.1.2. Parsing XML 20.5.1.3. Pull API for non-blocking parsing 20.5.1.4. Finding interesting elements 20.5.1.5. Modifying an XML File 20.5.1.6. Building XML documents 20.5.1.7. Parsing XML with Namespaces 20.5.1.8. Additional resources 20.5.2. XPath support 20.5.2.1. Example 20.5.2.2. Supported XPath syntax 20.5.3. Reference 20.5.3.1. Functions 20.5.3.2. Element Objects 20.5.3.3. ElementTree Objects 20.5.3.4. QName Objects 20.5.3.5. TreeBuilder Objects 20.5.3.6. XMLParser Objects 20.5.3.7. XMLPullParser Objects 20.5.3.8. Exceptions 20.6. xml.dom — The Document Object Model API 20.6.1. Module Contents 20.6.2. Objects in the DOM 20.6.2.1. DOMImplementation Objects 20.6.2.2. Node Objects 20.6.2.3. NodeList Objects 20.6.2.4. DocumentType Objects 20.6.2.5. Document Objects 20.6.2.6. Element Objects 20.6.2.7. Attr Objects 20.6.2.8. NamedNodeMap Objects 20.6.2.9. Comment Objects 20.6.2.10. Text and CDATASection Objects 20.6.2.11. ProcessingInstruction Objects 20.6.2.12. Exceptions 20.6.3. Conformance 20.6.3.1. Type Mapping 20.6.3.2. Accessor Methods 20.7. xml.dom.minidom — Minimal DOM implementation 20.7.1. DOM Objects 20.7.2. DOM Example 20.7.3. minidom and the DOM standard 20.8. xml.dom.pulldom — Support for building partial DOM trees 20.8.1. DOMEventStream Objects 20.9. xml.sax — Support for SAX2 parsers 20.9.1. SAXException Objects 20.10. xml.sax.handler — Base classes for SAX handlers 20.10.1. ContentHandler Objects 20.10.2. DTDHandler Objects 20.10.3. EntityResolver Objects 20.10.4. ErrorHandler Objects 20.11. xml.sax.saxutils — SAX Utilities 20.12. xml.sax.xmlreader — Interface for XML parsers 20.12.1. XMLReader Objects 20.12.2. IncrementalParser Objects 20.12.3. Locator Objects 20.12.4. InputSource Objects 20.12.5. The Attributes Interface 20.12.6. The AttributesNS Interface 20.13. xml.parsers.expat — Fast XML parsing using Expat 20.13.1. XMLParser Objects 20.13.2. ExpatError Exceptions 20.13.3. Example 20.13.4. Content Model Descriptions 20.13.5. Expat error constants 21. Internet Protocols and Support 21.1. webbrowser — Convenient Web-browser controller 21.1.1. Browser Controller Objects 21.2. cgi — Common Gateway Interface support 21.2.1. Introduction 21.2.2. Using the cgi module 21.2.3. Higher Level Interface 21.2.4. Functions 21.2.5. Caring about security 21.2.6. Installing your CGI script on a Unix system 21.2.7. Testing your CGI script 21.2.8. Debugging CGI scripts 21.2.9. Common problems and solutions 21.3. cgitb — Traceback manager for CGI scripts 21.4. wsgiref — WSGI Utilities and Reference Implementation 21.4.1. wsgiref.util – WSGI environment utilities 21.4.2. wsgiref.headers – WSGI response header tools 21.4.3. wsgiref.simple_server – a simple WSGI HTTP server 21.4.4. wsgiref.validate — WSGI conformance checker 21.4.5. wsgiref.handlers – server/gateway base classes 21.4.6. Examples 21.5. urllib — URL handling modules 21.6. urllib.request — Extensible library for opening URLs 21.6.1. Request Objects 21.6.2. OpenerDirector Objects 21.6.3. BaseHandler Objects 21.6.4. HTTPRedirectHandler Objects 21.6.5. HTTPCookieProcessor Objects 21.6.6. ProxyHandler Objects 21.6.7. HTTPPasswordMgr Objects 21.6.8. HTTPPasswordMgrWithPriorAuth Objects 21.6.9. AbstractBasicAuthHandler Objects 21.6.10. HTTPBasicAuthHandler Objects 21.6.11. ProxyBasicAuthHandler Objects 21.6.12. AbstractDigestAuthHandler Objects 21.6.13. HTTPDigestAuthHandler Objects 21.6.14. ProxyDigestAuthHandler Objects 21.6.15. HTTPHandler Objects 21.6.16. HTTPSHandler Objects 21.6.17. FileHandler Objects 21.6.18. DataHandler Objects 21.6.19. FTPHandler Objects 21.6.20. CacheFTPHandler Objects 21.6.21. UnknownHandler Objects 21.6.22. HTTPErrorProcessor Objects 21.6.23. Examples 21.6.24. Legacy interface 21.6.25. urllib.request Restrictions 21.7. urllib.responseResponse classes used by urllib 21.8. urllib.parse — Parse URLs into components 21.8.1. URL Parsing 21.8.2. Parsing ASCII Encoded Bytes 21.8.3. Structured Parse Results 21.8.4. URL Quoting 21.9. urllib.error — Exception classes raised by urllib.request 21.10. urllib.robotparser — Parser for robots.txt 21.11. http — HTTP modules 21.11.1. HTTP status codes 21.12. http.client — HTTP protocol client 21.12.1. HTTPConnection Objects 21.12.2. HTTPResponse Objects 21.12.3. Examples 21.12.4. HTTPMessage Objects 21.13. ftplib — FTP protocol client 21.13.1. FTP Objects 21.13.2. FTP_TLS Objects 21.14. poplib — POP3 protocol client 21.14.1. POP3 Objects 21.14.2. POP3 Example 21.15. imaplib — IMAP4 protocol client 21.15.1. IMAP4 Objects 21.15.2. IMAP4 Example 21.16. nntplib — NNTP protocol client 21.16.1. NNTP Objects 21.16.1.1. Attributes 21.16.1.2. Methods 21.16.2. Utility functions 21.17. smtplib — SMTP protocol client 21.17.1. SMTP Objects 21.17.2. SMTP Example 21.18. smtpd — SMTP Server 21.18.1. SMTPServer Objects 21.18.2. DebuggingServer Objects 21.18.3. PureProxy Objects 21.18.4. MailmanProxy Objects 21.18.5. SMTPChannel Objects 21.19. telnetlib — Telnet client 21.19.1. Telnet Objects 21.19.2. Telnet Example 21.20. uuid — UUID objects according to RFC 4122 21.20.1. Example 21.21. socketserver — A framework for network servers 21.21.1. Server Creation Notes 21.21.2. Server Objects 21.21.3. Request Handler Objects 21.21.4. Examples 21.21.4.1. socketserver.TCPServer Example 21.21.4.2. socketserver.UDPServer Example 21.21.4.3. Asynchronous Mixins 21.22. http.server — HTTP servers 21.23. http.cookies — HTTP state management 21.23.1. Cookie Objects 21.23.2. Morsel Objects 21.23.3. Example 21.24. http.cookiejar — Cookie handling for HTTP clients 21.24.1. CookieJar and FileCookieJar Objects 21.24.2. FileCookieJar subclasses and co-operation with web browsers 21.24.3. CookiePolicy Objects 21.24.4. DefaultCookiePolicy Objects 21.24.5. Cookie Objec
从 Windows 3.0 SDK 发掘的资源,英文原版 + HTML版本 Microsoft Codeview and Utilities User's Guide Microsoft(R) CodeView(R) and Utilities User's Guide Version 2.3 for MS(R) OS/2 and MS-DOS(R) Operating Systems MICROSOFT CORPORATION Information in this document is subject to change without notice and does not represent a commitment on the part of Microsoft Corporation. The software described in this document is furnished under a license agreement or nondisclosure agreement. The software may be used or copied only in accordance with the terms of the agreement. It is against the law to copy the software on any medium except as specifically allowed in the license or nondisclosure agreement. No part of this manual may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording, for any purpose without the express written permission of Microsoft. (c)Copyright Microsoft Corporation, 1987, 1989. All rights reserved. Simultaneously published in the U.S. and Canada. Printed and bound in the United States of America. Microsoft, MS, MS-DOS, XENIX, and CodeView are registered trademarks of Microsoft Corporation. AT&T is a registered trademark of American Telephone and Telegraph Company. Eagle is a registered trademark of Eagle Computer, Inc. IBM is a registered trademark of International Business Machines Corporation. Intel is a registered trademark of Intel Corporation. Lotus is a registered trademark of Lotus Development Corporation. Tandy is a registered trademark of Tandy Corporation. Document No. LN0801A-500-R00-0889 Part No. 07824 10 9 8 7 6 5 4 3 2 1 %@CR:MCVTOC00@% Table of Contents Introduction New Features of the CodeView(R) Debugger About this Manual Document Conventions Part 1 The CodeView Debugger Chapter 1 Getting Started 1.1 Restrictions 1.2 The CodeView Environment 1.3 Preparing Programs for the CodeView Debugger 1.3.1 Programming Considerations 1.3.2 CodeView Compile Options 1.3.3 CodeView Link

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值