[issue39244] multiprocessing.get_all_start_methods() wrong default on macOS
New submission from Stefan Holek : In Python 3.8 the default start method has changed from fork to spawn on macOS. https://docs.python.org/3/whatsnew/3.8.html#multiprocessing get_all_start_methods() says: "Returns a list of the supported start methods, the first of which is the default." https://docs.python.org/3/library/multiprocessing.html?highlight=finalize#multiprocessing.get_all_start_methods However, it appears to still return fork as default: Python 3.8.1 (default, Dec 22 2019, 03:45:23) [Clang 10.0.1 (clang-1001.0.46.4)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import multiprocessing >>> multiprocessing.get_all_start_methods() ['fork', 'spawn', 'forkserver'] >>> Thank you! -- components: Library (Lib), macOS messages: 359503 nosy: ned.deily, ronaldoussoren, stefanholek priority: normal severity: normal status: open title: multiprocessing.get_all_start_methods() wrong default on macOS type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue39244> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19647] unittest.TestSuite consumes tests
Stefan Holek added the comment: I have some complex test fixtures that I have written tests for, and one of them started to fail because it assumed that the suite would still be valid after having run. That said, I was able to work around the issue and if you don't care neither do I. ;-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19647 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19647] unittest.TestSuite consumes tests
New submission from Stefan Holek:
This test passed in Python = 3.3 but fails in 3.4:
def testTestSuiteConsumesTest(self):
class MyTestCase(unittest.TestCase):
def testMethod(self):
pass
test = MyTestCase('testMethod')
suite = unittest.TestSuite((test,))
result = unittest.TestResult()
self.assertEqual(next(iter(suite)), test)
suite.run(result)
self.assertEqual(next(iter(suite)), test)
The suite contains None after it has been run in Python 3.4.
--
components: Library (Lib)
messages: 203325
nosy: stefanholek
priority: normal
severity: normal
status: open
title: unittest.TestSuite consumes tests
type: behavior
versions: Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19647
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16310] zipfile: allow surrogates in filenames
Stefan Holek added the comment: It's possible to distribute Python packages with non-ASCII filenames. Well, it wasn't until very recently (distribute 0.6.29): https://bitbucket.org/tarek/distribute/issue/303/no-support-for-unicode-manifest-files Unless we are not talking about the same thing, which is possible. ;-) So yes, I have Latin-1 bytes on the filesystem, even though my locale is UTF-8. You system is not configured correctly. If you would like to distribute such invalid filename, how do you plan to access it on other platforms where the filename is decoded differently? It would be safer to build your project on a well configured system. This was done on purpose, to test how Python fares. Such files can easily come into existence, e.g. when cloning a Git repo created on a different system. I am not after correct ZIP files in this case, I am after Python not raising UnicodeErrors when it is supposed to a) support non-ASCII module names and b) support surrogates. python setup.py sdist --formats=gztar - works python setup.py sdist --formats=zip - UnicodeError If I am the only one to think this is wrong, then so be it. Our current workaround is to disallow surrogates in the manifest. /me shrugs. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16310 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16310] zipfile: allow surrogates in filenames
Stefan Holek added the comment: What we are trying to do is make distribute work with non-ASCII filenames, and this is one of the things we ran into. Fact 1: Filenames are bytes, whether you like it or not. Treating them as strings is going to give you more trouble than dragging the bytes along. Fact 2: Surrogates are Python 3's way of dealing with bytes. Fact 3: What follows is that surrogates must be supported wherever Python 3 deals with filenames. Fact 4: This is a *bug* since Python breaks its own rules here (I have removed the enhancement marker). The issue is not what ZIP can do, but what Python 3 *must* do. Creating a potentially non-standard ZIP file is fine, exploding in the user's face is not. -- type: enhancement - versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16310 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16310] zipfile: allow surrogates in filenames
New submission from Stefan Holek:
Please allow for surrogates in the zipfile module like it was done for tarfile
in #8390.
Currently zipfile breaks when encountering surrogates:
Traceback (most recent call last):
File /usr/local/python3.3/lib/python3.3/zipfile.py, line 392, in
_encodeFilenameFlags
return self.filename.encode('ascii'), self.flag_bits
UnicodeEncodeError: 'ascii' codec can't encode character '\udcfc' in position
21: ordinal not in range(128)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File setup.py, line 20, in module
'setuptools',
File /usr/local/python3.3/lib/python3.3/distutils/core.py, line 148, in
setup
dist.run_commands()
File /usr/local/python3.3/lib/python3.3/distutils/dist.py, line 917, in
run_commands
self.run_command(cmd)
File /usr/local/python3.3/lib/python3.3/distutils/dist.py, line 936, in
run_command
cmd_obj.run()
File
/home/stefan/sandbox/setuptools-git/lib/python3.3/site-packages/distribute-0.6.30-py3.3.egg/setuptools/command/sdist.py,
line 161, in run
self.make_distribution()
File /usr/local/python3.3/lib/python3.3/distutils/command/sdist.py, line
447, in make_distribution
file = self.make_archive(base_name, fmt, base_dir=base_dir)
File /usr/local/python3.3/lib/python3.3/distutils/cmd.py, line 370, in
make_archive
dry_run=self.dry_run)
File /usr/local/python3.3/lib/python3.3/distutils/archive_util.py, line
178, in make_archive
filename = func(base_name, base_dir, **kwargs)
File /usr/local/python3.3/lib/python3.3/distutils/archive_util.py, line
118, in make_zipfile
zip.write(path, path)
File /usr/local/python3.3/lib/python3.3/zipfile.py, line 1328, in write
self.fp.write(zinfo.FileHeader())
File /usr/local/python3.3/lib/python3.3/zipfile.py, line 382, in FileHeader
filename, flag_bits = self._encodeFilenameFlags()
File /usr/local/python3.3/lib/python3.3/zipfile.py, line 394, in
_encodeFilenameFlags
return self.filename.encode('utf-8'), self.flag_bits | 0x800
UnicodeEncodeError: 'utf-8' codec can't encode character '\udcfc' in position
21: surrogates not allowed
--
components: Library (Lib), Unicode
messages: 173676
nosy: ezio.melotti, stefanholek
priority: normal
severity: normal
status: open
title: zipfile: allow surrogates in filenames
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16310
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16310] zipfile: allow surrogates in filenames
Stefan Holek added the comment: A little more context perhaps: The use-case is building Python distributions containing non-ASCII filenames. These seemingly invalid filenames can occur in real-life when the files have been created by, say, a 'git clone' operation. So yes, I have Latin-1 bytes on the filesystem, even though my locale is UTF-8. And yes, Python 3 decodes that filename using surrogates. Creating .tar.gz distributions in this situation appears to work (even re-creating the foreign bytes when the archive is later extracted), whereas .zip archives fail in the way described above. I was hoping zipfile could be made to work the same as tarfile in this regard. Concerns for standards certainly didn't keep tarfile from supporting surrogates. ;-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16310 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15776] Allow pyvenv to work in existing directory
New submission from Stefan Holek: With virtualenv I can do $ virtualenv . but with pyvenv I get $pyvenv . Error: Directory exists: /Users/stefan/sandbox/foo Please allow pyvenv to apply to existing directories. -- components: None messages: 168990 nosy: stefanholek priority: normal severity: normal status: open title: Allow pyvenv to work in existing directory type: behavior versions: Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15776 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15776] Allow pyvenv to work in existing directory
Stefan Holek added the comment: Hm. What I am actually after is to bless an existing directory – source files and all – with a virtualenv (or pyvenv). I am not interested in the command deleting anything from anywhere, why thank you. Workflow: $ git clone g...@github.com:stefanholek/foo $ cd foo $ virtualenv . $ ./bin/python setup.py develop $ ./bin/python setup.py -q test This is how I use virtualenv at the moment and I'd rather not lose that ability. Thanks. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15776 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15776] Allow pyvenv to work in existing directory
Stefan Holek added the comment: Sorry for being late. I'll make a feature request for 3.4 then. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15776 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15645] 2to3 Grammar pickles not created when upgrading to 3.3.0b2
Stefan Holek added the comment: Mac OS X 10.6.8 (Snow Leopard) Xcode Tools 3.2.6 ./configure --prefix=/usr/local/python3.3 make sudo make install -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15645 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15645] 2to3 Grammar pickles not created when upgrading to 3.3.0b2
New submission from Stefan Holek:
After upgrading 3.3.0b1 to b2 (make install to same location) I noticed that
the Grammar pickles for beta.2 were missing (the beta.1 pickles still being
there).
The result is permission errors and/or virtualenv SandboxViolations, when 2to3
is used for the first time. E.g.:
SandboxViolation:
open('/usr/local/python3.3/lib/python3.3/lib2to3/Grammar3.3.0.beta.2.pickle',
'wb') {}
This is because users of Python (as opposed to root) may of course not write to
the library dir.
The pickles are created fine on a fresh install of Python 3.3.0b2 (make install
to new location).
--
components: 2to3 (2.x to 3.x conversion tool)
messages: 168180
nosy: stefanholek
priority: normal
severity: normal
status: open
title: 2to3 Grammar pickles not created when upgrading to 3.3.0b2
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15645
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13342] input() builtin always uses strict error handler
Stefan Holek ste...@epy.co.at added the comment: This is with Python 3.2.2 on Mac OS X 10.6 (SL). I have built Python from source with: ./configure; make; make install. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13342 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13342] input() builtin always uses strict error handler
Stefan Holek ste...@epy.co.at added the comment: Python 3.2.2 (default, Nov 4 2011, 22:28:55) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type help, copyright, credits or license for more information. import sys, io w = io.TextIOWrapper(sys.stdin.detach(), 'ascii', 'replace') input built-in function input input() Traceback (most recent call last): File stdin, line 1, in module ValueError: underlying buffer has been detached -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13342 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13342] input() builtin always uses strict error handler
Stefan Holek ste...@epy.co.at added the comment: Oops, the last one wasn't meant for the bug tracker. blush -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13342 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13342] input() builtin always uses strict error handler
Stefan Holek ste...@epy.co.at added the comment: I can make it work at the interpreter prompt with your patch applied. Sorry for cluttering up the ticket. ;-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13342 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
