[issue35273] 'eval' in generator expression behave different in dict from list

Peter Otten <__pete...@web.de> added the comment: You probably saw this is in Python 2.7 where it is the expected behaviour. All versions of Python 3 should produce the NameError. -- nosy: +peter.otten versions: +Python 3.6 -Python 2.7 ___ Python

[issue35274] Running print("\x98") then freeze in Interpreter

New submission from otst : My environment OS:Ubuntu18.04(x64) Python:3.6.6 Run print("\x98") in Python3 interpreter then freeze or slow responsed. Not problem run print '\x98' in Python 2.7.15rc1. Also no problem for python3 -c "print('\x98');" and run .py file. -- components:

[issue35273] 'eval' in generator expression behave different in dict from list

yesheng <13611358...@139.com> added the comment: I tried again, and could not reproduce on 3.6.7, latest update: For 3.6.7: Both yyy() and zzz() got NameError For 2.7.9 (default, Dec 10 2014, 12:24:55) [MSC v.1500 32 bit (Intel)] yyy() got ['abc', 'abd'] zzz() got NameError 2.7.11

[issue35273] 'eval' in generator expression behave different in dict from list

Raymond Hettinger added the comment: I get NameError for both versions in both 3.6.5 and 3.7.1. -- nosy: +rhettinger ___ Python tracker ___

[issue35273] 'eval' in generator expression behave different in dict from list

New submission from yesheng <13611358...@139.com>: def yyy(): a, b = 'abc', 'abd' print([eval(i) for i in ('a', 'b')]) def zzz(): a, b = 'abc', 'abd' print({i: eval(i) for i in ('a', 'b')}) yyy() # ok zzz() # NameError: name 'a' is not defined, however in yyy() it is ok

[issue35052] Coverity scan: copy/paste error in Lib/xml/dom/minidom.py

Shivank Gautam added the comment: Hey Tal, I am extremely sorry for all delay. actually, due to internship and my university exams, I am unable to dedicate my time to bug(#35052). please consider it and you can tell Charalampos Stratakis in the bug to push his prepared pull request. I hope

[issue24209] Allow IPv6 bind in http.server

Change by Gregory P. Smith : -- versions: +Python 3.8 -Python 3.6 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue24209] Allow IPv6 bind in http.server

Lisa Roach added the comment: Looks like the original author isn't around anymore (feel free to chime in if you are, Link!), so I went ahead and made a PR. I added a quick unit test, it's not much but more than nothing, plus updated the documentation. -- nosy: +lisroach

[issue24209] Allow IPv6 bind in http.server

Change by Lisa Roach : -- pull_requests: +9840 stage: test needed -> patch review ___ Python tracker ___ ___ Python-bugs-list

[issue8987] Distutils doesn't quote Windows command lines properly

Change by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue8987] Distutils doesn't quote Windows command lines properly

Eric Wieser added the comment: > then we should perhaps instead consider the rewrite for 3.6: provide a *new* > distutils function that does use Popen and does things "right" (based on > everything we've learned since distutils was written), leaving the old > function in place, deprecated,

[issue35266] Add _PyPreConfig and rework _PyCoreConfig and _PyMainInterpreterConfig

STINNER Victor added the comment: > I like where you're going with this, but would be willing to write an update > to PEP 432 to sketch out in advance what you now think the end state is going > to look like? Sadly, I'm unable to design in advance what will be the final state. Python

[issue35081] Move internal headers to Include/internal/

STINNER Victor added the comment: TODO: add a NEWS entry for all these changes. Copy of Nick Coghlan's comment: https://github.com/python/cpython/pull/10275#issuecomment-439339982 @vstinner For folks consuming source archives (Linux distros, anyone embedding Python in a larger application,

[issue35081] Move internal headers to Include/internal/

STINNER Victor added the comment: > Making _PyGC_FINALIZED() internal broke Cython (...) Aha, interesting. Would you mind to open a new dedicated issue? So we can discuss how much of the GC details we want to leak into the API :-) -- ___ Python

[issue35200] Make the half-open range behaviour easier to teach

Julien Palard added the comment: If I understand correctly, you'd like str(range(10)) to return ""? I'm really unconfortable doing this, for me __str__ is here to return an “informal or nicely printable string representation of an object", not a convoluted "<{type(object)} object ...>"

[issue35200] Make the half-open range behaviour easier to teach

Steven D'Aprano added the comment: On Sun, Nov 18, 2018 at 09:43:02PM +, Julien Palard wrote: > My first though went to giving something really simple like: > > >>> print(range(10)) > 1, 2, ..., 8, 9 -1 Surely that would be your *second* thought, since you already had a perfectly

[issue35200] Make the half-open range behaviour easier to teach

Julien Palard added the comment: My first though went to giving something really simple like: >>> print(range(10)) 1, 2, ..., 8, 9 But for the empty range it would give an empty string. It may make sense, but may also be surprising. The other way would be to print [1, 2, ..., 8. 9], so the

[issue25988] collections.abc.Indexable

Change by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue25988] collections.abc.Indexable

Carl Bordum Hansen added the comment: Thank you for all the hours all of you spent on making Python awesome. I would like to start contributing as well. Do you consider it time to remove `__getattr__` in `Lib/collections/__init__.py` on master yet (introduced in pr #5460)? -- nosy:

[issue35269] A possible segfault involving a newly-created coroutine

Andrew Svetlov added the comment: Thanks, Zackery! -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue11122] bdist_rpm should use rpmbuild, not rpm

Change by Marcin Niemira : -- pull_requests: +9839 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue11122] bdist_rpm should use rpmbuild, not rpm

Ned Deily added the comment: Note that Issue32281 also describes the problem of trying to use build_rpm on non-rpm systems, again specifically macOS. Before stumbling on this issue,I had suggested over there to use change bdist_rpm to not use hardwired paths for rpmbuild but, if the better

[issue32281] bdist_rpm fails if no rpm command and rpmbuild is not in /usr/bin or /bin

Ned Deily added the comment: Thanks, @n0npax, for producing a PR implementing what I suggested. It looks good. However, while testing it, I ran across earlier open Issue11122 in which the same issue of building rpms on macOS is brought up. (Sorry I didn't see this earlier!) The solution

[issue11122] bdist_rpm should use rpmbuild, not rpm

Change by Ned Deily : -- nosy: +bhyde, ned.deily versions: -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker ___

[issue32035] Documentation of zipfile.ZipFile().writestr() fails to mention that 'data' may also be bytes

Serhiy Storchaka added the comment: Since the docstring contains more information, it is better to just copy words from the docstring to the documentation. There are also other places where string is improperly used instead of bytes or the type is not specified. The note about file name

[issue32035] Documentation of zipfile.ZipFile().writestr() fails to mention that 'data' may also be bytes

Change by Serhiy Storchaka : -- pull_requests: +9838 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35131] Cannot access to customized paths within .pth file

Jason R. Coombs added the comment: The problem you've encountered is that previously the file was assumed to be one encoding and would fail if it was not that encoding... so it was possible to lazy-load the file and process each line. In the new model, where you need to evaluate the

[issue35269] A possible segfault involving a newly-created coroutine

Change by Andrew Svetlov : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue18859] README.valgrind should mention --with-valgrind

Change by Sanyam Khurana : -- pull_requests: +9837 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32035] Documentation of zipfile.ZipFile().writestr() fails to mention that 'data' may also be bytes

Sanyam Khurana added the comment: The change in current PR is very minor and looks good enough that aligns the docs with the docstring and functionality of `ZipFile.writestr` as described. Can a core-contributor, please look at this? Also, I'm adding 3.8 for this change. -- nosy:

[issue35169] Improve error messages for assignment

Serhiy Storchaka added the comment: Benjamin, could you please take a look at this? -- ___ Python tracker ___ ___ Python-bugs-list

[issue9842] Document ... used in recursive repr of containers

Serhiy Storchaka added the comment: Could anybody please look at PR 10330? -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue35251] FTPHandler.ftp_open documentation error

Luna Chen added the comment: Hi there Lysandros, I'm happy to investigate into this and send a PR. I think we will need some test cases for this as well. Please let me know! :) -- nosy: +BNMetrics ___ Python tracker

[issue30455] Generate all tokens related code and docs from Grammar/Tokens

Serhiy Storchaka added the comment: Could anybody please make a review? There are two alternate PRs: PR 1860 and PR 10370. The difference between them is that the former one uses Lib/token.py as a source, and the latter one uses Grammar/Tokens as a source and generates Lib/token.py too.

[issue35269] A possible segfault involving a newly-created coroutine

miss-islington added the comment: New changeset ae02a929ddd748b67b3e6f6c6665267f031142e7 by Miss Islington (bot) in branch '3.7': bpo-35269: Fix a possible segfault involving a newly-created coroutine (GH-10585)

[issue35269] A possible segfault involving a newly-created coroutine

Change by miss-islington : -- pull_requests: +9836 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35269] A possible segfault involving a newly-created coroutine

miss-islington added the comment: New changeset 062a57bf4b768ef726975bcc1d34398387520147 by Miss Islington (bot) (Zackery Spytz) in branch 'master': bpo-35269: Fix a possible segfault involving a newly-created coroutine (GH-10585)

[issue35145] sqlite3: optionally autoconvert table_info's DATETIME fields

Change by Robert Pollak : -- title: sqlite3: "select *" should optionally sniff and autoconvert TEXT datetime fields -> sqlite3: optionally autoconvert table_info's DATETIME fields ___ Python tracker

[issue35272] sqlite3 get the connected database url

Muhammed Alkan added the comment: The use case could be - Using it to check if you're connected to correct database (as you know the mutability could change the connection) - Getting the name, helping the developers while debugging. - No more reasons :P --

[issue35272] sqlite3 get the connected database url

Berker Peksag added the comment: Just to be sure, what do you want to do is import sqlite3 conn = sqlite3.connect("foo.db") assert conn.database_path == "foo.db" right? I don't think that's something worth to expose in the Connection object. What's your use case? --

[issue35272] sqlite3 get the connected database url

DamlaAltun added the comment: Yeah, that would be great enhancement -- nosy: +DamlaAltun ___ Python tracker ___ ___

[issue35272] sqlite3 get the connected database url

New submission from Muhammed Alkan : A feature for to get the connected database path or URL from connection object (sqlite3.Connection). -- messages: 330047 nosy: berker.peksag, ghaering, midnio priority: normal severity: normal status: open title: sqlite3 get the connected database

[issue35271] venv creates pyvenv.cfg with wrong home

Eric V. Smith added the comment: You're going to have to provide some information, we can't guess at what's going on. At the very least: What OS? What shell? Which exact version of Python? How was it installed? Where is the file pyvenv.cfg that shows the problem? What are its entire

[issue35081] Move internal headers to Include/internal/

Stefan Behnel added the comment: Making _PyGC_FINALIZED() internal broke Cython (https://github.com/cython/cython/issues/2721). It's used in the finaliser implementation

[issue35271] venv creates pyvenv.cfg with wrong home

New submission from wvxvw : I must have some environment variable set, which affects this behavior, but I don't know which one that would be. What happens is as follows: No matter in what directory I execute this command: python3 -m venv .venv or python3 -m venv $(pwd)/.venv no matter if

[issue32281] bdist_rpm fails if no rpm command and rpmbuild is not in /usr/bin or /bin

Change by Marcin Niemira : -- keywords: +patch pull_requests: +9835 stage: needs patch -> patch review ___ Python tracker ___ ___

[issue35200] Make the half-open range behaviour easier to teach

Julien Palard added the comment: In one hand I'm OK to enhance the __str__ of range, so I'll change my PR for this. It will not fix the issue, but let's not break backward compatibility. -- ___ Python tracker

[issue35200] Make the half-open range behaviour easier to teach

Nick Coghlan added the comment: (Retitled the issue to better reflect the underlying feature request) As Steven describes, there are enough problems with changing range.__repr__ that if that's the proposal, then the only possible answer is "No", and closing the issue. However, changing

[issue35265] Internal C API: pass the memory allocator in a context

Nick Coghlan added the comment: I think the idea makes sense, but find the proposed name potentially confusing for two reasons: 1. It isn't only about configuration, it's about interpreter initialisation state in general 2. We use "context" for several other purposes already (most notably

[issue15245] ast.literal_eval fails on some literals

Mark Dickinson added the comment: > The question is should we make it working in older versions? That seems like an easy question: it would be a new feature in a bugfix branch, so no, we shouldn't make it work in older versions. Looks to me as though this issue can be closed. --

[issue35266] Add _PyPreConfig and rework _PyCoreConfig and _PyMainInterpreterConfig

Nick Coghlan added the comment: I like where you're going with this, but would be willing to write an update to PEP 432 to sketch out in advance what you now think the end state is going to look like? Merging the general structure of the draft PEP 432 implementation to make it possible to