[issue11838] IDLE: make interactive code savable as a runnable script

[Roger Serwy]

Changes by Roger Serwy :


--
nosy: +serwy

___
Python tracker 

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

[issue13003] Bug in equivalent code for itertools.izip_longest

[Eli Bendersky]

Eli Bendersky  added the comment:

Yep, it appears that Raymond has fixed this in changeset b0065b9087ef

--
resolution: wont fix -> fixed

___
Python tracker 

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

[issue13517] readdir() in os.listdir not threadsafe on OSX 10.6.8

[Ross Lagerwall]

Changes by Ross Lagerwall :


--
nosy: +rosslagerwall

___
Python tracker 

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

[issue9090] Error code 10035 calling socket.recv() on a socket with a timeout (WSAEWOULDBLOCK - A non-blocking socket operation could not be completed immediately)

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
nosy:  -terry.reedy

___
Python tracker 

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

[issue13390] Hunt memory allocations in addition to reference leaks

[STINNER Victor]

STINNER Victor  added the comment:

The overhead on PyObject_Malloc() is just an increment on an integer, so it is 
very low (or null).

The feature is interesting, but I'm not convinced that a very simple counter is 
enough to track memory leaks. It may help the CPython test suite, but what 
about real world application?

> I think we should hide at least the initial implementation
> behind PY_REF_DEBUG until we're sure we've worked the kinks
> out of it.

Programs not always behave exactly the same in debug or in release mode. 
Sometimes, bugs disappear in debug mode :-(

If the feature is written to track memory leaks in the CPython test suite, it's 
ok to only expose the function in debug mode.

> Right now this patch will allow to enrich the daily refleak runs

Did you already found real leaks using your hack^Wpatch? (was c6dafa2e2594 
found by your tool?)

--
nosy: +haypo

___
Python tracker 

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

[issue13003] Bug in equivalent code for itertools.izip_longest

[Adam Forsyth]

Adam Forsyth  added the comment:

This is marked as "wont fix" but has been fixed, the resolution should be 
changed.

--
nosy: +agforsyth

___
Python tracker 

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

[issue13518] configparser

[Łukasz Langa]

Łukasz Langa  added the comment:

Hello, Mickey. By doing open('file', 'rb') you're explicitly stating you want 
the file to be opened in BINARY mode which means it doesn't return strings but 
bytes. This is not supported anymore in Python 3. This is clearly documented 
here: 
http://docs.python.org/dev/library/configparser.html#configparser.ConfigParser.read_file

Same goes for urllib.request.urlopen, it returns bytes because this is all 
Python knows at the time of reading the URL. If you happen to know the encoding 
(for instance by parsing the data or headers) you can do something like this: 
http://docs.python.org/dev/library/urllib.request.html#examples . Your example 
would become:

config.read_string(urlopen(path_config).read().decode('utf-8'))

Since this is a reasonable mistake to make, I'm leaving this open to adjust the 
exception raised if read() yields bytes instead of expected strings.

--
assignee:  -> lukasz.langa
components: +Library (Lib) -Build
keywords: +easy
priority: normal -> low
versions: +Python 3.3

___
Python tracker 

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

[issue13518] configparser

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +lukasz.langa

___
Python tracker 

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

[issue13518] configparser

[Mickey Ju]

New submission from Mickey Ju :

If this issue has raised previously, then I am sorry for repeating.  I did a 
search but did not find related reports.

Below is the thing I did.

  config = configparser.RawConfigParser()
  #config.read_file(urlopen(path_config))
  config.read_file(open('jkl.ini', 'rb'))

The line commented out was the thing I wanted to do originally.  I wanted to 
parse a configuration file stored on some web server.  And I got this error 
"TypeError: startswith first arg must be bytes or a tuple of bytes, not str."  
But after I tried, with this line "config.read_file(open('jkl.ini', 'rb'))", 
the same error can be reproduced.  Therefore, I think the error message should 
be stated another way around as "startswith first arg must be str instead of 
bytes or a tuple of bytes."  I have checked this by adding the lines below to 
configparser.py after the for-loop at line 994.

  print(type(line))
  line = str(line, 'utf-8')
  print(type(line))

That made the code work.

--
components: Build
messages: 148747
nosy: mickeyju
priority: normal
severity: normal
status: open
title: configparser
type: behavior
versions: Python 3.2

___
Python tracker 

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

[issue5689] Support xz compression in tarfile module

[Martin v . Löwis]

Martin v. Löwis  added the comment:

There is plenty of time until 3.3. OTOH, if Eric wants to work on it now: you 
got a week :-) Do recognize that there is a patch to start from already.

--

___
Python tracker 

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

[issue13517] readdir() in os.listdir not threadsafe on OSX 10.6.8

[Charles-François Natali]

Charles-François Natali  added the comment:

And here's a post by Ulrich Drepper:
http://udrepper.livejournal.com/18555.html

"""
readdir_r is only needed if multiple threads are using the same directory 
stream. I have yet to see a program where this really is the case. In this toy 
example the stream (variable dir) is definitely not shared between different 
threads. Therefore the use of readdir is just fine. Should this matter? Yes, it 
should, since readdir_r has to copy the data in into the buffer provided by the 
user while readdir has the possibility to avoid that.
"""

So I'm even more confident that we should keep the current code.
At least, before going any further (and complicating the code), I'd like to 
know whether this can be reproduced with a small C snippet.

--

___
Python tracker 

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

[issue13517] readdir() in os.listdir not threadsafe on OSX 10.6.8

[Thouis (Ray) Jones]

Thouis (Ray) Jones  added the comment:

> > It's also possible that readdir() is not reentrant with lstat()
> This doesn't make much sense to me.

Me either.  I think what I was actually seeing was multiple calls to readdir() 
still occurring even after placing a mutex on os.listdir due to my wrapping of 
os.listdir in a timeout via a subthread, and mutexing the timeout-wrapped 
version.  I will test this more carefully tomorrow.

I will also look into creating some C code to demonstrate the bug.

--

___
Python tracker 

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

[issue13517] readdir() in os.listdir not threadsafe on OSX 10.6.8

[Thouis (Ray) Jones]

Thouis (Ray) Jones  added the comment:

Reading through many pages discussing readdir vs. readdir_r (many on security 
mailing lists, a large number referring to the page linked in the patch), I get 
the impression that most implementations are thread-safe as long as separate 
threads do not call readdir() using the same DIR pointer.

I believe there is some ambiguity in the POSIX specification as to whether this 
is the only way in which readdir() might be thread-unsafe.

--

___
Python tracker 

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

[issue13517] readdir() in os.listdir not threadsafe on OSX 10.6.8

[Charles-François Natali]

Charles-François Natali  added the comment:

> Is there any reason to believe that the problem is confined to OS X?

It's a bit of a grey area.
Here's what POSIX says:

http://pubs.opengroup.org/onlinepubs/009695399/functions/readdir.html

"""
The pointer returned by readdir() points to data which may be overwritten by 
another call to readdir() on the same directory stream. This data is not 
overwritten by another call to readdir() on a different directory stream.
"""

So it seems safe as long as the threads are using distinct DIR *.
However, the documentation also says this:
"""
The readdir() function need not be reentrant. A function that is not required 
to be reentrant is not required to be thread-safe.
"""

So in theory, readddir() could use some static/global state which may make it 
not thread-safe.

I just had a look at glibc's implementation, and it is indeed safe:
http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/readdir.c;h=13e5e9a0213fcf37d5f289483439bff701a9708a;hb=HEAD

Every "sane" implementation should be safe in practice.

Now, it wouldn't be the first time we encounter such a stupid bug on OS X, but 
it would be nice to have a a short reproducer code in C to make sure.

> It's also possible that readdir() is not reentrant with lstat()

This doesn't make much sense to me.

--

___
Python tracker 

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

[issue13517] readdir() in os.listdir not threadsafe on OSX 10.6.8

[Thouis (Ray) Jones]

Changes by Thouis (Ray) Jones :


Added file: http://bugs.python.org/file23834/py272_readdir_r.v2.patch

___
Python tracker 

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

[issue13517] readdir() in os.listdir not threadsafe on OSX 10.6.8

[Thouis (Ray) Jones]

Thouis (Ray) Jones  added the comment:

I should add the caveat that I am not completely confident that I have 
stress-tested the patch enough to be sure that it actually addresses the 
problem.  It is still possible that this is an error in OSX or the remote 
fileserver in which a large amount of concurrent traffic is causing it to 
actually return invalid data.  This is somewhat belied by the fact that I was 
running 'find' at the same time, and did not see it give variable answers, 
ever. I will continue testing.

--

___
Python tracker 

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

[issue13517] readdir() in os.listdir not threadsafe on OSX 10.6.8

[Ned Deily]

Ned Deily  added the comment:

Is there any reason to believe that the problem is confined to OS X?

--
nosy: +ned.deily, neologix

___
Python tracker 

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

[issue13517] readdir() in os.listdir not threadsafe on OSX 10.6.8

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

The link mentioned in the patch is really interesting:
http://womble.decadent.org.uk/readdir_r-advisory.html

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue13517] readdir() in os.listdir not threadsafe on OSX 10.6.8

[Thouis (Ray) Jones]

Thouis (Ray) Jones  added the comment:

Here is the script I use to detect the failure.
% python filefinder.py /PATH/TO/LARGE/DIRECTORY/TREE

(note that I was working over samba with an 8ish-level deep directory with 
around 25 files).

Compare its final output in the FOUND column with 
% find /PATH/TO/LARGE/DIRECTORY/TREE | wc -l

--
Added file: http://bugs.python.org/file23833/filefinder.py

___
Python tracker 

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

[issue13517] readdir() in os.listdir not threadsafe on OSX 10.6.8

[Thouis (Ray) Jones]

New submission from Thouis (Ray) Jones :

On my system (OSX 10.6.8) using the python.org 32/64-bit build of 2.7.2, I see 
incorrect results from os.listdir() in a threaded program.  The error is that 
the result of os.listdir() is missing a few files from its list.

First, my use case.  I work with large image-based datasets, often with 
hundreds of thousands of images.  The first step in processing is to locate all 
of these images and extract some basic information (size, channels, etc.).  To 
do this more efficiently on network filesystems, where listing directories and 
stat()ing files is often slow, I wrote a multithreaded analog to os.walk().  
While validating its results against unix 'find', I saw discrepancies in the 
number of files found.

My guess is that OSX's readdir() is not reentrant when dealing with SMB shares, 
even on different DIR pointers.  It's also possible that readdir() is not 
reentrant with lstat(), as some of my tests seemed to indicate this, but I need 
to run some more tests to be sure that's what I was actually seeing.

In any case, there are three possible ways to fix this, I think.

- Remove the Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS around readdir() in 
posixmodule.c

- Put a mutex on readdir()

- Use readdir_r().  I've attached a potential patch for 2.7.2 for this solution.

I would prefer the second or last approach, as they preserve the ability to do 
other work while listing large directories.

By my reading of the python 3.0 to 3.4 sources, this problem exists in those 
versions, as well.

--
components: Library (Lib)
files: py272_readdir_r.patch
keywords: patch
messages: 148737
nosy: thouis
priority: normal
severity: normal
status: open
title: readdir() in os.listdir not threadsafe on OSX 10.6.8
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file23832/py272_readdir_r.patch

___
Python tracker 

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

[issue9090] Error code 10035 calling socket.recv() on a socket with a timeout (WSAEWOULDBLOCK - A non-blocking socket operation could not be completed immediately)

[Okko Willeboordse]

Okko Willeboordse  added the comment:

I bumped into this issue at one of my customers that use Python to control a 
machine through Beckhoff EtherCAT. The Python code communicates with the 
Beckhoff EtherCAT program using TCP/IP.
They use non blocking sockets like so;
s = select.select([self._socket], [], [], timeout)[0]
if not s:
  raise NoData
self._socket.recv(length)

They also found that the recv occasionally raises a 10035.
I changed the code in to;
s = select.select([self._socket], [], [], timeout)[0]
if not s:
  raise NoData
try:
  buffer_ = self._socket.recv(length)
except socket.error as inst:
  if (gaius.utils.Platform.WINDOWS and 10035 == inst.args[0]) or \
 (gaius.utils.Platform.LINUX and 11 == inst.args[0]):
raise NoData

So this issue applies also to sockets without timeout, albeit it can be worked 
around easily. 

Also note that this also applies to Linux as the man page of select states in 
the BUG section;

Under Linux, select() may report a socket file descriptor as "ready for
reading",  while  nevertheless a subsequent read blocks. This could for
example happen when data has arrived but  upon  examination  has  wrong
checksum  and is discarded. There may be other circumstances in which a
file descriptor is spuriously reported as ready.  Thus it may be  safer
to use O_NONBLOCK on sockets that should not block.

Note that Linux select is not Posix compliant as Posix states;

A descriptor shall be considered ready for reading when a call to an input 
function with O_NONBLOCK clear would not block, whether or not the function 
would transfer data successfully.

See https://lkml.org/lkml/2011/6/18/76

MSDN select says;

For other sockets, readability means that queued data is available for reading 
such that a call to recv, WSARecv, WSARecvFrom, or recvfrom is guaranteed not 
to block.

http://support.microsoft.com/kb/177346 says (for Windows 95);

The Winsock select() API might fail to block on a nonblocking socket and return 
WSAEWOULDBLOCK as an error code when either send() or recv() is subsequently 
called. For example, select() may return indicating there is data to read, yet 
a call to recv() returns with the error code WSAEWOULDBLOCK, indicating there 
is no data immediately available. Windows NT 4.0 does not exhibit this behavior.


Finally I have 2 questions;

Is this select behavior on Windows 'normal'? Noting that it is not documented. 
or does it behaves this way due to crippled NIC's or drivers (VMWare)?

Can this behavior be reproduced? I need this for automatic testing. Now these 
exceptional paths cannot be tested.

--
nosy: +Okko.Willeboordse

___
Python tracker 

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

[issue9009] Improve quality of Python/dtoa.c

[Rick Regan]

Rick Regan  added the comment:

>   if (!(dig = quorem(b,d))) {
>   b = multadd(b, 10, 0);  /* very unlikely */
>   dig = quorem(b,d);
>   }
> 
> This code is part of the algorithm for strtod.  Here b and d are
> Bigints, and b / d is a fraction that gives an approximation to 
> the value of the input to strtod;  the aim is to produce the 
> digits of b / d one-by-one to compare them with the strtod input,
> and (eventually) use the result of that comparison work out whether
> to round up or down.

> If the condition of the 'if' block above is ever satisfied, b is 
> multiplied by 10 (that's the multadd(b, 10, 0) call), so the 
> fraction b / d is multiplied by 10 (with no corresponding correction
> for the strtod input string), and the wrong comparison is made!

Mark,

I think I know the motivation for this code, although I still don't know how it 
could hit. The halfway value H is scaled by a power of ten to put it in the 
form "d1.d2d3d4d5...". The power of ten exponent is derived from the input 
decimal string S, instead of computing it from H using logarithms.

Now what if H's exponent does not match S's? I'm thinking of cases like S = 
10^n and H = 9.... * 10^(n-1). Scaling H by 10^-n would make it 
0.9... . That leading 0 needs to be removed, by multiplying by 10, do 
put it in the right form.

First of all, I don't know if a case like this is possible. Second of all, the 
check would fail either way (1 against 0 vs 1 against 9).
 
BTW, b / d represents only the significant digits of H, so it shouldn't matter 
that there's no corresponding adjustment to the input string.

To summarize: I'm not saying this code is necessary; I'm just saying it makes 
you wonder.

--
nosy: +DoctorBinary

___
Python tracker 

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

[issue13390] Hunt memory allocations in addition to reference leaks

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> > If someone finds a way to sanitize Valgrind output,
> 
> Did you use the valgrind suppression file (Misc/valgrind-python.supp)?

Ah, I hadn't. But using it doesn't seem to make much of a difference.
Also, the suppressions file seems quite inflexible (it has hardcoded
library version numbers for third-party libs).

--

___
Python tracker 

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

[issue12612] Valgrind suppressions

[Paul Price]

Paul Price  added the comment:

Here's the diff with the added sections commented out.

--
keywords: +patch
Added file: http://bugs.python.org/file23831/proposed.patch

___
Python tracker 

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

[issue13516] Gzip old log files in rotating handlers

[Raul Morales]

New submission from Raul Morales :

Sometimes log files grow very quickly and consume too much disk space (e.g. 
DEBUG), so compress old log files saves disk space without losing the 
information from log files.

I propose to add a "gzip" or "compress" argument to RotatingFileHandler and 
TimedRotatingFileHandler to select the number of old files you want to compress.

For example, if you set the argument to 0 (default) no files are gzipped , but 
if you set it to 3 you get the following log files:
app.log
app.log.1
app.log.2
app.log.3.gz
app.log.4.gz
...
app.log.n.gz

For TimedRotatingFileHandler it works similar, gzipping from the n-th newer log 
file to the oldest log file:
app.log
app.log.2011-12-01
app.log.2011-11-30
app.log.2011-11-29.gz
app.log.2011-11-28.gz
...

A possible patch is attached

--
components: Library (Lib)
files: log.patch
keywords: patch
messages: 148732
nosy: ramhux, vinay.sajip
priority: normal
severity: normal
status: open
title: Gzip old log files in rotating handlers
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file23830/log.patch

___
Python tracker 

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

[issue13390] Hunt memory allocations in addition to reference leaks

[Charles-François Natali]

Charles-François Natali  added the comment:

> If someone finds a way to sanitize Valgrind output,

Did you use the valgrind suppression file (Misc/valgrind-python.supp)?
If yes, then one could simply use --gen-suppressions=yes to add those spurious 
warning to the suppression file.

> a daily Valgrind run would be cool as well.

Daily, or rather weakly, since running under valgrind is so much slower ;-)

--

___
Python tracker 

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

[issue12612] Valgrind suppressions

[Charles-François Natali]

Charles-François Natali  added the comment:

Could you please provide a diff ?
Also, they should probably be commented by default (as other obmalloc-related 
calls).

--
nosy: +neologix

___
Python tracker 

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

[issue13512] ~/.pypirc created insecurely

[Philip Jenvey]

Philip Jenvey  added the comment:

2.5 is done 
http://mail.python.org/pipermail/python-committers/2011-October/001844.html

--

___
Python tracker 

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

[issue12850] [PATCH] stm.atomic

[Armin Rigo]

Armin Rigo  added the comment:

Closing the request for this patch.  It is unsatisfactory that it only offers 
the basic user-level STM feature of transaction, but not, say, 
abort_and_retry() or any other feature generally found in real-world STM 
implementations.  This goes against the idea, which was (in part) to let 
python-dev people play with it to know which features seem to make sense in 
Python.

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

[issue5302] Allow package_data specs/globs to match directories

[Éric Araujo]

Éric Araujo  added the comment:

As a first step for this, I moved around some things in the test file to ease 
coming additions.  Can someone test this patch for the distutils2 repo on 
Windows?

--
keywords: +patch
Added file: http://bugs.python.org/file23829/test_sdist.diff

___
Python tracker 

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

[issue9530] integer undefined behaviors

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 7e37598a25a6 by Mark Dickinson in branch 'default':
Issue #9530: Fix undefined behaviour due to signed overflow in 
Python/formatter_unicode.c.
http://hg.python.org/cpython/rev/7e37598a25a6

--

___
Python tracker 

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

[issue1040439] Missing documentation on how to link with libpython

[Éric Araujo]

Éric Araujo  added the comment:

I did a review on Rietveld.

--

___
Python tracker 

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

[issue13512] ~/.pypirc created insecurely

[Éric Araujo]

Éric Araujo  added the comment:

Thanks for the report Vincent.  Philip, your patch looks good, except that the 
code cannot use the with statement due to PEP 291 (I’ll take care of that).  
2.5 is also affected (the code is in the distutils.command.register module).

I don’t think we can write a test for this bug.

Barry, Martin, do you think this important enough for the versions in security 
mode?  (I’ve forgotten whether 2.5 is still in security mode or not, and can’t 
find the info online).

--
assignee: tarek -> eric.araujo
nosy: +barry, loewis
stage:  -> patch review
versions: +Python 3.2, Python 3.3

___
Python tracker 

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

[issue12307] Inconsistent formatting of section titles in PEP 0

[Éric Araujo]

Éric Araujo  added the comment:

Plain text PEPs actually have an HTML title, it’s only PEP 0 that does not.  
I’ll fix that when I get a minute.

--

___
Python tracker 

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

[issue11060] distutils2 sdist does not complain about version that is not PEP 386 compliant

[Éric Araujo]

Éric Araujo  added the comment:

Hi Berker Peksag, thanks for your interest in contributing.  Your patch is not 
what I had in mind: In test_command_sdist, a test should create an sdist and 
check that it fails with an error message, not instantiate a version object.  
Distutils2 has many layers; at the base, version needs to reject an incorrect 
version with a Python exception (and we should test that in test_version), at 
the top, commands like check, sdist and bdist should catch that exception and 
display a user-friendly error message (and their tests should create Python 
files and run the command).  Does this help?

--
assignee: tarek -> eric.araujo
stage:  -> test needed
versions: +Python 3.3

___
Python tracker 

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

[issue7652] Merge C version of decimal into py3k.

[Stefan Krah]

Stefan Krah  added the comment:

[Amaury]
> Overall, I think that the "mpd" C library should be better separated from the
> _decimal module (a bit like _ctypes, with the libffi library): its own 
> configure
> & makefile, its own test suite... which are not necessarily related to Python.

Except for its own directory libmpdec has all that (See LIBTEST.txt). Library
tests are in the tests/ directory, python tests in the python/ directory.

Are you suggesting to build a static library and then use that to build
the module? I remember this didn't work on Windows (not to mention AIX and 
such).

--

___
Python tracker 

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

[issue13515] Consistent documentation practices for security concerns and considerations

[Nick Coghlan]

Nick Coghlan  added the comment:

Yep, using notes rather than simple inline links would also be fine with me. 
So, with "in-line text" changed to "a ReST note", what do people otherwise 
think about the proposed style guide addition?

--

___
Python tracker 

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

[issue8668] Packaging: add a 'develop' command

[chris]

Changes by chris :


--
nosy: +chris

___
Python tracker 

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

[issue13515] Consistent documentation practices for security concerns and considerations

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I agree 100% with Ezio here.

--
nosy: +pitrou

___
Python tracker 

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

[issue11060] distutils2 sdist does not complain about version that is not PEP 386 compliant

[Berker Peksag]

Changes by Berker Peksag :


--
nosy: +berkerpeksag
Added file: http://bugs.python.org/file23828/issue11060_test_v1.diff

___
Python tracker 

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

[issue13515] Consistent documentation practices for security concerns and considerations

[Ezio Melotti]

Ezio Melotti  added the comment:

I think we are mixing a few different things here:
1) the content of the warning(s);
2) the position of the warning(s);
3) the style of the warning(s);

Duplicating the same content in each warning is bad, so a specific section that 
summarizes the problem is good.
Having at least a note with a link to the "Security consideration" section in 
each affected function is good too, because without them people won't notice it.
Having big red scary boxes is bad, because people are scared of big red things 
(especially scary ones), and our goal here is to warn, not to scare.

I think the problem with the subprocess doc is that there are many warnings and 
that they are big and red (and scary).  IMHO changing the style of the warning 
would already be a step forward the "clean look" advocated by Raymond.  
Grouping redundant text and possibly rephrasing it a bit would do the rest.

--

___
Python tracker 

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

[issue13515] Consistent documentation practices for security concerns and considerations

[Nick Coghlan]

Nick Coghlan  added the comment:

While I acknowledge the point (it's the reason I *didn't* remove those warnings 
in my recent major update to the subprocess docs), Raymond's right that 
scattering warnings everywhere in the docs for modules like subprocess isn't 
the right answer either. For a lot of things people use those modules for (i.e. 
private scripts with no untrusted user input) the warnings are excessive.

There's only so much we can do to protect novice programmers being given tasks 
beyond their experience, and only so much readability we should sacrifice in 
the name of educating people about general programming issues that aren't 
specific to Python.

--

___
Python tracker 

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

[issue5689] Support xz compression in tarfile module

[Lars Gustäbel]

Lars Gustäbel  added the comment:

I will be happy to, but my spare time is limited right now, so this could take 
about a week. If this is a problem, please go ahead.

--

___
Python tracker 

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

[issue12612] Valgrind suppressions

[Zhiping Deng]

Zhiping Deng  added the comment:

It works for me!

--
nosy: +Zhiping.Deng

___
Python tracker 

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

[issue13493] Import error with embedded python on AIX 6.1

[python_hu]

python_hu  added the comment:

-> void* handle = dlopen("/usr/local/lib/python2.7/lib-dynload/time.so", 2);
this code can work well,but when the code run to :
PyRun_SimpleString("from time import time,ctime\nprint 'Today 
is',ctime(time())\n");

it dumped, i think it make be because of there are two python handle 
running,one is main thread ,anthother is the  time.so.

--

___
Python tracker 

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

[issue13405] Add DTrace probes

[Jesús Cea Avión]

Jesús Cea Avión  added the comment:

The stack walker helper now supports unicode too. This was quite difficult!.

The patch is functionally complete.

Current patch is pretty final. It was easy and painless EXCEPT the stackhelper, 
because the "idea" of "PyCompactUnicodeObject" that GCC and DTRACE have are 
different. Current code includes a couple of "magic numbers". This can be 
fragile. But if it breaks, the only missing functionality would be the 
augmented stack dump. No crashed, because DTRACE probes are safe (for the 
program being monitored).

I guess the best idea would be to generate a ".h" at compile time, with the 
right magic constants.

I have tried to create global variables and import them from the stackhelper. 
That works... unless you use the "-c" DTrace argument. I guess I am hitting 
some bug in DTrace.

Pending: performance analysis. The performance hit should be very small.

Please, do a preliminar review.

--

___
Python tracker 

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

[issue13097] ctypes: segfault with large number of callback arguments

[STINNER Victor]

STINNER Victor  added the comment:

Is there really an use case where you need 2 ** 20 (1,048,576) arguments? If 
yes, I'm not against the torture in this case :-) If no, why not raising an 
error if there are too many arguments? E.g. limit to 1,024 arguments or maybe 
just 10?

--

___
Python tracker 

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

[issue13515] Consistent documentation practices for security concerns and considerations

[Ezio Melotti]

Ezio Melotti  added the comment:

Grouping the common warnings in a "Security Considerations" section sounds OK, 
but the warnings should still be visible IMHO.

In my experience, people:
 1) jump right to the doc for the function they are using;
 2) read the example and try to figure out how it works;
 3) if that fails, they read the text.

An inline text with a simple link might then pass unnoticed.  OTOH littering 
the doc with red boxes is far too noticeable.  Maybe we should use something in 
between (e.g. a "lighter" CSS for the warnings or a small warning icon).

--
nosy: +ezio.melotti

___
Python tracker 

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

[issue13405] Add DTrace probes

[Jesús Cea Avión]

Changes by Jesús Cea Avión :


Removed file: http://bugs.python.org/file23814/3968bb3e698f.diff

___
Python tracker 

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

[issue13405] Add DTrace probes

[Jesús Cea Avión]

Changes by Jesús Cea Avión :


Added file: http://bugs.python.org/file23827/2a7dedf6a65e.diff

___
Python tracker 

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