On Wed, 24 Feb 2021 13:47:40 +0100
Stéfane Fermigier wrote:
> On Wed, Feb 24, 2021 at 12:42 PM Paul Moore
> wrote:
>
> > On Wed, 24 Feb 2021 at 10:55, Stéfane Fermigier
> > wrote:
> > > There is probably a clever way to reuse common packages (probably via
> > clever symlinking) and
On Fri, 27 Nov 2020 08:56:18 -0500
Ned Batchelder
wrote:
> On 11/27/20 8:32 AM, Antoine Pitrou wrote:
> > On Fri, 27 Nov 2020 07:32:17 -0500
> > 2qdxy4rzwzuui...@potatochowder.com
> > wrote:
> >> I come from old(er) school (1980s, 1990s) embedded systems, an
On Fri, 27 Nov 2020 07:32:17 -0500
2qdxy4rzwzuui...@potatochowder.com
wrote:
>
> I come from old(er) school (1980s, 1990s) embedded systems, and who
> "owns" a particular mutable data structure and how/where it gets mutated
> always came up long before we wrote any code. No, I'm not claiming
On Fri, 27 Nov 2020 07:50:20 +1100
Steven D'Aprano wrote:
> On Thu, Nov 26, 2020 at 02:15:50PM -0500, nate lust wrote:
>
> > It would be convenient if you could mark in source code that you intended a
> > resource to be "moved" and any further access through other bindings are
> > not what was
Why are you trying to replicate move semantics in Python? The Python
ownership model is entirely different from C++. In C++ terms, every
Python object is like a shared_ptr<> (but with additional support for
tracking and collecting reference cycles).
Generally, when a Python function wants to
On Tue, 24 Nov 2020 10:23:10 +
Paul Moore wrote:
> On Tue, 24 Nov 2020 at 10:18, Antoine Pitrou wrote:
> >
> > On Mon, 23 Nov 2020 08:09:07 +
> > Paul Moore wrote:
> > >
> > > But it's not as limiting as you suggest - it *does* preclude most
>
On Mon, 23 Nov 2020 08:09:07 +
Paul Moore wrote:
>
> But it's not as limiting as you suggest - it *does* preclude most
> scientific use (because of numpy etc) but (for example) a large number
> of web libraries are pure Python.
Not sure what you mean here, but while Web frameworks
On Thu, 19 Nov 2020 19:44:57 +1100
Steven D'Aprano wrote:
> On Thu, Nov 19, 2020 at 08:22:40AM +0400, Abdur-Rahmaan Janhangeer wrote:
> >
> > What do you think of adding PyInstaller as an official
> > part of CPython?
>
> Before asking *us*, you ought to ask what the PyInstaller developers
On Fri, 16 Oct 2020 12:38:49 +0300
Ram Rachum wrote:
> Well, I can also write a decorator that does lru_cache, but there are a lot
> of advantages that it's available in the standard library...
But the standard libary doesn't have to contain every utility function
on Earth.
And if you want it
On Fri, 16 Oct 2020 11:34:08 +0300
Ram Rachum wrote:
> Did you mean like keeping a hidden attribute on the object with the result?
> Well, that'd require manually keeping track of these attributes for each
> method I'm caching. I do that sometimes, but it's verbose.
You can write a decorator
On Thu, 15 Oct 2020 22:31:25 -0600
Carl Meyer wrote:
> On Thu, Oct 15, 2020 at 3:33 PM David Mertz wrote:
> > So the use case needs to be:
> >
> > * Function operates on large objects
> > * Function operates on large, immutable objects
> > * Function never takes literal or computed arguments
On Tue, 13 Oct 2020 05:58:45 -
"Ma Lin" wrote:
>
> I heard in data science domain, the data is often huge, such as hundreds of
> GB or more. If people can make full use of multi-core CPU to compress, the
> experience will be much better than zlib.
This is true, but in data science it is
On Wed, 23 Sep 2020 13:26:13 +0300
Omer Katz wrote:
> I pointed out a use case for Brotli & HTTP2 as a concrete example for why
> it'd be more convenient to include brotli as a module.
> I'm sure there are other cases I haven't thought about.
>
> I don't understand why LZMA should be included
Hi,
On Mon, 21 Sep 2020 09:31:47 -
"Omer Katz" wrote:
> Hello everyone,
>
> We have many compression algorithms as standard modules, but we lack two
> important new algorithms: brotli and zstandard.
>
> Brotli is an important compression algorithm both for HTTP2 and for
>
On Sun, 30 Aug 2020 09:51:14 +0100
Barry Scott wrote:
> That is 4x slower then my code for 1,000,000 items.
This is highly dependent on the cost of equality checks, therefore on
the type being compared.
Regards
Antoine.
___
Python-ideas mailing list
On Wed, 26 Aug 2020 12:46:18 -0400
David Mertz wrote:
> In my mind, *anything* other than the straightforward and obvious signature
> `__getitem__(self, index, **kws)` is a pointless distraction.
Probably. However, one must define how it's exposed in C.
Regards
Antoine.
On Mon, 17 Aug 2020 08:49:23 -
"Ruben Vorderman" wrote:
> Dear python developers,
>
> As a bioinformatician I work a lot with gzip-compressed data. Recently I
> discovered Intel's Storage Acceleration Libraries at
> https://github.com/intel/isa-l. These people implemented the DEFLATE and
On Mon, 17 Aug 2020 22:54:32 +1200
Greg Ewing wrote:
> On 17/08/20 9:58 pm, Antoine Pitrou wrote:
> > Probably because exploiting Python abstraction facilities to build DSLs
> > has/had long been frown upon in this community? That was the leitmotiv
> > back when people
On Sat, 15 Aug 2020 19:27:24 -0700
Guido van Rossum wrote:
> On Sat, Aug 15, 2020 at 7:14 PM Caleb Donovick
> wrote:
>
> > > To me, the main weakness here is that you couldn't move forward with
> > this unless you also got the various static type checkers on board. But I
> > don't think
On Fri, 07 Aug 2020 08:54:37 -
"Kazantcev Andrey"
wrote:
> Chris Angelico wrote:
> > Why do you want dump and load to take parameters from "somewhere
> > else"?
>
> Because developers of libraries don't think about configuring json.dump
> method in mos of cases.
Then you should report
I agree with Raymond. The "implicit context" pattern is really only
desirable in a small subset of situations, and I don't think
configuring JSON serialization is one of those.
(it may even be an active nuisance, because some libraries may be using
JSON as an implementation detail and a "JSON
On Wed, 22 Jul 2020 15:06:59 +0200
Marco Sulla
wrote:
> What I'm doing on the contrary is a micro benchmark: I would confront if an
> algorithm is faster in a particular case (immutable dict).
>
> I runned the benchmarks many times, and even if the absolute values are not
> stable, the delta
On Sun, 19 Jul 2020 05:01:48 -0400
Wes Turner wrote:
>
> Can't remember where I thought I read that libuv + CPython asyncio is
> actually faster than node + libuv.
"faster" is pretty much meaningless without specifics. libuv + asyncio
will certainly be fast if you're mostly transferring
On Wed, 15 Jul 2020 09:45:06 +1000
Steven D'Aprano wrote:
>
> And that's the risk: can I guarantee that there is no clever scheme by
> which an attacker can fool me into unpickling malicious code? I need to
> be smarter than the attacker, and more imaginative, and to have thought
> as long
On Sun, 28 Jun 2020 01:41:01 +1000
Steven D'Aprano wrote:
>
> and ECMA-262 section 24.5.2, JSON.stringify, NOTE 4, page 683 states:
>
> "Finite numbers are stringified as if by calling ToString(number). NaN
> and Infinity regardless of sign are represented as the String null."
Ahh... typical
On Thu, 25 Jun 2020 18:32:48 -0700
Yonatan Zunger via Python-ideas
wrote:
>
> So that's an example of why you might find yourself in such a situation in
> userland. And overall, Python's signal handling mechanism is pretty good;
> it's *way* nicer than having to deal with it in C, since signal
On Sun, 21 Jun 2020 11:07:05 +0200
Antoine Pitrou wrote:
>
> There's no such thing as "the cache". There are usually several levels
> of cache. L1 cache is closest to the CPU [...]
... Note by "closest to the CPU" I really mean "closest to the CPU
cor
On Fri, 19 Jun 2020 20:30:03 +0100
Barry Scott wrote:
>
> > I know very little about how this works except a vague rule of thumb
> > that in the 21st century memory locality is king. If you want code to be
> > fast, keep it close together, not spread out.
>
> Remember that the caches are
Hello,
I think you forgot the all-important parts:
1) How does it work technically?
2) What performance gain on which benchmark?
Regards
Antoine.
On Thu, 18 Jun 2020 10:36:11 +0100
Jonathan Fine wrote:
> Hi All
>
> Summary: Shared objects in Unix are a major influence. This proposal can
On Tue, 16 Jun 2020 09:34:59 +0100
Jonathan Fine wrote:
>
> I've changed my opinion. I doubt that there's an easy win here. But I
> suspect that there is a win that is worth having. I'll now go away and
> think about things for a while.
This is a good idea. An even better idea, for people who
Can I just write "boo, hiss"?
In any case, even if those may be made unambiguous for the current
parser (I have no idea if that's true), they're visually ambiguous for
a human reader. With parentheses, it's immediate what are function
calls. Without, it's far less obvious whether such calls
On Fri, 29 May 2020 22:18:15 +0300
Paul Sokolovsky wrote:
> In all fairness, I don't know if Stackless ever fully waved GIL
> goodbye. If not, it shows how much the Python userbase needs to get rid
> of GIL.
Yes, nevermind that Stackless was designed at a time when multicore
computers were an
On Fri, 29 May 2020 09:48:53 -
"Mark Dickinson"
wrote:
>
> I have a proof-of-concept PR [1] that exposes this in the `operator` module
> as `operator.as_float`. See also the discussion on the tracker [2].
`operator.as_float` sounds good to me. There's the `operator.index`
precedent.
On Wed, 27 May 2020 21:24:08 +0300
Paul Sokolovsky wrote:
> Hello,
>
> On Wed, 27 May 2020 08:18:11 -
> redrad...@gmail.com wrote:
>
> > Thanks Guido !!
> >
> > I have not known about `pyston` ... It is pretty good like for me
> > I will take a close look at this project
>
> A recent
On Tue, 26 May 2020 22:19:12 -0400
Kyle Stanley wrote:
>
> > It could become more detailed about each minor versions, git tag, links
> to changelogs, links to the repositories, to the docs, download links,
> and so on.
>
> I don't know that it needs to be said, but for now, I think we should
On Wed, 20 May 2020 07:52:22 -0700
Guido van Rossum wrote:
> No, it's because the message speaks English, not Python, and in English we
> count starting from one. Users would be very confused you counted from zero
> here,
Agreed. I would be confused myself.
Regards
Antoine.
On Wed, 13 May 2020 20:52:38 +1000
Steven D'Aprano wrote:
>
> I don't know how complete HFS+ support is on Linux or Windows, but in
> principle any OS that supports HFS+ or (maybe) Joliet could have files
> with NULs.
>
> Remember that NULs may be legal next time you are stress testing your
On Sun, 3 May 2020 14:58:41 -0700
Andras Tantos wrote:
>
> 1. With the recent type-hint support, the feature could be made way more
> descriptive if this PEP got implemented.
>
> For example, instead of doing the following:
>
> def func(in: Dict[str, int])
>
> one could
On Sun, 3 May 2020 21:57:42 -0700
Guido van Rossum wrote:
> I should really stay out of this (hundreds of messages and still
> bickering^Wbikeshedding :-), but I personally find strict=True *less*
> confusing than equal=True, both for zip() and for map(). If I didn't know
> what was going on,
Andrew, can you describe the memory model issue in detail?
Regards
Antoine.
On Fri, 1 May 2020 22:45:13 -0700
Andrew Barnert via Python-ideas
wrote:
> On May 1, 2020, at 09:51, Tom Forbes wrote:
> >
> >> You’ve written an exactly equIvalent to the double-checked locking for
> >>
On Tue, 28 Apr 2020 11:04:15 +1000
Steven D'Aprano wrote:
>
> Yes, it's annoying when English words can have two or more meanings. The
> first time I can across math.sin, I was very excited, until I realised
> it was just the trigonometric function :-(
>
> This is the gunslinger.draw versus
here was. Would this require a
> PEP to be submitted? Or is it similar enough to existing functionality that
> it might not require one?
>
> > On 27 Apr 2020, at 19:37, Antoine Pitrou
> > wrote:
> >
> > On Mon, 27 Apr 2020 09:26:53 -0700
> > Ethan Furman wr
On Mon, 27 Apr 2020 09:26:53 -0700
Ethan Furman wrote:
>
> > Or are you saying that once could be interpreted to mean I cannot do that
> > 2nd def?
>
> That is what I was saying -- that `once`, all by itself, could mean multiple
> things.
That's a good point. A more explicit spelling
On Wed, 22 Apr 2020 12:52:01 +1000
Steven D'Aprano wrote:
> On Wed, Apr 22, 2020 at 01:07:07AM +0200, Antoine Pitrou wrote:
> > On Wed, 22 Apr 2020 08:34:56 +1000
> > Steven D'Aprano wrote:
> > > On Tue, Apr 21, 2020 at 12:09:44PM +0300, Serhiy Storchaka wrote:
On Wed, 22 Apr 2020 08:34:56 +1000
Steven D'Aprano wrote:
> On Tue, Apr 21, 2020 at 12:09:44PM +0300, Serhiy Storchaka wrote:
> > 21.04.20 11:15, Antoine Pitrou пише:
> > >Of course, the fact that zip() is the shorter form that everyone is
> > >used to means that,
On Mon, 20 Apr 2020 12:39:05 -0700
Andrew Barnert via Python-ideas
wrote:
> On Apr 20, 2020, at 11:25, Brandt Bucher wrote:
> >
> > I disagree. In my own personal experience, ~80% of the time when I use
> > `zip` there is an assumption that all of the iterables are the same length.
> >
>
>
On Mon, 20 Apr 2020 18:25:08 -
"Brandt Bucher"
wrote:
> > This is definitely sometimes useful, but I think less often than
> > zip_longest, which we already decided long ago isn’t important enough to
> > push into zip but instead should be a separate function living in
> > itertools.
>
On Thu, 16 Apr 2020 05:07:15 +1000
Chris Angelico wrote:
> On Thu, Apr 16, 2020 at 4:55 AM Ander Juaristi wrote:
> > TLS session resumption is currently supported, but only within the same
> > process. To the best of my knowledge, there is no way to save the TLS
> > session to a file to resume
On Thu, 9 Apr 2020 20:56:56 -0700
"Gregory P. Smith" wrote:
> On Wed, Apr 8, 2020, 10:37 AM Antoine Pitrou wrote:
>
> > On Wed, 8 Apr 2020 10:18:47 -0700
> > Guido van Rossum wrote:
> > >
> > > > But when I leave "large" temp obje
On Wed, 8 Apr 2020 10:18:47 -0700
Guido van Rossum wrote:
>
> > But when I leave "large" temp objects hanging and
> > give a rip, I already stick in "del" statements anyway. Very rarely,
> > but it happens.
> >
>
> I recall that in the development of asyncio there were a few places where
>
On Wed, 8 Apr 2020 09:53:41 -0700
Guido van Rossum wrote:
> Look at the following code.
>
> def foo(a, b):
> x = a + b
> if not x:
> return None
> sleep(1) # A calculation that does not use x
> return a*b
>
> This code DECREFs x when the frame is exited (at the return
On Wed, 1 Apr 2020 10:20:39 -0700
Andrew Barnert via Python-ideas
wrote:
> On Mar 31, 2020, at 20:03, Greg Ewing wrote:
> >
> > On 1/04/20 7:08 am, Serhiy Storchaka wrote:
> >> 31.03.20 20:52, Antoine Pitrou пише:
> >>> Your search is incomplet
Your search is incomplete, for example you failed to account for
occurrences of "cheese" and "milkshake".
Regards
Antoine.
On Tue, 31 Mar 2020 19:17:18 +0200
Gerrit Holl wrote:
> (needs a sponsor)
>
> latest version at
> https://github.com/gerritholl/peps/blob/animal-friendly/pep-.rst
On Tue, 10 Mar 2020 15:16:06 +0100
Remy NOEL wrote:
> On Mon, Mar 9, 2020 at 11:18 PM Kyle Stanley wrote:
>
> > We're currently looking into adjusting the current Executor implementation
> > (for both TPE and PPE) to not use daemon threads at all for subinterpreter
> > compatibility, see
On Mon, 24 Feb 2020 09:16:12 -0800
Christopher Barker
wrote:
> This is an honest question:
>
> Is it helpful to anyone taking part in this conversation about the
> conversation to have it?
>
> I don’t think it’s helpful to the list as a whole, honestly.
Agreed. Especially as it seems to be
On Mon, 17 Feb 2020 12:19:59 -0800
Guido van Rossum wrote:
> It's actually really hard to implement your own Future class that works
> well with concurrent.futures.as_completed() -- this is basically what
> complicated the OP's implementation. Maybe it would be useful to look into
> a protocol to
On Sun, 16 Feb 2020 19:46:13 -0500
Kyle Stanley wrote:
>
> Based on the proposal in the OP, I had considered that it might also be
> needed to be able to manually set the state of the future through something
> like a `Future.set_state()`, which would have a parameter for accessing it
> safely
On Sun, 16 Feb 2020 17:41:36 -0500
Kyle Stanley wrote:
>
> As a side note, are we still interested in expanding the public API for the
> Future class? Particularly for a public means of accessing the state. The
> primary motivation for it was this topic, but I could easily the same
> issues
On Sun, 16 Feb 2020 09:29:36 -0500
Kyle Stanley wrote:
>
> After Andrew explained his own use case for it with isolating bugs to
> ensure that the issue wasn't occurring as a result of parallelism, threads,
> processes, etc; I certainly can see how it would be useful. I could also
> see a use
On Sat, 15 Feb 2020 14:16:39 -0800
Andrew Barnert via Python-ideas
wrote:
> > On Feb 15, 2020, at 13:36, Jonathan Crall wrote:
> >
> > Also, there is no duck-typed class that behaves like an executor, but does
> > its processing in serial. Often times a develop will want to run a task in
> >
I hadn't seen the original message (perhaps it fell through the GMane
migration). I think this would indeed be a worthwhile addition to
pickle.
Is it possible to continue this discussion on python-dev? I don't
think this is a PEP-level topic.
Regards
Antoine.
On Fri, 7 Feb 2020 12:48:48
On Fri, 7 Feb 2020 13:03:52 -0500
Todd wrote:
> Currently with pickle you have to "open" the file separately from the
> pickle operation, generally using a "with" clause, then provide the file
> object to one of the pickle.dump or pickle.load. This adds quite a bit of
> boilerplate for simply
On Fri, 27 Dec 2019 23:52:13 -0800
Christopher Barker
wrote:
> On Fri, Dec 27, 2019 at 5:39 PM Guido van Rossum wrote:
>
> > Is duck typing float or Decimal worth the bother? Barring that it could be
> > done with some isinstance() checks (in the user code, not in math.isnan()).
> >
>
>
On Sat, 28 Dec 2019 19:31:33 +1100
Chris Angelico wrote:
> On Sat, Dec 28, 2019 at 7:03 PM Steve Barnes wrote:
> >
> > Personally I still like the fundamental:
> >
> >
> >
> > def is_nan(num):
> >
> > “”” Test for NaN “””
> >
> > return num != num
> >
>
> Which was in Steven's
Hi,
Just bear in mind that I have read only a couple sentences in the PEP.
But as soon as you propose to offer only "partial compatibility" with
a previous version, then I think it's worse than useless. You are
introducing an additional Python version, i.e. "3.9 bended towards 3.8
partial
On Fri, 13 Sep 2019 10:27:10 -0700
Andrew Barnert via Python-ideas
wrote:
>
> (If you want a shiny modern solution instead, this looks like one of the few
> cases where hardware TM support can probably speed things up relatively
> easily, which would be a fun project to work on…)
Hardware
t to
> prevent data races. Making this reference count variable atomic will prevent
> passing locks with these variables.
>
> GIL helps in preventing this scenario in case of multithreading, but it very
> well occurs in case of multiprocessing. Although, the type of shared resource
On Tue, 10 Sep 2019 18:59:55 +1000
Chris Angelico wrote:
> On Tue, Sep 10, 2019 at 6:55 PM Antoine Pitrou wrote:
> >
> > On Mon, 9 Sep 2019 19:04:35 +1000
> > Chris Angelico wrote:
> > > On Mon, Sep 9, 2019 at 12:34 AM Vinay Sharma via Python-ideas
> > &
Hi Vinay,
On Mon, 09 Sep 2019 08:23:48 -
Vinay Sharma via Python-ideas
wrote:
>
> Also, as far as I know (might be wrong) Value is stored in shared memory and
> is therefore very fast also. So, what I am proposing is a similar object to
> value to which operations like add, sub, xor,
On Mon, 9 Sep 2019 19:04:35 +1000
Chris Angelico wrote:
> On Mon, Sep 9, 2019 at 12:34 AM Vinay Sharma via Python-ideas
> wrote:
> >
> > Currently, C++ has support for atomic types, on which operations like add,
> > sub, xor, etc can be done atomically, thereby avoiding data races.
> > Having
On Mon, 9 Sep 2019 11:04:22 -0700
Christopher Barker
wrote:
> I'm surprised no one has mentioned Psyco yet -- probably because it evolved
> into PyPy -- but IIRC, Psycho was pretty much the same as what the OP is
> talking about -- direct Python to machine code, and easy on the fly or
> ahead of
On Sun, 08 Sep 2019 18:17:17 -
"Mark @pysoniq" wrote:
> Hi, David,
>
> In several other posts here, I have distinguished PysoniQ from the open
> source projects mentioned. It has much better ease of use and faster
> published metrics than the other projects mentioned. The faster metrics
On Sun, 08 Sep 2019 17:27:27 -
"Mark @pysoniq" wrote:
> Antoine,
>
> In response to "You should provide a detailed technical of your solution."
>
> The automatically created ctypes wrapper is one of the keys of the project.
> Blog entries 1 & 2 are a very detailed and technical discussion
On Sun, 08 Sep 2019 17:20:30 -
"Mark @pysoniq" wrote:
> Antoine,
>
> In response to your comment: "Finally, Cython does not require any
> rewriting, and annotations are
> optional."
>
> With Cython the end user does need to modify the code by inserting C type
> definitions like this:
With all due respect, your description sounds more like marketing than
actual technical data. You should provide a detailed technical of your
solution, otherwise this is off-topic on this mailing-list.
Also, performance numbers without a detailed description of what's
exactly measured
oduct leaves a bad taste in my mouth.
> But it's also not like there aren't already 5 or more open source projects
> that do a similar thing better already.
>
> On Sun, Sep 8, 2019, 12:03 PM Antoine Pitrou
> wrote:
>
> >
> > How is your approach different fro
How is your approach different from, say, Cython, Nuitka or Pythran?
Regards
Antoine.
On Sun, 08 Sep 2019 15:56:04 -
"Mark @pysoniq" wrote:
> Hi, Anders,
>
> The availability of a free extension every 30 days is a big benefit to the
> Python community that may not be immediately
I recommend you take at look at the "toolz" library, which provides
assorted APIs to help in data structure manipulation:
https://toolz.readthedocs.io/en/latest/index.html
Especially this function:
https://toolz.readthedocs.io/en/latest/api.html#toolz.dicttoolz.get_in
Regards
Antoine.
On
On Thu, 29 Aug 2019 12:51:04 +0900
"Stephen J. Turnbull" wrote:
>
> If there's a protocol for
> converting objects to JSON, people will expect it to work, pretty much
> as much as __str__ does, at least in the domain that they're working
> in. And frequently it won't, and the user will be
On Wed, 28 Aug 2019 03:03:00 +0900
"Stephen J. Turnbull" wrote:
> Antoine Pitrou writes:
>
> > Here is a use case where it may remove some pain from users'life:
> > https://bugs.python.org/issue24313
>
> The problem is that a protocol like __json__ doesn
On Tue, 27 Aug 2019 10:51:52 +0100
Paul Moore wrote:
>
> For example, the numpy case might be covered completely by the JSON
> module just adding supporting for types that provide an __index__
> method. So rather than needing a new protocol, an existing one might
> be perfectly adequate.
On Tue, 27 Aug 2019 11:20:58 +0200
Richard Musil wrote:
>
> To resolve the bpo issue with numpy, one would need to implement complete
> custom serialization (1) or simply convert numpy number types into Python
> number types.
Yes, both are possible and both could even be implemented. For Numpy
On Sun, 11 Aug 2019 20:09:41 -0400
David Shawley
wrote:
> On Aug 8, 2019, at 3:55 PM, Chris Angelico wrote:
>
> >
> > There are two broad suggestions that came out of that thread and
> > others, and I think it may be worth reopening them.
> >
> > 1) Should JSONEncoder (the class underlying
On Wed, 14 Aug 2019 04:21:05 +1000
Chris Angelico wrote:
>
> That's one of the reasons that a simple solution of "make JSONEncoder
> respect decimal.Decimal" was rejected - it would require that the json
> module import decimal, which is extremely costly. Having a __json__
> protocol would be
On Thu, 16 May 2019 18:05:39 +0300
Serhiy Storchaka
wrote:
> 16.05.19 17:05, Antoine Pitrou пише:
> > On Thu, 16 May 2019 16:04:36 +0300
> > Serhiy Storchaka
> > wrote:
> >> 16.05.19 14:33, Antoine Pitrou пише:
> >>> On Thu, 16 May 2019 13:05:48
On Thu, 16 May 2019 16:04:36 +0300
Serhiy Storchaka
wrote:
> 16.05.19 14:33, Antoine Pitrou пише:
> > On Thu, 16 May 2019 13:05:48 +0300
> > Serhiy Storchaka
> > wrote:
> >> 16.05.19 11:28, Barry Scott пише:
> >>> To replace one symlink wi
On Thu, 16 May 2019 13:05:48 +0300
Serhiy Storchaka
wrote:
> 16.05.19 11:28, Barry Scott пише:
> > To replace one symlink with another atomically is possible by using
> > rename() or renameat()
> > something like:
> >
> > os.symlink( src, tmp_symlink )
> > os.rename( tmp_symlink, dst )
On Mon, 6 May 2019 19:39:39 +0300
Serge Matveenko wrote:
> On Mon, May 6, 2019 at 7:29 PM Guido van Rossum wrote:
> >
> > On Mon, May 6, 2019 at 11:14 AM Serhiy Storchaka
> > wrote:
> >> I do not propose to change the current behavior. I propose to add new
> >> named constructors. In most
Hello,
I apologize because I'm only going to throw a very vague idea and I
don't currently have time or motivation to explore it myself. But I
think it may prove interesting for other people and perhaps spur some
concrete actionable proposal.
With the growing complexity of Python software
On Mon, 1 Apr 2019 10:41:40 -0400
Dan Sommers
<2qdxy4rzwzuui...@potatochowder.com>
wrote:
> On 4/1/19 10:27 AM, Antoine Pietri wrote:
>
> > - The / operator returns floats, which loses information when both of
> > the operands are integer. In Python 4, “1 / 2” should return a
> > decimal.Decimal.
On Tue, 26 Mar 2019 09:27:18 -
"Richard Whitehead"
wrote:
> Problem:
>
> Using Python's Condition class is error-prone and difficult. For example,
> the following pseudo-code would be quite typical of its use:
[...]
Nowadays, I would recommend to always use `Condition.wait_for()` rather
Hello,
On Thu, 21 Mar 2019 15:31:30 -0400
Hardik Patel
wrote:
> Hello,
> Can you please help me to contact a core team if it is possible.
> I would like to report an issue.
Issues can be reported at https://bugs.python.org/
Regards
Antoine.
___
On Thu, 21 Mar 2019 17:59:41 +
Rhodri James wrote:
>
> >> And to those who support this PEP, code examples where a dict merge
> >> operator will help are most welcome!
>
> I don't use Python often enough to have much to offer, I'm afraid. The
> sort of occasion I would use dict merging
On Fri, 22 Mar 2019 03:42:00 +1100
Steven D'Aprano wrote:
>
> For those who oppose the + operator, it will help me if you made it
> clear whether it is *just* the + symbol you dislike, and would accept
> the | operator instead, or whether you hate the whole operator concept
> regardless of
On Tue, 5 Mar 2019 16:39:40 +0900
INADA Naoki
wrote:
> I think some people in favor of PEP 584 just want
> single expression for merging dicts without in-place update.
>
> But I feel it's abuse of operator overload. I think functions
> and methods are better than operator unless the operator
>
On Thu, 21 Mar 2019 23:51:12 +1100
Chris Angelico wrote:
> On Thu, Mar 21, 2019 at 11:45 PM Antoine Pitrou wrote:
> >
> > On Thu, 21 Mar 2019 23:35:36 +1100
> > Chris Angelico wrote:
> > > On Thu, Mar 21, 2019 at 10:35 PM Antoine Pitrou
> > > wrote:
On Thu, 21 Mar 2019 23:35:36 +1100
Chris Angelico wrote:
> On Thu, Mar 21, 2019 at 10:35 PM Antoine Pitrou wrote:
> > > but it's NOT a new operator, it is making use of an existing one, and sure
> > > you could guess at a couple meanings, but the merge one is probably
On Wed, 20 Mar 2019 15:46:24 -1000
Christopher Barker
wrote:
>
> > This is precisely why I worded my question this way: what has changed
> > in the last 20 years that make a "+" dict operator more compelling
> > today than it was? Do we merge dicts much more frequently than we
> > did?
>
>
On Tue, 19 Mar 2019 10:49:41 +1300
Greg Ewing wrote:
> Rémi Lapeyre wrote:
>
> > You can make "inferences from the way things are used". But the
> > comparison with maths stops here, you don’t make such inferences because
> > your
> > object must be well defined before you start using it.
>
Seems reasonable to me.
Regards
Antoine.
On Mon, 18 Mar 2019 16:41:34 +0100
"Giampaolo Rodola'"
wrote:
> Hello,
> I've been having these 2 implemented in psutil for a long time. On
> POSIX these are convenience functions using os.kill() + SIGSTOP /
> SIGCONT (the same as CTRL+Z / "fg"). On
1 - 100 of 262 matches
Mail list logo
