On 2/14/06, Just van Rossum <just(a)letterror.com> wrote:
> Guido van Rossum wrote:
> > [...] surely text files are more commonly used, and surely the
> > most common operation should have the shorter name -- call it the
> > Huffman Principle.
>
> +1 for two functions.
>
> My choice would be open() for binary and opentext() for text. I don't
> find that backwards at all: the text function is going to be more
> different from the current open() function then the binary function
> would be since in many ways the str type is closer to bytes than to
> unicode.
It's still backwards because the current open function defaults to
text on Windows (the only platform where it matters any more).
> Maybe it's even better to use opentext() AND openbinary(), and deprecate
> plain open(). We could even introduce them at the same time as bytes()
> (and leave the open() deprecation for 3.0).
And then, on 2/14/06, Alex Martelli <aleaxit(a)gmail.com> wrote:
> What about shorter names, such as 'text' instead of 'opentext' and
> 'data' instead of 'openbinary'? By eschewing the 'open' prefix we
> might make it easy to eventually migrate off it. Maybe text and data
> could be two subclasses of file, with file remaining initially as it
> is (and perhaps becoming an abstract-only baseclass at the time 'open'
> is deprecated).
Plain 'text' and 'data' don't convey the fact that we're talking about
opening I/O objects here. If you want, we could say textfile() and
datafile(). (I'm fine with data instead of binary.)
But somehow I still like the 'open' verb. It has a long and rich
tradition. And it also nicely conveys that it is a factory function
which may return objects of different types (though similar in API)
based upon either additional arguments (e.g. buffering) or the
environment (e.g. encodings) or even inspection of the file being
opened.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
A bunch of Googlers were discussing the best way of doing the
following (a common idiom when maintaining a dict of lists of values
relating to a key, sometimes called a multimap):
if key not in d: d[key] = []
d[key].append(value)
An alternative way to spell this uses setdefault(), but it's not very readable:
d.setdefault(key, []).append(value)
and it also suffers from creating an unnecessary list instance.
(Timings were inconclusive; the approaches are within 5-10% of each
other in speed.)
My conclusion is that setdefault() is a failure -- it was a
well-intentioned construct, but doesn't actually create more readable
code.
Google has an internal data type called a DefaultDict which gets
passed a default value upon construction. Its __getitem__ method,
instead of raising KeyError, inserts a shallow copy (!) of the given
default value into the dict when the value is not found. So the above
code, after
d = DefaultDict([])
can be written as simply
d[key].append(value)
Note that of all the possible semantics for __getitem__ that could
have produced similar results (e.g. not inserting the default in the
underlying dict, or not copying the default value), the chosen
semantics are the only ones that makes this example work.
Over lunch with Alex Martelli, he proposed that a subclass of dict
with this behavior (but implemented in C) would be a good addition to
the language. It looks like it wouldn't be hard to implement. It could
be a builtin named defaultdict. The first, required, argument to the
constructor should be the default value. Remaining arguments (even
keyword args) are passed unchanged to the dict constructor.
Some more design subtleties:
- "key in d" still returns False if the key isn't there
- "d.get(key)" still returns None if the key isn't there
- "d.default" should be a read-only attribute giving the default value
Feedback?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
I just realized that there's a bug in the with-statement as currently
checked in. __exit__ is supposed to re-raise the exception if there
was one; if it returns normally, the finally clause is NOT to re-raise
it. The fix is relatively simple (I believe) but requires updating
lots of unit tests. It'll be a while.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
So I'm planning a 2.4.3c1 around the 22nd-23rd of March, with a 2.4.3
final a week later. This will be the first release since the svn
cutover, which should make things exciting.
This is to get things cleared out before we start the cycle of pain -
ahem - the 2.5 release cycle. A 2.4.4 would then follow when 2.5
final is done, hopefully October or so...
Anyone have any screaming issues with this? Martin's ok to do the
Windows release, and the doc build should be fine, too.
Anthony
--
Anthony Baxter <anthony(a)interlink.com.au>
It's never too late to have a happy childhood.
PEP 263 states that in Phase 2 the default encoding will be set to
ASCII. Although the PEP is marked final, this isn't actually
implemented. The warning about using non-ASCII characters started in
2.3. Does anyone think we shouldn't enforce the default being ASCII?
This means if an # -*- coding: ... -*- is not set and non-ASCII
characters are used, an error will be generated.
n
This could be a replacement for PEP 332. At least I hope it can
serve to summarize the previous discussion and help focus on the
currently undecided issues.
I'm too tired to dig up the rules for assigning it a PEP number.
Also, there are probably silly typos, etc. Sorry.
Neil
Bill Janssen wrote:
> I use it quite a bit for image processing (converting to and from the
> "data:" URL form), and various checksum applications (converting SHA
> into a string).
Aha! We have a customer!
For those cases, would you find it more convenient
for the result to be text or bytes in Py3k?
Greg
I made a few more minor revisions to the AST on the plane this
afternoon. I'll check them in tomorrow when I get a chance to do a
full test run.
* Remove asdl_seq_APPEND. All uses replaced with set
* Fix set_context() comments and check return value every where.
* Reimplement real arena for pyarena.c
Jeremy
After a small talk with Raymond, yesterday in the breakfast, I
proposed in PyAr the idea of start to translate the Library Reference.
You'll agree with me that this is a BIG effort. But not only big, it's dynamic!
So, we decided that we need a system that provide us the management of
the translations. And it'd be a good idea the system to be available
for translations in other languages.
One of the guys proposed to use Launchpad (https://launchpad.net/).
The question is, it's ok to use a third party system for this
initiative? Or you (we) prefer to host it in-house? Someone alredy
thought of this?
Thank you!
. Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
The buildbot shows that the debug-build test_grammar is dying with a C
assert failure on all boxes.
In case it helps, in a Windows release build test_transformer is also failing:
test_transformer
test test_transformer failed -- Traceback (most recent call last):
File "C:\Code\python\lib\test\test_transformer.py", line 16, in
testMultipleLHS
a = transformer.parse(s)
File "C:\Code\python\lib\compiler\transformer.py", line 52, in parse
return Transformer().parsesuite(buf)
File "C:\Code\python\lib\compiler\transformer.py", line 129, in parsesuite
return self.transform(parser.suite(text))
File "C:\Code\python\lib\compiler\transformer.py", line 125, in transform
return self.compile_node(tree)
File "C:\Code\python\lib\compiler\transformer.py", line 158, in compile_node
return self.file_input(node[1:])
File "C:\Code\python\lib\compiler\transformer.py", line 189, in file_input
self.com_append_stmt(stmts, node)
File "C:\Code\python\lib\compiler\transformer.py", line 1036, in
com_append_stmt
result = self.lookup_node(node)(node[1:])
File "C:\Code\python\lib\compiler\transformer.py", line 305, in stmt
return self.com_stmt(nodelist[0])
File "C:\Code\python\lib\compiler\transformer.py", line 1029, in com_stmt
result = self.lookup_node(node)(node[1:])
File "C:\Code\python\lib\compiler\transformer.py", line 315, in simple_stmt
self.com_append_stmt(stmts, nodelist[i])
File "C:\Code\python\lib\compiler\transformer.py", line 1036, in
com_append_stmt
result = self.lookup_node(node)(node[1:])
File "C:\Code\python\lib\compiler\transformer.py", line 305, in stmt
return self.com_stmt(nodelist[0])
File "C:\Code\python\lib\compiler\transformer.py", line 1029, in com_stmt
result = self.lookup_node(node)(node[1:])
File "C:\Code\python\lib\compiler\transformer.py", line 353, in expr_stmt
exprNode = self.lookup_node(en)(en[1:])
File "C:\Code\python\lib\compiler\transformer.py", line 763, in lookup_node
return self._dispatch[node[0]]
KeyError: 324
Also test_parser:
C:\Code\python\PCbuild>python -E -tt ../lib/test/regrtest.py -v test_parser
test_parser
test_assert (test.test_parser.RoundtripLegalSyntaxTestCase) ... FAIL
test_basic_import_statement
(test.test_parser.RoundtripLegalSyntaxTestCase) ... ok
test_class_defs (test.test_parser.RoundtripLegalSyntaxTestCase) ... ok
test_expressions (test.test_parser.RoundtripLegalSyntaxTestCase) ... FAIL
test_function_defs (test.test_parser.RoundtripLegalSyntaxTestCase) ... FAIL
test_import_from_statement
(test.test_parser.RoundtripLegalSyntaxTestCase) ... ok
test_pep263 (test.test_parser.RoundtripLegalSyntaxTestCase) ... ok
test_print (test.test_parser.RoundtripLegalSyntaxTestCase) ... FAIL
test_simple_assignments (test.test_parser.RoundtripLegalSyntaxTestCase) ... FAIL
test_simple_augmented_assignments
(test.test_parser.RoundtripLegalSyntaxTestCase) ... FAIL
test_simple_expression (test.test_parser.RoundtripLegalSyntaxTestCase) ... FAIL
test_yield_statement (test.test_parser.RoundtripLegalSyntaxTestCase) ... FAIL
test_a_comma_comma_c (test.test_parser.IllegalSyntaxTestCase) ... ok
test_illegal_operator (test.test_parser.IllegalSyntaxTestCase) ... ok
test_illegal_yield_1 (test.test_parser.IllegalSyntaxTestCase) ... ok
test_illegal_yield_2 (test.test_parser.IllegalSyntaxTestCase) ... ok
test_junk (test.test_parser.IllegalSyntaxTestCase) ... ok
test_malformed_global (test.test_parser.IllegalSyntaxTestCase) ... ok
test_print_chevron_comma (test.test_parser.IllegalSyntaxTestCase) ... ok
test_compile_error (test.test_parser.CompileTestCase) ... ok
test_compile_expr (test.test_parser.CompileTestCase) ... ok
test_compile_suite (test.test_parser.CompileTestCase) ... ok
======================================================================
FAIL: test_assert (test.test_parser.RoundtripLegalSyntaxTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Code\python\lib\test\test_parser.py", line 180, in test_assert
self.check_suite("assert alo < ahi and blo < bhi\n")
File "C:\Code\python\lib\test\test_parser.py", line 28, in check_suite
self.roundtrip(parser.suite, s)
File "C:\Code\python\lib\test\test_parser.py", line 19, in roundtrip
self.fail("could not roundtrip %r: %s" % (s, why))
AssertionError: could not roundtrip 'assert alo < ahi and blo <
bhi\n': Expected node type 303, got 302.
======================================================================
FAIL: test_expressions (test.test_parser.RoundtripLegalSyntaxTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Code\python\lib\test\test_parser.py", line 50, in test_expressions
self.check_expr("foo(1)")
File "C:\Code\python\lib\test\test_parser.py", line 25, in check_expr
self.roundtrip(parser.expr, s)
File "C:\Code\python\lib\test\test_parser.py", line 19, in roundtrip
self.fail("could not roundtrip %r: %s" % (s, why))
AssertionError: could not roundtrip 'foo(1)': Expected node type 303, got 302.
======================================================================
FAIL: test_function_defs (test.test_parser.RoundtripLegalSyntaxTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Code\python\lib\test\test_parser.py", line 119, in test_function_defs
self.check_suite("def f(foo=bar): pass")
File "C:\Code\python\lib\test\test_parser.py", line 28, in check_suite
self.roundtrip(parser.suite, s)
File "C:\Code\python\lib\test\test_parser.py", line 19, in roundtrip
self.fail("could not roundtrip %r: %s" % (s, why))
AssertionError: could not roundtrip 'def f(foo=bar): pass': Expected
node type 303, got 302.
======================================================================
FAIL: test_print (test.test_parser.RoundtripLegalSyntaxTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Code\python\lib\test\test_parser.py", line 86, in test_print
self.check_suite("print 1")
File "C:\Code\python\lib\test\test_parser.py", line 28, in check_suite
self.roundtrip(parser.suite, s)
File "C:\Code\python\lib\test\test_parser.py", line 19, in roundtrip
self.fail("could not roundtrip %r: %s" % (s, why))
AssertionError: could not roundtrip 'print 1': Expected node type 303, got 302.
======================================================================
FAIL: test_simple_assignments (test.test_parser.RoundtripLegalSyntaxTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Code\python\lib\test\test_parser.py", line 97, in
test_simple_assignments
self.check_suite("a = b")
File "C:\Code\python\lib\test\test_parser.py", line 28, in check_suite
self.roundtrip(parser.suite, s)
File "C:\Code\python\lib\test\test_parser.py", line 19, in roundtrip
self.fail("could not roundtrip %r: %s" % (s, why))
AssertionError: could not roundtrip 'a = b': Expected node type 303, got 302.
======================================================================
FAIL: test_simple_augmented_assignments
(test.test_parser.RoundtripLegalSyntaxTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Code\python\lib\test\test_parser.py", line 101, in
test_simple_augmented_assignments
self.check_suite("a += b")
File "C:\Code\python\lib\test\test_parser.py", line 28, in check_suite
self.roundtrip(parser.suite, s)
File "C:\Code\python\lib\test\test_parser.py", line 19, in roundtrip
self.fail("could not roundtrip %r: %s" % (s, why))
AssertionError: could not roundtrip 'a += b': Expected node type 303, got 302.
======================================================================
FAIL: test_simple_expression (test.test_parser.RoundtripLegalSyntaxTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Code\python\lib\test\test_parser.py", line 94, in
test_simple_expression
self.check_suite("a")
File "C:\Code\python\lib\test\test_parser.py", line 28, in check_suite
self.roundtrip(parser.suite, s)
File "C:\Code\python\lib\test\test_parser.py", line 19, in roundtrip
self.fail("could not roundtrip %r: %s" % (s, why))
AssertionError: could not roundtrip 'a': Expected node type 303, got 302.
======================================================================
FAIL: test_yield_statement (test.test_parser.RoundtripLegalSyntaxTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Code\python\lib\test\test_parser.py", line 31, in
test_yield_statement
self.check_suite("def f(): yield 1")
File "C:\Code\python\lib\test\test_parser.py", line 28, in check_suite
self.roundtrip(parser.suite, s)
File "C:\Code\python\lib\test\test_parser.py", line 19, in roundtrip
self.fail("could not roundtrip %r: %s" % (s, why))
AssertionError: could not roundtrip 'def f(): yield 1': Expected node
type 303, got 302.
----------------------------------------------------------------------
Ran 22 tests in 0.015s
FAILED (failures=8)
test test_parser failed -- errors occurred; run in verbose mode for details
1 test failed:
test_parser
and also test_compiler.
