[issue14428] Implementation of the PEP 418

[Charles-François Natali]

Charles-François Natali  added the comment:

Tiny review.

Two more details:
- since it's relatively straightforward to cache the last value returned using 
a static variable, it might be interesting to use this to make sure that the 
values returned are indeed monotonic
- I'm not a native speaker, but `hires` name bothers me a bit, I'd prefer 
`highres` (see for example 
http://www.kernel.org/doc/Documentation/timers/highres.txt, the highres kernel 
parameter and patch-set name), or maybe `hrtime`

--
nosy: +neologix

___
Python tracker 

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

[issue14386] Expose dictproxy as a public type

[Guido van Rossum]

Guido van Rossum  added the comment:

Since it has to go *somewhere*, let's put it in the types module.  It has a 
variety of other types that are used in the implementation of classes and 
functions and related things.

--

___
Python tracker 

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

[issue14408] Support the load_tests protocol in the stdlib tests

[Michael Foord]

Michael Foord  added the comment:

Yes, it would be preferable if unittest could load the set of test classes for 
each of these test modules without *requiring* a load_tests function.

Each test module will need looking at to see if the standard set of test 
classes exported by the module is the same as the set built by load_tests. 
Where they are the same load_tests is not needed. 

I *presume* the point of this patch is that these test modules *can't* just be 
run by the standard unittest invocation, and load_tests is *needed*.

(And I don't know what you mean by "predicate the support classes" Matt.)

--

___
Python tracker 

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

[issue14432] Bug in generator if the generator in created in a C thread

[STINNER Victor]

New submission from STINNER Victor :

We have a crash in our product when tracing is enabled by
sys.settrace() and threading.settrace(). If a Python generator is
created in a C thread, calling the generator later in another thread
may crash if Python tracing is enabled.

 - the C thread calls PyGILState_Ensure() which creates a temporary
Python thread state
 - a generator is created, the generator has a reference to a Python
frame which keeps a reference to the temporary Python thread state
 - the C thread calls PyGILState_Releases() which destroys the
temporary Python thread state
 - when the generator is called later in another thread, call_trace()
reads the Python thread state from the generator frame, which is the
destroyed frame => it does crash on a pointer dereference if the
memory was reallocated (by malloc()) and the data were erased

To reproduce the crash, unpack the attached
generator_frame_bug.tar.gz, compile the C module using:

   python setup.py build

and then run:

   PYTHONPATH=$(ls -d build/lib*/) python test.py

(or just "python test.py if you installed the _test module).
You may need to use Valgrind to see the error, or call memset(tstate,
0xFF, sizeof(*tstate)) before free(tstate) in tstate_delete_common().

Calling the generator should update its reference to the Python state
thread in its frame. The generator may also clears frame->f_tstate (to
detect bugs earlier), as it does for frame->f_back (to avoid a
reference cycle). Attached patch implements this fix for Python 3.3.

--
components: Interpreter Core
files: generator_frame_bug.tar.gz
messages: 156982
nosy: haypo, neologix, pitrou
priority: normal
severity: normal
status: open
title: Bug in generator if the generator in created in a C  thread
type: crash
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25054/generator_frame_bug.tar.gz

___
Python tracker 

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

[issue14408] Support the load_tests protocol in the stdlib tests

[R. David Murray]

R. David Murray  added the comment:

Your presumption is probably correct, however if that is the premise of the 
patch it is incorrect in detail, since we've already fixed test_queue 
specifically to be runnable with -m unittest without adding a load_tests.  I 
haven't looked at the other modules Matt is looking at, but it may well be that 
they can also be fixed without a load_tests.

The test_queue fix is issue 14333, also opened by Matt, but fixed by Michele.

I think we should make the tests runnable by unittest, but that we should use 
load_tests only if making discovery work for a particular test is too invasive.

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

[issue14432] Bug in generator if the generator in created in a C thread

[Ross Lagerwall]

Ross Lagerwall  added the comment:

Here's the patch ;-)

--
keywords: +patch
nosy: +rosslagerwall
Added file: http://bugs.python.org/file25055/generator.patch

___
Python tracker 

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

[issue7511] msvc9compiler.py: ValueError when trying to compile with VC Express

[Martin v . Löwis]

Martin v. Löwis  added the comment:

Victor, can you apply this patch and report that it works. In particular, if it 
does *not* work, can you please report the exact way of failing? (if you can, 
please also try to investigate why it fails).

--

___
Python tracker 

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

[issue14432] Bug in generator if the generator in created in a C thread

[Nick Coghlan]

Nick Coghlan  added the comment:

The proposed fix sounds reasonable to me. Would it be possible to work 
something into test_capi to actually test it?

--
nosy: +ncoghlan

___
Python tracker 

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

[issue14322] More test coverage for hmac

[Vijay Majagaonkar]

Changes by Vijay Majagaonkar :


--
nosy: +Vijay.Majagaonkar

___
Python tracker 

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

[issue14432] Bug in generator if the generator in created in a C thread

[Nick Coghlan]

Nick Coghlan  added the comment:

It may not even have to specifically test the crash - any operation that 
accessed the tstate on the frame and could be shown to be accessing the wrong 
thread state when called from another thread could demonstrate the problem.

--

___
Python tracker 

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

[issue14408] Support the load_tests protocol in the stdlib tests

[Éric Araujo]

Éric Araujo  added the comment:

> Of course this would remove the possibility to run things like “../../python 
> test_shutil.py”

I was wrong: we would just have the usual two-liner invoking unittest.main.  
What would be broken is running via regrtest if we remove test_main functions 
(IIRC); the functions could stay until regrtest learns to use unittest 
discovery.

--

___
Python tracker 

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

[issue14408] Support ./python -m unittest in the stdlib tests

[Éric Araujo]

Changes by Éric Araujo :


--
title: Support the load_tests protocol in the stdlib tests -> Support ./python 
-m unittest in the stdlib tests

___
Python tracker 

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

[issue14408] Support ./python -m unittest in the stdlib tests

[R. David Murray]

R. David Murray  added the comment:

The test_main functions can be converted to use unittest discovery, though.  
That's what I did for test_email.

--

___
Python tracker 

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

[issue14423] Getting the starting date of iso week from a week number and a year.

[Esben Agerbæk Black]

Esben Agerbæk Black  added the comment:

Patch updated with sanity checks.

--
Added file: http://bugs.python.org/file25056/isodates.patch

___
Python tracker 

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

[issue14408] Support ./python -m unittest in the stdlib tests

[Michael Foord]

Michael Foord  added the comment:

Test discovery is only needed for finding tests in directories of tests - for a 
single test module the standard test loader should work fine.

--

___
Python tracker 

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

[issue12643] code.InteractiveConsole ignores sys.excepthook

[Florent Xicluna]

Changes by Florent Xicluna :


--
nosy: +flox

___
Python tracker 

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

[issue14408] Support ./python -m unittest in the stdlib tests

[R. David Murray]

R. David Murray  added the comment:

Right.  What I meant to say was "test_main can be converted to use normal 
unittest test loading".  test_email is not an example of that, since it does 
use test discovery, but is a good example of a test collection that works with 
both regrtest and unittest without excess boilerplate such as listing 
individual test suites.

--

___
Python tracker 

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

[issue14423] Getting the starting date of iso week from a week number and a year.

[R. David Murray]

Changes by R. David Murray :


--
keywords: +needs review
nosy: +belopolsky
stage:  -> patch review
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.4

___
Python tracker 

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

[issue7511] msvc9compiler.py: ValueError when trying to compile with VC Express

[Victor Lin]

Victor Lin  added the comment:

Oddly, can't reproduce the problem anymore. I try to install win7 on virtual 
machine, but it works as well. I think the issue might caused by something 
else... not sure, so strange :S

Will look into detail once I encounter this issue again.

--

___
Python tracker 

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

[issue14409] IDLE does not execute any commands (command prompt works fine!)

[Ankit Agrawal]

Ankit Agrawal  added the comment:

Another cfg file from the original .idlerc folder

--
Added file: http://bugs.python.org/file25058/config-main.cfg

___
Python tracker 

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

[issue14409] IDLE does not execute any commands (command prompt works fine!)

[Ankit Agrawal]

Ankit Agrawal  added the comment:

Please find attached, the  original .cfg files that I was found in my idlerc 
folder. I hope this proves helpful. If you need any other information I'd be 
glad to help.

--
status: pending -> open
Added file: http://bugs.python.org/file25057/config-extensions.cfg

___
Python tracker 

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

[issue14423] Getting the starting date of iso week from a week number and a year.

[Esben Agerbæk Black]

Esben Agerbæk Black  added the comment:

Patch updated with tests and documentation

--
Added file: http://bugs.python.org/file25059/isodates.patch

___
Python tracker 

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

[issue14433] Python 3 interpreter crash with memoryview and os.fdopen

[Alexis Daboville]

New submission from Alexis Daboville :

Hi,

I was "playing" with memoryviews when I found this behaviour, launch the Python 
shell, and then enter the following:

>>> import os
>>> memoryview(os.fdopen(0))

A TypeError "cannot make memory view because object does not have the buffer 
interface" is raised and shown in the shell.

Then:
* On Windows 7, Python 3.2.2: Windows open a window with something like this 
"python.exe has stopped working"
* On CrunchBang Linux (Debian), Python 3.1.3: the shell exits (though echo $? 
print 0...).

On IRC, valhallasw was able to reproduce the bug:
[19:24]  a__: also happens under 3.2.2 under windows XP /and/ 3.2 
under ubuntu natty
[19:24]  the latter just crashes without any message, the former 
gives the windows XP equivalent of the 'program has stopped working' message

I hope this help, if you need more information please ask.

--
messages: 156996
nosy: alexis.d
priority: normal
severity: normal
status: open
title: Python 3 interpreter crash with memoryview and os.fdopen
type: crash
versions: Python 3.1, Python 3.2

___
Python tracker 

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

[issue14432] Bug in generator if the generator in created in a C thread

[Andrew Svetlov]

Changes by Andrew Svetlov :


--
nosy: +asvetlov

___
Python tracker 

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

[issue14433] Python 3 interpreter crash with memoryview and os.fdopen

[Charles-François Natali]

Charles-François Natali  added the comment:

Hello,

This has actually nothing to do with memoryview:

"""
>>> import os
[67212 refs]
>>> stdin = os.fdopen(0)
[67234 refs]
>>> del stdin
__main__:1: ResourceWarning: unclosed file <_io.TextIOWrapper name=0 mode='r' 
encoding='UTF-8'>
[67260 refs]
>>> 
[67261 refs]
[44710 refs]
"""

When the object returned by os.fdopen() is garbage collected, the underlying FD 
is closed, and the interpreter aborts when it tries to read from stdin.
So it's not an issue, try calling memoryview(fdopen() 
and it'll work.

--
nosy: +neologix
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type: crash -> behavior

___
Python tracker 

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

[issue14433] Python 3 interpreter crash with memoryview and os.fdopen

[Brian Curtin]

Brian Curtin  added the comment:

> So it's not an issue, try calling memoryview(fdopen( 0,1,2>) and it'll work.

This is exactly why it's an issue. Python should not crash.

--
nosy: +brian.curtin
status: closed -> open

___
Python tracker 

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

[issue14409] IDLE: not executing commands from shell, error with default keybinding for Return

[Roger Serwy]

Roger Serwy  added the comment:

Thank you for the configuration files. It helped with finding the bug.

The default key bindings in configHandler.py is incorrect for 
<> which caused the problem Ankit experienced.  This 
problem affects the 2.7 and 3.3 series. 

Attached is a patch against 3.3 (and 2.7) to fix the issue.

--
keywords: +patch
nosy: +asvetlov
stage:  -> patch review
title: IDLE does not execute any commands (command prompt works fine!) -> IDLE: 
not executing commands from shell, error with default keybinding for Return
versions: +Python 3.3
Added file: http://bugs.python.org/file25060/issue14409.patch

___
Python tracker 

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

[issue14433] Python 3 interpreter crash with memoryview and os.fdopen

[R. David Murray]

R. David Murray  added the comment:

To make this a little clearer, here's an even simpler example:

  >>> import os
  >>> os.fdopen(0)
<_io.TextIOWrapper name=0 mode='r' encoding='UTF-8'>
  >>> 1
__main__:1: ResourceWarning: unclosed file <_io.TextIOWrapper name=0 mode='r' 
encoding='UTF-8'>
  1
  >>>
  rdmurray@hey:~/python/p32>

What is happening here is that the file returned by os.fdopen is assigned to _, 
and then when I enter '1' *it* gets assigned to _, and the file gets gced and 
closed.  You can also see this directly:

  >>> import os
  >>> f = os.fdopen(0)
  >>> f.close()
  >>>
  rdmurray@hey:~/python/p32>

I explain this at length because I didn't understand it until I played around 
with it.

@Brian: this isn't a crash.  It is completely equivalent to pressing D at 
the interactive interpreter prompt.

--
nosy: +r.david.murray
status: open -> closed

___
Python tracker 

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

[issue14433] Python 3 interpreter crash with memoryview and os.fdopen

[Alexis Daboville]

Alexis Daboville  added the comment:

First, thank you all for the explanations (sorry for the misleading title about 
the memoryview, should I rename it?).

> @Brian: this isn't a crash.  It is completely equivalent to pressing D 
> at the interactive interpreter prompt.

Not exactly, at least on Windows if I type ^Z +  (which is the 
equivalent of ^D) the shell exits normally, while here there's an "annoying" 
error message (I don't say that it's important, just that that's not completely 
equivalent)

--

___
Python tracker 

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

[issue14433] Python 3 interpreter crash with memoryview and os.fdopen

[Brian Curtin]

Brian Curtin  added the comment:

Maybe it's a different reason, but some part of something about this crashes on 
Windows. "python.exe has stopped working" is a crash dialog.

--

___
Python tracker 

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

[issue14433] Python 3 interpreter crash with memoryview and os.fdopen

[R. David Murray]

R. David Murray  added the comment:

Hmm.  And D isn't how you shut down the interpreter on Windows, is it?  So 
maybe there is a Windows-specific bug here after all.  Or do you get that same 
dialog if you do the Windows equivalent of D in a shell window (is that 
different from a CMD window, or the same?)

--

___
Python tracker 

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

[issue14409] IDLE: not executing commands from shell, error with default keybinding for Return

[Ned Deily]

Ned Deily  added the comment:

Roger, I notice that the line your patch modifies in configHandler.py has been 
unchanged for years and is the same in older Python versions.  My impression 
from Ankit's description is that this is a new problem.  What's different or am 
I misunderstanding something?

--
nosy: +ned.deily

___
Python tracker 

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

[issue14386] Expose dictproxy as a public type

[Raymond Hettinger]

Raymond Hettinger  added the comment:

[GvR]
> Since it has to go *somewhere*, let's put it 
> in the types module.  It has a variety of other 
> types that are used in the implementation of 
> classes and functions and related things.

+1

--

___
Python tracker 

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

[issue14204] Support for the NPN extension to TLS/SSL

[Marcelo Fernández]

Changes by Marcelo Fernández :


--
nosy: +marcelo_fernandez

___
Python tracker 

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

[issue14409] IDLE: not executing commands from shell, error with default keybinding for Return

[Roger Serwy]

Roger Serwy  added the comment:

Ned, the buggy default keybinding for <> requires that 
Key-Return and then Key-KP_Enter be pressed before the virtual event triggers. 
This happens because both key events are present in a single string. The 
correct behavior requires each key event be listed in a separate string in a 
list. (See <> for an example). MultiCall.py has code (event_add) that 
iterates over the list and binds each key to an event.

This bug is also present in 2.3.5. (I just downloaded and tested it on XP.)

--

___
Python tracker 

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

[issue2090] __import__ with fromlist=

[Éric Araujo]

Changes by Éric Araujo :


--
versions: +Python 3.3 -Python 3.1

___
Python tracker 

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

[issue14408] Support ./python -m unittest in the stdlib tests

[Matt Joiner]

Matt Joiner  added the comment:

Michael:

The thread setup and cleanup is not required, AFAICT. You are also correct in 
that these particular test modules do not run correctly without modification 
(although test_queue does now that the bug I reported there was fixed).

Sorry by predicated, I mean that we could mask out the base classes that many 
of the tests are enumerated on top of. Some kind of decorator for the base 
could prevent the base class being discovered unless it's inherited from. This 
is the source of the errors one currently gets running the tests via -m 
unittest.

Eric:

I'm not sure what you mean by the files being long. I've taken the existing 
test case list and exposed this directly to both load_tests and unittest.main. 
The load_tests boilerplate is disappointing, but explicit.

--

___
Python tracker 

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

[issue14434] Tutorial link in "help()" in 3.2.2

[Bill Winslow]

New submission from Bill Winslow :

I installed "python3" to get into a good scripting language.

I ran "python3" and it said type "help". I did and it said type "help()" for 
interactive help, or "help(object)" for specific help. Just looking to get 
started, I did the former, where the message displayed says "Welcome to Python 
3.2!  This is the online help utility.

If this is your first time using Python, you should definitely check out
the tutorial on the Internet at http://docs.python.org/tutorial/.";

The link, unfortunately, leads to the Python 2.7 documentation, which is rather 
useless considering I'm trying to learn 3.2. The proper link should be 
http://docs.python.org/py3k/tutorial/.

Yes, this is really minor, but it would help with the "completeness" or 
"professional" appearance.

--
assignee: docs@python
components: Documentation
messages: 157011
nosy: Dubslow, docs@python
priority: normal
severity: normal
status: open
title: Tutorial link in "help()" in 3.2.2
type: behavior
versions: Python 3.2

___
Python tracker 

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

[issue14386] Expose dictproxy as a public type

[poq]

poq  added the comment:

It is exposed as types.DictProxyType in Python 2...

--
nosy: +poq

___
Python tracker 

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