Hello guys,
I am new to python scripting. I am trying to take data from excel sheet.
To do this I understand that xlrd need to add to the dictionary. I was unable
to do this. I have downloaded the file and stuck there.
Please let me know how can I do this. tell me the procedure.
Regards
On Sun, 27 Apr 2014 00:16:41 -0700, uma mahesh wrote:
Hello guys,
I am new to python scripting. I am trying to take data from excel sheet.
To do this I understand that xlrd need to add to the dictionary. I was
unable to do this. I have downloaded the file and stuck there.
Please let me
Hi, ALL,
I need to perform a subj.
Looking at the Google I found following thread with explanation:
http://stackoverflow.com/questions/36139/how-do-i-sort-a-list-of-strings-in-python
However, doing this in my python shell produces an error:
C:\Documents and Settings\Igor.FORDANWORK\My
Igor Korot wrote:
Hi, ALL,
I need to perform a subj.
Looking at the Google I found following thread with explanation:
http://stackoverflow.com/questions/36139/how-do-i-sort-a-list-of-strings-
in-python
However, doing this in my python shell produces an error:
C:\Documents and
Igor Korot wrote:
Hi, ALL,
I need to perform a subj.
Looking at the Google I found following thread with explanation:
http://stackoverflow.com/questions/36139/how-do-i-sort-a-list-of-strings-in-python
However, doing this in my python shell produces an error:
C:\Documents and
On Friday, 25 April 2014 10:05:03 UTC-4, Chris Angelico wrote:
First culprit I'd look at is the mixing of subprocess and threading.
It's entirely possible that something goes messy when you fork from a
thread.
I liked the theory, but I've run some tests and can't reproduce the error that
On Friday, 25 April 2014 14:58:56 UTC-4, Ned Deily wrote:
FWIW, the Python 2 version of subprocess is known to be thread-unsafe.
There is a Py2 backport available on PyPI of the improved Python 3
subprocess module:
Since that't the only thread that calls anything in subprocess, and I'm
Le samedi 26 avril 2014 15:38:29 UTC+2, Ian a écrit :
On Apr 26, 2014 3:46 AM, Frank Millman fr...@chagford.com wrote:
wxjm...@gmail.com wrote in message
news:03bb12d8-93be-4ef6-94ae-4a02789ae...@googlegroups.com...
==
I wrote once 90 % of Python 2 apps (a
On Mon, Apr 28, 2014 at 12:16 AM, Matthew Pounsett
matt.pouns...@gmail.com wrote:
On Friday, 25 April 2014 10:05:03 UTC-4, Chris Angelico wrote:
First culprit I'd look at is the mixing of subprocess and threading.
It's entirely possible that something goes messy when you fork from a
thread.
Hi Nsihant, I need your help, can I get your email address?
--
https://mail.python.org/mailman/listinfo/python-list
Huh? His email is in his post
On Apr 27, 2014 11:45 AM, ranasa...@gmail.com wrote:
Hi Nsihant, I need your help, can I get your email address?
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
On Wednesday, April 23, 2014 11:29:13 PM UTC+5:30, Rustom Mody wrote:
On Wednesday, April 23, 2014 1:23:00 PM UTC+5:30, Steven D'Aprano wrote:
On Tue, 22 Apr 2014 23:57:46 -0700, Rustom Mody wrote:
On the other hand when/if a keyboard mapping is defined in which the
characters that are
Not visible to me, can you tell me please?
On Sun, Apr 27, 2014 at 8:55 PM, Joel Goldstick joel.goldst...@gmail.comwrote:
Huh? His email is in his post
On Apr 27, 2014 11:45 AM, ranasa...@gmail.com wrote:
Hi Nsihant, I need your help, can I get your email address?
--
On Sun, 27 Apr 2014 22:41:57 +0500, Rana Muhammad Usman wrote:
On Sun, Apr 27, 2014 at 8:55 PM, Joel Goldstick
joel.goldst...@gmail.comwrote:
ranasa...@gmail.com wrote:
Hi Nsihant, I need your help, can I get your email address?
Huh? His email is in his post On Apr 27, 2014 11:45 AM,
E.D.G. edgrs...@ix.netcom.com wrote in message
news:9jydndajlf5n1sdonz2dnuvz_oqdn...@earthlink.com...
A PROPOSED INTERNET-BASED DISASTER ANTICIPATION AND RESPONSE COMPUTER
PROGRAM
Posted by E.D.G. on April 27, 2014
http://www.freewebs.com/eq-forecasting/Disaster_Response_System.html
Thanks for the response and I can certainly see that this old code can be improved, but I
respectfully disagree on the utility of this function. The flexibility of passing any
number of arguments to the function and returning a dictionary is much easier than
writing out dict(x=x, y=y,
On Mon, Apr 28, 2014 at 4:56 AM, Andrew Konstantaras akon...@icloud.com wrote:
Thanks for the response and I can certainly see that this old code can be
improved, but I respectfully disagree on the utility of this function. The
flexibility of passing any number of arguments to the function and
On 4/27/2014 6:40 AM, Kev Dwyer wrote:
Igor Korot wrote:
Hi, ALL,
I need to perform a subj.
Looking at the Google I found following thread with explanation:
http://stackoverflow.com/questions/36139/how-do-i-sort-a-list-of-strings-
in-python
However, doing this in my python shell produces
I guess I am missing something big as I am looking for a shorthand way of doing
the following:
dctA = dict(x=x, y=y, ... n=n)
This is, as I understand it a very natural way of using a dictionary. It seems that this syntax is unnecessarily redundant and hence my goal of writing
On Mon, Apr 28, 2014 at 7:51 AM, Andrew Konstantaras akon...@icloud.com wrote:
I will give the locals approach a try, it seems a little more clumsy than
simply passing the variables to the function.
This is your fundamental misunderstanding that's led to all of this.
You do not pass variables
On Sun, 27 Apr 2014 21:51:54 +, Andrew Konstantaras wrote:
I guess I am missing something big as I am looking for a shorthand way
of doing the following:
dctA = dict(x=x, y=y, ... n=n)
This is, as I understand it a very natural way of using a dictionary.
Would you prefer
On Mon, Apr 28, 2014 at 12:11 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
Suppose we could pass variables directly to the constructor, like this:
a = b = 2
L = [1, 2, 3]
dctA = dict(a, b, L[1], 2, 1+1)
Obviously all five values are 2, but what are the keys?
The dict
paul j3 added the comment:
This patch fixes both help and error formatting.
A module level '_format_metavars' does the formatting for both.
I have tried several alternatives, including using the 'usage' style.
There is similarity between this fix and that for issue 16468 (custom choices),
Jessica McKellar added the comment:
Thanks for reporting this, palm.kevin, and thanks for the patch,
amaury.forgeotdarc.
First, just to be explicit here's a short reproducer:
import sys
sys.stdin = None
help(1)
(Note that to get to the isatty check you need to provide an argument
Charles-François Natali added the comment:
I read again some remarks about alignement, it was suggested to provide
allocators providing an address aligned to a requested alignement. This topic
was already discussed in #18835.
The alignement issue is really orthogonal to the calloc one, so
akira added the comment:
Here's a new patch with a simplified ssl.cert_time_to_seconds()
implementation that brings strptime() back.
The behaviour is changed:
- accept both %e and %d strftime formats for days as strptime-based
implementation did before
- return an integer instead of a float
akira added the comment:
Replace IndexError with ValueError in the patch because tuple.index raises
ValueError.
--
Added file: http://bugs.python.org/file35051/ssl_cert_time_to_seconds-ps5.patch
___
Python tracker rep...@bugs.python.org
STINNER Victor added the comment:
2014-04-27 5:26 GMT+02:00 ivank rep...@bugs.python.org:
(I see the `IOError: [Errno 5] Input/output error` exception now.)
Can you please run your test in strace to see system calls?
--
___
Python tracker
STINNER Victor added the comment:
2014-04-27 10:30 GMT+02:00 Charles-François Natali rep...@bugs.python.org:
I read again some remarks about alignement, it was suggested to provide
allocators providing an address aligned to a requested alignement. This
topic was already discussed in #18835.
Claudiu.Popa added the comment:
In Python 3 docs there is a hint in the documentation for `loadTestsFromModule`:
This method searches module for classes derived from TestCase and creates an
instance of the class for each test method defined for the class.
The phrase with a fixture per test
Claudiu.Popa added the comment:
Ping? The change is clear, has the same semantics and its a little bit faster.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20642
___
Claudiu.Popa added the comment:
Can anyone review this patch?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18039
___
___
Python-bugs-list
Claudiu.Popa added the comment:
Ping. :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18615
___
___
Python-bugs-list mailing list
Unsubscribe:
Charles-François Natali added the comment:
This issue was opened to be able to use tracemalloc on numpy. I would
like to make sure that calloc is enough for numpy. I would prefer to
change the malloc API only once.
Then please at least rename the issue. Also, I don't see why
everything
Charles-François Natali added the comment:
Note to numpy devs: it would be great if some of you followed the
python-dev mailing list (I know it can be quite volume intensive, but
maybe simple filters could help keep the noise down): you guys have
definitely both expertise and real-life
STINNER Victor added the comment:
I wrote a short microbenchmark allocating objects using my benchmark.py script.
It looks like the operation (None,) * N is slower with calloc-3.patch, but
it's unclear how much times slower it is. I don't understand why only this
operation has different
Antoine Pitrou added the comment:
Regarding the *Calloc functions: how about we provide a sane API
instead of reproducing the cumbersome C API?
Isn't the point of reproducing the C API to allow quickly switching from
calloc() to PyObject_Calloc()?
(besides, it seems the OpenBSD guys like the
Stefan Krah added the comment:
Just to add another data point, I don't find the calloc() API
cumbersome.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21233
___
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20230
___
___
Python-bugs-list
STINNER Victor added the comment:
It looks like calloc-3.patch is wrong: it modify _PyObject_GC_Malloc() to fill
the newly allocated buffer with zeros, but _PyObject_GC_Malloc() is not only
called by PyType_GenericAlloc(): it is also used by _PyObject_GC_New() and
_PyObject_GC_NewVar(). The
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1820
___
___
Python-bugs-list
Stefan Krah added the comment:
Actually, I think we have to match the C-API: For instance, in
Modules/_decimal/_decimal.c:5527 the libmpdec allocators are
set to the Python allocators.
So I'd need to do:
mpd_callocfunc = PyMem_Calloc;
I suppose that's a common use case.
--
New submission from Claudiu.Popa:
Due to some bad math on my side, I passed max_workers=0 to
concurrent.futures.ThreadPoolExecutor. This didn't fail properly, but hanged.
The same behaviour occurs in ProcessPoolExecutor, but this time it fails
internally with something like this:
Exception
Claudiu.Popa added the comment:
For instance, multiprocessing behaves like this:
multiprocessing.Pool(-1)
Traceback (most recent call last):
File stdin, line 1, in module
File C:\Python34\lib\multiprocessing\context.py, line 118, in Pool
context=self.get_context())
File
New submission from Armin Ronacher:
I'm trying to write some code that fixes a misconfigured sys.stdin on a case by
case bases but unfortunately I cannot use TextIOWrapper for this because it
always closes the underlying file:
Python
import io
sys.stdin.encoding
'ANSI_X3.4-1968'
stdin =
Claudiu.Popa added the comment:
Added a new patch with improvements suggested by Jim. Thanks!
I removed the handling of processes=1, because it can still be useful: having a
background worker which processes the files received from _walk_dir. Also, it
checks that compile_dir receives a
Charles-François Natali added the comment:
It looks like calloc-3.patch is wrong: it modify _PyObject_GC_Malloc() to
fill the newly allocated buffer with zeros, but _PyObject_GC_Malloc() is not
only called by PyType_GenericAlloc(): it is also used by _PyObject_GC_New()
and
Changes by Steven D'Aprano steve+pyt...@pearwood.info:
--
nosy: -steven.daprano
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16104
___
___
Berker Peksag added the comment:
Can this be closed? (or needs backport to 2.7?
http://hg.python.org/cpython/file/2.7/Lib/io.py#l69)
--
nosy: +berker.peksag
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21225
Claudiu.Popa added the comment:
Add new patch with fixes proposed by Berker Peksag. Thanks for the review.
Hopefully, this is the last iteration of this patch.
--
Added file: http://bugs.python.org/file35055/issue16104_10.patch
___
Python tracker
Charles-François Natali added the comment:
I'm with Antoine, it's likely a glibc bug.
We already had a similar issue with fwrite():
http://bugs.python.org/issue17976
--
nosy: +neologix
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
ivank, if you know some C, perhaps you could write a trivial program that does
an fopen() followed by an fread() of 131072 bytes, and see if the fread()
errors out.
--
___
Python tracker rep...@bugs.python.org
Roundup Robot added the comment:
New changeset 6b912c90de72 by Benjamin Peterson in branch 'default':
say how to run one test (closes #21361)
http://hg.python.org/devguide/rev/6b912c90de72
--
nosy: +python-dev
resolution: - fixed
stage: patch review - resolved
status: open - closed
Tim Golden added the comment:
Committed. Thanks for the patch.
--
resolution: - fixed
stage: - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21349
___
Eric V. Smith added the comment:
I agree with Raymond: this isn't a practical problem worth solving. If it's
causing an actual problem, please re-open this issue and give a use case.
Thanks.
--
nosy: +eric.smith
resolution: - wont fix
status: open - closed
New submission from Armin Ronacher:
The documentation recommends replacing sys.stdin with a binary stream
currently: https://docs.python.org/3/library/sys.html#sys.stdin
This sounds like a bad idea because it will break pretty much everything in
Python in the process.
As example:
import
Roundup Robot added the comment:
New changeset 18cfc2a42772 by Tim Golden in branch '2.7':
Issue #9291 Do not attempt to re-encode mimetype data read from registry in
ANSI mode. Initial patches by Dmitry Jemerov Vladimir Iofik
http://hg.python.org/cpython/rev/18cfc2a42772
--
nosy:
New submission from Paul Sokolovsky:
It caused me a big surprise that asyncio.Task object automatically schedules
itself in the main loop for execution upon creation (i.e. in constructor).
Nowhere in the main reference part of section 18.5.2.4. Task
Roundup Robot added the comment:
New changeset 0c8a7299c7e3 by Tim Golden in branch '2.7':
Issue #9291 Add ACKS NEWS
http://hg.python.org/cpython/rev/0c8a7299c7e3
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9291
STINNER Victor added the comment:
And
http://www.eglibc.org/cgi-bin/viewvc.cgi/trunk/libc/malloc/malloc.c?view=markup
to check that calloc(nelem, elsize) is implemented as calloc(nelem *
elsize)
__libc_calloc() starts with a check on integer overflow.
--
Paul Sokolovsky added the comment:
Based on discussion
https://groups.google.com/forum/#!topic/python-tulip/zfMQIUcIR-0 . That
discussion actually questions the grounds of such Task behavior, and points it
as a violation of Explicit is better than implicit principle, and as
inconsistent
Charles-François Natali added the comment:
__libc_calloc() starts with a check on integer overflow.
Yes, see my previous message:
AFAICT, the two arguments are purely historical (it was used when
malloc() didn't guarantee suitable alignment, and has the advantage of
performing overflow check
New submission from Jon Brandvein:
def foo():
try:
return 1
finally;
return 2
print(foo()) # 2
I've seen this peculiar case discussed on a few blogs lately, but was unable to
find confirmation that this behavior is defined.
In the try/finally section of
Changes by Claudiu.Popa pcmantic...@gmail.com:
Added file: http://bugs.python.org/file35056/issue16104_11.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16104
___
eryksun added the comment:
It works if you detach the buffer beforehand:
import io, sys
stdin = sys.stdin
stdin.flush()
correct_stdin = io.TextIOWrapper(stdin.buffer, 'utf-8')
correct_stdin.readline()
foobar
'foobar\n'
correct_stdin.detach()
Charles-François Natali added the comment:
Thanks for the patch.
That's IMO a good change, but I would only apply it to default, and not
backport it.
--
nosy: +neologix
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21342
Changes by Berker Peksag berker.pek...@gmail.com:
--
nosy: +giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21365
___
Claudiu.Popa added the comment:
Attached patch with improvements suggested by Charles-François Natali. Thank
you for the review.
--
Added file: http://bugs.python.org/file35057/issue21362.patch
___
Python tracker rep...@bugs.python.org
STINNER Victor added the comment:
list: items are allocated in a second memory block. PyList_New() uses memset(0)
to set all items to NULL.
tuple: header and items are stored in a single structure (PyTupleObject), in a
single memory block. PyTuple_New() fills the items will NULL (so write
Charles-François Natali added the comment:
Like Antoine, I'm really skeptical about the backport: honestly, this change
doesn't bring much in a normal application. To run into the number of open file
descriptors limit (so the scalability aspect), one would need to have *many*
concurrent
STINNER Victor added the comment:
Because if a code creates many such objects which basically just do
calloc(), on operating systems with memory overommitting (such as
Linux), the calloc() allocations will pretty much always succeed, but
will segfault when the page is first written to in case of
Nathaniel Smith added the comment:
@Charles-François: I think your worries about calloc and overcommit are
unjustified. First, calloc and malloc+memset actually behave the same way here
-- with a large allocation and overcommit enabled, malloc and calloc will both
go ahead and return the
Charles-François Natali added the comment:
William, thanks for the benchmarks.
Unfortunately this type of benchmark depends on the hardware (disk, SSD, emmoey
bandwitdh, etc).
So I'd suggest, instead of using an hardcoded value, to simply reuse
io.DEFAULT_BUFFER_SIZE.
That way, if some day
Changes by Florent Xicluna florent.xicl...@gmail.com:
--
components: +IO
nosy: +benjamin.peterson, flox, hynek, pitrou, stutzbach
type: - behavior
versions: +Python 3.3, Python 3.4, Python 3.5
___
Python tracker rep...@bugs.python.org
Changes by Florent Xicluna florent.xicl...@gmail.com:
--
nosy: +flox
stage: - patch review
versions: +Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21362
___
Antoine Pitrou added the comment:
Initial introduction is 59cb9c074e09.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21364
___
___
Changes by Claudiu.Popa pcmantic...@gmail.com:
Added file: http://bugs.python.org/file35058/issue21362_1.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21362
___
Roundup Robot added the comment:
New changeset 17df50df62c7 by Tim Golden in branch 'default':
Issue #18314 os.unlink will now remove junction points on Windows. Patch by Kim
Gräsman.
http://hg.python.org/cpython/rev/17df50df62c7
--
nosy: +python-dev
Roundup Robot added the comment:
New changeset 4b97092aa4bd by Tim Golden in branch 'default':
Issue #18314 Add NEWS item.
http://hg.python.org/cpython/rev/4b97092aa4bd
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18314
New submission from Lee Clemens:
Not mentioned (at least not specifically) in the release notes,
multiprocessing.JoinableQueue now requires 'ctx' keyword argument:
def __init__(self, maxsize=0, *, ctx):
This causes an application calling JoinableQueue() to work with 3.3.2 (my
single test)
Lee Clemens added the comment:
Same issue (ctx keyword) occurs with multiprocessing.queues.SimpleQueue
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21367
___
Charles-François Natali added the comment:
@Charles-François: I think your worries about calloc and overcommit are
unjustified. First, calloc and malloc+memset actually behave the same way
here -- with a large allocation and overcommit enabled, malloc and calloc
will both go ahead and
Changes by Claudiu.Popa pcmantic...@gmail.com:
--
nosy: +sbt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21367
___
___
Python-bugs-list mailing
Nick Coghlan added the comment:
Yep, it's scary indeed, but such a long lived feature release is a novel
situation that may require some adjustments to our risk management.
However, we can still decide to defer some of the changes until 2.7.8, even
though the notion of backporting them has been
Tim Golden added the comment:
Backed out the commits after all the Windows buildbots broke. Need to look
further. (No problems on a Win7 or Ubuntu build here).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18314
Antoine Pitrou added the comment:
Just try python -c [i for i in
range(large value)] on a 64-bit machine, I'll bet you'll get a
MemoryError (ENOMEM).
Hmm, I get an OOM kill here.
--
___
Python tracker rep...@bugs.python.org
Nathaniel Smith added the comment:
On my laptop (x86-64, Linux 3.13, 12 GB RAM):
$ python3 -c [i for i in range(9)]
zsh: killed python3 -c [i for i in range(9)]
$ dmesg | tail -n 2
[404714.401901] Out of memory: Kill process 10752 (python3) score 687 or
sacrifice child
Roundup Robot added the comment:
New changeset d42d3d3f9c41 by Guido van Rossum in branch '3.4':
asyncio: Be careful accessing instance variables in __del__ (closes #21340).
http://hg.python.org/cpython/rev/d42d3d3f9c41
New changeset 0cb436c6f082 by Guido van Rossum in branch 'default':
Merge
Charles-François Natali added the comment:
And your test.py produces the same result. Are you sure you don't have a
ulimit set on address space?
Yep, I'm sure:
$ ulimit -v
unlimited
It's probably due to the exponential over-allocation used by the array
(to guarantee amortized constant
Charles-François Natali added the comment:
Dammit, read:
python -c 'bx * (2**48)'
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21233
___
___
Jessica McKellar added the comment:
Thanks for the patches, vladris!
I've reviewed the latest version, and it addresses all of Antoine's review
feedback. Ezio left some additional feedback
(http://bugs.python.org/review/5001/#ps3407) which still needs to be addressed.
--
nosy:
Nick Coghlan added the comment:
Additional environments where the system misreports the encoding to use
(courtesy of Armin Ronacher Graham Dumpleton on Twitter): upstart, Salt,
mod_wsgi.
Note that for more complex applications (e.g. integrated web UIs, socket
servers, sending email), round
Stefan Krah added the comment:
1. _asdict() returns a normal dictionary. I don't know if this is what
is required.
Good question. I don't think we can import OrderedDict from collections
because of the impact on startup time (_collections_abc was created to
avoid the issue for
Nathaniel Smith added the comment:
Right, python3 -c 'bx * (2 ** 48)' does give an instant MemoryError for me.
So I was wrong about it being the VM limit indeed.
The documentation on this is terrible! But, if I'm reading this right:
http://lxr.free-electrons.com/source/mm/util.c#L434
the
Charles-François Natali added the comment:
Alright, it bothered me so I wrote a small C testcase (attached),
which calls malloc in a loop, and can call memset upon the allocated
block right after allocation:
$ gcc -o /tmp/test /tmp/test.c; /tmp/test
malloc() returned NULL after 3050MB
$ gcc
Charles-François Natali added the comment:
So yeah, touching pages can affect whether a later malloc returns ENOMEM.
I'm not sure any of this actually matters in the Python case though :-).
There's still no reason to go touching pages pre-emptively just in case we
might write to them
Antoine Pitrou added the comment:
$ gcc -o /tmp/test /tmp/test.c; /tmp/test
malloc() returned NULL after 3050MB
$ gcc -DDO_MEMSET -o /tmp/test /tmp/test.c; /tmp/test
malloc() returned NULL after 2130MB
Without memset, the kernel happily allocates until we reach the 3GB
user address space
Stefan Krah added the comment:
This is probably offtopic, but I think people who want reliable
MemoryErrors can use limits, e.g. via djb's softlimit (daemontools):
$ softlimit -m 1 ./python
Python 3.5.0a0 (default:462470859e57+, Apr 27 2014, 19:34:06)
[GCC 4.7.2] on linux
Type help,
Charles-François Natali added the comment:
Both OOM here (3.11.0-20-generic, 64-bit, Ubuntu).
Hm...
What's /proc/sys/vm/overcommit_memory ?
If it's set to 0, then the kernel will always overcommit.
If you set it to 2, normally you'd definitely get ENOMEM (which is IMO
much nicer than getting
Charles-François Natali added the comment:
Hm...
What's /proc/sys/vm/overcommit_memory ?
If it's set to 0, then the kernel will always overcommit.
I meant 1 (damn, I need sleep).
--
___
Python tracker rep...@bugs.python.org
1 - 100 of 138 matches
Mail list logo
