[issue1158] %f format for datetime objects

[Brett Cannon]

Brett Cannon added the comment:

Are you going to add support to strptime as well?

As for the 'time' module, I don't think it would be useful as it serves
no purpose since the time tuple can't resolve to that resolution.  If
you do add support, though, I guess you just default to 0.

--
nosy: +brett.cannon

__
Tracker <[EMAIL PROTECTED]>

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

[issue1777530] ctypes on Solaris

[Aki]

Aki added the comment:

Sorry for not having done this earlier.
I thought this was already closed ...

I used your updated patch and installed the Python 2.5.1 from scratch.
It worked without any problem except python-config issue, which I have
reported in another case [issue1095].

_
Tracker <[EMAIL PROTECTED]>

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

[issue1158] %f format for datetime objects

[Skip Montanaro]

New submission from Skip Montanaro:

Attached is a patch for py3k which adds a %f format code to its strftime
method.  When included in a format string it expands to the number of
microseconds in the object.  date, time and datetime objects all support
the format (though I'm not sure what, if anything, it means for date
objects).

I don't know how practical this is for time.strftime() level because the
inputs are all so excited about being ints.  Still, if you wanted to
allow the seconds field to be a float and were willing to cast it to an
int where necessary and shadow struct tm with a pseudo-float-friendly
version of the same, you could probably smash it in there as well.

--
components: Extension Modules
files: percent-f.diff
keywords: patch, py3k
messages: 55876
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: %f format for datetime objects
type: rfe
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

__Index: Modules/datetimemodule.c
===
--- Modules/datetimemodule.c	(revision 58132)
+++ Modules/datetimemodule.c	(working copy)
@@ -1177,6 +1177,15 @@
 	return NULL;
 }
 
+static PyObject *
+make_freplacement(PyObject *object)
+{
+	char freplacement[7];
+	sprintf(freplacement, "%06d", TIME_GET_MICROSECOND(object));
+
+	return PyBytes_FromStringAndSize(freplacement, strlen(freplacement));
+}
+
 /* I sure don't want to reproduce the strftime code from the time module,
  * so this imports the module and calls it.  All the hair is due to
  * giving special meanings to the %z and %Z format codes via a preprocessing
@@ -1192,6 +1201,7 @@
 
 	PyObject *zreplacement = NULL;	/* py string, replacement for %z */
 	PyObject *Zreplacement = NULL;	/* py string, replacement for %Z */
+	PyObject *freplacement = NULL;	/* py string, replacement for %f */
 
 	const char *pin;/* pointer to next char in input format */
 Py_ssize_t flen;/* length of input format */
@@ -1243,7 +1253,7 @@
 	 * a new format.  Since computing the replacements for those codes
 	 * is expensive, don't unless they're actually used.
 	 */
-	totalnew = flen + 1;	/* realistic if no %z/%Z */
+	totalnew = flen + 1;	/* realistic if no %z/%Z/%f */
 	newfmt = PyBytes_FromStringAndSize(NULL, totalnew);
 	if (newfmt == NULL) goto Done;
 	pnew = PyBytes_AsString(newfmt);
@@ -1301,6 +1311,18 @@
 			ptoappend = PyBytes_AS_STRING(Zreplacement);
 			ntoappend = PyBytes_GET_SIZE(Zreplacement);
 		}
+		else if (ch == 'f') {
+			/* format microseconds */
+			if (freplacement == NULL) {
+freplacement = make_freplacement(object);
+if (freplacement == NULL)
+	goto Done;
+			}
+			assert(freplacement != NULL);
+			assert(PyBytes_Check(freplacement));
+			ptoappend = PyBytes_AS_STRING(freplacement);
+			ntoappend = PyBytes_GET_SIZE(freplacement);
+		}
 		else {
 			/* percent followed by neither z nor Z */
 			ptoappend = pin - 2;
@@ -1347,6 +1369,7 @@
 		Py_DECREF(time);
 	}
  Done:
+	Py_XDECREF(freplacement);
 	Py_XDECREF(zreplacement);
 	Py_XDECREF(Zreplacement);
 	Py_XDECREF(newfmt);
@@ -3159,7 +3182,7 @@
 {
 	char buf[100];
 	PyObject *result;
-	int us = TIME_GET_MICROSECOND(self);;
+	int us = TIME_GET_MICROSECOND(self);
 
 	if (us)
 		result = PyUnicode_FromFormat("%02d:%02d:%02d.%06d",
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1772851] Decimal and long hash, compatibly and efficiently

[ajaksu]

ajaksu added the comment:

Thanks a lot for the explanation. I still think it could be valuable
(C?)py3k change  (but now for the predictability, as you say :)

Regarding the performance of Decimal.__hash__:

 I believe (int) hash performance would be a moot issue if
Decimal.__int__ was (much) faster. I've been, for the last  three days,
trying to  convert decimal.py to use longs instead of tuples for
Decimal._int. Here are some (hand picked) results (on a Celeron M 1.46GHz):

In [906]: D = int_decimal.Decimal
(...)
In [914]: g = D("1E100")
(...)
In [916]: g
Out[916]: Decimal("1E+100")
(...)
In [918]: %timeit k = int(g)
10 loops, best of 3: 3.22 s per loop
(...)
In [920]: %timeit k = hash(int(g))
10 loops, best of 3: 3.28 s per loop
(...)
In [922]: log(int(g))
Out[922]: 2302585.0929940455

In [923]: log(10**100)
Out[923]: 2302585.0929940455

 I'm not very competent in many skills needed for the job AND I'm
working between field trips (next starts tomorrow), so, unfortunately,
the results are crude and awfully buggy so far. Most "(...)" above were
exceptions for simple things like "hash(g)" and there are lots of these
issues.

The conversion is based on using divisions and multiplications to
truncate/extend Decimal._int, from the notion that the bottleneck is the
tuple->str->int conversion. I predict lots of currently fast things
getting slower and a higher memory footprint, but it might still be
worth it and I'm willing to test the idea.

 As I told Facundo in a private email (y otro llegará hoy o mañana), the
simple cases seem workable for me, but I'm not able to tell right now if
this has any real chances of succeeding (because I'm bad at maths :/).
I've not even looked at __pow__, __mul__ and __div__ yet!

Anyway, I'll try to tidy things up as much as I can and email Facundo
(and yourself, if you are interested) the results of this large ugly
hack before now + 24h.

_
Tracker <[EMAIL PROTECTED]>

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

[issue1686386] Python SEGFAULT on tuple.__repr__ and str()

[Brett Cannon]

Changes by Brett Cannon:


--
title: Python SEGFAULT on invalid superclass access -> Python SEGFAULT on 
tuple.__repr__ and str()

_
Tracker <[EMAIL PROTECTED]>

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

[issue1686386] Python SEGFAULT on invalid superclass access

[Brett Cannon]

Brett Cannon added the comment:

OK, so I have attached a possible patch.  I found out that
tuple.__repr__ didn't do anything to prevent infinite recursion since
you can't pull it off from Python code.  But obviously C code is another
matter.  =)

Same goes for object.__str__; it didn't think about a type's tp_str
doing something that could lead to an infinite recursion.

Assigning back to Georg to make sure I am not doing something stupid nor
that the approach is to broad by changing _PyObject_Str() and
tuple.__repr__ instead of BaseException itself.

I have not written tests yet as they are rather difficult to do for what
the C code is doing without relying specifically on how exceptions do
their __repr__/__str__.

--
assignee: brett.cannon -> georg.brandl
keywords: +patch
status: open -> pending

_
Tracker <[EMAIL PROTECTED]>

_

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

[issue1157] test_urllib2net fails on test_ftp

[Guido van Rossum]

New submission from Guido van Rossum:

==
ERROR: test_ftp (__main__.OtherNetworkTests)
--
Traceback (most recent call last):
  File "Lib/test/test_urllib2net.py", line 173, in test_ftp
self._test_urls(urls, self._extra_handlers())
  File "Lib/test/test_urllib2net.py", line 242, in _test_urls
f = urllib2.urlopen(url, req)
  File "/usr/local/google/home/guido/python/py3k/Lib/urllib2.py", line
122, in urlopen
return _opener.open(url, data, timeout)
  File "/usr/local/google/home/guido/python/py3k/Lib/urllib2.py", line
378, in open
response = self._open(req, data)
  File "/usr/local/google/home/guido/python/py3k/Lib/urllib2.py", line
396, in _open
'_open', req)
  File "/usr/local/google/home/guido/python/py3k/Lib/urllib2.py", line
356, in _call_chain
result = func(*args)
  File "/usr/local/google/home/guido/python/py3k/Lib/urllib2.py", line
1271, in ftp_open
fw = self.connect_ftp(user, passwd, host, port, dirs, req.timeout)
  File "/usr/local/google/home/guido/python/py3k/Lib/urllib2.py", line
1316, in connect_ftp
self.cache[key] = ftpwrapper(user, passwd, host, port, dirs, timeout)
  File "/usr/local/google/home/guido/python/py3k/Lib/urllib.py", line
783, in __init__
self.init()
  File "/usr/local/google/home/guido/python/py3k/Lib/urllib.py", line
790, in init
self.ftp.login(self.user, self.passwd)
  File "/usr/local/google/home/guido/python/py3k/Lib/ftplib.py", line
372, in login
if resp[0] == '3': resp = self.sendcmd('PASS ' + passwd)
  File "/usr/local/google/home/guido/python/py3k/Lib/ftplib.py", line
242, in sendcmd
return self.getresp()
  File "/usr/local/google/home/guido/python/py3k/Lib/ftplib.py", line
208, in getresp
resp = self.getmultiline()
  File "/usr/local/google/home/guido/python/py3k/Lib/ftplib.py", line
198, in getmultiline
nextline = self.getline()
  File "/usr/local/google/home/guido/python/py3k/Lib/ftplib.py", line
181, in getline
line = self.file.readline()
  File "/usr/local/google/home/guido/python/py3k/Lib/io.py", line 1319,
in readline
readahead, pending = self._read_chunk()
  File "/usr/local/google/home/guido/python/py3k/Lib/io.py", line 1123,
in _read_chunk
pending = self._decoder.decode(readahead, not readahead)
  File
"/usr/local/google/home/guido/python/py3k/Lib/encodings/ascii.py", line
26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 47:
ordinal not in range(128)

--
messages: 55873
nosy: gvanrossum
severity: normal
status: open
title: test_urllib2net fails on test_ftp
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

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

[issue1772851] Decimal and long hash, compatibly and efficiently

[Mark Dickinson]

Mark Dickinson
 added the comment:

To help explain what's going on, here's some Python code.  The Python
function long_hash1 below has the properties that:

(1) long_hash1(n) == hash(n) for almost all integers n, with a very
small set of exceptions.  (The first positive exception is 2**33-1, and
the next after that is 3*2**33 - 1.  The negative exceptions have the
same absolute value as the positive ones, so the first negative
exception is n = 1-2**33).

(2) long_hash1(n) has a simple closed form, making it possible to
compute an equivalent Decimal hash efficiently.

(3) The current long_hash in Objects/longobject.c can be changed, by
adding a single line of C code, so that hash(n) == long_hash1(n) always.
That line is:

  if ((unsigned long)x < v->ob_digit[i]) x++;

added directly after the addition.

Explanation: the exceptions in (1) arise precisely when the addition

 x += v->ob_digit[i]

in the long_hash code overflows (in the *unsigned* sense---equivalently,
when the addition turns a negative x into a nonnegative one).  Since
ob_digit[i] only has 15 significant bits, and x has 32 (or 64), such
overflow is going to be rare---it'll occur for roughly one addition in
every 2**18 (or about 4 additions in every million), for `random' n.  So
for `most' n, hash(n) and long_hash1(n) are equal.

So what about long_hash2(n)?  This is what the patched long_hash 
is actually equivalent to;  it's essentially the same as long_hash1(n),
but fixed up to be genuinely periodic;  that is, long_hash1(n+ULONG_MAX)
== long_hash1(n) for any integer n.  long_hash1 and long_hash2 are equal
almost always for positive n (the exceptions being multiples of
ULONG_MAX), equal about half the time for negative n, and off-by-one
from each other about half the time.

I don't really know whether the periodicity is that useful---the
predictability is really what matters, so the 1-line change to produce a
hash function equivalent to long_hash1 would do just fine as far as
making Decimal work.

For what it's worth, I regard this patch as an ugly hack.  I don't like
the idea of changing something as fundamental as long.__hash__, and I
don't like having Decimal.__hash__ depend on knowing exactly how
long.__hash__ gets its values.   But there's a real problem here, namely
that, for example,

>>> set([Decimal("1E100")])

takes several minutes to complete.  (Try it!)  And I can't think of any
other easy way to solve this.  Alternative suggestions welcomed!



LONG_BITS = 32
W = 2**LONG_BITS
HW = W // 2
ULONG_MAX = W - 1

def long_hash1(n):
if n == 0:
h = 0
else:
h = (1 + (abs(n)-1) % ULONG_MAX) * (1 if n > 0 else -1)

# reduce mod W to lie in the usual range for a (signed) C long
h = (h + HW) % W - HW
if h == -1:
h = -2
return int(h)

def long_hash2(n):
h = n % ULONG_MAX

h = (h + HW) % W - HW
if h == -1:
h = -2
return int(h)

_
Tracker <[EMAIL PROTECTED]>

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

[issue1686386] Python SEGFAULT on invalid superclass access

[Brett Cannon]

Changes by Brett Cannon:


--
versions: +Python 2.6

_
Tracker <[EMAIL PROTECTED]>

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

[issue1686386] Python SEGFAULT on invalid superclass access

[Brett Cannon]

Brett Cannon added the comment:

So the first example (in msg31624) crashes because of infinite recursion
with the repr of exceptions::

#7771 0x00065178 in BaseException_repr (self=0x5dc6b8) at
Objects/exceptions.c:128
#7772 0x0001d90c in PyObject_Repr (v=0x5dc6b8) at Objects/object.c:362
#7773 0x0008c180 in tuplerepr (v=0x5dad58) at Objects/tupleobject.c:221

The second one in msg31626 dies because of the str of exceptions::

#3839 0x0001dd88 in PyObject_Str (v=0x5dc6b8) at Objects/object.c:427
#3840 0x00065120 in BaseException_str (self=0x5dc6b8) at
Objects/exceptions.c:110
#3841 0x0001dc0c in _PyObject_Str (v=0x5dc6b8) at Objects/object.c:407

Both fail because BaseException uses the str/repr of its arguments to
construct what string to return.  When it's itself it just goes on
forever trying to get the next object's representation.

The repr issue might be fixed by looking at how lists catch loops in
themselves (don't remember the exact C function).  Either way it is not
really str/repr that is causing the issue but exceptions for not
worrying about possible recursion thanks to using the str/repr of
contained objects.

_
Tracker <[EMAIL PROTECTED]>

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

[issue1145] Allow str.join to join non-string types (as per PEP 3100)

[Guido van Rossum]

Guido van Rossum added the comment:

There's one additional issue.  If any of the items is a bytes, the call
should fail.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1038] [py3k] pdb does not work in python 3000

[Georg Brandl]

Georg Brandl added the comment:

Fixed in rev. 58127.

--
assignee:  -> georg.brandl
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

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

[issue1148] TypeError on join - httplib mixing str and bytes

[Guido van Rossum]

Guido van Rossum added the comment:

Committed revision 58126.

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

__
Tracker <[EMAIL PROTECTED]>

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

[issue1151] "TypeError: expected string, bytes found" instead of KeyboardInterrupt

[Guido van Rossum]

Guido van Rossum added the comment:

Confirmed. Weird.

--
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

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

[issue1019] Cleanup pass on _curses and _curses_panel

[Georg Brandl]

Georg Brandl added the comment:

Unfortunately, the patch is hard to review with all the whitespace
cleanup distracting from semantic changes. Can you produce a patch with
only those changes?

--
nosy: +georg.brandl

__
Tracker <[EMAIL PROTECTED]>

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

[issue1148] TypeError on join - httplib mixing str and bytes

[Guido van Rossum]

Guido van Rossum added the comment:

Confirmed.  I'll fix it ASAP.

--
assignee:  -> gvanrossum
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

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

[issue1686386] Python SEGFAULT on invalid superclass access

[Georg Brandl]

Georg Brandl added the comment:

Brett, you recently fixed an infinite recursion crasher, right?

--
assignee:  -> brett.cannon
nosy: +brett.cannon

_
Tracker <[EMAIL PROTECTED]>

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

[issue1098] decode_unicode doesn't nul-terminate

[Georg Brandl]

Georg Brandl added the comment:

The function in question is in Python/ast.c. Martin, does the string
need to be null-terminated or does DecodeUnicodeEscape need to be fixed
(since it takes an explicit length argument)?

--
assignee:  -> loewis
nosy: +georg.brandl, loewis
type:  -> crash

__
Tracker <[EMAIL PROTECTED]>

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

[issue1120] "make altinstall" installs pydoc, idle, smtpd.py with broken shebang lines

[Georg Brandl]

Georg Brandl added the comment:

Fixed in rev. 58125, should be merged to 3k shortly. Thanks!

--
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

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

[issue1777530] ctypes on Solaris

[Thomas Heller]

Thomas Heller added the comment:

Can someone please test the patch and report back?  -- Thanks

_
Tracker <[EMAIL PROTECTED]>

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

[issue1145] Allow str.join to join non-string types (as per PEP 3100)

[Guido van Rossum]

Guido van Rossum added the comment:

I like this, but the patch has problems: you don't error-check the
return value from PyObject_Unicode() or PyUnicode_FromObject() (and why
do you need the latter call anyway?)

Also in the docstring I would reference str() instead of __str__().

There are also a few lines longer than 80 chars.

--
assignee:  -> gvanrossum
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

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

[issue1207379] class property fset not working

[Georg Brandl]

Georg Brandl added the comment:

It says "... for new-style classes (classes that derive from object)." I
think this is clear enough.

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

_
Tracker <[EMAIL PROTECTED]>

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

[issue1121] Document inspect.getfullargspec()

[Georg Brandl]

Georg Brandl added the comment:

Documented in rev. 1121.

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

__
Tracker <[EMAIL PROTECTED]>

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

[issue1153] help(pickle) fails: unorderable types: type() < type()

[Georg Brandl]

Georg Brandl added the comment:

Fixed in the repr module (it was calling sorted() on sets and dicts,
which is wrong without fallback) in rev. 58122 (trunk), 58123 (2.5) --
will be merged to 3.0 shortly.

--
assignee:  -> georg.brandl
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed
versions: +Python 2.5, Python 2.6

__
Tracker <[EMAIL PROTECTED]>

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

[issue1156] Suggested change to _exit function description in os module documentation

[Georg Brandl]

Georg Brandl added the comment:

Assigning to Martin.

--
assignee:  -> loewis
nosy: +georg.brandl, loewis

__
Tracker <[EMAIL PROTECTED]>

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

[issue1739468] Add a -z interpreter flag to execute a zip file

[Guido van Rossum]

Guido van Rossum added the comment:

PJE's patch looks good to me too.

Stylistic nits:

- The proper name of the now-public null importer type ought to be
PyNullImporter_Type, to rhyme with e.g. PyString_Type

- There's a multi-line if that has the closing parenthesis in an odd
place at the start of the next line. The preferred style is to place the
close paren after the last condition, and put the open curly on a line
by itself.

--
nosy: +gvanrossum

_
Tracker <[EMAIL PROTECTED]>

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

[issue1154] Carbon.CF memory leak

[Georg Brandl]

Georg Brandl added the comment:

Fixed in rev. 58119, 58120 (2.5).

--
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

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

[issue1156] Suggested change to _exit function description in os module documentation

[Johann Tonsing]

New submission from Johann Tonsing:

The document from which http://docs.python.org/lib/os-process.html was 
generated contains:

"Note: The standard way to exit is sys.exit(n). _exit() should normally 
only be used in the child process after a fork()."

Should "child" be replaced with "parent"?

This also applies to: http://docs.python.org/dev/library/os.html

Did not check the 3.0 docs (where can they be found?).

--
components: Documentation
messages: 55853
nosy: jtonsing
severity: normal
status: open
title: Suggested change to _exit function description in os module documentation
type: behavior
versions: Python 2.5, Python 2.6

__
Tracker <[EMAIL PROTECTED]>

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

[issue1598083] Top-level exception handler writes to stdout unsafely

[Georg Brandl]

Georg Brandl added the comment:

I'll look into it.

--
nosy: +georg.brandl

_
Tracker <[EMAIL PROTECTED]>

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

[issue1139] PyFile_Encoding should be PyFile_SetEncoding

[Georg Brandl]

Georg Brandl added the comment:

Fixed in rev. 58117, 58118 (2.5). Thanks!

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

__
Tracker <[EMAIL PROTECTED]>

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

[issue1122] PyTuple_Size and PyTuple_GET_SIZE return type documentation incorrect

[Georg Brandl]

Georg Brandl added the comment:

Fixed in rev. 58115, 58116 (2.5). Thanks!

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

__
Tracker <[EMAIL PROTECTED]>

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

[issue1152] Bug in documentation for SimpleXMLRPCServer

[Georg Brandl]

Georg Brandl added the comment:

Fixed in rev. 58114.

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

__
Tracker <[EMAIL PROTECTED]>

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

[issue1136] Bdb documentation

[Georg Brandl]

Georg Brandl added the comment:

Okay, committed as rev. 58112, 58113. Thank you!

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

__
Tracker <[EMAIL PROTECTED]>

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

[issue1535659] NNTPS support in nntplib

[Bill Janssen]

Bill Janssen added the comment:

Georg got it right -- this patch is bogus.  I'm going to close it as 
"won't fix".  Feel free to re-open it as an RFE with a good patch.

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

_
Tracker <[EMAIL PROTECTED]>

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

[issue1155] Carbon.CF memory management problem

[hhas]

New submission from hhas:

While other CF...RefObj_Convert functions return a borrowed object, 
CFStringRefObj_Convert will return either a new or borrowed CFStringRef 
depending on the type of value supplied (str, unicode or CFString). As a 
result, extensions that use CFStringRefObj_Convert function to (e.g.) 
parse arguments - for example, Carbon.Launch 
(Launch_LSGetApplicationForInfo, Launch_LSFindApplicationForInfo) - will 
leak memory when a str or unicode value is passed.

Three possible solutions:

1. Make all CF...RefObj_Convert functions return a 'new' object (i.e. 
call CFRetain if returning an existing CF object) and make callers 
responsible for always calling CFRelease on these objects when done. 

2. Make CFStringRefObj_Convert accept Carbon.CF.CFStringRef values only, 
and make users responsible for calling Carbon.CF.toCF on Python 
str/unicode values before passing them to extension functions.

3. Make no changes to existing code, but advise Python users to call 
Carbon.CF.toCF themselves before passing text values to extension 
functions whose docstrings specify CFStringRef parameters if they wish 
to avoid memory leaks.

The third solution would be the obvious choice if future Python 
development plans call for the deprecation and eventual removal of 
Carbon.CF. If Carbon.CF is to retained in the long term, however, then 
some sort of fix would be preferable.

While the other two solutions would inevitable cause some disruption, I 
would suggest #1 is the lesser evil as it would require only existing 
standard and 3rd-party C extensions to be modified, whereas #2 would 
require existing Python code to be modified which would affect end-users 
as well.

Note that if solution #1 is used, callers would need to avoid invoking 
CFRelease when an older, unfixed version of Carbon.CF is in use as this 
would cause a memory error. This shouldn't cause a problem if the fix is 
made in a major Python release (whose extensions are incompatible with 
earlier versions, and vice-versa). pymactoolbox.h could supply a 
suitable macro, e.g.:

#define CarbonCFRelease(v) if (v != NULL) CFRelease(v);

which client code could invoke as:

#ifdef CarbonCFRelease
CarbonCFRelease(someRef);
CarbonCFRelease(anotherRef);
#endif

Unpatched extensions would continue to leak (more) memory, of course, 
but there should be no other ill effects.

--
components: Macintosh
messages: 55846
nosy: hhas
severity: normal
status: open
title: Carbon.CF memory management problem
type: resource usage
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue1772851] Decimal and long hash, compatibly and efficiently

[ajaksu]

ajaksu added the comment:

IMHO this patch should be considered for  (at least) py3k, in which long
becomes the new int. As there is current interest in long/int
performance[1] this seems like a good time to raise this kind of issue.

 Mark, could you please outline the semantic changes (specially at
wraparound)? Would the hash value changes happen only in "wraparound (=
subtraction +   of 2**(bits_in_long)) by incrementing" cases?  
Would hash(-1) become -1?

Sorry to ask all that, but my C (and maths) is (are) *very* limited. I
guess an invalid hash value is the reason to have hash(-1) == hash(-2)
== -2 currently, if so the period would have to skip that, right? I
don't see the need for "y" and would chain some IFs (if x == -1 OR
abs(x) == ULONG_MAX), but those are weak guesses.


 Maybe it's worth discussing this patch  without linking its most
important change (long hash becoming periodic) to Decimal: it would have
many impacts beyond Decimal and is rather a core change (as opposed to
Lib).  Also,  a recent discussion on hashing[2] shows that sometimes the
current behavior was well planned :)

1 -  http://mail.python.org/pipermail/python-3000/2007-September/010374.html
2 - http://mail.python.org/pipermail/python-3000/2007-September/010327.html

--
nosy: +ajaksu2

_
Tracker <[EMAIL PROTECTED]>

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

[issue1136] Bdb documentation

[Cristina Yenyxe González García]

Cristina Yenyxe González García added the comment:

Oops, of course a filename should be in canonical form (an absolute name
which does not contain repeated path separators or symbolic links)!

__
Tracker <[EMAIL PROTECTED]>

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

[issue1154] Carbon.CF memory leak

[hhas]

New submission from hhas:

CFStringRefObj_Convert leaks memory when passed a str. See attached diff 
file for patch.

--
components: Macintosh
files: CFmodule.diff
messages: 55843
nosy: hhas
severity: normal
status: open
title: Carbon.CF memory leak
type: resource usage
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

__1830,1831c1830,1832
<   *p_itself = CFStringCreateWithCString((CFAllocatorRef)NULL, 
cStr, kCFStringEncodingASCII);
<   return 1;
---
> *p_itself = CFStringCreateWithCString((CFAllocatorRef)NULL, cStr, 
> kCFStringEncodingASCII);
> PyMem_Free(cStr);
> return 1;
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1136] Bdb documentation

[Georg Brandl]

Georg Brandl added the comment:

Thanks for reviewing, I'll finish and commit that one shortly.

--
assignee:  -> georg.brandl
nosy: +georg.brandl

__
Tracker <[EMAIL PROTECTED]>

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

[issue1142] code sample showing errors reading large files with py 2.5/3.0

[Guido van Rossum]

Guido van Rossum added the comment:

Cool. This helps track down the bug a bit more; it's either in (our
routine) getline_via_fgets or it's in Microsoft's text mode line end
translation (which universal newlines bypasses).

I'm assigning this to Tim Peters, who probably still has a Windows box
and once optimized the snot out of this code.

--
assignee:  -> tim_one
nosy: +tim_one

__
Tracker <[EMAIL PROTECTED]>

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

[issue1136] Bdb documentation

[Tim Golden]

Tim Golden added the comment:

I've reviewed the docs for English and general readability. As
mentioned, I've no idea of the tech involved. I did look through the
bdb.py source and the existing docs for pdb to get some idea of the
terminology used. Ultimately I've changed very little; in a couple of
places the English was just wrong and in a couple of others I felt a
small change improved things.

One thing I couldn't work out is that arklad, the author, used "canonic"
throughout which I've never seen used. I would simply have changed it to
"canonical" except that the code itself uses "canonic" as a function
name! In addition, there's no explanation of what canonic(al) means in
the context. I've left ?TJG? marks around all the instances.

--
nosy: +tim.golden

__
Tracker <[EMAIL PROTECTED]>

__

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

[issue1153] help(pickle) fails: unorderable types: type() < type()

[Marcin 'Qrczak' Kowalczyk]

New submission from Marcin 'Qrczak' Kowalczyk:

Python 3.0a1 (py3k, Sep  8 2007, 15:57:56) 
[GCC 4.2.1 20070719 (release) (PLD-Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle
>>> help(pickle)
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python3.0/site.py", line 350, in __call__
return pydoc.help(*args, **kwds)
  File "/usr/local/lib/python3.0/pydoc.py", line 1685, in __call__
self.help(request)
  File "/usr/local/lib/python3.0/pydoc.py", line 1729, in help
else: doc(request, 'Help on %s:')
  File "/usr/local/lib/python3.0/pydoc.py", line 1512, in doc
pager(render_doc(thing, title, forceload))
  File "/usr/local/lib/python3.0/pydoc.py", line 1490, in render_doc
return title % desc + '\n\n' + text.document(object, name)
  File "/usr/local/lib/python3.0/pydoc.py", line 319, in document
if inspect.ismodule(object): return self.docmodule(*args)
  File "/usr/local/lib/python3.0/pydoc.py", line 1076, in docmodule
contents.append(self.document(value, key, name))
  File "/usr/local/lib/python3.0/pydoc.py", line 320, in document
if inspect.isclass(object): return self.docclass(*args)
  File "/usr/local/lib/python3.0/pydoc.py", line 1210, in docclass
lambda t: t[1] == 'data')
  File "/usr/local/lib/python3.0/pydoc.py", line 1173, in spilldata
name, mod, maxlen=70, doc=doc) + '\n')
  File "/usr/local/lib/python3.0/pydoc.py", line 1295, in docother
repr = self.repr(object)
  File "/usr/local/lib/python3.0/repr.py", line 24, in repr
return self.repr1(x, self.maxlevel)
  File "/usr/local/lib/python3.0/pydoc.py", line 954, in repr1
return getattr(self, methodname)(x, level)
  File "/usr/local/lib/python3.0/repr.py", line 78, in repr_dict
for key in islice(sorted(x), self.maxdict):
TypeError: unorderable types: type() < type()
>>>

--
components: Library (Lib)
messages: 55839
nosy: Qrczak
severity: normal
status: open
title: help(pickle) fails: unorderable types: type() < type()
type: behavior
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

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