Re: [Python-Dev] C++ for CPython 3? (Re: str.count is slow)
martin == martin [EMAIL PROTECTED] writes: martin I don't understand. How can you use a C++ compiler, but martin not the C++ language? An abbreviation for those features that aren't in C. martin As the recent const dilemma shows, C99 and C++98 have, martin unfortunately, different interpretations of const (with martin the C interpretation being more strict). Yeah, that's really unfortunate. I suppose we'll probably run into it fairly quickly. Nevertheless, the restriction to programs that are both legal C89 and legal C++ of similar vintage has paid off for us, in the sense that we went from GCC 2.95 to GCC 3.4 without having significant problems where the compiler suddenly decided our code was unacceptable. (Similar experience with other vendors' compilers.) Recently we've seen a significant rise in warnings that need to be fixed, and occasional errors, as GCC 4.x has become more common. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can do free software business; ask what your business can do for free software. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes.from_hex()
Greg Ewing wrote:
Ron Adam wrote:
This uses syntax to determine the direction of encoding. It would be
easier and clearer to just require two arguments or a tuple.
u = unicode(b, 'encode', 'base64')
b = bytes(u, 'decode', 'base64')
The point of the exercise was to avoid using the terms
'encode' and 'decode' entirely, since some people claim
to be confused by them.
Yes, that was what I was trying for with the tounicode, tostring
(tobyte) suggestion, but the direction could become ambiguous as you
pointed out.
The constructors above have 4 data items implied:
1: The source object which includes the source type and data
2: The codec to use
3: The direction of the operation
4: The destination type (determined by the constructor used)
There isn't any ambiguity other than when to use encode or decode, but
in this case that really is a documentation problem because there is no
ambiguities in this form. Everything is explicit.
Another version of the above was pointed out to me off line that might
be preferable.
u = unicode(b, encode='base64')
b = bytes(u, decode='base64')
Which would also work with the tostring and tounicode methods.
u = b.tounicode(decode='base64')
b = u.tobytes(incode='base64')
If we're going to continue to use 'encode' and 'decode',
why not just make them functions:
b = encode(u, 'utf-8')
u = decode(b, 'utf-8')
import codecs
codecs.decode('abc', 'ascii')
u'abc'
There's that time machine again. ;-)
In the case of Unicode encodings, if you get them
backwards you'll get a type error.
The advantage of using functions over methods or
constructor arguments is that they can be applied
uniformly to any input and output types.
If codecs are to be more general, then there may be time when the
returned type needs to be specified. This would apply to codecs that
could return either bytes or strings, or strings or unicode, or bytes or
unicode. Some inputs may equally work with more than one output type.
Of course, the answer in these cases may be to just 'know' what you will
get, and then convert it to what you want.
Cheers,
Ron
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using and binding relative names (was Re: PEP forBetter Control of Nested Lexical Scopes)
Tim Peters wrote: [Alex Martelli] We stole list comprehensions and genexps from Haskell [Greg Ewing] The idea predates Haskell, I think. I first saw it in Miranda, and it may have come from something even earlier -- SETL, maybe? Haskell indeed took list comprehensions from SETL. SETL in turn adopted them from pre-computer standard notation in set theory, related to the oddly named (but not universally so named) axiom of comprehension. genexps were more directly taken from Icon (because of the generator part). SETL and Icon, of course, both have their roots in SNOBOL4, which was designed by Griswold when he worked at (IIRC) Bell Labs. Robert Dewar produced the machine-independent SPITBOL implementation (which I ported to DecSystem 10 as an undergraduate project at Leeds University). Griswold later went to the University of Arizona and developed Icon, Dewar went to Rutgers (I think) and developed SETL. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd www.holdenweb.com Love me, love my blog holdenweb.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When will regex really go away?
[EMAIL PROTECTED] wrote: Neal I'll do this, except there are some issues: Neal * Lib/reconvert.py imports regex. Ok to move regex,regsub,recovert to lib-old? Neal * ./Demo/pdist/rcslib.py ./Demo/sockets/mcast.py import regsub ... Neal * A whole mess of Demos and Tools use regex. What to do about them? ... How about creating Demo/old and populating it with stuff that imports regex, regsub or reconvert? Neal I don't know how to convert the uses of regsub to re, any Neal volunteers? Whippersnapper... sheesh! I still remember when all we had was regex. And we were thankful for it, by golly. Now you'd think the young-uns never knew it existed. wink You had regex? You were lucky. (etc., etc.) yorkshireman-ly y'rs - steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd www.holdenweb.com Love me, love my blog holdenweb.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Faster list comprehensions
Hello all, I've just posted a patch to SF (python.org/sf/1442442) that I thought I'd bring to everyone's attention. Executive summary: by changing the behaviour of the unused LIST_APPEND opcode, it's possible to get a 16% speed boost for list comprehensions. Currently, list comprehensions are built up by calling a bound method on the storage list. This is pretty inefficient, as it requires extra stack manipulation and a function call for each element in the final list. My patch takes the LIST_APPEND opcode (which existed in the eval loop but not the compiler) and changes its behaviour; rather than take its list argument off the stack, it takes a stack offset, allowing it to leave the list object in place. This also replaces the slow Python function call with a fast call directly to PyList_Append. In total, this results in a 16% speed improvement [1]. [1] Benchmarking was done by taking the list comprehension examples in Lib/test/test_grammar.py and running them in a loop a few thousand times. Python revision 42780 took 1.69 seconds to run the examples 1 times; the updated version takes 1.41 seconds. Thanks, Collin Winter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 357
I think PEP 357 and the corresponding patch (python.org/sf/1436368) ae looking pretty good, except for one issue: Currently, when calling the __index__() method on a long with a value exceeding the boundaries of ssize_t will raise OverflowError. The C API chooses to clip such values, but the Python version thows an exception. I think the Python API ought to be allowed to return any long value and it's up to the C API to clip it. Apart from that, I'm ready to accept the PEP. Other opinions? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Faster list comprehensions
[Collin Winter] I've just posted a patch to SF (python.org/sf/1442442) that I thought I'd bring to everyone's attention. Executive summary: by changing the behaviour of the unused LIST_APPEND opcode, it's possible to get a 16% speed boost for list comprehensions. That was working fine in Py2.4. It appears to have gotten left out of the AST compiler. The patch as submitted needs to be revised to only modify the compiler. The other changes were both unnecessary and incorrect -- those components should be left as they were in Py2.4. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] iterator API in Py3.0
On Wed, Mar 01, 2006, Raymond Hettinger wrote: I usually let this sort of thing slide, but the iterator API is too important for trivial, incompatible, and damaging changes. Looking back at Guido's original rationale for naming the method next() instead of __next__(), http://www.python.org/peps/pep-0234.html , it does not look like any of those reasons will cease to apply in Py3.0. OTOH, there is a final comment that choosing next() was perhaps a mistake that cannot be rectified. However, it can certainly be fixed in Python 3.0. My argument in favor of switching to __next__() is rather simple: * As a writer/teacher, I want to be able to say, All Python special methods have leading and trailing double-underscore. Period, end of story. * As a programmer, I want special methods to be VISIBLE. Python is a language for reading code. * Finally, as a debater in the future of the Python language, I don't want any time taken up discussing whether any future special method should get the same kind of special treatment we've given to next(). As for your point about efficiency, I don't much care whether we get a built-in next() function, but I think that anyone who is concerned about efficiency should do next = obj.__next__ which saves an attribute lookup, too. I still think the vast majority of cases will stick with for loops that automatically call __next__() directly. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ 19. A language that doesn't affect the way you think about programming, is not worth knowing. --Alan Perlis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] iterator API in Py3.0
[Aahz] * As a writer/teacher, I want to be able to say, All Python special methods have leading and trailing double-underscore. Period, end of story. When teaching your classes, do you sense an aversion to using double underscore methods in regular code? I sense an implied message that these methods are not intended to be called directly (i.e. the discomfort of typing x.__setitem__(k,v) serves as a cue to write x[k]=v instead; likewise, x.__int__() pushes towards int(x) instead). If so, then that is a good reason to leave it.next() as-is. Unlike __setitem__ or __int__, the next() method is intended to be called directly in normal code. Of course, for-loops are the most common case and it makes no difference there; however, in the rest of the cases where the iterator is accessed directly, the current naming is clean, readable, and doesn't provide an aversive cue. The double underscore convention is appropriate where the method is always invoked magically in normal code and not called directly. The next() method is differenct because it is a mixed case, sometimes called magically and sometimes called directly. In the latter case, the name is highly visible and therefore should not have double underscores. I suspect that those who feel differently are ones who usually avoid calling next() directly. That's okay, but we shouldn't muck-up the naming for the rest of us who often do have a need to use next(). This is doubly important because we're now expanding the protocol to include send() and throw(). Adding underscores around them too will only make those methods look harder to use than they actually are. Don't underestimate the psychological revulsion to calling code filled with piles of double underscores. As for your point about efficiency, I don't much care whether we get a built-in next() function, but I think that anyone who is concerned about efficiency should do next = obj.__next__ There are plenty of places to blow-off efficiency. This iterator protocol is not one of them. Looping constructs need to be as lightweight as possible. Code like next=obj.__next__ should be avoided as much as possible. It is ugly, it incidental to the expression of an algorithm, and it should not be encouraged. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Lib/test/test_compiler.py fails
testCompileLibrary (__main__.CompilerTest) ... compiling /home/splitscreen/src/python/python/Lib/dircache.pycompiling /home/splitscreen/src/python/python/Lib/smtplib.pycompiling /home/splitscreen/src/python/python/Lib/pickle.py ERRORtestFlatten (__main__.CompilerTest) ... oktestLineNo (__main__.CompilerTest) ... oktestNewClassSyntax (__main__.CompilerTest) ... oktestYieldExpr (__main__.CompilerTest) ... ok== ERROR: testCompileLibrary (__main__.CompilerTest)--Traceback (most recent call last): File Lib/test/test_compiler.py, line 36, in testCompileLibrary compiler.compile(buf, basename, exec) File /home/splitscreen/src/python/python/Lib/compiler/pycodegen.py, line 64, in compile gen.compile() File /home/splitscreen/src/python/python/Lib/compiler/pycodegen.py, line 112, in compile gen = ModuleCodeGenerator(tree) File /home/splitscreen/src/python/python/Lib/compiler/pycodegen.py, line 1290, in __init__ walk(tree, self) File /home/splitscreen/src/python/python/Lib/compiler/visitor.py, line 106, in walk walker.preorder(tree, visitor) File /home/splitscreen/src/python/python/Lib/compiler/visitor.py, line 63, in preorder self.dispatch(tree, *args) # XXX *args make sense? File /home/splitscreen/src/python/python/Lib/compiler/visitor.py, line 57, in dispatch return meth(node, *args) File /home/splitscreen/src/python/python/Lib/compiler/pycodegen.py, line 350, in visitModule self.visit(node.node) File /home/splitscreen/src/python/python/Lib/compiler/visitor.py, line 57, in dispatch return meth(node, *args) File /home/splitscreen/src/python/python/Lib/compiler/visitor.py, line 40, in default self.dispatch(child, *args) File /home/splitscreen/src/python/python/Lib/compiler/visitor.py, line 57, in dispatch return meth(node, *args) File /home/splitscreen/src/python/python/Lib/compiler/pycodegen.py, line 362, in visitFunction self._visitFuncOrLambda(node, isLambda=0) File /home/splitscreen/src/python/python/Lib/compiler/pycodegen.py, line 380, in _visitFuncOrLambda walk(node.code, gen) File /home/splitscreen/src/python/python/Lib/compiler/visitor.py, line 106, in walk walker.preorder(tree, visitor) File /home/splitscreen/src/python/python/Lib/compiler/visitor.py, line 63, in preorder self.dispatch(tree, *args) # XXX *args make sense? File /home/splitscreen/src/python/python/Lib/compiler/visitor.py, line 57, in dispatch return meth(node, *args) File /home/splitscreen/src/python/python/Lib/compiler/visitor.py, line 40, in default self.dispatch(child, *args) File /home/splitscreen/src/python/python/Lib/compiler/visitor.py, line 57, in dispatch return meth(node, *args) File /home/splitscreen/src/python/python/Lib/compiler/pycodegen.py, line 894, in visitImport level = 0 if absolute_import in self.futures else -1AttributeError: FunctionCodeGenerator instance has no attribute 'futures'[in file pickle.py]-- Ran 5 tests in 0.878sFAILED (errors=1) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Lib/test/test_compiler.py fails
Yup. It's fixed. n -- On 3/3/06, Matthew Fleming [EMAIL PROTECTED] wrote: testCompileLibrary (__main__.CompilerTest) ... compiling /home/splitscreen/src/python/python/Lib/dircache.py compiling /home/splitscreen/src/python/python/Lib/smtplib.py compiling /home/splitscreen/src/python/python/Lib/pickle.py ERROR testFlatten (__main__.CompilerTest) ... ok testLineNo (__main__.CompilerTest) ... ok testNewClassSyntax (__main__.CompilerTest) ... ok testYieldExpr (__main__.CompilerTest) ... ok == ERROR: testCompileLibrary (__main__.CompilerTest) -- Traceback (most recent call last): File Lib/test/test_compiler.py, line 36, in testCompileLibrary compiler.compile(buf, basename, exec) File /home/splitscreen/src/python/python/Lib/compiler/pycodegen.py, line 64, in compile gen.compile() File /home/splitscreen/src/python/python/Lib/compiler/pycodegen.py, line 112, in compile gen = ModuleCodeGenerator(tree) File /home/splitscreen/src/python/python/Lib/compiler/pycodegen.py, line 1290, in __init__ walk(tree, self) File /home/splitscreen/src/python/python/Lib/compiler/visitor.py, line 106, in walk walker.preorder(tree, visitor) File /home/splitscreen/src/python/python/Lib/compiler/visitor.py, line 63, in preorder self.dispatch(tree, *args) # XXX *args make sense? File /home/splitscreen/src/python/python/Lib/compiler/visitor.py, line 57, in dispatch return meth(node, *args) File /home/splitscreen/src/python/python/Lib/compiler/pycodegen.py, line 350, in visitModule self.visit(node.node) File /home/splitscreen/src/python/python/Lib/compiler/visitor.py, line 57, in dispatch return meth(node, *args) File /home/splitscreen/src/python/python/Lib/compiler/visitor.py, line 40, in default self.dispatch(child, *args) File /home/splitscreen/src/python/python/Lib/compiler/visitor.py, line 57, in dispatch return meth(node, *args) File /home/splitscreen/src/python/python/Lib/compiler/pycodegen.py, line 362, in visitFunction self._visitFuncOrLambda(node, isLambda=0) File /home/splitscreen/src/python/python/Lib/compiler/pycodegen.py, line 380, in _visitFuncOrLambda walk(node.code, gen) File /home/splitscreen/src/python/python/Lib/compiler/visitor.py, line 106, in walk walker.preorder(tree, visitor) File /home/splitscreen/src/python/python/Lib/compiler/visitor.py, line 63, in preorder self.dispatch(tree, *args) # XXX *args make sense? File /home/splitscreen/src/python/python/Lib/compiler/visitor.py, line 57, in dispatch return meth(node, *args) File /home/splitscreen/src/python/python/Lib/compiler/visitor.py, line 40, in default self.dispatch(child, *args) File /home/splitscreen/src/python/python/Lib/compiler/visitor.py, line 57, in dispatch return meth(node, *args) File /home/splitscreen/src/python/python/Lib/compiler/pycodegen.py, line 894, in visitImport level = 0 if absolute_import in self.futures else -1 AttributeError: FunctionCodeGenerator instance has no attribute 'futures'[in file pickle.py] -- Ran 5 tests in 0.878s FAILED (errors=1) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/nnorwitz%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] iterator API in Py3.0
Raymond writes: The double underscore convention is appropriate where the method is always invoked magically in normal code and not called directly. The next() method is differenct because it is a mixed case, sometimes called magically and sometimes called directly. In the latter case, the name is highly visible and therefore should not have double underscores. I think it's clear that if a method is invoked magically, it ought to have underscores; if it is invoked directly then it ought not to. next() is invoked both ways, so the question is which of the following invariants we would rather maintain: * Any method that gets invoked 'magically' (by syntax) will have underscores. * Any method with underscores should be invoked directly only if you are practicing deep magic. What I would *really* like is to keep both invariants... but the only way to do that is to have a __next__() method paired with a next() builtin. (The pattern we use for things like len().) This is great for everyone except for (1) backward compatibility, (2) performance (but does the indirection really need to hurt, and how much?), and (3) proliferation of builtins (adding one more for next() won't hurt, but if we make a practice of it we'll eventually have too many). All told, I prefer using the underscores. I think that the first invariant is important. But it's a judgement call, and a close one, so I'll be happy with either decision. -- Michael Chermside ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] iterator API in Py3.0
On 3/3/06, Raymond Hettinger [EMAIL PROTECTED] wrote: The double underscore convention is appropriate where the method is always invoked magically in normal code and not called directly. The next() method is differenct because it is a mixed case, sometimes called magically and sometimes called directly. In the latter case, the name is highly visible and therefore should not have double underscores. I suspect that those who feel differently are ones who usually avoid calling next() directly. That's okay, but we shouldn't muck-up the naming for the rest of us who often do have a need to use next(). This is doubly important because we're now expanding the protocol to include send() and throw(). Adding underscores around them too will only make those methods look harder to use than they actually are. Don't underestimate the psychological revulsion to calling code filled with piles of double underscores. I think it is a little odd that next is not spelled __next__, but I appreciate the reasons given here in particular. Every time I right .next(), I'm happy that it doesn't have underscores. Jeremy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] iterator API in Py3.0
On Fri, 2006-03-03 at 13:06 -0800, Michael Chermside wrote: I think it's clear that if a method is invoked magically, it ought to have underscores; if it is invoked directly then it ought not to. next() is invoked both ways, so the question is which of the following invariants we would rather maintain: * Any method that gets invoked 'magically' (by syntax) will have underscores. * Any method with underscores should be invoked directly only if you are practicing deep magic. Practicality beats purity, so IMHO if the user should type it, it should not have underscores. If we grow a built-in next() -- which I'm -0 on, then clearly it should get renamed to __next__() because then the user would /not/ be expected to write it. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] iterator API in Py3.0
At 04:09 PM 3/3/2006 -0500, Jeremy Hylton wrote: I think it is a little odd that next is not spelled __next__, but I appreciate the reasons given here in particular. Every time I right .next(), I'm happy that it doesn't have underscores. But then next(ob) should make you even happier, because then there's no '.', either. :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] iterator API in Py3.0
On 3/3/06, Phillip J. Eby [EMAIL PROTECTED] wrote: At 04:09 PM 3/3/2006 -0500, Jeremy Hylton wrote: I think it is a little odd that next is not spelled __next__, but I appreciate the reasons given here in particular. Every time I right .next(), I'm happy that it doesn't have underscores. But then next(ob) should make you even happier, because then there's no '.', either. :) I've got no problem with dots. No shift key necessary :-). On the subject of predilections and builtins, I find myself typing .size() a lot lately. Too much C++, I guess, but it seems so natural as I type it. Jeremy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C++ for CPython 3? (Re: str.count is slow)
It's probably worth mentioning that right now, we don't even come close to compiling with a C++ compiler. A bunch of the bugs are shallow (casting result from malloc, that sort of thing) but a bunch more look a tad uglier. Is this something worth trying to fix? Fixing the shallow bugs at least might be worthwhile... Anthony ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes.from_hex()
Stephen J. Turnbull wrote: Doesn't that make base64 non-text by analogy to other look but don't touch strings like a .gz or vmlinuz? No, because I can take a piece of base64 encoded data and use a text editor to manually paste it in with some other text (e.g. a plain-text (not MIME) mail message). Then I can mail it to someone, or send it by text-mode ftp, or translate it from Unix to MSDOS line endings and give it to a Windows user, or translate it into EBCDIC and give it to someone who has an IBM mainframe, etc, etc. And the person at the other end can use their text editor to manually extract it and decode it and recover the original data. I can't do any of those directly with a .gz file or vmlinuz. I'm not just making those uses up, BTW. It's not very long ago people used to do things like that all the time with uuencode, binhex, etc -- because mail and news at the time were strictly text channels. They still are, really -- otherwise we wouldn't be using anything as hairy as MIME, we'd just mail our binary files as-is. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes.from_hex()
Ron Adam wrote: This would apply to codecs that could return either bytes or strings, or strings or unicode, or bytes or unicode. I'd need to see some concrete examples of such codecs before being convinced that they exist, or that they couldn't just as well return a fixed type that you then transform to what you want. I suspect that said transformation would involve some further encoding or decoding, in which case you really have more than one codec. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes.from_hex()
Greg Ewing wrote:
Ron Adam wrote:
This would apply to codecs that
could return either bytes or strings, or strings or unicode, or bytes or
unicode.
I'd need to see some concrete examples of such codecs
before being convinced that they exist, or that they
couldn't just as well return a fixed type that you
then transform to what you want.
I think text some codecs that currently return 'ascii' encoded text
would be candidates. If you use u'abc'.encode('rot13') you get an ascii
string back and not a unicode string. And if you use decode to get back,
you don't get the original unicode back, but an ascii representation of
the original you then need to decode to unicode.
I suspect that said transformation would involve some
further encoding or decoding, in which case you really
have more than one codec.
Yes, I can see that.
So the following are probable better reasons to specify the type.
Codecs are very close to types and they quite often result in a type
change, having the change visible in the code adds to overall
readability. This is probably my main desire for this.
There is another reason for being explicit about types with codecs. If
you store the codecs with a tuple of attributes as the keys, (name,
in_type, out_type), then it makes it possible to look up the codec with
the correct behavior and then just do it.
The alternative is to test the input, try it, then test the output. The
look up doesn't add much overhead, but does adds safety. Codecs don't
seem to be the type of thing where you will want to be able to pass a
wide variety of objects into. So a narrow slot is probably preferable
to a wide one here.
In cases where a codec might be useful in more than one combination of
types, it could have an entry for each valid combination in the lookup
table. The codec lookup also validates the desired operation for nearly
free. Of course, the data will need to be valid as well. ;-)
Cheers,
Ron
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .py and .txt files missing svn:eol-style in trunk
[Oleg Broytmann[ My experience shows that if the developers use different OSes (our team uses Linux and Windows) it helps very much to set svn:eol-style to native for all text files - *.py, *.txt, etc, except for files with special requirements. Yes. So I use the following shell script #! /bin/sh svn add $@ svn propset svn:eol-style native $@ svn propset svn:keywords Date Rev Id $@ to add *.py files to the repository. (I don't want to put it in a global configuration because I have different requirements for different projects.) For other text files the same except keywords: #! /bin/sh svn add $@ svn propset svn:eol-style native $@ test_pepe263 probably should be binary (it contains funny characters). It should be text with encoding $ svn propset svn:mime-type text/plain; charset=koi8-r test_pep263 The reason it's binary is given in a comment at the top of the file: | # This file is marked as binary in the CVS, to prevent MacCVS from recoding it. So someone on a Mac should check whether the Mac flavor of SVN also screws it up. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Bug in from __future__ processing?
Hello, The Python spec states that the from __future__ import statement can only occur at the beginning of the file, preceded only by doc strings, comments, empty lines or other future statements. The following code snippets, however, dont raise Syntax error in Python 2.4.2. Is it a bug? I am asking whether in IronPython we should try to match behavior of Python compiler, or stick to the language spec. In this case, I believe that we should stick to the spec and report a bug in Python compiler. Thanks Martin Example 1: -- x = 10 / 2 from __future__ import division -- Example 2: -- from sys import * from __future__ import division -- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug in from __future__ processing?
[Martin Maly] The Python spec states that the from __future__ import … statement can only occur at the beginning of the file, preceded only by doc strings, comments, empty lines or other future statements. The following code snippets, however, don't raise Syntax error in Python 2.4.2. Is it a bug? I am asking whether in IronPython we should try to match behavior of Python compiler, or stick to the language spec. In this case, I believe that we should stick to the spec and report a bug in Python compiler. Guido bumped into this about a month ago, noting that he thought it was a bug in current Python trunk that the PEP restrictions _are_ followed now. I replied that I thought it was a bug in released Pythons that the PEP restrictions were _not_ followed: http://mail.python.org/pipermail/python-dev/2006-January/060247.html Doesn't look like Guido responded, so I'll channel him and declare that he intended to agree with me after all ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug in from __future__ processing?
On 3/3/06, Tim Peters [EMAIL PROTECTED] wrote: [Martin Maly] The Python spec states that the from __future__ import … statement can only occur at the beginning of the file, preceded only by doc strings, comments, empty lines or other future statements. The following code snippets, however, don't raise Syntax error in Python 2.4.2. Is it a bug? I am asking whether in IronPython we should try to match behavior of Python compiler, or stick to the language spec. In this case, I believe that we should stick to the spec and report a bug in Python compiler. Guido bumped into this about a month ago, noting that he thought it was a bug in current Python trunk that the PEP restrictions _are_ followed now. I replied that I thought it was a bug in released Pythons that the PEP restrictions were _not_ followed: http://mail.python.org/pipermail/python-dev/2006-January/060247.html Doesn't look like Guido responded, so I'll channel him and declare that he intended to agree with me after all ;-) It was so obvious that you were right I didn't bother to agree at the time. But yes, I agree. And I swear on a stack of Python 1.5.2 language reference manuals that you didn't have to twist my arm. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] __exit__ API?
A few days ago there were rumbling noises that requiring __exit__ to re-raise the exception (as I amended PEP 343 at the time) could lead to easily-missed bugs in __exit__ handlers. After thinking it over I think I agree and I think I'd like to change the API so that the exception is only ignored if __exit__ returns a true value. The easiest implementation is probably to just let the WITH_CLEANUP opcode do everything. This becomes a rather heavy opcode then but the alternative is to generate very hairy code (like the original patch did, full of ROT 4 choruses). Any objections? I probably won't get to this until Monday. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug in from __future__ processing?
[Tim] Doesn't look like Guido responded, so I'll channel him and declare that he intended to agree with me after all ;-) [Guido] It was so obvious that you were right I didn't bother to agree at the time. But yes, I agree. Of course you do. It was obvious to you, and therefore-- as your professional channeler --it was also obvious to me. For some inscrutable reason, though, others tend to imagine looming disasters in silence, instead of just plucking your comforting thoughts from the aether ;-) And I swear on a stack of Python 1.5.2 language reference manuals that you didn't have to twist my arm. :-) Indeed! But whose arm could we twist to get them to repair the compiler in 2.4? I'd settle for a blurb in the next 2.4 NEWS just noting that 2.5 will follow the documented syntax. That may even be desirable, to avoid breaking working (albeit by accident) code across a micro release. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .py and .txt files missing svn:eol-style in trunk
On Wed, 2006-03-01 at 00:17 -0600, Tim Peters wrote: OK, I tried to set eol-style on all of those. svn refused to change these: svn: File 'Lib\email\test\data\msg_26.txt' has binary mime type property Yeah, there's no reason for that, so I've fixed it. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .py and .txt files missing svn:eol-style in trunk
On Fri, 2006-03-03 at 23:43 -0500, Barry Warsaw wrote: On Wed, 2006-03-01 at 00:17 -0600, Tim Peters wrote: OK, I tried to set eol-style on all of those. svn refused to change these: svn: File 'Lib\email\test\data\msg_26.txt' has binary mime type property Yeah, there's no reason for that, so I've fixed it. Or wait, you fixed it there. I fixed it in the sandbox. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] iterator API in Py3.0
Raymond Hettinger wrote: When teaching your classes, do you sense an aversion to using double underscore methods in regular code? I sense an implied message that these methods are not intended to be called directly (i.e. the discomfort of typing x.__setitem__(k,v) serves as a cue to write x[k]=v instead; likewise, x.__int__() pushes towards int(x) instead). the if called magically, it should be __xxx__ rule is pretty worthless on its own; you also need to answer the questions called by whom ? and never called by application code ? (from the sound of it, one could suspect that some posters here would like all template methods in all standard library components to use the __xxx__ form). /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
