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] 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 "", 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] 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] 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] 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 Sun, 30 Jul 2006, Greg Ward wrote: [...] > Did you look at the crude attempt at testing for this bug that I hacked > into test_httplib.py? I posted it to bug #1486335 here: > > > http://sourceforge.net/tracker/download.php?group_id=5470&atid=105470&file_id=186245&aid=1486335 > > The idea is simple: put various chunked responses into strings and then > feed those strings to HTTPConnection. The trouble is that StringIO does > not behave the same as a real socket: where HTTPResponse fails one way > reading from a real socket (eg. infinite loop), it fails differently (or > not at all) reading from a StringIO. Makes testing with the FakeSocket > class in test_httplib.py problematic. There are always ways around unit testing problems, but... > Maybe the right way to test httplib is to spawn a server process > (thread?) to listen on some random port, feed various HTTP responses at > HTTPConnection/HTTPResponse, and see what happens. I'm not sure how to > do that portably, though. Well, I'll see if I can whip up a Unix-y > solution and see if anyone knows how to make it portable. I think adding this kind of functional test is extremely valuable, given that we don't seem to have any for httplib at present (Lib/test/test_httplib.py does not send any network packets). Maybe you could add a basic smoke test that does a simple successful GET, while you're going about adding your chunked encoding regression test(s)? Oh, wait: there is a functional test that uses the network, but it's at the end of httplib.py rather than being part of the test suite, and it follows the "Guru Watches Output" pattern :-) I tried to add a test for urllib2 recently that relied on a python.org URL being set up, but the python.org guys are pretty overworked already and haven't had time to enable that yet -- so I think that simply from that point of view your run-your-own-server approach is better. Why does it need to be unix-y, though? We have SimpleHTTPServer. We're not trying to test the OS, so I don't see a problem with using loopback and a single process -- and that would keep test run times down. Um, except that MS OSes seem a bit odd re the loopback interface -- ISTR that, at least back with NT4, you just didn't get a loopback i/face unless you had an ethernet driver installed (back then, I was on dialup). More unit tests would also be valuable, of course. 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
[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] 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
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" 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
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"
>> 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] 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] 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] BUG (urllib2) Authentication request header is broken on long usernames and passwords
On Mon, 9 Oct 2006, Scott Dial wrote:
[...]
> In retrospect, perhaps "{de|en}codestring" was a poor name choice.
> urllib2 should be calling b64encode directly.
>
> I have submitted a patch to the tracker: [ 1574068 ] urllib2 - Fix line
> breaks in authorization headers.
urllib should also be fixed in the same way (assuming your fix is
correct), since urllib also uses base64.{de,en}codestring().
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 "lazy strings" patch
On Sat, 21 Oct 2006, Mark Roberts wrote: [...] > If there's a widely recognized argument against this, a link will likely > sate my curiosity. Quoting from Martin v. Loewis earlier on the same day you posted: """ I think this specific approach will find strong resistance. It has been implemented many times, e.g. (apparently) in NextStep's NSString, and in Java's string type (where a string holds a reference to a character array, a start index, and an end index). Most recently, it was discussed under the name "string view" on the Py3k list, see http://mail.python.org/pipermail/python-3000/2006-August/003282.html Traditionally, the biggest objection is that even small strings may consume insane amounts of memory. """ 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] httplib &c. timeouts and global state
http://python.org/sf/2451 """ The new timeout support in 2.6 makes use of new function socket.create_connection(). socket.create_connection() provides no way to disable timeouts, other than by relying on socket.getdefaulttimeout() returning None. This is unfortunate, because it was the purpose of the new timeout support to allow control of timeouts without reliance on global state. setdefaultsocket.create_connection() should always call sock.settimeout() with the timeout passed to create_connection(), unless a special non-None value is passed indicating that the global default is to be used. Specific modules may then use that special non-None value where required, to preserve backwards-compatibility. """ Facundo doesn't seem to agree. If I understand him correctly, he objects to the use of a special value other than None as an argument value. I think avoiding this minor complication is secondary to avoiding gratuitously imposing global state on users where it's not needed. Much existing code uses .setdefaulttimeout(), because legacy code does not expose the socket timeout. Of course, not all of that code can be changed immediately (otherwise, why did we wait so long before Facundo did his valuable work on this?). Of course, very often, code that calls socket.setdefaulttimeout(some_non_none_value) wants a default timeout for everything. But that isn't *always* the case, and standard library modules that expose the timeout feature should not make that assumption. For example, an application might only want to set a timeout for some non-essential network operation. As another example, useful but poorly-written library code might call .setdefaulttimeout(). Also, ISTM there's a big difference between nobody having contributed the time to implement the feature on the one hand, and deliberately imposing the global socket timeout state on users on the other! Facundo indicates in the tracker discussion for 2451 that a decision was made here about this, but doesn't recall exactly which post, and directed me here. What I found in the archive is this thread (sorry for the non-python.org URL): http://www.gossamer-threads.com/lists/python/dev/555039?do=post_view_threaded#555039 In that discussion, this issue is raised, but I don't see any resolution that answers the objection made in issue 2451. Anyway, apologies in advance if there was a decision here that takes account of the above objection. I do want to thank Facundo for adding the timeout support to modules such as httplib. But I also want to loudly complain about this 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] 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
[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] 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
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] 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
[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
[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
Re: [Python-Dev] python-dev Summary for 2005-02-01 through 2005-02-14 [draft]
On Fri, 4 Mar 2005, Aahz wrote: > Both entries so far look very good. Perhaps writing python-dev summaries > could be a rotating position? Or even a joint effort? It's up to the contributors, of course: just a thought... 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: __except__ use cases
On Sun, 24 Apr 2005, Nick Coghlan wrote:
[...]
> Seeing this example has convinced me of something. PEP 310 should use the
> 'with'
> keyword, and 'expression block' syntax should be used to denote the 'default
> object' semantics proposed for Python 3K. For example:
>
> class Key2AttributeError(object):
> def __init__(self, obj, attr):
> self:
> .obj_type = type(obj)
> .attr = attr
> def __except__(self, ex_type, ex_val, ex_tb):
> if isinstance(ex_type, KeyError):
> self:
> raise AttributeError("%s instance has no attribute %s"
> % (.obj_type, .attr))
>
> > # Somewhere else. . .
> def __getattr__(self, name):
> with Key2AttributeError(self, key):
> self:
> return ._cache[key]
[...]
+1
Purely based on my aesthetic reaction, that is. Never having used other
languages with this 'attribute lookup shorthand' feature, that seems to
align *much* more with what I expect than the other way around. If 'with'
is used in other languages as the keyword for attribute lookup shorthand,
though, perhaps it will confuse other people, or at least make them frown
:-(
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
Re: [Python-Dev] defaultdict proposal round three
On Tue, 21 Feb 2006, Guido van Rossum wrote: [...] > If you're only interested in classifying the three specific built-ins > you mention, I'd check for the presense of certain attributes: > hasattr(x, "lower") -> x is a string of some kind; hasattr(x, "sort") > -> x is a list; hasattr(x, "update") -> x is a dict. Also, hasattr(x, > "union") -> x is a set; hasattr(x, "readline") -> x is a file. dict and set instances both have an .update() method. I guess "keys" or "items" is a better choice for testing dict-ness, if using "LBYL" at all. (anybody new to "LBYL" can google for that and EAFP -- latter does not stand for European Assoc. of Fish Pathologists in this context, though ;-) > That's duck typing! >>> hasattr(python, "quack") True 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 as|with . 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
[Python-Dev] Py3K timescale and stdlib philosophy (was: Re: Py3K thought: use...)
On Fri, 17 Mar 2006, Brett Cannon wrote: > On 3/17/06, A.M. Kuchling <[EMAIL PROTECTED]> wrote: >> Thought: We should drop all of httplib, urllib, urllib2, and ftplib, >> and instead adopt some third-party library for HTTP/FTP/whatever, >> write a Python wrapper, and use it instead. (The only such library I [...] > But maybe this also poses a larger question of where for Py3K we want > to take the stdlib. Ignoring its needed cleanup and nesting of the > namespace, do we want to try to use more external tools by importing > them and writing a Pythonic wrapper? Or do we want to not do that and > try to keep more things under our control and go with the status quo? > Or do we want to really prune down the stdlib and use more dynamic > downloading ala Cheeseshop and setuptools? [...] Do we have any idea yet what sort of timescale we're talking about for Python 3.0 (or should I call it Py3K still)? I have a personal interest in these particular modules, but the questions that seem to need answering first are more general ones about the stdlib post-3.0. Brett asks some good questions. ISTM that another important question must be: What do each of the small set of people like yourself (Brett), Andrew, Martin, Georg, Raymond (etc.!) who bear most of the burden of maintaining the stdlib at present, intend to do after Python 3.0 is out? I assume that it would only be useful to drop parts of the stdlib in this way if that group of people were then to stop working on them. That makes sense, but I don't want to make assumptions about what each of the group of people referred to above intend to do post-3.0: a. Drop 2.x right away to concentrate on developing and maintaining the 3.0 stdlib (and/or the 3.0 interpreter)? b. Spend at least some effort maintaining 2.x for a few years? c. Carry on maintaining 2.x for a few years? d. Ignore 3.x and continue with 2.x indefinitely? e. Watch and see how the Python community at large responds to 3.0? f. Wait and see what you feel like doing at the time? g. Some combination of the above? h. Quit Python to take up pig farming? These sorts of questions are often quite hard to answer, I understand, because many people often want to see what everybody else will do before making up their minds. But I guess people who post here frequently are less likely to do that than are the rest of us sheep ;-) [BTW, I assume much of the stdlib will remain essentially the same (if not without backwards-incompatibilities), one hopes people will step in to backport 3.0 fixes (and perhaps forward-port: I make no judgement about which of 2.x and 3.x will have the larger user community in the short or long term). People will presumably be more motivated to do that than currently, since I assume many people will not port all (or any) of their code to 3.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] 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] 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] 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] [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
On Thu, 13 Apr 2006, "Martin v. Löwis" wrote: Tim Peters wrote: I'm not the one to decide, but at some time the traceback module should be rewritten to match the interpreter behavior. No argument from me about that. I also think the traceback module should be corrected, and the test cases updated, despite the objections that it may break other people's doctest test cases. 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? 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] [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. [...] > """ 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
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 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] 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] 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
[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
[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
Re: [Python-Dev] [Python-checkins] This
On Sat, 27 May 2006, "Martin v. Löwis" wrote: [...] Just end user experience's two cents here (btw, this line is correct at English level?) [...] Wouldn't it be still be conventional to have an article somewhere? e.g. " Just /some/ end user's two cents here" Yes, but "one" (or maybe "an") rather than "some". (also, isn't "two cents" and "experience" roughly the same thing, so that one is redundant?) There's no such thing as a synonym of course, but it does sound funny, yes. 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] dictionary order
On Sun, 28 May 2006, Armin Rigo wrote:
[...]
> Now I'm stumbling upon this test for urllib2:
>
>>>> mgr = urllib2.HTTPPasswordMgr()
>>>> add = mgr.add_password
>>>> add("Some Realm", "http://example.com/";, "joe", "password")
>>>> add("Some Realm", "http://example.com/ni";, "ni", "ni")
>(...)
>
>Currently, we use the highest-level path where more than one
>match:
>
>>>> mgr.find_user_password("Some Realm", "http://example.com/ni";)
>('joe', 'password')
>
> Returning the outermost path is a bit strange, if you ask me, but I am
> no expert here. Stranger is the fact that the actual implement actually
> returns, not the outermost path at all -- there is no code to do that --
> but a random pick, the first match in dictionary order. The comment in
> the test is just misleading. I believe that urllib2 should be fixed to
> always return the *innermost* path, but I need confirmation about
> this...
I noticed the same things, and in fact I think this was fixed before you
posted :-)
FWIW, here are the details:
The checkin was from Georg as -r 46509, patch was
http://python.org/sf/1496206
Part of the comment on the patch:
"""
The patch also comments out one test which was testing
something not actually guaranteed by the code at all --
it was passing by fluke. The code it's trying to test
could do with some review, which is why I left this
test commented out rather than deleting the test (but
that is a long-standing issue unrelated to this patch,
so should not block this patch from being applied).
"""
Recently I have been slowly working my way through urllib2 auth, fixing
bugs and adding tests as I go. This particular issue is horribly unclear
in the RFC, though, and I haven't yet got round to the necessary checking
of real-world behaviour.
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 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
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
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] 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] 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. [...] > > 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] 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] 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] urlparse brokenness
On Tue, 22 Nov 2005, Paul Jimenez wrote: > It is my assertion that urlparse is currently broken. Specifically, I > think that urlparse breaks an abstraction boundary with ill effect. [...] I have some comments, but I can't see a patch on SF. Did you post 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] 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
[Python-Dev] Patch reviews & request for patch review
Hi I attended the bug day on Sunday and reviewed six bugs/patches (1212287, 1215184, 1115886, 1372650, 1216942, 878275). So, I'm hoping one of those nice people who offered 'review 5 get 1 free' might look at a patch of mine. Test, documentation, and explanatory comments in the tracker are all there: http://python.org/sf/1157027 "cookielib mis-handles RFC 2109 cookies in Netscape mode" (It's an old SF patch tracker ID, but I have uploaded a new patch for Python 2.5 since the old patch was not applied in 2.4.1 / 2.4.2.) There's another patch I uploaded whose resolution was agreed upon back in March, but the simple patch (including added test) never got applied: http://python.org/sf/1117398 "cookielib LWPCookieJar and MozillaCookieJar exceptions" Thanks in advance to anybody who has time to look at these, 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] 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] 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] The path module PEP
[Ian Bicking] >Losing .open() would make it much harder for anyone wanting to write, >say, a URI library that implements the Path API. [John] > Why? Could you expand a bit? > > What's wrong with urlopen(filesystem_path_instance) ? [Ian] >def read_config(path): >text = path.open().read() >... do something ... I should have expected that answer, but couldn't believe that you think it's a good idea to implement that obese filesystem path API for URLs ;-) Shouldn't we instead have: a) .open()-able objects blessed in the stdlib & stdlib docs, as a separate interface from the path interface (I guess that would be an argument in favour of path implementing that one-method interface, as long as it's not tied too tightly to the fat path interface) b) a path object with a thinner interface (I know you've already expressed that preference yourself...)? 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.
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.
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 ). 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] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
On Thu, 26 Jan 2006, Thomas Heller wrote: [...] > As I said in the other thread (where the discussion should probably be > continued anyway): > > http://mail.python.org/pipermail/python-dev/2006-January/060113.html > > 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. 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] 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 "", line 1, in ?
TypeError: set expected at most 1 arguments, got 3
>>> set(1)
Traceback (most recent call last):
File "", 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
