Re: [Python-Dev] Issues to be closed: objections?
On Mon, 16 Feb 2009, Daniel (ajax) Diniz wrote: http://bugs.python.org/issue809887 Improve pdb breakpoint feedback Why this one? John ___ 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] unittest Suggestions
On Wed, 13 Aug 2008, Antoine Pitrou wrote: [...] nose itself is not a completely independent piece of work but a discovery-based unittest extension (although a very big extension!). For that reason, Michael Foord's suggestion to gradually modernize and improve the stdlib unittest sounds reasonable to me: it allows to be more focussed, keep backwards compatibility, and also to decide and implement changes piecewise - avoiding the blank sheet effect where people all push for wild ideas and radically new concepts (tm). +1 (speaking as somebody who has worked on nose a bit) John ___ 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] fileobj.read(float): warning or error?
On Tue, 22 Jul 2008, Cameron Simpson wrote: [...] Leaving aside the 0.2 = 0 converstion, shouldn't read() raise an exception if asked for 1 bytes? Or is there a legitimate use for read(0) with which I was not previously aware? http://docs.python.org/lib/bltin-file-objects.html read([size]) ... If the size argument is negative or omitted, read all data until EOF is reached. ... John ___ 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] fileobj.read(float): warning or error?
On Wed, 23 Jul 2008, Cameron Simpson wrote: On 22Jul2008 20:56, John J Lee [EMAIL PROTECTED] wrote: On Tue, 22 Jul 2008, Cameron Simpson wrote: [...] Leaving aside the 0.2 = 0 converstion, shouldn't read() raise an exception if asked for 1 bytes? Or is there a legitimate use for read(0) with which I was not previously aware? http://docs.python.org/lib/bltin-file-objects.html read([size]) ... If the size argument is negative or omitted, read all data until EOF is reached. ... Hmm, yeah, but 0 is not negative and not omitted so this does not apply. Well, -1 *is* 1 (and is in the domain of the function), but yes -- sorry, read too quickly, took your 1 too literally. John ___ 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 bug day (was Re: New Developer)
On Fri, 6 Jun 2008, Facundo Batista wrote: [...] Next week we'll have a Python Bug Weekend [3], it's a good moment to gain speed. [...] [3] http://wiki.python.org/moin/PythonBugDay That page says the next bug day will be on Sat, June 21st-22nd 2008, which is in two weeks' time. Has that plan changed? John ___ 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] on Python's tests (and making them better)
On Thu, 5 Jun 2008, Benjamin Peterson wrote: - reorganizing the tests into separate directories Why this one? John ___ 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] Fwd: Problem withthe API for str.rpartition()
On Tue, 5 Sep 2006, Fred L. Drake, Jr. wrote: On Tuesday 05 September 2006 13:24, Michael Chermside wrote: How about something like this: S.partition(sep) - (head, sep, tail) S.rpartition(sep) - (tail, sep, rest) I think I prefer: S.partition(sep) - (head, sep, rest) S.rpartition(sep) - (tail, sep, rest) Here, rest is always used for what remains; head/tail are somewhat more clear here I think. But isn't rest is in the wrong place there, for rpartition: that's not the string that you might typically call.rpartition() on a second time. How about: S.partition(sep) - (left, sep, rest) S.rpartition(sep) - (rest, sep, right) John ___ 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] Py2.5 issue: decimal context manager misimplemented, misdesigned, and misdocumented
On Thu, 31 Aug 2006, Nick Coghlan wrote: [...] I committed this fix as 51664 on the trunk (although the docstrings are still example free because doctest doesn't understand __future__ statements). [...] Assuming doctest doesn't try to parse the Python code when SKIP is specified, I guess this would solve that little problem: http://docs.python.org/dev/lib/doctest-options.html SKIP When specified, do not run the example at all. This can be useful in contexts where doctest examples serve as both documentation and test cases, and an example should be included for documentation purposes, but should not be checked. E.g., the example's output might be random; or the example might depend on resources which would be unavailable to the test driver. The SKIP flag can also be used for temporarily commenting out examples. ... Changed in version 2.5: Constant SKIP was added. John ___ 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] String formatting / unicode 2.5 bug?
On Mon, 21 Aug 2006, Nick Coghlan wrote: John J Lee wrote: And once the result has been promoted to unicode, __unicode__ is used directly: print repr(%s%s % (a(), a())) __str__ accessing __main__.a object at 0x00AF66F0.__unicode__ __str__ accessing __main__.a object at 0x00AF6390.__unicode__ __str__ u'hihi' I don't understand this part. Why is __unicode__ called? Your example doesn't appear to show this happening once [i.e., because?] the result has been promoted to unicode -- if that were true, it would stand to reason wink that the interpreter would then conclude it should call __unicode__ for all remaining %s, and not bother with __str__. It does try to call unicode directly, but because the example object doesn't supply __unicode__ it ends up falling back to __str__ instead. The behaviour is clearer when the example object provides both methods: [...] If the interpreter is falling back from __unicode__ to __str__ (rather than the other way around, kind-of), that makes much more sense. I understood that __unicode__ was not provided, of course -- what wasn't clear to me was why the interpreter was calling/accessing those methods/attributes in the sequence it does. Still not sure I understand what the third __str__ above comes from, but until I've thought it through again, that's my problem. John ___ 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] String formatting / unicode 2.5 bug?
On Sun, 20 Aug 2006, Nick Coghlan wrote: John J Lee wrote: Is this a bug? I don't believe so - the string formatting documentation states that the result will be unicode if either the format string is unicode or any of the objects passed to a %s format code is unicode. That latter part has just been extended to include any object that returns Unicode from __str__, instead of being restricted to actual Unicode instances. Note that the following behaves the same way regardless of whether you use 2.4 or 2.5: %s % 'hi' %s % u'hi' Given that, the following wording should be changed: http://docs.python.org/lib/typesseq-strings.html Conversion Meaning Notes ... s String (converts any python object using str()). (4) ... (4) If the object or format provided is a unicode string, the resulting string will also be unicode. The note (4) says that the result will be unicode, but it doesn't say how, in this case, that comes about. This case is confusing because the docs claim string formatting with %s converts ... using str(), and yet str(a()) returns a bytestring. Does it *really* use str, or just __str__? Surely the latter? (given the observed behaviour, and not reading the C source) FWIW, this change broke epydoc (fails with an AssertionError -- so perhaps without the assert it would still work, dunno). And once the result has been promoted to unicode, __unicode__ is used directly: print repr(%s%s % (a(), a())) __str__ accessing __main__.a object at 0x00AF66F0.__unicode__ __str__ accessing __main__.a object at 0x00AF6390.__unicode__ __str__ u'hihi' I don't understand this part. Why is __unicode__ called? Your example doesn't appear to show this happening once [i.e., because?] the result has been promoted to unicode -- if that were true, it would stand to reason wink that the interpreter would then conclude it should call __unicode__ for all remaining %s, and not bother with __str__. If OTOH __unicode__ is called because __str__ returned a unicode object, it makes (very slightly) more sense that it goes through the same __str__-then-__unicode__ rigmarole for each object on the RHS of the %. But none of that seems to make a huge amount of sense. I've now found the September 2004 discussion of this, and I'm none the wiser. John ___ 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] String formatting / unicode 2.5 bug?
On Sun, 20 Aug 2006, Neil Schemenauer wrote: John J Lee [EMAIL PROTECTED] wrote: The note (4) says that the result will be unicode, but it doesn't say how, in this case, that comes about. This case is confusing because the docs claim string formatting with %s converts ... using str(), and yet str(a()) returns a bytestring. Does it *really* use str, or just __str__? Surely the latter? (given the observed behaviour, and not reading the C source) It uses __str__ and confirms that the returned object is a 'str' or 'unicode'. The docs are not precise but they were not for 2.4 either. Note the following case: [...] OK, but I assume you're not saying that the fact that the docs were broken in 2.4 implies they shouldn't be fixed now? I would suggest revised wording, but I'm clearly confused about what actually goes on under the hood... John ___ 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] String formatting / unicode 2.5 bug?
Is this a bug? # run with 2.4 and then with 2.5 (I'm running release25-maint:51410) class a(object): def __getattribute__(self, name): print accessing %r.%s % (self, name) return object.__getattribute__(self, name) def __str__(self): print __str__ return u'hi' print repr(str(a())) print print repr(%s % a()) John ___ 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] One-line fix for urllib2 regression
Revision 50842 made a change to an undocumented interface of urllib2 that I'm sure will break real code. Patch 1542948 reverts the part of that commit that applied to urllib2, and adds a one-line fix in its place that addresses the problem that 50842 fixed. Details are on the patch tracker: http://python.org/sf/1542948 Can somebody commit this for 2.5? John ___ 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] 2.5: recently introduced sgmllib regexp bug hangs Python
Looks like revision 47154 introduced a regexp that hangs Python (Ctrl-C
won't kill the process, CPU usage sits near 100%) under some
circumstances. There's a test case here:
http://python.org/sf/1541697
The problem isn't seen if you read the whole file at once (or almost the
whole file at once). (But that doesn't make it a non-bug, AFAICS.)
I'm not sure what the problem is, but presumably the relevant part of the
patch is this:
+starttag = re.compile(r'[a-zA-Z][-_.:a-zA-Z0-9]*\s*('
+r'\s*([a-zA-Z_][-:.a-zA-Z_0-9]*)(\s*=\s*'
+r'(\'[^\']*\'|[^]*|[-a-zA-Z0-9./,:;+*%?!$\(\)[EMAIL PROTECTED]'
+r'[][\-a-zA-Z0-9./,:;+*%?!$\(\)_#=~\'@]*(?=[\s/])))?'
+r')*\s*/?\s*(?=[])')
The patch attached to bug 1515142 (also from Sam Ruby -- claims to fix a
regression introduced by his recent sgmllib patches, and has not yet been
applied) does NOT fix the problem.
If nobody has time to fix this, perhaps rev 47154 should be reverted?
commit message for -r47154:
SF bug #1504333: sgmlib should allow angle brackets in quoted values
(modified patch by Sam Ruby; changed to use separate REs for start and end
tags to reduce matching cost for end tags; extended tests; updated to
avoid
breaking previous changes to support IPv6 addresses in unquoted attribute
values)
John
___
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] [wwwsearch-general] 2.5: recently introduced sgmllib regexp bug hangs Python
On Thu, 17 Aug 2006, John J Lee wrote: [...] If nobody has time to fix this, perhaps rev 47154 should be reverted? I should have put it more strongly: I think it *should* in fact be reverted if nobody has time to fix it before the release candidate / final release of 2.5. The revision in question is the most recent commit to sgmllib.py and certainly appears completely localised to that module. And a hung interpreter is worse than failing to parse some HTML, IMHO. [...] commit message for -r47154: SF bug #1504333: sgmlib should allow angle brackets in quoted values (modified patch by Sam Ruby; changed to use separate REs for start and end tags to reduce matching cost for end tags; extended tests; updated to avoid breaking previous changes to support IPv6 addresses in unquoted attribute values) [...] ___ 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] unicode hell/mixing str and unicode as dictionary keys
On Thu, 3 Aug 2006, M.-A. Lemburg wrote: [...] It's actually a good preparation for Py3k where 1 == u'abc' will (likely) also raise an exception. I though I'd heard (from Guido here or on the py3k list) that it was only 1 u'abc' that would raise an exception, and that 1 == u'abc' would still evaluate to False. Did I misunderstand? John ___ 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] httplib and bad response chunking
On Tue, 25 Jul 2006, Greg Ward wrote: [...] Where I'm getting hung up is how far to test this stuff. Stop when you run out of time ;-) I have discovered other hypothetical cases of bad chunking that cause httplib to go into an infinite loop or block forever on socket.readline(). Should we worry about those cases as well, despite not having seen them happen in the wild? More annoying, I can reproduce the block forever case using a real socket, but not using the StringIO-based FakeSocket class in test_httplib. They have been seen in the wild :-) http://python.org/sf/1411097 The IP address referenced isn't under my control, I don't know if it still provokes the error, but the problem is clear. John ___ 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] New miniconf module
On Wed, 26 Jul 2006, Phillip J. Eby wrote: [...] Actually, I would see more reason to include JSON in the standard library, since it's at least something approaching an internet protocol these days. +1 John ___ 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] urllib.quote and unicode bug resuscitation attempt
On Tue, 11 Jul 2006, Stefan Rank wrote:
urllib.quote fails on unicode strings and in an unhelpful way::
[...]
urllib.quote(u'a\xf1a')
Traceback (most recent call last):
File stdin, line 1, in ?
File C:\Python24\lib\urllib.py, line 1117, in quote
res = map(safe_map.__getitem__, s)
KeyError: u'\xf1'
More helpful than silently producing the wrong answer.
[...]
I suggest to add (after 2.5 I assume) one of the following to the
beginning of urllib.quote to either fail early and consistently on
unicode arguments and improve the error message::
if isinstance(s, unicode):
raise TypeError(quote needs a byte string argument, not unicode,
use `argument.encode('utf-8')` first.)
Won't this break existing code that catches the KeyError, for no big
benefit? If nobody is yet sure what the Right Thing is (see below), I
think we should not change this yet.
or to do The Right Thing (tm), which is utf-8 encoding::
if isinstance(s, unicode):
s = s.encode('utf-8')
as suggested in
http://www.w3.org/International/O-URL-code.html
and rfc3986.
You seem quite confident of that. You may be correct, but have you read
all of the following? (not trying to claim superior knowledge by asking
that, I just dunno what the right thing is yet: I haven't yet read RFC
2617 or got my head around what the unicode issues are or how they should
apply to the Python stdlib)
http://www.ietf.org/rfc/rfc2617.txt
http://www.ietf.org/rfc/rfc2616.txt
http://en.wikipedia.org/wiki/Percent-encoding
http://mail.python.org/pipermail/python-dev/2004-September/048944.html
Also note the recent discussions here about a module named uriparse or
urischemes, which fits in to this somewhere. It would be good to make
all the following changes in a single Python release (2.6, with luck):
- extend / modify urllib and urllib2 to handle unicode input
- address the urllib.quote issue you raise above (+ consider the other
utility functions in that module)
- add the urischemes module
In summary, I agree that your suggested fix (and all of the rest I refer
to above) should wait for 2.6, unless somebody (Martin?) who understands
all these issues is quite confident your suggested change is OK.
Presumably the release managers wouldn't allow it in 2.5 anyway.
John
___
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] Time-out in URL Open
On Mon, 3 Jul 2006, Guido van Rossum wrote: To fake things like this, socket.setdefaulttimeout() was added, though I don't know if it actually works. Have you tried that? [...] It works. I think there's some issue with SSL, though (can't seem to find the issue now). Of course, feeding through the timeout to the individual protocol modules would be a good thing. John ___ 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 more comments re new uriparse module, patch 1462525
On Mon, 5 Jun 2006, Nick Coghlan wrote: [...] I started to write a reply to this with some comments on the API (including the internal subclassing API), but ended up with so many different suggestions it was easier to just post a variant of the module. I called it urischemes and posted it on SF: http://python.org/sf/1500504 [...] At first glance, looks good. I hope to review it properly later. One point: I don't think there should be any mention of URL in the module -- we should use URI everywhere (see my comments on Paul's original version for a bit more on this). John ___ 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 more comments re new uriparse module, patch 1462525
[Not sure whether this kind of thing is best posted as tracker comments (but then the tracker gets terribly long and is mailed out every time a change happens) or posted here. Feel free to tell me I'm posting in the wrong place...] Some comments on this patch (a new module, submitted by Paul Jimenez, implementing the rules set out in RFC 3986 for URI parsing, joining URI references with a base URI etc.) http://python.org/sf/1462525 Sorry for the pause, Paul. I finally read RFC 3986 -- which I must say is probably the best-written RFC I've read (and there was much rejoicing). I still haven't read 3987 and got to grips with the unicode issues (whatever they are), but I have just implemented the same stuff you did, so have some comments on non-unicode aspects of your implementation (the version labelled v23 on the tracker): Your urljoin implementation seems to pass the tests (the tests taken from the RFC), but I have to I admit I don't understand it :-) It doesn't seem to take account of the distinction between undefined and empty URI components. For example, the authority of the URI reference may be empty but still defined. Anyway, if you're taking advantage of some subtle identity that implies that you can get away with truth-testing in place of is None tests, please don't ;-) It's slower than is [not] None tests both for the computer and (especially!) the reader. I don't like the use of module posixpath to implement the algorithm labelled remove_dot_segments. URIs are not POSIX filesystem paths, and shouldn't depend on code meant to implement the latter. But my own implementation is exceedingly ugly ATM, so I'm in no position to grumble too much :-) Normalisation of the base URI is optional, and your urljoin function never normalises. Instead, it parses the base and reference, then follows the algorithm of section 5.2 of the RFC. Parsing is required before normalisation takes place. So urljoin forces people who need to normalise the URI before to parse it twice, which is annoying. There should be some way to parse 5-tuples in instead of URIs. E.g., from my implementation: def urljoin(base_uri, uri_reference): return urlunsplit(urljoin_parts(urlsplit(base_uri), urlsplit(uri_reference))) It would be nice to have a 5-tuple-like class (I guess implemented as a subclass of tuple) that also exposes attributes (.authority, .path, etc.) -- the same way module time does it. The path component is required, though may be empty. Your parser returns None (meaning undefined) where it should return an empty string. Nit: Your tests involving ports contain non-digit characters in the port (viz. port), which is not valid by section 3.2.3 of the RFC. Smaller nit: the userinfo component was never allowed in http URLs, but you use them in your tests. This issue is outside of RFC 3986, of course. Particularly because the userinfo component is deprecated, I'd rather that userinfo-splitting and joining were separate functions, with the other functions dealing only with the standard RFC 3986 5-tuples. DefaultSchemes should be a class attribute of URIParser The naming of URLParser / URIParser is still insane :-) I suggest naming them _URIParser and URIParser respectively. I guess there should be no mention of URL anywhere in the module -- only URI (even though I hate URI, as a mostly-worthless distinction from URL, consistency inside the module is more important, and URI is technically correct and fits with all the terminology used in the RFC). I'm still heavily -1 on calling it uriparse though, because of the highly misleading comparison with the name urlparse (the difference between the modules isn't the difference between URIs and URLs). Re your comment on mailto:; in the tracker: sure, I understand it's not meant to be public, but the interface is! .parse() will return a 4-tuple for mailto: URLs. For everything else, it will return a 7-tuple. That's silly. The documentation should explain that the function of URIParser is hiding scheme-dependent URI normalisation. Method names and locals are still likeThis, contrary to PEP 8. docstrings and other whitespace are still non-standard -- follow PEP 8 (and PEP 257, which PEP 8 references) Doesn't have to be totally rigid of course -- e.g. lining up the : characters in the tests is fine. Standard stdlib form documentation is still missing. I'll be told off if I don't read you your rights: you don't have to submit in LaTeX markup -- apparently there are hordes of eager LaTeX markers-up lurking ready to pounce on poorly-formatted documentation wink Test suite still needs tweaking to put it in standard stdlib form John ___ 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] Assigning Group on SF tracker?
When opening patches on the SF tracker for bugs that affect Python 2.5, but may be candidates for backporting (to 2.4 ATM), should I leave Group as None, or set it to Python 2.5 to indicate it affects 2.5? If it's known to be a candidate for backporting, should I set it to Python 2.4 to indicate that? I'm guessing I should always select Python 2.5 if it affects 2.5, but I've been using None up till now, I think... John ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Bug day?
Is another bug day planned in the next week or two? John ___ 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] Visual studio 2005 express now free
On Mon, 24 Apr 2006, Paul Moore wrote: On 4/24/06, Neil Hodgson [EMAIL PROTECTED] wrote: Martin v. Löwis: Apparently, the status of this changed right now: it seems that the 2003 compiler is not available anymore; the page now says that it was replaced with the 2005 compiler. Should we reconsider? [...] No. Martin means that http://msdn.microsoft.com/visualc/vctoolkit2003/ no longer points to a downloadable version of MSVC which includes the optimizer, and generates VC 7.1 compatible binaries. This means that unless you've already downloaded it, or it's acceptable for someone else to host it, there's once again no way to build Python with free tools :-( [...] Actually, it's apparently still there, just at a different URL. Somebody posted the new URL on c.l.py a day or two back (Alex Martelli started the thread, IIRC). I'm off to the dentist, no time to Google for it! John___ 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] setuptools: past, present, future
On Sat, 22 Apr 2006, Fredrik Lundh wrote: Guido van Rossum wrote: [...] Python sorely lacks; but I've also heard from more than one person that CPAN sucks from a quality perspective. So I think we shouldn't [...] (as for the CPAN quality, any public repository will end up being full of crap; I don't see any way to work around that. automatic scoring [...] I had assumed Guido was referring to the quality of the infrastructure, including CPAN.pm, rather than the quality of the code stored in CPAN. I've certainly heard at least two people complain about the usability and reliability of the CPAN infrastructure recently, and recall I found it rather unfriendly myself. But that was around 5 years ago; I may simply be wrong or out of date. John ___ 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] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
On Sat, 15 Apr 2006, Tim Peters wrote: [...] Hmm, will 2.5's doctest work under Python 2.4? I guess that's not guaranteed, since I don't see any comment in doctest.py implying it needs to be compatible with old Pythons. doctest compatibility with 2.4 is neither a goal nor a non-goal for 2.5. I'm not sure why it's being asked, since the incompatible change projected for 2.5 is in how the trackback module spells some exception names; and doctest (every version of doctest) gets its idea of the name of an exception from the traceback module. Ah, yes. (Does the channelling service extend to divining the questions that posters on python-dev *should* have asked? No?) OK, I suppose I should have asked will 2.5's module traceback work with Python 2.4?. I guess the answer is something resembling no, but of course (?) the question I'm really interested in is how, without too much effort or ugliness, can people run their doctests on both 2.4 and 2.5? I guess if I care sufficiently, I should just go ahead and back-port to 2.4 insert whatever #$! code turns out to need back-porting here ;- and post it somewhere for the public good. John ___ 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] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
On Sun, 16 Apr 2006, Guido van Rossum wrote:
On 4/16/06, Paul Moore [EMAIL PROTECTED] wrote:
Personally, my instinct is that having the whole traceback in a
doctest is at least as ugly.
You don't need the whole traceback -- e.g.:
If a URL is supplied, it must have an authority (host:port) component.
According to RFC 3986, having an authority component means the URL must
have two slashes after the scheme:
_parse_proxy('file:/ftp.example.com/')
Traceback (most recent call last):
ValueError: proxy URL with no authority: 'file:/ftp.example.com/'
I think the try: ... except FooException: print 'FooException occurred'
style is uglier and less natural than that, but I guess it's not a big
deal.
Well, it depends on what you use doctest for. If you use it to write
unit tests, the try/except solution is fine, and perhaps preferable.
[...]
Preferable because depending less on irrelevant details? I had thought
that, apart from the issue with module traceback, IGNORE_EXCEPTION_DETAIL
made that a non-issue in most cases, but perhaps I missed something
(again).
John
___
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] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
On Sat, 15 Apr 2006, Tim Peters wrote: [...] [also John] Sorry, please ignore the post of mine I'm replying to here. I missed part of the thread, and Tim has already answered my question... That's news to Tim ;-) You mentioned use of '...' / ELLIPSIS, IIRC, so I assumed that would work -- but it seems not, from your latest post (that I'm replying to here). It's not possible to add a new doctest option in 2.5 that would allow a doctest to work under both 2.4 and 2.5: the test would blow up under 2.4, because 2.4's doctest wouldn't recognize the (new in 2.5) option, and would raise a ValueError of its own griping about the unknown option name. slaps forehead [...] import decimal try: 1 / decimal.Decimal(0) except decimal.DivisionByZero: print good good Yes, that works, I see. Kind of annoying of course, but can't be helped. Hmm, will 2.5's doctest work under Python 2.4? I guess that's not guaranteed, since I don't see any comment in doctest.py implying it needs to be compatible with old Pythons. Oddly enough, ELLIPSIS doesn't actually work for this purpose: [...] John ___ 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] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
Sorry, please ignore the post of mine I'm replying to here. I missed part of the thread, and Tim has already answered my question... On Fri, 14 Apr 2006, John J Lee wrote: [...] Assuming this is fixed in 2.5 final, is there some way to write doctests that work on both 2.4 and 2.5? If not, should something like doctest.IGNORE_EXCEPTION_DETAIL be added -- say IGNORE_EXCEPTION_MODULE? [...] ___ 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] PSF Contributor Agreement for pysqlite
On Mon, 10 Apr 2006, Martin v. Löwis wrote: I think I twice mailed everybody in Misc/ACKS. In principle, we want to have agreements from everybody who ever contributed, so that we can formally change the license (and so that it is clear to Python users what the legal standing is). [...] Not sure if it's just me, but I'm in that list, and I'm pretty sure I neither received an email nor faxed a contributor agreement (and my email address hasn't changed for years). John___ 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] New uriparse.py
On Sun, 2 Apr 2006, Martin v. Löwis wrote: Paul Jimenez wrote: Announcing uriparse.py, submitted for inclusion in the standard library. Patch request 1462525. [...] abstractions; however, this didn't mean anything to me. Saying urlparse doesn't comply with STD66 (aka RFC3986) because it hard-codes URI schemes, instead of applying the same syntax to all of them is something I would have understood as a problem. Evidently Paul quickly realised that back at the time of the original thread: hence the lack of posts from Paul protesting at Guido Mike Brown's explanations, and the appearance now of this nice module :-) So in short: are you willing to write documentation for this? The rationale section could either go into the urllib documentation (pointing out that particular problem, and referring to urilib as an improvement) Currently of course we have both the functions in urllib, plus module urlparse. This module is roughly a replacement for urlparse. Probably if this module is accepted (after a few changes, no doubt) the urllib functions should then be deprecated (which would probably trigger adding a few more functions to the new module). I guess module urlparse would also be deprecated. I have a list of concrete and mostly easily-resolved problems with the module (including not liking the name). I also suspect there are issues related to unicode, %-encoding c. exist which should be resolved before including this in the stdlib; I won't comment further on that until I've read the relevant RFCs. I've posted detailed comments on the tracker. John___ 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] Name for python package repository
On Thu, 30 Mar 2006, Greg Ewing wrote: I just thought of a possible name for the Python package repository. We could call it the PIPE - Python Index of Packages and Extensions. +1 John ___ 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] Py3k: Except clause syntax
On Fri, 17 Mar 2006, [EMAIL PROTECTED] wrote: [...] fuzz Wasn't the proposal : fuzz try: fuzz something fuzz except NameError, OtherError as e: fuzz something... I'm not sure. I only saw SomeError as|with SomeValue. Fuzzyman is right. In your formulation the comma binds more tightly than the as keyword. In import statements it's the other way around. That seems like it might be a source of confusion. Perhaps parentheses around the exception list should be mandatory for the 2-or-more exceptions case? except NameError as e: -- fine except (NameError) as e:-- fine except (NameError,) as e: -- fine except NameError, OtherError as e: -- SyntaxError except (NameError, OtherError) as e:-- fine John ___ 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] syntactic support for sets
On Wed, 1 Feb 2006, Greg Wilson wrote: Like many things in Python where people pre-emptively believe one thing or another, the interpreter's corrective feedback is immediate: Yup, that's the theory; it's a shame practice is different. So what mistake(s) *do* your students make? As people have pointed out, the mistake you complain about *does* usually result in an immediate traceback: set(1, 2, 3) Traceback (most recent call last): File stdin, line 1, in ? TypeError: set expected at most 1 arguments, got 3 set(1) Traceback (most recent call last): File stdin, line 1, in ? TypeError: iteration over non-sequence Perhaps this? set(argh) set(['a', 'h', 'r', 'g']) [...] the language, but I'd rather eliminate the sand traps than reuqire people to learn to recognize and avoid them. I'm sure nobody would disagree with you, but of course the devil is in the detail. John ___ 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] syntactic support for sets
On Wed, 1 Feb 2006, Greg Wilson wrote: [...] (Imagine having to write list(1, 2, 3, 4, 5)...) [...] I believe that was actually proposed on this list for Python 3. John ___ 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] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
On Fri, 27 Jan 2006, Thomas Heller wrote: John J Lee [EMAIL PROTECTED] writes: On Thu, 26 Jan 2006, Thomas Heller wrote: only aclocal.m4 isn't clear to me about the license. Anyway, it could be that this file isn't needed after all - I don't know enough about the GNU toolchain to be sure. Can anyone comment on this? From 'info autoconf': | The Autoconf macros are defined in several files. Some of the files | are distributed with Autoconf; `autoconf' reads them first. Then it | looks for the optional file `acsite.m4' in the directory that contains | the distributed Autoconf macro files, and for the optional file | `aclocal.m4' in the current directory. Those files can contain your | site's or the package's own Autoconf macro definitions (*note Writing [...] So, I assume aclocal.m4 is under the same license as the rest of the libffi you're using. I cannot uinderstand your reasoning. How can 'info autoconf' incluence the license of the aclocal.m4 file? Or do I misunderstand something? OK. I now notice I was confused as to why the license issue arose in the first place, but FWIW: My point was just that the autoconf info pages explain (if I read them right) that one keeps one's project-specific autoconf m4 macros in a file named 'aclocal.m4'. It's not a file distributed with autoconf, it's just a file naming convention, so I made the assumption that since libffi is apparently OK to include in Python, so must be its aclocal.m4 (even if some of the macros in the libffi aclocal.m4 originally derived from some other project). But I'm afraid this would fail with an AssertionError if it weren't pseudocode: import legally_compatible as compat from autoconf import acfiles from ctypes import libffi if compat(acfiles, libffi) and compat(libffi, python): assert compat(acfiles, python), John is not legally competent :-( John ___ 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] The path module PEP
On Tue, 24 Jan 2006, Ian Bicking wrote: [...] Losing .open() would make it much harder for anyone wanting to write, say, a URI library that implements the Path API. [...] Why? Could you expand a bit? What's wrong with urlopen(filesystem_path_instance) ? John ___ 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] / as path join operator (was: Re: The path module PEP)
On Thu, 26 Jan 2006, Tony Meyer wrote: [...] Well, if you include the much larger discussion on python-list, people (including me) have said that removing __div__ is a good idea. If it's included in the PEP, please at least include a justification and cover the problems with it. The vast majority of people (at least at the time) were either +0 or -0, not +1. +0's are not justification for including something. bikeshed FWLIW, I'm definitely +1 on using / as a path join operator. * It's being used to mean join, which is the exact opposite of /'s other meaning (divide). But it's a very readable way to write a common operation. Perhaps one reason the discrepancy you point out doesn't bother me is that division is the least-used of the +-*/ arithmetic operations. Also, , | and ^ seem like some sort of precedent, to my brain (if they don't to yours, that's fine and I believe you ;-). * Python's not Perl. We like using functions and not symbols. I think this is a tasteful, if not parsimonious, use of a symbol. /bikeshed John ___ 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] The path module PEP
On Thu, 26 Jan 2006, Tony Meyer wrote: [...] Why does reusing a string method for something very different seem like a bad idea, but reusing a mathematical operator for something very different seem like a good idea? [...] That's easy -- it's because, if you're going to use a name, people expect (with some level of trust) that you'll pick a good one. But people understand that there are only a few operators to use, so the meaning of operators is naturally more overloaded than that of method names. John ___ 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] / as path join operator (was: Re: The path module PEP)
[John J Lee] But it's a very readable way to write a common operation. Perhaps one reason the discrepancy you point out doesn't bother me is that division is the least-used of the +-*/ arithmetic operations. [Tony Meyer] Do you have evidence to back that up? No. :) [Ian Bicking] of mine, and in 12k lines there were 34 uses of join, and 1 use of division. In smaller scripts os.path.join tends to show up a lot more [Tony] The problem with these sorts of guesses is that there's no evidence. (Maybe the suggestion that Brett's PhD should collect a corpus of Python scripts was a good one wink). Are mathematicians that under represented? Is file processing that highly represented? I have no idea. A second data point: I looked at ~10k lines of physical data analysis code I have lying around -- presumably a relatively rare and extreme example as the Python-world in general goes. Result: 140 occurences of os.path.join 170 physical lines (as opposed to syntactical lines) containing / as a division operator (very few lines contained 1 use of '/', so you can multiply 170 by 1.25 to get an upper bound of 213 uses in total) (To get the second number, I used find and grep heavily but very cautiously, and final manual count of stubborn lines of grep output with no use of '/' as division operator) The fact that even in this extreme case os.path.join is close on the tail of '/' strongly backs up Ian's guess that, in most Python code, / as division is rare compared to path joining. Should we deprecate use of '/' and '//' for division in Python 3.0? is-he-joking?-ly y'rs John ___ 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] site triggering a bug in urllib2
On Tue, 17 Jan 2006, Thomas Mangin wrote:
[...]
I have hit a bug with python 2.4.2 (on Mandriva 2006) using urllib2.
The code which trigger the bug is as follow..
import urllib2
req = urllib2.Request(http://66.117.37.13/;)
# makes no difference ..
req.add_header('Connection', 'close')
handle = urllib2.urlopen(req)
data = handle.read()
print data
using a timeout on the socket does not work neither.
This is a real bug, I think. I filed a report on the SF bug tracker:
http://python.org/sf/1411097
The problem seems to be the (ab)use of socket._fileobject in urllib2 (I
believe this was introduced when urllib2 switched to using
httplib.HTTPConnection). The purpose of the hack (as commented in
AbstractHTTPHandler.do_open()) is to provide .readline() and .readlines()
methods on the response object returned by urllib2.urlopen().
Workaround if you're not using .readline() or .readlines() (against 2.4.2,
but should apply against current SVN):
--- urllib2.py.orig Fri Jan 20 20:10:56 2006
+++ urllib2.py Fri Jan 20 20:12:07 2006
@@ -1006,8 +1006,7 @@
# XXX It might be better to extract the read buffering code
# out of socket._fileobject() and into a base class.
-r.recv = r.read
-fp = socket._fileobject(r)
+fp = r.fp
resp = addinfourl(fp, r.msg, req.get_full_url())
resp.code = r.status
Not sure yet what the actual problem/cure is...
John
___
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] Buildbot questions
On Thu, 5 Jan 2006, Tim Peters wrote: [...] A problem for Windows buildbot slaves is that they need an appropriate compiler. Does this machine have MS VC 7.1 installed? If not, it can't compile the code. The Windows Python would also like to build several other packages (like bz2 and Tcl/Tk). Might a buildbot running this setup of David Munman's (free MS compiler + NAnt interpreting the MS project file) be useful? http://groups.google.co.uk/group/comp.lang.python/browse_frm/thread/226584dd47047bb6/1e33ad19197bee20 (I'm not offering a buildbot myself, just pointing out the possibility of using this tool) There always the chance it gets something wrong or falls over while trying to interpret the project file, of course. That in itself would be beneficial, though, if there's a committer willing to fix it when it breaks -- I currently have access to MS compilers, but I remember many happy :-/ hours as a graduate student trying to compile Fortran and C extensions on win32 with free compilers. An update style of slave does an svn update rather than a full checkout, and that usually goes very fast after the first time. Likewise compiling if binaries are left behind across runs. [...] Much though I like SVN, it seems its working copy management still leaves a little to be desired: Even quite recently (fairly sure it was client version 1.2.*, on Win XP) and with read-only checkouts used only for builds, I've still seen it end up in an incorrect state. I suspect 'svn switch' or 'svn up -r x' was the culprit, though, so perhaps it's not a problem if exactly 'svn up' is the only svn command ever executed on the checkout. Still, perhaps it's wise to wipe the checkout every so often? John ___ 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] Buildbot questions
On Thu, 5 Jan 2006, John J Lee wrote: Might a buildbot running this setup of David Munman's (free MS compiler + NAnt interpreting the MS project file) be useful? s/Munman/Murmann/ John ___ 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
On Fri, 16 Dec 2005, Phillip J. Eby wrote: [...to-and-fro re magic required to get a good SVN revision...] Shouldn't the command 'svnversion' be used instead? - http://svnbook.red-bean.com/en/1.1/re57.html It's true that the output of this command does change with 'svn up', even if the update makes no changes to files under version control in your working copy. It *seems* to be sane reproducible once you've done a single svn up, though (and if there are no locally modified files, mixed checkouts etc., the version it reports will be a single revision number with no non-numeric characters). John ___ 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] ast status, memory leaks, etc
On Tue, 22 Nov 2005, Fredrik Lundh wrote: [...] http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Misc/README.valgrind?view=markup The up-to-date version of that (from SVN instead of old CVS repository) is here: http://svn.python.org/view/python/trunk/Misc/README.valgrind?view=markup John ___ 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] Is some magic required to check out new files from svn?
On Sat, 12 Nov 2005 [EMAIL PROTECTED] wrote: [...] Before I wipe out Include and svn up again is there any debugging I can do for someone smarter in the ways of Subversion than me? Regarding my [...] Output of the svnversion command? That shows switched and locally modified files, etc. I'm not an svn guru, but I find that command useful, especially to point out when I switched some deep directory then forgot about it. John ___ 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 bug in urllib.urljoin
On Fri, 23 Sep 2005, Andrew Edmondson wrote: We've found a problem using urllib.urljoin when upgrading from python 2.3 to 2.4. It no longer joins a particular corner case of URLs correctly (we think!). The code appears to follow the algorithm (from http://www.ietf.org/rfc/rfc1808.txt) for resolving urls almost exacty... [...] Can you tell me if this was a deliberate decision to move from following the algorithm? If so then we'll work around it. I don't know if it was done right, but this came in at revision 1.41 of urlparse.py -- the commit comment is actually in 1.42: | Make urlparse RFC 2396 compliant. | Closes bug #450225 (thanks Michael Stone). So I guess the answer to your question is yes. http://python.org/sf/450225 http://www.ietf.org/rfc/rfc2396.txt John ___ 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] GIL, Python 3, and MP vs. UP (was Re: Variant of removing GIL.)
On Sun, 18 Sep 2005, Guido van Rossum wrote: On 9/17/05, John J Lee [EMAIL PROTECTED] wrote: [...snip...] [guido] If my hunch is right, I expect that instead of writing massively parallel applications, we will continue to write single-threaded applications that are tied together at the process level rather than at the thread level. I tend to agree. [...] I realize that not all algorithms (nor all computational problems) scale well to MP hardware. Is it feasible to usefully compile both MP and a UP binaries from one Python source code base? That's an understatement. I expect that *most* problems (even most problems that we will be programming 10-20 years from now) get little benefit out of MP. Perhaps, but I suspect we'll also get better at thinking up multiprocessor algorithms when better motivated by lack of exponential uniprocessor speed increases. ducks, fearing barrage of theorems... [...] Of course, it still takes a (anti-)hero to step forward and do the work... Be my guest. Prove me wrong. Talk is cheap; instead of arguing my points (all of which can be argued ad infinitum), come back when you've got a working GIL-free Python. Doesn't have to be CPython-based -- C# would be fine too. I don't actively want a GIL-free Python. I was just making some arguments in favour of GIL-removal that I hadn't seen made on a public list before. (In particular, removal now, since now is a special time.) John ___ 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] GIL, Python 3, and MP vs. UP
On Mon, 19 Sep 2005, Florian Weimer wrote: The real problem is that you can ditch most extension modules. 8-( [...] *Is* that a showstopper for Python 3.0, though? John ___ 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] GIL, Python 3, and MP vs. UP (was Re: Variant of removing GIL.)
On Tue, 20 Sep 2005, John J Lee wrote: [...] I don't actively want a GIL-free Python. I was just making some arguments [...] Actually, FWIW, I don't know if I even *passively* want a GIL-free Python, if it encourages threaded code (though I'd like to have that option for my occasional personal use, it seems to be an attractive nuisance for many other programmers). John ___ 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] GIL, Python 3, and MP vs. UP
On Mon, 19 Sep 2005, Tim Lesher wrote: On 9/19/05, Michael Hudson [EMAIL PROTECTED] wrote: I was disappointed that that article (hey, it was the only issue of ddj I've ever actually bought! :) didn't consider any concurrency models other than shared memory threading. The problem is that, for all its limitations, shared-memory threading is the most popular concurrency model on the most popular operating system, so future hardware platforms targeting that system will be optimizing for that case. We can either rail against the sea, or accept it. Hmm, that's an interesting point. Aside from that point I tend to agree with Guido: threading is not the only, nor the best, concurrency model. But maybe these chips designed with threading in mind blow that argument out of the water. I don't know enough to know whether that's true or not... John ___ 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] GIL, Python 3, and MP vs. UP
On Tue, 20 Sep 2005, Brett Cannon wrote: On 9/20/05, John J Lee [EMAIL PROTECTED] wrote: On Mon, 19 Sep 2005, Florian Weimer wrote: The real problem is that you can ditch most extension modules. 8-( [...] *Is* that a showstopper for Python 3.0, though? Who knows. I bet Guido doesn't even know how much breakage he is going to want to push. Some people have rather strongly pointed out (usually after I have proposed something), breaking stuff without a good reason is not worth the added level of breakage for when people try to update code to Python 3.0. Oh, absolutely. Completely changing how garbage collection works is not exactly a minor thing and there is the possibility it won't pan out. It would really suck for everyone to have to learn an entirely new way of handling garbage collection and have there not be a perk for doing so, especially since this kind of change will not be directly visible to the language itself. I didn't intend to refer to garbage collection in particular, but to removing the GIL, thus breaking extension modules (perhaps in a less-drastic way than implied by the copying garbage-collection proposal). John ___ 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
On Wed, 21 Sep 2005, Thomas Lotze wrote:
Barry Warsaw wrote:
x = (if a then
b
elif c then
d
else
e
)
[...]
I guess that's my point. To me, your latter is actually worse than
if a:
x = b
elif c:
x = d
else:
x = e
Can't see a difference as far as readability is concerned. But then,
tastes differ.
[...]
With the former, we have a more C-style syntax where meaning is determined
purely by delimeters rather than by whitespace. Instead of braces '{' and
'}', we have 'then' and 'elif'/'else'. That's a real difference.
The stricter form where you don't allow 'elif' will get used in more
restricted circumstances, so gives less encouragement for widespread abuse
of conditional expressions by people who don't like whitespace-based
syntax.
John
___
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
On Tue, 20 Sep 2005, John J Lee wrote:
[...]
With the former, we have a more C-style syntax where meaning is determined
purely by delimeters rather than by whitespace. Instead of braces '{' and
'}', we have 'then' and 'elif'/'else'. That's a real difference.
[...]
Um, not clear, sorry: the real difference I meant to refer to above is
that between delimiter-based and whitespace-based syntaxes (and not
between braces and differently-spelled delimiters).
John
___
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] os.path.diff(path1, path2)
On Fri, 16 Sep 2005, Greg Ewing wrote: Trent Mick wrote: If this *does* get added (I'm +0) then let's call it relpath or relpathto as in the various implementations out there: +1 on that, too. Preferably just relpath. [...] +1 on adding this function, and on relpath as the name. I wanted this function just a few weeks ago. John ___ 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] GIL, Python 3, and MP vs. UP (was Re: Variant of removing GIL.)
On Fri, 16 Sep 2005, Martin v. Löwis wrote: Sokolov Yura wrote: I think I know how to remove GIL Obviously I am an idiot. Not an idiot, just lazy :-) Please try to implement your ideas, and I predict that you will find: 1. it is a lot of work to implement 2. it requires changes to all C files, in particular to extension modules outside the Python source tree proper. 3. performing the conversion, even in a semi-mechanical way, will introduce many new bugs, in the form of race conditions because of missing locks. Optionally, you may also find that the performance of the interpreter will decrease. [...] Given the points you make, and the facts that both Python 3 and real problems with continuing to scale down semiconductor chip feature sizes are on the horizon, it seems that now would be an excellent time to start work on this, with the goal of introducing it at the same time as Python 3. a. Python 3.0 will break lots of code anyway, so the extension module issue becomes far less significant. b. In x years time (x 10?) it seems likely multiprocessor (MP) users will be in the majority. (As a result, the uniprocessor (UP) slowdown becomes less important in practice, and also Python has the opportunity of avoiding the risk of being sidelined by a real or perceived lack of MP performance.) c. Since time is needed to iron out bugs (and perhaps also to reimplememt some pieces of code from scratch), very early in the life of Python 3 seems like the least-worst time to begin work on such a change. I realize that not all algorithms (nor all computational problems) scale well to MP hardware. Is it feasible to usefully compile both MP and a UP binaries from one Python source code base? (I'm also quite aware that the GIL does not prevent all means of achieving efficient use of multiprocessors. I'm just concious that different parellisation problems are presumably best expressed using different tools, and that Python 3 and increased prevalance of MP systems might tip the balance in favour of removing the GIL.) Of course, it still takes a (anti-)hero to step forward and do the work... John ___ 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] Re: anonymous blocks
On Thu, 28 Apr 2005, Shane Hathaway wrote: [...] I think this concept can be explained clearly. I'd like to try explaining PEP 340 to someone new to Python but not new to programming. [...snip explanation...] Is it understandable so far? Yes, excellent. Speaking as somebody who scanned the PEP and this thread and only half-understood either, that was quite painless to read. Still not sure whether thunks or PEP 340 are better, but I'm at least confused on a higher level now. John ___ 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] Patches for cookielib bugs, for 2.4.1
Hope these can get in before 2.4.1. All include unit tests. http://python.org/sf/1117339 cookielib and cookies with special names http://python.org/sf/1117454 cookielib.LWPCookieJar incorrectly loads value-less cookies http://python.org/sf/1117398 cookielib LWPCookieJar and MozillaCookieJar exceptions John ___ 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] cookielib patch
Anyone like to commit 1028908? Patch was written by module author (me), including an important doc warning re (lack of) thread safety which I mistakenly thought had got into 2.4.0. John ___ 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] Wanted: members for Python Security Response Team
On Thu, 3 Feb 2005, Guido van Rossum wrote: [...] hope at least one person from the release team can be involved, e.g. [...] Guido, from python-announce list: [...] Python 2.3.5 will be released from www.python.org within a few days containing a fix for this issue. Python 2.4.1 will be released later this month containing the same fix. Patches for Python 2.2, 2.3 and 2.4 are also immediately available: [...] Hope this question isn't too dumb: How will Python releases made in response to security bugs be done: will they just include the security fix (rather than being taken from CVS HEAD), without the usual alpha / beta testing cycle? Or what...? John ___ 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] 2.4 news reaches interesting places
On Wed, 8 Dec 2004, Raymond Hettinger wrote: One thing that bugs me: the article says 3 or 4 times that Python is slow, each time with a refutation (but it's so flexible, but it's fast enough) but still, they sure seem to harp on the point. This is a PR issue that Python needs to fight -- any ideas? [...] * Have python.org prominently feature an article of Python's use in high-performance environments. IIRC, somebody wrote a realtime voice over internet system and found that with good design, there was no speed issue. Also, the cellphone apps may make a good example. [...] IIRC, Alex Martelli mentioned a video application at last year's ACCU / Python UK conference. He said the system never went into production, but it sounded like a good meme from the speed point of view: it triggered surprised and gleeful noises from the mixed Python / C++ / Java audience ;-). John ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.4 news reaches interesting places
On Wed, 8 Dec 2004, Phillip J. Eby wrote: At 02:18 PM 12/8/04 -0800, Guido van Rossum wrote: I was pleasantly surprised to find a pointer to this article in a news digest that the ACM emails me regularly (ACM TechNews). http://gcn.com/vol1_no1/daily-updates/28026-1.html One thing that bugs me: the article says 3 or 4 times that Python is slow, each time with a refutation (but it's so flexible, but it's fast enough) but still, they sure seem to harp on the point. This is a PR issue that Python needs to fight -- any ideas? The only thing that will fix the PR issue is to have a Python compiler distributed as part of the language. It doesn't matter if it doesn't I suspect you're correct, but the suggestion elsewhere to bundle py2exe seems likely to be counterproductive to me: merely emphasizing the interpreterness of Python the moment the idea spreads that Python-built .exe's are so big because they're just an interpreter plus a script. I'm sure PyPy, if successful, will be a big win on both PR and technical fronts. On a seperate PR issue, I use the word 'script' above advisedly: At work, I've noticed technical employees of clients who use Java often seem to take some satisfaction in referring to our web applications (which of course, consist of who knows how many packages, modules and classes) as CGI scripts. We do use CGI, but the CGI scripts themselves are always about five lines long and just contain boilerplate code and configuration to kick off our framework. You can see them imagining a great long script named doeverything.cgi... John ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
