[issue6482] PATCH: tiny simplification for subprocess

[Yinon Ehrlich]

Changes by Yinon Ehrlich :


--
files: subprocess.patch
keywords: patch
nosy: Yinon
severity: normal
status: open
title: PATCH: tiny simplification for subprocess
versions: Python 2.7
Added file: http://bugs.python.org/file14499/subprocess.patch

___
Python tracker 

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

[issue6481] PATCH: typo in subprocess documentation

[Yinon Ehrlich]

New submission from Yinon Ehrlich :

os.waitpid returns a tuple (pid, status)

--
assignee: georg.brandl
components: Documentation
files: subprocess.patch
keywords: patch
messages: 90513
nosy: Yinon, georg.brandl
severity: normal
status: open
title: PATCH: typo in subprocess documentation
versions: Python 2.6
Added file: http://bugs.python.org/file14498/subprocess.patch

___
Python tracker 

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

[issue6432] ImageTk.PhotoImage

[Sridhar Ratnakumar]

Sridhar Ratnakumar  added the comment:

ActivePython bug: http://bugs.activestate.com/show_bug.cgi?id=83694

--
nosy: +srid

___
Python tracker 

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

[issue6480] code.runsource() parsing bug

[Sean]

New submission from Sean :

I'm writing a little pre-processor that just parses python snippets out
of a file and passes them to a code.InteractiveInterpreter, and I'm
noticing some somewhat nasty stuff in how runsource handles some code.

sys.version:
'2.6.2 (r262:71600, Jul 12 2009, 11:52:33) \n[GCC 4.0.1 (Apple Inc.
build 5465)]' 

Doesn't work:
 interpreter.runsource('print("Foo")\nprint "Bar"')  

Works: 
 interpreter.runsource('print("Foo");print "Bar"')

Doesn't work:
 interpreter.runsource('print("Foo");\nprint "Bar"')  
  

Exact output:
>>> interpreter.runsource('print("Foo")\nprint "Bar"') 

Foo

False  

>>> interpreter.runsource('print("Foo");print "Bar"')  

Foo

Bar

False  

>>> interpreter.runsource('print("Foo");\nprint "Bar"')

Foo

False  

>>> 


Is this a known issue? I didn't see it while searching the bug database...

--
components: None
messages: 90511
nosy: smcallis
severity: normal
status: open
title: code.runsource() parsing bug
versions: Python 2.6

___
Python tracker 

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

[issue6444] multiline exception logging via syslog handler

[Max Arnold]

Max Arnold  added the comment:

> Why can't you either use %r in the format string, or define your own
handler/formatter to do exactly what you want?

I'm describing default behaviour of logger.exception(). Out of the box
(with SyslogHandler and "/dev/log") I'm unable to use it, because of
this problem.

Can you please explain in more details how I can change my code to
correcly log exceptions?  For example:

import logging, logging.handlers

log = logging.getLogger()
h = logging.handlers.SysLogHandler('/dev/log',
logging.handlers.SysLogHandler.LOG_LOCAL0)
h.setFormatter(logging.Formatter('%(name)s: %(levelname)s
%(funcName)s/%(lineno)d %(message)s'))
log.addHandler(h)

try:
a = 1/0
except:
log.exception('division by zero')

--
status: pending -> open

___
Python tracker 

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

[issue6479] platform.py writes to hard coded platform dependant "dev/null"

[John Burnett]

John Burnett  added the comment:

You're right, Vista64 is returning "win32" for the platform.

And ahh, I see what I did: in Python 2.5.2, _syscmd_file wasn't using a
sys.platform check.  Then when I looked at the current version, I saw it
was still using "/dev/null", but didn't see a platform check was added
to skip that part in rev 66104.

Regardless, thanks for adding the change... who knows, it might get hit
some day on a new platform ;).

--
status: open -> closed

___
Python tracker 

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

[issue6479] platform.py writes to hard coded platform dependant "dev/null"

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

John Burnett wrote:
> John Burnett  added the comment:
> 
> I'm not sure how you're seeing that those functions bypass external
> commands?

Both functions use this bypass mechanism:

if sys.platform in ('dos','win32','win16','os2'):
return default

> I'm running Vista64, and it certainly looks like calling
> platform.architecture calls _syscmd_file, which then immediately calls
> os.popen("file %s 2> /dev/null").  This causes windows to try and open a
> file called "file", which fails, and pipes the resulting error ("'file'
> is not recognized as an internal or external command, operable program
> or batch file.") to a file named "null" in my "c:\dev" directory.

Could you please tell me what sys.platform is set to on Vista 64 ?

If it's "win64", then I'll have to add that to the above test.
AFAIK, we chose to leave it set to "win32" even on 64-bit Windows
versions, so the above test should trigger on Vista 64 as well.

> This will happen on any system that doesn't /dev/null.  _syscmd_uname
> does the same thing, but "protects" against it by testing for platform
> type.  I'm not familiar enough with the supported platforms to know if
> it's covering all the bases, but a safer thing to do would be to just
> use os.devnull anyway.

I've added a similar patch in r74002, but those functions should
not really do anything on Windows at all.

--

___
Python tracker 

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

[issue6479] platform.py writes to hard coded platform dependant "dev/null"

[John Burnett]

John Burnett  added the comment:

I'm not sure how you're seeing that those functions bypass external
commands?

I'm running Vista64, and it certainly looks like calling
platform.architecture calls _syscmd_file, which then immediately calls
os.popen("file %s 2> /dev/null").  This causes windows to try and open a
file called "file", which fails, and pipes the resulting error ("'file'
is not recognized as an internal or external command, operable program
or batch file.") to a file named "null" in my "c:\dev" directory.

This will happen on any system that doesn't /dev/null.  _syscmd_uname
does the same thing, but "protects" against it by testing for platform
type.  I'm not familiar enough with the supported platforms to know if
it's covering all the bases, but a safer thing to do would be to just
use os.devnull anyway.

--

___
Python tracker 

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

[issue1820] Enhance Object/structseq.c to match namedtuple and tuple api

[Georg Brandl]

Georg Brandl  added the comment:

ISTM that structseq should have been a tuple subclass anyway.  Isn't it
advertised as some sort of "tuple with attribute access"?

--

___
Python tracker 

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

[issue6475] Documentation > Tutorial > List Comprehensions

[Georg Brandl]

Georg Brandl  added the comment:

Retro, you still won't give up, will you?

--
status: pending -> closed

___
Python tracker 

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

[issue3410] platform.version() don't work as expected in Vista in portuguese

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

I've checked in patch r74005 to address the problem.

Could you check whether the current SVN version of platform.py works on
your Portuguese Windows version ?

Thanks.

--

___
Python tracker 

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

[issue6476] MSVCRT's spawnve/spawnvpe are not thread safe

[Jose Fonseca]

Jose Fonseca  added the comment:

Perhaps. I'm not a scons developer -- just an user -- and I don't know
what versions of python far back in time they want support, but it
appears it would make sense to use subprocess where available indeed. I
already I've filled an issue with scons at
http://scons.tigris.org/issues/show_bug.cgi?id=2449 and linked back to
this issue and I trust the developers to do whatever they see fit to
address this problem.

Instead of just marking this issue as won't fix, shouldn't at least some
documentation be added, or something sensible like that? In
http://docs.python.org/library/os.html#process-management os.spawn* are
not marked as deprecated -- just says that "the subprocess module
provides more powerful facilities" and is "preferable" --, and it
certainly doesn't say these functions are not thread safe. It would be a
pity if other users would have to invest as much time as I did to find
this race condition (it was rare, and happened in a build farm so we
couldn't see the windows access violation dialog), and multithreading is
getting more and more common.

Also, if the only reason not to fix this is the lack of a patch I don't
mind in producing one FWIW.

--
status: pending -> open

___
Python tracker 

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

[issue6071] no longer possible to hash arrays

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> It no longer works with objects created with buffer() either:

That's because the buffer objects don't implement the buffer protocol
(in particular, they don't define the Py_TPFLAGS_HAVE_NEWBUFFER flag,
and the bf_getbuffer/bf_releasebuffer operations that go with that flag.

--

___
Python tracker 

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

[issue1616979] cp720 encoding map

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

The codec file now starts with the comment:
"""Python Character Mapping Codec cp720 generated on Windows:
Vista 6.0.6002 SP2 Multiprocessor Free with the command:
  python Tools/unicode/genwincodec.py 720
"""

I also added a file Tools\unicode\genwincodecs.bat that currently only 
generates cp720.py.

Applied in r74000 (trunk) and r74003 & r74004 (py3k)

--
resolution: accepted -> fixed
status: open -> closed

___
Python tracker 

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

[issue6479] platform.py writes to hard coded platform dependant "dev/null"

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

On which Windows platform would that be ?

Both internal helper functions bypass using an external command for
Windows and DOS platforms.

--

___
Python tracker 

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

[issue6479] platform.py writes to hard coded platform dependant "dev/null"

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
assignee:  -> lemburg
nosy: +lemburg

___
Python tracker 

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

[issue6479] platform.py writes to hard coded platform dependant "dev/null"

[John Burnett]

New submission from John Burnett :

The functions _syscmd_uname and _syscmd_file are hard-coded to pipe
stderr to "/dev/null", as opposed to os.devnull.  On Windows, this has
the effect of creating a file called "null" to a local "dev" directory
(if the directory exists).

Attached is a fix.  While the _syscmd_uname change isn't entirely
necessary on Windows due to its sys.platform check, I changed both
functions for consistency (and I'm not sure what other platforms might
not have a "/dev/null" either).

--
components: Library (Lib)
files: devnull.patch
keywords: patch
messages: 90499
nosy: john.burnett
severity: normal
status: open
title: platform.py writes to hard coded platform dependant "dev/null"
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14497/devnull.patch

___
Python tracker 

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

[issue6476] MSVCRT's spawnve/spawnvpe are not thread safe

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Indeed. But shouldn't you use the subprocess module instead?

--
nosy: +amaury.forgeotdarc
resolution:  -> wont fix
status: open -> pending

___
Python tracker 

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

[issue6478] time.tzset does not reset _strptime's locale time cache

[Mihai Ibanescu]

New submission from Mihai Ibanescu :

If one changes from one timezone to another within the same python
process, and if one tries to parse a time string that includes the
timezone, the library malfunctions.

See attached script for a reproducer.

The problem is that, even though time.tzset() is called, the LocaleTime
persisted in the TimeRE global is not reset. In my example, the EDT
timezone name, compiled from the previous TZ variable, is not valid
anymore in the 'Pacific/Fiji' timezone.

To witness the behavior, run the attached script with no arguments. It
will parse the time in the America/New_York timezone just fine.

Then run it with an argument (like python ttime.py 1). It will first
prime the _strptime cache in the Pacific/Fiji timezone, then attempt to
parse the same time string in the America/New_York timezone.

Finally, you can change the "if 0" to "if 1" for working around the problem.

This has been verified in 2.4.4 and 2.6.1 (did not have a chance to
verify it against python 2.6.2 yet).

--
components: Library (Lib)
files: ttime.py
messages: 90497
nosy: mibanescu
severity: normal
status: open
title: time.tzset does not reset _strptime's locale time cache
type: behavior
versions: Python 2.4, Python 2.6
Added file: http://bugs.python.org/file14496/ttime.py

___
Python tracker 

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

[issue6477] Pickling of NoneType raises PicklingError

[July Tikhonov]

New submission from July Tikhonov :

Python 3.2a0 (py3k:73749M, Jul  1 2009, 23:17:59)
[GCC 4.3.2 [gcc-4_3-branch revision 141291]] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle
[40072 refs]
>>> pickle.dumps(type(None))
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python3.2/pickle.py", line 1358, in dumps
Pickler(f, protocol, fix_imports=fix_imports).dump(obj)
_pickle.PicklingError: Can't pickle : attribute 
lookup builtins.NoneType failed
[40137 refs]
>>>

--
components: Library (Lib)
messages: 90496
nosy: July
severity: normal
status: open
title: Pickling of NoneType raises PicklingError
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

___
Python tracker 

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

[issue6476] MSVCRT's spawnve/spawnvpe are not thread safe

[Jose Fonseca]

New submission from Jose Fonseca :

MSVCRT's implementation of _spawnve, _spawnvpe, or any version that
takes an environ as paramater is not thread-safe, because it stores a
temporary environment string into a global variable.

_spawnve, _spawnvpe, and friends call a function named _cenvarg which
concatenate the environment strings into a global variable called
_aenvptr, which gets free'd and zero'd after each invocation.

This was causing random build failures in scons when parallel build (-j)
was enabled.

The sample application evidences this problem. It also includes a simple
workaround in python, by acquiring a global lock around os.spawnve, and
simulating P_WAIT with P_NOWAIT to avoid holding the global lock while
the child process is running. I believe something along these lines
should be done for CPython on Windows.

--
components: Interpreter Core
files: spawnve.py
messages: 90495
nosy: jfonseca
severity: normal
status: open
title: MSVCRT's spawnve/spawnvpe are not thread safe
type: crash
versions: Python 2.4, Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14495/spawnve.py

___
Python tracker 

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

[issue6418] unittest.TestProgram change breaks nose

[Michael Foord]

Michael Foord  added the comment:

Oops - I meant revision 73997 of course.

--

___
Python tracker 

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

[issue6418] unittest.TestProgram change breaks nose

[Michael Foord]

Michael Foord  added the comment:

Committed in revision 6418. Still needs fixing in trunk (note the patch
itself can't be applied as it is missing a couple of 'self's).

Having problems testing this fix without causing spurious output on stderr.

--

___
Python tracker 

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

[issue1563] asyncore and asynchat incompatible with Py3k str and bytes

[Jean-Paul Calderone]

Jean-Paul Calderone  added the comment:

> It's not, I was more thinking of push_str(foo), where it uses a
default encoding. I think some people don't know what unicode or
encoding is, or don't want to worry about it.

Nice as it sounds, the problem with this is that those people cannot
write correct programs without understanding this.  A push_str API which
implicitly encodes unicode to str would just be a point for bugs to be
introduced.

--

___
Python tracker 

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

[issue1563] asyncore and asynchat incompatible with Py3k str and bytes

[Jorrit Posthuma]

Jorrit Posthuma  added the comment:

On 13 jul 2009, at 17:33, Jean-Paul Calderone wrote:
>
> Jean-Paul Calderone  added the comment:
>
>> It's not 'that' clear you should only work with bytes on a socket.
>
> It's pretty clear to me. :)  That's what sockets can deal with -  
> bytes.

It's allso clear to me, but there are people that don't know that.

> If you want to transfer something other than bytes via a socket, then
> you need to convert it to bytes.  In the case of unicode, there are  
> many
> different choices which can be made for how to do this conversion.
> asyncore cannot know what the correct choice is in any particular
> situation, so it shouldn't try to make it.
>
> The attached patch forces the application to make this choice,
> fortunately.  However, since push_str is only one line, I'm not sure
> what the attraction is.  Why is push_str(foo, bar) preferable to
> push(foo.encode(bar))?

It's not, I was more thinking of push_str(foo), where it uses a  
default encoding. I think some people don't know what unicode or  
encoding is, or don't want to worry about it.

>
>> Maybe it's possible to do a default byte conversion when the user  
>> is working with strings.
>
> This definitely isn't reasonable and should not be done.  It's also  
> not
> what the last proposed patch does, so it doesn't seem to the direction
> the other interested parties have been working in.

It's not an attack ;), i'm pretty new to Python, and it was just  
something that i noticed (after changing from 2 to 3)

--

___
Python tracker 

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

[issue1563] asyncore and asynchat incompatible with Py3k str and bytes

[Jean-Paul Calderone]

Jean-Paul Calderone  added the comment:

> It's not 'that' clear you should only work with bytes on a socket. 

It's pretty clear to me. :)  That's what sockets can deal with - bytes.
 If you want to transfer something other than bytes via a socket, then
you need to convert it to bytes.  In the case of unicode, there are many
different choices which can be made for how to do this conversion. 
asyncore cannot know what the correct choice is in any particular
situation, so it shouldn't try to make it.

The attached patch forces the application to make this choice,
fortunately.  However, since push_str is only one line, I'm not sure
what the attraction is.  Why is push_str(foo, bar) preferable to
push(foo.encode(bar))?

> Maybe it's possible to do a default byte conversion when the user is
working with strings.

This definitely isn't reasonable and should not be done.  It's also not
what the last proposed patch does, so it doesn't seem to the direction
the other interested parties have been working in.

--
nosy: +exarkun

___
Python tracker 

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

[issue1563] asyncore and asynchat incompatible with Py3k str and bytes

[Jorrit Posthuma]

Jorrit Posthuma  added the comment:

It's not 'that' clear you should only work with bytes on a socket. 
Especially not when using a wrapper like asynchat. They are supposed to 
make it easier, and passing a string is easier. Maybe it's possible to do 
a default byte conversion when the user is working with strings.

--
nosy: +JPosthuma

___
Python tracker 

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

[issue6475] Documentation > Tutorial > List Comprehensions

[Mark Dickinson]

Changes by Mark Dickinson :


--
status: open -> pending

___
Python tracker 

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

[issue6475] Documentation > Tutorial > List Comprehensions

[Mark Dickinson]

Mark Dickinson  added the comment:

> I think that the fresh fruits can really be considered as dangerous
> weapons.

Indeed.  Google for "monty python self-defence against fresh fruit".

--
nosy: +marketdickinson
status: pending -> open

___
Python tracker 

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

[issue6475] Documentation > Tutorial > List Comprehensions

[Ezio Melotti]

Ezio Melotti  added the comment:

That example was introduced in r16743 as:
>>> spcs = ["  Apple", " Banana ", "Coco  nut  "]
>>> print [s.strip() for s in spcs]
['Apple', 'Banana', 'Coco  nut']

and was changed in r16831 to:
>>> freshfruit = ['  banana', '  loganberry ', 'passion fruit  ']
>>> [weapon.strip() for weapon in freshfruit]
['banana', 'loganberry', 'passion fruit']

I think that the fresh fruits can really be considered as dangerous
weapons - especially the banana. 

--
nosy: +ezio.melotti
priority:  -> low
resolution:  -> rejected
status: open -> pending

___
Python tracker 

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

[issue6475] Documentation > Tutorial > List Comprehensions

[Retro]

New submission from Retro :

There's a mistake in the code snippet:

>>> freshfruit = ['  banana', '  loganberry ', 'passion fruit  ']
>>> [weapon.strip() for weapon in freshfruit]
['banana', 'loganberry', 'passion fruit']


The second line should be:
>>> [fruit.strip() for fruit in freshfruit]
['banana', 'loganberry', 'passion fruit']


The old code snippet had weapons as items which many people didn't like,
so the code snippet was changed into a friendlier version. Please fix
this code snippet so that weapons are not involved here, even though the
code is not broken. Thank you.

--
assignee: georg.brandl
components: Documentation
messages: 90486
nosy: Retro, georg.brandl
severity: normal
status: open
title: Documentation > Tutorial > List Comprehensions
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

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

[issue6474] Inconsistent TypeError message on function calls with wrong number of arguments

[Hagen Fürstenau]

New submission from Hagen Fürstenau :

I think the following error messages are inconsistent and confusing:

>>> def f(a, b): pass
...
>>> f(a=1)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: f() takes exactly 2 non-keyword positional arguments (1 given)
>>> f(b=1)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: f() takes exactly 2 non-keyword positional arguments (0 given)


Strictly speaking, no positional arguments are given in either case, so
it should say "(0 given)" in both cases. On the other hand, the given
keyword arguments are filled into the positional argument slots, so
stating something like "(1 missing)" or "(1 unspecified)" in both cases
seems to make more sense. Any opinions?

--
components: Interpreter Core
messages: 90485
nosy: hagen
severity: normal
status: open
title: Inconsistent TypeError message on function calls with wrong number of 
arguments
type: behavior
versions: Python 2.7, Python 3.2

___
Python tracker 

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

[issue6433] multiprocessing: pool.map hangs on empty list

[Jesse Noller]

Jesse Noller  added the comment:

It's on my list for this week.

--

___
Python tracker 

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

[issue6433] multiprocessing: pool.map hangs on empty list

[Eric Eisner]

Eric Eisner  added the comment:

Can anyone review this patch? It is a very simple fix to catch this one
edge case. As this can cause multiprocessing to enter a state where it
needs to be externally killed, it would be good if this made 2.6.3.

--

___
Python tracker 

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

[issue6469] Function definition expressions feature

[R. David Murray]

R. David Murray  added the comment:

Even assuming you'd gotten a rough consensus on python-ideas (which it
does not appear that you have), a change of this nature would require a
PEP, and is thus not suitable for the tracker.

--
nosy: +r.david.murray
priority:  -> normal
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue5753] CVE-2008-5983 python: untrusted python modules search path

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Besides, the new API makes the behaviour more explicit and puts the
decision in the hands of the embedding developer (which certainly knows
better than us what he wants to do).
As the Python Zen says:

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

--

___
Python tracker 

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

[issue5753] CVE-2008-5983 python: untrusted python modules search path

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Indeed, it would certainly be useful to review current behaviour and
document it precisely; and then, perhaps change it in order to fix the
current bug. The problem is that the current behaviour seems to have
evolved quite organically, and it's not obvious who relies on what (as I
said, Python has many users). I'm not myself motivated in doing such a
research. Perhaps other developers can chime in.

--

___
Python tracker 

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

[issue6457] subprocess.Popen.communicate can lose data from output/error streams when broken input pipe occures

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Right, file.write raises IOError when os.write raises OSError :-(
Updated the patch.

--
Added file: http://bugs.python.org/file14494/broken_pipe-2.patch

___
Python tracker 

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

[issue6457] subprocess.Popen.communicate can lose data from output/error streams when broken input pipe occures

[Dariusz Walczak]

Dariusz Walczak  added the comment:

Your patch works for me with one exception:

On FreeBSD (python 2.6.1) OSError exception is raised by os.write
instead of IOError exception (raised by self.stdin.write on Windows).
The error code is same on both platforms.

--

___
Python tracker 

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

[issue6314] logging.basicConfig(level='DEBUG', ... and setLevel("DEBUG") result in no logging

[Vinay Sajip]

Vinay Sajip  added the comment:

Fixed checked into trunk & py3k as per msg90214.

--
resolution:  -> fixed
status: open -> pending

___
Python tracker 

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

[issue6458] With logging.config.fileConfig can't create logger without handler

[Vinay Sajip]

Vinay Sajip  added the comment:

Just set up a handlers= line in the relevant sections. You don't have to
actually specify any handlers.

--
nosy: +vsajip
resolution:  -> invalid
status: open -> closed

___
Python tracker 

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

[issue6444] multiline exception logging via syslog handler

[Vinay Sajip]

Vinay Sajip  added the comment:

Why can't you either use %r in the format string if you know you'll be
printing out multiple lines, or define your own handler/formatter to do
exactly what you want? I can't see how to provide what you need in a
generally useful way in the stdlib.

--
assignee:  -> vsajip
nosy: +vsajip
status: open -> pending

___
Python tracker 

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

[issue6469] Function definition expressions feature

[Chris Perkins]

Chris Perkins  added the comment:

Details and discussion: 
http://groups.google.com/group/python-ideas/browse_frm/thread/a2bb1ff3992d9c01

--

___
Python tracker 

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

[issue5753] CVE-2008-5983 python: untrusted python modules search path

[Tomas Hoger]

Tomas Hoger  added the comment:

Additional API has one disadvantage - it requires a modification of all
affected applications embedding python, which is not likely to happen
soon after the API is introduced.

Therefore, it may still be worth reviewing current behaviour (that
seemed to have had no documentation until recently, see issue #5144, and
can probably still benefit from more warnings related to the embedded
use) in this corner case (argv0 is bogus and contains no '/') to see if
it may be worth changing in future python versions.

As for command line flags, I presume you're referring to the
'wcscmp(argv0, L"-c")' part of the patch.  It's not more than a re-use
of the pattern already used couple of times in the PySys_SetArgv, that
got added via:

http://svn.python.org/view?view=rev&revision=39544

Again, it's an attempt to make sure this only changes behaviour in
rather specific case.

--

___
Python tracker 

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

[issue6473] hmac sha384/sha512 fails test vectors

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
priority:  -> critical
stage:  -> needs patch
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.5

___
Python tracker 

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

[issue1820] Enhance Object/structseq.c to match namedtuple and tuple api

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Raymond Hettinger wrote:
> Raymond Hettinger  added the comment:
> 
> In Py3.x, this fails:
> "%s.%s.%s-%s-%s" % sys.version_info
> 
> The reason is that PyUnicode_Format() expects a real tuple, not a tuple
> lookalike.  The fix is to either have structseq inherit from tuple or to
> modify PyUnicode_Format() to handle structseq:
> 
>if (PyCheck_StructSeq(args)) {
>   newargs = PyTuple_FromSequence(args);
>   if (newargs == NULL)
>   return NULL;
>   result = PyUncode_Format(format, newargs);
>   Py_DECREF(newargs);
>   return result;
>}

-1

The special-casing of tuples vs. non-tuples for % is already
bad enough. Adding structseq as another special case doesn't
make that any better.

What's so hard about writing

"%s.%s.%s-%s-%s" % tuple(sys.version_info)

anyway ?

--
nosy: +lemburg
title: Enhance Object/structseq.c to match namedtuple and tuple api -> Enhance 
Object/structseq.c to match namedtuple and tuple api

___
Python tracker 

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

[issue6457] subprocess.Popen.communicate can lose data from output/error streams when broken input pipe occures

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Testing on Debian with latest trunk:
- the proposed example code works very well (I get all data).
- I added "subprocess._has_poll = False", and some (sometimes all) data
is lost. It seems that select() will return stdin even if it is not
writable.

On Windows of course, communicate() uses a blocking write, and always fail.

The proposed patch ignore the errors when EPIPE is raised, and simply
stops writing.

--
keywords: +needs review, patch
nosy: +amaury.forgeotdarc
stage:  -> patch review
Added file: http://bugs.python.org/file14493/broken_pipe.patch

___
Python tracker 

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

[issue6071] no longer possible to hash arrays

[ivank]

ivank  added the comment:

It no longer works with objects created with buffer() either:

>>> hashlib.sha1(buffer("x")).hexdigest()
Traceback (most recent call last):
  File "", line 1, in 
TypeError: object supporting the buffer API required

--

___
Python tracker 

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