[issue813986] robotparser interactively prompts for username and password
Skip Montanaro added the comment: I'll take this one. Looks like an easy fix. -- assignee: loewis -> skip.montanaro nosy: +skip.montanaro priority: high -> normal type: -> behavior Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue813986> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue813986] robotparser interactively prompts for username and password
Skip Montanaro added the comment: Checked in as r57626 on trunk and r57627 on 2.5. -- resolution: -> accepted status: open -> closed Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue813986> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue813986] robotparser interactively prompts for username and password
Skip Montanaro added the comment: For those monitoring this, note that I am no unittest whiz, especially with oddball test files like test_robotparser.py. Please feel free to rewrite that code. Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue813986> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue527668] pydoc should respect __all__
Skip Montanaro added the comment: This was fixed in r36142 (i.e., ages ago). -- nosy: +skip.montanaro resolution: -> fixed status: open -> closed Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue527668> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue602893] cgitb tracebacks not accessible
Skip Montanaro added the comment:
I have no easy way to check if this change works. Can you apply it to
your Python installation and give it a whirl?
Thx,
Skip
--
assignee: -> skip.montanaro
nosy: +skip.montanaro
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue602893>
*** /tmp/skip/ediffTIE3ly Tue Aug 28 20:03:46 2007
--- /Users/skip/src/python/trunk/Lib/cgitb.py Tue Aug 28 20:02:27 2007
***
*** 138,147
i = lnum - index
for line in lines:
num = small(' ' * (5-len(str(i))) + str(i)) + ' '
- line = '%s%s' % (num, pydoc.html.preformat(line))
if i in highlight:
rows.append('%s' % line)
else:
rows.append('%s' % grey(line))
i += 1
--- 138,148
i = lnum - index
for line in lines:
num = small(' ' * (5-len(str(i))) + str(i)) + ' '
if i in highlight:
+ line = '=< s%s' % (num, pydoc.html.preformat(line))
rows.append('%s' % line)
else:
+ line = '%s%s' % (num, pydoc.html.preformat(line))
rows.append('%s' % grey(line))
i += 1
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1054] scriptsinstall target fails in alternate build dir
New submission from Skip Montanaro: I tried running make scriptsinstall from my build directory. It failed with this error message: error: file 'byteyears.py' does not exist I added os.path.abspath() around the source file name in the error message. It's looking for byteyears.py in the current directory. From where I executed make it's in ../Tools/scripts. I'm not sure it would work if executed from the top-level source directory either. -- components: Build messages: 55398 nosy: skip.montanaro priority: normal severity: normal status: open title: scriptsinstall target fails in alternate build dir type: behavior versions: Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1054> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue642309] pygettext should be installed
Skip Montanaro added the comment: I checked in a change to Tools/scripts/setup.py to install ../i18n/pygettext.py. The main scriptsinstall makefile target still needs work though (opened a ticket about that). -- assignee: -> skip.montanaro nosy: +skip.montanaro resolution: -> fixed status: open -> closed Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue642309> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue658407] email: minimal header encoding
Skip Montanaro added the comment: Marked as out-of-date. Might as well close it. -- nosy: +skip.montanaro status: open -> closed Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue658407> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue683910] zipfile should have a tarfile-like API
Skip Montanaro added the comment: Anthony, has this been fixed? -- nosy: +skip.montanaro Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue683910> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue444582] Finding programs in PATH, addition to os
Skip Montanaro added the comment: Commenting on Brett's reply... We use this sort of facility in SpamBayes to search for the OCR program. I crafted something by hand which didn't work on Windows. Mark Hammond had to clean up the mess I made. Having this as a canned function in os would be handy. Have a look at find_program in this file: http://spambayes.svn.sourceforge.net/viewvc/*checkout*/spambayes/trunk/spambayes/spambayes/ImageStripper.py?content-type=text%2Fplain -- nosy: +skip.montanaro Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue444582> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue751260] Thread in threading.py can only be started once
Skip Montanaro added the comment: Closing as won't fix. Python's threads work as designed. There are plenty of solutions available to get the desired behavior. -- nosy: +skip.montanaro resolution: -> wont fix Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue751260> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue766910] fix one or two bugs in trace.py
Skip Montanaro added the comment: Zooko, is this patch still necessary? -- assignee: -> skip.montanaro nosy: +skip.montanaro Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue766910> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue756576] Recursion limit too high for MacOSX
Skip Montanaro added the comment: This problem seems to have been fixed. The submitted test case yields maximum recursion depth exceeded on both 2.5 and 2.6a0. -- nosy: +skip.montanaro resolution: -> out of date Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue756576> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue761863] readline module that checks signals
Skip Montanaro added the comment: kdart - do you have any response to Guido's question? -- nosy: +skip.montanaro Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue761863> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue815753] SCO_SV: many modules cannot be imported
Skip Montanaro added the comment: No activity since late 2003. Do we even have a SCO system to test anything on? Should SCO support be dropped? -- nosy: +skip.montanaro Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue815753> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue849662] reading shelves is really slow
Skip Montanaro added the comment: Raymond - can we close this ticket? -- nosy: +skip.montanaro Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue849662> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue877124] configure links unnecessary library libdl
Skip Montanaro added the comment: Martin, can I close this? -- nosy: +skip.montanaro resolution: -> wont fix status: open -> closed Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue877124> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue504152] rfc822 long header continuation broken
Skip Montanaro added the comment: Is this still an issue? No activity since 2003-11. -- nosy: +skip.montanaro Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue504152> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue857888] Modules/Setup needs a suppress flag?
Skip Montanaro added the comment: That's what the comment character is for. Closing since there's already a good way to achieve the desired behavior and because Modules/Setup is generally not the primary way to build extensions anymore. -- assignee: -> skip.montanaro nosy: +skip.montanaro resolution: -> rejected status: open -> closed Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue857888> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1462525] URI parsing library
Changes by Skip Montanaro: -- nosy: +skip.montanaro _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1462525> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1675455] Use getaddrinfo() in urllib2.py for IPv6 support
Changes by Skip Montanaro: -- nosy: +skip.montanaro _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1675455> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue980098] Module to dynamically generate structseq objects
Changes by Skip Montanaro: -- nosy: +skip.montanaro Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue980098> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue852532] ^$ won't split on empty line
Skip Montanaro added the comment: Doc note checked in as r57878. Can we conclude based upon Tim's and Fredrik's comments that this behavior is to be expected and won't change? If so, I'll close this item. -- assignee: fdrake -> skip.montanaro nosy: +skip.montanaro resolution: postponed -> wont fix status: open -> pending Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue852532> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1330538] datetime/xmlrpclib.DateTime comparison
Skip Montanaro added the comment: Fred, can we move this forward? _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1330538> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1083] Confusing error message when dividing timedelta using /
New submission from Skip Montanaro: I discovered the hard way today that this won't work: >>> import datetime >>> d = datetime.timedelta(1) >>> d / 2 Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for /: 'datetime.timedelta' and 'int' The error message is misleading, because in fact timedelta objects *do* support division by ints, just not with the / operator: >>> d // 2 datetime.timedelta(0, 43200) Is there some way the error message can be improved, perhaps by identifying the denominator as effectively a float? -- components: Interpreter Core messages: 55566 nosy: skip.montanaro severity: normal status: open title: Confusing error message when dividing timedelta using / type: behavior __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1083> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1289118] timedelta multiply and divide by floating point
Skip Montanaro added the comment:
Attached is a diff to the datetime module that
implements floating point division. Comments?
Is it worthwhile to pursue? If so, I'll
implement the other floating point arithmetic
operations.
--
versions: +Python 2.6
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1289118>
_Index: Modules/datetimemodule.c
===
--- Modules/datetimemodule.c (revision 57877)
+++ Modules/datetimemodule.c (working copy)
@@ -1628,6 +1628,47 @@
}
static PyObject *
+divide_timedelta_float(PyDateTime_Delta *delta, PyObject *denom)
+{
+ int days;
+ double seconds;
+ double us;
+ double f;
+
+ if (PyFloat_Check(denom)) {
+ f = PyFloat_AS_DOUBLE(denom);
+ } else if (PyInt_Check(denom)) {
+ f = (double)PyInt_AsLong(denom);
+ } else if (PyLong_Check(denom)) {
+ f = (double)PyLong_AsLong(denom);
+ } else {
+ PyErr_SetString(PyExc_TypeError,
+"Invalid denominator for timedelta division.");
+ return NULL;
+ }
+
+ /* convert to seconds */
+ seconds = GET_TD_DAYS(delta) * (24 * 3600) +
+ (double)GET_TD_SECONDS(delta) +
+ (double)GET_TD_MICROSECONDS(delta) / 1e6;
+
+ /* arithmetic is now trivial */
+ seconds /= f;
+
+ /* convert back to days, seconds and us, checking for range error */
+ days = (int)(seconds / (24 * 3600));
+ if (check_delta_day_range(days) < 0)
+ return NULL;
+
+ seconds = seconds - days * (24 * 3600);
+ us = (seconds - (int)seconds) * 1e6;
+ /* round us to nearest whole number */
+ us = (int)(us + 0.5);
+
+ return new_delta(days, (int)seconds, (int)us, 1);
+}
+
+static PyObject *
delta_add(PyObject *left, PyObject *right)
{
PyObject *result = Py_NotImplemented;
@@ -1776,10 +1817,14 @@
if (PyDelta_Check(left)) {
/* delta * ??? */
- if (PyInt_Check(right) || PyLong_Check(right))
+ if (PyFloat_Check(right))
+ result = divide_timedelta_float(
+(PyDateTime_Delta *)left,
+right);
+ else if (PyInt_Check(right) || PyLong_Check(right))
result = divide_timedelta_int(
- (PyDateTime_Delta *)left,
- right);
+(PyDateTime_Delta *)left,
+right);
}
if (result == Py_NotImplemented)
@@ -2119,7 +2164,7 @@
0, /*nb_inplace_xor*/
0, /*nb_inplace_or*/
delta_divide,/* nb_floor_divide */
- 0, /* nb_true_divide */
+ delta_divide,/* nb_true_divide */
0, /* nb_inplace_floor_divide */
0, /* nb_inplace_true_divide */
};
Index: Lib/test/test_datetime.py
===
--- Lib/test/test_datetime.py (revision 57877)
+++ Lib/test/test_datetime.py (working copy)
@@ -234,6 +234,18 @@
eq(c//1000, td(0, 0, 1))
eq(a//10, td(0, 7*24*360))
eq(a//360, td(0, 0, 7*24*1000))
+eq(a//7.0, td(1))
+eq(b//10.0, td(0, 6))
+eq(c//1000.0, td(0, 0, 1))
+eq(a//10.0, td(0, 7*24*360))
+eq(a//360.0, td(0, 0, 7*24*1000))
+eq(a/0.5, td(14))
+eq(b/0.5, td(0, 120))
+eq(a/7, td(1))
+eq(b/10, td(0, 6))
+eq(c/1000, td(0, 0, 1))
+eq(a/10, td(0, 7*24*360))
+eq(a/360, td(0, 0, 7*24*1000))
def test_disallowed_computations(self):
a = timedelta(42)
@@ -245,14 +257,10 @@
self.assertRaises(TypeError, lambda: i+a)
self.assertRaises(TypeError, lambda: i-a)
-# Mul/div by float isn't supported.
+# Mul by float isn't supported.
x = 2.3
self.assertRaises(TypeError, lambda: a*x)
self.assertRaises(TypeError, lambda: x*a)
-self.assertRaises(TypeError, lambda: a/x)
-self.assertRaises(TypeError, lambda: x/a)
-self.assertRaises(TypeError, lambda: a // x)
-self.assertRaises(TypeError, lambda: x // a)
# Divison of int by timedelta doesn't make sense.
# Division by zero doesn't make sense.
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1289118] timedelta multiply and divide by floating point
Skip Montanaro added the comment: Ummm... make that: "I'll implement multiplication." _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1289118> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1118748] enable time + timedelta
Skip Montanaro added the comment: This has come up and been rejected because there are so many end cases. Here's an item from a thread I believe you started on comp.lang.python: http://mail.python.org/pipermail/python-list/2005-January/303023.html If you want to add time and timedelta objects, use datetime objects and extract their times. The behavior is well-defined. >>> t = datetime.time(11, 47, 00) >>> td = datetime.timedelta(0, 4, 1234) >>> dt = datetime.datetime.now().replace(hour=t.hour, minute=t.minute, second=t.second) >>> dt datetime.datetime(2007, 9, 1, 11, 47, 0, 147616) >>> for i in range(1, 10): ... print (dt + i * td).time() ... 22:53:40.148850 10:00:20.150084 21:07:00.151318 08:13:40.152552 19:20:20.153786 06:27:00.155020 17:33:40.156254 04:40:20.157488 15:47:00.158722 -- nosy: +skip.montanaro resolution: -> rejected status: open -> closed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1118748> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1487389] datetime.time and datetime.timedelta
Skip Montanaro added the comment: See this other issue I just closed: http://bugs.python.org/issue1118748 -- nosy: +skip.montanaro _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1487389> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1487389] datetime.time and datetime.timedelta
Changes by Skip Montanaro: -- resolution: -> rejected status: open -> closed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1487389> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1673409] datetime module missing some important methods
Skip Montanaro added the comment: There is no datetime.totimestamp because the range of time represented by a datetime object far exceeds the range of a normal int-based Unix timestamp (roughly 1970-2038). Datetime objects before the start of the Unix epoch would be represented by negative numbers. As far as I know, the common Unix library functions which accept epoch times wouldn't know what to do with a negative number. That said, you stated these missing methods were important. Can you offer some use cases which would support that contention? I personally don't think a argument for symmetry would be a convincing use case and that's the only one I can think of. -- nosy: +skip.montanaro _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1673409> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1074462] Irregular behavior of datetime.__str__()
Skip Montanaro added the comment:
I'm going to offer one more argument here, then close the ticket.
(Tim already told you the behavior wasn't going to change.)
str() is a convenience function intended to give conveniently
human-readable output. It's not intended to be a one-size-fits-
all routine. Humans are used to not seeing fractions of a second
in times when there are none. In those situations where you
unambiguously need microseconds displayed, use something like
this:
>>> str(dt.replace(microsecond=0)) + ".%06d" % dt.microsecond
'2007-09-01 22:30:36.32'
>>> dt.strftime("%H:%M:%S") + ".%06d" % dt.microsecond
'22:30:36.32'
--
nosy: +skip.montanaro
resolution: -> rejected
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1074462>
_
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1673409] datetime module missing some important methods
Skip Montanaro added the comment: Jon> Almost everything you just said about time_t is wrong. time_t is Jon> signed, and always has been (otherwise the 'end of time' for 32-bit Jon> time_t would be 2106, not 2038). Also, time_t does not end at 2038 Jon> because nothing says it must be 32 bits. Also, Python has 'long Jon> integers' which do not overflow. My apologies about goofing up on the signedness of time_t. What are you going to do with a long integer that you can't do with a datetime object? You clearly can't pass it directly to any Unix library functions which expect time_t. Converting it can overflow. Jon> Also, I don't understand what you mean about use cases. The "use Jon> case" is "dealing with anything which expects standard Unix time_t, Jon> for example the Python standard library". The use case I have Jon> personally is the program I was working on when I encountered the Jon> problem described in this bug report. Also I think symmetry is a Jon> darn good argument. Why does fromtimestamp exist if, as you claim, Jon> nobody uses time_t? What should datetime.datetime(, 1, 1).totimestamp() return? How would you pass it to something which accepts a time_t? The fromtimestamp functions work simply because the range of time_t is a proper subset of the range of Python's datetime objects. Symmetry gets you little. In situations where you need Unix timestamps and you know your datetime objects are within the bounds representable by time_t, you can define a convenience function: def totimestamp(dt): return time.mktime(dt.timetuple()) + dt.microsecond/1e6 This will, of course, fail if the year is too big or too small (and will fail in platform-dependent ways if the underlying platform's range of representable dates has different bounds than Unix does). Doing it without resorting to calling time.mktime is also nontrivial. Under the covers the datetime module currently uses platform functions to get time information anyway. It doesn't do a lot of low-level time arithmethic itself. Implementing fromtimestamp would require a fair amount of effort unless you were willing to punt and just raise OverflowError for dates outside the system's range. Skip _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1673409> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1374063] Broader iterable support for xmlrpclib
Skip Montanaro added the comment: Thanks for the feedback. I will reexamine what I've got. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1374063> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1117] Spurious warning about missing _sha256 and _sha512 when not needed
Skip Montanaro added the comment: Assigning to me because? I've had no involvement at all with SSL or sha code in Python. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1117> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1117] Spurious warning about missing _sha256 and _sha512 when not needed
Skip Montanaro added the comment: >> Assigning to me because? I've had no involvement at all >> with SSL or sha code in Python. Georg> IIRC you added the code that collects and displays these Georg> messages. Ah, okay. I will take a look at that. Skip -- title: Spurious warning about missing _sha256 and _sha512 when not needed -> Spurious warning about missing _sha256 and _sha512 when not needed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1117> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1117] Spurious warning about missing _sha256 and _sha512 when not needed
Skip Montanaro added the comment: I just checked in r58016. See if that solves the problem. -- resolution: -> fixed status: open -> pending __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1117> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1117] Spurious warning about missing _sha256 and _sha512 when not needed
Skip Montanaro added the comment: Thanks. I'm not sure how this slipped in there (I could check, I suppose). It seems to already be on the 2.5 branch, so I added it to the trunk (r58022) as well. -- status: pending -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1117> __ ___ 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
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]>
<http://bugs.python.org/issue1158>
__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
[issue1158] %f format for datetime objects
Skip Montanaro added the comment: Brett> Are you going to add support to strptime as well? I looked at strptime for about two seconds then moved on. I presume you would know how to add it easily though. ;-) Brett> As for the 'time' module, I don't think it would be useful as it serves Brett> no purpose since the time tuple can't resolve to that Brett> resolution. Resolution isn't the issue. You just make sure you add enough zeroes to make it be microseconds. The bigger problem is that time.strftime() takes a tuple of ints which basically represents a struct tm. That struct has an int seconds field and no sub-second field. You'd either have to start allowing floating point tm_sec fields then either truncating or rounding (but which?) to get ints when you need to actually generate an actual struct tm. Skip __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1158> __ ___ 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 added the comment: Eric> It's a nit, but there are a few other comments that should be Eric> changed to mention %f in addition to %z/%Z. Yes, thanks. Skip __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1158> __ ___ 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
Changes by Skip Montanaro: __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1158> __ ___ 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 added the comment:
Here are new patches for 2.6 and 3.0 including changes
to doc and test cases.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1158>
__Index: Lib/test/test_datetime.py
===
--- Lib/test/test_datetime.py (revision 58174)
+++ Lib/test/test_datetime.py (working copy)
@@ -1488,9 +1488,9 @@
def test_more_strftime(self):
# This tests fields beyond those tested by the TestDate.test_strftime.
-t = self.theclass(2004, 12, 31, 6, 22, 33)
-self.assertEqual(t.strftime("%m %d %y %S %M %H %j"),
-"12 31 04 33 22 06 366")
+t = self.theclass(2004, 12, 31, 6, 22, 33, 47)
+self.assertEqual(t.strftime("%m %d %y %f %S %M %H %j"),
+"12 31 04 47 33 22 06 366")
def test_extract(self):
dt = self.theclass(2002, 3, 4, 18, 45, 3, 1234)
@@ -1763,7 +1763,7 @@
def test_strftime(self):
t = self.theclass(1, 2, 3, 4)
-self.assertEqual(t.strftime('%H %M %S'), "01 02 03")
+self.assertEqual(t.strftime('%H %M %S %f'), "01 02 03 04")
# A naive object replaces %z and %Z with empty strings.
self.assertEqual(t.strftime("'%z' '%Z'"), "'' ''")
Index: Modules/datetimemodule.c
===
--- Modules/datetimemodule.c (revision 58174)
+++ Modules/datetimemodule.c (working copy)
@@ -1130,10 +1130,24 @@
return 0;
}
+static PyObject *
+make_freplacement(PyObject *object)
+{
+ char freplacement[7];
+ if (PyTime_Check(object))
+ sprintf(freplacement, "%06d", TIME_GET_MICROSECOND(object));
+ else if (PyDateTime_Check(object))
+ sprintf(freplacement, "%06d", DATE_GET_MICROSECOND(object));
+ else
+ sprintf(freplacement, "%06d", 0);
+
+ return PyString_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
- * step on the format string.
+ * giving special meanings to the %z, %Z and %f format codes via a
+ * preprocessing step on the format string.
* tzinfoarg is the argument to pass to the object's tzinfo method, if
* needed.
*/
@@ -1145,6 +1159,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 */
char *pin; /* pointer to next char in input format */
char ch; /* next char in input format */
@@ -1186,11 +1201,11 @@
}
}
- /* Scan the input format, looking for %z and %Z escapes, building
+ /* Scan the input format, looking for %z/%Z/%f escapes, building
* a new format. Since computing the replacements for those codes
* is expensive, don't unless they're actually used.
*/
- totalnew = PyString_Size(format) + 1; /* realistic if no %z/%Z */
+ totalnew = PyString_Size(format) + 1; /* realistic if no %z/%Z/%f */
newfmt = PyString_FromStringAndSize(NULL, totalnew);
if (newfmt == NULL) goto Done;
pnew = PyString_AsString(newfmt);
@@ -1272,6 +1287,18 @@
ptoappend = PyString_AS_STRING(Zreplacement);
ntoappend = PyString_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(PyString_Check(freplacement));
+ ptoappend = PyString_AS_STRING(freplacement);
+ ntoappend = PyString_GET_SIZE(freplacement);
+ }
else {
/* percent followed by neither z nor Z */
ptoappend = pin - 2;
@@ -1313,6 +1340,7 @@
Py_DECREF(time);
}
Done:
+ Py_XDECREF(freplacement);
Py_XDECREF(zreplacement);
Py_XDECREF(Zreplacement);
Py_XDECREF(newfmt);
Index: Doc/library/datetime.rst
===
--- Doc/library/datetime.rst (revision 58174)
+++ Doc/library/datetime.rst (working copy)
@@ -1297,10 +1297,16 @@
be used, as time objects have no such values. If they're used anyway, ``1900``
is substituted for the year, and ``0`` for the month and day.
-For :class:`date` objects, the format codes for hours, minutes, and seconds
-should not be used, as :class:`date` objects have no such values. If they're
-used anyway, ``0`` is substituted for them.
+For :class:`date` objects, the format codes for hours, minutes, seconds, and
+fractions of sec
[issue1158] %f format for datetime objects
Changes by Skip Montanaro: __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1158> __ ___ 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 added the comment: Brett, Continuing the discussion of strptime... It returns a time.struct_time. Would it cause too much breakage (only do this in 3.0) to add a tm_usec field to the end of that object? It seems a lot of bits of code might still expect a length 9 tuple-ish thing and do this: yy, mm, dd, hh, mm, ss, wk, j, tz = time.strptime(...) If we could make that change for 3.0 that might allow strptime to parse %f format codes. S __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1158> __ ___ 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 added the comment: Brett> In terms of strptime, I would just change _strptime.strptime() to Brett> _strptime._strptime() and have it return everything along with Brett> the microseconds measurement. Then have public functions that Brett> call that function and either strip off the microseconds or not. Sounds good. I'll work that into my patch(es). Skip __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1158> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1218] Restrict Google search to docs when in the docs subtree?
New submission from Skip Montanaro: It was reported to [EMAIL PROTECTED] today that Thomas Heller's pyhelp.cgi script is not available (yields 403 Forbidden). For the time being I removed that link from http://www.python.org/doc/. Still, there is the Google search box at the top of the page. Alas, that only restricts the search to www.python.org. It would be nice if on those pages under the /doc/... tree the relevant parameter (sitesearch?) restricted the search to the doc tree. Can this be done easily? (On a related note, shouldn't the website be listed as a separate component in the classification section?) -- components: Documentation messages: 56179 nosy: skip.montanaro priority: normal severity: normal status: open title: Restrict Google search to docs when in the docs subtree? type: behavior __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1218> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1218] Restrict Google search to docs when in the docs subtree?
Skip Montanaro added the comment: Martin> Website issues are not tracked in this tracker. See Martin> http://wiki.python.org/moin/PythonWebsiteCreatingNewTickets Is there some reason at this point that we need to maintain two separate trackers? A ton of work went into making our Roundup instance what the key players wanted. Why not use it to track website issues as well? With them separate you have two communities of maintainers and triage folks who are mostly disjoint. I assume there would be some trac-to-roundup conversion necessary. Perhaps something like that already exists. Skip __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1218> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1227] csv docs say 'excel_tab'; code says 'excel-tab'
Skip Montanaro added the comment:
The string name of the dialect is "excel-tab". Hyphens are not
valid characters in identifiers though, so the actual object
is named "excel_tab". When you call csv.get_dialect("excel-tab")
it instantiates the csv.excel_tab class and returns that:
>>> csv.list_dialects()
['excel-tab', 'excel']
>>> csv.get_dialect("excel-tab")
>>> csv.excel_tab
>>> csv.get_dialect("excel-tab").__class__ == csv.excel_tab
True
--
assignee: -> skip.montanaro
nosy: +skip.montanaro
resolution: -> works for me
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1227>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1074462] Irregular behavior of datetime.__str__()
Skip Montanaro added the comment: Zooko> Here is a note for the next person who comes to this ticket Zooko> wondering why isoformat() exhibits this slightly un-Pythonic Zooko> behavior. What are you referring to, that it doesn't display any microseconds when the microsecond field happens to be 0 or that it doesn't truncate the fractions of a second to milliseconds? Skip _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1074462> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1074462] Irregular behavior of datetime.__str__()
Skip Montanaro added the comment:
Zooko> I meant that it special-cases .microseconds == 0.
Tim indicated in his comment that the behavior is both by design and
documented and isn't going to change. In an earlier comment I showed how to
achieve the result you ased for in one line. Here's another example using
your desire for millisecond display resolution:
>>> dt.replace(microsecond=0).strftime("%Y-%m-%dT%H:%M:%S") + ".%03dZ" %
(dt.microsecond//1000)
'2007-10-15T08:24:02.509Z'
Also, I have a patch for py3k which adds a %f format specifier to strftime.
I still have to make some other additions, but you're more than welcome to
review what's there now:
http://bugs.python.org/issue1158
Skip
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1074462>
_
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1673409] datetime module missing some important methods
Skip Montanaro added the comment:
Tom> unless I'm missing something important this will do the trick quite
Tom> nicely:
>>>> from datetime import datetime
>>>> datetime(2007, 12, 24, 20, 0).strftime("%s")
Tom> '1198522800'
Tom> For most imaginable use cases, where an epoch style time stamp is
Tom> required this should be enough.
No fractions of a second...
Skip
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1673409>
_
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1673409] datetime module missing some important methods
Skip Montanaro added the comment: One other thing worth noting is that %s is not universally available. Solaris, for example, lacks it in its strftime() implementation. (It has a bazillion other non-standard format strings but not %s.) Skip _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1673409> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1673409] datetime module missing some important methods
Skip Montanaro added the comment: >> No fractions of a second... Jon> If we're expecting floating-point, then everything you said earlier Jon> about the limitations of ints was a bit redundant ;-) Yes, sorry. I responded to the mail without going back and reviewing the entire thread. (It's been a couple months.) Note however that my example to_timestamp() function converts the microseconds field to seconds and include them in the result. So, are we concluding that nothing needs to be added to the datetime module? Skip _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1673409> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1744580] cvs.get_dialect() return a class object
Skip Montanaro added the comment: I changed the documentation for 2.5 and 2.6 to reflect the change in semantics. r58840 and r58841. Have a look and let me know if that looks reasonable. -- status: open -> pending title: cvs.get_dialect() return a class object -> cvs.get_dialect() return a class object _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1744580> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1431091] CSV Sniffer fails to report mismatch of column counts
Skip Montanaro added the comment: This appears to work better in 2.5 and 2.6 (it doesn't crash, though it gets the delimiter wrong) but does indeed fail in 2.4. -- nosy: +skip.montanaro _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1431091> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1429818] trace.py needs to know about doctests
Skip Montanaro added the comment: Applied in r59317 (trunk) and r59318 (release25-maint). -- assignee: -> skip.montanaro nosy: +skip.montanaro resolution: -> accepted status: open -> closed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1429818> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1067] test_smtplib failures (caused by asyncore)
Changes by Skip Montanaro: -- nosy: +skip.montanaro __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1067> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1511] csv input converts \r\n to \n but csv output does not when a field has internal line breaks
Changes by Skip Montanaro: -- assignee: -> skip.montanaro nosy: +skip.montanaro __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1511> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9650] format codes in time.strptime docstrings
Skip Montanaro added the comment: There is the non-zero cost of keeping two copies of that bit of information in-sync with each other (and the code). If I execute "pydoc time" I get a link to the online module docs. It's not there when I execute "pydoc time.strftime". Perhaps pydoc should be modified to always include a link to the defining module even when the user asked for docs for something other than a module. -- nosy: +skip.montanaro ___ Python tracker <http://bugs.python.org/issue9650> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9662] ctypes not building under OS X because of ffi_closure_free not being defined early enough
Changes by Skip Montanaro : -- nosy: +skip.montanaro ___ Python tracker <http://bugs.python.org/issue9662> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9650] format codes in time.strptime docstrings
Skip Montanaro added the comment: Catherine, Did my suggestion to alter pydoc output so it always contains a link to the enclosing module's documentation not seem like a reasonable compromise? Another problem with embedding the format codes in the docstring is that it opens up a Pandora's box of other stuff that might be reasonable to include in other docstrings, but should probably just be documented in one place (perhaps with references elsewhere). For example, maybe we should add the list of signals to the docstrings for signal.signal and os.kill (pretty platform-dependent) or add all the format possibilities to the docstring for the format() builtin (brand new and probably not well-known to very many users). I'm sure there are other candidates. It can be difficult to know where to draw the line. Skip -- ___ Python tracker <http://bugs.python.org/issue9650> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9715] io doc improvements
Skip Montanaro added the comment: A couple wording comments: "All streams are careful about the type of data you give to them" would read better as "All streams accept specific types of data". "The default mode is ``'r'`` (open for reading text, synonym of ``'rt'``)". I liked the original wording better. Finally, not specific to this change, but I wonder if rather than having distinct io.StringIO and io.BytesIO classes it would be better to have a single io.MemoryIO class which takes mode arguments just like io.FileIO? The correspondence between file-based and memory- based i/o would be more one-to-one. Such a class could be added without breaking existing code by using the StringIO and BytesIO classes as the back-end for a MemoryIO class. -- nosy: +skip.montanaro ___ Python tracker <http://bugs.python.org/issue9715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9715] io doc improvements
Skip Montanaro added the comment: >> Finally, not specific to this change, but I wonder if rather than >> having distinct io.StringIO and io.BytesIO classes it would be better >> to have a single io.MemoryIO class which takes mode arguments just >> like io.FileIO? Â The correspondence between file-based and memory- >> based i/o would be more one-to-one. Â Such a class could be added >> without breaking existing code by using the StringIO and BytesIO >> classes as the back-end for a MemoryIO class. Benjamin> What advantage would that have? File I/O and memory I/O would have more uniform in their APIs and thus be easier to document, describe and use. Currently, one class is used to do file I/O. The type of I/O done is controlled by the mode and buffering flags. Two distinct classes are used to do memory I/O. If someone wanted to select between file and memory I/O at runtime it wouldn't be possible to just swap the class using the current code. Skip -- ___ Python tracker <http://bugs.python.org/issue9715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9650] format codes in time.strptime docstrings
Skip Montanaro added the comment: >> Did my suggestion to alter pydoc output so it always contains a link >> to the enclosing module's documentation not seem like a reasonable >> compromise? Catherine> I actually don't understand how that would help. The ``pydoc Catherine> time`` output doesn't include any information about the Catherine> formatting codes (at least, on my system). No, but it does include a link to the full documentation for the time module, so should you need more than is in the docstring, in theory everything you might want would only be one or two clicks away. Catherine> Also, ``pydoc`` isn't available on Windows systems, is it? Catherine> It isn't on mine; is that a quirk of my setup? You can fire up a documentation server using python -m pydoc -g which starts an HTTP server available to dispense documentation for everything in your PYTHONPATH. You can search for "strftime" there, and after a fairly long pause it will present you with a link you can click to get the time module docs. (I think there is a bug in the way it handles errors during import of the various modules.) Alternatively, click the "open browser" button and you will be directed to the front page of the content it serves. The resulting user interface is fairly crude, but if you search for "time" (it's in the lib-dynload section) and click the link provided, it pops up the pydoc documentation for the time module. From there you can click the Module Docs link in the upper right-hand corner to be taken to the full documentation for the time module. Catherine> Yes, certainly, in one place - but isn't it logical for the Catherine> docstring to be that one place? I think most people would argue, "no". Docstrings are helpers. The library reference manual is supposed to be comprehensive. Catherine> Here's where I would suggest drawing the line: if the method Catherine> is unusable without the information, and it's not easy to Catherine> guess or remember, and it's relatively concise, it should be Catherine> in the docstring. This would be a pretty radical change to the documentation. You're asking that either * Docstrings become the comprehensive source of information instead of the library reference manual, or * A fair amount of information be duplicated between the library reference manual and the docstrings. I suggest this discussion be moved to the doc-...@python.org mailing list. Those are the people who would be best equipped to discuss the overall topic. I'm just a single user with my personal perspective on the topic. I'm not the guy who makes these decisions. Skip -- ___ Python tracker <http://bugs.python.org/issue9650> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9755] Fix refcounting details in Py3k C API documentation
Skip Montanaro added the comment: I thought Fred Drake wrote the code that generated that file, but that was a long time ago in a galaxy far, far away. Perhaps Georg has subsumed it into his Sphinx/Python doc workflow? (making Fred "nosy" so he sees this thread...) S -- nosy: +fdrake, skip.montanaro ___ Python tracker <http://bugs.python.org/issue9755> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4388] test_cmd_line fails on MacOS X
Skip Montanaro added the comment: Any progress on this? Is the best thing to just set LANG? -- nosy: +skip.montanaro ___ Python tracker <http://bugs.python.org/issue4388> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9788] atexit and execution order
Skip Montanaro added the comment: I'm sure you can craft cases where one order is preferable to another, but I don't think you can make the case in general that first in, first out is preferable to last in, first out, or any other ordering of exit functions. -- nosy: +skip.montanaro ___ Python tracker <http://bugs.python.org/issue9788> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10101] a bug in built-in function round() ?
Skip Montanaro added the comment: No, just a result of the finite machine representation of floats: >>> repr(1.255) '1.2549' so the machine representation of 1.255 is actually less than that value and round() is doing the right thing. -- nosy: +skip.montanaro ___ Python tracker <http://bugs.python.org/issue10101> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10101] a bug in built-in function round() ?
Skip Montanaro added the comment: Retro> I didn't thought about the fact that binary floating point is so Retro> imprecise and can cause the round() to "error" in some Retro> situations. Details on the limitations of floating point arithmetic are here: http://docs.python.org/tutorial/floatingpoint.html Skip -- ___ Python tracker <http://bugs.python.org/issue10101> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9778] Make hash values the same width as a pointer (or Py_ssize_t)
Skip Montanaro added the comment: Not that anybody needs my input on this, but... Given the range of people advocating for this change, this looks to me like it should be a release blocker for 3.2. Raymond's comment about performance seems especially important, and since the world seems to be moving toward 64-bit operating systems (certainly should happen in a big way during the lifetime of Python 3) it seems worthwhile to hold up further 3.2 releases until this is solved. -- nosy: +skip.montanaro ___ Python tracker <http://bugs.python.org/issue9778> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9778] Make hash values the same width as a pointer (or Py_ssize_t)
Skip Montanaro added the comment: I added a placeholder to the What's New document. Since it will affect extension module authors it should be mentioned at a higher level than just Misc/NEWS. -- ___ Python tracker <http://bugs.python.org/issue9778> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1371826] distutils is silent about multiple -I/-L/-R
Skip Montanaro added the comment: I would prefer the gcc-like behavior. I realize there are constraints on making changes in distutils1, so what you propose sounds fine to me. -- nosy: +skip.montanaro ___ Python tracker <http://bugs.python.org/issue1371826> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1371826] distutils is silent about multiple -I/-L/-R
Changes by Skip Montanaro : -- nosy: -skip.montanaro ___ Python tracker <http://bugs.python.org/issue1371826> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10401] Globals / builtins cache
Skip Montanaro added the comment: Might such a cache lay the groundwork for more aggressive optimizations by JITs like Unladen Swallow? -- nosy: +skip.montanaro ___ Python tracker <http://bugs.python.org/issue10401> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10444] A mechanism is needed to override waiting for Python threads to finish
Skip Montanaro added the comment: Why is setting your threads as daemons not an option? -- nosy: +skip.montanaro ___ Python tracker <http://bugs.python.org/issue10444> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11419] Python-ast.[ch] out-of-date w.r.t. sources in fresh 2.5 checkout
New submission from Skip Montanaro : I'm working my way through the steps necessary to check out and build all versions of Python since 2.4 using Mercurial checkouts. I encountered my first problem with 2.5. It seems the Mercurial checkout creates the Python-ast.[ch] files before the files they depend on. This causes an initial checkout to try and run Python. I don't know if Mercurial can be tweaked to guarantee checkout order or not. Would be nice if it could. The workaround is simple, just touch the two files. -- messages: 130203 nosy: skip.montanaro priority: normal severity: normal status: open title: Python-ast.[ch] out-of-date w.r.t. sources in fresh 2.5 checkout ___ Python tracker <http://bugs.python.org/issue11419> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11419] Python-ast.[ch] out-of-date w.r.t. sources in fresh 2.5 checkout
Changes by Skip Montanaro : -- versions: +Python 2.5 ___ Python tracker <http://bugs.python.org/issue11419> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11421] Subversion keywords missing on 2.5 checkout
New submission from Skip Montanaro : Trying to build Python 2.5 from a fresh Mercurial checkout I get the following error trying to build modules using setup.py build: % nice make case $MAKEFLAGS in \ *-s*) CC='gcc' LDSHARED='gcc -L/opt/local/lib -bundle -undefined dynamic_lookup' OPT='-DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes' ./python.exe -E ./setup.py -q build;; \ *) CC='gcc' LDSHARED='gcc -L/opt/local/lib -bundle -undefined dynamic_lookup' OPT='-DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes' ./python.exe -E ./setup.py build;; \ esac Fatal Python error: subversion keywords missing /bin/sh: line 1: 48054 Abort trap CC='gcc' LDSHARED='gcc -L/opt/local/lib -bundle -undefined dynamic_lookup' OPT='-DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes' ./python.exe -E ./setup.py build make: *** [sharedmods] Error 134 Even if no release is made I think this should be fixed in Mercurial if possible. -- messages: 130207 nosy: skip.montanaro priority: normal severity: normal status: open title: Subversion keywords missing on 2.5 checkout versions: Python 2.5 ___ Python tracker <http://bugs.python.org/issue11421> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11421] Subversion keywords missing on 2.5 checkout
Skip Montanaro added the comment: Can you explain how I'm supposed to build Python 2.5 from a Mercurial checkout? What is magic about Sept 2011? -- ___ Python tracker <http://bugs.python.org/issue11421> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11421] Subversion keywords missing on 2.5 checkout
Skip Montanaro added the comment: The workaround turned out to be simple. I just expanded the $HeadURL$ subversion keyword as svn would have done it and committed the change locally. -- ___ Python tracker <http://bugs.python.org/issue11421> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11439] subversion keyword breakage
Changes by Skip Montanaro : -- nosy: +skip.montanaro ___ Python tracker <http://bugs.python.org/issue11439> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11439] subversion keyword breakage
Skip Montanaro added the comment: See also issue 11421. -- ___ Python tracker <http://bugs.python.org/issue11439> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11445] Something changed w.r.t. /pythonN.M/site-packages in the Hg switch
New submission from Skip Montanaro : I routinely configure Python like so on my Mac (10.5.8): ./configure --prefix=/Users/skip/local --enable-shared LDFLAGS=-L/opt/local/lib CPPFLAGS=-I/opt/local/include This has always worked for me. Now, after installing from my Mercurial sandbox I have to set PYTHONPATH to get my /python2.7/site-packages directory in sys.path. Here's sys.path in a vanilla python2.7 session when installed from a svn sandbox: ['/Users/skip/misc/python/python2', '/Users/skip/misc/python', '', '/Users/skip/local/lib/python2.7/site-packages/ZODB3-3.8.1b8-py2.7-macosx-10.3-i386.egg', '/Users/skip/local/lib/python2.7/site-packages/zdaemon-2.0.2-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/ZConfig-2.6.0-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/zope.testing-3.7.0-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/zope.proxy-3.4.2-py2.7-macosx-10.3-i386.egg', '/Users/skip/local/lib/python2.7/site-packages/zope.interface-3.4.1-py2.7-macosx-10.3-i386.egg', '/Users/skip/local/lib/python2.7/site-packages/yolk-0.4.1-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/SQLAlchemy-0.5.0rc2-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/decorator-2.3.1-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/dnspython-1.6.0-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/spambayes-1.1b1-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/py2app-0.3.6-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/bdist_mpkg-0.4.3-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/macholib-1.1-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/modulegraph-0.7-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/altgraph-0.6.7-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/python_dateutil-1.4.1-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/coverage-2.85-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/pycallgraph-0.5.1-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/see-0.4.0-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/mercurial-unknown-py2.7-macosx-10.3-i386.egg', '/Users/skip/local/lib/python2.7/site-packages/Pyjamas-0.5-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/Cheetah-2.0.1-py2.7-macosx-10.3-i386.egg', '/Users/skip/local/lib/python2.7/site-packages/mock-0.4.0-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/pydns-2.3.3-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/Importing-1.9.2-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/docutils-0.6-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/MiniMock-1.2.5-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/nose-0.11.2.dev-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/pytz-2010b-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/pip-0.6.3-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/xlrd-0.7.1-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/apipkg-1.0-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/argparse-1.1-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/virtualenv-1.5.1-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/tox-0.9-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/py-1.4.0-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/virtualenv5-1.3.4.5-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/pylint-0.22.0-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/logilab_astng-0.21.0-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/logilab_common-0.53.0-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/unittest2-0.5.1-py2.7.egg', '/Users/skip/local/lib/python2.7/site-packages/PIL-1.1.7-py2.7-macosx-10.4-i386.egg', '/Users/skip/local/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg', '/Users/skip/local/lib/python2.7', '/Users/skip/local/lib/python2.7/plat-darwin', '/Users/skip/local/lib/python2.7/plat-mac', '/Users/skip/local/lib/python2.7/plat-mac/lib-scriptpackages', '/Users/skip/local/lib/python2.7/lib-tk', '/Users/skip/local/lib/python2.7/lib-old', '/Users/skip/local/lib/python2.7/lib-dynload', '/Users/skip/.loc
[issue11445] Something changed w.r.t. /pythonN.M/site-packages in the Hg switch
Skip Montanaro added the comment: Ned> Are you sure you're not really using the MacPorts python? What's Ned> the value of sys.executable? Yup, pretty sure. :-) Here it is run from my hg sandbox: % pwd /Users/skip/src/hgpython/2.7 % ./python.exe Python 2.7.1 (r271:86832, Feb 2 2011, 06:56:19) [GCC 4.0.1 (Apple Inc. build 5493)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.executable '/Users/skip/src/hgpython/2.7/python.exe' >>> sys.path ['/Users/skip/misc/python/python2', '/Users/skip/misc/python', '', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload', '/Users/skip/.local/lib/python2.7/site-packages', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages'] Skip -- ___ Python tracker <http://bugs.python.org/issue11445> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11445] Something changed w.r.t. /pythonN.M/site-packages in the Hg switch
Skip Montanaro added the comment: Ned> No doubt you can work around it by removing the --enable-shared Ned> and/or removing the MacPorts Python2.7 from the picture. I don't rightly recall why I use --enable-shared, but hopefully I can get rid of it. MacPorts must have installed Python 2.7 for some reason of its own, so I don't want to mess with that. Any idea why --enable-shared didn't hose up my svn sandbox build? Skip -- ___ Python tracker <http://bugs.python.org/issue11445> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11445] Something changed w.r.t. /pythonN.M/site-packages in the Hg switch
Skip Montanaro added the comment: > Any idea why --enable-shared didn't hose up my svn sandbox build? I take that back. I looked in config.status. I didn't use --enable-shared in my svn sandbox build. I misread the output of grep. So, it's clearly the --enable-shared that's the culprit. The library search path built when I used LDFLAGS=-L/opt/local/lib must somehow search /opt/local/lib before searching $PWD. Would be nice if we could fix that. I can't see why a third party library search directory (generally intended to point the linker at stuff like libreadline or libjpeg) should be searched before the directory in which Python is being built. S -- ___ Python tracker <http://bugs.python.org/issue11445> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11549] Rewrite peephole to work on AST
Skip Montanaro added the comment: I'm confused. Why aren't there review links? -- nosy: +skip.montanaro ___ Python tracker <http://bugs.python.org/issue11549> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11575] addresses.txt file leaks into search engines
New submission from Skip Montanaro : The python.org postmaster received this email today: From: Tom Pinckney To: postmas...@python.org Subject: public email addresses Date: Wed, 16 Mar 2011 13:03:21 -0400 X-Spambayes-Classification: ham; 0.13 Kind of sucks that this file 1) exists 2) is indexed by google and 3) my email is in i\t. I found it by googling my email address to see what would come up. http://hg.python.org/pymigr/file/e727de0dfeec/addresses.txt I've asked the website team to see if they can adjust the robots.txt file, but is there something we can do to a) make it less likely that this file is harvested, or b) increase the obfuscation of the email addresses? (Maybe the entire file could be rot13?) -- messages: 131145 nosy: skip.montanaro priority: normal severity: normal status: open title: addresses.txt file leaks into search engines ___ Python tracker <http://bugs.python.org/issue11575> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11581] buildbot error when pushing to 2.5 branch?
Skip Montanaro added the comment: Should you be pushing anything to 2.5? -- nosy: +skip.montanaro ___ Python tracker <http://bugs.python.org/issue11581> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11579] python 2.5 does not build from hg - looks for subversion keywords
Skip Montanaro added the comment: See Issue 11439. -- nosy: +skip.montanaro ___ Python tracker <http://bugs.python.org/issue11579> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11581] buildbot error when pushing to 2.5 branch?
Skip Montanaro added the comment: Yes, but this is not a security issue. -- ___ Python tracker <http://bugs.python.org/issue11581> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7198] Extraneous newlines with csv.writer on Windows
Skip Montanaro added the comment: John> John Machin added the comment: John> Can somebody please review my "doc patch" submitted 2 months ago? My apologies. I have it in my sandbox, but a combination of the switch to Mercurial and lack of round tuits has conspired to keep me from checking it in. Skip -- ___ Python tracker <http://bugs.python.org/issue7198> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7198] Extraneous newlines with csv.writer on Windows
Skip Montanaro added the comment: Actually, I was thinking of another doc patch for the csv module. Your changes (or something very like them) made it into the 3.2 release, as you can see here: http://docs.python.org/py3k/library/csv.html S -- resolution: -> accepted status: open -> closed ___ Python tracker <http://bugs.python.org/issue7198> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11575] addresses.txt file leaks into search engines
Skip Montanaro added the comment: Tom Pinckney thinks it's a big deal. I suspect he might be interested to know why you think it's not. We are entitled to our own opinions about privacy, but the request at hand concerns another person's privacy. He's the one you need to convince. -- ___ Python tracker <http://bugs.python.org/issue11575> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11575] addresses.txt file leaks into search engines
Skip Montanaro added the comment: I interpreted "not a big deal" to mean that having addresses exposed was not a big deal. Too many pronouns perhaps. -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue11575> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11456] Documentation csv RFC4180
Changes by Skip Montanaro : -- resolution: -> accepted status: open -> closed ___ Python tracker <http://bugs.python.org/issue11456> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10515] csv sniffer does not recognize quotes at the end of line
Changes by Skip Montanaro : -- assignee: skip.montanaro -> nosy: -skip.montanaro ___ Python tracker <http://bugs.python.org/issue10515> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11549] Rewrite peephole to work on AST
Changes by Skip Montanaro : -- nosy: -skip.montanaro ___ Python tracker <http://bugs.python.org/issue11549> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11579] python 2.5 does not build from hg - looks for subversion keywords
Changes by Skip Montanaro : -- nosy: -skip.montanaro ___ Python tracker <http://bugs.python.org/issue11579> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
