[ python-Bugs-1473979 ] test test_capi crashed -- thread.error: can't allocate lock
Bugs item #1473979, was opened at 2006-04-21 10:27 Message generated for change (Comment added) made by shashikala You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473979&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: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: shashi (shashikala) Assigned to: Nobody/Anonymous (nobody) Summary: test test_capi crashed -- thread.error: can't allocate lock Initial Comment: Hi , This is shashikala . I am building Python 2.4.3 0n HP- UX 11.23 platform, the building of went smooth buit while testing Python using gmake test test_capi is failing . The Error is "test test_capi crashed -- thread.error: can't allocate lock" . Could you please help in fixing the above error. I am attaching the file which has details of the testing . Thanks and Regards, shashikala -- >Comment By: shashi (shashikala) Date: 2006-04-24 15:31 Message: Logged In: YES user_id=1506183 -- Comment By: Tim Peters (tim_one) Date: 2006-04-21 10:50 Message: Logged In: YES user_id=31435 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473979&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-1475397 ] compute/doc %z os-indep., time.asctime_tz / _TZ
Feature Requests item #1475397, was opened at 2006-04-24 11:40
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=1475397&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
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: compute/doc %z os-indep., time.asctime_tz / _TZ
Initial Comment:
Very often I need (for logging purposes, legal
international action confirmation display, ...) quickly
a stable/constant/technical/international timezone info
in addition to %c / .asctime. And find me regularly
checking if the computer/server displays %Z nice,
writing 10-liner funcs ...
found %z by trial (and in footnote)
yet time.strftime('%c %z') flickers (on Windows..)
think, %z can be computed very easily independent of OS
libs? time.altzone /% 3600 ... ==> "+/-HHMM" ?
that could be doc'ed.
( the sign of time.timezone / time.altzone is
unfortunately revers of RFC standardds , yet its ok
doced. there should be a function/update-function for
long running apps also ? )
then .asctime_tz() would be very nice to find it in the
docs. (and maybe asctime_TZ)
-robert
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1475397&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-1436203 ] getpass.getpass() should allow Unicode prompts
Feature Requests item #1436203, was opened at 2006-02-21 22:52
Message generated for change (Comment added) made by kxroberto
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1436203&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: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel Herding (wikipedian)
Assigned to: Nobody/Anonymous (nobody)
Summary: getpass.getpass() should allow Unicode prompts
Initial Comment:
Hi,
when using Python 2.4.1 on Linux, I get this:
>>> import getpass
>>> getpass.getpass(u'Contraseña: ')
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/getpass.py", line 35, in
unix_getpass
passwd = _raw_input(prompt)
File "/usr/lib/python2.4/getpass.py", line 74, in
_raw_input
prompt = str(prompt)
UnicodeEncodeError: 'ascii' codec can't encode
character u'\xf1' in position 8: ordinal not in range(128)
This one works, but only if the user's console is using
UTF-8 encoding:
>>> getpass.getpass(u'Contraseña: '.encode('utf-8'))
Contraseña:
I think you should be able to directly give a Unicode
string to getpass(), as you can also give a Unicode
string to print.
Daniel
--
Comment By: kxroberto (kxroberto)
Date: 2006-04-24 12:39
Message:
Logged In: YES
user_id=972995
That error line in getpass should probably simply be
commented out?
Whats your sys.stdout.encoding ? (Probably not enough for
spanish chars as well)
The others will probably recommend to create sitecustomize.py
I'd say: Its a general trouble with Python that (console)
output encoding is in 'strict' mode by default.
That crashes more apps, than it helps for discipline ...
And its hard even to grasp it and switch it for 'replace':
you'd need to replace sys.stdout with a custom formatter etc..
On MS Windows OS the MBCS conversion is kind of 'replace'
for good reason. Even in Python on Win:
u"abc\u034adef".encode('mbcs') does replacing.
tty's,browser,windows,... and maybe most text mode files
(and even bin ones (latin1/replace?) ?) should not break.
The cases, where encoding should break strictly are
naturally cases where the programmer is aware (and puts the
conversion into strict mode expicitely)
"Python cannot print": Even a harmless
>>> print u"abc\u034adef"
throws an exception. That is questionable enough:
http://groups.google.de/group/comp.lang.python/msg/eac9b025b93e0642
Maybe in future Python:
* encoding tuples should be accepted everywhere as
alternative to second argument: .encode((enc,error))
* text file's .encoding/.write_encoding=(xy,'replace') or
(xy,'backslashreplace')
* bin file's .encoding=('latin1','strict')
* site(customize).py's defaultencoding should be/accept a
tuple ('ascii','replace')
-robert
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1436203&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1475554 ] Poorly worded description for socket.makefile()
Bugs item #1475554, was opened at 2006-04-24 10:19 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=1475554&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 Submitted By: Roy Smith (roysmith) Assigned to: Nobody/Anonymous (nobody) Summary: Poorly worded description for socket.makefile() Initial Comment: On the "7.2.1 Socket Objects" page, under makefile(), it says "The socket should be in blocking mode". If I understand it correctly, it MUST be in blocking mode. "Must" implies a mandatory requirement, "should" implies a suggestion of the best way to do something. This comment applies to many places in the Python docs. There should be a comprehensive review of all the docs to clarify "should" vs. "must" usage. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475554&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1475554 ] Poorly worded description for socket.makefile()
Bugs item #1475554, was opened at 2006-04-24 10:19 Message generated for change (Settings changed) made by roysmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475554&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: 3 Submitted By: Roy Smith (roysmith) Assigned to: Nobody/Anonymous (nobody) Summary: Poorly worded description for socket.makefile() Initial Comment: On the "7.2.1 Socket Objects" page, under makefile(), it says "The socket should be in blocking mode". If I understand it correctly, it MUST be in blocking mode. "Must" implies a mandatory requirement, "should" implies a suggestion of the best way to do something. This comment applies to many places in the Python docs. There should be a comprehensive review of all the docs to clarify "should" vs. "must" usage. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475554&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1475692 ] replacing obj.__dict__ with a subclass of dict
Bugs item #1475692, was opened at 2006-04-24 20:45 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=1475692&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.4 Status: Open Resolution: None Priority: 5 Submitted By: ganges master (gangesmaster) Assigned to: Nobody/Anonymous (nobody) Summary: replacing obj.__dict__ with a subclass of dict Initial Comment: >>> class mydict(dict): ... def __getitem__(self, key): ... return 17 ... >>> class blah(object): ... def __init__(self): ... self.__dict__ = mydict() ... >>> b = blah() >>> print b.x Traceback (most recent call last): File "", line 1, in ? AttributeError: 'blah' object has no attribute 'x' python doesn't call the overriden version of __getitem__. i've done several more tests, and the cause to this problem, afaik, is that the code assumes __dict__ is an instance of dict, so it directly uses PyDict_GetItem (or whatever it's called), thus skipping the overriden method. python should either disable setting __dict__ to anything that is not a real dict (type(x) == dict instead of isinstance(x, dict)), or be willing to call overriden methods. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475692&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1467080 ] Many functions in socket module are not thread safe
Bugs item #1467080, was opened at 2006-04-08 18:09 Message generated for change (Comment added) made by sobomax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maxim Sobolev (sobomax) Assigned to: Nobody/Anonymous (nobody) Summary: Many functions in socket module are not thread safe Initial Comment: The socket module make a great effort to be thread-safe, but misses one big point - it uses single per-instance buffer to hold resolved sockaddr_xxx structures. Therefore, on SMP system it is possible that several threads calling functions that perform address resolution in parallel will stomp on each other resulting in incorrect or invalid address to be used in each case. For example, two threads calling sendto() in parallel can result in packets to be sent to incorrect addresses - packets from thread one from time to time will be sent to address requested by thread two and vice versa. Another, smaller issue is that the call to getnameinfo() is not protected with netdb mutex on systems that don't have thread-safe resolver. -- >Comment By: Maxim Sobolev (sobomax) Date: 2006-04-24 15:31 Message: Logged In: YES user_id=24670 OK, it looks like the only way to get this bug fixed is to reimplement patch to use stack instead of heap, so that here we go. Attached please find new version of the patch which allocates address buffer on stack. -Maxim -- Comment By: Maxim Sobolev (sobomax) Date: 2006-04-17 16:05 Message: Logged In: YES user_id=24670 > The big win is in simplification of the code. What do you call "big simplification"? Several malloc/free calls and appropriate NULL checks? Aside from stack usage issues the big loss here is portability - we either need to use some fixed length buffer with the size sufficient to hold any type of address (ugly!) or use sockaddr_storage, which may not exist on all platforms supported by the python. -Maxim -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-17 15:51 Message: Logged In: YES user_id=21627 The big win is in simplification of the code. Also, we are not talking about 10k here. On Linux, sock_addr_t is 128 bytes. Take a look at set_error: it allocates 100 bytes for an error buffer. Or sock_repr: 512 bytes for a buffer. Or socket_gethostname: 1024 bytes. Or socket_gethostbyname_ex: 16384 bytes. socket_getaddrinfo: 30 bytes. os_init: 100 bytes Or, looking at other modules: symtable.c:check_unoptimized: 300 bytes. Py_GetVersion: 250 bytes. PySys_SetArgv: 2*MAXPATHLEN+1 (on Linux, this is 8193 bytes). I could go on. Don't worry about stack consumption. Or, if you do, analyse the Python source code, and fix the big offenders first. Premature optimization is the root of all evil. -- Comment By: Maxim Sobolev (sobomax) Date: 2006-04-17 15:10 Message: Logged In: YES user_id=24670 > The address space available to each thread typically doesn't > depend on the number of threads. Instead, the stack size is > pre-determined, so it's vice versa: the number of threads > supported depends on that stack-size, which (currently) isn't tunable. Yes, but my point is that on low-end and/or embedded system the system can be configured with as low stack per thread as possible (since with for example 100 threads, every extra 10K of stack per thread means 1M of extra memory, which in the absence of paging needs to be wired down) and if only one thread needs this stack 990K of it will be effectively wasted. And since getaddrinfo()-family already uses heap for its results I don't see any big win in avoiding extra malloc()/free() call. Expecially considering that we are dealing with i/o here, so that system call overhead will be much more than that anyway, even if the program calls those functions heavily. -Maxim -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-17 14:22 Message: Logged In: YES user_id=21627 The argument of "hundreds of threads" is a red herring. The address space available to each thread typically doesn't depend on the number of threads. Instead, the stack size is pre-determined, so it's vice versa: the number of threads supported depends on that stack-size, which (currently) isn't tunable. Also, stack space is typically a scarce resource only for recursive functions. For leave functions, it doesn't matter, unless a single function consumes the majority of the
[ python-Bugs-1474677 ] non-keyword argument following keyword
Bugs item #1474677, was opened at 2006-04-22 09:11 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1474677&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.5 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) >Assigned to: Jeremy Hylton (jhylton) Summary: non-keyword argument following keyword Initial Comment: def foo(a,b=None):pass foo(b=1,2) With Python 2.5(compiled as of 2006-04-23), this code runs without any error. In older Python(although I didn't check every version of it), I get File "foo.py", line 2 foo(b=1,2) SyntaxError: non-keyword arg after keyword arg -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-24 22:47 Message: Logged In: YES user_id=33168 Jeremy, could you look at this? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1474677&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1474677 ] non-keyword argument following keyword
Bugs item #1474677, was opened at 2006-04-22 09:11 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1474677&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.5 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Jeremy Hylton (jhylton) Summary: non-keyword argument following keyword Initial Comment: def foo(a,b=None):pass foo(b=1,2) With Python 2.5(compiled as of 2006-04-23), this code runs without any error. In older Python(although I didn't check every version of it), I get File "foo.py", line 2 foo(b=1,2) SyntaxError: non-keyword arg after keyword arg -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-24 22:48 Message: Logged In: YES user_id=33168 Confirmed 2.5 behaviour and regression from 2.[34]. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-24 22:47 Message: Logged In: YES user_id=33168 Jeremy, could you look at this? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1474677&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
