date:20081231


Paolo 'Blaisorblade' Giarrusso  added the comment:

== On the patch itself ==
Why don't you use the C preprocessor instead of that Python code?
Sample code:

#define OPCODE_LIST(DEFINE_OPCODE) \
DEFINE_OPCODE(STOP_CODE, 0) \
DEFINE_OPCODE(POP_TOP, 1)   \
DEFINE_OPCODE(ROT_TWO, 2)   \
DEFINE_OPCODE(ROT_THREE, 3) \
DEFINE_OPCODE(DUP_TOP, 4)   \
DEFINE_OPCODE(ROT_FOUR, 5)  \
DEFINE_OPCODE(NOP, 9)   \
...

# define DECL_OPCODE(opcode)\
[opcode] = && label_ ## opcode,

void *opcodes[] = {
OPCODE_LIST(DECL_OPCODE)
};
# undef DECL_OPCODE

There are also other ways to do it, but using higher-order functions
within the preprocessor in this way is something that I learned from the
V8 source code.
It has the advantage that OPCODE_LIST can be used in a lot of other
places (maybe when implementing the 'opcode' module, if it's written in C).

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4797] test_fileio error (windows)

2008-12-31 Thread Hirokazu Yamamoto


New submission from Hirokazu Yamamoto :

This patch fixes this error.

http://www.python.org/dev/buildbot/trunk.stable/x86%20XP-4%
20trunk/builds/1727/step-test/0

==
FAIL: testOpendir (test.test_fileio.AutoFileTests)
--
Traceback (most recent call last):
  File "E:\cygwin\home\db3l\buildarea\trunk.bolen-
windows\build\lib\test\test_fileio.py", line 112, in testOpendir
self.assertEqual(e.filename, ".")
AssertionError: None != '.'

This error doesn't occur on py3k (because wide string is passed) but I 
think It's better to merge the patch into py3k too.

--
components: Windows
files: fix_test_fileio_error.patch
keywords: patch
messages: 78690
nosy: ocean-city
severity: normal
status: open
title: test_fileio error (windows)
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file12515/fix_test_fileio_error.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4753] Faster opcode dispatch on gcc


Paolo 'Blaisorblade' Giarrusso  added the comment:

Topics
1) About different speedups on 32bits vs 64 bits
2) About PPC slowdown
3) PyPI

=== About different speedups on 32bits vs 64 bits ===
An interpreter is very register-hungry, so on x86_64 it spends much less
time on register spill (i.e. moving locals from/to memory), so
instruction dispatch takes a bigger share of execution time. If the rest
of the interpreter is too slow, indirect threading gives no advantage.

Look at the amount of register variables in PyEval_EvalFrameEx() (btw,
do you support any compiler where nowadays 'register' still makes a
difference? That's quite weird). Lots of them are simply cached copies
of fields of the current frame and of the current function; without
copying them to locals, the compiler should assume they could change at
any function call.

In fact, adding locals this way gave huge speedups on tight loops on the
Python interpreter I built with a colleague for our student project, to
experiment with speeding up Python.

And adding a write to memory in the dispatch code (to f->last_i) gave a
20% slowdown. Since my interpreter uses a copying garbage collector and
CPython uses reference counting, which is much slower (if you don't know
this, show me a fast JVM with reference counting), I'm even surprised
you can get such a big speedup from threading.

=== About PPC slowdown ===
Somebody should try the patch on Pentium4 as well.

During our VM course, threading slowed down a toy interpreter with 4 toy
opcodes. Our teachers suggested that with such a small interpreter,
since threaded code takes more space (in that case, ~64 vs ~100 bytes),
this could give problems with code caches, but suggested checking that
idea using performance counters. I'm not sure about why.

I don't have right now neither a Pentium4 nor a PowerPC available, so I
can't check myself. But this is the best way to analyze the performance
unexpected behaviour.

=== PyPI ===
Paolo> (2.5 is in bugfix-only mode, and as far as I can see this patch
Paolo> cannot be accepted there, sadly).

Skip> You could backport it to 2.4 & 2.5 and just put it up on PyPI...
I was thinking to a private backport as well.
I didn't know about PyPI, it looks like PyPI is more for contributed
modules than for this, would that work?

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4753] Faster opcode dispatch on gcc


Paolo 'Blaisorblade' Giarrusso  added the comment:

> You may want to check out issue1408710 in which a similar patch was
> provided, but failed to deliver the desired results.
It's not really similar, because you don't duplicate the dispatch code.
It took me some time to understand why you didn't change the "goto
fast_next_opcode", but that's where you miss the speedup.

The only difference with your change is that you save the range check
for the switch, so the slowdown probably comes from some minor output
change from GCC I guess.

Anyway, this suggests that the speedup really comes from better branch
prediction and not from saving the range check. The 1st paper I
mentioned simply states that saving the range check might make a small
differences. The point is that sometimes, when you are going to flush
the pipeline, it's like adding a few instructions, even conditional
jumps, does not make a difference. I've observed this behaviour quite a
few times while building from scratch a small Python interpreter.

I guess (but this might be wrong) that's because the execution units
were not used at their fullest, and adding conditional jumps doesn't
make a differeence because flushing a pipeline once or twice is almost
the same (the second flush removes just few instructions). Or something
like that, I'm not expert enough of CPU architecture to be sure of such
guesses.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4753] Faster opcode dispatch on gcc


Paolo 'Blaisorblade' Giarrusso  added the comment:

Some other comments.
The time saving of indirect threading are also associated with the
removal of the range check, but better branch prediction is the main
advantage.

> Also, the macro USE_THREADED_CODE should be renamed to something else;
> the word "thread" is too tightly associated with multi-threading.

That's true.

> Furthermore, threaded code simply refers to code consisting only of
> function calls. Maybe, USE_COMPUTED_GOTO or USE_DIRECT_DISPATCH would be
> better.

I'd prefer USE_DIRECT_DISPATCH (or better, USE_THREADED_DISPATCH) rather
than USE_COMPUTED_GOTO, since the latter is just the used language
construct.

"indirect threading" is the standard name in CS literature to define
this technique. "Direct threading" is a variation where in the bytecode
array, opcode is replaced by the pointer opcode_handler[opcode], so that
dispatch is slightly faster. Most interpreters use indirect threading to
save memory, and because it enables to switch the opcode handlers table
to activate for instance debugging.

The best paper about this is:
"The Structure and Performance of Efficient Interpreters, M. Anton Ertl
and David Gregg, 2003".

The original paper about (direct) threaded code is this:
"Threaded Code, James R. Bell, Comm. of ACM, 1973", but I don't feel it
relevant at all today.
Indirect threading was introduced in "Indirect Threaded Code, Robert B.
K. Dewar, Communications of the ACM, 1975" (that's just a bit more
relevant, but still).

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4753] Faster opcode dispatch on gcc


Skip Montanaro  added the comment:

Paolo> (2.5 is in bugfix-only mode, and as far as I can see this patch
Paolo> cannot be accepted there, sadly).

You could backport it to 2.4 & 2.5 and just put it up on PyPI...

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4572] add SEEK_* values to io and/or io.IOBase


Changes by Benjamin Peterson :


--
versions:  -Python 3.0

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4753] Faster opcode dispatch on gcc


Paolo 'Blaisorblade' Giarrusso  added the comment:

Mentioning other versions as well.
The patch is so easy that it can be backported to all supported
versions, so I'm adding all of them (2.5 is in bugfix-only mode, and as
far as I can see this patch cannot be accepted there, sadly).

--
versions: +Python 2.6, Python 2.7, Python 3.0

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4753] Faster opcode dispatch on gcc


Changes by Paolo 'Blaisorblade' Giarrusso :


--
nosy: +blaisorblade

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3433] libtk

2008-12-31 Thread Mitchell Model


Changes by Mitchell Model :


--
title: Mac, 3.0 framework install error with fink cp -> libtk

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4522] Module wsgiref is not python3000 ready (unicode issues)


Antoine Pitrou  added the comment:

Resolution is more advanced in #4718.

--
nosy: +pitrou
resolution:  -> duplicate
status: open -> closed
superseder:  -> wsgiref package totally broken

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3266] Python-2.5.2/Modules/mmapmodule.c:915: error: `O_RDWR' undeclared


Changes by Antoine Pitrou :


--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

2008-12-31 Thread pmoody


pmoody  added the comment:

> I'm not sure which API in netaddr you're referring to.  If you want to
> construct that /24 with netaddr, then I would use
> netaddr.address.CIDR("1.1.1.0/24").  Offhand, I can't find an API which

netaddr.AddrRange

class AddrRange(__builtin__.object)
 |  A block of contiguous network addresses bounded by an arbitrary start and
 |  stop address. There is no requirement that they fall on strict bit mask
 |  boundaries, unlike L{CIDR} addresses.
 |

 |  __init__(self, first, last, klass=)
 |  Constructor.
 |
 |  @param first: start address for this network address range.
 |
 |  @param last: stop address for this network address range.
 |
 |  @param klass: (optional) class used to create each object returned.
 |  Default: L{Addr()} objects. See L{nrange()} documentations for
 |  additional details on options.

when looking through the code.google.com wiki, I couldn't find any
examples of creating addresses with netmasks and AddrRange was the
first thing I found when looking through pydoc.

> accepts two endpoints of a range to construct a network in netaddr.
> When I wrote about having separate types for individual addresses vs
> ranges of addresses in my previous comment, I had IP and CIDR
> respectively in mind, as opposed to ipaddr-py's single IPv4 class which
> can represent either.

and still having two separate classes represent the same thing seems odd to me.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3680] Cycles with some iterator are leaking.


Changes by Antoine Pitrou :


--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3976] pprint._safe_repr is not general enough in one instance


Antoine Pitrou  added the comment:

For this to be integrated, it should also add an unit test.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4035] Support bytes for os.exec*()


Antoine Pitrou  added the comment:

Hmm, I think the supported types should be the same for all platforms,
otherwise it creates unnecessary headaches.

Perhaps, in addition to the proposed behaviour on Posix (convert
everything to bytes if the program name is a bytes object), the reverse
could be done under Windows (convert the program name to str if it is a
bytes object).

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

2008-12-31 Thread Jean-Paul Calderone


Jean-Paul Calderone  added the comment:

> hm, all addresses have a subnet, even if its an implied /32, so
specifying a network as ("1.1.1.0", "1.1.1.255") seems a lot more
off-putting than "1.1.1.0/24". You're also much more likely to see the
latter in network devices.

I'm not sure which API in netaddr you're referring to.  If you want to
construct that /24 with netaddr, then I would use
netaddr.address.CIDR("1.1.1.0/24").  Offhand, I can't find an API which
accepts two endpoints of a range to construct a network in netaddr. 
When I wrote about having separate types for individual addresses vs
ranges of addresses in my previous comment, I had IP and CIDR
respectively in mind, as opposed to ipaddr-py's single IPv4 class which
can represent either.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4272] set timestamp in gzip stream


Antoine Pitrou  added the comment:

test_literal_output looks really too strict to me. At most, you could
check that the header and trailer are unchanged, but it would probably
make it equivalent to test_metadata.
Other than that, I think it's an useful addition.

--
nosy: +pitrou
priority:  -> normal
stage:  -> patch review
versions: +Python 2.7, Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4572] add SEEK_* values to io and/or io.IOBase


Antoine Pitrou  added the comment:

Sounds like a nice improvement.

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

2008-12-31 Thread pmoody


pmoody  added the comment:

hm, all addresses have a subnet, even if its an implied /32, so
specifying a network as ("1.1.1.0", "1.1.1.255") seems a lot more
off-putting than "1.1.1.0/24". You're also much more likely to see the
latter in network devices. I guess I don't see the utility in an address
range of .1 - .22 (or something arbitrary, something which doesn't fall
on a power-of-2 boundary); when dealing with ranges of addresses, i've
always only wanted to/needed to manipulate sub-networks of addresses.

and my expectation was always that method names, etc. would have to be
converted to more closely match other python code; ipaddr was written to
google's python style guide, which I understand can be different than
the python.org style guide ;)

also, ipaddr does make extensive use of pydoc, but you're right, the
webpage is spartan.

happy (PST) new year.

Cheers,
/peter

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1664] nntplib is not IPv6-capable


Antoine Pitrou  added the comment:

I was going to suggest writing a test but I see that nntplib hasn't got
a single unit test :-O

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

2008-12-31 Thread Jean-Paul Calderone


Jean-Paul Calderone  added the comment:

Performance shouldn't be a major concern here.  Utility is more
important and the implementation can be optimized later.

My initial impression of netaddr is pretty good.  One thing it has going
for it is documentation.  The netaddr google page gives a really great
overview of the functionality provided.  In comparison, the ipaddr-py
page is extremely sparse; the documentation in the repository is no
better (as there isn't really any).

There are a lot of minor things about ipaddr-py which are off-putting. 
It uses a naming convention that's not like any real Python software I'm
familiar with.  In particular, CamelCase method names really draw the
eye (in a bad way) and distract from the actual functionality being
provided.  I assume that if ipaddr-py is selected for inclusion, the API
will be adapted to fit PEP 8.  In comparison, netaddr appears to largely
comply with PEP 8 already.

Regarding the treatment of addresses versus address ranges, I prefer
netaddr's solution.  An address is not the same as an address range.  It
seems odd to try to represent them both with the same type as ipaddr-py
does.  This feels somewhat APLesque (where everything is a vector),
which isn't bad in itself, but generally if I want to manipulate an IP
address, I'm not thinking about it as a list of one address.  If I
wanted to do that, then I'd make a list and put the address in it.  By
comparison, the separate CIDR type in netaddr makes a lot of sense.  It
preserves a memory-efficient representation of the address range, but
does it with a different type than the fundamental address type.

This is far from a complete review of either library, obviously.  I've
done little more than glance over the documentation of each and do a
small amount of interactive playing around.  A lot more effort seems to
have gone into making netaddr accessible and appealing, and I think it
has succeeded.  Perhaps if some documentation for ipaddr-py is written
it will be easier to see where that library excels.  Of course, I assume
this is a prerequisite for inclusion in the standard library as well.

--
nosy: +exarkun

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4795] inspect.isgeneratorfunction inconsistent with other inspect functions


Raymond Hettinger  added the comment:

This can be simplified to just:

return (isfunction(object) or ismethod(object)) and \
 object.func_code.co_flags & CO_GENERATOR

No need for patterns like:

  if cond:
 return True
  return False

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

2008-12-31 Thread pmoody


pmoody  added the comment:

I'm biased ;) but I don't see what netaddr provides over ipaddr.  it
also seems to be in the neighborhood of 50% slower (at least on my mac
mini).

pmo...@mini - 04:52 PM - ~/Downloads/ipaddr-1.0.1
-> python -m timeit 'import ipaddr;\
ipaddr.IP("1.1.1.1")'
1 loops, best of 3: 46.2 usec per loop

pmo...@mini - 04:52 PM - ~/Downloads/netaddr-0.5.2
-> python -m timeit 'import netaddr;\
netaddr.IP("1.1.1.1")'
1 loops, best of 3: 71.9 usec per loop

dealing with netmasks, the difference is even greater.
pmo...@mini - 04:52 PM - ~/Downloads/ipaddr-1.0.1
-> python -m timeit 'import ipaddr;\
ipaddr.IP("1.1.1.1/255.255.255.0")'
1 loops, best of 3: 78.4 usec per loop

pmo...@mini - 04:49 PM - ~/Downloads/netaddr-0.5.2
-> python -m timeit 'import netaddr;\
> netaddr.IP("1.1.1.1/255.255.255.0")'
1000 loops, best of 3: 247 usec per loop

(and it doesn't seem to deal with hostsmasked addresses).

it also seems to be layed out in an unintuitive way, treating address
ranges a something very different than network addresses. hopefully
someone who isn't intimately familiar with both libraries can comment,
but ipaddr feels a lot cleaner to me.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4781] The function, Threading.Timer.run(), may be Inappropriate

2008-12-31 Thread Gabriel Genellina


Gabriel Genellina  added the comment:

Note that doing this would change the class semantics.
Timer "[...] represents an action that should be run only after a 
certain amount of time has passed — a timer." and the example clearly 
shows that the action is run *once*. 

Timer is basically an example of how to write custom Thread 
subclasses; if you want a "repetitive action", you may easily write a 
subclass based on the code you posted. Not every useful class must be 
in the standard library...

--
nosy: +gagenellina

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4796] Decimal to receive from_float method


Raymond Hettinger  added the comment:

FYI, there is already a lossless implementation in the docs:

def float_to_decimal(f):
"Convert a floating point number to a Decimal with no loss of
information"
n, d = f.as_integer_ratio()
with localcontext() as ctx:
ctx.traps[Inexact] = True
while True:
try:
   return Decimal(n) / Decimal(d)
except Inexact:
ctx.prec += 1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4796] Decimal to receive from_float method


Raymond Hettinger  added the comment:

The decimal constructor should be lossless.  The underlying spec was
designed with the notion that all numbers in decimal are exact;
operations can be lossy but the numbers themselves are exact. 
Accordingly, I recommend Decimal.from_float(f) with no qualifiers or
optional arguments.

To support the use case of wanting to round the input, I suggest a
separate method modeled on Context.create_decimal().  It can either be
an extension of the existing method or a new method like
Context.create_decimal_from_float().  I recommend the former since
rounding is already implied by the context qualifier.  Either way, the
effect would be the same as Decimal.from_float(f) + 0 in a given
context.  Per the docs:  "Creates a new Decimal instance from num but
using self as context. Unlike the Decimal constructor, the context
precision, rounding method, flags, and traps are applied to the conversion."

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4738] Patch to make zlib-objects better support threads


Antoine Pitrou  added the comment:

Same comment about potential deadlocks as in #4751.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4751] Patch for better thread support in hashlib


Antoine Pitrou  added the comment:

Actually, your code can deadlock since ENTER_HASHLIB doesn't release the
GIL. Think about it:

// Thread A is here, holding the GIL and waiting for self->lock to be 
// released by thread B
ENTER_HASHLIB(self)
Py_BEGIN_ALLOW_THREADS
// Thread B is here, holding self->lock and waiting for the GIL to be
// released by thread A
Py_END_ALLOW_THREADS
LEAVE_HASHLIB(self)

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4795] inspect.isgeneratorfunction inconsistent with other inspect functions


Benjamin Peterson  added the comment:

Fixed in r68112.

--
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3023] Problem with invalidly-encoded command-line arguments (Unix)

2008-12-31 Thread Gabriel Genellina


Changes by Gabriel Genellina :


--
nosy: +gagenellina

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

2008-12-31 Thread David Moss


David Moss  added the comment:

I think this might be worth a look before any hard and fast decisions
are made :-

http://code.google.com/p/netaddr/

--
nosy: +drkjam

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4751] Patch for better thread support in hashlib


Antoine Pitrou  added the comment:

Based on quick testing on my computer, we could probably put the limit
as low as 1KB. But it may be that locks are cheap under Linux.
In any case, the patch looks good, but I'm no OpenSSL expert.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4751] Patch for better thread support in hashlib


Changes by Antoine Pitrou :


--
nosy: +gps

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4796] Decimal to receive from_float method


Changes by Raymond Hettinger :


--
assignee:  -> rhettinger
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4753] Faster opcode dispatch on gcc


Changes by Antoine Pitrou :


Removed file: http://bugs.python.org/file12474/threadedceval2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4753] Faster opcode dispatch on gcc


Changes by Antoine Pitrou :


Removed file: http://bugs.python.org/file12511/threadedceval3.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4796] Decimal to receive from_float method

2008-12-31 Thread Steven D'Aprano


New submission from Steven D'Aprano :

In the PEP for Decimal, it was discussed that the class should have a 
from_float() method for converting from floats, but to leave it out of 
the Python 2.4 version:
http://www.python.org/dev/peps/pep-0327/#from-float

Following discussions with Mark Dickinson, I would like to request 
that this now be implemented.

The suggested API is:
Decimal.from_float(floatNumber, [decimal_places])

At the risk of derailing the request, I wonder whether it is better to 
give a context rather than a number of decimal places?

Pro: better control over conversion, as you can specify rounding 
method as well as number of decimal places.

Con: more difficult for newbies to understand.

Semi-pro: float to decimal conversions are inherently tricky, perhaps 
we should be discouraging newbies from blindly calling from_float() 
and make the (hypothetical) context argument mandatory rather than 
optional?

--
components: Library (Lib)
messages: 78664
nosy: stevenjd
severity: normal
status: open
title: Decimal to receive from_float method
type: feature request

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4753] Faster opcode dispatch on gcc


Antoine Pitrou  added the comment:

Attached new patch for fixes suggested by Alexandre (rename
opcode_targets.c to opcode_targets.h, replace USE_THREADED_CODE with
USE_COMPUTED_GOTOS).

Added file: http://bugs.python.org/file12514/threadedceval4.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4794] garbage collector blocks and takes worst-case linear time wrt number of objects

2008-12-31 Thread darrenr


darrenr  added the comment:

A 'stop-the-world' garbage collector that periodically released the GIL
could be run in a second thread, allowing the main thread to break in
and do some processing. However the nature of a stop-the-world collector
means that it probably would not easily be able to deal with changes
made by other threads in the middle of the collect.

My concern is that the Python process blocks and is unresponsive due to
garbage collection for periods of time that are not acceptable for
realtime interactive applications. Are there any plans to add an
incremental collector to Python?

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4795] inspect.isgeneratorfunction inconsistent with other inspect functions

2008-12-31 Thread Steven D'Aprano


New submission from Steven D'Aprano :

The inspect isSOMETHING() functions all return True or False, except 
for isgeneratorfunction(), which returns True or None.

The body of the function is very brief:

if (isfunction(object) or ismethod(object)) and \
object.func_code.co_flags & CO_GENERATOR:
return True

The behaviour can be made consistent with the other routines by either 
appending "else: return False", or changing the body to:

return bool(
  (isfunction(object) or ismethod(object)) and
   object.func_code.co_flags & CO_GENERATOR)

--
components: Library (Lib)
messages: 78661
nosy: stevenjd
severity: normal
status: open
title: inspect.isgeneratorfunction inconsistent with other inspect functions
type: behavior
versions: Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4753] Faster opcode dispatch on gcc


Antoine Pitrou  added the comment:

Hello,

> You may want to check out issue1408710 in which a similar patch was
> provided, but failed to deliver the desired results.
> 
> I didn't get the advertised ~15% speed-up, but only 4% on my Intel Core2
> laptop and 8% on my AMD Athlon64 X2 desktop. I attached the benchmark
> results.

Thanks. The machine I got the 15% speedup on is in 64-bit mode with gcc
4.3.2.

If you want to investigate, you can output the assembler code for
ceval.c; the command-line should be something like:

gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall 
-Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE -S -dA 
Python/ceval.c

and then count the number of indirect jump instructions in ceval.c:

grep -E "jmp[[:space:]]\*%" ceval.s

There should be 85 to 90 of them, roughly. If there are many less, then
the compiler has tried to optimize them by "sharing" them.

> First, you should rename opcode_targets.c to opcode_targets.h. This will
> make it explicit that the file is not compiled, but just included.

Ok.

> Also, the macro USE_THREADED_CODE should be renamed to something else;
> the word "thread" is too tightly associated with multi-threading.
> Furthermore, threaded code simply refers to code consisting only of
> function calls. Maybe, USE_COMPUTED_GOTO or USE_DIRECT_DISPATCH would be
> better.

Ok.

> Finally, why do you disable your patch when DYNAMIC_EXECUTION_PROFILE or
> LLTRACE is enabled? I tested your patch with both enabled and I didn't
> see any test failures.

Because otherwise the measurements these options are meant to do would
be meaningless.

> By the way, SUNCC also supports GCC's syntax for labels as values

I don't have a Sun machine to test, so I'll leave to someone else to
check and enable if they want to.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4793] Glossary incorrectly describes a decorator as "merely syntactic sugar"

Benjamin Peterson  added the comment:

On Wed, Dec 31, 2008 at 3:17 PM, Lenard Lindstrom
 wrote:
>
> However, the issue is one of definitions. Is the phrase "merely
> syntactic sugar" misleading? In this case it makes promises that may not
> be kept.

It's not misleading because in 99.99% of all cases (and 100% of all
reasonable ones), they are the same. In fact, I would classify the
fact that the function hasn't been assigned yet a implementation
detail.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4753] Faster opcode dispatch on gcc


Skip Montanaro  added the comment:

Antoine> You're sure you didn't compile in debug mode or something? Just
Antoine> checking.

There was a cut-n-paste error in that one which I noticed right after
submitting (man, do I hate the crappy editing capability of 
widgets).  I removed it within a minute or two and replaced it with a
correct version.  Short answer: Intel thumbs up, PowerPC thumbs down.

Skip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4753] Faster opcode dispatch on gcc


Antoine Pitrou  added the comment:

> Works pretty well for me on my MacBook Pro, but on my G5 it performed
> abysmally.  In fact, it ran so much worse that I cleaned up my sandbox 
> and did both checks all over again to make sure I didn't mess something
> up.  It looks like my MacBook Pro saw about a 14% degradation.  Both
> computers are running Mac OS X 10.5.6 with the latest Xcode - 3.1.2.
> On both computers gcc -v reports 4.0.1, Apple build 5490.

You're sure you didn't compile in debug mode or something? Just
checking.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4753] Faster opcode dispatch on gcc


Skip Montanaro  added the comment:

Works pretty well for me on my MacBook Pro, but on my G5 it performed
abysmally.  In fact, it ran so much worse that I cleaned up my sandbox 
and did both checks all over again to make sure I didn't mess something
up.  It looks like my MacBook Pro saw about a 7% improvement while my
G5 saw a 14% degradation.  Both computers are running Mac OS X 10.5.6
with the latest Xcode - 3.1.2.  On both computers gcc -v reports 4.0.1,
Apple build 5490.

If this is applied to the core I think it will have to select for more
than just gcc.  It will also have to select based on the instruction set
architecture.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4753] Faster opcode dispatch on gcc


Changes by Skip Montanaro :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4753] Faster opcode dispatch on gcc


Skip Montanaro  added the comment:

Works pretty well for me on my MacBook Pro, but on my G5 it performed
abysmally.  In fact, it ran so much worse that I cleaned up my sandbox 
and did both checks all over again to make sure I didn't mess something
up.  It looks like my MacBook Pro saw about a 14% degradation.  Both
computers are running Mac OS X 10.5.6 with the latest Xcode - 3.1.2.
On both computers gcc -v reports 4.0.1, Apple build 5490.

If this is applied to the core I think it will have to select for more
than just gcc.  It will also have to select based on the chip
architecture.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4790] Optimization to heapq module

2008-12-31 Thread Nilton Volpato


Nilton Volpato  added the comment:

Nice!

Maybe we could add the decorate/undecorate step to guarantee stability
to the C implementation. I'll do some experiments and timings on this.
The heapq library has a lot of room for optimization, I think.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4753] Faster opcode dispatch on gcc


Changes by Raymond Hettinger :


--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4753] Faster opcode dispatch on gcc

2008-12-31 Thread Alexandre Vassalotti


Changes by Alexandre Vassalotti :


Added file: http://bugs.python.org/file12513/intel-core2-mobile-pybench.txt

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4753] Faster opcode dispatch on gcc

2008-12-31 Thread Alexandre Vassalotti


Alexandre Vassalotti  added the comment:

You may want to check out issue1408710 in which a similar patch was
provided, but failed to deliver the desired results.

I didn't get the advertised ~15% speed-up, but only 4% on my Intel Core2
laptop and 8% on my AMD Athlon64 X2 desktop. I attached the benchmark
results.

The patch looks pretty clean. Here is a few things that caught my
attention while reading your patch.

First, you should rename opcode_targets.c to opcode_targets.h. This will
make it explicit that the file is not compiled, but just included.

Also, the macro USE_THREADED_CODE should be renamed to something else;
the word "thread" is too tightly associated with multi-threading.
Furthermore, threaded code simply refers to code consisting only of
function calls. Maybe, USE_COMPUTED_GOTO or USE_DIRECT_DISPATCH would be
better.

Finally, why do you disable your patch when DYNAMIC_EXECUTION_PROFILE or
LLTRACE is enabled? I tested your patch with both enabled and I didn't
see any test failures.

By the way, SUNCC also supports GCC's syntax for labels as values
(http://docs.sun.com/app/docs/doc/819-5265/bjabt?l=en&a=view).

--
nosy: +alexandre.vassalotti
Added file: http://bugs.python.org/file12512/amd-athlon64-x2-pybench.txt

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4793] Glossary incorrectly describes a decorator as "merely syntactic sugar"

2008-12-31 Thread Lenard Lindstrom


Lenard Lindstrom  added the comment:

The claim "merely" syntactic sugar implies that the inverse is also
true, the decorator expression:

@do_something
def foo():


can be replaced it with:

def foo():

foo = do_something(foo)

This is guaranteed if do_something is purely functional, but breaks if
do_something has side effects. The example was for illustration only. A
real application would likely access the parent frame. Whether or not
this is a questionable practice, it happens.

However, the issue is one of definitions. Is the phrase "merely
syntactic sugar" misleading? In this case it makes promises that may not
be kept.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4753] Faster opcode dispatch on gcc


Antoine Pitrou  added the comment:

This new patch adds some detailed comments, at Jason Orendorff's request.

Added file: http://bugs.python.org/file12511/threadedceval3.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4747] SyntaxError executing a script containing non-ASCII characters in its name or path


Benjamin Peterson  added the comment:

Looks good.

--
keywords:  -needs review
nosy: +benjamin.peterson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4794] garbage collector blocks and takes worst-case linear time wrt number of objects


Benjamin Peterson  added the comment:

The garbage collector will never be able to run in a second thread
because it manipulates Python objects, which the GIL is supposed to protect!

As for non-linear complexity, see #4688 and #4074 for some attempts to
sooth this problem over.

--
nosy: +benjamin.peterson
resolution:  -> duplicate
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4793] Glossary incorrectly describes a decorator as "merely syntactic sugar"


Benjamin Peterson  added the comment:

It is possible to "desugar" the exact behavior by creating the function
ones self.

Regardless, the usefulness this behavior is limited because it relys on
the decorator being in the same module as the function. It is also
fragile for nested functions.

--
nosy: +benjamin.peterson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4794] garbage collector blocks and takes worst-case linear time wrt number of objects

2008-12-31 Thread David W. Lambert


Changes by David W. Lambert :


--
nosy: +LambertDW

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4793] Glossary incorrectly describes a decorator as "merely syntactic sugar"

2008-12-31 Thread Lenard Lindstrom


Lenard Lindstrom  added the comment:

It is distinct behavior. Without a decorator a new function is
immediately assigned to the identifier. Any previous reference is lost.
A decorator postpones assignment until the decorator returns. That
allows the decorator to access the previous object. I don't know of any
way to do the same thing with:

def foo():
   .
foo = do_something(foo)

Here is part of a comp.lang.python thread discussing the possibility of
using a decorator for an overloaded function.

http://groups.google.com/group/comp.lang.python/browse_thread/thread/16a2e8b9d6705dfb/1cb0b358173daf06?lnk=gst&q=Lenard+Lindstrom+decorator#1cb0b358173daf06

Note that the decorator could create an overloaded function without any
extra variables. To do the equivalent in Python 2.3 a special attribute,
with a mangled name, was needed to store intermediate declarations.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4794] garbage collector blocks and takes worst-case linear time wrt number of objects

2008-12-31 Thread darrenr


Changes by darrenr :


--
components: +Interpreter Core
type:  -> resource usage

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4794] garbage collector blocks and takes worst-case linear time wrt number of objects

2008-12-31 Thread darrenr


New submission from darrenr :

Python's garbage collector holds GIL during collection and doesn't
provide any method of interruption or concurrency with other Python
threads within a single Python VM. This can be a problem for realtime
applications. The worst-case performance of the garbage collector takes
linear time with respect to the number of Python objects that could
potentially be involved in a garbage cycle. I've attached timings taken
on a Core 2 Quad 2.4 GHz (WinXP Pro, 3GB RAM), with ever-increasing
numbers of objects. The gc at worst takes upwards of 3 seconds before
the process runs out of memory.

If gc periodically released the GIL it would allow it to be put in a
separate thread, but as it stands it blocks the Python VM for periods of
time that are too long for realtime interactive applications.
Alternatively a gc that is incremental by default would eliminate the
need for a second thread.

--
files: gctimings.zip
messages: 78646
nosy: darrenr
severity: normal
status: open
title: garbage collector blocks and takes worst-case linear time wrt number of 
objects
versions: Python 2.4, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file12510/gctimings.zip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2827] IDLE 3.0a5 cannot handle UTF-8

2008-12-31 Thread Pavel Kosina


Pavel Kosina  added the comment:

the following very simple example might be the the same issue:

x="ěščřžýáíé"
print (x)

It reliably puts down IDLE entirely without any error message. It is
saved in UTF-8. 
python +idle 3.0, wxp sp3

--
nosy: +geon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4793] Glossary incorrectly describes a decorator as "merely syntactic sugar"


Guilherme Polo  added the comment:

Your example doesn't disprove the "merely syntactic sugar" found in the
documentation about the decorator syntax.

The results you are getting are based on when the decorator is applied.

--
nosy: +gpolo
resolution:  -> invalid
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4793] Glossary incorrectly describes a decorator as "merely syntactic sugar"

2008-12-31 Thread Lenard Lindstrom


New submission from Lenard Lindstrom :

http://www.python.org/doc/2.6/glossary.html

The decorator entry in the Python 2.6 documentation incorrectly
describes a decorator as "merely syntactic sugar". It is not, as this
example shows:

>>> def decorator(f):
f.prev = globals()[f.__name__]
return f

>>> func = 0
>>> def func():
pass

>>> func = decorator(func)
>>> func.prev

>>> func = 0
>>> @decorator
def func():
pass

>>> func.prev
0

This distinction could be useful in building multi-methods, for example.

--
assignee: georg.brandl
components: Documentation
messages: 78643
nosy: georg.brandl, kermode
severity: normal
status: open
title: Glossary incorrectly describes a decorator as "merely syntactic sugar"
versions: Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3260] fix_imports does not handle intra-package renames


Benjamin Peterson  added the comment:

I think I will close this as "won't fix". As you say, the only
applicable rename is test.test_support. That only is not enough IMO to
add all the complexity to fix_imports that handling packages properly
would require.

--
nosy: +benjamin.peterson
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2734] 2to3 converts long(itude) argument to int


Benjamin Peterson  added the comment:

I hope r68106 helps. 2to3 now refuses to change long if it is being
assigned to, the name of a function or class, the name of an argument,
or an attribute.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2638] tkSimpleDialog Window Flashing


Guilherme Polo  added the comment:

Dropped for inclusion in python 2.5, but should still be considered for
trunk and py3k.

--
resolution:  -> accepted
versions: +Python 2.7, Python 3.0, Python 3.1 -Python 2.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2995] Idle, some Linuxes, cannot position Cursor by mouseclick


Guilherme Polo  added the comment:

Can you retry making some small example that demonstrates the problem ?

--
nosy: +gpolo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2693] IDLE doesn't work with Tk 8.5 under python 2.5 and older


Changes by Guilherme Polo :


--
title: IDLE  doesn't work with Tk 8.5 -> IDLE  doesn't work with Tk 8.5 under 
python 2.5 and older

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2693] IDLE doesn't work with Tk 8.5


Guilherme Polo  added the comment:

Closing as only r59654 was backported to release25-maint, so Tk 8.5 is
not fully supported by the standard Tkinter present in python 2.5.x

--
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4753] Faster opcode dispatch on gcc


Changes by Skip Montanaro :


--
nosy: +skip.montanaro

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue995925] method after() and afer_idle() are not thread save


Guilherme Polo  added the comment:

This is not going to happen.
You should be protecting it yourself since this is a special case.

--
nosy: +gpolo
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4791] retrlines('LIST') and dir hang at end of listing in ftplib (python3.0)

2008-12-31 Thread Christopher Mahan


Christopher Mahan  added the comment:

The list does not seem to contain non-ascii characters.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1702551] distutils sdist does not exclude SVN/CVS files on Windows

2008-12-31 Thread Tarek Ziadé


Tarek Ziadé  added the comment:

I have put this ticket in my pile.

I will write the test to demonstrate the problem and get back to your
patch proposal.

As Christian said, both separator should be taken care of under Windows,
so the final regexp will be slighly different.

Last, the trunk code has evolved a bit since your initial proposal, and
now includes other VCSs like Mercurial or Git.

--
assignee:  -> tarek
nosy: +tarek

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue734176] Make Tkinter.py's nametowidget work with cloned menu widgets


Guilherme Polo  added the comment:

Eh.. old.
Anyway, I have made a patch against trunk now and it should work with
any nested level of cloned menus according to how tk names cloned menus.

--
nosy: +gpolo
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1 -Python 2.3
Added file: http://bugs.python.org/file12509/nametowidget_clonedmenus.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4791] retrlines('LIST') and dir hang at end of listing in ftplib (python3.0)

2008-12-31 Thread Christopher Mahan


Christopher Mahan  added the comment:

Added file screenshot of filezilla view of the folder in question.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4508] distutils compiler not handling spaces in path to output/src files

2008-12-31 Thread Tarek Ziadé


Tarek Ziadé  added the comment:

Hi. I am not familiar with weave. Could you provide a small sample of
code that raises this issue. This way, I will be able to write the
standalone test we can integrate in distutils together with your fix.

--
assignee:  -> tarek
nosy: +tarek
priority:  -> normal

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4670] setup.py exception when db_setup_debug = True


Amaury Forgeot d'Arc  added the comment:

Closing as "out of date": 2.6.0 already has the fix (since r54124), and
2.5 is now in security-fixes-only mode.

--
nosy: +amaury.forgeotdarc
resolution:  -> out of date
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4791] retrlines('LIST') and dir hang at end of listing in ftplib (python3.0)

2008-12-31 Thread Christopher Mahan


Christopher Mahan  added the comment:

the output: just before the non-responsiveness:

-rwxrwxrwx   1 nobody   nogroup   3905538 Dec 29 09:51 Bronski Beat -
Why.mp3
-rwxrwxrwx   1 nobody   nogroup873966 Dec 28 13:53 test9.avi
-rwxrwxrwx   1 nobody   nogroup   2512653 Dec 29 08:28 test9_lg.wmv
-rwxrwxrwx   1 nobody   nogroup  6549 Dec 29 08:28 test9_lg.wmv.jpg
-rwxrwxrwx   1 nobody   nogroup   1788466 Dec 29 03:04 test9_med.flv
-rwxrwxrwx   1 nobody   nogroup  6394 Dec 29 03:04 test9_med.flv.jpg
-rwxrwxrwx   1 nobody   nogroup   1263041 Dec 28 13:53 test9_sm.flv
-rwxrwxrwx   1 nobody   nogroup  6465 Dec 28 13:53 test9_sm.flv.jpg

Added file: http://bugs.python.org/file12508/from_filezilla.png

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4753] Faster opcode dispatch on gcc


Antoine Pitrou  added the comment:

> Is this a special GCC feature?

Yes, it is.
http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4753] Faster opcode dispatch on gcc

2008-12-31 Thread Christian Heimes


Christian Heimes  added the comment:

> I haven't read any papers. Having a jump table in itself isn't special
> (the compiler does exactly that when compiling the switch() statement).
> What's special is that a dedicated indirect jump instruction at the end
> of each opcode helps the CPU make a separate prediction for which opcode
> follows the other one, which is not possible with a switch statement
> where the jump instruction is shared by all opcodes. I believe that's
> where most of the speedup comes from.
> 
> If you read the patch it will probably be easy to understand.

You are right. It's easier to understand after I've learned how the
opcode_targets table is working. Previously I didn't know that one can
store the address of a label in an array. Before I got it I wondered
where the pointers were defined. Is this a special GCC feature? I
haven't seen it before.

> Don't know! Your experiments are welcome. My patch is far simpler to
> integrate though (it's small, introduces very few changes and does not
> break any existing tests).

Yes, your patch is much smaller, less intrusive and easier to understand
with a little background in CS.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3638] tkinter.mainloop() is meaningless and crash: remove it


Antoine Pitrou  added the comment:

Well, well, sorry for the noise!

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3638] tkinter.mainloop() is meaningless and crash: remove it


Guilherme Polo  added the comment:

On Wed, Dec 31, 2008 at 2:27 PM, Guilherme Polo  wrote:
>
> Guilherme Polo  added the comment:
>
> On Wed, Dec 31, 2008 at 2:24 PM, Antoine Pitrou  
> wrote:
>>
>> Antoine Pitrou  added the comment:
>>
>> "tkinter.mainloop" seems used in a bunch of places according to Google
>> Code. Am I missing something?
>>
>
> Yes, those are not _tkinter.mainlooop, they are Tkinter.mainloop.
>

Or were you referring to my other comment about removing it from
Tkinter.py too ?

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3638] tkinter.mainloop() is meaningless and crash: remove it


Guilherme Polo  added the comment:

On Wed, Dec 31, 2008 at 2:24 PM, Antoine Pitrou  wrote:
>
> Antoine Pitrou  added the comment:
>
> "tkinter.mainloop" seems used in a bunch of places according to Google
> Code. Am I missing something?
>

Yes, those are not _tkinter.mainlooop, they are Tkinter.mainloop.

> http://www.google.com/codesearch?hl=fr&lr=&q=%22tkinter.mainloop%22&sbtn=Rechercher
>

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4732] Object allocation stress leads to segfault on RHEL


Antoine Pitrou  added the comment:

Ok, thanks for the investigation!

--
resolution:  -> invalid
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4732] Object allocation stress leads to segfault on RHEL

2008-12-31 Thread Andrew


Andrew  added the comment:

This problem appears to be specific to RHEL 5, and is not a Python
problem.  Linking against Google malloc (libtcmalloc) fixes the issue.

This bug should be closed.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3638] tkinter.mainloop() is meaningless and crash: remove it


Antoine Pitrou  added the comment:

"tkinter.mainloop" seems used in a bunch of places according to Google
Code. Am I missing something?

http://www.google.com/codesearch?hl=fr&lr=&q=%22tkinter.mainloop%22&sbtn=Rechercher

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4747] SyntaxError executing a script containing non-ASCII characters in its name or path


Amaury Forgeot d'Arc  added the comment:

Yes. As usual, the problem occurs when the platform encoding (used by
wcstombs) is not utf-8.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4753] Faster opcode dispatch on gcc


Antoine Pitrou  added the comment:

> I'm having trouble understanding the technique of the jump table. Can
> you provide some links to papers that explain the threaded code? I'm
> interested in learning more.

I haven't read any papers. Having a jump table in itself isn't special
(the compiler does exactly that when compiling the switch() statement).
What's special is that a dedicated indirect jump instruction at the end
of each opcode helps the CPU make a separate prediction for which opcode
follows the other one, which is not possible with a switch statement
where the jump instruction is shared by all opcodes. I believe that's
where most of the speedup comes from.

If you read the patch it will probably be easy to understand.

I had the idea to try this after a thread on pypy-dev, there are more
references there:
http://codespeak.net/pipermail/pypy-dev/2008q4/004916.html

> How does your implementation compare to the GForth based threaded code
> speedwise?

Don't know! Your experiments are welcome. My patch is far simpler to
integrate though (it's small, introduces very few changes and does not
break any existing tests).

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4749] Issue with RotatingFileHandler logging handler on Windows

2008-12-31 Thread Vinay Sajip

Vinay Sajip added the comment:

Can you (Mohammad) say which specific tickets raised the same issue? I
downloaded and ran your script (Windows XP Pro, ActivePython 2.5.2.2)
and had no problems. I created a .bat file with 100 invocations of the
.py file.

Lowell Alleman refers to concurrent use of a single log file by multiple
processes - this is not supported as there is no cross-platform method
of handling multiple process contention for a file. Lowell's handler
uses a portalocker module which is for NT or posix only - if this works
for you, then great.

The preferred way of dealing with logging to a single file from multiple
processes is to use a SocketHandler from the processes, and a separate
socket receiver application which receives the events and logs to file.
An example is in the docs:

http://docs.python.org/library/logging.html#sending-and-receiving-logging-events-across-a-network

I'll change the status of this issue to Pending while I wait for info on
other tickets about this - but multiple process support for any logging
to file (whether rotating or not) is not supported and won't be until
there is a cross-platform mechanism for file locking in the stdlib.

N.B. re your script - logging.shutdown() need not be called by your
script, as logging registers an atexit handler to do this automatically.

--
resolution: -> works for me
status: open -> pending

___
Python tracker

___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4791] retrlines('LIST') and dir hang at end of listing in ftplib (python3.0)

2008-12-31 Thread STINNER Victor


STINNER Victor  added the comment:

Can you paste the expected result of ftp.retrlines('LIST')? Does a 
directory contains a non-ASCII character?

--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4747] SyntaxError executing a script containing non-ASCII characters in its name or path

2008-12-31 Thread STINNER Victor


STINNER Victor  added the comment:

I'm unable to reproduce the problem on Linux. I wrote a 
script /home/haypo/ééé/ééé.py:
---
#!/home/haypo/prog/SVN/py3k/python
# -*- coding: ascii -*-
print("a")
---

The script runs fine:
$ ./ééé.py
a
$ /home/haypo/prog/SVN/py3k/python ééé.py
a

Is the problem specific to Windows?

--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4753] Faster opcode dispatch on gcc

2008-12-31 Thread Christian Heimes


Christian Heimes  added the comment:

I'm having trouble understanding the technique of the jump table. Can
you provide some links to papers that explain the threaded code? I'm
interested in learning more.
How does your implementation compare to the GForth based threaded code
speedwise?

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4772] undesired switch fall-through in socketmodule.c


Amaury Forgeot d'Arc  added the comment:

See attached patch.

--
keywords: +needs review, patch
nosy: +amaury.forgeotdarc
stage:  -> patch review
versions: +Python 2.6, Python 3.0
Added file: http://bugs.python.org/file12507/bluetooth.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4753] Faster opcode dispatch on gcc

2008-12-31 Thread Christian Heimes


Changes by Christian Heimes :


--
nosy: +christian.heimes

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4747] SyntaxError executing a script containing non-ASCII characters in its name or path


Amaury Forgeot d'Arc  added the comment:

This also happens if there is any kind of syntax error in the file: 
"SyntaxError: None" is printed without any other hint.

The (char*) filename passed to PyRun_AnyFile should be utf-8 encoded;
Otherwise the file cannot be re-opened.

Attached patch fixes both issues, please review.
It removes one occurrence of wcstombs in favor of the PyUnicode machinery.

--
keywords: +needs review, patch
nosy: +amaury.forgeotdarc
stage:  -> patch review
Added file: http://bugs.python.org/file12506/unicode_scriptname.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4792] PythonCmd in Modules/_tkinter.c should use the given "interp" parameter