[issue6673] Py3.1 hangs in coroutine and eats up all memory

[Stefan Behnel]

Stefan Behnel  added the comment:

Very good argumentation, thanks Nick!

I think this is worth being fixed in the 3.1 series.

--

___
Python tracker 

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

[issue6673] Py3.1 hangs in coroutine and eats up all memory

[Stefan Behnel]

Changes by Stefan Behnel :


--
status: closed -> open

___
Python tracker 

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

[issue1424148] urllib.FancyURLopener.redirect_internal looses data on POST!

[Senthil]

Senthil  added the comment:

I am assigning this to myself. I shall do some research on this issue +
plus current standings by other clients/libraries and come out with a
summary.

--
assignee:  -> orsenthil

___
Python tracker 

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

[issue6714] memmove fails with unicode strings

[Eric Smith]

Changes by Eric Smith :


--
resolution:  -> invalid
stage:  -> committed/rejected

___
Python tracker 

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

[issue6714] memmove fails with unicode strings

[Giorgos Verigakis]

Giorgos Verigakis  added the comment:

Yes, you are right. I thought that the different behavior was weird. Sorry 
this is not a bug.

--
status: open -> closed

___
Python tracker 

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

[issue6712] sys._getframe is not available on all Python implementations

[Brett Cannon]

Brett Cannon  added the comment:

On Sun, Aug 16, 2009 at 16:23, Michael Foord wrote:
>
> Michael Foord  added the comment:
>
> I meant in IronPython of course. D'oh. Anyway, I made the change to
> inspect to keep it compatible with IronPython so I can make the
> documentation change.
>
> A mention in the sys._getframe docs that it is not guaranteed to exist
> across implementations would be useful. I'll add that unless there are
> major objections.

You won't get objections as that's what the code does. I say just do
it and if people actually object we can back out the commit.

--

___
Python tracker 

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

[issue6712] sys._getframe is not available on all Python implementations

[Michael Foord]

Michael Foord  added the comment:

I meant in IronPython of course. D'oh. Anyway, I made the change to
inspect to keep it compatible with IronPython so I can make the
documentation change.

A mention in the sys._getframe docs that it is not guaranteed to exist
across implementations would be useful. I'll add that unless there are
major objections.

--

___
Python tracker 

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

[issue6712] sys._getframe is not available on all Python implementations

[Brett Cannon]

Brett Cannon  added the comment:

It sounds like inspect needs to have its docs updated such that it makes 
it explicit inspect.currentframe() requires sys._getframe() to exist to 
return anything of use (the code returns None in other cases). So the 
public API can exist, but it needs to say what it depends on is optional.

--

___
Python tracker 

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

[issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4.

[Gregory P. Smith]

Gregory P. Smith  added the comment:

btw, when using async io (poll, select, etc) I -think- your socket will
see a read event when the server closes the connection (sends you a FIN
or even a RST) at which point your sock.recv() when you've been told
data was ready will return 0 bytes indicating that the server has closed
the connection.

I like your MSG_PEEK hack here.  I'll figure out if this or something
else should go into (the giant mess that is) httplib.

--
priority:  -> normal

___
Python tracker 

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

[issue6712] sys._getframe is not available on all Python implementations

[Michael Foord]

Michael Foord  added the comment:

It's actually quite annoying that inspect takes a private API (that has
warnings in the documentation about its use) and makes it public. It's
just a direct alias. That in itself is not a good reason to say the
_getframe should be public.

Python frames are not available by *default* in Python, because of the
performance cost of using them.

--
nosy: +michael.foord

___
Python tracker 

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

[issue6712] sys._getframe is not available on all Python implementations

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Yeah I'd take this to the list.  Perhaps this is destined to be a public
API.

--
nosy: +gregory.p.smith

___
Python tracker 

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

[issue6712] sys._getframe is not available on all Python implementations

[Tobias Ivarsson]

Tobias Ivarsson  added the comment:

While it is true that not all Python implementations support
sys._getframe() in some or all execution modes, Jython does support it,
even IronPython supports it with the proper startup parameters these days.

More importantly sys._getframe() [or something equivalent] *is*
available as a public API in the inspect module of Python, as
inspect.currentframe(). I don't know why the inspect module is not
brought up in the discussions about sys._getframe(), but it is a public
API. Would this mean that introspecting callframes is something all
interpreters are expected to support? Brett: what is your opinion?
Perhaps I should move this discussion to the mailing list?

--
nosy: +thobe

___
Python tracker 

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

[issue6281] Bug in hashlib

[Gregory P. Smith]

Gregory P. Smith  added the comment:

That code was indeed a mess.  I've incorporated most suggestions from
your cleaned up version (and fixed a bug in it) in trunk r74479.

Have you ever seen __get_builtin_constructor fail in practice?  I can
imagine that packing up a stripped down python interpreter with only a
subset of the hash extension modules would be the only time this would
likely be encountered.

I've changed your code to log an error and continue rather than silently
continue when an expected hash function is not available.  That error
log may be overkill, perhaps we should just leave catching this problem
up to the unittests.

--
priority:  -> normal
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

[issue6714] memmove fails with unicode strings

[Eric Smith]

Eric Smith  added the comment:

What platform is this on? For a ucs4 platform, that is what I'd expect
the result to be. Check sys.maxunicode to see if you have a ucs2 or ucs4
build.

What do you expect as the result?

Remember that memmove takes a count of bytes, not a character count.

--
nosy: +eric.smith

___
Python tracker 

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

[issue6714] memmove fails with unicode strings

[Giorgos Verigakis]

New submission from Giorgos Verigakis :

A demonstration:

>>> buf = create_string_buffer('__')
>>> memmove(buf, 'SPAM', 4)
614584
>>> buf.raw
'SPAM__\x00'

>>> buf = create_string_buffer('__')
>>> memmove(buf, u'SPAM', 4)
614672
>>> buf.raw
'S\x00\x00\x00__\x00'

FWIW memmove fails in Python 3.0 too.

--
assignee: theller
components: ctypes
messages: 91644
nosy: theller, verigak
severity: normal
status: open
title: memmove fails with unicode strings
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

[issue6665] fnmatch fails on filenames containing \n character

[Gregory P. Smith]

Gregory P. Smith  added the comment:

I'll backport this to 2.6 and 3.1 later (its too late for 3.1.1).

--
versions:  -Python 2.7, Python 3.2

___
Python tracker 

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

[issue6665] fnmatch fails on filenames containing \n character

[Gregory P. Smith]

Gregory P. Smith  added the comment:

fixed in trunk r74475, py3k r74476

--

___
Python tracker 

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

[issue6712] sys._getframe is not available on all Python implementations

[Brett Cannon]

Brett Cannon  added the comment:

The leading underscore is meant to convey that it is not guaranteed to 
exist. But in spite of this, we do plan long-term to make it explicit what 
all interpreters are expected to (not) support.

--
nosy: +brett.cannon

___
Python tracker 

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

[issue6665] fnmatch fails on filenames containing \n character

[Gregory P. Smith]

Gregory P. Smith  added the comment:

changing the '$' to \Z(?ms)' fixes the problem.

--

___
Python tracker 

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

[issue6665] fnmatch fails on filenames containing \n character

[Gregory P. Smith]

Gregory P. Smith  added the comment:

aww, i guess the _cache does cache the result of the glob -> regular
expression translation.  it needs to stay for that.

--

___
Python tracker 

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

[issue6665] fnmatch fails on filenames containing \n character

[Gregory P. Smith]

Gregory P. Smith  added the comment:

haha wow I just read the fnmatch code... trunk r2734 | guido | 1992-01-12 

added fnmatch._cache for it to cache compiled regular expressions.  That
has -long- since become unnecessary as the re module does that itself. ;)

I'll clean this up while fixing this bug.

--
priority:  -> normal

___
Python tracker 

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

[issue6695] PyXXX_ClearFreeList for dict, set, and list

[Gregory P. Smith]

Gregory P. Smith  added the comment:

+1 on the PyXXX_ClearFreeList patch and calling them from gc.collect()
as is done with the others.

I agree with Guido, don't add a tp_free_list slot as the common case
would be NULL.

Regarding gc clearing freelists: I agree with Antoine and Martin. 
Clearing free lists in the highest generation of GC is a very good
thing.  Rebuilding them infrequently should not have a significant
performance impact and makes long running python jobs better behaved by
releasing more memory when possible.

--
nosy: +gregory.p.smith

___
Python tracker 

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

[issue6665] fnmatch fails on filenames containing \n character

[Gregory P. Smith]

Changes by Gregory P. Smith :


--
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith

___
Python tracker 

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

[issue6713] Integer & Long types: Performance improvement of 1.6x to 2x for base 10 conversions

[Gawain Bolton]

New submission from Gawain Bolton :

Converting integer & long types to their ASCII representation is a task
which can be quite CPU intensive due to the division & modulo
operations.  For long integers having hundreds or thousands of digits,
this can take a truly significant amount of CPU time.

I have written a special case for base 10 conversions which allows for
two improvements.
1) Two digits can be converted at a time, thus reducing the number of
div/mod operations by two.
2) An optimizing compiler can avoid performing a division operation when
the divisor is hardcoded.  The expensive division operation can be
replaced by a much faster multiplication operation.

My tests show an improvement of 1.6x to 1.8x improvement for integer
types and 2x improvement for longs.

Note that because integers are displayed using fprintf(), the
performance improvement is only seen when __repr__() is called.

Patch is provided against trunk.  It is somewhat difficult to read the
patch in one or two places due to the use of tabs.

--
components: Interpreter Core
files: base10_conversion_performance_patch.txt
messages: 91636
nosy: gawain
severity: normal
status: open
title: Integer & Long types:  Performance improvement of 1.6x to 2x for base 10 
conversions
type: performance
versions: Python 2.7
Added file: 
http://bugs.python.org/file14736/base10_conversion_performance_patch.txt

___
Python tracker 

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

[issue6695] PyXXX_ClearFreeList for dict, set, and list

[Martin v . Löwis]

Martin v. Löwis  added the comment:

I still stand by my suggestion to free memory as a side effect of
garbage collection. It may well be that an application will start
re-allocating blocks that soon end up in the free list again. OTOH, it
may also be that releasing those free lists, along with the freeing that
the GC just did, can cause arenas to become completely free, and thus be
returned to the operating system. Users really really want Python to
return memory to the operating system whenever possible, and on its own;
those free lists can block memory from being returned, more or less
unreasonably.

So unless it can be demonstrated (preferably in a realistic application)
that clearing the free lists has a measurable negative impact, I propose
to keep things the way they are.

IMO, it would be best if we could eliminate the freelists altogether.

--

___
Python tracker 

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

[issue6627] threading.local() does not work with C-created threads

[Giorgos Verigakis]

Changes by Giorgos Verigakis :


--
nosy: +verigak

___
Python tracker 

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

[issue6695] PyXXX_ClearFreeList for dict, set, and list

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
resolution: accepted -> 

___
Python tracker 

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

[issue6695] PyXXX_ClearFreeList for dict, set, and list

[R. David Murray]

R. David Murray  added the comment:

FWIW, I agree with Antoine here.  I think user expectation is that when
"garbage" is collected, at least some freed memory will be returned to
the operating system.  The normal user's conception of what "garbage" is
has nothing to do with cycles.  It just so happens that in CPython,
that's the main thing the garbage collector collects.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue6695] PyXXX_ClearFreeList for dict, set, and list

[Antoine Pitrou]

Antoine Pitrou  added the comment:

The change was originally made in r60797, « Implemented Martin's
suggestion to clear the free lists during the garbage collection of the
highest generation ».

--
nosy: +christian.heimes, loewis

___
Python tracker 

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

[issue6244] Support for tcl 8.6

[Guilherme Polo]

Guilherme Polo  added the comment:

This has been committed now, r74471,74472 (trunk) and r74473 (py3k).

--
resolution:  -> accepted
status: open -> closed

___
Python tracker 

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

[issue6695] PyXXX_ClearFreeList for dict, set, and list

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> When did that happen?  I agree with Raymond.  The cyclic gc should just
> reclaim cycles.

People don't care about referential cycles, they care about freeing some
memory (if memory was available in infinite quantities nobody would care
about breaking cycles). That's how the API is used most of the time,
IMO. And that's why measurements of the usefulness of calling
gc.collect() are usually done in megabytes, not in number of
references :-).

So, while I agree that it sounds bizarre for the GC to do other
memory-related tasks, it's also quite practical. Besides, the GC already
has a heuristic for *when* to cleanup memory, and it makes sense to
reuse this heuristic for other memory cleanup tasks, rather than to
invent another heuristic or put the burden of the task on the user (who
usually won't even know what those freelists are).

--

___
Python tracker 

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

[issue6695] PyXXX_ClearFreeList for dict, set, and list

[Skip Montanaro]

Skip Montanaro  added the comment:

>> I thought GC was expected to eliminate reference cycles.

Antoine> Of course, but it's also the de facto API when wanting to
Antoine> reclaim memory.

When did that happen?  I agree with Raymond.  The cyclic gc should just
reclaim cycles.

Skip

--

___
Python tracker 

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

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

[Chris Rebert]

Changes by Chris Rebert :


--
nosy: +cvrebert

___
Python tracker 

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

[issue6712] sys._getframe is not available on all Python implementations

[Chris Rebert]

Changes by Chris Rebert :


--
nosy: +cvrebert

___
Python tracker 

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

[issue6712] sys._getframe is not available on all Python implementations

[Johannes Janssen]

New submission from Johannes Janssen :

As I learned on the mailing list the function sys._getframe() is not
available on all Python implementations (e.g. jython). This information
should be added to the documentation.

--
assignee: georg.brandl
components: Documentation
messages: 91629
nosy: georg.brandl, johannes.janssen
severity: normal
status: open
title: sys._getframe is not available on all Python implementations

___
Python tracker 

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