[ python-Feature Requests-1634034 ] Show "expected" token on syntax error
Feature Requests item #1634034, was opened at 2007-01-12 13:03
Message generated for change (Comment added) made by oliver_gramberg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1634034&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: Parser/Compiler
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Oliver Gramberg (oliver_gramberg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Show "expected" token on syntax error
Initial Comment:
I suggest that the parser, when reporting a syntax
error, should make use of its knowlegde of which token
type is expected at the position where the error
occurred. This results in more helpful error messages:
-
>>> for a in (8,9)
File "", line 1
for a in (8,9)
^
SyntaxError: invalid syntax - COLON expected
-
>>> for a in (8,9: print a,
File "", line 1
for a in (8,9: print a,
^
SyntaxError: invalid syntax: RPAR expected
-
I tried the following patch (for pythonrun.c). It works
well in the shell both interactively and in scripts,
as well as in IDLE. But it's not complete:
- It doesn't always print useful messages (only for
fixed-size terminal token types, I assume.)
- There sure are cases where more than one token type
is allowed in a position. I believe I have seen that
this information is available too somewhere in the
parser, but it is not forwarded to the err_input
routine.
It's even nicer to show "')'" instead of "RPAR"...
-
/* Set the error appropriate to the given input error code (see errcode.h) */
static void
err_input(perrdetail *err)
{
PyObject *v, *w, *errtype;
PyObject* u = NULL;
char *msg = NULL;
errtype = PyExc_SyntaxError;
switch (err->error) {
case E_SYNTAX:
errtype = PyExc_IndentationError;
if (err->expected == INDENT)
msg = "expected an indented block";
else if (err->token == INDENT)
msg = "unexpected indent";
else if (err->token == DEDENT)
msg = "unexpected unindent";
else {
char buf[50];
errtype = PyExc_SyntaxError;
if(err->expected != -1) {
snprintf(buf, 48, "invalid syntax - %.16s
expected\0",
_PyParser_TokenNames[err->expected]);
msg = buf;
} else {
msg = "invalid syntax";
}
}
break;
...
-
I am willing to help work on this.
Regards
-Oliver
--
>Comment By: Oliver Gramberg (oliver_gramberg)
Date: 2007-03-30 11:44
Message:
Logged In: YES
user_id=206204
Originator: YES
Pfa a diff for my patch.
Regards
-Oliver
File Added: pythonrun.patch
--
Comment By: Sean Gillespie (sean_gillespie)
Date: 2007-03-28 23:37
Message:
Logged In: YES
user_id=1744567
Originator: NO
Your patch seems to work.
I agree that showing the token (as in ")") would indeed be much more
useful, and it would be pretty easy to implement.
However, I think that you should generate a diff for your patch. Its
incredibly hard to read over SF.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1634034&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1688274 ] Python/C PyClass_* are not documented
Bugs item #1688274, was opened at 2007-03-26 14:24 Message generated for change (Comment added) made by tvainika You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688274&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: Tommi Vainikainen (tvainika) Assigned to: Nobody/Anonymous (nobody) Summary: Python/C PyClass_* are not documented Initial Comment: Python/C API Reference Manual chapter 7.5 Other Objects does not contain subchapter for Class objects, but only Instance objects and many other are documented there. >From header I can find that at least PyClass_Check and PyClass_New exist, I >just don't know what those do until I take time to read source code... :( -- >Comment By: Tommi Vainikainen (tvainika) Date: 2007-03-30 15:31 Message: Logged In: YES user_id=1753247 Originator: YES Actually one more thing: I think that chapter 7.5.2 Instance Objects would need also similar note about being relevant only for old-style classes. (At least I think it is only relevant for old style classes.) -- Comment By: Tommi Vainikainen (tvainika) Date: 2007-03-30 10:58 Message: Logged In: YES user_id=1753247 Originator: YES Looks good for me. Actually the first pointer to new-style classes is the most important I think... :) (which I found out by myself after reporting this bug) -- Comment By: Collin Winter (collinwinter) Date: 2007-03-30 06:24 Message: Logged In: YES user_id=1344176 Originator: NO Take a look at the attached patch and see if that says what you want. File Added: concrete.tex.diff -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688274&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1177998 ] Add a settimeout to ftplib.FTP object
Feature Requests item #1177998, was opened at 2005-04-06 15:52
Message generated for change (Comment added) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1177998&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: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Juan Antonio Valiño García (juanval)
Assigned to: Facundo Batista (facundobatista)
Summary: Add a settimeout to ftplib.FTP object
Initial Comment:
It will be usefull that the FTP object of ftplib had a
settimeout method to setup a timeout for the connection,
because the only way of doing this is to use the
socket.setdefaulttimeout method, and this is very
dangerous when you are using threads.
Thanks and keep up the work !
--
>Comment By: Facundo Batista (facundobatista)
Date: 2007-03-30 10:02
Message:
Logged In: YES
user_id=752496
Originator: NO
It's already in the trunk, you can do this:
>>> ftp = ftplib.FTP("localhost", timeout=30)
... or ...
>>> ftp = ftplib.FTP()
>>> ftp.connect("localhost", timeout=30)
... or ...
>>> ftp = ftplib.FTP(timeout=30)
>>> ftp.connect("localhost")
... or ...
>>> ftp = ftplib.FTP()
>>> ftp.timeout = 30
>>> ftp.connect("localhost")
:D
Thanks Collin!
--
Comment By: Collin Winter (collinwinter)
Date: 2007-03-30 04:23
Message:
Logged In: YES
user_id=1344176
Originator: NO
Facundo, I believe you're doing something along these lines, right?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1177998&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1688274 ] Python/C PyClass_* are not documented
Bugs item #1688274, was opened at 2007-03-26 07:24 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688274&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: Python 2.6 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Tommi Vainikainen (tvainika) Assigned to: Nobody/Anonymous (nobody) Summary: Python/C PyClass_* are not documented Initial Comment: Python/C API Reference Manual chapter 7.5 Other Objects does not contain subchapter for Class objects, but only Instance objects and many other are documented there. >From header I can find that at least PyClass_Check and PyClass_New exist, I >just don't know what those do until I take time to read source code... :( -- >Comment By: Collin Winter (collinwinter) Date: 2007-03-30 10:02 Message: Logged In: YES user_id=1344176 Originator: NO I'll add a note to the docs for instance objects. Fixed in r54614. Thanks, Tommi. -- Comment By: Tommi Vainikainen (tvainika) Date: 2007-03-30 08:31 Message: Logged In: YES user_id=1753247 Originator: YES Actually one more thing: I think that chapter 7.5.2 Instance Objects would need also similar note about being relevant only for old-style classes. (At least I think it is only relevant for old style classes.) -- Comment By: Tommi Vainikainen (tvainika) Date: 2007-03-30 03:58 Message: Logged In: YES user_id=1753247 Originator: YES Looks good for me. Actually the first pointer to new-style classes is the most important I think... :) (which I found out by myself after reporting this bug) -- Comment By: Collin Winter (collinwinter) Date: 2007-03-29 23:24 Message: Logged In: YES user_id=1344176 Originator: NO Take a look at the attached patch and see if that says what you want. File Added: concrete.tex.diff -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688274&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1506171 ] Add "methodcaller" to the operator module
Feature Requests item #1506171, was opened at 2006-06-14 12:02
Message generated for change (Comment added) made by collinwinter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506171&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: Closed
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: Gregory Petrosyan (gregory_p)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add "methodcaller" to the operator module
Initial Comment:
I found that I (like Alex Martelli, http://mail.python.
org/pipermail/python-dev/2006-February/060341.html :-)
am writing lambdas like "lambda x: x.do_smth(a,b,c)" a
lot (often for filter/map functions). So, I think it
would be great to have such a function implemented in
C and placed in the standart library. Operator module
can be a good place for it.
--
Regards, Gregory.
--
>Comment By: Collin Winter (collinwinter)
Date: 2007-03-30 10:39
Message:
Logged In: YES
user_id=1344176
Originator: NO
Guido has stated that lambda will not be removed in Python 3000 (see PEP
3099), so I can't see the need for a HOF to avoid lambda-usage, especially
when the lambda expression is shorter/clearer:
operator.methodcaller('method', x, y, z)
lambda x: x.method(x, y, z)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506171&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1612190 ] Py_DEBUG
Feature Requests item #1612190, was opened at 2006-12-09 10:48 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1612190&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: Rejected Priority: 5 Private: No Submitted By: nitro (nitrogenycs) Assigned to: Nobody/Anonymous (nobody) Summary: Py_DEBUG Initial Comment: Hello, I am writing an extension module (Win32, VC8). Of course I need to #include . Now, when _DEBUG is defined in my application Py_DEBUG gets defined as well (in pyconfig.h). I don't want this to happen as I have to link to the python debug library that way. However, I don't want to debug python, I only want to debug my own application. So the automatic definition of Py_DEBUG doesn't seem right. A solution that would be backwards compatible could look like: #ifdef _DEBUG && !defined(Py_NO_DEBUG) # define Py_DEBUG #endif Could something like this be included in python? Note that #undef _DEBUG #include #define _DEBUG does not work as VC8 complains in this case, because some header files had the _DEBUG preprocessor symbol and some didn't. That trick used to work in VC 6 and 7.x. I've seen a lot of people fighting this problem. Another problem that also arises from pyconfig.h is this code: # ifdef _DEBUG # pragma comment(lib,"python24_d.lib") # else I don't think it's clean that python tells my program what to link to. I am the one who should (and wants to) do this via a linker switch. I know that some people probably would regard the code above as a feature, but it's the opposite imo. A backwards compatible change could look like: #ifdef MS_COREDLL # ifndef Py_BUILD_CORE /* not building the core - must be an ext */ # if defined(_MSC_VER) && !defined(Py_NO_AUTOMATIC_MSVC_LINK) /* So MSVC users need not specify the .lib file in their Makefile (other compilers are generally taken care of by distutils.) */ # ifdef _DEBUG # pragma comment(lib,"python24_d.lib") # else # pragma comment(lib,"python24.lib") # endif /* _DEBUG */ # endif /* _MSC_VER */ # endif /* Py_BUILD_CORE */ #endif /* MS_COREDLL */ Thanks, -Matthias -- >Comment By: Collin Winter (collinwinter) Date: 2007-03-30 10:40 Message: Logged In: YES user_id=1344176 Originator: NO Closing per Martin's comment. -- Comment By: Martin v. Löwis (loewis) Date: 2006-12-11 14:09 Message: Logged In: YES user_id=21627 Originator: NO You should just not define _DEBUG then. You don't need to define _DEBUG to perform debugging; instead, _DEBUG requests that the debug version of the MS CRT is linked to your application. As mixing different CRTs (e.g. debug and non-debug) in a single application can cause crashes, you *must* use a python2x.dll that is linked with the debug CRT; this will be python2x_d.dll. So no, something like this should not be added to Python. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1612190&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-815563 ] bug with ill-formed rfc822 attachments
Feature Requests item #815563, was opened at 2003-09-30 22:32 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=815563&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stuart D. Gathman (customdesigned) Assigned to: Nobody/Anonymous (nobody) Summary: bug with ill-formed rfc822 attachments Initial Comment: The following proglet gets an except with the attached message: -te.py import email import sys msg = email.message_from_file(sys.stdin) sys.stdout.write(msg.as_string()) -- python2 te.pyComment By: Collin Winter (collinwinter) Date: 2007-03-30 10:50 Message: Logged In: YES user_id=1344176 Originator: NO I don't see any exception as of Python 2.5. Closing as "fixed". -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-21 16:00 Message: Logged In: YES user_id=12800 Note that if you're looking for something that just parses messages into headers and bodies, you might look at the HeaderParser class. You'd have to write a bit of code to get an outer parser that falls back to a HeaderParser on invalid unparseable inner messages. -- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-11-21 15:52 Message: Logged In: YES user_id=142072 Your disposition makes sense. Since all messages with invalid MIME boundaries are either invalid themselves, or bounces or forwards of invalid messages, my work around is to issue an SMTP reject: if exc_type == email.Errors.BoundaryError: self.setreply('554','5.7.7', 'Boundary error in your message, are you a spammer?') For 2.4, I recommend that rfc822 attachments be parsed independently of the enclosing message. If the attachment is invalid, turn it into a plain rfc822 message object or a string. Although the rfc822 module is deprecated, I find it very useful to represent mail that may or may not correctly follow MIME standards. Examples include forwarded spam (using the new innoculation RFC), and generic mailbox processing. I suggest retaining rfc822 as a 'featureless' message with only headers and body. -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-21 15:36 Message: Logged In: YES user_id=12800 I'm moving this to a feature request for Python 2.4. There's little that we can do about this in Python 2.3 since the lax parser is only so good at guessing the intent of ill-formed messages. email 2.x can't do what you suggest because that would be a new feature and can't be introduced into Python 2.3. The email-sig is chartered with developing an improved parser for Python 2.4 that might be able to handle this. In the meantime, you could probably derive your own Parser class that might be able to worm around this problem in an application specific way. --
[ python-Feature Requests-795081 ] email.Message param parsing problem II
Feature Requests item #795081, was opened at 2003-08-25 23:37
Message generated for change (Comment added) made by collinwinter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=795081&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: Stuart D. Gathman (customdesigned)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Message param parsing problem II
Initial Comment:
The enclosed real life (inactivated) virus message
causes email.Message to fail to find the multipart
attachments. This is because the headers following
Content-Type are indented, causing email.Message to
properly append them to Content-Type. The trick is
that the boundary is quoted, and Outhouse^H^H^H^H^Hlook
apparently gets a value of 'bound' for boundary,
whereas email.Message gets the value
'"bound"\n\tX-Priority...'. email.Utils.unqoute
apparently gives up and doesn't remove any quotes.
I believe that unqoute should return just what is
between the quotes, so that '"abc" def' would be
unquoted to 'abc'. In fact, my email filtering
software (http://bmsi.com/python/milter.html) works
correctly on all kinds of screwy mail using my version
of unquote using this heuristic. I believe that header
used by the virus is invalid, so a STRICT parser should
reject it, but a tolerant parser (such as a virus
scanner would use) should use the heuristic.
Here is a brief script to show the problem (attached
file in test/virus5):
--t.py--
import email
msg = email.message_from_file(open('test/virus5','r'))
print msg.get_params()
-
$ python2 t.py
[('multipart/mixed', ''), ('boundary',
'"bound"\n\tX-Priority: 3\n\tX-MSMail-Priority:
Normal\n\tX-Mailer: Microsoft Outlook Express
5.50.4522.1300\n\tX-MimeOLE: Produced By Microsoft
MimeOLE V5.50.4522.1300')]
--
>Comment By: Collin Winter (collinwinter)
Date: 2007-03-30 10:58
Message:
Logged In: YES
user_id=1344176
Originator: NO
I'm still seeing this behaviour as of Python 2.6a0.
Barry: I take it email-sig didn't get around to discussing this?
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-11-21 15:45
Message:
Logged In: YES
user_id=12800
Moving this to feature requests for Python 2.4. If
appropriate, the email-sig should address this in the
intended new lax parser for email 3.0 / Python 2.4. We
can't add this to the Python 2.3 (or earlier) maintenance
releases.
--
Comment By: Stuart D. Gathman (customdesigned)
Date: 2003-08-25 23:57
Message:
Logged In: YES
user_id=142072
Here is a proposed fix for email.Util.unquote (except it
should test for a 'strict' mode flag, which is current only
in Parser):
def unquote(str):
"""Remove quotes from a string."""
if len(str) > 1:
if str.startswith('"'):
if str.endswith('"'):
str = str[1:-1]
else: # remove garbage after trailing quote
try: str = str[1:str[1:].index('"')+1]
except: return str
return str.replace('', '\\').replace('\\"', '"')
if str.startswith('<') and str.endswith('>'):
return str[1:-1]
return str
Actually, I replaced only email.Message._unquotevalue for my
application to minimize the impact. That would also be a
good place to check for a STRICT flag stored with the
message object. Perhaps the Parser should set the Message
_strict flag from its own _strict flag.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=795081&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1691387 ] Call sys.except_hook if exception occurs in __del__
Feature Requests item #1691387, was opened at 2007-03-30 15:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1691387&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: Open Resolution: None Priority: 5 Private: No Submitted By: John Ehresman (jpe) Assigned to: Nobody/Anonymous (nobody) Summary: Call sys.except_hook if exception occurs in __del__ Initial Comment: Is there a reason why sys.except_hook isn't called when __del__ returns with an exception? If not, I can write a patch to call sys.except_hook from PyErr_WriteUnraisable. The default of printing the full traceback should be possible in many situations. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1691387&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-588825 ] unittest.py, better error message
Feature Requests item #588825, was opened at 2002-07-30 18:29 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=588825&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: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Wehr (stefanheimann) >Assigned to: Collin Winter (collinwinter) Summary: unittest.py, better error message Initial Comment: These two methods of the class TestCase are not very good: def failUnlessEqual(self, first, second, msg=None): """Fail if the two objects are unequal as determined by the '!=' operator. """ if first != second: raise self.failureException, \ (msg or '%s != %s' % (`first`, `second`)) def failIfEqual(self, first, second, msg=None): """Fail if the two objects are equal as determined by the '==' operator. """ if first == second: raise self.failureException, \ (msg or '%s == %s' % (`first`, `second`)) The first thing is that you should print the difference of the given values like that: '<%s> == <%s>' % (`first`, `second`) The < and > delimits the string and so is is easier to detect where the string starts and where it ends. The second thing is that I would really like to see the two values that are (not) equal even if I provide a message. Maybe its better to raise the exception like that: if msg is not None: msg += ' Expected: <%s>, is: <%s>' % (first, second) raise self.failureException, \ (msg or '%s != %s' % (`first`, `second`)) bye Stefan -- Comment By: Brett Cannon (bcannon) Date: 2003-05-21 00:47 Message: Logged In: YES user_id=357491 I am making this an RFE since it is just a suggestion and not a bug. -- Comment By: Raymond Hettinger (rhettinger) Date: 2002-08-18 18:19 Message: Logged In: YES user_id=80475 Steve, would you like these implemented or left as is? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=588825&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1691411 ] Duplicate "preferences" menu item/Tk Aqua 8.4.14
Bugs item #1691411, was opened at 2007-03-30 11:12
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=1691411&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: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kevin Walzer (wordtech)
Assigned to: Nobody/Anonymous (nobody)
Summary: Duplicate "preferences" menu item/Tk Aqua 8.4.14
Initial Comment:
Version 8.4.14 of Tcl/Tk Aqua (for OS X) hard-codes a "Preferences" item in
the Apple menu. As a result, IDLE now has two "Preferences" items--the active
one that is coded by default, and an inactive item that is hard-coded by Tk.
The way to work around this is to check the version of Tk that is present, in
this fashion:
tkversion=Tkinter.Tk().tk.eval('info patchlevel')
If it is 8.4.14 or greater, then you should bind IDLE's "preferences" dialog to
the hard-coded menu item in Tk (and remove the "preferences" menu entry that
comes with IDLE). It can be done in this fashion:
Tkinter.Tk().createcommand('::tk::mac::ShowPreferences',
IDLEpreferencesfunction) ##substitute the correction function name here
If tkversion <= '8.4.13', leave things as they are.
I have tried to put together a patch for this, but I'm not sure where the
correct place to add this code is. I've looked at Bindings.py and
macosxSupport.py, but it doesn't work as expected (in macosxSupport.py, it
simply ignores the code; in Bindings.py, it removes IDLE's preferences item,
but doesn't activate the hard-coded one). So I'm leaving this to someone with a
greater knowledge of IDLE's internal structure to apply.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1691411&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-478407 ] Need Windows os.link() support
Feature Requests item #478407, was opened at 2001-11-05 14:34 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=478407&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: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Need Windows os.link() support Initial Comment: NTFS has (always?) had hard link support. This functionality is now exposed in Win32 starting with Windows 2000 [see CreateHardLink()]. I've added Windows support to os.link(). I've tried to support FAT, NT, 95 by doing a CopyFile(). 2000 support is enabled by defining _WIN32_WINNT=0x500 in pythoncore.dsp. When this is done, the redundant #includein errnomodule.c gives compilation errors. -- >Comment By: Collin Winter (collinwinter) Date: 2007-03-30 12:13 Message: Logged In: YES user_id=1344176 Originator: NO This feature request has been superseded by #1578269, which includes several references on the subject. -- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 22:08 Message: Logged In: YES user_id=357491 If you would like this to actually be looked at it would be best to create a patch against CVS and upload a diff file instead of a zip file. -- Comment By: Michael Dubner (dubnerm) Date: 2003-01-18 00:49 Message: Logged In: YES user_id=39274 Also one can create os.symlink() and os.readlink() for all windows versions after 95 - using shell links (like cygwin do for symlink emulation). -- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-05 14:35 Message: Logged In: NO I think that I forgot to add my email address: [EMAIL PROTECTED] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=478407&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1506171 ] Add "methodcaller" to the operator module
Feature Requests item #1506171, was opened at 2006-06-14 11:02
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506171&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: Rejected
Priority: 5
Private: No
Submitted By: Gregory Petrosyan (gregory_p)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add "methodcaller" to the operator module
Initial Comment:
I found that I (like Alex Martelli, http://mail.python.
org/pipermail/python-dev/2006-February/060341.html :-)
am writing lambdas like "lambda x: x.do_smth(a,b,c)" a
lot (often for filter/map functions). So, I think it
would be great to have such a function implemented in
C and placed in the standart library. Operator module
can be a good place for it.
--
Regards, Gregory.
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-03-30 11:46
Message:
Logged In: YES
user_id=80475
Originator: NO
Re-opening. There are valid use cases for this request and there are some
speed benefits to having a functional form.
--
Comment By: Collin Winter (collinwinter)
Date: 2007-03-30 09:39
Message:
Logged In: YES
user_id=1344176
Originator: NO
Guido has stated that lambda will not be removed in Python 3000 (see PEP
3099), so I can't see the need for a HOF to avoid lambda-usage, especially
when the lambda expression is shorter/clearer:
operator.methodcaller('method', x, y, z)
lambda x: x.method(x, y, z)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506171&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-588825 ] unittest.py, better error message
Feature Requests item #588825, was opened at 2002-07-30 17:29 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=588825&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: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Wehr (stefanheimann) Assigned to: Collin Winter (collinwinter) Summary: unittest.py, better error message Initial Comment: These two methods of the class TestCase are not very good: def failUnlessEqual(self, first, second, msg=None): """Fail if the two objects are unequal as determined by the '!=' operator. """ if first != second: raise self.failureException, \ (msg or '%s != %s' % (`first`, `second`)) def failIfEqual(self, first, second, msg=None): """Fail if the two objects are equal as determined by the '==' operator. """ if first == second: raise self.failureException, \ (msg or '%s == %s' % (`first`, `second`)) The first thing is that you should print the difference of the given values like that: '<%s> == <%s>' % (`first`, `second`) The < and > delimits the string and so is is easier to detect where the string starts and where it ends. The second thing is that I would really like to see the two values that are (not) equal even if I provide a message. Maybe its better to raise the exception like that: if msg is not None: msg += ' Expected: <%s>, is: <%s>' % (first, second) raise self.failureException, \ (msg or '%s != %s' % (`first`, `second`)) bye Stefan -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-03-30 11:52 Message: Logged In: YES user_id=80475 Originator: NO Collin, you should probably solicit Steve Purcell's input before proceeding with the one. The request seems reasonable but the module author should have some say in the matter. -- Comment By: Brett Cannon (bcannon) Date: 2003-05-20 23:47 Message: Logged In: YES user_id=357491 I am making this an RFE since it is just a suggestion and not a bug. -- Comment By: Raymond Hettinger (rhettinger) Date: 2002-08-18 17:19 Message: Logged In: YES user_id=80475 Steve, would you like these implemented or left as is? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=588825&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1685000 ] DoS asyncore vulnerability
Bugs item #1685000, was opened at 2007-03-21 02:15 Message generated for change (Comment added) made by rushing You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685000&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: Open Resolution: None Priority: 5 Private: No Submitted By: billiejoex (billiejoex) Assigned to: Nobody/Anonymous (nobody) Summary: DoS asyncore vulnerability Initial Comment: DoS asyncore vulnerability asyncore, independently if used with select() or poll(), suffers a DoS-type vulnerability when a high number of simultaneous connections to handle simultaneously is reached. The number of maximum connections is system-dependent as well as the type of error raised. I attached two simple Proof of Concept scripts demonstrating such bug. If you want to try the behaviours listed below run the attached "asyncore_server.py" and "asyncore_client.py" scripts on your local workstation. On my Windows XP system (Python 2.5), independently if asyncore has been used to develop a server or a client, the error is raised by select() inside asyncore's "poll" function when 512 (socket_map's elements) simultaneous connections are reached. Here's the traceback I get: [...] connections: 510 connections: 511 connections: 512 Traceback (most recent call last): File "C:\scripts\asyncore_server.py", line 38, in asyncore.loop() File "C:\Python25\lib\asyncore.py", line 191, in loop poll_fun(timeout, map) File "C:\Python25\lib\asyncore.py", line 121, in poll r, w, e = select.select(r, w, e, timeout) ValueError: too many file descriptors in select() On my Linux Ubuntu 6.10 (kernel 2.6.17-10, Python 2.5) different type of errors are raised depending on the application (client or server). In an asyncore-based client the error is raised by socket module (dispatcher's "self.socket" attribute) inside 'connect' method of 'dispatcher' class: [...] connections: 1018 connections: 1019 connections: 1020 connections: 1021 Traceback (most recent call last): File "asyncore_client.py", line 31, in File "asyncore.py", line 191, in loop File "asyncore.py", line 138, in poll File "asyncore.py", line 80, in write File "asyncore.py", line 76, in write File "asyncore.py", line 395, in handle_write_event File "asyncore_client.py", line 24, in handle_connect File "asyncore_client.py", line 9, in __init__ File "asyncore.py", line 257, in create_socket File "socket.py", line 156, in __init__ socket.error: (24, 'Too many open files') On an asyncore-based server the error is raised by socket module (dispatcher's "self.socket" attribute) inside 'accept' method of 'dispatcher' class: [...] connections: 1019 connections: 1020 connections: 1021 Traceback (most recent call last): File "asyncore_server.py", line 38, in File "asyncore.py", line 191, in loop File "asyncore.py", line 132, in poll File "asyncore.py", line 72, in read File "asyncore.py", line 68, in read File "asyncore.py", line 384, in handle_read_event File "asyncore_server.py", line 16, in handle_accept File "asyncore.py", line 321, in accept File "socket.py", line 170, in accept socket.error: (24, 'Too many open files') -- Comment By: Sam Rushing (rushing) Date: 2007-03-30 10:22 Message: Logged In: YES user_id=73736 Originator: NO Turns out medusa doesn't have a socket counter class, that was some other project I was thinking of. Putting a try/except in place doesn't really help the problem... if you fail to create a new socket what action will you take? A better approach is to have a configurable limit on the number of open connections, and then have a server-specific reaction to exceeding that limit. For example, an SMTP server might respond with a 4XX greeting and close the connection. An additional problem on Unix is that running out of descriptors affects more than just sockets. Once you hit the FD limit you can't open files, or do anything that requires a descriptor. -- Comment By: billiejoex (billiejoex) Date: 2007-03-29 07:03 Message: Logged In: YES user_id=1357589 Originator: YES > The problem is that there's no portable way to know what the limit > on file descriptors is. Why don't put a try/except statement before creating a new socket's file-descriptor? I believe that such problem shouldn't be understimated. Actually asyncore is the only asynchronous module present in Python's stdlib. If asyncore suffers a DoS vulnerability it just means that writing a secure client/server application with Python without using a third-party library isn't possible. I wrote a modified version of asyncore that solves the problem with select (aff
[ python-Bugs-451607 ] SSL support in socket module needs tests
Bugs item #451607, was opened at 2001-08-16 13:00 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=451607&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: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barry A. Warsaw (bwarsaw) >Assigned to: Facundo Batista (facundobatista) Summary: SSL support in socket module needs tests Initial Comment: SSL support in the socket module should have a regression test, either in test_socket.py or in a separate test_ssl.py file. -- >Comment By: Facundo Batista (facundobatista) Date: 2007-03-30 21:45 Message: Logged In: YES user_id=752496 Originator: NO I'll try to test the socket to a (when available) local openssl server. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-12 05:01 Message: Logged In: YES user_id=21627 I don't think I will do anything about this anytime soon, so unassigning myself. -- Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 05:51 Message: Logged In: YES user_id=21627 I don't think this is relevant here: OpenSSL uses whatever device it uses; we need not to concern ourselves with OpenSSL's choice. -- Comment By: Nobody/Anonymous (nobody) Date: 2002-10-10 05:39 Message: Logged In: NO Using /dev/random for a user level application is inappropriate. Use /dev/urandom instead. /dev/random actually tries to suck entropy out of the entropy pool, and blocks if there's not enough. It's best to make sure there's sufficient initial entropy in the pool, then use /dev/urandom which uses the existing entropy to seed a CPRNG. Assuming the CPRNG is properly designed, /dev/urandom should be fine for OpenSSL, since if someone magically breaks the cryptography in the CPRNG then they can probably break OpenSSL's cryptography the same way. --phr -- Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 05:13 Message: Logged In: YES user_id=21627 Things have changed a bit since: Solaris 9 has /dev/random. -- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2002-10-09 15:25 Message: Logged In: YES user_id=80200 yes it definitely does because on solaris, which doesn't have a /dev/random, urlretrieve fails to operate because openssl cannot get enough entropy for the PRNG in order to make the SSL connection. -- Comment By: Martin v. Löwis (loewis) Date: 2001-10-11 16:39 Message: Logged In: YES user_id=21627 1) When prngd runs on a TCP socket, it still won't accept connections from remote systems. 2) Sure, but would that simplify testing? 3) My comment was actually directed at bug #232460, which is Solaris specific: Solaris does not have a /dev/[u]random, so prngd is the only choice. I agree that using /dev/random is better if available. Furthermore, OpenSSL will already make this choice for you at installation time. -- Comment By: paul rubin (phr) Date: 2001-10-11 15:44 Message: Logged In: YES user_id=72053 1) I think it's dangerous to run a prngd on an IP socket instead of a Unix domain socket. It creates the possibility of (either accidentally or by ignorance) running OpenSSL on a separate host from the prngd, making the random numbers vulnerable to network sniffing. That's bad--the numbers are cryptographic secrets and should not be exposed. 2) It's simple to set up a local SSL server with the command line openssl s_server option. 3) I'm not crazy about the whole prngd concept. I haven't looked at the CHILL interface yet, but if it's possible to abandon prngd and get random numbers through CHILL, that might be best. On Linux, /dev/urandom should be used. -- Comment By: Martin v. Löwis (loewis) Date: 2001-10-11 15:32 Message: Logged In: YES user_id=21627 On PRNG problems, it seems we have two options: - wait for, then require OpenSSL 0.9.7. It will look for a prngd socket in default locations (/var/run/egd-pool, /dev/egd-pool, /etc/egd-pool and /etc/entropy); then require administrators to set up OpenSSL that it indeed finds a prngd in these locations when needed. - expose RAND_add. Exposing any other of the interfaces is pointless; on our installation, prngd runs on localhost:708 instead of a Unix domain sock
[ python-Bugs-1027394 ] socket.ssl should explain that it is a 2/3 connection
Bugs item #1027394, was opened at 2004-09-13 14:45 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1027394&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: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: adam goucher (adamg-work) Assigned to: Nobody/Anonymous (nobody) Summary: socket.ssl should explain that it is a 2/3 connection Initial Comment: When you try to connect via socket.ssl(), python attempts a ssl2 connection then negotiates up. On some servers however ssl2 is disabled making the connection fail. The documentation should mention this limitation. If you want to connect to an ssl3 or tls1 only server, you need to modify the ssl context this method uses. I submitted a patch (889813) some time ago to allow the context to be specified as an optional argument. -- >Comment By: Facundo Batista (facundobatista) Date: 2007-03-30 22:23 Message: Logged In: YES user_id=752496 Originator: NO Please, could you came up with a text that I could use to fix the docs? There's no need of LaTeX format here, just append the parragraph here. Regards, -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1027394&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
