New submission from Dino Viehland :
Many Python deployments involve large code based that are used in scenarios
where processes are fork-and-exec'd. When running in these environments code
objects can end up occupying a lot of memory. Because the code objects are on
random pages
Changes by Dino Viehland <di...@microsoft.com>:
--
pull_requests: +2194
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30604>
___
Changes by Dino Viehland <di...@microsoft.com>:
--
pull_requests: +2082
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29943>
___
Changes by Dino Viehland <di...@microsoft.com>:
--
pull_requests: +2080
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30604>
___
New submission from Dino Viehland:
The co_extra_freefuncs are stored in PyThreadState. When calling
_PyEval_RequestCodeExtraIndex you are given a thread specific index. The code
object can then lose it's last reference on a different thread, and the wrong
free function can be called
Dino Viehland added the comment:
I like how this makes the loop opcodes more regular - it should make things
like Pyjion (http://www.github.com/Microsoft/Pyjion) which translate bytecode
into native code. We already have some code (currently commented out) checking
that GET_ITER is followed
New submission from Dino Viehland:
import functools
def f():
def g():
yield 1
return g
functools.partial(f())().__qualname__ != f()().__qualname__
The qualified name gets passed in via the interpreter loop with
_PyEval_EvalCodeWithName calling PyGen_NewWithQualName
New submission from Dino Viehland:
When implementing an iterable object by hand, and raising StopIteration with a
value, the value is not provided as the result of the yield from expression.
This differs from the behavior in the Formal Semantics section. Here's an
example of how it differs
Dino Viehland di...@microsoft.com added the comment:
Antoine: If you're looking at my test.py then my expectation is that this
doesn't crash because a RuntimeError should be raised when the maximum
recursion limit is hit, and then the trace handler should be uninstalled
because it leaks
Dino Viehland di...@microsoft.com added the comment:
It's catching the exception when it invokes x, but the recursion enforcement
should happen at a method prolog, including at the invocation of g. Therefore
if we're at or beyond the recursion limit when invoking the trace handler the
limits
Dino Viehland di...@microsoft.com added the comment:
Maybe there just needs to be a max that it will bump it up?
FYI this isn't actually causing any problems for me, I just ran into it while
doing IronPython development and was surprised to be able to crash the
interpreter w/ pure Python
Dino Viehland di...@microsoft.com added the comment:
One thought might be to do a recursion check (and maybe for multiple frames)
when entering a try rather than incrementing the recursion limit to allow the
handlers to run.
That would cause the exception to be more likely taken before you
New submission from Dino Viehland di...@microsoft.com:
OpenSSL has had many fixes since the 0.9.8l version, and in particular there is
one issue which prevents it from connecting with SSL with a client certificate:
the end result is the SSL connection hangs or times out.
Updating the OpenSSL
Dino Viehland di...@microsoft.com added the comment:
A 1.0 version would be fine w/ me (I tested it with one of those and it worked
as well) - I was just thinking a bug fix release might want to stick w/ a bug
fix release of OpenSSL too
Dino Viehland di...@microsoft.com added the comment:
I ran into a similar issue and believe I have a simpler repro. I think the
issue here might be that when you take a stack overflow inside of a
sys.settrace handler that you can then later violate the stack depth. The
attached test.py has
New submission from Dino Viehland di...@microsoft.com:
subprocess isn't very friendly to implementations with different GCs then
CPython and in general relies on behavior that's not going to be very stable.
I noticed the following issues but was able to work around all of them.
First Popen
New submission from Dino Viehland di...@microsoft.com:
x = bytearray(b'abc')
y = memoryview(x)
del y[0:1]
This crashes CPython 3.1.1 and 2.7.
--
components: Interpreter Core
messages: 115333
nosy: dino.viehland
priority: normal
severity: normal
status: open
title: Del on memoryview
Dino Viehland di...@microsoft.com added the comment:
I've opened a bug in the IronPython bug tracker:
http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=27209
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8825
Dino Viehland di...@microsoft.com added the comment:
Brett Cannon was going to try and look at it and commit it. If you think it
looks good you can commit it :)
I do not yet have commit privledges simply because I need to gen my SSH key and
send that off to Brett. I'm also hoping to get
New submission from Dino Viehland di...@microsoft.com:
This adds new test cases for bugs reported by Thomas Heller against IronPython
for ctypes and winreg:
ctypes: the variant bool type isn't supported
winreg: errno is not correctly set when QueryValue fails
--
assignee: theller
Changes by Dino Viehland di...@microsoft.com:
--
type: - behavior
versions: +Python 3.2
Added file: http://bugs.python.org/file16132/patch30.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7855
Dino Viehland di...@microsoft.com added the comment:
The problem with assertRaises is I need to actually check the errno on the
exception and assertRaises doesn't let me do that.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Dino Viehland di...@microsoft.com added the comment:
I'll switch to the context manager form in the 3.x branch - it looks like
that's not available in the 2.x branch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7855
Changes by Dino Viehland di...@microsoft.com:
Added file: http://bugs.python.org/file16133/patch30.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7855
Dino Viehland di...@microsoft.com added the comment:
Ezio: I'm going to stick w/ assertEqual here as Michael points out these are
different. In particular I want to make sure that you can assign any true
value to the ctypes field but when you read it back you get True or False
regardless
Changes by Dino Viehland di...@microsoft.com:
Added file: http://bugs.python.org/file16134/patch.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7855
Changes by Dino Viehland di...@microsoft.com:
Added file: http://bugs.python.org/file16135/patch30.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7855
Dino Viehland di...@microsoft.com added the comment:
Ahh, so it is in 2.7, apparently I was in a 2.6 enlistment. I've updated the
2.x patch to use the context manager as well.
I've also switched to using assertTrue(x is True) and assertTrue(x is False) so
that it's not checking precisely
New submission from Dino Viehland di...@microsoft.com:
Currently the json module is using the sre_* modules to construct it's
regular expressions instead of just using the re module directly.
Because of this it's taking a dependency on what would appear to be
CPython specific implementation
Changes by Dino Viehland di...@microsoft.com:
--
nosy: +DinoV
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7071
___
___
Python-bugs-list mailing
New submission from Dino Viehland di...@microsoft.com:
from types import ModuleType as M
m = M.__new__(M)
dir(m)
In 2.5 this raises an exception about not having __dict__, 2.6.2
crashes out right.
--
components: Interpreter Core
messages: 91580
nosy: DinoV
severity: normal
status
New submission from Dino Viehland [EMAIL PROTECTED]:
10e667.__format__('+') returns '+1.0#INF'
vs:
10e667.__format__('') which returns 'inf'
The docs say 'inf' is right.
--
messages: 76703
nosy: DinoV
severity: normal
status: open
title: 10e667.__format__('+') should return 'inf
Changes by Dino Viehland [EMAIL PROTECTED]:
--
components: +Interpreter Core
type: - behavior
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4482
New submission from Dino Viehland [EMAIL PROTECTED]:
In 2.6 but not in 3.0 RC2:
x = bytearray(b'abc')
y = x.replace(b'abc', b'bar', 0)
id(x) == id(y)
In 2.6 and in 3.0 RC2:
t = bytearray()
for i in range(256): t.append(i)
x = bytearray(b'')
y = x.translate(t)
id(x) == id(y
101 - 134 of 134 matches
Mail list logo
