Bug report - Python 3.10 from Microsoft Store - IDLE won't start

[Johan Gunnarsson via Python-list]

Hello, IDLE won't start if ver. 3.10 is installed from Microsoft Store.
3.9 works just fine.

Thanks in advance!


Johan Gunnarsson
Lunds universitet
Medicinska fakulteten
Bibliotek & IKT
Box 118, 221 00 Lund
Besöksadress: Sölvegatan 19, 221 84 Lund
Telefon: +46 46 222 18 23
www.medicin.lu.se
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Bug report

[Peter Otten]

On 24/02/2021 22:03, Dan Stromberg wrote:

On Wed, Feb 24, 2021 at 12:58 PM Peter Otten <__pete...@web.de> wrote:


On 24/02/2021 20:36, Carla Molina wrote:
This is not a bug. Have a look at the array's dtype:

  >>> n = 60461826
  >>> a = np.array([1, 50, 100, 150, 200, 250, 300])
  >>> a.dtype
dtype('int32')


I'm getting dtypes of float64.


When you run the snippet above or


import numpy as np

NR = 0.25
N = 60461826

initialINCIDENCE = np.array([1, 50, 100, 150, 200, 250, 300])
initialINCIDENCE = initialINCIDENCE*N/(10*7*NR)


here, i. e. after the division?

initialINCIDENCE*N

should be an int32 array, but dividing by

(10*7*NR)

returns an dtype=float64 array. Switching back to my modified example:

>>> a/42
array([0.02380952, 1.19047619, 2.38095238, 3.57142857, 4.76190476,
   5.95238095, 7.14285714])
>>> _.dtype
dtype('float64')
--
https://mail.python.org/mailman/listinfo/python-list

Re: Bug report

[Dan Stromberg]

On Wed, Feb 24, 2021 at 12:58 PM Peter Otten <__pete...@web.de> wrote:

> On 24/02/2021 20:36, Carla Molina wrote:
> This is not a bug. Have a look at the array's dtype:
>
>  >>> n = 60461826
>  >>> a = np.array([1, 50, 100, 150, 200, 250, 300])
>  >>> a.dtype
> dtype('int32')
>
I'm getting dtypes of float64.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Bug report

[Dan Stromberg]

I'm getting:
/usr/local/cpython-2.7/bin/python (2.7.16) bad
('numpy version:', '1.16.6')
Traceback (most recent call last):
  File "./nii", line 31, in 
assert left == right, "{} != {}".format(left, right)
AssertionError: 86374.0371429 != 86374.0371429
/usr/local/cpython-3.0/bin/python (3.0.1) bad  No numpy found
/usr/local/cpython-3.1/bin/python (3.1.5) bad  No numpy found
/usr/local/cpython-3.2/bin/python (3.2.5) bad  No numpy found
/usr/local/cpython-3.3/bin/python (3.3.7) bad  No numpy found
/usr/local/cpython-3.4/bin/python (3.4.8) bad  No numpy found
/usr/local/cpython-3.5/bin/python (3.5.5) bad
numpy version: 1.18.5
Traceback (most recent call last):
  File "./nii", line 31, in 
assert left == right, "{} != {}".format(left, right)
AssertionError: 86374.03714285714 != 86374.03714285715
/usr/local/cpython-3.6/bin/python (3.6.0) bad
numpy version: 1.18.1
Traceback (most recent call last):
  File "./nii", line 31, in 
assert left == right, "{} != {}".format(left, right)
AssertionError: 86374.03714285714 != 86374.03714285715
/usr/local/cpython-3.7/bin/python (3.7.0) bad
numpy version: 1.19.0
Traceback (most recent call last):
  File "./nii", line 31, in 
assert left == right, "{} != {}".format(left, right)
AssertionError: 86374.03714285714 != 86374.03714285715
/usr/local/cpython-3.8/bin/python (3.8.0) bad
numpy version: 1.19.0
Traceback (most recent call last):
  File "./nii", line 31, in 
assert left == right, "{} != {}".format(left, right)
AssertionError: 86374.03714285714 != 86374.03714285715
/usr/local/cpython-3.9/bin/python (3.9.0) bad
numpy version: 1.19.4
Traceback (most recent call last):
  File
"/home/dstromberg/src/stack-overflow,python-list/numpy-initial-incidence/./nii",
line 31, in 
assert left == right, "{} != {}".format(left, right)
AssertionError: 86374.03714285714 != 86374.03714285715

So the difference is tiny for me, and can be imputed to rounding error.
Multiplying the big terms first before dividing naturally gives less
rounding error.

As far as why your install is having problems, I don't really know.  What
version of numpy are you using?


On Wed, Feb 24, 2021 at 12:12 PM Carla Molina 
wrote:

> I found the following bug (python 3.9.1) when multiplying an array by
> several variables without parentheses; look at the following example:
>
> import numpy as np
>
> NR = 0.25
> N = 60461826
>
> initialINCIDENCE = np.array([1, 50, 100, 150, 200, 250, 300])
> initialINCIDENCE = initialINCIDENCE*N/(10*7*NR)
> print('First result ' +str(initialINCIDENCE))
>
> initialINCIDENCE = np.array([1, 50, 100, 150, 200, 250, 300])
> initialINCIDENCE = initialINCIDENCE*(N/(10*7*NR))
> print('Second result ' +str(initialINCIDENCE))
>
> The result given is:
>
> First result [   345.49614857  -7267.86283429  10006.94459429   2739.08176
>   -4528.78107429 -11796.64390857   5478.16352   ]
> Second result [   345.49614857  17274.80742857  34549.61485714
>  51824.42228571  69099.22971429  86374.03714286 103648.84457143]
>
> Clearly both are different, and in particular the first one has no sense to
> me.
> Thank you,
>
> Carla.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Bug report

[Peter Otten]

On 24/02/2021 20:36, Carla Molina wrote:

I found the following bug (python 3.9.1) when multiplying an array by
several variables without parentheses; look at the following example:

import numpy as np

NR = 0.25
N = 60461826

initialINCIDENCE = np.array([1, 50, 100, 150, 200, 250, 300])
initialINCIDENCE = initialINCIDENCE*N/(10*7*NR)
print('First result ' +str(initialINCIDENCE))

initialINCIDENCE = np.array([1, 50, 100, 150, 200, 250, 300])
initialINCIDENCE = initialINCIDENCE*(N/(10*7*NR))
print('Second result ' +str(initialINCIDENCE))

The result given is:

First result [   345.49614857  -7267.86283429  10006.94459429   2739.08176
   -4528.78107429 -11796.64390857   5478.16352   ]
Second result [   345.49614857  17274.80742857  34549.61485714
  51824.42228571  69099.22971429  86374.03714286 103648.84457143]

Clearly both are different, and in particular the first one has no sense to
me.


This is not a bug. Have a look at the array's dtype:

>>> n = 60461826
>>> a = np.array([1, 50, 100, 150, 200, 250, 300])
>>> a.dtype
dtype('int32')

A 32-bit integer cannot hold the result of, e. g. 50 * n, the result is
unhelpfully clipped.

One possible fix is to specify the array type:

>>> b = np.array([1, 50, 100, 150, 200, 250, 300], dtype=float)
>>> b * n
array([6.04618260e+07, 3.02309130e+09, 6.04618260e+09, 9.06927390e+09,
   1.20923652e+10, 1.51154565e+10, 1.81385478e+10])
--
https://mail.python.org/mailman/listinfo/python-list

Bug report

[Carla Molina]

I found the following bug (python 3.9.1) when multiplying an array by
several variables without parentheses; look at the following example:

import numpy as np

NR = 0.25
N = 60461826

initialINCIDENCE = np.array([1, 50, 100, 150, 200, 250, 300])
initialINCIDENCE = initialINCIDENCE*N/(10*7*NR)
print('First result ' +str(initialINCIDENCE))

initialINCIDENCE = np.array([1, 50, 100, 150, 200, 250, 300])
initialINCIDENCE = initialINCIDENCE*(N/(10*7*NR))
print('Second result ' +str(initialINCIDENCE))

The result given is:

First result [   345.49614857  -7267.86283429  10006.94459429   2739.08176
  -4528.78107429 -11796.64390857   5478.16352   ]
Second result [   345.49614857  17274.80742857  34549.61485714
 51824.42228571  69099.22971429  86374.03714286 103648.84457143]

Clearly both are different, and in particular the first one has no sense to
me.
Thank you,

Carla.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: IDLE 3.8.4 [was 3.8.3] -- bug report

[Ned Deily]

On 2020-08-03 15:37, Halvard Tislavoll wrote:
> I'am dealing with a bug
[...]
> Python 3.8.4 (default, Jul 20 2020, 20:20:14)
> IDLE 3.8.4
> 
> I have been using IDLE for many years. But now I can not do it.
> 
> Example:
> I write a heading for a python script in my text editor, xed and save as 
> 'test.py'.
> ..
>     #! /usr/bin/env python
>     #  -*- coding: utf-8 -*-
> 
>     # ... pandas-techniques-python-data-manipulation/
> 
>     import pandas as pd
>     import numpy as np
> 
>     #---
> ...
> Then I open 'test.py' in IDLE. Everything looks normal.
> 
> I am testing whether it is possible to save with the shortcut ctrl-s. OK.
> 
> But then I write the following line:
> 
>     print ("\ n # 1 - Boolean Indexing in Pandas \ n")
> 
> Result:
> storage no longer works. And IDLE becomes useless!
> 
> The problem is that print statement no longer support my sign "-" U + 2013 EN 
> DASH
> 
> but this sign goes well;  "-" U + 002D HYPHEN-MINUS

See https://bugs.python.org/issue41300

The problem was introduced in Python 3.8.4 (released 2020-07-13) and has
been fixed in 3.8.5 which was released 2020-07-20.


-- 
https://mail.python.org/mailman/listinfo/python-list

IDLE 3.8.3 -- bug report

[Halvard Tislavoll]

I'am dealing with a bug

My machine:
Type: Laptop
    System: Hewlett-Packard
    product: HP EliteBook 8770w
    v: A1029D1102
    Prosessor: Intel© Core™ i7-3720QM CPU @ 2.60GHz × 4
    RAM: 15.6 GiB
    Hd: 2577.6 GB
    Graphic card: NVIDIA Corporation GK104GLM [Quadro K3000M]

Operating system:   Linux Mint 20 Cinnamon
    Cinnamon version: 4.6.6
    Linux kernal: 5.4.0-42-generic

pyenv 1.2.20
Python 3.8.4 (default, Jul 20 2020, 20:20:14)
IDLE 3.8.4

I have been using IDLE for many years. But now I can not do it.

Example:
I write a heading for a python script in my text editor, xed and save as 
'test.py'.
..
    #! /usr/bin/env python
    #  -*- coding: utf-8 -*-

    # ... pandas-techniques-python-data-manipulation/

    import pandas as pd
    import numpy as np

    #---
...
Then I open 'test.py' in IDLE. Everything looks normal.

I am testing whether it is possible to save with the shortcut ctrl-s. OK.

But then I write the following line:

    print ("\ n # 1 - Boolean Indexing in Pandas \ n")

Result:
storage no longer works. And IDLE becomes useless!

The problem is that print statement no longer support my sign "-" U + 2013 EN 
DASH

but this sign goes well;  "-" U + 002D HYPHEN-MINUS

Want to get this fixed

Thank you in advance, Halvard Tislavoll
 


 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: a Python bug report

[Peter J. Holzer]

On 2018-05-29 21:34:21 -0400, José María Mateos wrote:
> On Wed, May 30, 2018 at 01:07:38AM +, Ruifeng Guo wrote:
> > We encountered a bug in Python recently, we checked the behavior for Python 
> > version 2.7.12, and 3.1.1, both version show the same behavior. Please see 
> > below the unexpected behavior in "red text".
[...]
> In [3]: 1000 * 1.017
> Out[3]: 1016.9
> 
> So there you have it.

To expand a bit on that, the reason, why 1000 * 1.017 isn't 1017 isn't
that an x86 processor can't multiply, it is that 1017/1000 cannot be exactly
represented in a binary fraction (just like 1/7 cannot be exactly
represented in a decimal fraction).

So when you type 1.017, the computer really stores
1.016904076730672386474907398223876953125 and when you
multiply that by 1000, the result would be
1016.904076730672386474907398223876953125, but that needs a
few bits too much, so it rounded down to
1016.8863131622783839702606201171875.

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: a Python bug report

[Ian Kelly]

On Tue, May 29, 2018 at 7:07 PM, Ruifeng Guo  wrote:
> Hello,
> We encountered a bug in Python recently, we checked the behavior for Python 
> version 2.7.12, and 3.1.1, both version show the same behavior. Please see 
> below the unexpected behavior in "red text".
>
> Thanks,
> Ruifeng Guo
>
> From: Brian Archer
> Sent: Tuesday, May 29, 2018 5:57 PM
> To: Ruifeng Guo 
> Subject: Python Bug
>
> Python 3.1.1 (r311:74480, Nov 20 2012, 09:11:57)
> [GCC 4.2.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
 a=1017.0
 print(int(a))
> 1017
 b=1000*1.017
 print(b)
> 1017.0
 int(b)
> 1016
 c=1017.0
 int(c)
> 1017

Try this, and you'll see what the problem is:

>>> repr(b)
'1016.9'

The value of b is not really 1017, but fractionally less as a result
of floating point rounding error, because 1.017 cannot be exactly
represented as a float.

In Python 3.2, the str() of the float type was changed to match the
repr(), so that when you use print() as above you will also get this
result:

>>> print(b)
1016.9

By the way, Python 3.1.1 is really old (six years!). I recommend
upgrading if possible.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: a Python bug report

[José María Mateos]

On Wed, May 30, 2018 at 01:07:38AM +, Ruifeng Guo wrote:
> Hello,
> We encountered a bug in Python recently, we checked the behavior for Python 
> version 2.7.12, and 3.1.1, both version show the same behavior. Please see 
> below the unexpected behavior in "red text".

Have you tried the round() function, however?

In [1]: round(1000 * 1.017)
Out[1]: 1017.0

This is a floating point precision "issue". int() only gets rid of the 
decimals.

In [2]: int(3.9)
Out[2]: 3

Because:

In [3]: 1000 * 1.017
Out[3]: 1016.9

So there you have it.

Some more reading: 
https://stackoverflow.com/questions/43660910/python-difference-between-round-and-int

Cheers,

-- 
José María (Chema) Mateos
https://rinzewind.org/blog-es || https://rinzewind.org/blog-en
-- 
https://mail.python.org/mailman/listinfo/python-list

a Python bug report

[Ruifeng Guo]

Hello,
We encountered a bug in Python recently, we checked the behavior for Python 
version 2.7.12, and 3.1.1, both version show the same behavior. Please see 
below the unexpected behavior in "red text".

Thanks,
Ruifeng Guo

From: Brian Archer
Sent: Tuesday, May 29, 2018 5:57 PM
To: Ruifeng Guo 
Subject: Python Bug

Python 3.1.1 (r311:74480, Nov 20 2012, 09:11:57)
[GCC 4.2.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a=1017.0
>>> print(int(a))
1017
>>> b=1000*1.017
>>> print(b)
1017.0
>>> int(b)
1016
>>> c=1017.0
>>> int(c)
1017
>>>



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python bug report

[breamoreboy]

On Friday, December 22, 2017 at 1:28:17 PM UTC, Ranya wrote:
> Hi,
> Am trying to use clr.AddReference and clr.AddReferenceToFile, but
> python(2.7) keeps making this error:
> 
> Traceback (most recent call last):
>   File "", line 1, in 
> clr.AddReference("UnityEngine")AttributeError: 'module' object has
> no attribute 'AddReference'
> 
> How can I fix this?
> Thanks in advance.

Are you actually using the IronPython clr module, have you downloaded by 
mistake the module of the same name from pypi, or do you have a module of the 
same name on your path?

--
Kindest regards.

Mark Lawrence.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python bug report

[Peter Pearson]

On Thu, 21 Dec 2017 23:54:17 +0100, Ranya  wrote:
> Hi,
> Am trying to use clr.AddReference and clr.AddReferenceToFile, but
> python(2.7) keeps making this error:
>
> Traceback (most recent call last):
>   File "", line 1, in 
> clr.AddReference("UnityEngine")AttributeError: 'module' object has
> no attribute 'AddReference'
>
> How can I fix this?
> Thanks in advance.

What is clr?  Whatever it is, it doesn't have the AddReference
attribute that you seem to be expecting.

-- 
To email me, substitute nowhere->runbox, invalid->com.
-- 
https://mail.python.org/mailman/listinfo/python-list

Python bug report

[Ranya]

Hi,
Am trying to use clr.AddReference and clr.AddReferenceToFile, but
python(2.7) keeps making this error:

Traceback (most recent call last):
  File "", line 1, in 
clr.AddReference("UnityEngine")AttributeError: 'module' object has
no attribute 'AddReference'

How can I fix this?
Thanks in advance.
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Cannot register to submit a bug report

[John Posner]

Terry Ready said: 

 >> > My ISP (AT&T/Yahoo) was blocking email from the Python bug-tracker:
"The
 >> > sending system has been identified as a source of spam".
 >> 
 >> I hope you were able to suggest to them that that 
 >> identification must be 
 >> an error.  Frustrating given the spam sources that somehow 
 >> do not get 
 >> identified.

The AT&T web site carefully explained that only administrators, not mere
mortals, would be able to submit a "this is not spam" appeal. So I forwarded
the appropriate info to Martin Lowis, my Tracker-discuss benefactor.

 >> > I took a suggestion
 >> > from Martin Lowis on the "tracker-discuss" list: register under a
different
 >> > email address. That solution worked fine.
 >> 
 >> Better than waiting for AT&T to wise up. ;-)

Fuggedaboudit! :-)






E-mail message checked by Spyware Doctor (6.0.0.386)
Database version: 5.12080
http://www.pctools.com/en/spyware-doctor-antivirus/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Cannot register to submit a bug report

[Terry Reedy]

John Posner wrote:


My ISP (AT&T/Yahoo) was blocking email from the Python bug-tracker: "The
sending system has been identified as a source of spam".


I hope you were able to suggest to them that that identification must be 
an error.  Frustrating given the spam sources that somehow do not get 
identified.


> I took a suggestion

from Martin Lowis on the "tracker-discuss" list: register under a different
email address. That solution worked fine.


Better than waiting for AT&T to wise up. ;-)

--
http://mail.python.org/mailman/listinfo/python-list

RE: Cannot register to submit a bug report

[John Posner]

 >>  >> We can try to debug this :)
 >>  >> 
 >>  >> > E-mail message checked by Spyware Doctor (6.0.0.386)
 >>  >> > Database version: 
 >>  >> 5.12060http://www.pctools.com/en/spyware-doctor-antivirus/
 >>  >> 
 >>  >> Any chance it's Spyware Doctor or some anti-virus flagging 
 >>  >> the message and hiding it?

I said:

 >> Thanks for the suggestion, but that's probably not it. No 
 >> message appears on my ISP mail server (Yahoo), either. 
 >> That's beyond the reach of my machine's Spyware Doctor.
 >> 
 >> I plan to take Terry's suggestion: send a message to the Webmaster.

My ISP (AT&T/Yahoo) was blocking email from the Python bug-tracker: "The
sending system has been identified as a source of spam". I took a suggestion
from Martin Lowis on the "tracker-discuss" list: register under a different
email address. That solution worked fine.





E-mail message checked by Spyware Doctor (6.0.0.386)
Database version: 5.12080
http://www.pctools.com/en/spyware-doctor-antivirus/
--
http://mail.python.org/mailman/listinfo/python-list

RE: Cannot register to submit a bug report

[John Posner]

 >> 
 >> We can try to debug this :)
 >> 
 >> > E-mail message checked by Spyware Doctor (6.0.0.386)
 >> > Database version: 
 >> 5.12060http://www.pctools.com/en/spyware-doctor-antivirus/
 >> 
 >> Any chance it's Spyware Doctor or some anti-virus flagging 
 >> the message
 >> and hiding it?
 >> 

Thanks for the suggestion, but that's probably not it. No message appears on
my ISP mail server (Yahoo), either. That's beyond the reach of my machine's
Spyware Doctor.

I plan to take Terry's suggestion: send a message to the Webmaster.

Tx,
John





E-mail message checked by Spyware Doctor (6.0.0.386)
Database version: 5.12060
http://www.pctools.com/en/spyware-doctor-antivirus/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Cannot register to submit a bug report

[ajaksu]

John Posner wrote:
> I've tried twice to register myself at bugs.python.org. But the confirmation
> email message never arrives. (Yes, I checked my spam folder.) What do I do
> now?

We can try to debug this :)

> E-mail message checked by Spyware Doctor (6.0.0.386)
> Database version: 5.12060http://www.pctools.com/en/spyware-doctor-antivirus/

Any chance it's Spyware Doctor or some anti-virus flagging the message
and hiding it?

Here are some headers I get in a test confirmation email, maybe the
different values for 'from' make it look spammish:
  FROM: roundup-ad...@example.com
  TO: lo...@localhost
  From nobody Sun Mar 29 23:02:37 2009
[...]
  Subject: Complete your registration to Tracker -- key ITK...
  To: lo...@localhost
  From: Tracker 
  Date: Sun, 29 Mar 2009 23:02:37 +
  Precedence: bulk

HTH,
Daniel
--
http://mail.python.org/mailman/listinfo/python-list

Re: Cannot register to submit a bug report

[Terry Reedy]

John Posner wrote:

I've tried twice to register myself at bugs.python.org. But the confirmation
email message never arrives. (Yes, I checked my spam folder.) What do I do
now?


I will not suggest that you register at the roundup tracker to report 
this ;-, especially since it may be a local problem.  If no answer here, 
try email to webmaster.python.org.


--
http://mail.python.org/mailman/listinfo/python-list

Cannot register to submit a bug report

[John Posner]

I've tried twice to register myself at bugs.python.org. But the confirmation
email message never arrives. (Yes, I checked my spam folder.) What do I do
now?






E-mail message checked by Spyware Doctor (6.0.0.386)
Database version: 5.12060
http://www.pctools.com/en/spyware-doctor-antivirus/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Bug report: ClientForm

[Steve Holden]

MRAB wrote:
> Muddy Coder wrote:
>> Hi Folks,
>>
>> As directed, I got ClientForm and played with it. It is cool! However,
>> I also found a bug:
>>
>> When it parses a form, if the VALUE of a field has not space, it works
>> very well. For example, if a dropdown list, there many options, such
>> as:
>>
>>  
>>
>> the value foo will be picked up for sure. But, if there is a space:
>>
>>  .
>>
> Values should be quoted, although you can omit the quotes if there
> aren't any spaces in the string:
> 
> 
> 
> You can see examples at http://wwwsearch.sourceforge.net/ClientForm/
> 
> 
> 
> As you can see, whitespace separates the name=value pairs.
> 
>> The *bar* will be missed out. I wish this bug can be fixed in near
>> future.
>>
> It's not a bug.

Or, if it is, it's a bug in the web page, not ClientForm!

regards
 Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

--
http://mail.python.org/mailman/listinfo/python-list

Re: Bug report: ClientForm

[Lie Ryan]

MRAB wrote:
> Muddy Coder wrote:
>> Hi Folks,
>>
>> When it parses a form, if the VALUE of a field has not space, it works
>> very well. For example, if a dropdown list, there many options, such
>> as:
>>
>>  
>>
>> the value foo will be picked up for sure. But, if there is a space:
>>
>>  .
>>
> Values should be quoted, although you can omit the quotes if there
> aren't any spaces in the string:
> 
> 
> 
> You can see examples at http://wwwsearch.sourceforge.net/ClientForm/
> 
> 
> 
> As you can see, whitespace separates the name=value pairs.

It is also a good habit to have the quotes even when you don't use
spaces. Also, knowledge of xHTML in general should come in handy.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Bug report: ClientForm

[Gabriel Genellina]

En Sat, 28 Feb 2009 21:01:56 -0200, Muddy Coder   
escribió:



By the way, can somebody helps me on setting parameter of uploading a
file. In ClientForm, if I need to upload a text file, I can do it by:

form.add_file(..., "text/plain")

What about a picture file? What is the counterpart of 'text/plain"?


See http://www.iana.org/assignments/media-types/image/

--
Gabriel Genellina

--
http://mail.python.org/mailman/listinfo/python-list

Re: Bug report: ClientForm

[MRAB]

Muddy Coder wrote:

Hi Folks,

As directed, I got ClientForm and played with it. It is cool! However,
I also found a bug:

When it parses a form, if the VALUE of a field has not space, it works
very well. For example, if a dropdown list, there many options, such
as:

 

the value foo will be picked up for sure. But, if there is a space:

 .


Values should be quoted, although you can omit the quotes if there
aren't any spaces in the string:



You can see examples at http://wwwsearch.sourceforge.net/ClientForm/



As you can see, whitespace separates the name=value pairs.


The *bar* will be missed out. I wish this bug can be fixed in near
future.


It's not a bug.
--
http://mail.python.org/mailman/listinfo/python-list

Bug report: ClientForm

[Muddy Coder]

Hi Folks,

As directed, I got ClientForm and played with it. It is cool! However,
I also found a bug:

When it parses a form, if the VALUE of a field has not space, it works
very well. For example, if a dropdown list, there many options, such
as:

 

the value foo will be picked up for sure. But, if there is a space:

 .

The *bar* will be missed out. I wish this bug can be fixed in near
future.

By the way, can somebody helps me on setting parameter of uploading a
file. In ClientForm, if I need to upload a text file, I can do it by:

form.add_file(..., "text/plain")

What about a picture file? What is the counterpart of 'text/plain"?
Thanks!

Muddy Coder
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python 2.6 fails on compiling > Bug report

[googler . 1 . webmaster]

Hi! :)

>Sorry, there were a few line wrap-arounds in the diff file due to long
>lines but the changes for the four significant lines should be easy to
>do manually.


Hadn't done that before but I found a ressource how to read that
syntax.
x86_64 would be enough. i test that again. Thank you. :)
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python 2.6 fails on compiling > Bug report

[Ned Deily]

In article 
,
 googler.1.webmas...@spamgourmet.com wrote:
> May the diff file is wrong? on my system it doesn't work.
> Well, set the -enable-universalsdk= path occurs that error.

Sorry, there were a few line wrap-arounds in the diff file due to long 
lines but the changes for the four significant lines should be easy to 
do manually.

Note that the build I made this way has not been tested on ppc64 and has 
had minimal testing so far on x64_64.

-- 
 Ned Deily,
 n...@acm.org

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python 2.6 fails on compiling > Bug report

[googler . 1 . webmaster]

hi, thanks for your help.

May the diff file is wrong? on my system it doesn't work.
Well, set the -enable-universalsdk= path occurs that error.

Hmm. that is really a disaster, isn't it :( hm.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python 2.6 fails on compiling > Bug report

[Ned Deily]

In article 
<07832575-9b98-4a03-a181-4470a5a00...@35g2000pry.googlegroups.com>,
 googler.1.webmas...@spamgourmet.com wrote:

> hm... any ideas?

Have you tried specifying one of the universal SDKs, i.e. 
/Developer/SDKs/MacOSX10.n.sdk?  That's what the "official" python.org 
builds do.  The build script for the batteries-included installer is in 
the source tar ball at Mac/BuildScript/build-installer.py.

FWIW, I made a universal (4-way) batteries-included framework build for 
2.6 on 10.5 with the following patch to that script:

--- build-installer.py.bak 2008-12-17 20:02:59.0 -0800
+++ build-installer.py  2008-12-17 23:18:57.0 -0800
@@ -1,12 +1,9 @@
-#!/usr/bin/python2.3
+#!/usr/bin/python2.5
 """
 This script is used to build the "official unofficial" universal build 
on
-Mac OS X. It requires Mac OS X 10.4, Xcode 2.2 and the 10.4u SDK to do 
its
+Mac OS X. It requires Mac OS X 10.5, Xcode 3.0 and the 10.5u SDK to do 
its
 work.
 
-Please ensure that this script keeps working with Python 2.3, to avoid
-bootstrap issues (/usr/bin/python is Python 2.3 on OSX 10.4)
-
 Usage: see USAGE variable in the script.
 """
 import platform, os, sys, getopt, textwrap, shutil, urllib2, stat, 
time, pwd
@@ -65,10 +62,10 @@
 DEPSRC = os.path.expanduser('~/Universal/other-sources')
 
 # Location of the preferred SDK
-SDKPATH = "/Developer/SDKs/MacOSX10.4u.sdk"
+SDKPATH = "/Developer/SDKs/MacOSX10.5.sdk"
 #SDKPATH = "/"
 
-ARCHLIST = ('i386', 'ppc',)
+ARCHLIST = ('i386', 'ppc', 'x86_64', 'ppc64', )
 
 # Source directory (asume we're in Mac/BuildScript)
 SRCDIR = os.path.dirname(
@@ -630,7 +627,7 @@
 version = getVersion()
 
 print "Running configure..."
-runCommand("%s -C --enable-framework --enable-universalsdk=%s 
LDFLAGS='-g -L%s/libraries/usr/local/lib' OPT='-g -O3 
-I%s/libraries/usr/local/include' 2>&1"%(
+runCommand("%s -C --enable-framework --enable-universalsdk=%s 
--with-universal-archs=all LDFLAGS='-g -L%s/libraries/usr/local/lib' 
OPT='-g -O3 -I%s/libraries/usr/local/include' 2>&1"%(
 shellQuote(os.path.join(SRCDIR, 'configure')),
 shellQuote(SDKPATH), shellQuote(WORKDIR)[1:-1],
 shellQuote(WORKDIR)[1:-1]))
@@ -1017,7 +1014,7 @@
 parseOptions()
 checkEnvironment()
 
-os.environ['MACOSX_DEPLOYMENT_TARGET'] = '10.3'
+os.environ['MACOSX_DEPLOYMENT_TARGET'] = '10.5'
 
 if os.path.exists(WORKDIR):
 shutil.rmtree(WORKDIR)

-- 
 Ned Deily,
 n...@acm.org

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python 2.6 fails on compiling > Bug report

[googler . 1 . webmaster]

Hi!

I didn't wanted to post 11.000 Lines here, so I uploaded it here:

http://rapidshare.com/files/181425216/config.log.html

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python 2.6 fails on compiling > Bug report

[David Cournapeau]

On Fri, Jan 9, 2009 at 6:18 PM,   wrote:
> hm... any ideas?

Posting the config.log file would be a first step to give more information,

David
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python 2.6 fails on compiling > Bug report

[googler . 1 . webmaster]

hm... any ideas?
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python 2.6 fails on compiling > Bug report

[googler . 1 . webmaster]

Hi searched for "Library/Frameworks/" in the config file and edited it
to "@executable_path".

Well my configure and make command worked very fine. Just 'make
install' aborted after this error message.


test -d "/Applications/Python 2.6" || mkdir -p "/Applications/Python
2.6"
test -d "/Applications/Python 2.6/IDLE.app" && rm -r "/Applications/
Python 2.6/IDLE.app"
cp -PR IDLE.app "/Applications/Python 2.6"
touch "/Applications/Python 2.6/IDLE.app"
cp ./config-main.def "@executable_path/Python.framework/Versions/2.6/
lib/python2.6/idlelib/config-main.def"
cp: @executable_path/Python.framework/Versions/2.6/lib/python2.6/
idlelib/config-main.def: No such file or directory
make[2]: *** [install] Error 1
make[1]: *** [install_IDLE] Error 2
make: *** [frameworkinstallapps4way] Error 2


That is not cool.. really.. thats not cool. Thanks for your tipps.
--
http://mail.python.org/mailman/listinfo/python-list

Python 2.6 fails on compiling > Bug report

[googler . 1 . webmaster]

Hi!

I compiled Python 2.6.1 on a Mac OSX 10.5.5 Intel machine with this
configure command and got this message


FAILS: ./configure --with-framework-name=Python --with-
universal-archs=all --enable-framework --enable-
universals...@executable_path/my/path/to/app


WORKS: ./configure --with-framework-name=Python --with-
universal-archs=all --enable-framework --enable-universalsdk=/


[...]
configure: WARNING: dlfcn.h: present but cannot be compiled
configure: WARNING: dlfcn.h: check for missing prerequisite
headers?
configure: WARNING: dlfcn.h: see the Autoconf documentation
configure: WARNING: dlfcn.h: section "Present But Cannot Be
Compiled"
configure: WARNING: dlfcn.h: proceeding with the preprocessor's result
configure: WARNING: dlfcn.h: in the future, the compiler will take
precedence
configure: WARNING: ##
 ##
configure: WARNING: ## Report this to http://www.python.org/python-bugs
##
configure: WARNING: ##
 ##
checking for dlfcn.h... yes
[...] many of this error warnings occure.


/* its already noted in the bug reporter but there is no solution.
Does anyone know how to use my custom path?


Thanks.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Bug Report / Patch (1159139 cgi.py invalid REQUEST_METHOD set)

[Joe]

Reinhold,

Thanks for responding...

I see that you are using Python 2.4.1 and the bug was against 2.4.  (I am 
now using 2.4.1)

If I remember correctly there were two issues that I ran into, one was with 
a missing REQUEST_METHOD and the other was with a INCORRECT request method. 
As per your example the missing one does not seem to be a problem any 
longer.

The incorrect REQUEST_METHOD setting still seems to be an issue with Python 
2.4.1.

Make the following changes to your code to demonstrate that problem.

import cgi
import os # NEW

os.environ['REQUEST_METHOD'] = 'cgi'# NEW

field = cgi.FieldStorage()

print field
print field.keys()# NEW

Run the program now with NO parameters. (I'm running on WinXP SP2).

After you start the program cgi.py will be reading from stdin.

type "a=1" and hit enter
type "b=2" and hit enter
press ctrl-z (to send eof) and hit enter

You will get the following stack trace.

FieldStorage(None, None, 'a=1\nb=2\n')
Traceback (most recent call last):
  File "H:\1\t2.py", line 12, in ?
print field.keys()
  File "P:\SW\Python\lib\cgi.py", line 601, in keys
TypeError: not indexable

When the environment does not have a correctly set REQUEST_METHOD cgi.py 
prompts
for key=value pairs by reading from sys.stdin.  (as demonstrated above)  I 
realize REQUEST_METHOD
should be set properly but hear me out.

After the values are read from sys.stdin they are never stored in the 
FieldStorage.list attribute like they are
when the FieldStorage.read_urlencoded or FieldStorage.read_multi methods are 
called.  The read_single
method is the one that has the problem (it is inconsistenty with the other 
two methods because it doesn't
store the values like the other two methods do).

This causes a problem when FieldStorage.keys() is called because although 
the values were read from
sys.stdin they were never stored in FieldStorage.list.

Although you could argue that REQUEST_METHOD should have been set correctly 
in the first place, it still
seems like if cgi.py is going to handle that situation of a invalid 
REQUEST_METHOD by actually reading the
values from sys.stdin (it already does this part) it should store them too 
(especially since it does store the values in the other two methods).

Does that explain the issue more clearly?


"Reinhold Birkenfeld" <[EMAIL PROTECTED]> wrote in 
message news:[EMAIL PROTECTED]
> Joe wrote:
>> Back in March I submitted a patch for cgi.py to sourceforge to fix a 
>> problem
>> with the handling of an invalid REQUEST_METHOD.
>>
>> I thought I followed all the steps to properly submit the bug and patch 
>> but
>> the patch is still sitting there in limbo.
>>
>> This is the first patch I have submitted for Python, did I miss a step in
>> the patch process?
>>
>> What else needs to be done?
>
> Can you provide an example script demonstrating the problem you describe?
>
> I tried something like this (Py2.4.1):
>
> --- test_cgi.py
> #!/bin/env python
> import cgi
> fs = cgi.FieldStorage()
> print fs
>
> $ python test_cgi.py "a=1&b=2"
> FieldStorage(None, None, [MiniFieldStorage('a', '1'), 
> MiniFieldStorage('b', '2')])
> $
>
> There's no REQUEST_METHOD or QUERY_STRING env var set.
>
> Reinhold 


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bug Report / Patch (1159139 cgi.py invalid REQUEST_METHOD set)

[Steven Bethard]

Joe wrote:
> Back in March I submitted a patch for cgi.py to sourceforge to fix a problem 
> with the handling of an invalid REQUEST_METHOD.
> 
> I thought I followed all the steps to properly submit the bug and patch but 
> the patch is still sitting there in limbo.

Patches get processed when people have the time to review them.

If you'd like to speed up the process, a few people on the python-dev 
list have promised to review a patch if the requester reviews 5 other 
patches.  So if you want to get your patch looked at:

(1) pick 5 other patches
(2) try them on your system
(3) make a helpful comment on each of the patch trackers
(4) send a summary of your reviews to the python-dev list, along with a 
link to the patch you'd like reviewed.

HTH,

STeVe
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bug Report / Patch (1159139 cgi.py invalid REQUEST_METHOD set)

[Reinhold Birkenfeld]

Joe wrote:
> Back in March I submitted a patch for cgi.py to sourceforge to fix a problem 
> with the handling of an invalid REQUEST_METHOD.
> 
> I thought I followed all the steps to properly submit the bug and patch but 
> the patch is still sitting there in limbo.
> 
> This is the first patch I have submitted for Python, did I miss a step in 
> the patch process?
> 
> What else needs to be done?

Can you provide an example script demonstrating the problem you describe?

I tried something like this (Py2.4.1):

--- test_cgi.py
#!/bin/env python
import cgi
fs = cgi.FieldStorage()
print fs

$ python test_cgi.py "a=1&b=2"
FieldStorage(None, None, [MiniFieldStorage('a', '1'), MiniFieldStorage('b', 
'2')])
$

There's no REQUEST_METHOD or QUERY_STRING env var set.

Reinhold
-- 
http://mail.python.org/mailman/listinfo/python-list

Bug Report / Patch (1159139 cgi.py invalid REQUEST_METHOD set)

[Joe]

Back in March I submitted a patch for cgi.py to sourceforge to fix a problem 
with the handling of an invalid REQUEST_METHOD.

I thought I followed all the steps to properly submit the bug and patch but 
the patch is still sitting there in limbo.

This is the first patch I have submitted for Python, did I miss a step in 
the patch process?

What else needs to be done?

Thanks!



-- 
http://mail.python.org/mailman/listinfo/python-list