[issue12972] Color prompt + readline
New submission from Damian :
Hi, when using terminal coloring codes (for instance '\x1b[32mhello
world\x1b[0m' for a green 'hello world') the raw_input function and readline
module behave well except under a very specific use case...
import readline # provides history via up/down
prompt = '\x1b[32m>>> \x1b[0m' # green '>>> ' prompt
while True:
raw_input(prompt)
This provides a green prompt and up/down cycles through prior input. This works
well as long as the input is shorter than the prompt string length (in this
case 13 characters). However, if the input is longer than the prompt then
up/down thinks that the first thirteen rendered characters now belong to the
prompt. For instance...
atagar@fenrir:~/Desktop/arm$ python tmp.py
>>> http://docs.python.org/library/readline
Press up, then down to get back to a blank prompt. You'll have...
>>> http://do
This is probably due to a len() check on the raw_input argument...
>>> len('>>> http://do')
13
>>> len('\x1b[32m>>> \x1b[0m')
13
I'm at a bit of a loss for investigating this further - help would be
appreciated! -Damian
--
messages: 143977
nosy: atagar1
priority: normal
severity: normal
status: open
title: Color prompt + readline
type: behavior
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue12972>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12972] Color prompt + readline
Damian added the comment: Retested with Python 3.1.1 and this issue doesn't manifest. This can be resolved - sorry about the noise. :) -- nosy: +atagar ___ Python tracker <http://bugs.python.org/issue12972> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4787] Curses Unicode Support
New submission from Damian :
Hi, in switching to Python 3.0 I've run into an issue with displaying
Unicode characters via curses. In Python 2.x a simple hello-world looks
like:
#!/usr/bin/python
# coding=UTF-8
import curses
import locale
locale.setlocale(locale.LC_ALL,"")
def doStuff(stdscr):
message = u"hello わたし!"
stdscr.addstr(0, 0, message.encode("utf-8"), curses.A_BLINK)
stdscr.getch() # pauses until a key's hit
curses.wrapper(doStuff)
This works. However, when I try to come up with an equivalent for Python
3.0:
#!/usr/bin/python
import curses
import locale
locale.setlocale(locale.LC_ALL,"")
def doStuff(stdscr):
message = "hello わたし!"
stdscr.addstr(0, 0, message, curses.A_BLINK)
stdscr.getch() # pauses until a key's hit
curses.wrapper(doStuff)
It fails (printing gibberish to the console). It seems that the problem
is that the curses module isn't respecting the system's preferred
encoding (utf-8) which was set via the setlocale function (as per
instructions at
http://docs.python.org/dev/3.0/library/curses.html#module-curses).
My apologies in advance if this is my mistake. Cheers! -Damian
--
components: Unicode
messages: 78563
nosy: atagar1
severity: normal
status: open
title: Curses Unicode Support
type: behavior
versions: Python 3.0
___
Python tracker
<http://bugs.python.org/issue4787>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4787] Curses Unicode Support
Damian added the comment: My OS is Ubuntu 8.04 (Hardy) and the locale is utf-8: >>> locale.setlocale(locale.LC_ALL,"") 'en_US.UTF-8' You do mean the Python 3.0 example didn't work, right? The Python3.0 header is: Python 3.0 (r30:67503, Dec 21 2008, 02:16:52) [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2 in case that makes a difference. ___ Python tracker <http://bugs.python.org/issue4787> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4787] Curses Unicode Support
Damian added the comment: Ack - sorry, typo. I meant "You do mean the Python 3.0 example did work, right?" ___ Python tracker <http://bugs.python.org/issue4787> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4787] Curses Unicode Support
Damian added the comment: Doing a checkout of the trunk - I'll let you know if it works. Thanks! ___ Python tracker <http://bugs.python.org/issue4787> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4787] Curses Unicode Support
Damian added the comment: Just finished recompiling and works perfectly. My hat's off to you - many thanks! -Damian ___ Python tracker <http://bugs.python.org/issue4787> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4787] Curses Unicode Support
Damian added the comment: Looks like this was my mistake, not a bug. According to: http://mail.python.org/pipermail/python-list/2007-July/450133.html Python 2.5 also requires the addition of libcursesw but it was working for the Ubuntu release because they specifically added it. There's no missing functionality - just my mistake. Cheers! -Damian ___ Python tracker <http://bugs.python.org/issue4787> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15126] Theading isAlive() missing version note
New submission from Damian : The threading module's isAlive() method had an is_alive() alias first created in python 2.6. The documentation page doesn't mention this... http://docs.python.org/library/threading.html#threading.Thread.is_alive However, this is noted for other methods like the Event's is_set()... http://docs.python.org/library/threading.html#threading.Event.is_set Very minor issue, just meant that I needed to do a bit of experimentation to figure it out. -- assignee: docs@python components: Documentation messages: 163344 nosy: atagar1, docs@python priority: normal severity: normal status: open title: Theading isAlive() missing version note versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue15126> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15126] Theading isAlive() missing version note
Damian added the comment: I'm gonna hazard the guess that other methods like currentThread() and current_thread() are the same... http://docs.python.org/library/threading.html#threading.current_thread -- ___ Python tracker <http://bugs.python.org/issue15126> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12972] Color prompt + readline
Damian added the comment: Just a quick comment that I ran into this again, but turns out that it's not an issue with python. Rather, this is a quirk with how readline works... https://stackoverflow.com/questions/9468435/look-how-to-fix-column-calculation-in-python-readline-if-use-color-prompt Color prompts need to be wrapped by RL_PROMPT_START_IGNORE and RL_PROMPT_END_IGNORE. -- ___ Python tracker <http://bugs.python.org/issue12972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17059] tarfile.is_tarfile without read permissions raises AttributeError
New submission from Damian:
Hi. While porting a library of mine from python 2.7 to 3.2 I noticed that
tarfile.is_tarfile() now raises an AttributeError rather than IOError when it
lacks read permissions...
atagar@morrigan:~$ touch dummy_file.tar
atagar@morrigan:~$ chmod 000 dummy_file.tar
atagar@morrigan:~$ pwd
/home/atagar
atagar@morrigan:~$ python
Python 2.7.1+ (r271:86832, Sep 27 2012, 21:16:52)
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tarfile
>>> tarfile.is_tarfile("/home/atagar/dummy_file.tar")
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/tarfile.py", line 2583, in is_tarfile
t = open(name)
File "/usr/lib/python2.7/tarfile.py", line 1658, in open
return func(name, "r", fileobj, **kwargs)
File "/usr/lib/python2.7/tarfile.py", line 1720, in gzopen
fileobj = bltn_open(name, mode + "b")
IOError: [Errno 13] Permission denied: '/home/atagar/dummy_file.tar'
atagar@morrigan:~$ python3
Python 3.2 (r32:88445, Oct 20 2012, 14:09:50)
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tarfile
>>> tarfile.is_tarfile("/home/atagar/dummy_file.tar")
Traceback (most recent call last):
File "/usr/lib/python3.2/tarfile.py", line 1805, in gzopen
fileobj = gzip.GzipFile(name, mode + "b", compresslevel, fileobj)
File "/usr/lib/python3.2/gzip.py", line 157, in __init__
fileobj = self.myfileobj = builtins.open(filename, mode or 'rb')
IOError: [Errno 13] Permission denied: '/home/atagar/dummy_file.tar'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.2/tarfile.py", line 2593, in is_tarfile
t = open(name)
File "/usr/lib/python3.2/tarfile.py", line 1739, in open
return func(name, "r", fileobj, **kwargs)
File "/usr/lib/python3.2/tarfile.py", line 1809, in gzopen
fileobj.close()
AttributeError: 'NoneType' object has no attribute 'close'
>>> try:
... tarfile.is_tarfile("/home/atagar/dummy_file.tar")
... except IOError:
... print("caught an IOError")
... except AttributeError:
... print("caught an AttributeError")
...
caught an AttributeError
... easy to work around, but I suspect this wasn't intentional. :)
--
components: None
messages: 180824
nosy: atagar
priority: normal
severity: normal
status: open
title: tarfile.is_tarfile without read permissions raises AttributeError
type: behavior
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue17059>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17105] Python 3.2 segfault
New submission from Damian:
Hi. While porting a library of mine (https://stem.torproject.org/) to python 3
I've been reliably encountering a python segmentation fault while running its
integration tests. After many hours of head scratching I've narrowed the repro
to the following script...
import queue
import socket
class Demo(object):
def __init__(self, control_socket_file):
demo_queue = queue.Queue()
try:
raise ValueError()
except ValueError as exc:
demo_queue.put(exc)
for i in range(20):
control_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
control_socket.connect(("www.google.com", 80))
control_socket_file = control_socket.makefile(mode = "rw", newline = "")
Demo(control_socket_file)
atagar@morrigan:~$ python3 --version
Python 3.2
atagar@morrigan:~$ python3 demo.py
Segmentation fault
Yes, I realise that the script is stupidly convoluted but it was the minimal
amount of code I could get to in order to reproduce the problem. Some things to
note...
* You must have an object that gets a reference to an open socket based file.
* You need to have a try/catch block and enqueue that exception. If you get rid
of the try/catch or enqueue something else then no segfault for you.
* The segfault isn't entirely reliable (seems so happen half the time or so),
hence the loop.
While this repro script is pointless, it's the last issue preventing me from
moving to python 3. At this point I'm out of idea so help would be greatly
appreciated.
Thanks! -Damian
Python: Python 3.2 (r32:88445, Oct 20 2012, 14:09:50)
Platform: Ubuntu 11.04
PS. If the advice is 'upgrade python, 3.2 had some segfault bugs' then a
pointer to those bugs would be appreciated. I've sunk quite a few hours into
this issue so it would be nice to finally figure out what's up.
--
messages: 181190
nosy: atagar
priority: normal
severity: normal
status: open
title: Python 3.2 segfault
type: crash
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue17105>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17105] Python 3.2 segfault
Damian added the comment: Thanks. I snagged the 3.3 tarball from 'http://www.python.org/download/' after your first comment. Compilation just finished and it works there... atagar@morrigan:~$ ~/Desktop/Python-3.3.0/python --version Python 3.3.0 atagar@morrigan:~$ ~/Desktop/Python-3.3.0/python demo.py *sigh* Feel free to resolve this ticket. -- ___ Python tracker <http://bugs.python.org/issue17105> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40033] Just defined class missing from scope
New submission from Damian Yurzola : In the following example the last line throws as 'NameError: name 'Level1A' is not defined' for both 3.7 and 3.8 I assumed that Level1A should already be in scope while defining the insides of Level1B. But it isn't. Is this a bug, or am I missing something? from typing import List, Union class Level0A: pass class Level0B: class Level1A: subs: List[Level0A] class Level1B: subs: List[Level1A] -- components: Interpreter Core messages: 364759 nosy: yurzo priority: normal severity: normal status: open title: Just defined class missing from scope versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue40033> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40033] Just defined class missing from scope
Damian Yurzola added the comment: This is even a better example: Level1A is available to inherit from, but not to type with. Example: from typing import List class Level0A: pass class Level0B: class Level1A: pass class Level1B(Level1A): pass class Level1C: test: Level1A -- ___ Python tracker <https://bugs.python.org/issue40033> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40033] Just defined class missing from scope
Change by Damian Yurzola : -- versions: +Python 3.7 ___ Python tracker <https://bugs.python.org/issue40033> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41447] Resource Tracker in Multiprocessing Shared Memory not working correctly
New submission from Damian Barabonkov :
The way the resource tracker is used in /Lib/multiprocessing/shared_memory.py
leads to it issuing warnings/errors, even when resources are cleaned up
properly.
Attached are two simple demo files copied from the documentation example
(https://docs.python.org/3.9/library/multiprocessing.shared_memory.html) that
illustrate the warnings below:
proc1.py
Traceback (most recent call last):
File "proc1.py", line 19, in
shm.unlink() # Free and release the shared memory block at the very end
File
"/home/damian/Documents/QuantCo/miniconda3/envs/pipeline-parallel/lib/python3.8/multiprocessing/shared_memory.py",
line 244, in unlink
_posixshmem.shm_unlink(self._name)
FileNotFoundError: [Errno 2] No such file or directory: '/shmem'
/home/damian/Documents/QuantCo/miniconda3/envs/pipeline-parallel/lib/python3.8/multiprocessing/resource_tracker.py:218:
UserWarning: resource_tracker: There appear to be 1 leaked shared_memory
objects to clean up at shutdown
warnings.warn('resource_tracker: There appear to be %d '
/home/damian/Documents/QuantCo/miniconda3/envs/pipeline-parallel/lib/python3.8/multiprocessing/resource_tracker.py:231:
UserWarning: resource_tracker: '/shmem': [Errno 2] No such file or directory:
'/shmem'
warnings.warn('resource_tracker: %r: %s' % (name, e))
proc2.py
python3.8/multiprocessing/resource_tracker.py:218: UserWarning:
resource_tracker: There appear to be 1 leaked shared_memory objects to clean up
at shutdown
warnings.warn('resource_tracker: There appear to be %d '
--
files: shmem_bug.py
messages: 374621
nosy: damian.barabonkov
priority: normal
severity: normal
status: open
title: Resource Tracker in Multiprocessing Shared Memory not working correctly
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49351/shmem_bug.py
___
Python tracker
<https://bugs.python.org/issue41447>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38119] resource tracker destroys shared memory segments when other processes should still have valid access
Damian Barabonkov added the comment: As per Guido's comment (https://github.com/python/cpython/pull/21516#issuecomment-668110711), I'm going to use this space to discuss ways to go forward with resource tracking and SharedMemory. Taking inspiration from Vinay (https://bugs.python.org/issue37754#msg351445), I think the simplest and best way forward is to use a small section of the shared memory at the start as a reference counter. Every time a process latches onto a shared memory block, it does and atomic increment to the reference counter. And if it detaches, it does an atomic decrement. This atomic operations are available in C via hardware specific instructions. This would require modifying the Python C code posixshmem.c. It should not be a difficult change. This would then change the SharedMemory API such that a call to `close()` could check the reference count at the end, and aromatically unlink if it reaches 0. Basically, the purpose of the explicit `unlink()` call is dissolved. I think this would also play nice with the current implementation of the `resource_tracker`. A small change would need to take place such that it calls `close()` instead of `unlink()` as the clean up function. Nonetheless, it would keep track if all attachments of shared memory call `close()` at the end, which they should, and issue a warning if they do not. It would do this with the current code, no need to change anything. -- nosy: +damian.barabonkov ___ Python tracker <https://bugs.python.org/issue38119> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38119] resource tracker destroys shared memory segments when other processes should still have valid access
Damian Barabonkov added the comment: Unless the resource_tracker also dies along with the process. In which case, I'm not sure what there is there to do. I believe the resource_tracker actually spawns a process alongside the process that uses it. So if the parent process seg-faults, the resource_tracker should still be alive. -- ___ Python tracker <https://bugs.python.org/issue38119> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38119] resource tracker destroys shared memory segments when other processes should still have valid access
Damian Barabonkov added the comment: Agreed. -- ___ Python tracker <https://bugs.python.org/issue38119> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41904] datetime.datetime.today makes no sense and should be removed
New submission from Damian Yurzola : Last night I discovered we have datetime.datetime.today alongside datetime.datetime.now and datetime.date.today. - datetime.now - date.today Both make semantic sense. datetime.datetime.today returns a datetime, which make no semantic sense and causes confusion. On further inspection of the code, this is due to the fact that datetime inherits from date. so datetime.today is practically an implementation of datetime.now minus the "tz". I think we should implement a datetime.today only to rise an AttributeError or some other way to stop people from using the wrong semantic mental model. We'd also need to remove the documentation entry: https://docs.python.org/3/library/datetime.html#datetime.datetime.today >From this inspection we also find that: datetime.hour/minute/second are unnecessarily redefined. lines Lib/datetime.py#L1606 to datetime.py#L1620 could be removed without any ill effect. date.today: https://github.com/python/cpython/blob/256e54acdbdb26745d4bbb5cf366454151e42773/Lib/datetime.py#L833 https://docs.python.org/3/library/datetime.html#datetime.datetime.today -- components: Library (Lib) messages: 377768 nosy: yurzo priority: normal severity: normal status: open title: datetime.datetime.today makes no sense and should be removed ___ Python tracker <https://bugs.python.org/issue41904> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41904] datetime.datetime.today makes no sense and should be removed
Damian Yurzola added the comment: Thanks for your prompt answer Steven. I was inspired to file this bug after reading through a multiplicity of bugs introduced by folks confused by the library's behavior. So there's good precedent. While granted, the documentation is explicit and the inheritance chain substantiates it. There's nothing more explicit than the function/type names and saying datetime.today() brings, as you say, arbitrary time to the conversation. Which I claim, subjectively, that it should not. Gratuitous breakage, is debatable. It would not be the first or last. It could be a chance to remove a lot of code that works around potentially incorrect mental models. But since both points are to some extent subjective. I'm OK to have left this on the record and move on. What do you say about the unnecessarily redefined properties? Lines Lib/datetime.py#L1606 to datetime.py#L1620 -- ___ Python tracker <https://bugs.python.org/issue41904> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41904] datetime.datetime.today makes no sense and should be removed
Damian Yurzola added the comment: I searched all of github and there seem to be ~350K entries for datetime.today I think this supports steven.daprano point against removal. I could not spot any major library in a quick cursory look. However I do see many calls that look a lot like they should have been datetime.date.today rather than datetime.datetime.today. You see people basically dropping the hours, minutes, secs. And you also see people doing date math on datetime.date.today which will result in different answers through out the day. I like HassanAbouelela's idea that datetime.datetime.today should return an arbitrary fixed time rather than an arbitrary variable time. -- ___ Python tracker <https://bugs.python.org/issue41904> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41904] datetime.datetime.today makes no sense and should be removed
Damian Yurzola added the comment: It took me a while to collect my thoughts but here you go. Advanced users don't have a problem. They'll trade in date or datetime objects explicitly. The "proof" is I could not find any github repo with more than one start that'll call datetime.today(). The less advanced users are sometime doing datetime.today and then all kinds of weird things. HassanAbouelela has a good point: datetime.today() is a straight forward way to get today in a datetime object. On the topic of: > "How long is it until Christmas?" # Current In [7]: datetime.datetime.today() - datetime.datetime.now() Out[7]: datetime.timedelta(days=-1, seconds=86399, microseconds=91) # Hassan's In [16]: datetime.datetime(2020, 12, 25) - datetime.datetime(datetime.datetime.today().year, datetime.datetime.today().month, datetime.datetime.today().day) Out[16]: datetime.timedelta(days=72) Optimizing for the less advanced user, I believe Hassan's proposal yields the more intuitive result. -- ___ Python tracker <https://bugs.python.org/issue41904> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41904] datetime.datetime.today makes no sense and should be removed
Damian Yurzola added the comment: Sorry I got my "current" wrong and I can't find the edit button Here again: > "How long is it until Christmas?" # Current implementation In [23]: datetime.datetime(2020, 12, 25) - datetime.datetime.today() Out[23]: datetime.timedelta(days=71, seconds=53018, microseconds=941806) # Hassan's In [16]: datetime.datetime(2020, 12, 25) - datetime.datetime(datetime.datetime.today().year, datetime.datetime.today().month, datetime.datetime.today().day) Out[16]: datetime.timedelta(days=72) -- ___ Python tracker <https://bugs.python.org/issue41904> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37742] logging.getLogger accepts name='root' leading to confusion
New submission from Damian Yurzola :
'root' should be a reserved name to avoid this:
>>> import logging
>>> a = logging.getLogger()
>>> b = logging.getLogger('root')
>>> a.name
'root'
>>> b.name
'root'
>>> a is b
False
--
components: Library (Lib)
messages: 348877
nosy: yurzo
priority: normal
severity: normal
status: open
title: logging.getLogger accepts name='root' leading to confusion
type: enhancement
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue37742>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7321] PyIter_Check(obj) fails when obj is of type PySetType
New submission from Damian Eads : The instructions for the C interface to the Python set class http://docs.python.org/c-api/set.html say to use PyObject_GetIter and follow the iterator protocol. After following the instructions for the iterator protocol here, http://docs.python.org/c-api/iter.html I was able to successfully iterate through a set object. However, PyIter_Check(obj) returns false yet set objects follow the iterator protocol. Is this the correct behavior? Thank you. Kind regards, Damian Eads -- messages: 95229 nosy: damianeads severity: normal status: open title: PyIter_Check(obj) fails when obj is of type PySetType versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue7321> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26562] Large Involuntary context switches during oom-killer
New submission from Damian Myerscough:
I have been running a simple script inside a Docker container to cause the
container to trigger oom-killer.
>>> mem = {}
>>> for i in range(65535):
... mem[i] = "A" * 65535
When oom-killer is trigger I see a large number of involuntary context switches
and major page faults which causes a spike in CPU
and disk.
# /usr/bin/time --verbose python
Python 2.7.9 (default, Mar 1 2015, 12:57:24)
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> mem = {}
>>> for i in range(65535):
... mem[i] = "A" * 65535
...
Command terminated by signal 9
Command being timed: "python"
User time (seconds): 0.13
System time (seconds): 3.83
Percent of CPU this job got: 17%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:22.94
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 2096516
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 33536
Minor (reclaiming a frame) page faults: 524545
Voluntary context switches: 30706
Involuntary context switches: 137852
Swaps: 0
File system inputs: 8499072
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
I tried the same test using NodeJS/C++ and I could see a lot less involuntary
context switches and major page faults which indicates this could
be a Python issue.
# /usr/bin/time --verbose ./alloc_forever 1024 5 524288000
initial_alloc_amount: 1024, sleep_duration: 5, alloc_amount: 524288000
memory: 501.07MB
memory: 1001.29MB
memory: 1501.19MB
memory: 2001.09MB
Command terminated by signal 9
Command being timed: "./alloc_forever 1024 5 524288000"
User time (seconds): 0.63
System time (seconds): 0.97
Percent of CPU this job got: 7%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:21.61
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 2096536
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 11
Minor (reclaiming a frame) page faults: 524178
Voluntary context switches: 17
Involuntary context switches: 284
Swaps: 0
File system inputs: 336
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
--
messages: 261781
nosy: DamianMyerscough
priority: normal
severity: normal
status: open
title: Large Involuntary context switches during oom-killer
type: resource usage
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5
___
Python tracker
<http://bugs.python.org/issue26562>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26562] Large Involuntary context switches during oom-killer
Damian Myerscough added the comment: @rbcollins there is nothing else running in the Docker container other than the python interpreter. I did an `strace` of the process mmap(NULL, 3149824, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7effc2d0c000 munmap(0x7effc300d000, 790528) = 0 @haypo, this only with Python when it is killed by oom-killer. NodeJS/C++ dont show nearly as many involuntary context switches or page faults. I logged the bug to see if anyone else has encountered this. -- ___ Python tracker <http://bugs.python.org/issue26562> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26562] Large Involuntary context switches during oom-killer
Damian Myerscough added the comment: Thanks for the feedback, I will continue to dig into this. I know processes go crazy sometimes when OOM killer kicks off, I just wanted to rule out a Python bug or if anyone in the community has seen this before. Thanks -- ___ Python tracker <http://bugs.python.org/issue26562> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28674] fosa.zd.dj...@gmail.com
Changes by Damian Kotlar : -- assignee: docs@python components: 2to3 (2.x to 3.x conversion tool), Cross-Build, Demos and Tools, Documentation, Extension Modules, Installation, Interpreter Core, Library (Lib), SSL, Tests, XML, email files: samsungapps.html nosy: Alex.Willmer, barry, docs@python, fosa.zd.dj...@gmail.com, r.david.murray priority: normal severity: normal status: open title: fosa.zd.dj...@gmail.com versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45461/samsungapps.html ___ Python tracker <http://bugs.python.org/issue28674> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
