On Fri, Sep 14, 2018 at 6:08 PM Larry Hastings wrote:
> I can suggest that, based on conversation from Carl, that adding the stat
> calls back in costs you half the startup. So any mechanism where we're
> talking to the disk _at all_ simply isn't going to be as fast.
Is that cost for when the
ing attempts to prevent exploitation
of known vulnerabilities because the software in question is currently too
slow.
For a 4-8% performance penalty, we could just add the CFLAGS to the build
now and not worry about it.
I give up.
On Friday, September 21, 2018, Franklin? Lee
wrote:
> On Thu, Se
On Thu, Sep 20, 2018 at 2:10 PM Wes Turner wrote:
>
> On Thursday, September 20, 2018, Stefan Ring wrote:
>>
>> On Tue, Sep 18, 2018 at 8:38 AM INADA Naoki wrote:
>>
>> > I think this topic should split to two topics: (1) Guard Python
>> > process from Spectre/Meltdown
>> > attack from other pro
On Tue, Sep 18, 2018 at 2:40 AM INADA Naoki wrote:
>
> On Tue, Sep 18, 2018 at 7:08 AM Wes Turner wrote:
> >
> > To summarize:
> >
> > - CPython may be vulnerable to speculative execution vulnerabilities, but
> > none are known.
> > - In general, CPython is currently too slow for speculative exe
I believe this is the article Wes wanted to link to:
https://www.thomas-krenn.com/en/wiki/Safety_instructions_for_Meltdown_and_Spectre
On Mon, Sep 17, 2018 at 6:10 PM Wes Turner wrote:
>
> To summarize:
>
> - CPython may be vulnerable to speculative execution vulnerabilities, but
> none are know
On Mon, May 14, 2018, 03:36 Chris Angelico wrote:
> Guido has stated that this parallel is desired and important:
>
> result = [f(x) for x in iter if g(x)]
> result = list(f(x) for x in iter if g(x))
>
> Obviously the genexp has to be implemented with a nested function,
> since there's no guarant
On Tue, Dec 26, 2017 at 2:01 AM, Yogev Hendel wrote:
>
> I don't know if this is the right place to put this,
> but I've found the following lines of code results in an incredibly long
> processing time.
> Perhaps it might be of use to someone.
>
> import re
> pat = re.compile('^/?(?:\\w+)/(?:[%\\
On Thu, Jan 26, 2017 at 4:13 PM, Sven R. Kunze wrote:
> Hi folks,
>
> I recently refreshed regular expressions theoretical basics *indulging in
> reminiscences* So, I read https://swtch.com/~rsc/regexp/regexp1.html
>
> However, reaching the chart in the lower third of the article, I saw Python
> 2
On Sat, Oct 8, 2016 at 6:01 AM, Serhiy Storchaka wrote:
> Since dict is ordered in CPython 3.6, it can be used instead of OrderedDict
> in some places (e.g. for implementing simple limited caches). But since this
> is implementation detail, it can't be used in the stdlib unconditionally.
> Needed
On Sep 14, 2016 8:29 AM, "Paul Moore" wrote:
>
> On 14 September 2016 at 13:18, Franklin? Lee
> wrote:
> > On Sep 9, 2016 1:35 AM, "Benjamin Peterson" wrote:
> >> On Thu, Sep 8, 2016, at 22:33, Tim Delaney wrote:
> >> > Are sets also or
On Sep 9, 2016 1:35 AM, "Benjamin Peterson" wrote:
> On Thu, Sep 8, 2016, at 22:33, Tim Delaney wrote:
> > Are sets also ordered by default now? None of the PEPs appear to mention
> > it.
>
> No.
Is there anyone working to move sets in the same direction for 3.6?
_
On Jun 21, 2016 11:12 AM, "INADA Naoki" wrote:
>
> I'm sorry, but I hadn't realized which compact ordered dict is
> not ordered for split table.
>
> For example:
> >>> class A:
> ... ...
> ...
> >>> a = A()
> >>> b = A()
> >>> a.a = 1
> >>> a.b = 2
> >>> b.b = 3
> >>> b.a = 4
> >>> a.__dict__.it
In the original discussion, I think they decided to reimplement set before
dict.
The original discussion is here, for anyone else:
https://mail.python.org/pipermail/python-dev/2012-December/123028.html
On Jun 18, 2016 3:15 AM, "INADA Naoki" wrote:
> If builtin dict in both of PyPy and CPython is
Compact OrderedDicts can leave gaps, and once in a while compactify. For
example, whenever the entry table is full, it can decide whether to resize
(and only copy non-gaps), or just compactactify
Compact regular dicts can swap from the back and have no gaps.
I don't see the point of discussing th
ow
gaps in your compact entry table. PyPy implemented compact dicts and
chose(?) to make dicts ordered.
On Saturday, June 11, 2016, Eric Snow wrote:
> On Fri, Jun 10, 2016 at 11:54 AM, Franklin? Lee
> > wrote:
> > Eric, have you any work in progress on compact dicts?
>
>
ow
gaps in your compact entry table. PyPy implemented compact dicts and
chose(?) to make dicts ordered.
On Saturday, June 11, 2016, Eric Snow wrote:
> On Fri, Jun 10, 2016 at 11:54 AM, Franklin? Lee
> > wrote:
> > Eric, have you any work in progress on compact dicts?
>
>
ow
gaps in your compact entry table. PyPy implemented compact dicts and
chose(?) to make dicts ordered.
On Saturday, June 11, 2016, Eric Snow wrote:
> On Fri, Jun 10, 2016 at 11:54 AM, Franklin? Lee
> > wrote:
> > Eric, have you any work in progress on compact dicts?
>
>
ow
gaps in your compact entry table. PyPy implemented compact dicts and
chose(?) to make dicts ordered.
On Saturday, June 11, 2016, Eric Snow wrote:
> On Fri, Jun 10, 2016 at 11:54 AM, Franklin? Lee
> > wrote:
> > Eric, have you any work in progress on compact dicts?
>
>
ow
gaps in your compact entry table. PyPy implemented compact dicts and
chose(?) to make dicts ordered.
On Saturday, June 11, 2016, Eric Snow wrote:
> On Fri, Jun 10, 2016 at 11:54 AM, Franklin? Lee
> > wrote:
> > Eric, have you any work in progress on compact dicts?
>
>
ow
gaps in your compact entry table. PyPy implemented compact dicts and
chose(?) to make dicts ordered.
On Saturday, June 11, 2016, Eric Snow wrote:
> On Fri, Jun 10, 2016 at 11:54 AM, Franklin? Lee
> > wrote:
> > Eric, have you any work in progress on compact dicts?
>
>
Eric, have you any work in progress on compact dicts?
On Fri, Jun 10, 2016 at 12:54 PM, Eric Snow wrote:
> On Thu, Jun 9, 2016 at 1:10 PM, Émanuel Barry wrote:
>> As stated by Guido (and pointed out in the PEP):
>>
>> Making **kwds ordered is still open, but requires careful design and
>> implem
On Jun 8, 2016 8:13 AM, "Paul Sokolovsky" wrote:
>
> Hello,
>
> On Wed, 8 Jun 2016 14:45:22 +0300
> Serhiy Storchaka wrote:
>
> []
>
> > > $ ./run-bench-tests bench/bytealloc*
> > > bench/bytealloc:
> > > 3.333s (+00.00%) bench/bytealloc-1-bytes_n.py
> > > 11.244s (+237.35%) bench/bytea
On Jun 7, 2016 8:52 PM, "Eric Snow" wrote:
> * the default class *definition* namespace is now ``OrderdDict``
> * the order in which class attributes are defined is preserved in the
By using an OrderedDict, names are ordered by first definition point,
rather than location of the used definition.
It's just that I don't know whether any of them require particular
versions. If you say the latest is fine, then okay.
On Wed, May 25, 2016 at 1:37 PM, Brett Cannon wrote:
>
>
> On Wed, 25 May 2016 at 10:24 Franklin? Lee
> wrote:
>>
>> Should these notes come
Should these notes come with version requirements/minimums?
"OS X users should be told to download XCode from the Apple App Store
ahead of time."
"If new contributors think they may be doing C development, suggest
the use of LLVM + clang as this provides better error reporting than
gcc."
"For Wind
On Apr 26, 2016 4:02 AM, "Paul Moore" wrote:
>
> On 25 April 2016 at 23:55, Franklin? Lee
wrote:
> > FWIW, Gmail's policies require:
> [...]
> > That link is currently the only obvious way to unsubscribe.
>
> I'm not sure why gmail's policies
FWIW, Gmail's policies require:
"""
A user must be able to unsubscribe from your mailing list through
one of the following means:
* A prominent link in the body of an email leading users to a page
confirming his or her unsubscription (no input from the user, other
than confirmation, should
For this particular case, is there someone generous enough (or, can someone
apply for a PSF grant) to ship Mathieu a DVD/two/flash drive?
On Feb 26, 2016 12:18 PM, "Mathieu Dupuy" wrote:
> Hi.
> I am currently working on adding some functionality on a standard
> library module (http://bugs.python
I think it would be nice for manipulating (e.g. optimizing, possibly with
JIT-like analysis) and comparing regexes. It can also be useful as a
teaching tool, e.g. exercises in optimizing and comparing regexes.
I think the discussion should be on python-ideas, though.
On Feb 14, 2016 2:01 PM, "Jona
On Fri, Dec 18, 2015 at 2:32 PM, Andrew Barnert via Python-Dev
wrote:
> (Also, either way, it seems more like a thread for -ideas than -dev...)
I said this early on in this thread!
Should I try to write up my idea as a single thing, instead of a bunch
of responses, and post it in -ideas?
Shoul
On Thu, Dec 17, 2015 at 6:41 PM, Franklin? Lee
wrote:
> Then Descriptors are in the dict, so MIGHT benefit from refcells. The
> memory cost might be higher, though.
Might be worse than the savings, I mean.
___
Python-Dev mailing list
Pyth
> wrote:
>>
>> On Thursday, December 17, 2015 11:19 AM, Franklin? Lee
>> wrote:
>>
>>
>>> ...
>>> as soon as I figure out how descriptors actually work...
>>
>>
>> I think you need to learn what LOAD_ATTR and the machinery around
On Thu, Dec 17, 2015 at 12:30 PM, Andrew Barnert wrote:
> On Dec 17, 2015, at 07:38, Franklin? Lee
> wrote:
>>
>> The nested dictionaries are only for nested scopes (and inner
>> functions don't create nested scopes). Nested scopes will already
>> require
On Thu, Dec 17, 2015 at 11:50 AM, Victor Stinner
wrote:
> I don't understand how you plan to avoid guards. The purpose of guards
> is to respect the Python semantic by falling back to the "slow"
> bytecode if something changes. So I don't understand your idea of
> avoiding completly guards. Again,
(Previous thread was here, by the way:
https://mail.python.org/pipermail/python-dev/2015-December/142437.html)
On Thu, Dec 17, 2015 at 8:48 AM, Steven D'Aprano wrote:
> On Thu, Dec 17, 2015 at 12:53:13PM +0100, Victor Stinner quoted:
>> 2015-12-17 11:54 GMT+01:00 Franklin? Lee
On Thu, Dec 17, 2015 at 6:53 AM, Victor Stinner
wrote:
> 2015-12-17 11:54 GMT+01:00 Franklin? Lee :
>> My suggestion should improve *all* function calls which refer to
>> outside names.
>
> Ok, I now think that you should stop hijacking the FAT Python thread.
> I start
On Wed, Dec 16, 2015 at 2:01 AM, Victor Stinner
wrote:
> Le mercredi 16 décembre 2015, Franklin? Lee
> a écrit :
>>
>> I am confident that the time overhead and the savings will beat the
>> versioning dict. The versioning dict method has to save a reference to
>
I realized yet another thing, which will reduce overhead: the original
array can store values directly, and you maintain the refs by
repeatedly updating them when moving refs around. RefCells will point
to a pointer to the value cell (which already exists in the table).
- `getitem` will be almos
ation would result in a call to its set/del functions,
which would initiate a deep copy.
On Tue, Dec 15, 2015 at 3:29 PM, Victor Stinner
wrote:
> 2015-12-15 12:23 GMT+01:00 Franklin? Lee :
>> I was thinking (as an alternative to versioning dicts) about a
>> dictionary which woul
On Sat, Dec 04, 2015 at 7:49 AM, Victor Stinner
wrote:
> Versionned dictionary
> =
>
> In the previous milestone of FAT Python, the versionned dictionary was a
> new type inherited from the builtin dict type which added a __version__
> read-only (global "version" of dictionary
On Tue, Dec 15, 2015 at 8:04 AM, Victor Stinner
wrote:
> Is it expected that "not x.__eq__(y)" can be different than
> "x.__ne__(y)"? Is it part of the Python semantic?
In Numpy, `x != y` returns an array of bools, while `not x == y`
creates an array of bools and then tries to convert it to a boo
41 matches
Mail list logo
