[issue15494] Move test/support.py into a test.support subpackage

Change by hai shi : -- nosy: +shihai1991 nosy_count: 12.0 -> 13.0 pull_requests: +20067 pull_request: https://github.com/python/cpython/pull/20824 ___ Python tracker ___ __

[issue15494] Move test/support.py into a test.support subpackage

Roundup Robot added the comment: New changeset e6f2f3eda290 by Ned Deily in branch '3.3': Issue #15494: Install new test/support directory. http://hg.python.org/cpython/rev/e6f2f3eda290 New changeset 4df2e094f83e by Ned Deily in branch 'default': Issue #15494: merge from 3.3 http://hg.python.org

[issue15494] Move test/support.py into a test.support subpackage

Roundup Robot added the comment: New changeset 0b7ed24f7d33 by Nick Coghlan in branch '3.3': Issue #15494: test.support is now a package rather than a module http://hg.python.org/cpython/rev/0b7ed24f7d33 -- ___ Python tracker

[issue15494] Move test/support.py into a test.support subpackage

Roundup Robot added the comment: New changeset 203a77e74aa7 by Nick Coghlan in branch 'default': Close #15494: test.support is now a package rather than a module http://hg.python.org/cpython/rev/203a77e74aa7 -- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status:

[issue15494] Move test/support.py into a test.support subpackage

Stephen Tonkin added the comment: Likewise, move_test_support.patch did not break things under OS X 10.8. -- nosy: +sptonkin ___ Python tracker ___ __

[issue15494] Move test/support.py into a test.support subpackage

Michael Dorman added the comment: move_test_support.patch didn't break tests under Windows x64 -- nosy: +mjdorma ___ Python tracker ___ __

[issue15494] Move test/support.py into a test.support subpackage

Indra Talip added the comment: as per Nick's direction the attached patch moves test/support.py to test/support/__init__.py and includes small fixes for some of the tests that break as a consequence. -- keywords: +patch nosy: +italip Added file: http://bugs.python.org/file30850/move_te

[issue15494] Move test/support.py into a test.support subpackage

Nick Coghlan added the comment: Ah, I *thought* there was another module that started me down this path. Issue 11816 (a dis module upgrade that I finally deemed ready enough to commit) added "test.bytecode_helper", so the new test.support package will consist of at least: support/__init__.py

[issue15494] Move test/support.py into a test.support subpackage

Changes by Florent Xicluna : -- nosy: +flox ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue15494] Move test/support.py into a test.support subpackage

Nick Coghlan added the comment: Yeah, it was only when we went to add "test.pkg_helper" (so that test_runpy and test_pkgutil could share it) that we put the brakes on and decided to stop making a bad situation worse and do something different. There are probably some other helpers we could spi

[issue15494] Move test/support.py into a test.support subpackage

Ezio Melotti added the comment: FWIW the reason why I proposed to add assert_python_ok to test.support, is that from my point of view it's just one of the many *test* support utilities defined in test.support. I think that from Nick's point of view, assert_python_ok is just one of the many *s

[issue15494] Move test/support.py into a test.support subpackage

Éric Araujo added the comment: FWIW I have no principled opinion about big vs. small test.support module, as this is purely internal code. The reasons for this proposal as I understand them are: - One module for script helpers, one module for package creation, etc. are not bad. - We don’t real

[issue15494] Move test/support.py into a test.support subpackage

Nick Coghlan added the comment: OK, Georg has locked the 3.2 branch now, so we can proceed with this without making any 3.2 blockers harder to deal with. -- versions: +Python 3.3 ___ Python tracker ___

[issue15494] Move test/support.py into a test.support subpackage

R. David Murray added the comment: Let's not argue over generalities. Let's wait and argue over a specific patch proposal. -- ___ Python tracker ___ ___

[issue15494] Move test/support.py into a test.support subpackage

Ezio Melotti added the comment: > Please stop telling me to write awful code. I'm not telling you to write awful code, I'm telling you that IME having to deal with a single file is easier, so that's what I would personally prefer. Clearly if other developers disagree and/or if there is too mu

[issue15494] Move test/support.py into a test.support subpackage

Nick Coghlan added the comment: Whereas I actively want to avoid *deliberately* making test.support even more of an incoherent mess. I'm still utterly astonished you're actively promoting the idea. Please stop telling me to write awful code. -- ___ Py

[issue15494] Move test/support.py into a test.support subpackage

Ezio Melotti added the comment: So IIUC the package will contain __init__.py (what is now support.py), script_helper, and pkg_helper. One reason why I proposed to merge script_helper with support.py is that functions like assert_python*() are used in several modules already, and are generic e

[issue15494] Move test/support.py into a test.support subpackage

Nick Coghlan added the comment: This whole refactoring project grew out of the fact that Chris and I were looking for somewhere to put common helpers for package testing. Specfically, I wrote a heap of helpers for test_runpy that I wanted to use for the new pkgutil tests. The short term hack

[issue15494] Move test/support.py into a test.support subpackage

Martin v. Löwis added the comment: This may increasingly get off-topic, so I'll stop with generalities after this post. I find the effect of modularization on discoverability to be two-sided. On the one hand, splitting functionality into groups helps discoverability, since you don't have to w

[issue15494] Move test/support.py into a test.support subpackage

R. David Murray added the comment: Every sizeable (and some not-so-sizeable) Python projects I've worked on have one or more 'utils' modules that collect stuff that doesn't logically fit elsewhere. That's what test.support is for the test infrastructure. I agree that we should not talk in gen

[issue15494] Move test/support.py into a test.support subpackage

Ezio Melotti added the comment: > Ezio, this issue is not to split up support.py. Nick already responded > to you to this effect in the fourth comment above. Indeed, I should have re-read the messages more carefully. > Also, in the second comment to this issue, I said that this issue was > to

[issue15494] Move test/support.py into a test.support subpackage

Chris Jerdonek added the comment: > If you are planning to further split support.py, then I'm -1. Ezio, this issue is not to split up support.py. Nick already responded to you to this effect in the fourth comment above. Also, in the second comment to this issue, I said that this issue was to

[issue15494] Move test/support.py into a test.support subpackage

Martin v. Löwis added the comment: Since "basic software engineering principles" have been invoked, I'd like to point out that many of the standard motivations to modularization don't apply in this case. So it is fair to ask what *specific* benefits such a restructuring may have. Such a descri

[issue15494] Move test/support.py into a test.support subpackage

Ezio Melotti added the comment: > Umm, WTF? You're really asking me to justify the basic software > engineering principle that modularity is good, I'm aware of the principle -- what I'm asking is what practical advantages this will bring (practicality beats purity). > and wanting to dump ever

[issue15494] Move test/support.py into a test.support subpackage

Nick Coghlan added the comment: I already did, that thread 'tis a large part of why I'm somewhat irritable in relation to this topic today. "Huge source files are inherently bad because they provide no hint as to the modular breakdown and encourage excessive coupling between subcomponents" is

[issue15494] Move test/support.py into a test.support subpackage

Antoine Pitrou added the comment: Ah, ok. Perhaps I should read python-dev before talking about it! -- ___ Python tracker ___ ___ Pyth

[issue15494] Move test/support.py into a test.support subpackage

Chris Jerdonek added the comment: >> Excessively large source files are a sign of bad software design. > > Do you [want to] weigh in the python-dev discussion about splitting > unicodeobject.c? Nick did weigh in starting here: http://mail.python.org/pipermail/python-dev/2012-October/122391.html

[issue15494] Move test/support.py into a test.support subpackage

Antoine Pitrou added the comment: s/Do you weigh in/Do you want to weigh in/, sorry. -- ___ Python tracker ___ ___ Python-bugs-list ma

[issue15494] Move test/support.py into a test.support subpackage

Antoine Pitrou added the comment: > test.support will become a package in 3.3 and trunk after the final 3.2 > release goes out. > > Excessively large source files are a sign of bad software design. Do you weigh in the python-dev discussion about splitting unicodeobject.c? -- _

[issue15494] Move test/support.py into a test.support subpackage

Nick Coghlan added the comment: Umm, WTF? You're really asking me to justify the basic software engineering principle that modularity is good, and wanting to dump everything in one file is one of the classic signs that your architectural design is non-existent and you have completely failed to ad

[issue15494] Move test/support.py into a test.support subpackage

Ezio Melotti added the comment: > Excessively large source files are a sign of bad software design. Are there actual reasons that support this claim? -- ___ Python tracker ___ _

[issue15494] Move test/support.py into a test.support subpackage

Nick Coghlan added the comment: test.support will become a package in 3.3 and trunk after the final 3.2 release goes out. Excessively large source files are a sign of bad software design. -- ___ Python tracker ___

[issue15494] Move test/support.py into a test.support subpackage

Ezio Melotti added the comment: Tonight I was looking for assert_python_failure() in test.support, and it took me a while to figure out it was in script_helper.py instead. As suggested in msg166778 by Antoine, I would rather pick option 1 and merge everything in test.support, rather than furth

[issue15494] Move test/support.py into a test.support subpackage

Changes by R. David Murray : -- nosy: +r.david.murray ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue15494] Move test/support.py into a test.support subpackage

Changes by Martin v. Löwis : -- versions: +Python 3.3 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue15494] Move test/support.py into a test.support subpackage

Changes by Martin v. Löwis : -- versions: -Python 3.3 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue15494] Move test/support.py into a test.support subpackage

Nick Coghlan added the comment: I've just gone through and made sure all the related issues are correctly assigned to me. -- ___ Python tracker ___ _

[issue15494] Move test/support.py into a test.support subpackage

Nick Coghlan added the comment: As noted in the original post, this is a change which will be made once the 3.3 release is out the door. It's origin lies in the fact that one of the new pkgutil tests currently lives in test_runpy because test_runpy has much better infrastructure for that kind

[issue15494] Move test/support.py into a test.support subpackage

Martin v. Löwis added the comment: So who is going to provide a patch for it, and when? I don't think the tracker is the right place to keep list of things that someone wants to do some day. There isn't an issue "Python should have a JIT", either. Tracker issues should be actionable at the tim

[issue15494] Move test/support.py into a test.support subpackage

Nick Coghlan added the comment: Martin, this change has been specifically requested by me to better organise all the support code that ISN'T in test.support. That file is already huge, and I'm not going to make it even bigger with all the test infrastructure needed for generating packaging hei

[issue15494] Move test/support.py into a test.support subpackage

Martin v. Löwis added the comment: -1. test.support is not at all too large for a single module; there is no point in refactoring it. Without a specific patch to review which proposes some specific change, I'm rejecting this change request. -- nosy: +loewis resolution: -> rejected st

[issue15494] Move test/support.py into a test.support subpackage

Nick Coghlan added the comment: Note that I don't think test.support itself should be broken up - I don't see any good reason to split the current grab bag of functionality out into submodules, so you'd just have support/__init__.py open instead. This is really about giving us a better way to

[issue15494] Move test/support.py into a test.support subpackage

Ezio Melotti added the comment: I'd prefer to keep test.support as a single module, rather than converting it to a package. Most of the time I open up test.support when I'm trying to find some function, so having more files will only make this more complicated. -- nosy: +ezio.melotti t

[issue15494] Move test/support.py into a test.support subpackage

Chris Jerdonek added the comment: If people are okay with populating test/support/__init__.py with code (at least initially), the first patch could be to move support.py into test/support/__init__.py. One nice thing about this approach is that the calling code won't need to change. The seco

[issue15494] Move test/support.py into a test.support subpackage

New submission from Chris Jerdonek: This issue is to move test/support.py into a test.support subpackage as discussed in issue 15403. This can be done post-release. -- components: Tests messages: 166848 nosy: cjerdonek, ncoghlan, pitrou priority: normal severity: normal status: open ti