From tarka@zip.com.au  Wed Mar  1 00:15:46 2000
From: tarka@zip.com.au (tarka@zip.com.au)
Date: Tue, 29 Feb 2000 19:15:46 -0500 (EST)
Subject: [Python-bugs-list] urllib.py fails with username/password proxies (PR#221)
Message-ID: <20000301001546.4E1DC1CD4C@dinsdale.python.org>

Full_Name: Steve Smith
Version: 1.5.2
OS: Irix
Submission from: proxy2.csc.com.au (202.10.5.198)


urllib.py fails to handle proxies with user and password information 
included in the proxy URL, e.g. http://ssmith:testpass@10.11.12.13:1234

The following example ...

	import os, urllib
	os.environ['http_proxy'] = "http://ssmith:testpass01@10.11.12.13:1234"
	f = urllib.urlopen('http://www.python.org')
	data = f.read()
	print data

fails with the following errors :

Traceback (innermost last):
  File "url.py", line 3, in ?
    f = urllib.urlopen('http://www.python.org')
  File "/var/share//lib/python1.5/urllib.py", line 59, in urlopen
    return _urlopener.open(url)
  File "/var/share//lib/python1.5/urllib.py", line 157, in open
    return getattr(self, name)(url)
  File "/var/share//lib/python1.5/urllib.py", line 253, in open_http
    h = httplib.HTTP(host)
  File "/var/share//lib/python1.5/httplib.py", line 51, in __init__
    if host: self.connect(host, port)
  File "/var/share//lib/python1.5/httplib.py", line 75, in connect
    raise socket.error, "nonnumeric port"
IOError: [Errno socket error] nonnumeric port







From guido@python.org  Wed Mar  1 14:20:00 2000
From: guido@python.org (guido@python.org)
Date: Wed,  1 Mar 2000 09:20:00 -0500 (EST)
Subject: [Python-bugs-list] IDLE and -t (PR#213)
Message-ID: <20000301142000.EA1331CE35@dinsdale.python.org>

Randall,

Thanks for your enlightenment.  I looked at your example, and it
works; but I need more, because IDLE creates windows using Toplevel(),
not using Tk().  (Using Tk() would create a new Tcl interpreter for
each window, which wastes time and memory resources, and re-reads the
~/.<whatever>.py file each time.)

I've experimented with xprop a bit, and I'm not getting results I
like.  If I write root = Tk(className="foo"), WM_CLASS is "foo",
"Foo".  Them if I write top = Toplevel(root), WM_CLASS for that window
is "1234567", "Toplevel".  If I try top = Toplevel(root, name="bar"),
I get "bar", "Toplevel".  Shouldn't I be able to set the second
component of WM_CLASS somehow?

Got any ideas?

If you can send me a patch, that would be greatly appreciated!

--Guido van Rossum (home page: http://www.python.org/~guido/)




From david_albeck@dragonsys.com  Thu Mar  2 17:42:27 2000
From: david_albeck@dragonsys.com (david_albeck@dragonsys.com)
Date: Thu,  2 Mar 2000 12:42:27 -0500 (EST)
Subject: [Python-bugs-list] Py_IsInitialized() crash: "no current thread" (PR#222)
Message-ID: <20000302174227.CAB601CD5F@dinsdale.python.org>

Full_Name: David B. Albeck
Version: 1.5.2
OS: Windows NT
Submission from: pluto.dragonsys.com (204.165.63.1)


Py_IsInitialized() crashes if Python is not initialized!

I am running Python embedded in a simple test program written in C++.  
Before making any other Python calls (notably, before calling Py_Initialize()),
it calls Py_IsInitialized().
That crashes with the message:
Fatal Python error: PyThreadState_Get: no current thread

Replacing Py_IsInitialized() with my own function (using a static variable)is my
workaround.

If, after making sure I've already called Py_Initialize(), I then call
Py_IsInitialized(), Py_IsInitialized() works fine (returns True).





From guido@python.org  Thu Mar  2 17:53:33 2000
From: guido@python.org (guido@python.org)
Date: Thu,  2 Mar 2000 12:53:33 -0500 (EST)
Subject: [Python-bugs-list] Py_IsInitialized() crash: "no current thread" (PR#222)
Message-ID: <20000302175333.577581CD5F@dinsdale.python.org>

> Py_IsInitialized() crashes if Python is not initialized!
> 
> I am running Python embedded in a simple test program written in C++.  
> Before making any other Python calls (notably, before calling Py_Initialize()),
> it calls Py_IsInitialized().
> That crashes with the message:
> Fatal Python error: PyThreadState_Get: no current thread
> 
> Replacing Py_IsInitialized() with my own function (using a static variable)is my
> workaround.
> 
> If, after making sure I've already called Py_Initialize(), I then call
> Py_IsInitialized(), Py_IsInitialized() works fine (returns True).

Given the source code for Py_IsInitialized(), I find it hard to
believe that Py_IsInitialized() causes a fatal error.

int
Py_IsInitialized()
{
	return initialized;
}


Please investigate further; could there be another call that your code
makes?

--Guido van Rossum (home page: http://www.python.org/~guido/)




From David_Albeck@Dragonsys.com  Thu Mar  2 19:51:33 2000
From: David_Albeck@Dragonsys.com (David_Albeck@Dragonsys.com)
Date: Thu,  2 Mar 2000 14:51:33 -0500 (EST)
Subject: [Python-bugs-list] Py_IsInitialized() crash: "no current (PR#223)
Message-ID: <20000302195133.AFD751CD78@dinsdale.python.org>

---------------------- Forwarded by David Albeck/Dragon Systems USA on
03/02/2000 02:51 PM ---------------------------


David Albeck
03/02/2000 02:42 PM

To:   Guido van Rossum <guido@python.org>
cc:
Subject:  Re: [Python-bugs-list] Py_IsInitialized() crash: "no current thread"
      (PR#222)  (Document link: David Albeck)

I was also using an error-catching macro which called PyErr_Occurred()... THAT
was crashing when I used it to check on Py_IsInitialized()!

               ---Dave "facial omelette" Albeck



Guido van Rossum <guido@python.org> on 03/02/2000 12:55:20 PM

To:   David Albeck/Dragon Systems USA@Dragon Systems USA
cc:   bugs-py@python.org
Subject:  Re: [Python-bugs-list] Py_IsInitialized() crash: "no current thread"
      (PR#222)



> Py_IsInitialized() crashes if Python is not initialized!
>
> I am running Python embedded in a simple test program written in C++.
> Before making any other Python calls (notably, before calling
Py_Initialize()),
> it calls Py_IsInitialized().
> That crashes with the message:
> Fatal Python error: PyThreadState_Get: no current thread
>
> Replacing Py_IsInitialized() with my own function (using a static variable)is
my
> workaround.
>
> If, after making sure I've already called Py_Initialize(), I then call
> Py_IsInitialized(), Py_IsInitialized() works fine (returns True).

Given the source code for Py_IsInitialized(), I find it hard to
believe that Py_IsInitialized() causes a fatal error.

int
Py_IsInitialized()
{
     return initialized;
}


Please investigate further; could there be another call that your code
makes?

--Guido van Rossum (home page: http://www.python.org/~guido/)










From guido@python.org  Thu Mar  2 21:02:20 2000
From: guido@python.org (guido@python.org)
Date: Thu,  2 Mar 2000 16:02:20 -0500 (EST)
Subject: [Python-bugs-list] Py_IsInitialized() crash: "no current thread" (PR#222)
Message-ID: <20000302210220.E1D121CD86@dinsdale.python.org>

So there.
------- Forwarded Message

Date:    Thu, 02 Mar 2000 14:42:29 -0500
From:    David_Albeck@Dragonsys.com
To:      Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] Py_IsInitialized() crash: "no current thread" (
	  PR#222)

I was also using an error-catching macro which called PyErr_Occurred()... THAT
was crashing when I used it to check on Py_IsInitialized()!

               ---Dave "facial omelette" Albeck




Guido van Rossum <guido@python.org> on 03/02/2000 12:55:20 PM

To:   David Albeck/Dragon Systems USA@Dragon Systems USA
cc:   bugs-py@python.org
Subject:  Re: [Python-bugs-list] Py_IsInitialized() crash: "no current thread"
      (PR#222)



> Py_IsInitialized() crashes if Python is not initialized!
>
> I am running Python embedded in a simple test program written in C++.
> Before making any other Python calls (notably, before calling
Py_Initialize()),
> it calls Py_IsInitialized().
> That crashes with the message:
> Fatal Python error: PyThreadState_Get: no current thread
>
> Replacing Py_IsInitialized() with my own function (using a static variable)is
my
> workaround.
>
> If, after making sure I've already called Py_Initialize(), I then call
> Py_IsInitialized(), Py_IsInitialized() works fine (returns True).

Given the source code for Py_IsInitialized(), I find it hard to
believe that Py_IsInitialized() causes a fatal error.

int
Py_IsInitialized()
{
     return initialized;
}


Please investigate further; could there be another call that your code
makes?

- --Guido van Rossum (home page: http://www.python.org/~guido/)





------- End of Forwarded Message





From flight@mathi.uni-heidelberg.de  Sat Mar  4 20:01:18 2000
From: flight@mathi.uni-heidelberg.de (flight@mathi.uni-heidelberg.de)
Date: Sat,  4 Mar 2000 15:01:18 -0500 (EST)
Subject: [Python-bugs-list] configure problem: libieee with Linux/glibc2 ? (PR#224)
Message-ID: <20000304200118.564281CD98@dinsdale.python.org>

--zYM0uCDKw75PZbzx
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

I think Python 1.5.2's configure script is to fast with including -lieee in=
 LIBS.


I would suggest the following change to configure.in:

@@ -850,7 +856,10 @@
 # (none yet)
=20
 # Linux requires this for correct f.p. operations
-AC_CHECK_LIB(ieee, __fpu_control)
+AC_CHECK_FUNC(__fpu_control,
+  [],
+  [AC_CHECK_LIB(ieee, __fpu_control)
+])
=20
 # Check for --with-fpectl
 AC_MSG_CHECKING(for --with-fpectl)


This mean, libieee will only by tried if __fpu_control isn't found elsewhere
(i.e. in libc).=20
=20

With glibc 2.x, Linux doesn't need libieee anymore (it's still there for
compilation of legacy applications, but it's an empty static library), since
__fpu_control() is already defined in the libc library.



Furthermore, __fpu_control() is only used in fpectlmodule which currently
doesn't build with glibc 2.1 anyway due to the absence of __setfpucw (see
manpage below).

Does anybody know how to fix fpectlmodule for glibc 2.1 ? How does
__setfpucw(0x1372) translate into the _FPU_SETCW language ?

    Gregor
   =20


NAME
       __setfpucw  -  set  fpu  control word on i386 architecture
       (obsolete)

SYNOPSIS
       #include <i386/fpu_control.h>

       void __setfpucw((unsigned short) control_word);

DESCRIPTION
       __setfpucw transfer control_word to the registers  of  the
       fpu  (floating  point unit) on i386 architecture. This was
       used to control floating  point  precision,  rounding  and
       floating point exceptions.

AVAILABILITY
       As  of  glibc 2.1 (libc6 2.1) this function does not exist
       anymore. There are new functions from ISO C 9x to  control
       fpu  rounding  modes. These functions don't have manpages,
       but are documented in the info docs.

       If direct acces to the FPU control word is  still  needed,
       the     _FPU_GETCW     and    _FPU_SETCW    macros    from
       /usr/include/fpu_control.h can be used.
      =20

--zYM0uCDKw75PZbzx
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4wWfQ3eVfDf25G40RAel1AKC+sA67Wy2fzav4T0fAYd84PXT4rQCdGXdr
j9s6W3nqetjTtWGLg1g7C0Y=
=Y40q
-----END PGP SIGNATURE-----

--zYM0uCDKw75PZbzx--




From aa8vb@yahoo.com  Mon Mar  6 13:48:35 2000
From: aa8vb@yahoo.com (aa8vb@yahoo.com)
Date: Mon,  6 Mar 2000 08:48:35 -0500 (EST)
Subject: [Python-bugs-list] IDLE and -t (PR#213)
Message-ID: <20000306134835.186CF1CD4A@dinsdale.python.org>

--MGYHOYXEY6WxJCY8
Content-Type: text/plain; charset=us-ascii

Guido van Rossum:
 |Thanks for your enlightenment.  I looked at your example, and it
 |works; but I need more, because IDLE creates windows using Toplevel(),
 |not using Tk().  (Using Tk() would create a new Tcl interpreter for
 |each window, which wastes time and memory resources, and re-reads the
 |~/.<whatever>.py file each time.)
 |
 |I've experimented with xprop a bit, and I'm not getting results I
 |like.  If I write root = Tk(className="foo"), WM_CLASS is "foo",
 |"Foo".  Them if I write top = Toplevel(root), WM_CLASS for that window
 |is "1234567", "Toplevel".  If I try top = Toplevel(root, name="bar"),
 |I get "bar", "Toplevel".  Shouldn't I be able to set the second
 |component of WM_CLASS somehow?
 |
 |Got any ideas?

Sorry about that last message.  This issue is very closely related to the
resource loading issue on idle-dev, but not the same.  Once the small
change below is in-place (to solve this problem), the platform-independent
Tkinter methods for resource loading can be used to solve the idle-dev
problem, if desired.

Research indicates that the Tk-ism for setting Toplevel classes is:

      "toplevel .mytop -class classname"

So the Tkinter syntax is:

      top1   = Toplevel( root, class_=classname )

The attached test app demonstrates this.  I verified that I am able to set
X resources for these windows using the class name "Idle".

-- 
Randall Hopper
aa8vb@yahoo.com

--MGYHOYXEY6WxJCY8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="tk_class.py"

from Tkinter import *

CLASSNAME = "Idle"

root = Tk( className=CLASSNAME )
root.wm_withdraw()

# A toplevel with a WM_CLASS
top1   = Toplevel( root, class_=CLASSNAME )
label1 = Label( top1, text="Toplevel 1" )
label1.pack()

# Another one
top2   = Toplevel( root, class_=CLASSNAME )
label2 = Label( top2, text="Toplevel 2" )
label2.pack()

root.mainloop()

--MGYHOYXEY6WxJCY8--




From guido@python.org  Mon Mar  6 14:09:47 2000
From: guido@python.org (guido@python.org)
Date: Mon,  6 Mar 2000 09:09:47 -0500 (EST)
Subject: [Python-bugs-list] IDLE and -t (PR#213)
Message-ID: <20000306140947.308EF1CD57@dinsdale.python.org>

> Sorry about that last message.  This issue is very closely related to the
> resource loading issue on idle-dev, but not the same.  Once the small
> change below is in-place (to solve this problem), the platform-independent
> Tkinter methods for resource loading can be used to solve the idle-dev
> problem, if desired.

See my response in idle-dev :-)

Of course the Tk options can still be used for changing things that
the config file or prefs dialog doesn't support.

> Research indicates that the Tk-ism for setting Toplevel classes is:
> 
>       "toplevel .mytop -class classname"
> 
> So the Tkinter syntax is:
> 
>       top1   = Toplevel( root, class_=classname )
> 
> The attached test app demonstrates this.  I verified that I am able to set
> X resources for these windows using the class name "Idle".

OK, I'll try to support this!

--Guido van Rossum (home page: http://www.python.org/~guido/)




From wam-pythonbug@wamber.net  Tue Mar  7 19:28:34 2000
From: wam-pythonbug@wamber.net (wam-pythonbug@wamber.net)
Date: Tue,  7 Mar 2000 14:28:34 -0500 (EST)
Subject: [Python-bugs-list] readline bug/missing feature : rl_completer_word_break_characters (PR#225)
Message-ID: <20000307192834.24D881CDCD@dinsdale.python.org>

Full_Name: William McVey
Version: 1.5.2 
OS: Linux RH6.1
Submission from: dhcp-aus-163-101.cisco.com (171.69.163.101)


The readline module of python 1.5.2 seems to have a hardcoded definition
of rl_completer_word_break_characters (Modules/readline.c line 245).
This is great when using tab completion for Python variables; however,
I would like to use tab completion in my interactive application (a
subclass of Cmd) with different word boundaries.  It appears as if 
there is no way to reset rl_completer_word_break_characters, since it
is not exported to the python class and is not a variable that can
be controlled via init variables.  By hardcoding the word break variable 
to just the word break characters of the python language itself, the 
module maintainers keep the tab completion facility of the readline 
module from being a generic facility.

I am still a python novice and am unable to provide a patch for this 
bug.  It should be a straightforward change though to export 
rl_completer_word_break_characters (ideally, all the usefull variables 
available in the readline library) to python so subclasses can override
the default values.




From guido@python.org  Tue Mar  7 19:34:30 2000
From: guido@python.org (guido@python.org)
Date: Tue,  7 Mar 2000 14:34:30 -0500 (EST)
Subject: [Python-bugs-list] readline bug/missing feature : rl_completer_word_break_characters (PR#225)
Message-ID: <20000307193430.726901CDE1@dinsdale.python.org>

Thank you for your bug report.

I climbed in my time machine and fixed it retroactively.  As of 18
November 1999, this has been fixed in the CVS repository.  Check out
readlinemodule.c rev 2.15. :-)

"""
Patches by Kannan Vijayan:

new:
readline.get_begidx() -> int
	gets the beginning index in the command line string
	delimiting the tab-completion scope.  This would
	probably be used from within a tab-completion
	handler

readline.get_endidx() -> int
	gets the ending index in the command line string
	delimiting the tab-completion scope.  This would
	probably be used from within a tab-compeltion
	handler

readline.set_completer_delims(string) -> None
	sets the delimiters used by readline as word breakpoints
	for tab-completion

readline.get_completer_delims() -> string
	gets the delimiters used by readline as word breakpoints
	for tab-completion

fixed:
readline.get_line_buffer() -> string
	doesnt cause a debug message every other call
"""

See www.python.org/download/cvs.html for information on the CVS
repository.

--Guido van Rossum (home page: http://www.python.org/~guido/)




From guido@python.org  Tue Mar  7 19:36:24 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 07 Mar 2000 14:36:24 -0500
Subject: [Python-bugs-list] readline bug/missing feature : rl_completer_word_break_characters (PR#225)
In-Reply-To: Your message of "Tue, 07 Mar 2000 14:28:34 EST."
 <20000307192834.24D881CDCD@dinsdale.python.org>
References: <20000307192834.24D881CDCD@dinsdale.python.org>
Message-ID: <200003071936.OAA15526@eric.cnri.reston.va.us>

Thank you for your bug report.

I climbed in my time machine and fixed it retroactively.  As of 18
November 1999, this has been fixed in the CVS repository.  Check out
readlinemodule.c rev 2.15. :-)

"""
Patches by Kannan Vijayan:

new:
readline.get_begidx() -> int
	gets the beginning index in the command line string
	delimiting the tab-completion scope.  This would
	probably be used from within a tab-completion
	handler

readline.get_endidx() -> int
	gets the ending index in the command line string
	delimiting the tab-completion scope.  This would
	probably be used from within a tab-compeltion
	handler

readline.set_completer_delims(string) -> None
	sets the delimiters used by readline as word breakpoints
	for tab-completion

readline.get_completer_delims() -> string
	gets the delimiters used by readline as word breakpoints
	for tab-completion

fixed:
readline.get_line_buffer() -> string
	doesnt cause a debug message every other call
"""

See www.python.org/download/cvs.html for information on the CVS
repository.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From smceligot@iname.com  Wed Mar  8 05:18:18 2000
From: smceligot@iname.com (smceligot@iname.com)
Date: Wed,  8 Mar 2000 00:18:18 -0500 (EST)
Subject: [Python-bugs-list] duplicate form elements crashes cgi.py (PR#226)
Message-ID: <20000308051818.999781CD26@dinsdale.python.org>

Full_Name: Sean McEligot
Version: 1.5.2
OS: Linux
Submission from: adsl-141-156-43-178.bellatlantic.net (141.156.43.178)


For example, try:
http://www.python.org/cgi-bin/faqw.py?req=home&req=home

cgi.FieldStorage()['req'] returns a dictionary of all the form fields instead 
of a FieldStorage object. cgi.FieldStorage().value then raises an
AttributeError.








From guido@python.org  Wed Mar  8 12:35:06 2000
From: guido@python.org (Guido van Rossum)
Date: Wed, 08 Mar 2000 07:35:06 -0500
Subject: [Python-bugs-list] duplicate form elements crashes cgi.py (PR#226)
In-Reply-To: Your message of "Wed, 08 Mar 2000 00:18:18 EST."
 <20000308051818.999781CD26@dinsdale.python.org>
References: <20000308051818.999781CD26@dinsdale.python.org>
Message-ID: <200003081235.HAA19964@eric.cnri.reston.va.us>

> For example, try:
> http://www.python.org/cgi-bin/faqw.py?req=home&req=home
> 
> cgi.FieldStorage()['req'] returns a dictionary of all the form fields instead 
> of a FieldStorage object. cgi.FieldStorage().value then raises an
> AttributeError.

Read the docs for cgi.py.  If you write forms that do this, you have
to inspect the objects you get back to determine if there's a list or
not.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From guido@python.org  Wed Mar  8 12:33:13 2000
From: guido@python.org (guido@python.org)
Date: Wed,  8 Mar 2000 07:33:13 -0500 (EST)
Subject: [Python-bugs-list] duplicate form elements crashes cgi.py (PR#226)
Message-ID: <20000308123313.444081CD15@dinsdale.python.org>

> For example, try:
> http://www.python.org/cgi-bin/faqw.py?req=home&req=home
> 
> cgi.FieldStorage()['req'] returns a dictionary of all the form fields instead 
> of a FieldStorage object. cgi.FieldStorage().value then raises an
> AttributeError.

Read the docs for cgi.py.  If you write forms that do this, you have
to inspect the objects you get back to determine if there's a list or
not.

--Guido van Rossum (home page: http://www.python.org/~guido/)




From info@vaccari.it  Wed Mar  8 17:52:46 2000
From: info@vaccari.it (info@vaccari.it)
Date: Wed,  8 Mar 2000 12:52:46 -0500 (EST)
Subject: [Python-bugs-list] VACCARI News (PR#227)
Message-ID: <20000308175246.C99061CD7D@dinsdale.python.org>



========================================
   VACCARI Philately-Books NewsLetter
========================================



Dear Collector,


a new VACCARI AUCTION is online.

Direct address to auction is
http://www.vaccari.it/_1_filatelia/cataloghi/cat61/cat61.htm

Please visit our site
http://www.vaccari.it

*** MILANOFIL Philatelic Exhibition will be held in Milano, Italy
from 10 to 12 March, 2000. More info at
http://www.vaccari.it/_1_filatelia/altro/esposint/milanofil2000/milanofil2000.htm



Enjoy your time!

Kind regards.



Valeria Vaccari





****************************************
If you don’t want be in this mailing list please reply to this email
with "REMOVE" as first word of Subject.






--------------------------------------------------------------------------------




Gentile Collezionista,


la nuova ASTA VACCARI e' online.

L'indirizzo diretto all'asta e'
http://www.vaccari.it/_1_filatelia/cataloghi/cat61/cat61.htm

La invitiamo inoltre a visitare il nostro sito
http://www.vaccari.it

*** MILANOFIL Esposizione Filatelica dal 10 al 12 marzo 2000.
http://www.vaccari.it/_1_filatelia/altro/esposint/milanofil2000/milanofil2000.htm



Con i migliori saluti.



Valeria Vaccari





****************************************
I dati in possesso di Vaccari srl sono trattati nel rispetto
della legge 675/96 sulla tutela dei dati personali e saranno utilizzati
al fine di aggiornarLa su prodotti, iniziative ed offerte di Vaccari
srl.

Qualora non desideri ricevere ulteriori comunicazioni, risponda a
questa email scrivendo "REMOVE" nel Subject del messaggio.








VACCARI srl
Filatelia - Editoria
via M. Buonarroti, 46
41058 Vignola (MO) - Italy

Tel. ++39 - 059 764106 editoria/books -  059 771251 filatelia/philately
Fax ++39- 059 760157
http://www.vaccari.it  - email info@vaccari.it








From dean@dragonsys.com  Wed Mar  8 20:36:01 2000
From: dean@dragonsys.com (dean@dragonsys.com)
Date: Wed,  8 Mar 2000 15:36:01 -0500 (EST)
Subject: [Python-bugs-list] configure script fails with cross-compiler (PR#228)
Message-ID: <20000308203601.A218A1CD3C@dinsdale.python.org>

Full_Name: Dean Sturtevant
Version: 1.5.2
OS: Linux
Submission from: pluto.dragonsys.com (204.165.63.1)


I was trying to build python with a cross-compiler, so I put my cross-compiler
bin directory in the front of my path and executed the configure script. The
fact that a cross-compiler was being used was detected correctly, causing it to
fail later on at line 1922:
    { echo "configure: error: can not run test program while cross compiling"
1>&2; exit 1; }

This is a bug in configure, isn't it?






From guido@python.org  Thu Mar  9 03:18:18 2000
From: guido@python.org (guido@python.org)
Date: Wed,  8 Mar 2000 22:18:18 -0500 (EST)
Subject: [Python-bugs-list] configure script fails with cross-compiler (PR#228)
Message-ID: <20000309031818.C89C61CDA9@dinsdale.python.org>

> I was trying to build python with a cross-compiler, so I put my cross-compiler
> bin directory in the front of my path and executed the configure script. The
> fact that a cross-compiler was being used was detected correctly, causing it to
> fail later on at line 1922:
>     { echo "configure: error: can not run test program while cross compiling"
> 1>&2; exit 1; }
> 
> This is a bug in configure, isn't it?

Depends on your point of view.  It's a restriction that the configure
doesn't work with a cross compiler, because there are a bunch of tests
for which it needs to run code to determine the outcome.

If you want to contribute patches to configure.in to supply defaults
(I think there are 6-8 cases) that would be approciated.  See
python.org/patches/.

Cheers,

--Guido van Rossum (home page: http://www.python.org/~guido/)




From aa8vb@yahoo.com  Thu Mar  9 13:57:51 2000
From: aa8vb@yahoo.com (aa8vb@yahoo.com)
Date: Thu,  9 Mar 2000 08:57:51 -0500 (EST)
Subject: [Python-bugs-list] Tkinter Optionmenu doesn't accept 'font' resource (PR#229)
Message-ID: <20000309135751.113471CDF2@dinsdale.python.org>

Full_Name: Randall Hopper
Version: 1.5.2
OS: IRIX 6.5
Submission from: ralph.rtpnc.epa.gov (134.67.66.44)


    menu = apply( OptionMenu, ( parent, var ) + tuple( option_names ),
                  { 'font':PANEL_FONT } )

generates:

    TypeError: unexpected keyword argument: font

It would be helpful if the 'font' resource were accepted and used to create the
menubutton and child command widgets.

In its absense, folks need to poke at the internals of OptionMenu (obviously
not a good idea) or establish a parent frame for each option menu with a 
unique name and use option_add to stuff *Class*Font: resources into the Tk
resource database.

If the 'font' option were supported, it would simplify this greatly.

Thanks,

Randall




From guido@python.org  Thu Mar  9 15:45:55 2000
From: guido@python.org (Guido van Rossum)
Date: Thu, 09 Mar 2000 10:45:55 -0500
Subject: [Python-bugs-list] Tkinter Optionmenu doesn't accept 'font' resource (PR#229)
In-Reply-To: Your message of "Thu, 09 Mar 2000 08:57:51 EST."
 <20000309135751.113471CDF2@dinsdale.python.org>
References: <20000309135751.113471CDF2@dinsdale.python.org>
Message-ID: <200003091545.KAA21862@eric.cnri.reston.va.us>

> It would be helpful if the 'font' resource were accepted and used to
> create the menubutton and child command widgets.

Unfortunately, the underlying Tk command, tk_optionmenu, doesn't
support this.  Nothing I can do about it.

(See
http://dev.scriptics.com/man/tcl8.3/TkCmd/optionMenu.htm.)

--Guido van Rossum (home page: http://www.python.org/~guido/)


From guido@python.org  Thu Mar  9 15:44:00 2000
From: guido@python.org (guido@python.org)
Date: Thu,  9 Mar 2000 10:44:00 -0500 (EST)
Subject: [Python-bugs-list] Tkinter Optionmenu doesn't accept 'font' resource (PR#229)
Message-ID: <20000309154400.B1CEE1CE04@dinsdale.python.org>

> It would be helpful if the 'font' resource were accepted and used to
> create the menubutton and child command widgets.

Unfortunately, the underlying Tk command, tk_optionmenu, doesn't
support this.  Nothing I can do about it.

(See
http://dev.scriptics.com/man/tcl8.3/TkCmd/optionMenu.htm.)

--Guido van Rossum (home page: http://www.python.org/~guido/)




From ken@basistech.com  Thu Mar  9 15:58:52 2000
From: ken@basistech.com (ken@basistech.com)
Date: Thu,  9 Mar 2000 10:58:52 -0500 (EST)
Subject: [Python-bugs-list] Module re bug.  \b fails (PR#230)
Message-ID: <20000309155852.02AC31CE06@dinsdale.python.org>

Full_Name: Kenneth A. Glidden
Version: 1.5.2
OS: NT 4.0 SP 5
Submission from: dhcp-1-243.basistech.com (199.88.205.243)


\b doesn't seem to work as advertised in the following expression:
re.match( "\bchar\b", "  char " )

This fails to produce a match.
This can be duplicated interactively in python as shown below:

Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import re
>>> print re.match( "\bchar\b", "  char " )
None
>>>

-Ken




From guido@python.org  Thu Mar  9 16:26:19 2000
From: guido@python.org (guido@python.org)
Date: Thu,  9 Mar 2000 11:26:19 -0500 (EST)
Subject: [Python-bugs-list] Module re bug. \b fails (PR#230)
Message-ID: <20000309162619.2EE031CE10@dinsdale.python.org>

> \b doesn't seem to work as advertised in the following expression:
> re.match( "\bchar\b", "  char " )

This is because \b is interpreted as a string literal
escape for backspace, before the regular expression parser gets to see
it.

As the re module docs explain, you should always use r"\bchar\b" to
avoid this kind of problem.

--Guido van Rossum (home page: http://www.python.org/~guido/)





From ken@basistech.com  Thu Mar  9 16:40:39 2000
From: ken@basistech.com (ken@basistech.com)
Date: Thu,  9 Mar 2000 11:40:39 -0500 (EST)
Subject: [Python-bugs-list] Module re bug. \b fails (PR#230)
Message-ID: <20000309164039.7481B1CE1A@dinsdale.python.org>

Thanks for the quick reply.  I did read the docs, your suggestion, and
examples
in "Programming Python" by Mark Lutz (p649)

I still believe it is broken.  See these examples:

----------------------------------------
1) My attempt at your suggestion (FAILS)
----------------------------------------
C:\Projects\Unicode Tutorial\Scripts>python
Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import re
>>> print re.match( r"\bchar\b", "  char " )
None
>>>

----------------------------------------
2) My use of \ without using r (WORKS)
---------------------------------------->>> print re.match( "\s*char\s*", "
char " )
<re.MatchObject instance at 7fe260>

Forgive the missteps of a python newbie.  I did check the docs and have
tried your suggestion.  Am I misinterpreting something concerning proper
syntax?

It still doesn't work.

-Ken

-----Original Message-----
From: Guido van Rossum [mailto:guido@python.org]
Sent: Thursday, March 09, 2000 11:28 AM
To: ken@basistech.com
Cc: bugs-py@python.org
Subject: Re: [Python-bugs-list] Module re bug. \b fails (PR#230)


> \b doesn't seem to work as advertised in the following expression:
> re.match( "\bchar\b", "  char " )

This is because \b is interpreted as a string literal
escape for backspace, before the regular expression parser gets to see
it.

As the re module docs explain, you should always use r"\bchar\b" to
avoid this kind of problem.

--Guido van Rossum (home page: http://www.python.org/~guido/)




From fdrake@acm.org  Thu Mar  9 16:45:07 2000
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Thu, 9 Mar 2000 11:45:07 -0500 (EST)
Subject: [Python-bugs-list] Module re bug. \b fails (PR#230)
In-Reply-To: <20000309162619.2EE031CE10@dinsdale.python.org>
References: <20000309162619.2EE031CE10@dinsdale.python.org>
Message-ID: <14535.54547.653431.520550@weyr.cnri.reston.va.us>

Ken reported:
 > \b doesn't seem to work as advertised in the following expression:
 > re.match( "\bchar\b", "  char " )

guido@python.org writes:
 > This is because \b is interpreted as a string literal
 > escape for backspace, before the regular expression parser gets to see

  I thought about that, but it *still* doesn't work:

>>> import re
>>> print re.match("\bchar\b", "  char ")
None
>>> print re.match(r"\bchar\b", "  char ")
None

  So not only is there a bug in the bug report, but somewhere in pcre
(or the Python binding) as well.


  -Fred

--
Fred L. Drake, Jr.	  <fdrake at acm.org>
Corporation for National Research Initiatives


From fdrake@acm.org  Thu Mar  9 16:43:11 2000
From: fdrake@acm.org (fdrake@acm.org)
Date: Thu,  9 Mar 2000 11:43:11 -0500 (EST)
Subject: [Python-bugs-list] Module re bug. \b fails (PR#230)
Message-ID: <20000309164311.726861CE1C@dinsdale.python.org>

Ken reported:
 > \b doesn't seem to work as advertised in the following expression:
 > re.match( "\bchar\b", "  char " )

guido@python.org writes:
 > This is because \b is interpreted as a string literal
 > escape for backspace, before the regular expression parser gets to see

  I thought about that, but it *still* doesn't work:

>>> import re
>>> print re.match("\bchar\b", "  char ")
None
>>> print re.match(r"\bchar\b", "  char ")
None

  So not only is there a bug in the bug report, but somewhere in pcre
(or the Python binding) as well.


  -Fred

--
Fred L. Drake, Jr.	  <fdrake at acm.org>
Corporation for National Research Initiatives




From ken@basistech.com  Thu Mar  9 16:50:17 2000
From: ken@basistech.com (Ken Glidden)
Date: Thu, 9 Mar 2000 11:50:17 -0500
Subject: [Python-bugs-list] Module re bug. \b fails (PR#230)
Message-ID: <21F87348A4D9D311B4200090276AEBD9036A0B@ginza.basistech.com>

Perhaps there is a bug in the docs, too, since the use of \ in an expression
without using r works:

C:\Projects\Unicode Tutorial\Scripts>python
Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam

>>> import re
>>> print re.match( "\s*char\s*", "  char " )
<re.MatchObject instance at 7fdaf0>

-Ken

-----Original Message-----
From: Fred L. Drake, Jr. [mailto:fdrake@acm.org]
Sent: Thursday, March 09, 2000 11:45 AM
To: guido@python.org; ken@basistech.com
Cc: python-bugs-list@python.org; bugs-py@python.org
Subject: Re: [Python-bugs-list] Module re bug. \b fails (PR#230)



Ken reported:
 > \b doesn't seem to work as advertised in the following expression:
 > re.match( "\bchar\b", "  char " )

guido@python.org writes:
 > This is because \b is interpreted as a string literal
 > escape for backspace, before the regular expression parser gets to see

  I thought about that, but it *still* doesn't work:

>>> import re
>>> print re.match("\bchar\b", "  char ")
None
>>> print re.match(r"\bchar\b", "  char ")
None

  So not only is there a bug in the bug report, but somewhere in pcre
(or the Python binding) as well.


  -Fred

--
Fred L. Drake, Jr.	  <fdrake at acm.org>
Corporation for National Research Initiatives


From ken@basistech.com  Thu Mar  9 16:48:15 2000
From: ken@basistech.com (ken@basistech.com)
Date: Thu,  9 Mar 2000 11:48:15 -0500 (EST)
Subject: [Python-bugs-list] Module re bug. \b fails (PR#230)
Message-ID: <20000309164815.00B841CE1E@dinsdale.python.org>

Perhaps there is a bug in the docs, too, since the use of \ in an expression
without using r works:

C:\Projects\Unicode Tutorial\Scripts>python
Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam

>>> import re
>>> print re.match( "\s*char\s*", "  char " )
<re.MatchObject instance at 7fdaf0>

-Ken

-----Original Message-----
From: Fred L. Drake, Jr. [mailto:fdrake@acm.org]
Sent: Thursday, March 09, 2000 11:45 AM
To: guido@python.org; ken@basistech.com
Cc: python-bugs-list@python.org; bugs-py@python.org
Subject: Re: [Python-bugs-list] Module re bug. \b fails (PR#230)



Ken reported:
 > \b doesn't seem to work as advertised in the following expression:
 > re.match( "\bchar\b", "  char " )

guido@python.org writes:
 > This is because \b is interpreted as a string literal
 > escape for backspace, before the regular expression parser gets to see

  I thought about that, but it *still* doesn't work:

>>> import re
>>> print re.match("\bchar\b", "  char ")
None
>>> print re.match(r"\bchar\b", "  char ")
None

  So not only is there a bug in the bug report, but somewhere in pcre
(or the Python binding) as well.


  -Fred

--
Fred L. Drake, Jr.	  <fdrake at acm.org>
Corporation for National Research Initiatives




From fdrake@acm.org  Thu Mar  9 17:13:17 2000
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Thu, 9 Mar 2000 12:13:17 -0500 (EST)
Subject: [Python-bugs-list] Module re bug. \b fails (PR#230)
In-Reply-To: <21F87348A4D9D311B4200090276AEBD9036A0B@ginza.basistech.com>
References: <21F87348A4D9D311B4200090276AEBD9036A0B@ginza.basistech.com>
Message-ID: <14535.56237.765913.180083@weyr.cnri.reston.va.us>

Ken Glidden writes:
 > Perhaps there is a bug in the docs, too, since the use of \ in an expression
 > without using r works:

  When using "cooked" strings (without the 'r' prefix), what works
depends on the character which follows the '\' character; see the
language reference for details.  This is a "feature" of Python's
string quoting.


  -Fred

--
Fred L. Drake, Jr.	  <fdrake at acm.org>
Corporation for National Research Initiatives


From fdrake@acm.org  Thu Mar  9 17:11:24 2000
From: fdrake@acm.org (fdrake@acm.org)
Date: Thu,  9 Mar 2000 12:11:24 -0500 (EST)
Subject: [Python-bugs-list] Module re bug. \b fails (PR#230)
Message-ID: <20000309171124.39D7F1CE2F@dinsdale.python.org>

Ken Glidden writes:
 > Perhaps there is a bug in the docs, too, since the use of \ in an expression
 > without using r works:

  When using "cooked" strings (without the 'r' prefix), what works
depends on the character which follows the '\' character; see the
language reference for details.  This is a "feature" of Python's
string quoting.


  -Fred

--
Fred L. Drake, Jr.	  <fdrake at acm.org>
Corporation for National Research Initiatives




From guido@python.org  Thu Mar  9 18:01:19 2000
From: guido@python.org (guido@python.org)
Date: Thu,  9 Mar 2000 13:01:19 -0500 (EST)
Subject: [Python-bugs-list] Module re bug. \b fails (PR#230)
Message-ID: <20000309180119.13D821CE20@dinsdale.python.org>

> I still believe it is broken.  See these examples:
> 
> ----------------------------------------
> 1) My attempt at your suggestion (FAILS)
> ----------------------------------------
> C:\Projects\Unicode Tutorial\Scripts>python
> Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>> import re
> >>> print re.match( r"\bchar\b", "  char " )
> None
> >>>
> 
> ----------------------------------------
> 2) My use of \ without using r (WORKS)
> ---------------------------------------->>> print re.match( "\s*char\s*", "
> char " )
> <re.MatchObject instance at 7fe260>
> 
> Forgive the missteps of a python newbie.  I did check the docs and have
> tried your suggestion.  Am I misinterpreting something concerning proper
> syntax?
> 
> It still doesn't work.

Hm, you're right.  Note that \s is not a recognized string escape, so
r"\s" == "\s"; however r"\b" != "\b".

I can't explain why r"x\b" doesn't match "x " though.

I'll ask Andrew.

--Guido van Rossum (home page: http://www.python.org/~guido/)




From guido@python.org  Thu Mar  9 18:11:13 2000
From: guido@python.org (guido@python.org)
Date: Thu,  9 Mar 2000 13:11:13 -0500 (EST)
Subject: [Python-bugs-list] "Andrew M. Kuchling": Re: Module re bug. \b fails (PR#230)
Message-ID: <20000309181113.7EA701CE30@dinsdale.python.org>

Sigh.  I'm embarrassed.

------- Forwarded Message

Date:    Thu, 09 Mar 2000 13:11:38 -0500
From:    "Andrew M. Kuchling" <akuchlin@mems-exchange.org>
To:      Guido van Rossum <guido@python.org>
cc:      fdrake@acm.org, ken@basistech.com
Subject: Re: Module re bug. \b fails (PR#230)

Guido van Rossum writes:
>Ken reported:
> > \b doesn't seem to work as advertised in the following expression:
> > re.match( "\bchar\b", "  char " )
>
>It seems that matching for \b doesn't work properly.  I certainly
>would have expected re.match(r"x\b", " x ") to match, but it returns
>None.

You want re.search(); remember, re.match() requires that the match
begin at the start of the string, so x\b will never match " x ".

- -- 
A.M. Kuchling			http://starship.python.net/crew/amk/
So as this only point among the rest remaineth sure and certain, namely, that
nothing is certain...
    -- Pliny the Elder, the Natural History, tr. Philemon Holland


------- End of Forwarded Message





From bwarsaw@cnri.reston.va.us  Thu Mar  9 18:26:55 2000
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw)
Date: Thu, 9 Mar 2000 13:26:55 -0500 (EST)
Subject: [Python-bugs-list] "Andrew M. Kuchling": Re: Module re bug. \b fails (PR#230)
References: <20000309181113.7EA701CE30@dinsdale.python.org>
Message-ID: <14535.60655.667000.113531@anthem.cnri.reston.va.us>

>>>>> "guido" ==   <guido@python.org> writes:

    guido> Sigh.  I'm embarrassed.

Don't be.  The interface is simply broken and everybody makes the same
mistake (sometimes, like me, over and over again :).  Not that it can
be changed.  :(

-Barry


From bwarsaw@cnri.reston.va.us  Thu Mar  9 18:24:58 2000
From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us)
Date: Thu,  9 Mar 2000 13:24:58 -0500 (EST)
Subject: [Python-bugs-list] "Andrew M. Kuchling": Re: Module re bug. \b fails (PR#230)
Message-ID: <20000309182458.A47441CE31@dinsdale.python.org>

>>>>> "guido" ==   <guido@python.org> writes:

    guido> Sigh.  I'm embarrassed.

Don't be.  The interface is simply broken and everybody makes the same
mistake (sometimes, like me, over and over again :).  Not that it can
be changed.  :(

-Barry




From tim_one@email.msn.com  Fri Mar 10 03:31:42 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Thu, 9 Mar 2000 22:31:42 -0500
Subject: [Python-bugs-list] "Andrew M. Kuchling": Re: Module re bug. \b fails (PR#230)
In-Reply-To: <20000309182458.A47441CE31@dinsdale.python.org>
Message-ID: <000d01bf8a41$274369e0$58a2143f@tim>

> >>>>> "guido" ==   <guido@python.org> writes:
>
>     guido> Sigh.  I'm embarrassed.

[Barry]
> Don't be.  The interface is simply broken and everybody makes the same
> mistake (sometimes, like me, over and over again :).

Ha ha:  not me!  I've never ever confused these.  Here's the trick:
"search" searches and "match" matches.  Just keep that in mind and you'll
never go wrong either <wink>.

> Not that it can be changed.  :(

We could add alias names and "deprecate" the current names.  But what names?
"search" and "dontsearch" <0.9 wink>?  BTW, these functions are great, and I
would kill to keep "match" (it's sooooo much more useful when problems get
hard).




From tim_one@email.msn.com  Fri Mar 10 03:31:12 2000
From: tim_one@email.msn.com (tim_one@email.msn.com)
Date: Thu,  9 Mar 2000 22:31:12 -0500 (EST)
Subject: [Python-bugs-list] "Andrew M. Kuchling": Re: Module re bug. \b fails (PR#230)
Message-ID: <20000310033112.D32E11CD26@dinsdale.python.org>

> >>>>> "guido" ==   <guido@python.org> writes:
>
>     guido> Sigh.  I'm embarrassed.

[Barry]
> Don't be.  The interface is simply broken and everybody makes the same
> mistake (sometimes, like me, over and over again :).

Ha ha:  not me!  I've never ever confused these.  Here's the trick:
"search" searches and "match" matches.  Just keep that in mind and you'll
never go wrong either <wink>.

> Not that it can be changed.  :(

We could add alias names and "deprecate" the current names.  But what names?
"search" and "dontsearch" <0.9 wink>?  BTW, these functions are great, and I
would kill to keep "match" (it's sooooo much more useful when problems get
hard).






From bwarsaw@cnri.reston.va.us  Fri Mar 10 04:33:46 2000
From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us)
Date: Thu, 9 Mar 2000 23:33:46 -0500 (EST)
Subject: [Python-bugs-list] "Andrew M. Kuchling": Re: Module re bug. \b fails (PR#230)
References: <20000309182458.A47441CE31@dinsdale.python.org>
 <000d01bf8a41$274369e0$58a2143f@tim>
Message-ID: <14536.31530.165544.872583@anthem.cnri.reston.va.us>

>>>>> "TP" == Tim Peters <tim_one@email.msn.com> writes:

    TP> We could add alias names and "deprecate" the current names.
    TP> But what names?  "search" and "dontsearch" <0.9 wink>?  BTW,
    TP> these functions are great, and I would kill to keep "match"
    TP> (it's sooooo much more useful when problems get hard).

How about knockknockyouinthere() and izitatthefront() ?

For sure, I'd never get those wrong!

dwim-or-dim-ly y'rs,
-Barry



From bwarsaw@cnri.reston.va.us  Fri Mar 10 04:31:47 2000
From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us)
Date: Thu,  9 Mar 2000 23:31:47 -0500 (EST)
Subject: [Python-bugs-list] "Andrew M. Kuchling": Re: Module re bug. \b fails (PR#230)
Message-ID: <20000310043147.6E5201CD38@dinsdale.python.org>

>>>>> "TP" == Tim Peters <tim_one@email.msn.com> writes:

    TP> We could add alias names and "deprecate" the current names.
    TP> But what names?  "search" and "dontsearch" <0.9 wink>?  BTW,
    TP> these functions are great, and I would kill to keep "match"
    TP> (it's sooooo much more useful when problems get hard).

How about knockknockyouinthere() and izitatthefront() ?

For sure, I'd never get those wrong!

dwim-or-dim-ly y'rs,
-Barry





From nadavh@envision.co.il  Fri Mar 10 23:35:08 2000
From: nadavh@envision.co.il (nadavh@envision.co.il)
Date: Fri, 10 Mar 2000 18:35:08 -0500 (EST)
Subject: [Python-bugs-list] Inverse hyperbolic functions in cmath module (PR#231)
Message-ID: <20000310233508.3D06F1CE01@dinsdale.python.org>

Full_Name: Nadav Horesh
Version: 1.52
OS: NT 4.0 SP4
Submission from: (NULL) (212.25.119.223)


1.  The function cmath.acosh provides the negative branch with low 
precision. For example:

>>> cmath.acosh(cmath.cosh(10.0))
(-10.0000000135+0j)

Proposed solution --- use the following formula which is precise and
avoids singularities with complex arguments:

def acosh(x):
   return 2.0*log(sqrt(x+1.0) + sqrt(x-1.0)) - log(2.0)

2.  The function cmath.sinh does not handle moderately large 
arguments. For example:

>>> cmath.asinh(cmath.sinh(20.0))
(1.#INF+0j)

Proposed solution:

Use the textbook formula:
def asinh(x):
   return log(x+sqrt(x*x+1.0))

This calculation is more limited then the acosh calculation, but
still works fine.




From guido@python.org  Fri Mar 10 23:44:01 2000
From: guido@python.org (Guido van Rossum)
Date: Fri, 10 Mar 2000 18:44:01 -0500
Subject: [Python-bugs-list] Inverse hyperbolic functions in cmath module (PR#231)
In-Reply-To: Your message of "Fri, 10 Mar 2000 18:35:08 EST."
 <20000310233508.3D06F1CE01@dinsdale.python.org>
References: <20000310233508.3D06F1CE01@dinsdale.python.org>
Message-ID: <200003102344.SAA13419@eric.cnri.reston.va.us>

> Full_Name: Nadav Horesh
> Version: 1.52
> OS: NT 4.0 SP4
> Submission from: (NULL) (212.25.119.223)
> 
> 
> 1.  The function cmath.acosh provides the negative branch with low 
> precision. For example:
> 
> >>> cmath.acosh(cmath.cosh(10.0))
> (-10.0000000135+0j)
> 
> Proposed solution --- use the following formula which is precise and
> avoids singularities with complex arguments:
> 
> def acosh(x):
>    return 2.0*log(sqrt(x+1.0) + sqrt(x-1.0)) - log(2.0)
> 
> 2.  The function cmath.sinh does not handle moderately large 
> arguments. For example:
> 
> >>> cmath.asinh(cmath.sinh(20.0))
> (1.#INF+0j)
> 
> Proposed solution:
> 
> Use the textbook formula:
> def asinh(x):
>    return log(x+sqrt(x*x+1.0))
> 
> This calculation is more limited then the acosh calculation, but
> still works fine.

We're just using the VC++ C library.  I suggest you send your bug
report to Microsoft.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From guido@python.org  Fri Mar 10 23:42:08 2000
From: guido@python.org (guido@python.org)
Date: Fri, 10 Mar 2000 18:42:08 -0500 (EST)
Subject: [Python-bugs-list] Inverse hyperbolic functions in cmath module (PR#231)
Message-ID: <20000310234208.B1C031CDFA@dinsdale.python.org>

> Full_Name: Nadav Horesh
> Version: 1.52
> OS: NT 4.0 SP4
> Submission from: (NULL) (212.25.119.223)
> 
> 
> 1.  The function cmath.acosh provides the negative branch with low 
> precision. For example:
> 
> >>> cmath.acosh(cmath.cosh(10.0))
> (-10.0000000135+0j)
> 
> Proposed solution --- use the following formula which is precise and
> avoids singularities with complex arguments:
> 
> def acosh(x):
>    return 2.0*log(sqrt(x+1.0) + sqrt(x-1.0)) - log(2.0)
> 
> 2.  The function cmath.sinh does not handle moderately large 
> arguments. For example:
> 
> >>> cmath.asinh(cmath.sinh(20.0))
> (1.#INF+0j)
> 
> Proposed solution:
> 
> Use the textbook formula:
> def asinh(x):
>    return log(x+sqrt(x*x+1.0))
> 
> This calculation is more limited then the acosh calculation, but
> still works fine.

We're just using the VC++ C library.  I suggest you send your bug
report to Microsoft.

--Guido van Rossum (home page: http://www.python.org/~guido/)




From DavidA@ActiveState.com  Sat Mar 11 00:47:23 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Fri, 10 Mar 2000 16:47:23 -0800
Subject: [Python-bugs-list] Inverse hyperbolic functions in cmath module (PR#231)
In-Reply-To: <20000310234208.B1C031CDFA@dinsdale.python.org>
Message-ID: <LMBBIEIJKMPMLBONJMFCAEICCCAA.DavidA@ActiveState.com>

> We're just using the VC++ C library.  I suggest you send your bug
> report to Microsoft.

FWIW: the Perl folks are more and more (it seems to me) redoing things
themselves if the C library tends to be broken or slow.  I'm not suggesting
that it's a good decision, just commenting.

--david



From DavidA@ActiveState.com  Sat Mar 11 00:46:36 2000
From: DavidA@ActiveState.com (DavidA@ActiveState.com)
Date: Fri, 10 Mar 2000 19:46:36 -0500 (EST)
Subject: [Python-bugs-list] Inverse hyperbolic functions in cmath module (PR#231)
Message-ID: <20000311004636.BE2D41CE0E@dinsdale.python.org>

> We're just using the VC++ C library.  I suggest you send your bug
> report to Microsoft.

FWIW: the Perl folks are more and more (it seems to me) redoing things
themselves if the C library tends to be broken or slow.  I'm not suggesting
that it's a good decision, just commenting.

--david





From tim_one@email.msn.com  Sat Mar 11 03:05:07 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Fri, 10 Mar 2000 22:05:07 -0500
Subject: [Python-bugs-list] Inverse hyperbolic functions in cmath module (PR#231)
In-Reply-To: <20000310234208.B1C031CDFA@dinsdale.python.org>
Message-ID: <000901bf8b06$9baf8820$a42d153f@tim>

[Nadav Horesh, suggests different algorithms in cmath, for some complex
 inverse hyperbolics]

[Guido, misfires]
> We're just using the VC++ C library.

C doesn't define any functions on complex numbers -- cmathmodule.c
implements these all on its own.  I can't make time to look at this now, but
complaining to Microsoft about this will do Nadav even less good than when
it *is* their problem <wink>.




From tim_one@email.msn.com  Sat Mar 11 03:03:19 2000
From: tim_one@email.msn.com (tim_one@email.msn.com)
Date: Fri, 10 Mar 2000 22:03:19 -0500 (EST)
Subject: [Python-bugs-list] Inverse hyperbolic functions in cmath module (PR#231)
Message-ID: <20000311030319.A504B1CD4B@dinsdale.python.org>

[Nadav Horesh, suggests different algorithms in cmath, for some complex
 inverse hyperbolics]

[Guido, misfires]
> We're just using the VC++ C library.

C doesn't define any functions on complex numbers -- cmathmodule.c
implements these all on its own.  I can't make time to look at this now, but
complaining to Microsoft about this will do Nadav even less good than when
it *is* their problem <wink>.






From calvin@studcs.uni-sb.de  Sat Mar 11 03:39:53 2000
From: calvin@studcs.uni-sb.de (calvin@studcs.uni-sb.de)
Date: Fri, 10 Mar 2000 22:39:53 -0500 (EST)
Subject: [Python-bugs-list] httplib.HTTP.getfile() gets not the specified URL (PR#232)
Message-ID: <20000311033953.A66121CD80@dinsdale.python.org>

Full_Name: Bastian Kleineidam
Version: 1.5.2
OS: Debian Linux
Submission from: www-cache2.rz.uni-sb.de (134.96.7.103)


I request the URL http://www.calvinandhobbes.com/ and get the content of
http://www.uexpress.com/. With other tools (wget, Netscape, Perl GET), this
is not the case.
Here my Python script:
#!/usr/bin/env python
import httplib
h = httplib.HTTP("www.calvinandhobbes.com")
h.putrequest("GET","/")
h.endheaders()
r=h.getreply()
print r[2]
print h.getfile().read()

What I get is the content of http://www.uexpress.com/, not the specified URL.





From DavidA@ActiveState.com  Sat Mar 11 05:49:27 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Fri, 10 Mar 2000 21:49:27 -0800
Subject: [Python-bugs-list] Inverse hyperbolic functions in cmath module (PR#231)
In-Reply-To: <000901bf8b06$9baf8820$a42d153f@tim>
Message-ID: <LMBBIEIJKMPMLBONJMFCEEIJCCAA.DavidA@ActiveState.com>

> [Nadav Horesh, suggests different algorithms in cmath, for some complex
>  inverse hyperbolics]
>
> [Guido, misfires]
> > We're just using the VC++ C library.
>
> C doesn't define any functions on complex numbers -- cmathmodule.c
> implements these all on its own.  I can't make time to look at
> this now, but
> complaining to Microsoft about this will do Nadav even less good than when
> it *is* their problem <wink>.

As an aside, if anyone ever wants to trim the number of builtin C modules, I
found that it was much easier to write cmath.py than to write cmath.java
(for JPython).  The same cmath.py should work fine in CPython.  I can dig it
up, but I can't swear that I used the most numerically stable algorithms.
It did give the same numbers as CPython's cmath on a test set.

-david



From DavidA@ActiveState.com  Sat Mar 11 05:48:41 2000
From: DavidA@ActiveState.com (DavidA@ActiveState.com)
Date: Sat, 11 Mar 2000 00:48:41 -0500 (EST)
Subject: [Python-bugs-list] Inverse hyperbolic functions in cmath module (PR#231)
Message-ID: <20000311054841.743651CD27@dinsdale.python.org>

> [Nadav Horesh, suggests different algorithms in cmath, for some complex
>  inverse hyperbolics]
>
> [Guido, misfires]
> > We're just using the VC++ C library.
>
> C doesn't define any functions on complex numbers -- cmathmodule.c
> implements these all on its own.  I can't make time to look at
> this now, but
> complaining to Microsoft about this will do Nadav even less good than when
> it *is* their problem <wink>.

As an aside, if anyone ever wants to trim the number of builtin C modules, I
found that it was much easier to write cmath.py than to write cmath.java
(for JPython).  The same cmath.py should work fine in CPython.  I can dig it
up, but I can't swear that I used the most numerically stable algorithms.
It did give the same numbers as CPython's cmath on a test set.

-david





From guido@python.org  Sat Mar 11 11:58:47 2000
From: guido@python.org (Guido van Rossum)
Date: Sat, 11 Mar 2000 06:58:47 -0500
Subject: [Python-bugs-list] httplib.HTTP.getfile() gets not the specified URL (PR#232)
In-Reply-To: Your message of "Fri, 10 Mar 2000 22:39:53 EST."
 <20000311033953.A66121CD80@dinsdale.python.org>
References: <20000311033953.A66121CD80@dinsdale.python.org>
Message-ID: <200003111158.GAA10526@eric.cnri.reston.va.us>

> Full_Name: Bastian Kleineidam
> Version: 1.5.2
> OS: Debian Linux
> Submission from: www-cache2.rz.uni-sb.de (134.96.7.103)
> 
> I request the URL http://www.calvinandhobbes.com/ and get the content of
> http://www.uexpress.com/. With other tools (wget, Netscape, Perl GET), this
> is not the case.
> Here my Python script:
> #!/usr/bin/env python
> import httplib
> h = httplib.HTTP("www.calvinandhobbes.com")
> h.putrequest("GET","/")
> h.endheaders()
> r=h.getreply()
> print r[2]
> print h.getfile().read()
> 
> What I get is the content of http://www.uexpress.com/, not the specified URL.

The website is using virtual domains.  If you add the following call
between putrequest and endheaders it will work:

h.putheader('Host', 'www.calvinandhobbes.com')

Also, consider using urllib.  You could write the whole thing in two
lines:

import urllib
print urllib.urlopen("www.calvinandhobbes.com").read()

Good luck!

--Guido van Rossum (home page: http://www.python.org/~guido/)


From guido@python.org  Sat Mar 11 11:56:52 2000
From: guido@python.org (guido@python.org)
Date: Sat, 11 Mar 2000 06:56:52 -0500 (EST)
Subject: [Python-bugs-list] httplib.HTTP.getfile() gets not the specified URL (PR#232)
Message-ID: <20000311115652.21C3D1CD45@dinsdale.python.org>

> Full_Name: Bastian Kleineidam
> Version: 1.5.2
> OS: Debian Linux
> Submission from: www-cache2.rz.uni-sb.de (134.96.7.103)
> 
> I request the URL http://www.calvinandhobbes.com/ and get the content of
> http://www.uexpress.com/. With other tools (wget, Netscape, Perl GET), this
> is not the case.
> Here my Python script:
> #!/usr/bin/env python
> import httplib
> h = httplib.HTTP("www.calvinandhobbes.com")
> h.putrequest("GET","/")
> h.endheaders()
> r=h.getreply()
> print r[2]
> print h.getfile().read()
> 
> What I get is the content of http://www.uexpress.com/, not the specified URL.

The website is using virtual domains.  If you add the following call
between putrequest and endheaders it will work:

h.putheader('Host', 'www.calvinandhobbes.com')

Also, consider using urllib.  You could write the whole thing in two
lines:

import urllib
print urllib.urlopen("www.calvinandhobbes.com").read()

Good luck!

--Guido van Rossum (home page: http://www.python.org/~guido/)




From tim_one@email.msn.com  Sat Mar 11 18:47:25 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Sat, 11 Mar 2000 13:47:25 -0500
Subject: [Python-bugs-list] Inverse hyperbolic functions in cmath module (PR#231)
In-Reply-To: <LMBBIEIJKMPMLBONJMFCEEIJCCAA.DavidA@ActiveState.com>
Message-ID: <000c01bf8b8a$3efd5240$c72d153f@tim>

[Tim]
> C doesn't define any functions on complex numbers -- cmathmodule.c
> implements these all on its own.

[David Ascher]
> As an aside, if anyone ever wants to trim the number of builtin C
> modules, I found that it was much easier to write cmath.py than to
> write cmath.java (for JPython).  The same cmath.py should work fine
> in CPython.

Yes, I don't see anything in cmathmodule.c that *needs* to be coded in C; &
coding would be much clearer in Python, using infix notation for the basic
complex binary ops.  Two possible reasons for leaving it in C:

1. Lower internal call overheads (i.e., speed).

2. Improving quality -- complex libraries are very difficult to get right
   in all cases if they're made IEEE-754 aware, and doing so requires
fiddling
   with the processor-level 754 control & status features.  But there's no
   portable way to do that now, and won't be until the next iteration of C.

> I can dig it up, but I can't swear that I used the most numerically stable
> algorithms.

I can:  you didn't <wink>.  Doesn't matter, though!  cmathmodule.c is naive
too, and achieving good accuracy across the whole domain is a major
undertaking.  That gives the best reason to write it in Python:

3. There's a long way to go to make this "industrial strength", so the
   current cmath is really just a prototype.  Everyone knows prototyping
   is much easier in Python.  QED <wink>.

> It did give the same numbers as CPython's cmath on a test set.

So ship it <wink>.




From tim_one@email.msn.com  Sat Mar 11 18:46:05 2000
From: tim_one@email.msn.com (tim_one@email.msn.com)
Date: Sat, 11 Mar 2000 13:46:05 -0500 (EST)
Subject: [Python-bugs-list] Inverse hyperbolic functions in cmath module (PR#231)
Message-ID: <20000311184605.5D9AA1CD44@dinsdale.python.org>

[Tim]
> C doesn't define any functions on complex numbers -- cmathmodule.c
> implements these all on its own.

[David Ascher]
> As an aside, if anyone ever wants to trim the number of builtin C
> modules, I found that it was much easier to write cmath.py than to
> write cmath.java (for JPython).  The same cmath.py should work fine
> in CPython.

Yes, I don't see anything in cmathmodule.c that *needs* to be coded in C; &
coding would be much clearer in Python, using infix notation for the basic
complex binary ops.  Two possible reasons for leaving it in C:

1. Lower internal call overheads (i.e., speed).

2. Improving quality -- complex libraries are very difficult to get right
   in all cases if they're made IEEE-754 aware, and doing so requires
fiddling
   with the processor-level 754 control & status features.  But there's no
   portable way to do that now, and won't be until the next iteration of C.

> I can dig it up, but I can't swear that I used the most numerically stable
> algorithms.

I can:  you didn't <wink>.  Doesn't matter, though!  cmathmodule.c is naive
too, and achieving good accuracy across the whole domain is a major
undertaking.  That gives the best reason to write it in Python:

3. There's a long way to go to make this "industrial strength", so the
   current cmath is really just a prototype.  Everyone knows prototyping
   is much easier in Python.  QED <wink>.

> It did give the same numbers as CPython's cmath on a test set.

So ship it <wink>.






From japhy@pobox.com  Sat Mar 11 21:34:44 2000
From: japhy@pobox.com (japhy@pobox.com)
Date: Sat, 11 Mar 2000 16:34:44 -0500 (EST)
Subject: [Python-bugs-list] __builtin__ and __builtins__ ?! (PR#233)
Message-ID: <20000311213444.B1DB31CD7B@dinsdale.python.org>

Full_Name: Jeff Pinyan
Version: 1.5.2
OS: SunOS
Submission from: bcts-remote-8-166.bergen.org (168.229.8.166)


I've noticed there's a __builtins__ module (which calls itself __builtin__).
Why is this around?  I don't think I've seen __builtins__ referenced in any of
the docs I've read.  And what boggles me even more is that __builtins__ SAYS:

>>> __builtins__
<module '__builtin__' (built-in)>

I don't know if this is a "bug" or not.




From guido@python.org  Mon Mar 13 14:58:39 2000
From: guido@python.org (guido@python.org)
Date: Mon, 13 Mar 2000 09:58:39 -0500 (EST)
Subject: [Python-bugs-list] __builtin__ and __builtins__ ?! (PR#233)
Message-ID: <20000313145839.E1B051CD68@dinsdale.python.org>

> Full_Name: Jeff Pinyan
> Version: 1.5.2
> OS: SunOS
> Submission from: bcts-remote-8-166.bergen.org (168.229.8.166)
> 
> 
> I've noticed there's a __builtins__ module (which calls itself __builtin__).
> Why is this around?  I don't think I've seen __builtins__ referenced in any of
> the docs I've read.  And what boggles me even more is that __builtins__ SAYS:
> 
> >>> __builtins__
> <module '__builtin__' (built-in)>
> 
> I don't know if this is a "bug" or not.

It's not a bug, just some arcane naming.  The *module* is __builtin__
(no 's').  You can import it if you wish.  The __builtins__ object
(with 's') that you will find in each module's namespace is the
dictionary where the system looks for built-ins; it is
__builtin__.__dict__.  This is a mechanism used by restricted
execution (see module rexec).  For various reasons, mostly having to
do with an attempt to reduce the output from a directory contents
listing, the __builtins__ object in the __main__ module (what you
interact with at the >>> prompt) is not the dictionary but the
__builtin__ module itself -- but the semantics are the same.

--Guido van Rossum (home page: http://www.python.org/~guido/)





From m.favas@per.dem.csiro.au  Tue Mar 14 02:06:20 2000
From: m.favas@per.dem.csiro.au (m.favas@per.dem.csiro.au)
Date: Mon, 13 Mar 2000 21:06:20 -0500 (EST)
Subject: [Python-bugs-list] 2 small Unicode glitches in CVS of March 14 2000 (PR#234)
Message-ID: <20000314020620.0F93A1CDC1@dinsdale.python.org>

Platform: DEC/Compaq Alpha, Tru64 Unix, DEC/Compaq C compiler
Compaq C V6.1-110 (dtk) on Digital UNIX V4.0F  (Rev. 1229)

Glitch 1:
=========
Compiling Objects/unicodeobject.c produces the following warnings:

cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H   -c
unicodeobject.c
-o unicodeobject.o
cc: Warning: unicodeobject.c, line 1072: The block-level declaration of
the
function "findchar" specifies an explicit storage class other than
extern.
(funcstrcls)
        static const Py_UNICODE *findchar(const Py_UNICODE *s,
--------------------------------^
cc: Warning: unicodeobject.c, line 2033: In this declaration, "findchar"
is
declared with both internal and external linkage.  The previous
declaration is
at line number 1072 in file unicodeobject.c. (mixlinkage)
const Py_UNICODE *findchar(const Py_UNICODE *s,
-----------------^

Suggested patch (move the forward declaration of findchar out of the
function it is currently in):

*** unicodeobject.c.orig        Tue Mar 14 09:50:15 2000
--- unicodeobject.c     Tue Mar 14 09:51:16 2000
***************
*** 1051,1056 ****
--- 1051,1060 ----
  
  */
  
+ static const Py_UNICODE *findchar(const Py_UNICODE *s,
+                                 int size,
+                                 Py_UNICODE ch);
+ 
  static
  PyObject *unicodeescape_string(const Py_UNICODE *s,
                                 int size,
***************
*** 1069,1077 ****
      p = q = PyString_AS_STRING(repr);
  
      if (quotes) {
-         static const Py_UNICODE *findchar(const Py_UNICODE *s,
-                                         int size,
-                                         Py_UNICODE ch);
          *p++ = 'u';
          *p++ = (findchar(s, size, '\'') && 
                  !findchar(s, size, '"')) ? '"' : '\'';
--- 1073,1078 ----


Glitch 2:
=========
"make test" fails the unicode test, but Lib/test/test_unicode.py
succeeds.
Lib/test/output/test_unicode is missing a line for the "contains" method
test.

Patch:

*** test_unicode.orig   Tue Mar 14 09:58:45 2000
--- test_unicode        Tue Mar 14 09:59:03 2000
***************
*** 1,4 ****
--- 1,5 ----
  test_unicode
  Testing Unicode comparisons... done.
+ Testing Unicode contains method... done.
  Testing Unicode formatting strings... done.
  Testing unicodedata module... done.


I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims").  To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation.  I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.

-- 
Email  - m.favas@per.dem.csiro.au        Mark C Favas
Phone  - +61 8 9333 6268, 0418 926 074   CSIRO Exploration & Mining
Fax    - +61 8 9383 9891                 Private Bag Post Office Wembley
GPS    - 31.97 S, 115.81 E               Western Australia 6014




From piers@cs.su.oz.au  Tue Mar 14 23:55:40 2000
From: piers@cs.su.oz.au (piers@cs.su.oz.au)
Date: Tue, 14 Mar 2000 18:55:40 -0500 (EST)
Subject: [Python-bugs-list] rfc822.py module - address parsing problem (PR#235)
Message-ID: <20000314235540.B87AF1CE9F@dinsdale.python.org>

Full_Name: Piers Lauder
Version: 1.5.2
OS: sunos
Submission from: metro.ucc.usyd.edu.au (129.78.64.2)


RFC822 specifies an address form known as a "domain literal",
eg: [132.151.1.21], but rfc822.parseaddr() incorrectly strips
the square brackets denoting special treatment of the contents.
(This routine is used by smtplib module, and thus causes it
to deliver messages using this form of address incorrectly.)

Here is an example:

: s ; python
Python 1.5.2 (#10, May 11 1999, 15:32:03)  [GCC 2.8.1] on sunos5
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import rfc822
>>> rfc822.parseaddr('guido@[132.151.1.21]')
('', 'guido@132.151.1.21')
>>> 






From jsolbrig@webcom.com  Wed Mar 15 00:55:23 2000
From: jsolbrig@webcom.com (jsolbrig@webcom.com)
Date: Tue, 14 Mar 2000 19:55:23 -0500 (EST)
Subject: [Python-bugs-list] pdb bug (PR#236)
Message-ID: <20000315005523.3AAB01CEA5@dinsdale.python.org>

Full_Name: Hans Joseph Solbrig
Version: 1.5.2
OS: Win32/win95
Submission from: hazelnut.uoregon.edu (128.223.85.89)


pdb (python debugger) tends to drop (ignore) breaks in multi-file debugging.

I wish I had time to isolate the offending code but I don't.




From komarek@andrew.cmu.edu  Thu Mar 16 05:00:03 2000
From: komarek@andrew.cmu.edu (komarek@andrew.cmu.edu)
Date: Thu, 16 Mar 2000 00:00:03 -0500 (EST)
Subject: [Python-bugs-list] Tkinter geometry problem with grid (PR#237)
Message-ID: <20000316050003.37A171CF59@dinsdale.python.org>

Full_Name: Paul Komarek
Version: 1.5.2
OS: RedHat GNU/Linux 6.1
Submission from: elmo.rem.cmu.edu (128.2.82.218)



This seems to be the right place to submit a (possible) Tkinter bug, but
please let me know if it isn't.  I'm running Python 1.5.2, with Tkinter from
the RedHat rpm tkinter-1.5.2-7.  Here's the shortest code I could make that
illustrated the problem:

from Tkinter import *
root = Tk()
f = Frame( root).pack()
Label( f, text = 'Hello1').grid()
root.mainloop()

The Tk window never shows up, I assume because of a geometry negotiation
failure.  I believe this should work because the Label is gridded inside f,
and is the only widget inside f.  f is packed in the root, and is the only
widget.  So there should be no conflicts, correct?

I ran the following code in Perl/Tk:

use strict;
use Tk;
my $root = MainWindow->new;
my $f = $root->Frame()->pack();
$f->Label( -text => "Hello1")->grid();
MainLoop;

I believe this should be equivalent to the Python code above.  However, the
result is what I expected--a window with a label in it, no problems with
geometry, etc.

-Paul Komarek




From port22@rnhnet.com  Thu Mar 16 19:52:33 2000
From: port22@rnhnet.com (port22@rnhnet.com)
Date: Thu, 16 Mar 2000 14:52:33 -0500 (EST)
Subject: [Python-bugs-list] PC / Internet fax solution (PR#238)
Message-ID: <20000316195233.E89201CEF6@dinsdale.python.org>

I stopped by your web site and thought you may be interested in our
PC/internet based fax service. You can send 1 to 1,000,000 faxes in just
minutes to any destination in the US, Canada, and Europe for as low as 7.4
cents per minute. Our user-friendly submission software lets you queue your
job on our server within minutes. Why not try the system for FREE. We will
be happy to send 100 Faxes on your behalf to your fax list immediately.
Simply go to 

http://www.efaxcast.com/submit.htm

 




From Michael_Frericks@informatik-kooperation.de  Fri Mar 17 16:27:25 2000
From: Michael_Frericks@informatik-kooperation.de (Michael_Frericks@informatik-kooperation.de)
Date: Fri, 17 Mar 2000 11:27:25 -0500 (EST)
Subject: [Python-bugs-list] PRIVATE: CGIHTTPServer (PR#239)
Message-ID: <20000317162725.9E7C71CD43@dinsdale.python.org>

Full_Name: Michael Frericks
Version: 1.5.2
OS: WinNT 4.0
Submission from: proxy1.s-web.de (195.140.123.17)


The module CGIHTTPServer does not run on WinNT since 

a) the function executable() seems to return a false value, if you omit the call
of executable() you come to
b) the function nobody_uid() imports the module pwd available only for unix
c) other unix-functions as fork... are used to create a process with the user
nobody




From gvr@ricochet.net  Fri Mar 17 19:02:01 2000
From: gvr@ricochet.net (gvr@ricochet.net)
Date: Fri, 17 Mar 2000 14:02:01 -0500 (EST)
Subject: [Python-bugs-list] Tkinter geometry problem with grid (PR#237)
Message-ID: <20000317190201.9A7841CD6F@dinsdale.python.org>

> from Tkinter import *
> root = Tk()
> f = Frame( root).pack()
> Label( f, text = 'Hello1').grid()
> root.mainloop()

Komarek,

The pack() method doesn't return the widget; it returns None.
Thus, the Label receives None as the master, and doesn't do the right think.
Thy this code instead:

f = Frame(root)
f.pack()
lab = Label(f, text='Hello1')
lab.grid()
root.mainloop()

--Guido






From kragen@pobox.com  Fri Mar 17 21:06:22 2000
From: kragen@pobox.com (kragen@pobox.com)
Date: Fri, 17 Mar 2000 16:06:22 -0500 (EST)
Subject: [Python-bugs-list] build on NeXTStep (PR#240)
Message-ID: <20000317210622.8EA731CD3C@dinsdale.python.org>

I'm building Python on NeXTStep; I've encountered three minor problems.

- importdl.c by default on NeXTStep allows linking with Objective-C
  modules, which is cool.  Unfortunately, properly supporting this
  requires adding -ObjC to the cc command line in the Makefile.
- posixmodule.c doesn't #include anything that declares fsync() and
  doesn't declare it itself, but tries to reference it.  Adding a
  declaration of fsync() fixes the problem.
- test_strftime and test_time fail.
  test test_strftime failed -- Writing: 'Conflict for %j (julian day (001-366)):', expected: ''
  I suspect this may be a platform bug.  Here's some of the output,
  which is 696 lines in full:
strftime test for Fri Mar 17 12:53:20 2000
Strftime test, platform: next3_3, Python version: 1.5.2
Conflict for %j (julian day (001-366)):
  Expected 077, but got 076
Conflict for nonstandard '%c' format (near-asctime() format):
  Expected Fri Mar 17 12:53:20 2000, but got Fri Mar 17 12:53:20  2000
Conflict for nonstandard '%x' format (%m/%d/%y %H:%M:%S):
  Expected 03/17/00, but got Fri Mar 17 2000
Does not appear to support '%Z' format (time zone name)
Conflict for nonstandard '%D' format (mm/dd/yy):
  Expected 03/17/00, but got ?
Conflict for nonstandard '%e' format (day of month as number, blank padded ( 0-31)):
  Expected 17, but got ?
Conflict for nonstandard '%h' format (abbreviated month name):
  Expected Mar, but got ?
Conflict for nonstandard '%k' format (hour, blank padded ( 0-23)):
  Expected 12, but got ?
Conflict for nonstandard '%n' format (newline character):
  Expected 
, but got ?
Conflict for nonstandard '%r' format (%I:%M:%S %p):
  Expected 12:53:20 PM, but got ?
Conflict for nonstandard '%R' format (%H:%M):
  Expected 12:53, but got ?
Conflict for nonstandard '%s' format (seconds since the Epoch in UCT):
  Expected 953326400, but got ?
Conflict for nonstandard '%t' format (tab character):
  Expected      , but got ?
Conflict for nonstandard '%T' format (%H:%M:%S):
  Expected 12:53:20, but got ?
Conflict for nonstandard '%3y' format (year without century rendered using fieldwidth):
  Expected 000, but got ?y
Conflict for %j (julian day (001-366)):
  Expected 327, but got 326
Conflict for %W (week number of the year (Mon 1st)):
  Expected 46, but got 47
Conflict for %j (julian day (001-366)):
  Expected 328, but got 327
Conflict for %j (julian day (001-366)):
  Expected 329, but got 328
Conflict for %j (julian day (001-366)):
  Expected 330, but got 329

test test_time failed -- Writing: 'time.mktime(time.localtime(t)) <> t', expected: ''
(and that was all of the output from test_time.  Presumably this is
related to the strftime bugs --- perhaps the mythical Y2K leap-year bug?)

I'm afraid I'm not sure what version of NeXTStep I'm on.  'arch'
reports 'hppa'; 'cc --version' reports '2.5.8'; 'uname -a' reports
'Command not found'.

I'm not trying to build a very sophisticated environment --- just the
defaults.

-- 
<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08.  Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.html>
The power didn't go out on 2000-01-01 either.  :)





From nobody@example.org  Sun Mar 19 19:14:47 2000
From: nobody@example.org (nobody@example.org)
Date: Sun, 19 Mar 2000 14:14:47 -0500 (EST)
Subject: [Python-bugs-list] PRIVATE: Some bug fixes for Python 1.5.2 manual. (PR#241)
Message-ID: <20000319191447.C47A01CD69@dinsdale.python.org>

Full_Name: No Body
Version: 1.5.2
OS: Linux
Submission from: host96.207.55.120.aadsl.com (207.55.120.96)



lib/debugger-commands.html

    -- In d(own) command, "older" should be "newer".
    -- In u(p) command, "newer" should be "older".

lib/node201.html

    -- In third paragraph, "used that" should be "used * that", where * 
    is: in, with, for, or something else.

lib/module-thread.html

    -- In the Caveats section, "exit_thread()" should be "exit()".

lib/module-time.html

    -- The "altzone" language is confusing.  "0th meridian" probably
    should be "GMT" or "UCT" since we're talking about time, not
    longitude.  And use of "0th" leads to confusion in English.
    The first meridian runs thru Greenwich; always has, always will.
    Readers expect English, not C'nish, else "Sunday as the first"
    on the same page is wrong.
    -- Same for "timezone".

lib/module-thread.html

    -- What is a "main thread"?  Newbies consider threads to be
    light-weight processes and the main program's process is not
    light weight and thus not a thread and thus not the main thread.





From jon@dstc.edu.au  Tue Mar 21 23:41:24 2000
From: jon@dstc.edu.au (jon@dstc.edu.au)
Date: Tue, 21 Mar 2000 18:41:24 -0500 (EST)
Subject: [Python-bugs-list] freeze imports obsolete cmp module (PR#242)
Message-ID: <20000321234124.880721CDD2@dinsdale.python.org>

Full_Name: Jonathan Giddy
Version: 1.5.2+
OS: Linux 2.2.12
Submission from: cow.cc.monash.edu.au (130.194.11.89)


Since cmp.py has been declared obsolete and moved to lib-old,
freeze no longer works unless lib-old is added to the PYTHONPATH.





From lannert@uni-duesseldorf.de  Wed Mar 22 00:07:53 2000
From: lannert@uni-duesseldorf.de (lannert@uni-duesseldorf.de)
Date: Tue, 21 Mar 2000 19:07:53 -0500 (EST)
Subject: [Python-bugs-list] netrc.py rejects hostnames (PR#243)
Message-ID: <20000322000753.0338B1CDDD@dinsdale.python.org>

Hi,

I tried to use netrc.py but it chokes on my ~/.netrc: hostnames of the
form spam.uni-duesseldorf.de are rejected because of the '-' character.

The following patch against the CVS version made this module work (for
me!):

--- netrc.py~   Wed Mar 22 01:01:33 2000
+++ netrc.py    Wed Mar 22 01:02:01 2000
@@ -15,7 +15,7 @@
         self.hosts = {}
         self.macros = {}
         lexer = shlex.shlex(fp)
-        lexer.wordchars = lexer.wordchars + '.'
+        lexer.wordchars = lexer.wordchars + '.-'
         while 1:
             # Look for a machine, default, or macdef top-level keyword
             toplevel = tt = lexer.get_token()


AFAIK, '-' is a legitimate hostname character; I don't think that this
extended acceptance of the lexer could break anything else.

BTW, the following lines:

31:                lexer.whitepace = ' \t'
35:                        lexer.whitepace = ' \t\r\n'

look a bit strange; shouldn't it be "whitespace" as defined in shlex?
(But then, how did this ever work? :)

  Detlef




From tdeutsch@cea.fr  Wed Mar 22 13:54:07 2000
From: tdeutsch@cea.fr (tdeutsch@cea.fr)
Date: Wed, 22 Mar 2000 08:54:07 -0500 (EST)
Subject: [Python-bugs-list] string.replace returns MemoryError (PR#244)
Message-ID: <20000322135407.096F21CE4C@dinsdale.python.org>

Full_Name: Thierry Deutsch
Version: 1.5.2
OS: OSF1-alpha
Submission from: drfmc.ceng.cea.fr (132.168.10.1)


Python 1.5.2 (#8, Mar 21 2000, 17:41:50) [C] on osf1V4
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import strop
>>> strop.replace('aaaa','aa','')
Traceback (innermost last):
  File "<stdin>", line 1, in ?
MemoryError

I use strop.replace but I discovered the "bug" with string.replace.

In OSF1 alpha V4.0, malloc(0) returns 0.
The script configure detects correctly this feature
(#define MALLOC_ZERO_RETURNS_NULL 1).
The bug is due, I think, to the use of malloc instead of PyMem_New
in the file stropmodule.c.

There are some reports with the function apply
but it seems that here the cause is different.




From sde@recombinant.demon.co.uk  Wed Mar 22 21:13:27 2000
From: sde@recombinant.demon.co.uk (sde@recombinant.demon.co.uk)
Date: Wed, 22 Mar 2000 16:13:27 -0500 (EST)
Subject: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
Message-ID: <20000322211327.6D2EB1CE7C@dinsdale.python.org>

Full_Name: Stephen D Evans
Version: 1.5.2
OS: win32
Submission from: recombinant.demon.co.uk (212.229.73.7)


#! /usr/bin/python

# Inconsistent behaviour.

# Python 1.5.2 win32 fails the second print (why not both?)
# other versions print both expressions

#              Ok  Python 1.5.2 on SuSE Linux 6.3
#              Ok  JPython 1.1 on java1.1.7B
# Partial failure  Python 1.5.2 win32

print eval("float(1.0e-309)")
print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309





From sde@recombinant.demon.co.uk  Wed Mar 22 21:15:52 2000
From: sde@recombinant.demon.co.uk (sde@recombinant.demon.co.uk)
Date: Wed, 22 Mar 2000 16:15:52 -0500 (EST)
Subject: [Python-bugs-list] anomolous list append of tuple (PR#246)
Message-ID: <20000322211552.B0E5C1CE82@dinsdale.python.org>

Full_Name: Stephen D Evans
Version: 1.5.2
OS: win32 and linux
Submission from: recombinant.demon.co.uk (212.229.73.7)


#! /usr/bin/python

# Anomalous behaviour.

# JPython correctly detects TypeError
# other versions print L

# No failure  Python 1.5.2 win32
# No failure  Python 1.5.2 on SuSE Linux 6.3
#      Fails  JPython 1.1 on java1.1.7B (correct behaviour?)
L=[]
L.append((1,2))
L.append(3,4) # TypeError: append(): expected 1 args; got 2
print L # [(1, 2), (3, 4)]





From mhammond@skippinet.com.au  Wed Mar 22 22:30:02 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Wed, 22 Mar 2000 14:30:02 -0800
Subject: [Python-bugs-list] anomolous list append of tuple (PR#246)
In-Reply-To: <20000322211552.B0E5C1CE82@dinsdale.python.org>
Message-ID: <ECEPKNMJLHAPFFJHDOJBCEPNCGAA.mhammond@skippinet.com.au>

This was not originally a bug - but the current CVS tree has a "fix" for
this, so I guess it really was a bug after all :-)  The main thing is that
1.6 will not have this problem.

Mark.

> -----Original Message-----
> From: python-bugs-list-admin@python.org
> [mailto:python-bugs-list-admin@python.org]On Behalf Of
> sde@recombinant.demon.co.uk
> Sent: Wednesday, 22 March 2000 1:16 PM
> To: python-bugs-list@python.org
> Cc: bugs-py@python.org
> Subject: [Python-bugs-list] anomolous list append of tuple (PR#246)
>
>
> Full_Name: Stephen D Evans
> Version: 1.5.2
> OS: win32 and linux
> Submission from: recombinant.demon.co.uk (212.229.73.7)
>
>
> #! /usr/bin/python
>
> # Anomalous behaviour.
>
> # JPython correctly detects TypeError
> # other versions print L
>
> # No failure  Python 1.5.2 win32
> # No failure  Python 1.5.2 on SuSE Linux 6.3
> #      Fails  JPython 1.1 on java1.1.7B (correct behaviour?)
> L=[]
> L.append((1,2))
> L.append(3,4) # TypeError: append(): expected 1 args; got 2
> print L # [(1, 2), (3, 4)]
>
>
>
>
> _______________________________________________
> Python-bugs-list maillist  -  Python-bugs-list@python.org
> http://www.python.org/mailman/listinfo/python-bugs-list
>



From mhammond@skippinet.com.au  Wed Mar 22 22:28:14 2000
From: mhammond@skippinet.com.au (mhammond@skippinet.com.au)
Date: Wed, 22 Mar 2000 17:28:14 -0500 (EST)
Subject: [Python-bugs-list] anomolous list append of tuple (PR#246)
Message-ID: <20000322222814.605C11CDCC@dinsdale.python.org>

This was not originally a bug - but the current CVS tree has a "fix" for
this, so I guess it really was a bug after all :-)  The main thing is that
1.6 will not have this problem.

Mark.

> -----Original Message-----
> From: python-bugs-list-admin@python.org
> [mailto:python-bugs-list-admin@python.org]On Behalf Of
> sde@recombinant.demon.co.uk
> Sent: Wednesday, 22 March 2000 1:16 PM
> To: python-bugs-list@python.org
> Cc: bugs-py@python.org
> Subject: [Python-bugs-list] anomolous list append of tuple (PR#246)
>
>
> Full_Name: Stephen D Evans
> Version: 1.5.2
> OS: win32 and linux
> Submission from: recombinant.demon.co.uk (212.229.73.7)
>
>
> #! /usr/bin/python
>
> # Anomalous behaviour.
>
> # JPython correctly detects TypeError
> # other versions print L
>
> # No failure  Python 1.5.2 win32
> # No failure  Python 1.5.2 on SuSE Linux 6.3
> #      Fails  JPython 1.1 on java1.1.7B (correct behaviour?)
> L=[]
> L.append((1,2))
> L.append(3,4) # TypeError: append(): expected 1 args; got 2
> print L # [(1, 2), (3, 4)]
>
>
>
>
> _______________________________________________
> Python-bugs-list maillist  -  Python-bugs-list@python.org
> http://www.python.org/mailman/listinfo/python-bugs-list
>





From tim_one@email.msn.com  Thu Mar 23 07:17:35 2000
From: tim_one@email.msn.com (tim_one@email.msn.com)
Date: Thu, 23 Mar 2000 02:17:35 -0500 (EST)
Subject: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
Message-ID: <20000323071735.42A9A1CE50@dinsdale.python.org>

> -----Original Message-----
> From: python-bugs-list-admin@python.org
> [mailto:python-bugs-list-admin@python.org]On Behalf Of
> sde@recombinant.demon.co.uk
> Sent: Wednesday, March 22, 2000 4:13 PM
> To: python-bugs-list@python.org
> Cc: bugs-py@python.org
> Subject: [Python-bugs-list] float("1.0e-309") inconsistency on win32
> (PR#245)
>
>
> Full_Name: Stephen D Evans
> Version: 1.5.2
> OS: win32
> Submission from: recombinant.demon.co.uk (212.229.73.7)
>
>
> #! /usr/bin/python
>
> # Inconsistent behaviour.
>
> # Python 1.5.2 win32 fails the second print (why not both?)
> # other versions print both expressions
>
> #              Ok  Python 1.5.2 on SuSE Linux 6.3
> #              Ok  JPython 1.1 on java1.1.7B
> # Partial failure  Python 1.5.2 win32
>
> print eval("float(1.0e-309)")
> print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309

First note that these don't do the same thing:  the first passes a float to
"float", the second passes a string to "float".  Change the first to

    print eval("float('1.0e-309')")

and it gives the same bogus error as the second one.

Then it turns out the error is Microsoft's fault.  This tiny C program shows
the bug:

#include <errno.h>
#include <stdlib.h>
#include <stdio.h>

void
main()
{
    double x;
    char* dontcare;
    errno = 0;
    x = strtod("1.0e-309", &dontcare);
    printf("errno after = %d\n", errno);
    printf("x after = %g\n", x);
}

This prints

    errno after = 34
    x after = 0

when compiled & linked with MS's VC5; don't know about VC6.  Same thing for
"1.0e-308".  Works fine for "1.0e-307".  Doubt this will get fixed before MS
fixes their library.






From tim_one@email.msn.com  Thu Mar 23 06:43:30 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Thu, 23 Mar 2000 01:43:30 -0500
Subject: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
In-Reply-To: <20000322211327.6D2EB1CE7C@dinsdale.python.org>
Message-ID: <000001bf9493$1a18cec0$662d153f@tim>

> -----Original Message-----
> From: python-bugs-list-admin@python.org
> [mailto:python-bugs-list-admin@python.org]On Behalf Of
> sde@recombinant.demon.co.uk
> Sent: Wednesday, March 22, 2000 4:13 PM
> To: python-bugs-list@python.org
> Cc: bugs-py@python.org
> Subject: [Python-bugs-list] float("1.0e-309") inconsistency on win32
> (PR#245)
>
>
> Full_Name: Stephen D Evans
> Version: 1.5.2
> OS: win32
> Submission from: recombinant.demon.co.uk (212.229.73.7)
>
>
> #! /usr/bin/python
>
> # Inconsistent behaviour.
>
> # Python 1.5.2 win32 fails the second print (why not both?)
> # other versions print both expressions
>
> #              Ok  Python 1.5.2 on SuSE Linux 6.3
> #              Ok  JPython 1.1 on java1.1.7B
> # Partial failure  Python 1.5.2 win32
>
> print eval("float(1.0e-309)")
> print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309

First note that these don't do the same thing:  the first passes a float to
"float", the second passes a string to "float".  Change the first to

    print eval("float('1.0e-309')")

and it gives the same bogus error as the second one.

Then it turns out the error is Microsoft's fault.  This tiny C program shows
the bug:

#include <errno.h>
#include <stdlib.h>
#include <stdio.h>

void
main()
{
    double x;
    char* dontcare;
    errno = 0;
    x = strtod("1.0e-309", &dontcare);
    printf("errno after = %d\n", errno);
    printf("x after = %g\n", x);
}

This prints

    errno after = 34
    x after = 0

when compiled & linked with MS's VC5; don't know about VC6.  Same thing for
"1.0e-308".  Works fine for "1.0e-307".  Doubt this will get fixed before MS
fixes their library.




From bthomas@hirevelocity.com  Thu Mar 23 16:08:52 2000
From: bthomas@hirevelocity.com (bthomas@hirevelocity.com)
Date: Thu, 23 Mar 2000 11:08:52 -0500 (EST)
Subject: [Python-bugs-list] Quick Question (PR#247)
Message-ID: <20000323160852.269041CEDA@dinsdale.python.org>

Thursday, 3/23/00


Hi,

I got your name from the SF Web Firmlist.

Any Idea where the best place is, to find Consultant level Salespeople for a
San Fran based Web
Sales Company.

We've been trying for a while and no luck...

Can you help, thanks,

Bill Thomas





From guido@python.org  Fri Mar 24 09:49:53 2000
From: guido@python.org (guido@python.org)
Date: Fri, 24 Mar 2000 04:49:53 -0500 (EST)
Subject: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
Message-ID: <20000324094953.954D51CF2D@dinsdale.python.org>

> > Full_Name: Stephen D Evans
> > Version: 1.5.2
> > OS: win32
> > Submission from: recombinant.demon.co.uk (212.229.73.7)
> >
> >
> > #! /usr/bin/python
> >
> > # Inconsistent behaviour.
> >
> > # Python 1.5.2 win32 fails the second print (why not both?)
> > # other versions print both expressions
> >
> > #              Ok  Python 1.5.2 on SuSE Linux 6.3
> > #              Ok  JPython 1.1 on java1.1.7B
> > # Partial failure  Python 1.5.2 win32
> >
> > print eval("float(1.0e-309)")
> > print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309
> 
> First note that these don't do the same thing:  the first passes a float to
> "float", the second passes a string to "float".  Change the first to
> 
>     print eval("float('1.0e-309')")
> 
> and it gives the same bogus error as the second one.
> 
> Then it turns out the error is Microsoft's fault.  This tiny C program shows
> the bug:
> 
> #include <errno.h>
> #include <stdlib.h>
> #include <stdio.h>
> 
> void
> main()
> {
>     double x;
>     char* dontcare;
>     errno = 0;
>     x = strtod("1.0e-309", &dontcare);
>     printf("errno after = %d\n", errno);
>     printf("x after = %g\n", x);
> }
> 
> This prints
> 
>     errno after = 34
>     x after = 0
> 
> when compiled & linked with MS's VC5; don't know about VC6.  Same thing for
> "1.0e-308".  Works fine for "1.0e-307".  Doubt this will get fixed before MS
> fixes their library.

The bizarre thing is that this is broken the same way on Solaris:

>>> 1.0e-309
1.0000000000000019e-309
>>> float("1.0e-309")
Traceback (innermost last):
  File "<stdin>", line 1, in ?
ValueError: float() literal too large: 1.0e-309
>>>

I looked and it turns out that Python uses atof() in the first case
(string literal encountered in a Python expression) and strtod() in
the second case (string passed to float()).

Apparently strtod() and atof() differ in implementation, even though
the Solaris man page says "The atof(str) function call is equivalent
to strtod(str, (char **)NULL)."

We could fix this by changing float() to do its own syntax checking
and then use atof()...  Is it worth it?

--Guido van Rossum (home page: http://www.python.org/~guido/)




From guido@python.org  Fri Mar 24 15:03:05 2000
From: guido@python.org (guido@python.org)
Date: Fri, 24 Mar 2000 10:03:05 -0500 (EST)
Subject: [Python-bugs-list] build on NeXTStep (PR#240)
Message-ID: <20000324150305.A5AAF1CF56@dinsdale.python.org>

> I'm building Python on NeXTStep; I've encountered three minor problems.
> 
> - importdl.c by default on NeXTStep allows linking with Objective-C
>   modules, which is cool.  Unfortunately, properly supporting this
>   requires adding -ObjC to the cc command line in the Makefile.
> - posixmodule.c doesn't #include anything that declares fsync() and
>   doesn't declare it itself, but tries to reference it.  Adding a
>   declaration of fsync() fixes the problem.
> - test_strftime and test_time fail.
>   test test_strftime failed -- Writing: 'Conflict for %j (julian day (001-366)):', expected: ''
>   I suspect this may be a platform bug.  Here's some of the output,
>   which is 696 lines in full:
[...]
> (and that was all of the output from test_time.  Presumably this is
> related to the strftime bugs --- perhaps the mythical Y2K leap-year bug?)
> 
> I'm afraid I'm not sure what version of NeXTStep I'm on.  'arch'
> reports 'hppa'; 'cc --version' reports '2.5.8'; 'uname -a' reports
> 'Command not found'.
> 
> I'm not trying to build a very sophisticated environment --- just the
> defaults.

Kragen,

Can you send us some patches?  We don't have a NextStep system around
to test any of this, and your description of the problem doesn't help
me to create fixes that will certainly work for you.

There's probably not much you can do about the strftime problem --
just don't use time.strftime()! :-)

Please read python.org/patches for info on how to submit patches.
Thanks for contributing!

--Guido van Rossum (home page: http://www.python.org/~guido/)




From hoehle@tzd.telekom.de  Fri Mar 24 15:47:09 2000
From: hoehle@tzd.telekom.de (Joerg-Cyril Hoehle)
Date: Fri, 24 Mar 2000 16:47:09 +0100 (MET)
Subject: socket.onnect() RE: [Python-bugs-list] <dict>.has_key() allows more than one argument (PR#210)
Message-ID: <200003241547.QAA13048@w9f01006.dmst02.telekom.de>

Hi,

Guido wrote:
>> was a late addition to Python (it implicitly converts "1, 2" to a tuple),
>> and if you can use
>The form without the extra parentheses passes two arguments to the
>has_key() method.  I'd like to exclude this syntax -- just like
>list.append(1, 2), which also currently means list.append((1, 2)), but
>which should really be disallowed because the user could easily have
>intended list.extend([1, 2]).  (Excluding the latter is not so easy
>because it would break existing sloppy code; for Python 1.6 I think we
>can afford such breakage.)

>was changed, but not all built-ins were fixed.

[I just browsed the site for bugs about asyncore.py and hit this thread...]

Similarly, I'd like to report that in Python 1.4 & 1.5.2,
I noticed that socket.connect() also allows two syntaxes:

socket.connect("localhost",80) and connect(("localhost",80))

Only the latter is currently documented.

The difference cost me a couple of hours of debugging, since asyncore
provides an own connect() with only one argument and I didn't understand
why my connects sometimes worked and sometimes barfed :-(

So please, check the existing code for similar places and either
disallow them all (if I understood the thread correctly, Guido prefers
only a single way, I agree with this), or document both possibilities.

list.append() with multiple arguments as in Lisp would be practical I
bet, but that's a different story (Tim showed in the thread that
asyncore.py uses such a call to append).

Tim wrote:
>acts like Python list.extend([1, 2]).  So that's all the more reason to
>invoke "in the face of ambiguity, refuse the temptation to guess".

Sometimes I believe my english is not good enough to understand Tim's
posts. I'd comment that it's better to avoid the puzzling about the
ambiguity, like about the two different connects() above.  Functions
defined in Python itself wouldn't allow such an ambiguity and require
either one, or two arguments. Please avoid the loss of time to
programmers like me who try to understand what is right when apparently
presented two almost equal interfaces which lead to puzzling bugs.

Regards,
	J"org H"ohle
hoehle@tzd.telekom.de --/ Funktionssicherheit/Reliability
Technologiezentrum T-Nova GmbH/Telekom Research Center


From guido@python.org  Fri Mar 24 20:22:08 2000
From: guido@python.org (Guido van Rossum)
Date: Fri, 24 Mar 2000 15:22:08 -0500
Subject: socket.onnect() RE: [Python-bugs-list] <dict>.has_key() allows more than one argument (PR#210)
In-Reply-To: Your message of "Fri, 24 Mar 2000 16:47:09 +0100."
 <200003241547.QAA13048@w9f01006.dmst02.telekom.de>
References: <200003241547.QAA13048@w9f01006.dmst02.telekom.de>
Message-ID: <200003242022.PAA27943@eric.cnri.reston.va.us>

> [I just browsed the site for bugs about asyncore.py and hit this thread...]
> 
> Similarly, I'd like to report that in Python 1.4 & 1.5.2,
> I noticed that socket.connect() also allows two syntaxes:
> 
> socket.connect("localhost",80) and connect(("localhost",80))
> 
> Only the latter is currently documented.
> 
> The difference cost me a couple of hours of debugging, since asyncore
> provides an own connect() with only one argument and I didn't understand
> why my connects sometimes worked and sometimes barfed :-(
> 
> So please, check the existing code for similar places and either
> disallow them all (if I understood the thread correctly, Guido prefers
> only a single way, I agree with this), or document both possibilities.
> 
> list.append() with multiple arguments as in Lisp would be practical I
> bet, but that's a different story (Tim showed in the thread that
> asyncore.py uses such a call to append).
> 
> Tim wrote:
> >acts like Python list.extend([1, 2]).  So that's all the more reason to
> >invoke "in the face of ambiguity, refuse the temptation to guess".
> 
> Sometimes I believe my english is not good enough to understand Tim's
> posts. I'd comment that it's better to avoid the puzzling about the
> ambiguity, like about the two different connects() above.  Functions
> defined in Python itself wouldn't allow such an ambiguity and require
> either one, or two arguments. Please avoid the loss of time to
> programmers like me who try to understand what is right when apparently
> presented two almost equal interfaces which lead to puzzling bugs.

Thanks for your reminder -- yes, socket.connect() and friends should
only allow a single argument.  Unfortunately it's not quite so easy as
it was for list.append() to fix this one, but I'll fix it...

--Guido van Rossum (home page: http://www.python.org/~guido/)


From tim_one@email.msn.com  Sat Mar 25 03:48:50 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Fri, 24 Mar 2000 22:48:50 -0500
Subject: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
In-Reply-To: <20000324094953.954D51CF2D@dinsdale.python.org>
Message-ID: <000d01bf960d$092c4260$752d153f@tim>

[atof and strtod act differently given denormals on both Windows &
 Solaris]

[Guido]
> ...
> Apparently strtod() and atof() differ in implementation, even though
> the Solaris man page says "The atof(str) function call is equivalent
> to strtod(str, (char **)NULL)."

Ya, their man page is lying.  atof() existed in the mists of prehistory and
typically did no error checking at all.  IIRC, ANSI C introduced strtod(),
which generally got implemented as a layer of error-checking around atof.

I have to take it back that this is a bug in MS's strtod:  DBL_MIN is MS's
limits.h is 2.2250738585072014e-308, so strtod() *should* gripe on non-zero
inputs with absolute value smaller than that.

> We could fix this by changing float() to do its own syntax checking
> and then use atof()...  Is it worth it?

Depends on your goal <wink>:  do you want more extreme cases, like 1e-500,
to blow up (strtod) or underflow to 0 (atof)?  The example in the original
test case is subtler because atof made it *appear* to be "a regular old
number"; in fact, it's not, it's small enough that it falls into 754's
"denormalized" range.  This means the conversion loses some extraordinary
amount of-- but not all --information (whereas 1e-500 is below even the
denorm range:  conversion loses all information).

Without a coherent strategy for dealing with 754 issues, it's hard to decide
which is better.  Since strtod() is more restrictive, if this is worth
bothering about at all now (for P3K I think 754 needs to be taken
seriously), I actually recommend changing  current atof() calls to use
native strtod() instead.




From tim_one@email.msn.com  Sat Mar 25 03:46:40 2000
From: tim_one@email.msn.com (tim_one@email.msn.com)
Date: Fri, 24 Mar 2000 22:46:40 -0500 (EST)
Subject: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
Message-ID: <20000325034640.1F9C91CFB3@dinsdale.python.org>

[atof and strtod act differently given denormals on both Windows &
 Solaris]

[Guido]
> ...
> Apparently strtod() and atof() differ in implementation, even though
> the Solaris man page says "The atof(str) function call is equivalent
> to strtod(str, (char **)NULL)."

Ya, their man page is lying.  atof() existed in the mists of prehistory and
typically did no error checking at all.  IIRC, ANSI C introduced strtod(),
which generally got implemented as a layer of error-checking around atof.

I have to take it back that this is a bug in MS's strtod:  DBL_MIN is MS's
limits.h is 2.2250738585072014e-308, so strtod() *should* gripe on non-zero
inputs with absolute value smaller than that.

> We could fix this by changing float() to do its own syntax checking
> and then use atof()...  Is it worth it?

Depends on your goal <wink>:  do you want more extreme cases, like 1e-500,
to blow up (strtod) or underflow to 0 (atof)?  The example in the original
test case is subtler because atof made it *appear* to be "a regular old
number"; in fact, it's not, it's small enough that it falls into 754's
"denormalized" range.  This means the conversion loses some extraordinary
amount of-- but not all --information (whereas 1e-500 is below even the
denorm range:  conversion loses all information).

Without a coherent strategy for dealing with 754 issues, it's hard to decide
which is better.  Since strtod() is more restrictive, if this is worth
bothering about at all now (for P3K I think 754 needs to be taken
seriously), I actually recommend changing  current atof() calls to use
native strtod() instead.






From guido@python.org  Sat Mar 25 04:12:27 2000
From: guido@python.org (guido@python.org)
Date: Fri, 24 Mar 2000 23:12:27 -0500 (EST)
Subject: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
Message-ID: <20000325041227.403D11CFB2@dinsdale.python.org>

> [atof and strtod act differently given denormals on both Windows &
>  Solaris]
> 
> [Guido]
> > ...
> > Apparently strtod() and atof() differ in implementation, even though
> > the Solaris man page says "The atof(str) function call is equivalent
> > to strtod(str, (char **)NULL)."

[Tim]
> Ya, their man page is lying.  atof() existed in the mists of prehistory and
> typically did no error checking at all.  IIRC, ANSI C introduced strtod(),
> which generally got implemented as a layer of error-checking around atof.
> 
> I have to take it back that this is a bug in MS's strtod:  DBL_MIN is MS's
> limits.h is 2.2250738585072014e-308, so strtod() *should* gripe on non-zero
> inputs with absolute value smaller than that.
> 
> > We could fix this by changing float() to do its own syntax checking
> > and then use atof()...  Is it worth it?
> 
> Depends on your goal <wink>:  do you want more extreme cases, like 1e-500,
> to blow up (strtod) or underflow to 0 (atof)?  The example in the original
> test case is subtler because atof made it *appear* to be "a regular old
> number"; in fact, it's not, it's small enough that it falls into 754's
> "denormalized" range.  This means the conversion loses some extraordinary
> amount of-- but not all --information (whereas 1e-500 is below even the
> denorm range:  conversion loses all information).
> 
> Without a coherent strategy for dealing with 754 issues, it's hard to decide
> which is better.  Since strtod() is more restrictive, if this is worth
> bothering about at all now (for P3K I think 754 needs to be taken
> seriously), I actually recommend changing  current atof() calls to use
> native strtod() instead.

Hm, I'm not so sure.  Suppose I'm writing a program that reads a data
files generated by some Fortran program.  The Fortran program is
giving me points to plot for example.  If Fortran manages to output
1e-500, wouldn't it make more sense if I rounded that to zero instead
of rejecting it?  After all, after converting to plot precision it's
going to be zero anyway.

This way I could almost defend using strtod() for literals in
Python source code (where it makes more sense to warn about underflow)
but atof() for input.  Except that of course input could conceivably
be using eval()...

Another argument for turning underflow into zero is that that also
happens in regular arithmetic:

>>> 0.1**2**8
1.0000000000000275e-256
>>> 0.1**2**9
0.0

I like this uniform behavior: overflow -> exception, underflow ->
zero.  My calculator does this too.

Am I hopelessly naive about this?  What else can we do?  What control
does C give?  What does sscanf() do?

--Guido van Rossum (home page: http://www.python.org/~guido/)




From tim_one@email.msn.com  Sat Mar 25 04:51:03 2000
From: tim_one@email.msn.com (tim_one@email.msn.com)
Date: Fri, 24 Mar 2000 23:51:03 -0500 (EST)
Subject: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
Message-ID: <20000325045103.0C87D1CFB4@dinsdale.python.org>

"In the face of ambiguity, refuse the temptation to guess".

That's one of the Pythonic Theses you're tempted to ignore too often <wink>.

Part of taking 754 seriously is that 754 gives the user complete control
over what happens in case of exceptions (including underflow):  ignore them,
raise a fatal error, or simply set a flag saying it occurred.
Unfortunately, we have to wait for C9x until there's a portable way to get
at that stuff.  Before then, it requires wildly varying platform-specific
hair.

> Hm, I'm not so sure.  Suppose I'm writing a program that reads a data
> files generated by some Fortran program.  The Fortran program is
> giving me points to plot for example.  If Fortran manages to output
> 1e-500, wouldn't it make more sense if I rounded that to zero instead
> of rejecting it?

This *may* make good sense if Python had certain knowledge that the program
is merely going to plot the points, but probably not even then.  That is,
"insignificantly small" is relative to the application, and e.g. for all we
know the Fortran program generated a million doubles *all* in the range
[1e-500, 10e-500]:  the intended plot of the data could very well be a
pointillistic version of the Mona Lisa rather than a straight line.

> After all, after converting to plot precision it's
> going to be zero anyway.

As above, this conclusion relies on the dubious assumption that 1e-500 is
very much smaller than the other values.

> This way I could almost defend using strtod() for literals in
> Python source code (where it makes more sense to warn about underflow)
> but atof() for input.  Except that of course input could conceivably
> be using eval()...
>
> Another argument for turning underflow into zero is that that also
> happens in regular arithmetic:
>
> >>> 0.1**2**8
> 1.0000000000000275e-256
> >>> 0.1**2**9
> 0.0

Which is often desired but sometimes a disaster -- the language simply can't
guess.  On whatever machine you ran this on, it almost certainly set the
"underflow happened" flag but continued on because the underflow exception
was masked out by default.

> I like this uniform behavior: overflow -> exception, underflow ->
> zero.  My calculator does this too.

Not mine <wink>.  Really, whether underflow gripes is controlled by a
user-settable flag on high end HP calculators.  Note too that neither does
float *overflow* raise an exception under most Pythons today:

D:\Python>python
Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> 1e500
1.#INF
>>> 1e200**2
1.#INF
>>>

I personally favor raising exceptions (by default) on 754's overflow, divide
by 0, and invalid operation conditions, while (again by default) letting
underflow and inexact pass without comment.  But it again requires fiddling
the HW's 754 control registers to make that happen.  P3K, not now.

> Am I hopelessly naive about this?

Not *entirely* hopeless, but close <wink>.  If we ever talk about it for an
hour, I'll convince you of the futility of fighting 754.  They beat all
resistance out of me in a mere decade <0.5 wink>.

> What else can we do?

Not much!  Switching uniformly to either atof() or strtod() would be OK by
me for now, although I don't think patching over the current inconsistency
buys enough bang for the buck to be worth the effort.

> What control does C give?

None, until C9X.

> What does sscanf() do?

I don't care -- ANSI C predated 754's absolute universal triumph, and ANSI
C's numerics fight the *right* thing to do now just about every step of the
way.  C9x is supposed to fix all that.

In the meantime, I think what JPython does is much more interesting (but
don't know what that is):  whatever we do here should be consistent with The
Other Python too, and Java has a much better 754 story than ANSI C.  754 is
here to stay, but the last iteration of ANSI C isn't.  Best guess is that
Java acts more like atof than strtod in this case.






From jeffallen@sourcenet.org  Sat Mar 25 06:17:32 2000
From: jeffallen@sourcenet.org (jeffallen@sourcenet.org)
Date: Sat, 25 Mar 2000 01:17:32 -0500 (EST)
Subject: [Python-bugs-list] Would you like to save 30% on your phone bills and... (PR#248)
Message-ID: <20000325061732.7384C1CF75@dinsdale.python.org>

To be removed from this mailing list immediately press reply and enter REMOVE on the subject line.

Would you like some information on saving 30% on your Phone bills each month and how to get up to 8% back each month on your Utilities including phone. This service works for both business and residential. Sign up is FREE

Reply with "MORE INFO" in the subject field





From lisa21@edmail.com  Sat Mar 25 08:28:24 2000
From: lisa21@edmail.com (lisa21@edmail.com)
Date: Sat, 25 Mar 2000 03:28:24 -0500 (EST)
Subject: [Python-bugs-list] Expose your business to the Internet (PR#249)
Message-ID: <20000325082824.1E3BB1CFB7@dinsdale.python.org>

PUT EMAIL MARKETING TO WORK FOR YOU...

Call NOW and receive 50,000
FREE emails with your order!

WE HAVE OPT-IN LISTS!!!!

see below for removal.

Special Ends Friday March 31, 2000

MLM'ers, We can build your downline.

Imagine having a product or idea and selling it
for only $10.

Now imagine sending an ad for your product or idea
to 25 million people!

If you only get a 1/10 of 1% response
you have just made $250,000!!

You hear about people getting rich off
the Internet everyday on TV,
now is the perfect time for you
to jump in on all the action.

FACT.
With the introduction of the Internet, one primary
KEY to conducting your business successfully is
creating massive exposure in a cost effective
manner.

FACT.
The experts agree that email marketing is one of
the most cost effective forms of promotion in
existence today.

Electronic mail has overtaken the telephone as the
primary means of business communication.(American
Management Association)

Of online users 41 percent check their email daily.

"A gold mine for those who can take advantage of
bulk email programs"- The New York Times

"Email is an incredible lead generation tool"
-Crains Magazine

"Blows away traditional Mailing"-Advertising Age

"It's truly arrived. Email is the killer app so
far in the online world"-Kate Delhagen, Forrester
Research Analyst

Why not let a professional company handle your
direct email marketing efforts for you?

*We will assist you in developing your entire
campaign!

*We can even create your ad or annoucement for
you!

*No responses? We resend at no cost!

For More Information CALL NOW-702-248-1043


For removal see below.

SPECIAL RATES
SPECIAL ENDS Friday March 31, 2000

Targeted Rates Upon Request.

BONUS!!!
Call In and receive 50,000 Extra Emails at
No Cost!

Call NOW - 702-248-1043








++++++++++++++++++++++++++++++++++++++++++++++++++
We are terribly sorry if you received this message
in error.
If you wish to be removed. Please, type "REMOVE"
in the subject line:   outnow@fiberia.com

++++++++++++++++++++++++++++++++++++++++++++++++++





From guido@python.org  Sat Mar 25 19:13:52 2000
From: guido@python.org (guido@python.org)
Date: Sat, 25 Mar 2000 14:13:52 -0500 (EST)
Subject: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
Message-ID: <20000325191352.050DC1CFD0@dinsdale.python.org>

> "In the face of ambiguity, refuse the temptation to guess".
> 
> That's one of the Pythonic Theses you're tempted to ignore too often <wink>.
> 
> Part of taking 754 seriously is that 754 gives the user complete control
> over what happens in case of exceptions (including underflow):  ignore them,
> raise a fatal error, or simply set a flag saying it occurred.
> Unfortunately, we have to wait for C9x until there's a portable way to get
> at that stuff.  Before then, it requires wildly varying platform-specific
> hair.

OK, so let's stick with the defaults that 754 presecribes until we can
give the user control.  That's the purpose of defaults, right?

> > Hm, I'm not so sure.  Suppose I'm writing a program that reads a data
> > files generated by some Fortran program.  The Fortran program is
> > giving me points to plot for example.  If Fortran manages to output
> > 1e-500, wouldn't it make more sense if I rounded that to zero instead
> > of rejecting it?
> 
> This *may* make good sense if Python had certain knowledge that the program
> is merely going to plot the points, but probably not even then.  That is,
> "insignificantly small" is relative to the application, and e.g. for all we
> know the Fortran program generated a million doubles *all* in the range
> [1e-500, 10e-500]:  the intended plot of the data could very well be a
> pointillistic version of the Mona Lisa rather than a straight line.

OK, forget the example.

> > After all, after converting to plot precision it's
> > going to be zero anyway.
> 
> As above, this conclusion relies on the dubious assumption that 1e-500 is
> very much smaller than the other values.

I think even 754 tells us that 1e-500 is smaller than what we normally
need to deal with.

> > This way I could almost defend using strtod() for literals in
> > Python source code (where it makes more sense to warn about underflow)
> > but atof() for input.  Except that of course input could conceivably
> > be using eval()...
> >
> > Another argument for turning underflow into zero is that that also
> > happens in regular arithmetic:
> >
> > >>> 0.1**2**8
> > 1.0000000000000275e-256
> > >>> 0.1**2**9
> > 0.0
> 
> Which is often desired but sometimes a disaster -- the language simply can't
> guess.  On whatever machine you ran this on, it almost certainly set the
> "underflow happened" flag but continued on because the underflow exception
> was masked out by default.

Again: 754 gives a default.  I want to conform to the default -- it's
better to provide control, but even when we provide control, there will
still be default behavior, and (if I understand 754 correctly) the
default is not to interrupt for underflow.

> > I like this uniform behavior: overflow -> exception, underflow ->
> > zero.  My calculator does this too.
> 
> Not mine <wink>.  Really, whether underflow gripes is controlled by a
> user-settable flag on high end HP calculators.  Note too that neither does
> float *overflow* raise an exception under most Pythons today:
> 
> D:\Python>python
> Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>> 1e500
> 1.#INF
> >>> 1e200**2
> 1.#INF
> >>>

Oops, you're right.  Must be another 754 default behavior!

> I personally favor raising exceptions (by default) on 754's overflow, divide
> by 0, and invalid operation conditions, while (again by default) letting
> the HW's 754 control registers to make that happen.  P3K, not now.

I would personally also prefer an exception for overflow.  You don't
say what you want for underflow though.  I still like silent underflow
to zero by default.

> > Am I hopelessly naive about this?
> 
> Not *entirely* hopeless, but close <wink>.  If we ever talk about it for an
> hour, I'll convince you of the futility of fighting 754.  They beat all
> resistance out of me in a mere decade <0.5 wink>.

I'm not fighting it.  Say the ideal Python has full user control over
fp exceptions.  What should the defaults be?  Python 1.6 should have
the same defaults, even if it doesn't have the controls.

> > What else can we do?
> 
> Not much!  Switching uniformly to either atof() or strtod() would be OK by
> me for now, although I don't think patching over the current inconsistency
> buys enough bang for the buck to be worth the effort.
> 
> > What control does C give?
> 
> None, until C9X.
> 
> > What does sscanf() do?
> 
> I don't care -- ANSI C predated 754's absolute universal triumph, and ANSI
> C's numerics fight the *right* thing to do now just about every step of the
> way.  C9x is supposed to fix all that.
> 
> In the meantime, I think what JPython does is much more interesting (but
> don't know what that is):  whatever we do here should be consistent with The
> Other Python too, and Java has a much better 754 story than ANSI C.  754 is
> here to stay, but the last iteration of ANSI C isn't.  Best guess is that
> Java acts more like atof than strtod in this case.

Bingo.  Indeed it does.  1e500 prints as Infinity; 1e-500 is 0.0,
either as literal or when converted from a string.

I'll change float() to use atof().

--Guido van Rossum (home page: http://www.python.org/~guido/)




From carrie.neptune@eudoramail.com  Tue Mar 28 02:20:22 2000
From: carrie.neptune@eudoramail.com (carrie.neptune@eudoramail.com)
Date: Mon, 27 Mar 2000 21:20:22 -0500 (EST)
Subject: [Python-bugs-list] Email Advertising Special--Ends Friday (PR#250)
Message-ID: <20000328022022.176FC1CE10@dinsdale.python.org>

PUT EMAIL MARKETING TO WORK FOR YOU...

Call NOW and receive 50,000
additional emails with your order
for only $100. Thats 40,000 FREE emails!!!

WE HAVE OPT-IN LISTS!!!!

see below for removal.

Special Ends Friday March 31, 2000

MLM'ers, We can build your downline.

Imagine having a product or idea and selling it
for only $10.

Now imagine sending an ad for your product or idea
to 25 million people!

If you only get a 1/10 of 1% response
you have just made $250,000!!

You hear about people getting rich off
the Internet everyday on TV,
now is the perfect time for you
to jump in on all the action.

FACT.
With the introduction of the Internet, one primary
KEY to conducting your business successfully is
creating massive exposure in a cost effective
manner.

FACT.
The experts agree that email marketing is one of
the most cost effective forms of promotion in
existence today.

Electronic mail has overtaken the telephone as the
primary means of business communication.(American
Management Association)

Of online users 41 percent check their email daily.

"A gold mine for those who can take advantage of
bulk email programs"- The New York Times

"Email is an incredible lead generation tool"
-Crains Magazine

"Blows away traditional Mailing"-Advertising Age

"It's truly arrived. Email is the killer app so
far in the online world"-Kate Delhagen, Forrester
Research Analyst

Why not let a professional company handle your
direct email marketing efforts for you?

*We will assist you in developing your entire
campaign!

*We can even create your ad or annoucement for
you!

*No responses? We resend at no cost!

For More Information CALL NOW-702-248-1043


For removal see below.

SPECIAL RATES
SPECIAL ENDS Friday March 31, 2000

Targeted Rates Upon Request.

BONUS!!!
Call In and receive 50,000 Extra Emails at
No Cost!

Call NOW - 702-248-1043








++++++++++++++++++++++++++++++++++++++++++++++++++
We are terribly sorry if you received this message
in error.
If you wish to be removed. Please, type "REMOVE"
in the subject line:   outnow@fiberia.com

++++++++++++++++++++++++++++++++++++++++++++++++++





From carrie.neptune@eudoramail.com  Tue Mar 28 02:30:40 2000
From: carrie.neptune@eudoramail.com (carrie.neptune@eudoramail.com)
Date: Mon, 27 Mar 2000 21:30:40 -0500 (EST)
Subject: [Python-bugs-list] Expose your business to the Internet (PR#251)
Message-ID: <20000328023040.CD87D1CE0B@dinsdale.python.org>

PUT EMAIL MARKETING TO WORK FOR YOU...

Call NOW and receive 50,000
additional emails with your order
for only $100. Thats 40,000 FREE emails!!!

WE HAVE OPT-IN LISTS!!!!

see below for removal.

Special Ends Friday March 31, 2000

MLM'ers, We can build your downline.

Imagine having a product or idea and selling it
for only $10.

Now imagine sending an ad for your product or idea
to 25 million people!

If you only get a 1/10 of 1% response
you have just made $250,000!!

You hear about people getting rich off
the Internet everyday on TV,
now is the perfect time for you
to jump in on all the action.

FACT.
With the introduction of the Internet, one primary
KEY to conducting your business successfully is
creating massive exposure in a cost effective
manner.

FACT.
The experts agree that email marketing is one of
the most cost effective forms of promotion in
existence today.

Electronic mail has overtaken the telephone as the
primary means of business communication.(American
Management Association)

Of online users 41 percent check their email daily.

"A gold mine for those who can take advantage of
bulk email programs"- The New York Times

"Email is an incredible lead generation tool"
-Crains Magazine

"Blows away traditional Mailing"-Advertising Age

"It's truly arrived. Email is the killer app so
far in the online world"-Kate Delhagen, Forrester
Research Analyst

Why not let a professional company handle your
direct email marketing efforts for you?

*We will assist you in developing your entire
campaign!

*We can even create your ad or annoucement for
you!

*No responses? We resend at no cost!

For More Information CALL NOW-702-248-1043


For removal see below.

SPECIAL RATES
SPECIAL ENDS Friday March 31, 2000

Targeted Rates Upon Request.

BONUS!!!
Call In and receive 50,000 Extra Emails at
No Cost!

Call NOW - 702-248-1043








++++++++++++++++++++++++++++++++++++++++++++++++++
We are terribly sorry if you received this message
in error.
If you wish to be removed. Please, type "REMOVE"
in the subject line:   outnow@fiberia.com

++++++++++++++++++++++++++++++++++++++++++++++++++





From kragen@pobox.com  Tue Mar 28 17:43:00 2000
From: kragen@pobox.com (kragen@pobox.com)
Date: Tue, 28 Mar 2000 12:43:00 -0500 (EST)
Subject: [Python-bugs-list] build on NeXTStep (PR#240)
Message-ID: <20000328174300.C6B791CE63@dinsdale.python.org>

Guido writes:
> [Kragen wrote:]
> > I'm afraid I'm not sure what version of NeXTStep I'm on.  'arch'
> > reports 'hppa'; 'cc --version' reports '2.5.8'; 'uname -a' reports
> > 'Command not found'.

It's NeXTStep 3.3.

> Can you send us some patches?  We don't have a NextStep system around
> to test any of this, and your description of the problem doesn't help
> me to create fixes that will certainly work for you.

I can send a patch for importdl.c; the right thing to do for this would
be to modify the Makefile to change the flags passed to the compiler to
include -ObjC, but I don't know how to do that.  My solution was to
change a #define in the source to turn off the ability to import
Objective-C modules, which is obviously far from optimal --- thus my
failure to include a patch for this in the first email.

In posixmodule.c, which needs fsync() declared, I'm not sure where to
declare it.  I can certainly supply a patch that works for NeXTStep
3.3, but I don't understand the rat's-nest of #ifdefs there well enough
to be sure it won't break compilation on some other platform, or even
another version of NeXTStep --- thus my failure to include a patch for
this in the first email.

So I can send patches for both of these, but I am not sure if I should.

> Please read python.org/patches for info on how to submit patches.

Thanks.

-- 
<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08.  Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.html>
The power didn't go out on 2000-01-01 either.  :)





From guido@python.org  Tue Mar 28 19:41:28 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 28 Mar 2000 14:41:28 -0500
Subject: [Python-bugs-list] build on NeXTStep (PR#240)
In-Reply-To: Your message of "Tue, 28 Mar 2000 12:43:00 EST."
 <20000328174300.C6B791CE63@dinsdale.python.org>
References: <20000328174300.C6B791CE63@dinsdale.python.org>
Message-ID: <200003281941.OAA05170@eric.cnri.reston.va.us>

> It's NeXTStep 3.3.
> 
> > Can you send us some patches?  We don't have a NextStep system around
> > to test any of this, and your description of the problem doesn't help
> > me to create fixes that will certainly work for you.
> 
> I can send a patch for importdl.c; the right thing to do for this would
> be to modify the Makefile to change the flags passed to the compiler to
> include -ObjC, but I don't know how to do that.  My solution was to
> change a #define in the source to turn off the ability to import
> Objective-C modules, which is obviously far from optimal --- thus my
> failure to include a patch for this in the first email.
> 
> In posixmodule.c, which needs fsync() declared, I'm not sure where to
> declare it.  I can certainly supply a patch that works for NeXTStep
> 3.3, but I don't understand the rat's-nest of #ifdefs there well enough
> to be sure it won't break compilation on some other platform, or even
> another version of NeXTStep --- thus my failure to include a patch for
> this in the first email.
> 
> So I can send patches for both of these, but I am not sure if I should.

Maybe we should just drop it?  I don't think NextStep 3.3 has much
future or even much current use, does it?  it's only supported for
historic reasons.  If you get it to work, fine -- but I don't think
the general public would benefit much from adding NS 3.3 support...

Or am I wrong?

--Guido van Rossum (home page: http://www.python.org/~guido/)


From guido@python.org  Tue Mar 28 19:39:17 2000
From: guido@python.org (guido@python.org)
Date: Tue, 28 Mar 2000 14:39:17 -0500 (EST)
Subject: [Python-bugs-list] build on NeXTStep (PR#240)
Message-ID: <20000328193917.7E9831CE71@dinsdale.python.org>

> It's NeXTStep 3.3.
> 
> > Can you send us some patches?  We don't have a NextStep system around
> > to test any of this, and your description of the problem doesn't help
> > me to create fixes that will certainly work for you.
> 
> I can send a patch for importdl.c; the right thing to do for this would
> be to modify the Makefile to change the flags passed to the compiler to
> include -ObjC, but I don't know how to do that.  My solution was to
> change a #define in the source to turn off the ability to import
> Objective-C modules, which is obviously far from optimal --- thus my
> failure to include a patch for this in the first email.
> 
> In posixmodule.c, which needs fsync() declared, I'm not sure where to
> declare it.  I can certainly supply a patch that works for NeXTStep
> 3.3, but I don't understand the rat's-nest of #ifdefs there well enough
> to be sure it won't break compilation on some other platform, or even
> another version of NeXTStep --- thus my failure to include a patch for
> this in the first email.
> 
> So I can send patches for both of these, but I am not sure if I should.

Maybe we should just drop it?  I don't think NextStep 3.3 has much
future or even much current use, does it?  it's only supported for
historic reasons.  If you get it to work, fine -- but I don't think
the general public would benefit much from adding NS 3.3 support...

Or am I wrong?

--Guido van Rossum (home page: http://www.python.org/~guido/)




From carey@zxmail.com  Wed Mar 29 04:42:26 2000
From: carey@zxmail.com (carey@zxmail.com)
Date: Tue, 28 Mar 2000 23:42:26 -0500 (EST)
Subject: [Python-bugs-list] Email Advertising Works--Special Rates till Friday (PR#252)
Message-ID: <20000329044226.E2B7B1CE9E@dinsdale.python.org>

PUT EMAIL MARKETING TO WORK FOR YOU...

Call NOW and receive 50,000
additional emails with your order
for only $100. Thats 40,000 FREE emails!!!

WE HAVE OPT-IN LISTS!!!!

see below for removal.

Special Ends Friday March 31, 2000

MLM'ers, We can build your downline.

Imagine having a product or idea and selling it
for only $10.

Now imagine sending an ad for your product or idea
to 25 million people!

If you only get a 1/10 of 1% response
you have just made $250,000!!

You hear about people getting rich off
the Internet everyday on TV,
now is the perfect time for you
to jump in on all the action.

FACT.
With the introduction of the Internet, one primary
KEY to conducting your business successfully is
creating massive exposure in a cost effective
manner.

FACT.
The experts agree that email marketing is one of
the most cost effective forms of promotion in
existence today.

Electronic mail has overtaken the telephone as the
primary means of business communication.(American
Management Association)

Of online users 41 percent check their email daily.

"A gold mine for those who can take advantage of
bulk email programs"- The New York Times

"Email is an incredible lead generation tool"
-Crains Magazine

"Blows away traditional Mailing"-Advertising Age

"It's truly arrived. Email is the killer app so
far in the online world"-Kate Delhagen, Forrester
Research Analyst

Why not let a professional company handle your
direct email marketing efforts for you?

*We will assist you in developing your entire
campaign!

*We can even create your ad or annoucement for
you!

*No responses? We resend at no cost!

For More Information CALL NOW-702-248-1043


For removal see below.

SPECIAL RATES
SPECIAL ENDS Friday March 31, 2000

Targeted Rates Upon Request.

BONUS!!!
Call In and receive 50,000 Extra Emails at
No Cost!

Call NOW - 702-248-1043








++++++++++++++++++++++++++++++++++++++++++++++++++
We are terribly sorry if you received this message
in error.
If you wish to be removed. Please, type "REMOVE"
in the subject line:   outnow@fiberia.com

++++++++++++++++++++++++++++++++++++++++++++++++++





From m.favas@per.dem.csiro.au  Thu Mar 30 05:16:08 2000
From: m.favas@per.dem.csiro.au (m.favas@per.dem.csiro.au)
Date: Thu, 30 Mar 2000 00:16:08 -0500 (EST)
Subject: [Python-bugs-list] possible bug in CVS ceval.c of 30 March (PR#253)
Message-ID: <20000330051608.758BD1CDF2@dinsdale.python.org>

Full_Name: Mark Favas
Version: 1.5.2+
OS: Tru64 Unix
Submission from: groucho.per.dem.csiro.au (130.116.27.1)


Building CVS Python 1.5.2+ of 30 March 200 on Tru64 Unix (V4.0 1229 alpha) with
Compaq C (Compaq C V6.1-110 (dtk) on Digital UNIX V4.0F) results in the
following
warning:

cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H   -c ceval.c -o ceval.o
cc: Warning: ceval.c, line 1670: The scalar variable "args" is fetched but not
initialized.  And there may be other such fetches of this variable that have
not
been reported in this compilation. (uninit1)
                                Py_DECREF(args);
--------------------------------^

Looking at the code, args is defined at the start of the function as:
        PyObject **args; (line 343)
and subsequently redefined as:
                        PyObject *args; (line 1618)




From m.favas@per.dem.csiro.au  Thu Mar 30 05:21:02 2000
From: m.favas@per.dem.csiro.au (m.favas@per.dem.csiro.au)
Date: Thu, 30 Mar 2000 00:21:02 -0500 (EST)
Subject: [Python-bugs-list] Compile bug in CVS _tkinter.c of 30 March (PR#254)
Message-ID: <20000330052102.448C81CDF2@dinsdale.python.org>

Full_Name: Mark Favas
Version: 1.5.2+
OS: Tru64 Unix
Submission from: groucho.per.dem.csiro.au (130.116.27.1)


Compiling the 30 March CVS version of Python on Tru64 Unix with Compaq C
(Compaq C V6.1-110 (dtk) on Digital UNIX V4.0F  (Rev. 1229)) produces the
following error:

cc  -DWITH_APPINIT -I/usr/local/include -O -Olimit 1500 -I./../Include -I..
-DHAVE_CONFIG_H -c ./_tkinter.c
cc: Error: ./_tkinter.c, line 573: In the initializer for flags,
"TCL_EVAL_DIRECT" is not declared. (undeclared)
        int flags = TCL_EVAL_DIRECT;
--------------------^

The version of Tcl/Tk is 8.0.5 - this TCL_EVAL_DIRECT does not exist in the
Tcl/Tk header files for 8.0.5




From lk@pdi.com  Thu Mar 30 06:14:13 2000
From: lk@pdi.com (lk@pdi.com)
Date: Thu, 30 Mar 2000 01:14:13 -0500 (EST)
Subject: [Python-bugs-list] Typo in comment in Lib/user.py (PR#255)
Message-ID: <20000330061413.ACAA91CE03@dinsdale.python.org>

Full_Name: Lawrence Kesteloot
Version: 1.5.2
OS: IRIX
Submission from: as53-73.okldca.pacific.verio.net (207.20.233.73)


Lib/user.py has a comment that says that the script
pointed to by PYTHONPATH will be executed on startup.
That should say PYTHONSTARTUP.





From hilary@mail.warmmail.com  Thu Mar 30 11:28:16 2000
From: hilary@mail.warmmail.com (hilary@mail.warmmail.com)
Date: Thu, 30 Mar 2000 06:28:16 -0500 (EST)
Subject: [Python-bugs-list] Email Advertising Works--Special Rates till Friday (PR#256)
Message-ID: <20000330112816.4023C1CE58@dinsdale.python.org>

PUT EMAIL MARKETING TO WORK FOR YOU...

Call NOW and receive 50,000
additional emails with your order
for only $100. Thats 40,000 FREE emails!!!

WE HAVE OPT-IN LISTS!!!!

see below for removal.

Special Ends Friday March 31, 2000

MLM'ers, We can build your downline.

Imagine having a product or idea and selling it
for only $10.

Now imagine sending an ad for your product or idea
to 25 million people!

If you only get a 1/10 of 1% response
you have just made $250,000!!

You hear about people getting rich off
the Internet everyday on TV,
now is the perfect time for you
to jump in on all the action.

FACT.
With the introduction of the Internet, one primary
KEY to conducting your business successfully is
creating massive exposure in a cost effective
manner.

FACT.
The experts agree that email marketing is one of
the most cost effective forms of promotion in
existence today.

Electronic mail has overtaken the telephone as the
primary means of business communication.(American
Management Association)

Of online users 41 percent check their email daily.

"A gold mine for those who can take advantage of
bulk email programs"- The New York Times

"Email is an incredible lead generation tool"
-Crains Magazine

"Blows away traditional Mailing"-Advertising Age

"It's truly arrived. Email is the killer app so
far in the online world"-Kate Delhagen, Forrester
Research Analyst

Why not let a professional company handle your
direct email marketing efforts for you?

*We will assist you in developing your entire
campaign!

*We can even create your ad or annoucement for
you!

*No responses? We resend at no cost!

For More Information CALL NOW-702-248-1043


For removal see below.

SPECIAL RATES
SPECIAL ENDS Friday March 31, 2000

Targeted Rates Upon Request.

BONUS!!!
Call In and receive 50,000 Extra Emails at
No Cost!

Call NOW - 702-248-1043








++++++++++++++++++++++++++++++++++++++++++++++++++
We are terribly sorry if you received this message
in error.
If you wish to be removed. Please, type "REMOVE"
in the subject line:   outnow@fiberia.com

++++++++++++++++++++++++++++++++++++++++++++++++++





From hilary@mail.warmmail.com  Thu Mar 30 11:28:58 2000
From: hilary@mail.warmmail.com (hilary@mail.warmmail.com)
Date: Thu, 30 Mar 2000 06:28:58 -0500 (EST)
Subject: [Python-bugs-list] Email Advertising Works--Special Rates till Friday (PR#257)
Message-ID: <20000330112858.1826B1CE58@dinsdale.python.org>

PUT EMAIL MARKETING TO WORK FOR YOU...

Call NOW and receive 50,000
additional emails with your order
for only $100. Thats 40,000 FREE emails!!!

WE HAVE OPT-IN LISTS!!!!

see below for removal.

Special Ends Friday March 31, 2000

MLM'ers, We can build your downline.

Imagine having a product or idea and selling it
for only $10.

Now imagine sending an ad for your product or idea
to 25 million people!

If you only get a 1/10 of 1% response
you have just made $250,000!!

You hear about people getting rich off
the Internet everyday on TV,
now is the perfect time for you
to jump in on all the action.

FACT.
With the introduction of the Internet, one primary
KEY to conducting your business successfully is
creating massive exposure in a cost effective
manner.

FACT.
The experts agree that email marketing is one of
the most cost effective forms of promotion in
existence today.

Electronic mail has overtaken the telephone as the
primary means of business communication.(American
Management Association)

Of online users 41 percent check their email daily.

"A gold mine for those who can take advantage of
bulk email programs"- The New York Times

"Email is an incredible lead generation tool"
-Crains Magazine

"Blows away traditional Mailing"-Advertising Age

"It's truly arrived. Email is the killer app so
far in the online world"-Kate Delhagen, Forrester
Research Analyst

Why not let a professional company handle your
direct email marketing efforts for you?

*We will assist you in developing your entire
campaign!

*We can even create your ad or annoucement for
you!

*No responses? We resend at no cost!

For More Information CALL NOW-702-248-1043


For removal see below.

SPECIAL RATES
SPECIAL ENDS Friday March 31, 2000

Targeted Rates Upon Request.

BONUS!!!
Call In and receive 50,000 Extra Emails at
No Cost!

Call NOW - 702-248-1043








++++++++++++++++++++++++++++++++++++++++++++++++++
We are terribly sorry if you received this message
in error.
If you wish to be removed. Please, type "REMOVE"
in the subject line:   outnow@fiberia.com

++++++++++++++++++++++++++++++++++++++++++++++++++





From guido@python.org  Thu Mar 30 14:59:06 2000
From: guido@python.org (guido@python.org)
Date: Thu, 30 Mar 2000 09:59:06 -0500 (EST)
Subject: [Python-bugs-list] Typo in comment in Lib/user.py (PR#255)
Message-ID: <20000330145906.55AFB1CE8B@dinsdale.python.org>

> Lib/user.py has a comment that says that the script
> pointed to by PYTHONPATH will be executed on startup.
> That should say PYTHONSTARTUP.

Thanks!  And fixed.

--Guido van Rossum (home page: http://www.python.org/~guido/)




From guido@python.org  Thu Mar 30 20:09:21 2000
From: guido@python.org (Guido van Rossum)
Date: Thu, 30 Mar 2000 15:09:21 -0500
Subject: [Python-bugs-list] Compile bug in CVS _tkinter.c of 30 March (PR#254)
In-Reply-To: Your message of "Thu, 30 Mar 2000 00:21:02 EST."
 <20000330052102.448C81CDF2@dinsdale.python.org>
References: <20000330052102.448C81CDF2@dinsdale.python.org>
Message-ID: <200003302009.PAA22011@eric.cnri.reston.va.us>

> Compiling the 30 March CVS version of Python on Tru64 Unix with Compaq C
> (Compaq C V6.1-110 (dtk) on Digital UNIX V4.0F  (Rev. 1229)) produces the
> following error:
> 
> cc  -DWITH_APPINIT -I/usr/local/include -O -Olimit 1500 -I./../Include -I..
> -DHAVE_CONFIG_H -c ./_tkinter.c
> cc: Error: ./_tkinter.c, line 573: In the initializer for flags,
> "TCL_EVAL_DIRECT" is not declared. (undeclared)
>         int flags = TCL_EVAL_DIRECT;
> --------------------^
> 
> The version of Tcl/Tk is 8.0.5 - this TCL_EVAL_DIRECT does not exist in the
> Tcl/Tk header files for 8.0.5

Oops, the Tcl_Obj code doesn't work at all for Tcl 8.0; it uses
Tcl_EvalObjv which didn't exist before 8.1.  I'll see what I can do
quickly...

--Guido van Rossum (home page: http://www.python.org/~guido/)


From guido@python.org  Thu Mar 30 20:07:17 2000
From: guido@python.org (guido@python.org)
Date: Thu, 30 Mar 2000 15:07:17 -0500 (EST)
Subject: [Python-bugs-list] Compile bug in CVS _tkinter.c of 30 March (PR#254)
Message-ID: <20000330200717.4B2171CED2@dinsdale.python.org>

> Compiling the 30 March CVS version of Python on Tru64 Unix with Compaq C
> (Compaq C V6.1-110 (dtk) on Digital UNIX V4.0F  (Rev. 1229)) produces the
> following error:
> 
> cc  -DWITH_APPINIT -I/usr/local/include -O -Olimit 1500 -I./../Include -I..
> -DHAVE_CONFIG_H -c ./_tkinter.c
> cc: Error: ./_tkinter.c, line 573: In the initializer for flags,
> "TCL_EVAL_DIRECT" is not declared. (undeclared)
>         int flags = TCL_EVAL_DIRECT;
> --------------------^
> 
> The version of Tcl/Tk is 8.0.5 - this TCL_EVAL_DIRECT does not exist in the
> Tcl/Tk header files for 8.0.5

Oops, the Tcl_Obj code doesn't work at all for Tcl 8.0; it uses
Tcl_EvalObjv which didn't exist before 8.1.  I'll see what I can do
quickly...

--Guido van Rossum (home page: http://www.python.org/~guido/)




From m.favas@per.dem.csiro.au  Fri Mar 31 03:05:38 2000
From: m.favas@per.dem.csiro.au (m.favas@per.dem.csiro.au)
Date: Thu, 30 Mar 2000 22:05:38 -0500 (EST)
Subject: [Python-bugs-list] Compile bug in CVS mmapmodule.c of 31 March (PR#258)
Message-ID: <20000331030538.E9C611CCFA@dinsdale.python.org>

Full_Name: Mark Favas
Version: 1.5.2+ (current CVS)
OS: Tru64 Unix
Submission from: wa-proxy.csiro.au (130.116.2.3)


Compiling mmapmodule.c from CVS of 31 March 2000 on Tru64 Unix with Compaq C
version Compaq C V6.1-110 (dtk) on Digital UNIX V4.0F  (Rev. 1229) produces
the following errors:

cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./mmapmodule.c
cc: Error: ./mmapmodule.c, line 121: In this statement, "where" and "0" cannot
be compared with a relational operator. (norelational)
        if ((where >= 0) && (where < (self->data+self->size))) {
-------------^
cc: Warning: ./mmapmodule.c, line 620: In this statement, the referenced type
of
the pointer value "PyString_AsString(...)" is "char", which is not compatible
with "unsigned char". (ptrmismatch)
        buf = PyString_AsString(v);
--------^
cc: Warning: ./mmapmodule.c, line 643: In this statement, the referenced type
of
the pointer value "PyString_AsString(...)" is "char", which is not compatible
with "unsigned char". (ptrmismatch)
        buf = PyString_AsString(v);
--------^




From cpr@emsoftware.com  Fri Mar 31 16:05:35 2000
From: cpr@emsoftware.com (cpr@emsoftware.com)
Date: Fri, 31 Mar 2000 11:05:35 -0500 (EST)
Subject: [Python-bugs-list] new module "codecs" in 1.6 (PR#259)
Message-ID: <20000331160535.747CA1CD54@dinsdale.python.org>

Full_Name: Chris Ryland
Version: 1.6
OS: NT 4
Submission from: cache.1st.net (209.240.0.17)


Simple suggestion: to avoid confusion with multimedia codecs, how about naming
the codecs module unicodecs? (Nit, I realize.)




From guido@python.org  Fri Mar 31 17:48:00 2000
From: guido@python.org (Guido van Rossum)
Date: Fri, 31 Mar 2000 12:48:00 -0500
Subject: [Python-bugs-list] Compile bug in CVS mmapmodule.c of 31 March (PR#258)
In-Reply-To: Your message of "Thu, 30 Mar 2000 22:05:38 EST."
 <20000331030538.E9C611CCFA@dinsdale.python.org>
References: <20000331030538.E9C611CCFA@dinsdale.python.org>
Message-ID: <200003311748.MAA23925@eric.cnri.reston.va.us>

> Compiling mmapmodule.c from CVS of 31 March 2000 on Tru64 Unix with Compaq C
> version Compaq C V6.1-110 (dtk) on Digital UNIX V4.0F  (Rev. 1229) produces
> the following errors:
> 
> cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./mmapmodule.c
> cc: Error: ./mmapmodule.c, line 121: In this statement, "where" and "0" cannot
> be compared with a relational operator. (norelational)
>         if ((where >= 0) && (where < (self->data+self->size))) {
> -------------^
> cc: Warning: ./mmapmodule.c, line 620: In this statement, the referenced type
> of
> the pointer value "PyString_AsString(...)" is "char", which is not compatible
> with "unsigned char". (ptrmismatch)
>         buf = PyString_AsString(v);
> --------^
> cc: Warning: ./mmapmodule.c, line 643: In this statement, the referenced type
> of
> the pointer value "PyString_AsString(...)" is "char", which is not compatible
> with "unsigned char". (ptrmismatch)
>         buf = PyString_AsString(v);
> --------^

Mark, it seems that these can all be fixed with casts.  Can you
prepare a patch and mail it to patches@python.org?  If I do it, I
can't test that the patch actually works on your platform...

--Guido van Rossum (home page: http://www.python.org/~guido/)


From guido@python.org  Fri Mar 31 17:45:51 2000
From: guido@python.org (guido@python.org)
Date: Fri, 31 Mar 2000 12:45:51 -0500 (EST)
Subject: [Python-bugs-list] Compile bug in CVS mmapmodule.c of 31 March (PR#258)
Message-ID: <20000331174551.B44EC1CDB5@dinsdale.python.org>

> Compiling mmapmodule.c from CVS of 31 March 2000 on Tru64 Unix with Compaq C
> version Compaq C V6.1-110 (dtk) on Digital UNIX V4.0F  (Rev. 1229) produces
> the following errors:
> 
> cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./mmapmodule.c
> cc: Error: ./mmapmodule.c, line 121: In this statement, "where" and "0" cannot
> be compared with a relational operator. (norelational)
>         if ((where >= 0) && (where < (self->data+self->size))) {
> -------------^
> cc: Warning: ./mmapmodule.c, line 620: In this statement, the referenced type
> of
> the pointer value "PyString_AsString(...)" is "char", which is not compatible
> with "unsigned char". (ptrmismatch)
>         buf = PyString_AsString(v);
> --------^
> cc: Warning: ./mmapmodule.c, line 643: In this statement, the referenced type
> of
> the pointer value "PyString_AsString(...)" is "char", which is not compatible
> with "unsigned char". (ptrmismatch)
>         buf = PyString_AsString(v);
> --------^

Mark, it seems that these can all be fixed with casts.  Can you
prepare a patch and mail it to patches@python.org?  If I do it, I
can't test that the patch actually works on your platform...

--Guido van Rossum (home page: http://www.python.org/~guido/)




From guido@python.org  Fri Mar 31 17:46:31 2000
From: guido@python.org (guido@python.org)
Date: Fri, 31 Mar 2000 12:46:31 -0500 (EST)
Subject: [Python-bugs-list] possible bug in CVS ceval.c of 30 March (PR#253)
Message-ID: <20000331174631.227901CDB4@dinsdale.python.org>

> Building CVS Python 1.5.2+ of 30 March 200 on Tru64 Unix (V4.0 1229 alpha) with
> Compaq C (Compaq C V6.1-110 (dtk) on Digital UNIX V4.0F) results in the
> following
> warning:
> 
> cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H   -c ceval.c -o ceval.o
> cc: Warning: ceval.c, line 1670: The scalar variable "args" is fetched but not
> initialized.  And there may be other such fetches of this variable that have
> not
> been reported in this compilation. (uninit1)
>                                 Py_DECREF(args);
> --------------------------------^
> 
> Looking at the code, args is defined at the start of the function as:
>         PyObject **args; (line 343)
> and subsequently redefined as:
>                         PyObject *args; (line 1618)

Jeremy has checked in a patch that takes care of this (and a few other
things).

--Guido van Rossum (home page: http://www.python.org/~guido/)




From mal@lemburg.com  Fri Mar 31 18:45:58 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 31 Mar 2000 20:45:58 +0200
Subject: [Python-bugs-list] new module "codecs" in 1.6 (PR#259)
References: <20000331160535.747CA1CD54@dinsdale.python.org>
Message-ID: <38E4F266.C3B46A06@lemburg.com>

cpr@emsoftware.com wrote:
> 
> Full_Name: Chris Ryland
> Version: 1.6
> OS: NT 4
> Submission from: cache.1st.net (209.240.0.17)
> 
> Simple suggestion: to avoid confusion with multimedia codecs, how about naming
> the codecs module unicodecs? (Nit, I realize.)

The codecs.py module and the registry behind it are intended to
provide APIs for many different kinds of codecs -- not just
Unicode ones.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From mal@lemburg.com  Fri Mar 31 22:11:56 2000
From: mal@lemburg.com (mal@lemburg.com)
Date: Fri, 31 Mar 2000 17:11:56 -0500 (EST)
Subject: [Python-bugs-list] new module "codecs" in 1.6 (PR#259)
Message-ID: <20000331221156.4761B1CDFD@dinsdale.python.org>

cpr@emsoftware.com wrote:
> 
> Full_Name: Chris Ryland
> Version: 1.6
> OS: NT 4
> Submission from: cache.1st.net (209.240.0.17)
> 
> Simple suggestion: to avoid confusion with multimedia codecs, how about naming
> the codecs module unicodecs? (Nit, I realize.)

The codecs.py module and the registry behind it are intended to
provide APIs for many different kinds of codecs -- not just
Unicode ones.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/






From lipman@helix.nih.gov  Fri Mar 31 23:03:58 2000
From: lipman@helix.nih.gov (lipman@helix.nih.gov)
Date: Fri, 31 Mar 2000 18:03:58 -0500 (EST)
Subject: [Python-bugs-list] trouble building under Solaris 7 (PR#260)
Message-ID: <20000331230358.074421CE04@dinsdale.python.org>

Full_Name: Everett Lipman
Version: 1.5.2
OS: Solaris 7 106541-08
Submission from: sphere.niddk.nih.gov (128.231.4.194)


When I built Python on my machine:

SunOS 5.7 Generic_106541-08 sun4u sparc SUNW,Ultra-5_10

Python's internal symbols (for instance PySequence_Length) were not
included in the dynamic symbol table of the python executable.  This
prevented the Numerical-15.2 extensions from importing properly.  My
machine has both the Sun linker (in /usr/ccs/bin) and the GNU linker
installed.  I use the GNU linker, which is first in the $PATH under
which Python was built.

A workaround for this problem is to change the following line in
Modules/Makefile.pre from

LDFLAGS=

to

LDFLAGS= -export-dynamic

This will only work for the GNU linker.