[issue4945] json checks True/False by identity, not boolean value

Chris Jerdonek added the comment: You're right. My mistake. :) -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[issue4945] json checks True/False by identity, not boolean value

Mark Dickinson added the comment: > Changing "If *allow_nan* is ``True``" to "equals ``True``" I don't think that's any more accurate. Many Python objects are 'true' but not equal to 'True' (e.g., nonempty collections). -- ___ Python tracker

[issue4945] json checks True/False by identity, not boolean value

Chris Jerdonek added the comment: Ezio told me my previous comment was hard to understand. For the record, what I meant was that if you have a statement like, "If *allow_nan* is ``True``, then Otherwise, ...," then this can be read to mean that something like 1 for *allow_nan* would be

[issue16565] Increase Py_AddPendingCall array size

Antoine Pitrou added the comment: > If I try to acquire the GIL PyGILState_Ensure() call > PyObject_CallObject and release the GIL in the aio_completion_handler > function a SEGFAULT occurs in 2.7.3 but not in 3.3 and newer.. Well, can you post a traceback? -- _

[issue16574] clarify policy on updates to final peps

Nick Coghlan added the comment: Yeah, I agree the "in general" in PEP 1 is enough of a caveat. The unwritten rules in this particular case are that if something in a PEP is important enough to be permanently referenced, then it's important enough to be part of the language spec (either the mai

[issue16576] ctypes: structure with bitfields as argument

Armin Rigo added the comment: The same misbehavior occurs if the structures are packed ("_pack_ = 1"). Attached in test186_lib.tgz. -- Added file: http://bugs.python.org/file28157/test186_lib.tgz ___ Python tracker

[issue7976] warnings should provide a public API for accessing its option parsing code

Éric Araujo added the comment: No problem! :) -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue16576] ctypes: structure with bitfields as argument

Changes by Alex Gaynor : -- nosy: +alex ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/

[issue16576] ctypes: structure with bitfields as argument

New submission from Armin Rigo: ctypes pretends to support passing arguments to C functions that are structures containing bitfields, or at least does not explicitly forbid it. But doing so results in misbehavior or segfaults in libffi itself. Indeed, libffi has no support for this, and ctyp

[issue16575] ctypes: unions as arguments

Changes by Armin Rigo : -- type: -> crash ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue16575] ctypes: unions as arguments

Changes by Alex Gaynor : -- nosy: +alex ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/

[issue7976] warnings should provide a public API for accessing its option parsing code

Bruno Dupuis added the comment: Éric, I saw the `review` link just after I submited the second patch, and I read your comments. I'll do the changes. Sorry, I still have to learn the tools and processes. -- ___ Python tracker

[issue16575] ctypes: unions as arguments

New submission from Armin Rigo: ctypes pretends to support passing arguments to C functions that are unions (not pointers to unions), but that's a lie. In fact, the underlying libffi does not support it. The attached example misbehaves on Linux x86-64. -- components: ctypes files: te

[issue16495] bytes_decode() unnecessarily examines encoding

Changes by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue13094] Need Programming FAQ entry for the behavior of closures

Changes by Ezio Melotti : -- assignee: docs@python -> ezio.melotti ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue16574] clarify policy on updates to final peps

Chris Jerdonek added the comment: > I think the gist here is that “in general” is good enough, given that there > is unwritten consensus about what edits are possible in the developers’ heads. As I said, I'm okay with keeping the PEP as is (with "in general," etc) provided a clarification is d

[issue7976] warnings should provide a public API for accessing its option parsing code

Bruno Dupuis added the comment: I added the documentation with a recipe. -- Added file: http://bugs.python.org/file28154/warnings_opt_parse_API-2.patch ___ Python tracker ___

[issue16568] allow constructors to be documented separately from class

Ezio Melotti added the comment: > For all the built-in types, I see the value now. The same applies for non built-in types too though (e.g. http://docs.python.org/3.4/library/collections.html). The only difference is that the built-in ones have entries in functions.rst and use more links. >

[issue16568] allow constructors to be documented separately from class

Éric Araujo added the comment: For all the built-in types, I see the value now. Thinking aloud: Separating the namespaces used by the str and func roles would probably require too many changes in Sphinx. The current way is to use the function directive to document the class/constructor usage

[issue16574] clarify policy on updates to final peps

Ezio Melotti added the comment: FTR the reason I suggested to modify PEP 362 is that we are linking to it from the docs. This means that people will go and read the PEP looking for clarifications, so the PEP should be clear. In this regard I see the PEP (or at least the relevant section) as

[issue16568] allow constructors to be documented separately from class

Ezio Melotti added the comment: This came up while documenting the str type in datamodel.rst (IIRC), and linking to it from functions.rst. On one hand you want to say what the str type is, on the other hand you want to document the constructor and explain how can you use str() to obtain str o

[issue16574] clarify policy on updates to final peps

Éric Araujo added the comment: I think the gist here is that “in general” is good enough, given that there is unwritten consensus about what edits are possible in the developers’ heads. Most of the time unwritten knowledge is not good, but (if I get what Martin and Barry mean correctly) for P

[issue16568] allow constructors to be documented separately from class

Éric Araujo added the comment: I’m interested in an explanation of the value of doing this. In the threading docs for example, the classes (i.e. initializers) are documented in one section, with awkward links to “Thread objects”, “Lock objects”, etc. This felt much more cumbersome to me than

[issue16568] allow constructors to be documented separately from class

Changes by Ezio Melotti : -- nosy: +eric.araujo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue16574] clarify policy on updates to final peps

Brett Cannon added the comment: Once PEPs reach their final status, I view them basically done if there is more official docs. For instance, I updated PEP 302 because the import and importlib docs were not as thorough as they are now thanks to Barry. But now that we have proper docs I don't pl

[issue15043] test_gdb is disallowed by default security settings in Fedora 17

R. David Murray added the comment: Since it looks like that is your buildbot, can you do some command line testing to see what is going wrong with the gdb invocation? I'm wondering if perhaps this feature was backported as a security patch, so that the gdb version check is an insufficient che

[issue16549] regression: -m json.tool module is broken

Roundup Robot added the comment: New changeset 4102c1a02417 by Ezio Melotti in branch '2.7': #16549: fix test failures on Windows. http://hg.python.org/cpython/rev/4102c1a02417 New changeset 4ec9f0b0f8f1 by Ezio Melotti in branch '3.2': #16549: fix test failures on Windows. http://hg.python.org/

[issue7976] warnings should provide a public API for accessing its option parsing code

Bruno Dupuis added the comment: Thanks, I'll write the doc. Now, I'm not sure that keeping _OptionError as WarningsOptParsingError base class is a good idea. I can't see any use case to catch this exception outside the module and I'm quite sure nobody ever has. However, I tend to be over-cons

[issue16574] clarify policy on updates to final peps

Chris Jerdonek added the comment: By the way, I don't especially care if the clarification goes in the PEP itself or not. What's more important is that it be documented *somewhere* (which could also be the devguide, for example). My interest in knowing the process is genuine. -- __

[issue16565] Increase Py_AddPendingCall array size

Felipe Cruz added the comment: Just confirmed that signals is not a viable option. Is too slow, as Antonie already pointed. It's almost 5 times slower than with SIGEV_THREAD. The problem now is: If I use Py_AddPendingCall, the tests can hang sometimes. I can still follow Amaury suggestion to

[issue16574] clarify policy on updates to final peps

Chris Jerdonek added the comment: Okay, so in a comment to issue 15990, Ezio suggested that some clarifying changes to PEP 362 might be worth making. How would I (or someone else) go about doing that? Where would they begin? I think this recent e-mail from Nick applies: http://mail.python.o

[issue16574] clarify policy on updates to final peps

Éric Araujo added the comment: Right, “in general” is good enough to capture what we do. Chris, closing? -- ___ Python tracker ___ __

[issue7976] warnings should provide a public API for accessing its option parsing code

Éric Araujo added the comment: About the name: I think it’s good. “Warnings” is at the start, meaning this is related to the warnings system; an exception with “Warning” at the end would however not be good. I started to comment that the name could be just OptionParsingError, given that we d

[issue16574] clarify policy on updates to final peps

Barry A. Warsaw added the comment: On Nov 29, 2012, at 12:56 AM, Chris Jerdonek wrote: > >Currently, PEP 1 says, "In general, Standards track PEPs are no longer >modified after they have reached the Final state." I agree w/mvl. This is still true, and it doesn't mean PEPs can't be modified aft

[issue7976] warnings should provide a public API for accessing its option parsing code

Éric Araujo added the comment: Thanks! I reviewed the patch. You should have received an email, or you can follow the “review” link on the right of your patch in the list of files. Can you add documentation? -- stage: needs patch -> patch review _

[issue7976] warnings should provide a public API for accessing its option parsing code

Bruno Dupuis added the comment: Patch attached. I just exposed _setoption() as process_option() so that the user can manage execptions as she wants but she has to make his own loop. `_OptionError` is exposed as `WarningsOptParsingError`. I'm not satisfied with this name as it is quite long an

[issue16333] Trailing whitespace in json dump when using indent

Éric Araujo added the comment: All right. :) -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue16574] clarify policy on updates to final peps

Éric Araujo added the comment: I think Brett edited PEP 302 a decade after its acceptance. -- nosy: +brett.cannon ___ Python tracker ___ _

[issue16574] clarify policy on updates to final peps

Chris Jerdonek added the comment: Are you saying that PEP 1 is correct and that Final PEPs should not be modified, or that the PEP isn't correct but that it shouldn't be modified? If the latter, for someone new it's not clear whether minor clarifications are permitted and if so, how to go abou

[issue16574] clarify policy on updates to final peps

Martin v. Löwis added the comment: I don't think this needs clarification. The status quo is fine. -- nosy: +loewis ___ Python tracker ___ ___

[issue16572] Bad multi-inheritance support in some libs like threading or multiprocessing

Richard Oudkerk added the comment: > But I think the problem remains: do you agree that Classes should include > a super() call in their __init__ ? No, I don't. I think super() is an attractive nuisance which is difficult to use correctly in an __init__() method, except in the trivial case wh

[issue16333] Trailing whitespace in json dump when using indent

Ezio Melotti added the comment: > I noticed in the check-in mail that you added the note before > the description of the separators argument The note is just after the description of the indent argument, because it's relevant only when a indent value is specified. > Regular text would have loo

[issue16333] Trailing whitespace in json dump when using indent

Éric Araujo added the comment: Ezio, I noticed in the check-in mail that you added the note before the description of the separators argument (specifically, the descrition of what it does when it’s a tuple). Maybe it would flow best to move the note after that part? Also, I don’t think this

[issue15990] solidify argument/parameter terminology

Chris Jerdonek added the comment: I just created issue 16574 to clarify PEP 1 with regard to the above. -- ___ Python tracker ___ ___

[issue16574] clarify policy on updates to final peps

New submission from Chris Jerdonek: This issue is to clarify the policy in PEP 1 regarding non-substantive changes to PEPs in the Final state (minor clarifications, rephrasings, etc). Currently, PEP 1 says, "In general, Standards track PEPs are no longer modified after they have reached the Fi

[issue16476] Trailing spaces in pretty-printed JSON

Changes by Ezio Melotti : -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue16333] Trailing whitespace in json dump when using indent

Roundup Robot added the comment: New changeset 1e3b01c52aee by Ezio Melotti in branch 'default': #16333: add Misc/NEWS entry for e63ac05ccfa8. http://hg.python.org/cpython/rev/1e3b01c52aee -- ___ Python tracker ___

[issue16549] regression: -m json.tool module is broken

Ezio Melotti added the comment: Fixed, thanks for the patches! -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: +Python 2.7 ___ Python tracker

[issue16549] regression: -m json.tool module is broken

Roundup Robot added the comment: New changeset 08e5973fdc7e by Ezio Melotti in branch '2.7': #16549: Add tests for json.tools. Initial patch by Berker Peksag and Serhiy Storchaka. http://hg.python.org/cpython/rev/08e5973fdc7e New changeset 44c544809e6c by Ezio Melotti in branch '3.2': #16549:

[issue16476] Trailing spaces in pretty-printed JSON

Ezio Melotti added the comment: I fixed this separately from #16333. In the "default" branch this got fixed by #16333 already. Thanks for the report! -- assignee: -> ezio.melotti components: +Library (Lib) resolution: duplicate -> fixed versions: +Python 3.2, Python 3.3, Python 3.4 ___

[issue16476] Trailing spaces in pretty-printed JSON

Roundup Robot added the comment: New changeset fa277ab588de by Ezio Melotti in branch '2.7': #16476: Fix json.tool to avoid including trailing whitespace. http://hg.python.org/cpython/rev/fa277ab588de New changeset 6996a53f13ce by Ezio Melotti in branch '3.2': #16476: Fix json.tool to avoid incl

[issue16572] Bad multi-inheritance support in some libs like threading or multiprocessing

Thomas Chiroux added the comment: That's right. Lets consider this 'patch' was more for illustrating my example (like: this kind of modification may work) than to add directly into python core module... (which i'm not capable of) But I think the problem remains: do you agree that Classes shou

[issue16534] -Olimit: unsupported option: warnings and ./configure failures

Stefan Krah added the comment: ./configure is fixed, sys.float_repr_style is 'short' now. I agree that it's not worth backporting Py_NAN fixes; I guess we can close this then. -- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed versions: -Python 3.

[issue16476] Trailing spaces in pretty-printed JSON

Changes by Ezio Melotti : -- status: closed -> open ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue16573] 2to3 should treat enumerate like sorted for zip, map, filter, dict, xrange

New submission from Jonathan Kotta: enumerate() is a "consuming_call", as defined in fixer_util.py, because it takes an iterable (not necessarily a collection). Therefore whenever we have something like enumerate(zip(...)), we don't need to replace it with enumerate(list(zip(...))) in 2to3, b

[issue15990] solidify argument/parameter terminology

Chris Jerdonek added the comment: Thanks for the clarification. I will create an issue to clarify that part of PEP 1. It should also say who is allowed to make such changes and whether/from whom approval is necessary, etc. -- ___ Python tracker <

[issue16572] Bad multi-inheritance support in some libs like threading or multiprocessing

Richard Oudkerk added the comment: The patch is liable to break programs which explicitly call base constructors because the constructor will be called more than once. It also assumes that the __init__() method of all base classes should be called with no arguments (other than self). That is

[issue16534] -Olimit: unsupported option: warnings and ./configure failures

Roundup Robot added the comment: New changeset 5697387b0089 by Stefan Krah in branch '2.7': Issue #16534: On HP-UX ac_cv_olimit_ok=yes is a false positive. http://hg.python.org/cpython/rev/5697387b0089 -- nosy: +python-dev ___ Python tracker

[issue15043] test_gdb is disallowed by default security settings in Fedora 17

Stefan Krah added the comment: The test still seems to fail on Fedora 16: http://buildbot.python.org/all/builders/AMD64%20Fedora%20without%20threads%202.7/builds/906/steps/test/logs/stdio -- nosy: +skrah ___ Python tracker

[issue16333] Trailing whitespace in json dump when using indent

Ezio Melotti added the comment: I committed the patches leaving out the json.tool changes. I will commit those as part of #16476. Thanks Serhiy for the patches! -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed

[issue16333] Trailing whitespace in json dump when using indent

Roundup Robot added the comment: New changeset e7919cf9b5e5 by Ezio Melotti in branch 'default': #16333: fix example in docstring. http://hg.python.org/cpython/rev/e7919cf9b5e5 -- ___ Python tracker ___

[issue16333] Trailing whitespace in json dump when using indent

Roundup Robot added the comment: New changeset 78bad589f205 by Ezio Melotti in branch '2.7': #16333: document a way to get rid of trailing whitespace when indent is used. http://hg.python.org/cpython/rev/78bad589f205 New changeset 2a5b183ac3cd by Ezio Melotti in branch '3.2': #16333: document a

[issue16534] -Olimit: unsupported option: warnings and ./configure failures

Stefan Krah added the comment: The issue here is that the BASECFLAGS variable contains the mysterious option -Olimit 1500, which makes the X87_DOUBLE_ROUNDING test fail (i.e. X87_DOUBLE_ROUNDING is set to true when it should be false). When BASECFLAGS is unset, test_float passes. -Olimit giv

[issue16572] Bad multi-inheritance support in some libs like threading or multiprocessing

Thomas Chiroux added the comment: updated diff file, unified format -- Added file: http://bugs.python.org/file28151/diff_unified_threading.py_2.7.patch ___ Python tracker ___ ___

[issue16572] Bad multi-inheritance support in some libs like threading or multiprocessing

Serhiy Storchaka added the comment: Can you please provide a diff in unified format? I don't see any super() in Lib/threading.py. -- nosy: +serhiy.storchaka ___ Python tracker _

[issue15990] solidify argument/parameter terminology

Ezio Melotti added the comment: The PEPs don't undergo major changes, but AFAIU typo fixes and minor clarifications/rephrasing are allowed. -- ___ Python tracker ___ ___

[issue15990] solidify argument/parameter terminology

Éric Araujo added the comment: PEP 1 doesn’t reflect current practice then. -- ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue9176] module termios doesn't build on HP-UX

Stefan Krah added the comment: This should be fixed now (see #6308). -- nosy: +skrah resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> termios fix for QNX breaks HP-UX ___ Python tracker

[issue16572] Bad multi-inheritance support in some libs like threading or multiprocessing

New submission from Thomas Chiroux: when using multi-inheritance and super() in __init__(), super() tries to run each constructor once. For this to work correctly, it is needed to call super() in each constructor, including for Classes directly inherited from object. The sample below does not

[issue15990] solidify argument/parameter terminology

Chris Jerdonek added the comment: > Note that I took this from the pep. The pep could get the same clarification > (unless I made it more confusing than it was). Reading the following, it seems that PEPs aren't generally clarified after becoming Final (as is PEP 362): "In general, Standards t

[issue16333] Trailing whitespace in json dump when using indent

Changes by Éric Araujo : -- components: +Documentation versions: +Python 2.7, Python 3.2, Python 3.3 ___ Python tracker ___ ___ Python

[issue16333] Trailing whitespace in json dump when using indent

Serhiy Storchaka added the comment: Please left 2.7, 3.2 and 3.3 for documentation changes (the second patch). -- ___ Python tracker ___ _

[issue10052] Python/dtoa.c:158: #error "Failed to find an exact-width 32-bit integer type" (FreeBSD 4.11 + gcc 2.95.4)

Changes by Mark Dickinson : -- versions: +Python 3.3, Python 3.4 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue10052] Python/dtoa.c:158: #error "Failed to find an exact-width 32-bit integer type" (FreeBSD 4.11 + gcc 2.95.4)

Changes by Mark Dickinson : -- assignee: -> mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: htt

[issue10052] Python/dtoa.c:158: #error "Failed to find an exact-width 32-bit integer type" (FreeBSD 4.11 + gcc 2.95.4)

Mark Dickinson added the comment: This is also an issue on the Tru64 / alpha on Snakebite: that platform has inttypes.h but no stdint.h, and inttypes.h has typedefs for uint32_t and friends, but no defines for UINT32_MAX, etc. So the pyport.h check: #if (defined UINT32_MAX || defined uint32_

[issue16333] Trailing whitespace in json dump when using indent

Éric Araujo added the comment: I agree with RDM. -- versions: -Python 2.7, Python 3.2, Python 3.3 ___ Python tracker ___ ___ Python-b

[issue10052] Python/dtoa.c:158: #error "Failed to find an exact-width 32-bit integer type" (FreeBSD 4.11 + gcc 2.95.4)

Changes by Trent Nelson : -- nosy: +trent ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.or

[issue16333] Trailing whitespace in json dump when using indent

R. David Murray added the comment: Yes, I think the risk of breaking doctests (and breaking them in a very mysterious way...trailing spaces) is high enough that we shouldn't backport the fix, unfortunately. -- ___ Python tracker

[issue16333] Trailing whitespace in json dump when using indent

Ezio Melotti added the comment: > There is no promise of binary compatibility for pretty-printed data. This was the reason that made me consider backporting this on the other branches. After all I expect this feature to be used from the terminal, while printing JSON in a human-friendly format

[issue4806] Function calls taking a generator as star argument can mask TypeErrors in the generator

Changes by Chris Kaynor : -- nosy: +DragonFireCK ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue16565] Increase Py_AddPendingCall array size

Antoine Pitrou added the comment: I just took a look at https://github.com/felipecruz/pyaio/commit/127372ba0a6dbca4045256dcd653789ee35f6a78 and it looks a bit silly to me: if the completion handler is called in a separate thread, then the completion handler can just take the GIL and put the r

[issue16565] Increase Py_AddPendingCall array size

Amaury Forgeot d'Arc added the comment: This array would still have a fixed size. Could you arrange your code so that you enqueue pending calls elsewhere, and call Py_AddPendingCall only once until the pending items have been processed? -- nosy: +amaury.forgeotdarc

[issue16568] allow constructors to be documented separately from class

Changes by Ezio Melotti : -- nosy: +georg.brandl ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue16568] allow constructors to be documented separately from class

Ezio Melotti added the comment: I was wondering if this should be called initializer instead of constructor. Another idea is to keep using the "method" directive and use :initializer: to differentiate it from the others. This might be easier to implement, but OTOH is not consistent with the

[issue11076] Iterable argparse Namespace

Chris Jerdonek added the comment: Following up Andrew's last comment, for the record, it looks like this was done as part of issue 8982. -- nosy: +chris.jerdonek superseder: -> argparse docs cross reference Namespace as a class but the Namespace class is not documented __

[issue16570] Absolute imports fail to take full path into account?

Eric Snow added the comment: oops. too slow. :) -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue16570] Absolute imports fail to take full path into account?

Eric Snow added the comment: Things are working as they should here. The key points: * when running a script, sys.path[0] is set to the script's directory (with no script sys.path[0] is set to the CWD, see issue13475), * pkg/tests/__init__.py is loaded and executed twice: once as the script un

[issue16571] Iterating over inconsistently-indented code block causes execution of code only on last iteration of loop

Brian Berard added the comment: @nedbat I'm able to run that code as is and receive no such error. With the -tt option, I do receive an indentation error. I will keep that in mind. -- ___ Python tracker __

[issue16571] Iterating over inconsistently-indented code block causes execution of code only on last iteration of loop

Ned Batchelder added the comment: @Brian: Your code doesn't run in Python 2.7 as you've shown it, it produces an IndentationError. If your code is actually different, and does run, try running it with the -tt flag on Python, which will warn about inconsistent indentation. -- nosy: +

[issue16570] Absolute imports fail to take full path into account?

Brett Cannon added the comment: Glad it makes sense now. =) I was writing my reply while you sent yours. Anyway, your PYTHONPATH setting goes on to sys.path *after* the directory containing the script being executed. This is so that when you execute Python code somewhere it will get the local

[issue16570] Absolute imports fail to take full path into account?

Brett Cannon added the comment: When you execute a module on the command line, sys.path[0] is set to that containing directory (e.g. pkg/tests in your example; just have pkg/tests/__init__.py print out sys.path to see what I mean). ``import http`` is going to look on sys.path no matter what, a

[issue16570] Absolute imports fail to take full path into account?

Dirkjan Ochtman added the comment: Never mind, I get what you're getting at now. I thought that the cwd was added to the sys.path, not the containing directory for the executed script. I'll look into using __main__. Thanks! -- ___ Python tracker

[issue16570] Absolute imports fail to take full path into account?

Dirkjan Ochtman added the comment: It's not nonsensical. Something exactly like it came up while I was looking into porting couchdb-python to Python 3. couchdb-python has had a couchdb.http module for a while now; it didn't start clashing with the stdlib until Python 3. Also, I don't understan

[issue11076] Iterable argparse Namespace

Andrew Svetlov added the comment: Sorry, looks like it work already was done. Reverting: c008f070f88a 814403d824a5 ddcf09a348ca -- nosy: +asvetlov resolution: -> duplicate stage: patch review -> committed/rejected status: open -> closed ___ Python t

[issue16570] Absolute imports fail to take full path into account?

Brett Cannon added the comment: This test example is nonsensical. You are directly executing a package which leads to pkg/tests being put in sys.path first. That means you end up with http in pkg/tests masking the one in the stdlib, which causes your ``from http.clients import HTTPConnection``

[issue11076] Iterable argparse Namespace

Roundup Robot added the comment: New changeset bbecbcff0ce4 by Andrew Svetlov in branch '3.2': Issue #11076: document the way to convert argparse.Namespace to a dict. http://hg.python.org/cpython/rev/bbecbcff0ce4 New changeset ee4e31845977 by Andrew Svetlov in branch '3.3': Merge issue #11076: d

[issue15627] Add a method to importlib.abc.SourceLoader for converting source to a code object

Brett Cannon added the comment: It might not be compulsory, but how else are you going to get a code object? Then again, get_code() kind of codifies the use of the word "code" for methods that return a code object. So if you want to do the work to change the name then go ahead. -- __

[issue15990] solidify argument/parameter terminology

Changes by Guido van Rossum : -- nosy: -gvanrossum, python-dev ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue16474] More code coverage for imp module

Andrew Svetlov added the comment: I think nothing bad to push additional tests into 3.3 also. -- ___ Python tracker ___ ___ Python-bug

[issue16571] Iterating over inconsistently-indented code block causes execution of code only on last iteration of loop

Changes by Serhiy Storchaka : -- stage: -> committed/rejected ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

  1   2   >