New submission from Julian Taylor jtaylor.deb...@googlemail.com:
./Lib/lib-tk/Tkinter.py:33 has this svn keyword substitution:
__version__ = $Revision$
Due to the change to hg this field is not substituted and makes __version__
quite pointless.
This affects the python 2.7.2rc1
Julian Taylor jtaylor.deb...@googlemail.com added the comment:
matplotlib fails to build due to this with 2.7.2rc1 in ubuntu oneiric (but its
seems simple to fix):
https://launchpad.net/ubuntu/+source/matplotlib/1.0.1-2ubuntu1/+build/2535369
New submission from Julian Taylor jtaylor.deb...@googlemail.com:
using unicode strings for locale.normalize gives following traceback with
python2.7:
~$ python2.7 -c 'import locale; locale.normalize(uen_US)'
Traceback (most recent call last):
File string, line 1, in module
File /usr/lib
Julian Taylor jtaylor.deb...@googlemail.com added the comment:
this is a regression introduced by fixing http://bugs.python.org/issue1813
This breaks some user code,. e.g. wx.Locale.GetCanonicalName returns unicode.
Example bugs:
https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug
Julian Taylor added the comment:
is SHLIB_SUFFIX=.so really correct on mac?
shared libraries have .dylib extension, loadable modules have .so (which would
be EXT_SUFFIX?)
e.g libpython itself uses .dylib.
--
nosy: +jtaylor108
___
Python tracker rep
Julian Taylor added the comment:
I'm going by what says in configure:
# SHLIB_SUFFIX is the extension of shared libraries
The extension of shared libraries on macos is .dylib in most cases (e.g libtool
based libraries and as mentioned python itself)
Maybe its just a documentation/naming issue
Julian Taylor added the comment:
just to clarify its not any issue in python, python is working fine with .so
The issue is just that theses variables tends to be used by other applications
to figure out information on the system (like shared library extension, see
numpy.distutils)
You
New submission from Julian Taylor:
sys.version_info(major=3, minor=3, micro=1, releaselevel='final', serial=0)
In [3]: type(tempfile.TemporaryFile().name)
Out[3]: builtins.int
in python2 it returned a string, this is a somewhat pointless api change which
breaks some third party code, e.g
Julian Taylor added the comment:
I tested the latest patch (python27-gdb_py3.patch) with ubuntu 13.10 gdb
compiled against python3.3, while it fixes the syntax errors it does not fix
the functionality.
E.g. one gets this error on breakpoints:
Python Exception class 'gdb.error
Julian Taylor added the comment:
on further investigation I seem to have screwed up patching the files. Patching
properly they do work. Sorry for the noise.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19308
New submission from Julian Taylor:
the pvariance and variance functions take the argument mu and xbar to pass the
population and sample mean to avoid some recomputation.
I assume the keyword arguments are different because the two means accepted are
different, but the docstring does
Julian Taylor added the comment:
xbar is the *sample* mean of course
maybe with proper docstrings the two functions could also use the same keyword
argument?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20389
Julian Taylor added the comment:
the patch seems to work for me in ipython.
--
nosy: +jtaylor
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3158
Changes by Julian Taylor jtaylor.deb...@googlemail.com:
--
components: +Library (Lib)
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20389
New submission from Julian Taylor:
attached a prototype patch that avoids the memset of ob_item in PyTuple_New
which is not necessary for the BUILD_TUPLE bytecode and PyTuple_Pack as these
overwrite every entry in ob_item anyway.
This improves small tuple creation by about 5%.
It does
Julian Taylor added the comment:
won't replacing _PyObject_GC_Malloc with a calloc cause Var objects
(PyObject_NewVar) to be completely zeroed which I think they didn't before?
Some numeric programs stuff a lot of data into var objects and could care about
python suddenly setting them to zero
Julian Taylor added the comment:
I just tested it, PyObject_NewVar seems to use RawMalloc not the GC malloc so
its probably fine.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21233
Julian Taylor added the comment:
in the case of the median you can archive similar performance to a multiselect
by simply calling min([len(data) // 2 + 1]) for the second order statistic
which you need for the averaging of even number of elements.
maybe an interesting datapoint would
Julian Taylor added the comment:
for median alone a multiselect is probably overkill (thats why I mentioned the
minimum trick)
but a selection algorithm is useful on its own for all of python and then a
multiselect should be considered.
Of course that means it would need to be implemented
Julian Taylor added the comment:
very nice, thanks for adding this.
coincidentally numpy added the same to numpy.distutils independently just a
week later, though numpy also accepts an environment variable to set the number
of jobs.
This is useful for e.g. pip installations where one does
New submission from Julian Taylor:
dictionary creation spends a not insignificant amount of time in malloc
allocating keys objects. Python has a nice small object allocator that avoids a
lot of this overhead and falls back to malloc for larger allocations.
Is there a reason the dictionary does
Julian Taylor added the comment:
attached documentation update patch.
--
keywords: +patch
Added file:
http://bugs.python.org/file38369/0001-Issue-23530-Update-documentation-clarify-relation-of.patch
___
Python tracker rep...@bugs.python.org
http
Julian Taylor added the comment:
PyObject_Malloc just calls malloc above the threshold so there is no problem
for larger dicts.
For larger dicts the performance of malloc is also irrelevant as the time will
be spent elsewhere.
--
___
Python tracker
Julian Taylor added the comment:
certainly for anything that needs good control over affinity psutils is the
best choice, but I'm not arguing to implement full process control in python. I
only want python to provide the number of cores one can work on to make best
use of the available
Julian Taylor added the comment:
oh thats great so python already has what I want. Then just an small
documentation update would be good, I'll have a go at a patch later.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23530
New submission from Julian Taylor:
multiprocessing.cpu_count and os.cpu_count which are often used to determine
how many processes one can run in parallel do not respect the cpuset which may
limit the process to only a subset of online cpus leading to heavy
oversubscription in e.g
Julian Taylor added the comment:
I do agree that its probably safer to not change the default return value.
But adding a option (or new function) would still be good, the number of
available cpus is more often the number you actually want in practice.
To the very least the documentation should
Julian Taylor added the comment:
Your benchmarks are not affected by this change see the other issue. They are
also not representative of every workload out there.
I can at least see the argument why you didn't want to put the other variant of
this change in as it made the code a tiny bit
Julian Taylor added the comment:
ok I ran it again, but note the machine was under use the full time so the
results are likely have no meaning.
python perf.py -r -b default /tmp/normal/bin/python3 /tmp/opt/bin/python3
Min: 0.399279 - 0.376527: 1.06x faster
Avg: 0.410819 - 0.383315: 1.07x
Julian Taylor added the comment:
Large objects are just if size 512: return malloc(size) there is no reason it
should be slower.
Also for large objects allocation speed does not matter as much.
--
___
Python tracker rep...@bugs.python.org
http
Julian Taylor added the comment:
right at best its probably too insignificant to really be worthwhile, closing.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21148
Julian Taylor added the comment:
any comments on the doc changes?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23530
___
___
Python-bugs-list
Julian Taylor added the comment:
the median of median of 5 is quite significantly slower than a quickselect.
numpy implements an introselect which uses quickselect but falls back to median
of median of 5 if not enough progress is done.
In the numpy implementation for 10 element median
Julian Taylor added the comment:
ping, this has been sitting for 4 years and two python releases. Its about time
this stupidly simple thing gets merged.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Julian Taylor added the comment:
glibcs malloc is not obstack, its not a simple linear heap where one object on
top means everything below is not freeable. It also uses MADV_DONTNEED give
sbrk'd memory back to the system. This is the place where MADV_FREE can now be
used now as the latter
Julian Taylor added the comment:
which is exactly what malloc is already doing for, thus my point is by using
malloc we would fullfill your request.
But do you have an actual real work application where this would help?
it is pretty easy to figure out, just run the application under perf
Julian Taylor added the comment:
I know one can change the allocator, but the default is mmap which I don't
think is a very good choice for the current arena size.
All the arguments about fragmentation and memory space also apply to pythons
arena allocator itself and I am not convinced
Julian Taylor added the comment:
simplest way to fix this would be to not use malloc instead of mmap in the
allocator, then you also get MADV_FREE for free when malloc uses it.
The rational for using mmap is kind of weak, the source just says "heap
fragmentation". The usual argument
Julian Taylor added the comment:
it defaulted to 128kb ten years ago, its a dynamic threshold since ages.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Julian Taylor added the comment:
ARENA_SIZE is 256kb, the threshold in glibc is up to 32 MB
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Julian Taylor added the comment:
The api looks good to me. Works fine in numpy.
--
nosy: +jtaylor
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Julian Taylor added the comment:
I don't see any reason why not to.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26530>
___
___
Julian Taylor added the comment:
I am not sure if _PyTraceMalloc_GetTraceback really needs to be a public
function.
Exposing the tracing information should probably just go over python interfaces.
--
___
Python tracker <rep...@bugs.python.org>
Julian Taylor added the comment:
With this changeset it would:
https://github.com/numpy/numpy/pull/8885
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Julian Taylor:
Probably a case of 'don't do that' but reading lines in a compressed files in
binary mode produces bytes with invalid newlines in encodings that where '\n'
is encoded as something else:
with lzma.open("test.xz", "wt", encoding="UTF-
Julian Taylor added the comment:
see also http://bugs.python.org/issue17083
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Julian Taylor added the comment:
on second though not really worth an issue as it is a general problem of
readline on binary streams. Sorry for the noise.
--
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.p
New submission from Julian Taylor:
The debug raw allocator do not return the same alignment as malloc. See
_PyMem_DebugRawAlloc:
https://github.com/python/cpython/blob/master/Objects/obmalloc.c#L1873
The line
return p + 2*SST
adds 2 * sizeof(size_t) to the pointer returned by malloc
Julian Taylor added the comment:
no in numpy it is just a case of using the wrong allocator in a certain spot,
an issue that can be fixed in numpy.
But it is also minor bug/documentation issue in Python itself.
Alignment isn't very important for SIMD any more but there are architectures
where
Julian Taylor added the comment:
The largest type is usually the long double. Its alignment ranges from 4 bytes
(i386) to 16 bytes (sparc).
So Py_MAX (sizeof (size_t), 8) should indeed do it.
--
___
Python tracker <rep...@bugs.python.org>
50 matches
Mail list logo
