[issue4753] Faster opcode dispatch on gcc

[Paolo 'Blaisorblade' Giarrusso]

Paolo 'Blaisorblade' Giarrusso  added the comment:

Ok, then vmgen adds almost just direct threading instead of indirect
threading.

Since the purpose of superinstructions is to eliminate dispatch
overhead, and that's more important when little actual work is done,
what about all ones which unconditionally end with FAST_DISPATCH and are
common? DUP_TOP, POP_TOP, DUP_TOPX(2,3) and other stack handling staff
which can't fail? To have any of them + XXX without error handling
problems? Removing handling of DUP_TOPX{4,5} is implied, you shouldn't
check functionality of the compiler during interpretation - indeed, even
the idea using a parameter for that is a waste. Have DUP_TOPX2 and
DUP_TOPX3, like JVM, is just simpler.

> Replication would be trickier since we want the bytecode generation to
be deterministic, but it's probably doable too.

Bytecode conversion during I/O is perfectly fine, to convert from the
actual bytecode to one of the chosen replicas. Conversion in a rescan
pass can be also OK (less cache friendly though, so if it's easy to
avoid, please do).

___
Python tracker 

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

[issue4889] difflib

[Gabriel Genellina]

Gabriel Genellina  added the comment:

You (as a human) most likely parse these lines:

hostname vaijain123
hostname CAVANC1001CR1

as "two words, the first one is the same, the second word changed".
But difflib sees them more or less as: "21 letters, 8 of them are the 
same, 13 are different". There are many more differences than matches, 
so it makes sense to show the changes as a complete replacement:

>>> d = difflib.ndiff(["hostname vaijain123\n"], ["hostname 
CAVANC1001CR1\n"])
>>> print ''.join(d)
- hostname vaijain123
+ hostname CAVANC1001CR1

It has nothing to do with upper or lower case letters ("A" and "a" are 
completely different things for difflib). If the names were shorter, it 
might consider a match:

>>> d = difflib.ndiff(["hostname vai\n"], ["hostname CAV\n"])
>>> print ''.join(d)
- hostname vai
?  ^^^
+ hostname CAV
?  ^^^

Note how the ratio changes:

>>> difflib.SequenceMatcher(None, "hostname vaijain123", "hostname 
CAVANC1001CR1").ratio()
0.48780487804878048
>>> difflib.SequenceMatcher(None, "hostname vai", "hostname CAV").ratio
()
0.75

The ratio must be 0.75 or higher for a differ to consider two lines 
"close enough" to show intra-line differences.

--
nosy: +gagenellina

___
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

[Jeffrey Yasskin]

Jeffrey Yasskin  added the comment:

@Paolo: I'm going to be looking into converting more common sequences
into superinstructions. We only have LOAD_CONST+XXX so far. The others
are difficult because vmgen doesn't provide easy ways to deal with error
handling, but Jakob and I have come up with a couple ideas to get around
that.

Replication would be trickier since we want the bytecode generation to
be deterministic, but it's probably doable too. I'll post any
significant results I get.

___
Python tracker 

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

[issue4896] Faster why variable manipulation in ceval.c

[Paolo 'Blaisorblade' Giarrusso]

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

[issue4871] zipfile can't decrypt

[Gabriel Genellina]

Gabriel Genellina  added the comment:

Lukas Lueg> The default encoding is UTF8

What do you mean? Not inside a zip file. The default encoding is CP437 
(the original IBM PC US character set).

A zipfile password is a sequence of bytes, not characters, as defined 
in the specification. Probably this issue has to wait until it is 
decided what to do in the general case; anyway, encoding the password 
to bytes at the application level seems to be safer.

--
nosy: +gagenellina

___
Python tracker 

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

[issue4908] adding a get_metadata in distutils

[Andi Albrecht]

Andi Albrecht  added the comment:

Is it intended that when reading PKG-INFO files the PEP 314 attributes
(provides, requires, obsoletes) are only set if version is exactly "1.1"? 

I'd expected that those attributes are available regardless of the
metadata version of the parsed file (with None as default for PKG-INFO
files < 1.1).

--
nosy: +aalbrecht

___
Python tracker 

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

[issue4926] putenv() accepts names containing '=', return value of unsetenv() not checked

[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

[issue3720] segfault in for loop with evil iterator

[Gregory P. Smith]

Gregory P. Smith  added the comment:

nice hack! :)

I'm going to guess that existing code in the wild setting tp_iternext = 
&PyObject_GetIter is rare.  I certainly can not rule it entirely out but 
I don't see anything in the open source world using 
http://www.google.com/codesearch

I'd be okay with this hack.  Let the release manager and/or BDFL make 
this call.

___
Python tracker 

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

[issue4913] wave.py: add writesamples() and readsamples()

[Guilherme Polo]

Guilherme Polo  added the comment:

> "DC (0 hz) assumption"?
> wave.py makes the assumption that what the user wants is whatever
> happens to be in the file, however arbitrary. (That 8 bit samples are
> unsigned bytes is probably an artifact of early ADC logic. Typically you
> got an absolute, n-bit value from an old ADC. Newer chips often return
> signed values.) It's very unlikely that anything but a copy program
> would try to work with unsigned char samples. Too many things to go
> wrong. Too much confusion. Zero means zero in most of the world, in and
> out of audio processing. :)

Every document/text I've found so far talks about 8 bit samples being
unsigned, it is not like I'm trying to enforce it just because I want,
just following the specification.
But, SDL for example, accepts wav files with unsigned 8 bits, signed 8
bits, unsigned 16 bits, signed 16 bits, and with different byte
orders, so apparently different libraries write different wave files.
I wonder which of these would be good to get included in wave.py, but
for this current issue I would prefer to not even touch this another
problem and stick with what is the documented for the wave format.

> .
> .
> But not putting the 8-bit offset in the read/write_samples logic does
> eliminate 2 lines of code in each routine.

It is good that it is just two lines, it means they could be added
back (and adapted) when we start supporting different output/input
formats for wave.

> "4) Well, lets fix a format then. else: wavs = [[wav]]" ?
> That's an extra [] I think.

Right.

> "wavs.extend(wav)" ?
> I had to look up extend() and try it in the Python shell! :) To each his
> own. But when I found out that one could do list+=added_list in Python I
> never looked back. Intuitive. I special-cased mono for speed purposes.
> No reason to do the +=/extend for mono samples. But, maybe the
> interpretor handles all that.

It won't just do this optimization, keeping the special case for mono is fine.

> "test_wave.py"?
> Oooo. Bit minimal, that. Yeah, I think a couple of things could be
> fleshed out there.

I'm waiting for the new hand written tests now :)

___
Python tracker 

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

[issue4903] binascii.crc32() - document signed vs unsigned results

[Gabriel Genellina]

Gabriel Genellina  added the comment:

Just a small note on the wording: "will have" and "will always be" look 
too strong to me. I'd just use is, are. Present tense seems to be --in 
general-- the preferred style in the documentation.

--
nosy: +gagenellina

___
Python tracker 

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

[issue4913] wave.py: add writesamples() and readsamples()

[Alex Robinson]

Alex Robinson  added the comment:

"DC (0 hz) assumption"?
wave.py makes the assumption that what the user wants is whatever
happens to be in the file, however arbitrary. (That 8 bit samples are
unsigned bytes is probably an artifact of early ADC logic. Typically you
got an absolute, n-bit value from an old ADC. Newer chips often return
signed values.) It's very unlikely that anything but a copy program
would try to work with unsigned char samples. Too many things to go
wrong. Too much confusion. Zero means zero in most of the world, in and
out of audio processing. :)  That said, not having to offset the 8 bit
samples sparsifies the read/write_sample code. But, I'm thinking that
that's at the expense of every program that uses it. When in doubt, I
figure, do what is more useful. Don't force the caller to write a
wrapper if he'll need to do it 99% of the time. But this is not a
religious thing with me. A wrapper can be written. And, in fact, I'd
sure think it would be nice to include wrappers like auto-scaling and
auto-zeroing in wave.py. But maybe not, as these ops probably belong in
some array.py type module. Anyway, a non-audio guy who just wants to
read a wave file, diddle with it, and write it out. Or who just wants to
generate some sound and write it out. Or who just wants to read a wave
file and graph it or something. All of these guys will be stunned when
they find out to their hours-of-work chagrin that wave files' 8 bit
samples are not signed chars. And, if I were one of them, I'd be plenty
peeved after having to spend all that time learning about some
historical artifact just to read an danged audio file, for gosh sakes.
But not putting the 8-bit offset in the read/write_samples logic does
eliminate 2 lines of code in each routine.

"writesamples would raise an exception"
Yep, taste. I'm inclined to find this irritating and I don't like being
irritated by packages I use. Makes for a poor out-of-box experience.
But, taste. :)

"4) Well, lets fix a format then. else: wavs = [[wav]]" ?
That's an extra [] I think. [[samples]] would be an array of array of an
array of samples. s = [1,2]; print [ [ a ] ];[[[1,2]]]
On reflection, I'd say I agree with you more than I do with me on the
ability of writesamples() to take a simple array of mono samples. Not a
good thing to do.

"wavs.extend(wav)" ?
I had to look up extend() and try it in the Python shell! :) To each his
own. But when I found out that one could do list+=added_list in Python I
never looked back. Intuitive. I special-cased mono for speed purposes.
No reason to do the +=/extend for mono samples. But, maybe the
interpretor handles all that. Don't know. Didn't measure it.

"monkey patch"?'
Wonderful! This makes your rewrite of the code *so* much cleaner. Thanks
for the tip!

"code layout"?
Har, har. Yep, no one in software has ever spent any time "discussing"
code layout before. Let's do it for the first time in history.

"test_wave.py"?
Oooo. Bit minimal, that. Yeah, I think a couple of things could be
fleshed out there.

Gotta run now. But will try to update the code in wave_futz later. Other
things on plate, though.

Guilherme, I really appreciate your handling this and your guidance. Thanks!

___
Python tracker 

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

[issue4881] Python's timezon handling: daylight saving option

[Pablo Castagnino]

Pablo Castagnino  added the comment:

Ok, everything seems to be working now in Ubuntu. However, I can't get
it work in WIN XP (at work). :(

Thanks for all your help!

___
Python tracker 

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

[issue4905] Use INVALID_FILE_ATTRIBUTES instead of magic numbers

[Gabriel Genellina]

Gabriel Genellina  added the comment:

The patch looks fine to me

--
nosy: +gagenellina

___
Python tracker 

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

[issue3720] segfault in for loop with evil iterator

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Yes, a hack: What about setting tp_iternext to PyObject_GetIter? they happen 
to have the same signature.
Yes, calling next() will call iter() instead; but an iterator is often its 
own iterator, and more importantly, PyIter_Check() is also called.

And the error message is surprisingly almost correct:
  "TypeError: iter() returned non-iterator of type 'BadIterator'"
It's not completely correct since the error occurred while calling the 
__next__() method of the iterator.

See attached patch for 2.6.

I can see one cause of incompatibility: if someone designed an extension 
type in C where tp_iternext is already PyObject_GetIter. It's is insane but 
valid, and the patch would break it. It's not worth the trouble I suppose...

--
keywords: +needs review
status: pending -> open
Added file: http://bugs.python.org/file12711/next-nevernull-26.patch

___
Python tracker 

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

[issue3720] segfault in for loop with evil iterator

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Fixed in r68560 (trunk) and r68561 (py3k).

Difficult to backport: extensions compiled with 2.6.x would not run on 
2.6.0.

--
keywords:  -needs review
resolution:  -> fixed
status: open -> pending

___
Python tracker 

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

[issue3720] segfault in for loop with evil iterator

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Any crash is a potential security problem.

This needs to be fixed in 2.6.x without breaking 2.6.0 extension 
compatibility.  (requiring extensions to be recompiled to fix the 
problem for an extension is fine, but they still need to load and work 
normally even if they have not been)

As trunk r68560 can't be backported?  what will?  Is there an 
appropriate pre-existing hackish substitute for PyObj_NextNotImplemented 
or will it require adding a test anytime the tp_nextiter slot is used?

--
components: +Interpreter Core
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

[issue4926] putenv() accepts names containing '=', return value of unsetenv() not checked

[David Watson]

Changes by David Watson :


Added file: http://bugs.python.org/file12710/3.x.diff

___
Python tracker 

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

[issue4926] putenv() accepts names containing '=', return value of unsetenv() not checked

[David Watson]

Changes by David Watson :


Added file: http://bugs.python.org/file12709/2.x.diff

___
Python tracker 

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

[issue4926] putenv() accepts names containing '=', return value of unsetenv() not checked

[David Watson]

New submission from David Watson :

One of these problems interacts with the other, and can cause
os.unsetenv() to free memory that's still in use.  Firstly,
calling os.putenv("FOO=BAR", "value") causes putenv(3) to be
called with the string "FOO=BAR=value", which sets a variable
called FOO, not FOO=BAR; hence, os.putenv() should not accept a
name with an "=" character in it.

The way this interacts with os.unsetenv() is that the string
(FOO=BAR=value) is stored in the internal dictionary object
posix_putenv_garbage under the key "FOO=BAR".  The reference in
this dict is supposed to prevent the bytes object (str in 3.x on
Windows) that contains the string from being garbage collected
and freed until unsetenv() is called, since putenv(3) makes the
char **environ array point to the actual string, not a copy.

The problem with os.unsetenv() is that it does not check the
return value from unsetenv(3) at all and will unconditionally
remove the corresponding string from posix_putenv_garbage.
Following the example above, when os.unsetenv("FOO=BAR") is
called, unsetenv(3) will fail because the name contains an "="
character, but the object containing the string will be garbage
collected even though char **environ still has a pointer to it.

This is a bit tricky to give a visible demonstration of, but the
attached visibility.diff adds posix_putenv_garbage to the module
namespace and prints the return value from unsetenv() so you can
see what's going on.

The other two attached diffs fix the problems (for 2.x and 3.x
separately) by making os.unsetenv() raise OSError on failure in
the usual way, and os.putenv() raise ValueError when its first
argument contains "=".  They also add test cases and docs.  In
the patch for 3.x, some of the relevant code differs between Unix
and Windows; I changed both but I've only tested the Unix
version.

--
components: Extension Modules
files: visibility.diff
keywords: patch
messages: 79708
nosy: baikie
severity: normal
status: open
title: putenv() accepts names containing '=', return value of unsetenv() not 
checked
type: behavior
Added file: http://bugs.python.org/file12708/visibility.diff

___
Python tracker 

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

[issue1696199] Add collections.counts()

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Thanks for the review comments.  Incorporated all suggested changes and
did some other minor tidying-up.  Extended the update example to include
c.update(Counter('abcdee')).  Committed as r68559 .

Decided to leave __repr__() with a sort.  Though it's not strictly
necessary, it's a nice convenience saving a user from doing the same
thing mentally.  Also, it helps with doctests by giving a reliable
ordering when element counts are non-equal.  For datasets small enough
that someone would want to display their repr, the time spent sorting is
negligible.

--
assignee: georg.brandl -> rhettinger
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

[issue4921] Object lifetime and inner recursive function

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Well, tracking memory consumption of each container would be better than
simpling couting them, but it's much more complicated as well (not to
mention that memory consumption can vary, so you must recalculate it
periodically...).

___
Python tracker 

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

[issue1479611] speed up function calls

[Collin Winter]

Changes by Collin Winter :


--
nosy: +collinwinter, jyasskin

___
Python tracker 

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

[issue4907] ast.literal_eval does not properly handled complex numbers

[Armin Ronacher]

Armin Ronacher  added the comment:

Here a patch with unittests to correctly handle complex numbers.  This
does not allow the user of arbitrary add/sub expressions on complex numbers.

Added file: http://bugs.python.org/file12707/literal-eval.patch

___
Python tracker 

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

[issue3582] thread_nt.c update

[Martin v. Löwis]

Changes by Martin v. Löwis :


--
status: open -> closed

___
Python tracker 

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

[issue2233] Makefile.pre.in contains extra slash before $(DESTDIR) which can cause Cygwin build to fail

[Jason Tishler]

Jason Tishler  added the comment:

Obviously not... :,(

It seems like we might have to go with your "/./" workaround, but let 
me see if I can come up with another approach.

___
Python tracker 

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

[issue3038] Return results from Python callbacks to Tcl as Tcl objects, please backport it.

[Guilherme Polo]

Guilherme Polo  added the comment:

Not going to happen, python 2.5.4 is already out there.

--
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

[issue2486] Recode (parts of) decimal module in C

[Nick Coghlan]

Nick Coghlan  added the comment:

FWIW, I actually prefer Mark's graduated approach to the Python->C
migration since we have a continuously working module that will get
incrementally faster over time. As profiling finds performance
bottlenecks in the Python code, those parts can be migrated to C (e.g.
as has been done initially with the manipulation of the coefficient,
which has been one of the main time sinks in the decimal module since
the days when it was still stored as a tuple instead of a string).

Having most of the module in C should be the endpoint, not where we
attempt to start (as I recall, attempts to rewrite the whole module in C
in one go have already been made, and they failed miserably).

___
Python tracker 

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

[issue4907] ast.literal_eval does not properly handled complex numbers

[Mark Dickinson]

Mark Dickinson  added the comment:

BTW, both those "I'm not sure"s should be taken literally:  I'm not a user 
of the ast module, I don't know who the typical users are, and I don't 
know what the typical uses for the literal_eval function are.  The patch 
just struck me as odd, so I thought I'd comment.

IOW, take my comments with a large pinch of salt.

___
Python tracker 

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

[issue2486] Recode (parts of) decimal module in C

[Mark Dickinson]

Mark Dickinson  added the comment:

Guess that makes this a bit of a wasted effort on my part, then.  Darn.

> a substantial portion of the module should be coded in C and
> needs to function independently of Python, with accessors provided to
> for Python to wrap around.

I'm curious what sort of memory model you have in mind for this:  would
you implement separate memory management code that could easily be
swapped in or out for the standard Python object allocator?  Or does the 
functioning independently of Python bit not go as far as memory 
management?

In any case, let me know if there's anything I can do to help out, 
whether it's coding, or review, or whatever.  For what it's worth, I'm 
hoping to check in a significantly simpler (and I hope faster!) version 
of the log, log10 and exp functions to decimal.py in the near future, 
which should make rewriting that portion a little easier.  The pow stuff 
could use some work, too.

--
assignee: marketdickinson -> 

___
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

[Jeffrey Yasskin]

Jeffrey Yasskin  added the comment:

I've left some line-by-line comments at
http://codereview.appspot.com/11905. Sorry if there was already a
Rietveld thread; I didn't see one.

___
Python tracker 

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

[issue1696199] Add collections.counts()

[Guido van Rossum]

Changes by Guido van Rossum :


--
nosy:  -gvanrossum

___
Python tracker 

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

[issue1696199] Add collections.counts()

[Georg Brandl]

Georg Brandl  added the comment:

Attaching new patch with small changes:

* Don't describe a class with "Returns ..." as if it was a function.
* Indent interposed paragraphs so that the method descriptions still
belong to the .. class directive.
* Fixed Ned's typo.
* Note that elements() and most_common() order elements arbitrarily.
* Reorder the seealso's a bit; the first line is bold.

Questions:

* Steven's counter.update('abcdee') wouldn't work -- I guess one is
supposed to use counter.update(Counter('abcdee')). Should that be noted
in the docs?
* Is it needed to sort the items for the __repr__?

Added file: http://bugs.python.org/file12706/counter7.diff

___
Python tracker 

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

[issue4925] Improve error message of subprocess

[David W. Lambert]

David W. Lambert  added the comment:

(Actual command stream includes chmod +x ./s.sh)

___
Python tracker 

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

[issue1696199] Add collections.counts()

[Ned Deily]

Ned Deily  added the comment:

In counter6.diff line 56

"Assigning a count of zero or reducing the count to the zero leaves the"

suggest s/the zero/zero/

--
nosy: +nad

___
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]

Paolo 'Blaisorblade' Giarrusso  added the comment:

A couple percent maybe is not worth vmgen-ing. But even if I'm not a
vmgen expert, I read many papers from Ertl about superinstructions and
replication, so the expected speedup from vmgen'ing is much bigger.
Is there some more advanced feature we are not using and could use?
Have the previous static predictions be converted to superinstructions?
Have other common sequences be treated like that?
Is there an existing discussion on this?

___
Python tracker 

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

[issue1696199] Add collections.counts()

[Steven Bethard]

Steven Bethard  added the comment:

The whole point was to have a function (or class) that accumulates a
sequence and counts it. collections.defaultdict(lambda: 0) doesn't
achieve this on its own because it only knows how to handle sequences of
(key, value):

>>> d = collections.defaultdict(lambda: 0)
>>> d.update('aaabbac')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: dictionary update sequence element #0 has length 1; 2 is
required

The feature request here was mainly a request to provide an abbreviation
of a very common 4-line function.

___
Python tracker 

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

[issue3720] segfault in for loop with evil iterator

[Benjamin Peterson]

Benjamin Peterson  added the comment:

I think PyObject_NextNotImplemented should be renamed to
_PyObject_NextNotImplemented. Aside from that, I think the patch is
ready for committing.

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue4913] wave.py: add writesamples() and readsamples()

[Guilherme Polo]

Guilherme Polo  added the comment:

I was going to reply about your "code layout" answer but forgot. Well,
each one has their preferences so I'm not going to question yours.

The only problem is that there is no maintainer for wave.py, so, the
more you follow the rules for Python code (or at least code that gets
included in Python) the greater are the chances for them getting included.

___
Python tracker 

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

[issue4913] wave.py: add writesamples() and readsamples()

[Guilherme Polo]

Guilherme Polo  added the comment:

1) wave.py doesn't do assumptions about what the user wants, so I don't
think it is the place to put the DC (0 hz) assumption.

3) writesamples would raise an exception in the case of the current
number of channels set being wrong.

4) Well, lets fix a format then. I said list of lists of integers, or it
could use generators, and you didn't disagree here so it seems to be
fine. The problem in the current code is that you are making mono
channels special by being the one where a list of lists of integers is
not returned, but instead a single is returned. This is troublesome for
the caller to set the number of channels then, it is also a different
format then when something with 2 channels or other configuration is
used. With that in mind I have simplified some of your code as this:


def readsamples(self, nframes) :
"""Return a list of lists of integers.

The number of these inner lists is given by the number of channels in
the wave file. Each list contains the channel samples formatted as
integers.
"""
wav = self.readframes(nframes)

sampwidth = self.getsampwidth()
wav = struct.unpack(
'<%d%s' % (len(wav) / sampwidth, wave._array_fmts[sampwidth]),
wav)

nc = self.getnchannels()
if nc > 1:
wavs = []
for c in xrange(nc):
wavs.append([wav[si] for si in xrange(c, len(wav), nc)])
else:
wavs = [[wav]]

return wavs

def writesamples(self, *wavs) :
"""Write samples to the wave file.

wavs must follow the structure returned by readsamples.
"""
if self.getnchannels() != len(wavs):
raise wave.Error("# of channels != # of samples")

wav = []
for w in zip(*wavs):
wav.extend(w)

ws = array.array(wave._array_fmts[self.getsampwidth()], wav)
ws = ws.tostring()

# we want all the samples in writeframes() format so that _convert
# can be called on them
self.writeframes(ws)


You can monkey patch wave then by doing:

wave.Wave_write.writesamples = writesamples
wave.Wave_read.readsamples = readsamples

And then change some other parts of your code.

5) There is a very small test for wave in Python's source,
Lib/test/test_wave.py

___
Python tracker 

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

[issue1696199] Add collections.counts()

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

> the typical usage is c=Counter(myseq) with no other non-dict accesses
> (mostly just c[elem]+=1 and print c[elem])

Isn't collections.defaultdict(lambda:0) enough for this purpose?

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue4910] Remove uses of nb_long slot, and rename to nb_reserved.

[Benjamin Peterson]

Benjamin Peterson  added the comment:

The first installment looks good!

___
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

[Jeffrey Yasskin]

Jeffrey Yasskin  added the comment:

Here's the vmgen-based patch for comparison. Again, it passes all the
tests, but isn't complete outside of that and (unless consensus develops
that a couple percent is worth requiring vmgen) shouldn't distract from
reviewing Antoine's patch. I'll look over threadedceval5.patch in detail
next.

Added file: http://bugs.python.org/file12705/vmgen_2.7.patch

___
Python tracker 

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

[issue1168055] Add current dir when running try_run test program

[Fernando Gomes]

Fernando Gomes  added the comment:

Dear Community,
I'd fronted problems to install Statistics module on my Ubuntu.
There are errors that are hard to solve without an expert help, such as
the one received from Michiel (Thank you again!!!).
Errors are listed below:

# XXX
o...@fgsj-ima:/usr/lib/python2.5/statistics-0.19# python setup.py config
running config
 = begin statistics configuration 
unable to execute _configtest: No such file or directory
libm does not contain erf; skipping this feature
unable to execute _configtest: No such file or directory
libm does not contain erfc; skipping this feature
 = end statistics configuration ==
wrote config file (src/config.h)
r...@fgsj-ima:/usr/lib/python2.5/statistics-0.19# python setup.py build
running build
running build_ext
building 'statistics' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -Isrc
-I/usr/lib/python2.5/site-packages/numpy/core/include
-I/usr/include/python2.5
-c src/statisticsmodule.c -o
build/temp.linux-i686-2.5/src/statisticsmodule.o
src/statisticsmodule.c:1:20: error: Python.h: No such file or directory
In file included from
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/arrayobject.h:14,
from src/statisticsmodule.c:2:
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:100:2:
error: #error Must use Python with unicode enabled.
In file included from
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/arrayobject.h:14,
from src/statisticsmodule.c:2:
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:920:
error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘npy_intp’
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:921:
error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘npy_uintp’
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1013:
error:
expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1014:
error:
expected ‘)’ before ‘*’ token
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1016:
error:
expected declaration specifiers or ‘...’ before ‘npy_intp’
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1016:
error:
expected declaration specifiers or ‘...’ before ‘npy_intp’
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1017:
error:
expected declaration specifiers or ‘...’ before ‘npy_intp’
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1027:
error:
expected declaration specifiers or ‘...’ before ‘npy_intp’
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1027:
error:
expected declaration specifiers or ‘...’ before ‘npy_intp’
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1029:
error:
expected declaration specifiers or ‘...’ before ‘npy_intp’
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1029:
error:
expected declaration specifiers or ‘...’ before ‘npy_intp’
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1030:
error:
expected declaration specifiers or ‘...’ before ‘npy_intp’
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1032:
error:
expected declaration specifiers or ‘...’ before ‘npy_intp’
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1037:
error:
expected ‘)’ before ‘*’ token
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1042:
error:
expected declaration specifiers or ‘...’ before ‘npy_intp’
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1044:
error:
expected declaration specifiers or ‘...’ before ‘npy_intp’
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1045:
error:
expected declaration specifiers or ‘...’ before ‘npy_intp’
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1045:
error:
expected declaration specifiers or ‘...’ before ‘npy_intp’
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1047:
error:
expected declaration specifiers or ‘...’ before ‘npy_intp’
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1051:
error:
expected declaration specifiers or ‘...’ before ‘npy_intp’
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1053:
error:
expected declaration specifiers or ‘...’ before ‘npy_intp’
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1054:
error:
expected declaration specifiers or ‘...’ before ‘npy_intp’
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1055:
error:
expected declaration specifiers or ‘...’ before ‘npy_intp’
/usr/lib/python2.5/site-

[issue4913] wave.py: add writesamples() and readsamples()

[Alex Robinson]

Alex Robinson  added the comment:

"8 bit samples stored as unsigned bytes"?
8 bit samples are 0..255 in the file. But to work with them, you'll want
them -128..127. The code assumes DC==0 sample values for simplicity.

"if len(wavs) not in [ 1, 2, 4 ]" ?
That way if you're working with mono, you can simply pass your samples
down to writesamples() without having to remember to "[ samples ]" them.
If you forget, no big deal. It's too bad that readsamples() can't know
that you want only mono samples. That would make mono work simpler.
Anyway, I don't argue very strongly for this spiff. In some ways it's
worse to be there. After all, the caller may be writing 1 frame at a
time, though I don't think that such logic would work. And would be
pretty slow, too, probably.

"Calling setnchannels"?
Since the number of channels *must* be the number of sample arrays
passed to writesamples(), either writesamples() must rely on the caller
already having gratuitously set the number of channels (correctly), or
writesamples() can simply force the issue. If the caller set the number
of channels wrongly, then the output file will be corrupt or
writesamples() would need to raise an exception. Both just make work for
the caller. get/set_nchannels() are not particularly useful if you are
using the read/write_sample API. If there were no ..frame() API,
getnchannels() might still be handy to use to find out how many channels
a wave file being read has before any samples have been read. But that's
about it.

"integers, is that the best format"?
Far bettern than the byte stream form which is useless, confusing, error
prone, and exposes the internal wave file format to the caller who could
generally care less how a wave file stores the samples. But, you bring
up a very good point, I think. I forgot to int(s) the samples when they
are put in to the arrays. The reason for an int() call on all the
samples is so that the caller can deal with samples as floats. (Which is
how he will want to deal with them if he's doing anything interesting.)
So, this:
ws  = array.array('l', [ int(s)   for s in wav ])
ws  = array.array('h', [ int(s)   for s in wav ])
ws  = array.array('B', [ int(s + 128) for s in wav ])
And, for testing, in normalize_samples():
samps   = [ s * mxm for s in samps ]
So normalize_samples() always sends floats to writesamples().


"The code layout"?
:) Well. Whatever. I know that the "official" python thing is to push
colons left. I don't like that. I've experimented in the last few years
with doing a lot of vertical alignment. Over time, I've found that it is
a great way to do things. It's pretty amazing how much easier it is to
scan and read code that has, as a start, the "="'s vertically aligned.
And, over the last few years, I've put more and more blank lines in.
Vertically compressed code tends to look like assembler language. I edit
with 200+ character wide screen so, since I stopped forcing everything
to fit on TTY, text mode CGA, or punch cards, I've lost a taste for
narrow code. In fact, I personally have a real hard time reading
line-broken code. That said, multi-lining "if" statements in ways that
allow delete/insert of lines, 1 for each "operator ()" expression, can
be very nice. Calls to routines with a gob of parameters, each on a
separate line, can sure be a good way to deal with a bad thing (routines
that take a lot of params are bad, that is). Etc. Anyway, I assumed that
the code would be reformatted by whomever maintains wave.py. No biggy.

"hand write the wave file for testing"?
Good point! Allows a test to do things like odd numbers of frames, 1
frame, max'ed out sample values, long runs of silence, DC offsets, etc.
Do you know whether there are already test files for wave.py? They'd
have those sorts of things in them. Hmmm. It's odd that wave.py doesn't
run from the command line and dump the header or something, at least.
Maybe do some simple conversions (8/16, mono/stereo switches, reverses
... that sort of thing). Would be handy.


This code is not tested on a big-endian machine. I ran it under XP
(py2.4) and Ubuntu64 (py2.5) and all the output files CRC the same on
both PCs.

___
Python tracker 

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

[issue4925] Improve error message of subprocess

[David W. Lambert]

David W. Lambert  added the comment:

Related, but outside python realm, this error likewise confuses:

$ cat < s.sh
#! invalid path
echo hi
EOF
$ ./s.sh 
zsh: no such file or directory: ./s.sh

--
nosy: +LambertDW

___
Python tracker 

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

[issue4925] Improve error message of subprocess

[Martin Mokrejs]

New submission from Martin Mokrejs :

I think the following error output unsatisfactory as it does not give me
any hint what file was not found:

$ fetch_quals.py blah.txt 
Traceback (most recent call last):
  File "/home/mmokrejs/bin/fetch_quals.py", line 15, in 
_p1 = subprocess.Popen(['query_tracedb', 'retrieve', 'quality',
_id], stdin=subprocess.PIPE, stdout=subprocess.PIPE)
  File "/usr/lib/python2.5/subprocess.py", line 594, in __init__
errread, errwrite)
  File "/usr/lib/python2.5/subprocess.py", line 1091, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
$

I know now that I had to specify full path tot he binary or include
shell=True argument but anyway, please improve the error message.

--
components: Extension Modules
messages: 79684
nosy: mmokrejs
severity: normal
status: open
title: Improve error message of subprocess
type: behavior
versions: Python 2.5

___
Python tracker 

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

[issue4760] cmp gone documentations

[David W. Lambert]

David W. Lambert  added the comment:

http://docs.python.org/dev/3.1/library/unittest.html#module-unittest

Search for "cmp".  There are two references.  I apologize if I
misunderstand issue 1717,

--
title: cmp gone---What's new in 3.1 -> cmp gone documentations

___
Python tracker 

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

[issue1403068] cannot import extension module with Purify

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Newer versions of Purify seem to convert the file name to uppercase
letters (PYTHON27__D$Purify...), so the error is does not occur anymore.
The current code is fragile though...

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

___
Python tracker 

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

[issue4913] wave.py: add writesamples() and readsamples()

[Guilherme Polo]

Guilherme Polo  added the comment:

Aren't 8 bit samples stored as unsigned bytes ? If yes, they don't range
between -128 and 127 (first disagreement). So this line: wav = [ s - 128
for s in wav ] and the respective one (that adds +128 in writesamples)
should go.

Why is this check: "if len(wavs) not in [ 1, 2, 4 ]" needed ?

Calling setnchannels inside writesamples looks very wrong to me, weren't
you going to writesamples ? Then why is it modified the number of
channels ? The caller should be responsible for calling setnchannels,
besides, what is the use of calling setnchannels here ?

I see writesamples is expecting "wavs" to be a list of lists containing
integers, is that the best format to expect ? writeframes works with
strings (which are actually byte strings).

The code layout didn't help me to get in agreement with it either.

The above paragraphs are the things I disagree with the patch, hopefully
you can help on those questions. Also, it would be better to hand write
the wave file for testing so we can be sure about its content without
needing much analysis.

___
Python tracker 

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

[issue4921] Object lifetime and inner recursive function

[Hirokazu Yamamoto]

Hirokazu Yamamoto  added the comment:

A little followup. Attached script q112.py (some puzzle program) ate up 
my RAM (80MB) and never ran GC while solving. Current python GC looks 
at the number of GC objects, but GC object like set object can contain 
many non GC object, so... I feel it would be nice if there is better GC 
triger/timing.

Added file: http://bugs.python.org/file12704/q112.py

___
Python tracker 

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

[issue4908] adding a get_metadata in distutils

[Ray]

Ray  added the comment:

I've tested it out using the straight distutils installation, and it
works great!

___
Python tracker 

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

[issue4913] wave.py: add writesamples() and readsamples()

[Alex Robinson]

Alex Robinson  added the comment:

Polo: "I could do it, but I'm in disagreement with big part of your patch."

Why surely you can't mean the bug. :) (The test program has it fixed.)

What is the disagreement?

Apparently this bug system allows file attachments, so I will upload a
test program and wave file.

The program is hard coded to read the wave file and write a bunch of
wave files, the names of which describe what they sound like.

Added file: http://bugs.python.org/file12703/wave_futz.zip

___
Python tracker 

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

[issue4908] adding a get_metadata in distutils

[Tarek Ziadé]

Tarek Ziadé  added the comment:

yes the patch doesn't treat the eggs installed with easy_install yet,
just plain distutils

I'll let you know when EGG_INFO/PKG-INFO is ready (should be in the
coming days)

___
Python tracker 

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

[issue4908] adding a get_metadata in distutils

[Ray]

Ray  added the comment:

The patch didn't install correctly using 'patch', but I manually merged
the changes into my environment (Ubuntu 8.10 running 2.5.2) - I'll
upload the diff rejections if they'll be helpful.

After installing, I attempted to use the new code to determine the
version number, and am receiving 'None' as my result.  After looking
through the code, I believe its looking for a '.egg-info' file, but my
custom package doesn't have one (it was installed using 'easy_install' -
easy_install -z ), so it looks like that info is instead
stored in EGG_INFO/PKG-INFO within the egg itself.

Here's a dir dump of my installed egg:
my_package-1.0-py2.5.egg/
|-- EGG-INFO
|   |-- PKG-INFO
|   |-- SOURCES.txt
|   |-- dependency_links.txt
|   |-- top_level.txt
|   `-- zip-safe
|-- my_package.py
`-- my_package.pyc

___
Python tracker 

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

[issue881261] Overflow in Python Profiler

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

on POSIX, clock() indeed wraps around after some time.
This was corrected with issue645894, and is available since python 2.5.

--
nosy: +amaury.forgeotdarc
resolution:  -> out of date
status: open -> closed
superseder:  -> better timer resolution for profile.py

___
Python tracker 

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

[issue4924] gc.collect() won't always collect as expected

[Martin v. Löwis]

Martin v. Löwis  added the comment:

It should be possible to trigger this by invoking gc.collect in an
__del__ implementation of an object that is attached to a cycle.

However, I don't think this is an important issue; +0 for resolving this
by documenting the status quo (instead of making the implementation
match the documentation).

--
nosy: +loewis

___
Python tracker 

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

[issue4924] gc.collect() won't always collect as expected

[Antoine Pitrou]

New submission from Antoine Pitrou :

I haven't verified this through any test (actually I'm wondering how to
deterministically reproduce it), but logically there are cases where
gc.collect() (and, similarly, PyGC_Collect()) won't work as advertised.

Specifically, when the GC is asked to collect a given generation but a
younger generation is already being collected, collect() will simply
notice this and return 0. However, only the younger generation will have
been collected, not the generation asked by the user.

It wouldn't take too much effort to make gc.collect() and PyGC_Collect()
truely deterministic.

--
messages: 79673
nosy: pitrou
priority: normal
severity: normal
stage: test needed
status: open
title: gc.collect() won't always collect as expected
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

___
Python tracker 

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

[issue4921] Object lifetime and inner recursive function

[Hirokazu Yamamoto]

Hirokazu Yamamoto  added the comment:

Thank you for explanation. The combination of inner function + method 
variable was very handy for me, but maybe I should refrain from using 
it lightly. :-(

--
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

[issue812369] module shutdown procedure based on GC

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Looking at the patch, is there any reason it doesn't get rid of the
current _PyModule_Clear() implementation to replace it by a call to
PyDict_Clear() followed by PyGC_Collect()?
(the call to PyGC_Collect could be disabled while finalizing, because
there's no use calling it as many times as there are modules to be
disbanded)

The major annoyance with the current scheme is that, at interpreter
shutdown, some globals you want to rely on in your destructors suddenly
become None.

About what to do of gc.garbage at shutdown, there was another proposal
in #477863.

--
nosy: +pitrou

___
Python tracker 

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

[issue4921] Object lifetime and inner recursive function

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Since g calls "itself" in its own scope, it is stored as one of its own
cell vars, which creates a reference cycle. a is also part of its
reference cycle for the same reason, so it must wait for garbage
collection to be reclaimed.

If g didn't keep a reference to its cell vars, closures wouldn't be
possible, because the cell vars wouldn't survive the end of f's scope.

(g doesn't have to be recursive, it's enough that it makes a reference
to itself in its own scope:

def f():
a = A()
def g():
a
g

or even:

def f():
a = A()
def g():
a
h
h = g

)

--
nosy: +pitrou

___
Python tracker 

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

[issue4913] wave.py: add writesamples() and readsamples()

[Guilherme Polo]

Guilherme Polo  added the comment:

I could do it, but I'm in disagreement with big part of your patch.

Can you add some kind of test you used for it ? Raw data, sample file,
or something like this.

___
Python tracker 

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

[issue4913] wave.py: add writesamples() and readsamples()

[Alex Robinson]

Alex Robinson  added the comment:

I might be able to do doc/test/patch in a month or two, but know
zero.zero about the process so would expect it to take far more than a
few hours when I do have time.

___
Python tracker 

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

[issue4923] time.strftime documentation needs update

[Riccardo Attilio Galli]

New submission from Riccardo Attilio Galli :

there are discrepancies in the online documentation of
  strftime
in time.strftime http://docs.python.org/library/time.html
and datetime.strftime (http://docs.python.org/library/datetime.html)

In particular, seems like datetime.strftime is the one up to date,
having format codes %f and %z documented, and possibly others

--
assignee: georg.brandl
components: Documentation
messages: 79667
nosy: georg.brandl, riquito
severity: normal
status: open
title: time.strftime documentation needs update
type: feature request
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

[issue4920] Inconsistent usage of next/__next__ in ABC collections; collections.Iterator is not compatible with Python 2.6 iterators.

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Good catch!

--
nosy: +rhettinger
priority:  -> high

___
Python tracker 

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

[issue4922] set.add and set.discard are not conformant to collections.MutableSet interface

[Jaroslaw Rosiek]

New submission from Jaroslaw Rosiek :

Methods set.add and set.discard should return boolean values according
to collections.MutableSet but they are not.

>>> print set().add(5)
None
>>> print set().discard(5)
None

--
components: Library (Lib)
messages: 79665
nosy: jrosiek
severity: normal
status: open
title: set.add and set.discard are not conformant to collections.MutableSet 
interface
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

[issue4921] Object lifetime and inner recursive function

[Hirokazu Yamamoto]

New submission from Hirokazu Yamamoto :

Hello. Sorry if this is noise. I expected

__del__
out of function
__del__
out of function
__del__
out of function

on following code, but actually I got

out of function
out of function
out of function
__del__
__del__
__del__

Is this expected behavoir? (I believed `a' would be
freed after returned from f(), so I was suprised)

If I remove the comment of gc.collect(), the code works as expected.

///

import gc

class A:
def __del__(self):
print("__del__")

def f():
a = A()
def g():
a
g()

def main():
for _ in range(3):
f()
#   gc.collect()
print("out of function")

if __name__ == '__main__':
main()

--
components: Interpreter Core
messages: 79664
nosy: ocean-city
severity: normal
status: open
title: Object lifetime and inner recursive function
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

___
Python tracker 

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

[issue1696199] Add collections.counts()

[Raymond Hettinger]

Changes by Raymond Hettinger :


Removed file: http://bugs.python.org/file12695/counter5.diff

___
Python tracker 

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

[issue1696199] Add collections.counts()

[Raymond Hettinger]

Changes by Raymond Hettinger :


Removed file: http://bugs.python.org/file12671/counter4.diff

___
Python tracker 

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

[issue1696199] Add collections.counts()

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Attaching an update with improved docs.  Thanks for looking at this.

Added file: http://bugs.python.org/file12702/counter6.diff

___
Python tracker 

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

[issue4920] Inconsistent usage of next/__next__ in ABC collections; collections.Iterator is not compatible with Python 2.6 iterators.

[Jaroslaw Rosiek]

Changes by Jaroslaw Rosiek :


--
keywords: +patch
Added file: http://bugs.python.org/file12701/_abcoll.patch

___
Python tracker 

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

[issue4920] Inconsistent usage of next/__next__ in ABC collections; collections.Iterator is not compatible with Python 2.6 iterators.

[Jaroslaw Rosiek]

Changes by Jaroslaw Rosiek :


Added file: http://bugs.python.org/file12700/example2.py

___
Python tracker 

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

[issue4920] Inconsistent usage of next/__next__ in ABC collections; collections.Iterator is not compatible with Python 2.6 iterators.

[Jaroslaw Rosiek]

Changes by Jaroslaw Rosiek :


Removed file: http://bugs.python.org/file12699/example2.py

___
Python tracker 

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

[issue4920] Inconsistent usage of next/__next__ in ABC collections; collections.Iterator is not compatible with Python 2.6 iterators.

[Jaroslaw Rosiek]

Changes by Jaroslaw Rosiek :


Added file: http://bugs.python.org/file12699/example2.py

___
Python tracker 

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

[issue4920] Inconsistent usage of next/__next__ in ABC collections; collections.Iterator is not compatible with Python 2.6 iterators.

[Jaroslaw Rosiek]

New submission from Jaroslaw Rosiek :

1. collections.MutableSet refers to __next__() slot instead of next()
buildin. 

2. collection.Iterator is not compatible with 2.6's iterators which
should have next() slot. Proposed solution: add a next() method to
collections.Iterator that falls back to __next__().

Attaching:
  1. Example code for problem 1
  2. Example code for problem 2
  3. A patch

When are you planning next bugfix release for 2.6 (I am particularly
interested in these issues :))?

--
components: Library (Lib)
files: example1.py
messages: 79662
nosy: jrosiek
severity: normal
status: open
title: Inconsistent usage of next/__next__ in ABC collections; 
collections.Iterator is not compatible with Python 2.6 iterators.
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file12698/example1.py

___
Python tracker 

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

[issue4913] wave.py: add writesamples() and readsamples()

[Guilherme Polo]

Changes by Guilherme Polo :


--
versions:  -Python 2.6, Python 3.0

___
Python tracker 

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

[issue1483545] Wave.py support for ulaw and alaw audio

[Guilherme Polo]

Changes by Guilherme Polo :


--
type:  -> feature request
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

[issue1696199] Add collections.counts()

[Georg Brandl]

Georg Brandl  added the comment:

Yes, I'll have a look this evening.

___
Python tracker 

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

[issue4913] wave.py: add writesamples() and readsamples()

[Guilherme Polo]

Guilherme Polo  added the comment:

Documentation, tests and patch against trunk are needed to get this into
Python, but to me the request is fine.

--
title: wave.py writes 16 bit sample files of half the correct duration -> 
wave.py: add writesamples() and readsamples()
versions:  -Python 2.4, Python 2.5

___
Python tracker 

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

[issue4910] Remove uses of nb_long slot, and rename to nb_reserved.

[Mark Dickinson]

Mark Dickinson  added the comment:

That was a pretty poor patch.  Here's a better one:

 - added Misc/NEWS entry
 - added tests to check that __long__ is never called
 - removed Modules/_struct.c change, in the interests of
   keeping the patch focused.

Added file: http://bugs.python.org/file12697/issue4910_1a.patch

___
Python tracker 

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

[issue4293] Thread Safe Py_AddPendingCall

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

Added MISC/News entry in revision: 68545

___
Python tracker 

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

[issue3582] thread_nt.c update

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

Misc/NEWS updated in revision: 68544

___
Python tracker 

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

[issue3582] thread_nt.c update

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

Note, see defect 4906 for fallout caused by this checkin.

___
Python tracker 

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

[issue4910] Remove uses of nb_long slot, and rename to nb_reserved.

[Mark Dickinson]

Mark Dickinson  added the comment:

Here's a patch against the py3k branch that gets rid of the two existing 
uses of nb_long in the core:

 - in PyNumber_Long, conversion was attempted first using nb_int and
   then using nb_long.  The patch simply removes the nb_long code, so
   int(x) no longer attempts to use the __long__ method for conversion.

 - in Modules/_struct.c, there's a call to nb_long in a function that's
   attempting to turn an arbitrary PyObject into a PyLongObject;  the
   patch replaces this with nb_int (and updates an error message).

 - In Lib/test/test_long.py, __long__ has been replaced with __int__
   in a test that __int__/__long__ takes precedence over __trunc__
   for conversion to int.

With this patch, all tests pass on my (OS X 10.5/Intel) machine.
(Except test_socket, but I'm 97.2% certain that's unrelated.)

If someone can review this quickly I'll move on to the next patch towards 
removing nb_long.  (My issue #1717 experience suggests that it ought to be 
easier to effect the removal via a series of 3 or 4 short, easy-to-review 
patches with clear intent than via one bigger, more confused patch.)

I think it would be good if nb_long could be altered before 3.0.1.

Benjamin, do you have time to take a look?

--
assignee:  -> benjamin.peterson
keywords: +patch
nosy: +benjamin.peterson
priority:  -> critical
title: Should both nb_long and nb_int still exist in 3.x? -> Remove uses of 
nb_long slot, and rename to nb_reserved.
type:  -> behavior
Added file: http://bugs.python.org/file12696/issue4910_1.patch

___
Python tracker 

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

[issue4919] 2.6.1 build issues on solaris with SunStudio 12

[scott wedel]

New submission from scott wedel :

The HUGE_VAL aka infinity issue is solved if the LIB is -lsunmath -lm
instead of just -lm

Sun Studio 12 compiler also seems to choke on the PyByteArray_GET_SIZE
and _AS_STRING because those macros use the ',' operator to stuff an
assert before the pointer lookup.  When I remove the assert portion of
those macros then they compile fine.

The assertions in those macros appear a bit silly because some places
they are used already have prior assertions and I don't see the point of
the macro which appears to be to crash due to an assertion one statement
prior to the null pointer reference causing a crash.

The configure process also appeared to make a few mistakes such as not
finding uid_t because that is in  and not in the presumed
header file.  If configure were to include the standard header files AND
the file that it expects to find the definition then it would be better
at finding what is defined.  I don't know why Sun does that.

--
components: Build
messages: 79654
nosy: taverngeek
severity: normal
status: open
title: 2.6.1 build issues on solaris with SunStudio 12
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

[issue3582] thread_nt.c update

[Martin v. Löwis]

Martin v. Löwis  added the comment:

Please add a Misc/NEWS entry for this change.

--
assignee:  -> krisvale
status: closed -> open

___
Python tracker 

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

[issue4893] Use separate thread support code under MS Windows CE

[Martin v. Löwis]

Martin v. Löwis  added the comment:

I see. Whether the call to PyThread_get_thread_ident comes before the
access to errno (in the original version) depends on the compiler, of
course. Also, this function should be trusted to not affect the last
error, since it can't fail.

I've added a comment to explain what the variables are good for, and
committed the patch as r68542, r68543.

--
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

[issue4915] Port sysmodule.c to MS Windows CE

[Martin v. Löwis]

Martin v. Löwis  added the comment:

Thanks for the patch. Committed as r68540, r68541.

--
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

[issue1696199] Add collections.counts()

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Georg, could you give this a once over before I commit?  Thanks.

--
assignee: rhettinger -> georg.brandl
nosy: +georg.brandl
Added file: http://bugs.python.org/file12695/counter5.diff

___
Python tracker 

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