Antti Haapala added the comment:
mmap is not the problem, the eagerness of munmap is a source of possible
problem.
The munmap eagerness does not show problems in all programs because the arena
allocation heuristics do not work as intended. A proper solution in Linux and
other operating
Antti Haapala added the comment:
I do not believe there is code that would depend on `urlparse(urlstring={})`
*not* throwing an error, since `{}` obviously is neither a URL, nor a string.
Further down the documentation explicitly states that
> The URL parsing functions were origina
Changes by Antti Haapala :
--
nosy: ztane
priority: normal
severity: normal
status: open
title: __reduce__ format
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue26
New submission from Antti Haapala:
This is an annoying heisenbug; it seems that some objects cannot be formatted
until you explicitly do obj.__format__. For example `object.__reduce__` behaves
like this:
Python 2.7.10 (default, Oct 14 2015, 16:09:02)
[GCC 5.2.1 20151010] on linux2
Antti Haapala added the comment:
s/explicitly do/explicitly access/
--
___
Python tracker
<http://bugs.python.org/issue26906>
___
___
Python-bugs-list mailin
Antti Haapala added the comment:
I can reproduce the bug in 3.5.0+ Ubuntu with list iterator, if I execute
python with -S:
% python3.5 -S
Python 3.5.0+ (default, Oct 11 2015, 09:05:38)
[GCC 5.2.1 20151010] on linux
>>> format(iter([]))
Traceback (most recent
Antti Haapala added the comment:
And to the other things failing, I was trying to find out which of the magic
method ops fail, and for that tried to find out the `dir` of list iterator.
Well...
% python3.5 -S
Python 3.5.0+ (default, Oct 11 2015, 09:05:38)
[GCC 5.2.1
Antti Haapala added the comment:
I am not an expert on PyType internals, so I am wondering why is the
PyType_Ready'ing done implicitly at all?
--
___
Python tracker
<http://bugs.python.org/is
Antti Haapala added the comment:
Could it be possible to to make the debug build absolutely abort on any usage
of PyType's that are not readied, usage including instantiating them. Then,
instead of changing all `static` linkages to `extern`s (as in Serhiy's first
patch) one could r
New submission from Antti Haapala:
https://docs.python.org/3/tutorial/modules.html#importing-from-a-package
says that
"The import statement uses the following convention: if a package’s __init__.py
code defines a list named __all__, it is taken to be the list of module names
that shou
New submission from Antti Haapala:
I benchmarked some f'' strings against .format, and surprisingly f'' was slower
than .format in about all the simple cases I could think of. I guess this is
because f'' strings implicitly use `''.join([])`.
The byte co
Antti Haapala added the comment:
This behaviour exists exactly because the return value also contains the
`.hostname`, which for the IPv6 addresses is *without* brackets:
>>> urlparse('http://[::1]:80/').hostname
'::1'
There is no way to get a proper pars
Antti Haapala added the comment:
Casting the pointer is OK, explicitly typing the pointer is even better; then
the arithmetic is even clearer and it is easy to add offsets in words!
However what I'd prefer here as the size of the type is important, to use
`uint16_t` or typedef instead of
Antti Haapala added the comment:
This does apply to all versions of Python from 2.6 up. Registering does work of
course.
I believe the reason for not having the __subclasshook__ is the following
sentence in PEP 3119: "ABCs are intended to solve problems that don't have a
good solut
Antti Haapala added the comment:
well, they wouldn't and shouldn't behave like range. range is a sequence
whereas count or repeat wouldn't necessarily be sequences. (they can be
infinite and thus not having length). And the count shouldn't be *reiterable*
because t
Antti Haapala added the comment:
Would it be enough to just have the message say "takes 1 positional argument
and keyword-only arguments but 2 positional arguments were given"? And this
should of course for **kwargs too.
--
nosy: +ztane
Antti Haapala added the comment:
I am the current maintainer of python-Levenshtein package on PyPI/Github, but I
wrote about 0 % of the functionality; almost everything excepting bug fixes and
Python 3 compatibility was written by the original author David Necas and
possibly contributors; now
Antti Haapala added the comment:
This is *still* there in Hg tip: PyCFunction_Call in Objects/methodobject.c
does not have a case for `METH_KEYWORDS` only at all.
The documentation for METH_KEYWORDS says that it is *typically* coupled with
METH_VARARGS; however not having the case means that
Antti Haapala added the comment:
+1 for this patch, the current documentation states it very wrong.
--
nosy: +ztane
___
Python tracker
<http://bugs.python.org/issue22
Antti Haapala added the comment:
I tried to post a comment on rietveld, but 500 infernal error...
PyUnicode_New(0, 0) will return unicode_empty. If unicode_empty is NULL, then
it will also initialize it. It would be cleanest if unicode_empty was
statically created.
NULL cannot be used as the
Antti Haapala added the comment:
Though it is clean to do like this: let _PyUnicode_JoinArray have `NULL` mean
empty string, as it is more logical anyway; then PyUnicode_Join itself just
needs to:
if (separator == NULL) {
separator = PyUnicode_FromOrdinal(' ');
Antti Haapala added the comment:
There is no need to ifdef anything, the memcpy is the only correct way to do
it. As memcpy is also a reserved identifier in C, the compiler can and will
optimize this into a 64-bit access on those platforms where it can be safely
done so (x86 for example), e.g
Antti Haapala added the comment:
3.5.1+ ubuntu; I run the Popen case in while True, and watch `top` - not a
single digit changes in the memory usage (the last digit being the kilobytes).
That the memory footprint increases *once* by 4KiB is nothing; please run this
in a loop.
--
nosy
Antti Haapala added the comment:
I just noticed that you're actually testing a builtin instead of something in
just module globals. How is the performance with module globals?
--
nosy: +ztane
___
Python tracker
<http://bugs.python.org/is
Antti Haapala added the comment:
Ahhah, the title should say: subprocess module leaks 4kiB memory **per thread**.
--
___
Python tracker
<http://bugs.python.org/issue28
Antti Haapala added the comment:
I wouldn't actually consider the builtin lookup speed almost at all, in all
non-trivial applications the ratio of builtins to any other names will
diminish; and if there is a tight loop, it is possible to always speed it up by
`min = min` if you do not ne
Antti Haapala added the comment:
The title of the issue is still wrong. As I noted before the problem is not
with subprocess leaking 4K memory *always*. The issue comes from the fact that
subprocess seems to leak 4K memory per individual thread. The test code to use
is thus
def test
Antti Haapala added the comment:
I am very negative to this idea. Correct code in Python **2** would either set
`__hash__ = None` or redefine `__hash__` in *any* class that defines `__eq__`.
That it just wasn't used like that is no excuse.
This warning is even more important if eve
Antti Haapala added the comment:
The problem is in `urlunparse`. If you check the RFC 2396, it has the following
regular expression:
^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?
where group 3 is the //netloc, and 4 is netloc substring, of an url
http://netloc/foobar - and
Antti Haapala added the comment:
*I mean the problem exists in `urlparse`, not only in `urlunparse`
--
___
Python tracker
<http://bugs.python.org/issue23
Antti Haapala added the comment:
So you mean that unittest.mock should explicitly set `__hash__ = None`; but
this is already what the unittest.mock does, in Python 3; there is no need to
set `__hash__ = None`; it is the backport that needs to do this in order to
stay compatible. There is no
Antti Haapala added the comment:
Well, as far as I understand, this is a bug in the backport only. The Python
2.6+ backport does not behave identically to Python 3 code in Python 2, unless
`__hash__ = None` is added. unittest.mock in Python 3 is not affected in any
way
Antti Haapala added the comment:
Totally inlined when built with GCC, release mode, there is no trace of the
maybe_small_long symbol, I couldn't even really decipher where it was being
done in the disassembly of longobject.c. Was this the Windows release build?
--
nosy: +
Antti Haapala added the comment:
*wow* isn't this in Python 3 yet (I've been using Zope translationstrings
lately so I didn't know that pgettext is still not supported).
--
nosy: +ztane
___
Python tracker
<http://bugs.py
Antti Haapala added the comment:
Serhiy, you actually did make a mistake above; `'%s' % x` cannot be rewritten
as `f'{x!s}'`, only `'%s' % (x,)` can be optimized...
(just try with `x = 1, 2`)
--
nosy: +ztane
___
Antti Haapala added the comment:
To be more precise, C90, C99, C11 all say that ~"For d, i, o, u, x and X
conversions, if a precision is specified, the 0 flag will be ignored."
--
nosy: +ztane
___
Python tracker
<http://bugs.python.o
Antti Haapala added the comment:
One question is why doesn't it just try to `open`, but wants to stat first,
when the python principle has always been EAFP.
--
nosy: +ztane
___
Python tracker
<http://bugs.python.org/is
Antti Haapala added the comment:
I found the full document on SlideShare:
http://www.slideshare.net/sacobat/tcvn-5712-1993-cng-ngh-thng-tin-b-m-chun-8bit-k-t-vit-dng-trong-trao-i-thng-tin
As far as I can understand, they're "subsets" of each other only in the sense
that VN1
Antti Haapala added the comment:
Ah there was something that I overlooked before - the VN1 and VN2 both have
combining accents too. If I read correctly, the main letter should precede the
combining character, just as in Unicode; VN3 seems to lack combining characters
altogether.
Thus, for
Antti Haapala added the comment:
Someone on Stack Overflow just had a problem where their shell script would
work in shell but get `OSError: [Errno 8] Exec format error` when calling it
with `subprocess.call`. I'd say rather fix this (on POSIX platforms).
Why does Python do path resolvi
Antti Haapala added the comment:
While at it, another POSIX semantic that execvp doesn't support is the
behaviour when `PATH` is not set, e.g. on Linux, the search path is set to '.',
followed by confstr(_CS_PATH). It is debatable whether this is desired (having
current dir
101 - 141 of 141 matches
Mail list logo