[issue3208] function annotation for builtin and C function

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

The "First" argument does not apply here, we could just say "annotations
are not a function invariant", but the "Second" argument is valid to me. 

A solution would be a global (or interpreter-local if we really want to
support sub-interpreters) registry that stores annotations. The index
could not be the PyCFunctionObject (since it is different for every
bound method), but the address of the PyMethodDef entry.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3434] Mac, 3.0 framework install, Python.app not created

[Georg Brandl]

Changes by Georg Brandl <[EMAIL PROTECTED]>:


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

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3435] trace.py tries to get coverage data from non Python files

[Gustavo Narea]

New submission from Gustavo Narea <[EMAIL PROTECTED]>:

trace.py tries to get coverage information from non Python files, which raises a
SyntaxError because the file doesn't contain valid Python code.

I've attached a path that fixes this problem in Python 2.5.

--
components: Library (Lib)
files: trace.diff
keywords: patch
messages: 70197
nosy: Gustavo
severity: normal
status: open
title: trace.py tries to get coverage data from non Python files
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10964/trace.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3435] trace.py tries to get coverage data from non Python files

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

Your remark is certainly valid, but where does this occur? Some tool
that generate python code on the fly?
Do you have an example, a use case?

--
nosy: +amaury.forgeotdarc

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3435] trace.py tries to get coverage data from non Python files

[Gustavo Narea]

Gustavo Narea <[EMAIL PROTECTED]> added the comment:

Hi, Amaury.

I found this problem using the Bitten continuous integration system
(http://bitten.edgewall.org/ticket/304).

I'm using the TurboGears framework with Genshi, and therefore
mypackage.templates module should contain non-Python files. Here you'll find
its contents:
https://tracker.gnulinuxmatters.org/browser/animador/trunk/animador/template

This is the only situation where the problem occurs, AFAIK.

If you want to reproduce it, you can:
 1.- Install Bitten:
easy_install http://svn.edgewall.org/repos/bitten/trunk/
 2.- Install my package:
svn co https://svn.gnulinuxmatters.org:81/animador/trunk/ animador
cd animador
./setup.py develop
 3.- Run Bitten's "unittest" extension for setuptools under my package with the
following options:
./setup.py unittest --xml-output build/test-results.xml --coverage-summary
build/test-coverage.txt --coverage-dir build/coverage

Then you'll get a SyntaxError if the patch I attached is not applied.

Cheers.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2983] Ttk support for Tkinter

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

I've added it to PyPi (http://pypi.python.org/pypi/pyttk) yesterday to
facilitate the process of installing the module (without needing to
checkout the repo) in the hope that people will use it, and contribute
to make it better and possibly even support its inclusion into python
(given the chances of getting this into 2.6 and 3.0 are near zero now).

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1758146] Crash in PyObject_Malloc

[Franco DiRosa]

Franco DiRosa <[EMAIL PROTECTED]> added the comment:

I'm unsure if you are understanding what I'm doing so here is the 
story...

I stepped through Py_Initialize and this function takes the main 
interpreter and it's initial thread state and makes that the GIL thread 
state.

The following code in Py_Initialize hijacks the main interpreter and 
thread state for GIL use...

/* auto-thread-state API, if available */
#ifdef WITH_THREAD
_PyGILState_Init(interp, tstate);
#endif /* WITH_THREAD */

WITH_THREAD is defined since I'm using multithreading in my application.

So now if you create thread states from the main interpeter and use the 
PyEval_Acquire/Release and PyThreadState_Swap you will get the 
assertion when compiled with the DEBUG option. If you use the 
PyGILState_Ensure and PyGILState_Release functions you don't. 

What I'm doing is that I have a Windows application with embedded 
python.  The application spawns multiple threads each running a python 
script.  Each application thread has its own unique PyThreadState 
created from the main interpreter because I wanted all the modules 
loaded only once for resource conservation purposes (thus use only one 
interpreter). I used PyEval_Acquire/Release and PyThreadState_Swap to 
handle swapping in each application thread's thread state when each one 
uses the python API.  This worked great in RELEASE compilation but in 
DEBUG it asserted.  Now that I use the GIL functions it works well and 
not only that, I removed the code I had put in myself to handle python 
callback's into the application and avoiding deadlocks by calling 
PyEval_Acquire onto itself (since it uses mutexes which doesn't do 
reference counting so it could deadlock waiting on itself to complete)

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2834] re.IGNORECASE not Unicode-ready

[Mark Summerfield]

Changes by Mark Summerfield <[EMAIL PROTECTED]>:


--
nosy: +mark

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3359] add 'rbU' mode to open()

[anatoly techtonik]

anatoly techtonik <[EMAIL PROTECTED]> added the comment:

Thanks for the hints. It appeared that "universal text mode" is not for
crossplatform but for platform-specific programming. =)

So I gave it up and ended with my own 'rb' newlines counter and 'wb'
writer which inserts lines in required format.

As for 2.6 io.open()
http://docs.python.org/dev/library/io.html#module-io
- can anybody point what's the difference between text mode with
newlines='' and binary mode?
- the comment about newline=
"If it is '', universal newline mode is enabled, but line endings are
returned to the caller untranslated. If it has any of the other legal
values, input lines are only terminated by the given string, and the
line ending is returned to the caller untranslated."
does it mean that if newline='\r\n' is specified all single '\n'
characters are returned inline?

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3433] Mac, 3.0 framework install error with fink cp

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Isn't this a Fink problem then?

--
nosy: +benjamin.peterson

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3433] Mac, 3.0 framework install error with fink cp

[Robin Dunn]

Robin Dunn <[EMAIL PROTECTED]> added the comment:

Maybe, but I think that a more proper approach would be one of the
following:

* Decide that features specific to Apple's cp are required and change
the Makefile to use /bin/cp instead of just cp.

* Use configure to determine if a GNU cp is present and if so adjust the
command-line parameters used.

* Just use the $(INSTALL) value already set by configure as already used
in the main Makefile.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3359] add 'rbU' mode to open()

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

> does it mean that if newline='\r\n' is specified all single '\n'
> characters are returned inline?
Yes.

Let's take a file with mixed newlines:
>>> io.open("c:/temp/t", "rb").read()
'a\rb\r\nc\nd\n'

rb mode splits only on '\r\n' (I'm on Windows)
>>> io.open("c:/temp/t", "rb").readlines()
['a\rb\r\n', 'c\n', 'd\n']

rU mode splits on every newline, and converts everything to \n
>>> io.open("c:/temp/t", "rU").readlines()
[u'a\n', u'b\n', u'c\n', u'd\n']

newline='' splits like rU, but does not translate newlines:
>>> io.open("c:/temp/t", newline='').readlines()
[u'a\r', u'b\r\n', u'c\n', u'd\n']

newline='\r\n' only splits on the specified string:
>>> io.open("c:/temp/t", newline='\r\n').readlines()
[u'a\rb\r\n', u'c\nd\n']

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2834] re.IGNORECASE not Unicode-ready

[Antoine Pitrou]

Changes by Antoine Pitrou <[EMAIL PROTECTED]>:


--
assignee:  -> pitrou
priority:  -> critical

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1758146] Crash in PyObject_Malloc

[Graham Dumpleton]

Graham Dumpleton <[EMAIL PROTECTED]> added the comment:

I do understand.

The initial thread, which is effectively a foreign thread to Python to 
begin with, when used to initialise Python, ie., call Py_Initialize(), 
is treated in a special way in as much as as a side effect it does that 
initialisation of GIL internal thread state. This is as you say. But, 
this is the only foreign thread this implicitly occurs for and why the 
main thread is a bit special.

If you were to create additional foreign threads outside of Python, ie., 
in addition to main thread which initialised it, those later threads 
should not fail the Py_DEBUG test unless the code they execute 
explicitly calls the simplified API and by doing so implicitly causes 
internal threadstate for that thread to be created.

Hope this makes sense. Sorry, in a bit of a hurry.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2832] Line numbers reported by extract_stack are offset by the #-*- encoding line

[Antoine Pitrou]

Changes by Antoine Pitrou <[EMAIL PROTECTED]>:


--
nosy: +pitrou

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3436] csv.DictReader inconsistency

[Andrii V. Mishkovskyi]

New submission from Andrii V. Mishkovskyi <[EMAIL PROTECTED]>:

I had to use csv module recently and ran into a "problem" with
DictReader. I had to get headers of CSV file and only after that iterate
throgh each row. But AFAIU there is no way to do it, other then
subclassing. So, basically, right now we have this:

Python 3.0b2+ (unknown, Jul 24 2008, 12:15:52)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import csv
>>> r = csv.DictReader(open('test.csv'))
>>> r.fieldnames
>>> next(r)
{'baz': '13', 'foo': '42', 'bar': '27'}
>>> r.fieldnames
['foo', 'bar', 'baz']

I think it would be much more useful, if DictReader got 'fieldnames' on
calling __init__ method, so this would look like this:
>>> r = csv.DictReader(open('test.csv'))
>>> r.fieldnames
['foo', 'bar', 'baz']

The easy way to do this is to subclass csv.DictReader.
The hard way to do this is to apply the patches I'm attaching. :)
These patches also remove redundant check for self.fieldnames being None
for each next()/__next__() call

--
files: py3k.csv.py.diff
keywords: patch
messages: 70207
nosy: mishok13
severity: normal
status: open
title: csv.DictReader inconsistency
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10965/py3k.csv.py.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3436] csv.DictReader inconsistency

[Andrii V. Mishkovskyi]

Changes by Andrii V. Mishkovskyi <[EMAIL PROTECTED]>:


Added file: http://bugs.python.org/file10966/trunk.csv.py.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3436] csv.DictReader inconsistency

[Andrii V. Mishkovskyi]

Changes by Andrii V. Mishkovskyi <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file10966/trunk.csv.py.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3436] csv.DictReader inconsistency

[Andrii V. Mishkovskyi]

Changes by Andrii V. Mishkovskyi <[EMAIL PROTECTED]>:


Added file: http://bugs.python.org/file10967/trunk.csv.py.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3436] csv.DictReader inconsistency

[Andrii V. Mishkovskyi]

Changes by Andrii V. Mishkovskyi <[EMAIL PROTECTED]>:


--
components: +Library (Lib)
type:  -> behavior

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2566] Py3.0a4 wsgiref simple_server failed to start

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

The same bug is being discussed in #3348

--
nosy: +pitrou
resolution:  -> duplicate
status: open -> closed
superseder:  -> Cannot start wsgiref simple server in Py3k

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3348] Cannot start wsgiref simple server in Py3k

[Antoine Pitrou]

Changes by Antoine Pitrou <[EMAIL PROTECTED]>:


--
nosy: +delimy

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3437] robotparser.py missing one line

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
assignee:  -> skip.montanaro
nosy: +skip.montanaro

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3438] PyCF_DONT_IMPLY_DEDENT can be used to activate the with statement

[Guilherme Polo]

New submission from Guilherme Polo <[EMAIL PROTECTED]>:

Yesterday I read at a maillist about IDLE being able to use the "with"
statement in python 2.5 without needing to explicitly doing "from
__future__ import with_statement", then today I started tracing the
origin of this. It starts at the use of the InteractiveInterpreter from
the code module (so this report affects any custom shells based on it),
which uses the codeop module to compile lines.

The Compile class of the codeop module, innocently compiles the passed
source with a PyCF_DONT_IMPLY_DEDENT flag by default (I'm not going to
enter in the other details done by Compile). 
This flag is then converted to PyPARSE_DONT_IMPLY_DEDENT (defined at
parsetok.py with a value of 0x0002) by a PARSER_FLAGS macro at
pythonrun.c. Later on the function parsertok at Parser/parsetok.c is
called and it performs this check "if (flags &
PyPARSE_WITH_IS_KEYWORD)", but PyPARSE_WITH_IS_KEYWORD right now has a
value of 0x0003, so this check ends up working for both
PyPARSE_WITH_IS_KEYWORD and PyPARSE_DONT_IMPLY_DEDENT, causing the
with_statement to be enabled if the PyCF_DONT_IMPLY_DEDENT flag is
passed to the compile builtin.

To test this, start the interpreter (python 2.5) and:

>>> a = compile('with open("something") as x: pass\n', '-', 'single', 0x200)
>>> import __future__
>>> a = compile('with open("something") as x: pass\n', '-', 'single',
__future__.with_statement.compiler_flag)

Notice how it works in both cases. 

The patch added is deadly (!) simple (make clean is needed).

--
components: Interpreter Core
files: new_PyPARSE_WITH_IS_KEYWORD.diff
keywords: patch
messages: 70210
nosy: gpolo
severity: normal
status: open
title: PyCF_DONT_IMPLY_DEDENT can be used to activate the with statement
versions: Python 2.5
Added file: http://bugs.python.org/file10968/new_PyPARSE_WITH_IS_KEYWORD.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3438] PyCF_DONT_IMPLY_DEDENT can be used to activate the with statement

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

"This flag is then converted to PyPARSE_DONT_IMPLY_DEDENT (defined at
parsetok.py with a value of 0x0002"

Sorry, it is defined at "parsetok.h" of course.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3139] bytearrays are not thread safe

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

Here is a patch adding the s* format, and changing files, sockets, and
fileio to use it. For bz2, the immediate effect is that you get a type
error (as an object providing bf_releasebuffer cannot be converted
through s#/w# anymore); it would be possible to fix bz2 also to use
s*/w* instead.

I'd like reviewers to focus on flaws in the approach and bugs in the
implementation; existing code should be converted to the new API
afterwards (or not converted at all for 2.6/3.0, but only as patches get
contributed).

If this is accepted in principle, I'll forward-port it to 3.0.

Added file: http://bugs.python.org/file10969/s_star.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3437] robotparser.py missing one line

[mARK]

New submission from mARK <[EMAIL PROTECTED]>:

RobotFileParser.parse() contains the lines

elif line[0] == "disallow":
if state != 0:
entry.rulelines.append(RuleLine(line[1], False))
state = 2
elif line[0] == "allow":
if state != 0:
entry.rulelines.append(RuleLine(line[1], True))

with no 'state = 2' in the 'allow' part.
This causes different behaviour depending on whether the file ends with
'allow' or 'disallow', or an empty line.

Those lines were taken from revision 65118.  My Python 2.5 sources are
similar.  I have not checked others.

--
components: Library (Lib)
messages: 70209
nosy: mbloore
severity: normal
status: open
title: robotparser.py missing one line
type: behavior
versions: Python 2.5, Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3436] csv.DictReader inconsistency

[Raymond Hettinger]

Raymond Hettinger <[EMAIL PROTECTED]> added the comment:

I think this is the wrong approach.  It would be better to have a 
separate getheader() method.  Having __init__ do the deed is at odds 
with other uses of __init__ that only do setup but don't start reading.

--
nosy: +rhettinger

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3436] csv.DictReader inconsistency

[Andrii V. Mishkovskyi]

Andrii V. Mishkovskyi <[EMAIL PROTECTED]> added the comment:

And how this method should look?
Something like this, I suppose:
def getheader(self):
if self.fieldnames is None:
try:
self.fieldnames = self.reader.next()
except StopIteration:
pass
 return self.fieldnames

Well, adding new API after beta2 is a "no-no" as I understand, so this
getheader() method can be added only in 2.7/3.1 releases. Should I post
updated patches or just live with it?

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3394] zipfile.writestr doesn't set external attributes, so files are extracted mode 000 on Unix

[Dylan Grose]

Changes by Dylan Grose <[EMAIL PROTECTED]>:


--
nosy: +dkbg

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3256] Multiprocessing docs are not 3.0-ready

[Andrii V. Mishkovskyi]

Andrii V. Mishkovskyi <[EMAIL PROTECTED]> added the comment:

btw, some of the docstrings are also outdated, e.g. Pool.imap, Pool.map,
etc. Should I handle this one too?

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3439] math.frexp and obtaining the bit size of a large integer

[Fredrik Johansson]

New submission from Fredrik Johansson <[EMAIL PROTECTED]>:

Python 3.0b2 (r30b2:65106, Jul 18 2008, 18:44:17) [MSC v.1500 32 bit
(Intel)] on
 win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> math.frexp(10**100)
(0.5714936956411375, 333)
>>> math.frexp(10**1000)
Traceback (most recent call last):
  File "", line 1, in 
OverflowError: Python int too large to convert to C double
>>>

(Same behavior in Python 2.5.2, and presumably 2.6 although I haven't
checked the latter.)

I think it should be easy to make frexp work for large integers by
calling PyLong_AsScaledDouble and adding the exponents. It would be
logical to fix this since math.log(n) already works for large integers.

My reason for requesting this change is that math.frexp is the fastest
way I know of to accurately count the number of bits in a Python integer
(it is more robust than math.log(n,2) and makes it easy to verify that
the computed size is exact) and this is something I need to do a lot.

Actually, it would be even more useful to have a standard function to
directly obtain the bit size of an integer. If I'm not mistaken,
PyLong_NumBits does precisely this, and would just have to be wrapped.
Aside from my own needs (which don't reflect those of the Python
community), there is at least one place in the standard library where
this would be useful: decimal.py contains an inefficient implementation
(_nbits) that could removed.

--
components: Library (Lib)
messages: 70216
nosy: fredrikj
severity: normal
status: open
title: math.frexp and obtaining the bit size of a large integer
type: feature request
versions: Python 2.6, Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3438] PyCF_DONT_IMPLY_DEDENT can be used to activate the with statement

[Roger Demetrescu]

Changes by Roger Demetrescu <[EMAIL PROTECTED]>:


--
nosy: +rdemetrescu

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3256] Multiprocessing docs are not 3.0-ready

[Jesse Noller]

Jesse Noller <[EMAIL PROTECTED]> added the comment:

that's your call Andrii

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3359] add 'rbU' mode to open()

[anatoly techtonik]

anatoly techtonik <[EMAIL PROTECTED]> added the comment:

This '\r' makes things worse. I am also on Windows and didn't thought
that "rb" processes '\r\n' linefeeds as a side-effect of '\n' being the
last character. Thanks.

newline='' is just what I need. I guess there is no alternative to it in
2.5 series except splitting lines returned from binary read manually.
What about file.newlines attribute - is it preserved in 2.6/Py3k?

BTW, it would be nice to have this example in manual.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3359] add 'rbU' mode to open()

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

Please read
http://docs.python.org/dev/library/io.html#io.TextIOBase.newlines

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2417] [py3k] Integer floor division (//): small int check omitted

[Facundo Batista]

Facundo Batista <[EMAIL PROTECTED]> added the comment:

Commited in r65220.

Thank you everybody!!

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

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2916] urlgrabber.grabber calls setdefaulttimeout

[Georg Brandl]

Changes by Georg Brandl <[EMAIL PROTECTED]>:


--
resolution:  -> invalid
status: open -> closed
versions: +3rd party -Python 2.5

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3439] math.frexp and obtaining the bit size of a large integer

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

Would you like to work on a patch?

--
nosy: +loewis

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1767370] Make xmlrpc use HTTP/1.1 and keepalive

[Donovan Baarda]

Donovan Baarda <[EMAIL PROTECTED]> added the comment:

On Tue, July 22, 2008 05:21, Martin v. Löwis wrote:
>
> Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
>
> We would need the copyright holder of the patch to submit a contributor
> form. Would that be possible?

he works for Google ([EMAIL PROTECTED]), and so do I ([EMAIL PROTECTED])... I
think Google has some sort of company wide contributor agreement, and I
faintly recall signing something before I started working at Google...

krabbe also has a more recent version of this patch that we both keep
failing to submit..

Please let me know if he still needs to sign something, and I'll try to
get him to submit his most recent version of this...

> --
> nosy: +loewis
>
> ___
> Python tracker <[EMAIL PROTECTED]>
> 
> ___
>

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3439] math.frexp and obtaining the bit size of a large integer

[Raymond Hettinger]

Raymond Hettinger <[EMAIL PROTECTED]> added the comment:

I prefer your idea to expose PyLong_Numbits().  IMO, frexp() is very 
much a floating point concept and should probably remain that way.

--
nosy: +rhettinger

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3256] Multiprocessing docs are not 3.0-ready

[Andrii V. Mishkovskyi]

Andrii V. Mishkovskyi <[EMAIL PROTECTED]> added the comment:

OK, I'll work on this too. :) Patch should be ready by Monday.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3440] Starting Python as a subprocess fails when subprocess.Popen has env argument

[Lenard Lindstrom]

New submission from Lenard Lindstrom <[EMAIL PROTECTED]>:

Python 2.6b2 (r26b2:65106, Jul 18 2008, 18:22:27) [MSC v.1500 32 bit
(Intel)] on win32

Windows XP Professional, SP 2

Library class subprocess.Popen


When subprocess.Popen is used to start the python interpreter as a
subprocess with a custom environment, env is set to a mapping, the
subprocess terminates with the following pop-up error dialog:

"The application failed to initialize properly (0xc0150004). Click on OK
to terminate the application."

The attached fail.py program reproduces the bug. It should print "ABCDE"
if successful. It does for Pythons 2.4 and 2.5.

The reason is that Python 2.6 on Windows requires the environment
variable SystemRoot, which it cannot find. This is demonstrated by
modifying fail.py to include SystemRoot in the environment. This works:

import sys
import os
import subprocess

command = ('''%s -c "import os; print os.environ['YAHOO']"''' %
   sys.executable)

env = {"YAHOO": "ABCDE", "SystemRoot": os.environ["SystemRoot"]}
subprocess.Popen(command, env=env).wait()

--
components: Library (Lib), Windows
files: fail.py
messages: 70225
nosy: kermode
severity: normal
status: open
title: Starting Python as a subprocess fails when subprocess.Popen has env 
argument
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file10970/fail.py

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3422] sphinx.doc.autodoc: Hook for changing argspec

[Pauli Virtanen]

Pauli Virtanen <[EMAIL PROTECTED]> added the comment:

Suggested patch attached. Tested on Numpy documentation.

It adds a new signal,

autodoc-process-signature(app, what, name, obj, options,
  signature, return_annotation)

which is assumed to return either None or a 
new (signature, return_annotation) tuple. Warnings are raised
only if introspection fails and none of the event handlers returns
a new signature.

--
keywords: +patch
Added file: http://bugs.python.org/file10971/autodoc-process-signature.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3353] make built-in tokenizer available via Python C API

[Fredrik Lundh]

Fredrik Lundh <[EMAIL PROTECTED]> added the comment:

That's should be all that's needed to expose the existing API, as is. 
If you want to verify the build, you can grab the pytoken.c and setup.py
files from this directory, and try building the module.

http://svn.effbot.org/public/stuff/sandbox/pytoken/

Make sure you remove the local copy of "tokenizer.h" that's present in
that directory before you build.  If that module builds, all's well.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3439] math.frexp and obtaining the bit size of a large integer

[Raymond Hettinger]

Raymond Hettinger <[EMAIL PROTECTED]> added the comment:

Another reason to leave frexp() untouched  is that it is tightly 
coupled to ldexp() as its inverse, for a lossless roundtrip:

  assert ldexp(*frexp(pi)) == pi

This relationship is bound to get mucked-up or confused if frexp starts 
accepting large integers that are no exactly representable as floats 
(i.e. 2**100+1).

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1767370] Make xmlrpc use HTTP/1.1 and keepalive

[Martín Conte Mac Donell]

Martín Conte Mac Donell <[EMAIL PROTECTED]> added the comment:

I've signed and faxed the form. Just in case.

Martin.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3439] math.frexp and obtaining the bit size of a large integer

[Fredrik Johansson]

Fredrik Johansson <[EMAIL PROTECTED]> added the comment:

Raymond, yes, I think that a separate numbits function would better,
although exposing this functionality would not prevent also changing the
behavior of frexp. As I said, math.log already knows about long
integers, so handling long integers similarly in frexp would not be all
that unnatural. (On the other hand, it is true that math.sqrt, math.pow,
math.cos, etc could all theoretically be "fixed" to work with
larger-than-double input, and that slippery slope is probably better
avoided.)

Good point about roundtripping, but the problem with that argument is
that frexp already accepts integers that cannot be represented exactly,
e.g.:

>>> ldexp(*frexp(10**100)) == 10**100
False

Anyway, if there is support for exposing _PyLong_Numbits, should it be a
method or a function? (And if a function, placed where? Should it accept
floating-point input?)

I'm attaching a patch (for the trunk) that adds a numbits method to the
int and long types. My C-fu is limited, and I've never hacked on Python
before, so the code is probably broken or otherwise bad in several ways
(but in that case you can tell me about it and I will learn something
:-). I did not bother to optimize the implementation for int, and the
tests may be redundant/incomplete/placed wrongly.

A slight problem is that _PyLong_NumBits is restricted to a size_t, so
it raises an OverflowError on 32-bit platforms for some easily
physically representable numbers:

>>> (1<<3*10**9).numbits()
Traceback (most recent call last):
  File "", line 1, in 
OverflowError: long int too large to convert to int

This would need to be fixed somehow.

If numbits becomes a method, should it also be added to the Integral
ABC? GMPY's mpz type, by the way, defines a method numdigits(self,
base). This generalization would possibly be overkill, but it's worth
considering.

If it's too late to add this method/function for 2.6 and 3.0, please
update the issue version field as appropriate.

--
keywords: +patch
Added file: http://bugs.python.org/file10972/numbits.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3439] math.frexp and obtaining the bit size of a large integer

[Raymond Hettinger]

Raymond Hettinger <[EMAIL PROTECTED]> added the comment:

numbers.Integral is already way too fat of an API.  Am -1 on expanding 
it further.  Recommend sticking with the simplest, least invasive, 
least pervasive version of your request, a numbits() method for ints.

FWIW, in Py2.6 you can already write:

  def numbits(x):
  return len(bin(abs(x))) - 2

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

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3366] Add gamma and error functions to math module

[nirinA raseliarison]

Changes by nirinA raseliarison <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file10954/mathmodule.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3366] Add gamma and error functions to math module

[nirinA raseliarison]

Changes by nirinA raseliarison <[EMAIL PROTECTED]>:


Added file: http://bugs.python.org/file10973/pymath.c.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3366] Add gamma and error functions to math module

[nirinA raseliarison]

Changes by nirinA raseliarison <[EMAIL PROTECTED]>:


Added file: http://bugs.python.org/file10974/mathmodule.c.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3366] Add gamma and error functions to math module

[nirinA raseliarison]

Changes by nirinA raseliarison <[EMAIL PROTECTED]>:


Added file: http://bugs.python.org/file10975/pymath.h.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3366] Add gamma and error functions to math module

[nirinA raseliarison]

Changes by nirinA raseliarison <[EMAIL PROTECTED]>:


Added file: http://bugs.python.org/file10976/test_math.py.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3366] Add gamma and error functions to math module

[nirinA raseliarison]

nirinA raseliarison <[EMAIL PROTECTED]> added the comment:

Mark Dickinson :
> So a full patch for this should touch at least Python/pymath.c, 
> Modules/mathmodule.c, configure.in, Lib/test/test_math.py, and 
> Doc/Library/math.rst.
here are patches for Python/pymath.c, Modules/mathmodule.c,
Lib/test/test_math.py, Doc/Library/math.rst and also Include/pymath.h.
i haven't touched configure.in as i've erf, erfc, lgamma and tgamma
on my platform, so the patches can be tested.
the doc may need better wording and test_math.py some additionnal tests.

Raymond Hettinger:
> It would be nice if we knew the error bounds for each of the 
> approximation methods. Do we know how the coefficients were generated?
it will be really great if we're able to regenerate all these
coefficients. this may be done by following the comments in
the original codes, but not that easy and not sure one will obtain
the same things.

> The lowword/highword macros look to be tightly tied to the internal 
> processor representation for floats.  It would be more portable and 
> maintainable to replace that bit twiddling with something based on frexp
it seems possible to avoid the use of these macros.
i'll try to find time to dig up these possibilities.

Added file: http://bugs.python.org/file10977/math.rst.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3366] Add gamma and error functions to math module

[Raymond Hettinger]

Raymond Hettinger <[EMAIL PROTECTED]> added the comment:

Why isn't tgamma() simply named gamma()?  The t prefix does nothing for 
me except raise questions.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3437] robotparser.py missing one line

[Skip Montanaro]

Skip Montanaro <[EMAIL PROTECTED]> added the comment:

Do you have a concrete robots.txt file I can use in a test case?

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3437] robotparser.py missing one line

[Skip Montanaro]

Skip Montanaro <[EMAIL PROTECTED]> added the comment:

Perhaps more important than a test case, can you explain what states 0, 1 
and 2 are (maybe give them some symbolic names I can at least put in a 
comment)?  This is not my code.  Though I wrote the first version of the 
robotparser module and I served as the person who checked this version 
into the repo, as I recall this is a complete rewrite.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3437] robotparser.py missing one line

[Skip Montanaro]

Skip Montanaro <[EMAIL PROTECTED]> added the comment:

*sigh* there are no test cases with Allow: lines in test_robotparser.py.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3437] robotparser.py missing one line

[Skip Montanaro]

Skip Montanaro <[EMAIL PROTECTED]> added the comment:

*sigh* there are no test cases in the current code with Allow: lines in 
test_robotparser.py.

--
priority:  -> normal
versions: +Python 2.6

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3437] robotparser.py missing one line

[Skip Montanaro]

Changes by Skip Montanaro <[EMAIL PROTECTED]>:


___
Python tracker <[EMAIL PROTECTED]>

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

[issue3436] csv.DictReader inconsistency

[Skip Montanaro]

Skip Montanaro <[EMAIL PROTECTED]> added the comment:

That would be a fairly easy change to the DictReader class (see
the attached patch) but probably can't be applied at this point
in the 2.6 release cycle even though all csv module tests pass
with it.

--
nosy: +skip.montanaro
Added file: http://bugs.python.org/file10978/csv.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1767370] Make xmlrpc use HTTP/1.1 and keepalive

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

If this is under the Google agreement, then it's fine (I think). It's
just that we can't accept anonymous contributions (even if made through
a known middleman).

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3441] Regression in "module as a script" command-line option

[Richard Jones]

New submission from Richard Jones <[EMAIL PROTECTED]>:

The Python 2.5 "-m" command-line option allowed execution of a package
directly, by invoking the __init__.py module.

Python 2.6 no longer allows this.

This is a quite unfortunate regression, and I would urge the decision to
hobble it to be reconsidered.

--
messages: 70240
nosy: richard
severity: normal
status: open
title: Regression in "module as a script" command-line option
versions: Python 2.6

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3441] Regression in "module as a script" command-line option

[Richard Jones]

Changes by Richard Jones <[EMAIL PROTECTED]>:


--
type:  -> behavior

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3366] Add gamma and error functions to math module

[Daniel Stutzbach]

Daniel Stutzbach <[EMAIL PROTECTED]> added the comment:

I think he just carried the names over from C, where:

tgamma() is the "true gamma function"
lgamma() is the log of the gamma function

and gamma() might be tgamma() or lgamma() depending on which C library
you use (sigh).

I'm +1 on making gamma() be the true gamma function and not carrying
over this brain-damage to Python.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3358] 2to3 Iterative Wildcard Matching

[Collin Winter]

Collin Winter <[EMAIL PROTECTED]> added the comment:

Yeah, benchmarking this change against the unmodified HEAD, the
iterative version runs the test suite much slower. Let's file this under
the "didn't work out" category. It was a good idea that you obviated
with the fix_imports improvements.

___
Python tracker <[EMAIL PROTECTED]>

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