[issue22983] Cookie parsing should be more permissive
Changes by Waldemar Parzonka waldemar.parzo...@gmail.com: -- nosy: +Waldemar.Parzonka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22983 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22968] Lib/types.py nit: isinstance != PyType_IsSubtype
Greg Turner added the comment: Just added a commit message. -- Added file: http://bugs.python.org/file37349/fix_types_calculate_meta_v3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22968 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22968] Lib/types.py nit: isinstance != PyType_IsSubtype
Greg Turner added the comment: Here are some tests for this... first, some tests that pass right now and demonstrate, I think, correctness of the second batch of tests. -- Added file: http://bugs.python.org/file37350/test_virtual_metaclasses.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22968 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22968] Lib/types.py nit: isinstance != PyType_IsSubtype
Greg Turner added the comment: And some analogous tests for types.py, which don't pass without fix_types_calculate_meta_v3.patch. -- Added file: http://bugs.python.org/file37351/test_virtual_metaclasses_in_types_module.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22968 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22968] Lib/types.py nit: isinstance != PyType_IsSubtype
Greg Turner added the comment: And some analogous tests for types.py, which don't pass without fix_types_calculate_meta_v3.patch. -- Added file: http://bugs.python.org/file37352/test_virtual_metaclasses_in_types_module.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22968 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22987] ssl module documentation: incorrect compatibility matrix
New submission from Kali Kaneko: The SSLv23 row that can be read in the socket creation section in the documentation for the ssl module looks incorrect: https://docs.python.org/2.7/library/ssl.html#socket-creation by my tests (with python 2.7.8) that row should read: yes no yes yes yes yes instead of: yes no yes no no no as it does now. Since a client specifying SSLv23 should be (and it seems to be) able to negotiate the highest available version that the server can offer, no matter if the server has chosen a tls version. Is this an error in the documentation, or is there any situation in which the current values hold true? -- assignee: docs@python components: Documentation messages: 232078 nosy: docs@python, kali priority: normal severity: normal status: open title: ssl module documentation: incorrect compatibility matrix versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22987 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22987] ssl module documentation: incorrect compatibility matrix
Alex Gaynor added the comment: I agree this is a bug, but I believe the correct output is: no yes yes yes yes yes -- nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22987 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22987] ssl module documentation: incorrect compatibility matrix
Antoine Pitrou added the comment: Alex is right. The current doc was valid for older OpenSSL versions, which sent a SSLv2 hello with SSLv23. Reference from the OpenSSL docs: If the cipher list does not contain any SSLv2 ciphersuites (the default cipher list does not) or extensions are required (for example server name) a client will send out TLSv1 client hello messages including extensions and will indicate that it also understands TLSv1.1, TLSv1.2 and permits a fallback to SSLv3. A server will support SSLv3, TLSv1, TLSv1.1 and TLSv1.2 protocols. (https://www.openssl.org/docs/ssl/SSL_CTX_new.html) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22987 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22988] No error when yielding from `finally`
New submission from Felipe: This bug report is the opposite of issue #14718. The interpreter did not raise an error when it encountered a `yield` expression inside the `finally` part of a `try/finally` statement. My system's info: Python 3.4.2 (v3.4.2:ab2c023a9432, Oct 6 2014, 22:15:05) [MSC v.1600 32 bit (Intel)] on win32 More detail === My interpreter does not raise any errors when yielding from a `finally` block. The documentation states, Yield expressions are allowed in the try clause of a try ... finally construct.[1] Though not explicitly stated, the suggestion is that `yield` is not allowed in the `finally` clause. Issue #14718 suggests that this interpretation is correct. Not raising an exception for `yield` inside of `finally` can cause incorrect behavior when the generator raises its own unhandled exception in the `try` block. PEP 342 says, If the generator raises an uncaught exception, it is propagated to send()'s caller. In this case, however, the exception gets paused at the `yield` expression, instead of propagating to the caller. Here's an example that can clarify the issue: def f(): # I expected this function not to compile ... try: ... raise ValueError ... finally: ... yield 1 # Execution freezes here instead of propagating the ValueError ... yield done ... g = f() g.send(None) # PEP 342 would require ValueError to be raised here 1 g.send(1) Traceback (most recent call last): File stdin, line 1, in module File stdin, line 3, in f2 ValueError I may be arguing over the meaning of uncaught exception, but I expected (given that the function compiles and doesn't raise a `RuntimeError`) the `ValueError` to propagate rather than get frozen. Example 2 --- The second example is adapted from http://bugs.python.org/issue14718, where the submitter received a `RuntimeError`, but I did not: def f2(): # I also expected this function not to compile ... try: ... yield 1 ... finally: ... yield 4 ... g = f() # issue 14718 suggests this should raise RuntimeError next(g) 1 next(g) 4 next(g) Traceback (most recent call last): File stdin, line 1, in module StopIteration Possible resolution: = 1. Enforce the ban on `yield` inside a finally `clause`. It seems like this should already be happening, so I'm not sure why my version isn't performing the check. This could be a run-time check (which seems like it may already be implemented), but I think this could even be a compile-time check (by looking at the AST). 2. Clarify the documentation to make explicit the ban on the use of `yield` inside the `finally` clause, and specify what type of error it will raise (i.e., `SyntaxError` or `RuntimeError`? or something else?). I'll submit a patch for 2 if there's support for this change, and I will work on 1 if someone can point me in the right direction. I've engaged with the C source relating to the different protocols, but have never looked through the compiler/VM. Notes [1] https://docs.python.org/3.4/reference/expressions.html#yield-expressions -- components: Interpreter Core messages: 232081 nosy: fov priority: normal severity: normal status: open title: No error when yielding from `finally` type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22988 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22988] No error when yielding from `finally`
Changes by Ethan Furman et...@stoneleaf.us: -- nosy: +ethan.furman, giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22988 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22988] No error when yielding from `finally`
Guido van Rossum added the comment: There is no prohibition in the language against yield in a finally block. It may not be a good idea, but the behavior you see is all as it should be. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22988 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22989] HTTPResponse.msg not as documented
New submission from Paul Hartmann:
HTTPResponse.msg is documented as a http.client.HTTPMessage object containing
the headers of the response [1].
But in fact this is a string containing the status code:
import urllib.request
req=urllib.request.urlopen('http://heise.de')
content = req.read()
type(req.msg)
class 'str'
req.msg
'OK'
This value is apparently overriden in urllib/request.py:
./urllib/request.py:1246:# This line replaces the .msg attribute of the
HTTPResponse
./urllib/request.py-1247-# with .headers, because urllib clients expect
the response to
./urllib/request.py:1248:# have the reason in .msg. It would be good
to mark this
./urllib/request.py-1249-# attribute is deprecated and get then to use
info() or
./urllib/request.py-1250-# .headers.
./urllib/request.py:1251:r.msg = r.reason
Anyhow, it should be documented, that is not safe to retrieve the headers with
HTTPResponse.msg and maybe add HTTPResponse.headers to the documentation.
[1] https://docs.python.org/3/library/http.client.html
--
assignee: docs@python
components: Documentation
messages: 232083
nosy: bastik, docs@python
priority: normal
severity: normal
status: open
title: HTTPResponse.msg not as documented
versions: Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22989
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22988] No error when yielding from `finally`
R. David Murray added the comment: FIlipe, in case you hadn't noticed, the reason for the error in the other issue is that the generator was closed when it got garbage collected, and it ignored the close (executed a yield after the close). Thus the error message there is accurate and expected, just as (as Guido said) the behavior here is consistent with the combined semantics of generators and try/finally. Do you want to suggest an improvement to the docs? It may be that we'll decide a change is more confusing than helpful, but we'll need someone to suggest a wording to decide that. -- assignee: - docs@python components: +Documentation -Interpreter Core nosy: +docs@python, r.david.murray versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22988 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22989] HTTPResponse.msg not as documented
Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22989 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22987] ssl module documentation: incorrect compatibility matrix
Roundup Robot added the comment: New changeset 7af5d5493497 by Antoine Pitrou in branch '2.7': Fix #22987: update the compatibility matrix for a SSLv23 client. https://hg.python.org/cpython/rev/7af5d5493497 New changeset 9f03572690d2 by Antoine Pitrou in branch '3.4': Fix #22987: update the compatibility matrix for a SSLv23 client. https://hg.python.org/cpython/rev/9f03572690d2 New changeset 7509a0607c40 by Antoine Pitrou in branch 'default': Fix #22987: update the compatibility matrix for a SSLv23 client. https://hg.python.org/cpython/rev/7509a0607c40 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22987 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22988] No error when yielding from `finally`
Ethan Furman added the comment: Here's the excerpt from the docs: Yield expressions are allowed in the try clause of a try ... finally construct. If the generator is not resumed before it is finalized (by reaching a zero reference count or by being garbage collected), the generator-iterator’s close() method will be called, allowing any pending finally clauses to execute. This certainly makes it sound like 'yield' is okay in the 'try' portion, but not the 'finally' portion. So 'yield' is allowed in the 'try' portion, and it's allowed in the 'finally' portion -- is it also allowed in the 'except' portion? If so, we could simplify the first line to: Yield expressions are allowed in try ... except ... finally constructs. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22988 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22987] ssl module documentation: incorrect compatibility matrix
Changes by Antoine Pitrou pit...@free.fr: -- resolution: - fixed stage: - resolved status: open - closed versions: +Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22987 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22988] No error when yielding from `finally`
Felipe added the comment: Thanks for the clarification; sorry I misread issue #14718. I agree with Ethan's point. Though I would say Yield expressions are allowed anywhere in try ... except ... finally constructs. I'd also like to explicitly add a point about the exception-handling machinery getting frozen, but I'm not sure how to phrase it clearly and accurately. Here's an attempt (my adds in square brackets): By suspended, we mean that all local state is retained, including the current bindings of local variables, the instruction pointer, the internal evaluation stack, [active exception handlers, and paused exceptions in finally blocks]. Another approach would be: By suspended, we mean that all local state is retained, including the current bindings of local variables, the instruction pointer, and the internal evaluation stack. [The state of any exception-handling code is also retained when yielding from a try ... except ... finally statement.] -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22988 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22988] No error when yielding from `finally`
Changes by Guido van Rossum gu...@python.org: -- nosy: -gvanrossum ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22988 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11101] plistlib has no graceful way of handing None values
Changes by Matt Hansen hanse...@me.com: -- nosy: +Matt.Hansen ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11101 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16329] mimetypes does not support webm type
Jim Jewett added the comment: I interpreted Issue 15's closure as being about the distinction between Application/webm vs Video/webm, etc. As far as I understand it, the python stdlib doesn't actually care what the major Mime type is, or, frankly, even whether the definition makes sense. We just want Video/webm to be registered. I have created issue 886 on the webm site at https://code.google.com/p/webm/issues/detail?id=886can=4colspec=ID%20Pri%20mstone%20ReleaseBlock%20Type%20Component%20Status%20Owner%20Summary Anyone with more detail (e.g., do we need to define Application/webm as well as Video/webm ... do we care what the definition is ... etc ...) is encouraged to chime in. -- nosy: +Jim.Jewett ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16329 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21557] os.popen os.system lack shell-related security warnings
Demian Brecht added the comment: After discussion in Rietveld, the patch looks good to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21557 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16329] mimetypes does not support webm type
Chris Rebert added the comment: WebM's docs use video/webm and never use an application/* type. See http://www.webmproject.org/docs/container/ They also specify audio/webm for audio-only content, but both use the same file extension, so associating .webm with video/webm seems quite reasonable since it's more general (an audio-only file is just a degenerate case of an audiovideo file). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16329 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22982] BOM incorrectly inserted before writing, after seeking in text file
Antoine Pitrou added the comment: This is a limitation more than a bug. When you seek to the start of the file, the encoder is reset because Python thinks you are gonna to write there. If you remove the call to `file.seek(0, io.SEEK_SET)`, things work fine. @Amaury, whence can only be zero there: https://hg.python.org/cpython/file/0744ceb5c0ed/Lib/_pyio.py#l1960 -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22982 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22982] BOM incorrectly inserted before writing, after seeking in text file
Mark Ingram added the comment: It's more than a limitation, because if I call `file.seek(0, io.SEEK_END)` then the encoder is still reset, and will still write the BOM, even at the end of the file. This also means that it's impossible to seek in a text file that you want to append to. I've had to work around this by opening the file as binary, manually writing the BOM, and writing the strings as encoded bytes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22982 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21557] os.popen os.system lack shell-related security warnings
R. David Murray added the comment: Since Raymond is the person who tends to object most strongly to warning boxes in the docs, let's get his opinion on this. I'm not sure that the warning box is necessary, the text may be sufficient. On the other hand, this *is* a significant insecurity vector. As far as the text goes, I'd combine the two paragraphs and introduce the text from the second one with Alternatively, And if it isn't a warning box, the the language should be refocused to be positive: Use the Popen module with shell=False to avoid the common security issues involved in using unsanitized input from untrusted sources... -- nosy: +r.david.murray, rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21557 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22990] bdist installation dialog
New submission from Alan: The Select Python Installations dialog box contains the line Select the Python locations where distribution_name should be installed. If distribution_name is anything other than a very short string, the line is truncated, due to the following factors: - the line doesn't wrap - the dialog box can't be resized - the message (aside from the distribution name) is fairly lengthy See the screenshot, where I created a distribution of a package whose name is not_such_a_long_name. At the same time as the line is made wrappable and/or the dialog box is made resizable, it would be nice to improve the wording of the message. It took me a while to figure out what was going on because the GUI elements have different meanings from the ones seen more commonly. Usually these elements (the menu with choices beginning with Will be installed on local hard drive and ending with Entire feature will be unavailable) are used to choose one or more features of an application to install, not one or more places to install the same application. Maybe something like this would work: Select Where to Install Select Python locations in which to install distribution_name: Python 2.7 (found in the registry) Python 3.3 (found in the registry) Python (other location) instead of the current: Select Python Installations Select the Python locations where distribution_name should be installed: Python 2.7 from registry Python 3.3 from registry Python from another location -- components: Distutils files: bdist_screenshot.PNG messages: 232094 nosy: Alan, dstufft, eric.araujo priority: normal severity: normal status: open title: bdist installation dialog type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file37353/bdist_screenshot.PNG ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16329] mimetypes does not support webm type
Terry J. Reedy added the comment: Antoine Pitrou and Ethan Furman agreed on pydev that this should be applied. Chris, is the existing patch exactly what you think is needed? -- nosy: +terry.reedy stage: - commit review type: - enhancement versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16329 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16329] mimetypes does not support webm type
Terry J. Reedy added the comment: Does test_mimetypes (assuming it exists), have a test for the mapping, are is something needed? -- stage: commit review - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16329 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16329] mimetypes does not support webm type
Chris Rebert added the comment: Yes, the existing patch looks fine. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16329 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16329] mimetypes does not support webm type
Ezio Melotti added the comment: A while ago there was a discussion about updating the MIME registry on bug fix releases too, and I seem to remember people agreed it should be done. If this is indeed the case and the patch is accepted for 3.5, should it also be backported to 2.7 and 3.4? -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16329 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22991] test_gdb leaves the terminal in raw mode with gdb 7.8.1
New submission from Xavier de Gaye: This happens on archlinux. Annoying: the terminal becomes unusable unless you type blindly 'stty sane CTL-J', and the backspace key is still wrong. This does not happen with gdb 7.6.1. And this does not happen when running gdb with the 'mi' interpreter. The attached patch uses GDB/MI. The problem with using the GDB/MI interface, is that it is very verbose when trying to debug a test. -- components: Tests files: gdbmi.patch keywords: patch messages: 232099 nosy: xdegaye priority: normal severity: normal status: open title: test_gdb leaves the terminal in raw mode with gdb 7.8.1 type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file37354/gdbmi.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22991 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22992] Adding a git developer's guide to Mercurial to devguide
New submission from Demian Brecht: Coming out of a recent thread in python-dev, it was mentioned that adding a git developer's guide to mercurial may be beneficial to help lower the initial barrier of entry for prospective contributors (https://mail.python.org/pipermail/python-dev/2014-November/137280.html). The attached patch is a slightly reworded version of my blog post here: http://demianbrecht.github.io/vcs/2014/07/31/from-git-to-hg/. -- components: Devguide files: gitdevs.patch keywords: patch messages: 232100 nosy: demian.brecht, ezio.melotti priority: normal severity: normal status: open title: Adding a git developer's guide to Mercurial to devguide Added file: http://bugs.python.org/file37355/gitdevs.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22992 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22992] Adding a git developer's guide to Mercurial to devguide
Ezio Melotti added the comment: I have a few comments about the patch. About the markup: 1) you can specify the default highlight (bash) once at the top of the file, and just use :: afterwards instead of .. code-block::; 2) the used for some headers is inconsistent with the other files; 3) when you use NamedBranches, do you want to create a link? if so you should use :ref:`NamedBranches` and add a reference; About the content: 1) you should make clear that bookmarks are local and they won't be included in the patch and/or affect the main repo; 2) we usually want a single diff for each issue -- you should show how to create a diff that includes all the changes related to issueA or issueB (this can be done easily with named branches, not sure about bookmarks); 3) hg ci --amend could be used to update existing changesets after a review (this will also solve the above problem); 4) it should be possible to use evolve instead of bookmarks, but evolve is currently still a work in progress, so I'm not sure is worth mentioning it yet; 5) you said that named branches, bookmarks, and queues are all branches types in Mercurial. Can you add a source for that? (I never heard of bookmarks and queues as branches, but they might be, and there are also non-named branches. I just want to make sure that the terms are used correctly.); 6) when you mention :code:`hg log -G`, you should probably mention -L10 too, otherwise on the CPython repo the command will result in a graph with 90k+ changesets; 7) Note that Mercurial doesn't have git's concept of staging, so all changes will be committed. - To avoid committing there are different ways: a) leave the code uncommitted in the working copy (works with one or two unrelated issues, but doesn't scale well); b) save changes on a .diff and apply it when needed (what I usually do, scales well but it has a bit of overhead since you need to update/apply the diff); c) use mq; d) use evolve. Mercurial also has the concept of phases (http://mercurial.selenic.com/wiki/Phases) that might be somewhat related, even though it affected committed changes (if you set a cs as secret it won't be pushed); 8) Trying to learn usual hg workflows might also be easier than trying to use a git-like workflow on mercurial, so you could suggest considering them too (I don't remember if we have anything about it in the devguide though). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22992 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22991] test_gdb leaves the terminal in raw mode with gdb 7.8.1
Changes by Ned Deily n...@acm.org: -- nosy: +dmalcolm ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22991 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20692] Tutorial and FAQ: how to call a method on an int
Changes by Josh Rosenberg shadowranger+pyt...@gmail.com: -- nosy: +josh.r ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20692 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22992] Adding a git developer's guide to Mercurial to devguide
Berker Peksag added the comment: +The workflow of a developer might look something like this: a core developer or a contributor? It would be good to split core developer and contributor workflows. +# address review comments and merge +git checkout master +git merge issueA +git branch -d issueA For example, from the contributor side, you shouldn't touch the master branch at all. It should be: # address review comments git commit -a # check upstream and rebase git pull --rebase upstream master # or origin master in this example # push changes (optional) git push origin issueA # origin should be contributor's fork here -- nosy: +berker.peksag stage: - patch review type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22992 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17852] Built-in module _io can loose data from buffered files at exit
Changes by Nikolaus Rath nikol...@rath.org: -- nosy: +nikratio ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17852 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17852] Built-in module _io can loose data from buffered files at exit
Nikolaus Rath added the comment: Serhiy, I believe this still happens in Python 3.4, but it is harder to reproduce. I couldn't get Armin's script to produce the problem either, but I'm pretty sure that this is what causes e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771452#60. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17852 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22968] Lib/types.py nit: isinstance != PyType_IsSubtype
Greg Turner added the comment: Fixed a trivial typo in test_virtual_metaclass_in_types_module.patch -- versions: +Python 3.5 Added file: http://bugs.python.org/file37356/test_virtual_metaclasses_in_types_module_v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22968 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16893] Generate Idle help from Doc/library/idle.rst
Roundup Robot added the comment: New changeset 6db65ff985b6 by Terry Jan Reedy in branch '3.4': Issue #16893: For Idle doc, move index entries, copy no-subprocess section https://hg.python.org/cpython/rev/6db65ff985b6 New changeset feec1ea55127 by Terry Jan Reedy in branch '2.7': Issue #16893: Update 2.7 version of Idle doc to match 3.4 doc as of the just https://hg.python.org/cpython/rev/feec1ea55127 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16893 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3068] IDLE - Add an extension configuration dialog
Roundup Robot added the comment: New changeset 395673aac686 by Terry Jan Reedy in branch '2.7': Issue #3068: Document the new Configure Extensions dialog and menu entry. https://hg.python.org/cpython/rev/395673aac686 New changeset b099cc290ae9 by Terry Jan Reedy in branch '3.4': Issue #3068: Document the new Configure Extensions dialog and menu entry. https://hg.python.org/cpython/rev/b099cc290ae9 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3068 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3068] IDLE - Add an extension configuration dialog
Changes by Terry J. Reedy tjre...@udel.edu: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3068 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22993] Plistlib fails on certain valid plist values
New submission from Connor Wolf:
I'm using plistlib to process plist files produced by an iphone app. Somehow,
the application is generating plist files with a absolute date value along the
lines of `-12-30T00:00:00Z`.
This is a valid date, and the apple plist libraries can handle this without
issue. However, it causes a ValueError if you load a plist containing it.
Minimal example:
python file:
```
import plistlib
test = plistlib.readPlist('./test.plist')
```
plist file:
```
?xml version=1.0 encoding=UTF-8?
!DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN
http://www.apple.com/DTDs/PropertyList-1.0.dtd;
plist version=1.0
dict
keyTest/key
date-12-30T00:00:00Z/date
/dict
/plist
```
This fails on both python3 and python2, with the exact same error:
```
herp@mainnas:/media/Storage/Scripts/pFail$ python3 test.py
Traceback (most recent call last):
File test.py, line 3, in module
test = plistlib.readPlist('./test.plist')
File /usr/lib/python3.4/plistlib.py, line 164, in readPlist
dict_type=_InternalDict)
File /usr/lib/python3.4/plistlib.py, line 995, in load
return p.parse(fp)
File /usr/lib/python3.4/plistlib.py, line 325, in parse
self.parser.ParseFile(fileobj)
File /usr/lib/python3.4/plistlib.py, line 337, in handle_end_element
handler()
File /usr/lib/python3.4/plistlib.py, line 413, in end_date
self.add_object(_date_from_string(self.get_data()))
File /usr/lib/python3.4/plistlib.py, line 291, in _date_from_string
return datetime.datetime(*lst)
ValueError: year is out of range
herp@mainnas:/media/Storage/Scripts/pFail$ python test.py
Traceback (most recent call last):
File test.py, line 3, in module
test = plistlib.readPlist('./test.plist')
File /usr/lib/python2.7/plistlib.py, line 78, in readPlist
rootObject = p.parse(pathOrFile)
File /usr/lib/python2.7/plistlib.py, line 406, in parse
parser.ParseFile(fileobj)
File /usr/lib/python2.7/plistlib.py, line 418, in handleEndElement
handler()
File /usr/lib/python2.7/plistlib.py, line 474, in end_date
self.addObject(_dateFromString(self.getData()))
File /usr/lib/python2.7/plistlib.py, line 198, in _dateFromString
return datetime.datetime(*lst)
ValueError: year is out of range
herp@mainnas:/media/Storage/Scripts/pFail$
```
--
components: Library (Lib)
messages: 232107
nosy: Connor.Wolf
priority: normal
severity: normal
status: open
title: Plistlib fails on certain valid plist values
type: behavior
versions: Python 2.7, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22993
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22993] Plistlib fails on certain valid plist values
Connor Wolf added the comment: Aaaand there is no markup processing. How do I edit my report? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22993 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17852] Built-in module _io can loose data from buffered files at exit
Charles-François Natali added the comment: Serhiy, I believe this still happens in Python 3.4, but it is harder to reproduce. I couldn't get Armin's script to produce the problem either, but I'm pretty sure that this is what causes e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771452#60. Maybe, as it's been said several times, it's an application bug: files should be closed explicitly (or better with a context manager of course). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17852 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22993] Plistlib fails on certain valid plist values
Ned Deily added the comment: (Currently, it is not possible to edit a particular message in an issue. You could add a replacement comment to the issue and ask that the older message be delete.) This seems to be a problem date. As documented, plistlib converts plist dates to/from Python datetime.datetime objects. And, as is documented from datetime objects, the year field must be between 1 (MINYEAR) and (MAXYEAR). So, it would appear that dates with year 0 are not representable as datetime objects; it's not obvious to me how plistlib could handle a date like that without changing the API, i.e. returning something other than a datetime object or by changing the rules for datetime objects, which is very unlikely to happen. https://docs.python.org/dev/library/plistlib.html https://docs.python.org/dev/library/datetime.html#datetime.MINYEAR -- nosy: +belopolsky, ned.deily, ronaldoussoren ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22993 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
