The test_socketserver unittest seems to be failing occasionally for
me. (Svn HEAD, Ubuntu dapper.)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
I have a curious situation which might be a bug in urllib (Python 2.5
installed from a .msi file gotten from python.org) when running on
Windows XP. (This is running inside a Parallels virtual machine, but I
don't see how that matters, because, as you will see in a second, I'm
able to access the Web server both by its IP address and name.
Here's a screenshot of a console session:
http://www.ncee.net/shane/urllib.png
You can see from the screenshot:
1. This machine is able to ping the Web server's IP address.
2. I can even access the Web server via the DNS name assigned
(www.nce.net) using wget.exe (from UnxUtils).
3. However, when I try to simulate wget.exe by using urllib, I get an
error.
Here's the urllib command (which, incidentally works fine from my
MacBook Pro):
python -c "import urllib ;
urllib.urlretrieve(\"http://www.ncee.net/shane/test.py\",\"test.py\")"
I tested this on a Windows 2000 Server, and urllib behaved normally.
Is this possibly a bug on Windows XP?
--
Shane Geiger
IT Director
National Council on Economic Education
sgeiger(a)ncee.net | 402-438-8958 | http://www.ncee.net
Leading the Campaign for Economic and Financial Literacy
Trent Mick has a module called which.py that might make a nice
platform-independent replacement for python2.5/Tools/scripts/which.py.
http://www.trentm.com/projects/which/
Why which.py?
|which.py| is a small GNU-which replacement. It has the following features:
* it is portable (Windows, Linux, Mac OS X, Un*x);
* it understands PATHEXT and "App Paths" registration on Windows
(i.e. it will find everything that |start| does from the command
shell);
* it can print all matches on the PATH;
* it can note "near misses" on the PATH (e.g. files that match but
may not, say, have execute permissions); and
* it can be used as a Python module.
I also would be happy to have this be a replacement for the |which.py|
in the Python CVS tree at |dist/src/Tools/scripts/which.py| which is
Unix-specific and not usable as a module; and perhaps for inclusion in
the stdlib.
--
Shane Geiger
IT Director
National Council on Economic Education
sgeiger(a)ncee.net | 402-438-8958 | http://www.ncee.net
Leading the Campaign for Economic and Financial Literacy
Has anyone heard the Python+XUL community cry "I'm not dead yet!" or are
they really dead? I haven't seen mentions of new work in these areas
lately. XUL in general seems to have died (so many broken links on XUL
pages). Was this just a fad? If not, and if there's some really useful
of it (especially if in Python) please point it out.
--
Shane Geiger
IT Director
National Council on Economic Education
sgeiger(a)ncee.net | 402-438-8958 | http://www.ncee.net
Leading the Campaign for Economic and Financial Literacy
PEP: XXX
Title: Postfix type declarations
Version: $Revision: $
Last-Modified: $Date: $
Author: Georg Brandl <g.brandl(a)gmx.net>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 01-Apr-2007
Python-Version: 3.0
Abstract
========
This PEP proposes the addition of a postfix type declaration syntax to
Python. It also specifies a new ``typedef`` statement which is used to create
new mappings between types and declarators.
Its acceptance will greatly enhance the Python user experience as well as
eliminate one of the warts that deter users of other programming languages from
switching to Python.
Rationale
=========
Python has long suffered from the lack of explicit type declarations. Being one
of the few aspects in which the language deviates from its Zen, this wart has
sparked many a discussion between Python heretics and members of the PSU (for
a few examples, see [EX1]_, [EX2]_ or [EX3]_), and it also made it a large-scale
enterprise success unlikely.
However, if one wants to put an end to this misery, a decent Pythonic syntax
must be found. In almost all languages that have them, type declarations lack
this quality: they are verbose, often needing *multiple words* for a single
type, or they are hard to comprehend (e.g., a certain language uses completely
unrelated [#]_ adjectives like ``dim`` for type declaration).
Therefore, this PEP combines the move to type declarations with another bold
move that will once again prove that Python is not only future-proof but
future-embracing: the introduction of Unicode characters as an integral
constituent of source code.
Unicode makes it possible to express much more with much less characters, which
is in accordance with the Zen ("Readability counts.") [ZEN]_. Additionally, it
eliminates the need for a separate type declaration statement, and last but not
least, it makes Python measure up to Perl 6, which already uses Unicode for its
operators. [#]_
Specification
=============
When the type declaration mode is in operation, the grammar is changed so that
each ``NAME`` must consist of two parts: a name and a type declarator, which is
exactly one Unicode character.
The declarator uniquely specifies the type of the name, and if it occurs on the
left hand side of an expression, this type is enforced: an ``InquisitionError``
exception is raised if the returned type doesn't match the declared type. [#]_
Also, function call result types have to be specified. If the result of the call
does not have the declared type, an ``InquisitionError`` is raised. Caution: the
declarator for the result should not be confused with the declarator for the
function object (see the example below).
Type declarators after names that are only read, not assigned to, are not strictly
necessary but enforced anyway (see the Python Zen: "Explicit is better than
implicit.").
The mapping between types and declarators is not static. It can be completely
customized by the programmer, but for convenience there are some predefined
mappings for some built-in types:
========================= ===================================================
Type Declarator
========================= ===================================================
``object`` � (REPLACEMENT CHARACTER)
``int`` ℕ (DOUBLE-STRUCK CAPITAL N)
``float`` ℮ (ESTIMATED SYMBOL)
``bool`` ✓ (CHECK MARK)
``complex`` ℂ (DOUBLE-STRUCK CAPITAL C)
``str`` ✎ (LOWER RIGHT PENCIL)
``unicode`` ✒ (BLACK NIB)
``tuple`` ⒯ (PARENTHESIZED LATIN SMALL LETTER T)
``list`` ♨ (HOT SPRINGS)
``dict`` ⧟ (DOUBLE-ENDED MULTIMAP)
``set`` ∅ (EMPTY SET) (*Note:* this is also for full sets)
``frozenset`` ☃ (SNOWMAN)
``datetime`` ⌚ (WATCH)
``function`` ƛ (LATIN SMALL LETTER LAMBDA WITH STROKE)
``generator`` ⚛ (ATOM SYMBOL)
``Exception`` ⌁ (ELECTRIC ARROW)
========================= ===================================================
The declarator for the ``None`` type is a zero-width space.
These characters should be obvious and easy to remember and type for every
programmer.
Unicode replacement units
=========================
Since even in our modern, globalized world there are still some old-fashioned
rebels who can't or don't want to use Unicode in their source code, and since
Python is a forgiving language, a fallback is provided for those:
Instead of the single Unicode character, they can type ``name${UNICODE NAME OF
THE DECLARATOR}$``. For example, these two function definitions are equivalent::
def fooƛ(xℂ):
return None
and ::
def foo${LATIN SMALL LETTER LAMBDA WITH STROKE}$(x${DOUBLE-STRUCK CAPITAL C}$):
return None${ZERO WIDTH NO-BREAK SPACE}$
This is still easy to read and makes the full power of type-annotated Python
available to ASCII believers.
The ``typedef`` statement
=========================
The mapping between types and declarators can be extended with this new statement.
The syntax is as follows::
typedef_stmt ::= "typedef" expr DECLARATOR
where ``expr`` resolves to a type object. For convenience, the ``typedef`` statement
can also be mixed with the ``class`` statement for new classes, like so::
typedef class Foo☺(object�):
pass
Example
=======
This is the standard ``os.path.normpath`` function, converted to type declaration
syntax::
def normpathƛ(path✎)✎:
"""Normalize path, eliminating double slashes, etc."""
if path✎ == '':
return '.'
initial_slashes✓ = path✎.startswithƛ('/')✓
# POSIX allows one or two initial slashes, but treats three or more
# as single slash.
if (initial_slashes✓ and
path✎.startswithƛ('//')✓ and not path✎.startswithƛ('///')✓)✓:
initial_slashesℕ = 2
comps♨ = path✎.splitƛ('/')♨
new_comps♨ = []♨
for comp✎ in comps♨:
if comp✎ in ('', '.')⒯:
continue
if (comp✎ != '..' or (not initial_slashesℕ and not new_comps♨)✓ or
(new_comps♨ and new_comps♨[-1]✎ == '..')✓)✓:
new_comps♨.appendƛ(comp✎)
elif new_comps♨:
new_comps♨.popƛ()✎
comps♨ = new_comps♨
path✎ = '/'.join(comps♨)✎
if initial_slashesℕ:
path✎ = '/'*initial_slashesℕ + path✎
return path✎ or '.'
As you can clearly see, the type declarations add expressiveness, while at the
same time they make the code look much more professional.
Compatibility issues
====================
To enable type declaration mode, one has to write::
from __future__ import type_declarations
which enables Unicode parsing of the source [#]_, makes ``typedef`` a keyword
and enforces correct types for all assignments and function calls.
References
==========
.. [EX1] http://mail.python.org/pipermail/python-list/2003-June/210588.html
.. [EX2] http://mail.python.org/pipermail/python-list/2000-May/034685.html
.. [EX3]
http://groups.google.com/group/comp.lang.python/browse_frm/thread/6ae8c6add…
.. [#] Though, if you know the language in question, it may not be *that* unrelated.
.. [ZEN] http://www.python.org/dev/peps/pep-0020/
.. [#] Well, it would, if there was a Perl 6.
.. [#] Since the name ``TypeError`` is already in use, this name has been chosen
for obvious reasons.
.. [#] The encoding in which the code is written is read from a standard coding
cookie. There will also be an autodetection mechanism, invoked by ``from
__future__ import encoding_hell``.
Acknowledgements
================
Many thanks go to Armin Ronacher, Alexander Schremmer and Marek Kubica who helped
find the most suitable and mnemonic declarator for built-in types.
Thanks also to the Unicode Consortium for including all those useful characters
in the Unicode standard.
Copyright
=========
This document has been placed in the public domain.
..
Local Variables:
coding: utf-8
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
End:
Some subclasses of Exception are no longer pickleable in Python 2.5. An
example:
class A(Exception):
def __init__(self, foo):
self.foo = foo
The key problem here is if you do not somehow set self.args to the correct
arguments (via Exception.__init__ or setting self.args directly), you will
get a TypeError when you try to unpickle it:
TypeError: __init__() takes exactly 2 arguments (1 given)
I do not think this is unusual. I found a few examples in Python's
standard library that have this problem:
subprocess.CalledProcessError
HTMLParser.HTMLParseError
httplib.UnknownProtocol, httplib.IncompleteRead, httplib.BadStatusLine
optparse.OptParseError
pickle._Stop
and on and on...
Does anyone have any thoughts about this? Is it a bug?
I can imagine one could argue that exceptions should call the base
__init__ method to properly set args, but there are so many exceptions out
there that do not do this that it would be very difficult to track them
all down.
I removed the __reduce__ and __setstate__ methods from BaseException and
everything seems to just work. Pickling/unpickling works for all
protocols whether or not you set self.args. Is this an appropriate
solution? I'm not sure what the motivation for having these methods is.
-Eric
This is a reminder that the 2.5 branch will be frozen early next week.
If there are changes you want to get into 2.5.1, they should be
checked in within a few days. Be conservative! There will be a
2.5.2, it's better to wait than to have to make a new release for one
rushed feature. If you don't believe, just wait until Anthony shows
up at your doorstep. :-)
n
Python Doc Problem Example: os.path.split()
Xah Lee, 20050918
Quote from: http://www.python.org/doc/2.4.1/lib/module-os.path.html
«
split(path)
Split the pathname path into a pair, (head, tail) where tail is
the last pathname component and head is everything leading up to
that. The tail part will never contain a slash; if path ends in a
slash, tail will be empty. If there is no slash in path, head will be
empty. If path is empty, both head and tail are empty. Trailing
slashes are stripped from head unless it is the root (one or more
slashes only). In nearly all cases, join(head, tail) equals path (the
only exception being when there were multiple slashes separating head
from tail).
»
This confusive verbiage is a result of the author's pretention in a
austere style and his failure to think clearly before writing.
Suggested rewrite:
«
split(path)
returns a pair (dirname,filename), where dirname is the part of
path up to the last slash, and filename is the rest of the string
after the last slash.
Exceptional cases are:
• if path is a single slash (or repeated), then path == dirname
and filename is empty.
• If the last slash is repeated, they are treated as one single
slash.
»
I was working on a program where i needed to split a path into
dirname, corename, and suffix.
I came to this page and took me a while to understand what split() is
about. There are other path related functions splitext(), splitdrive
(), basename(), dirname(). User has to scan the whole page and read
painfully each one to fully understand how to choose and use them for
the task at hand.
As i have explained before (see references at bottom), documentation
should be organized oriented towards programer's tasks, not
alphabetically, compiler view, or computer sciency scheme. On this
os.path module, split(), splittext(), dirname(), basename() should
all be under one section. This way, their usefulness and each's
fitness becomes clearer, and also easier to document as a collective.
Other functions that test files or get info about files should be
grouped together. Don't be afraid of having functions that won't fit
into some grouping scheme. For exapmle, the walk() and
supports_unicode_filenames() can be lumped at the bottom as Other.
The need to present materials in some aloof, computer sciency,
academic, technically precise way is a major usability problem of the
Python doc.
(the Pythoners's need to present materials in a formal style is a
backlash of the happy-go-lucky sloppiness of unix/perl community.
However, they being pretty much the same crowd without significant
critical thinking and writing skills, cannot do better by hiding in
formality.)
Also, at the top we see:
Warning: On Windows, many of these functions do not properly
support UNC pathnames. splitunc() and ismount() do handle them
correctly.
As indicated before, this is a exhibition of tech geeking and
jargonizing. If this warning is necessary, place it at the bottom of
the page as a footnote. Also, spell out UNC, and provide a link to
its proper spec.
Tech geekers are very pretentious and cryptic in their tech docs.
They are afraid, as if spelling out UNC would make them
unprofessional, that their peers would deem them inferior. There are
a myriad of technical standards that any programer could only be
familiar with a fraction, confined to his area of expertise.
Standards and its acronyms come and go, and each with varying degrees
of precision, actual relevance, and they are intermingled with de
facto practices in the commercial world that may not even have
official names. The tech geekers are clouded by their tech-expertise.
The purpose of documentation is not some cold academic presentation.
Vast majority who came to use os.path wouldn't know what UNC is nor
do they need to know. Spell things out when in doubt.
UNC here, isn't really a significant “standard”. This warning
should be left out.
Suggestions:
* Regroup path manipulating functions together, file info
functions together, etc.
* After regrouping the functions, much of the writing can be
simplified since these functions are doing similar tasks. Writing can
focus on their differences. Rewrite them with a focus on what users
needs to do. Add examples in intricate situations. Avoid the computer
science thesis writing style.
* Remove the UNC warning at the top.
-----
Here are a few other Python doc problems i've written in the past years:
Python doc problem example: os.system()
http://xahlee.org/perl-python/python_doc_os.html
Python Doc Problem Example: os.path.split()
http://xahlee.org/perl-python/python_doc_os_path_split.html
Python Doc Problem Example: sort()
http://xahlee.org/perl-python/python_doc_sort.html
Python Doc Problem Example: gzip module
http://xahlee.org/perl-python/python_doc_gzip.html
Xah
xah(a)xahlee.org
∑ http://xahlee.org/
☄
