[issue12279] Add build_distinfo command to packaging

Changes by Michael Mulich : -- nosy: -michael.mulich2 ___ Python tracker <http://bugs.python.org/issue12279> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12279] Add build_distinfo command to packaging

Michael Mulich added the comment: On Mon, Jul 11, 2011 at 11:43 AM, Éric Araujo wrote: > What do you mean with context?  Wouldn’t all three commands just make install_distinfo generate files in the build dir? Right, my context comment is invalid. > I think that option 4 is th

[issue8668] Packaging: add a 'develop' command

Michael Mulich added the comment: On Mon, Jul 11, 2011 at 1:14 PM, Carl Meyer wrote: >> * Cases 2, 3, 5 and 6 are strongly related. > I don't know. I don't consider case 3 useful, because I don't consider > "I don't want to use a virtualenv" (without

[issue8668] Packaging: add a 'develop' command

Michael Mulich added the comment: On Tue, Jul 12, 2011 at 9:39 AM, higery wrote: >> The develop command writes three pieces of information to the filesystem: >>  1. It calls upon the build action(s) to build the package relative to >> the package's root directory. >

[issue12544] Avoid using a pseudo-dict for _type_equality_funcs in unittest

Michael Foord added the comment: It isn't clear to me exactly what fix you are suggesting for Python 2.7? -- assignee: -> michael.foord ___ Python tracker <http://bugs.python.org

[issue7559] TestLoader.loadTestsFromName swallows import errors

Michael Foord added the comment: My thinking on this has evolved a bit. Changing an import error into an attribute error is just a bad api. We should just fix the bad api. -- ___ Python tracker <http://bugs.python.org/issue7

[issue12544] Avoid using a pseudo-dict for _type_equality_funcs in unittest

Michael Foord added the comment: I wouldn't object to having a cyclic reference test for TestCase, although if it ever becomes a problem for the development of unittest we may have to disable it again. I think Benjamin said he would like to modify the test from Martin&#x

[issue7897] Support parametrized tests in unittest

Michael Foord added the comment: *If* we add this to unittest then we need to decide between test load time parameterised tests and test run time parameterisation. Load time is more backwards compatible / easier (all tests can be generated at load time and the number of tests can be known

[issue7897] Support parametrized tests in unittest

Michael Foord added the comment: And yes, parameterising test cases is a different issue. bzr does this IIRC. This is easier in some ways, and can be done through load_tests, or any other test load time mechanism. -- ___ Python tracker <h

[issue7897] Support parametrized tests in unittest

Michael Foord added the comment: Test selection would require load time parameterisation - although the current test selection mechanism is through importing which would probably *not* work without a specific fix. Same for run time parameterisation. Well how *exactly* you generate the names

[issue7897] Support parametrized tests in unittest

Michael Foord added the comment: Dammit, I've reversed my thinking in some of those messages. Load time parameterisation *does* give you separate test reporting. It is run time parameterisation that doesn't. Depending on how you do it (i.e. if the decorator generates the tests and

[issue7897] Support parametrized tests in unittest

Michael Foord added the comment: So if we do import time *or* test load time parameterisation then we can do separate failure reporting. We may still want to improve "test selection" for parameterised tests. There are use cases for run time parameterisation (for example genera

[issue7897] Support parametrized tests in unittest

Michael Foord added the comment: That all sounds good to me Nick. Some notes / questions. How should parameterised tests be marked? I'm happy with a unittest.parameterized decorator (it would do no work other than mark the test method, with the parameterisation being done in the TestL

[issue7897] Support parametrized tests in unittest

Michael Foord added the comment: Oh, and if we're not going to get clever with naming, how is the TestResult going to include the parameter repr in the failure report? That information will have to be stored on the TestCase. I would prefer this feature not to touch the TestResult - s

[issue7897] Support parametrized tests in unittest

Michael Foord added the comment: Well, pyflakes will tell you about name clashes within a TestCase (unless you're shadowing a test on a base class which I guess is rarely the case)... When we generate the tests we could add the parameter reprs to the docstring. A decorator factor that

[issue7897] Support parametrized tests in unittest

Michael Foord added the comment: Note that name clashes *would* result in non-unique testcase ids, so we need to prevent that. -- ___ Python tracker <http://bugs.python.org/issue7

[issue12600] Support parameterized TestCases in unittest

Michael Foord added the comment: Yeah, without some clear advantages and a clean api / implementation I'm -1. -- ___ Python tracker <http://bugs.python.org/is

[issue7897] Support parametrized tests in unittest

Michael Foord added the comment: David, I don't understand - it looks like Nick's suggestion would allow you to create a name per case, that's the point of it! You could even do this: def _name_from_case(name, cases): for idx, case in enumerate(cases, start=1): tes

[issue11610] Improved support for abstract base classes with descriptors

Changes by Michael Foord : -- nosy: -michael.foord ___ Python tracker <http://bugs.python.org/issue11610> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12600] Support parameterized TestCases in unittest

Michael Foord added the comment: Having a "TestCase factory" would be pretty easy, and solve the scaling problems. For example: def make_testcase_classes(): for backend in backends: yield type( '{}Test'.format(backend.name),

[issue12626] run test cases based on a glob filter

Michael Foord added the comment: I love the functionality. Running individual tests (or groups of tests) with unittest is a *pain*. I had hoped to solve this through unittest extensions, but this is taking me longer to get to than I had hoped. So I would like to add this to unittest, but

[issue12626] run test cases based on a glob filter

Michael Foord added the comment: I agree with Antoine, as test.support is not a public api adding new features to assist with debugging is fine. -- ___ Python tracker <http://bugs.python.org/issue12

[issue8639] Allow callable objects in inspect.getfullargspec

Michael Foord added the comment: Right. For a callable object (instance with __call__ method), it's unambiguous which signature you want. For a class it's ambiguous. -- ___ Python tracker <http://bugs.python.

[issue12681] unittest expectedFailure could take a message argument like skip does

Michael Foord added the comment: Well, expectedFailure could dispatch on the type of the argument, with different behaviour for strings and anything else (presumed to be a function / method). That would be inconsistent with the api for skipping though. (I'm not wild on the message arg

[issue12738] Bug in multiprocessing.JoinableQueue() implementation on Ubuntu 11.04

New submission from Michael Hall : I recently switched to Ubuntu 11.04 from OpenSUSE 11.4, and when I go to run a project I coded a couple days ago under OpenSUSE using the multiprocessing library, it hangs when it did not under OpenSUSE. Specifically, I am using two queues, work_queue from

[issue12738] Bug in multiprocessing.JoinableQueue() implementation on Ubuntu 11.04

Michael Hall added the comment: Edit: Sorry, I should have been more clear. The hang occurs after the first child process exits, at which point all four children become zombies (none of the others exit, they just zombify immediately), and the main process sits there waiting forever for the

[issue12738] Bug in multiprocessing.JoinableQueue() implementation on Ubuntu 11.04

Michael Hall added the comment: Okay, I have attached the code I've been using. Don't worry about what it does (it's a biology thing), but just follow these steps: 1. Make sure you have numpy and scipy installed. 2. Extract the zip file. 3. Run it with ./svm_main.py te

[issue12738] Bug in multiprocessing.JoinableQueue() implementation on Ubuntu 11.04

Michael Hall added the comment: I tried switching from joining on the work_queue to just joining on the individual child processes, and it seems to work now. Weird. Anyway, it'd be nice to see the JoinableQueue fixed, but it's not pressin

[issue12809] Missing new setsockopts in Linux (eg: IP_TRANSPARENT)

New submission from Michael Farrell : Recently, iptables has added support for transparent proxies using a new TPROXY target on Linux2. This requires a new option in setsockopts, IP_TRANSPARENT. There's some background on the feature here: http://www.mjmwired.net/kernel/Document

[issue12883] xml.sax.xmlreader.AttributesImpl allows empty string as attribute names

New submission from Michael Sulyaev : I can get not-well-formed XML output (attribute name must not be empty string): AttributeImpl must ignore dict entries that may not be cast to valid XML attributes. Code: #!/usr/bin/python from xml.sax.xmlreader import AttributesImpl as Attrs from

[issue6560] socket sendmsg(), recvmsg() methods

Changes by Michael Schurter : -- nosy: +schmichael ___ Python tracker <http://bugs.python.org/issue6560> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12957] mmap.resize changes memory address of mmap'd region

New submission from Michael Schurter : Since mmap.resize uses MREMAP_MAYMOVE on Linux, it would be nice to warn users that pointers into their memory mapped regions will be invalid after resizes. Linux's manpage offers the following explanation: "If the mapping is relocated, the

[issue7219] Unhelpful error message when a distutils package install fails due to a permissions error

Michael Foord added the comment: Output below, first without DISTUTILS_DEBUG (showing the not very useful default message) and second with. (The actual exception is "Access to the path 'C:\Program Files\IronPython 2.7\Lib\site-packages\mock.py' is denied.") This is w

[issue9571] argparse: Allow the use of -- to break out of nargs and into subparser

New submission from Michael.Elsdörfer : argparse already seems to support -- to indicate that what follows are positional arguments. However, I would like to parse something like: ./script.py --ignore one two -- COMMAND I.e., --ignore is an nargs='+' argument, and I need a way to break out of

[issue1173475] __slots__ for subclasses of variable length types

Michael Hudson added the comment: Well, I can think of some counters to that -- surely it's _more_ confusing if slots only works some of the time? -- but realistically I'm not going to work on this any further. -- ___ Python trac

[issue9424] deprecate unittest.TestCase.assertEquals

Michael Foord added the comment: We aren't talking about *removing* these methods from unittest - but now that we have standardised on assertEqual for the Python test suite it is annoying (particularly for Ezio who changes) when *new* tests are checked in using the old (deprecated-bu

[issue9424] Disable unittest.TestCase.assertEquals and assert_ during a regrtest run

Changes by Michael Foord : -- title: deprecate unittest.TestCase.assertEquals -> Disable unittest.TestCase.assertEquals and assert_ during a regrtest run ___ Python tracker <http://bugs.python.org/iss

[issue9338] argparse optionals with nargs='+' can't be followed by positionals

Changes by Michael.Elsdörfer : -- nosy: +elsdoerfer ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue9424] Disable unittest.TestCase.assertEquals and assert_ during a regrtest run

Michael Foord added the comment: Well, there is *some* value in stylistic consistency. If it didn't matter at all then Guido wouldn't have instigated the deprecation of assertEquals and assert_ and standardised on assertEqual (which he did during the sprints at PyCon 2009). Eithe

[issue9587] unittest.assertRaises() return the raised exception

Michael Foord added the comment: If you want the exception then use assertRaises in a with statement. The exception is available as an attribute on the context manager. -- resolution: -> rejected stage: -> committed/rejected status: open -&g

[issue9587] unittest.assertRaises() return the raised exception

Michael Foord added the comment: Sorry, it's a reopened bug requesting a feature that has already been considered and rejected previously. Yes I was abrupt, my apologies - I'm trying to clear my backlog before I go away. -- ___ Pyth

[issue7175] Define a standard location and API for configuration files

Michael Foord added the comment: It would be nice to settle this. Personally I would like to see the defaults being: Linux: ~/.pythonx.y Mac OS X: ~/.pythonx.y with a fallback of ~/Library/Preferences/.pythonx.y Windows: ~/pythonx.y perhaps with a backup of AppData/pythonx.y For both Windows

[issue7219] Unhelpful error message when a distutils package install fails due to a permissions error

Michael Foord added the comment: The "None" error message *looks* to me like the result of a failed assertion. That may not be correct of course... -- ___ Python tracker <http://bugs.python.

[issue9587] unittest.assertRaises() return the raised exception

Michael Foord added the comment: Providing access to the exception on the context manager was *precisely* to meet the use case of wanting to make assertions about the exception. I tend to agree with Guido that having one of the asserts return something is a bit odd, but irrespective of that

[issue706406] fix bug #685846: raw_input defers signals

Michael Stone added the comment: Wow, you wait 3/4 of a decade or so and the status of these bugs does tend to change on you. I'm not sure it's fixed, but it is different. Here's a test script for you: import readline import signal def handle(a,b): print "received s

[issue1020188] Use Py_CLEAR where necessary to avoid crashes

Michael Hudson added the comment: I think it makes sense to close this; if problems remain they should be reported in more targeted tickets. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue1

[issue7501] python -m unittest path_to_suite_function errors

Michael Foord added the comment: Well, it was misdiagnosed yes - but asking for "python -m unittest ..." support in Python 2.6 is still a feature request and not a bug report. (So unfortunately it can't be fixed in 2.6 which is bugfix only. The solution is to use unittest

[issue7742] please avoid 'which' in Modules/ld_so_aix

Michael Haubenwallner added the comment: @Stefan: Nope, setting some PATH in ~/.cshrc is the wrong thing to do, and it actually is the reason for this issue at all: 'which' is intended to tell the location of some command that would be used when started on current commandline

[issue9732] Addition of getattr_static for inspect module

New submission from Michael Foord : As discussed on python-dev, a version of getattr that does static lookups - bypassing the descriptor protocol, __getattr__, and __getattribute__. Initial implementation by Nick Coghlan, amended and tests added by me. Phillip Eby objects to this code

[issue9732] Addition of getattr_static for inspect module

Michael Foord added the comment: Tests require Python 3. Implementation works with Python 2 as well. -- Added file: http://bugs.python.org/file18700/test_static.py ___ Python tracker <http://bugs.python.org/issue9

[issue9732] Addition of getattr_static for inspect module

Changes by Michael Foord : Removed file: http://bugs.python.org/file18700/test_static.py ___ Python tracker <http://bugs.python.org/issue9732> ___ ___ Python-bugs-list m

[issue9732] Addition of getattr_static for inspect module

Changes by Michael Foord : -- Removed message: http://bugs.python.org/msg115297 ___ Python tracker <http://bugs.python.org/issue9732> ___ ___ Python-bugs-list m

[issue9732] Addition of getattr_static for inspect module

Michael Foord added the comment: Tests require Python 3. Implementation works with Python 2 as well. -- Added file: http://bugs.python.org/file18701/test_static.py ___ Python tracker <http://bugs.python.org/issue9

[issue9732] Addition of getattr_static for inspect module

Changes by Michael Foord : -- Removed message: http://bugs.python.org/msg115296 ___ Python tracker <http://bugs.python.org/issue9732> ___ ___ Python-bugs-list m

[issue9732] Addition of getattr_static for inspect module

Michael Foord added the comment: (Reposted as text was entirely duplicated - oops.) As discussed on python-dev, a version of getattr that does static lookups - bypassing the descriptor protocol, __getattr__, and __getattribute__. Initial implementation by Nick Coghlan, amended and tests

[issue9732] Addition of getattr_static for inspect module

Michael Foord added the comment: Since the addition of __dir__, dir(obj) can return arbitrary values. Typically (I guess) this will be used to add dynamically created attributes that this function will fail to find - so it is *more* likely that we will fail to find something in dir than the

[issue9732] Addition of getattr_static for inspect module

Michael Foord added the comment: (Or vice versa - getattr_static may succeed in finding members - like descriptors that raise AttributeError when fetched - when getattr fails.) -- ___ Python tracker <http://bugs.python.org/issue9

[issue9754] assertWarns and assertWarnsRegexp

Michael Foord added the comment: +1 -- ___ Python tracker <http://bugs.python.org/issue9754> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue9754] assertWarns and assertWarnsRegexp

Michael Foord added the comment: (Note that in general I am against extending the TestCase API with more asserts given how wide it is and how much it has expanded in recent versions. I've written warning checking code enough times for third party projects that I think this is worth it t

[issue9754] assertWarns and assertWarnsRegexp

Michael Foord added the comment: Why not accepting a tuple of warnings? That doesn't make sense for assertWarnsRegexp of course. -- ___ Python tracker <http://bugs.python.org/i

[issue4026] fcntl extension fails to build on AIX 6.1

Michael Haubenwallner added the comment: While I've not tested these patches myself, I do think there still is an unhandled case: building a 64bit python. As libbsd.a contains 32bit objects only, there is no 64bit flock(). So AC_CHECK_LIB(bsd,flock) may still fail, which should resu

[issue4026] fcntl extension fails to build on AIX 6.1

Michael Haubenwallner added the comment: While I do agree this being an AIX bug, it is not a blocker here: fcntl extension does not _depend_ on flock, it just does _prefer_ flock: If not available, fcntl extension uses something else (fcntl IIRC), as it did (even without linking libbsd) before

[issue4026] fcntl extension fails to build on AIX 6.1

Michael Haubenwallner added the comment: Sorry to be pedantic - but it looks like (don't have a build environment at hand at the moment) it will fail to build as 64bit on the not-so-up-to-date AIX with missing 64bit flock implementation: There, the compile-check will succeed and d

[issue4026] fcntl extension fails to build on AIX 6.1

Michael Haubenwallner added the comment: Using this patch based on current py3k branch I've been able now to build the fcntl module for 32bit aix5.3 (with flock) and 64bit aix5.3 (without flock), both using an old gcc-3.3.6, as well as for 64bit linux. If necessary, I should be able to c

[issue4026] fcntl extension fails to build on AIX 6.1

Michael Haubenwallner added the comment: Sébastien, while this gives expected results on the AIX box here, it still has one subtle problem: AC_TRY_LINK may fail due to missing declaration in _or_ due to missing implementation in libc. The subsequent AC_CHECK_LIB won't fail whe

[issue9796] Add summary tables for unittest API

Michael Foord added the comment: This has been on my 'todo list' for a long time. Feel free to get to it before me. Please *don't* include the now deprecated assert* methods in the table. I'd like to move all the deprecated methods to a separate section of the documentati

[issue9831] test_distutils fails on MacOSX 10.6

Changes by Michael Foord : -- nosy: -michael.foord ___ Python tracker <http://bugs.python.org/issue9831> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9857] SkipTest in tearDown is reported an as an error

Michael Foord added the comment: Interesting use case. If the test has not yet failed this is fine. The problem is that if an exception has *already* been raised then it will already have been added to the result - so by then skipping is meaningless (or contradictory - the test can fail

[issue9162] License for multiprocessing files

Michael Fladischer added the comment: Is there any timeline on when this will be fixed? It's currently blocking work on a python-related package for Debian. -- ___ Python tracker <http://bugs.python.org/i

[issue1705520] pyunit should allow __unittest in locals to trim stackframes

Michael Foord added the comment: It is relevant and would be *possible* to implement. I'm not 100% convinced it is a good *enough* idea to make it worth adding though. I'd like to leave the issue open for the moment in case other people want

[issue9889] PyUnicode_FormatV and Py_UNICODE*?

New submission from Michael Kleehammer : Using Py_UNICODE* in Python 3 C extensions is significantly more cumbersome than using char* was in Python 2.x. One addition that could help would be a Py_UNICODE* format type for PyUnicode_FormatV. Many printf libraries us %S for wchar_t which would

[issue9401] automatically try forward operations when reverse operations are NotImplemented

Michael Gilbert added the comment: i think that, for example, the default __rsub__ implementation could be: return self + -other which should just do the right thing assuming the addition and negation functions already do the right thing for the class type. anyway, any implementation

[issue9906] including elementary mathematical functions in default types

New submission from Michael Gilbert : hi, it would be really nice if elementary mathematical operations such as sin/cosine (via __sin__ and __cos__) were available as base parts of the python data model [0]. this would make it easier to write new math classes, and it would eliminate the

[issue9906] including elementary mathematical functions in default types

Michael Gilbert added the comment: the elementary functions are well-defined set, and i would include all of them. that includes exp, sqrt, ln, trig, and hyperbolic functions. i'll start a thread on python-ideas. thanks. -- ___ Python tr

[issue9868] test_locale leaves locale changed

Michael Foord added the comment: unittest *can't* know which setUp methods have already been called if an error occurs in one of them (because they are called explicitly by the sub-classes and not by unittest itself). Given this, the specific fix suggested seems

[issue9868] test_locale leaves locale changed

Michael Foord added the comment: Destructors are special cased in many languages and tearDown is not a destructor. More importantly though the change you suggest would be backwards incompatible. The 'correct' way to do this in new code is to use cleanUp functions which *are* call

[issue9926] Wrapped TestSuite subclass does not get __call__ executed

Michael Foord added the comment: Right, _wrapped_run is private and not intended to be overridden. Perhaps slightly ironically (for this particular bug report) is that the change was introduced to support class and module level setUp and tearDown (similar to the use-case it now blocks

[issue9926] Wrapped TestSuite subclass does not get __call__ executed

Michael Foord added the comment: Hmmm... 2.7 has already been released and has the same issue, so 'drastic' changes (like renaming BaseTestSuite back to TestSuite) are probably out. -- components: +Library (Lib) versions: +Python 2.7

[issue9926] Wrapped TestSuite subclass does not get __call__ executed

Michael Foord added the comment: Ok, so here is an idea that could remove the need for TestSuite._wrapped_run. TestSuite.run could "tag" the result object (set an attribute). Nested TestSuites would see an already tagged suite and do nothing (beyond running tests of course). The

[issue9926] Wrapped TestSuite subclass does not get __call__ executed

Michael Foord added the comment: On 24/09/2010 19:23, Martin v. Löwis wrote: > Martin v. Löwis added the comment: >> Perhaps slightly ironically (for this particular bug report) is that >> the change was introduced to support class and module level setUp and >> tearDow

[issue9926] Wrapped TestSuite subclass does not get __call__ executed

Michael Foord added the comment: The attached patch fixes the issue (I think...) by tagging the result object. It removes the need for _wrapped_result altogether. The test fails without the change to TestSuite and passes with the change. This could be applied to 2.7-maint and py3k. Uhm

[issue9082] warnings.filterwarnings doesn't work with -O

Michael Foord added the comment: When I run with -OO I get 42 test failures. Most of them look like they are due to missing docstrings but some are likely to be due to missing asserts. 42 tests failed: test_bisect test_cmd test_code test_collections test_compileall test_ctypes

[issue9082] warnings.filterwarnings doesn't work with -O

Michael Foord added the comment: Most of those failures look like they have a similar cause (not all of them though) related to running doctests. When issue 6292 was closed all tests passed with -OO, so this is a regression. I'm raising a separate issue for that. Looking at the

[issue9964] Test failures with -OO

New submission from Michael Foord : When I run the test suite (py3k branch) with -OO I get 42 failures. Most of these look like they are caused by the same (or a similar) problem (attempting to run doctests from now-non-existent docstrings). The tests that fail are: When I run with -OO I get

[issue9082] warnings.filterwarnings doesn't work with -O

Michael Foord added the comment: Cool - although I *do* see failures under -O; test_import for example. That one is a __pycache__ test, so barry's fault I think. I'll detail the failures in issue 9964 as I think *most* of them are caused by a problem with pdb.py In fact, if you

[issue9082] warnings.filterwarnings doesn't work with -O

Changes by Michael Foord : Removed file: http://bugs.python.org/file19035/pdb.diff ___ Python tracker <http://bugs.python.org/issue9082> ___ ___ Python-bugs-list mailin

[issue9082] warnings.filterwarnings doesn't work with -O

Michael Foord added the comment: Oops. The patch should go to issue 9964. Sorry for all this noise. -- ___ Python tracker <http://bugs.python.org/issue9

[issue9964] Test failures with -OO

Michael Foord added the comment: Most of the failures are caused by a problem in pdb. In fact, if you run Python with -OO you can't even *import* pdb. The attached patch fixes that problem (a hasty and untested patch though), and that reduces the number of failures to 5: 5 tests f

[issue9969] tokenize: add support for tokenizing 'str' objects

Changes by Michael Foord : -- nosy: +michael.foord ___ Python tracker <http://bugs.python.org/issue9969> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9969] tokenize: add support for tokenizing 'str' objects

Michael Foord added the comment: Note from Nick Coghlan from the Python-dev discussion: A very quick scan of _tokenize suggests it is designed to support detect_encoding returning None to indicate the line iterator will return already decoded lines. This is confirmed by the fact the standard

[issue9977] TestCase.assertItemsEqual's description of differences

Changes by Michael Foord : -- assignee: -> michael.foord components: +Library (Lib) versions: +Python 3.2 ___ Python tracker <http://bugs.python.org/iss

[issue9976] Make TestCase._formatMessage public

Changes by Michael Foord : -- assignee: -> michael.foord components: +Library (Lib) versions: +Python 3.2 ___ Python tracker <http://bugs.python.org/iss

[issue9309] Add environment variable complementing command line option -no-user-cfg

Michael Brickenstein added the comment: Actually, Sage acts in a similar way like virtualenvs do. In fact, config files are also a problem for virtualenv, see second red box here: http://wiki.pylonshq.com/display/pylonscookbook/Using+a+Virtualenv+Sandbox cite: --- Virtualenv is currently

[issue10015] Creating a multiproccess.pool.ThreadPool from a child thread blows up.

New submission from Michael Olson : Using Python 2.7 x32 on Windows XP Attempting to create a multiprocessing.pool.ThreadPool in a child thread created using threading.Thread, an AttributeError is thrown. A ThreadPool created in the main thread can be passed to the child thread and used

[issue10049] Add a "no-op" (null) context manager to contextlib

Michael Foord added the comment: +1 Looks like a reasonable use case. -- nosy: +michael.foord, ncoghlan ___ Python tracker <http://bugs.python.org/issue10

[issue10049] Add a "no-op" (null) context manager to contextlib

Michael Foord added the comment: Patch is missing tests and documentation. -- ___ Python tracker <http://bugs.python.org/issue10049> ___ ___ Python-bugs-list m

[issue10076] Regex objects became uncopyable in 2.5

New submission from Michael Shields : For many years now, the sre module has provided __copy__ and __deepcopy__ modules that raise an exception ("cannot copy this pattern object") by default, with an #ifdef to enable their implementations. Until Python 2.5, these were simply unus

[issue10076] Regex objects became uncopyable in 2.5

Michael Shields added the comment: Here's the patch. I updated the test case and release notes also. I'm a Google employee, so this patch is covered by whatever usual copyright arrangement we have with the PSF. -- keywords: +patch Added file: http://bugs.python.org/file

[issue6417] multiprocessing Process examples: print and getppid

Michael Newman added the comment: The example is working correctly for: Python 3.2a3 (r32a3:85355, Oct 10 2010, 17:11:45) [MSC v.1500 32 bit (Intel)] on win32 # First test: C:\mike>c:\Python32\python.exe s2.py main line module name: __main__ parent process: 2360 process id: 1584 functio

[issue10128] multiprocessing.Pool throws exception with __main__.py

New submission from Michael Olson : In an application with an entry point of __main__.py, multiprocessing.Pool throws the following: Traceback (most recent call last): File "", line 1, in File "D:\Dev\Python27\lib\multiprocessing\forking.py", line 346, in main prep

<    1   2   3   4   5   6   7   8   9   10   >