|
Size: 1345
Comment: the interdependencies between noise and emissions. Aircraft designed to meet stringent, [[http://140.112.13.91/eg2008/airline-in-israel-279|airline in israel]]millimeters can adversely affect aircraft
|
← Revision 17 as of 2009-09-13 06:07:15 ⇥
Size: 4807
Comment: Revert off-topic spam
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| the interdependencies between noise and emissions. Aircraft designed to meet stringent, [[http://140.112.13.91/eg2008/airline-in-israel-279|airline in israel]]millimeters can adversely affect aircraft aerodynamic performance (Valarezo et al., 1993;, yzxom, [[http://hvr.postech.ac.kr/wiki/wiki.php/airline-to-puerto-rico-98|airline to puerto rico]]Thus it can take up to 40 years to turn a fleet over to a new technology. In addition,, 6046, [[http://hvr.postech.ac.kr/wiki/wiki.php/emirate-airline-96|emirate airline]]deicing while aircraft await takeoff. The exact compositions of different ADFs and AAFs, 26059, [[http://projects.dorkbot.org/rd04/wiki/nationwide-airline-354|nationwide airline]]statements that are required prior to airport development projects or airspace redesign., 142796, [[http://ccan.ozlabs.org/Wiki/ba-airline-306|ba airline]]may have negative consequences for local, national and world economies. But allow-, :))), [[http://www.sulug.sun.ac.za/cgi-bin/moin.cgi/jordan-airline-218|jordan airline]]areas are kept free of weeds for aircraft safety and to preserve the infrastructure. If, :DD, [[http://miya.pe.kr/wiki/airline-certification-101|airline certification]]operations and technology). Operational changes include limiting flight hours (e.g., noise, bfi, ---- CategoryIntegratedDevelopmentEnvironment |
Björn Lindqvist restarted the discussion about getting Path into the stdlib in January. The PEP and reference implementation is available here: [[http://www.python.org/dev/peps/pep-0355|PEP 355]], PathModule, PathModuleTests There are alternative proposals as well: AlternativePathClass, AlternativePathDiscussion, AlternativePathModuleTests = Path class Pre-Pre-PEP = == Introduction == The Python Standard Library currently has many modules that allow the developer to interact with the filesystem. Currently this set of modules is: * os * os.path * fnmatch * glob * shutil * stat This PEP proposes that a new class or module be added to the Python Standard Library that will make all filesystem operations available from one place in a consistent way. == Reference Implementation == Reinhold has modified Jason Orendorff's original path.py to fit discussions in python-dev and comp.lang.python and has placed it in Python under nondist/sandbox/path: http://svn.python.org/projects/sandbox/trunk/path/path.py Other implementations to look at include the original, path.py and some things that others have mentioned on c.l.p. and python-dev. Jason Orendorff's original path.py can be found here: http://www.jorendorff.com/articles/python/path/ == Motivation == The motivation for a single standard class or module to handle filesystem operations is threefold: * Reduce the number of modules a user must import and refer to to do common operations * Aesthetics: code written with the reference implementation is more concise, easier to read, and also easier to write * Consistency: All filesystem operations should be accessed from within the same module. == Design Principles == 1. A Path should be a drop-in replacement for a str or unicode as much as possible. 2. Properties are the interface for actual attributes of a Path. For example, a Path's basename will be the same regardless of data on the local filesystem. Accessing a Path property will never result in an IOError. 3. Methods are the interface for attributes of whatever the Path represents, for example, the last-modified-time or contents of a file. Calling a Path method may result in an IOError if the method accesses the actual filesystem and finds a problem (e.g. the Path refers to a nonexistent file). 4. [Done in CVS] Should be subclassable so third parties can offer richer subclasses. Use {{{self.__class__()}}} instead of {{{Path()}}} in method bodies. Alternate constructors like {{{Path.cwd()}}} should be a class methods rather than static methods. (MikeOrr) == Backwards Compatibility == If this PEP is accepted, then several of the existing standard modules will become redundant, which violates the [[TOOWTDI]] principle. The following modules will become redundant: * os.path * shutils * fnmatch * glob * stat * parts of os (like mkdir) It is proposed that Python 2.5 will mark redundant modules as deprecated and issue a warning when they are imported. The functionality that these modules offer should be moved into the path module. Python 2.6 will remove the redundant modules from the standard library. == Open Issues == * What to call this module / class, and where to put it? * API issues with reference implementation: * Remove duplicate functionality: * .joinpath / .joinwith * Property / method consistency: * .parent -> .dirname (and get rid of .dirname()) * .name -> .filename (and get rid of .basename()) * .namebase -> .filebase * .atime/.mtime/.ctime -> .atime()/.mtime()/.ctime() * .size -> .filesize() * .splitall() -> .parts() * bytes() -> get_bytes() * write_bytes() -> set_bytes() / append_bytes() * text() -> get_text() * write_text() -> set_text() / append_text() * lines() -> get_lines() * write_lines() -> set_lines() / append_lines() * .joinpath(*args) -> .subpath(*args)? * This needs consensus, I prefer .joinpath() * .listdir() -> .subpaths() OR .listpaths() * drop .getcwd()? * default constructor could assign absolute cwd, or "."? * Should .mtime()/etc. return datetime objects? * I vote no, timestamps are fine == Discussions == * http://sourceforge.net/tracker/index.php?func=detail&aid=1226256&group_id=5470&atid=355470 * http://thread.gmane.org/gmane.comp.python.devel/69403 * http://mail.python.org/pipermail/python-dev/2005-June/054438.html * http://groups.google.ca/group/comp.lang.python/msg/822a302350658a01 |
Björn Lindqvist restarted the discussion about getting Path into the stdlib in January. The PEP and reference implementation is available here: PEP 355, PathModule, PathModuleTests
There are alternative proposals as well: AlternativePathClass, AlternativePathDiscussion, AlternativePathModuleTests
Path class Pre-Pre-PEP
Introduction
The Python Standard Library currently has many modules that allow the developer to interact with the filesystem. Currently this set of modules is:
- os
- os.path
- fnmatch
- glob
- shutil
- stat
This PEP proposes that a new class or module be added to the Python Standard Library that will make all filesystem operations available from one place in a consistent way.
Reference Implementation
Reinhold has modified Jason Orendorff's original path.py to fit discussions in python-dev and comp.lang.python and has placed it in Python under nondist/sandbox/path: http://svn.python.org/projects/sandbox/trunk/path/path.py
Other implementations to look at include the original, path.py and some things that others have mentioned on c.l.p. and python-dev.
Jason Orendorff's original path.py can be found here: http://www.jorendorff.com/articles/python/path/
Motivation
The motivation for a single standard class or module to handle filesystem operations is threefold:
- Reduce the number of modules a user must import and refer to to do common operations
- Aesthetics: code written with the reference implementation is more concise, easier to read, and also easier to write
- Consistency: All filesystem operations should be accessed from within the same module.
Design Principles
1. A Path should be a drop-in replacement for a str or unicode as much as possible.
2. Properties are the interface for actual attributes of a Path. For example, a Path's basename will be the same regardless of data on the local filesystem. Accessing a Path property will never result in an IOError.
3. Methods are the interface for attributes of whatever the Path represents, for example, the last-modified-time or contents of a file. Calling a Path method may result in an IOError if the method accesses the actual filesystem and finds a problem (e.g. the Path refers to a nonexistent file).
4. [Done in CVS] Should be subclassable so third parties can offer richer subclasses. Use self.__class__() instead of Path() in method bodies. Alternate constructors like Path.cwd() should be a class methods rather than static methods. (MikeOrr)
Backwards Compatibility
If this PEP is accepted, then several of the existing standard modules will become redundant, which violates the TOOWTDI principle. The following modules will become redundant:
- os.path
- shutils
- fnmatch
- glob
- stat
- parts of os (like mkdir)
It is proposed that Python 2.5 will mark redundant modules as deprecated and issue a warning when they are imported. The functionality that these modules offer should be moved into the path module.
Python 2.6 will remove the redundant modules from the standard library.
Open Issues
- What to call this module / class, and where to put it?
- API issues with reference implementation:
- Remove duplicate functionality:
- .joinpath / .joinwith
- Property / method consistency:
.parent -> .dirname (and get rid of .dirname())
.name -> .filename (and get rid of .basename())
.namebase -> .filebase
.atime/.mtime/.ctime -> .atime()/.mtime()/.ctime()
.size -> .filesize()
.splitall() -> .parts()
bytes() -> get_bytes()
write_bytes() -> set_bytes() / append_bytes()
text() -> get_text()
write_text() -> set_text() / append_text()
lines() -> get_lines()
write_lines() -> set_lines() / append_lines()
.joinpath(*args) -> .subpath(*args)?
- This needs consensus, I prefer .joinpath()
.listdir() -> .subpaths() OR .listpaths()
- drop .getcwd()?
- default constructor could assign absolute cwd, or "."?
- Should .mtime()/etc. return datetime objects?
- I vote no, timestamps are fine
- Remove duplicate functionality: