[issue1074] python3.0-config script does not run on py3k

[Georg Brandl]

Georg Brandl added the comment:

Koen van de Sande schrieb:
> New submission from Koen van de Sande:
> 
> The python3.0-config script, installed into the py3k bin folder, does 
> not run on Python 3.0a1, because of the syntax change in the "print" 
> statement. Possibly there are other compatibility issues.

Thanks, fixed in rev. 57862.

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

[issue1072] Documentaion font size too small

[Georg Brandl]

Georg Brandl added the comment:

Bill Janssen schrieb:
> Bill Janssen added the comment:
> 
> I agree.  It shouldn't be an absolute size, and it is too small.

Okay, should be fixed in SVN (rev. 57864) and be live on the page in
the next 12 hours.

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

[issue1072] Documentaion font size too small

[Georg Brandl]

Georg Brandl added the comment:

Bill Janssen schrieb:
> Bill Janssen added the comment:
> 
> I agree.  It shouldn't be an absolute size, and it is too small.

Fixed in rev. 57864, should be live on the site in the next 12 hours.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1079] decode_header does not follow RFC 2047

[Mickaël Guérin]

New submission from Mickaël Guérin:

email.header.decode_header expect a space or end of line after the end
of an encoded word ("?="). There is nothing about that thing in RFC 2047.

Python 2.5.1 ChangeLog seems to indicate that this bug has been solved.
Unfortunately, the function still don't work.

A visible effet of the bad regex used has the consequence found in Issue
1467619

it seems there are 2 different regex with the same purpose in two
different files (ecre in header.py & ecre in utils.py). the one in
utils.py seems to give better results.

--
components: Library (Lib)
messages: 5
nosy: kael
severity: normal
status: open
title: decode_header does not follow RFC 2047
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

[issue1072] Documentaion font size too small

[Nir Soffer]

Nir Soffer added the comment:

The body font size is good now, but now lot of elements are too big. 
Here are list of issues in typical pages related to the font change:

Module page: (e.g. http://docs.python.org/dev/library/bisect.html)

- content headings
- the bread-crumbs navigation flow to out of its div when the using 
narrow window or huge font in the browser
- previous|next... links in the header
- headings in the sidebar are huge
- text in the sidebar can be smaller then the body text
- copyright line - can by tiny

Main page (http://docs.python.org/dev/index.html):

- The main titles (e.g. What's new in ...) are huge - 100-120% should be 
fine. (CSS class biglink)
- The links description may be smaller then the regular body text

__
Tracker <[EMAIL PROTECTED]>

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

[issue1080] Search broken

[Nir Soffer]

New submission from Nir Soffer:

http://docs.python.org/dev/search.html

In Safari:
- does not find anything. e.g. search for print.
- The sections selection do not remember the user selection. e.g. select 
Language Reference, search, the page comes out with Language Reference 
deselected.
- The search term is not remembered - the search box is always empty
- There are not search results

In Firefox:

- Search interface remember the search term and the sections selection, 
but the search results are always empty

--
components: Documentation
messages: 7
nosy: nirs
severity: normal
status: open
title: Search broken
type: behavior
versions: Python 2.6, 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

[issue1081] file.seek allows float arguments

[Georg Brandl]

New submission from Georg Brandl:

Although documented as deprecated, file.seek accepts float arguments in 3.0.

--
keywords: py3k
messages: 8
nosy: georg.brandl
severity: normal
status: open
title: file.seek allows float arguments
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

[issue1080] Search broken

[Georg Brandl]

Georg Brandl added the comment:

This is currently expected; the non-dev version will include a different
search function.

--
nosy: +georg.brandl
resolution:  -> later
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

[issue1071] unicode.translate() doesn't error out on invalid translation table

[Georg Brandl]

Georg Brandl added the comment:

Here's a patch that should make unicode.translate() more robust, and
also allows unicode characters to be passed in the mapping.

__
Tracker <[EMAIL PROTECTED]>

__Index: Objects/unicodeobject.c
===
--- Objects/unicodeobject.c (Revision 57871)
+++ Objects/unicodeobject.c (Arbeitskopie)
@@ -7763,10 +7763,48 @@
 static PyObject*
 unicode_translate(PyUnicodeObject *self, PyObject *table)
 {
+PyObject *keys = NULL;
+Py_ssize_t i;
+
+if (!PyDict_Check(table)) {
+PyErr_SetString(PyExc_TypeError, "translate argument must be a dict");
+return NULL;
+}
+/* fixup the table -- allow string keys instead of only int keys */
+keys = PyDict_Keys(table);
+if (!keys) return NULL;
+for (i = 0; i < PyList_GET_SIZE(keys); i++) {
+PyObject *key = PyList_GET_ITEM(keys, i);
+if (PyUnicode_Check(key)) {
+/* convert string keys to integer keys */
+PyObject *newkey;
+if (PyUnicode_GET_SIZE(key) != 1) {
+PyErr_SetString(PyExc_ValueError, "string items in translate "
+"table must be 1 element long");
+goto err;
+}
+newkey = PyInt_FromLong(PyUnicode_AS_UNICODE(key)[0]);
+if (!newkey)
+goto err;
+if (PyDict_SetItem(table, newkey, PyDict_GetItem(table, key)) < 0)
+goto err;
+if (PyDict_DelItem(table, key) < 0)
+goto err;
+} else if (!PyInt_Check(key)) {
+PyErr_SetString(PyExc_TypeError, "items in translate table must be 
"
+"strings or integers");
+goto err;
+}
+}
+Py_DECREF(keys);
+
 return PyUnicode_TranslateCharmap(self->str,
  self->length,
  table,
  "ignore");
+  err:
+Py_XDECREF(keys);
+return NULL;
 }
 
 PyDoc_STRVAR(upper__doc__,
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1082] platform system may be Windows or Microsoft since Vista

[Pat LaVarre]

New submission from Pat LaVarre:

SUMMARY:

'Microsoft' is the platform.system() of Vista Windows, whereas 'Windows' 
was the platform.system() of XP Windows, whoops.

STEPS TO REPRODUCE & ACTUAL RESULTS:

Run 2.5.1 Python in a Vista and see:

>>> import platform
>>> platform.system()
>>>
'Microsoft'
>>> 

EXPECTED RESULTS:

>>> import platform
>>> platform.system()
'Windows'
>>> 

WORKAROUND:

Write new Python source code like:

if platform.system() in ('Windows', 'Microsoft'): 
if not (platform.system() in ('Windows', 'Microsoft')): 

in place of obsolete Python source code like:

if platform.system() == 'Windows': # Microsoft 
if platform.system() != 'Windows': # Microsoft 

REGRESSION/ ISOLATION:

Seen by me in an Enterprise Vista. Indexed by Google as reported by 
Martin v. Löwis (loewis) circa 2007-05-29 07:11 as:

http://mail.python.org/pipermail/patches/2007-June/022947.html 
... 

Patches item #1726668, was opened at 2007-05-28 03:23 

On Microsoft Vista platform.system() returns 'Microsoft' and 
platform.release() returns 'Windows' 

Under Microsoft Windows XP SP2 platform.system() returns 'Windows' and 
platform.release() returns 'XP'. 

This is problem was caused by a change in the output of the "ver" 
command. In Windows XP SP2 "ver" outputted 'Microsoft Windows XP 
[Version 5.1.2600]'  In Microsoft Vista "ver" outputted 'Microsoft 
Windows [Version 6.0.6000]'. The lack of the 3rd word before version 
causes _syscmd_ver(...) in platform.py to return 'Microsoft' for system 
instead of 'Microsoft Windows'. This causes uname() to return the 
incorrect values. Both system() and release() call uname().

NOTES:

There is no fixing all of this?

Cross-platform scripts actually will misbehave across the large 
population that is 2.5 Python in Vista unless those scripts change to 
implement something like the suggested workaround, that's now an 
accomplished fact.

Question: Is it better to leave this feature as is, so that everyone 
eventually learns to workaround it, or is it better to fix it late now 
in 2007-09, so that many people never have to learn to workaround it?

Question: Why are we screen-scraping the Ver command, instead of calling 
Win kernel32.getVersionEx? And how can any code for screen-scraping the 
Ver command be in doubt about whether the platform.system underneath is 
'Windows'?

--
components: Windows
messages: 55561
nosy: [EMAIL PROTECTED]
severity: major
status: open
title: platform system may be Windows or Microsoft since Vista
type: behavior
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

[issue1072] Documentaion font size too small

[Georg Brandl]

Georg Brandl added the comment:

Okay, next try. I think the sizes are more balanced now.

__
Tracker <[EMAIL PROTECTED]>

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

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


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

Skip Montanaro added the comment:

Fred, can we move this forward?

_
Tracker <[EMAIL PROTECTED]>

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

[issue1082] platform system may be Windows or Microsoft since Vista

[Bill Janssen]

Bill Janssen added the comment:

Wow.  I think that platform.system() should return "Windows" for both XP 
and Vista, and platform.release() should return either "Vista" or "XP".  
Seems like a patch to make this happen would be a good idea.

--
nosy: +janssen

__
Tracker <[EMAIL PROTECTED]>

__
___
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 /

[Skip Montanaro]

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

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

[issue1084] ''.find() gives wrong result in Python built with ICC

[Simon Anders]

Changes by Simon Anders:


--
components: Build, Interpreter Core
severity: normal
status: open
title: ''.find() gives wrong result in Python built with ICC
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

[issue1084] ''.find() gives wrong result in Python built with ICC

[Simon Anders]

New submission from Simon Anders:

I have just encountered a strange bug affecting Python 2.5.1 on an
x86_64 Linux, but only when compiled with the Intel C Compiler (ICC)
10.0, not a GCC-compiled Python. On my Intel-compiled one, which
otherwise seems to work fine, ''.find() works incorrectly.

I have narrowed down the issue to the simple test case

   "foo2/**bar**/".find ("/**bar**/")

Observe: On a GCC-compiled Python 2.5.1, the command works as
expected by returning 4:

  [EMAIL PROTECTED] tmp]$ /usr/site/hc-2.6/python/gnu/2.5.1/bin/python2.5
  Python 2.5.1 (r251:54863, Aug 30 2007, 16:21:23)
  [GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> print "foo2/**bar**/".find ("/**bar**/")
  4

On my Python 2.5.1 installation which was compiled from source with the
Intel C Compiler (ICC) for Linux, version 10.0, '-1' is returned:

  [EMAIL PROTECTED] tmp]$ /usr/site/hc-2.6/python/intel/2.5.1/bin/python2.5
  Python 2.5.1 (r251:54863, Aug 30 2007, 16:20:06)
  [GCC Intel(R) C++ gcc 3.4 mode] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> print "foo2/**bar**/".find ("/**bar**/")
  -1

What could have possibly gone wrong here? Admittedly, this smacks more
of a bug in icc than in Python, but I report it here, as I feel at loss
of what else to do with it.

Obvious first question: Does anyone else out here have an ICC-compiled
Python handy  to check whether the bug reproduces elsewhere?

Any idea what kind of oddity I have stumbled over here? Obviously, it
could simply be that something went wrong when compiling Python from
source with ICC, but it should not happen that the interpreter
nebertheless starts up and fails only silently.

Additional information:

- I have stumbled over the problem when trying to install Numpy 1.0.3.1,
as the built failed at the point where a script 'conv_template.py',
which is part of NumPy's installtion system, is started to do some
pattern replacements in a file called 'scalartypes.inc.src'. My test
case is reduced from this script.

- The system is the master node of a compute cluster with AMD Opteron
CPUs. The cluster is not involved, all was done on the master node. The
box runs RedHat Enterprise Linux 4.0 Advanced Server. It replies to
'uname -a' with:
   Linux hc-ma.uibk.ac.at 2.6.9-42.0.10.ELsmp #1 SMP Fri Feb 16 17:13:42
EST 2007 x86_64 x86_64 x86_64 GNU/Linux

- The dynamic dependencies of the GCC-compiled and the ICC-compiled
Python binaries are:
[EMAIL PROTECTED] tmp]$ ldd /usr/site/hc-2.6/python/gnu/2.5.1/bin/python2.5
libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x00370290)
libdl.so.2 => /lib64/libdl.so.2 (0x003701d0)
libutil.so.1 => /lib64/libutil.so.1 (0x00370390)
libm.so.6 => /lib64/tls/libm.so.6 (0x003701b0)
libc.so.6 => /lib64/tls/libc.so.6 (0x00370180)
/lib64/ld-linux-x86-64.so.2 (0x00370160)
[EMAIL PROTECTED] tmp]$ ldd /usr/site/hc-2.6/python/intel/2.5.1/bin/python2.5
libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x00370290)
libdl.so.2 => /lib64/libdl.so.2 (0x003701d0)
libutil.so.1 => /lib64/libutil.so.1 (0x00370390)
libimf.so => /usr/site/hc-2.6/intel/10.0/cc/lib/libimf.so
(0x002a95579000)
libm.so.6 => /lib64/tls/libm.so.6 (0x003701b0)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00370580)
libc.so.6 => /lib64/tls/libc.so.6 (0x00370180)
/lib64/ld-linux-x86-64.so.2 (0x00370160)

- The precise revision of Python is "Python 2.5.1 (r251:54863)".

- The test case ceases to show failure if the string is only slightly
altered, e.g. if the word 'foo', the word 'bar' or the one of the
asterisks or one of the slashes is cut out in both search and target string.

--
nosy: +sanders_muc

__
Tracker <[EMAIL PROTECTED]>

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

[issue1071] unicode.translate() doesn't error out on invalid translation table

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

Nice idea, but why don't you use a dictionary iterator (PyDict_Next())
for the fixup ?

__
Tracker <[EMAIL PROTECTED]>

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

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

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

Skip Montanaro added the comment:

Ummm... make that: "I'll implement multiplication."

_
Tracker <[EMAIL PROTECTED]>

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

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

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

Skip Montanaro added the comment:

See this other issue I just closed:

http://bugs.python.org/issue1118748

--
nosy: +skip.montanaro

_
Tracker <[EMAIL PROTECTED]>

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

Changes by Skip Montanaro:


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

[issue1673409] datetime module missing some important methods

[Skip Montanaro]

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

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

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

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

[issue1085] OS X 10.5.x Build Problems

[Noah Gift]

Changes by Noah Gift:


--
components: Tests
severity: major
status: open
title: OS X 10.5.x Build Problems
type: compile error
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

[issue1085] OS X 10.5.x Build Problems

[Noah Gift]

New submission from Noah Gift:

Compile problem on:

System Software Overview:

  System Version:   Mac OS X 10.5 (9A527)
  Kernel Version:   Darwin 9.0.0b5

Temporary Fix was to go into Modules/posixmodule.c

and at line:  3767

Take out function and create empty function.

I was then able to get make to run, but still got these non-critical 
errors:

Failed to find the necessary bits to build these modules:
_bsddbgdbm  ossaudiodev
readline  spwd 
To find the necessary bits, look in setup.py in detect_modules() for the 
module's name.


Failed to build these modules:
_OSA 

Running make test I get:

running sudo make test, some errors are:

Traceback (most recent call last):
  File "/Users/ngift/Desktop/Python-3.0a1/Lib/SocketServer.py", line 
222, in handle_request
self.process_request(request, client_address)
  File "/Users/ngift/Desktop/Python-3.0a1/Lib/SocketServer.py", line 
241, in process_request
self.finish_request(request, client_address)
  File "/Users/ngift/Desktop/Python-3.0a1/Lib/SocketServer.py", line 
254, in finish_request
self.RequestHandlerClass(request, client_address, self)
  File "/Users/ngift/Desktop/Python-3.0a1/Lib/SocketServer.py", line 
522, in __init__
self.handle()
  File "/Users/ngift/Desktop/Python-3.0a1/Lib/BaseHTTPServer.py", line 
330, in handle
self.handle_one_request()
  File "/Users/ngift/Desktop/Python-3.0a1/Lib/BaseHTTPServer.py", line 
313, in handle_one_request
self.raw_requestline = self.rfile.readline()
  File "/Users/ngift/Desktop/Python-3.0a1/Lib/io.py", line 380, in 
readline
b = self.read(nreadahead())
  File "/Users/ngift/Desktop/Python-3.0a1/Lib/io.py", line 366, in 
nreadahead
readahead = self.peek(1, unsafe=True)
  File "/Users/ngift/Desktop/Python-3.0a1/Lib/io.py", line 758, in peek
current = self.raw.read(to_read)
  File "/Users/ngift/Desktop/Python-3.0a1/Lib/io.py", line 442, in read
n = self.readinto(b)
  File "/Users/ngift/Desktop/Python-3.0a1/Lib/socket.py", line 292, in 
readinto
return self._sock.recv_into(b)
socket.error: (35, 'Resource temporarily unavailable')
test test_xmlrpc failed -- errors occurred; run in verbose mode for 
details
test_xmlrpc_net
test_xmlrpc_net skipped -- Use of the `network' resource not enabled
test_zipfile
test_zipfile64
test_zipfile64 skipped -- test requires loads of disk-space bytes and a 
long time to run
test_zipimport
test_zlib
295 tests OK.
2 tests failed:
test__locale test_xmlrpc
25 tests skipped:
test_bsddb test_bsddb3 test_codecmaps_cn test_codecmaps_hk
test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses
test_gdbm test_largefile test_locale test_normalization
test_ossaudiodev test_pep277 test_socket_ssl test_socketserver
test_ssl test_startfile test_timeout test_urllib2net
test_urllibnet test_winreg test_winsound test_xmlrpc_net
test_zipfile64
1 skip unexpected on darwin:
test_ssl
make: *** [test] Error 1

Then when I run make install it *almost* works but I get:

Writing 
/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/lib-
dynload/Python-3.0a1-py3.0.egg-info
ln -fs "../../../Python" 
"/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/config/
libpython3.0.a"
cd Mac && make installmacsubtree DESTDIR=""
Creating directory 
/Library/Frameworks/Python.framework/Versions/3.0/Mac/Tools
DYLD_FRAMEWORK_PATH=/Users/ngift/Desktop/Python-3.0a1: ../python.exe 
./scripts/cachersrc.py -v 
/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/plat-mac 
/Library/Frameworks/Python.framework/Versions/3.0/Mac/Tools
  File "./scripts/cachersrc.py", line 15
def handler((verbose, force), dirname, fnames):
^
SyntaxError: invalid syntax
make[1]: *** [installmacsubtree] Error 1
make: *** [frameworkinstallmaclib] Error 2

--
nosy: +noahgift

__
Tracker <[EMAIL PROTECTED]>

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