Thomas Heller <[EMAIL PROTECTED]> added the comment:
Daniel, IMO you've found a separate bug. I added it as issue #2548.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
Thomas Heller <[EMAIL PROTECTED]> added the comment:
Committed as rev 62143.
--
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
Thomas Heller <[EMAIL PROTECTED]> added the comment:
Committed as rev 62145.
--
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
Thomas Heller <[EMAIL PROTECTED]> added the comment:
On *nix-like systems, ctypes will most likely only compile with gcc.
Since I do not have access to such systems, neither the expertise for
them, this will not change unless someone provides patches.
--
nosy: +t
Thomas Heller <[EMAIL PROTECTED]> added the comment:
I'm curious: Why do you insist on using the sun compiler? Are there
political or technical reasons?
Another thing: in principle it should be possible to build a libffi
shared library with gcc, and use it in a sun-c compiled p
Thomas Wouters <[EMAIL PROTECTED]> added the comment:
Updated patch: reworked some internals, and added generalization of
functioncalls after talking with Guido. *args is now considered just
another positional argument, and can occur anywhere in the positional
argument section. It can also
Changes by Thomas Wouters <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file9673/morestar.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2292>
__
Thomas Wouters <[EMAIL PROTECTED]> added the comment:
No, it's what you asked for in msg63551:
> How about dicts?
> kwds = {'z': 0, 'w': 12}
> {'x': 1, 'y': 2, **kwds} # {'x': 1, 'y': 2, 'z': 0, &#
Thomas Wouters <[EMAIL PROTECTED]> added the comment:
Agreed. A PEP was already on my TODO list (although I don't mind if
someone else picks it up :-) I implemented the
dict-unpacking-in-dict-literal syntax in the mean time; it's pushed to
the starunpack bzr branch, but I&#x
Thomas Wouters <[EMAIL PROTECTED]> added the comment:
On Mon, Apr 7, 2008 at 9:00 PM, Alexander Belopolsky <[EMAIL PROTECTED]>
wrote:
>
> Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
>
> Thomas,
>
> Could you add BUILD_*_UNPACK opcodes document
Changes by Thomas Wouters <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file9970/unnamed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2292>
__
_
Thomas Wouters <[EMAIL PROTECTED]> added the comment:
I'm not sure how this matters. The order of evaluation is the same, the
BUILD_SET implementation just hashes the evaluated items in a different
order. You can't really rely on that particular order as it's tied
Thomas Wouters <[EMAIL PROTECTED]> added the comment:
I don't think the order in which the items are hashed is really what
Raymond was worried about. Rather, the size of the stack was, and the
effect of having all the items on the stack at the same time. I think
Raymond is wrong i
New submission from Thomas Heller <[EMAIL PROTECTED]>:
This patch implements the POINTER() and the pointer() function in C;
giving a speedup of roughly a factor of 2.
--
assignee: theller
components: ctypes
files: ctypes-pointer.diff
keywords: patch, patch
messages: 65356
nosy: t
Thomas Heller <[EMAIL PROTECTED]> added the comment:
I see this also, on Leopard x86. The linker error is not printed on
Tiger PPC. At least, the ctypes test suite does work ok so it may be
that it can be ignored.
Googling for this error, I find that it may be related to linker change
Thomas Heller <[EMAIL PROTECTED]> added the comment:
So closing this as won't fix.
--
resolution: -> wont fix
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http:/
Changes by Thomas Heller <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file9129/ctypes-funcptr.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Thomas Heller <[EMAIL PROTECTED]> added the comment:
Remove useless file (doesn't contain a patch).
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1797>
__
Thomas Heller <[EMAIL PROTECTED]> added the comment:
Committed a slightly modified patch as rev 62338; will also be merged
into py3k.
--
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
New submission from Thomas Heller <[EMAIL PROTECTED]>:
This patch implements a .from_buffer(source, offset=0) class method from
ctypes types. 'source' must expose a writeable buffer interface; the
created ctypes instance will share the internal buffer of the source
object;
Changes by Thomas Heller <[EMAIL PROTECTED]>:
--
type: -> behavior
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2655>
__
___
Python-b
Thomas Heller <[EMAIL PROTECTED]> added the comment:
> The __slots__ member of a class object has the same behavior.
> You may mutate it (even replace it) but this has no effect: only the
> value available when the "class" statement was executed is relevant.
The rules i
Thomas Heller <[EMAIL PROTECTED]> added the comment:
The suggestion by Lenard Lindstrom was an additional method named
'from_buffer_copy'.
__
Tracker <[EMAIL PROTECTED]>
<http://
New submission from Thomas Heller <[EMAIL PROTECTED]>:
Zachary Pincus posted a message about this cyclic reference in ctypes
CFunctionType objects. The reference has the problem that these objects
are cleaned up later than expected.
The attached patch fixes this problem by removing the
Thomas Heller <[EMAIL PROTECTED]> added the comment:
Closing as won't fix.
--
resolution: -> wont fix
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http:/
Thomas Heller <[EMAIL PROTECTED]> added the comment:
> Can you please elaborate your (apparent) concerns about this patch? IOW,
> why did you not check it in?
I have no concerns about the patch, and I am currently committing it.
I'm uploading so that I can points others to i
Thomas Heller <[EMAIL PROTECTED]> added the comment:
Fixed in trunk and py3k, committed as rev 62481 (trunk), rev 62484 (py3k).
I'll leave this open until the decision about backporting to
release25-maint is made.
--
resolution: -> accepted
Thomas Heller <[EMAIL PROTECTED]> added the comment:
>> Can you please elaborate your (apparent) concerns about this patch? IOW,
>> why did you not check it in?
>
> I have no concerns about the patch, and I am currently committing it.
> I'm uploading so tha
Thomas Heller <[EMAIL PROTECTED]> added the comment:
Implemented from_buffer() and from_buffer_copy() as rev 62497 to SVN trunk.
--
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
Changes by Thomas Heller <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10057/from_buffer.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Thomas Heller <[EMAIL PROTECTED]>:
IIUC, the bytes object should be immutable (in contrast to bytearray).
But PyObject_FromWriteBuffer() does not fail.
It seems that the attached patch fixes it; however there are lots of
failures in the testsuite with the patch
Thomas Heller <[EMAIL PROTECTED]> added the comment:
Also fixed in release25-maint, rev 62504.
--
resolution: accepted -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
New submission from Thomas Lee <[EMAIL PROTECTED]>:
The current code in Parser/asdl.py doesn't handle syntax errors very
well. A minor problem to be sure, since the net result is the same (i.e.
build fails), but the error message being displayed is entirely
unhelpful to the deve
Thomas Heller <[EMAIL PROTECTED]> added the comment:
Instead of waiting for review I've committed this as rev 62597.
--
assignee: -> theller
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<htt
Thomas Heller <[EMAIL PROTECTED]> added the comment:
Duplicate of issue #2538.
--
resolution: -> duplicate
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
Changes by Thomas Heller <[EMAIL PROTECTED]>:
--
nosy: +theller
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2538>
__
___
Python-bugs-list mailin
New submission from Thomas Herve <[EMAIL PROTECTED]>:
The problematic change is here:
http://svn.python.org/view/python/trunk/Lib/socket.py?rev=62627&r1=61008&r2=62627
The following script shows the problem:
Python 2.6a2+ (trunk:62707, May 4 2008, 19:13:44)
[GCC 4.2.3 (Ubuntu
Thomas Heller <[EMAIL PROTECTED]> added the comment:
Thanks for your efforts, Christian.
This test needs an object which implements the readonly buffer interface.
Unfortunately the bytes object that I would like to use is broken:
http://bugs.python.org/iss
Thomas Lee <[EMAIL PROTECTED]> added the comment:
I'm working on the AST optimization code for 2.7 (?) in the
tlee-ast-optimize branch. I've since adopted some of the ideas from this
patch, but I'll take another look when I get a chance. The folding
operation is al
Thomas Lee <[EMAIL PROTECTED]> added the comment:
Here's a patch against the 2.x trunk. Basically just dispatches reads of
a partial's __name__ and __doc__ attributes to the underlying function
object.
--
keywords: +patch
nosy: +thomas.lee
Added file: http://bugs.pyth
New submission from Thomas Lee <[EMAIL PROTECTED]>:
For XML elements containing only text data, it would be nice if
toprettyxml could omit the whitespace it normally injects before & after
the text, e.g.
Bob
Becomes:
Bob
>From what I understand th
Thomas Lee <[EMAIL PROTECTED]> added the comment:
I actually agree with the sentiment Georg.
Would it instead be useful to maybe provide a __repr__ implementation
that describes the state of the partially applied function? I guess this
is an entirely different issue, maybe one for python
Thomas Heller <[EMAIL PROTECTED]> added the comment:
[David Lambert]
> > @CFUNCTYPE(c_int, POINTER(c_int), POINTER(c_int))
> > def py_cmp_func(*args):
> > (a,b,) = (t[0] for t in args)
> > print("py_cmp_func", a, b)
> > return a-b
>
Thomas Lee <[EMAIL PROTECTED]> added the comment:
Neal said:
> I was surprised to see the change to the AST, but I understand why you
did it.
The problems David ran into here sound like an argument for arbitrary
AST annotations -- an idea that I was toying with around the time
&q
Thomas Heller <[EMAIL PROTECTED]> added the comment:
I wonder if a patch for ctypes like this (which is not yet complete)
could be used to implement this, or MUST it be implemented in C?
The patch contains a mixin class that implements the numeric methods.
However, the actual operation
New submission from Thomas Lee <[EMAIL PROTECTED]>:
It's important that dependencies of grammar.h get rebuilt if graminit.h
is regenerated (e.g. the Grammar is modified). If these dependencies do
not get rebuilt, the constants associated with each type of parse node
will have inconsis
Thomas Lee <[EMAIL PROTECTED]> added the comment:
Updating affected versions. Probably affects 3.x too.
--
versions: +Python 2.7
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Thomas Heller <[EMAIL PROTECTED]> added the comment:
Has nothing to do with ctypes (the package), unassigning.
--
components: -ctypes
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Thomas Heller <[EMAIL PROTECTED]>:
--
assignee: theller ->
nosy: -theller
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Thomas Heller <[EMAIL PROTECTED]>:
--
assignee: georg.brandl
components: Documentation
files: doc.patch
keywords: patch, patch
nosy: georg.brandl, theller
severity: normal
stage: patch review
status: open
title: Docs for 'y' Py_BuildValue tag are wrong
vers
New submission from Thomas Heller <[EMAIL PROTECTED]>:
ctypes raises UnicodeDecodeError in german windows (it should print
'Unzulässige Funktion'):
>>> from ctypes import FormatError
[46681 refs]
>>> FormatError(1)
Traceback (most recent call last):
File
Thomas Heller <[EMAIL PROTECTED]> added the comment:
The simple patch (ctypes-simple.patch) uses the 'y' format tag for
PyBuild_Value to build a bytes object as error message.
--
keywords: +patch
Added file: http://bugs.python.org/file12129/cty
Thomas Heller <[EMAIL PROTECTED]> added the comment:
The 'better' patch changes the internal FormatError function to return a
wide string; so conversion from ascii to unicode by Python functions is
not needed and it returns strings to the caller:
>>> from ctypes impor
Changes by Thomas Heller <[EMAIL PROTECTED]>:
--
keywords: +needs review
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4429>
___
_
New submission from Thomas Heller <[EMAIL PROTECTED]>:
The following code, which only works on Windows, crashes with an access
violation somewhere in the garbage collector in a debug build:
>>> import _ctypes
[43470 refs]
>>> _ctypes.COMError(1, 2, 3)
The problem is th
Thomas Heller <[EMAIL PROTECTED]> added the comment:
Thanks for the review. I commited the 'better' patch plus a NEWS entry
as svn rev. 67391.
--
resolution: -> fixed
status: open -> closed
type: -> crash
___
Python
Thomas Heller <[EMAIL PROTECTED]> added the comment:
Thanks for the review; committed as svn rev. 67402.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Thomas Heller <[EMAIL PROTECTED]> added the comment:
Currently, the _fields_ of ctypes Structures with non-native byte order
can only contain simple types (like int, char, but not pointers), and
arrays of those.
Since this is all Python code (in Lib/ctypes/endian.py) it should be
possi
Thomas Heller <[EMAIL PROTECTED]> added the comment:
Correction:
>> Since this is all Python code (in Lib/ctypes/_endian.py) it should be
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Thomas Lee <[EMAIL PROTECTED]> added the comment:
A deeper issue here is that Parser/parsetok.c has a dependency on
graminit.h. The problem is that Parser/parsetok.c is a part of the
Parser/pgen program which is actually being used to *generate*
graminit.h in the first place.
This breaks
Thomas Lee <[EMAIL PROTECTED]> added the comment:
I mean pgen's dependency on graminit.h, not the parser's. :)
___
Python tracker <[EMAIL PROTECTED]>
<http://
Thomas Lee <[EMAIL PROTECTED]> added the comment:
okay, so it turns out that putting rules in Grammar/Grammar before the
top-level non-terminals breaks things in a different way.
Attached is another (hopefully final and working) patch.
Added file: http://bugs.python.org/file12185
Thomas Lee <[EMAIL PROTECTED]> added the comment:
Here's a new patch that I believe should fix this issue.
It modifies Makefile.pre.in to include a few additional dependency
declarations for source files that depend on Include/graminit.h and
Include/Python-ast.h, as well as moving en
Thomas Lee <[EMAIL PROTECTED]> added the comment:
Thanks for the review Brett, apologies for the mess.
I'm attaching two new patches -- one for review, the other containing
the generated files. These differ very slightly from the original patch
-- mainly just removing some stuff I
Thomas Lee <[EMAIL PROTECTED]> added the comment:
And here's the patch for review.
Added file: http://bugs.python.org/file12209/build-evilness-fix-03-review.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Thomas Lee <[EMAIL PROTECTED]> added the comment:
Related reading from a few years back:
http://coding.derkeiler.com/Archive/Python/comp.lang.python/2005-05/msg03829.html
--
nosy: +thomas.lee
___
Python tracker <[EMAIL PROTECTE
Thomas Heller <[EMAIL PROTECTED]> added the comment:
Is this really a regression? I do not think so; the libffi library
included with the Python 2.5 ctypes does not support closures on the
arm. See file Modules/_ctypes/libffi/src/arm/ffitarget.h, it contains
'#define FFI
Thomas Heller <[EMAIL PROTECTED]> added the comment:
> It seems that ffi_info moved into ctypes.h: could that have caused the
> breakage?
Not sure what you mean exactly (there is no ffi_info in ctypes.h), but I
assume you are referring to sv
Thomas Heller <[EMAIL PROTECTED]> added the comment:
>> One difficulty with the patch is that the original ctypes code
>> contained a tp_as_number ...
>This can be solved by changing the order of bases for c_ classes.
>See attached.
Cool! Why didn&
New submission from Thomas Heller <[EMAIL PROTECTED]>:
The 2to3 fixer translates this code:
range(42)[::-1]
into this one:
list(range(42)[::-1]
which throws an error when run with Python 3:
Traceback (most recent call last):
File "test.py", line 1, in
print(lis
New submission from Thomas Heller :
Running a bdist_wininst installer that contains a install script, with
python 3, raises an exception. This is displayed in the gui:
ImportError: No module named __builtin__
*** run_installscript: internal error 0x ***
This is probably because the
New submission from Thomas Heller :
Distutils setup function accepts an 'options' named argument which
allows to pass options to subcommands in a dictionary (At the moment I
cannot find where this is documented).
When an empty dictionary is passed, distutils spits out a warning:
C:\s
New submission from Thomas Finley :
This is a patch for the Python 3.1 build checked out from
http://svn.python.org/projects/python/branches/py3k
The current behavior of itertools.combinations(iterable,r) and
itertools.permutations(iterable,r) is to throw a ValueError if iterable
yields fewer
Thomas Finley added the comment:
Hi Raymond, thanks for your well reasoned and thorough reply. Just a
couple small thoughts... I'll borrow your numbers if you don't mind.
1. I'd ask you to discount this argument. There are many situations in
the Python library where em
Thomas Heller added the comment:
Matthias Klose schrieb:
> there are some problems with ctypes.util.find_library(), which I would
> like to see fixed on active branches.
>
> - find_library is not robust, if either objdump or gcc are not
>installed. fixed by raising an e
Thomas Heller added the comment:
The patch is fine, no need for another diff.
--
resolution: -> accepted
versions: +Python 3.1
___
Python tracker
<http://bugs.python.org/iss
Thomas Heller added the comment:
Fixed in release30-maint, rev. 68402 and py3k, rev. 68401.
Thanks for the patch.
--
resolution: accepted -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Changes by Thomas Heller :
--
nosy: +theller
___
Python tracker
<http://bugs.python.org/issue2396>
___
___
Python-bugs-list mailing list
Unsubscribe:
Thomas Lee added the comment:
Brett, any feedback on this one?
___
Python tracker
<http://bugs.python.org/issue4347>
___
___
Python-bugs-list mailing list
Unsubscribe:
Thomas Heller added the comment:
> The distutils version number is now updated automatically by the Python
> release process, so the comment in that file can be removed.
How does this mechanism work? I'm wondering if I should use a similar
mechanism for the ctypes ver
Thomas Lee added the comment:
This would appear to be another build quirk: Lib/symbol.py needs to be
regenerated if Grammar/Grammar changes.
Brett, do you think it would be okay for this file to be generated
automatically as part of the build process? I can't think of any good
reason why
Thomas Heller added the comment:
Fixed in trunk (rev 69505) and release26-maint (rev 69506).
The bug was already fixed in a different way in py3k and release30-maint
although in a different way, I merged this exact fix anyway (rev 69507
and rev 69508).
Thanks.
--
resolution: -> fi
Changes by Thomas Heller :
--
nosy: +theller
___
Python tracker
<http://bugs.python.org/issue1552880>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Thomas Heller :
--
nosy: -theller
___
Python tracker
<http://bugs.python.org/issue850997>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Thomas Guettler :
https://docs.python.org/3.10/library/sys.html#sys.settrace
> Trace functions should have three arguments: frame, event, and arg. frame is
> the current stack frame.
It would be super cool, if "current stack frame" could be a hyperlink to
New submission from Thomas Fischbacher :
The Python reference says:
(1) https://docs.python.org/3/library/exceptions.html#concrete-exceptions
exception AssertionError
Raised when an assert statement fails.
(2) https://docs.python.org/3/reference/simple_stmts.html#the-assert-statement
Thomas Fischbacher added the comment:
The documentation of exceptions in the reference is one of the places that
makes the life of users substantially harder than it ought to be, since the
documentation appears to not have been written with the intent to give
guarantees that users can
New submission from Thomas Grainger :
importing a module with bytes in `sys.path` fails with:
File "", line 182, in _path_isabs
TypeError: startswith first arg must be bytes or a tuple of bytes, not str
(see reproducer in attached demo.py)
however `sys.path` is documented as
Change by Thomas Grainger :
--
components: +Library (Lib)
versions: +Python 3.10, Python 3.11, Python 3.9
___
Python tracker
<https://bugs.python.org/issue47
Change by Thomas Grainger :
--
keywords: +patch
pull_requests: +29993
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/31897
___
Python tracker
<https://bugs.python.org/issu
Thomas Grainger added the comment:
this is a regression from 3.2:
```
Python 3.2.6 (default, Jan 18 2016, 19:21:14)
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tempfile
>>>
Thomas Grainger added the comment:
https://docs.python.org/3/reference/import.html#path-entry-finders says "The
encoding of bytes entries is determined by the individual path entry finders."
see
https://github.com/python/cpython/commit/82c1c781c7ee6496bd4c404b7ba972
Thomas Grainger added the comment:
interestingly bytes filenames pointing to zip files on sys.path do support
bytes (see zipfile_demo.py)
--
Added file: https://bugs.python.org/file50679/zipfile_demo.py
___
Python tracker
<https://bugs.python.
Thomas Grainger added the comment:
zipimporter.zipimporter handles non-bytes paths here:
https://github.com/python/cpython/blob/2cf7f865f099db11cc6903b334d9c376610313e8/Lib/zipimport.py#L65-L67
I think FileFinder should do the same
--
___
Python
New submission from Thomas Grainger :
importing from a bytes zipimport path on sys.path results in a BytesWarning:
Comparison between bytes and string
running the reproducer with `python -b` shows:
python -b zipfile_demo.py
:1345: BytesWarning: Comparison between
bytes and string
see also
Thomas Grainger added the comment:
> I'd advocate for not supporting bytes paths and instead updating the
> documentation to require strings.
I've got PR GH-31934 started to do this
--
message_count: 8.0 -> 9.0
pull_requests: +30026
pull_request: https://github
New submission from Thomas Grainger :
the following code prints:
import sys
import dis
import pprint
def demo():
for i in range(1):
if i >= 0:
pass
class Tracer:
def __init__(self):
self.events = []
def trace(self, frame, event,
Change by Thomas Grainger :
--
keywords: +patch
nosy: +graingert
nosy_count: 4.0 -> 5.0
pull_requests: +30134
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/32044
___
Python tracker
<https://bugs.p
Thomas Fischbacher added the comment:
Addendum
Serhiy, I agree that my assessment was incorrect.
It actually is unittest/mock.py that has quite a few 'raise AssertionError'
that are not coming from an 'assert' keyword statement.
At a deeper level, the problem here i
New submission from Thomas Fischbacher :
>>> help(math.isfinite)
isfinite(x, /)
Return True if x is neither an infinity nor a NaN, and False otherwise.
So, one would expect the following expression to return `True` or `False`. We
instead observe:
>>> math.isfinite(1
501 - 600 of 1791 matches
Mail list logo
