Stefan Krah added the comment:
I'm not sure. In the Blaze test suite, 1e7b636b6009 has the SystemError.
4a5b61b0d090 segfaults.
Blaze is pushing Python's dynamic capabilities to absolute limits,
so perhaps this is specific to a few applications only.
For Blaze *itself* there is no difference
Stefan Krah added the comment:
Yes, I'm sure. I even cloned a fresh repo. Also, I tested in
release mode (not --with-pydebug).
https://github.com/blaze/blaze
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
The Blaze test suite segfaults with 4a5b61b0d090.
--
nosy: +skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Stefan Krah <ste...@bytereef.org>:
--
nosy: +ned.deily
priority: normal -> release blocker
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Stefan Krah added the comment:
Agreed. SilentGhost, it's probably best to open new issues for the warnings.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
Probably this one: #23545
--
nosy: +skrah
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.or
Stefan Krah added the comment:
Sorry, Raymond, this is my code area. I said I'll review a patch.
--
assignee: lisroach -> skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.or
Stefan Krah added the comment:
Which Stefan? :)
Anyway, the first half of this issue was centered around the
proposition that fractions are a "better decimal", and the
latest pull request still has the "decimal backend" in it. :)
Fast fractions have been around for a
Stefan Krah added the comment:
Hardly a bad error message, but see #26208.
--
nosy: +skrah
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> decimal C module's exceptions don't match the Python version
type: behavior -&
Stefan Krah added the comment:
The reason is that the benchmark is a softball for fractions. Using the fastest
fraction implementation (gmpy.mpq) and the best printing method for both types,
gmpy.mpq seems to be about 2.5 to 3 times slower than decimal.
It is however easy to generate
Stefan Krah added the comment:
I've left comments on GitHub.
[scoder]
> As I said, where ever exact calculations are needed..
Even if the formatting comment is addressed, the main problem with
this benchmark is that *both* fraction and decimal calculations
are in fact exact here.
You
Stefan Krah added the comment:
"hand written signatures" refers to the signatures that Argument Clinic would
generate if it were used (but I don't want that).
So this is an example of a hand written signature:
"is_infinite($self, /)\n--\n\n\"
I still wonder if peopl
Stefan Krah added the comment:
I'm also not opposed to adding it (-0.000) as long as we rename it to
bm_fractions.py and change the docstring to "based on the telco benchmark".
--
___
Python tracker <rep...@bugs.python.org>
<htt
Stefan Krah added the comment:
I think string conversion should be part of this benchmark, or it should be
renamed to fraction-arith or something.
The formatting function can be a significant bottleneck, and if you use
Fractions for financial calculations the result will still need
Stefan Krah added the comment:
Wow, on my machine this is very stable, great.
The output should be like
http://www.bytereef.org/software/mpdecimal/benchmarks/telco.py ,
but printing one number only should be okay. The important thing is that some
decimal is printed at all to test
Stefan Krah added the comment:
Agreed, the changes are too big for 2.7.
--
resolution: -> wont fix
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Stefan Krah added the comment:
I found the docstrings a bit too verbose (the power() docstring takes up more
than a page), but I'm happy to add it and review a patch.
The patch authors need to take the hand written function signatures into
account.
--
assignee: docs@python -> sk
Stefan Krah added the comment:
#15787. All Python versions have these leaks, which aren't terribly important
in practice.
If it still bothers you, consider writing a Python C extension instead of
"embedding" Python, which is what most people do anyway.
--
status: open
Stefan Krah added the comment:
It is a known problem that PEP 3121 and later similar PEPs address.
Most C extensions leak a (usually very small) amount of memory with
each call to Initialize()/Finalize().
IMO this issue can be closed.
--
nosy: +skrah
Stefan Krah added the comment:
Sorry, I missed issue27587_pystate_addmodule.diff: no new issue in the
updated analysis.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
Pavel did another analysis with the external packages removed. Thanks
for this!
http://www.viva64.com/en/b/0418/
The new analysis found another glitch. Also see my message to
python-committers.
--
nosy: +skrah
Changes by Stefan Krah <ste...@bytereef.org>:
--
nosy: -skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue12345>
___
__
Stefan Krah added the comment:
On Fri, Aug 12, 2016 at 08:38:52PM +, Serge Stroobandt wrote:
> This should not be that difficult to implement?
> I promise, every six months an engineer will stop by here asking for this.
> Instead of nagging, this could already have been implemente
Stefan Krah added the comment:
Aaron, I may be wrong, but I understood this to be something like:
>>> from __future__ import barry_as_FLUFL
>>> 3 <> 10
True
I *do* hope sympy supports that! :-)
--
nosy: +skrah
___
Stefan Krah added the comment:
Your "buffer overflow" png shows the regular "414 request-uri too large"
traceback.
A traceback is not a crash (I wonder if we need an faq for this).
--
nosy: +skrah
resolution: -> not a bug
stage: -> resol
Stefan Krah added the comment:
> after reading the bad standard ...
Make sure not to buy a Power 6 processor and not to use IEEE 754-2008, because
that's essentially what you'll get.
IEEE doesn't specify engineering notation though.
--
___
Pyt
Stefan Krah added the comment:
On Thu, Aug 11, 2016 at 09:29:44AM +, REIX Tony wrote:
> -fno-strict-aliasing -fwrapv for gcc
>
> So, that means that you would get better performance if you applied on Python
> v2.7 what Python v3.5 did about Py_SIZE(x) .
> However, there are
Stefan Krah added the comment:
On Thu, Aug 11, 2016 at 09:17:10AM +, Antti Haapala wrote:
> However the *precision* of decimals is meaningless anyhow. Add a very
> precisely measured '0e0' to any number and the sum also has exponent of 0,
> and is thus never displayed in ex
Stefan Krah added the comment:
In 2.7 we use -fno-strict-aliasing and -fwrapv for gcc. I think it is probably
required to use the equivalent options for xlc.
These are examples of things that have been cleaned up in 3.x. 2.7 actually
relies on these options
Stefan Krah added the comment:
@Antti Please think before you write and stop making unfounded allegations.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
@Antti The behavior follows this standard:
http://speleotrove.com/decimal/decarith.html
Nothing we can do about it even if we wanted to.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Changes by Stefan Krah <ste...@bytereef.org>:
--
stage: patch review -> commit review
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Stefan Krah added the comment:
@Evelyn @koobs Thanks for communicating with the other projects that are
involved in this issue!
Could you double-check that especially the 2.7 patch does exactly what you
want? For 2.7 it's practically a one time chance
Stefan Krah added the comment:
We can of course commit this, but could you also lobby here?
https://llvm.org/bugs/show_bug.cgi?id=18164
I'm seeing this quite often that we fix something here and no one insists on
the upstream bug trackers
Changes by Stefan Krah <ste...@bytereef.org>:
--
assignee: -> skrah
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.5
___
Python tracker <rep...@bugs.python.org>
<http:/
Stefan Krah added the comment:
Yes, I agree this is nicer. Thanks for the patch.
--
nosy: +skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
Марк, sorry for all this negativity. ;)
But I'm also -1. What is wrong with socket.ntohs() etc.?
--
nosy: +skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Stefan Krah <ste...@bytereef.org>:
--
nosy: -skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27604>
___
__
Stefan Krah added the comment:
I can see nothing wrong with msg271168. It's polite, informative, not apodictic
and does not rule out the possibility of accepting a patch.
Also, it answers a direct question from msg271142.
--
nosy: +skrah
___
Python
Changes by Stefan Krah <ste...@bytereef.org>:
--
stage: commit review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
Stefan Krah added the comment:
Apparently sysconfig.get_config_var() is already called in site.py anyway,
so in principle I'm fine with using it here.
In the stdlib it seems to be the first use outside site.py though, and
site.py can be disabled by using "python -S", so perhaps
Stefan Krah added the comment:
Which makes me think that --no-use-wheel should be the default in pip ...
As a Linux user I'm *very* uneasy about this whole binary wheel thing.
--
nosy: +skrah
___
Python tracker <rep...@bugs.python.org>
Stefan Krah added the comment:
Also, IMO the whole capsule mechanism would be broken if function pointers in
dynamic libs could just be invalidated due to reloading.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
These are builtin static types. Even with non-builtin static types, the address
of the type should always be the same. C-extensions aren't reloaded.
--
___
Python tracker <rep...@bugs.python.org>
Stefan Krah added the comment:
The approaches look good, but for clarity I want to replace all method calls
that should never be overridden by the plain C functions of their corresponding
static types.
I have no opinion about the Python version. The diff also "fixes" #26975 for
the
Stefan Krah added the comment:
Strange, why can anyone edit the classification? It happens a lot lately.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
I guess so. Our Rietveld setup apparently has some heuristics that work best
when you're on the default branch and completely synced with the main repo.
--
___
Python tracker <rep...@bugs.python.org>
Stefan Krah added the comment:
Good point about Misc/NEWS: I just regenerated the patch mindlessly to check
the "diff --git" situation :)
Actually, Xavier, it's often better to leave out the NEWS section in the bug
tracker patches and just add it before pushing. Perhaps Rietv
Stefan Krah added the comment:
I did "hg pull -u" before re-generating the diff. Other than that, sometimes
newer mercurial versions behave better (I have 2.8.2).
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
Changes by Stefan Krah <ste...@bytereef.org>:
Added file: http://bugs.python.org/file43660/issue27442-3.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Stefan Krah added the comment:
It looks like the peephole optimizer chokes on some constant folding.
Probably:
INF = float("inf")
NAN = float("nan")
-INF
-NAN
You could try some combinations in the REPL.
--
nosy: +skrah
___
Changes by Stefan Krah <ste...@bytereef.org>:
--
components: +Tests -Build, Installation
resolution: fixed -> duplicate
status: open -> closed
type: compile error -> behavior
___
Python tracker <rep...@bugs.python.org>
&l
Stefan Krah added the comment:
Ah, so the tests pass when you run them manually but "make test"
fails. This looks like
https://bugs.python.org/issue26837 ,
which is fixed in the next release. You can just ignore this
failure, it's harmless.
[BTW, using autoremo
Stefan Krah added the comment:
I think you need tcl8.4-dev and tk8.4-dev and perhaps zlib1g-dev.
Actually the point is that it's expected that some modules don't build
if the corresponding libraries aren't installed.
--
___
Python tracker <
Stefan Krah added the comment:
You need to install at least these development libraries:
sudo apt-get install libssl-dev liblzma-dev libbz2-dev libreadline-dev
libgdbm-dev libffi-dev
Possibly some are missing in this list, tkinter and zip for example.
Use "apt-cache search tkinter"
Stefan Krah added the comment:
I'll look at it soon -- I just don't have much time right now.
--
assignee: -> skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.or
Stefan Krah added the comment:
Let's close it then.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Changes by Stefan Krah <ste...@bytereef.org>:
--
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27006>
___
_
Stefan Krah added the comment:
> PyDec_CheckExact(type) always return 0. Should be PyDec_CheckExact(result).
'result' is always an exact decimal, because your enum example won't work
otherwise.
> And what about other calls of PyDecType_FromFloatExact()? Can they produce
> broken
Stefan Krah added the comment:
Thank you for the detailed summary!
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Stefan Krah added the comment:
posixmodule_3.patch looks good to me. Gregory has already approved the
approach, so I think you can go ahead and commit this.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
man urandom:
"A read from the /dev/urandom device will not block waiting for more entropy.
As a result, if there is not sufficient entropy in the
entropy pool, the returned values are theoretically vulnerable to
a cryptographic a
Stefan Krah added the comment:
On Tue, Jun 07, 2016 at 10:01:16AM +, STINNER Victor wrote:
> Maybe need something like time.get_clock_info(), sys.float_info and
> sys.thread_info for os.urandom(): a string describing the implementation of
> os.urandom(). It would allow the
Stefan Krah added the comment:
I think such warnings should be emitted at application level, similar to the
case when a program refuses to run under UID 0.
If admins wish, they can also integrate such checks into the system startup
sequence (e.g. runlevel 3 is only reached if randomness
Stefan Krah added the comment:
Sorry, I meant *Demian*.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue20408>
___
___
Pyth
Stefan Krah added the comment:
Or pretend in the documentation that it's a positional arg and make it one
later. There is a slight performance difference.
I agree with Damien that probably no one uses the keyword arg.
--
___
Python tracker <
Stefan Krah added the comment:
I've also opened a feature request here:
https://code.google.com/p/android/issues/detail?id=210812
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
Thanks! Closing again.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Stefan Krah added the comment:
Okay thanks, let's assume api-level >= 21 for now. I've moved the include into
pyport.h in order to save a little space everywhere. Could you check if that
works?
--
Added file: http://bugs.python.org/file42944/issue26857.d
Stefan Krah added the comment:
I can only comment on the Windows 10 issue: I think I did the install
with "Right-click -> Run as administrator" and then installed for
all users. Encodings, pip and everything else works here.
--
Stefan Krah added the comment:
Thanks, Georg! The decimal parts look good to me. I understand that
people wonder about the relaxed rules for Decimal -- we have discussed
that here:
https://mail.python.org/pipermail/python-dev/2016-March/143557.html
I don't think that it will be a problem
Changes by Stefan Krah <ste...@bytereef.org>:
--
nosy: +skrah
versions: +Python 3.5, Python 3.6 -Python 3.4
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.o
Changes by Stefan Krah <ste...@bytereef.org>:
--
nosy: -skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26839>
___
__
Stefan Krah added the comment:
How about supporting API >= 23 only? Can people upgrade their devices or do
they have to buy a new one?
--
nosy: +Chi Hsuan Yen
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.or
Stefan Krah added the comment:
As Mark hinted at, many people would say there is no issue at all.
Subclassing like that often breaks the Liskov Substitution Principle.
For more information, see e.g.:
http://okmij.org/ftp/Computation/Subtyping/
"Alas, LSP when considered from an OOP
Stefan Krah added the comment:
It seems to work correctly here for non-binary floats:
>>> from _pydecimal import Decimal
>>> Decimal.from_float(Decimal("1.2"))
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python
Stefan Krah added the comment:
Serhiy, I'm sorry that I overreacted here. You're doing great work for
Python -- we just happen to disagree on this one particular issue.
I think there were some proponents on python-dev, perhaps they'll show
up and discuss the details
Stefan Krah added the comment:
It seems that the patch also introduces a segfault if PyLong_FromSsize_t()
returns NULL.
--
nosy: +skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Stefan Krah <ste...@bytereef.org>:
--
nosy: -skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26871>
___
__
Stefan Krah added the comment:
Your definition of correctness is very odd. The "leaks" you are talking
about are single references in case of a module initialization failure,
in which case you are likely to have much bigger problems.
Please take _decimal out of this patch, it's a was
Stefan Krah added the comment:
I think the current behavior is good for error handling by goto,
which is common for module initialization.
Please don't change this.
--
nosy: +skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Stefan Krah added the comment:
It seems that Android is the only known platform that deviates from
/bin/sh. So perhaps we should simply set a variable to either
/bin/sh or /system/bin/sh rather than waiting for #16353 to settle.
--
nosy: +skrah
versions: +Python 3.6 -Python 3.4
Stefan Krah added the comment:
IOW, on Linux tinfo should work fine in combination with ncursesw.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
Do you need libtinfow? It seems that it's not supported in setup.py,
and getting even libtinfo support into some Linux distributions took
quite a while.
--
nosy: +skrah
___
Python tracker <rep...@bugs.python.org>
Stefan Krah added the comment:
Since Android is the only known system with an odd include path, I
prefer the short patch. In general, let's try to keep patches as
short as possible (which Xavier is already doing).
--
___
Python tracker <
Stefan Krah added the comment:
@shiz: Can we settle on API level 21 or is there any reason to leave this in?
--
nosy: +skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
Thanks again!
--
assignee: -> skrah
nosy: +skrah
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
Stefan Krah added the comment:
Thanks!
--
assignee: -> skrah
nosy: +skrah
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
Stefan Krah added the comment:
Thanks, fixed.
--
assignee: -> skrah
nosy: +skrah
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
Stefan Krah added the comment:
I did not claim that it magically creates entropy. -- Many VMs are throwaway
test beds. It would be annoying to setup some entropy
gathering mechanism just so that Python starts.
--
___
Python tracker <
Stefan Krah added the comment:
It is clear how /dev/urandom works. I just think that securing enough
entropy on startup should be done by the init scripts (if systemd still
allows that :) and not by an application.
[Unless the application is gpg or similar
Stefan Krah added the comment:
Wow, it's by design:
" os.urandom(n)
Return a string of n random bytes suitable for cryptographic use."
``man urandom'':
"A read from the /dev/urandom device will not block waiting for more entropy.
As a result, if there is
Stefan Krah added the comment:
Hmm. Why does os.urandom(), which should explicitly not block, use a blocking
getrandom() function?
This is quite unexpected on Linux.
--
nosy: +skrah
___
Python tracker <rep...@bugs.python.org>
Stefan Krah added the comment:
Okay, for the record: I think that returning "None" would probably be
more correct than the empty string, but I don't think users actually
care to the point that they will introduce a case split in their
applications.
Realistically, probably no one c
Stefan Krah added the comment:
> Maybe issue #26723 can be closed now as well ?
I think it was already closed, but I added a link to this issue now.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.or
Stefan Krah added the comment:
After #26846 _decimal builds on Android.
--
resolution: rejected -> fixed
superseder: -> Workaround for non-standard stdlib.h on Android
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Stefan Krah <ste...@bytereef.org>:
--
assignee: -> skrah
components: +Build -Cross-Build
nosy: +skrah
resolution: -> fixed
stage: -> resolved
status: open -> closed
versions: +Python 3.6 -Python 3.4, Python 3.5
___
P
Stefan Krah added the comment:
We don't support Android officially yet, but I think until #8610
is resolved something must be done here.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Stefan Krah <ste...@bytereef.org>:
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
New submission from Stefan Krah:
Android's stdlib.h pollutes the namespace by including a memory.h header.
--
assignee: skrah
components: Build
messages: 264199
nosy: skrah, xdegaye
priority: normal
severity: normal
status: open
title: Workaround for non-standard stdlib.h on Android
701 - 800 of 3373 matches
Mail list logo
