[issue4261] The pwd module doesn't distinguish between errors and no user

[Peter Åstrand]

New submission from Peter Åstrand <[EMAIL PROTECTED]>:

The getpwnam function in the pwd module does not correctly distinguish
between the case when the user does not exist and error
conditions. getpwnam() returns NULL in both cases, the the calling
code needs to check errno to determine if an error occured or not. 

This bug is problematic in conjunction with bug
https://bugzilla.redhat.com/show_bug.cgi?id=470003, since it means
that Pythons getpwnam() will sometimes raise KeyError even for valid
users. How to reproduce:

$ python
Python 2.4.3 (#1, Jan 14 2008, 18:32:40)
[GCC 4.1.2 20070626 (Red Hat 4.1.2-14)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pwd
>>> pwd.getpwnam("astrand")
('astrand', '*', 164, 20164, 'Peter Astrand', '/home/astrand', '/bin/bash')
>>>
>>> pwd.getpwnam("astrand")
Traceback (most recent call last):
  File "", line 1, in ?
KeyError: 'getpwnam(): name not found: astrand'
>>>
>>> pwd.getpwnam("astrand")
('astrand', '*', 164, 20164, 'Peter Astrand', '/home/astrand', '/bin/bash')
>>>

I was restarting the OpenLDAP server between the first successful call
and the traceback one.

--
components: Library (Lib)
messages: 75516
nosy: astrand
severity: normal
status: open
title: The pwd module doesn't distinguish between errors and no user
type: behavior
versions: Python 2.4

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3588] sysconfig variable LINKFORSHARED has wrong value for MacOS X framework build

[Matteo Bertini]

Matteo Bertini <[EMAIL PROTECTED]> added the comment:

I can add that providing the option:

-mmacosx-version-min=10.4

or setting the anv var

MACOSX_DEPLOYMENT_TARGET=10.4

is it possible to build an extension in MacPython.org too
(without that option there was a problem with some 10.5 libs)

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[STINNER Victor]

STINNER Victor <[EMAIL PROTECTED]> added the comment:

> As for marhsalled data and pyc compatibility, yes that is important to
> consider.

The problem is also that with the 30-bit digit patch, some Python will use 15 
bits whereas some other will use 30 bits. The base in marshal should be the 
same in both cases.

And why 30 bits and not 31 bits, or 63 bits, or 120 bits? We may use other 
bases in the future. That's why I prefer to use a common base like base 256. 
And GMP has functions (mpz_import) to load data in base 256, but it's more 
complicate to load data in base 2^15.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4261] The pwd module doesn't distinguish between errors and no user

[STINNER Victor]

STINNER Victor <[EMAIL PROTECTED]> added the comment:

You're right. getpwnam() and getpwuid() have to check errno. A 
different error should be raised, something like:
   RuntimeError("getpwnam(%s) failure: %s" % (name, strerror(errno)))

The grp should also be affected.

--
nosy: +haypo

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4262] import and compile() do not treat trailing whitespace the same

[Mark Seaborn]

New submission from Mark Seaborn <[EMAIL PROTECTED]>:

compile() raises a SyntaxError if the source code it is given contains
trailing spaces or a trailing carriage return character, but this does
happen if the same source code is imported or executed.

import subprocess

data = "if True:\n  pass\n  "
filename = "/tmp/test.py"
fh = open(filename, "w")
fh.write(data)
fh.close()
subprocess.check_call(["python", filename])
subprocess.check_call(["python", "-c", "import test"], cwd="/tmp")
compile(data, filename, "exec")


This gives:

Traceback (most recent call last):
  File "whitespace.py", line 11, in 
compile(data, filename, "exec")
  File "/tmp/test.py", line 3

SyntaxError: invalid syntax

This also happens if the data is changed to:
data = "if True:\n  pass\r"

--
components: Interpreter Core
messages: 75521
nosy: mseaborn
severity: normal
status: open
title: import and compile() do not treat trailing whitespace the same
type: behavior
versions: 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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

[Victor Stinner]
> I saw that you choosed to use the base 2^30 for marshal. For a better 
> portability (be able to use .pyc generated without your patch), you 
> may keep the base 2^15. I implemented that in my GMP patch (manual 
> conversion from/to base 2^15).

Agreed.  I'll fix this so that the .pyc format is unchanged. Thanks!

> And why 30 bits and not 31 bits, or 63 bits, or 120 bits?

Mostly laziness: the change from 15 to 30 bits turned out to be extraordinarily 
easy.  Note that the longobject.c part of 
the patch does almost nothing except adding a bunch of casts here and there.

31 bits would involve rewriting the powering algorithm, which assumes that 
PyLong_SHIFT is divisible by 5.  It would gain 
very little over 30 bits, and if Pernici Mario's optimizations are considered 
(issue 3944) multiplication would likely be 
slower with 31-bit digits than with 30-bit digits.

63 (or 62, or 60) bits is simply too large right now:  you'd need access to a 
hardware 64 x 64 -> 128 bit multiply to make 
this worth it, and I'd guess there are many fewer platforms that make this 
easy, though I don't really know.  I know it's 
possible on gcc/x86_64 by making use of the (undocumented) __uint128_t type.  
But even where this type is available, base 
2**63 might still be slower than base 2**30. I've done some experiments with 
multiprecision *decimal* arithmetic in C that 
showed that even on a 64-bit machine, using base 10**9 (i.e. approx 30 bits) 
was significantly faster than using base 
10**18.

120 bits?  Does GMP even go this far?  I guess part of the attraction is that 
it's a multiple of 8...

The other obvious choices to consider would be 32 bits (or 16 bits, or 64 
bits).  This is possible, and may even be worth 
it, but it would be a *much* bigger effort; most of the algorithms would need 
to be rewritten.  One problem is again the 
mismatch between C and assembler:  detecting overflow when adding two 32-bit 
unsigned integers is trivial in x86 assembler, 
but it's not so obvious how to write portable C code that has a decent chance 
of being compiled optimally on a wide variety 
of compilers. 

I guess my feeling is simply that the 15-bit to 30-bit change seems incredibly 
easy and cheap: very little code change, and 
hence low risk of accidental breakage.  So if there are indeed significant 
efficiency benefits (still to be determined) then 
it looks like a clear win to me.

[Gregory Smith]
> (i haven't reviewed your autoconf stuff yet)

The changes to configure and pyconfig.h are just from rerunning autoconf and 
autoheader;  it's only configure.in that should 
need looking at.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[STINNER Victor]

STINNER Victor <[EMAIL PROTECTED]> added the comment:

> > And why 30 bits and not 31 bits, or 63 bits, or 120 bits?
>
> Mostly laziness (...)

It was an argument for changing the base used by the mashal :-)

> 31 bits would involve rewriting the powering algorithm, which assumes that
> PyLong_SHIFT is divisible by 5

Powering is an simple algorithm. If it was the division, it would be much 
harder :-) Python stores the sign of the number in the first digit. Because 
of that, we are limited to 15/30 bits. Storing the sign in the size (which 
size? no idea yet) would allows to use a bigger base (31 bits? 63 bits?).

> One problem is again the mismatch between C and assembler:  detecting
> overflow when adding two 32-bit unsigned integers is trivial in x86
> assembler, but it's not so obvious how to write portable C code that has a
> decent chance of being compiled optimally on a wide variety of compilers.

I wrote an example to detect overflows in C on the mailing list. Copy of my 
email:
--- 8< --
About 31, 32, 63 or 64 bits: I guess that you want to avoid integer overflow. 
Intel has an "overflow" flag, changed for all instructions. For other CPUs, 
you can use emulate this flag. Example with the type int that I used in my 
GMP patch:

Add:
  int a, b, sum;
  sum = a + b;
  exact = ((a < 0) ^ (b < 0)) || ((a < 0) == (sum < 0));

Substract:
  int a, b, diff;
  diff = a + b;
  exact = ((a < 0) == (b < 0)) || ((a < 0) == (diff < 0));

Multiply:
  int a, b, product;
  if (a == 0 || b == 0) {
 product = 0;  /* exact */
  } else if (a != INT_MIN || (b == 1)) {
 product = a * b;
 exact = (product / b) == a);
  } else {
 /* INT_MIN * -1 = -INT_MIN: overflow */
  }

Divide:
  int a, b, q;
  if (a != INT_MIN || b != -1) {
 q = a / b;   /* exact */
  } else {
 /* INT_MIN / -1 = -INT_MIN: overflow */
  }

Checking overflow may costs more than using a smaller base. Only a benchmark 
can answer ;-)
--- 8< --

> I guess my feeling is simply that the 15-bit to 30-bit change seems
> incredibly easy and cheap: very little code change, and hence low risk of
> accidental breakage.

Python has an amazing regression test suite! I used it to fix my GMP patch. We 
can experiment new bases using this suite.

Anyway, i love the idea of using 30 bits instead of 15! Most computer are now 
32 or 64 bits! But it's safe to keep the 15 bits version to support older 
computers or buggy compilers.

I started to work with GIT. You may be interrested to work together on GIT. 
It's much easier to exchanges changeset and play with branches. I will try to 
publish my GIT tree somewhere.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4263] BufferedWriter non-blocking overage

[Banesiu Sever]

New submission from Banesiu Sever <[EMAIL PROTECTED]>:

In some corner cases io.BufferedWriter raises an io.BlockingIOError
"lying" about the number of characters written.
I've added some tests and a small change to fix this issue.

--
components: Library (Lib)
files: bw_overage.diff
keywords: patch
messages: 75523
nosy: banesiu.sever
severity: normal
status: open
title: BufferedWriter non-blocking overage
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file11945/bw_overage.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4233] open(0, closefd=False) prints 3 warnings

[Barry A. Warsaw]

Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:

Small typo, conveyed to Crys_ in irc.

--
nosy: +barry
resolution:  -> accepted

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4264] Patch: optimize code to use LIST_APPEND instead of calling list.append

[David Turner]

New submission from David Turner <[EMAIL PROTECTED]>:

This is a patch to Tom Lee's AST optimization branch.

Python bytecode includes at least one operation which is not directly
accessible from Python code: LIST_APPEND, which pops a value and a list
off the stack and appends the value to the list. This is used in
generating code for list comprehensions:

[x for x in somelist]

generates the following code for the body of the loop:

...
LOAD_FAST 1#a local is generated to hold the new list
LOAD_FAST 2 #the iteration variable, x
LIST_APPEND
...

Whereas if you were to try to write the comprehension directly, you
would get:

LOAD_FAST 1
LOAD_ATTR 0 #an index into the constant table: “append”
LOAD_FAST 2
CALL_FUNCTION 1 #remove x and the append function from the top of the
stack and push the result of the call
POP_TOP

This is much slower. In part, it’s the cost of doing the attribute
lookup each time, which is why it’s common to see code like a = [] ap =
a.append for x in …..: ap(x + …) return a But the function call is
naturally slower than the simpler LIST_APPEND operation. The attached
patch tries to determine statically if a local is all circumstances
holds a list, and if so, generates LIST_APPEND whenever user code would
call local.append.  It’s not perfect — in particular, I could track
local types on a more fine-grained level than per-function. But it’s a
start.

--
files: tlee-ast-optimize-appends.diff
keywords: patch
messages: 75525
nosy: novalis_dt
severity: normal
status: open
title: Patch: optimize code to use LIST_APPEND instead of calling list.append
Added file: http://bugs.python.org/file11946/tlee-ast-optimize-appends.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4233] open(0, closefd=False) prints 3 warnings

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

Applied in r67106 (py3k)

The patch must be backported to 2.6 and 2.7.

--
assignee:  -> christian.heimes
resolution: accepted -> fixed
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

[issue4233] open(0, closefd=False) prints 3 warnings

[Christian Heimes]

Changes by Christian Heimes <[EMAIL PROTECTED]>:


--
priority: release blocker -> high
versions: +Python 2.6, Python 2.7 -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

[issue1210] imaplib does not run under Python 3

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

Committed in r67107

--
resolution: accepted -> 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

[issue3714] nntplib module broken by str to unicode conversion

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

Applied in revision r67108

--
nosy: +christian.heimes
resolution: accepted -> 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

[issue3727] poplib module broken by str to unicode conversion

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

Patch applied in r67109

--
nosy: +christian.heimes
resolution: accepted -> 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

[issue4265] shutil.copyfile() leaks file descriptors when disk fills

[Ammon Riley]

New submission from Ammon Riley <[EMAIL PROTECTED]>:

If the disk fills up during the copy operation, shutil.copyfile() leaks
file descriptors. 

The problem is the order of the close() statements in the finally block.
In the event the copy operation runs out of disk space, the fdst.close()
call triggers an IOError, which prevents the fsrc.close() call from being
called. 

Swapping the two calls, so that fsrc is closed first prevents this issue,
though it doesn't solve the underlying problem that IOErrors raised during
the close() operation will prevent the second close() from being called.

A probably better solution:

def copyfile(src, dst):
"""Copy data from src to dst"""
if _samefile(src, dst):
raise Error, "`%s` and `%s` are the same file" % (src, dst)

fsrc = None
fdst = None
try:
fsrc = open(src, 'rb')
fdst = open(dst, 'wb')
copyfileobj(fsrc, fdst)
finally:
try:
if fsrc:
fsrc.close()
finally:
if fdst:
fdst.close()

--
components: Library (Lib)
messages: 75530
nosy: ammon_riley
severity: normal
status: open
title: shutil.copyfile() leaks file descriptors when disk fills
type: resource usage
versions: 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

[issue4211] frozen packages set an improper __path__ value

[Nick Coghlan]

Nick Coghlan <[EMAIL PROTECTED]> added the comment:

FWIW, I agree with the idea of fixing it for 3.0 and leaving it in for 2.x.

--
nosy: +ncoghlan

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4262] import and compile() do not treat trailing whitespace the same

[Brett Cannon]

Changes by Brett Cannon <[EMAIL PROTECTED]>:


--
nosy: +brett.cannon

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4211] frozen packages set an improper __path__ value

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

I approve of the API change. It's 3.0, dammit!

--
nosy: +gvanrossum
resolution:  -> accepted

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4211] frozen packages set an improper __path__ value

[Benjamin Peterson]

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

Fixed in r67112.

--
nosy: +benjamin.peterson
resolution: accepted -> 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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

Following Victor's suggestion, here's an updated patch; same as before, 
except that marshal now uses base 2**15 for reading and writing, 
independently of whether PyLong_SHIFT is 15 or 30.

Added file: http://bugs.python.org/file11947/30bit_longdigit3.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[STINNER Victor]

Changes by STINNER Victor <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file11936/30bit_longdigit2.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4260] ctypes.xFUNCTYPE are decorators.

[Kevin Watters]

Kevin Watters <[EMAIL PROTECTED]> added the comment:

As far as I know, the above code will fail randomly in release mode if 
you have multiple threads running Python, because when ctypes calls out 
to CFUNCTYPE functions, it releases the GIL.

For decorating a python function to give to qsort, maybe you can use 
PYFUNCTYPE?

--
nosy: +kevinwatters

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[STINNER Victor]

STINNER Victor <[EMAIL PROTECTED]> added the comment:

Mark: would it be possible to keep the "2 digits" hack in 
PyLong_FromLong, especially with base 2^15? Eg. "#if PyLong_SHIFT == 
15". The base 2^15 slow, so don't make it slower :-)

-   /* 2 digits */
-   if (!(ival >> 2*PyLong_SHIFT)) {
-   v = _PyLong_New(2);
-   if (v) {
-   Py_SIZE(v) = 2*sign;
-   v->ob_digit[0] = (digit)ival & PyLong_MASK;
-   v->ob_digit[1] = ival >> PyLong_SHIFT;
-   }
-   return (PyObject*)v;
-   }

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3799] Byte/string inconsistencies between different dbm modules

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

The patch causes three errors:

==
ERROR: test_anydbm_access (test.test_dbm.TestCase-dbm.dumb)
--
Traceback (most recent call last):
  File "/home/heimes/dev/python/py3k/Lib/test/test_dbm.py", line 92, in
test_anydbm_access
f = dbm.open(_fname, 'r')
  File "/home/heimes/dev/python/py3k/Lib/dbm/__init__.py", line 79, in open
raise error[0]("need 'c' or 'n' flag to open new db")
dbm.error: need 'c' or 'n' flag to open new db

==
ERROR: test_anydbm_keys (test.test_dbm.TestCase-dbm.dumb)
--
Traceback (most recent call last):
  File "/home/heimes/dev/python/py3k/Lib/test/test_dbm.py", line 86, in
test_anydbm_keys
f = dbm.open(_fname, 'r')
  File "/home/heimes/dev/python/py3k/Lib/dbm/__init__.py", line 79, in open
raise error[0]("need 'c' or 'n' flag to open new db")
dbm.error: need 'c' or 'n' flag to open new db

==
ERROR: test_anydbm_read (test.test_dbm.TestCase-dbm.dumb)
--
Traceback (most recent call last):
  File "/home/heimes/dev/python/py3k/Lib/test/test_dbm.py", line 80, in
test_anydbm_read
f = dbm.open(_fname, 'r')
  File "/home/heimes/dev/python/py3k/Lib/dbm/__init__.py", line 79, in open
raise error[0]("need 'c' or 'n' flag to open new db")
dbm.error: need 'c' or 'n' flag to open new db

--
Ran 16 tests in 0.429s

FAILED (errors=3)

--
nosy: +christian.heimes

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4247] Docs: Provide some examples of "pass" use in the tutorial.

[Sean Reifschneider]

Sean Reifschneider <[EMAIL PROTECTED]> added the comment:

I'm attaching a new version here, which addresses the object call type
comments.

Added file: http://bugs.python.org/file11948/pass-examples-2.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[STINNER Victor]

STINNER Victor <[EMAIL PROTECTED]> added the comment:

> marshal now uses base 2**15 for reading and writing

Yes, it uses base 2**15 but it's not the correct conversion to base 
2**15. You convert each PyLong digit to base 2**15 but not the whole 
number. As a result, the format is different than the current mashal 
version.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[STINNER Victor]

STINNER Victor <[EMAIL PROTECTED]> added the comment:

PyLong_FromLong() doesn't go into the 1 digit special case for 
negative number. You should use:
/* Fast path for single-digits ints */
if (!(abs_ival>>PyLong_SHIFT)) {
v = _PyLong_New(1);
if (v) {
Py_SIZE(v) = sign;
v->ob_digit[0] = abs_ival;
}
return (PyObject*)v;
}

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3799] Byte/string inconsistencies between different dbm modules

[Barry A. Warsaw]

Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:

I don't see enough progress on this issue, and I'm not going to hold up
3.0rc2 for it, so I'm deferring.

--
nosy: +barry
priority: release blocker -> deferred blocker

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4236] Crash when importing builtin module during interpreter shutdown

[Barry A. Warsaw]

Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:

This seems like a corner case to me.  We should fix it before the final
release, but I don't think it's worth holding up 3.0rc2 for it.  Deferring.

--
priority: release blocker -> deferred blocker

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2744] Fix test_cProfile

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
priority: critical -> high

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3775] Update RELNOTES file

[Barry A. Warsaw]

Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:

This is really done, so closing.

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

[issue3799] Byte/string inconsistencies between different dbm modules

[Skip Montanaro]

Changes by Skip Montanaro <[EMAIL PROTECTED]>:


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

[issue4266] Python 3.0 docs are broken.

[Barry A. Warsaw]

New submission from Barry A. Warsaw <[EMAIL PROTECTED]>:

The Python 3.0 documentation is broken.  This is blocking the 3.0rc2
release.
I'm too tired right now to figure out what the base problem is.

This was during the ".../release.py --export 3.0rc2" build phase.

pdflatex 'c-api.tex'
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
entering extended mode
(./c-api.tex
LaTeX2e <2003/12/01>
Babel  and hyphenation patterns for american, french, german,
ngerman, b
ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch,
esperanto, e
stonian, finnish, greek, icelandic, irish, italian, latin, magyar,
norsk, polis
h, portuges, romanian, russian, serbian, slovak, slovene, spanish,
swedish, tur
kish, ukrainian, nohyphenation, loaded.
(./manual.cls
Document Class: manual 2008/10/18 Document class (Sphinx manual)
(/opt/local/share/texmf-dist/tex/latex/base/report.cls
Document Class: report 2004/02/16 v1.4f Standard LaTeX document class
(/opt/local/share/texmf-dist/tex/latex/base/size10.clo)))
(/opt/local/share/texmf-dist/tex/latex/base/inputenc.sty
(/opt/local/share/texmf-dist/tex/latex/base/utf8.def
(/opt/local/share/texmf-dist/tex/latex/base/t1enc.dfu)
(/opt/local/share/texmf-dist/tex/latex/base/ot1enc.dfu)
(/opt/local/share/texmf-dist/tex/latex/base/omsenc.dfu)))
(/opt/local/share/texmf-dist/tex/latex/base/fontenc.sty
(/opt/local/share/texmf-dist/tex/latex/base/t1enc.def))
(/opt/local/share/texmf-dist/tex/generic/babel/babel.sty
(/opt/local/share/texmf-dist/tex/generic/babel/english.ldf
(/opt/local/share/texmf-dist/tex/generic/babel/babel.def)))
(/opt/local/share/texmf-dist/tex/latex/psnfss/times.sty) (./fncychap.sty)
(./sphinx.sty (/opt/local/share/texmf-dist/tex/latex/base/textcomp.sty
(/opt/local/share/texmf-dist/tex/latex/base/ts1enc.def
(/opt/local/share/texmf-dist/tex/latex/base/ts1enc.dfu)))
(/opt/local/share/texmf-dist/tex/latex/fancyhdr/fancyhdr.sty)
(/opt/local/share/texmf-dist/tex/latex/fancybox/fancybox.sty
Style option: `fancybox' v1.3 <2000/09/19> (tvz)
) (/opt/local/share/texmf-dist/tex/latex/titlesec/titlesec.sty)
(./tabulary.sty
(/opt/local/share/texmf-dist/tex/latex/tools/array.sty))
(/opt/local/share/texmf-dist/tex/latex/amsmath/amsmath.sty
For additional information on amsmath, use the `?' option.
(/opt/local/share/texmf-dist/tex/latex/amsmath/amstext.sty
(/opt/local/share/texmf-dist/tex/latex/amsmath/amsgen.sty))
(/opt/local/share/texmf-dist/tex/latex/amsmath/amsbsy.sty)
(/opt/local/share/texmf-dist/tex/latex/amsmath/amsopn.sty))
(/opt/local/share/texmf-dist/tex/latex/base/makeidx.sty)
(/opt/local/share/texmf-dist/tex/latex/framed/framed.sty)
(/opt/local/share/texmf-dist/tex/latex/graphics/color.sty
(/opt/local/share/texmf-dist/tex/latex/graphics/color.cfg)
(/opt/local/share/texmf-dist/tex/latex/graphics/pdftex.def))
(/opt/local/share/texmf-dist/tex/latex/fancyvrb/fancyvrb.sty
Style option: `fancyvrb' v2.6, with DG/SPQR fixes <1998/07/17> (tvz)
(/opt/local/share/texmf-dist/tex/latex/graphics/keyval.sty)
No file fancyvrb.cfg.
) (/opt/local/share/texmf-dist/tex/latex/graphics/graphicx.sty
(/opt/local/share/texmf-dist/tex/latex/graphics/graphics.sty
(/opt/local/share/texmf-dist/tex/latex/graphics/trig.sty)
(/opt/local/share/texmf-dist/tex/latex/graphics/graphics.cfg)))
(/opt/local/share/texmf-dist/tex/plain/pdfcolor/pdfcolor.tex)
! Extra \fi.
l.62 \fi\fi
   
?

--
assignee: georg.brandl
components: Documentation
messages: 75544
nosy: barry, georg.brandl
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Python 3.0 docs are broken.
type: compile error
versions: 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

[issue4266] Python 3.0 docs are broken.

[Winfried Plappert]

Winfried Plappert <[EMAIL PROTECTED]> added the comment:

This is a simple one to fix: remove the second \fi on the incriminated
line in sphinx.sty, line 62. I just checked out Sphinx version 67115 and
retested. With my fix = removal of the second \fi, the make process works.  

The issue also applies to Python 2.6.

--
nosy: +wplappert
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

[issue4266] Python 3.0 docs are broken.

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

The issue is not as "easy" as it seems (or at least that's what I believe).

Barry, if you install the xetex package, the build should run fine.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4264] Patch: optimize code to use LIST_APPEND instead of calling list.append

[Neal Norwitz]

Neal Norwitz <[EMAIL PROTECTED]> added the comment:

Interesting approach.  I was surprised to see the change to the AST, but
I understand why you did it.  I think if the AST optimization approach
works out well, we will want to have some more general mechanism to
communicate these optimization (or other!) hints to the compiler.  It
would suck to have to modify the AST each time we wanted to add a new
optimization.  You and Tom might have better ideas for how best to
achieve that.

I'll make some comments that would need to be addressed, but you might
want to wait making any changes depending on what approach you decide to
take.

The most important missing piece is tests to show that the new code works.

There are various whitespace issues.  Both whitespace only changes that
should be avoided and indentation inconsistencies with the existing code
(or so it appears).  The latter could be the way I'm viewing the file or
existing problems with tabs.

In Python/optimize.c, you need to handle the case where the PyDict_New()
calls fail.  It looks like currently an undetected error can happen in
during construction.  And on destruction it will crash because the
objects will be NULL when calling Py_DECREF.

All calls like PyDict_SetItem(), PyInt_FromLong(), etc need to handle
errors.

I'll need to study the code a lot more to see how well it behaves. 
Tests would help a lot with that.

--
nosy: +nnorwitz

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4267] sqlite3 documentation

[Gabriel Genellina]

New submission from Gabriel Genellina <[EMAIL PROTECTED]>:

Three small changes to sqlite3 documentation:

1) (mostly cosmetic) In the second example, changed what was "a tuple 
of tuples" to "a list of tuples" to follow common practice.

2) "DEFERRED", "IMMEDIATE" and "EXLUSIVE" (possible values for 
Connection.isolation_level) are strings, not module constants, so 
should be surrounded with quotes.

2) The iterdump example is not well written. Currently says:

   con = sqlite3.connect('existing_db.db')
   full_dump = os.linesep.join(con.iterdump())
   f = open('dump.sql', 'w')
   f.writelines(full_dump)
   f.close()

Using os.linesep to join lines to be written to a text file has strange 
results in non-Unix systems; joining the *whole* database dump into a 
big string isn't a good idea; and finally, writelines(some_string) will 
write the text one char at a time (!). 
I've rewritten it as:

   with open('dump.sql', 'w') as f:
   for line in con.iterdump():
   f.write('%s\n' % line)

to take advantage of iterdump's lazy nature.

--
assignee: georg.brandl
components: Documentation
files: sqlite3.diff
keywords: patch
messages: 75548
nosy: gagenellina, georg.brandl
severity: normal
status: open
title: sqlite3 documentation
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11949/sqlite3.diff

___
Python tracker <[EMAIL PROTECTED]>

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