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

[Peter Otten]

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 tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[otst]

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: Interpreter Core
messages: 330076
nosy: otst
priority: normal
severity: normal
status: open
title: Running print("\x98") then freeze in Interpreter
type: behavior
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[yesheng]

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 (v2.7.11:6d1b6a68f775, Dec  5 2015, 20:40:30) [MSC v.1500 64 bit (AMD64)]
yyy() got ['abc', 'abd']
zzz() got NameError

--
versions: +Python 2.7 -Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I get NameError for both versions in both 3.6.5 and 3.7.1.

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[yesheng]

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

--
messages: 330073
nosy: yesheng
priority: normal
severity: normal
status: open
title: 'eval' in generator expression behave different in dict from list
type: behavior
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Shivank Gautam]

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 you will be still supportive when I will return in mid-dec after 
completing my exams.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24209] Allow IPv6 bind in http.server

[Gregory P. Smith]

Change by Gregory P. Smith :


--
versions: +Python 3.8 -Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24209] Allow IPv6 bind in http.server

[Lisa Roach]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24209] Allow IPv6 bind in http.server

[Lisa Roach]

Change by Lisa Roach :


--
pull_requests: +9840
stage: test needed -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Lawrence]

Change by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Eric Wieser]

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, for backward compatibility.

Was any progress made towards achieving this? It's frustrating that the correct 
quoting behavior we get with `subprocess.Popen(List[str])` is not used by 
`spawn`, and now every level of distutils code has to think about whether it 
needs to quote its arguments for the shell.

--
nosy: +Eric.Wieser

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35266] Add _PyPreConfig and rework _PyCoreConfig and _PyMainInterpreterConfig

[STINNER Victor]

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 initialization is a giant beast, full of traps, with many practical 
issues.

I'm moving slowly, step by step.

For example, this issue "only" move wchar_t* out of _PyCoreConfig, but Eric 
Snow told that me that he (or you, Nick, I don't recall) would prefer to not 
use "Unicode" during the very first initialization stage. wchar_t* is already 
Unicode. I'm unable to see yet how to have 3 stages:

1) no unicode
2) C structures, wchar_t*
3) Python objects

Currently, (1)+(2) is _PyCoreConfig and (3) is _PyMainInterpreterConfig.

I prefer to work directly on the code to make sure to have a working 
implementation, than working on paper but don't know if it's possible to 
implement it :-)

One issue is that it requires more steps, but from my point of view we better 
control the risk since it's possible to move back if we make a mistake in a 
small change.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35081] Move internal headers to Include/internal/

[STINNER Victor]

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, etc) rather than prebuilt binaries, the build 
process is something that can break, even for Py_BUILD_CORE only changes.

For those folks, when they pull a new source archive, their builds may break, 
especially if they're applying additional downstream patches the way Linux 
distros do.

The NEWS entry for this header file rearrangement should go in the Build 
section (https://github.com/python/cpython/tree/master/Misc/NEWS.d/next/Build) 
rather than the C API section (since these headers aren't part of the public 
API at all), but it should still exist.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35081] Move internal headers to Include/internal/

[STINNER Victor]

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 tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Julien Palard]

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 ...>" notation.

I agree with you, the [0, 1, ..., 8, 9] notation is too confusing with the repr 
of a list, that's why I proposed the "0, 1, ..., 8, 9" which looks nice.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Steven D'Aprano]

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 adequate first thought:

 

is explicit about what kind of object we have. Remember, there will be 
times where people don't know they have a range object, and are printing 
it to find out what they have.

Let's just move that from __repr__ to __str__.

> 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 empty range gets [] 
> instead of nothing.

Certainly not. That looks like a list containing 1, 2, ellipsis, 8, 9, 
and will only increase confusion about the difference between lists and 
range objects.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Julien Palard]

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 empty range gets [] 
instead of nothing.

I think I prefer the first way.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25988] collections.abc.Indexable

[Guido van Rossum]

Change by Guido van Rossum :


--
nosy:  -gvanrossum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25988] collections.abc.Indexable

[Carl Bordum Hansen]

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: +carlbordum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Thanks, Zackery!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11122] bdist_rpm should use rpmbuild, not rpm

[Marcin Niemira]

Change by Marcin Niemira :


--
pull_requests: +9839

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11122] bdist_rpm should use rpmbuild, not rpm

[Ned Deily]

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 solution is to just unconditionally use rpmbuild, 
let's do that instead.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ned Deily]

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 proposed there is to just unconditionally use 
rpmbuild as the use of rpm was for now obsolete versions.  I don't really have 
any experience with rpmbuild or stake in making the change.  But, rather than 
applying PR 10589, it looks like following through on Issue11122 would be the 
better approach.  Therefore, I'm going to close this issue (and PR) as a 
duplicate and suggest we move the discussion and perhaps generate a new PR 
there.

--
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> bdist_rpm should use rpmbuild, not rpm

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11122] bdist_rpm should use rpmbuild, not rpm

[Ned Deily]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

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 encoding doesn't make sense 
in Python 3, since ZipFile.write() doesn't support bytes as a file name.

PR 10592 fixed this.

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +9838

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Jason R. Coombs]

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 viability of the file in one 
of two candidate encodings, you'll necessarily need to read the entire file 
once before processing its contents.

Therefore, I recommend one of these options:

1. Always read the file in binary mode, ascertain the "best" encoding, then 
rewind the file and wrap it in a TextIOWrapper for that encoding. Presumably 
this logic is common--perhaps there's already a routine that does just that.
2. In a try/except block, read the entire content, decoded, into another 
iterable ... and then have the logic below rely on that content. i.e. `f = 
list(f)`.
3. Always assume UTF-8 instead of the system encoding. This change would be 
backward incompatible, so probably isn't acceptable without at least an interim 
release with a deprecation warning.

I recommend a combination of (1) and then (3) in the future. That is:

def determine_best_encoding(f, encodings=('utf-8', sys.getdefaultencoding())):
"""
Attempt to read and decode all of stream f using the encodings
and return the first one that succeeds. Rewinds the file.
"""


f = open(..., 'rb)
encoding = determine_best_encoding(f)
if encoding != 'utf-8':
warnings.warn("Detected pth file with unsupported encoding", 
DeprecationWarning)
f = io.TextIOWrapper(f, encoding)


Then, in a future version, dropping support for local encodings, all of that 
code can be replaced with `f = open(..., encoding='utf-8')`.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Andrew Svetlov]

Change by Andrew Svetlov :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Sanyam Khurana]

Change by Sanyam Khurana :


--
pull_requests: +9837

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Sanyam Khurana]

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: +CuriousLearner
versions: +Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35169] Improve error messages for assignment

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Benjamin, could you please take a look at this?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Could anybody please look at PR 10330?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35251] FTPHandler.ftp_open documentation error

[Luna Chen]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[miss-islington]

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)
https://github.com/python/cpython/commit/ae02a929ddd748b67b3e6f6c6665267f031142e7


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[miss-islington]

Change by miss-islington :


--
pull_requests: +9836

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[miss-islington]

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)
https://github.com/python/cpython/commit/062a57bf4b768ef726975bcc1d34398387520147


--
nosy: +miss-islington

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Robert Pollak]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35272] sqlite3 get the connected database url

[Muhammed Alkan]

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35272] sqlite3 get the connected database url

[Berker Peksag]

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?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35272] sqlite3 get the connected database url

[DamlaAltun]

DamlaAltun  added the comment:

Yeah, that would be great enhancement

--
nosy: +DamlaAltun

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35272] sqlite3 get the connected database url

[Muhammed Alkan]

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 url
type: enhancement
versions: Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35271] venv creates pyvenv.cfg with wrong home

[Eric V. Smith]

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 contents? 
What are all of your environment variable?

--
nosy: +eric.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35081] Move internal headers to Include/internal/

[Stefan Behnel]

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 
(https://github.com/cython/cython/blob/da657c8e326a419cde8ae6ea91be9661b9622504/Cython/Compiler/ModuleNode.py#L1442-L1456),
 to determine if an object for which tp_dealloc() is called has already been 
finalised or whether we have to do it. I'm not sure how to deal with this on 
our side now. Any clue?

--
nosy: +scoder

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35271] venv creates pyvenv.cfg with wrong home

[wvxvw]

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 the path is relative or absolute, the value of "home" in generated 
pyvenv.cfg will point to some other virtual environment I created earlier.

I would expect that at the minimum, if you aren't going to use the argument 
given on command line, then, at the minimum, alert the user about it.  Why even 
bother given the argument in this case?

PS. I discovered this, perhaps, due to using Emacs + pyvenv-* commands which 
probably set some environment variables.

--
components: Library (Lib)
messages: 330044
nosy: wvxvw
priority: normal
severity: normal
status: open
title: venv creates pyvenv.cfg with wrong home
type: behavior
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Marcin Niemira]

Change by Marcin Niemira :


--
keywords: +patch
pull_requests: +9835
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Julien Palard]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Nick Coghlan]

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 range.__str__ (and hence print, f-strings, logging, and more) 
offers many of the same benefits, without most of the downsides (repr will 
still roundtrip through eval, doctests won't break, etc).

The only potential benefit that gets lost is the fact that entering "range(10)" 
at the REPL will still print "range(0, 10)", such that you need to do 
"print(range(10))" to get the version that shows the endpoint values. For 
longer ranges, "print(range(100))" will still end up being a lot more user 
friendly than "print(list(100))".

--
title: Range repr could be better -> Make the half-open range behaviour easier 
to teach

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Nick Coghlan]

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 with 
statement context managers and async contexts)

Given the proposed "_PyPreConfig" construct, how would you feel about calling 
this "_PyPreInitState"? The idea there being that like PreConfig, the 
PreInitState would be discarded once the interpreter was fully initialised - 
the PreInitState would only be needed to handle cleanup *while* initialising 
(either of temporary values, or in the event of initialisation failing and 
needing to undo previous allocations).

My comment from #32566 also applies here: PEP 432 is now lagging so far behind 
the state of the private API implementation that it really needs an update to 
better reflect where you're wanting to take the public initialisation API 
following these changes.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15245] ast.literal_eval fails on some literals

[Mark Dickinson]

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35266] Add _PyPreConfig and rework _PyCoreConfig and _PyMainInterpreterConfig

[Nick Coghlan]

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 start migrating settings and see what's viable in practice has 
pretty much worked out as hoped, but we've diverged far enough from that 
structure now that we can't credibly claim to be working towards the current 
PEP draft as the new multi stage initialisation API.

Changing the proposal (and adding yourself as a co-author) is fine - that was 
the whole point of enabling initial development as a private API in the first 
place.

--
nosy: +lukasz.langa

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com