Re: [Python-Dev] Strange umask(?)/st_mode issue

I wouldn't expect it to be the case in a CI environment but I believe a umask can be overridden if the filesystem is mounted and configured with acls set? (oh, hah, Ivan just said the same thing) -gps On Sat, Mar 30, 2019 at 9:05 AM Steve Dower wrote: > On 29Mar.2019 1944, Steve Dower wrote:

Re: [Python-Dev] Strange umask(?)/st_mode issue

That does sound strange. How easily can you reproduce it? That majorly effects how I would try to debug something like this... If you're able to get an strace of a failed run then that would probably tell us a *lot*. On Fri, Mar 29, 2019, 16:28 Steve Dower wrote: > Hi > > I'm trying to track

Re: [Python-Dev] PEP 556 threaded garbage collection & linear recursion in gc

of such a report. -G On Wed, Mar 27, 2019, 5:38 PM Tim Peters wrote: > [Gregory P. Smith ] > > ... > > A situation came up the other day where I believe this could've helped. > > > > Scenario (admittedly not one most environments run into): A Python > process &

[Python-Dev] PEP 556 threaded garbage collection & linear recursion in gc

https://www.python.org/dev/peps/pep-0556/ This PEP is currently Deferred as nobody is actively working on a test implementation. A situation came up the other day where I *believe* this could've helped. Scenario (admittedly not one most environments run into): A Python process with a C++

Re: [Python-Dev] Best way to specify docstrings for member objects

(answers above and below the quoting) I like the idea of documenting attributes, but we shouldn't force the user to use __slots__ as that has significant side effects and is rarely something people should bother to use. There are multiple types of attributes. class and instance. but regardless

Re: [Python-Dev] Remove tempfile.mktemp()

sting question. 16 (= 128 bits) would be a nice "obviously safe" number, and gives 22-byte filenames. We might be able to get away with fewer, if we had a plausible cost model for the attack. This is another point where a security specialist might be helpful :-). -n -- Nathaniel J. Smith

Re: [Python-Dev] Is XML serialization output guaranteed to be bytewise identical forever?

On Tue, Mar 19, 2019, 4:53 AM Ned Batchelder wrote: > On 3/19/19 4:13 AM, Serhiy Storchaka wrote: > > 19.03.19 00:41, Raymond Hettinger пише: > >> 4) Fix the tests in the third-party modules to be more focused on > >> their actual test objectives, the semantics of the generated XML > >> rather

Re: [Python-Dev] Is XML serialization output guaranteed to be bytewise identical forever?

On Mon, Mar 18, 2019 at 9:44 PM Terry Reedy wrote: > On 3/18/2019 6:41 PM, Raymond Hettinger wrote: > > We're having a super interesting discussion on > https://bugs.python.org/issue34160 . It is now marked as a release > blocker and warrants a broader discussion. > > > > Our problem is that at

Re: [Python-Dev] Is XML serialization output guaranteed to be bytewise identical forever?

I noticed that your list doesn't include "add a DOM equality operator". That seems potentially simpler to implement than canonical XML serialization, and like a useful thing to have in any case. Would it make sense as an option? On Mon, Mar 18, 2019, 15:46 Raymond Hettinger wrote: > We're

Re: [Python-Dev] (Licensing question) backport of shutil.copyfile() functionality

On Tue, Mar 12, 2019 at 2:55 PM Giampaolo Rodola' wrote: > > > On Tue, Mar 12, 2019 at 3:01 AM Glenn Linderman > wrote: > >> On 3/11/2019 4:35 PM, Giampaolo Rodola' wrote: >> >> Hello, >> some time ago I contributed a couple of patches to speedup shutil.copy*() >> functions: >>

Re: [Python-Dev] (Licensing question) backport of shutil.copyfile() functionality

Things in the standard library are already covered by the PSF license so that is what should be kept on backports from the stdlib to earlier versions. I do recommend keeping your backported stuff and new functionality separate (separate packages ideally, but that'll depend on how intertwined

Re: [Python-Dev] configparser: should optionxform be idempotent?

> On Mar 8, 2019, at 12:12 AM, Steven D'Aprano wrote: > >> On Fri, Mar 08, 2019 at 12:56:13PM +1300, Greg Ewing wrote: >> >> In any case, the word is easy enough to avoid in this case. > > I don't think we should avoid using standard terminology even if we can. > Knowledge of standard

Re: [Python-Dev] PEP 581: Using GitHub Issues for CPython

On Thu, Mar 7, 2019 at 2:12 PM Mariatta wrote: > > On Thu, Mar 7, 2019 at 12:35 PM Matthew Woodcraft > wrote: > >> >> One part of this PEP stands out to me: >> >> | We should not be moving all open issues to GitHub. Issues with little >> | or no activity should just be closed. Issues with no

Re: [Python-Dev] Compile-time resolution of packages [Was: Another update for PEP 394...]

On Wed, Feb 27, 2019 at 5:12 PM Toshio Kuratomi wrote: > > On Tue, Feb 26, 2019 at 2:07 PM Neil Schemenauer > wrote: > >> On 2019-02-26, Gregory P. Smith wrote: >> > On Tue, Feb 26, 2019 at 9:55 AM Barry Warsaw wrote: >> > For an OS distro provided interpr

Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

On Tue, Feb 26, 2019 at 2:31 PM Steve Dower wrote: > On 2/26/2019 1:20 PM, Gregory P. Smith wrote: > > For an OS distro provided interpreter, being able to restrict its use to > > only OS distro provided software would be ideal (so ideal that people > > who haven't le

Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

On Tue, Feb 26, 2019 at 2:28 PM Victor Stinner wrote: > Le mar. 26 févr. 2019 à 22:24, Gregory P. Smith a écrit > : > > A feature that I find missing from posix-y OSes that support #! lines is > an ability to restrict what can use a given interpreter. > > Fedora runs sys

Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

On Tue, Feb 26, 2019 at 9:55 AM Barry Warsaw wrote: > > There haven't been many new ideas since this summary – mostly it was > explaining and re-hashing what's been mentioned before. > > Thanks for the summary Petr. > > Here’s another way to think about the problem. I know Nick and I have >

Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

On Tue, Feb 26, 2019 at 8:59 AM INADA Naoki wrote: > > > > With *Homebrew*, `python` points to Homebrew’s Python 2.7.x (if > > installed) otherwise the macOS system Python. That's exactly according > > to the PEP. They tried to switch python to python3 before, and got > > rather nasty backlash

Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

On Mon, Feb 18, 2019, 7:34 AM Matthias Klose On 16.02.19 00:15, Gregory P. Smith wrote: > > On Thu, Feb 14, 2019 at 9:29 AM Barry Warsaw wrote: > > > >> On Feb 13, 2019, at 23:08, Matěj Cepl wrote: > >> > >>> Is this relevant to the discussion at hand?

Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

On Thu, Feb 14, 2019 at 9:29 AM Barry Warsaw wrote: > On Feb 13, 2019, at 23:08, Matěj Cepl wrote: > > > Is this relevant to the discussion at hand? We are talking about > > the binary /usr/bin/python3 which will be surely be provided > > even by Python 4, won't it? > > Why would it be? Since

Re: [Python-Dev] Is distutils.util.get_platform() the "current" or the "target" platform

On Fri, Feb 15, 2019 at 2:02 PM Steve Dower wrote: > On 14Feb2019 1147, Gregory P. Smith wrote: > > To alleviate confusion long term I'd love it if we could deprecate the > > unqualified get_platform() API and point people towards always being > > explicit about get

Re: [Python-Dev] Is distutils.util.get_platform() the "current" or the "target" platform

On Thu, Feb 14, 2019 at 11:38 AM Steve Dower wrote: > As part of adding ARM32 support for Windows, we need to enable > cross-compilation in distutils. This is easy enough, though it requires > somehow getting the target platform as well as the current platform. > > Right now, the change at

Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

On Thu, Feb 14, 2019 at 12:43 AM Antoine Pitrou wrote: > > On Wed, 13 Feb 2019 17:32:44 -0800 > Nathaniel Smith wrote: > > On Wed, Feb 13, 2019 at 3:02 PM Steven D'Aprano wrote: > > > > > > On Wed, Feb 13, 2019 at 05:16:54PM -0500, Terry Reedy wrote: > >

Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

p3/python -m pip/python3 -m pip would be nice to know. I don't know if sys.executable would tell us anything useful or not. pip knows where the current python's script directory is; maybe it should report whether it contains 'python2', 'python3', 'python', and perhaps whi

Re: [Python-Dev] How to update namedtuple asdict() to use dict instead of OrderedDict

On Thu, Jan 31, 2019, 05:26 Nick Coghlan On Thu, 31 Jan 2019 at 16:40, Glenn Linderman > wrote: > >> On 1/30/2019 8:45 PM, Raymond Hettinger wrote: > >>> On Jan 30, 2019, at 3:41 PM, Glenn Linderman > wrote: > >>> Would it be practical to add deprecated methods to regular dict for > the

Re: [Python-Dev] How to update namedtuple asdict() to use dict instead of OrderedDict

ch faster, > and has a much cleaner looking repr. How viable would it be to make OrderedDict smaller, faster, and give it a cleaner looking repr? -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list Python-Dev@python.org https://mai

Re: [Python-Dev] How to update namedtuple asdict() to use dict instead of OrderedDict

On Wed, Jan 30, 2019 at 2:32 PM Raymond Hettinger < raymond.hettin...@gmail.com> wrote: > Now that regular dicts are ordered and compact, it makes more sense for > the _asdict() method to create a regular dict (as it did in its early days) > rather than an OrderedDict. The regular dict is much

Re: [Python-Dev] Sub-interpreters: importing numpy causes hang

On Thu, Jan 24, 2019 at 1:25 PM Chris Barker - NOAA Federal via Python-Dev < python-dev@python.org> wrote: > If your primary concern is module clashes between plugins, maybe you > can hack around that: > > 1) if the plugins are providing copies of any other modules, then you > can simply require

Re: [Python-Dev] Sub-interpreters: importing numpy causes hang

On Sun, Jan 27, 2019, 06:34 Stephan Reiter Cool. Thanks, Nick! > > I did experiments based on this idea ( > https://github.com/stephanreiter/cpython/commit/3bca91c26ac81e517b4aa22302be1741b3315622) > and haven't rejected it yet. :-) > > Together with the other fix ( >

Re: [Python-Dev] Add more SyntaxWarnings?

On 1/24/2019 6:16 PM, Eric V. Smith wrote: On 1/24/2019 5:52 PM, Chris Angelico wrote: +1. If it's something that the peephole optimizer is already allowed to change (eg "1"+"1" is constant-folded) and there is absolutely no way that it can ever be changed at run time, the

Re: [Python-Dev] Add more SyntaxWarnings?

On 1/24/2019 5:52 PM, Chris Angelico wrote: On Fri, Jan 25, 2019 at 9:42 AM Steven D'Aprano wrote: We could say that implementations are allowed to raise errors at compile time instead of run time, but aren't required to. Then it becomes a matter of "quality of implementation". For literal

Re: [Python-Dev] Sub-interpreters: importing numpy causes hang

them into a single coherent environment. -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Sub-interpreters: importing numpy causes hang

There are currently numerous incompatibilities between numpy and subinterpreters, and no concrete plan for fixing them. The numpy team does not consider subinterpreters to be a supported configuration, and can't help you with any issues you run into. I know the concept of subinterpreters is really

Re: [Python-Dev] ctypes: is it intentional that id() is the only way to get the address of an object?

ple could use in theory. -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] ctypes: is it intentional that id() is the only way to get the address of an object?

On Thu, Jan 17, 2019, 22:11 Steve Dower For everyone who managed to reply *hours* after Eryk Sun posted the > correct answer and still get it wrong, here it is again in full. > > As a bonus, here's a link to the place where this answer appears in the > documentation: >

Re: [Python-Dev] ctypes: is it intentional that id() is the only way to get the address of an object?

n Thu, Jan 17, 2019 at 4:51 PM Gregory P. Smith wrote: > > I've heard that libraries using ctypes, cffi, or cython code of various sorts > in the real world wild today does abuse the unfortunate side effect of > CPython's implementation of id(). I don't have specif

Re: [Python-Dev] ctypes: is it intentional that id() is the only way to get the address of an object?

I've heard that libraries using ctypes, cffi, or cython code of various sorts in the real world wild today does abuse the unfortunate side effect of CPython's implementation of id(). I don't have specific instances of this in mind but trust what I've heard: that it is happening. id() should never

Re: [Python-Dev] Usage of the multiprocessing API and object lifetime

On Tue, Dec 11, 2018, 07:13 Antoine Pitrou > What you are proposing here starts to smell like an anti-pattern to > me. Python _is_ a garbage-collected language, so by definition, there > _are_ going to be resources that are automatically collected when an > object disappears. If I'm allocating

Re: [Python-Dev] test_urllib2net fixed to repair Travis CI

Travis is in the middle of moving everything from AWS to GCE, which is probably related: https://blog.travis-ci.com/2018-11-19-required-linux-infrastructure-migration As noted there, GCE has different IP addresses. But I suspect it's not the new IP address that's the problem, but rather the fact

Re: [Python-Dev] Inclusion of lz4 bindings in stdlib?

On Sat, Dec 1, 2018, 06:56 Steve Holden We* should probably do more collectively to point people at > production-quality third-party modules, as I believe we currently do with > pipenv which, while not a part of the standard library, is still > recommended in the documentation as the preferred

Re: [Python-Dev] Standard library vs Standard distribution?

reter. But if the stdlib isn't a single-box-of-batteries, then what is it? It's really hard to tell whether specific packages would be good or bad additions to the stdlib, when we don't even know what the stdlib is supposed to be. -n -- Nathaniel J. Smith -- https://vorpus.org __

Re: [Python-Dev] Standard library vs Standard distribution?

But for the major projects where I have some knowledge of the development process -- like requests, urllib3, numpy, pip, setuptools, cryptography -- the main blocker to putting them in the stdlib is that the maintainers don't think a stdlibized version could meet their quality standards. -n --

Re: [Python-Dev] Inclusion of lz4 bindings in stdlib?

M INADA Naoki > wrote: > >> On Thu, Nov 29, 2018 at 6:27 AM Steven D'Aprano >> wrote: >> > >> > On Wed, Nov 28, 2018 at 10:43:04AM -0800, Gregory P. Smith wrote: >> > >> > > PyPI makes getting more algorithms easy. >> > >

Re: [Python-Dev] Inclusion of lz4 bindings in stdlib?

On Thu, Nov 29, 2018, 10:32 Antoine Pitrou On Thu, 29 Nov 2018 09:49:32 -0800 > Nathaniel Smith wrote: > > > > There are a lot of challenges to switching to a "standard distribution" > > model. I'm not certain it's the best option. But what I like about it is >

Re: [Python-Dev] Inclusion of lz4 bindings in stdlib?

On Thu, Nov 29, 2018, 08:34 Antoine Pitrou > Le 29/11/2018 à 17:25, Steve Dower a écrit : > > > > My experience is that the first group would benefit from a larger > > _standard distribution_, which is not necessarily the same thing as a > > larger stdlib. > > > > I'm firmly on the "smaller core,

Re: [Python-Dev] Standard library vs Standard distribution?

meta: I'm not participating in this sub-thread. Just changing the subject line. On Thu, Nov 29, 2018 at 9:17 AM Christian Heimes wrote: > On 29/11/2018 17.32, Antoine Pitrou wrote: > > We may ask ourselves if there is really a large difference between a > > "standard distribution" and a

Re: [Python-Dev] Inclusion of lz4 bindings in stdlib?

On Wed, Nov 28, 2018 at 10:43 AM Gregory P. Smith wrote: > > On Wed, Nov 28, 2018 at 9:52 AM Brett Cannon wrote: > >> Are we getting to the point that we want a compresslib like hashlib if we >> are going to be adding more compression algorithms? >> > &g

Re: [Python-Dev] Inclusion of lz4 bindings in stdlib?

On Wed, Nov 28, 2018, 12:08 Antoine Pitrou On Wed, 28 Nov 2018 19:35:31 + > Jonathan Underwood wrote: > > On Wed, 28 Nov 2018 at 18:57, Antoine Pitrou > wrote: > > > > > > On Wed, 28 Nov 2018 10:43:04 -0800 > > > "Gregory P. Smith" w

Re: [Python-Dev] Inclusion of lz4 bindings in stdlib?

On Wed, Nov 28, 2018 at 9:52 AM Brett Cannon wrote: > Are we getting to the point that we want a compresslib like hashlib if we > are going to be adding more compression algorithms? > Lets avoid the lib suffix when unnecessary. I used the name hashlib because the name hash was already taken by

Re: [Python-Dev] C API changes

On Mon, Nov 26, 2018 at 4:10 PM Larry Hastings wrote: > On 11/23/18 5:15 AM, Armin Rigo wrote: > > Also FWIW, my own 2 cents on the topic of changing the C API: let's > entirely drop ``PyObject *`` and instead use more opaque > handles---like a ``PyHandle`` that is defined as a pointer-sized C >

Re: [Python-Dev] C API changes

On Mon, Nov 26, 2018 at 6:12 PM Eric V. Smith wrote: > I thought the important part of the proposal was to have multiple > PyHandles that point to the same PyObject (you couldn't "directly > compare handles with each other to learn about object identity"). But > I'll

Re: [Python-Dev] C API changes

On 11/26/2018 7:08 PM, Larry Hastings wrote: On 11/23/18 5:15 AM, Armin Rigo wrote: Also FWIW, my own 2 cents on the topic of changing the C API: let's entirely drop ``PyObject *`` and instead use more opaque handles---like a ``PyHandle`` that is defined as a pointer-sized C type but is not

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

of money at Graal so I guess we'll find out. -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

least for the main ABI. The limited ABI supposedly doesn't, but probably does, and as noted above it has such limited use that it's probably still possible to fix any stuff that's leaked out accidentally. -n -- Nathaniel J. Smith -- https://vorpus.org __

Re: [Python-Dev] General concerns about C API changes

On Sun, Nov 18, 2018 at 8:52 AM Stefan Behnel wrote: > > Gregory P. Smith schrieb am 15.11.18 um 01:03: > > From my point of view: A static inline function is a much nicer modern code > > style than a C preprocessor macro. > > It's also slower to compile, given that f

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

'm guessing it's partly due to limits of the API, but also things like: lack of docs and examples, lack of py2 support, ... -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/list

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

> > It seems like the discussion so far is: > > Victor: "I know people when people hear 'new API' they get scared and > think we're going to do a Python-3-like breaking transition, but don't > worry, we're never going to do that." > Nathaniel: "But then what does the new API add?" > Greg: "It lets

Re: [Python-Dev] General concerns about C API changes

On Tue, Nov 13, 2018 at 7:06 PM Raymond Hettinger < raymond.hettin...@gmail.com> wrote: > Overall, I support the efforts to improve the C API, but over the last few > weeks have become worried. I don't want to hold up progress with fear, > uncertainty, and doubt. Yet, I would like to be more

Re: [Python-Dev] General concerns about C API changes

having buy in that the churn isn't destabilizing and will > actually produce a benefit that is worth it. > > > Raymond > > > > > > > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/m

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

tting to supporting them forever. And I don't know the best answer to all your questions above, that's what experimenting is for :-). But it certainly is technically possible to make a new API that shares a common subset with the old API, e.g.: /* NewPython.h */ #include #

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

On Mon, Nov 12, 2018 at 10:46 PM, Gregory P. Smith wrote: > > On Fri, Nov 9, 2018 at 5:50 PM Nathaniel Smith wrote: >> >> On Fri, Nov 9, 2018 at 4:30 PM, Victor Stinner >> wrote: >> > Ah, important points. I don't want to touch the current C AP

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

On Sun, Nov 11, 2018 at 3:19 PM Victor Stinner wrote: > Le sam. 10 nov. 2018 à 04:02, Nathaniel Smith a écrit : > > So is it fair to say that your plan is that CPython will always use > > the current ("old") API internally, and the "new" API will be > >

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

On Fri, Nov 9, 2018 at 5:50 PM Nathaniel Smith wrote: > On Fri, Nov 9, 2018 at 4:30 PM, Victor Stinner > wrote: > > Ah, important points. I don't want to touch the current C API nor make > > it less efficient. And compatibility in both directions (current C API > >

Re: [Python-Dev] Signalling NANs

tries to set all the status flags correctly. And I'm not sure sNaN support is actually useful anyway... Of course if all you want is a value that raises an exception whenever it's used in an arithmetic expression, then Python does support that :-) sNaN = object() -n -- Nathaniel J. Smith -- ht

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

On Fri, Nov 9, 2018 at 6:03 PM, Victor Stinner wrote: > Le sam. 10 nov. 2018 à 02:50, Nathaniel Smith a écrit : >> Doesn't this mean that you're just making the C API larger and more >> complicated, rather than simplifying it? You cite some benefits >> (tagged pointers

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

ger and more complicated, rather than simplifying it? You cite some benefits (tagged pointers, changing the layout of PyObject, making PyPy's life easier), but I don't see how you can do any of those things so long as the current C API remains supported. -n -- Nat

Re: [Python-Dev] Implementing an awaitable

_ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/njs%40pobox.com > -- Nathaniel J. Smith -- https://vorpus.org __

Re: [Python-Dev] short-circuiting runtime errors/exceptions in python debugger.

r instructions (continue / enter debugger / exit / ...). Or, on Linux, there's: https://www.criu.org/ I also wonder if it would be useful to give pdb the ability to break when an exception is *raised*, rather than when it's caught? -n -- Nathaniel J. Smi

Re: [Python-Dev] "Deprecation" of os.system in favor of subprocess?

The os module is by definition special. It exposes libc and platform APIs. That there are Python modules that provide similar functionality, often surpassing it and sometimes being built on top of it, is intentional. Random quotes from the Zen don't win arguments. Although practicality beats

Re: [Python-Dev] [Python-checkins] bpo-34203: FAQ now recommends python 3.x over 2.x (GH-9796)

> On Oct 12, 2018, at 7:03 PM, Martin Panter wrote: > >> On 12/10/2018, Eric V. Smith wrote: >>> On 10/12/2018 5:17 AM, Tal Einat wrote: >>> >>> The latest stable releases can always be found on the `Python download page >>> -<https://www.p

Re: [Python-Dev] bpo-34837: Multiprocessing.Pool API Extension - Pass Data to Workers w/o Globals

On Fri, Oct 12, 2018, 06:09 Antoine Pitrou wrote: > On Fri, 12 Oct 2018 08:33:32 -0400 > Sean Harrington wrote: > > Hi Nathaniel - this if this solution can be made performant, than I would > > be more than satisfied. > > > > I think this would require removing "func" from the "task tuple", and

Re: [Python-Dev] [Python-checkins] bpo-34203: FAQ now recommends python 3.x over 2.x (GH-9796)

On 10/12/2018 5:17 AM, Tal Einat wrote: The latest stable releases can always be found on the `Python download page -`_. There are two recommended production-ready -versions at this point in time, because at the moment there are two branches of -stable

Re: [Python-Dev] Use of objdump within ctypes _get_soname()

On Mon, Oct 8, 2018 at 11:59 PM Ray Donnelly wrote: > Hi, > > We ran into an issue on the Anaconda Distribution recently where we > added libarchive-c to conda-build (so we can un-compress more source > archive formats than tarfile supports) and everything was good a few > hours, until it hit

Re: [Python-Dev] bpo-34837: Multiprocessing.Pool API Extension - Pass Data to Workers w/o Globals

might also solve your problem, if pool.map is clever enough to only send the function object once to each worker? -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/lis

Re: [Python-Dev] What is the purpose of the _PyThreadState_Current symbol in Python 3?

On Fri, Sep 28, 2018 at 3:29 PM, Gabriele wrote: > On Fri, 28 Sep 2018 at 23:12, Nathaniel Smith wrote: >> What information do you wish the interpreter provided, that would make your >> program simpler and more reliable? > > An exported global variable th

Re: [Python-Dev] What is the purpose of the _PyThreadState_Current symbol in Python 3?

What information do you wish the interpreter provided, that would make your program simpler and more reliable? On Fri, Sep 28, 2018, 07:21 Gabriele wrote: > Hi Victor, > > > I understand that you are writing a debugger and you can only *read* > > modify, not execute code, right? > > I'm working

Re: [Python-Dev] Postponed annotations break inspection of dataclasses

Yes, it’s https://bugs.python.org/issue34776 -- Eric > On Sep 27, 2018, at 12:05 PM, Ivan Levkivskyi wrote: > > Do we have a b.p.o. issue about this? If no, then I would recommend to open > one, so that we will not loose track of this. > > -- > Ivan > > > >> On Sat, 22 Sep 2018 at 16:32,

Re: [Python-Dev] Questions about signal handling.

On Mon, Sep 24, 2018 at 1:20 PM Eric Snow wrote: > On Mon, Sep 24, 2018 at 11:14 AM Yury Selivanov > wrote: > > On Fri, Sep 21, 2018 at 7:04 PM Eric Snow > wrote: > > > 1. Why do we restrict calls to signal.signal() to the main thread? > > > 2. Why must signal handlers run in the main thread?

Re: [Python-Dev] Postponed annotations break inspection of dataclasses

On 9/22/2018 12:41 PM, Guido van Rossum wrote: This is a good catch -- thanks for bringing it up. I'm adding Eric Smith (author of dataclasses) and Ivan Levkivskyi (co-author of typing) as well as Łukasz Langa (author of PEP 563) to the thread to see if they have further insights. I don't

Re: [Python-Dev] Store startup modules as C structures for 20%+ startup speed improvement?

On 9/19/2018 9:25 PM, Barry Warsaw wrote: On Sep 19, 2018, at 20:34, Gregory P. Smith wrote: There's ongoing work to rewrite zipimport.c in python using zipfile itself Great timing! Serhiy’s rewrite of zipimport in Python has just landed in 3.8, although it doesn’t use zipfile. What’s

Re: [Python-Dev] Store startup modules as C structures for 20%+ startup speed improvement?

On Sat, Sep 15, 2018 at 2:53 AM Paul Moore wrote: > On Fri, 14 Sep 2018 at 23:28, Neil Schemenauer > wrote: > > > > On 2018-09-14, Larry Hastings wrote: > > > [..] adding the stat calls back in costs you half the startup. So > > > any mechanism where we're talking to the disk _at all_ simply >

Re: [Python-Dev] SEC: Spectre variant 2: GCC: -mindirect-branch=thunk -mindirect-branch-register

Hi Wes, It's great you're passionate about python security, but this is the wrong way to go about it. Spectre is inherently super subtle and confusing, so if there's something that people need to do, then we need a clear, comprehensive write-up of what the threat is and how to address it. Perhaps

Re: [Python-Dev] bpo-34595: How to format a type name?

On 9/13/2018 8:04 PM, Victor Stinner wrote: Le ven. 14 sept. 2018 à 00:09, Eric V. Smith a écrit : f'{type(obj)}' becomes type(obj).__format__(''), so you can return something other than __str__ or __repr__ does. It's only by convention that an object's __format__ returns __str__: it need

Re: [Python-Dev] bpo-34595: How to format a type name?

On 9/13/2018 5:52 PM, Petr Viktorin wrote: On 09/13/18 14:08, Victor Stinner wrote: Le jeu. 13 sept. 2018 à 16:01, Eric V. Smith a écrit : * Add !t conversion to format string I'm strongly opposed to this. This !t conversion would not be widely applicable enough to be generally useful

Re: [Python-Dev] bpo-34595: How to format a type name?

On 9/12/2018 8:33 PM, Victor Stinner wrote: Hi, For the type name, sometimes, we only get a type (not an instance), and we want to format its FQN. IMHO we need to provide ways to format the FQN of a type for *types* and for *instances*. Here is my proposal: * Add !t conversion to format

Re: [Python-Dev] AES decryption/encryption support for zipfile

On Wed, Sep 5, 2018 at 8:24 AM 大野隆弘 wrote: > Sorry, allow me to ask one more thing. > If I want to use AES in zipfile module, what the good way to implement? > If anyone wants to add support for additional zipfile encryption/decryption methods, there are a few options: (a) Fork the stdlib

Re: [Python-Dev] Schedule of the Python 3.7.1 release?

On 9/5/2018 6:22 AM, Christian Heimes wrote: On 2018-09-05 11:56, Victor Stinner wrote: Hi, Someone asked somewhere (oops, I forgot where!) when is Python 3.7.1 scheduled. I wanted to reply when I saw that it was scheduled for 2 months ago: "3.7.1: 2018-07-xx"

Re: [Python-Dev] Python 2.7 EOL date

On 8/23/2018 8:14 PM, Barry Warsaw wrote: On Aug 23, 2018, at 15:23, Eric V. Smith wrote: On 8/23/2018 4:30 PM, Victor Stinner wrote: Hi, The reference is the PEP 373 "Python 2.7 Release Schedule". See the "Update" section: https://www.python.org/dev/peps/pep-0373/#update

Re: [Python-Dev] Python 2.7 EOL date

On 8/23/2018 4:30 PM, Victor Stinner wrote: Hi, The reference is the PEP 373 "Python 2.7 Release Schedule". See the "Update" section: https://www.python.org/dev/peps/pep-0373/#update We could probably make it more clear in this section and/or in https://www.python.org/dev/peps/pep-0373/#id4

Re: [Python-Dev] USE_STACKCHECK and running out of stack

On Sat, Jul 28, 2018 at 7:51 AM Ronald Oussoren via Python-Dev < python-dev@python.org> wrote: > Hi, > > I’m looking at PyOS_CheckStack because this feature might be useful on > macOS (and when I created bpo-33955 for this someone ran with it and > created a patch). > > Does anyone remember why

Re: [Python-Dev] Finding Guido's replacement

On 7/24/2018 4:32 PM, Gregory P. Smith wrote: On Tue, Jul 24, 2018 at 12:27 PM Abdur-Rahmaan Janhangeer mailto:arj.pyt...@gmail.com>> wrote: not googler i mean google. they requested a change to a pep "They"?  nah.  "Google LLC" did not request anything. People

Re: [Python-Dev] Finding Guido's replacement

On Tue, Jul 24, 2018 at 12:27 PM Abdur-Rahmaan Janhangeer < arj.pyt...@gmail.com> wrote: > not googler i mean google. they requested a change to a pep > "They"? nah. "Google LLC" did not request anything. People who happen to be working for Google on a Google owned project asked a question

Re: [Python-Dev] [Windows] how to prevent the wrong version of zlib1.dll to be used by lib-dynload modules

On Mon, Jul 23, 2018, 08:22 Eric Le Lay wrote: > Hello list, > > I encountered a problem with the Windows packaging of gPodder[1] > using msys2: > > basic libraries (zlib, openssl) depended upon by python > platform-specific modules are loaded preferably : > 1. from lib-dynload (where they are

Re: [Python-Dev] Fuzzing the Python standard library

s welcome. Just be careful that it's actually helpful :-). -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/opt

Re: [Python-Dev] Question about PEP 484

On Mon, Jul 16, 2018 at 1:44 PM Guido van Rossum wrote: > As one of the authors of PEP 484, *I* never thought there was an ambiguity > here. The intention was for stub files to conform to the same grammar as > regular .py files, but with a different interpretation. > > > "Have the same syntax as

Re: [Python-Dev] why is not 64-bit installer the default download link for Windows?

the 64-bit installer could detect 32-bit systems and explain to users that they got the wrong version and direct them to the correct one, that would help anyone who does get confused by the 64-bit installer becoming more prominent. -n -- Nathaniel J. Smith -- https://vorpus.org

Re: [Python-Dev] Time for 3.4.9 and 3.5.6

On 7/8/2018 8:35 PM, Terry Reedy wrote: On 7/8/2018 1:05 PM, Ivan Pozdeev via Python-Dev wrote: I'll use this opportunity to remind you that 3.4 build is broken -- it can't be built from start to installer with the instructions given because of outside factors (CPython has migrated from Hg to

Re: [Python-Dev] Call for prudence about PEP-572

On 7/8/2018 1:59 PM, Chris Angelico wrote: On Mon, Jul 9, 2018 at 3:55 AM, Eric V. Smith wrote: I agree with Chris in this case. That said, there is at least one place where the grammar does forbid you from doing something that would otherwise make be allowable: decorators. @lookup[0

Re: [Python-Dev] Call for prudence about PEP-572

On 7/8/2018 1:23 PM, Chris Angelico wrote: On Mon, Jul 9, 2018 at 3:14 AM, Giampaolo Rodola' wrote: On Sun, Jul 8, 2018 at 6:45 PM Steve Holden wrote: But the PEP 8 spellings are foo(x=1) and f(x := 1). The extra spacing makes it obvious that this isn't a regular named

Re: [Python-Dev] Call for prudence about PEP-572

On 7/8/2018 5:41 AM, Giampaolo Rodola' wrote: As for "assert" what I'm concern about is the proliferation of things like this:     class Foo:         def __init__(self):             assert self.x := fun1()             assert self.y := fun2()             assert self.z := fun3() When I look

<    1   2   3   4   5   6   7   8   9   10   >