[issue24621] zipfile.BadZipFile: File is not a zip file

Changes by Ronald Oussoren : -- nosy: +ronaldoussoren ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://m

[issue24632] Improve documentation about __main__.py

Ezio Melotti added the comment: > I think this is due to PEP 420 Namespace Packages. It works on Python 2 too: $ ls execdir/ foo.py __main__.py $ cat execdir/foo.py print("foo imported") $ cat execdir/__main__.py import foo; print("main imported") $ python execdir/ foo imported main imported

[issue24621] zipfile.BadZipFile: File is not a zip file

Serhiy Storchaka added the comment: unzip can't proceed this file too. $ unzip -v not_working.zip Archive: not_working.zip End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive. In the latter case the central

[issue24632] Improve documentation about __main__.py

Davide Rizzo added the comment: As far as I understand, assuming dir/ contains a __main__.py file $ python dir is equivalent to $ python dir/__main__.py in that it's behaviourally nothing more than executing a script in that dir and setting sys.path accordingly. This is the same in Python 2

[issue24642] Will there be an MSI installer?

New submission from Alex Walters: I use the *.msi installers for python to automate deployment of... an absurd number of python installations. I have been able to do this relatively easily, as the Windows installer didn't change much between 2.6 and 3.4 (possibly much longer than that, but I

[issue23319] Missing SWAP_INT in I_set_sw

Matthieu Gautier added the comment: The bug is also present in Python 2.7. Is it possible to backport this fix ? -- versions: +Python 2.7 ___ Python tracker ___

[issue17359] Mention "__main__.py" explicitly in command line docs

Ezio Melotti added the comment: See also #24632. -- nosy: +ezio.melotti type: -> enhancement ___ Python tracker ___ ___ Python-bugs-l

[issue24642] Will there be an MSI installer?

Changes by STINNER Victor : -- components: +Installation ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:

[issue24642] Will there be an MSI installer?

Matthew Barnett added the comment: There's an "executable installer"; it's a .exe instead of a .msi. -- nosy: +mrabarnett ___ Python tracker ___ _

[issue24642] Will there be an MSI installer?

Steve Dower added the comment: Also have a read of https://docs.python.org/3.5/using/windows.html and see whether it will suit your needs. I need to hear feedback on this, as we're running short on time to make drastic changes if they are necessary. I too automate installation of absurd number

[issue23247] Crash in the reset() method of StreamWriter of CJK codecs

Martin Panter added the comment: Aaron: Your version of the fix immediately returns None, while Victor’s tries to encode an empty string (if I understand it correctly). I imagine this shortcut could be slightly more efficient, but is it always correct? In any case, Aaron’s test looks okay to m

[issue23247] Crash in the reset() method of StreamWriter of CJK codecs

STINNER Victor added the comment: > Aaron: Your version of the fix immediately returns None, while Victor’s tries > to encode an empty string (if I understand it correctly). Aaron patch is better. I misunderstood the code. reset() always return None, the empty string is unused in my patch. fi

[issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h

New submission from James Salter: For python 3.5, PC/pyconfig.h contains the following for vs2015 support: /* VS 2015 defines these names with a leading underscore */ #if _MSC_VER >= 1900 #define timezone _timezone #define daylight _daylight #define tzname _tzname #endif This breaks any python

[issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h

Zachary Ware added the comment: I suppose we'll have to resort to #ifndef _Py_timezone #if _MSC_VER >= 1900 #define _Py_timezone _timezone #else #define _Py_timezone timezone #endif #endif ... -- components: +Build, Windows -Extension Modules nosy: +paul.moore, steve.dower, tim.golden,

[issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h

Steve Dower added the comment: Or we could define _timezone on those platforms that don't have the underscore. I'm not hugely fussed either way. We need to fix this though. -- ___ Python tracker __

[issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h

STINNER Victor added the comment: Can't we move the #define only in .c files where they are needed? Or in a private header (not included by Python.h)? -- nosy: +haypo ___ Python tracker ___

[issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h

Steve Dower added the comment: That's probably an option, though it would break extensions that use `timezone` expecting it to work. But it seems like any change is going to cause that. I prefer defining _Py_timezone, since at least we can offer something that is portable for all Python 3.5 pl

[issue24644] --help for runnable stdlib modules

New submission from Antony Lee: Support for python -m [-h|--help] is a bit patchy right now: $ python -mpdb -h usage: pdb.py [-c command] ... pyfile [arg] ... $ python -mpdb --help Traceback (most recent call last): File "/usr/lib/python3.4/runpy.py", line 170, in _run_module_as_main "_

[issue24630] null pointer dereference in `load_newobj_ex`

Brad Larsen added the comment: Yeah, this appears to be fixed along with #24552. -- status: open -> pending ___ Python tracker ___ ___

[issue23247] Crash in the reset() method of StreamWriter of CJK codecs

Aaron Hill added the comment: I've added a test case to exercise reset() -- Added file: http://bugs.python.org/file39934/fix-multibytecodec-segfault-with-test.patch ___ Python tracker _

[issue24630] null pointer dereference in `load_newobj_ex`

Changes by Serhiy Storchaka : -- resolution: -> out of date stage: -> resolved status: pending -> closed ___ Python tracker ___ ___

[issue24644] --help for runnable stdlib modules

R. David Murray added the comment: Please open individual issues to address individual modules that you would like to contribute to improving. Adding/fixing help is often best done by rewriting the argument parsing...contributions have been made to improve several modules already. In most ca

[issue24645] logging.handlers.QueueHandler should not lock when handling a record

New submission from Justin Bronder: The Queue backing the QueueHandler is already sufficiently locking for thread-safety. This isn't a huge issue, but the QueueHandler is a very nice built-in which could be used to work around a deadlock I've encountered several times. In brief, functions wh

[issue24646] Python accepts SSL certificate that should be rejected on OSX

New submission from Jussi Pakkanen: Create a dummy certificate and build an ssl context like this: ctx = ssl.SSLContext(ssl.PROTOCOL_TLSv1) ctx.verify_mode = ssl.CERT_REQUIRED ctx.load_verify_locations(cadata=dummy_certificate) Then try to connect to a public service like this: u = urllib.requ

[issue24646] Python accepts SSL certificate that should be rejected on OSX

Donald Stufft added the comment: I think the only way to actually fix this, is to stop using the OpenSSL provided by OSX. -- nosy: +dstufft ___ Python tracker ___ __

[issue24567] random.choice IndexError due to double-rounding

Serhiy Storchaka added the comment: See the attached timings for sample(). Patched sample2 is at worst 4% slower than original sample, and optimized sample3 is between sample and sample2. In any case the difference is pretty small, so I'm good with Raymond's variant if it looks better for him

[issue24645] logging.handlers.QueueHandler should not lock when handling a record

R. David Murray added the comment: Can you expand on the deadlock? Are you saying that the "extra" locking is causing the deadlock? -- nosy: +r.david.murray, vinay.sajip versions: -Python 3.2, Python 3.3 ___ Python tracker

[issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h

STINNER Victor added the comment: > That's probably an option, though it would break extensions that use > `timezone` expecting it to work. Hum, I don't remember that the "timezone" symbol of part of the Python public API. Which extensions? -- ___ P

[issue23247] Crash in the reset() method of StreamWriter of CJK codecs

Roundup Robot added the comment: New changeset 35a6fe0e2b27 by Victor Stinner in branch '3.4': Closes #23247: Fix a crash in the StreamWriter.reset() of CJK codecs https://hg.python.org/cpython/rev/35a6fe0e2b27 -- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved st

[issue23247] Crash in the reset() method of StreamWriter of CJK codecs

STINNER Victor added the comment: @Aaron Hill: Thanks for your patch! I only kept the minimal test of your patch. If you want to enhance the test suite, you may write new test to test the behaviour of reset(). I prefer to only commit the minimum patch. @Martin: Thanks for your report. The issu

[issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h

Steve Dower added the comment: It's not, but "#include " in any extension will make it available for you, so it's very likely that extensions have simply used it without adding their own conditional compilation for the various interpretations of whether timezone is standard or not. Bit of a s

[issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h

STINNER Victor added the comment: For me, it's not the responsability of python.h to ensure that the timezone symbol is available. -- ___ Python tracker ___ _

[issue23601] use small object allocator for dict key storage

Mark Shannon added the comment: +1 from me. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h

Steve Dower added the comment: Agreed. However, I also don't want extensions to stop building because of a change we make. But since that's inevitable here, let's go with Zach's original suggestion and use a name that won't conflict. (IIRC, I originally put the #ifdefs in each file and was tol

[issue24647] Document argparse.REMAINDER as being equal to "..."

New submission from Antony Lee: Currently the argparse docs mention the special values "+", "*" and "?" by their actual values instead of argparse.{ONE_OR_MORE,ZERO_OR_MORE,OPTIONAL}, but argparse.REMAINDER is mentioned as is. It seems easier to just use its actual value ("...") in the docs a

[issue23601] use small object allocator for dict key storage

Serhiy Storchaka added the comment: If use small object allocator for dict key storage, why not use it for dict value storage? -- ___ Python tracker ___

[issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h

Zachary Ware added the comment: > (IIRC, I originally put the #ifdefs in each file and was told to move > them to pyconfig.h...) Yeah, I think I did suggest that, to match what we do with hypot/_hypot for MSC 1600+. We should probably also change that one while fixing timezone, daylight, and

[issue24645] logging.handlers.QueueHandler should not lock when handling a record

Justin Bronder added the comment: On 16/07/15 20:03 +, R. David Murray wrote: > > R. David Murray added the comment: > > Can you expand on the deadlock? Are you saying that the "extra" locking is > causing the deadlock? > > -- > nosy: +r.david.murray, vinay.sajip > versions: -Py

[issue24648] Allocation of values array in split dicts should use small object allocator.

New submission from Mark Shannon: Issue 23601 advocates using the small object allocator for dict-keys objects and the results of tests are good. Using the small object allocator for dict value-arrays as well seems like the obvious next step. -- components: Interpreter Core keywords:

[issue23601] use small object allocator for dict key storage

Mark Shannon added the comment: Yes, but that shouldn't block this issue. I've opened issue 24648 instead. -- ___ Python tracker ___ _

[issue24645] logging.handlers.QueueHandler should not lock when handling a record

R. David Murray added the comment: I can't see doing io in __repr__ ever making sense, so I'm not sure this is a use case we care about. But Vinay might not have any objection to removing locking if it is redundant, so we'll see what he has to say. --

[issue24648] Allocation of values array in split dicts should use small object allocator.

STINNER Victor added the comment: If it's an optimization, we need benchmarks. We should also try to modify PyMem allocator to simply be an alias to PyObject allocator. I expect a little speedup. I'm not talking for the specific case of the dict type, but for all Python. -- nosy: +hay

[issue19918] PureWindowsPath.relative_to() is not case insensitive

Changes by Aaron Meurer : -- nosy: +Aaron Meurer ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue24642] Will there be an MSI installer?

Alex Walters added the comment: Related to the exe installer... /? lists only 4 options, none of which are useful in restricting the installation, or changing its location. -- ___ Python tracker __

[issue24642] Will there be an MSI installer?

Alex Walters added the comment: and...you already addressed that. Ignore previous. -- ___ Python tracker ___ ___ Python-bugs-list mai

[issue24649] python -mtrace --help is wrong

New submission from Antony Lee: While working on #24644, I noticed that the help for python -mtrace is quite wrong. $ python -mtrace --help Usage: /usr/lib/python3.4/trace.py [OPTIONS] [ARGS] Meta-options: --helpDisplay this help then exit. --version Output version

[issue24644] --help for runnable stdlib modules

Antony Lee added the comment: To be honest I don't really plan to contribute any patch on this specific issue right now, the CLI interface of e.g. trace has some other serious issues (see e.g. #24649) that I don't want to work out, and writing tests for the CLI are a pain too (also why I haven

[issue21238] unittest.mock.Mock should not allow you to use non-existent assert methods

John Allison added the comment: That probably IS a joke. Why not fix the underlying issue instead? -- nosy: +John Allison ___ Python tracker ___ _

[issue24645] logging.handlers.QueueHandler should not lock when handling a record

Vinay Sajip added the comment: I'm not sure I want to make a special case just to support what seems like a somewhat pathological use case (no offence intended). If you need this, there's no reason you couldn't subclass QueueHandler and override handle(), is there? -- ___

[issue24645] logging.handlers.QueueHandler should not lock when handling a record

Justin Bronder added the comment: On 16/07/15 23:21 +, Vinay Sajip wrote: > > Vinay Sajip added the comment: > > I'm not sure I want to make a special case just to support what seems like a > somewhat pathological use case (no offence intended). > > If you need this, there's no reason you

[issue24645] logging.handlers.QueueHandler should not lock when handling a record

Vinay Sajip added the comment: I agree the lock could be seen as redundant as there are no shared data structures used by the current implementation of the enqueue and prepare methods (which are called after the lock is acquired), but users could potentially override those methods in subclasse

[issue21750] mock_open data is visible only once for the life of the class

Changes by Berker Peksag : -- stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://m

[issue21750] mock_open data is visible only once for the life of the class

Berker Peksag added the comment: LGTM. A minor comment: +def test_mock_open_reuse_issue_21750(self): We can also add an assert to check the data is actually "data" (e.g. assertEqual(f1.read(), 'data')). -- stage: patch review -> commit review

[issue24650] Error in yield expression documentation

New submission from swanson: https://docs.python.org/3/reference/expressions.html in 6.2.9. Yield expressions end of 1st paragraph: "Using a yield expression in a function’s body causes that function to be a generator." NO! As the very next sentence explains, a generator is what's returned