[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

[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

[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 _

[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: 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

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

[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

[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: 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. -- __

[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

[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/

[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

[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

[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

[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

[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

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

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

É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

[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. >

[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 ___

[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

[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

[issue16495] bytes_decode() unnecessarily examines encoding

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

[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

[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

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

[issue16575] ctypes: unions as arguments

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

[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

[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/

[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

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

[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

[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? -- _

[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

[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: You're right. My mistake. :) -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

<    1   2