Changes by Thomas Wouters tho...@python.org:
Removed file: http://bugs.python.org/file21014/gcc-visibility.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11410
New submission from Thomas Wouters tho...@python.org:
This patch adds support for the GCC visibility attributes to the PyAPI_* macros
(currently only used for Windows.) GCC's default visibility is 'public', but
can be changed to 'hidden' with the '-fvisibility=hidden' argument; see
http
Thomas Wouters tho...@python.org added the comment:
This patch adds support for the GCC visibility attributes to the PyAPI_* macros
(currently only used for Windows.) GCC's default visibility is 'public', but
can be changed to 'hidden' with the '-fvisibility=hidden' argument; see
http
Changes by Thomas Wouters tho...@python.org:
--
Removed message: http://bugs.python.org/msg130144
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11410
Thomas Wouters tho...@python.org added the comment:
Uploaded to Rietveld, too: http://codereview.appspot.com/4260052/
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11410
New submission from Thomas Wouters tho...@python.org:
Fix a (double) typo in the Makefile, which prevents 'make
DESTDIR=relative/path' from working correctly.
--
files: destdir.diff
keywords: easy, needs review, patch
messages: 130146
nosy: twouters
priority: normal
severity: normal
Changes by Thomas Wouters tho...@python.org:
--
resolution: - fixed
status: open - closed
superseder: - Thread shutdown exception in Thread.notify()
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4684
Thomas Wouters tho...@python.org added the comment:
Things getting worse before they get better? http://docs.python.org/ now shows
the 2.7a4 documentation, which is really not good. Perhaps we need some
safeguards to make sure that http://docs.python.org/ is a *stable* version of
the docs? :P
Thomas Wouters tho...@python.org added the comment:
Oh, actually, looks like something was redirecting from docs.python.org to
docs.python.org/dev. It seems fixed now. (It wasn't just me, though, I got
complaints from others that it was 2.7a4 for at least an hour
Changes by Thomas Wouters tho...@python.org:
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8111
___
___
Python-bugs-list mailing list
Changes by Thomas Wouters tho...@python.org:
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8111
___
___
Python-bugs-list mailing list
Thomas Wouters tho...@python.org added the comment:
Nevermind the 2.7a4 comments, I think I'm just not all awake yet. The
complaints I got were about it being 2.6.5c2, my browser showing me 2.7a4 may
have been stupid autocompletion or something. (Still, please fix
New submission from Thomas Wouters tho...@python.org:
docs.python.org is showing the docs for 2.6.5c2. As its most obvious bad
consequence, docs.python.org/download.html doesn't offer any actual downloads,
and there are no obvious (to newbies looking to download docs) links to working
Thomas Wouters tho...@python.org added the comment:
You have a nan in your list of tuples, which screws up the sorting. After the
first sort, elements 580395-7 are:
(0.99257340581672904, 551095),
(nan, 551371),
(6.6494600485570754e-14, 551526),
--
nosy: +twouters
resolution
New submission from Thomas Wouters tho...@python.org:
In order to properly handle multiple threads and fork()-calls from C code
(rather than os.fork()), Python should provide pthread_atfork()-like
functionality: a function to call before a fork, to acquire any locks
that need to be acquired
Thomas Wouters tho...@python.org added the comment:
Checked in the patch to fix the forks-through-os.fork() cases, which
should be most of them. Forks from other C code will need some more work,
created http://bugs.python.org/issue6923 to track that.
--
resolution: - fixed
status
Thomas Wouters tho...@python.org added the comment:
Here's a preliminary fix (also see
http://codereview.appspot.com/96125/show )
--
assignee: - twouters
keywords: +patch
nosy: +twouters
Added file: http://bugs.python.org/file14553/import_lock_fork_deadlock.diff
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'll add some actual tests
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 documentation to
Doc/library/dis.rst? It would also
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
closely to the stack
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 in this case
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, 'w': 12}
(unpacking of dicts in dicts.)
__
Tracker [EMAIL PROTECTED
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 occur
Changes by Thomas Wouters [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file9673/morestar.diff
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2292
__
___
Python-bugs
New submission from Thomas Wouters [EMAIL PROTECTED]:
The attached patch adds the missing *-unpacking generalizations.
Specifically:
a, b, *c = range(5)
*a, b, c = a, b, *c
a, b, c
([0, 1, 2], 3, 4)
[ *a, b, c ]
[0, 1, 2, 3, 4]
L = [ a, (3, 4), {5}, {6: None}, (i for i in range(7, 10
Thomas Wouters [EMAIL PROTECTED] added the comment:
On Sat, Mar 15, 2008 at 9:12 AM, Guido van Rossum [EMAIL PROTECTED]
wrote:
Guido van Rossum [EMAIL PROTECTED] added the comment:
Didn't you say it does sets too? Does this work?
a = [1, 2, 3]
{1, *a, 0, 4} # {0, 1, 2, 3, 4}
Yes
Thomas Wouters [EMAIL PROTECTED] added the comment:
On Sat, Mar 15, 2008 at 9:18 AM, Guido van Rossum [EMAIL PROTECTED]
wrote:
Guido van Rossum [EMAIL PROTECTED] added the comment:
Looking at the flatten() example I'm curious -- how come the output of
flatten(L)
is displayed as a list
Changes by Thomas Wouters:
Removed file: http://bugs.python.org/file9320/dictviews_backport.diff
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1967
__
___
Python-bugs-list
Thomas Wouters added the comment:
After talking to Guido, got rid of the future import magic in favour of
just providing 'viewkeys', 'viewitems' and 'viewvalues' methods of
dicts. This makes efficient 2.6-and-3.0 dict-using code possibly by
making 2to3 translate the view-methods directly to keys
New submission from Thomas Wouters:
Patch to backport dictviews to trunk. Consists of some trickery:
- new 'viewkeys', 'viewvalues' and 'viewitems' methods of dicts,
returning exactly what 'keys', 'values' and 'items' return in 3.0: three
new types defined in dictobject.c
- a future import
Changes by Thomas Wouters:
--
assignee: twouters - nobody
nosy: +nobody
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1067
__
___
Python-bugs-list mailing list
Thomas Wouters added the comment:
I thought I already had, in my reply to Martin and the original comment:
he's right, but I don't care about asyncore or asynchat. I merely
perpetuated the fix that was already in place. The real 'fix' is to
teach both modules about unicode; have them handle
Thomas Wouters added the comment:
I agree, but the change wasn't actually mine. I merely adjusted the
already-implemented strategy to the fact that bytes(str) no longer
works. I think the original change was Jeremy H's.
__
Tracker [EMAIL PROTECTED]
http
Thomas Wouters added the comment:
Well, that's not quite how I implemented the slicing, and it's also not
how the existing simple-slicing was implemented: A negative start index
is taken to mean 0, and a stop index below the start index is taken to
mean 'the start index' (leading to an empty
Thomas Wouters added the comment:
Hmmm Well, that's fine by me, but it changes current behaviour, and
in a way that ctypes own testsuite was testing, even ;) (it does, e.g.,
'p[:4]' in a couple of places.) Requiring the start always would
possibly break a lot of code. We could make only
Thomas Wouters added the comment:
Checked in a slightly newer version.
--
resolution: accepted - fixed
status: open - closed
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1617699
New submission from Thomas Wouters:
test_smtplib fails because asyncore uses bytes(data) where data may be
bytes or str or some undefined type. The attached patch fixes it to the
extend that test_smtplib works again (plus a small fix in test_smtplib
itself.) I'm not sure if this is the right
Thomas Wouters added the comment:
Checked in.
--
resolution: accepted - fixed
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1067
__
___
Python
New submission from Thomas Wouters:
test_cmd_line tests various things by spawning sys.executable.
Unfortunately it does so without passing the -E argument (which 'make
test' does do) so environment variables like PYTHONHOME and PYTHONPATH
can cause the test to fail.
--
assignee
Thomas Wouters added the comment:
Added tests (by duplicating any slicing operations in the test suite
with extended slice syntax, to force the use of slice-objects ;)
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1617699
Changes by Thomas Wouters:
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1617699
_
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman
Changes by Thomas Wouters:
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1617699
_
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman
Thomas Wouters added the comment:
I'd like to check this into the trunk, without the non-step-1 support
for now, so that we can remove simple slicing from the py3k branch. We
can always add non-step-1 support later (all the sooner if someone who
isn't me volunteers to do the painful bits
Thomas Wouters added the comment:
I prefer the current method, as it's more obviously walking in two
strides across the same array. I also dislike hiding the final memmove()
of the tail bit inside the loop. As for which is more obvious, I would
submit neither is obvious, as it took me quite
Thomas Wouters added the comment:
Committed revision 57619.
--
assignee: - twouters
resolution: - fixed
status: open - closed
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1617702
Thomas Wouters added the comment:
Committed revision 57619.
--
assignee: - twouters
resolution: - fixed
status: open - closed
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1617701
Thomas Wouters added the comment:
Committed revision 57619.
--
assignee: - twouters
resolution: - fixed
status: open - closed
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1617698
Thomas Wouters added the comment:
Committed revision 57619.
--
assignee: - twouters
resolution: - fixed
status: open - closed
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1617682
Thomas Wouters added the comment:
Committed revision 57619.
--
assignee: - twouters
resolution: - fixed
status: open - closed
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1617691
Thomas Wouters added the comment:
Committed revision 57619.
--
assignee: - twouters
resolution: - fixed
status: open - closed
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1617700
201 - 250 of 250 matches
Mail list logo
