[ python-Feature Requests-1618676 ] Promote list comprehensions to Language Integrated Query?
Feature Requests item #1618676, was opened at 2006-12-19 12:08
Message generated for change (Comment added) made by jettlogic
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1618676&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: JettLogic (jettlogic)
Assigned to: Nobody/Anonymous (nobody)
Summary: Promote list comprehensions to Language Integrated Query?
Initial Comment:
Hi,
A feature idea (shall put to mailing list discussion sometime), is to extend
list comprehensions to many uses of SQL or XQuery unnecessary.
The benefit of language integration over passing SQL/XQuery strings to external
libraries would be making code agnostic to the source of the data: in-memory
tables and trees could be queried just like a relational DB or XML. An "order
by" could be more efficient than sorted(f(x) for x in y).
Of course list comprehensions do much of the C#-style LINQ already, but they
can't (easily) do joins or "select x from a, y from b" type queries, or return
XML a la XQuery.
On the library side, DBAPI helps make code independent of any particular
database, and sqlite in 2.5 means in-memory tables (lists of tuples) aren't
really necessary.
If worthwhile, implementation would probably be best suited to PyPy.
C# Example from http://en.wikipedia.org/wiki/Language_Integrated_Query
var q = from o in db.Orders, c in db.Customers
where o.Quality == "200" && (o.CustomerID == c.CustomerID)
select new { o.DueDate, c.CompanyName, c.ItemID, c.ItemName };
--
>Comment By: JettLogic (jettlogic)
Date: 2006-12-22 12:25
Message:
Logged In: YES
user_id=1345991
Originator: YES
Oh ok, I guess it's up to the Py3k discussions then to figure out LINQ.
Funny my search for "Python Language Integrated Query" didn't turn up much
(at least not the Py3k list) and now my OP is #1 on Google on 2006/12/22
for the search. Though "Python LINQ" turns up:
http://sayspy.blogspot.com/2006/02/why-python-doesnt-need-something-like.html
I suppose there's still the efficiency of having the database doing the
filter (instead of "if x > 5") and the grouping (instead of
itertools.groupby()), and the joins.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-12-22 07:59
Message:
Logged In: YES
user_id=341410
Originator: NO
There have been various discussions about metasyntax proposals and Python,
see the Python-3000 mailing list for references to LINQ. The general
answer has been "no". Note that you can do much of what you want by
overloading operations on standard Python objects like __or__, __and__,
etc.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1618676&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-411881 ] Use of "except:" in logging module
Bugs item #411881, was opened at 2001-03-28 06:58 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 2 Private: No Submitted By: Itamar Shtull-Trauring (itamar) Assigned to: Vinay Sajip (vsajip) Summary: Use of "except:" in logging module Initial Comment: A large amount of modules in the standard library use "except:" instead of specifying the exceptions to be caught. In some cases this may be correct, but I think in most cases this not true and this may cause problems. Here's the list of modules, which I got by doing: grep "except:" *.py | cut -f 1 -d " " | sort | uniq Bastion.py CGIHTTPServer.py Cookie.py SocketServer.py anydbm.py asyncore.py bdb.py cgi.py chunk.py cmd.py code.py compileall.py doctest.py fileinput.py formatter.py getpass.py htmllib.py imaplib.py inspect.py locale.py locale.py mailcap.py mhlib.py mimetools.py mimify.py os.py pdb.py popen2.py posixfile.py pre.py pstats.py pty.py pyclbr.py pydoc.py repr.py rexec.py rfc822.py shelve.py shutil.py tempfile.py threading.py traceback.py types.py unittest.py urllib.py zipfile.py -- >Comment By: Skip Montanaro (montanaro) Date: 2006-12-22 06:52 Message: Logged In: YES user_id=44345 Originator: NO Vinay, In LogRecord.__init__ what exceptions do you expect to catch? Looking at the code for basename and splitext in os.py it's pretty hard to see how they would raise an exception unless they were passed something besides string or unicode objects. I think all you are doing here is masking programmer error. In StreamHandler.emit what might you get besides ValueError (if self.stream is closed)? I don't have time to go through each of the cases, but in general, it seems like the set of possible exceptions that could be raised at any given point in the code is generally pretty small. You should catch those exceptions and let the other stuff go. They are generally going to be programmer's errors and shouldn't be silently squashed. Skip -- Comment By: Vinay Sajip (vsajip) Date: 2006-12-22 01:42 Message: Logged In: YES user_id=308438 Originator: NO The reason for the fair number of bare excepts in logging is this: in many cases (e.g. long-running processes like Zope servers) users don't want their application to change behaviour just because of some exception thrown in logging. So, logging aims to be very quiet indeed and swallows exceptions, except SystemExit and KeyboardInterrupt in certain situations. Also, logging is one of the modules which is (meant to be) 1.5.2 compatible, and string exceptions are not that uncommon in older code. I've looked at bare excepts in logging and here's my summary on them: logging/__init__.py: currentframe(): Backward compatibility only, sys._getframe is used where available so currentframe() will only be called on rare occasions. LogRecord.__init__(): There's a try/bare except around calls to os.path.basename() and os.path.splitext(). I could add a raise clause for SystemExit/KeyboardInterrupt. StreamHandler.emit(): Reraises SystemExit and KeyboardInterrupt, and otherwise calls handleError() which raises everything if raiseExceptions is set (the default). shutdown(): Normally only called at system exit, and will re-raise everything if raiseExceptions is set (the default). logging/handlers.py: BaseRotatingHandler.emit(): Reraises SystemExit and KeyboardInterrupt, and otherwise calls handleError() which raises everything if raiseExceptions is set (the default). SocketHandler.createSocket(): I could add a raise clause for SystemExit/KeyboardInterrupt. SocketHandler.emit(): Reraises SystemExit and KeyboardInterrupt, and otherwise calls handleError() which raises everything if raiseExceptions is set (the default). SysLogHandler.emit(): Reraises SystemExit and KeyboardInterrupt, and otherwise calls handleError() which raises everything if raiseExceptions is set (the default). SMTPHandler.emit(): Should change bare except to ImportError for the formatdate import. Elsewhere, reraises SystemExit and KeyboardInterrupt, and otherwise calls handleError() which raises everything if raiseExceptions is set (the default). NTEventLogHandler.emit(): Reraises SystemExit and KeyboardInterrupt, and otherwise calls handleError() which raises everything if raiseExceptions is set (the default). HTTPHandler.emit(): Reraises SystemExit and KeyboardInterrupt, and otherwise calls handleError() which raises everything if raiseExceptions is set (the default). logging/config.py:
[ python-Bugs-583975 ] gethostbyaddr lag
Bugs item #583975, was opened at 2002-07-19 14:41
Message generated for change (Comment added) made by akuchling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=583975&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jason R. Mastaler (jasonrm)
Assigned to: Nobody/Anonymous (nobody)
Summary: gethostbyaddr lag
Initial Comment:
For more info, also see
http://mail.python.org/pipermail/python-list/2002-July/113706.html
Perl's gethostbyaddr doesn't seem to have this problem
as shown
below. Should I report this in the bug tracker?
$ time perl -MSocket -lwe 'print +(gethostbyaddr
inet_aton("datavortex.net"), AF_INET)[0]'
datavortex.net
real0m0.063s
user0m0.050s
sys 0m0.010s
$ time python2 -c 'from socket import * ; print
gethostbyaddr("datavortex.net")[0]'
datavortex.net
real0m20.176s
user0m0.070s
sys 0m0.020s
--
>Comment By: A.M. Kuchling (akuchling)
Date: 2006-12-22 08:11
Message:
Logged In: YES
user_id=11375
Originator: NO
Was the cause of this bug ever diagnosed? Should this report remain open,
or be closed?
--
Comment By: Jason R. Mastaler (jasonrm)
Date: 2003-07-24 23:03
Message:
Logged In: YES
user_id=85984
This problem has cropped up again for another
TMDA user, so we still have this bug in Python.
In short, just as with the previous report, this
user sees a 20 second delay with
socket.gethostbyaddr() on a hostname which
all other tools (nslookup, host, mail progs, etc)
look up instantaneously.
In other words, Python is the only app on his
system with this problem. I had him try
Python 2.3c1 to no avail.
As with the previous user, he is running Linux
(Redhat):
Linux sparge 2.4.20-18.7 #1 Thu May 29 06:51:53 EDT 2003
i686 unknown
glibc-2.2.5-43
Any other information I should provide or any
diagnostics I can have the user run?
--
Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-11-02 23:40
Message:
Logged In: YES
user_id=85984
The problem was under Python 2.2.
Though now the user reports that he can no longer
reproduce the problem, despite not having done any
Python upgrades or system configuration changes.
We might just have to chuck this one up to
FM (Funny Magic).
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2002-11-02 16:14
Message:
Logged In: YES
user_id=33168
Jason, still with us? What version of python were you
having the problem with? 2.1.x? 2.2.x? Do you have the
problem with 2.2? Have you looked at patch #604210
(http://python.org/604210)? Can you test that?
--
Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-09-06 20:20
Message:
Logged In: YES
user_id=85984
Still having the problem, but I'm unsure how to
proceed.
nslookup and host both return instantly when querying
datavortex.net.
Only Python seems to exhibit this problem, but it
still could be a system misconfiguration. This is the
only time I've ever seen/heard of this behavior.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2002-09-06 18:23
Message:
Logged In: YES
user_id=33168
Jason, are you still having this problem? Do you have
anything to report?
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2002-07-22 18:37
Message:
Logged In: YES
user_id=33168
Looking at the output, the problem is definitely in
gethostbyaddr_r().
This is what python calls from Modules/socketmodule.c
socket_gethostbyaddr().
Notice: the first attempt to send to the first DNS server
"207.69.188.185" looks like it fails after 5 seconds. DNS
#2 is attempted "207.69.188.186", this send also takes 5
seconds, back to #1 ...
The poll is being done in gethostbyaddr_r() (ie, libc). If
you want to break in a debugger, gethost...() should be
around line 2216 in python 2.2. You can also put prints in.
As for why perl doesn't have the same problem, it could be
that perl doesn't use the same library call
(gethostbyaddr_r), or attempts to read from /etc/hosts
before contacting the DNS server. I'm just guessing. In
order to debug this further, you will probably need the
python sources. What happens if you do host datavortex.net
(you could also try nslookup)? Does that return immediately
or wait?
--
Comment By: Data Vortex (datavortex)
Date: 2002-07-22 15:15
Message:
Lo
[ python-Bugs-737202 ] CGIHTTPServer does not handle scripts in sub-dirs
Bugs item #737202, was opened at 2003-05-13 13:54
Message generated for change (Comment added) made by akuchling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737202&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Hartmut Goebel (htgoebel)
Assigned to: Nobody/Anonymous (nobody)
Summary: CGIHTTPServer does not handle scripts in sub-dirs
Initial Comment:
CGIHTTPServer does not handle scripts in sub directoreis correctly:
When accessing eg. '/cgi-bin/scripts/bla', CGIHTTPServer returns
404 CGI script is not a plain file ('/cgi-bin/script')
This tracked down to CGIHTTPRequestHandler.run_cgi() containing
these lines:
i = rest.find('/')
if i >= 0:
script, rest = rest[:i], rest[i:]
else:
script, rest = rest, ''
scriptname = dir + '/' + script
This will move the dir-part of the 'rest' into 'script', but leave the
actual filename in 'rest'. The 'scriptname' thus does miss the filename.
I assume this should become simply:
script, rest = rest, ''
scriptname = dir + '/' + script
--
>Comment By: A.M. Kuchling (akuchling)
Date: 2006-12-22 08:15
Message:
Logged In: YES
user_id=11375
Originator: NO
Attaching Titus' patch.
File Added: python-bug737202-patch.diff
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-05-30 14:51
Message:
Logged In: YES
user_id=752496
The example shows the problem in Py2.4.1.
--
Comment By: Titus Brown (titus)
Date: 2005-01-17 00:31
Message:
Logged In: YES
user_id=23486
Verified proper behavior does not work in 2.2, 2.3, 2.4, or current CVS.
The attached patches are just a filename; you should try downloading
them to be sure they're actually a patch ;).
A simpe self-contained example is at
http://issola.caltech.edu/~t/transfer/python-bug737202-example.tgz
it works under Python 2.2 or greater & demonstrates the problem.
A patch for the current CVS HEAD is at
http://issola.caltech.edu/~t/transfer/python-bug737202-patch.diff
and 2.4 should probably be back-patched as well.
--
Comment By: Hartmut Goebel (htgoebel)
Date: 2005-01-16 10:11
Message:
Logged In: YES
user_id=376953
Encloded please find a testcase.
I've checkt it with 2.3.3.
Buf should still persist in 2.3.4 and 2.4. I've checked the
CVS diffs and there is no change which would solve it.
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 13:42
Message:
Logged In: YES
user_id=752496
Both bugs are for the same problem, keeping this alive
(because it has the patch), closing the other as Duplicate.
Regarding the patch, the actual code has something very
similar to it, so maybe the bug is already fixed...
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 13:42
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
Comment By: Titus Brown (titus)
Date: 2004-12-19 01:20
Message:
Logged In: YES
user_id=23486
same as bug 778804, assigned to esr.
--
Comment By: Hartmut Goebel (htgoebel)
Date: 2003-05-23 09:21
Message:
Logged In: YES
user_id=376953
I rethought this: The reason for this type of split is to make it possible
to
pass parameters as part of the URL, like Zope does.
So the snippet above should be changed to something like this:
i = 0
while 1:
# get the next path-element out of the url
i = rest.find('/', i)
if i >= 0:
script, rest = rest[:i], rest[i:]
else:
script, rest = rest, ''
scriptname = dir + '/' + script
scriptfile = self.translatepath(scriptname)
if os.isdir(scriptname):
# if scriptname is a directory, continue "walking" the
url
continue
# scriptname is not a directory, stop "walking" the url
break
Patch is included.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detai
[ python-Bugs-737202 ] CGIHTTPServer does not handle scripts in sub-dirs
Bugs item #737202, was opened at 2003-05-13 13:54
Message generated for change (Comment added) made by akuchling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737202&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
>Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Hartmut Goebel (htgoebel)
>Assigned to: A.M. Kuchling (akuchling)
Summary: CGIHTTPServer does not handle scripts in sub-dirs
Initial Comment:
CGIHTTPServer does not handle scripts in sub directoreis correctly:
When accessing eg. '/cgi-bin/scripts/bla', CGIHTTPServer returns
404 CGI script is not a plain file ('/cgi-bin/script')
This tracked down to CGIHTTPRequestHandler.run_cgi() containing
these lines:
i = rest.find('/')
if i >= 0:
script, rest = rest[:i], rest[i:]
else:
script, rest = rest, ''
scriptname = dir + '/' + script
This will move the dir-part of the 'rest' into 'script', but leave the
actual filename in 'rest'. The 'scriptname' thus does miss the filename.
I assume this should become simply:
script, rest = rest, ''
scriptname = dir + '/' + script
--
>Comment By: A.M. Kuchling (akuchling)
Date: 2006-12-22 08:28
Message:
Logged In: YES
user_id=11375
Originator: NO
Fix seems correct; applied to trunk in rev. 53139 and to 25-maint in rev.
53140.
--
Comment By: A.M. Kuchling (akuchling)
Date: 2006-12-22 08:15
Message:
Logged In: YES
user_id=11375
Originator: NO
Attaching Titus' patch.
File Added: python-bug737202-patch.diff
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-05-30 14:51
Message:
Logged In: YES
user_id=752496
The example shows the problem in Py2.4.1.
--
Comment By: Titus Brown (titus)
Date: 2005-01-17 00:31
Message:
Logged In: YES
user_id=23486
Verified proper behavior does not work in 2.2, 2.3, 2.4, or current CVS.
The attached patches are just a filename; you should try downloading
them to be sure they're actually a patch ;).
A simpe self-contained example is at
http://issola.caltech.edu/~t/transfer/python-bug737202-example.tgz
it works under Python 2.2 or greater & demonstrates the problem.
A patch for the current CVS HEAD is at
http://issola.caltech.edu/~t/transfer/python-bug737202-patch.diff
and 2.4 should probably be back-patched as well.
--
Comment By: Hartmut Goebel (htgoebel)
Date: 2005-01-16 10:11
Message:
Logged In: YES
user_id=376953
Encloded please find a testcase.
I've checkt it with 2.3.3.
Buf should still persist in 2.3.4 and 2.4. I've checked the
CVS diffs and there is no change which would solve it.
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 13:42
Message:
Logged In: YES
user_id=752496
Both bugs are for the same problem, keeping this alive
(because it has the patch), closing the other as Duplicate.
Regarding the patch, the actual code has something very
similar to it, so maybe the bug is already fixed...
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 13:42
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
Comment By: Titus Brown (titus)
Date: 2004-12-19 01:20
Message:
Logged In: YES
user_id=23486
same as bug 778804, assigned to esr.
--
Comment By: Hartmut Goebel (htgoebel)
Date: 2003-05-23 09:21
Message:
Logged In: YES
user_id=376953
I rethought this: The reason for this type of split is to make it possible
to
pass parameters as part of the URL, like Zope does.
So the snippet above should be changed to something like this:
i = 0
while 1:
# get the next path-element out of the url
i = rest.find('/', i)
if i >= 0:
script, rest = rest[:i], rest[i:]
else:
script, rest = rest, ''
scriptname = dir + '/' + script
scriptfile = self.translatepath(scriptname)
if os.isdir(scriptname):
# if scriptname is a directory, continu
[ python-Bugs-776202 ] MacOS9: test_uu fails
Bugs item #776202, was opened at 2003-07-23 08:02 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776202&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: None Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: MacOS9: test_uu fails Initial Comment: test_uu fails on MacPython-OS9: AssertionError: 'The smooth-scaled python crept over the sleeping dog\r' != 'The smooth-scaled python crept over the sleeping dog\n' Presumably it mixes binary and text I/O. -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 08:33 Message: Logged In: YES user_id=11375 Originator: NO Should the suggested patch be applied, simply for the sake of consistency in test_uu? It's probably difficult to replicate this bug now; does Jack even have a MacOS 9 installation any more? -- Comment By: Walter Dörwald (doerwalter) Date: 2003-08-04 09:33 Message: Logged In: YES user_id=89016 Can you try the following patch (diff.txt)? The patch changes all open() statements to use text mode. I've tested the patch on Windows and Linux. I don't know why the old test mixed text and binary mode. The test should have failed even before the port to PyUnit. -- Comment By: Jack Jansen (jackjansen) Date: 2003-08-04 07:41 Message: Logged In: YES user_id=45365 It's in test_decode. The log is attached. -- Comment By: Walter Dörwald (doerwalter) Date: 2003-08-04 07:21 Message: Logged In: YES user_id=89016 It would help to see a complete traceback (Is the error in test_encode or test_decode?) -- Comment By: Jack Jansen (jackjansen) Date: 2003-07-31 15:50 Message: Logged In: YES user_id=45365 I changed the open call to use 'rU' in stead of 'r' (test_uu rev. 1.6.6.1). I get the distinct impression that this isn't the right fix, though, but that the real problem is elsewhere (mixing up text and binary I/O), so I'd like a second opinion. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776202&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-802128 ] Mode argument of dumbdbm does not work
Bugs item #802128, was opened at 2003-09-07 16:46 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=802128&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin v. Löwis (loewis) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Mode argument of dumbdbm does not work Initial Comment: In dumbdbm.py 2.15, support for a mode argument was added. However, this support does not work: The mode argument is passed to __builtin__.open, which does not support specification of a mode. Instead, the third argument to that function specifies the buffer size. -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 08:44 Message: Logged In: YES user_id=11375 Originator: NO Fred, do you still have the patch you mention? I've worked up a patch, but it must be simpler; I don't do anything with the umask. -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-09-12 02:18 Message: Logged In: YES user_id=3066 I have what I think is a correct patch, but I should be able to simplify it (related to handling the umask). Untested on Windows. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=802128&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-802128 ] Mode argument of dumbdbm does not work
Bugs item #802128, was opened at 2003-09-07 16:46 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=802128&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin v. Löwis (loewis) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Mode argument of dumbdbm does not work Initial Comment: In dumbdbm.py 2.15, support for a mode argument was added. However, this support does not work: The mode argument is passed to __builtin__.open, which does not support specification of a mode. Instead, the third argument to that function specifies the buffer size. -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 08:50 Message: Logged In: YES user_id=11375 Originator: NO Attaching my patch. File Added: dumbdbm.patch -- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 08:44 Message: Logged In: YES user_id=11375 Originator: NO Fred, do you still have the patch you mention? I've worked up a patch, but it must be simpler; I don't do anything with the umask. -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-09-12 02:18 Message: Logged In: YES user_id=3066 I have what I think is a correct patch, but I should be able to simplify it (related to handling the umask). Untested on Windows. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=802128&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-802128 ] Mode argument of dumbdbm does not work
Bugs item #802128, was opened at 2003-09-07 16:46 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=802128&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin v. Löwis (loewis) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Mode argument of dumbdbm does not work Initial Comment: In dumbdbm.py 2.15, support for a mode argument was added. However, this support does not work: The mode argument is passed to __builtin__.open, which does not support specification of a mode. Instead, the third argument to that function specifies the buffer size. -- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-12-22 08:54 Message: Logged In: YES user_id=3066 Originator: NO Sorry, my patch is long gone. :-( -- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 08:50 Message: Logged In: YES user_id=11375 Originator: NO Attaching my patch. File Added: dumbdbm.patch -- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 08:44 Message: Logged In: YES user_id=11375 Originator: NO Fred, do you still have the patch you mention? I've worked up a patch, but it must be simpler; I don't do anything with the umask. -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-09-12 02:18 Message: Logged In: YES user_id=3066 I have what I think is a correct patch, but I should be able to simplify it (related to handling the umask). Untested on Windows. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=802128&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1559142 ] some section links (previous, up, next) missing last word
Bugs item #1559142, was opened at 2006-09-15 04:17 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559142&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tim Smith (thimsmith) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: some section links (previous, up, next) missing last word Initial Comment: The Previous, Up and Next links in the Library Reference are often missing the last word. Examples: http://www.python.org/doc/current/lib/module-operator.html """Previous: 3.9 UserString Up: 3. Python Runtime Services Next: 3.10.1 Mapping Operators to """ (Next link missing last word "Functions".) http://www.python.org/doc/current/lib/weakref-example.html """Previous: 3.3.1 Weak Reference Objects Up: 3.3 weakref Next: 3.3.3 Weak References in """ (Next link missing last two words "Extension Types".) There are *many* examples of this. -- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-12-22 08:56 Message: Logged In: YES user_id=3066 Originator: NO This is indeed a LaTeX2HTML (mis-)feature. I think this is the first time it's been reported as a problem, but I agree that it's misleading without some indication that something was elided (an ellipsis would help a lot). -- Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 08:10 Message: Logged In: YES user_id=849994 This seems to be a "feature" of LaTeX2html. It limits the links to three words. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559142&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-802128 ] Mode argument of dumbdbm does not work
Bugs item #802128, was opened at 2003-09-07 16:46 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=802128&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin v. Löwis (loewis) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Mode argument of dumbdbm does not work Initial Comment: In dumbdbm.py 2.15, support for a mode argument was added. However, this support does not work: The mode argument is passed to __builtin__.open, which does not support specification of a mode. Instead, the third argument to that function specifies the buffer size. -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 10:05 Message: Logged In: YES user_id=11375 Originator: NO Fix committed in rev. 53141. Leaving open while I look at umask stuff a bit. -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-12-22 08:54 Message: Logged In: YES user_id=3066 Originator: NO Sorry, my patch is long gone. :-( -- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 08:50 Message: Logged In: YES user_id=11375 Originator: NO Attaching my patch. File Added: dumbdbm.patch -- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 08:44 Message: Logged In: YES user_id=11375 Originator: NO Fred, do you still have the patch you mention? I've worked up a patch, but it must be simpler; I don't do anything with the umask. -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-09-12 02:18 Message: Logged In: YES user_id=3066 I have what I think is a correct patch, but I should be able to simplify it (related to handling the umask). Untested on Windows. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=802128&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-802128 ] Mode argument of dumbdbm does not work
Bugs item #802128, was opened at 2003-09-07 16:46 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=802128&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core >Group: Python 2.6 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Martin v. Löwis (loewis) >Assigned to: A.M. Kuchling (akuchling) Summary: Mode argument of dumbdbm does not work Initial Comment: In dumbdbm.py 2.15, support for a mode argument was added. However, this support does not work: The mode argument is passed to __builtin__.open, which does not support specification of a mode. Instead, the third argument to that function specifies the buffer size. -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 10:17 Message: Logged In: YES user_id=11375 Originator: NO Change committed for the umask stuff; I'll see how the buildbots react. Closing this bug. -- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 10:05 Message: Logged In: YES user_id=11375 Originator: NO Fix committed in rev. 53141. Leaving open while I look at umask stuff a bit. -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-12-22 08:54 Message: Logged In: YES user_id=3066 Originator: NO Sorry, my patch is long gone. :-( -- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 08:50 Message: Logged In: YES user_id=11375 Originator: NO Attaching my patch. File Added: dumbdbm.patch -- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 08:44 Message: Logged In: YES user_id=11375 Originator: NO Fred, do you still have the patch you mention? I've worked up a patch, but it must be simpler; I don't do anything with the umask. -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-09-12 02:18 Message: Logged In: YES user_id=3066 I have what I think is a correct patch, but I should be able to simplify it (related to handling the umask). Untested on Windows. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=802128&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-776202 ] MacOS9: test_uu fails
Bugs item #776202, was opened at 2003-07-23 14:02 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776202&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: None Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Jack Jansen (jackjansen) >Assigned to: A.M. Kuchling (akuchling) Summary: MacOS9: test_uu fails Initial Comment: test_uu fails on MacPython-OS9: AssertionError: 'The smooth-scaled python crept over the sleeping dog\r' != 'The smooth-scaled python crept over the sleeping dog\n' Presumably it mixes binary and text I/O. -- >Comment By: Jack Jansen (jackjansen) Date: 2006-12-22 16:46 Message: Logged In: YES user_id=45365 Originator: YES MacOS9 is long dead, uuencoded files are probably even longer dead... If the patch looks good: apply it. But I wouldn't spend more than a few milliseconds on the whole issue:-) -- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 14:33 Message: Logged In: YES user_id=11375 Originator: NO Should the suggested patch be applied, simply for the sake of consistency in test_uu? It's probably difficult to replicate this bug now; does Jack even have a MacOS 9 installation any more? -- Comment By: Walter Dörwald (doerwalter) Date: 2003-08-04 15:33 Message: Logged In: YES user_id=89016 Can you try the following patch (diff.txt)? The patch changes all open() statements to use text mode. I've tested the patch on Windows and Linux. I don't know why the old test mixed text and binary mode. The test should have failed even before the port to PyUnit. -- Comment By: Jack Jansen (jackjansen) Date: 2003-08-04 13:41 Message: Logged In: YES user_id=45365 It's in test_decode. The log is attached. -- Comment By: Walter Dörwald (doerwalter) Date: 2003-08-04 13:21 Message: Logged In: YES user_id=89016 It would help to see a complete traceback (Is the error in test_encode or test_decode?) -- Comment By: Jack Jansen (jackjansen) Date: 2003-07-31 21:50 Message: Logged In: YES user_id=45365 I changed the open call to use 'rU' in stead of 'r' (test_uu rev. 1.6.6.1). I get the distinct impression that this isn't the right fix, though, but that the real problem is elsewhere (mixing up text and binary I/O), so I'd like a second opinion. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776202&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-776202 ] MacOS9: test_uu fails
Bugs item #776202, was opened at 2003-07-23 08:02 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776202&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh >Group: Python 2.6 >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Jack Jansen (jackjansen) Assigned to: A.M. Kuchling (akuchling) Summary: MacOS9: test_uu fails Initial Comment: test_uu fails on MacPython-OS9: AssertionError: 'The smooth-scaled python crept over the sleeping dog\r' != 'The smooth-scaled python crept over the sleeping dog\n' Presumably it mixes binary and text I/O. -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 11:43 Message: Logged In: YES user_id=11375 Originator: NO Applied in rev. 53145. -- Comment By: Jack Jansen (jackjansen) Date: 2006-12-22 10:46 Message: Logged In: YES user_id=45365 Originator: YES MacOS9 is long dead, uuencoded files are probably even longer dead... If the patch looks good: apply it. But I wouldn't spend more than a few milliseconds on the whole issue:-) -- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 08:33 Message: Logged In: YES user_id=11375 Originator: NO Should the suggested patch be applied, simply for the sake of consistency in test_uu? It's probably difficult to replicate this bug now; does Jack even have a MacOS 9 installation any more? -- Comment By: Walter Dörwald (doerwalter) Date: 2003-08-04 09:33 Message: Logged In: YES user_id=89016 Can you try the following patch (diff.txt)? The patch changes all open() statements to use text mode. I've tested the patch on Windows and Linux. I don't know why the old test mixed text and binary mode. The test should have failed even before the port to PyUnit. -- Comment By: Jack Jansen (jackjansen) Date: 2003-08-04 07:41 Message: Logged In: YES user_id=45365 It's in test_decode. The log is attached. -- Comment By: Walter Dörwald (doerwalter) Date: 2003-08-04 07:21 Message: Logged In: YES user_id=89016 It would help to see a complete traceback (Is the error in test_encode or test_decode?) -- Comment By: Jack Jansen (jackjansen) Date: 2003-07-31 15:50 Message: Logged In: YES user_id=45365 I changed the open call to use 'rU' in stead of 'r' (test_uu rev. 1.6.6.1). I get the distinct impression that this isn't the right fix, though, but that the real problem is elsewhere (mixing up text and binary I/O), so I'd like a second opinion. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776202&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1620945 ] minor inconsistency in socket.close
Bugs item #1620945, was opened at 2006-12-22 18:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1620945&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jonathan Ellis (ellisj) Assigned to: Nobody/Anonymous (nobody) Summary: minor inconsistency in socket.close Initial Comment: In python 2.5 socket.close, all methods are delegated to _dummy, which raises an error. It would be more consistent to delegate each method to its counterpart in _closedsocket; in particular re-closing a closed socket is not intended to raise: def close(self): self._sock.close() self._sock = _closedsocket() for method in _delegate_methods: setattr(self, method, getattr(self._sock, method)) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1620945&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1621111 ] IDLE crashes on OS X 10.4 when "Preferences" selected
Bugs item #162, was opened at 2006-12-23 13:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=162&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mick L (mehum) Assigned to: Jack Jansen (jackjansen) Summary: IDLE crashes on OS X 10.4 when "Preferences" selected Initial Comment: When I select 'preferences' (on IDLE 1.2, Python 2.5) or 'Configure IDLE' (IDLE 1.1.4, Python 2.4.4 and IDLE 1.0, Python 2.3.3), Python crashes as soon as the dialog box appears. Terminal reports a "Segmentation fault" upon the crash. My system is an iMac G5 with 1 GB ram running OS X v 10.4.8, Tcl/Tk 8.4.10, and seems otherwise stable. IDLE also appears stable until I select this option. The Python crash log is attached. Please, can anyone suggest what may be causing this problem? Thank you. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=162&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1621111 ] IDLE crashes on OS X 10.4 when "Preferences" selected
Bugs item #162, was opened at 2006-12-23 13:03 Message generated for change (Settings changed) made by mehum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=162&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mick L (mehum) >Assigned to: Ronald Oussoren (ronaldoussoren) Summary: IDLE crashes on OS X 10.4 when "Preferences" selected Initial Comment: When I select 'preferences' (on IDLE 1.2, Python 2.5) or 'Configure IDLE' (IDLE 1.1.4, Python 2.4.4 and IDLE 1.0, Python 2.3.3), Python crashes as soon as the dialog box appears. Terminal reports a "Segmentation fault" upon the crash. My system is an iMac G5 with 1 GB ram running OS X v 10.4.8, Tcl/Tk 8.4.10, and seems otherwise stable. IDLE also appears stable until I select this option. The Python crash log is attached. Please, can anyone suggest what may be causing this problem? Thank you. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=162&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
