[issue12539] multiprocessing.Event.wait(n) doesn't time out properly

[Charles-François Natali]

Charles-François Natali  added the comment:

Are you using a 2.6.38 kernel?
There was a regression in early 2.6.38 kernels that caused FUTEX_WAIT with a 
timeout to never return after a suspend-resume, see:
https://lkml.org/lkml/2011/4/13/23

It's been fixed by this commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0cd9c6494ee5c19aef085152bc37f3a4e774a9e1

Could you try with a more recent kernel (it should be fixed in 2.6.38.4)?

--
nosy: +neologix

___
Python tracker 

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

[issue12436] Provide reference to detailed installation instructions

[Nick Coghlan]

Nick Coghlan  added the comment:

Nice, I didn't know we have those comprehensive using docs. However, they 
should be linked from http://docs.python.org/dev/tutorial/interpreter.html 
(definitely inline and perhaps a see also).

--

___
Python tracker 

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

[issue12535] Chained tracebacks are confusing because the first traceback is minimal

[Nick Coghlan]

Nick Coghlan  added the comment:

The ordering is as it is so that the last line in the displayed traceback 
corresponds to the exception that was actually caught. That is, the last line 
remains the same regardless of whether or not there was an earlier exception in 
the chain. Without that, the caught exception would be buried in the middle of 
a wall of text:

Traceback (most recent call last):
  File "", line 1, in 
  File "/home/rdmurray/python/email6/Lib/mailbox.py", line 1631, in set_flags
self.replace_header('Status', status_flags)
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 495, in 
replace_header
print('rep', self.header_factory)
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 469, in 
__getattr__
self.__class__.__name__, key))
AttributeError: 'mboxMessage' object has no attribute 'header_factory'
CAUGHT THIS
This exception was caught while handling:
Traceback (most recent call last):
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 466, in 
__getattr__
return getattr(self._headers, key)
AttributeError: '_Header_List' object has no attribute 'header_factory'
NOT THIS

The consequence is that the outermost call in the call stack ends up buried in 
the middle of a wall of text instead. That's not optimal either, but we have to 
choose one or the other and I think the status quo is the better choice.

However, not closing this yet, as I think RDM may have a valid point: should we 
put something at the *start* of the truncated traceback to indicate that it was 
cut short due to another exception? For example:

Traceback (truncated due to later exception, most recent call last):
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 466, in 
__getattr__
return getattr(self._headers, key)
AttributeError: '_Header_List' object has no attribute 'header_factory'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 1, in 
  File "/home/rdmurray/python/email6/Lib/mailbox.py", line 1631, in set_flags
self.replace_header('Status', status_flags)
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 495, in 
replace_header
print('rep', self.header_factory)
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 469, in 
__getattr__
self.__class__.__name__, key))
AttributeError: 'mboxMessage' object has no attribute 'header_factory'

--

___
Python tracker 

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

[issue4376] Nested ctypes 'BigEndianStructure' fails

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Is there a unit test about the actual feature: that the bytes are actually 
swapped in the structure?

For example, with a
class T(BigEndianStructure): _fields_ = [("a", c_int), ("b", c_int)]
cast a pointer to T into a pointer to c_int, and read the values.

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue12539] multiprocessing.Event.wait(n) doesn't time out properly

[mokrates]

mokrates  added the comment:

> Are you using a 2.6.38 kernel?

Yes

> There was a regression in early 2.6.38 kernels that caused FUTEX_WAIT
> with a timeout to never return after a suspend-resume, see:
> https://lkml.org/lkml/2011/4/13/23

Ah, thank you, that explains why gajim has problems too...

>  Could you try with a more recent kernel (it should be fixed in
> 2.6.38.4)?

I will, when it comes with my ubuntu... Thank you very much.

mo

--

___
Python tracker 

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

[issue12540] "Restart Shell" command leaves pythonw.exe processes running

[Peter Caven]

New submission from Peter Caven :

On Windows Vista (x64) the IDLE "Restart Shell" command leaves a "pythonw.exe" 
process running each time that the command is used.
Observed in Python 3.2.1 release and RC2.

--
components: IDLE
messages: 140179
nosy: Peter.Caven
priority: normal
severity: normal
status: open
title: "Restart Shell" command leaves pythonw.exe processes running
type: resource usage
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

[issue12485] textwrap.wrap: new argument for more pleasing output

[R. David Murray]

Changes by R. David Murray :


--
nosy: +r.david.murray

___
Python tracker 

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

[issue12219] tkinter.filedialog.askopenfilename XT dialog on Windows 7

[digi proc]

digi proc  added the comment:

Almost certainly a tkinter bug.

A work around is below. First build a DLL from the following C++ source (and 
add a similar function for the 'save' dlg rather than the 'open' dlg):

#include "windows.h"
#include "Commdlg.h"
#include "tchar.h"

extern "C"{

 __declspec(dllexport)  wchar_t * _cdecl GetOpenFileNamePlus(HWND 
Parent,LPCWSTR InitDir,LPCWSTR FilenameIn,LPCWSTR Filter,LPCWSTR DefExt,LPCWSTR 
Title)
{
OPENFILENAME OpenFile;

//  MessageBox(NULL,Title,L"",MB_OK);

memset (&OpenFile, 0, sizeof(OPENFILENAME));

static wchar_t Filename[MAX_PATH*2];

_tcscpy(Filename,FilenameIn);

OpenFile.lpstrInitialDir=InitDir;
OpenFile.lStructSize = sizeof(OPENFILENAME);
OpenFile.hwndOwner = Parent;
OpenFile.lpstrFile = Filename;
OpenFile.nMaxFile = MAX_PATH*2+10;
OpenFile.lpstrFilter = Filter;
OpenFile.nFilterIndex = 0;
OpenFile.lpstrDefExt=DefExt;
OpenFile.lpstrTitle = Title;

OpenFile.Flags=OFN_OVERWRITEPROMPT | OFN_PATHMUSTEXIST | 
OFN_NOCHANGEDIR;

long Stat=GetOpenFileName(&OpenFile);

if(Stat)
return Filename;
else
return NULL;
}


}

Then in python call it like this, for example:

import ctypes

commdlg=ctypes.windll.commdlg_plus
commdlg.GetOpenFileNamePlus.argtypes= [ctypes.c_void_p, ctypes.c_wchar_p, 
ctypes.c_wchar_p, ctypes.c_wchar_p, ctypes.c_wchar_p, ctypes.c_wchar_p]
commdlg.GetOpenFileNamePlus.restype= ctypes.c_wchar_p
s=commdlg.GetOpenFileNamePlus(0, "StartDir", "DefFilename", "Text 
files\0*.txt\0Image files\0*.jpg;*.gif\0\0","txt", "Select a file")

--
nosy: +digiproc

___
Python tracker 

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

[issue12219] tkinter.filedialog.askopenfilename XT dialog on Windows 7

[digi proc]

digi proc  added the comment:

By the way, that above C++ function is not re-entrant! I was lazy and just made 
a static return buffer. To make it re-entrant, you'd need to figure out how to 
allocate enough space in the DefFile string so the C function could write the 
selected filename to that buffer instead of making its own.

--

___
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

[higery]

higery  added the comment:

>
> ** After the package has been installed in-place (using the develop
> command), how does one identify it as an in development project (or in
> development mode)? -- Case 3 and 6 touch on this topic (case 3 is a little
> vague at this time), but doesn't explain what type of action is intended. So
> if we install in-place (aka, develop), how does the python interpreter find
> the package? Are we using PYTHONPATH at this point (which would be
> contradict a requirement in  case 6)?
>

There is an .egg-link file that will be used by pkg_resources to find the
develop-installed packages, so my current implementation of develop command
in packaging module also adds a .distinfo-link file in the site-packages
which will be used to identify a project is installed in development mode or
not.

--
Added file: http://bugs.python.org/file22628/unnamed

___
Python tracker 

___

** After the package has been installed in-place (using the develop command), 
how does one identify it as an in development project (or in development mode)? 
-- Case 3 and 6 touch on this topic (case 3 is a little vague at this time), 
but doesn't explain what type of action is intended. So if we install 
in-place (aka, develop), how does the python interpreter find the package? Are 
we using PYTHONPATH at this point (which would be contradict a requirement in 
 case 6)?
There is an .egg-link file that will be used by 
pkg_resources to find the develop-installed packages, so my current 
implementation of develop command in packaging module also adds a 
.distinfo-link file in the site-packages which will be used to identify a 
project is installed in development mode or not.

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

[issue9254] __import__ docstring should recommend importlib.import_module()

[Éric Araujo]

Éric Araujo  added the comment:

The docstring of __import__ was updated to mention importlib in 3d490c3a019e, 
for #7397.  Attached patch edits the docs.

--
keywords: +patch
versions:  -Python 3.1
Added file: http://bugs.python.org/file22629/__import__-mention-importlib.diff

___
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

[Éric Araujo]

Changes by Éric Araujo :


Removed file: http://bugs.python.org/file22628/unnamed

___
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

[Éric Araujo]

Éric Araujo  added the comment:

For now, you should not worry about pkg_resources.  Write a simple 
pure-packaging implementation compatible with packaging; the setuptools and 
distribute developers will see if they want to add forward compatibility with 
our system.

--

___
Python tracker 

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

[issue12539] multiprocessing.Event.wait(n) doesn't time out properly

[Charles-François Natali]

Charles-François Natali  added the comment:

>> Are you using a 2.6.38 kernel?

> Yes

Alright, closing as invalid then.

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

[issue8668] Packaging: add a 'develop' command

[higery]

higery  added the comment:

2011/7/12 Michael Mulich 

>
> Michael Mulich  added the comment:
>
> The wiki page has been edited to note what the develop command will
> write to the file system. I'll restate it here as well...
>
> The develop command writes three pieces of information to the filesystem:
>  1. It calls upon the build action(s) to build the package relative to
> the package's root directory.
>  2. It calls the [build|install]_distinfo action to write the
> .dist-info metadata inside the build directory. (see also Issue 12279)
>  3. It adds the build directory's path to a .pth file.
>

You are right, what you listed above are also the things done by the
'develop' command of my current implementation. In addition, as I replied
earlier, we can also add a .distinfo-link file  more than the .pth file.

--
Added file: http://bugs.python.org/file22630/unnamed

___
Python tracker 

___2011/7/12 Michael Mulich rep...@bugs.python.org>

Michael Mulich michael.mul...@gmail.com> added 
the comment:
The wiki page has been edited to note what the develop command will
write to the file system. I'll restate it here as well...

The develop command writes three pieces of information to the filesystem:
 1. It calls upon the build action(s) to build the package relative to
the package's root directory.
 2. It calls the [build|install]_distinfo action to write the
.dist-info metadata inside the build directory. (see also Issue 12279)
 3. It adds the build directory's path to a .pth 
file.You are right, what you listed above are also 
the things done by the 'develop' command of my current implementation. 
In addition, as I replied earlier, we can also add a .distinfo-link file  more 
than the .pth file.

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

[issue7559] TestLoader.loadTestsFromName swallows import errors

[Alex Garel]

Alex Garel  added the comment:

May I just add that I also ran into this and give my +1 for any fix :-)

--
nosy: +alexgarel

___
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

[higery]

Changes by higery :


Removed file: http://bugs.python.org/file22630/unnamed

___
Python tracker 

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

[issue12279] Add build_distinfo command to packaging

[Éric Araujo]

Éric Araujo  added the comment:

> So if we include the RECORD file (point number 2) without the checksum
> and size (two columns in the RECORD csv format),
Well, three columns, the last one being empty.

> we will still be PEP376 valid (maybe?), but the file verification
> information will be missing. And we don't really want this
> information because if we edit a file, the checksum and size will be
> incorrect anyhow. This missing information is not important when
> using the develop or test commands, because we are running the
> commands on a trusted local copy.
Good thinking.

> What are the consequences of not writing the checksum or size to the
> RECORD file? And does that solve the issue?
I think checksum was intended for use by uninstallers, so we’re good.  I don’t 
know why the size is included.


> I don't really think the "invalid PEP 376" issue is a problem: PEP
> 376 describes the metadata for installed distributions; it has
> nothing to say about built metadata for a distribution which has not
> yet been installed.
The problem is that develop is a kind of install.

> For purposes of the develop command, if a pth file is used to
> implement develop, then ideally when develop is run a RECORD file
> would be added containing only the path to that pth file, as thats
> the only file that has actually been installed
Yeah!

> (and the only one that should be removed if the develop-installed
> package is uninstalled).
Are you saying that such a RECORD file would allow any installer compatible 
with PEP 376 to undo a develop install?  Clever!

--

___
Python tracker 

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

[issue3565] array documentation, method names not 3.x-compliant

[Éric Araujo]

Éric Araujo  added the comment:

It was Antoine in fa8b57f987c5, for #8990.

--
nosy: +eric.araujo

___
Python tracker 

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

[issue10968] threading.Timer should be a class so that it can be derived

[Éric Araujo]

Éric Araujo  added the comment:

Attached patch removes the indirection functions; the _Verbose shenanigans are 
left alone.  The test suite passes; I haven’t edited the doc yet.

--
keywords: +patch
Added file: http://bugs.python.org/file22631/threading-classes.diff

___
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

[higery]

Changes by higery :


Added file: http://bugs.python.org/file22632/2750cd9e2111.diff

___
Python tracker 

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

[issue12541] Accepting Badly formed headers in urllib HTTPBasicAuth

[Alex Leon]

New submission from Alex Leon :

It looks like some servers using basic authentication don't include quotes 
around the realm (example https://api.connect2field.com) as required by rfc 
2617. urllib wont handle these requests and silently fails, but a simple change 
to the regex in AbstractBasicAuthHandler from
 
'realm=(["\'])(.*?)\\2', re.I)
to
'realm=(["\']?)(["\']*)\\2', re.I)

would make authentication more flexible.

--
components: Library (Lib)
messages: 140191
nosy: Alex.Leon
priority: normal
severity: normal
status: open
title: Accepting Badly formed headers in urllib HTTPBasicAuth
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

[issue8668] Packaging: add a 'develop' command

[Éric Araujo]

Changes by Éric Araujo :


Removed file: http://bugs.python.org/file22614/b1b9da3b3d20.diff

___
Python tracker 

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

[issue12417] Inappropriate copyright on profile files

[Éric Araujo]

Éric Araujo  added the comment:

The former license was also present in the reST documentation.  Attached patch 
removes it, and also cleans up two lines: it removes a comment that duplicates 
a docstring, and removes the docstring from profile that you added to pstats :)

--

___
Python tracker 

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

[issue12417] Inappropriate copyright on profile files

[Éric Araujo]

Changes by Éric Araujo :


Added file: http://bugs.python.org/file22633/profile-free-followup.diff

___
Python tracker 

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

[issue12542] Remove duplicates of cmp_to_key used in tests

[Éric Araujo]

New submission from Éric Araujo :

Two test files still use their own CmpToKey after the introduction of 
functools.cmp_to_key.

--
components: Tests
files: remove-custom-cmptokey.diff
keywords: patch
messages: 140193
nosy: eric.araujo, rhettinger
priority: normal
severity: normal
stage: commit review
status: open
title: Remove duplicates of cmp_to_key used in tests
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22634/remove-custom-cmptokey.diff

___
Python tracker 

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

[issue12541] Accepting Badly formed headers in urllib HTTPBasicAuth

[Senthil Kumaran]

Changes by Senthil Kumaran :


--
assignee:  -> orsenthil
nosy: +orsenthil

___
Python tracker 

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

[issue12542] Remove duplicates of cmp_to_key used in tests

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
resolution:  -> accepted

___
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

[Michael Mulich]

Michael Mulich  added the comment:

On Tue, Jul 12, 2011 at 9:39 AM, higery  wrote:
>> The develop command writes three pieces of information to the filesystem:
>>  1. It calls upon the build action(s) to build the package relative to
>> the package's root directory.
>>  2. It calls the [build|install]_distinfo action to write the
>> .dist-info metadata inside the build directory. (see also Issue 12279)
>>  3. It adds the build directory's path to a .pth file.
>>
>
> You are right, what you listed above are also the things done by the
> 'develop' command of my current implementation. In addition, as I replied
> earlier, we can also add a .distinfo-link file  more than the .pth file.

I don't like the idea of a .distinfo-link file. Would it even be
necessary if we already have a .pth entry?

We should probably just use one of these files, either .distinfo-link
or .pth. The .pth implementation has the least impact on code base and
is already implemented. If we add support for a .distinfo-link, we
would then need to modify database module to support that extension.

--

___
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

[Éric Araujo]

Éric Araujo  added the comment:

Oh, I just realized that one thing I insisted on was wrong.

I pushed for the modules to be built in the build dir, as well as the dist-info 
dir, so that the build dir can be added to sys.path to let both import and 
packaging.database find the files.  But this breaks one important develop 
feature: editions to the code should be visible immediately, without having to 
re-run develop or build.

--

___
Python tracker 

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

[issue12279] Add build_distinfo command to packaging

[Éric Araujo]

Éric Araujo  added the comment:

About writing dist-info files into the build dir or the project root dir, see 
msg140195

--

___
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

[Éric Araujo]

Éric Araujo  added the comment:

Ah, higery’s code already has an answer for me: it writes *two* paths in the 
.pth file, one to the build dir (so that .dist-info is found) and one to the 
modules root (for modules, built in place).  Anyone sees a problem with that?  
(For example huge sys.path.)

In this scheme, when Python modules are edited, changes are visible instantly, 
when C modules are edited, a call to build_ext is required, and when the 
metadata is edited, build_distinfo is required.  Does that sound good?

--

___
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

[Éric Araujo]

Éric Araujo  added the comment:

I’ve reviewed the last patch.  It looks like the code only installs to the 
global site-packages, and there is no support to install to the user 
site-packages or to another arbitrary location.

On Windows, normal users seem to be able to write to the global site-packages 
(see #12260), but on other OSes with a proper rights model  that won’t 
do.  Luckily, PEP 370 brings us user site-packages (currently poorly 
documented, see #8617 and #10745), but only for 2.6, 2.7 and 3.x.  It looks 
like Tarek is ready to drop 2.4 compatibility for distutils2, so the question 
is: what to do under 2.5?

Generally, I don’t see why develop could not install to any directory.  We want 
a default invocation without options to Just Work™, finding a writable 
directory already on sys.path and writing into it, but that doesn’t exclude 
letting the user do what they want.

--

___
Python tracker 

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

[issue12449] Add accelerator "F" to button "Finish" in all MSI installers made by bdist_msi

[Thomas Holmes]

Thomas Holmes  added the comment:

> > It also creates an exe installer, not an MSI.
> Why would you think it creates an MSI?  bdist_wininst is not bdist_msi.

My concern for MSI is that this issue is referencing a change to MSI 
generation. I never had any expectation for wininst to generate an MSI.

If I remember correctly from trying the other day --formats=msi fails because 
bdist_msi is set as a valid format.

I have begun work on fixing these problems, as I've encountered them, and will 
be writing up issues for them soon.

--

___
Python tracker 

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

[issue12449] Add accelerator "F" to button "Finish" in all MSI installers made by bdist_msi

[Thomas Holmes]

Thomas Holmes  added the comment:

I mean that msi is _not_ set as a valid format. I will verify this evening.

--

___
Python tracker 

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

[issue11553] Docs for: import, packages, site.py, .pth files

[Éric Araujo]

Éric Araujo  added the comment:

>>> Exactly what variants of arguments are possible, and what are their
>>> effects?
>> Does http://docs.python.org/dev/library/functions#__import__ help?
>> Does http://docs.python.org/dev/library/importlib ?
> Well somewhat overkill -- because the matter of interest was args for
> from... and import, while the docs you mention are for more
> complicated underlying functions. (Interesting nonetheless.)

importlib.import_module should not be overkill, as it was designed specifically 
to be more easy and correct to use than __import__.

>>> -- the __all__ variable: Does it act generally to limit visibility
>>> of a module or package's attributes, or does pertain only to the
>>> 'from...import *' statement?
>> Both. 
> I'm pretty sure that's not correct -- pretty sure that __all__ only
> specifies what's included in from...import *, and does not prevent
> access via from...import specific_attrib.  But I may have tested
> incorrectly.

Sorry, I should have clarified.  I meant that __all__ limits what “from x 
import *” can see (for somemodule.__all__), and what pydoc and other tools 
display (for someobject.__all__).  Direct reference “x._lalala” or explicit 
import “from x import explicit_name” don’t look at __all__.
 
>>> In addsitepackages(), the library directory for Windows (the else
>>> clause) is shown as lower-case 'lib' instead of 'Lib'.

Please report that as a new bug.

>>> sys
>>> Could helpfully point to a discussion of the typical items to
>>> be found in sys.path under normal circumstances
>> Hm, this would be very platform-specific.  What use cases would that
>> help?
> It would demystify how python already knows how to find various
> things under vanilla circumstances.

I’m all for demystification, so OK.  We already have platform-specific examples 
in site and/or sysconfig docs, so once more wouldn’t harm.

>>> 'Installing Python Modules' document
>>> "Windows has no concept of a user’s home directory, " and so on.
>> The author probably meant that there was no $HOME environment
>> variable, ~ shortcut and all that.
> Fair enough, but in actuality there *is* a user-specific location (on
> Windows) examined by site.py, which is in %APPDATA%\Python\.

That does not map to the home concept at all.  Anyway, it does not really add 
value to say that one OS doesn’t have something that another OS has, let’s just 
say that X uses something and that Y uses soemthing else.

>> Don’t confuse the prefix and the install dir.  The directory for
>> Python modules is computed as prefix + Lib/site-packages.
> Currently, under "Alternate installation: Windows (the prefix
> scheme)", it says:
>python setup.py install --prefix="\Temp\Python" [...]
> Does this really mean "install modules to \Temp\Python\Lib\site-packages"?

I don’t know, try it in a shell!

> (And as a side point, surely installing under the Temp directory is a
> strange location to pick for an example?)

Well, the docs gotta pick something.  A tempdir is not worse than something 
else to demonstrate how to use a tool.

We need to have one discussion thread for each issue, to make this huge doc bug 
manageable.  I will go over your first message again and open one report for 
each point, this week if I have time.

--

___
Python tracker 

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

[issue12417] Inappropriate copyright on profile files

[Paul Hildebrandt]

Paul Hildebrandt  added the comment:

Good catch, thanks Eric!  You are a wonderful human being.

--

___
Python tracker 

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

[issue12149] Segfault in _PyObject_GenericGetAttrWithDict

[Davide Rizzo]

Davide Rizzo  added the comment:

The attached test segfaults (and passes with the patch). It wasn't clear to me 
where to put the test (it is a typeobject issue triggered by io) but Antoine on 
IRC agreed it would make sense to add it to test_io anyway.

Python 2.7 is affected too by the bug, but it doesn't trigger with 
_PyIOBase_finalize because it first checks for "closed" but the lookup fails 
(not sure why) so it doesn't try to call "close". On Python 3.3 the lookup for 
"closed" returned a valid descriptor from the method cache even after the type 
is cleared.

--
versions: +Python 2.7
Added file: http://bugs.python.org/file22635/test_io.diff

___
Python tracker 

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

[issue12279] Add build_distinfo command to packaging

[Carl Meyer]

Carl Meyer  added the comment:

>> I don't really think the "invalid PEP 376" issue is a problem: PEP
>> 376 describes the metadata for installed distributions; it has
>> nothing to say about built metadata for a distribution which has not
>> yet been installed.
> The problem is that develop is a kind of install.

Right, I was simply referring to "build_distinfo" leaving it
empty/missing; I'd want "develop" to add a (very short) RECORD file as
specified below.

>> For purposes of the develop command, if a pth file is used to
>> implement develop, then ideally when develop is run a RECORD file
>> would be added containing only the path to that pth file, as thats
>> the only file that has actually been installed
> Yeah!
> 
>> (and the only one that should be removed if the develop-installed
>> package is uninstalled).
> Are you saying that such a RECORD file would allow any installer compatible 
> with PEP 376 to undo a develop install?  Clever!

Yeah, that's the idea. I don't see any actual use case for having all of
the Python modules etc included in the RECORD file for a
develop-install, because they haven't been installed anywhere: what we
really want to know is "what has been placed in the installation
location that we need to keep track of."?

--

___
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

[Carl Meyer]

Carl Meyer  added the comment:

> Ah, higery’s code already has an answer for me: it writes *two* paths in the 
> .pth file, one to the build dir (so that .dist-info is found) and one to the 
> modules root (for modules, built in place).  Anyone sees a problem with that? 
>  (For example huge sys.path.)
> 
> In this scheme, when Python modules are edited, changes are visible 
> instantly, when C modules are edited, a call to build_ext is required, and 
> when the metadata is edited, build_distinfo is required.  Does that sound 
> good?

That sounds reasonable to me. I'm not worried about that making sys.path
too long: whatever we do we aren't going to challenge buildout in that
department ;-)

--

___
Python tracker 

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

[issue12543] `issubclass(collections.deque, collections.Sequence) == False`

[Ram Rachum]

New submission from Ram Rachum :

Is there a good reason that `issubclass(collections.deque, 
collections.Sequence) == False`? What's not-sequence-y about `deque`?

--
messages: 140206
nosy: cool-RR
priority: normal
severity: normal
status: open
title: `issubclass(collections.deque, collections.Sequence) == False`

___
Python tracker 

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

[issue9254] __import__ docstring should recommend importlib.import_module()

[Brett Cannon]

Brett Cannon  added the comment:

Patch looks good to me.

--
stage: needs patch -> commit review

___
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

[Carl Meyer]

Carl Meyer  added the comment:

> I’ve reviewed the last patch.  It looks like the code only installs
> to the global site-packages, and there is no support to install to
> the user site-packages or to another arbitrary location.
> 
> On Windows, normal users seem to be able to write to the global
> site-packages (see #12260), but on other OSes with a proper rights
> model  that won’t do.  Luckily, PEP 370 brings us user
> site-packages (currently poorly documented, see #8617 and #10745),
> but only for 2.6, 2.7 and 3.x.  It looks like Tarek is ready to drop
> 2.4 compatibility for distutils2, so the question is: what to do
> under 2.5?
> 
> Generally, I don’t see why develop could not install to any
> directory.  We want a default invocation without options to Just
> Work™, finding a writable directory already on sys.path and writing
> into it, but that doesn’t exclude letting the user do what they
> want.

I don't see why the installation-location-finding for develop should be
any different than for a normal "pysetup install". Does "pysetup
install" install to global site-packages by default, or try to find
somewhere it can install without additional privileges? Whatever it does
by default, develop should do the same. If "develop" can install to
arbitrary locations, then "install" should be able to as well (though I
don't really see the value in "arbitrary locations", since you then have
to set up PYTHONPATH manually anyway). There is no reason for them to
have different features in this area, it just adds confusion.

Certainly "develop" should support PEP 370, ideally with the same
command-line flag as a regular install.

--

___
Python tracker 

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

[issue12149] Segfault in _PyObject_GenericGetAttrWithDict

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Thank you very much!

--
stage: needs patch -> patch review
versions:  -Python 3.1

___
Python tracker 

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

[issue3565] array documentation, method names not 3.x-compliant

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Is there still any idea/intention of renaming .from/.tounicode to
> .from/.tostring? That would have to be done at least one version with
> the 'string' names absent, and would have little gain as 'unicode' is
> clear.

Indeed, not only it would bring little benefit, but may also confuse users 
porting from 2.x (since the from/tostring methods would then have a totally 
different meaning).

--
resolution:  -> duplicate
stage: patch review -> committed/rejected
status: open -> closed
superseder:  -> array constructor and array.fromstring should accept bytearray.

___
Python tracker 

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

[issue12149] Segfault in _PyObject_GenericGetAttrWithDict

[Roundup Robot]

Roundup Robot  added the comment:

New changeset cd40ea4087b0 by Antoine Pitrou in branch '3.2':
Issue #12149: Update the method cache after a type's dictionnary gets
http://hg.python.org/cpython/rev/cd40ea4087b0

New changeset 5992cbbedf59 by Antoine Pitrou in branch 'default':
Issue #12149: Update the method cache after a type's dictionnary gets
http://hg.python.org/cpython/rev/5992cbbedf59

--
nosy: +python-dev

___
Python tracker 

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

[issue12149] Segfault in _PyObject_GenericGetAttrWithDict

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 9618303852da by Antoine Pitrou in branch '2.7':
Issue #12149: Update the method cache after a type's dictionnary gets
http://hg.python.org/cpython/rev/9618303852da

--

___
Python tracker 

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

[issue12149] Segfault in _PyObject_GenericGetAttrWithDict

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Should be fixed now. Thanks again Davide for the patch.

--
resolution:  -> fixed
stage: patch review -> 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

[issue12543] `issubclass(collections.deque, collections.Sequence) == False`

[R. David Murray]

R. David Murray  added the comment:

Maybe they don't support all Sequence operations?  They don't support slicing, 
certainly, but I can't tell from the collections ABC docs if Sequence is 
required to support slicing.

--
nosy: +r.david.murray, rhettinger

___
Python tracker 

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

[issue6721] Locks in python standard library should be sanitized on fork

[Nir Aides]

Nir Aides  added the comment:

Well, my brain did not deadlock, but after spinning on the problem for a while 
longer, it now thinks Tomaž Šolc and Steffen are right.

We should try to fix the multiprocessing module so it does not deadlock 
single-thread programs and deprecate fork in multi-threaded programs.

Here is the longer version, which is a summary of what people said here in 
various forms, observations from diving into the code and Googling around:


1) The rabbit hole

a) In a multi-threaded program, fork() may be called while another thread is in 
a critical section. That thread will not exist in the child and the critical 
section will remain locked. Any attempt to enter that critical section will 
deadlock the child.

b) POSIX included the pthread_atfork() API in an attempt to deal with the 
problem:
http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_atfork.html

c) But it turns out atfork handlers are limited to calling async-signal-safe 
functions since fork may be called from a signal handler:
http://download.oracle.com/docs/cd/E19963-01/html/821-1601/gen-61908.html#gen-95948

This means atfork handlers may not actually acquire or release locks. See 
opinion by David Butenhof who was involved in the standardization effort of 
POSIX threads:
http://groups.google.com/group/comp.programming.threads/msg/3a43122820983fde

d) One consequence is that we can not assume third party libraries are safe to 
fork in multi-threaded program. It is likely their developers consider this 
scenario broken.

e) It seems the general consensus across the WWW concerning this problem is 
that it has no solution and that a fork should be followed by exec as soon as 
possible.

Some references:
http://pubs.opengroup.org/onlinepubs/009695399/functions/fork.html
http://austingroupbugs.net/view.php?id=62
http://sourceware.org/bugzilla/show_bug.cgi?id=4737
http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them


2) Python’s killer rabbit

The standard library multiprocessing module does two things that force us into 
the rabbit hole; it creates worker threads and forks without exec.

Therefore, any program that uses the multiprocessing module is a 
multi-threading forking program.

One immediate problem is that a multiprocessing.Pool may fork from its worker 
thread in Pool._handle_workers(). This puts the forked child at risk of 
deadlock with any code that was run by the parent’s main thread (the entire 
program logic).

More problems may be found with a code review.

Other modules to look at are concurrent.futures.process (creates a worker 
thread and uses multiprocessing) and socketserver (ForkingMixIn forks without 
exec).


3) God bless the GIL

a) Python signal handlers run synchronously in the interpreter loop of the main 
thread, so os.fork() will never be called from a POSIX signal handler.

This means Python atfork prepare and parent handlers may run any code. The code 
run at the child is still restricted though and may deadlock into any acquired 
locks left behind by dead threads in the standard library or lower level third 
party libraries.

b) Turns out the GIL also helps by synchronizing threads.

Any lock held for the duration of a function call while the GIL is held will be 
released by the time os.fork() is called. But if a thread in the program calls 
a function that yields the GIL we are in la la land again and need to watch out 
step.


4) Landing gently at the bottom

a) I think we should try to review and sanitize the worker threads of the 
multiprocessing module and other implicit worker threads in the standard 
library.

Once we do (and since os.fork() is never run from a POSIX signal handler) the 
multiprocessing library should be safe to use in programs that do not start 
other threads.

b) Then we should declare the user scenario of mixing the threading and 
multiprocessing modules as broken by design.

c) Finally, optionally provide atfork API

The atfork API can be used to refactor existing fork handlers in the standard 
library, provide handlers for modules such as the logging module that will 
reduce the risk of deadlock in existing programs, and can be used by developers 
who insist on mixing threading and forking in their programs.


5) Sanitizing worker threads in the multiprocessing module

TODO :) 

(will try to post some ideas soon)

--

___
Python tracker 

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

[issue12543] `issubclass(collections.deque, collections.Sequence) == False`

[Raymond Hettinger]

Raymond Hettinger  added the comment:

index() isn't supported.

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

[issue12544] Avoid using a pseudo-dict for _type_equality_funcs in unittest

[Martin]

New submission from Martin :

The fix for issue 10326 landing on Python 2.7 trunk has interfered with a hack 
I wrote in Bazaar to break the reference cycles the private 
`unittest.TestCase._type_equality_funcs` member creates.

As the change to make pickling work is nearly enough to avoid the test and the 
dict referencing each other, it would be good to remove that breakage and the 
need for the hack in the first place.

Downstream bug:



--
components: Library (Lib)
messages: 140217
nosy: MarkRoddy, gz, michael.foord
priority: normal
severity: normal
status: open
title: Avoid using a pseudo-dict for _type_equality_funcs in unittest
type: behavior
versions: Python 2.7, 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

[issue12544] Avoid using a pseudo-dict for _type_equality_funcs in unittest

[Michael Foord]

Michael Foord  added the comment:

It isn't clear to me exactly what fix you are suggesting for Python 2.7?

--
assignee:  -> michael.foord

___
Python tracker 

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

[issue12544] Avoid using a pseudo-dict for _type_equality_funcs in unittest

[Martin]

Changes by Martin :


--
keywords: +patch
Added file: http://bugs.python.org/file22636/avoid_TestCase_refcycle.diff

___
Python tracker 

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

[issue12544] Avoid using a pseudo-dict for _type_equality_funcs in unittest

[Martin]

Martin  added the comment:

Michael: See attached patch, that should merge up to Python 3 without too much 
pain as well.

--

___
Python tracker 

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

[issue12544] Avoid using a pseudo-dict for _type_equality_funcs in unittest

[Martin]

Changes by Martin :


Removed file: http://bugs.python.org/file22636/avoid_TestCase_refcycle.diff

___
Python tracker 

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

[issue12544] Avoid using a pseudo-dict for _type_equality_funcs in unittest

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 02a591131360 by Benjamin Peterson in branch '2.7':
this can be done without a custom dict (also fixes #12544)
http://hg.python.org/cpython/rev/02a591131360

New changeset 842f5ed06255 by Benjamin Peterson in branch '3.2':
this can be done without a custom dict (also fixes #12544)
http://hg.python.org/cpython/rev/842f5ed06255

New changeset 47a36d2d2b44 by Benjamin Peterson in branch 'default':
merge 3.2 (#12544)
http://hg.python.org/cpython/rev/47a36d2d2b44

--
nosy: +python-dev

___
Python tracker 

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

[issue12544] Avoid using a pseudo-dict for _type_equality_funcs in unittest

[Benjamin Peterson]

Changes by Benjamin Peterson :


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

[issue12544] Avoid using a pseudo-dict for _type_equality_funcs in unittest

[Martin]

Martin  added the comment:

...typo in the first patch, this one should be okay. But... already landed 
without the testcase?

--
Added file: http://bugs.python.org/file22637/avoid_TestCase_refcycle.diff

___
Python tracker 

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

[issue12545] Incorrect handling of return codes in the posix_lseek function in posixmodule.c

[Kuberan Naganathan]

New submission from Kuberan Naganathan :

The lseek function can legitimately return a code less then zero ( except for 
-1 ) when seeking beyond an offset of 2^63.  This behavior should be supported 
in order to permit the python interpreter to seek in files with valid data at 
locations greater than or equal to 2^63.  This can happen in a sparse file or 
in the /proc file system address space file.  

The fix is simple.  In the posix_lseek function check for result != -1 instead 
of checking for result < 0 in return code checks of the value returned by lseek.

--
components: IO
messages: 140222
nosy: Kuberan.Naganathan
priority: normal
severity: normal
status: open
title: Incorrect handling of return codes in the posix_lseek function in 
posixmodule.c
versions: Python 2.7

___
Python tracker 

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

[issue12545] Incorrect handling of return codes in the posix_lseek function in posixmodule.c

[Kuberan Naganathan]

Kuberan Naganathan  added the comment:

In addition I would like the posix_lseek function to accept a value larger than 
2^63 as a seek offset.  Currently I seem to need to seek multiple times within 
a file to achieve an offset larger than 2^63 ( assuming the return type check 
on the return value of lseek is fixed. )

--

___
Python tracker 

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

[issue3565] array documentation, method names not 3.x-compliant

[Matt Giuca]

Matt Giuca  added the comment:

There are still some inconsistencies in the documentation (in particular, 
incorrectly using the word "string" to refer to a bytes object, which made 
sense in Python 2 but not 3), which I fixed in my doc-only.patch file that's 
coming up to its third birthday.

Most of it has been fixed with the previous change which added 'tobytes' and 
'frombytes' and made tostring and fromstring aliases. But there are some places 
which don't make sense:

array: "If given a list or string" needs to be "If given a list, bytes or 
string" (since a bytes is not a string).
frombytes: "Appends items from the string" needs to be "Appends items from the 
bytes object", since this does not work if you give it a string.

Less importantly, I also recommended renaming "unicode string" to just 
"string", since in Python 3 there is no such thing as a non-unicode string. For 
instance, there is an example that uses a variable named "unicodestring" that 
could be renamed to just "string".

> Indeed, not only it would bring little benefit, but may also confuse
> users porting from 2.x (since the from/tostring methods would then
> have a totally different meaning).
Well, by that logic, you shouldn't have renamed "unicode" to "str" since that 
would also confuse users porting from 2.x. It generally seems like a good idea 
in Python 3 to rename all mentions of "string" to "bytes" and all mentions of 
"unicode" to "string", so as to be consistent with the new names of the types 
(it is better to be internally consistent than consistent with the previous 
version).

Though I do agree that it would be chaos to rename array.from/tounicode to 
from/tostring now, given that array.from/tostring already has a different 
meaning in Python 3.

--

___
Python tracker 

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

[issue12546] str.format cannot fill with \x00 char

[Gavin Andresen]

New submission from Gavin Andresen :

This gives me "foo   " instead of expected "foo\x00\x00\x00" :

"{0:\x00<6}".format('foo')

--
components: Library (Lib)
messages: 140225
nosy: Gavin.Andresen
priority: normal
severity: normal
status: open
title: str.format cannot fill with \x00 char
type: behavior
versions: Python 2.7

___
Python tracker 

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