On Wed, Jun 3, 2020 at 2:13 PM Victor Stinner wrote:
> Le mer. 3 juin 2020 à 19:17, Mark Shannon a écrit :
> > > I also *added* a bunch of *new* "getter" or "setter" functions to the
> > > public C API for my project of hiding implementation details, like
> > > making structures opaque:
> > > ht
Sounds like a natural fit, I'd just do it for 3.10.
On Sun, May 24, 2020, 9:45 AM Eric V. Smith wrote:
> Does anyone have an opinion on https://bugs.python.org/issue39673? It
> maps ETIME to TimeoutError, in addition to the already existing ETIMEDOUT.
>
> http://man7.org/linux/man-pages/man3/err
On Wed, May 20, 2020 at 11:09 AM Jim J. Jewett wrote:
> David Mertz wrote:
>
> > Fwiw, I don't think it changes my order, but 'strict' is a better word
> than
> > 'equal' in all those places. I'd subtract 0.1 from each of those votes if
> > they used "equal".
>
> I would say that 'equal' is worse
On Fri, May 15, 2020 at 11:55 AM Henk-Jaap Wagenaar <
wagenaarhenkj...@gmail.com> wrote:
> I'll join in with the fun...
>
> zip(strict=True) +1
> itertools.zip_strict() +0
>
Agreed. The best way to reduce accidental incorrect use of the builtin is
to make the builtin capable of doing what a peop
On Wed, May 6, 2020 at 1:14 PM Serhiy Storchaka wrote:
> 06.05.20 00:46, Victor Stinner пише:
> > Subinterpreters and multiprocessing have basically the same speed on
> > this benchmark.
>
> It does not look like there are some advantages of subinterpreters
> against multiprocessing.
>
There is
On Mon, May 4, 2020 at 9:45 AM Steve Dower wrote:
> For those who haven't looked in a while, the uuid module uses ctypes to
> look up libuuid for uuid_generate_time_safe() and uuid_generate_time()
> functions.
>
> I've run into scenarios where I need to remove this from our own builds,
> but it s
On Wed, Apr 29, 2020 at 5:40 AM Julien Salort wrote:
> Le 29/04/2020 à 03:18, Eric Snow a écrit :
>
> > My (honest) question is, how many folks using subinterpreters are
> > going to want to use numpy (or module X) enough to get mad about it
> > before the extension supports subinterpreters? Wha
On Tue, Apr 21, 2020 at 9:35 PM Gregory P. Smith wrote:
> Could we go ahead and mark lib2to3 as Pending Deprecation in 3.9 so we can
> get it out of the stdlib by 3.11 or 3.12?
>
I'm going ahead and tracking the idea in https://bugs.python.org/issue40360.
>
> lib2to3 is th
Could we go ahead and mark lib2to3 as Pending Deprecation in 3.9 so we can
get it out of the stdlib by 3.11 or 3.12?
lib2to3 is the basis of all sorts of general source code manipulation
tooling. Its name and original reason d'etre have moved on. It is
actively used to parse and rewrite Python 3
On Tue, Apr 21, 2020 at 10:49 AM Antoine Pitrou wrote:
> On Tue, 21 Apr 2020 18:46:04 +0200
> Petr Viktorin wrote:
> > On 2020-04-21 11:01, Antoine Pitrou wrote:
> > > On Mon, 20 Apr 2020 19:21:21 -0600
> > > Eric Snow wrote:
> > >> Honest question: how many C extensions have process-global sta
On Wed, Apr 15, 2020 at 7:37 AM Victor Stinner wrote:
> Le mer. 15 avr. 2020 à 05:02, Raymond Hettinger
> a écrit :
> > I would like to make that functionality available to the JSON module (or
> just about anything else that accepts a custom dict) by adding the magic
> methods for mappings so th
On Wed, Apr 15, 2020 at 12:49 PM Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:
> First of all, be aware of the limitations of this approach (which will
> need to be clearly documented if we go this way):
>
>- It only allows valid Python identifiers -- while JSON accepts any
>
On Tue, Mar 24, 2020 at 11:55 AM Brett Cannon wrote:
> -1 on "cut*" because my brain keeps reading it as "cute".
> +1 on "trim*" as it is clear what's going on and no confusion with
> preexisting methods.
> +1 on "remove*" for the same reasons as "trim*".
>
> And if no consensus is reached in thi
Nice PEP! That this discussion wound up in the NP-complete "naming things"
territory as the main topic right from the start/prefix/beginning speaks
highly of it. :)
The only things left I have to add are (a) agreed on don't specify if it is
a copy or not for str and bytes.. BUT (b) do specify that
e for upgrading us to 3.9 so we'd simply make
that happen at that time)
-gps
On Fri, Jan 17, 2020 at 11:09 AM Gregory P. Smith wrote:
> +1 remove it to match that policy. I find it unlikely someone will ask
> for it to be restored, but our first response before doing so should be to
&
+1 remove it to match that policy. I find it unlikely someone will ask for
it to be restored, but our first response before doing so should be to see
if they can instead use it as a dependency via PyPI: Someone who wants to
maintain it for future use can take 3.8 formatter module and put it there.
On Wed, Jan 1, 2020 at 6:40 AM Andrew Svetlov
wrote:
> __del__ is very useful not for interpreter shutdown but as a regular
> destructor in object's lifecycle.
>
The reason we should warn people against ever implementing __del__ is that
people rarely actually understand object lifecycle. Its pr
On Tue, Dec 17, 2019 at 12:30 PM Kacvinsky, Tom
wrote:
> We ran into an issue where having the SQLite library built with
> -DSQLITE_THREADSAFE=0,
> but then the sqlite3 module (really, the _sqlite3.so0 crashing in
> threading code. So I have
> to ask if it is intended that the sqlite3 Python mo
On Mon, Dec 16, 2019 at 11:11 AM Steve Dower wrote:
> On 13Dec2019 0959, Brett Cannon wrote:
> > Steve Dower wrote:
> >> If people are generally happy to move PR builds/checks to GitHub
> >> Actions, I'm happy to merge https://github.com/zooba/cpython/pull/7
> >> into
> >> our active branches (wi
I personally think we shouldn't worry about it. I *try* to use an autoconf
version at least as recent as what was used for the current file, but
beyond that it is unlikely anything depends on autoconf distroisms within
our own in tree configure.
Forcing humans to do weird tricks (always guaranteed
My overall problem with the PEP and a reason I'd reject it by default it
that it is asking to pre-emptively impose limits on things, some of which
we believe would cause problems to existing long running applications
(limiting the total number of types for example), without having actually
demonstr
I'd prefer it if we stayed on topic here...
On Fri, Dec 6, 2019 at 3:15 PM Chris Angelico wrote:
> On Sat, Dec 7, 2019 at 9:58 AM Greg Ewing
> wrote:
> >
> > On 7/12/19 2:54 am, Rhodri James wrote:
> >
> > > You've talked some about not making the 640k mistake
> >
> > I think it's a bit unfair
On Tue, Dec 3, 2019 at 8:21 AM Mark Shannon wrote:
> Hi Everyone,
>
> I am proposing a new PEP, still in draft form, to impose a limit of one
> million on various aspects of Python programs, such as the lines of code
> per module.
>
> Any thoughts or feedback?
>
> The PEP:
> https://github.com/ma
On Wed, Nov 27, 2019 at 10:15 AM Brett Cannon wrote:
> Gregory P. Smith wrote:
> > On Tue, Nov 26, 2019 at 12:00 PM Brett Cannon br...@python.org wrote:
> > > Python 3.9 is going to be the first release which
> > > will exist without any
> > > Python 2.7 ove
On Tue, Nov 26, 2019 at 12:00 PM Brett Cannon wrote:
> Python 3.9 is going to be the first release which will exist without any
> Python 2.7 overlap. Does this mean we are ready to start removing things
> that have been deprecated since at least Python 3.7? PEP 4 says [we are in
> the clear for m
On Fri, Nov 22, 2019 at 10:10 AM Mark Shannon wrote:
> Hi,
>
> On 21/11/2019 8:04 pm, Brett Cannon wrote:
> > An unfortunate side-effect of making PyInterpreterState in Python 3.8
> opaque is it removed [PEP 523](https://www.python.org/dev/peps/pep-0523/)
> support. https://www.python.org/dev/pep
On Fri, Aug 9, 2019 at 11:37 AM Eric V. Smith wrote:
> On 8/9/2019 2:28 PM, Jonathan Goble wrote:
> > On Fri, Aug 9, 2019 at 12:34 PM Nick Coghlan wrote:
> >> I find the "Our deprecation warnings were even less visible than
> >> normal" argument for extending the deprecation period compelling.
>
On Fri, Aug 9, 2019 at 8:43 AM Guido van Rossum wrote:
> This discussion looks like there's no end in sight. Maybe the Steering
> Council should take a vote?
>
I've merged the PR reverting the behavior in 3.8 and am doing the same in
the master branch.
The sheer volume of email this is generati
People distribute code via pypi. if we reject uploads of packages with
these problems and link to fixers (modernize can be taught what to do), we
prevent them from spreading further. A few years after doing that, we can
revisit how much pain and for whom making this a SyntaxWarning or even
Syntax
On Tue, Aug 6, 2019 at 10:06 AM Neil Schemenauer
wrote:
>
> Making it an error so soon would be mistake, IMHO. That will break
> currently working code for small benefit. When Python was a young
> language with a few thousand users, it was easier to make these
> kinds of changes. Now, we shoul
On Mon, Jul 1, 2019 at 9:01 AM Steven D'Aprano wrote:
> On Sat, Jun 29, 2019 at 10:26:04AM -0500, Skip Montanaro wrote:
> > > You have missed at least one: the minimum technology requirement for
> > > using Github is a lot more stringent than for Roundup. Github's minimum
> > > system requirement
On Thu, Jun 6, 2019 at 6:19 AM Victor Stinner wrote:
> Le jeu. 6 juin 2019 à 14:18, Steven D'Aprano a
> écrit :
> > i.e. 25-40% longer. Is there a shorter permalink form available, like
> > goo.gl, bitly, youtu.be etc use? That would be awesome if we could use
> > them instead.
>
> I really disl
On Fri, May 24, 2019 at 1:48 PM Ezio Melotti wrote:
>
> On Fri, May 24, 2019, 20:23 Gregory P. Smith wrote:
>
>> -cc: committers to avoid crossposting.
>>
>
> +1 (I wanted to include committers, since the announcement about PEP 581
> was posted there too, but it&#
-cc: committers to avoid crossposting.
I have feedback for roundup as experienced on BPO that should be
represented within PEP 595 if we are going to have a summary of "improving
roundup for BPO" captured in a PEP (presumably already rejected given 581?
But good to have documented regardless so _t
I suggest filing a bug to track this...
On Thu, May 23, 2019 at 10:13 AM Tim Peters wrote:
> [Inada Naoki ]
> > ...
> > 2. This loop is cleary hot:
> >
> https://github.com/python/cpython/blob/51aa35e9e17eef60d04add9619fe2a7eb938358c/Objects/obmalloc.c#L1816-L1819
>
> Which is 3 lines of code pl
I like the feature, we should have it. It'll be useful for debugging and
probably more.
Which brings me to the annoying paint color question: These exceptions were
most definitely raised. Thus the term "unraisable" is wrong. I believe you
really mean "uncatchable".
-gps
On Thu, May 16, 2019 at
On Fri, May 3, 2019 at 10:46 PM Eric V. Smith wrote:
> Is there a policy against using Unicode identifiers in test files?
>
> As part of adding !d to f-strings, there's a code path that's only
> executed if the text of the expression is non-ascii. The easiest way to
> exercise it, and the way I f
On Wed, Apr 10, 2019 at 11:00 AM Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:
>
> On 10.04.2019 7:30, Karthikeyan wrote:
>
> Thanks Gregory. I think it's a good tradeoff to ensure this validation
> only for URLs of http scheme.
>
> I also agree handling newline is little problematic
On Tue, Apr 9, 2019 at 4:45 PM Karthikeyan wrote:
> I would recommend fixing it since it's potentially remote code execution
> on systems like Redis (latest versions of Redis have this mitigated) though
> I must admit I don't fully understand the complexity since there are
> multiple issues linke
On Mon, Apr 1, 2019 at 4:49 PM Cameron Simpson wrote:
> On 01Apr2019 15:44, Steve Dower wrote:
> >On 01Apr2019 1535, Cameron Simpson wrote:
> >>On 01Apr2019 09:12, Steve Dower wrote:
> >>>On 30Mar2019 1130, Gregory P. Smith wrote:
> >>>>I wouldn&#
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:
>
ual next time I
hear 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)
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++ extensi
(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
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 th
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
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:
>> https://bugs.pyth
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 thing
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 dec
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
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'
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
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
> talk
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 ci
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?
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 t
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 abou
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 https:
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 sm
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 t
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
2018 at 12:04 PM 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.
&
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 "standar
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
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
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
>
>
> 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
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 com
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
> > essentially an abstraction layer, that's d
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
> > <=> new C API) is very importa
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 pu
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 var
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?
>
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
>
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 zipfi
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 th
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 see
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
Hah, yes, that was un-intuitive for me. I was looking for something
labelled "logs" to click on. thanks. (I hope MS is taking notes on UX
issues here)
So these failures were in fact the known flakes and not infrastructure.
good!
On the high level view of VSTS output on a failure:
"Issues:
pha
These both look like VSTS infrastructure falling over on PRs:
https://python.visualstudio.com/cpython/_build?buildId=522
https://python.visualstudio.com/cpython/_build?buildId=523
I don't see anywhere that gives information about the failures. (*)
These CI failures on different platforms are
Why did this commit modify .py files, unittests, and test.support?
That is inappropriate for something claiming to merely enable a CI platform.
-gps
On Thu, May 17, 2018 at 6:50 AM Steve Dower
wrote:
>
> https://github.com/python/cpython/commit/0d8f83f59c8f4cc7fe125434ca4ecdcac111810f
> commit
On Thu, May 3, 2018 at 5:22 PM, Lukasz Langa wrote:
>
> > On May 2, 2018, at 8:57 PM, INADA Naoki wrote:
> >
> > Recently, I reported how stdlib slows down `import requests`.
> > https://github.com/requests/requests/issues/4315#issuecomment-385584974
> >
> > For Python 3.8, my ideas for faster s
+1 to the concept!
On Thu, May 3, 2018 at 1:13 PM, Carl Shapiro wrote:
> Hello,
>
> Yesterday Neil Schemenauer mentioned some work that a colleague of mine
> (CCed) and I have done to improve CPython start-up time. Given the recent
> discussion, it seems timely to discuss what we are doing and
On Wed, May 2, 2018 at 2:13 PM, Barry Warsaw wrote:
> Thanks for bringing this topic up again. At $day_job, this is a highly
> visible and important topic, since the majority of our command line tools
> are written in Python (of varying versions from 2.7 to 3.6). Some of those
> tools can take
On Wed, Apr 18, 2018 at 11:04 AM Barry Warsaw wrote:
> On Apr 18, 2018, at 10:43, MRAB wrote:
>
> > Some languages use '=' for assignment, others for equality, but do you
> know of a language that uses ':=' for equality' or '==' for assignment?
>
> Clearly we should take a page from the ternary
On Mon, Apr 2, 2018 at 3:57 PM Lukasz Langa wrote:
>
> > On Apr 2, 2018, at 2:13 PM, Antoine Pitrou wrote:
> >
> > On Mon, 2 Apr 2018 13:48:46 -0700
> > Lukasz Langa wrote:
> >> Pickle protocol version 4.0 was originally defined back in PEP 3154 and
> shipped as part of Python 3.4 back in 2011.
Given that, go ahead and change in master (3.8).
On Mon, Apr 2, 2018 at 3:13 PM Christian Heimes
wrote:
> On 2018-04-02 22:48, Lukasz Langa wrote:
> > Pickle protocol version 4.0 was originally defined back in PEP 3154 and
> shipped as part of Python 3.4 back in 2011. Yet it's still not the defa
On Mon, Mar 12, 2018 at 9:51 AM Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
> There is a feature request and patch to propagate the float.is_integer()
> API through rest of the numeric types ( https://bugs.python.org/issue26680
> ).
>
> While I don't think it is a good idea, the OP has
On Tue, Feb 20, 2018 at 6:50 PM Brett Cannon wrote:
> It's been a year and 10 days since we moved to GitHub, so I figured now is
> as good a time as any to ask people if they are generally happy with the
> workflow and if there is a particular sticking point to please bring it up
> on the core-wo
How often do we find ourselves grumbling over .py file style in PRs on
github? If the answer to that isn't very often, the rest of my response
below seems moot. :)
On Wed, Feb 21, 2018 at 7:30 PM Guido van Rossum wrote:
> Where I work we have some teams using flake8 and some teams that use
> py
+1 using unsafe_hash as a name addresses my concern. It's a good signal
that there are caveats worth considering.
-gps
On Sun, Feb 4, 2018, 9:50 PM Guido van Rossum wrote:
> Looks like this is turning into a major flamewar regardless of what I say.
> :-(
>
> I really don't want to lose the abil
On Fri, Feb 2, 2018 at 10:25 PM Nick Coghlan wrote:
>
>
> On 3 Feb. 2018 1:09 am, "Eric V. Smith" wrote:
>
>
> The problem with dropping hash=True is: how would you write __hash__
> yourself? It seems like a bug magnet if you're adding fields to the class
> and forget to update __hash__, especia
On Wed, Jan 31, 2018 at 4:46 PM Jesus Cea wrote:
> https://docs.python.org/3.6/library/threading.html doesn't document
> "threading.Lock().locked()", and it is something quite useful.
>
> In fact, it is used in "threading.py" itself. For instance, lines 109,
> 985, 1289.
>
> Is there any reason t
TL;DR of Steve's post - MSVC is the compiler of choice for most serious
software on Windows. So we use it to best integrate with the world. There
is no compelling reason to change that.
The free-as-in-beer MSVC community edition is finally non-sucky (their
earlier efforts were crippled, they seem
I'm curious if changing the obmalloc.c ALIGNMENT and ALIGNMENT_SHIFT
defines is sufficient to avoid ABI breakage.
-gps
On Tue, Jan 30, 2018 at 1:20 PM Gregory P. Smith wrote:
> The proper fix for this in the code would likely break ABI compatibility
> (ie: not possible in python
The proper fix for this in the code would likely break ABI compatibility
(ie: not possible in python 2.7 or any other stable release).
Clang's UBSAN (undefined behavior sanitizer) has been flagging this one for
a long time.
In Python 3 a double is used instead of long double since 2012 as I did
s
On Sat, Jan 13, 2018 at 4:34 PM Steven D'Aprano wrote:
> On Sat, Jan 13, 2018 at 02:23:19PM +0100, Antoine Pitrou wrote:
> > On Sat, 13 Jan 2018 13:54:33 +0100
> > Christian Heimes wrote:
> > >
> > > If we agree to drop support for OpenSSL 0.9.8 and 1.0.1, then I can
> land
> > > bunch of useful
On Mon, Jan 8, 2018 at 4:03 PM Random832 wrote:
> On Mon, Jan 8, 2018, at 18:05, Gregory P. Smith wrote:
> > i agree with just a list of tuples, but i suggest creating namedtuple
> > instances in the posix module for the purpose (one each for close, dup2,
> > open) . Don&#
On Mon, Jan 8, 2018 at 12:36 PM Serhiy Storchaka
wrote:
> 08.01.18 11:11, Pablo Galindo Salgado пише:
> > Following Gregory's comment on the PR I understand that he is proposing
> > to have three objects in the os module representing each action and pass
> > a sequence of these objects to the Pyt
the best way to improve shell escaping on windows is to send a PR against
the list2cmdline code that escapes everything you believe it should when
running on windows. With hyperlinks to the relevant msdn info about what
might need escaping.
On Sun, Jan 7, 2018 at 11:38 AM Christian Tismer
wrote:
101 - 200 of 628 matches
Mail list logo
