Eli Bendersky wrote (in
http://mail.python.org/pipermail/python-dev/2012-February/116393.html ):
> A package will be marked provisional by including the
> following paragraph as a note at the top of its
> documentation page:
I really would like some marker available from within Python
itself.
PEP author Victor asked
(in http://mail.python.org/pipermail/python-dev/2012-February/116499.html):
> Maybe I missed the answer, but how do you handle timestamp with an
> unspecified starting point like os.times() or time.clock()? Should we
> leave these function unchanged?
If *all* you know is
PEP author Mark Shannon wrote
(in
http://mail.python.org/pipermail/python-dev/attachments/20120208/05be469a/attachment.txt):
> ... allows ... (the ``__dict__`` attribute of an object) to share
> keys with other attribute dictionaries of instances of the same class.
Is "the same class" a delibe
In http://mail.python.org/pipermail/python-dev/2012-February/116073.html
Nick Coghlan wrote:
> Besides, float128 is a bad example - such a type could just be
> returned directly where we return float64 now. (The only reason we
> can't do that with Decimal is because we deliberately don't allow
>
In http://mail.python.org/pipermail/python-dev/2012-January/116003.html
>> > Benjamin Peterson wrote:
>> >> 2. It will be off by default in stable releases ... This will
>> >> prevent code breakage ...
>> 2012/1/27 Steven D'Aprano :
>> > ... it will become on by default in some future release?
In http://mail.python.org/pipermail/python-dev/2012-January/115715.html
Frank Sievertsen wrote:
Am 20.01.2012 13:08, schrieb Victor Stinner:
>>> I'm surprised we haven't seen bug reports about it from users
>>> of 64-bit Pythons long ago
>> A Python dictionary only uses the lower bits of a hash
Summary: There needs to be a simple way to opt out at install time.
It would be far better to offer more fine-grained control, but leaving
that better solution to downstream is acceptable.
On 3 September 2014 01:19, Antoine Pitrou wrote:
> RFC 2818 (HTTP over TLS) has the following language
On Mon, Sep 8, 2014 at 3:44 PM, Cory Benfield wrote:
> On 8 September 2014 18:23, Jim J. Jewett wrote:
>> Summary: There needs to be a simple way to opt out at install time.
>> It would be far better to offer more fine-grained control, but leaving
>> that better solu
On Tue, Sep 9, 2014 at 12:11 PM, Christian Heimes wrote:
> On 09.09.2014 05:03, Nick Coghlan wrote:
>>
>> On 9 Sep 2014 10:48, "Jim J. Jewett" > <mailto:jimjjew...@gmail.com>> wrote:
>> From Guido's and your feedback, I think we may need two things
On September 11, 2014, Jeff Allen wrote:
> ... the area of code point
> space used for the smuggling of bytes under PEP-383 is not a
> "Unicode Private Use Area", but a portion of the trailing surrogate
> range. This is a code violation, which I imagine is why
> "surrogateescape" is an error
On Sat Sep 13 00:16:30 CEST 2014, Jeff Allen wrote:
> 1. Java does not really have a Unicode type, therefore not one that
> validates. It has a String type that is a sequence of UTF-16 code units.
> There are some String methods and Character methods that deal with code
> points represented
I have a strong suspicion that I'm missing something; I have been
persuaded both directions too often to believe I have a grip on the
real issue.
So I'm putting out some assumptions; please tell me if I'm wrong, and
maybe make them more explicit in the PEP.
(1) The change will only affect situat
M. Cepl asked:
> What I really don't understand is why this discussion is hg v.
> GitHub, when it should be hg v. git. Particular hosting is
> a secondary issue
I think even the proponents concede that git isn't better enough
to justify a switch in repositories.
They do claim that GitHub (
Brett Cannon wrote:
> 4. Contributor creates account on bugs.python.org and signs the
> [contributor agreement](https://www.python.org/psf/contrib/contrib-form/)
Is there an expiration on such forms? If there doesn't need to be
(and one form is good for multiple tickets), is there an objectio
On Thu, Dec 18, 2014, at 14:13, Maciej Fijalkowski wrote:
> ... http://bugs.python.org/issue23085 ...
> is there any reason any more for libffi being included in CPython?
[And why a fork, instead of just treating it as an external dependency]
Benjamin Peterson responded:
> It has some sort of
On Thu, Dec 18, 2014, at 14:13, Maciej Fijalkowski wrote:
> ... http://bugs.python.org/issue23085 ...
> is there any reason any more for libffi being included in CPython?
Paul Moore wrote:
> Probably the easiest way of moving this forward would be for someone
> to identify the CPython-specific
Barry Warsaw wrote:
>> I don't know exactly what the procedure would be to claim .pyz for *nix,
>> e.g. updating /etc/mime.types, but I think the PEP should at least mention
>> this. I think we want to get as official support for .pyz files on *nix as
>> possible.
Paul Moore wrote:
> I'll add a
On Wed, Feb 18, 2015 at 4:16 PM, Paul Moore wrote:
> On 18 February 2015 at 20:48, Jim J. Jewett wrote:
>> Barry Warsaw wrote:
>>>> I don't know exactly what the procedure would be to claim .pyz for *nix,
>>>> e.g. updating /etc/mime.types,
...
&g
On 24 February 2015 at 18:58, Guido van Rossum wrote:
> The naming of the functions feels inconsistent -- maybe pack(directory,
> target) -> create_archive(directory, archive), and set_interpreter() ->
> copy_archive(archive, new_archive)?
Paul Moore wrote:
> One possible source of confusion w
On Wed, Feb 25, 2015 at 2:33 PM, Paul Moore wrote:
> On 25 February 2015 at 17:06, Paul Moore wrote:
> I've included the resulting API
> documentation below. It looks pretty good to me.
Me too. I have a few nits anyhow.
> .. function:: create_archive(directory, target=None, interpreter=None,
On 10 March 2015 at slightly after midnight. Paul Moore wrote:
> Personally I doubt it would make much difference. If the docs say
> "pygmentize" I'm unlikely to dig around to find that the incantation
> "python -m pygments.somemodule:main" does the same thing using 3 times
> as many characters
On 16 March 2015 Petr Viktorin wrote:
> If PyModuleCreate is not defined, PyModuleExec is expected to operate
> on any Python object for which attributes can be added by PyObject_GetAttr*
> and retrieved by PyObject_SetAttr*.
I assume it is the other way around (add with Set and retrieve with Ge
On Tue Apr 28 23:49:56 CEST 2015, Guido van Rossum quoted PEP 492:
> Rationale and Goals
> ===
>
> Current Python supports implementing coroutines via generators (PEP
> 342), further enhanced by the ``yield from`` syntax introduced in PEP
> 380. This approach has a number of short
On Wed, Apr 29, 2015 at 2:26 PM, Paul Moore wrote:
> On 29 April 2015 at 18:43, Jim J. Jewett wrote:
>> So? PEP 492 never says what coroutines *are* in a way that explains
>> why it matters that they are different from generators.
...
> Looking at the Wikipedia article on
On Wed Apr 29 20:06:23 CEST 2015,Yury Selivanov replied:
>> As best I can guess, the difference seems to be that a "normal"
>> generator is using yield primarily to say:
>> "I'm not done; I have more values when you want them",
>> but an asynchronous (PEP492) coroutine is primarily saying:
On Thu, Apr 30, 2015 at 3:32 PM, Guido van Rossum wrote:
(me:)
>> A badly worded attempt to say
>> Normal generator: yield (as opposed to return) means
>> that the function isn't done, and there may be more
>> things to return later.
>> but an asynchronous (PEP492) coroutine is primarily saying
On Fri, May 1, 2015 at 2:59 PM, Guido van Rossum wrote:
> On Fri, May 1, 2015 at 11:26 AM, Jim J. Jewett wrote:
>>
>> On Thu, Apr 30, 2015 at 3:32 PM, Guido van Rossum
>> wrote:
>>
>> (Guido:)> Actually that's not even wrong. When using generators as
On Fri, May 1, 2015 at 4:10 PM, Guido van Rossum wrote:
> On Fri, May 1, 2015 at 12:48 PM, Jim J. Jewett wrote:
>>
>> If there are more tasks than executors, yield is a way to release your
>> current executor and go to the back of the line. I'm pretty sure I
>&
On Thu Apr 30 21:27:09 CEST 2015, Yury Selivanov replied:
On 2015-04-30 2:41 PM, Jim J. Jewett wrote:
>> Bad phrasing on my part. Is there anything that prevents an
>> asynchronous call (or waiting for one) without the "async with"?
>> If so, I'm missing so
On Sun May 3 08:32:02 CEST 2015, Stefan Behnel wrote:
> Ok, fair enough. So, how would you use this new protocol manually then?
> Say, I already know that I won't need to await the next item that the
> iterator will return. For normal iterators, I could just call next() on it
> and continue the f
On Fri May 1 23:58:26 CEST 2015, Yury Selivanov wrote:
>>> Yes, you can't use 'yield from' in __exit__/__enter__
>>> in current Python.
>> What do you mean by "can't use"?
> It probably executed without errors, but it didn't run the
> generators.
True. But it did return the one created by __
On Tue May 5 18:29:44 CEST 2015, Yury Selivanov posted an updated PEP492.
Where are the following over-simplifications wrong?
(1) The PEP is intended for use (almost exclusively) with
asychronous IO and a scheduler such as the asynchio event loop.
(2) The new syntax is intended to make it eas
On Tue May 5 21:44:26 CEST 2015,Brett Cannon wrote:
> It's not as
> complicated as it seems when you realize there is an event loop driving
> everything (which people have been leaving out of the conversation since it
> doesn't tie into the syntax directly).
Another reason people don't realize i
Tue May 5 21:48:36 CEST 2015, Yury Selivanov wrote:
> As for terminology, I view this discussion differently. It's
> not about the technical details (Python has asymmetric
> coroutines, that's it), but rather on how to disambiguate
> coroutines implemented with generators and yield-from, from
>
Mark Shannon wrote:
> PY2, etc. really need to go.
> Assuming that this code type checks OK:
>
> if typing.PY2:
> type_safe_under_py2_only()
> else:
> type_safe_under_py3_only()
>
> Is the checker supposed to pass this:
>
> if sys.hexversion < 0x0300:
> type_safe_under_py2_
At Thu May 21 22:27:50 CEST 2015, Guido wrote:
> I want to encourage users to think about annotations as types,
> and for most users the distinction between type and class is
> too subtle,
So what is the distinction that you are trying to make?
That a type refers to a variable (name), and a cl
On Sun May 24 12:06:40 CEST 2015, Nick Coghlan wrote:
> On 24 May 2015 at 19:44, Mark Shannon wrote:
>> On 24/05/15 10:35, Nick Coghlan wrote:
>>> If we leave __definition_order__ out for the time being then, for the
>>> vast majority of code, the fact that the ephemeral namespace used to
>>> ev
On Thu Jun 18 20:33:13 CEST 2015, Larry Hastings asked:
> On 06/18/2015 11:27 AM, Terry Reedy wrote:
>> Unicode 8.0 was just released. Can we have unicodedata updated to
>> match in 3.5?
> What does this entail? Data changes, code changes, both?
Note that the unicode 7 changes also need to
On Fri Jun 26 16:51:13 CEST 2015, Paul Sokolovsky wrote:
> So, currently in Python you know if you do:
>socket.write(buf)
> Then you know it will finish without interruptions for entire buffer.
How do you know that?
Are you assuming that socket.write is a builtin, rather than a
python me
PEP 498 is only the latest PEP where part of the concern is fear that
it may encourage certain types of bad code.
Would it be reasonable to ask PEPs to start including a section on any
recommended changes to PEP8? (e.g., "If an embedded expression
doesn't fit on a single line, factor it out to a
(1) Please make it clear within the abstract what counts as a change.
(1a) E.g., a second paragraph such as "Adding or removing a key, or
replacing a value, counts as a change. Modifying an object in place,
or replacing it with itself may not be picked up."
(1b) Is there a way to force a vers
> On Jan 17, 2016, at 11:10, Brett Cannon wrote:
>> While doing a review of http://bugs.python.org/review/26129/
>> ... update PEP 7 to remove the optionality of curly braces
On Mon Jan 18 03:39:42 EST 2016, Andrew Barnert pointed out:
> There are two ways you could do that.
[The one most p
On Sun Mar 20 16:26:03 EDT 2016, Nikolaus Rath wrote:
> Which I believe makes it completely pointless to cite Python at all. As
> far as I can see, nowadays citations are given for two reasons:
> 1. To give the reader a starting point to get more information on a
>topic.
I don't often see
(1) I think the "built-in" should instead be a module-level function
in the pathlib. If you aren't already expecting pathlib paths, then
you're just expecting strings to work anyhow, and a builtin isn't
likely to be helpful.
(2) I prefer that the function be explicit about the fact that it is
d
On Thu Apr 14 11:19:42 EDT 2016, Victor Stinner posted the latest
draft of PEP 509; dict version_tag
(1) Meta Question: If this is really only for CPython, then is
"Standards Track" the right classification?
(2) Why *promise* not to update the version_tag when replacing a
value with itself?
On Fri, Apr 15, 2016 at 4:41 PM, Victor Stinner
wrote:
> 2016-04-15 19:54 GMT+02:00 Jim J. Jewett :
>> (2) Why *promise* not to update the version_tag when replacing a
>> value with itself?
> It's an useful property. For example, let's say that you have a guard
On Fri, Apr 15, 2016 at 7:31 PM, Victor Stinner
wrote:
> .2016-04-15 23:45 GMT+02:00 Jim J. Jewett :
...
>> I just worry that you may end up closing off even better optimizations
>> later, if you make too many promises about exactly how you will do
>> which ones.
>> T
On Sat, Apr 16, 2016 at 5:01 PM, Victor Stinner
wrote:
> * I mentionned that version++ must be atomic, and that in the case of
> CPython, it's done by the GIL
Better; if those methods *already* hold the GIL, it is worth saying
"already", to indicate that the change is not expensive.
> * I remove
On Mon, Oct 10, 2016, at 14:04, MRAB wrote:
> Instead of locking the object, could we keep the GIL, but have it
> normally released?
> A thread could then still call a function such as PyWeakref_GetObject()
> that returns a borrowed reference, but only if it's holding the GIL. It
> would be able
(Fri Nov 15 16:57:00 CET 2013) Stephen J. Turnbull wrote:
> Serhiy Storchaka wrote:
> > If the transform() method will be added, I prefer to have only
> > one transformation method and specify a direction by the
> > transformation name ("bzip2"/"unbzip2").
Me too. Until I consider specia
> Steven D'Aprano wrote:
>> I think that heuristics to guess the encoding have their role to play,
>> if the caller understands the risks.
Ben Finney wrote:
> In my opinion, content-type guessing heuristics certainly don't belong
> in the standard library.
It would be great if there were never
As best I can tell, some people (apparently including Guido
and PEP author Antoine) are taking some assumptions almost
for granted, while other people (including me, before Nick's
messages) were not assuming them at all.
Since these assumptions (or, possibly, rejections of them?)
are likely to d
>> So when it is time to guess [at the character encoding of a file],
>> a source of good guesses is an important battery to include.
> The barrier for entry to the standard library is higher than mere
> usefulness.
Agreed. But "most programs will need it, and people will either
include (the s
Nick Coghlan wrote:
>> Arbitrary binary data and ASCII compatible binary data are *different
>> things* and the only argument in favour of modelling them with a single
>> type is because Python 2 did it that way.
Greg Ewing replied:
> I would say that ASCII compatible binary data is a
> *sub
Greg Ewing replied:
>> ... ASCII compatible binary data is a
>> *subset* of arbitrary binary data.
I wrote:
> But in terms of explaining the text model, that
> separation is important enough that
>(2) It *may* be worth creating a virtual
> split in the documentation.
(rough ske
Victor Stinner wrote:
>> Will ascii() ever emit an antislash representation?
> Try ascii(chr(0x1f)).
In which version? I get:
ValueError: chr() arg not in range(0x11)
> How do you plan to use this output? Write it into a socket or a file?
> When I debug, I use print & logging w
Yury Selivanov wrote:
> I think the Motivation section is pretty weak.
I have normally wished for this when I was (semi-
interactively) exploring a weakly structured dataset.
Often, I start with a string, split it into something
hopefully like records, and then start applying filters
and tran
Greg Ewing suggested:
>> This version might be more readable:
>>
>> value = lst[2] except "No value" if IndexError
Ethan Furman asked:
> It does read nicely, and is fine for the single, non-nested, case
> (which is probably the vast majority), but how would
> it handle nested exceptions?
The PEP currently says:
> Alternative Proposals
> =
> Discussion on python-ideas brought up the following syntax suggestions::
>value = expr except default if Exception [as e]
This one was rejected because of the out-of-order evaluation.
Note, however, that the (fart
(Thu Mar 6 23:26:47 CET 2014) Chris Angelico responded:
> On Fri, Mar 7, 2014 at 7:29 AM, Jim J. Jewett wrote:
>> [ note that "x if y" already occurs in multiple contexts, and
>> always evaluates y before x. ]
> Yes, but that's still out of order.
Ye
On Wed Mar 5 17:37:12 CET 2014, Victor Stinner wrote:
> Python 3 now stores the traceback object in Exception.__traceback__
> and exceptions can be chained through Exception.__context__. It's
> convenient but it introduced tricky reference cycles if the exception
> object is used out of the ex
On Thu Mar 6 16:52:56 CET 2014, Antoine Pitrou wrote:
> IMO it is absolutely out of question to allow creation of arbitrary
> frames from Python code, because the structure and initialization of
> frames embody too many low-level implementation details.
So?
Does any of that matter until the
n inside a longer line.
(3a) Does the except expression need to be general, or would it work
if it were limited to a subclause of variable assignments?
(3b) What about comprehensions?
On Fri Mar 7 20:54:31 CET 2014, Chris Angelico wrote:
>On Sat, Mar 8, 2014 at 5:58 AM, Jim J. Jewett w
On Fri Mar 7 20:54:31 CET 2014, Chris Angelico wrote:
> On Sat, Mar 8, 2014 at 5:58 AM, Jim J. Jewett wrote:
>> (Thu Mar 6 23:26:47 CET 2014) Chris Angelico responded:
>>> ...[as-capturing is] deferred until there's a non-closure means of
>>> creating a sub-sco
On Mon Mar 10 18:56:17 CET 2014 (and earlier quotes), Maciej Fijalkowski wrote:
Maciej:>> You should not rely on __del__s being called timely one way or
Maciej:>> another. Why would you require this for the program to work
Maciej:>> correctly in the particular example of __traceback__?
To the e
(1) I believe the recent consensus was that the number of comparisons
made in a dict lookup is an implementation detail. (Please correct me
if I am wrong.)
(2) Is "the item will be hashed at least once" a language guarantee?
For small mappings, it might well be more efficient to just store the
(1) Should fixes to a docstring go in with a patch, even if they
aren't related to the changing functionality?
Bytestring compilation has several orthogonal parameters. Most -- but
not all -- are documented in the docstring. (Specifically, there is
no explanation of the rx parameter which acts
On Mon, Apr 28, 2014 at 12:56 PM, Charles-François Natali
wrote:
> Why would the user care if multiprocessing is used behind the scene?
Err ... that was another set of questions that I forgot to ask.
(A) Why bother raising an error if multiprocessing is unavailable?
After all, there is a perfec
Steven D'Aprano wrote:
> (1) I asked if it would be okay for MicroPython to *optionally* use
> nominally Unicode strings limited to ASCII. Pretty much the only
> response to this as been Guido saying "That would be a pretty lousy
> option", and since nobody has really defended the suggestion,
On 6/24/2014 4:22 AM, Serhiy Storchaka wrote:
> I submitted a number of patches which fixes currently broken
> Unicode-disabled build of Python 2.7 (built with --disable-unicode
> configure option). I suppose this was broken in 2.7 when C
> implementation of the io module was introduced.
It has
Sat Aug 2 12:11:54 CEST 2014, Julian Taylor wrote (in
https://mail.python.org/pipermail/python-dev/2014-August/135623.html ) wrote:
> Andrea Griffini wrote:
>>However sum([[1,2,3],[4],[],[5,6]], []) concatenates the lists.
> hm could this be a pure python case that would profit from
(On June 19, 2013) Barry Warsaw wrote about porting mailman from
flufl.enum to the stdlib.enum:
> Switching from call syntax to getitem syntax for looking up an
> enum member by name, e.g.
>-delivery_mode = DeliveryMode(data['delivery_mode'])
>+delivery_mode = Delivery
(Tue Oct 29 12:37:52 CET 2013) Victor Stinner wrote:
> For consistency, you cannot keep traces when tracing is disabled.
> The free() must be enabled to remove allocated memory blocks, or
> next malloc() may get the same address which would raise an assertion
> error (you cannot have two memory
I agree that startup time is a problem, but I wonder if some of the pain
could be mitigated by using a persistent process.
For example, in
https://mail.python.org/pipermail/python-dev/2017-July/148664.html Ben Hoyt
mentions that the Google Cloud SDK (CLI) team has found it "especially
problematic
Building on Brett's suggestion:
FrameContext: used in/writable by one frame
ContextStack: a FrameContext and its various fallbacks
-jJ
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscr
In https://mail.python.org/pipermail/python-dev/2017-August/148869.html
Nick Coghlan wrote:
> * what we want to capture at generator creation time is
> the context where writes will happen, and we also
> want that to be the innermost context used for lookups
So when creating a generator, we w
On Thu, Aug 24, 2017 at 1:12 AM, Yury Selivanov > On Thu, Aug 24, 2017
at 12:32 AM, Jim J. Jewett wrote:
> The key requirement for using immutable datastructures is to make
> "get_execution_context" operation fast.
Do you really need the whole execution context, or do you ju
Should PEP 550 discuss other implementations? E.g., the object space used
in pypy?
-jJ
___
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
On Aug 24, 2017 11:02 AM, "Yury Selivanov" wrote:
On Thu, Aug 24, 2017 at 10:05 AM, Jim J. Jewett
wrote:
> On Thu, Aug 24, 2017 at 1:12 AM, Yury Selivanov > On Thu, Aug 24, 2017
> at 12:32 AM, Jim J. Jewett wrote:
If you look at this small example:
foo = new_context_k
I think there is general consensus that this should go in a module other
than sys. (At least a submodule.)
The specific names are still To Be Determined, but I suspect seeing the
functions and objects as part of a named module will affect what works.
So I am requesting that the next iteration jus
Does setting an ImplicitScopeVar to None set the value to None, or just
remove it?
If it removes it, does that effectively unmask a previously masked value?
If it really sets to None, then is there a way to explicitly unmask
previously masked values?
Perhaps the initial constructor should requir
(1) I found the following (particularly "bases classes") very confusing:
"""
If an object that is not a class object appears in the bases of a class
definition, then ``__mro_entries__`` is searched on it. If found,
it is called with the original tuple of bases as an argument. The result
of the c
I understand auto-generating the __hash__ (and __eq__) for a frozen
container; that is just convenient.
But why is there any desire to autogenerate a __hash__ for something
that isn't frozen? Like a list or dict, the normal case would be for
it not to have a hash at all, and the author *should* w
On Mon, Feb 19, 2018 at 5:06 PM, Chris Barker - NOAA Federal <
chris.barker at noaa.gov> wrote:
> If I have this right, on the discussion about frozen and hash, a use
> case was brought up for taking a few steps to create an instance (and
> thus wanting it not frozen) and then wanting it hashable.
I think part of the disconnect is that this enhancement could very
easily be abused, and it seems likely that it will be, because the
problems aren't visible while writing the code -- only when reading it
later.
I therefore suggest making it very clear in the PEP -- and probably in
PEP 8 -- how t
FWIW, the web archive
https://mail.python.org/archives/list/python-dev@python.org/thread/ZX2JLOZDOXWVBQLKE4UCVTU5JABPQSLB/
does not seem to display the problems ... apparently the individual messages
are not included in view source, and are cleaned up for chrome's inspect. I'm
not sure whether
Is it possible for the installer to check whether or not there is a
pre-existing system-wide launcher, and only do the complicated stuff
if it is actually there?
-jJ
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to pyt
On Wed, Sep 11, 2019 at 5:36 AM Steve Dower wrote:
> But you mention "only do ... stuff if ... there" - what stuff are you
> referring to? The installer should do *less* if it's partially installed
> already, not more.
My understanding was that
(1) You believe the py.exe launcher should be instal
I wouldn't worry too much about the the Singletons in this issue; they could be
solved in any of several ways, all of which would be improvements conceptually
-- if performance and backwards compatibility were resolved.
In theory, the incr/decr pair should be delegated to the memory store, with
There is value in saying "These are things that might be limited by the
implementation."
There is great value in documenting the limits that CPython in particular
currently chooses to enforce. Users may want to see the numbers, and other
implementations may wish to match or exceed these minimu
David Mertz wrote:
> On Wed, Dec 11, 2019, 6:40 AM Mark Shannon m...@hotpy.org
> wrote:
> > I NEVER care about memory at all... except inasmuch as it effects speed.
In my admittedly idiosyncratic experience, memory is usually by far my most
constrained resource. I do care about it, even if pyth
Victor Stinner wrote:
> I started to modify Python internals to pass explicitly the Python
> thread state ("tstate") to internal C a functions:
Is work this summarized somewhere like a PEP?
> https://vstinner.github.io/cpython-pass-tstate.html
describes the motivation, but not the details on why
Why do sub-interpreters require (separate and) heap-allocated types?
It seems types that are statically allocated are a pretty good use for immortal
objects, where you never change the refcount ... and then I don't see why you
need more than one copy.
__
Ronald Oussoren wrote:
> > On 28 Apr 2020, at 20:38, Jim J. Jewett jimjjew...@gmail.com wrote:
> > Why do sub-interpreters require (separate and) heap-allocated types?
> > It seems types that are statically allocated are a pretty good use for
> > immortal
> > objec
Even then, disconnect seems like the primary use case, with a
channel.kill_for_all being a specialized subclass. One argument for leaving it
to a subclass is that it isn't clear what other interpreters should do when
that happens. Shut down? Start getting exceptions if they happen to use it
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 than 'strict'. but 'strict' is also wrong.
Zipping to a potentiall
I don't think that sharing data only by copying is the final plan. Proxied
objects seem like a fairly obvious extension.
I am also a bit suspicious of that great timing; perhaps latency is also
important for startup?
___
Python-Dev mailing list -- pyt
In fairness, if the process is really exiting, the OS should clear that out.
Even if it is embedded, the embedding process could just release (or zero out)
the entire memory allocation. I personally like plugging those leaks, but it
does feel like putting purity over practicality.
Even without platform differences, limits on the value of parameters really
ought to be in the docstring, which is available to inspect. If you're asking
for a more specific convention that could actually be used, that still probably
still needs to be written.
__
There are the usual concurrency problems of "read a value, change it, store it
back without checking whether it already changed". The only thing special
about lifecycle happens at refcount 0, which should not happen when more than
one interpreter has a reference.
Similarly, C code can mess thi
1 - 100 of 227 matches
Mail list logo
