[issue22220] Ttk extensions test failure

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Sorry, it was wrong link. Correct one is:
http://buildbot.python.org/all/builders/x86%20XP-4%203.4/builds/411/steps/test/logs/stdio

Build #411 failed, build #412 successful, and build #413 failed again. May be 
this is test order depending failure.

--

___
Python tracker 

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

[issue22208] tarfile can't add in memory files (reopened)

[Mark Grandi]

Mark Grandi added the comment:

I still don't see why TarFile.add() can't be changed to accept a file like 
object so users don't have to fumble around with a TarInfo object when they 
just want add a file like object, and don't care about the permission bits and 
whatnot. It also says un the TarInfo section that you get those objects from 
gettarinfo(), and its not clear (at least to me) that you can just manually 
construct one, and that you only need the size property set.

I still the easiest way to solve this is to have gettarinfo() or add() accept 
file like objects that don't have file descriptors, as it would go a long way 
to simplifying the use of this module as well. (in zip file you don't ever have 
to worry about ZipInfo objects unless you need them...)

--

___
Python tracker 

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

[issue22216] smtplip STARTTLS fails at second attampt due to unsufficiant quit()

[R. David Murray]

Changes by R. David Murray :


--
components: +email
nosy: +barry, r.david.murray

___
Python tracker 

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

[issue22208] tarfile can't add in memory files (reopened)

[R. David Murray]

Changes by R. David Murray :


--
nosy: +r.david.murray

___
Python tracker 

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

[issue22226] Refactor dict result handling in Tkinter

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

Proposed patch refactors code which converts the result of Tcl call to Python 
dict. Added new private function _splitdict() which does this in more robust 
manner.

Also this patch fixes a bug in Treeview.heading(). The heading subcommand of 
ttk::treeview return options dict in which one key surprisingly was not '-' 
prefixed.

% ttk::treeview t
% .t heading #0
-text {} -image {} -anchor center -command {} state {}

Current code unconditionally cuts "s" from the "state" key.

>>> from tkinter import ttk
>>> t = ttk.Treeview()
>>> t.heading('#0')
{'anchor': 'center', 'tate': '', 'image': '', 'text': '', 'command': ''}

--
assignee: serhiy.storchaka
components: Tkinter
files: tkinter_splitdict.diff
keywords: patch
messages: 225515
nosy: gpolo, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: Refactor dict result handling in Tkinter
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36411/tkinter_splitdict.diff

___
Python tracker 

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

[issue20291] Argument Clinic should understand *args and **kwargs parameters

[Larry Hastings]

Larry Hastings added the comment:

So, let's think about this for a minute.  What's the API that we *want* here?

If your function has the signature
   (a, b, c=20, *args)
and you call it with
   (1, 2, 3, 4, 5)
should "args" be (4, 5), or (1, 2, 3, 4, 5)?

I assert that the impl function should get the same "args" (and "kwargs") that 
a Python function would--that is, post-argument-processing.  In the above 
example "args" should get (4, 5).

This might be somewhat painful to do in round 1, where we're still leveraging 
off PyArg_ParseTuple*.  But in the future it'll be cheaper to do it this way.  
In any case, it's the right API, so that's what we should do.

(Adding Nick just to see if he agrees--he had a use case for *args in the 
builtin module.)

--
nosy: +ncoghlan

___
Python tracker 

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

[issue17140] Document multiprocessing.pool.ThreadPool

[Nick Coghlan]

Nick Coghlan added the comment:

After a question from Brandon Rhodes, I noticed that ThreadPool is actually 
listed in multiprocess.pool.__all__.

So rather than doing anything more dramatic, we should just document the 
existing multiprocessing feature.

As Richard says, the concurrent.futures Executor already provides a general 
purpose thread and process pooling model, and when that isn't appropriate, 
something like asyncio or gevent may actually be a better fit anyway.

--
keywords: +easy
nosy: +brandon-rhodes
title: Provide a more obvious public ThreadPool API -> Document 
multiprocessing.pool.ThreadPool
versions: +Python 3.5

___
Python tracker 

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

[issue22165] Empty response from http.server when directory listing contains invalid unicode

[Senthil Kumaran]

Changes by Senthil Kumaran :


--
status: open -> closed

___
Python tracker 

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

[issue22165] Empty response from http.server when directory listing contains invalid unicode

[Senthil Kumaran]

Changes by Senthil Kumaran :


--
resolution:  -> fixed
stage:  -> resolved

___
Python tracker 

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

[issue18554] os.__all__ is incomplete

[Martin Panter]

Martin Panter added the comment:

I ran into this today, trying to do “help(os)”. The workaround was to do 
“import posix; help(posix)”.

--
nosy: +vadmium

___
Python tracker 

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

[issue21412] Solaris/Oracle Studio: Fatal Python error: PyThreadState_Get when built --with-pymalloc

[John Beck]

John Beck added the comment:

Ned: yes, I can confirm that the patch from http://bugs.python.org/issue21166 
does indeed fix the problem.  Thank you very much!

--

___
Python tracker 

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

[issue22090] Decimal and float formatting treat '%' differently for infinities and nans.

[Stefan Krah]

Stefan Krah added the comment:

I guess it's the right thing to do and here's a patch. Could one of you double 
check the decimal.py part?

--
keywords: +patch
Added file: http://bugs.python.org/file36410/issue22090.diff

___
Python tracker 

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

[issue2527] Pass a namespace to timeit

[Ben Roberts]

Ben Roberts added the comment:

Correction, the name of the argument is 'globals', not 'global'.

--

___
Python tracker 

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

[issue2527] Pass a namespace to timeit

[Ben Roberts]

Ben Roberts added the comment:

Attached is a patch that adds a 'global' kwarg to the Timeit constructor, which 
does pretty much what it says on the tin: specifies a global namespace that 
exec() will use.

I originally had a 'locals' arg as well (to mirror the signature of eval/exec), 
but realized that the local vars I was passing to exec were not available to 
the inner function.  Reason: the timeit module compiles/execs a *closure*, and 
closed-over variables and exec() simply do not play nicely.  Possible 
workarounds were to munge locals() into the globals() dict, or to somehow 
inject the variables in the locals dict into the closure.  I found neither of 
these options superior to simply not including a locals argument, for reasons 
of Least Surprise and maintainability.

Patch includes some basic tests and documentation.  I am particularly 
uncomfortable with writing docs so those very likely need some polish.

--
keywords: +patch
Added file: http://bugs.python.org/file36409/timeit_global_arg.patch

___
Python tracker 

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

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

[Steve Dower]

Steve Dower added the comment:

There is other work going on that will make the patches unnecessary. One 
problem is that vcvarsall.bat isn't where msvc9compiler.py is looking, which 
can be fixed with monkey patching in setup.py or in setuptools. The other 
problem is that VC9 is hard to get hold of these days. I'm working on both 
problems and dealing with the big-company-inertia problem.

For 3.5 I'll update msvc9compiler.py as part of my VC14 support. 3.4 (and 3.5 
in the meantime) don't need to be updated as the easiest way to get VC10 is 
still as part of VS 2010. However, when the VS 2010 download is removed then 
things will become more difficult.

In general, I think we're better off helping package developers make 
builds/wheels than we are helping users to get the compiler. Windows just 
doesn't have enough platform incompatibilities to make it worthwhile.

--

___
Python tracker 

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

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

[Mark Lawrence]

Mark Lawrence added the comment:

I'm assuming that the 2.7 patch is still valid but have no idea whether or not 
any work is needed on 3.4 or 3.5.

--
nosy: +BreamoreBoy, zach.ware
versions: +Python 3.5 -Python 3.2, Python 3.3

___
Python tracker 

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

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

[Brian Curtin]

Changes by Brian Curtin :


--
nosy:  -brian.curtin

___
Python tracker 

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

[issue7951] Should str.format allow negative indexes when used for __getitem__ access?

[Mark Lawrence]

Mark Lawrence added the comment:

msg216038 suggests three options for the doc patch, does anybody have any 
preference or a better alternative?

--
nosy: +BreamoreBoy

___
Python tracker 

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

[issue21163] asyncio doesn't warn if a task is destroyed during its execution

[Marco Paolini]

Marco Paolini added the comment:

Submitted a first stab at #2. Let me know what you think.

If this works we'll have to remove the test_gc_pending test and then maybe even 
the code that now logs errors when a pending task is gc'ed

--
Added file: http://bugs.python.org/file36408/issue_22163_patch_0.diff

___
Python tracker 

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

[issue21041] pathlib.PurePath.parents rejects negative indexes

[Akira Li]

Akira Li added the comment:

> #7951 has an interesting debate on negative indexes that is possibly 
> applicable here.

Mark could you point to a message that explains why p.parents[-2] is worse
than p.parents[len(p.parents)-2]?

--

___
Python tracker 

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

[issue22225] Add SQLite support to http.cookiejar

[Demian Brecht]

New submission from Demian Brecht:

This is a proposal for adding SQLite support to http.cookiejar. I've been 
working on an implementation for MozillaSQLiteCookieJar and 
GoogleSQLiteCookieJar (initial patch will likely only include Mozilla) but 
wanted to make sure that the addition has buy-in before I continue work on it 
within the stdlib.

--
components: Library (Lib)
messages: 225502
nosy: demian.brecht
priority: normal
severity: normal
status: open
title: Add SQLite support to http.cookiejar
type: enhancement
versions: Python 3.5

___
Python tracker 

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

[issue22197] Allow better verbosity / output control in test cases

[Demian Brecht]

Changes by Demian Brecht :


--
nosy: +demian.brecht

___
Python tracker 

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

[issue21308] PEP 466: backport ssl changes

[Alex Gaynor]

Alex Gaynor added the comment:

Thanks for testing this out Robert! The attached patch fixes the error you saw.

--
Added file: http://bugs.python.org/file36407/ssl-backport.diff

___
Python tracker 

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

[issue21163] asyncio doesn't warn if a task is destroyed during its execution

[Marco Paolini]

Marco Paolini added the comment:

> So you are changing your mind and withdrawing your option #1.

I think option #1 (tell users to keep strong refs to tasks) is
OK but option #2 is better.

Yes, I changed my mind ;)

--

___
Python tracker 

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

[issue21163] asyncio doesn't warn if a task is destroyed during its execution

[Guido van Rossum]

Guido van Rossum added the comment:

So you are changing your mind and withdrawing your option #1.

I don't have the time to really dig deeply into the example app and what's
going on. If you want to help, you can try to come up with a patch (and it
should have good unit tests).

I'll be on vacation most of this week.

On Mon, Aug 18, 2014 at 9:17 AM, Marco Paolini 
wrote:

>
> Marco Paolini added the comment:
>
> Asking the user to manage strong refs is just passing the potential
> leak issue outside of the standard library. It doesn't really solve
> anything.
>
> If the user gets the strong refs wrong he can either lose tasks or
> leak memory.
>
> If the standard library gets it right, both issues are avoided.
>
> > I'm all in favor of documenting that you must keep a strong reference to
> a
> > task that you want to keep alive. I'm not keen on automatically keep all
> > tasks alive, that might exacerbate leaks (which are by definition hard to
> find) in existing programs.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue21163] asyncio doesn't warn if a task is destroyed during its execution

[Marco Paolini]

Marco Paolini added the comment:

Asking the user to manage strong refs is just passing the potential 
leak issue outside of the standard library. It doesn't really solve anything.

If the user gets the strong refs wrong he can either lose tasks or 
leak memory.

If the standard library gets it right, both issues are avoided.

> I'm all in favor of documenting that you must keep a strong reference to a
> task that you want to keep alive. I'm not keen on automatically keep all
> tasks alive, that might exacerbate leaks (which are by definition hard to
find) in existing programs.

--

___
Python tracker 

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

[issue21163] asyncio doesn't warn if a task is destroyed during its execution

[Guido van Rossum]

Guido van Rossum added the comment:

I'm all in favor of documenting that you must keep a strong reference to a
task that you want to keep alive. I'm not keen on automatically keep all
tasks alive, that might exacerbate leaks (which are by definition hard to
find) in existing programs.

On Mon, Aug 18, 2014 at 7:20 AM, Marco Paolini 
wrote:

>
> Marco Paolini added the comment:
>
> I finally wrapped my head around this. I wrote a (simpler) script to get a
> better picture.
>
> What happens
> -
>
> When a consumer task is first istantiated, the loop holds a strong
> reference to it (_ready)
>
> Later on, as the loop starts, the consumer task is yielded and it waits on
> an unreachable future. The last strong ref to it is lost (loop._ready).
>
> It is not collected immediately because it just created a reference loop
> (task -> coroutine -> stack -> future -> task) that will be broken only at
> task completion.
>
> gc.collect() called *before* the tasks are ever run has the weird side
> effect of moving the automatic gc collection forward in time.
> Automatic gc triggers after a few (but not all) consumers have become
> unreachable, depending on how many instructions were executed before
> running the loop.
>
> gc.collect() called after all the consumers are waiting on the unreachable
> future reaps all consumer tasks as expected. No bug in garbage collection.
>
> Yielding from asyncio.sleep() prevents the consumers from being
> collected: it creates a strong ref to the future in the loop.
> I suspect also all network-related asyncio coroutines behave this way.
>
> Summing up: Tasks that have no strong refs may be garbage collected
> unexpectedly or not at all, depending on which future they yield to. It is
> very difficult to debug and undestand why these tasks disappear.
>
> Side note: the patches submitted and merged in this issue do emit the
> relevant warnings when PYTHONASYNCIODEBUG is set. This is very useful.
>
> Proposed enhanchements
> --
>
> 1. Document that you should always keep strong refs to tasks or to
> futures/coroutines the tasks yields from. This knowledge is currently
> passed around the brave asyncio users like oral tradition.
>
> 2. Alternatively, keep strong references to all futures that make it
> through Task._step. We are already keeping strong refs to *some* of the
> asyncio builtin coroutines (`asyncio.sleep` is one of those). Also, we do
> keep strong references to tasks that are ready to be run (the ones that
> simply `yield` or the ones that have not started yet)
>
> If you also think 1. or 2. are neeed, let me know and I'll try cook a
> patch.
>
> Sorry for the noise
>
> --
> nosy: +mpaolini
> Added file: http://bugs.python.org/file36405/test2.py
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue20042] Python Launcher, Windows, fails on scripts w/ non-latin names

[Steve Dower]

Steve Dower added the comment:

It should be fixable. In general, Unicode in the console is fine, but the CRT 
doesn't handle it well (as shown by the _setmode extension being able to fix 
it).

The 'correct' fix for Unicode in the console is at 
http://www.siao2.com/2010/04/07/9989346.aspx and it basically comes down to 
"use the Windows API and not the CRT". It's certainly fixable here, though the 
general fix for Python itself is more difficult because we want/need to expose 
the bytes interface as well (that said, #1602 seems to have a good fix right 
now that just happens to be easily distributable as pure Python code, so 
there's little motivation to merge it in, especially since it will break 
back-compat).

I don't know entirely whether _setmode is a correct fix here, or if the 
attached patch is sufficient, but it can be fixed.

--

___
Python tracker 

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

[issue22224] docs.python.org is prone to political blocking in Russia

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

It looks like the IP address is being used by some viruses/trojans:

https://www.virustotal.com/en/ip-address/185.31.17.175/information/

It may help using e.g. b.global-ssl.fastly.net as CNAME for docs.python.org 
(e.g. by adding it to the /etc/hosts).

--
nosy: +lemburg

___
Python tracker 

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

[issue22214] Tkinter: Don't stringify callbacks arguments

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> The patch appears to change it to 2 in tkinter/__init__.py.

This is for development only. You can apply the patch and test how new mode 
affects IDLE or other applications.

> One thing slightly puzzles me: the current PythonCmd is used in a call to
> Tcl_CreateCommand.  (Since the latter is not in _tkinter, I presume it is
> 'imported' in one of the includes.)  The new PythonObjCmd is passed to
> Tcl_CreateObjCommand. Does that already exist, just waiting for us to add
> PythonObjCmd?

All Tcl_* functions are Tcl C API functions. Old functions work with strings 
(char *). Modern functions (have "Obj" in a name) work with specialized Tcl 
objects (Tcl_Obj *).

> I near as I can tell, the only differences between PythonCmd and
> PythonOjbCmd are /argv/objv/ and the following.
> 
>   PyObject *s = unicodeFromTclString(argv[i + 1]);
>   PyObject *s = FromObj(data->self, objv[i + 1]);
> 
> I think I would make the name substitution either in both or neither.  It
> would be nice to reuse the rest of the code.

I'm not sure that I understand all you mean, but in updated patch the common 
code are extracted to separate function.

--
Added file: http://bugs.python.org/file36406/tkinter_obj_cmd_2.patch

___
Python tracker 

___diff -r e5f78085499e Lib/test/test_tcl.py
--- a/Lib/test/test_tcl.py  Mon Aug 18 17:48:15 2014 +0300
+++ b/Lib/test/test_tcl.py  Mon Aug 18 17:51:59 2014 +0300
@@ -427,22 +427,29 @@
 return arg
 self.interp.createcommand('testfunc', testfunc)
 self.addCleanup(self.interp.tk.deletecommand, 'testfunc')
-def check(value, expected=None, *, eq=self.assertEqual):
-if expected is None:
-expected = value
+def check(value, arg1=None, arg2=None, *, eq=self.assertEqual):
+expected = value
+if self.wantobjects >= 2:
+if arg2 is not None:
+expected = arg2
+expected_type = type(expected)
+else:
+if arg1 is not None:
+expected = arg1
+expected_type = str
 nonlocal result
 result = None
 r = self.interp.call('testfunc', value)
-self.assertIsInstance(result, str)
+self.assertIsInstance(result, expected_type)
 eq(result, expected)
-self.assertIsInstance(r, str)
+self.assertIsInstance(r, expected_type)
 eq(r, expected)
 def float_eq(actual, expected):
 self.assertAlmostEqual(float(actual), expected,
delta=abs(expected) * 1e-10)
 
-check(True, '1')
-check(False, '0')
+check(True, '1', 1)
+check(False, '0', 0)
 check('string')
 check('string\xbd')
 check('string\u20ac')
@@ -465,9 +472,13 @@
 check(float('inf'), eq=float_eq)
 check(-float('inf'), eq=float_eq)
 # XXX NaN representation can be not parsable by float()
-check((), '')
-check((1, (2,), (3, 4), '5 6', ()), '1 2 {3 4} {5 6} {}')
-check([1, [2,], [3, 4], '5 6', []], '1 2 {3 4} {5 6} {}')
+check((), '', '')
+check((1, (2,), (3, 4), '5 6', ()),
+  '1 2 {3 4} {5 6} {}',
+  (1, (2,), (3, 4), '5 6', ''))
+check([1, [2,], [3, 4], '5 6', []],
+  '1 2 {3 4} {5 6} {}',
+  (1, (2,), (3, 4), '5 6', ''))
 
 def test_splitlist(self):
 splitlist = self.interp.tk.splitlist
diff -r e5f78085499e Lib/tkinter/__init__.py
--- a/Lib/tkinter/__init__.py   Mon Aug 18 17:48:15 2014 +0300
+++ b/Lib/tkinter/__init__.py   Mon Aug 18 17:51:59 2014 +0300
@@ -41,7 +41,7 @@
 import re
 
 
-wantobjects = 1
+wantobjects = 2
 
 TkVersion = float(_tkinter.TK_VERSION)
 TclVersion = float(_tkinter.TCL_VERSION)
diff -r e5f78085499e Modules/_tkinter.c
--- a/Modules/_tkinter.cMon Aug 18 17:48:15 2014 +0300
+++ b/Modules/_tkinter.cMon Aug 18 17:51:59 2014 +0300
@@ -1967,6 +1967,32 @@
 return TCL_ERROR;
 }
 
+static int
+PythonCmd_Call(Tcl_Interp *interp, PyObject *func, PyObject *args)
+{
+Tcl_Obj *obj_res;
+PyObject *res = PyEval_CallObject(func, args);
+Py_DECREF(args);
+
+if (res == NULL)
+return PythonCmd_Error(interp);
+
+obj_res = AsObj(res);
+if (obj_res == NULL) {
+Py_DECREF(res);
+return PythonCmd_Error(interp);
+}
+else {
+Tcl_SetObjResult(interp, obj_res);
+}
+
+Py_DECREF(res);
+
+LEAVE_PYTHON
+
+return TCL_OK;
+}
+
 /* This is the Tcl command that acts as a wrapper for Python
  * function or method.
  */
@@ -1974,49 +2000,52 @@
 PythonCmd(ClientData clientData, Tcl_Interp *interp, int argc, const char 
*argv[])
 {
 PythonCmd_ClientData *data = (PythonCmd_Client

[issue21163] asyncio doesn't warn if a task is destroyed during its execution

[Marco Paolini]

Marco Paolini added the comment:

I finally wrapped my head around this. I wrote a (simpler) script to get a 
better picture.

What happens
-

When a consumer task is first istantiated, the loop holds a strong reference to 
it (_ready)

Later on, as the loop starts, the consumer task is yielded and it waits on an 
unreachable future. The last strong ref to it is lost (loop._ready).

It is not collected immediately because it just created a reference loop
(task -> coroutine -> stack -> future -> task) that will be broken only at task 
completion.

gc.collect() called *before* the tasks are ever run has the weird side effect 
of moving the automatic gc collection forward in time.
Automatic gc triggers after a few (but not all) consumers have become 
unreachable, depending on how many instructions were executed before running 
the loop.

gc.collect() called after all the consumers are waiting on the unreachable 
future reaps all consumer tasks as expected. No bug in garbage collection.

Yielding from asyncio.sleep() prevents the consumers from being 
collected: it creates a strong ref to the future in the loop.
I suspect also all network-related asyncio coroutines behave this way.

Summing up: Tasks that have no strong refs may be garbage collected 
unexpectedly or not at all, depending on which future they yield to. It is very 
difficult to debug and undestand why these tasks disappear.
 
Side note: the patches submitted and merged in this issue do emit the relevant 
warnings when PYTHONASYNCIODEBUG is set. This is very useful.

Proposed enhanchements
--

1. Document that you should always keep strong refs to tasks or to 
futures/coroutines the tasks yields from. This knowledge is currently passed 
around the brave asyncio users like oral tradition.

2. Alternatively, keep strong references to all futures that make it through 
Task._step. We are already keeping strong refs to *some* of the asyncio builtin 
coroutines (`asyncio.sleep` is one of those). Also, we do keep strong 
references to tasks that are ready to be run (the ones that simply `yield` or 
the ones that have not started yet)

If you also think 1. or 2. are neeed, let me know and I'll try cook a patch.

Sorry for the noise

--
nosy: +mpaolini
Added file: http://bugs.python.org/file36405/test2.py

___
Python tracker 

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

[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program

[Brian Curtin]

Changes by Brian Curtin :


--
nosy:  -brian.curtin

___
Python tracker 

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

[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program

[Bastien Montagne]

Changes by Bastien Montagne :


--
nosy: +mont29

___
Python tracker 

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

[issue22224] docs.python.org is prone to political blocking in Russia

[Georg Brandl]

Georg Brandl added the comment:

Not much more we can do from here.

--
nosy: +georg.brandl
resolution:  -> third party
status: open -> closed

___
Python tracker 

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

[issue12067] Doc: remove errors about mixed-type comparisons.

[Berker Peksag]

Changes by Berker Peksag :


--
stage: needs patch -> patch review

___
Python tracker 

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

[issue22224] docs.python.org is prone to political blocking in Russia

[Donald Stufft]

Donald Stufft added the comment:

Just a FYI, I've let Fastly know about this.

--
nosy: +dstufft

___
Python tracker 

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

[issue22115] Add new methods to trace Tkinter variables

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> "list or tuple" (of such strings.)  Can we say 'sequence' (or even set or
> iterable) or is the requirement specifically tuple or list?

No. The call() method accepted only tuples, and since issue21525 it now 
supports lists.

> Does tk call the traceback function with any args it supplies(other than
> those passed in)? (In other words, is the callback affected by the #22214
> proposal?)

Tcl calls the traceback function with stringified arguments. No, this is not 
affected by the #22214 proposal. And only types which are supported by Tkinter 
(int, bool, float, str, bytes, tuple, list, Tcl_Obj) are allowed. But this 
behavior can be changed in future versions of Tcl..

> "Should be same as were specified in trace_add()." Is a subset not allowed
> to remove a subset of the registrations currently allowed?  Does trying to
> delete other modes raise TclError?  If both are so, I would say something
> like "Must be a subset of current trace modes.".

Unfortunately both are no. If you pass wrong mode, trace_remove() will 
silently finished, but next attempt to call a callback will raise TclError 
(because a command is already deleted). Fixed in next patch and should be 
backported.

> That aside, remembering and passing the
> arguments back seems like a bizarre requirement that makes not sense. What
> happens if one does not, or gets it wrong?

Same bad things as when pass wrong mode.

> It the args are really required
> exactly, then is seems that trace_add should return (cbname,) + args to be
> passed back to trace_remove as cbname_args.

Looks good.

> Alternatively, could *args (and mode) be retrieved from trace_info?

You can retrieve mode, cbname and (stringified) args from trace_info. Currently 
following code removes all callbacks from variable:

for mode, cbname_args in v.trace_info():
v.trace_remove(mode, *cbname_args)

With next patch '*' is not needed.

Thank you for the review. Updated patch addresses all your comments.

--
Added file: http://bugs.python.org/file36404/tkinter_trace_variable_4.patch

___
Python tracker 

___diff -r 66c7f30fe8c7 Lib/tkinter/__init__.py
--- a/Lib/tkinter/__init__.py   Sun Aug 17 23:01:33 2014 -0500
+++ b/Lib/tkinter/__init__.py   Mon Aug 18 15:37:33 2014 +0300
@@ -242,16 +242,9 @@
 def get(self):
 """Return value of variable."""
 return self._tk.globalgetvar(self._name)
-def trace_variable(self, mode, callback):
-"""Define a trace callback for the variable.
-
-MODE is one of "r", "w", "u" for read, write, undefine.
-CALLBACK must be a function which is called when
-the variable is read, written or undefined.
-
-Return the name of the callback.
-"""
-f = CallWrapper(callback, None, self).__call__
+
+def _register(self, callback):
+f = CallWrapper(callback, None, self._root).__call__
 cbname = repr(id(f))
 try:
 callback = callback.__func__
@@ -265,6 +258,65 @@
 if self._tclCommands is None:
 self._tclCommands = []
 self._tclCommands.append(cbname)
+return cbname
+
+def trace_add(self, mode, callback, *args):
+"""Define a trace callback for the variable.
+
+Mode is one of "array", "read", "write", "unset", or a list or tuple
+of such strings.
+Callback must be a function which is called when the variable is
+accessed or modified via the array command, read, written or unset.
+Additional arguments are passed to the traceback call.
+
+Return a tuple containg the name of the callback and additional
+arguments.
+"""
+cbname = self._register(callback)
+self._tk.call('trace', 'add', 'variable',
+  self._name, mode, (cbname,) + args)
+return (cbname,) + args
+
+def trace_remove(self, mode, cbname_args):
+"""Delete the trace callback for a variable.
+
+Mode is one of "array", "read", "write", "unset" or a list or tuple
+of such strings.  Must be same as were specified in trace_add().
+Cbname_args must be a tuple returned from trace_add().
+"""
+self._tk.call('trace', 'remove', 'variable',
+  self._name, mode, cbname_args)
+cbname = cbname_args[0]
+for m, ca in self.trace_info():
+if ca[0] == cbname:
+break
+else:
+self._tk.deletecommand(cbname)
+try:
+self._tclCommands.remove(cbname)
+except ValueError:
+pass
+
+def trace_info(self):
+"""Return all trace callback information."""
+splitlist = self._tk.splitlist
+return [(splitlist(k), splitlist(v)) for k, v in map(splitlist,
+splitlist(self._tk.call('trace', 'info', 'variabl

[issue21308] PEP 466: backport ssl changes

[Robert Kuska]

Robert Kuska added the comment:

Hi everyone,

I went ahead and I've applied ssl-backport.diff (alex, 2014-08-07 18:49) patch 
into Python 2.7.8 on Fedora Rawhide (currently only scratch build).

My report:
Firstly, I've encountered seg fault, I fixed this with patch from 
http://bugs.python.org/issue22023

Next issue was/is distro specific, there is disabled SSLv2 protocol when 
SSLv23_method is used[0]. However python3 builds fine[1]:

In test_ssl.py:test_protocol_sslv23 when calling
try_protocol_combo(ssl.PROTOCOL_SSLv23, ssl.PROTOCOL_SSLv2, True)
this will raise an OSError on python3 but this error is caught by test.

In python 2 this will raise a socket.error[2] instead, but test_protocol_sslv23 
is catching ssl.SSLError, shouldn't be that changed to socket.error so both 
python2 and python3 behave the same? 


[0] SSLv23 
http://pkgs.fedoraproject.org/cgit/openssl.git/tree/openssl-1.0.1h-disable-sslv2v3.patch
[1] Python3 build 
https://kojipkgs.fedoraproject.org//work/tasks/9993/733/build.log (search 
for test_protocol_sslv23)
[2] Python2 build 
https://kojipkgs.fedoraproject.org//work/tasks/9367/7399367/build.log (search 
for test_protocol_sslv23)

--
nosy: +rkuska

___
Python tracker 

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

[issue22224] docs.python.org is prone to political blocking in Russia

[Christian Heimes]

Christian Heimes added the comment:

Dmitry Chestnykh has pointed me to https://antizapret.info/site.php?id=5903

--
nosy: +christian.heimes

___
Python tracker 

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

[issue22224] docs.python.org is prone to political blocking in Russia

[Alexander Patrakov]

New submission from Alexander Patrakov:

I could not access http://docs.python.org/ from work today. Upon investigation, 
it appears that the ISP has blocked all sites on the IP address 185.31.17.175, 
because of the court order unrelated to docs.python.org. Many other ISPs in 
Russia also don't know any methods of site blocking except by IP address.

Even if the bad site removes the offending materials, the situation is doomed 
to repeat itself in the future.

To avoid this, please obtain an IPv4 or IPv6 address for docs.python.org that 
is not shared with any site not controlled by PSF.

--
assignee: docs@python
components: Documentation
messages: 225487
nosy: Alexander.Patrakov, docs@python
priority: normal
severity: normal
status: open
title: docs.python.org is prone to political blocking in Russia
type: behavior

___
Python tracker 

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

[issue19883] Integer overflow in zipimport.c

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
versions: +Python 2.7, Python 3.5 -Python 3.3

___
Python tracker 

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

[issue20797] zipfile.extractall should accept bytes path as parameter

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka
stage:  -> needs patch
versions: +Python 3.5 -Python 3.3

___
Python tracker 

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

[issue20912] [zipfile.py]: Make zip directory attributes more friendly for MS-Windows

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee:  -> serhiy.storchaka

___
Python tracker 

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

[issue20912] [zipfile.py]: Make zip directory attributes more friendly for MS-Windows

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Looks good. But writestr() should be updated too. Some users use it to add a 
directory to ZIP file. Here is a patch with tests. It also changes attributes 
of regular file added by writestr().

--
stage: test needed -> patch review
versions:  -Python 3.3
Added file: http://bugs.python.org/file36403/zipfile_dirattrs.patch

___
Python tracker 

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

[issue22223] argparse not including '--' arguments in previous optional REMAINDER argument

[Jurko Gospodnetić]

Jurko Gospodnetić added the comment:

Might be related to the following issues:

http://bugs.python.org/issue9571
http://bugs.python.org/issue13922

--

___
Python tracker 

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

[issue22223] argparse not including '--' arguments in previous optional REMAINDER argument

[Jurko Gospodnetić]

New submission from Jurko Gospodnetić:

If you have an optional nargs=argparse.REMAINDER argument defined
then, if specified, its value should contain all the remaining command-line 
content. However, it seems that value does not include later '--' arguments.

For example, the following works as expected:

import argparse
parser = argparse.ArgumentParser(prog="PROG")
parser.add_argument("--args", nargs=argparse.REMAINDER)
args = parser.parse_args("--args cmd --arg1 XX ZZ".split())
assert args.args == ["cmd", "--arg1", "XX", "ZZ"]

But the following fails with
'PROG: error: unrecognized arguments: -- ZZ':

import argparse
parser = argparse.ArgumentParser(prog="PROG")
parser.add_argument("--args", nargs=argparse.REMAINDER)
args = parser.parse_args("--args cmd --arg1 XX -- ZZ".split())
assert args.args == ["cmd", "--arg1", "XX", "--", "ZZ"]


Note that the same code works as expected when using a
positional nargs=argparse.REMAINDER arguments:

import argparse
parser = argparse.ArgumentParser(prog="PROG")
parser.add_argument("args", nargs=argparse.REMAINDER)
args = parser.parse_args("args cmd --arg1 XX ZZ".split())
assert args.args == ["cmd", "--arg1", "XX", "ZZ"]
args = parser.parse_args("args cmd --arg1 XX -- ZZ".split())
assert args.args == ["cmd", "--arg1", "XX", "--", "ZZ"]

But that, of course, does not allow us to have the args value
start with something like "--blah" that looks like an optional
argument.


Hope this helps.

Best regards,
  Jurko Gospodnetić

--
components: Library (Lib)
messages: 225484
nosy: Jurko.Gospodnetić
priority: normal
severity: normal
status: open
title: argparse not including '--' arguments in previous optional REMAINDER 
argument
type: behavior
versions: Python 2.7, Python 3.4

___
Python tracker 

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