I certainly understand saying "this change isn't important enough to justify a
change."
But it sounds as though you are saying the benefit is irrelevant; it is just
inherently too expensive to ask programs that are already dealing with
internals and trying to optimize performance to make a mec
ah... we may have been talking past each other.
Steve Dower wrote:
> On 25Jul2020 2014, Jim J. Jewett wrote:
> > But it sounds as though you are saying the benefit
[of storing the line numbers in an external table, I thought,
but perhaps Pablo Galindo Salgado and yourself were
talkin
Oscar Benjamin's study of sympy is part of what prompted this, and does provide
a concrete example of why constructors should be echoed.
I think in general, the matching has fallen into two categories:
(1) Simple literal-like matching, that mostly works OK. There is still some
concern over wh
Raihan Rasheed Apurbo wrote:
> In CPython we have reference counting. My question is can we optimize current
> RC using
> strategies like Deferred RC and Coalescing?
You might also look at some of the older attempts to remove reference counting
entirely in favor of (usually) the Boehm tracing co
Emily Bowman wrote:
> If you can update to a breaking Python version, but aren't allowed one
> single point version of an external module, you have a process problem.
Agreed. Does it surprise you to know that many large organizations have a
process problem?
__
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
In http://mail.python.org/pipermail/python-dev/2012-February/116953.html
Terry J. Reedy wrote:
> I presume that most 2.6 code has problems other than u'' when
> attempting to run under 3.x.
Why?
If you're talking about generic code that has seen minimal changes
since 2.0, sure. But I think th
In http://mail.python.org/pipermail/python-dev/2012-February/116955.html
Victor Stinner proposed:
> The blacklist implementation has a major issue: it is still possible
> to call write methods of the dict class (e.g. dict.set(my_frozendict,
> key, value)).
It is also possible to use ctypes and
In http://mail.python.org/pipermail/python-dev/2012-February/117070.html
Vinay Sajip wrote:
> It's moot, but as I see it: the purpose of PEP 414 is to facilitate a
> single codebase across 2.x and 3.x. However, it only does this if your
> 3.x interest is 3.3+
For many people -- particularly tho
In http://mail.python.org/pipermail/python-dev/2012-February/117113.html
Victor Stinner posted:
> An immutable mapping can be implemented using frozendict::
> class immutabledict(frozendict):
> def __new__(cls, *args, **kw):
> # ensure that all values are immutable
>
In http://mail.python.org/pipermail/python-dev/2012-March/117348.html
Georg Brandl posted:
> Python 3.3 includes a range of improvements of the 3.x series, as well as
> easier
> porting between 2.x and 3.x. Major new features in the 3.3 release series
> are:
As much as it is nice to just c
http://mail.python.org/pipermail/python-dev/2012-March/117396.html
Stefan Behnel posted:
> I found a problem in the current "yield from" implementation ...
[paraphrasing]
g1 yields from g2
g2 yields from g1
XXX python follows the existing delegation without checking re-entrancy
http://mail.python.org/pipermail/python-dev/2012-March/117395.html
Brett Cannon posted:
[in reply to Mark Shannon's suggestion of adding a builtins parameter
to match locals and globals]
> It's a mess right now to try to grab the __import__()
> implementation and this would actually help clarif
In
view-source:http://mail.python.org/pipermail/python-dev/2012-March/117586.html
van.lindberg at gmail.com posted:
>>> 1) The layout for the python root directory for all platforms should be
>>> as follows:
>>> stdlib = {base/userbase}/lib/python{py_version_short}
>>> platstdlib = {base/user
In http://mail.python.org/pipermail/python-dev/2012-March/117617.html
van.lindberg at gmail.com posted:
> As noted earlier in the thread, I also change my proposal to maintain
> the existing differences between system installs and user installs.
[Wanted lower case, which should be irrelevant;
In http://mail.python.org/pipermail/python-dev/2012-March/117570.html
Steven D'Aprano posted:
> "Need" is awfully strong. I don't believe it is the responsibility
> of the standard library to be judge and reviewer of third party
> packages that it doesn't control.
It is, however, user-friendly
In http://mail.python.org/pipermail/python-dev/2012-March/117762.html
Georg Brandl posted:
>> + If available, a monotonic clock is used. By default, if *strict* is
>> False,
>> + the function falls back to another clock if the monotonic clock failed
>> or is
>> + not available. If *stric
In http://mail.python.org/pipermail/python-dev/2012-March/117953.html
VanL wrote:
> Paul Moore wrote:
>> First of all, this difference is almost entirely *invisible*. Apart
>> from possibly setting PATH (once!) users should not be digging around
>> in the Python installation directory. Certainl
In http://mail.python.org/pipermail/python-dev/2012-March/118024.html
Steven D'Aprano wrote:
> What makes this "steady", given that it can be adjusted
> and it can go backwards?
It is best-effort for steady, but putting "best" in the name would
be an attractive nuisance.
> Is steady() merely a
In http://mail.python.org/pipermail/python-dev/2012-April/119134.html
Benjamin Peterson wrote:
> I see PEP 418 gives time.clock_info() two boolean fields named
> "is_monotonic" and "is_adjusted". I think the "is_" is unnecessary and
> a bit ugly, and they could just be renamed "monotonic" and "a
Summary:
*Every* Parameter attribute is optional, even name. (Think of
builtins, even if they aren't automatically supported yet.)
So go ahead and define some others that are sometimes useful.
Instead of defining a BoundArguments class, just return a copy
of the Signature, w
Vinay Sajip reworded the 'Provides-Dist' definition to explicitly say:
> The use of multiple names in this field *must not* be used for
> bundling distributions together. It is intended for use when
> projects are forked and merged over time ...
(1) Then how *should* the "bundle-of-several-co
201 - 227 of 227 matches
Mail list logo
