[Python-Dev] TAR problems under Solaris
Recently, someone on dclpy posted about an error he got when he tried to unpack the Python distribution tarball with Sparc Solaris 9's tar: tar: directory checksum error With GNU tar, it worked correctly. Is this a known issue, or is it irrelevant? Reinhold -- Mail address is perfectly valid! ___ 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] TAR problems under Solaris
Tim Peters wrote: [Reinhold Birkenfeld] Recently, someone on dclpy posted about an error he got when he tried to unpack the Python distribution tarball with Sparc Solaris 9's tar: tar: directory checksum error With GNU tar, it worked correctly. Is this a known issue, or is it irrelevant? It's a known issue for just about every tarball-based distribution of every project on the planet. For Python, Solaris tar woes are noted on this page: http://www.python.org/2.4.2/bugs.html Ah ok, so never mind. Reinhold -- Mail address is perfectly valid! ___ 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] Naming conventions in Py3K
Ka-Ping Yee wrote: In a fair number of cases, Python doesn't follow its own recommended naming conventions. Changing these things would break backward compatibility, so they are out of the question for Python 2.*, but it would be nice to keep these in mind for Python 3K. Constants in all caps: NONE, TRUE, FALSE, ELLIPSIS That's ugly. I bet with this change you will find modules out there which do True = TRUE at the start. In fact, I like it that the basic Python functions and most of the types are all-lowercase. It find the code to be better readable. Reinhold -- Mail address is perfectly valid! ___ 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] a quit that actually quits
[EMAIL PROTECTED] wrote: Fredrik a quit/exit command that actually quits, instead of printing a Fredrik you didn't say please! message. I like Fredrik's idea more and more. Without my Unix bifocals it wouldn't occur to me that Ctrl-D is the way to exit. Knowing Ctrl-Z is EOF on Windows, it wouldn't occur to me that I'd also have to hit Return. Without my Python shades I'd never guess to exit via raise SystemExit. While the raise command is one true way, it certainly won't occur to newbies. I have no idea how I'd exit from Pippy or from the interpreter prompt on a Nokia phone without it. In short, I think it makes a lot of sense to support a bare exit and/or quit as a completely intuitive platform-independent newbie-friendly way to exit the interpreter. +1. Reinhold -- Mail address is perfectly valid! ___ 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] a quit that actually quits
Fredrik Lundh wrote: Walter Dörwald wrote: We have sys.displayhook and sys.excepthook. Why not add a sys.inputhook? sys.inputhook gets passed each line entered and may return True if it has processed the line inself and False if normal handling of the input should be done. This allows special treatment of quit, exit, help /.../ so how would such a hook deal with the def exit(): ... pass exit case ? In the inputhook one would have to check for exit being defined at interpreter level. Reinhold -- Mail address is perfectly valid! ___ 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] a quit that actually quits
Fredrik Lundh wrote: sourceforge just went off the air, so I'm posting this patch here, in order to distract you all from Christian's deque thread. this silly little patch changes the behaviour of the interpreter so that quit and exit actually exits the interpreter. it does this by installing a custom excepthook that looks for NameErrors at the top level, in interactive mode only. What is wrong with something like this: class Quitter: ... def __repr__(self): raise SystemExit ... exit = quit = Quitter() It could optionally check for top level too, of course. Reinhold -- Mail address is perfectly valid! ___ 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] a quit that actually quits
Fredrik Lundh wrote: Reinhold Birkenfeld wrote: What is wrong with something like this: class Quitter: ... def __repr__(self): raise SystemExit ... exit = quit = Quitter() vars() # oops! You're right. class Quitter: ... def __repr__(self): ... n = sys._getframe(1).f_code.co_names ... if n == (exit,) or n == (quit,): ...raise SystemExit better? ;) Reinhold -- Mail address is perfectly valid! ___ 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] NotImplemented reaching top-level
Armin Rigo wrote: Hi Facundo, On Sat, Dec 24, 2005 at 02:31:19PM -0300, Facundo Batista wrote: d += 1.2 d NotImplemented The situation appears to be a mess. Some combinations of specific operators fail to convert NotImplemented to a TypeError, depending on old- or new-style-class-ness, although this is clearly a bug (e.g. in an example like yours but using -= instead of +=, we get the correct TypeError.) Obviously, we need to write some comprehensive tests about this. But now I just found out that the old, still-pending SF bug #847024 about A()*5 in new-style classes hasn't been given any attention; my theory is that nobody fully understands the convoluted code paths of abstract.c any more :-( Time for a rewrite? Reinhold -- Mail address is perfectly valid! ___ 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] status of development documentation
Robey Pointer wrote: On 22 Dec 2005, at 3:51, Michael Hudson wrote: Fredrik Lundh [EMAIL PROTECTED] writes: Checked the python-list archives lately? If you google c.l.python for the word documentation, you'll find recent megathreads with subjects like bitching about the documentation, opensource documentation problems and python documentation should be better among the top hits. But if you check the bug and patch trackers, you don't find many contributions. Something's definitely broken. Hmm, it's this discussion again! Let me make my point again! Writing good documentation is hard. I can only speak for my own experience, but maybe it will help. I once tried to help fix a piece of the python docs. The description of Py_UNICODE on http://docs.python.org/api/unicodeObjects.html was -- and still is -- incorrect. The current docs were released on September 28. They are not updated until the next Python release, so that's probably why your patch doesn't show up there. That may not be a good thing. Documentation fixes should go online much quicker than with every Python release, or am I mistaken? Reinhold -- Mail address is perfectly valid! ___ 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] Expose Subversion revision number to Python
Martin v. Löwis wrote: Propose first. I have the feeling that the feature will change forth and back if everybody gets to say something. I would call it sys.svnversion (because that's what it is). Perhaps it could make sense for sys.svnversion to exist only in a debug build. This way people won't use it to test for release versions. Reinhold -- Mail address is perfectly valid! ___ 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] PEP 8 updates/clarifications
Ian Bicking wrote: Guido van Rossum wrote: On 12/14/05, Barry Warsaw [EMAIL PROTECTED] wrote: On Thu, 2005-12-15 at 11:13 +1100, Dave Cole wrote: The only thing I strongly disagree with is the promotion of javaNaming to equal footing with python_naming. Actually, they're not on equal footing atm. I happen to agree with you though. It doesn't matter. Many large projects are adopting the camelCase convention, either by choice or by accident. I did a brief review of Zope 3 and Chandler, and while neither is consistent, camelCase prevails (Chandler also has a lot of CapWords method names, wihch suggests they didn't get this from Java -- maybe from C++?). Everything that touches wx seems to adopt CapWords method names -- in part (hopefully) or in whole. Wx's API comes from Windows, and the Microsoft method conventions. Bad, that. While the Windows API names once made sense when they referred to standalone functions, not methods, they now look ugly in wx or .NET. Reinhold -- Mail address is perfectly valid! ___ 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] Python 3
Hi, don't know if this is known here, but it seems we have quite a long way to go: http://kuerzer.de/python3 Reinhold wink ___ 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] a different kind of reduce...
Raymond Hettinger wrote: [Martin Blais] I'm always--literally every time-- looking for a more functional form, something that would be like this: # apply dirname() 3 times on its results, initializing with p ... = repapply(dirname, 3, p) [Greg Ewing] Maybe ** should be defined for functions so that you could do things like up3levels = dirname ** 3 Hmm, using the function's own namespace is an interesting idea. It might also be a good place to put other functionals: results = f.map(data) newf = f.partial(somearg) And we have solved the map, filter and reduce are going away! Let's all weep together problem with one strike! Reinhold -- Mail address is perfectly valid! ___ 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] Definining properties - a use case for class decorators?
Michele Simionato wrote:
As other explained, the syntax would not work for functions (and it is
not intended to).
A possible use case I had in mind is to define inlined modules to be
used as bunches
of attributes. For instance, I could define a module as
module m():
a = 1
b = 2
where 'module' would be the following function:
def module(name, args, dic):
mod = types.ModuleType(name, dic.get('__doc__'))
for k in dic: setattr(mod, k, dic[k])
return mod
Wow. This looks like an almighty tool. We can have modules, interfaces,
classes and properties all the like with this.
Guess a PEP would be nice.
Reinhold
___
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] Divorcing str and unicode (no more implicit conversions).
Martin Blais wrote:
On 10/3/05, Michael Hudson [EMAIL PROTECTED] wrote:
Martin Blais [EMAIL PROTECTED] writes:
How hard would that be to implement?
import sys
reload(sys)
sys.setdefaultencoding('undefined')
Hmmm any particular reason for the call to reload() here?
Yes. setdefaultencoding() is removed from sys by site.py. To get it
again you must reload sys.
Reinhold
--
Mail address is perfectly valid!
___
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] Autoloading? (Making Queue.Queue easier to use)
Sokolov Yura wrote: May be allow modules to define __getattr__ ? def __getattr__(thing): try: return __some_standart_way__(thing) except AttributeError: if thing==Queue: import sys from Queue import Queue setattr(sys.modules[__name__],Queue,Queue) return Queue raise I proposed something like this in the RFE tracker a while ago, but no one commented on it. Reinhold -- Mail address is perfectly valid! ___ 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] Extending tuple unpacking
Greg Ewing wrote: Guido van Rossum wrote: BTW, what should [a, b, *rest] = (1, 2, 3, 4, 5) do? Should it set rest to (3, 4, 5) or to [3, 4, 5]? Whatever type is chosen, it should be the same type, always. The rhs could be any iterable, not just a tuple or a list. Making a special case of preserving one or two types doesn't seem worth it to me. I don't think that [a, b, c] = iterable is good style right now, so I'd say that [a, b, *rest] = iterable should be disallowed or be the same as with parentheses. It's not intuitive that rest could be a list here. ? And then perhaps *rest = x should mean rest = tuple(x) Or should that be disallowed Why bother? What harm would result from the ability to write that? There certainly is a need for doing the same from the end: *rest, a, b = (1, 2, 3, 4, 5) I wouldn't mind at all if *rest were only allowed at the end. There's a pragmatic reason for that if nothing else: the rhs can be any iterable, and there's no easy way of getting all but the last n items from a general iterable. Where does it stop? For me, it stops with *rest only allowed at the end, and always yielding a predictable type (which could be either tuple or list, I don't care). +1. Tuple is more consistent. BTW, and quite unrelated, I've always felt uncomfortable that you have to write f(a, b, foo=1, bar=2, *args, **kwds) I've always wanted to write that as f(a, b, *args, foo=1, bar=2, **kwds) Yes, I'd like that too, with the additional meaning that foo and bar can only be specified by keyword, not by position. That would be a logical consequence. But one should also be able to give default values for positional parameters. So: foo(a, b, c=1, *args, d=2, e=5, **kwargs) ^ positionalonly with kw or with kw Reinhold -- Mail address is perfectly valid! ___ 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] Tests and unicode
Martin v. Löwis wrote: Reinhold Birkenfeld wrote: One problem is that no Unicode escapes can be used since compiling the file raises ValueErrors for them. Such strings would have to be produced using unichr(). You mean, in Unicode literals? There are various approaches, depending on context: - you could encode the literals as UTF-8, and decode it when the module/test case is imported. See test_support.TESTFN_UNICODE for an example. - you could use unichr - you could use eval, see test_re for an example Okay. I can fix this, but several library modules must be fixed too (mostly simple fixes), e.g. pickletools, gettext, doctest or encodings. Is this the right way? Or is disabling Unicode not supported any more? There are certainly tests that cannot be executed when Unicode is not available. It would be good if such tests get skipped instead of being failing, and it would be good if all tests that do not require Unicode support run even when Unicode support is missing. That's my approach too. Whether it is supported is a tricky question: your message indicates that, right now, it is *not* supported (or else you wouldn't have noticed a problem). Well, the core builds without Unicode, and any code that doesn't use unicode should run fine too. But the tests fail at the moment. Whether we think it should be supported depends on who we is, as with all these minor features: some think it is a waste of time, some think it should be supported if reasonably possible, and some think this a conditio sine qua non. It certainly isn't a release-critical feature. Correct. I'll see if I have the time. Reinhold -- Mail address is perfectly valid! ___ 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] Tests and unicode
Hi, I looked whether I could make the test suite pass again when compiled with --disable-unicode. One problem is that no Unicode escapes can be used since compiling the file raises ValueErrors for them. Such strings would have to be produced using unichr(). Is this the right way? Or is disabling Unicode not supported any more? Reinhold -- Mail address is perfectly valid! ___ 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] inplace operators and __setitem__
Hi, a general question. Consider: class A(list): def __setitem__(self, index, item): # do something with index and item return list.__setitem__(self, index, item) lst = A([1,set()]) lst[0] |= 1 lst[1] |= set([1]) Do we want lst.__setitem__ to be called in the second inplace assignment? A case where this matters is here: http://python.org/sf/1306777 Reinhold -- Mail address is perfectly valid! ___ 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] Adding a conditional expression in Py3.0
Sokolov Yura wrote: Sorry for looking in every hole. Just a suggestion. A= condition and first or second problem is in case when first in (None,0,[],). May be invent new operator 'take'. take - returns right operator when left evals to True and stops computing condidtional expression. Then we could write: A = condition take first or second. A = x==y take w or s A = z is not None and q!=12 take [] or allowable(z,q) take [(z,q)] or Impossible Ok, it might looks ugly. But may be not. One of the advantages of (if x then y else z) is that it doesn't require the introduction of a new keyword (I think the then could be special- cased like as in the import statement). Reinhold -- Mail address is perfectly valid! ___ 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] IMPORTANT: release24-maint branch is FROZEN from 2005-09-21 00:00 UTC for 2.4.2
Anthony Baxter wrote: Starting in about 11 hours time, the release24-maint branch is FROZEN for the 2.4.2c1 release. The freeze will last for around a day, and then we're in a state of mostly-frozen for another week, until 2.4.2 (final). During that week, please don't check things into the branch unless you check with me first. Let's make this a nice painless release. I'll send another message once 2.4.2 is done. Do you think the patch at https://sourceforge.net/tracker/?func=detailatid=305470aid=1298449group_id=5470 could go in before 2.4.2 final? It's a rather major issue within cStringIO.writelines(). Reinhold -- Mail address is perfectly valid! ___ 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] Adding a conditional expression in Py3.0
Jason Orendorff wrote: Honestly, I think I would prefer this syntax. Examples from real code, before and after: lines = [line for line in pr.block.body if line.logical_line.strip() != ''] lines = [for line in pr.block.body: if line.logical_line.strip() != '': line] row.values = \ [line[col.start:col.end].strip() for col in columns] row.values = \ [for col in columns: line[col.start:col.end].rstrip()] return [p for p in self.listdir(pattern) if p.isdir()] return [for p in self.listdir(pattern): if p.isdir(): p] -1. Too much similarity with the for/if statement. People would say why can we put a for statement in brackets but not a try statement. Reinhold -- Mail address is perfectly valid! ___ 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] and and or operators in Py3.0
Raymond Hettinger wrote: I propose that in Py3.0, the and and or operators be simplified to always return a Boolean value instead of returning the last evaluated argument. No, please not. It's useful sometimes and doesn't hurt most times. 1) The construct can be error-prone. When an error occurs it can be invisible to the person who wrote it. I got bitten in published code that had survived testing and code review: def real(self): 'Return a vector with the real part of each input element' # do not convert integer inputs to floats return self.map(lambda z: type(z)==types.ComplexType and z.real or z) I'm surprised you wrote that in the first place. The and/or conditional is one of the few occurences where one will carefully look for false values in the and part. The code fails silently when z is (0+4i). It took a good while to trace down a user reported error (when Matlab results disagreed with my matrix module results) and determine that the real() method contained an error. Even when traced down, I found it hard to see the error in the code. Now that I know what to look for, it has not happened again, but I do always have to stare hard at any and/or group to mentally verify each case. [...] P.S. Simplifying and and or may create a need to introduce a conditional operator but that is a discussion for another day. Exactly. A conditional was turned down some time ago, for good reasons. Reinhold -- Mail address is perfectly valid! ___ 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] Adding a conditional expression in Py3.0
Guido van Rossum wrote: Given this realization, I'm now -1 on Raymond's idea, and +1 on adding a conditional expression. I believe (y if x else z) was my favorite last time, wasn't it? I've changed the subject accordingly. As the PEP states, I'm not sure if changing the customary order of arguments in conditional expressions is good. Also, I assume the thing will be short-circuiting, and it's confusing to grasp that y in (y if x else z) will possibly never be evaluated. Reinhold -- Mail address is perfectly valid! ___ 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] possible memory leak on windows (valgrind report)
Neal Norwitz wrote: I ran 2.4.x through valgrind and found two small problems on Linux that have been fixed. There may be some other issues which could benefit from more eyes (small, probably one time memory leaks). The entire run is here: http://python.org/valgrind-2.4.2.out (I need to write a lot more suppression rules for gentoo.) I think I see a memory leak in win32_startfile. Since I don't run windows I can't test it. filepath should be allocated with the et flag to PyArgs_ParseTuple(), but it wasn't freed without this patch. Does this make sense? See the attached patch. Applied the patch, this was my fault. Reinhold -- Mail address is perfectly valid! ___ 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] python/dist/src/Lib urllib.py, 1.165.2.1, 1.165.2.2
Raymond Hettinger wrote:
[Reinhold Birkenfeld]
This last patch includes a new exception, are you sure that this can
be
safely backported?
Not too worried about it. Better to have the exception reported than
the silent failure that confused the heck out of everyone who tried to
figure-out what caused the OP's problem.
If so, the documentation changes must be backported, too.
Maybe. My thought is the new message is akin to an improved error
message. However, adding it to the Py2.4 docs suggests that you could
catch and handle the exception, but that cannot be done portably across
Py2.4 versions. If you really feel the need, go ahead and add to the
docs with \versionadded{2.4.2}. My preference is to leave it be.
Makes sense. It'll be best to leave it be.
Reinhold
--
Mail address is perfectly valid!
___
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] speeding up list append calls
Martin v. Löwis wrote: Neal Norwitz wrote: This code doesn't really work in general. It assumes that any append function call is a list method, which is obviously invalid. But if a variable is known to be a list (ie, local and assigned as list (BUILD_LIST) or a list comprehension), could we do something like this as a peephole optimization? Alternatively, couldn't LIST_APPEND check that this really is a list, and, if it isn't, fall back to PyObject_CallMethod? Are there any other optimizations which solely act on the name of a method? This seems a step too far. Reinhold -- Mail address is perfectly valid! ___ 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] Term unification
Hi, looking at bug #1283289, I saw that the term keyword parameter is used in Python/getargs.c, mixed with keyword argument. Grepping through the source, keyword parameter had 43 matches, while keyword argument had 430. Should the parameter form be extinguished? Reinhold (And BTW, should bug #1283289 be fixed as the poster suggests?) -- Mail address is perfectly valid! ___ 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] Term unification
Ah, ok. Then I guess everything's fine. It was just the /* make sure there are no duplicate values for an argument; its not clear when to use the term keyword argument vs. keyword parameter in messages */ that disturbed me. Reinhold Guido van Rossum wrote: Correct usage is argument for the call site but parameter for the function/method definition. So you can't just count occurrences. On 9/14/05, Reinhold Birkenfeld [EMAIL PROTECTED] wrote: Hi, looking at bug #1283289, I saw that the term keyword parameter is used in Python/getargs.c, mixed with keyword argument. Grepping through the source, keyword parameter had 43 matches, while keyword argument had 430. Should the parameter form be extinguished? Reinhold (And BTW, should bug #1283289 be fixed as the poster suggests?) -- Mail address is perfectly valid! ___ 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] str.dedent
Hi, some time ago, I proposed a string method dedent (which currently is in the textwrap module). The RFE is at http://python.org/sf/1237680. Any opinions? If I don't get positive comments, I'll reject it. Reinhold -- Mail address is perfectly valid! ___ 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] str.dedent
Okay. I consider it rejected. Reinhold Guido van Rossum wrote: From the sound of it, it's probably not worth endowing every string object with this method and hardcoding its implementation forever in C code. There are so many corner cases and variations on the functionality of dedenting a block that it's better to keep it as Python source code. On 9/14/05, Reinhold Birkenfeld [EMAIL PROTECTED] wrote: Hi, some time ago, I proposed a string method dedent (which currently is in the textwrap module). The RFE is at http://python.org/sf/1237680. Any opinions? If I don't get positive comments, I'll reject it. Reinhold -- Mail address is perfectly valid! ___ 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] python/dist/src/Lib urllib.py, 1.165.2.1, 1.165.2.2
[EMAIL PROTECTED] wrote: Update of /cvsroot/python/python/dist/src/Lib In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv31892 Modified Files: Tag: release24-maint urllib.py Log Message: Sync-up with patches to the head. Includes SF 1016880: urllib.urlretrieve silently truncates downloads and the performance fix-ups. This last patch includes a new exception, are you sure that this can be safely backported? If so, the documentation changes must be backported, too. Reinhold -- Mail address is perfectly valid! ___ 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] Tools directory (Was RE: Replacement for print in Python 3.0)
Brett Cannon wrote: On 9/8/05, Tony Meyer [EMAIL PROTECTED] wrote: [finding Tools/i18n/pygettext.py] You're right, I think Tools is probably a bad place for anything. If it's not part of the stdlib, I'll likely never find it. Agreed. Maybe with the introduction of -m in Python 2.4, some of the Tools/ scripts could be put in __main__ sections of appropriate modules? So that python -m gettext would be equivilant to python Tools/i18n/pygettext.py? Questionable. Most scripts don't correspond to a single library module. (However, pyggettext.py is 22KB, which is a big addition to the module; not everything in Tools/Scripts might be used enough for this, or have an appopriate module to be put in either). Are there other ideas about how Tools/ could be improved? Either moving things, or making it more likely that people will look there for scripts? I assume that the Windows installer includes the Tools/ directory. If it doesn't that is one problem. =) Otherwise it is mostly a lack of advertisement and them not being installed by ``make install``. If you just download the soure and install you will never know the directory even exists. It needs to be made obvious to people that it is even there. +1. Most non-Windows users with distribution-supplied Pythons will never get the Tools directory on their installs though there is a number of really useful scripts there. Question is, if ``make install`` should install it, where? Has the time come for /usr/share/python? Or /usr/lib/pythonX.Y/Tools (without __init__.py)? Probably the only way is to document the directory. I think so, too. The tools are worth a top-level documentation entry. Reinhold -- Mail address is perfectly valid! ___ 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] Python 3 design principles
Greg Ewing wrote: Charles Cazabon wrote: Perhaps py3k could have a py2compat module. Importing it could have the effect of (for instance) putting compile, id, and intern into the global namespace, making print an alias for writeln, There's no way importing a module could add something that works like the old print statement, unless some serious magic is going on... You'd have to enclose print arguments in parentheses. Of course, the trailing comma form would be lost. Reinhold -- Mail address is perfectly valid! ___ 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] Replacement for print in Python 3.0
Guido van Rossum wrote: [Charles Cazabon] Perhaps py3k could have a py2compat module. Importing it could have the effect of (for instance) putting compile, id, and intern into the global namespace, making print an alias for writeln, [Greg Ewing] There's no way importing a module could add something that works like the old print statement, unless some serious magic is going on... [Reinhold Birkenfeld] You'd have to enclose print arguments in parentheses. Of course, the trailing comma form would be lost. And good riddance! The print statement harks back to ABC and even (unvisual) Basic. Out with it! Here I have to agree with Barry. print is very handy, and print is, too. I'd rather see exec and assert becoming a function. A transitional strategy could be to start designing the new API and introduce it in Python 2.x. Here's my strawman: (1) Add two new methods the the stream (file) API and extend write(): stream.write(a1, a2, ...) -- equivalent to map(stream.write, map(str, [a1, a2, ...])) stream.writeln(a1, a2, ...) -- equivalent to stream.write(a1, a2, ..., \n) stream.writef(fmt, a1, a2, ...) -- equivalent to stream.write(fmt % (a1, a2, ...)) Do we really need writef()? It seems to be not much better than its %-formatting equivalent. (2) Add builtin functions write(), writeln(), writef() that call the corresponding method on sys.stdout. (Note: these should not just be the bound methods; assignment to sys.stdout should immediately affect those, just like for print. There's an important use case for this.) If write* is introduced, this is absolutely necessary. Reinhold -- Mail address is perfectly valid! ___ 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] Replacement for print in Python 3.0
Raymond Hettinger wrote: Do we really need writef()? It seems to be not much better than its %- formatting equivalent. Actually, formatting needs to become a function. The overloading of the arithmetic mod operator has proven to be unfortunate (if only because of precedence issues). But then, a format() function would be necessary (equivalent to sprintf) Also, the format coding scheme itself needs to be revisited. There is no shortage of people who have taken issue with the trailing s in %(myvar)s. That's a nuisance, right. Reinhold -- Mail address is perfectly valid! ___ 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] Proof of the pudding: str.partition()
Bill Janssen wrote:
(*) Regular Expressions
This can be orthogonally added to the 're' module, and definitely should
not be part of the string method.
Sounds right to me, and it *should* be orthogonally added to the 're'
module coincidentally simultaneously with the change to the string
object :-).
I have to say, it would be nice if
foo bar.partition(re.compile('\s'))
would work. That is, if the argument is an re pattern object instead
of a string, it would be nice if it were understood appropriately,
just for symmetry's sake. But it's hardly necessary.
And it's horrible, for none of the other string methods accept a RE.
In Python, RE functionality is in the re module and nowhere else, and this
is a Good Thing. There are languages which give REs too much weight by
philosophy
(hint, hint), but Python isn't one of them. Interestingly, Python programmers
suffer less from the help me, my RE doesn't work problem.
Reinhold
--
Mail address is perfectly valid!
___
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] Remove str.find in 3.0?
Bill Janssen wrote: There are basically two ways for a system, such as a Python function, to indicate 'I cannot give a normal response. One (1a) is to give an inband signal that is like a normal response except that it is not (str.find returing -1). A variation (1b) is to give an inband response that is more obviously not a real response (many None returns). The other (2) is to not respond (never return normally) but to give an out-of-band signal of some sort (str.index raising ValueError). Python as distributed usually chooses 1b or 2. I believe str.find and .rfind are unique in the choice of 1a. Doubt it. The problem with returning None is that it tests as False, but so does 0, which is a valid string index position. Heh. You know what the Perl6 folks would suggest in this case? return 0 but true; # literally! Might add a boolean str.contains() to cover this test case. There's already __contains__. Reinhold -- Mail address is perfectly valid! ___ 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] Remove str.find in 3.0?
Raymond Hettinger wrote: [Martin] For another example, file.read() returns an empty string at EOF. When my turn comes for making 3.0 proposals, I'm going to recommend nixing the empty string at EOF API. That is a carry-over from C that made some sense before there were iterators. Now, we have the option of introducing much cleaner iterator versions of these methods that use compact, fast, and readable for-loops instead of multi-statement while-loop boilerplate. I think for char in iter(lambda: f.read(1), ''): pass is not bad, too. Reinhold -- Mail address is perfectly valid! ___ 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] test_bz2 on Python 2.4.1
A.B., Khalid wrote: #--- Python 2.4.1 from CVS -# [test_bz2] RuntimeError: wrong sequence of bz2 library commands used I don't understand this. The sources for the bz2 modules are exactly equal in both branches. I know. Even the tests are equal. I didn't say that these files are to blame, I just said that the test is failing in Python 2.4.1 on Windows. cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot/python login cvs -z7 -d :pserver:[EMAIL PROTECTED]:/cvsroot/python update -dP -r release24-maint python And it is, more or less, the same way I check out other branches. No problem here, just eliminating possibilities. Could anyone else on Windows please try the test_bz2, too? Reinhold -- Mail address is perfectly valid! ___ 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] operator.c for release24-maint and test_bz2 on Python 2.4.1
A.B., Khalid wrote:
Hello there,
The release24-maint check-ins for today contained this typo:
===
RCS file: /cvsroot/python/python/dist/src/Modules/operator.c,v
retrieving revision 2.29
retrieving revision 2.29.4.1
diff -u -d -r2.29 -r2.29.4.1
--- operator.c 4 Dec 2003 22:17:49 - 2.29
+++ operator.c 26 Aug 2005 06:43:16 - 2.29.4.1
@@ -267,6 +267,9 @@
itemgetterobject *ig;
PyObject *item;
+ if (!_PyArg_NoKeywords(itemgetter(), kdws)) - kdws should be kwds
+ return NULL;
+
if (!PyArg_UnpackTuple(args, itemgetter, 1, 1, item))
return NULL;
Thank you, that is corrected now.
However, and in Python 2.4.1 the following happens when the test is not
invoked from an interpreted session:
$ python ../Lib/test/test_bz2.py
testBug1191043 (__main__.BZ2FileTest) ... ERROR
ERROR
[...]
==
ERROR: testBug1191043 (__main__.BZ2FileTest)
--
Traceback (most recent call last):
File ../Lib/test/test_bz2.py, line 255, in testBug1191043
lines = bz2f.readlines()
RuntimeError: wrong sequence of bz2 library commands used
==
ERROR: testBug1191043 (__main__.BZ2FileTest)
--
Traceback (most recent call last):
File ../Lib/test/test_bz2.py, line 47, in tearDown
os.unlink(self.filename)
OSError: [Errno 13] Permission denied: '@test'
--
Ran 33 tests in 6.210s
FAILED (errors=2)
Traceback (most recent call last):
File ../Lib/test/test_bz2.py, line 357, in ?
test_main()
File ../Lib/test/test_bz2.py, line 353, in test_main
FuncTest
File G:\PROJS\PY24\PYTHON\DIST\SRC\lib\test\test_support.py, line 290, in
run_unittest
run_suite(suite, testclass)
File G:\PROJS\PY24\PYTHON\DIST\SRC\lib\test\test_support.py, line 274, in
run_suite
raise TestFailed(msg)
test.test_support.TestFailed: errors occurred; run in verbose mode for
details
Are you sure that you are calling the newly-built python.exe? It is strange that
the test should pass in interactive mode when it doesn't in normal mode.
For a confirmation, can you execute this piece of code both interactively and
from a file:
data =
'BZh91AYSY\xd9b\x89]\x00\x00\x00\x03\x80\x04\x00\x02\x00\x0c\x00
\x00!\x9ah3M\x13]\xc9\x14\xe1BCe\x8a%t'
f = open('test.bz2', wb)
f.write(data)
f.close()
bz2f = BZ2File('test.bz2')
lines = bz2f.readlines()
bz2f.close()
assert lines == ['Test']
bz2f = BZ2File('test.bz2)
xlines = list(bz2f.xreadlines())
bz2f.close()
assert lines == ['Test']
os.unlink('test.bz2')
Reinhold
--
Mail address is perfectly valid!
___
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] Bare except clauses in PEP 348
Raymond Hettinger wrote: Deprecation means your code will still work I hope every book that documents except: also adds but don't use this except under very special circumstances. I think you're overreacting (again), Raymond. 3.0 will be much more successful if we can introduce many of its features into 2.x. Many of those features are in fact improvements of the language even if they break old code. We're trying to balance between breaking old code and introducing new features; deprecation is the accepted way to do this. Fredrik, please speak up. Someone should represent the users here. I'm reached my limit on how much time I can devote to thinking out the implications of these proposals. Someone else needs to overreact. Perhaps I may add a pragmatic POV (yes, I know that pragmatic is usually attributed to another language ;-). If except: issues a deprecation warning in 2.5, many people will come and say woohoo, Python breaks backwards compatibility and I knew it, Python is unreliable, my script issues 1,233 warnings now and such. You can see this effect looking at the discussion that broke out when Guido announced that map, filter and reduce would vanish (as builtins) in 3.0. People spoke up and said, if that's going to be the plan, I'll stop using Python etc. That said, I think that unless it is a new feature (like with statements) transitions to Python 3.0 shouldn't be enforced in the 2.x series. With 3.0, everyone expects a clear cut and a compatibility breach. Reinhold -- Mail address is perfectly valid! ___ 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] Docs/Pointer to Tools/scripts?
Hi, after adding Oleg Broytmann's findnocoding.py to Tools/scripts, I wonder whether the Tools directory is documented at all. There are many useful scripts there which many people will not find if they are not listed anywhere in the docs. Just a thought. Reinhold -- Mail address is perfectly valid! ___ 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] python/dist/src/Doc/tut tut.tex,1.276,1.277
[EMAIL PROTECTED] wrote:
I'm not a native speaker, but...
@@ -114,7 +114,7 @@
programs, or to test functions during bottom-up program development.
It is also a handy desk calculator.
-Python allows writing very compact and readable programs. Programs
+Python enables programs to written compactly and readably. Programs
written in Python are typically much shorter than equivalent C or
\Cpp{} programs, for several reasons:
\begin{itemize}
...shouldn't it be programs to be written compactly?
@@ -1753,8 +1753,8 @@
\begin{methoddesc}[list]{pop}{\optional{i}}
Remove the item at the given position in the list, and return it. If
-no index is specified, \code{a.pop()} returns the last item in the
-list. The item is also removed from the list. (The square brackets
+no index is specified, \code{a.pop()} removes and returns the last item
+in the list. The item is also removed from the list. (The square brackets
around the \var{i} in the method signature denote that the parameter
is optional, not that you should type square brackets at that
position. You will see this notation frequently in the
Thats twice the same the same (removal from list).
@@ -1985,7 +1987,9 @@
\section{The \keyword{del} statement \label{del}}
There is a way to remove an item from a list given its index instead
-of its value: the \keyword{del} statement. This can also be used to
+of its value: the \keyword{del} statement. Unlike the \method{pop()})
+method which returns a value, the \keyword{del} keyword is a statement
+and can also be used to
remove slices from a list (which we did earlier by assignment of an
empty list to the slice). For example:
The del keyword is a statement?
@@ -2133,8 +2137,8 @@
keys. Tuples can be used as keys if they contain only strings,
numbers, or tuples; if a tuple contains any mutable object either
directly or indirectly, it cannot be used as a key. You can't use
-lists as keys, since lists can be modified in place using their
-\method{append()} and \method{extend()} methods, as well as slice and
+lists as keys, since lists can be modified in place using methods like
+\method{append()} and \method{extend()} or modified with slice and
indexed assignments.
Is the second modified necessary?
@@ -5595,8 +5603,8 @@
to round it again can't make it better: it was already as good as it
gets.
-Another consequence is that since 0.1 is not exactly 1/10, adding 0.1
-to itself 10 times may not yield exactly 1.0, either:
+Another consequence is that since 0.1 is not exactly 1/10,
+summing ten values of 0.1 may not yield exactly 1.0, either:
\begin{verbatim}
sum = 0.0
Is it clear from context that the 0.1 is not exactly 1/10 refers to
floating point only?
@@ -5637,7 +5645,7 @@
you can perform an exact analysis of cases like this yourself. Basic
familiarity with binary floating-point representation is assumed.
-\dfn{Representation error} refers to that some (most, actually)
+\dfn{Representation error} refers to fact that some (most, actually)
decimal fractions cannot be represented exactly as binary (base 2)
fractions. This is the chief reason why Python (or Perl, C, \Cpp,
Java, Fortran, and many others) often won't display the exact decimal
...refers to the fact...?
Reinhold
--
Mail address is perfectly valid!
___
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] Generalised String Coercion
Guido van Rossum wrote: The main problem for a smooth Unicode transition remains I/O, in my opinion; I'd like to see a PEP describing a way to attach an encoding to text files, and a way to decide on a default encoding for stdin, stdout, stderr. FWIW, I've already drafted a patch for the former. It lets you write to file.encoding and honors this when writing Unicode strings to it. http://www.python.org/sf/1214889 Reinhold -- Mail address is perfectly valid! ___ 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] PEP 348: Exception Reorganization for Python 3.0
Raymond Hettinger wrote: 2. There is a lesson to be taken from a story in the ACM risks forum where a massive phone outage was traced to a single line of C code that ran a break to get out of a nested if-statement. The interesting part is that this was known to be mission critical code yet the error survived multiple, independent code reviews. The problem was that the code created an optical illusion. We risk the same thing when an except Exception doesn't catch ControlFlowExceptions. The recovery/logging handler will look like it ought to catch everything, but it won't. That is a disaster for fault-tolerant coding and for keeping your sales demo from exploding in front of customers. I think that ControlFlowException should inherit from Exception, because it is an exception. As Raymond says, it's hard to spot this when in a hurry. But looking at the current PEP 348, why not rename BaseException to Exception and Exception to Error? That way, you could say except Error: instead of most of today's bare except: and it's clear that StopIteration or GeneratorExit won't be caught because they are not errors. Reinhold -- Mail address is perfectly valid! ___ 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] builtin filter function
Ruslan Spivak wrote: Hello. I was reading source code for bltinmodule.c and found probably erroneus stuff in filter function. I'm newbie to python inners and don't know if attached code is worth for a patch submission. I would appreciate if someone could take a look at it and if it's ok then i'll make submission, otherwise just drop it. TIA This is indeed a bug in the function, and could have caused memory leaks because of not releasing the preallocated tuple. Since this is evident, I fixed it by now (Python/bltinmodule.c r2.318.2.1 and r2.322), but in the future you should always post patches to SourceForge to avoid crowding python-dev. But above all, thank you for spotting this issue and helping to make Python more bug-free! Reinhold -- Mail address is perfectly valid! ___ 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] python/dist/src/Doc/lib emailutil.tex,1.11,1.12
[EMAIL PROTECTED] wrote:
Update of /cvsroot/python/python/dist/src/Doc/lib
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv20654
Modified Files:
emailutil.tex
Log Message:
Note that usegmt is new in 2.4. Closes #1239681.
Index: emailutil.tex
===
RCS file: /cvsroot/python/python/dist/src/Doc/lib/emailutil.tex,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -d -r1.11 -r1.12
--- emailutil.tex 1 Nov 2004 03:59:24 - 1.11
+++ emailutil.tex 17 Jul 2005 11:47:46 - 1.12
@@ -103,7 +103,8 @@
Optional \var{usegmt} is a flag that when \code{True}, outputs a
date string with the timezone as an ascii string \code{GMT}, rather
than a numeric \code{-}. This is needed for some protocols (such
-as HTTP). This only applies when \var{localtime} is \code{False}
+as HTTP). This only applies when \var{localtime} is \code{False}.
+New in Python 2.4.
\end{funcdesc}
\begin{funcdesc}{make_msgid}{\optional{idstring}}
Wouldn't that be \versionadded{2.4}?
Reinhold
--
Mail address is perfectly valid!
___
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] Some RFE for review
Reinhold Birkenfeld wrote: Hi, while bugs and patches are sometimes tricky to close, RFE can be very easy to decide whether to implement in the first place. So what about working a bit on this front? Here are several RFE reviewed, perhaps some can be closed (should is always from submitter's point of view): Aren't there opinions to the RFE other than the path module one? Reinhold -- Mail address is perfectly valid! ___ 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] SF patch #1214889 - file.encoding support
Hi, would anyone care to comment about this patch of mine -- https://sourceforge.net/tracker/?func=detailatid=305470aid=1214889group_id=5470 It makes file.encoding read-write and lets the write() and writelines() methods obey it. Reinhold -- Mail address is perfectly valid! ___ 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] SF patch #1214889 - file.encoding support
M.-A. Lemburg wrote: Reinhold Birkenfeld wrote: Hi, would anyone care to comment about this patch of mine -- https://sourceforge.net/tracker/?func=detailatid=305470aid=1214889group_id=5470 It makes file.encoding read-write and lets the write() and writelines() methods obey it. Done. Please see SF. PS: Please don't use -nospam or the like email addresses when posting to this list. Thanks. Why? This address is perfectly valid (as is written in my signature), and almost completely spam-free. Reinhold -- Mail address is perfectly valid! ___ 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] Python on PyPI
Hi, to whom it may concern: the Python package on PyPI is at version 2.3.2. Reinhold -- Mail address is perfectly valid! ___ 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] Triple-quoted strings and indentation
Guido van Rossum wrote: On 7/5/05, Andrew Durdin [EMAIL PROTECTED] wrote: I have written a patch that changes the way triple-quoted strings are scanned so that leading whitespace is ignored in much the same way that pep 257 handles it for docstrings. Largely this was for a learning experience in hacking the parser, but it would be very nice IMO if something of this sort could be implemented in a future version of Python. I don't think so. It smells too much of DWIM, which is very unpythonic. EIBTI. Another idea, which is much more conservative: textwrap.dedent is highly under- rated and hidden. Why not make it builtin or a string method? Reinhold -- Mail address is perfectly valid! ___ 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] Possible context managers in stdlib
Hi, I compiled a list of some possible new context managers that could be added to the stdlib. Introducing a new feature should IMO also show usage of it in the distribution itself. That wasn't done with decorators (a decorators module is compiled at the moment, if I'm right), but with context managers, there's certainly room to add some. Of course, my list is excessive, it's only some ideas I got by flying over the stdlib docs. * builtins: with open/file * sys: with sys.redirected_std[in|out|err] with sys.trace with sys.excepthook * warnings: with warnings.filter * pprint: with pprint.printer (used for print) * codecs: with codecs.open with codecs.EncodedFile * decimal: with decimal.Context * os: with os.current_directory with os.modified_env with os.umask/uid/gid etc. with os.popen with os.tmpfile * subprocess: with subprocess.Popen * mutex: with mutexobj * curses: with curses.wrapper * tempfile: with tempfile.[Named]TemporaryFile etc. * locale: with locale.differentlocale * logging: with logging.ignored with logging.Logger * signal: with signal.handler * socket: with socket.socket * threading: with threading.Lock with threading.Condition with threading.Event * mmap: with mmap.mmap * bz2/zipfile/tarfile: with ...open * dl: with dl.open * tty: with tty.raw with tty.cbreak * cgitb: with cgitb.enabled * urllib/urllib2: with urllib.urlopen etc. * httplib: with httplib.HTTPConnection * ftplib: with ftplib.FTP * poplib: with poplib.POP3 * imaplib: with imaplib.IMAP4 * nttplib: with nntplib.NNTP * smtplib: with smtplib.SMTP * telnetlib: with telnetlib.Telnet * xmlrpclib: with xmlrpclib.ServerProxy Reinhold -- Mail address is perfectly valid! ___ 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] Possible context managers in stdlib
Phillip J. Eby wrote: At 10:24 PM 7/8/2005 +0200, Reinhold Birkenfeld wrote: with sys.trace Note that it's currently not possible to inspect the trace/profile hooks from Python code, only from C, so that might be, um, interesting to implement. That was beyond my short view... if it can't be implemented, it won't. * pprint: with pprint.printer (used for print) Interesting; I'm not sure if I like it. * os: with os.current_directory What does this do? Oh, I get it. The name's not very obvious. I would've expected a more imperative name, something like 'with os.setcwd()' or 'with os.pushdir()'. I didn't think about the names too long. ;) with os.modified_env with os.umask/uid/gid etc. Yeah, again I would expect more verbish names, but these are at least easier to grasp than current_directory was. Names can be found, of course. * curses: with curses.wrapper with logging.Logger * tty: with tty.raw with tty.cbreak * cgitb: with cgitb.enabled What do these do? curses: curses.wrapper currently is a function which restores sane terminal settings after the curses program bails out. It could be a context manager too. Similar is tty.raw and tty.cbreak. These switch terminal modes, and in case of an uncaught exception the terminal will stay in this state. Context managers would restore the sane mode on exit. logging.Logger: hm, I didn't think about that properly. cgitb: enables or disables the full traceback view (Ok, it wouldn't be so useful). Reinhold -- Mail address is perfectly valid! ___ 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] Possible context managers in stdlib
Raymond Hettinger wrote: I compiled a list of some possible new context managers that could be added to the stdlib. Introducing a new feature should IMO also show usage of it in the distribution itself. That wasn't done with decorators (a decorators module is compiled at the moment, if I'm right), but with context managers, there's certainly room to add some. Of course, my list is excessive, it's only some ideas I got by flying over the stdlib docs. The PEP contains plenty of examples. If you're really feeling the need, add something to the demo directory. For the most part, the applications need to work themselves out over time through wikis, individual patch submissions, ASPN recipes, third-party apps, etc. The natural evolution of best practices tends to get thwarted by prematurely using the standard library to cast a particular solution in stone. This doesn't preclude individual patches such as a context manager for decimal.Context objects. Each proposal should be considered on its own merits rather than as a part of an overall effort to ram a bunch of these into the standard library.Over time, plenty of these will sprout-up. As with decorators? Sure, plenty have sprouted up, but delivering them one release after the feature itself (if the decorators module makes it into 2.5) seems a little bit like lagging behind -- especially when good and useful examples exist. Of course, not all of these in my list are good ideas to implement. Reinhold -- Mail address is perfectly valid! ___ 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] 'With' context documentation draft (was Re: Terminology for PEP 343
Paul Moore wrote: On 7/6/05, Michael Chermside [EMAIL PROTECTED] wrote: Paul Moore writes: I also like the fact that it offers a neat 1-word name for the generator decorator, @context. Well, ok... does anyone *else* agree? I too saw this and thought neat! a simple one-word name!. But then I started worrying that it's not defining the *context*, but rather the *context manager*. While context manager is a term I could easily imagine associating only with 'with' statements, context is too general a term... even after Python supports 'with' statements I will continue to use context to mean lots of different things (eg: decimal.context). Actually, you're starting to persuade me... Although I generally prefer decorator names which are single words. Along with the at-sign, underscores make the whole thing look a little too punctuation-heavy for me (and don't suggest camel case, please!). Anything against @contextmanager in analogy to @staticmethod ? Reinhold -- Mail address is perfectly valid! ___ 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] reducing self.x=x; self.y=y; self.z=z boilerplate code
Nick Coghlan wrote:
[...]
If the right hand side of 'as' permitted the same forms as are going
to be permitted for the 'as' clause in 'with' statements, then Ralf's
situation could be handled via:
def __init__(self as s, x as s.x, y as s.y, z as s.z):
pass
Essentially, it allows arguments to be given two names - a public name
(before the 'as', used for keyword arguments), and a private name
(after the 'as', not used for keyword arguments, allows easy shorthand
aliasing of self, unpacking of tuple arguments, and easy assignment of
instance variables).
There once was a suggestion like this on c.l.py, expanding this to other
statements, like:
if re.match('a.*b', text) as m:
# do something
What has become of this? It seems to be a wanted feature, and while I concur
that classic 'C-style' assignment-as-expression is undesirable (because of
the =/== bug-source), this would be a way, wouldn't it?
Reinhold
--
Mail address is perfectly valid!
___
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] Adding the 'path' module (was Re: Some RFEforreview)
Michael Hoffman wrote: On Wed, 29 Jun 2005, Tony Meyer wrote: Maybe this has already been answered somewhere (although I don't recall seeing it, and it's not in the sourceforge tracker) but has anyone asked Jason Orendorff what his opinion about this (including the module in the stdlib) is? I e-mailed Jason earlier this week before submitting the RFE. He said that I'd like to see path (or something like it) in the standard library. He also said he didn't have time to write a PEP at the moment, but that I should feel free to do so. As for me, I'm happy for Reinhold to do it if he wants. wink Well, as it is your RFE... ;) I'm not eager to write a PEP right now, though I think I said so in a post. I just wanted to start a discussion here, so that you can write a better PEP wink. Reinhold -- Mail address is perfectly valid! ___ 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] Adding the 'path' module (was Re: Some RFE for review)
Michael Hoffman wrote: On Sun, 26 Jun 2005, Phillip J. Eby wrote: At 08:19 PM 6/26/2005 +0100, Michael Hoffman wrote: On Sun, 26 Jun 2005, Phillip J. Eby wrote: * drop getcwd(); it makes no sense on a path instance Personally I use path.getcwd() as a class method all the time. It makes as much sense as fromkeys() does on a dict instance, which is technically possible but non-sensical. It's also duplication with os.path; I'm -1 on creating a new staticmethod for it. os.getcwd() returns a string, but path.getcwd() returns a new path object. Almost everything in path is a duplication of os.path--the difference is that the path methods start and end with path objects. +1. Reinhold -- Mail address is perfectly valid! ___ 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] Adding the 'path' module (was Re: Some RFE for review)
Phillip J. Eby wrote: At 08:20 AM 6/27/2005 +0100, Michael Hoffman wrote: os.getcwd() returns a string, but path.getcwd() returns a new path object. In that case, I'd expect it to be 'path.fromcwd()' or 'path.cwd()'; i.e. a constructor classmethod by analogy with 'dict.fromkeys()' or 'datetime.now()'. 'getcwd()' looks like it's getting a property of a path instance, and doesn't match stdlib conventions for constructors. So, +1 as long as it's called cwd() or something better (i.e. clearer and/or more consistent with stdlib constructor conventions). You're right. +1 for calling it fromcwd(). With that settled, should I rewrite the module? Should I write a PEP? Reinhold -- Mail address is perfectly valid! ___ 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] Some RFE for review
Hi, while bugs and patches are sometimes tricky to close, RFE can be very easy to decide whether to implement in the first place. So what about working a bit on this front? Here are several RFE reviewed, perhaps some can be closed (should is always from submitter's point of view): 1193128: str.translate(None, delchars) should be allowed and only delete delchars from the string. Review: may be a good feature, although string._idmap can be passed as the first parameter too. 1226256: The path module by Jason Orendorff should be in the standard library. http://www.jorendorff.com/articles/python/path/ Review: the module is great and seems to have a large user base. On c.l.py there are frequent praises about it. 1216944: urllib(2) should gain a dict mapping HTTP status codes to the correspondig status/error text. Review: I can't see anything speaking against it. 1214675: warnings should get a removefilter() method. An alternative would be to fully document the filters attribute to allow direct tinkering with it. Review: As mwh said in a comment, this isn't Java, so the latter may be the way to go. 1205239: Shift operands should be allowed to be negative integers, so e.g. a -2 is the same as a 2. Review: Allowing this would open a source of bugs previously well identifiable. 1152248: In order to read records separated by something other than newline, file objects should either support an additional parameter (the separator) to (x)readlines(), or gain an additional method which does this. Review: The former is a no-go, I think, because what is read won't be lines. The latter is further complicating the file interface, so I would follow the principle that not every 3-line function should be builtin. 1110010: A function attrmap should be introduced which is used as follows: attrmap(x)['att'] == getattr(x, 'att') The submitter mentions the use case of new-style classes without a __dict__ used at the right of %-style string interpolation. Review: I don't know whether this is worth it. 1052098: An environment variable should be supported to set the default encoding. Review: If one wants this for a single application, he can still implement it himself. 985094: getattr should support a callable as the second argument, used as follows: getattr(obj, func) == func(obj) Review: Highly unintuitive to me. That's all for today; sorry if it was too much ;) Reinhold -- Mail address is perfectly valid! ___ 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] Adding the 'path' module (was Re: Some RFE for review)
Phillip J. Eby wrote: At 06:57 PM 6/26/2005 +0200, Reinhold Birkenfeld wrote: 1226256: The path module by Jason Orendorff should be in the standard library. http://www.jorendorff.com/articles/python/path/ Review: the module is great and seems to have a large user base. On c.l.py there are frequent praises about it. [...] Aside from all these concerns, I'm +1 on adding the module. Here's my list of suggested changes: [...] I agree with your changes list. One more issue is open: the one of naming. As path is already the name of a module, what would the new object be called to avoid confusion? pathobj? objpath? Path? Reinhold -- Mail address is perfectly valid! ___ 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] [Python-checkins] python/dist/src/Lib Cookie.py, 1.17, 1.18
Tim Peters wrote: [EMAIL PROTECTED] Update of /cvsroot/python/python/dist/src/Lib In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4891/Lib Modified Files: Cookie.py Log Message: bug [ 1108948 ] Cookie.py produces invalid code [...] I assume this accounts for the current failure of test_cookie: You're right, I forgot to checkin the change to the output file. Thanks, Reinhold -- Mail address is perfectly valid! ___ 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] Recommend accepting PEP 312 -- Simple Implicit Lambda
Kay Schluehr wrote: Reduction provides often the advantage to make expressions/statements scriptable what they are not in Python. Python is strong in scripting classes/objects ( a big plus of the language ) but you can't simply use the language to prove that lambda x,y: x+y*y lambda x,y: y**2+x are essentialy the same functions with different implementations [1]. Except that they are not. Think of __pow__, think of __add__ and __radd__. Reinhold -- Mail address is perfectly valid! ___ 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] Recommend accepting PEP 312 -- Simple Implicit Lambda
Kay Schluehr wrote: Reinhold Birkenfeld wrote: lambda x,y: x+y*y lambda x,y: y**2+x are essentialy the same functions with different implementations [1]. Except that they are not. Think of __pow__, think of __add__ and __radd__. You know the difference between the concept of a function and it's infinitely many representations? That's why formal definitions exist. I must say that I don't understand what you're after. Reinhold -- Mail address is perfectly valid! ___ 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] Thoughts on stdlib evolvement
Skip Montanaro wrote: Tim On 6/6/05, Reinhold Birkenfeld [EMAIL PROTECTED] wrote: - Flat namespace: Should we tend to a more hierarchic library (e.g. inet.url, inet.http, inet.nntp)? This would increase clarity when searching for a module. Tim -1. I feel the opposite way: when trying to figure out where Tim something lives, I prefer Python's flat namespace to (for Tim example) Java's com.company.baz.bar.foo hierarchy. I think Reinhold's suggestion (e.g., inet.*) was for a flatter namespace than Java's scheme, but for a slightly more structured namespace than the current standard library provides. Some amount of structure helps to collect modules together whose names don't obviously suggest who their neighbors are in the functionality space. For example, to the naive user it might not be obvious that these groups of modules and packages are related: * getopt and optparse * bsddb, gdbm and anydbm * email, mhlib, quopri * heapq, collections * user, site, sitecustomize * profile, hotshot, pstats * pipes, subprocess, os Yep, exactly. Java's namespaces are ugly, that's right, but a flatter version certainly improves readability. Namespaces are one honking great idea -- let's do more of those! I wouldn't mind a stdlib that defined a set of top-level packages (some of which might be wholly unpopulated by modules in the standard distribution) It might, for example, define a gui package and gui.Tkinter and gui._tkinter modules, leaving the remainder of gui namespace available for 3rd party modules. Such a scheme would probably work best if there was some fairly lightweight registration/approval process in the community to avoid needless collisions. For example, it might be a bit confusing if two organizations began installing their packages in a subpackage named gui.widgets. An unsuspecting person downloading an application that used one version of gui.widgets into environment with the conflicting gui.widgets would run into trouble. Is the CPAN namespace wide open? If I wanted to create a Perl module to fit into the HTML namespace is there some procedure involved or is it an example of squatters' rights? Personally, I think that CPAN is one of the greatest strengths of Perl. The language is a mess, and the quality of many modules is questionable, but it's incredibly easy to find a module for handling a special problem, and the namespaces are IMHO well thought out. Additionally, the docs - 3rd party modules: There are many superb modules out there, some of which really do have a standard character. Examples include PIL, numarray, ElementTree, [wxPython - I know this is a hairy issue], Tim I think the most important question for each of these is is the Tim module's release schedule at least as stable as Python's?. For Tim many of these, I suspect the answer is no. If you provide the necessary namespace structure for them to nestle into, I suspect most of them could be maintained outside the stdlib just fine. Exactly! There needn't be such a big separation between stdlib and 3rd party. Access to the net is standard nowadays, though it wouldn't be of any harm making a big distribution with all modules available, for downloading and burning on CD, for example. PJE's great EasyInstall and Python Eggs will be a perfect starting point for this, I think. Reinhold -- Mail address is perfectly valid! ___ 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] Thoughts on stdlib evolvement
Hello, I am currently having some thoughts about the standard library, with regard to Python 2.5 and 3.0. Since I don't want to withhold them from you, here are they ;) - Flat namespace: Should we tend to a more hierarchic library (e.g. inet.url, inet.http, inet.nntp)? This would increase clarity when searching for a module. - 3rd party modules: There are many superb modules out there, some of which really do have a standard character. Examples include PIL, numarray, ElementTree, [wxPython - I know this is a hairy issue], - User interface: Tkinter may be the standard, but other Toolkits deserve notice, notably wxPython and PyGtk, the latter of which might be even easier to package. Reinhold, please don't hit me! -- Mail address is perfectly valid! ___ 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] Closing old bugs
Raymond Hettinger wrote: I've seen some systems that solve this problem by allowing users to vote for favorite bugs... then you can tell the important bugs because they are more likely to have lots of votes. As I see it, Facundo is using a variant of that system. He is asking whether there is *ONE PERSON* out there who cares enough about a bug to subscribe to it and then to respond to his inquiry. If there's not even one such person, then he's closing the bug (but if one such person comes along later, they can re-report it). -1 This is both silly and harmful. It in no way resembles a professional approach to bug resolution. It throws away valuable information based on some vague theory of developer marketing (i.e. threatening to close a bug will cause a qualified, interested developer to suddenly have both the time and inclination to address it properly). ACK so far. If the real goal is to kick some life into bug resolution, then do something that directly fulfills that goal. Host a bug day. Make a newsgroup posting requesting thoughts on your favorite ten bugs. Write email to people who you think are capable of addressing the particular issue in question. Go recruit some qualified developers. Or just find a bug that interests you and fix it. Well, to fix it is not so easy for most people. You have to post a patch or attach it to the bug and then wait for someone to check it in. It's not sure that this is done anytime soon (no complaint; time is short, I know). Even fixes that are agreed upon by several people are not always checked in for a long time. Reinhold -- Mail address is perfectly valid! ___ 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] sys.path in interactive session
While looking at bug #779191, I saw that sys.path's first element is '' in interactive sessions, but the current dir otherwise. Is this intentional? Reinhold -- Mail address is perfectly valid! ___ 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] Request for dev permissions
Raymond Hettinger wrote: [Reinhold Birkenfeld] would anybody mind if I was given permissions on the tracker and CVS, for fixing small things like bug #1202475. I feel that I can help you others out a bit with this and I promise I won't change the interpreter to accept braces... Let's start out with CVS tracker permissions. When you have a patch that is really to apply, upload it to the tracker and assign to me. OK, thanks. Reinhold -- Mail address is perfectly valid! ___ 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] Request for dev permissions
Hello, would anybody mind if I was given permissions on the tracker and CVS, for fixing small things like bug #1202475. I feel that I can help you others out a bit with this and I promise I won't change the interpreter to accept braces... Reinhold -- Mail address is perfectly valid! ___ 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] Pre-PEP: Unifying try-except and try-finally
Guido van Rossum wrote: [François Pinard] It happens once in a while that I want to comment out the except clauses of a try statement, when I want the traceback of the inner raising, for debugging purposes. Syntax forces me to also comment the `try:' line, and indent out the lines following the `try:' line. And of course, the converse operation once debugging is done. This is slightly heavy. I tend to address this by substituting a different exception. I don't see the use case common enough to want to allow dangling try-suites. Easy enough, adding raise at the top of the except clause also solves the problem. P.S. - Another detail, while on this subject. On the first message I've read on this topic, the original poster wrote something like: f = None try: f = action1(...) ... finally: if f is not None: action2(f) The proposed syntax did not repeat this little part about None, quoted above, so suggesting an over-good feeling about syntax efficiency. While nice, the syntax still does not solve this detail, which occurs frequently in my experience. Oh, I do not have solutions to offer, but it might be worth a thought from the mighty thinkers of this list :-) I don't understand your issue here. What is the problem with that code? Perhaps it ought to be rewritten as f = action1() try: ... finally: action2(f) I can't see how this would ever do something different than your version. Well, in the original the call to action1 was wrapped in an additional try-except block. f = None try: try: f = action1() except: print error finally: if f is not None: action2(f) Reinhold -- Mail address is perfectly valid! ___ 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] Pre-PEP: Unifying try-except and try-finally
Hello,
after proposing this here (albeit deep in the PEP 340 thread) and
getting a somewhat affirmatory response from Guido, I have written
something that could become a PEP if sufficiently hatched...
---
PEP: XXX
Title: Unifying try-except and try-finally
Version: $Revision: $
Last-Modified: $Date: $
Author: Reinhold Birkenfeld [EMAIL PROTECTED]
Status: Draft
Type: Standards Track
Content-Type: text/plain
Created: 04-May-2005
Post-History:
Abstract
This PEP proposes a change in the syntax and semantics of try
statements to allow combined try-except-finally blocks. This
means in short that it would be valid to write
try:
do something
except Exception:
handle the error
finally:
cleanup
Rationale/Proposal
There are many use cases for the try-except statement and
for the try-finally statement per se; however, often one needs
to catch exceptions and execute some cleanup code afterwards.
It is slightly annoying and not very intelligible that
one has to write
f = None
try:
try:
f = open(filename)
text = f.read()
except IOError:
print 'An error occured'
finally:
if f:
f.close()
So it is proposed that a construction like this
try:
suite 1
except Ex1:
suite 2
more except: clauses
else:
suite 3
finally:
suite 4
be exactly the same as the legacy
try:
try:
suite 1
except Ex1:
suite 2
more except: clauses
else:
suite 3
finally:
suite 4
This is backwards compatible, and every try statement that is
legal today would continue to work.
Changes to the grammar
The grammar for the try statement, which is currently
try_stmt: ('try' ':' suite (except_clause ':' suite)+
['else' ':' suite] | 'try' ':' suite 'finally' ':' suite)
would have to become
try_stmt: ('try' ':' suite (except_clause ':' suite)+
['else' ':' suite] ['finally' ':' suite] |
'try' ':' suite (except_clause ':' suite)*
['else' ':' suite] 'finally' ':' suite)
Implementation
As the PEP author currently does not have sufficient knowledge
of the CPython implementation, he is unfortunately not able
to deliver one.
References
None yet.
Copyright
This document has been placed in the public domain.
---
Reinhold
--
Mail address is perfectly valid!
___
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] PEP 340: Breaking out.
Paul Moore wrote: On 5/4/05, Alex Martelli [EMAIL PROTECTED] wrote: On May 4, 2005, at 01:57, Paul Moore wrote: I can't think of a reasonable condition which wouldn't involve reading the file - which either involves an inner loop (and we already can't break out of two loops, so the third one implied by the opening block makes things no worse), or needs the whole file reading (which can be Looking for a file with a certain magicnumber in its 1st two bytes...? for name in filenames: opening(name) as f: if f.read(2) == 0xFEB0: break This does seem to make real-life sense to me... Yes, that'd do. I can't say I think it would be common, but it's a valid case. And the workaround is the usual messy flag variable: for name in filenames: found = False opening(name) as f: if f.read(2) == 0xFEB0: found = True if found: break Is there anything we could do about this? Reinhold -- Mail address is perfectly valid! ___ 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] begin as keyword for pep 340
Adam Souzis wrote: I'm a bit surpised that no one has yet [1] suggested begin as a keyword instead block as it seems to express the intent of blocks and is concise and readable. For example, here are the examples in PEP 340 rewritten using begin: begin locking(): ... I don't know, but I always would expect end to follow each begin somewhere... the-good-old-pascal-days-ly yours, Reinhold PS: What about using? Too C#-ish? -- Mail address is perfectly valid! ___ 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] Pre-PEP: Unifying try-except and try-finally
Tim Peters wrote: [Reinhold Birkenfeld] ... I think the behaviour of the else clause is much harder to guess, mainly when used with the looping constructs. No, that's obvious wink. OK, I'm persuaded. Well you wield the Force, master. What about `else` mixed with try/except/finally? try: A except: B else: C finally: D If A executes without exception, does D execute before or after C? Given the order of the clauses, is it so ambiguous? Reinhold -- Mail address is perfectly valid! ___ 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] Re: anonymous blocks
Guido van Rossum wrote: [Greg Ewing] I like the general shape of this, but I have one or two reservations about the details. That summarizes the feedback so far pretty well. I think we're on to something. And I'm not too proud to say that Ruby has led the way here to some extent (even if Python's implementation would be fundamentally different, since it's based on generators, which has some different possibilities and precludes some Ruby patterns). Five random thoughts: 1. So if break and continue are allowed in with statements only when there is an enclosing loop, it would be a inconsistency; consider for item in seq: with gen(): continue when the generator gen catches the ContinueFlow and does with it what it wants. It is then slightly unfair not to allow with x: continue Anyway, I would consider both counterintuitive. So what about making ReturnFlow, BreakFlow and ContinueFlow private exceptions that cannot be caught in user code and instead introducing a new statement that allows passing data to the generator? 2. In process of handling this, would it be reasonable to (re)introduce a combined try-except-finally statement with defined syntax (all except before finally) and behavior (finally is always executed)? 5. What about the intended usage of 'with' as in Visual B.. NO, NO, NOT THE WHIP! (not that you couldn't emulate this with a clever generator: def short(x): yield x with short(my.long[object]reference()) as _: _.spam = _.ham = _.eggs() yours, Reinhold -- Mail address is perfectly valid! ___ 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] Re: anonymous blocks
Nick Coghlan wrote: Guido van Rossum wrote: [snip] - I think there's a better word than Flow, but I'll keep using it until we find something better. How about simply reusing Iteration (ala StopIteration)? Pass in 'ContinueIteration' for 'continue' Pass in 'BreakIteration' for 'break' Pass in 'AbortIteration' for 'return' and finalisation. And advise strongly *against* intercepting AbortIteration with anything other than a finally block. Hmmm... another idea: If break and continue return keep exactly the current semantics (break or continue the innermost for/while-loop), do we need different exceptions at all? AFAICS AbortIteration (+1 on the name) would be sufficient for all three interrupting statements, and this would prevent misuse too, I think. yours, Reinhold -- Mail address is perfectly valid! ___ 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] Re: anonymous blocks
Nick Coghlan wrote: Interestingly, with this approach, for dummy in my_resource() would still wrap the block of code in the entrance/exit code (because my_resource *is* a generator), but it wouldn't get the try/finally semantics. An alternative would be to replace the 'yield None' with a 'break' or 'continue', and create an object which supports the resource protocol and NOT the iterator protocol. Something like: def my_resource(): print Hi! # Do entrance code continue # Go on with the contents of the 'with' block print Bye! # Do exit code (This is currently a SyntaxError, so it isn't ambiguous in any way) Oh, it is ambiguous, as soon as you insert a for/while statement in your resource function and want to call continue in there. Other than that, it's very neat. Maybe yield alone (which is always a SyntaxError) could be used. Reinhold -- Mail address is perfectly valid! ___ 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] Re: anonymous blocks
Guido van Rossum wrote: What was your opinion on where as a lambda replacement? i.e. foo = bar(callback1, callback2) where: def callback1(x): print hello, def callback2(x): print world! I don't recall seeing this proposed, but I might have -- I thought of pretty much exactly this syntax in the shower a few days ago. Gee, the time machine again! Lots of proposals on c.l.py base on the introduction of expression suites, that is, suites embedded in arbitrary expressions. My opinion is that one will never find a suitable (;-) syntax, there's always the question of where to put the code that follows the suite (and is part of the same statement). yours, Reinhold -- Mail address is perfectly valid! ___ 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] Re: Shorthand for lambda
Ka-Ping Yee wrote: It dawned on me that you could use this idea to make the whole filter/lambda experience vastly more pleasant. I whipped up a quick implementation: from placeholder import _ numbers = [5, 9, 56, 34, 1, 24, 37, 89] filter(_ 30, numbers) [5, 9, 1, 24] map(_ + 10, numbers) [15, 19, 66, 44, 11, 34, 47, 99] Look ma, no lambdas! What does you implementation do for this: somevar = False filter(_ and False, numbers) Reinhold ___ 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] Re: Change 'env var BROWSER override' semantics in webbrowser.py
Martin v. Löwis wrote: Rodrigo Dias Arruda Senra wrote: I propose a small change in webbrowse.py module. I think I'm generally in favour of such a change. However: - please don't post patches to python-dev, unless you *want* them to be ignored. Typically, nobody will pick up patches from python-dev and apply them, except for rare cases (e.g. urgent bug fixes of serious breakages); post to SF instead. - please accompany your change with a documentation patch. It may be that the exact search procedure for browsers is not specified yet; take that chance and specify it so clearly that the code without your patch would actually conflict with the documentation, so that readers of the new code can verify that this is indeed the documentation-mandated behaviour. - consider integration of test cases. As this involves startup code and environment variables, I would be willing to waive the test case requirement here as unimplementable. However, do consider writing test cases. Additionally, there are several patches on SF that pertain to webbrowser.py; perhaps you can review some of them... Reinhold -- Mail address is perfectly valid! ___ 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] Re: @deprecated (was: Useful thread project for 2.5?)
Nick Coghlan wrote: Raymond Hettinger wrote: Decorators like this should preserve information about the underlying function: def deprecated(func): This is a decorator which can be used to mark functions as deprecated. It will result in a warning being emmitted when the function is used. def newFunc(*args, **kwargs): warnings.warn(Call to deprecated function.) return func(*args, **kwargs) newFunc.__name__ = func.__name__ newFunc.__doc__ = func.__doc__ newFunc.__dict__.update(func.__dict__) return newFunc A utility method on function objects could simplify this: newFunc.update_info(func) +1. This is really good for 90% of all decorator uses. But maybe a better name should be found, perhaps update_meta. Reinhold -- Mail address is perfectly valid! ___ 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] Legacy bugs on SF
Hello, still in 2004, this comment was added to old bugs with groups Python2.*: Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as Won't fix. The month is over now, so what to do with them? Note that there are other very old bugs, e.g. in the Platform-specific group, which I think may be closed too. Reinhold -- Mail address is perfectly valid! ___ 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] What about CALL_ATTR?
While rummaging in the old patches, I found this: The result of the PyCore sprint of me and Brett: the CALL_ATTR opcode (LOAD_ATTR and CALL_FUNCTION combined) that skips the PyMethod creation and destruction for classic classes (but not newstyle classes, yet.) The code is somewhat rough yet, it needs commenting, some renaming, and most importantly testing. It seems to work, however, and provides between a 35% and 5% speedup. (5% in 'average' code, up to 35% in instance method calls and instance creation alone.) It also needs to be updated to include newstyle classes. I will likely work on this on the flight home. (patch #709744) How is the status of this? Sounds promising, I'd say... Reinhold -- Mail address is perfectly valid! ___ 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
