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

[issue40804] Bug report in python3.6.8 using argparse module

[Irit Katriel]

Irit Katriel  added the comment:

amansi26, I am closing this because you did not reply to the request for more 
information for almost a year. Also, the link in your comment is not working 
anymore. 

If you are still having a problem with argparse, please open a new issue for it 
and include code that demonstrates the problem.

There is some documentation on bug reporting that might be helpful:
https://docs.python.org/3/bugs.html#using-the-python-issue-tracker

--
nosy: +iritkatriel
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

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

[issue40804] Bug report in python3.6.8 using argparse module

[Terry J. Reedy]

Terry J. Reedy  added the comment:

3.6 has only gotten security fixed for 1.5 years.  We need a test file that can 
be run as is in the master branch to see if there is a current bug.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue40804] Bug report in python3.6.8 using argparse module

[Florian Dahlitz]

Change by Florian Dahlitz :


--
nosy: +DahlitzFlorian

___
Python tracker 

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

[issue40804] Bug report in python3.6.8 using argparse module

[Rémi Lapeyre]

Rémi Lapeyre  added the comment:

Hi amansi26, thanks for reporting this issue.

Without an example program that reproduces it, we won't be able to diagnose and 
fix it thought. Can you post one?

--
nosy: +remi.lapeyre

___
Python tracker 

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

[issue40804] Bug report in python3.6.8 using argparse module

[amansi26]

New submission from amansi26 :

I am using 3.6.8 version of python.
I am seeing an error as AttributeError: 'Namespace' object has no attribute 
'func' while using argparse . The code is working fine with python2.7 argparser.

I see a similar bug [4] reported at python 3.3 and  python3.4. The workaround 
mentioned works fine for a single level command.
 
Scenarios:
- If there is one command and various subcommands, like [1].The solution works 
fine.
- But suppose I have a command with mutiple level of subcommands like [2]. In 
this case if I give [3] as a command the ArgumentParser.prog() takes just the 
first command as input in this 
  case (open-stack). Hence the parser.print_usage prints [1].
 
 [1] [2] [3]   https://bpa.st/PUPA
 
[4]  https://bugs.python.org/issue16308

--
messages: 370184
nosy: amansi26
priority: normal
severity: normal
status: open
title: Bug report in python3.6.8 using argparse module
type: behavior
versions: Python 3.6

___
Python tracker 
<https://bugs.python.org/issue40804>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21615] Curses bug report for Python 2.7 and Python 3.2

[Zachary Ware]

Zachary Ware  added the comment:

Hi Richard, sorry it too so long for anyone to respond to this issue!  It's 
been long enough that I'm going to assume that this has long since been fixed 
or worked around.  However, if you can still reproduce this with a modern 
version of Python (3.6-3.8), do please reopen the issue and attach some code 
that shows what's going on.

--
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

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

[issue23816] struct.unpack returns null pascal strings - [first] bug report

[Mark Dickinson]

Mark Dickinson added the comment:

Specifically, I believe what's happening here is that "8s4spp" is interpreted 
as "8s4s1p1p", so it decodes a single byte (which can only encode an empty 
string) for each of the "1p" cases.

I wonder whether the struct module should raise an exception if the length byte 
read from the encoded data exceeds the count given in the format.

--

___
Python tracker 

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

[issue23816] struct.unpack returns null pascal strings - [first] bug report

[Xiang Zhang]

Xiang Zhang added the comment:

My previous two messages are not clear enough so I delete them. Sorry for the 
noise. :-(

When unpacking a pascal string, you cannot simply specify a p format character 
otherwise struct calculate a wrong size of the format. That's why unpack fails. 
When count conflicts with the length byte, the smaller one is chosen. I think 
this is consistent with packing.

--

___
Python tracker 

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

[issue23816] struct.unpack returns null pascal strings - [first] bug report

[Xiang Zhang]

Changes by Xiang Zhang :


--
Removed message: http://bugs.python.org/msg292959

___
Python tracker 

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

[issue23816] struct.unpack returns null pascal strings - [first] bug report

[Xiang Zhang]

Changes by Xiang Zhang :


--
Removed message: http://bugs.python.org/msg292958

___
Python tracker 

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

[issue23816] struct.unpack returns null pascal strings - [first] bug report

[Xiang Zhang]

Xiang Zhang added the comment:

Note in the doc:

  Note that for unpack(), the 'p' format character consumes count bytes

I think this means you still need to specify the repeat count for unpacking 'p'.

--

___
Python tracker 

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

[issue23816] struct.unpack returns null pascal strings - [first] bug report

[Xiang Zhang]

Xiang Zhang added the comment:

Hmm, code->size is determined by repeat count at initilization stage so I don't 
understand why it should be updated in s_unpack_internal to 255. And the repro 
script works well for me.

--
nosy: +xiang.zhang
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue23816] struct.unpack returns null pascal strings - [first] bug report

[Jon Heiner]

New submission from Jon Heiner:

I believe there is an issue with the _struct.c handling of Pascal style strings.

In the _struct.c:s_unpack_internal() function (reading 2.7.6 and 2.7.9 source 
from tgz ball), the size parameter 'n' is clamped to code-size-1.

As far as I can tell, 'n' is set to the correct deserialized value, but the 
code-size value is not set to 255. I could be incorrect, as I'm not running in 
a debugger.

I've attached a short repro case. Note the use of unpack_from() as otherwise 
unpac() will thrown an error. Additionally, I may be using it wrong, but this 
feels correct.

--
components: Library (Lib)
files: unpack_pascal.py
messages: 239644
nosy: jonheiner, mark.dickinson, meador.inge
priority: normal
severity: normal
status: open
title: struct.unpack returns null pascal strings - [first] bug report
versions: Python 2.7
Added file: http://bugs.python.org/file38745/unpack_pascal.py

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

[issue21615] Curses bug report for Python 2.7 and Python 3.2

[Richard s. Gordon]

New submission from Richard s. Gordon:

Curses bug report for Python 2.7 and Python 3.2

My Python code outputs text properly with xterm and xterm-16color. It does not 
work properly with xterm-88color and xterm-256color (after defining RGB color 
pallet) when run on Python-2.7 and Python-3.2 on Cygwin with Windows 7 Pro, 
Ubuntu Linux 12.04, Mac OS X 10.9.3 and PS-BSD 10.

For text output to xterm-88color and xterm-256color Python generates unique 
colors that are plagued by the wrong color and underline artifacts.

xterm-16color   xterm-16color   
xterm-88color   xterm-256color
==  ==  
==  ===
Region 1cyan on black   cyan on black   
cyan on olive with underlines   cyan on purple with 
underlines
Region 2white on black  white on black  
navy on black   white on orange
Region 3yellow on black yellow on black magenta 
on black with underlinesnavy on black with underlines

Some of my test platform terminals (such as iTerm2 on my iMac desktop system 
running Mac OSX Mavericks 10.9.3) default to xterm-256color and presumably 
already have Python 2.7.5 built for 256 color. I downloaded and built Python 
3.2.2. 

My Python test code works properly with xterm and xterm-16color. Both display 
the wrong colors, some with underlines when run with xterm-88color and 
xterm-256color.

Any solutions or suggestions?

Richard S. Gordon

--
messages: 219425
nosy: eclectic9509
priority: normal
severity: normal
status: open
title: Curses bug report for Python 2.7 and Python 3.2

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

[issue19149] python bug report

[Martin]

New submission from Martin:

Hello! My name is Martin, a member of Free Software in Comahue National
University of Neuquén, Argentina. We have detected an error in the compiler
for Python 2.7 using Ubuntu 12.04: I write the code, without realizing I
leave a comment with syntax error in that line (do not put the # of
comments), compile and get error of sistaxis in that line. Fix the error
adding # to comment, I do compile again and it shows me various errors that
take over the Python compiler and I am forced to close it. Hope your
response with a possible solution to this problem, my idea is to continue
using this version of Python. Thank yo

--
messages: 198878
nosy: Grupobetatesting
priority: normal
severity: normal
status: open
title: python bug report

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

[issue19150] python bug report

[Martin]

New submission from Martin:

Hello! My name is Martin, a member of Free Software in Comahue National 
University of Neuquén, Argentina. We have detected an error in the compiler for 
Python 2.7 using Ubuntu 12.04: I write the code, without realizing I leave a 
comment with syntax error in that line (do not put the # of comments), compile 
and get error of sistaxis in that line. Fix the error adding # to comment, I do 
compile again and it shows me various errors that take over the Python compiler 
and I am forced to close it. Hope your response with a possible solution to 
this problem, my idea is to continue using this version of Python. Thank yo

--
components: IDLE
files: Captura de pantalla de 2013-10-02 23:52:10.png
messages: 198879
nosy: Grupobetatesting
priority: normal
severity: normal
status: open
title: python bug report
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file31948/Captura de pantalla de 2013-10-02 
23:52:10.png

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

[issue19149] python bug report

[Ned Deily]

Changes by Ned Deily n...@acm.org:


--
resolution:  - duplicate
stage:  - committed/rejected
status: open - closed
superseder:  - python bug report

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

[issue16868] Python Developer Guide: Include a reminder to ping bug report if not reviewed in timely manner

[Roundup Robot]

Roundup Robot added the comment:

New changeset 3f2637a6fbfa by Ezio Melotti in branch 'default':
#16868: mention that you can ping issues before writing to python-dev.
http://hg.python.org/devguide/rev/3f2637a6fbfa

--
nosy: +python-dev

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

[issue16868] Python Developer Guide: Include a reminder to ping bug report if not reviewed in timely manner

[Ezio Melotti]

Ezio Melotti added the comment:

Fixed with a slightly different wording (thanks Chris for the suggestion).
Thanks Todd for the report and the initial patch!

--
assignee: docs@python - ezio.melotti
resolution:  - fixed
stage: commit review - committed/rejected
status: open - closed
type: behavior - enhancement

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

[issue16868] Python Developer Guide: Include a reminder to ping bug report if not reviewed in timely manner

[Todd Rovito]

Todd Rovito added the comment:

Ok I changed the time to one month...now the patch reads:
To begin with, please be patient! There are many more people submitting 
patches than there are people capable of reviewing your patch. Getting your 
patch reviewed requires a reviewer to have the spare time and motivation to 
look at your patch (we cannot force anyone to review patches). If your patch 
has not received any notice from reviewers (i.e., no comment made) after one 
month, first “ping” the issue on the issue tracker to remind the nosy list that 
the patch needs a review. After the issue has been “pinged” and if you don’t 
get a response after a few days then you may email python-...@python.org asking 
for someone to review your patch.

--
Added file: 
http://bugs.python.org/file28611/16868PythonDeveloperGuidePingIssueBeforeEmailingPython-devV3.patch

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

[issue16868] Python Developer Guide: Include a reminder to ping bug report if not reviewed in timely manner

[Todd Rovito]

Changes by Todd Rovito rovit...@gmail.com:


Removed file: 
http://bugs.python.org/file28573/16868PythonDeveloperGuidePingIssueBeforeEmailingPython-dev.patch

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

[issue16868] Python Developer Guide: Include a reminder to ping bug report if not reviewed in timely manner

[Todd Rovito]

Changes by Todd Rovito rovit...@gmail.com:


Removed file: 
http://bugs.python.org/file28603/16868PythonDeveloperGuidePingIssueBeforeEmailingPython-devV2.patch

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

[issue16868] Python Developer Guide: Include a reminder to ping bug report if not reviewed in timely manner

[Brett Cannon]

Brett Cannon added the comment:

Wording LGTM

--
stage:  - commit review

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

[issue16868] Python Developer Guide: Include a reminder to ping bug report if not reviewed in timely manner

[Brett Cannon]

Changes by Brett Cannon br...@python.org:


--
nosy: +brett.cannon

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

[issue16868] Python Developer Guide: Include a reminder to ping bug report if not reviewed in timely manner

[Todd Rovito]

Todd Rovito added the comment:

I agree with Meador it should be a specific amount of time.  As a beginner at 
contributing to Python I thought substantial amount of time meant one month 
but it depends on interpretation.  I think making it very specific makes the 
documentation more clear.  Included in the new patch are the other suggestions 
made by Mr. Jerdonek.  Thanks for the feedback!

--
Added file: 
http://bugs.python.org/file28603/16868PythonDeveloperGuidePingIssueBeforeEmailingPython-devV2.patch

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

[issue16868] Python Developer Guide: Include a reminder to ping bug report if not reviewed in timely manner

[Ezio Melotti]

Ezio Melotti added the comment:

A month sounds good to me.

--

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

[issue16868] Python Developer Guide: Include a reminder to ping bug report if not reviewed in timely manner

[Meador Inge]

Meador Inge added the comment:

This seems like a reasonable addition to me.  Although, I don't like the 
substantial amount of time part (yes I know it was already there).  That 
should probably be replaced with something more concrete, e.g. one week.

--
nosy: +meador.inge

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

[issue16868] Python Developer Guide: Include a reminder to ping bug report if not reviewed in timely manner

[Chris Jerdonek]

Chris Jerdonek added the comment:

I would also take out the sentence about forgetting about the issue, because 
that's just one of several possible reasons and I don't think usually the main 
reason.

--
nosy: +chris.jerdonek

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

[issue16868] Python Developer Guide: Include a reminder to ping bug report if not reviewed in timely manner

[Ezio Melotti]

Ezio Melotti added the comment:

I agree with Chris.

+substantial amount of time first ping the issue on the `issue tracker`_

I would add a comma after 'time'.

 I don't like the substantial amount of time part (yes I know it
 was already there).  That should probably be replaced with something
 more concrete, e.g. one week.

That really depends on the situation.  I think the point of that sentence is to 
make clear that some time might pass before someone can look at the issue, and 
I'm not sure it's necessary to quantify this.

--

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

[issue16868] Python Developer Guide: Include a reminder to ping bug report if not reviewed in timely manner

[Meador Inge]

Meador Inge added the comment:

On Sat, Jan 5, 2013 at 5:55 PM, Ezio Melotti rep...@bugs.python.org wrote:

 That really depends on the situation.  I think the point of that sentence is 
 to make clear that some time might
 pass before someone can look at the issue, and I'm not sure it's necessary to 
 quantify this.

It currently says:


 If your patch has not received any notice from reviewers (i.e., no
comment made) after a substantial amount of time then you may email
python-...@python.org asking for someone to take a look at your patch.


That doesn't seem very useful to me because a newcomer is going to
wonder how much time is substantial.  If you quantify it, then they
don't really have to think about it as much which makes contributing
easier.

--

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

[issue16868] Python Developer Guide: Include a reminder to ping bug report if not reviewed in timely manner

[Todd Rovito]

New submission from Todd Rovito:

The Python Developer Guide in section 3.3 about the life cycle of a 
patch/review process makes no mention that a bug should be pinged first 
before posting to the python-...@python.org email list requesting a review.  

For more information see this thread on the Python-Dev email list: 
http://mail.python.org/pipermail/python-dev/2013-January/123453.html

--
assignee: docs@python
components: Documentation
messages: 179109
nosy: Todd.Rovito, docs@python
priority: normal
severity: normal
status: open
title: Python Developer Guide: Include a reminder to ping bug report if not 
reviewed in timely manner
type: behavior
versions: Python 3.4

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

[issue16868] Python Developer Guide: Include a reminder to ping bug report if not reviewed in timely manner

[Todd Rovito]

Changes by Todd Rovito rovit...@gmail.com:


--
components: +Devguide -Documentation
nosy: +ezio.melotti

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

[issue16868] Python Developer Guide: Include a reminder to ping bug report if not reviewed in timely manner

[Todd Rovito]

Todd Rovito added the comment:

Here is a suggested patch with help from R. David Murray:
To begin with, please be patient! There are many more people submitting 
patches than there are people capable of reviewing your patch. Getting your 
patch reviewed requires a reviewer to have the spare time and motivation to 
look at your patch (we cannot force anyone to review patches). If your patch 
has not received any notice from reviewers (i.e., no comment made) after a 
substantial amount of time first “ping” the issue on the issue tracker to 
remind the nosy list that the patch needs a review. It is possible that the 
nosy committers have just forgotten about the issue. After the issue has been 
“pinged” and if you don’t get a response after a few days then you may email 
python-...@python.org asking for someone to review your patch.

--
keywords: +patch
Added file: 
http://bugs.python.org/file28573/16868PythonDeveloperGuidePingIssueBeforeEmailingPython-dev.patch

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

[issue8846] cgi.py bug report + fix: tailing carriage return and newline characters in multipart cgi input broken

[Andre Wobst]

Andre Wobst wob...@users.sourceforge.net added the comment:

I just declare this bug to be a duplicate of #4953. Due to the recent fix 
r87998 of the cgi module my extended/corrected testcases attached in this bug 
report now pass.

--
resolution:  - duplicate
status: open - closed

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

[issue8846] cgi.py bug report + fix: tailing carriage return and newline characters in multipart cgi input broken

[Florent Xicluna]

Changes by Florent Xicluna florent.xicl...@gmail.com:


--
nosy: +flox
versions: +Python 3.2

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

[issue8846] cgi.py bug report + fix: tailing carriage return and newline characters in multipart cgi input broken

[Andre Wobst]

New submission from Andre Wobst wob...@users.sourceforge.net:

There are serious bugs in carriage return and newline handling at the end of a 
multipart cgi input. The enclosed patch extends the test_cgi.py (and actually 
reverts two wrong tests to what they had been for python2.x). Additionally, the 
bugs are fixed by two small corrections to cgi.py and email/feedparser.py. 
Thanks for consideration.

--
components: Library (Lib)
files: fix-cgi.patch
keywords: patch
messages: 106691
nosy: wobsta
priority: normal
severity: normal
status: open
title: cgi.py bug report + fix: tailing carriage return and newline characters 
in multipart cgi input broken
versions: Python 3.3
Added file: http://bugs.python.org/file17487/fix-cgi.patch

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

[issue8846] cgi.py bug report + fix: tailing carriage return and newline characters in multipart cgi input broken

[Andre Wobst]

Changes by Andre Wobst wob...@users.sourceforge.net:


--
type:  - behavior
versions: +Python 3.1 -Python 3.3

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

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 (ATT/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

[Terry Reedy]

John Posner wrote:


My ISP (ATT/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 ATT to wise up. ;-)

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

RE: Cannot register to submit a bug report

[John Posner]

Terry Ready said: 

   My ISP (ATT/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 ATT 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 ATT 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

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

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 issue_trac...@example.com
  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

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

 option value=foo 

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

 option value=foo bar .

 Values should be quoted, although you can omit the quotes if there
 aren't any spaces in the string:
 
 option value=foo bar
 
 You can see examples at http://wwwsearch.sourceforge.net/ClientForm/
 
 input type=checkbox name=control2 value=foo id=cbe1
 
 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

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:

option value=foo 

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

option value=foo bar .

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

option value=foo 

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

option value=foo bar .


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

option value=foo bar

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

input type=checkbox name=control2 value=foo id=cbe1

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

Re: Bug report: ClientForm

[Gabriel Genellina]

En Sat, 28 Feb 2009 21:01:56 -0200, Muddy Coder cosmo_gene...@yahoo.com  
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

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

 option value=foo 

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

 option value=foo bar .

 Values should be quoted, although you can omit the quotes if there
 aren't any spaces in the string:
 
 option value=foo bar
 
 You can see examples at http://wwwsearch.sourceforge.net/ClientForm/
 
 input type=checkbox name=control2 value=foo id=cbe1
 
 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: 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

[David Cournapeau]

On Fri, Jan 9, 2009 at 6:18 PM,  googler.1.webmas...@spamgourmet.com 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]

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

[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' 21%(
+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' 21%(
 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, 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 
f79bcab6-59ef-43f1-a5b5-7a9171d64...@u18g2000pro.googlegroups.com,
 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! :)

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

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

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

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=1b=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)

[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=1b=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