[issue14220] "yield from" kills generator on re-entry

[Stefan Behnel]

Stefan Behnel  added the comment:

Ah, yes, that should work in both implementations. I'll give it a try. Thanks!

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

___
Python tracker 

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

[issue14216] ImportError: No module named binascii

[Qian Liu]

Qian Liu  added the comment:

Hi, Eric Araujo,

Thanks for your help. I run "make -s" and found the following message. It
seems that binascii cannot be built correctly. What should I do? Many
thanks.

libpython2.7.a(posixmodule.o)(.text+0x47e1): In function `posix_tmpnam':
./Modules/posixmodule.c:7370: warning: the use of `tmpnam_r' is dangerous,
better use `mkstemp'
libpython2.7.a(posixmodule.o)(.text+0x46c7): In function `posix_tempnam':
./Modules/posixmodule.c:7317: warning: the use of `tempnam' is dangerous,
better use `mkstemp'
building dbm using gdbm
/usr/bin/ld: /usr/local/lib/libz.a(crc32.o): relocation R_X86_64_32 against
`a local symbol' can not be used when making a shared object; recompile
with -fPIC
/usr/local/lib/libz.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
/usr/bin/ld: /usr/local/lib/libz.a(crc32.o): relocation R_X86_64_32 against
`a local symbol' can not be used when making a shared object; recompile
with -fPIC
/usr/local/lib/libz.a: could not read symbols: Bad value
collect2: ld returned 1 exit status

Python build finished, but the necessary bits to build these modules were
not found:
_sqlite3   bsddb185   dl
imageopsunaudiodev
To find the necessary bits, look in setup.py in detect_modules() for the
module's name.

*Failed to build these modules:*
*binascii   zlib*

Best regards,
Qian Liu

--

___
Python tracker 

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

[issue14227] console w/ cp65001 displays extra characters for non-ascii strings.

[Mark Tolonen]

New submission from Mark Tolonen :

This is on Windows 7 SP1.  Run 'chcp 65001' then Python from a console.  Note 
the extra characters when non-ASCII characters are in the string.  At a guess 
it appears to be using the UTF-8 byte length of the internal representation 
instead of the character count.

Python 3.3.0a1 (default, Mar  4 2012, 17:27:59) [MSC v.1500 32 bit (Intel)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> print('hello')
hello
>>> print('p\u012bny\u012bn')
pīnyīn
n
>>> print('\u012b'*10)
īī
�
�ī

--
components: IO, Unicode, Windows
messages: 155149
nosy: ezio.melotti, metolone
priority: normal
severity: normal
status: open
title: console w/ cp65001 displays extra characters for non-ascii strings.
type: behavior
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

[issue13370] test_ctypes fails when building python with clang

[Meador Inge]

Meador Inge  added the comment:

LLVM/clang bug report here: http://llvm.org/bugs/show_bug.cgi?id=12207.

--

___
Python tracker 

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

[issue14205] Raise an error if a dict is modified during a lookup

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 0255bafbccf2 by Victor Stinner in branch 'default':
Issue #14205: document the change of dict[key] behaviour if dict is modified
http://hg.python.org/cpython/rev/0255bafbccf2

--

___
Python tracker 

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

[issue6755] Patch: new method get_wch for ncurses bindings: accept wide characters (unicode)

[STINNER Victor]

Changes by STINNER Victor :


--
status: open -> closed

___
Python tracker 

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

[issue6755] Patch: new method get_wch for ncurses bindings: accept wide characters (unicode)

[STINNER Victor]

STINNER Victor  added the comment:

Antoine's issue has been fixed:
"Modules/_cursesmodule.c:919:9: attention : implicit declaration of function 
‘wget_wch’"

It looks like Jesús's issue is specific to Solaris (or is already fixed?), and 
so I added a comment to the issue #13552: "Modules/_cursesmodule.c:920: 
warning: implicit declaration of function 'wget_wch'".

--

___
Python tracker 

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

[issue13552] Compilation issues of the curses module on OpenIndiana

[STINNER Victor]

STINNER Victor  added the comment:

Jesús Cea Avión also noticed in msg143798 from the issue #6755:

I have compiled ncurses myself, supporting wide characters. I get this warnings 
in the buildbots:

"""
/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Modules/_cursesmodule.c:920:
 warning: implicit declaration of function 'wget_wch'
/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Modules/_cursesmodule.c:927:
 warning: implicit declaration of function 'mvwget_wch'
/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Modules/_cursesmodule.c:2760:
 warning: implicit declaration of function 'unget_wch'
"""

Studying the "ncurses.h", I see the definition of "wget_wch" and others. But 
these definitions are created only if "_XOPEN_SOURCE_EXTENDED" is defined.

Something to be explored?.

--

___
Python tracker 

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

[issue1469629] __dict__ = self in subclass of dict causes a memory leak

[Roundup Robot]

Roundup Robot  added the comment:

New changeset c7623da4e2af by Benjamin Peterson in branch '2.7':
allow cycles throught the __dict__ slot to be cleared (closes #1469629)
http://hg.python.org/cpython/rev/c7623da4e2af

--

___
Python tracker 

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

[issue14223] curses addch broken on Python3.3a1

[STINNER Victor]

STINNER Victor  added the comment:

I introduced the arbitrary limit when I added support of the curses Unicode API 
(libncursesw). The limit is useless if libncursesw is used, whereas it blocks 
legal "characters" like KEY_xxx constants. So I just removed the check and it 
should not be ok.

The real issue is that Python curses is not linked to libncursesw on Mac OS X!

--

___
Python tracker 

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

[issue3787] Make PyInstanceMethod_Type available or remove it

[Benjamin Peterson]

Changes by Benjamin Peterson :


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

___
Python tracker 

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

[issue14223] curses addch broken on Python3.3a1

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 861a5f3e7453 by Victor Stinner in branch 'default':
Close #14223: curses.addch() is no more limited to the range 0-255 when the
http://hg.python.org/cpython/rev/861a5f3e7453

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

[issue1469629] __dict__ = self in subclass of dict causes a memory leak

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 3787e896dbe9 by Benjamin Peterson in branch '3.2':
allow cycles throught the __dict__ slot to be cleared (closes #1469629)
http://hg.python.org/cpython/rev/3787e896dbe9

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

[issue3787] Make PyInstanceMethod_Type available or remove it

[Roundup Robot]

Roundup Robot  added the comment:

New changeset b595e1ad5722 by Benjamin Peterson in branch 'default':
merge 3.2 (#3787e896dbe9)
http://hg.python.org/cpython/rev/b595e1ad5722

--
nosy: +python-dev

___
Python tracker 

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

[issue14222] Using time.time() in Queue.get breaks when system time is changed

[STINNER Victor]

STINNER Victor  added the comment:

> Well, in 3.3 we could use clock_gettime(CLOCK_MONOTONIC) where available.

It's better to use time.monotonic().

> That said, this is not specific to Queue.get() and will probably happen with 
> many similar functions taking a timeout parameter.

Yep, it may be used for lock.acquire(timeout=timeout) for example. It 
would help to have a portable monotonic clock API in C.

--

___
Python tracker 

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

[issue14127] os.stat and os.utime: allow preserving exact metadata

[Nick Coghlan]

Nick Coghlan  added the comment:

FWIW, +1 on using the *name* of the keyword arg to define the format/resolution 
of the argument. It's simple and clear right now, and is easily updated to 
handle higher resolutions in the future.

--
nosy: +ncoghlan

___
Python tracker 

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

[issue14209] pkgutil.iter_zipimport_modules ignores the prefix parameter for packages

[Nick Coghlan]

Nick Coghlan  added the comment:

Adding Brett, since the plan is to clear out a lot of the redundant code in 
pkgutil once importlib is fully bootstrapped as the standard import 
implementation.

(although this will still affect the older versions directly)

--
nosy: +brett.cannon

___
Python tracker 

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

[issue13964] os.utimensat() and os.futimes() should accept (sec, nsec), drop os.futimens()

[Larry Hastings]

Larry Hastings  added the comment:

I just asked Guido in person, and he says he never intended to suggest 
accepting a (sec, nsec) tuple.  os.*utime* may accept atime and mtime as either 
float seconds-since-the-epoch, or int nanoseconds-since-the-epoch when passed 
in using the ns= named parameter.

--

___
Python tracker 

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

[issue7652] Merge C version of decimal into py3k.

[Stefan Krah]

Stefan Krah  added the comment:

Jim Jewett  wrote:
> > OK, as a basis for discussion I've added:
> > http://hg.python.org/features/cdecimal/file/8b75c2825508/Modules/_decimal/FILEMAP.txt
> 
> Starting from that URL, I don't actually find setup.py.

It's the setup.py from the Python top level directory.

> I'm not sure what sort of failures building in the normal order led
> to, but that is certainly something worth documenting, and (ideally)
> fixing.

I do not have access to AIX. On Windows the failures were locale related
when mixing the dynamic and static runtimes.

> I didn't see any mention of the literature subdirectory, which makes
> me wonder if there were other files not listed in the map.  (Not yet
> curious enough to verify for myself, though.)  (*.txt files?)

FILEMAP.txt was intended to get people started, not to be a polished work.

> I suppose a subdirectory name like "python" makes sense when you look
> at the library as a C/C++ project that happens to provide python
> bindings; as part of the python core, it is misleading.

OK.

> provide extra functionality, or to generate some of the source code,

There is no source code generation. I'm not sure where this idea comes
from. genlocale.py e.g. has this comment:

Usage:  ../../../python genlocale.py | ../tests/runtest -

> Within the library, does io.[ch] really limit itself to ASCII?  If so,
> then I don't know why you're worried about the Turkish i.  If you mean
> generic text, then please don't specify ASCII.

I do mean ASCII. Please run this gdb session:

diff --git a/Modules/_decimal/io.c b/Modules/_decimal/io.c
--- a/Modules/_decimal/io.c
+++ b/Modules/_decimal/io.c
@@ -245,7 +245,7 @@
if (digits > (size_t)(ctx->prec-ctx->clamp))
goto conversion_error;
}
-   else if (_mpd_strneq(s, "inf", "INF", 3)) {
+   else if (strncasecmp(s, "inf", 3) == 0) {
s += 3;
if (*s == '\0' || _mpd_strneq(s, "inity", "INITY", 6)) {
/* numeric-value: infinity */

gdb ../../python
b mpd_qset_string
r
>>> locale.setlocale(locale.LC_ALL, 'tr_TR.utf8')
'tr_TR.utf8'
>>> from decimal import *
>>> Decimal("Infinity")

(gdb) 
248 else if (strncasecmp(s, "inf", 3) == 0) {
(gdb) p s
$1 = 0x77191280 "Infinity"
(gdb) p s[0]
$2 = 73 'I'
(gdb) n
259 if ((coeff = scan_dpoint_exp(s, &dpoint, &exp, &end)) 
== NULL)

Clearly 'I' is ASCII and strncasecmp fails, exactly as written in the
comment above _mpd_strneq().

> Within memory.[ch], how much of this configurability is useful (or
> even available) to a python user, as opposed to an extension writer?

Since it is in the libmpdec section, "User" refers to the extension writer.
I can simply drop the "User".

> Under the Bignum section, it mentions that functions from these files
> are ultimately used in _mpd_fntmul, but doesn't mention where that is
> (in the main _cdecimal.c)

OK.

> Also, when it talks about "large arrays", could you clarify that it
> isn't talking about arrays of values or even matrixes, it is just
> talking about numbers large enough that even representing them takes
> at least N bytes?

But it is referring to abstract sequences or arrays of values less
than a certain prime. These values happen to be the coefficient of
an mpd_t, but you could perform the transform on any sequence.

I thought 'Bignum' would already imply an array of machine words
representing a number.

> >> Would it at least be OK to wrap them in stubs for exporting, so that
> >> the test logic could be places with the others tests? ??(I worry that
> >> some tests may stop getting run if someone else modifies the build
> >> process and doesn't notice the unusual location.)
> 
> > tests/runtest.c won't compile then. I'll look into the stub and also
> > the _testhelp suggestions.
> 
> OK, let me rephrase.  Is newton division exported to users, or used
> internally, or is it just for testing purposes?

It's used internally as _mpd_qbarrett_divmod(). When the coefficient has
more than MPD_NEWTONDIV_CUTOFF words, the division functions dispatch
to _mpd_qbarrett_divmod().

> _mpd_qtest_newtondiv is documented as a testcase; I would rather see
> it move to a test file.  Why can't it?

I said in my last mail that I'll look into it.

> >> > "Infinity", "InFinItY", "iNF" are all allowed by the specification.
> 
> >> OK; so is io.c part of the library, or part of the python binding?
> 
> > I see a potential source of confusion: io.c is firmly part of the
> > library.
> 
> [And should therefore be available when used without python?]

I meant: Despite the fact that io.c might /appear/ to be specifically
written for the module because of the presence of PEP 3101 references,
it is part of the standalone (moduleless) library. However, _decimal.c
uses all parts of io.c except for a couple of functions at the bottom
of the file that are useful for debugging.

--

_

[issue14220] "yield from" kills generator on re-entry

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 3357eac1ba62 by Benjamin Peterson in branch 'default':
make delegating generators say they running (closes #14220)
http://hg.python.org/cpython/rev/3357eac1ba62

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

[issue14220] "yield from" kills generator on re-entry

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Don't worry! I'll be fixing it in a moment...

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue14220] "yield from" kills generator on re-entry

[Nick Coghlan]

Nick Coghlan  added the comment:

Added Mark Shannon to the nosy list - he's been tinkering with this area of the 
interpreter lately.

This definitely needs to be fixed though (even if that does mean major surgery 
on the implementation, up to and including the introduction of an __iter_from__ 
method)

--
nosy: +Mark.Shannon

___
Python tracker 

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

[issue14226] Expose dict_proxy type from descrobject.c

[André Malo]

New submission from André Malo :

As discussed in the dev-thread about frozendicts, it would be helpful for 
providing advisory read-only-dicts, to just expose the dict_proxy type. I 
suppose, the collections module would be a good place (it just needs to provide 
the interface to the type, not the whole implementation).

--
components: Extension Modules, Interpreter Core
messages: 155131
nosy: ndparker
priority: normal
severity: normal
status: open
title: Expose dict_proxy type from descrobject.c
type: enhancement

___
Python tracker 

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

[issue1469629] __dict__ = self in subclass of dict causes a memory leak

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +haypo

___
Python tracker 

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

[issue14225] _cursesmodule compile error in OS X 32-bit-only installer build

[Ned Deily]

New submission from Ned Deily :

./Modules/_cursesmodule.c:279: error: syntax error before 'cchar_t'
/Users/sysadmin/build/v3.3.0a1/Modules/_cursesmodule.c: In function 
'PyCurses_ConvertToCchar_t':
./Modules/_cursesmodule.c:289: error: 'obj' undeclared (first use in this 
function)/Users/sysadmin/build/v3.3.0a1/Modules/_cursesmodule.c:279: error: 
syntax error before 'cchar_t'

Note to self, this installer build builds its own version of ncurses. It may 
need adjusting for 3.3.

--
assignee: ned.deily
components: Build, Macintosh
messages: 155130
nosy: ned.deily
priority: release blocker
severity: normal
status: open
title: _cursesmodule compile error in OS X 32-bit-only installer build
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

[issue14222] Using time.time() in Queue.get breaks when system time is changed

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Well, in 3.3 we could use clock_gettime(CLOCK_MONOTONIC) where available.
That said, this is not specific to Queue.get() and will probably happen with 
many similar functions taking a timeout parameter.

--
nosy: +haypo, neologix, pitrou

___
Python tracker 

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

[issue14220] "yield from" kills generator on re-entry

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +ncoghlan

___
Python tracker 

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

[issue14217] text output pretends to be code

[Éric Araujo]

Éric Araujo  added the comment:

Use this:

.. code-block:: none

   output etc.

--
nosy: +eric.araujo
versions: +Python 2.7 -Python 3.1

___
Python tracker 

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

[issue14218] include rendered output in addition to markup

[Éric Araujo]

Éric Araujo  added the comment:

> For devguide/documenting, If you show me markup, also show me what output it 
> gives me.
Would this really be useful?  If you’re looking at that page, you want to know 
what markup to use for what situation; why do you care about output?

> It's kinda tedious to keep building the markup just to verify how it's 
> rendered.
I’m not sure I understand; if there were example output in the doc, you’d only 
have to build the devguide once to see how markup is rendered, wouldn’t you?

--
nosy: +eric.araujo

___
Python tracker 

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

[issue14215] http://www.python.org/dev/peps/ title is python.org

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +eric.araujo

___
Python tracker 

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

[issue14216] ImportError: No module named binascii

[Éric Araujo]

Éric Araujo  added the comment:

I suggest you do two things:
- first, run “make -s” to reduce messages and see if the binascii module is 
compiled correctly or skipped
- second, avoid possible misleading issues with PATH entirely by starting your 
Python with an absolute path, like ~/path/to/python

(Sidenote: It would be kind of you to edit your replies to remove unneeded 
quotes from previous messages.  They just clobber the bug report.  Thanks in 
advance.)

--
nosy: +eric.araujo

___
Python tracker 

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

[issue14223] curses addch broken on Python3.3a1

[R. David Murray]

R. David Murray  added the comment:

Marking as release blocker since this is a regression.  Added people from the 
other curses issue as being likely to be interested in this one.

--
nosy: +cben, gpolo, haypo, inigoserna, jcea, phep, pitrou, python-dev, 
r.david.murray, schodet, zeha
priority: normal -> release blocker
stage:  -> needs patch
type:  -> behavior

___
Python tracker 

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

[issue14209] pkgutil.iter_zipimport_modules ignores the prefix parameter for packages

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +ncoghlan, pje
stage:  -> test needed

___
Python tracker 

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

[issue14224] packaging: path description of resources is mixed up

[Éric Araujo]

Éric Araujo  added the comment:

Thanks, will apply.

--
assignee: docs@python -> eric.araujo
nosy: +eric.araujo

___
Python tracker 

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

[issue14224] packaging: path description of resources is mixed up

[Johannes Kolb]

New submission from Johannes Kolb :

The documentation for "files" section of the setup.cfg file causes confusion: 
The examples don't match the description. Obviously the order of "destination" 
and "source" part in the generated filenames was mixed up in some places.

--
assignee: docs@python
components: Documentation
files: packaging-docfixes.diff
keywords: patch
messages: 155123
nosy: docs@python, jokoala
priority: normal
severity: normal
status: open
title: packaging: path description of resources is mixed up
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file24754/packaging-docfixes.diff

___
Python tracker 

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

[issue14212] Segfault when using re.finditer over mmap

[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

[issue14212] Segfault when using re.finditer over mmap

[Benjamin Peterson]

Benjamin Peterson  added the comment:

I think 2.7 might be hopeless.

--
nosy: +benjamin.peterson
resolution: fixed -> 
stage: committed/rejected -> 
status: closed -> open

___
Python tracker 

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

[issue14212] Segfault when using re.finditer over mmap

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 10a79a33d09b by Benjamin Peterson in branch '3.2':
keep the buffer object around while we're using it (closes #14212)
http://hg.python.org/cpython/rev/10a79a33d09b

New changeset 17dfe24e5107 by Benjamin Peterson in branch 'default':
merge 3.2 (#14212)
http://hg.python.org/cpython/rev/17dfe24e5107

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

[issue11122] bdist_rpm should use rpmbuild, not rpm

[Éric Araujo]

Changes by Éric Araujo :


--
title: bdist_rpm fails -> bdist_rpm should use rpmbuild, not rpm

___
Python tracker 

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

[issue11122] bdist_rpm fails

[Éric Araujo]

Éric Araujo  added the comment:

More info on rpm vs. rpmbuild: http://bugs.python.org/issue1533164#msg82592

--
keywords: +easy
stage:  -> needs patch

___
Python tracker 

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

[issue6755] Patch: new method get_wch for ncurses bindings: accept wide characters (unicode)

[Nicholas Cole]

Nicholas Cole  added the comment:

On Wed, Mar 7, 2012 at 7:40 AM, R. David Murray  wrote:
>
> R. David Murray  added the comment:
>
> Since this bug is about adding a new feature, it is unlikely to be the 
> correct bug for this to be against.
>
> Given that you've identified a regression, I suggest you open a new bug with 
> a reproducer, and we'll set it to release blocker.

I've created issue 14223.  I hope I've done so correctly.

Best wishes,

Nicholas

--

___
Python tracker 

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

[issue5926] bdist_msi: add support for minimum Python version for pure Python projects

[Éric Araujo]

Changes by Éric Araujo :


--
assignee: tarek -> eric.araujo
title: bdist_msi - add support for minimum Python version for pure Python 
packages -> bdist_msi: add support for minimum Python version for pure Python 
projects
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

[issue14223] curses addch broken on Python3.3a1

[Nicholas Cole]

New submission from Nicholas Cole :

The following code works on Python versions prior to 3.3a1:

import curses

def test_screen(screen):
screen.addch(5,5, curses.ACS_HLINE)
screen.refresh()

curses.wrapper(test_screen)

On python3.3, the program produces the following traceback:


Traceback (most recent call last):
  File "/tmp/p.py", line 7, in 
curses.wrapper(test_screen)
  File 
"/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/curses/__init__.py",
 line 94, in wrapper
return func(stdscr, *args, **kwds)
  File "/tmp/p.py", line 4, in test_screen
screen.addch(5,5, curses.ACS_HLINE)
OverflowError: byte doesn't fit in chtype

--
components: Library (Lib)
messages: 155118
nosy: Nicholas.Cole
priority: normal
severity: normal
status: open
title: curses addch broken on Python3.3a1
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

[issue13719] bdist_msi upload fails

[Éric Araujo]

Éric Araujo  added the comment:

I forgot to mention two other problems in my test:
- need to pass name and version keyword arguments to self.create_dist or to 
change the expected filename to UNKNOWN-UNKNOWN
- need to embed the result of distutils.util.get_platform() into the expected 
filename

--

___
Python tracker 

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

[issue13719] bdist_msi upload fails

[Éric Araujo]

Éric Araujo  added the comment:

I finally got a virtual machine up and running and was able to diagnose the 
problem.  There are two things.  First, the dist directory (where the msi file 
will be created) is created relative to the current working directory, which 
explains why listdir in the temporary project directory caused the test to 
fail.  Second, after your patch bdist_wininst puts a full path in the 
dist.dist_files list, but it should use a relative path, like other bdist 
commands do.  (This choice comes from the fact that setup scripts must be run 
from their parent directory.)

Fixing the first problem is just a matter of adding os.chdir(project_dir) in 
the test; the second problem is also easy, using os.path.join and 
self.dist_dir.  I chose to backout the commits because I won’t be able to make 
a correct patch right now, I have to configure file sharing between my host and 
my VM.  Let’s have the buildbots green for a while and then break them again 
(not :).

Debugging this made me realize that all tests should use os.path.join('dist', 
filename) instead of e.g. 'dist/blah-1.0.rpm' in test_bdist_rpm; I’ll do that 
in another commit.

--
resolution: fixed -> 
stage: committed/rejected -> 

___
Python tracker 

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

[issue13785] Make concurrent.futures.Future state public

[Brian Quinlan]

Brian Quinlan  added the comment:

I guess the question is: why do you need to know the state in that form?

--

___
Python tracker 

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

[issue14148] Option to kill "stuck" workers in a multiprocessing pool

[Brian Quinlan]

Changes by Brian Quinlan :


--
nosy: +bquinlan

___
Python tracker 

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

[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks

[Brian Quinlan]

Brian Quinlan  added the comment:

I'm closing this since tbrink didn't respond to pitrou's comments.

--
resolution:  -> out of date

___
Python tracker 

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

[issue14119] Ability to adjust queue size in Executors

[Brian Quinlan]

Changes by Brian Quinlan :


--
assignee:  -> bquinlan
nosy: +bquinlan

___
Python tracker 

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

[issue13719] bdist_msi upload fails

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 7e629bacec87 by Éric Araujo in branch '3.2':
Backout buggy patch committed for #13719
http://hg.python.org/cpython/rev/7e629bacec87

New changeset 17106d7d34b4 by Éric Araujo in branch 'default':
Remove buggy change for #13719 in packaging
http://hg.python.org/cpython/rev/17106d7d34b4

--

___
Python tracker 

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

[issue14220] "yield from" kills generator on re-entry

[Stefan Behnel]

Stefan Behnel  added the comment:

Here is an analysis of this (less verbose) code:

def g1():
yield "y1"
yield from g2()
yield "y4"

def g2():
yield "y2"
try:
yield from gi
except ValueError:
pass  # catch "already running" error
yield "y3"

gi = g1()
for y in gi:
print("Yielded: %s" % (y,))

This is what it currently does:

1) g1() delegates to a new g2()

2) g2 delegates back to the g1 instance and asks for its next value

3) Python sees the active delegation in g1 and asks g2 for its next value

4) g2 sees that it's already running and throws an exception

Ok so far. Now:

5) the exception is propagated into g1 at call level 3), not at level 1)!

6) g1 undelegates and terminates by the exception

7) g2 catches the exception, yields "y3" and then terminates normally

8) g1 gets control back but has already terminated and does nothing

Effect: "y4" is not yielded anymore.

The problem is in steps 5) and 6), which are handled by g1 at the wrong call 
level. They shouldn't lead to undelegation and termination in g1, just to an 
exception being raised in g2.

--

___
Python tracker 

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

[issue1531415] parsetok.c emits warnings by writing to stderr

[Brett Cannon]

Brett Cannon  added the comment:

It's quite possible you are right, Michele. I don't know if anyone has looked 
at what exactly is required for _warnings.c compared to pgen.

--

___
Python tracker 

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

[issue13719] bdist_msi upload fails

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 077b42a54803 by Éric Araujo in branch '2.7':
Backout buggy patch for #13719
http://hg.python.org/cpython/rev/077b42a54803

--

___
Python tracker 

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

[issue8754] quote bad module name in ImportError-like messages

[Brett Cannon]

Brett Cannon  added the comment:

It technically doesn't depend, but it potentially would make this moot. But 
stuff is going on at the language summit which is going to shift stuff around.

--
dependencies:  -ImportError needs attributes for module and file name

___
Python tracker 

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

[issue2377] Replace __import__ w/ importlib.__import__

[Brett Cannon]

Brett Cannon  added the comment:

The finding/loading code in import.c is purely because of the imp module's 
public API (e.g. imp.find_module()). I have been waiting to find out if 
importlib would get bootstrapped before making the current module _imp and then 
creating an imp.py which handles most of the high-level stuff (e.g. imp.py 
containing find_module() and have it use importlib). That would let all of that 
C code go away since I already tie into the low-level C API for C-level import 
function calls.

--

___
Python tracker 

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

[issue7652] Merge C version of decimal into py3k.

[Jim Jewett]

Jim Jewett  added the comment:

On Wed, Mar 7, 2012 at 5:28 AM, Stefan Krah
 added the comment:

> OK, as a basis for discussion I've added:
> http://hg.python.org/features/cdecimal/file/8b75c2825508/Modules/_decimal/FILEMAP.txt

That is indeed very helpful.  So helpful that now I understand well
enough to have additional gripes.  :D

Starting from that URL, I don't actually find setup.py.

I am assuming (but would prefer to have the file explicitly state)
that _decimal.c and docstrings.h are the only source files, and that
setup.py would be the only build infrastructure needed if you already
had libmpdec.a.

I'm not sure what sort of failures building in the normal order led
to, but that is certainly something worth documenting, and (ideally)
fixing.

I didn't see any mention of the literature subdirectory, which makes
me wonder if there were other files not listed in the map.  (Not yet
curious enough to verify for myself, though.)  (*.txt files?)

I suppose a subdirectory name like "python" makes sense when you look
at the library as a C/C++ project that happens to provide python
bindings; as part of the python core, it is misleading.  It sounds
like it should be named "extended_tests" or some such.  (Note that
this assumes it is strictly for tests; if you are also using it to
provide extra functionality, or to generate some of the source code,
then I agree with Benjamin that it should move to tools, and the
generated code should have clear comments right at the top warning
that it is generated.)

Within the library, does io.[ch] really limit itself to ASCII?  If so,
then I don't know why you're worried about the Turkish i.  If you mean
generic text, then please don't specify ASCII.

Within memory.[ch], how much of this configurability is useful (or
even available) to a python user, as opposed to an extension writer?
Or is it really just for testing?  As in, would it be reasonable to
just have a single header with a half-dozen #defines, but to replace
that header when doing a memory-test build?  Or at least to hide the
alternative function definitions inside an obvious #ifdef, so that
they don't take up memory and attention when they aren't applicable?

Under the Bignum section, it mentions that functions from these files
are ultimately used in _mpd_fntmul, but doesn't mention where that is
(in the main _cdecimal.c)

Also, when it talks about "large arrays", could you clarify that it
isn't talking about arrays of values or even matrixes, it is just
talking about numbers large enough that even representing them takes
at least N bytes?

>> Would it at least be OK to wrap them in stubs for exporting, so that
>> the test logic could be places with the others tests?  (I worry that
>> some tests may stop getting run if someone else modifies the build
>> process and doesn't notice the unusual location.)

> tests/runtest.c won't compile then. I'll look into the stub and also
> the _testhelp suggestions.

OK, let me rephrase.  Is newton division exported to users, or used
internally, or is it just for testing purposes?

_mpd_qtest_newtondiv is documented as a testcase; I would rather see
it move to a test file.  Why can't it?  If it is because of
_mpd_qdiv_inf, _settriple, _mpd_qbarrett_divmod, _mpd_real_size (the
only apparently internal things it uses), then why are these internal?
 Could they be exposed at least to test functions?  If not, could they
at least be wrapped in something that could exposed, such as
_testhelp_mpd_qdiv_inf?

>> > "Infinity", "InFinItY", "iNF" are all allowed by the specification.

>> OK; so is io.c part of the library, or part of the python binding?

> I see a potential source of confusion: io.c is firmly part of the
> library.

[And should therefore be available when used without python?]

> All PEP 3101 formatting is part of libmpdec, because I like
> the mini language. io.c only understands ASCII and UTF-8 fill characters.

> It is the *library* tests that would fail under the Turkish locale
> (if not for _mpd_strneq).

Are those tests relevant to a _cdecimal built in to python itself?  If
not, then the comment is at least misleading.  Would it make sense to
have a directory for files that are used only for the standalone C
library, but not when built as part of python?

>> Good enough, though I would rather see that as a comment near the assembly.

> Comments how to enforce an ANSI build (much slower!) are in LIBTEST.txt
> and now also in FILEMAP.txt.

I would not have made the leap from that to "What to do if the
assembly code needs to be replaced or even just changed."

--

___
Python tracker 

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

[issue14222] Using time.time() in Queue.get breaks when system time is changed

[Tasslehoff Kjappfot]

New submission from Tasslehoff Kjappfot :

Queue.get([block[, timeout]]) uses time.time() for calculations of the timeout. 
If someone changes the system time this breaks. If a timeout of 1 second is set 
and someone (on a unix system) uses date to set the time 1 hour back, Queue.get 
will use 1 hour and 1 second to time out.

I'm guessing the fix is just to use another library function to measure time, 
but I don't know if one exists that works on all platforms.

--
components: Library (Lib)
messages: 155106
nosy: tasslehoff
priority: normal
severity: normal
status: open
title: Using time.time() in Queue.get breaks when system time is changed
type: behavior
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

[issue14212] Segfault when using re.finditer over mmap

[Stefan Krah]

Changes by Stefan Krah :


--
nosy: +skrah

___
Python tracker 

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

[issue14212] Segfault when using re.finditer over mmap

[Alex Gaynor]

Changes by Alex Gaynor :


--
nosy: +alex

___
Python tracker 

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

[issue14212] Segfault when using re.finditer over mmap

[Matthew Barnett]

Matthew Barnett  added the comment:

In the function "getstring" in _sre.c, the code obtains a pointer to the 
characters of the buffer and then releases the buffer.

There's a comment before the release:

/* Release the buffer immediately --- possibly dangerous
   but doing something else would require some re-factoring
*/
PyBuffer_Release(&view);

What's happening is that after the mmap is closed the pointer is no longer 
valid.

--

___
Python tracker 

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

[issue14221] re.sub backreferences to numbered groups produce garbage

[Ezio Melotti]

Ezio Melotti  added the comment:

You forgot to use raw strings:
>>> text = "The cat ate the rat."
>>> print("before: %s" % text)
before: The cat ate the rat.
>>> text = re.sub("(\w+) ate the (\w+)", r"\2 ate the \1", text)
>>> print("after : %s" % text)
after : The rat ate the cat.
>>> 

(Maybe you should reconsider writing yet another tutorial about regular 
expressions, and possibly submit patches to improve the official regex howto if 
you think it's not good enough.)

--
assignee:  -> ezio.melotti
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

[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters

[Glenn Linderman]

Glenn Linderman  added the comment:

Improved documentation would certainly help the situation.

And yes, I understand that optparse simply returned the set of positional 
parameters without giving them names, types, or groups.  So does getopt, and 
pretty much all previous art in the arena of command line parsing that I am 
familiar with.

To successfully replace optparse and other prior art, though, there should be 
an equivalent, although perhaps improved, functionality in argparse.

This lack of documentation for the idea that the ordered set of all positional 
parameters is not treated as a sequence certainly slipped under the covers of 
optparse functionality when I first read about it when optparse was being added 
to the stdlib.  I had no clue that the specification of positional parameters 
would do anything other than process the positional parameters sequentially, 
without being disrupted by intervening optional parameters.  The capabilities 
for naming, and typing those parameters are nice enhancements, but were not 
seen as redefining what positional parameters are, from its historical 
definition.  Is there wording in the PEP that describes such?

Naming and typing and even grouping positional parameters are all nice 
features... but there should be no undocumented boundaries between positional 
parameters (or groups of them), and presently there are no documented 
boundaries, and with prior art there were no boundaries.

Having no boundaries among positional parameters is a capability and 
expectation that has a long history, and tools ported from prior art to 
argparse need the capability to preserve command line compatibility.  Hence, I 
conclude that, unless this was spelled out in the PEP and I missed it, that 
having such boundaries is a bug, even if your intentions were otherwise, and 
that the test case I provided should work.

My test was only meant to demonstrate the issue, not to be a particular use 
case, but there are use cases that would be affected in the same manner as the 
demonstration.

Regarding your suggested documentation, it is more complete than my suggestion, 
but "sequence" should probably be replaced by "sequence of adjacent" if that is 
what is meant, because with positional parameters, the historical perspective 
is that the sequence of positional parameters may be interrupted by optional 
parameters, but that makes it no less a sequence.

I believe that the present syntax for parsing positional parameters should be 
fixed to handle all positional parameters, because of the history of prior art, 
and that if there is a need, benefit, or demand for treating positional 
parameters in groups, then that should be documented and created as additional 
features.

I further cannot figure out how to even parse the additional positional 
parameters as a separate group, using the current capabilities.  My attempt to 
do so in t14.py failed.

--
Added file: http://bugs.python.org/file24753/t14.py

___
Python tracker 

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

[issue14187] add "annotation" entry to Glossary

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti
type:  -> enhancement

___
Python tracker 

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

[issue14208] No way to recover original argv with python -m

[Georg Brandl]

Georg Brandl  added the comment:

I agree.  Maybe I may throw "full_argv" or "executable_argv" (i.e. to be used 
with exec([sys.executable] + sys.executable_arg)) in the air?

--

___
Python tracker 

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

[issue14187] add "annotation" entry to Glossary

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I'm not sure this would be a worthwhile addition.  This language feature is not 
widely referenced outside the docs for the feature itself.

--
nosy: +rhettinger

___
Python tracker 

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

[issue14221] re.sub backreferences to numbered groups produce garbage

[Phillip Feldman]

New submission from Phillip Feldman :

The first example below works; the second one produces output containing 
garbage characters.  (This came up while I was creating a set of examples for a 
tutorial on regular expressions).

import re

text= "The cat ate the rat."
print("before: %s" % text)
m= re.search("The (\w+) ate the (\w+)", text)
text= "The %s ate the %s." % (m.group(2), m.group(1))
print("after : %s" % text)

text= "The cat ate the rat."
print("before: %s" % text)
text= re.sub("(\w+) ate the (\w+)", "\2 ate the \1", text)
print("after : %s" % text)

--
components: Regular Expressions
messages: 155100
nosy: Phillip.M.Feldman, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: re.sub backreferences to numbered groups produce garbage
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

[issue10951] gcc 4.6 warnings

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 2f10c1ad4b21 by Ross Lagerwall in branch 'default':
Issue #10951: Fix warnings in the socket module.
http://hg.python.org/cpython/rev/2f10c1ad4b21

New changeset 1dd43e939c07 by Ross Lagerwall in branch 'default':
Issue #10951: Fix compiler warnings in _sre.c
http://hg.python.org/cpython/rev/1dd43e939c07

--

___
Python tracker 

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

[issue14214] test_concurrent_futures hangs

[Brian Quinlan]

Brian Quinlan  added the comment:

Could you run just the test_concurrent_futures test, hit ctrl-C at the point 
where it hangs, and send the traceback here?

--

___
Python tracker 

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

[issue9592] Limitations in objects returned by multiprocessing Pool

[Max Franks]

Max Franks  added the comment:

Issue 3 is not related to the other 2. See this post 
http://bugs.python.org/issue5370. As haypo said, it has to do with unpickling 
objects. The post above gives a solution by using the __setstate__ function.

--
nosy: +eliquious

___
Python tracker 

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

[issue14214] test_concurrent_futures hangs

[Nadeem Vawda]

Nadeem Vawda  added the comment:

> I happended several times.

Hmm. If you hit another failure, can you post the random seed and any
other interesting info that might help figure this out?

The test_dbm failures look like issue 14120. You might want to follow up
there.

--
nosy: +bquinlan

___
Python tracker 

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

[issue7652] Merge C version of decimal into py3k.

[Stefan Krah]

Stefan Krah  added the comment:

This issue was raised by Jim on Rietveld:

Currently, the order of arguments in Context.__init__() differs
from repr(Context):

>>> Context()
Context(prec=28, rounding=ROUND_HALF_EVEN, Emin=-9, Emax=9, 
capitals=1, flags=[], traps=[DivisionByZero, Overflow, InvalidOperation])
>>> 
>>> Context(28, ROUND_HALF_EVEN, -9, 9, 1, [], [DivisionByZero, 
>>> Overflow, InvalidOperation])
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.2/decimal.py", line 3774, in __init__
flags = dict([(s, int(s in flags)) for s in _signals])
  File "/usr/lib/python3.2/decimal.py", line 3774, in 
flags = dict([(s, int(s in flags)) for s in _signals])
TypeError: argument of type 'int' is not iterable
>>> 


I find this quite ugly. The repr() order is the good one, since
it moves the flag dictionaries to the end. I wanted to change
the order in Context.__init__() to match repr(), but I'm not
sure if such a change is possible.

I don't think Python code would initialize a context without keywords,
but C extensions might.

--
versions: +Python 3.3 -Python 3.2

___
Python tracker 

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

[issue14201] Documented caching for shared library's __getattr__ and __getitem__ is incorrect

[Erik Johansson]

Erik Johansson  added the comment:

Ah, I see. I modified the title to reflect this.

Perhaps adding this simple example as well can help people (e.g. me) see it?

>>> libc.time == libc.time
True
>>> libc['time'] == libc['time']
False

--
title: libc.time != libc['time'] -> Documented caching for shared library's 
__getattr__ and __getitem__ is incorrect

___
Python tracker 

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

[issue7652] Merge C version of decimal into py3k.

[Stefan Krah]

Stefan Krah  added the comment:

Marc-Andre Lemburg  wrote:
> Does the C version have a C API importable as capsule ?

Not yet. I'll try to make a list with proposed function names and post it here.

> If not, could you add one and a decimal.h to go with it ?

Yes, sure.

--

___
Python tracker 

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

[issue14201] libc.time != libc['time']

[Éric Araujo]

Éric Araujo  added the comment:

Item access is documented in this section: 
http://docs.python.org/library/ctypes#loading-shared-libraries (scroll a bit 
down looking for __getitem__); the wording about caching is ambiguous with 
respect to the current behavior.

--
assignee:  -> docs@python
components: +Documentation
keywords: +easy
nosy: +docs@python, eric.araujo
stage:  -> needs patch

___
Python tracker 

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

[issue14205] Raise an error if a dict is modified during a lookup

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee: rhettinger -> 

___
Python tracker 

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

[issue14201] libc.time != libc['time']

[Erik Johansson]

Erik Johansson  added the comment:

Perhaps this behaviour should be documented somewhere (unless it already is)?

--

___
Python tracker 

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

[issue14214] test_concurrent_futures hangs

[Miki Tebeka]

Miki Tebeka  added the comment:

I happended several times. Ran it this morning an got passed it, however other 
tests failed though:
==
ERROR: test_anydbm_creation (test.test_dbm.TestCase-dbm.ndbm)
--
Traceback (most recent call last):
  File "/home/miki/src/Python-3.3.0a1/Lib/test/test_dbm.py", line 70, in 
test_anydbm_creation
self.read_helper(f)
  File "/home/miki/src/Python-3.3.0a1/Lib/test/test_dbm.py", line 111, in 
read_helper
self.assertEqual(self._dict[key], f[key.encode("ascii")])
KeyError: b'0'

==
ERROR: test_anydbm_modification (test.test_dbm.TestCase-dbm.ndbm)
--
Traceback (most recent call last):
  File "/home/miki/src/Python-3.3.0a1/Lib/test/test_dbm.py", line 85, in 
test_anydbm_modification
self.read_helper(f)
  File "/home/miki/src/Python-3.3.0a1/Lib/test/test_dbm.py", line 111, in 
read_helper
self.assertEqual(self._dict[key], f[key.encode("ascii")])
KeyError: b'0'

==
ERROR: test_anydbm_read (test.test_dbm.TestCase-dbm.ndbm)
--
Traceback (most recent call last):
  File "/home/miki/src/Python-3.3.0a1/Lib/test/test_dbm.py", line 91, in 
test_anydbm_read
self.read_helper(f)
  File "/home/miki/src/Python-3.3.0a1/Lib/test/test_dbm.py", line 111, in 
read_helper
self.assertEqual(self._dict[key], f[key.encode("ascii")])
KeyError: b'0'

--
Ran 18 tests in 0.149s

FAILED (errors=3)

--

___
Python tracker 

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

[issue14201] libc.time != libc['time']

[Thomas Heller]

Thomas Heller  added the comment:

The rationale was to allow different packages (for example) in the same process 
to have their own private instance of a foreign function, with possibly 
different definitions of restype, argtypes and/or errcheck.

--

___
Python tracker 

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

[issue7652] Merge C version of decimal into py3k.

[Stefan Krah]

Stefan Krah  added the comment:

Jim Jewett  wrote:
> implementation details.  Are there are clear distinctions (type
> info/python bindings/basic arithmetic/advanced
> algorithms/internal-use-only/???)

I failed to mention that libmpdec also has complete documentation. Perhaps
that can answer some questions:

http://www.bytereef.org/mpdecimal/doc/libmpdec/index.html
http://www.bytereef.org/mpdecimal/doc/libmpdec/functions.html#quiet-functions

--

___
Python tracker 

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

[issue7652] Merge C version of decimal into py3k.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> _ctypes does not compile with icc and suncc. Unlike _ctypes, _decimal
> has a fallback in the form of decimal.py. So, perhaps as an alternative
> we could leave the inlines and wait for build failure reports?

Sounds good to me.

--

___
Python tracker 

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

[issue7652] Merge C version of decimal into py3k.

[Stefan Krah]

Stefan Krah  added the comment:

Antoine Pitrou  wrote:
> You could use Py_LOCAL_INLINE, but most compilers should inline small
> functions automatically, AFAIK.

At the time I wrote it I benchmarked everything. I'm pretty sure
that gcc did not inline larger functions like mpd_qresize_zero()
and mpd_word_digits() and even some smaller ones that are declared
ALWAYS_INLINE. Also, the static inline functions in the header
files are absolutely crucial for speed.

I recall that Mark initially said that in the Modules hierarchy
not every module would need to compile. Now, _decimal is already
tested with gcc, clang, icc, suncc, Visual Studio, and success
has been reported with xlc[1]. CompCert compiles libmpdec but not
Python.

_ctypes does not compile with icc and suncc. Unlike _ctypes, _decimal
has a fallback in the form of decimal.py. So, perhaps as an alternative
we could leave the inlines and wait for build failure reports?

[1] compilation success, one of the numerous AIX issues on
bugs.python.org with loading the module was encountered IIRC.

--

___
Python tracker 

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

[issue7652] Merge C version of decimal into py3k.

[Stefan Krah]

Stefan Krah  added the comment:

Case Van Horsen  wrote:
> cdecimal 2.3 does not support the __ceil__ and __floor__

Thanks. I'll look into that.

> cdecimal.Decimal instances do not emulate the various single-underscore 
> methods of a decimal.Decimal instance. In gmpy2, I use _int, _exp, _sign, and 
> _is_special to convert a decimal.Decimal into an exact fraction. I realize 
> the issue is with gmpy2 and I will fix gmpy2, but there may be other code 
> that uses those methods.

There seems to be a real need for getting (sign, coeff, exp). I think
psycopg2 uses a painful way to get an integer coefficient via as_tuple().
What should really be added is either as_triple(), which would return
(sign, coeff, exp) with an integer coefficient or make these attributes
official:

Decimal.sign
Decimal.coeff
Decimal.exp

I have to think about implementing Decimal._int etc. Somehow I feel that
doing so would send a wrong signal: People shouldn't assume that they'll
get away with using private methods and attributes.

Also, of course they'll keep using these private methods until they
are finally deprecated, and *then* they'll have to change things.

--

___
Python tracker 

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

[issue1469629] __dict__ = self in subclass of dict causes a memory leak

[Florent Xicluna]

Changes by Florent Xicluna :


--
nosy: +flox
title: __dict__ = self in subclass of dict causes a memory leak? -> __dict__ = 
self in subclass of dict causes a memory leak

___
Python tracker 

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

[issue1469629] __dict__ = self in subclass of dict causes a memory leak?

[Hrvoje Nikšić]

Hrvoje Nikšić  added the comment:

Could this patch please be committed to Python? We have just run into this 
problem in production, where our own variant of AttrDict was shown to be 
leaking.

It is possible to work around the problem by implementing explicit __getattr__ 
and __setattr__, but that is both slower and trickier to get right.

--
nosy: +hniksic

___
Python tracker 

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

[issue7652] Merge C version of decimal into py3k.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Do you happen to know a free compiler that builds Python but does not
> understand "inline"? I'm asking because without testing you can never
> really be sure:

You could use Py_LOCAL_INLINE, but most compilers should inline small
functions automatically, AFAIK.

--

___
Python tracker 

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

[issue7652] Merge C version of decimal into py3k.

[Stefan Krah]

Stefan Krah  added the comment:

Benjamin Peterson  wrote:
> Speaking of inline, the "inline" keyword will have to go because it's not C89.

Do you happen to know a free compiler that builds Python but does not
understand "inline"? I'm asking because without testing you can never
really be sure:

For example I added support for compilers without uint64_t, but
all major compilers (gcc, suncc, icc, VS) of course have uint64_t.

Then I finally found CompCert, and discovered that a couple of
things were missing in the headers.

--

___
Python tracker 

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

[issue11379] Remove "lightweight" from minidom description

[Stefan Behnel]

Stefan Behnel  added the comment:

Oh, right, I missed that part. I also think that a visible note is better. And 
+1 for "W3C DOM interface".

--

___
Python tracker 

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

[issue14214] test_concurrent_futures hangs

[Nadeem Vawda]

Nadeem Vawda  added the comment:

Is this a single failure that you encountered, or have you been able to
reproduce it on subsequent runs? I haven't seen a failure in
test_concurrent_futures in 10-15 runs of "make test" (also on Ubuntu
11.10 64-bit).

--
nosy: +nadeem.vawda
stage:  -> needs patch
type:  -> behavior

___
Python tracker 

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

[issue7652] Merge C version of decimal into py3k.

[Stefan Krah]

Stefan Krah  added the comment:

Benjamin Peterson  wrote:
> The scripts for generating code would preferably go in a Tools/decimal 
> directory.

Hmm, do you mean the gen*.py scripts? The output is generated by decimal.py
and used for testing libmpdec. While the syntax resembles that of the
*.decTest files, only tests/runtest can handle the format.

--

___
Python tracker 

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

[issue11379] Remove "lightweight" from minidom description

[Eli Bendersky]

Eli Bendersky  added the comment:

Éric,

I'm ok with replacing "lightweight" by "minimal", unless others have 
objections. Regarding the specifics of the minidom-desc-2.diff patch:

   "proficient with the DOM"

I'm not sure "the DOM" is semantically correct. "the W3C-DOM interface" is more 
precise.

Also, I still think that a note would be more appropriate, but I don't care 
enough to argue about it :)

--

___
Python tracker 

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

[issue11379] Remove "lightweight" from minidom description

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> FYI, note that http://wiki.python.org/moin/MiniDom says this about  
> minidom: “slow and very memory hungry DOM implementation”.

Thanks for the notice; I have now fixed that wording.

--

___
Python tracker 

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

[issue14218] include rendered output in addition to markup

[Tshepang Lekhonkhobe]

Tshepang Lekhonkhobe  added the comment:

> Sandro Tosi  added the comment:
>
> 3.1 and 2.6 as in security fix only: please don't add those versions for 
> non-sec issue

Sorry, I thought there was an exception for documentation issues.

--

___
Python tracker 

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

[issue14202] The docs of xml.dom.pulldom are almost nonexistent

[Éric Araujo]

Éric Araujo  added the comment:

Merged Florian’s version with the original file to create a patch.

--
Added file: http://bugs.python.org/file24752/pulldom-documentation.rst

___
Python tracker 

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

[issue11379] Remove "lightweight" from minidom description

[Éric Araujo]

Éric Araujo  added the comment:

FYI, note that http://wiki.python.org/moin/MiniDom says this about minidom: 
“slow and very memory hungry DOM implementation”.

As you have seen, I have applied my ToC order change.  Now in order to commit 
my s/lightweight/minimal/ change and close this report, can you Eli say if 
minidom-desc-2 is okay (I’m asking you because this patch touches text you just 
added, contrary to minidom-desc)?

--

___
Python tracker 

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

[issue14208] No way to recover original argv with python -m

[Nick Coghlan]

Nick Coghlan  added the comment:

In framing a question for Raymond regarding his preference for avoiding the 
__argv__ name, I realised I agreed with him. My reasoning is that, when a 
Python process starts, sys.stdin is sys.__stdin__, sys.stdout is sys.__stdout__ 
and sys.stderr is sys.__stderr__. The dunder versions capture the original 
values as created by the interpreter initialisation, not the raw OS level file 
descriptors.

The new attribute proposed here is different - it's not an immutable copy of 
the original value of sys.argv, it's a *different* sequence altogether. The 
analogy with the standard stream initial value capture created by the use of 
sys.__argv__ would actually be misleading rather than helpful.

For the same reason, Raymond's specific argv_original suggestion doesn't really 
work for me. Alas, I can think of several other possible colours for that 
particular bikeshed (such as argv_os, argv_main, argv_raw, argv_platform, 
argv_executable) without having any particular good way of choosing between 
them.

--

___
Python tracker 

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

[issue14220] "yield from" kills generator on re-entry

[Stefan Behnel]

New submission from Stefan Behnel :

Based on the existing "test_attempted_yield_from_loop" in 
Lib/test/test_pep380.py, I wrote this test and I wonder why it does not work:

"""
def test_attempted_reentry():
"""
>>> for line in test_attempted_reentry(): print(line)
g1: starting
Yielded: y1
g1: about to yield from g2
g2: starting
Yielded: y2
g2: about to yield from g1
g2: caught ValueError
Yielded: y3
g1: after delegating to g2
Yielded: y4
"""
trace = []
def g1():
trace.append("g1: starting")
yield "y1"
trace.append("g1: about to yield from g2")
yield from g2()
trace.append("g1: after delegating to g2")
yield "y4"

def g2():
trace.append("g2: starting")
yield "y2"
trace.append("g2: about to yield from g1")
try:
yield from gi
except ValueError:
trace.append("g2: caught ValueError")
else:
trace.append("g1 did not raise ValueError on reentry")
yield "y3"
gi = g1()
for y in gi:
trace.append("Yielded: %s" % (y,))
return trace
"""

In current CPython, I get this:

"""
Failed example:
for line in test_attempted_reentry(): print(line)
Expected:
g1: starting
Yielded: y1
g1: about to yield from g2
g2: starting
Yielded: y2
g2: about to yield from g1
g2: caught ValueError
Yielded: y3
g1: after delegating to g2
Yielded: y4
Got:
g1: starting
Yielded: y1
g1: about to yield from g2
g2: starting
Yielded: y2
g2: about to yield from g1
g2: caught ValueError
Yielded: y3
"""

Even though I catch the ValueError (raised on generator reentry) at the 
position where I run the "yield from", the outer generator (g1) does not 
continue to run after the termination of g2. It shouldn't normally have an 
impact on the running g1 that someone attempts to jump back into it, but it 
clearly does here.

I noticed this while trying to adapt the implementation for Cython, because the 
original test was one of the few failing cases and it made the code jump 
through the generator support code quite wildly.

--
components: Interpreter Core
messages: 155072
nosy: scoder
priority: normal
severity: normal
status: open
title: "yield from" kills generator on re-entry
type: behavior
versions: Python 3.3

___
Python tracker 

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

[issue7652] Merge C version of decimal into py3k.

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Does the C version have a C API importable as capsule ?
If not, could you add one and a decimal.h to go with it ?

This makes integration in 3rd party modules a lot easier.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com


2012-02-13: Released eGenix pyOpenSSL 0.13http://egenix.com/go26
2012-02-09: Released mxODBC.Zope.DA 2.0.2 http://egenix.com/go25

::: Try our new mxODBC.Connect Python Database Interface for free ! 

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/

--
nosy: +lemburg

___
Python tracker 

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

[issue7652] Merge C version of decimal into py3k.

[Stefan Krah]

Stefan Krah  added the comment:

Jim Jewett  wrote:
> Whether you need *additional* subdirectories within _cdecimal to
> subcategorize the .c and .h files, I'm not sure -- because I didn't
> get in deep enough to know what they should be.  If the categorization
> let people focus on the core, that would be helpful, but it wasn't
> clear to me which files were part of the exported API and which were
> implementation details.  Are there are clear distinctions (type
> info/python bindings/basic arithmetic/advanced
> algorithms/internal-use-only/???)

OK, as a basis for discussion I've added:

http://hg.python.org/features/cdecimal/file/8b75c2825508/Modules/_decimal/FILEMAP.txt

I didn't mention the main reason why _decimal.c and libmpdec are in a flat
directory: Building the library first and then the module from the library
led to problems on at least Windows and AIX. That's why I started to treat
all libmpdec files as part of the module, list them as dependencies in setup.py
and let distutils figure everything out. Distutils also can figure out
automatically if a Mac OS build happens to be a "universal" build and things
like that.

The build process is very well tested by now and it took quite a while
to figure everything out, so I'd be reluctant to change the flat hierarchy.

> > ??python/ ?? ?? ??-> ??extended module tests
> 
> I would really expect that to still be under tests, and I would expect
> a directory called python to contain code written in python, or at
> least python bindings.

Could you explain? The python/ directory contains deccheck.py, formathelper.py
etc.

> Would it at least be OK to wrap them in stubs for exporting, so that
> the test logic could be places with the others tests?  (I worry that
> some tests may stop getting run if someone else modifies the build
> process and doesn't notice the unusual location.)

tests/runtest.c won't compile then. I'll look into the stub and also
the _testhelp suggestions.

> > "Infinity", "InFinItY", "iNF" are all allowed by the specification.
> 
> OK; so is io.c part of the library, or part of the python binding?

I see a potential source of confusion: io.c is firmly part of the
library. All PEP 3101 formatting is part of libmpdec, because I like
the mini language. io.c only understands ASCII and UTF-8 fill characters.

It is the *library* tests that would fail under the Turkish locale
(if not for _mpd_strneq).

> Good enough, though I would rather see that as a comment near the assembly.

Comments how to enforce an ANSI build (much slower!) are in LIBTEST.txt
and now also in FILEMAP.txt.

> I'm not worried about the header files.  I am worried about what is
> exposed to python, but just documenting it (docstrings and the module
> .rst) may be OK.
> 
> But I'm also worried that there may be fair amounts of code that are
> effectively dead after the "remove any names not in decimal.py"
> importing trick.  If so, I would at least like that in some sort of
> #ifdef, so that people don't spend too much time trying to make sense
> of it.

It's the opposite: names from decimal.py starting with an underscore
that are not in _decimal are removed. If I don't use that trick, I
end up with about 50 additional symbols from decimal.py:

import decimal # the C version
dir(decimal)

... '_ContextManager', '_Infinity', '_Log10Memoize', ...

--

___
Python tracker 

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

[issue14219] start the Class tutorial in a more gentle manner

[Sandro Tosi]

Sandro Tosi  added the comment:

see msg155067

--
nosy: +sandro.tosi
versions:  -Python 2.6, Python 3.1

___
Python tracker 

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

[issue14218] include rendered output in addition to markup

[Sandro Tosi]

Sandro Tosi  added the comment:

additionally, devguide has no version associated with it.

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