[issue413850] Bug in xml/__init__.py

Change by admin : -- github: None -> 34278 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue438295] [Windows] __init__.py cause strange behavior

Change by admin : -- github: None -> 34697 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue215056] __init__.py has tab ==> indention error

Change by admin : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue215056] __init__.py has tab ==> indention error

Change by admin : -- github: None -> 33170 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44586] unittest requires __init__.py for test discovery

Inada Naoki added the comment: And https://dev.to/methane/don-t-omit-init-py-3hga too. -- nosy: +methane ___ Python tracker ___

[issue44586] unittest requires __init__.py for test discovery

Karthikeyan Singaravelan added the comment: See also https://bugs.python.org/issue23882 -- nosy: +xtreak ___ Python tracker ___

[issue44586] unittest requires __init__.py for test discovery

New submission from ma19 : This is how my project is currently set up: src: - main.py - src1.py - src2.py test: - __init__.py - test_src1.py - test_src2.py If I remove __init__.py from the "test" directory, the unittest discovery fails. I thought that __init__.py was

[issue27074] Confusing text about __all__ in __init__.py in tutorial

Change by Irit Katriel : -- nosy: +eric.snow ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44064] Python39/lib/logging/__init__.py SyntaxError: cannot delete starred

Kathleen West added the comment: Created an issue @ microsoft/vscode-python https://github.com/microsoft/vscode-python/issues/16174 -- stage: -> resolved status: open -> closed ___ Python tracker

[issue44064] Python39/lib/logging/__init__.py SyntaxError: cannot delete starred

Kathleen West added the comment: We have a root cause/answer to the issue for future reference. Jedi is a static analysis tool for Python that is typically used in IDEs/editors plugins (VS Code) I will create a bug here: https://github.com/Microsoft/vscode-python -- resolution:

[issue44064] Python39/lib/logging/__init__.py SyntaxError: cannot delete starred

Jelle Zijlstra added the comment: "del t, v, tb" is perfectly legal Python syntax. It's whatever tool is showing a syntax error there (jedi, apparently) that's buggy. % python3.9 Python 3.9.4 (default, Apr 9 2021, 09:47:14) [Clang 12.0.0 (clang-1200.0.32.29)] on darwin Type "help",

[issue44064] Python39/lib/logging/__init__.py SyntaxError: cannot delete starred

Kathleen West added the comment: I literally changed the base logging code to this and it worked finally: del t del v del tb -- ___ Python tracker

[issue44064] Python39/lib/logging/__init__.py SyntaxError: cannot delete starred

Kathleen West added the comment: The "del" statement *** del_stmt ::= "del" target_list Deletion is recursively defined very similar to the way assignment is defined. Rather than spelling it out in full details, here are some hints. Deletion of a target list recursively

[issue44064] Python39/lib/logging/__init__.py SyntaxError: cannot delete starred

Kathleen West added the comment: Jelle Zijlstra (Jelle Zijlstra) "Saying it so doesn't make it so" See the photo for proof. If you could reply with more details and clear steps on how to resolve the issue, that would be appreciated. -- ___

[issue44064] Python39/lib/logging/__init__.py SyntaxError: cannot delete starred

Jelle Zijlstra added the comment: Line 1030 of 3.9.4 is at https://github.com/python/cpython/blob/1f2e3088f3c097b5bde69bbd63dfcd0852d31984/Lib/logging/__init__.py#L1030 and doesn't have a del statement or a syntax error. Most likely there's some mismatch where you're running the wrong

[issue44064] Python39/lib/logging/__init__.py SyntaxError: cannot delete starred

New submission from Kathleen West : There is a syntax error in the python library "Python39/lib/logging/__init__.py" that when I run this is VS Code in debug mode, this shows up all the time. python --version Python 3.9.4 Python39/lib/logging/__init__.py { "resourc

Re: Transistion from module to package and __init__.py

Chris Nyland wrote at 2021-5-4 22:20 -0400: > ... >So for a while now I have taken to converting >my module, in this example database.py, to the __init__.py of the package. >I remember reading years back that having code in the __init__.py was bad >practice but I can't remember

Re: Transistion from module to package and __init__.py

> Either of these still leaves a database.database namespace laying about and > to me it just seems untidy. So for a while now I have taken to converting > my module, in this example database.py, to the __init__.py of the package. > So I was hoping to get > feed back from a

Transistion from module to package and __init__.py

naturally I make a package folder called database, put and empty __init__.py, in goes my database module and all resource files. Here is where I my primary design question comes in. As organized now as described to import and use the package I need from database import database or I have to put

[issue36238] distutils complains "package init file 'xxx/__init__.py' not found (or not a regular file)" when using Cythonized __init__.pyx

Steve Dower added the comment: Distutils is now deprecated (see PEP 632) and all tagged issues are being closed. From now until removal, only release blocking issues will be considered for distutils. If this issue does not relate to distutils, please remove the component and reopen it. If

[issue42672] tkinter/__init__.py raises a NameError if NoDefaultRoot()

Ivo Shipkaliev added the comment: Thank you! -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42672] tkinter/__init__.py raises a NameError if NoDefaultRoot()

New submission from Serhiy Storchaka : The patch is not correct. Its first part negates the correct behavior, its second part does not affect behavior at all, and all this does not have any effect on NameError. This issue looks like a duplication of 42630. -- resolution: ->

[issue42672] tkinter/__init__.py raises a NameError if NoDefaultRoot()

Change by Terry J. Reedy : -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42672] tkinter/__init__.py raises a NameError if NoDefaultRoot()

Change by Ivo Shipkaliev : -- components: Tkinter files: default_root.diff keywords: patch nosy: shippo_ priority: normal severity: normal status: open title: tkinter/__init__.py raises a NameError if NoDefaultRoot() type: behavior versions: Python 3.10 Added file: https

[issue27578] inspect.findsource raises exception with empty __init__.py

kernc added the comment: The proposed patch doesn't break any interfaces. `inspect.getsource/.getsourcelines()` still raise `OSError` if the source is unretrievable. `linecache.getlines()` is undocumented, but the change retains perfect compatibility with *docstrings* of both

[issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files?

Change by Inada Naoki : -- superseder: -> unittest discovery doesn't detect namespace packages when given no parameters ___ Python tracker ___

[issue27578] inspect.findsource raises exception with empty __init__.py

Terry J. Reedy added the comment: I agree that getsource raising is a bug. I would more at the behavior and doc for getlines before I decided about that. -- nosy: +terry.reedy versions: -Python 2.7, Python 3.5, Python 3.6, Python 3.9 ___ Python

[issue27578] inspect.findsource raises exception with empty __init__.py

Change by kernc : -- keywords: +patch pull_requests: +20006 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20809 ___ Python tracker ___

[issue27578] inspect.findsource raises exception with empty __init__.py

Change by kernc : -- nosy: +kernc versions: +Python 3.10, Python 3.9 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue29258] __init__.py required for pkgutil.walk_packages in python3

Inada Naoki added the comment: I am totally agree with Wolfgang: > they make it impossible to know whether a directory found on the filesystem > is *intended* as a Python package or not. I think we shouldn't treat normal directory as namespace package until some portion in the directory is

[issue29258] __init__.py required for pkgutil.walk_packages in python3

Change by Inada Naoki : -- assignee: -> docs@python components: +Documentation -Library (Lib) nosy: +docs@python resolution: rejected -> stage: resolved -> needs patch status: closed -> open versions: +Python 3.8, Python 3.9 -Python 3.5, Python 3.6

[issue29258] __init__.py required for pkgutil.walk_packages in python3

Eric Wieser added the comment: If the resolution here is that this is behaving as intended (which personally I disagree with), I think this issue should remain open as a documentation task - the docs should clearly state that this does not apply to PEP420 namespace packages. --

[issue36892] "Modules" section in Tutorial contains incorrect description about __init__.py

packages. It is a feature for very special use case. Don't omit ``__init__.py`` in regular packages. -- nosy: +inada.naoki ___ Python tracker <https://bugs.python.org/issue36

[issue29258] __init__.py required for pkgutil.walk_packages in python3

Inada Naoki added the comment: > PEP420 makes __init__.py files optional This is almost wrong. PEP 420 added a new way for "namespace pacakge." PEP 420 doesn't make empty __init__.py file in regular package. (See https://dev.to/methane/don-t-omit-init-py-3hga)

[issue32524] Python 2.7 leaks a packages __init__.py module object on SyntaxError

Change by Cheryl Sabella : -- resolution: -> wont fix stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue38457] __package__ is None in __init__.py until an import is used

Nick Coghlan added the comment: Yes, this is a design flaw in the Python 2 import system - it derives `__package__` from `__name__` the first time it needs the information and `__package__` isn't already set. The problem was fixed for the Python 3 series by way of PEP 451, which made

[issue38457] __package__ is None in __init__.py until an import is used

Change by Brett Cannon : -- nosy: -brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38457] __package__ is None in __init__.py until an import is used

Change by Brett Cannon : -- nosy: +brett.cannon, eric.snow, ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue38457] __package__ is None in __init__.py until an import is used

Change by Brett Cannon : -- nosy: -brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38457] __package__ is None in __init__.py until an import is used

Yuval S added the comment: * It should be python[23] -m x.test, of course. -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue38457] __package__ is None in __init__.py until an import is used

Change by Karthikeyan Singaravelan : -- nosy: +brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38457] __package__ is None in __init__.py until an import is used

New submission from Yuval S : In Python 2.7, the __package__ variable isn't set when __init__.py is run, until an import is done. In Python 3.5, it is set correctly. e.g. # mkdir x && echo "print(__package__)" | tee x/__init__.py x/test.py # python2 x.test None x # python3

[issue29258] __init__.py required for pkgutil.walk_packages in python3

Change by Eric Wieser : -- nosy: +Eric Wieser ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36892] "Modules" section in Tutorial contains incorrect description about __init__.py

Ezio Melotti added the comment: I agree that implicit namespace packages don't deserve more than a footnote in that page. However, since I often have to answer questions about packages, I'm thinking that perhaps it would be better to expand that page and maybe have a page dedicated to

[issue36892] "Modules" section in Tutorial contains incorrect description about __init__.py

Steven D'Aprano added the comment: In my experience, beginners have enough trouble getting packages right without complicating the tutorial with a rarely-used advanced feature like namespace packages. I don't think this needs more than perhaps a footnote, if that. -- nosy:

[issue36892] "Modules" section in Tutorial contains incorrect description about __init__.py

New submission from musou1500 : "Modules" section in the tutorial says that https://docs.python.org/3/tutorial/modules.html "The __init__.py files are required to make Python treat directories containing the file as packages. " But, thanks to PEP 420, __init__.py is not r

Re: Why not being able to call modules from lib folder into test folder although I have __init__.py file both?

On 26/04/19 11:14 AM, dieter wrote: Arup Rakshit writes: I am not able to call modules from lib folder in my test folder, but outside of tests folder I can access them. How should I fix this? Mocks$ tree . . ├── lib │ ├── __init__.py │ ├── __pycache__ │ │ ├── __init__.cpython-37.pyc

Re: Why not being able to call modules from lib folder into test folder although I have __init__.py file both?

Arup Rakshit writes: > I am not able to call modules from lib folder in my test folder, but outside > of tests folder I can access them. How should I fix this? > > Mocks$ tree . > . > ├── lib > │ ├── __init__.py > │ ├── __pycache__ > │ │

Why not being able to call modules from lib folder into test folder although I have __init__.py file both?

I am not able to call modules from lib folder in my test folder, but outside of tests folder I can access them. How should I fix this? Mocks$ tree . . ├── lib │ ├── __init__.py │ ├── __pycache__ │ │ ├── __init__.cpython-37.pyc │ │ └── product.cpython-37.pyc │ └── product.py

[issue36238] distutils complains "package init file 'xxx/__init__.py' not found (or not a regular file)" when using Cythonized __init__.pyx

New submission from jt : distutils spits out a warning: package init file 'xxx/__init__.py' not found (or not a regular file) ... when using Cythonized __init__.pyx instead. However, the installed package works absolutely fine, it can be imported & used perfectly, so this warning s

[issue34768] Add documentation explaining __init__.py in packages

Éric Araujo added the comment: I think the expectation is that people will know about modules and packages long before they upload things to PyPI. The import system and the packaging tools are two independent domains. For example the official tutorial has an intro:

[issue34768] Add documentation explaining __init__.py in packages

Change by Benito Kestelman : -- title: Add documentation for the purpose of __init__.py in packages -> Add documentation explaining __init__.py in packages ___ Python tracker <https://bugs.python.org/issu

[issue34768] Add documentation for the purpose of __init__.py in packages

New submission from Benito Kestelman : I just learned how to make my own package in python and upload it to pypi. I mainly used the documentation here: https://packaging.python.org/tutorials/packaging-projects/ Other than the toy example, there is no explanation of __init__.py, its purpose

[issue34534] importlib.resources does not work with packages that have no __init__.py

Barry A. Warsaw added the comment: https://docs.python.org/3/reference/import.html#regular-packages Regular packages have __init__.py files and namespace packages do not. "Implicit non-namespace packages" aren't really A Thing. This design choice is deliberate; namespac

[issue34534] importlib.resources does not work with packages that have no __init__.py

Girts Folkmanis added the comment: > What's the difference between "namespace packages and implicit non-namespace > packages"? To me, the semantic difference is that "namespace packages" are what is used when you have "foo.bar" and "foo.baz" come from different distributions

[issue34534] importlib.resources does not work with packages that have no __init__.py

Eric V. Smith added the comment: What's the difference between "namespace packages and implicit non-namespace packages"? I think those are the same thing, aren't they? -- nosy: +barry, brett.cannon, eric.smith ___ Python tracker

[issue34534] importlib.resources does not work with packages that have no __init__.py

New submission from Girts Folkmanis : importlib.resources does not seem to work with packages that don't have __init__.py present. Since 3.3+ generally there is no need to create empty __init__.py, as directories are automatically treated as packages even without the file present. So my

[issue32524] Python 2.7 leaks a packages __init__.py module object on SyntaxError

Change by Segev Finer : -- keywords: +patch pull_requests: +5001 stage: -> patch review ___ Python tracker ___

[issue32524] Python 2.7 leaks a packages __init__.py module object on SyntaxError

New submission from Segev Finer <segev...@gmail.com>: With the file hello/__init__.py: ham = 123 spam()spam() I get the following: Python 2.7.14 (v2.7.14:84471935ed, Sep 16 2017, 20:19:30) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright&qu

Re: Using __init__.py

gt;> >> I wanted to know that can I use __init__.py file for adding a project >> directory to sys.path (sys.path.insert(0, directory))? > > That is the wrong way to fix this problem. It might work, for a little while, > but then something will change, or you will do something just

Re: Using __init__.py

ed by adding project directory to sys.path(). > > I wanted to know that can I use __init__.py file for adding a project > directory to sys.path (sys.path.insert(0, directory))? That is the wrong way to fix this problem. It might work, for a little while, but then something will c

Using __init__.py

to know that can I use __init__.py file for adding a project directory to sys.path (sys.path.insert(0, directory))? -- https://mail.python.org/mailman/listinfo/python-list

[issue16662] load_tests not invoked in package/__init__.py

STINNER Victor added the comment: New changeset 22d4e8fb99b16657eabfe7f9fee2d40a5ef882f6 by Victor Stinner in branch '3.6': bpo-30813: Fix unittest when hunting refleaks (#2502) (#2505) https://github.com/python/cpython/commit/22d4e8fb99b16657eabfe7f9fee2d40a5ef882f6 --

[issue16662] load_tests not invoked in package/__init__.py

STINNER Victor added the comment: New changeset 714afccf6e7644d21ce1a39e90bf83cb0c9a74f1 by Victor Stinner in branch '3.5': bpo-30813: Fix unittest when hunting refleaks (#2502) (#2506) https://github.com/python/cpython/commit/714afccf6e7644d21ce1a39e90bf83cb0c9a74f1 --

[issue16662] load_tests not invoked in package/__init__.py

Changes by STINNER Victor : -- pull_requests: +2575 ___ Python tracker ___ ___

[issue16662] load_tests not invoked in package/__init__.py

Changes by STINNER Victor : -- pull_requests: +2571 ___ Python tracker ___ ___

[issue16662] load_tests not invoked in package/__init__.py

STINNER Victor added the comment: New changeset e4f9a2d2be42d5a2cdd624f8ed7cdf5028c5fbc3 by Victor Stinner in branch 'master': bpo-30813: Fix unittest when hunting refleaks (#2502) https://github.com/python/cpython/commit/e4f9a2d2be42d5a2cdd624f8ed7cdf5028c5fbc3 --

[issue16662] load_tests not invoked in package/__init__.py

Changes by STINNER Victor : -- pull_requests: +2564 ___ Python tracker ___ ___

[issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files?

Changes by Berker Peksag : -- resolution: -> not a bug stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files?

Changes by Ned Batchelder : -- nosy: +nedbat ___ Python tracker ___ ___

[issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files?

Andrei Fokau added the comment: I was wrong. The ticket can be closed now. -- nosy: +Andrei Fokau2 ___ Python tracker ___

[issue29258] __init__.py required for pkgutil.walk_packages in python3

Changes by Brett Cannon : -- nosy: -brett.cannon ___ Python tracker ___ ___

[issue29258] __init__.py required for pkgutil.walk_packages in python3

Wolfgang Maier added the comment: > all that's required here is to eliminate the check for __init__.py from > pkgutil._iter_file_finder_modules Ok, I was exaggerating here. To do it right would require a more complex change, but that's all that's needed to get an estimate of the

[issue29258] __init__.py required for pkgutil.walk_packages in python3

Wolfgang Maier added the comment: While it is rather trivial to implement the proposed functionality - all that's required here is to eliminate the check for __init__.py from pkgutil._iter_file_finder_modules - this would have undesired impacts on, e.g., pydoc.apropos: This function would

[issue29258] __init__.py required for pkgutil.walk_packages in python3

Changes by Wolfgang Maier : -- nosy: +wolma ___ Python tracker ___

[issue29716] Python 3 Module doc still sounds like __init__.py is required

Brett Cannon added the comment: I've gone ahead and closed this. Thanks for taking the time to check in on this, James! -- nosy: +brett.cannon resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker

[issue29716] Python 3 Module doc still sounds like __init__.py is required

Changes by Marco Buttu : -- nosy: +marco.buttu ___ Python tracker ___ ___

[issue29716] Python 3 Module doc still sounds like __init__.py is required

INADA Naoki added the comment: I think so. namespace package is topic for packaging ecosystem developers, like setuptools and pip. Normal python programmer shouldn't omit __init__.py. Python tutorial is for people who want to be normal python programmer. 2017/03/04 午後1:53 "James O&

[issue29716] Python 3 Module doc still sounds like __init__.py is required

James O added the comment: Ah, I didn't realize some tools depended on it. Should I set the status to closed? (like I said, I'm new to this) -- ___ Python tracker

[issue29716] Python 3 Module doc still sounds like __init__.py is required

INADA Naoki added the comment: namespace package is very advanced topic. I don't think tutorial should mention it. Putting __init__.py always in normal package is highly recommended. Otherwise, many tools can't distinguish normal directory and python package. 2017/03/04 午前6:26 "James O&

[issue29716] Python 3 Module doc still sounds like __init__.py is required

New submission from James O: PEP 420 says "Allowing implicit namespace packages means that the requirement to provide an __init__.py file can be dropped completely..." (as described here: http://stackoverflow.com/questions/37139786/is-init-py-not-required-for-packages-i

[issue28425] Python3 ignores __init__.py that are links to /dev/null

Douglas Greiman added the comment: Bazel has been updated to no longer create symlinks to /dev/null https://github.com/bazelbuild/bazel/issues/1458 -- ___ Python tracker

[issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files?

INADA Naoki added the comment: When using import, (namespace) package name is explicitly specified. Only specified name is searched. In test loader's case, there are no such limit. Loader may search millions of completely unrelated directories. It may include directories in NFS or samba over

[issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files?

INADA Naoki added the comment: I'm afraid this change makes testloader searches unrelated directory contains massive files (like node_modules). I don't think loading all tests from whole namespace package is not usual use case. -- nosy: +inada.naoki

[issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files?

Andrei Fokau added the comment: Removing `--with-pydebug` parameter helped to avoid issue with _crypto extension. Testing Django with that build produced result identical to 3.6.0: Ran 11723 tests in 83.897s OK (skipped=1149, expected failures=4) The patch is ready for review. --

[issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files?

Andrei Fokau added the comment: Testing with Django seems indicated an issue. I did the following with 3.6 patch (cherry-pick to bea9d2f64) on macOS with OpenSSL installed via Homebrew: $ cd /Users/andrei/Python/cpython/ $ export CFLAGS="-I/usr/local/opt/openssl/include" $ export

[issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files?

Andrei Fokau added the comment: Ok, testing with Django was a bad idea due to compatibility with 3.7. I could apply it to 3.6.x and test Django with it. Is there a better idea how to trial the test discovery? -- ___ Python tracker

[issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files?

Andrei Fokau added the comment: Docs promise already support for namespace packages, so just a minor clarification was done. -- ___ Python tracker ___

[issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files?

Changes by Mariatta Wijaya : -- versions: -Python 3.4 ___ Python tracker ___ ___

[issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files?

Changes by Serhiy Storchaka : -- nosy: +ezio.melotti, michael.foord, rbcollins stage: -> patch review ___ Python tracker

[issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files?

Andrei Fokau added the comment: Alright, I made an initial fix in #282. I believe that I still need to update the docs and run it with something big, e.g. Django. -- ___ Python tracker

[issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files?

Changes by Roundup Robot : -- pull_requests: +251 ___ Python tracker ___

[issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files?

def patched_isfile(path): return str(path).endswith('__init__.py') or original_isfile(path) os.path.isfile = patched_isfile result = super()._find_test_path(full_path=full_path, pattern=pattern, namespace=namespace

[issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files?

New submission from Andrei Fokau: Hi, As far as I see, unittest.TestLoader doesn't search in PEP-420 packages, i.e. packages without __init__.py files. Is there some motivation behind this, or the loader was just not yet adapted for Implicit Namespace Packages? -- components: Tests

[issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files?

Changes by Barry A. Warsaw : -- nosy: +barry ___ Python tracker ___ ___ Python-bugs-list

[issue29258] __init__.py required for pkgutil.walk_packages in python3

Changes by Serhiy Storchaka : -- nosy: +brett.cannon, eric.snow, ncoghlan versions: -Python 3.3, Python 3.4 ___ Python tracker

[issue29258] __init__.py required for pkgutil.walk_packages in python3

New submission from Anthony Sottile: PEP420 makes __init__.py files optional: https://docs.python.org/3/whatsnew/3.3.html#pep-420-implicit-namespace-packages Though it seems without them, pkgutil.walk_packages does not function as desired: https://docs.python.org/3/library/pkgutil.html

[issue28425] Python3 ignores __init__.py that are links to /dev/null

Brett Cannon added the comment: Those results are expected as passing in a file by path means it's just read by open() and then passed to exec() while the others pass through import itself which has the os.path.isfile() check. Since this is a change from Python 2.7 I would be willing to look

[issue28425] Python3 ignores __init__.py that are links to /dev/null

Douglas Greiman added the comment: To be thorough, I looked at non __init__.py source files as well, with erratic results. And who knows what would happen on other OS's. So a blanket "must be a regular file" seems reasonable. $ ls -l b.* lrwxrwxrwx 1 dgreiman eng 9 Dec 9 16:05 b.

[issue28425] Python3 ignores __init__.py that are links to /dev/null

Brett Cannon added the comment: There's probably a place to mention it in the language spec for import and/or importlib. -- ___ Python tracker ___

  1   2   3   4   5   >