[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

[Raymond Hettinger]

Raymond Hettinger added the comment:

FWIW, I'm -1 on moving this module to the standard library.  There has 
been basically *zero* demand for something like this.  Because rational 
implementations seem to be more fun to write than to use, I think there 
are some competing implementations.

--
nosy: +rhettinger

__
Tracker <[EMAIL PROTECTED]>

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

[issue1763] Winpath module - easy access to Windows directories like My Documents

[Martin v. Löwis]

Martin v. Löwis added the comment:

It was never explicitly discussed, however, I always assumed that NT4
support is not necessary anymore.

I would like to pose a policy that Python does not need to support
Windows releases which have left Microsoft's "extended support". For NT
4 WS, this was on 30.6.2004. For Windows 2000 Pro, this will be on
13.7.2010. Of course, *testing* the releases on Windows 2000 will become
difficult - I don't have access to Windows 2000 installations anymore.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1763] Winpath module - easy access to Windows directories like My Documents

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

> It uses SHGetFolderPathW which is compatible with Windows 2000.

Is Python supposed to still work on Windows NT 4?

http://svn.python.org/projects/python/trunk/README says that support
will be droppen in 2.6 for Win9x and WinME, but says nothing about NT4.

OTOH, the msdn library site removed many references to NT4 (see the doc
for CreateFile, for example). It could be wise to say that python 2.6 is
supported only on Windows 2000 and up.

--
nosy: +amaury.forgeotdarc

__
Tracker <[EMAIL PROTECTED]>

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

[issue1763] Winpath module - easy access to Windows directories like My Documents

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

OK. We should also remove references to older versions on the website:
http://www.python.org/download/releases/2.5.1/ and the various READMEs.

For testing older platforms, we can still use virtual machines. I think
this is how Christian develops on Windows XP.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1774] Reference to New style classes documentation is incorrect

[albert hofkamp]

New submission from albert hofkamp:

In the Python reference manual (the online current documentation), in
Section 3.3 "New-style and classic classes", there is a reference to
external documentation about new style classes.
The reference is however incorrect, it should be
http://www.python.org/doc/newstyle/ rather than the mentioned
http://www.python.org/doc/newstyle.html

--
components: Documentation
messages: 59588
nosy: aioryi
severity: normal
status: open
title: Reference to New style classes documentation is incorrect
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

[issue1773] Reference to Python issue tracker incorrect

[albert hofkamp]

New submission from albert hofkamp:

In the Python reference manual (the online current documentation), in
the "About this document" section, there is a reference to the
Sourceforge bug tracker for reporting errors in the document.
This tracker however has been closed, and has been replaced by the one
at http://bugs.python.org/

--
components: Documentation
messages: 59587
nosy: aioryi
severity: normal
status: open
title: Reference to Python issue tracker incorrect
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

[issue1114] _curses issues on 64-bit big-endian (e.g, AIX)

[A.M. Kuchling]

A.M. Kuchling added the comment:

Rev. 59870 on trunk fixes another usage of &attr in the wrapper for the
chgat() method.

Luke, a 2.5.2 release is not too far off.  If possible, can you please
try compiling the 25-maint branch on AIX to check that the problems are
fixed?  Thanks!

__
Tracker <[EMAIL PROTECTED]>

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

[issue1731] Random errors on interpreter shutdown

[A.M. Kuchling]

A.M. Kuchling added the comment:

The fix has been applied (by GvR) to 2.5 in r59724.

This issue can probably be closed now.

--
nosy: +akuchling

__
Tracker <[EMAIL PROTECTED]>

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

[issue1266] segfault in curses when calling redrawwin() before refresh()

[A.M. Kuchling]

Changes by A.M. Kuchling:


--
assignee:  -> akuchling
nosy: +akuchling

__
Tracker <[EMAIL PROTECTED]>

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

[issue1775] filehandle.write() does not return None (Python 3.0a2)

[Andre Roberge]

New submission from Andre Roberge:

According to the docs, and consistent with the Python 2.x behavior,
filehandle.write() should return None.  However, under 3.0a2 (and
3.0a1), it returns the number of characters written.

Either the documentation
http://docs.python.org/dev/3.0/tutorial/inputoutput.html#reading-and-writing-files
is wrong, or it is a bug.  I would *much* prefer if the behavior would
stay the same as before.

Below is a sample session illustrating the behavior.  Note that I also
get an error message when exiting the session using exit() - this is an
unrelated problem.

Python 3.0a2 (r30a2:59382, Dec 27 2007, 15:48:14) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> handle = open('test_file.txt.', 'w')
>>> handle.write('spam')
4
>>> r = handle.write('more spam')
>>> print(r)
9
>>> exit()
/usr/local/py3k/lib/python3.0/io.py:1210: RuntimeWarning: Trying to
close unclosable fd!
  self.buffer.close()

--
components: Interpreter Core
messages: 59592
nosy: aroberge
severity: normal
status: open
title: filehandle.write() does not return None (Python 3.0a2)
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

[issue1773] Reference to Python issue tracker incorrect

[A.M. Kuchling]

A.M. Kuchling added the comment:

Fixed in rev. 57394 of the 2.5 branch; thanks for reporting this!  The
web site's copy of the documentation will be updated when Python 2.5.2
is released.

--
assignee:  -> akuchling
nosy: +akuchling
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

[issue1774] Reference to New style classes documentation is incorrect

[Facundo Batista]

Changes by Facundo Batista:


--
assignee:  -> facundobatista
nosy: +facundobatista

__
Tracker <[EMAIL PROTECTED]>

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

[issue1761] Bug in re.sub()

[Fredrik Lundh]

Fredrik Lundh added the comment:

For the record, $ is defined to match "before a newline at the end of
the string, or at the end of the string" in normal mode, and "before any
newline, or at the end of the string" in multiline mode.

(and I have a vague memory that the "before a newline" behaviour in
normal mode was added for Perl compatibility)

> It seems that it matches BOTH the end of the string AND just before
the newline at the end of the string.

Of course it does: re.sub scans the string for matches from left to
right, and does the substitution everywhere the pattern matches, only
skipping over the matched parts.  Or in other words, if a pattern
matches N characters on position X has no influence on whether it
matches on position X+N or not.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1763] Winpath module - easy access to Windows directories like My Documents

[Christian Heimes]

Christian Heimes added the comment:

Amaury Forgeot d'Arc wrote:
> For testing older platforms, we can still use virtual machines. I think
> this is how Christian develops on Windows XP.

Correct, I'm using a VMWare installation of Windows XP SP2 German and
DesktopBSD (FreeBSD variant) to test Python on Windows and BSD. Several
of the build bots seem to use a VMWare installation, too.

Christian

__
Tracker <[EMAIL PROTECTED]>

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

[issue1642054] Python 2.5 gets curses.h warning on HPUX

[A.M. Kuchling]

Changes by A.M. Kuchling:


--
assignee:  -> akuchling

_
Tracker <[EMAIL PROTECTED]>

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

[issue1776] __import__ must not accept filenames

[Christian Heimes]

New submission from Christian Heimes:

See http://permalink.gmane.org/gmane.comp.python.devel/90960

It's also "broken" in 2.5 but we must not change the behavior in a
maintenance  release.

--
components: Interpreter Core
messages: 59602
nosy: tiran
priority: normal
severity: normal
status: open
title: __import__ must not accept filenames
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

[issue1379209] socket.recv(OOB) raises exception on closed socket

[Facundo Batista]

Facundo Batista added the comment:

Tried it on Linux, but the behaviour is the same on Py2.5.

It was already fixed in the trunk (it returns "", as in the inbound read).

Thanks for the report!

--
resolution:  -> out of date
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

[issue1775] filehandle.write() does not return None (Python 3.0a2)

[Guido van Rossum]

Guido van Rossum added the comment:

The intention was that the lowest-level (unbuffered) stream object can
write fewer bytes than given to it, as it is a direct interface to the
underlying system call, which has this property (especially when the
file is in non-blocking mode).

I think it's fine to return None from the higher-level classes' write()
method (buffered and text).  Though this makes it a bit harder to switch
between buffered and unbuffered binary output.  Perhaps text I/O should
return None and bytes I/O should return a byte count?

__
Tracker <[EMAIL PROTECTED]>

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

[issue846388] Check for signals during regular expression matches

[Facundo Batista]

Facundo Batista added the comment:

Retried it in a platform where I trust timing, and it proved ok.

So, problem solved, no performance impact, all tests pass ok. Commited
in r59862.

Thank you all!

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

[issue1729930] 2.5.1 latest svn fails test_curses and test_timeout

[A.M. Kuchling]

A.M. Kuchling added the comment:

According to the man page for endwin() from ncurses, "In this
implementation endwin returns an error if the terminal was not
initialized." This doesn't make the problem any clearer to me.  Perhaps
the setupterm() or initscr() in Lib/tests/test_curses is failing in a
way that 
we aren't noticing.

--
nosy: +akuchling

_
Tracker <[EMAIL PROTECTED]>

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

[issue1775] filehandle.write() does not return None (Python 3.0a2)

[Christian Heimes]

Christian Heimes added the comment:

Guido, Mike and Mark have implemented most of the new IO library. I'm
sure they can shed some light on the design decision.

I've fixed the other bug a while ago. I don't use exit() and I didn't
noticed the problem until Joseph pointed me in the right direction.

--
assignee:  -> gvanrossum
components: +Library (Lib) -Interpreter Core
nosy: +georg.brandl, gvanrossum, mark_t_russell, tiran
priority:  -> normal

__
Tracker <[EMAIL PROTECTED]>

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

[issue1774] Reference to New style classes documentation is incorrect

[Christian Heimes]

Changes by Christian Heimes:


--
priority:  -> low

__
Tracker <[EMAIL PROTECTED]>

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

[issue1761] Bug in re.sub()

[Guido van Rossum]

Guido van Rossum added the comment:

Which is why I like to use \Z to match *only* the end of the string.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1761] Bug in re.sub()

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

Aha, I always thought that \Z was an alias for $.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1210] imaplib does not run under Python 3

[Jean-Paul Calderone]

Jean-Paul Calderone added the comment:

You're correct in pointing out that IMAP4 supports arbitrary encodings,
so simply hard-coding ASCII is not correct.  The encoding isn't
connection-level, but applies to particular sequences of bytes in the
connection stream.  To correctly interpret the bytes as characters,
decoding must be integrated with the rest of the protocol implementation.

--
nosy: +exarkun

__
Tracker <[EMAIL PROTECTED]>

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

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

[Guido van Rossum]

Guido van Rossum added the comment:

Raymond, do you *always* have to be such a grinch?

The mere existance of competing implementations proves that there's a
need.  Hopefully having one in the stdlib will inspire others to
contribute improvements rather than starting from scratch.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1774] Reference to New style classes documentation is incorrect

[Facundo Batista]

Facundo Batista added the comment:

It was ok in the trunk docs. Fixed it in the 2.5 maint branch.

Thanks for the report!

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

[issue1621] Do not assume signed integer overflow behavior

[Guido van Rossum]

Guido van Rossum added the comment:

Alexandre, which Python version did you compile with -Wstrict-overflow?
 It would behoove us to check 2.5.2 thoroughly before it goes out the door.

I will contact Coverity to ask if they check for this kind of thing. 
(They just upgraded us to "Rung 2", whatever that may mean. :-)

MvL: I don't want 2s complement throughout the language, I just want the
overflow checks to be reliable.  Since I'd forgotten about the
difference between unsigned and signed overflow, I have no idea how many
overflow checks have been submitted that are relying on signed overflow;
though apparently (if the -Wstrict-overflow results can be trusted)
we're okay.

FWIW, I've heard that some commercial compilers (e.g. XLC) assume that
even *unsigned* overflow is undefined, violating the C standard.  This
would suggest that buffer overflow checks should be coded without
relying on arithmetic overflow at all.  This is possible, just a bit hairy.

--
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

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

[issue1608] test_str.py crashes

[Guido van Rossum]

Guido van Rossum added the comment:

It would actually be better to use -fno-strict-overflow instead of
-fwrapv, if it exists (GCC 4.2 and later).

See also http://bugs.python.org/issue1621 which suggests there aren't
actually many places that need this; gcc -Wstrict-overflow should help
auditing the code.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

[Raymond Hettinger]

Raymond Hettinger added the comment:

Not sure I'm the grinch on this one.  I thought PEPs on this were 
rejected long ago and no one complained afterwards.  After years of 
watching newsgroup discussions and feature requests, I do not recall a 
single request or seeing a single problem that was better solved with a 
rational package.  On python-help and the tutorial newsgroup, I've 
never seen a question about the existing module in the Tools directory 
or even a question on the topic.

I think rational modules are ubiquitous for the same reason as Sudoku 
solvers -- they are cute, an easy exercise, and fun to write.  There is 
some variation in how each chooses to make compromises so the 
denominators do not get unusably large. Also, there is some variation 
in sophistication of the GCD/LCD algorithm.

I had thought the standards for inclusion in the standard library had 
risen quite a bit (best-in-class category killers and whatnot).  ISTM, 
this is aspiring cruft -- I cannot remember encountering a real 
business or engineering problem that needed rational arithmetic (the 
decimal module seems to meet the rare need for high precision 
arithmetic).

All that being said, maybe the module with serve some sort of 
educational purpose or will serve to show-off the numeric tower 
abstract base classes.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1621] Do not assume signed integer overflow behavior

[Guido van Rossum]

Guido van Rossum added the comment:

Marc-Andre: what do you mean by breaking lots and lots of extensions? 
Extensions also contain buffer overflow checks (at least I hope they do
:-) and those should also be guaranteed safe by using -fwrapv or
-fno-strict-overflow (GCC 4.2 and higher) until we're sure there aren't any.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

[Facundo Batista]

Facundo Batista added the comment:

The PEP 239 is Rejected (http://www.python.org/dev/peps/pep-0239/).

If a Rational data type would be included in the stdlib, my
recommendation is that first that PEP would be reopened and pushed until
get accepted.

Also, note the kind of questions Mark is asking here: the analysis and
answer of those questions belongs to a PEP, not to a patch. We risk to
not be very rational (1/2 wink) in these decisions.

I'd close this patch as Rejected (as for the PEP), at least until the
PEP gets accepted (if ever).

--
nosy: +facundobatista

__
Tracker <[EMAIL PROTECTED]>

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

[issue1621] Do not assume signed integer overflow behavior

[Ismail Donmez]

Ismail Donmez added the comment:

-Wstrict-overflow=3 with gcc 4.3 trunk here shows :

Modules/cPickle.c: In function 'Unpickler_noload':
Modules/cPickle.c:4232: warning: assuming signed overflow does not occur
when assuming that (X - c) > X is always false

Modules/cPickle.c:194: warning: assuming signed overflow does not occur
when assuming that (X - c) > X is always false
Modules/cPickle.c: In function 'load':
Modules/cPickle.c:4232: warning: assuming signed overflow does not occur
when assuming that (X - c) > X is always false

But also note that -fno-strict-aliasing is also just another workaround
and its more serious than -fwrapv.

--
nosy: +cartman

__
Tracker <[EMAIL PROTECTED]>

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

[issue1777] ElementTree/cElementTree findtext inconsistency

[Grant Monroe]

New submission from Grant Monroe:

cElementTree findtext seems to return None when it should return a string.

--
components: Library (Lib)
files: etree_test.py
messages: 59618
nosy: gmonroe
severity: normal
status: open
title: ElementTree/cElementTree findtext inconsistency
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file9115/etree_test.py

__
Tracker <[EMAIL PROTECTED]>

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

[issue1621] Do not assume signed integer overflow behavior

[Martin v. Löwis]

Martin v. Löwis added the comment:

> But also note that -fno-strict-aliasing is also just another workaround
> and its more serious than -fwrapv.

Sure - however, that is fixed in Python 3 (and unrelated to this issue)

__
Tracker <[EMAIL PROTECTED]>

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

[issue1763] Winpath module - easy access to Windows directories like My Documents

[Martin v. Löwis]

Martin v. Löwis added the comment:

> OK. We should also remove references to older versions on the website:
> http://www.python.org/download/releases/2.5.1/ and the various READMEs.

No. Python 2.5.1 *does* support Windows 95 (I have myself tested that).
Only 2.6 will drop support for 9x.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1777] ElementTree/cElementTree findtext inconsistency

[Martin v. Löwis]

Martin v. Löwis added the comment:

Fredrik, can you take a look?

--
assignee:  -> effbot
nosy: +effbot, loewis

__
Tracker <[EMAIL PROTECTED]>

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

[issue1731] Random errors on interpreter shutdown

[Guido van Rossum]

Changes by Guido van Rossum:


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

[issue1776] __import__ must not accept filenames

[Christian Heimes]

Christian Heimes added the comment:

Fixed in r59876

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

[issue1750] Test: This is title

[Georg Brandl]

Georg Brandl added the comment:

testing 

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

[issue1777] ElementTree/cElementTree findtext inconsistency

[Fredrik Lundh]

Fredrik Lundh added the comment:

Looks like the mechanisms used decide when to invoke the full
ElementPath machinery differs somewhat.  I've added this to the TODO
list for ET 1.3; in the meantime, my advice is "don't do that".

(adding a check for '.' to the PATHCHAR macro should fix this, I think.)

--
priority:  -> normal

__
Tracker <[EMAIL PROTECTED]>

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

[issue1750] Test: This is title

[Georg Brandl]

Georg Brandl added the comment:

testing 

__
Tracker <[EMAIL PROTECTED]>

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

[issue1775] filehandle.write() does not return None (Python 3.0a2)

[Andre Roberge]

Andre Roberge added the comment:

After doing some more reading, I realize that the current behaviour is
totally consistent with
http://www.python.org/dev/peps/pep-3116/
which I should have consulted first.
So perhaps it should be considered to be simply a case of a
documentation error, as I alluded to when I open this issue. (sorry for
the noise)

__
Tracker <[EMAIL PROTECTED]>

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

[issue1448325] re search infinite loop

[Ralf Schmitt]

Ralf Schmitt added the comment:

You're being a victim of two issues here:

1.regular expression matching can take a long time. see:
http://bugs.python.org/issue1662581

2. regular expression matching was not interruptible:
http://bugs.python.org/issue846388

--
nosy: +schmir
versions: +Python 2.3, 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

[issue1662581] the re module can perform poorly: O(2**n) versus O(n**2)

[Ralf Schmitt]

Ralf Schmitt added the comment:

here are two other bug reports about the same issue:

http://bugs.python.org/issue1448325

http://bugs.python.org/issue1566086

--
nosy: +schmir

_
Tracker <[EMAIL PROTECTED]>

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

[issue1277] mailbox.Maildir: factory not used

[A.M. Kuchling]

Changes by A.M. Kuchling:


--
assignee:  -> akuchling
nosy: +akuchling

__
Tracker <[EMAIL PROTECTED]>

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

[issue1566086] RE (regular expression) matching stuck in loop

[Ralf Schmitt]

Ralf Schmitt added the comment:

With python 2.6 the program can be interrupted with ctrl-c (see
http://bugs.python.org/issue846388). I think this one should be closed
as a duplicate of: http://bugs.python.org/issue1662581

--
nosy: +schmir

_
Tracker <[EMAIL PROTECTED]>

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

[issue1720992] automatic imports

[Ralf Schmitt]

Ralf Schmitt added the comment:

it won't get better than: http://pypi.python.org/pypi/autoimp/
I suggest this should be closed.

--
nosy: +schmir

_
Tracker <[EMAIL PROTECTED]>

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

[issue756982] mailbox should use email not rfc822

[A.M. Kuchling]

Changes by A.M. Kuchling:


--
assignee: barry -> akuchling


Tracker <[EMAIL PROTECTED]>


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

[issue1488934] file.write + closed pipe = no error

[Ralf Schmitt]

Ralf Schmitt added the comment:

the c program is broken as it does not check the error code of fflush.
The real problem is buffering.

while True:
__print 'Hello'
__time.sleep (1)

will not notice an error until the buffers are flushed.
Running python t.py |head -n2 and killing head does not give me an
error. with PYTHONUNBUFFERED=1 or when using sys.stdout.flush() the
program breaks with:

~/ PYTHONUNBUFFERED=1 python t.py|head -n2   
[EMAIL PROTECTED] ok
Hello
Hello
Traceback (most recent call last):
  File "t.py", line 5, in 
print "Hello"
IOError: [Errno 32] Broken pipe

--
nosy: +schmir

_
Tracker <[EMAIL PROTECTED]>

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

[issue1488934] file.write + closed pipe = no error

[Ralf Schmitt]

Ralf Schmitt added the comment:

ahh.no. the c program does the fflush on the logfile...sorry.

_
Tracker <[EMAIL PROTECTED]>

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

[issue1566086] RE (regular expression) matching stuck in loop

[Georg Brandl]

Georg Brandl added the comment:

Done.

--
nosy: +georg.brandl
resolution:  -> duplicate
status: open -> closed
superseder:  -> the re module can perform poorly: O(2**n) versus O(n**2)

_
Tracker <[EMAIL PROTECTED]>

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

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

[Guido van Rossum]

Guido van Rossum added the comment:

The rejection of PEP 239 was years ago.  PEP 3141 was accepted; it
includes adding a rational type to the stdlib, and Jeffrey is doing this
with my encouragement.

The motivation is to have at least one example of each type in our
modest numeric tower in the stdlib.  I'm sure there will be plenty of
uses for rational.py, e.g. in education.  Of course, if someone has a
better candidate or a proposed improvement, speak up now!  It looks like
Mark's suggestions can be treated as code review; I don't think we need
a new PEP.

Note that the mere existence of PEP 239 again points out that the demand
is not zero.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1778] SyntaxError.offset sometimes wrong

[Achim Gaedke]

New submission from Achim Gaedke:

The value SyntaxError.offset is for most SyntaxErrors an offset from
beginning of line SyntaxError.lineno. In case of an triple-quoted string
which is not at all closed, offset seems to be the offset from beginning
of the buffer.

--
components: Interpreter Core
files: compile_test.py
messages: 59634
nosy: AchimGaedke
severity: normal
status: open
title: SyntaxError.offset sometimes wrong
type: behavior
versions: Python 2.4, Python 2.5
Added file: http://bugs.python.org/file9116/compile_test.py

__
Tracker <[EMAIL PROTECTED]>

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

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

[Raymond Hettinger]

Raymond Hettinger added the comment:

If this goes in, I have some recommendations:

* Follow the decimal module's lead in assiduously avoiding
float->rational conversions.  Something like Rat.from_float(1.1) is
likely to produce unexpected results (like locking in an inexact input
and having an unexpectedly large denominator).

* Likewise, follow decimal's lead in avoiding all automatic coercisions
from floats:  Rational(3,10) + 0.3 for example.  The two don't mix.

* Consider following decimal's lead on having a context that can limit
the maximum size of a denominator.  There are various strategies for
handling a limit overflow including raising an exception or finding the
nearest rational upto the max denominator (there are some excellent
though complex published algorithms for this) or rounding the nearest
fixed-base (very easy).  I'll dig out my HP calculator manuals at some
point -- they had worked-out a number of challenges with fractional
arithmetic (including their own version of an Inexact tag).

* Consider adding Decimal.from_rational and Rational.from_decimal.  I
believe these are both easy and can be done losslessly.

* Automatic coercions to/from Decimal need to respect the active decimal
context.  For example the result of Rational(3,11) +
Decimal('3.1415926') is context dependent and may not be commutative.

* When in doubt, keep the API minimal so we don't lock-in design mistakes.

* Test the API by taking a few numerical algorithms and seeing how well
they work with rational inputs (for starters, try
http://docs.python.org/lib/decimal-recipes.html ).

* If you do put in a method that accepts floats, make sure that it can
accept arguments to control the rational approximation.  Ideally, you
would get something something like this Rational.approximate(math.pi, 6)
--> 355/113 that could produce the smallest rationalal approximation to
a given level of accuracy.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1778] SyntaxError.offset sometimes wrong

[Christian Heimes]

Changes by Christian Heimes:


--
priority:  -> normal

__
Tracker <[EMAIL PROTECTED]>

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

[issue1277] mailbox.Maildir: factory not used

[Christian Heimes]

Changes by Christian Heimes:


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

__
Tracker <[EMAIL PROTECTED]>

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

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

[Facundo Batista]

Facundo Batista added the comment:

2008/1/9, Raymond Hettinger said:

> * Consider adding Decimal.from_rational and Rational.from_decimal.  I
> believe these are both easy and can be done losslessly.

If it's lossless, why not just allow Decimal(Rational(...)) and
Rational(Decimal(...))?

__
Tracker <[EMAIL PROTECTED]>

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

[issue1381] cmath is numerically unsound

[Christian Heimes]

Christian Heimes added the comment:

Guido, how do you like the idea of Include/pymath.h and Python/pymath.c
containing supplementary mathematical functions and mathematical
constants? Mark's patch for cmath is rather large, can it still be
applied to 2.5?

--
nosy: +gvanrossum
versions: +Python 2.6

__
Tracker <[EMAIL PROTECTED]>

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

[issue1381] cmath is numerically unsound

[Guido van Rossum]

Guido van Rossum added the comment:

Are you crazy?  Adding new features to 2.5?  No way!

__
Tracker <[EMAIL PROTECTED]>

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

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

[Raymond Hettinger]

Raymond Hettinger added the comment:

> If it's lossless, why not just allow 
>Decimal(Rational(...)) and Rational(Decimal(...))?

Those conversions are fine.  

It's the float<-->rational conversions that are problematic.  There are
exact float to rational conversions using math.frexp() but I don't think
the results tend to match what users expect (since 1.1 isn't exactly
represented).  Also, there may be overflow issues with trying to go from
rationals to floats when the denomintor is very large.

I think the history of rational modules is that simplistic
implementations get built and then the writers find that exploding
denominators limit their usefulness for anything other than trivial
problems.  The solution is to limit denominators but that involves less
trivial algorithms and a more sophisticated API.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

[Guido van Rossum]

Guido van Rossum added the comment:

On Jan 9, 2008 4:29 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> I think the history of rational modules is that simplistic
> implementations get built and then the writers find that exploding
> denominators limit their usefulness for anything other than trivial
> problems.  The solution is to limit denominators but that involves less
> trivial algorithms and a more sophisticated API.

A "rational" type that limits denominators (presumably by rounding)
isn't needed -- we alreay have Decimal.  The proposed rational type is
meant for "pure" mathematical uses, just like Python's long ints.

Regarding float->rational, I propose to refuse Rational(1.1) for the
same reasons as Decimal(1.1) is refused, but to add a separate
constructor (a class method?) that converts a float to a rational
exactly (as long as it isn't nan or inf), large denominators be
damned. This can help people who are interested in taking floating
point numbers apart.

float(Rational()) should be fine.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1779] int("- 1") is valud, but float("- 1") isn't. Which is right?

[Guido van Rossum]

New submission from Guido van Rossum:

I discovered that when converting a string to an int or float, the int
conversion allows whitespace after the sign, while the float conversion
doesn't. I think they should be consistent.

--
components: Interpreter Core
messages: 59641
nosy: gvanrossum
priority: low
severity: normal
status: open
title: int("- 1") is valud, but float("- 1") isn't. Which is right?
versions: Python 2.4, Python 2.5, 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

[issue1780] Decimal constructor accepts newline terminated strings

[Mark Dickinson]

New submission from Mark Dickinson:

After seeing issue #1761, I realized that there's a bug in the Decimal 
constructor:  it accepts newline-terminated strings:

>>> from decimal import *
>>> s = "2.3\n"
>>> Decimal(s)
Decimal("2.3")

I think this is, strictly speaking, a bug because:

(1) The IBM decimal specification explicitly disallows additional whitespace 
in a numeric string (see http://www2.hursley.ibm.com/decimal/daconvs.html),

(2) the operation to-number is supposed only to accept numeric strings, and

(3) Decimal.__new__ is currently the method that implements to-number.

Is this worth fixing?  This buggy behaviour might well be useful (e.g. to 
someone parsing a file with one Decimal per line).

I'll fix it if anyone thinks it's worth it.  Even if it should be fixed, I 
don't think this is worth backporting to Python 2.5, especially since it 
might break things.

--
assignee: facundobatista
components: Library (Lib)
messages: 59642
nosy: facundobatista, marketdickinson
priority: normal
severity: minor
status: open
title: Decimal constructor accepts newline terminated strings
type: behavior
versions: Python 2.5, 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

[issue1780] Decimal constructor accepts newline terminated strings

[Guido van Rossum]

Guido van Rossum added the comment:

I'd propose doing the same thing as int() and float(), which accept and
strip leading and trailing whitespace.

--
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

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

[issue1780] Decimal constructor accepts newline terminated strings

[Raymond Hettinger]

Raymond Hettinger added the comment:

I concur with Guido.  The to-number operation is part of the spec.  The
constructor belongs to us and should match the rest of the language.

--
nosy: +rhettinger

__
Tracker <[EMAIL PROTECTED]>

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

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

[Jeffrey Yasskin]

Jeffrey Yasskin added the comment:

> * Follow the decimal module's lead in assiduously avoiding
> float->rational conversions.  Something like Rat.from_float(1.1) is
> likely to produce unexpected results (like locking in an inexact input
> and having an unexpectedly large denominator).

I agree that it's not usually what people ought to use, and I don't
think it's an essential part of the API. It might be a useful starting
point for the approximation methods though. .trim() and .approximate()
in 
http://svn.python.org/view/sandbox/trunk/rational/Rational.py?rev=40988&view=auto
and Haskell's approxRational
(http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/Data-Ratio.html)
start from rationals instead of floats. On the other hand, it might
make sense to provide explicit methods to approximate from floats
instead of asking people to execute the two-phase process. I'm happy
to give it a different name or drop it entirely.

> * Likewise, follow decimal's lead in avoiding all automatic coercisions
> from floats:  Rational(3,10) + 0.3 for example.  The two don't mix.

I'm reluctant to remove the fallback to float, unless the consensus is
that it's always a bad idea to support mixed-mode arithmetic (which is
possible: I was surprised by the loss of precision of "10**23/1" while
writing this). Part of the purpose of this class is to demonstrate how
to implement cross-type operations. Note that it is an automatic
coercion _to_ floats, so it doesn't look like you've gotten magic
extra precision.

> * Consider following decimal's lead on having a context that can limit
> the maximum size of a denominator.  There are various strategies for
> handling a limit overflow including raising an exception or finding the
> nearest rational upto the max denominator (there are some excellent
> though complex published algorithms for this) or rounding the nearest
> fixed-base (very easy).  I'll dig out my HP calculator manuals at some
> point -- they had worked-out a number of challenges with fractional
> arithmetic (including their own version of an Inexact tag).

Good idea, but I'd like to punt that to a later revision if you don't
mind. If we do punt, that'll force the default context to be "infinite
precision" but won't prevent us from adding explicit contexts. Do you
see any problems with that?

> * Consider adding Decimal.from_rational and Rational.from_decimal.  I
> believe these are both easy and can be done losslessly.

Decimal.from_rational(Rat(1, 3)) wouldn't be lossless, but
Rational.from_decimal is easier than from_float. Then
Decimal.from_rational() could rely on just numbers.Rational, so it
would be independent of this module. Is that a method you'd want on
Decimal anyway? The question becomes whether we want the rational to
import decimal to implement the typecheck, or just assume that
.as_tuple() does the right thing. These are just as optional as
.from_float() though, so we can also leave them for future
consideration.

> * Automatic coercions to/from Decimal need to respect the active decimal
> context.  For example the result of Rational(3,11) +
> Decimal('3.1415926') is context dependent and may not be commutative.

Since I don't have any tests for that, I don't know whether it works.
I suspect it currently returns a float! :) What do you want it to do?
Unfortunately, giving it any special behavior reduces the value of the
class as an example of falling back to floats, but that shouldn't
necessarily stop us from making it do the right thing.

> * When in doubt, keep the API minimal so we don't lock-in design mistakes.

Absolutely!

> * Test the API by taking a few numerical algorithms and seeing how well
> they work with rational inputs (for starters, try
> http://docs.python.org/lib/decimal-recipes.html ).

Good idea. I'll add some of those to the test suite.

> * If you do put in a method that accepts floats, make sure that it can
> accept arguments to control the rational approximation.  Ideally, you
> would get something something like this Rational.approximate(math.pi, 6)
> --> 355/113 that could produce the smallest rationalal approximation to
> a given level of accuracy.

Right. My initial plan was to use
Rational.from_float(math.pi).simplest_fraction_within(Rational(1,
10**6)) but I'm not set on that, and, because there are several
choices for the approximation method, I'm skeptical whether it should
go into the initial revision at all.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1780] Decimal constructor accepts newline terminated strings

[Mark Dickinson]

Mark Dickinson added the comment:

Okay:  in that case, I propose:
(1) adding a to_number method to the Decimal and Context class, so that 
we're still in full compliance with the specification, and
(2) altering Decimal.__new__ to allow trailing and leading whitespace.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1780] Decimal constructor accepts newline terminated strings

[Mark Dickinson]

Mark Dickinson added the comment:

Aargh!  It's only the Context class that needs a to_number method---it 
makes no sense as a Decimal method.  And to_number is almost already 
there, in the form of Context.create_decimal.

I'll work out exactly what the minimum is that needs to be done to 
comply with the specification, and post a patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1720992] automatic imports

[Christian Heimes]

Christian Heimes added the comment:

The idea is against the basic principals and Zen Of Python (type "import
this at the Python prompt to read more about the Zen Of Python).

Ralf's link about autoimp is a nice solution but don't ever use it in
real code!

--
nosy: +tiran
resolution:  -> wont fix
status: open -> closed

_
Tracker <[EMAIL PROTECTED]>

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

[issue1448325] re search infinite loop

[Christian Heimes]

Christian Heimes added the comment:

Duplicate and partly fixed

--
nosy: +tiran
resolution:  -> duplicate
status: open -> closed
superseder:  -> Check for signals during regular expression matches

_
Tracker <[EMAIL PROTECTED]>

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

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

[Raymond Hettinger]

Raymond Hettinger added the comment:

> Decimal.from_rational(Rat(1, 3)) wouldn't be lossless

It should be implemented as Decimal(1)/Decimal(3) and then let the
context handle any inexactness.

> Rational.from_decimal is easier than from_float.

Yes.  Just use Decimal.as_tuple() to get the integer components.

> Then Decimal.from_rational() could rely on just numbers.
> Rational, so it would be independent of this module. 
>Is that a method you'd want on Decimal anyway? 

Instead, just expand the decimal constructor to accept a rational input.

> Regarding float->rational, I propose to refuse Rational(1.1)
> for the same reasons as Decimal(1.1) is refused,

+1 

> but to add a separate constructor (a class method?) that 
> converts a float to a rational exactly (as long as it 
> isn't nan or inf), large denominators be damned. This 
> can help people who are interested in taking floating
> point numbers apart. 

Here's how to pick the integer components out of a float:

   mant, exp = math.frexp(x)
   mant, exp = int(mant * 2.0 ** 53), exp-53


>> * Likewise, follow decimal's lead in avoiding all 
>> automatic coercions from floats:  
>>Rational(3,10) + 0.3 for example.  The two don't mix.

> I'm reluctant to remove the fallback to float,

You will need some plan to scale-down long integers than exceed the
range of floats (right shifting the numerator and denominator until they
fit).

__
Tracker <[EMAIL PROTECTED]>

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

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

[Raymond Hettinger]

Raymond Hettinger added the comment:

One other thought, the Decimal and Rational constructors can be made to
talk to each other via a magic method so that neither has to import the
other (somewhat like we do now with __int__ and __float__).

__
Tracker <[EMAIL PROTECTED]>

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

[issue1781] ConfigParser: add_section('DEFAULT') causes duplicate sections.

[Tim Lesher]

New submission from Tim Lesher:

ConfigParser doesn't prevent "manually" adding a section named DEFAULT;
however, doing so creates a duplicate, inaccessible [DEFAULT] section in
the config file:

>>> import sys, ConfigParser
>>> c = ConfigParser.ConfigParser()
>>> c.add_section('DEFAULT')
>>> c.write(sys.stdout)
[DEFAULT]

>>> c.set('DEFAULT', 'color', 'yellow')
>>> c.write(sys.stdout)
[DEFAULT]
color = yellow

[DEFAULT]


It seems that the correct thing to do would be to disallow
add_section('DEFAULT').

--
components: Library (Lib)
messages: 59652
nosy: tlesher
severity: normal
status: open
title: ConfigParser: add_section('DEFAULT') causes duplicate sections.
type: behavior
versions: Python 2.6

__
Tracker <[EMAIL PROTECTED]>

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

[issue1781] ConfigParser: add_section('DEFAULT') causes duplicate sections.

[Guido van Rossum]

Guido van Rossum added the comment:

Care to provide a patch?

Otherwise this may be a good bug day candidate.  The next one's Jan 19.

--
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

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

[issue1780] Decimal constructor accepts newline terminated strings

[Mark Dickinson]

Mark Dickinson added the comment:

In the spirit of making the Decimal constructor match the rest of the language, 
can I propose another change:  make Decimal("not a decimal") raise a 
ValueError.

Currently, Decimal("not a decimal") either raises InvalidOperation or returns a 
Decimal NaN, depending on whether the InvalidOperation trap is set in the 
current context or not.  This behaviour presumably again comes directly from 
the specification, but as pointed out already Decimal.__new__ doesn't need to 
rigidly follow the specification---we just need to make sure that the 
functionality of to-number is present somewhere (and create_decimal seems like 
a good candidate for that).  It seems to me that:

Decimal.__new__ shouldn't care about the current context.

The fact that __new__ takes a context parameter at the moment is potentially 
confusing:  one might reasonably expect that passing a context to __new__ would 
result in the Decimal being rounded to fit that context (as happens with 
create_decimal).  In fact, the *only* reason the context argument is there 
because it's needed to raise InvalidOperation;  if the first argument to 
__new__ is valid then the context is entirely unused.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1780] Decimal constructor accepts newline terminated strings

[Raymond Hettinger]

Raymond Hettinger added the comment:

I think the decimal exceptions should continue to be raised as-is. 
There is a well-defined and thought-out structure for the Decimal
exceptions.  Also, the constructor's exceptions tend to be raised in an
environment where there are other decimal operations taking place -- it
would be a shame to have to catch both types of exception.

I spent about a month working on this module and put a decent amount of
thought into integrating the API.  I would prefer to not revisit all of
those decisions one at a time.

Instead, let's graft on any new magic methods and fix straight-out bugs.  

Having lots of little microscopic API changes will harm more than it
will help.  Why introduce incompatabilities for no gain.

I'm inclined to dismiss this whole bug report.  It doesn't help anything
to muck with the existing choices about whitespace handling.  Recommend
closing this as yagni / don't-care.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

[Mark Dickinson]

Mark Dickinson added the comment:

Allowing automatic coercion to and from Decimal sounds dangerous and 
complicated to me.  Mightn't it be safer just to disallow this (at least for 
now)?

I think something like trim()  (find the closest rational approximation with 
denominator bounded by a given integer) would be useful to have as a Rational 
method, but probably only for explicit use.

I'm still worried about equality tests:  is it possible to give a good reason 
why Decimal("2.5") == Rational(5, 2) should return False, while Rational(5, 2) 
== 2.5 returns True.  Can someone articulate some workable principle that 
dictates when an int/float/complex/Rational/Decimal instance compares equal to 
some other int/float/complex/Rational/Decimal instance of possibly different 
type but the same numerical value?

__
Tracker <[EMAIL PROTECTED]>

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

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

[Guido van Rossum]

Guido van Rossum added the comment:

All in all, Decimal is the odd man out -- it may never become a full
member of the Real ABC. The built-in types complex, float and int (and
long in 2.x) all support mixed-mode arithmetic, and this is one of the
assumptions of the numeric tower -- and of course of mathematics. The
new Rational type can be designed to fit in this system pretty easily,
because it has no pre-existing constraints; but the Decimal type
defies coercion, and is perhaps best left alone. It's already breaking
the commonly understood properties of equality, e.g. 1.0 == 1 ==
Decimal("1") != 1.0.

--Guido

On Jan 9, 2008 7:51 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
>
> Mark Dickinson added the comment:
>
> Allowing automatic coercion to and from Decimal sounds dangerous and
> complicated to me.  Mightn't it be safer just to disallow this (at least for
> now)?
>
> I think something like trim()  (find the closest rational approximation with
> denominator bounded by a given integer) would be useful to have as a Rational
> method, but probably only for explicit use.
>
> I'm still worried about equality tests:  is it possible to give a good reason
> why Decimal("2.5") == Rational(5, 2) should return False, while Rational(5, 2)
> == 2.5 returns True.  Can someone articulate some workable principle that
> dictates when an int/float/complex/Rational/Decimal instance compares equal to
> some other int/float/complex/Rational/Decimal instance of possibly different
> type but the same numerical value?
>
>
> __
> Tracker <[EMAIL PROTECTED]>
> 
> __
>

__
Tracker <[EMAIL PROTECTED]>

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

[issue1720992] automatic imports

[Juan Manuel Borges Caño]

Juan Manuel Borges Caño added the comment:

Thank you for the link.

I think this bug is already closed.

_
Tracker <[EMAIL PROTECTED]>

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

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

[Raymond Hettinger]

Raymond Hettinger added the comment:

Would it be reasonable then to not have any of the numeric tower stuff 
put in the decimal module -- basically leave it alone (no __ceil__, 
etc)?

__
Tracker <[EMAIL PROTECTED]>

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