[issue17875] Set Intersection returns unexpected results

[Mark Dickinson]

Mark Dickinson added the comment:

It appears that your list1 and list2 are not regular Python lists, but have 
type cobra.core.DictList (which inherits from list, but overrides the 'index' 
method).  cobra is a 3rd party package, not maintained by the Python 
developers, so I'm afraid this isn't the right place to ask about it;  is there 
a mailing list for the cobra package?

--
nosy: +mark.dickinson
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

[issue12458] Tracebacks should contain the first line of continuation lines

[Ezio Melotti]

Ezio Melotti added the comment:

I think all the lines involved in a multi-line expression should be reported.

Take for example this simple code:
  x = [int(c, 16)
   for c in '0123456789ABCDEFG'
   if c.isdigit() or c.isupper()]

With Python 2 the traceback is:
Traceback (most recent call last):
  File "deleteme.py", line 3, in 
if c.isdigit() or c.isupper()]
ValueError: invalid literal for int() with base 16: 'G'

Which is not very helpful, because you don't see the int() call that is causing 
the error in the first place and you don't see where the G comes from.


Incidentally, for this specific case, the traceback is a bit better on Python3:
Traceback (most recent call last):
  File "deleteme.py", line 2, in 
for c in '0123456789ABGDEF'
  File "deleteme.py", line 3, in 
if c.isdigit() or c.isupper()]
ValueError: invalid literal for int() with base 16: 'G'

But this still misses the int() call.

IMHO it would be better to have something like:
  Traceback (most recent call last):
  File "deleteme.py", lines 1-3, in 
x = [int(c, 16)
 for c in '0123456789ABCDEFG'
 if c.isdigit() or c.isupper()]
ValueError: invalid literal for int() with base 16: 'G'


If this is rejected for some reason, I think printing the first line -- rather 
than the last -- would still be an improvement, because in most of the cases 
the first line contains more information (e.g. the name of the function with a 
multi-line list of args, a raise/assert with the name of the exception and part 
of the message, the operation done for each element of a genexp/listcomp).

--

___
Python tracker 

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

[issue17272] request.full_url: unexpected results on assignment

[Demian Brecht]

Demian Brecht added the comment:

Issue 8280 reports the error by way of urlopen(). In light of that, would it 
not make more sense to have the *Opener be responsible for determining which 
parts of the url should be used?

i.e. request.py, line ~1255:

r.url = req.get_full_url()

might instead be

r.url = req.full_url.split('#')[0]

To me, it would make more sense to have the client code (in this case, meaning 
the consumer of the Request object, which is the *Opener) be smart enough to 
know what parts of the url should be used in the HTTP request than to have the 
Request object have inconsistencies in the set and subsequent get values for 
full_url.

I wouldn't have an issue at all with adding a new patch that (on top of 
implementing full_url):

1. Adds identical tests to get_full_url for full_url
2. Changes the client code in *Opener (and anywhere else known to exhibit the 
same behaviour) to strip the URL fragment for the HTTP request

I don't believe that this change would be any more of a backwards compatibility 
risk than what's currently in the patch as the logic in terms of urlopen is 
kept. The risk of dependencies on fragment-less full_urls however, would remain.

--

___
Python tracker 

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

[issue17192] libffi-3.0.13 import

[Gregory P. Smith]

Gregory P. Smith added the comment:

I've got this and all of the fixes necessary for 3.3, default and 2.7 in my 
local repositories.

odd thing in the 3.2 patch: it is entirely unclear to me if the issue 10309 fix 
needs to be kept.  i included it as it was missing from 3.2 after previous 
commits (3.3 and 3.4 still kept it).  2.7 needs it as well.  the other part of 
the patch is the issue 11729 fix that already exists upstream being reapplied; 
it was inadvertently undone during the upgrade.

I _could_ push fixes for all branches at once right now unless pushes to 3.2 
are blocked and prevent me from pushing anything.

(rant: at which point i declare "hg hell" and feel like giving up because it 
simply has gotten in the way throughout this entire process rather than 
helping... i'll be forced to manually create diffs and reapply them to _other_ 
hg checkouts?  not so useful.  surely someone will stupidly claim i'm holding 
hg wrong instead of the tool being unhelpful).

We need to GET RID of libffi being bundled as part of the source release in 
3.4.  this is disgusting.

--
keywords: +patch
Added file: http://bugs.python.org/file30076/issue17192-refix-3.2-gps01.diff

___
Python tracker 

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

[issue17876] Doc issue with threading.Event

[Ezio Melotti]

Changes by Ezio Melotti :


--
keywords: +easy
nosy: +ezio.melotti
stage:  -> needs patch

___
Python tracker 

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

[issue17192] libffi-3.0.13 import

[Georg Brandl]

Georg Brandl added the comment:

OK, 3.2 block disabled, push away.

--

___
Python tracker 

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

[issue17714] str.encode('base64') add trailing new line character. It is not documented.

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti
stage: needs patch -> patch review
type:  -> enhancement

___
Python tracker 

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

[issue17852] Built-in module _io can loose data from buffered files at exit

[STINNER Victor]

STINNER Victor added the comment:

> It's guaranteed for exit(), not _Exit()/_exit().

Oops ok, thanks.

2013/4/30 Charles-François Natali :
>
> Charles-François Natali added the comment:
>
>> Hum, POSIX (2004) is not so strict:
>> "Whether open streams are flushed or closed, or temporary files are
>> removed is implementation-defined."
>> http://pubs.opengroup.org/onlinepubs/009695399/functions/exit.html
>
> You're looking at the wrong section:
>
> "The exit() function shall then flush all open streams with unwritten
> buffered data, close all open streams"
>
> Then a couple lines below:
>
> "The _Exit() [CX]   and _exit()  functions shall not call functions
> registered with atexit() nor any registered signal handlers. Whether
> open streams are flushed or closed, or temporary files are removed is
> implementation-defined."
>
> It's guaranteed for exit(), not _Exit()/_exit().
>
> --
>
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

[issue17192] libffi-3.0.13 import

[koobs]

koobs added the comment:

Ready to confirm on buildbots when this lands

Also, libffi-3.0.13 is installed on my buildbots if you want to use -custom to 
have a play, I can be pinged anytime on IRC if I can be of any assistance. 
koobs @ #python-dev

--

___
Python tracker 

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

[issue17192] libffi-3.0.13 import

[Roundup Robot]

Roundup Robot added the comment:

New changeset 7a2e0c1bb1a9 by Gregory P. Smith in branch '3.2':
* Fix issue 17192 for 3.2 - reapply the issue11729 patch that was undone
http://hg.python.org/cpython/rev/7a2e0c1bb1a9

New changeset aa3371fa9773 by Gregory P. Smith in branch '3.3':
* Fix PART of issue 17192 for 3.3 - reapply the issue11729 patch
http://hg.python.org/cpython/rev/aa3371fa9773

New changeset e0fdc21c7d13 by Gregory P. Smith in branch 'default':
* Fix PART of issue 17192 for 3.4 - reapply the issue11729 patch
http://hg.python.org/cpython/rev/e0fdc21c7d13

New changeset c665abe15c4a by Gregory P. Smith in branch '3.3':
* Fix remaining bits of issue 17192 for 3.3 - these changes
http://hg.python.org/cpython/rev/c665abe15c4a

New changeset 688bc0b44d96 by Gregory P. Smith in branch 'default':
* Fix remaining bits of issue 17192 for 3.4 - these changes
http://hg.python.org/cpython/rev/688bc0b44d96

New changeset 663800e18fef by Gregory P. Smith in branch '3.2':
This local change was lost during the fixing of issue17192 to update
http://hg.python.org/cpython/rev/663800e18fef

New changeset 7438d202e380 by Gregory P. Smith in branch '2.7':
This local change was lost during the fixing of issue17192 to update
http://hg.python.org/cpython/rev/7438d202e380

--

___
Python tracker 

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

[issue11729] libffi assembler relocation check is not robust, fails with clang

[Roundup Robot]

Roundup Robot added the comment:

New changeset 7a2e0c1bb1a9 by Gregory P. Smith in branch '3.2':
* Fix issue 17192 for 3.2 - reapply the issue11729 patch that was undone
http://hg.python.org/cpython/rev/7a2e0c1bb1a9

New changeset aa3371fa9773 by Gregory P. Smith in branch '3.3':
* Fix PART of issue 17192 for 3.3 - reapply the issue11729 patch
http://hg.python.org/cpython/rev/aa3371fa9773

New changeset e0fdc21c7d13 by Gregory P. Smith in branch 'default':
* Fix PART of issue 17192 for 3.4 - reapply the issue11729 patch
http://hg.python.org/cpython/rev/e0fdc21c7d13

--

___
Python tracker 

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

[issue10309] dlmalloc.c needs _GNU_SOURCE for mremap()

[Roundup Robot]

Roundup Robot added the comment:

New changeset 663800e18fef by Gregory P. Smith in branch '3.2':
This local change was lost during the fixing of issue17192 to update
http://hg.python.org/cpython/rev/663800e18fef

New changeset 7438d202e380 by Gregory P. Smith in branch '2.7':
This local change was lost during the fixing of issue17192 to update
http://hg.python.org/cpython/rev/7438d202e380

--

___
Python tracker 

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

[issue17870] Python does not provide PyLong_FromIntMax_t() or PyLong_FromUintMax_t() function

[STINNER Victor]

STINNER Victor added the comment:

>> It is the same question than yours: is there a platform with an integer type 
>> wider than a pointer (intptr_t/void*)?

> It's x86. sizeof(void*) == 4, sizeof(long long) == 8.

Ah  yes. So "SIZEOF_VOID_P <=" is not a good test. File position
(off_t) size can be 64 bit on a 32-bit system (like Linux/i386 and
Win32), whereas pointers size is 32 bit.

I don't think that we can rely on the availability of PY_LONG_LONG, it
may depend on the compiler or even on the compiler options.

IMO, if we decide to add functions for intmax_t and uintmax_t types,
the safest option is to only define functions if the real C type
(intmax_t and uintmax_t types) is available. I mean, we should not
guess intmax_t ourself, or we may choose the wrong type (too small
type).

--

___
Python tracker 

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

[issue17843] Lib/test/testbz2_bigmem.bz2 trigger virus warnings

[Nadeem Vawda]

Nadeem Vawda added the comment:

Benjamin, please cherry-pick this for 2.7.4 as well (changesets b7bfedc8ee18 
and 529c4defbfd7).

--
stage: needs patch -> commit review
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

[issue17192] libffi-3.0.13 import

[Gregory P. Smith]

Changes by Gregory P. Smith :


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

[issue17868] pprint long non-printable bytes as hexdump

[anatoly techtonik]

anatoly techtonik added the comment:

Some issues:

1. the hex converting logic doesn't belong to base64 module - there is no 
chance a person without StackOverflow access can find it
2. i'd put issue17862 first as a dependency for this one, because proposed 
itertools.chunks() can be further optimized (chunking endless sequences with 
constant memory overhead, pypy specific speedups, etc)

I like that this is not over-engineered. In my hexdump module I got too 
involved with problems of parsing/producing full dumps in a way compatible with 
Python 2/3. So I have to postpone my own user story until finally I run out of 
time.

Probably hexdump.dump() returning string will make it a useful API for the 
primary user story.
hexdump.dumpgen() as a line generator with 16 hexadecimal bytes delimited by 
space should cover all other use cases.

--

___
Python tracker 

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

[issue17877] Skip test_variable_tzname when the zoneinfo database is missing

[Ezio Melotti]

New submission from Ezio Melotti:

If the Olson/zoneinfo/tz database is missing, test_variable_tzname fails:

[1/1] test_email
Warning -- sys.path was modified by test_email
test test_email failed -- Traceback (most recent call last):
  File "/usr/local/lib/python3.3/test/support.py", line 1311, in inner
return func(*args, **kwds)
  File "/usr/local/lib/python3.3/test/test_email/test_utils.py", line 133, in 
test_variable_tzname
self.assertEqual(t1.tzname(), 'MSK')
AssertionError: 'Europe' != 'MSK'
- Europe
+ MSK

The attached patch checks if /usr/share/zoneinfo or /usr/lib/zoneinfo exist, 
and skip the test if they don't.  This test is already skipped on Windows.

--
components: Tests
files: olson.diff
keywords: patch
messages: 188145
nosy: belopolsky, ezio.melotti, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Skip test_variable_tzname when the zoneinfo database is missing
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file30077/olson.diff

___
Python tracker 

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

[issue12458] Tracebacks should contain the first line of continuation lines

[Dmi Baranov]

Changes by Dmi Baranov :


--
nosy: +dmi.baranov

___
Python tracker 

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

[issue17721] Help button on preference window doesn't work

[Guilherme Simões]

Guilherme Simões added the comment:

Hi, Terry!

I already signed the Contributor License Agreement Form.

Attached is a new patch with the buttons commented out and a small comment 
explaining why I did that. I hope the patch is better now.

--
Added file: http://bugs.python.org/file30078/Issue17721-1.patch

___
Python tracker 

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

[issue17878] There is no way to get a list of available codecs

[Paul Moore]

New submission from Paul Moore:

The codecs module allows the user to register additional codecs, but does not 
offer a means of getting a list of registered codecs.

This is important, for example, in a tool to re-encode files. It is reasonable 
to expect that such a tool would offer a list of supported encodings, to assist 
the user. For example, the -l option of the iconv command.

--
components: Unicode
messages: 188147
nosy: ezio.melotti, pmoore
priority: normal
severity: normal
status: open
title: There is no way to get a list of available codecs
type: behavior
versions: Python 3.3, Python 3.4

___
Python tracker 

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

[issue17878] There is no way to get a list of available codecs

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +lemburg, ncoghlan

___
Python tracker 

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

[issue17878] There is no way to get a list of available codecs

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

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

[issue17773] test_pydoc fails with the installed testsuite (2.7)

[koobs]

koobs added the comment:

I am seeing a similar set of test failures buildbots for 2.7 that are 
relatively recent too:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%2Bclang%202.7/builds/479/steps/test/logs/stdio

I cant account for test_html_doc failure but I have seen apropos tests fail in 
the past here due to third party modules doing funny things.

I upstreamed a fix in buildbot which addressed it as seen in this commit:

https://github.com/buildbot/buildbot/commit/126e02341c76bd5a027c2ca5a8467aa5708228f2#master/buildbot/test/__init__.py

I can test again without paramiko installed on the buildbot to see what the 
test failure delta is and report back

--
nosy: +koobs

___
Python tracker 

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

[issue17870] Python does not provide PyLong_FromIntMax_t() or PyLong_FromUintMax_t() function

[STINNER Victor]

STINNER Victor added the comment:

> Or maybe even better would be PyLong_FromBytes(&myinteger, sizeof(myinteger)) 
> ?

There is a private function:

obj = _PyLong_FromByteArray((const unsigned char*)&myinteger, 
sizeof(myinteger), PY_LITTLE_ENDIAN, is_signed);

Where PY_LITTLE_ENDIAN is 1 on little-endian platform, and is_signed should be 
0 or 1.

This function is inefficient (slow). It would be better to have a functions for 
intmax_t and uintmax_t types. Such functions would be enough to support other 
"recent" C types: intptr_t, uintptr_t, ptrdiff_t, etc. We may also add support 
for these types in PyArg_Parse* (ex: with "j" and "J" types, intmax_t and 
uintmax_t).

--

___
Python tracker 

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

[issue17874] ProcessPoolExecutor in interactive shell doesn't work in Windows

[Richard Oudkerk]

Richard Oudkerk added the comment:

Some sort of error is expected.

On Windows any functions or classes used in a task sent the executor must be 
picklable/unpicklable.  This means that they must be defined in an importable 
module rather than being defined in the interactive shell.

On Unix, you can use a definition made in the interactive shell, but *only* if 
it was defined before starting the executor.

--
nosy: +sbt
type: crash -> behavior

___
Python tracker 

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

[issue17879] corrupt download

[Steffen Flemming]

New submission from Steffen Flemming:

http://www.python.org/ftp/python/2.7.4/Python-2.7.4.tgz
http://www.python.org/ftp/python/2.7.4/Python-2.7.4.tar.bz2
at 30.04.2013 12:45
bzip2: Compressed file ends unexpectedly;

--
components: Build
messages: 188151
nosy: u14183
priority: normal
severity: normal
status: open
title: corrupt download
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

[issue17880] `tmpnam_r' is dangerous, better use `mkstemp'

[Steffen Flemming]

New submission from Steffen Flemming:

/tmp/Python-2.7.3/./Modules/posixmodule.c:7432: warning: the use of `tmpnam_r' 
is dangerous, better use `mkstemp'

--
components: Build
messages: 188152
nosy: u14183
priority: normal
severity: normal
status: open
title: `tmpnam_r' is dangerous, better use `mkstemp'
type: compile error
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

[issue17879] corrupt download

[Ezio Melotti]

Ezio Melotti added the comment:

Have you tried downloading it again?

--
nosy: +benjamin.peterson, ezio.melotti

___
Python tracker 

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

[issue17879] corrupt download

[Steffen Flemming]

Steffen Flemming added the comment:

yes on other host now its working. was confused by it was affecting two files.

--

___
Python tracker 

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

[issue17879] corrupt download

[Ezio Melotti]

Ezio Melotti added the comment:

OK, I'll close the issue 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

[issue17880] `tmpnam_r' is dangerous, better use `mkstemp'

[Christian Heimes]

Christian Heimes added the comment:

Please ignore the linker warning. tmpnam_r has been removed from Python 3.x. 
It's still available in 2.7 for legacy reasons and marked as dangerous in our 
docs http://docs.python.org/2.7/library/os.html#os.tempnam

--
nosy: +christian.heimes
resolution:  -> out of date
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

[issue17853] Conflict between lexical scoping and name injection in __prepare__

[Nick Coghlan]

Nick Coghlan added the comment:

Aside from the spurious definition of CLASS_FREE, looks good to me.

I did need to double check that PyDict_GetItem is the API that *doesn't* raise 
the error :)

--

___
Python tracker 

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

[issue17721] Help button on preference window doesn't work

[Roger Serwy]

Roger Serwy added the comment:

LGTM.

--
stage:  -> commit review

___
Python tracker 

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

[issue12458] Tracebacks should contain the first line of continuation lines

[Giampaolo Rodola']

Giampaolo Rodola' added the comment:

> But on python-ideas, G. Rodola noted the following
> assert \
> 1 == 0, \
> "error"
[...]
> and requested that the *second* or *middle* line should be reported.

No, I was suggesting (assuming it's reasonably possible in terms of 
implementation) to report the whole block (3 lines) as-is. 
Note that the same would apply for functions.
For example this:

self.assertEqual(1, 
 2)

Currently prints:

Traceback (most recent call last):
  File "foo.py", line 7, in test_foo
2)
AssertionError: 1 != 2

While instead it should:

Traceback (most recent call last):
  File "foo.py", line 6, in test_foo
self.assertEqual(1, 
 2)
AssertionError: 1 != 2

--

___
Python tracker 

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

[issue17881] plistlib.writePlist documentation clarification for file object

[Lance Helsten]

New submission from Lance Helsten:

plistlib.writePlist documentation states """Write 'rootObject' to a .plist 
file. 'pathOrFile' may either be a file name or a (writable) file object.""", 
but if a text IO object is given for the pathOrFile object (e.g. 
``io.TextIOBase`` or ``sys.stdout``) a ``TypeError`` with message "must be str, 
not bytes" is raised.

To clarify the documentation should be changed to be """...or a (writable, 
binary) file object.""".

--
messages: 188160
nosy: lanhel
priority: normal
severity: normal
status: open
title: plistlib.writePlist documentation clarification for file object
type: enhancement
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

[issue17881] plistlib.writePlist documentation clarification for file object

[Roundup Robot]

Roundup Robot added the comment:

New changeset 6e9d21761fc1 by Ezio Melotti in branch '3.3':
#17881: clarify documentation of plistlib.
http://hg.python.org/cpython/rev/6e9d21761fc1

New changeset 1ec6d3cc217d by Ezio Melotti in branch 'default':
#17881: merge with 3.3.
http://hg.python.org/cpython/rev/1ec6d3cc217d

--
nosy: +python-dev

___
Python tracker 

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

[issue17881] plistlib.writePlist documentation clarification for file object

[Ezio Melotti]

Ezio Melotti added the comment:

Fixed, thanks for the report!

--
assignee:  -> ezio.melotti
components: +Documentation
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.3, Python 3.4 -Python 3.2

___
Python tracker 

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

[issue17853] Conflict between lexical scoping and name injection in __prepare__

[Roundup Robot]

Roundup Robot added the comment:

New changeset cf65c7a75f55 by Benjamin Peterson in branch 'default':
check local class namespace before reaching for cells (closes #17853)
http://hg.python.org/cpython/rev/cf65c7a75f55

--
nosy: +python-dev
resolution:  -> fixed
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

[issue17843] Lib/test/testbz2_bigmem.bz2 trigger virus warnings

[Benjamin Peterson]

Benjamin Peterson added the comment:

I'm just going to branch off the current 2.7 branch at this point.

--

___
Python tracker 

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

[issue17843] Lib/test/testbz2_bigmem.bz2 trigger virus warnings

[Benjamin Peterson]

Benjamin Peterson added the comment:

Ah, sorry, I see what you mean. Will do.

--

___
Python tracker 

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

[issue17876] Doc issue with threading.Event

[R. David Murray]

R. David Murray added the comment:

I'm sorry, the 3.2 docs are no longer updated.  The effective way to become 
aware of these changes between versions is via the 'version changed' tags in 
the new documentation.  You will note that these tags exist in the 3.3 docs.

--
nosy: +r.david.murray
resolution:  -> out of date
stage: needs patch -> 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

[issue12458] Tracebacks should contain the first line of continuation lines

[R. David Murray]

R. David Murray added the comment:

I agree that printing all the lines would be best, and printing the first line 
would be second best.  I suspect once someone works out how to do the latter it 
is just as easy to do the former, though :)

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

[issue17870] Python does not provide PyLong_FromIntMax_t() or PyLong_FromUintMax_t() function

[STINNER Victor]

STINNER Victor added the comment:

Some Google searchs told me that no CPU support 128-bit integer and
using 64-bit integer as intmax_t is safe.

GCC has a __int128 type, but I didn't find on which platform it is
supported, nor if intmax_t is __int128 in this case.

Microsoft Visual Studio has stdint.h since its version 2010 (which is
the version required to compile Python 3.4 on Windows according to the
Python developer guide).

I propose a safer definition of Py_intmax_t:

#ifdef HAVE_UINTMAX_T
typedef uintmax_t Py_uintmax_t;
typedef intmax_t Py_intmax_t;

#elif SIZEOF_SIZE_T >= 8
typedef size_t Py_uintmax_t;
typedef Py_ssize_t Py_intmax_t;

#elif defined(HAVE_LONG_LONG) && SIZEOF_LONG_LONG >= 8
typedef unsigned PY_LONG_LONG Py_uintmax_t;
typedef PY_LONG_LONG Py_intmax_t;

#else
#   error "Python needs a typedef for Py_uintmax_t in pyport.h."
#endif

I don't think that a fallback on the long type is required, testing
size_t should be enough.

At least, the compilation fails if the Py_intmax_t type cannot be defined.

Having generic PyLong_FromUintMax_t() and PyLong_AsUintMax_t()
functions (and signed version) would simplify the support of other OS
types with variable size: time_t, clock_t, pid_t, gid_t, uid_t, off_t,
etc.

--

___
Python tracker 

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

[issue17882] test_objecttypes fails for 3.2.4 on CentOS 6

[bharper]

New submission from bharper:

Hello,

I have been running into some issues with test_objecttypes with 3.2.4 on CentOS 
6:

== 
FAIL: test_objecttypes (test.test_sys.SizeofTest)  
-- 
Traceback (most recent call last): 
  File "/builddir/build/BUILD/Python-3.2.4/Lib/test/test_sys.py", line 789, in 
test_objecttypes
check(int, s)  
  File "/builddir/build/BUILD/Python-3.2.4/Lib/test/support.py", line 1155, in 
check_sizeof
test.assertEqual(result, size, msg)
AssertionError: 856 != 816 : wrong size for : got 856, expected 
816
--

Looking over the bugs, I do not see anyone else having issues with this test.  
It does appear that this test got updated in issue 15467.  

Any insight would be greatly appreciate.

-Ben

--
components: Build
messages: 188169
nosy: bharper
priority: normal
severity: normal
status: open
title: test_objecttypes fails for 3.2.4 on CentOS 6
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

[issue15088] PyGen_NeedsFinalizing is public, but undocumented

[Nathan Housel]

Nathan Housel added the comment:

Please correct me if I'm wrong, but I think PyGen_NeedsFinalizing should not be 
an API function because it is only used, nor _PyGen_FetchStopIterationValue. In 
the attached patch I've removed PyGen_NeedsFinalizing and 
_PyGen_FetchStopIterationValue fom the public API.

--
keywords: +patch
nosy: +plasticgap
Added file: http://bugs.python.org/file30079/Issue15088.diff

___
Python tracker 

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

[issue12458] Tracebacks should contain the first line of continuation lines

[Terry J. Reedy]

Terry J. Reedy added the comment:

OK, you would make tracebacks even longer by adding lines that might or might 
not be be useful. Suppose the error is not the assertion itself, but in one of 
the expressions (in this case, being compared for equality):
self.assertEqual(1/0,
1000)
Or reverse the two expressions, or replace the method call with an assert 
statement and join the expressions with '=='. Would you still print both lines?

My experience on python-list is that people more often have a problem with a 
whole line being too much context, not too little. Someone writes 
'print(complicated_expression)' and gets a Unicode error. Is the problem the 
expression or the printing of the result to a limited charset console? Both 
cases have been posted. I sometimes advise people to break their elegant 
one-liners into two or more lines to make the actual error expression more 
obvious. If we were to revise the CPython compiler and traceback generator, 
that is what I think the aim should be. Such a change would include printing 
multiple lines when the expression spans multiple lines. This might have to be 
limited to debug builds.

--

___
Python tracker 

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

[issue15984] Wrong documentation for PyUnicode_FromObject()

[Brian Curtin]

Brian Curtin added the comment:

In the "Otherwise it coerces" sentence, obj should probably be ``obj``.

--
nosy: +brian.curtin

___
Python tracker 

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

[issue15984] Wrong documentation for PyUnicode_FromObject()

[Terry J. Reedy]

Changes by Terry J. Reedy :


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

[issue17822] Save on Close windows (IDLE)

[Guilherme Simões]

Guilherme Simões added the comment:

I didn't test Roger's patch because I have limited access to Windows, but I 
think it should solve this specific issue.

But the problem is actually more general. For example, the same odd behavior 
happens when you try to run a module without saving. On MacOS one modal dialog 
pops up, but in Windows you can open as many dialogs as you want.

--

___
Python tracker 

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

[issue17819] removes need for CONFIG_SITE external configuration

[Antonio Cavallo]

Changes by Antonio Cavallo :


--
nosy: +benjamin.peterson, doko

___
Python tracker 

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

[issue17857] sqlite modules doesn't build with 2.7.4 on Mac OS X 10.4

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +benjamin.peterson, larry
priority: normal -> release blocker
status: closed -> open
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

[issue12458] Tracebacks should contain the first line of continuation lines

[R. David Murray]

R. David Murray added the comment:

The point is to print one logical line.  Printing a fragment of the logical 
line is clearly not very helpful...I have found myself a number of times 
looking for the bug in the fragment printed, and (quickly, but still...) then 
remembering that the traceback just prints the last physical line and the 
problem might be earlier.

Providing a caret is probably impossible.  I don't think the bytecode contains 
enough information to even make a guess as to where a caret should go.  I'm not 
even sure we can get the logical line.

--

___
Python tracker 

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

[issue17857] sqlite modules doesn't build with 2.7.4 on Mac OS X 10.4

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I think this fix should be included in the next regression release.

--

___
Python tracker 

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

[issue15984] Wrong documentation for PyUnicode_FromObject()

[R. David Murray]

R. David Murray added the comment:

So (speaking from C API ignorance here), if you pass it a unicode subclass you 
get back an instance of the base unicode type?  Is that what coercion means 
here?

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

[issue17656] Python 2.7.4 breaks ZipFile extraction of zip files with unicode member paths

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee:  -> serhiy.storchaka

___
Python tracker 

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

[issue17585] IDLE - regression with exit() and quit()

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

This fix introduces other bug (see issue17838). I think this fix with 
issue17838 fix should be included in next regression releases.

--
nosy: +benjamin.peterson, georg.brandl, larry
priority: critical -> release blocker
status: closed -> open
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

[issue17838] Can't assign a different value for sys.stdin in IDLE

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Due to the coming of regression fix releases the fix for this issue urgently 
needed. It fixes a regression in issue17585 which fixes a regression in last 
bugfix releases.

--
nosy: +benjamin.peterson, georg.brandl, larry
priority: normal -> release blocker
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

[issue15984] Wrong documentation for PyUnicode_FromObject()

[Kyle Roberts]

Kyle Roberts added the comment:

Thanks for the quick responses.

Brian: Nice catch, I'll add the ``obj`` shortly.

R. David: You're correct, that's exactly what happens, and what coercion means 
here. The language is almost the same as PyUnicode_FromEncodedObject()'s 
documentation, but if it's unclear I don't mind changing both. The code's 
comment offers another way of describing the "type modification":

/* For a Unicode subtype that's not a Unicode object, return a true Unicode 
object with the same data. */

--

___
Python tracker 

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

[issue15984] Wrong documentation for PyUnicode_FromObject() and PyUnicode_FromEncodedObject()

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Perhaps we should correct a documentation for PyUnicode_FromEncodedObject() 
too. Coercing doesn't look as right term for decoding.

--
title: Wrong documentation for PyUnicode_FromObject() -> Wrong documentation 
for PyUnicode_FromObject() and PyUnicode_FromEncodedObject()

___
Python tracker 

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

[issue17864] IDLE won't run

[Ben Read]

Ben Read added the comment:

Good news - ran the sudo command, entered the password but I could still not 
make the directory, but I could within Finder - this time without a password. 
Tried the IDLE application again and it now works. 

Thank you once again for your help in resolving this. 

Regards,

Ben

Begin forwarded message:

> From: Ben Read 
> Subject: Re: [issue17864] IDLE won't run
> Date: 29 April 2013 22:12:03 BST
> To: Python tracker 
> 
> Thank you for getting me this far - it's funny that Python has been the 
> program to make this problem apparent, but looking closer, there are other 
> issues such as not being able to create a new folder in the user folder 
> without entering username and password.
> 
> I appreciate your help in diagnosing the problem.
> 
> Ben
> 
> 
> On 29 Apr 2013, at 10:37, Ned Deily  wrote:
> 
>> 
>> Ned Deily added the comment:
>> 
>> The "ls" shows that, for some reason, your home directory is owned by user 
>> "temp", not by user "ben". That's not good.  Try doing this:
>> 
>> sudo chown ben /Users/ben/
>> 
>> But we're way past an IDLE or Python problem here.  This is a basic Unix 
>> system administration issue.
>> 
>> --
>> 
>> ___
>> Python tracker 
>> 
>> ___
>

--
title: IDLE fails to launch when it cannot create .idlerc directory -> IDLE 
won't run

___
Python tracker 

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

[issue17857] sqlite modules doesn't build with 2.7.4 on Mac OS X 10.4

[Ned Deily]

Ned Deily added the comment:

Georg, do you want a 3.2 patch for this as well?

--

___
Python tracker 

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

[issue16518] add "buffer protocol" to glossary

[Roundup Robot]

Roundup Robot added the comment:

New changeset 474f28bf67b3 by Ezio Melotti in branch '3.3':
#16518: add "bytes-like object" to the glossary.
http://hg.python.org/cpython/rev/474f28bf67b3

New changeset 747cede24367 by Ezio Melotti in branch 'default':
#16518: merge with 3.3.
http://hg.python.org/cpython/rev/747cede24367

New changeset 1b92a0112f5d by Ezio Melotti in branch '2.7':
#16518: add "bytes-like object" to the glossary.
http://hg.python.org/cpython/rev/1b92a0112f5d

--
nosy: +python-dev

___
Python tracker 

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

[issue17883] Fix buildbot testing of Tkinter

[Zachary Ware]

New submission from Zachary Ware:

Ezio, you brought up the fact that the 2.7 Windows buildbots were skipping the 
Tkinter tests in Terry's core-mentorship thread about tkinter on Windows last 
month, and I've finally learned what is causing that failure.  It appears that 
when 689a813f4afc and df39b0bc4106 were committed, they were not backported to 
2.7.  Attached is a patch to backport those two changesets, which should make 
things (more) right.  

This only affects running tests via PCbuild/rt.bat (or Tools/buildbot/test.bat, 
which calls PCbuild/rt.bat), and doesn't do anything for finding the tcl/tk 
.dlls any other time.

--
components: Tests, Tkinter, Windows
files: 2.7_rt.bat_tcltk_fix.diff
keywords: patch
messages: 188184
nosy: ezio.melotti, terry.reedy, zach.ware
priority: normal
severity: normal
status: open
title: Fix buildbot testing of Tkinter
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file30080/2.7_rt.bat_tcltk_fix.diff

___
Python tracker 

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

[issue17825] Indentation.offset and SyntaxError.offset mismatch

[Florent Xicluna]

Florent Xicluna added the comment:

Patch updated with latest changes of trunk.

--
Added file: http://bugs.python.org/file30081/patch_indenterror_offset_v2.diff

___
Python tracker 

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

[issue17883] Fix buildbot testing of Tkinter

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +roger.serwy
stage:  -> patch review

___
Python tracker 

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

[issue17829] csv.Sniffer.snif doesn't set up the dialect properly for a csv created with dialect=csv.excel_tab and containing quote (") char

[Dmi Baranov]

Changes by Dmi Baranov :


--
nosy: +dmi.baranov

___
Python tracker 

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

[issue12458] Tracebacks should contain the first line of continuation lines

[Terry J. Reedy]

Terry J. Reedy added the comment:

>>> Printing a fragment of the logical line is clearly not very helpful

Given the unbounded and recursive nature of 'logical line', I disagree with 
that as a general, versus special-case, statement.

Consider:
r(a()/b(),
  d()/e(),
  g=h()/i(),
  )
If either e() or i() returns 0, printing all 4 lines is less helpful, by adding 
noise (which line has the error?), than just printing the 1 line with the 
ZeroDivisionError. The context is irrelevant.

Or consider:
mymegalist = {
  a,
  b,
... <500 lines, one item per line>
  xyz,
}
If 1 of the expressions raises an error, do you really want all 500 lines in 
the traceback? Again, the context is probably irrelevant.

Quite aside from this, 'd()/e(),' and 'g=h()/i(),' are both legal logical lines 
in themselves (though with different semantics) as well as being fragments of 
the r call.

Moreover, the multiline r call above may itself be just a fragment of a call to 
another function (further indented). The practical difficulty for the proposal, 
even if limited to multiline calls, is that any bare call could either be part 
of a larger expression by returning something or be a statement operating 
through side-effects. Similarly, any 'var=f()' call could either be an 
assignment statement or keyword arg expression in some other call.

--

___
Python tracker 

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

[issue12458] Tracebacks should contain the first line of continuation lines

[Ezio Melotti]

Ezio Melotti added the comment:

> Consider:
>r(a()/b(),
>  d()/e(),
>  g=h()/i(),
>  )

I tried to run this, with e() == 0, and got:
Traceback (most recent call last):
  File "deleteme.py", line 6, in 
d()/e(),
ZeroDivisionError: division by zero

This is actually a good point, because in this specific case the traceback is 
correct, and showing all the lines would make things worse.


> If 1 of the expressions raises an error, do you really want
> all 500 lines in the traceback?

I assume it wouldn't be too difficult to limit the output to 3-5 lines max.

Someone should try to fiddle with the code I indicated in msg144813, and see 
what can be done.  If there are enough informations it might be possible to 
keep reporting a single line for the aforementioned case, but report more lines 
for the cases listed in the other messages; if there aren't enough informations 
we will have to abandon the idea (or find a way to retrieve them).

--
nosy: +kushaldas

___
Python tracker 

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

[issue17630] Create a pure Python zipfile importer

[Dmi Baranov]

Changes by Dmi Baranov :


--
nosy: +dmi.baranov

___
Python tracker 

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

[issue12458] Tracebacks should contain the first line of continuation lines

[Terry J. Reedy]

Terry J. Reedy added the comment:

idlelib has two files that *might* be helpful to anyone who wants to pursue 
this: PyParse.py and HyperParser.py. One use of the latter is for calltips. 
When the user types '(', the HyperParser is used first to determine whether the 
'(' is preceded by an operator (making it a grouper) or not (making it a call 
operator). In the later case, it parses backwards to find the beginning of the 
callable expression, which is then evaluated to get the callable (if it does 
not contain an embedded call) and hence the signature. Parsing forward and back 
from a given line might be similar.

--

___
Python tracker 

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

[issue17870] Python does not provide PyLong_FromIntMax_t() or PyLong_FromUintMax_t() function

[STINNER Victor]

STINNER Victor added the comment:

Here is a first patch adding the following functions:

PyObject* PyLong_FromIntMax_t(intmax_t v);
PyObject* PyLong_FromUintMax_t(uintmax_t v);
intmax_t PyLong_AsIntMax_t(PyObject *pylong);
uintmax_t PyLong_AsUintMax_t(PyObject *pylong);

I used AC_TYPE_INTMAX_T and AC_TYPE_UINTMAX_T in configure.ac, so intmax_t and 
uintmax_t are defined if the platform does not provide them. (I guess that 
these types are defined in pyconfig.h.) On Windows, Visual Studio 2010 supports 
stdint.h, and so these types are available.

autoheader && autoconf must be called to regenerate configure script and 
pyconfig.h.in template.

--
keywords: +patch
Added file: http://bugs.python.org/file30082/intmax_t.patch

___
Python tracker 

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

[issue17712] test_gdb failures

[Roundup Robot]

Roundup Robot added the comment:

New changeset 4e58cafbebfc by Antoine Pitrou in branch '3.3':
Issue #17712: Fix test_gdb failures on Ubuntu 13.04.
http://hg.python.org/cpython/rev/4e58cafbebfc

New changeset 4e186581fea7 by Antoine Pitrou in branch 'default':
Issue #17712: Fix test_gdb failures on Ubuntu 13.04.
http://hg.python.org/cpython/rev/4e186581fea7

--
nosy: +python-dev

___
Python tracker 

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

[issue17712] test_gdb failures

[Roundup Robot]

Roundup Robot added the comment:

New changeset c241831a91f2 by Antoine Pitrou in branch '2.7':
Issue #17712: Fix test_gdb failures on Ubuntu 13.04.
http://hg.python.org/cpython/rev/c241831a91f2

--

___
Python tracker 

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

[issue17712] test_gdb failures

[Antoine Pitrou]

Changes by Antoine Pitrou :


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

[issue17884] Try to reuse stdint.h types like int32_t

[STINNER Victor]

New submission from STINNER Victor:

In different places, macros like SIZEOF_VOID_P or SIZEOF_LONG to choose a type, 
whereas the C language proposes standard types since ISO C99: intXX_t and 
uintXX_t (8, 16, 32, 64), intptr_t, etc.

Python should rely on these new types instead of trying to reimplement this 
standard. autotools provides missing types if needed. On Windows, stdint.h is 
supported in Microsoft Visual Studio 2010.

Attached patch reuses stdint.h types in different places. I only tested it on 
Linux Fedora 11.

sha3 module should also be modified.

I don't know if int64_t and uint64_t are always supported, nor if we can rely 
on them. Does Python support platform without 64-bit integer type?

The md5 module uses PY_LONG_LONG to get a 64-bit type. Does anyone know a 
platform where the md5 module is not compiled?

--
files: reuse_stdint_types.patch
keywords: patch
messages: 188192
nosy: Devin Jeanpierre, haypo, mark.dickinson
priority: normal
severity: normal
status: open
title: Try to reuse stdint.h types like int32_t
versions: Python 3.4
Added file: http://bugs.python.org/file30083/reuse_stdint_types.patch

___
Python tracker 

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

[issue17870] Python does not provide PyLong_FromIntMax_t() or PyLong_FromUintMax_t() function

[STINNER Victor]

STINNER Victor added the comment:

See also issue #17884.

--

___
Python tracker 

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

[issue17884] Try to reuse stdint.h types like int32_t

[STINNER Victor]

STINNER Victor added the comment:

See also issue #17870 related to intmax_t and uintmax_t.

--

___
Python tracker 

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

[issue16177] IDLE Crash on Open Parens

[Eric Schulz]

Eric Schulz added the comment:

I can repo with MacOS 10.8.3 and Tcl 8.5.13.  I'm fairly certian it is 
triggered by the calltip.  However, it is intermittent.  I can work for a 
while, get comfortable and let my guard down, then hit the crash.  Typically 
after I have a good amount of unsaved work.  Once I hit it, it'll repro easily 
for the rest of the day.

See excerpts below, full stack trace attached.
---

Process: Python [1036]
Path:/Applications/Python 2.7/IDLE.app/Contents/MacOS/Python
Identifier:  org.python.IDLE
Version: 2.7.3 (2.7.3)
Code Type:   X86 (Native)
Parent Process:  launchd [844]
User ID: 501

Date/Time:   2013-04-30 16:07:14.372 -0700
OS Version:  Mac OS X 10.8.3 (12D78)
Report Version:  10

Interval Since Last Report:  136409 sec
Crashes Since Last Report:   8
Per-App Interval Since Last Report:  82331 sec
Per-App Crashes Since Last Report:   5
Anonymous UUID:  2FC95C75-D434-7DE8-F643-1CC8AA4EB026

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0002, 0x

Application Specific Information:
*** Terminating app due to uncaught exception 
'NSInternalInconsistencyException', reason: 'Error (1000) creating window shape'




  0x476000 -   0x547ff7 +Tcl (8.5.13 - 8.5.13) 
<5038805B-75D8-4B2F-ACE5-55397CE37577> 
/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl
  0x571000 -   0x66ffe7 +Tk (8.5.13 - 8.5.13) 
<0F00C53A-5891-5B7A-1914-290EDC0E4612> 
/Library/Frameworks/Tk.framework/Versions/8.5/Tk

--
Added file: http://bugs.python.org/file30084/issue16177_stack_trace.txt

___
Python tracker 

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

[issue17870] Python does not provide PyLong_FromIntMax_t() or PyLong_FromUintMax_t() function

[STINNER Victor]

STINNER Victor added the comment:

Another patch to use PyLong_FromIntMax_t().

--
Added file: http://bugs.python.org/file30085/use_intmax_t.patch

___
Python tracker 

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

[issue17885] multiprocessing.Process child process imports package instead of parent file

[HCT]

New submission from HCT:

created a project with the following content
CODEC/
CODEC/video.py
CODEC/audio.py
CODEC/__init__.py
CRC/
CRC/crc24.py
CRC/crc32.py
CRC/__init__.py
TEST/test_crc.py
TEST/test_codec.py
TEST/__init__.py
__init__.py
test.py
main.py


test.py contain tests that launches multiple multiprocessing.Process to test 
diffferent module in parallel, but always fail to launch child processes for 
test with AttributeError. I spent lots of time trying to figure out why my code 
don't work. I also tried to use the examples from 
http://docs.python.org/dev/library/multiprocessing.html#the-process-class and 
they also gives AttributeError when launching child process. in the end, I 
figured out it's because Pythong file test.py has same name as package TEST. 
change test.py to test_all.py and everything worked.

It looks multiprocessing import defaults to import package, not the parent file 
when file name without suffix is same as package.

--
components: Library (Lib)
messages: 188197
nosy: hct
priority: normal
severity: normal
status: open
title: multiprocessing.Process child process imports package instead of parent 
file
type: compile error
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

[issue17885] multiprocessing.Process child process imports package instead of parent file

[R. David Murray]

R. David Murray added the comment:

I take it you are on a case insensitive file system, in which case this is just 
the way imports work in Python: a package is preferred to a .py file with the 
same name.

--
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type: compile error -> 

___
Python tracker 

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

[issue17874] ProcessPoolExecutor in interactive shell doesn't work in Windows

[Decade]

Decade added the comment:

Ah. Then, a documentation error. The error message ("queue.Full"?) and the 
documentation are totally not clear about that. Does ProcessPoolExecutor just 
not require tasks to be picklable in Unix?

Also, this raises questions about what exactly "picklable" means, and why it's 
not defined in the documentation.

--

___
Python tracker 

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

[issue17886] Invitation to connect on LinkedIn

[Hank Christian]

New submission from Hank Christian:

LinkedIn


Python,

I'd like to add you to my professional network on LinkedIn.

- Henry

Henry Christian
ADJUNCT PROFESSOR at Central Texas College
Greater Los Angeles Area

Confirm that you know Henry Christian:
https://www.linkedin.com/e/-3qcne3-hg5vnelc-3m/isd/10674146693/f8KKDSuG/?hs=false&tok=0pSa4dW8LbLlI1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/-3qcne3-hg5vnelc-3m/z2oU7dKDzpt2G7xQz2FC2SclHmnUGzmsk0c/goo/report%40bugs%2Epython%2Eorg/20061/I4269541394_1/?hs=false&tok=3ubW__G4DbLlI1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

--
messages: 188200
nosy: hankchristian
priority: normal
severity: normal
status: open
title: Invitation to connect on LinkedIn

___
Python tracker 

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

[issue17886] spam

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
resolution:  -> invalid
status: open -> closed
title: Invitation to connect on LinkedIn -> spam

___
Python tracker 

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

[issue15984] Wrong documentation for PyUnicode_FromObject() and PyUnicode_FromEncodedObject()

[Kyle Roberts]

Kyle Roberts added the comment:

I've uploaded a new patch with the obj argument properly marked up. Brian, I 
think *obj* is what we want based on other examples in that file. It looks like 
italics is typically used when discussing parameters since each parameter is 
italicized in the signature.

R.David and Serhiy, I thought about the use of "coercion" some more and I think 
the current wording is fine. "Type coercion/conversion" is a commonly used 
phrase with some languages, so I think the phrase is applicable here as well 
(for a python example: 
http://docs.python.org/release/2.5.2/ref/coercion-rules.html). Let me know if 
you'd still like to see it changed. Thanks.

--
Added file: http://bugs.python.org/file30086/from_object_v2.patch

___
Python tracker 

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

[issue16177] Typing left parenthesis in IDLE causes intermittent Cocoa Tk crash on OS X

[Ned Deily]

Ned Deily added the comment:

Thanks for the report, Eric.  It confirms that the problem still exists with 
everything current.  I'm sorry you are hitting the crash.  Without being able 
to reliably reproduce the problem, it's difficult to be able to help.  Are 
there any hints you can give about what you were doing leading up to the crash, 
e.g. how many IDLE windows open, how large and where were they placed on the 
desktop, any hidden IDLE windows, how large a file if editing (is the window 
scrolling)?  The only other practical thing I can think of is to try a debug 
build of Python and of Tcl/Tk in the hopes of getting a more precise stack 
trace. (I could supply that.)  I suspect opening a Tk or an Apple incident 
without more to go will not be very productive.

--
components:  -IDLE
nosy: +wordtech
stage:  -> test needed
title: IDLE Crash on Open Parens -> Typing left parenthesis in IDLE causes 
intermittent Cocoa Tk crash on OS X

___
Python tracker 

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

[issue17887] docs: summary page - generator vs iterator vs iterable

[anatoly techtonik]

New submission from anatoly techtonik:

Docs lack a good summary page comparing three concepts. The main question is 
how do I tell if something is a sequence, generator, iterator or iterable? I 
found myself puzzled that range() is neither generator or iterator.

--
assignee: docs@python
components: Documentation
messages: 188203
nosy: docs@python, techtonik
priority: normal
severity: normal
status: open
title: docs: summary page - generator vs iterator vs iterable

___
Python tracker 

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