Rationale
=========
- Separation of executable code and non-executable data is a good thing.
- Additional security in Python is a good idea.
- Python should support things like the NX bit to separate code and
non-executable data.
Discussion
==========
How could Python implement support for the NX bit? (And/or additional
modern security measures; as appropriate).
What sort of an API would C extensions need?
Would this be easier in PyPy or in CPython?
- https://en.wikipedia.org/wiki/NX_bit
- https://en.wikipedia.org/wiki/Executable_space_protection
Here's one way to identify whether an executable supports NX:
https://github.com/longld/peda/blob/e0eb0af4bcf3ee/peda.py#L2543
On Sunday, September 2, 2018, Zaur Shibzukhov <szport(a)gmail.com> wrote:
>
>
> ---
> *Zaur Shibzukhov*
>
>
> 2018-09-02 22:11 GMT+03:00 Wes Turner <wes.turner(a)gmail.com>:
>
>> Does the value of __hash__ change when attributes of a recordclass change?
>>
>
> Currently recordclass's __hash__ didn't implemented.
>
https://docs.python.org/3/glossary.html#term-hashablehttps://docs.python.org/3/reference/datamodel.html#object.__hash__http://www.attrs.org/en/stable/hashing.html
>
>> On Sunday, September 2, 2018, Zaur Shibzukhov <szport(a)gmail.com> wrote:
>>
>>> As the author of `recordclass` I would like to shed some light...
>>>
>>> Recorclass originated as a response to the [question](
>>> https://stackoverflow.com/questions/29290359/exis
>>> tence-of-mutable-named-tuple-in-python/29419745#29419745) on
>>> stackoverflow.
>>>
>>> `Recordclass` was conceived and implemented as a type that, by api,
>>> memory and speed, would be completely identical to` namedtuple`, except
>>> that it would support an assignment in which any element could be replaced
>>> without creating a new instance, as in ` namedtuple`. Those. would be
>>> almost identical to `namedtuple` and support the assignment (` __setitem__`
>>> / `setslice__`).
>>>
>>> The effectiveness of namedtuple is based on the effectiveness of the
>>> `tuple` type in python. In order to achieve the same efficiency it was
>>> necessary to create a type `memoryslots`. Its structure
>>> (`PyMemorySlotsObject`) is identical to the structure of` tuple`
>>> (`PyTupleObject`) and therefore takes up the same amount of memory as`
>>> tuple`.
>>>
>>> `Recordclass` is defined on top of` memoryslots` just like `namedtuple`
>>> above` tuple`. Attributes are accessed via a descriptor (`itemgetset`),
>>> which supports both` __get__` and `__set__` by the element index.
>>>
>>> The class generated by `recordclass` is:
>>>
>>> `` `
>>> from recordclass import memoryslots, itemgetset
>>>
>>> class C (memoryslots):
>>> __slots__ = ()
>>>
>>> _fields = ('attr_1', ..., 'attr_m')
>>>
>>> attr_1 = itemgetset (0)
>>> ...
>>> attr_m = itemgetset (m-1)
>>>
>>> def __new __ (cls, attr_1, ..., attr_m):
>>> 'Create new instance of {typename} ({arg_list})'
>>> return memoryslots .__ new __ (cls, attr_1, ..., attr_m)
>>> `` `
>>> etc. following the `namedtuple` definition scheme.
>>>
>>> As a result, `recordclass` takes up as much memory as` namedtuple`, it
>>> supports quick access by `__getitem__` /` __setitem__` and by attribute
>>> name via the protocol of the descriptors.
>>>
>>> Regards,
>>>
>>> Zaur
>>>
>>> суббота, 1 сентября 2018 г., 10:48:07 UTC+3 пользователь Martin Bammer
>>> написал:
>>>>
>>>> Hi,
>>>>
>>>> what about adding recordclass
>>>> (https://bitbucket.org/intellimath/recordclass) to the collections
>>>> module
>>>>
>>>> It is like namedtuple, but elements are writable and it is written in C
>>>> and thus much faster.
>>>>
>>>> And for convenience it could be named as namedlist.
>>>>
>>>> Regards,
>>>>
>>>> Martin
>>>>
>>>>
>>>> _______________________________________________
>>>> Python-ideas mailing list
>>>> Python...(a)python.org
>>>> https://mail.python.org/mailman/listinfo/python-ideas
>>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>>
>>>
>
> Date: Thu, 30 Aug 2018 00:07:04 +0200
> From: Marko Ristin-Kaufmann <marko.ristin(a)gmail.com>
...
> I think we got entangled in a discussion about whether design-by-contract
> is useful or not. IMO, the personal experience ("I never used/needed this
> feature") is quite an inappropriate rule whether something needs to be
> introduced into the language or not.
>
> There seems to be evidence that design-by-contract is useful. Let me cite
> Bertrand Meyer from his article "Why not program right?" that I already
> mentioned before:
I don't think that being useful by itself should be enough. I think new features
should also be "Pythonic" and I don't see design by contract notation as a
good fit.
For example, C has the useful & operator which lets you pass &foo as
a pointer/array argument despite foo being a scalar, so assignment to
bar[0] in the called function actually sets the value of foo. It might be
possible to create some kind of aliasing operator for Python so that two
or more variables were bound to the same location, but would we want
it? No, because Python is not intended for that style of programming.
For another example, GPU shading languages have the special keywords
uniform and varying for distinguishing definitions that won't change across
parallel invocations and definitions that will. Demonstrably very useful in
computer games and supercomputer number crunching, so why doesn't
Python have those keywords? Because it's not designed to be used for
such.
For design by contract, as others have noted Python assert statements
work fine for simple preconditions and postconditions. I don't see any
significant difference in readability between existing
def foo(x, y):
assert(x > 0)
# Do stuff
assert(x == y)
and new style
def foo(x, y):
require:
x > 0
# Do stuff
ensure:
x == y
Yes there's more to design by contract than simple assertions, but it's not
just adding syntax. Meyer often uses the special "old" construct in his post
condition examples, a trivial example being
ensure count = old.count + 1
How do we do that in Python? And another part of design by contract (at
least according to Meyer) is that it's not enough to just raise an exception,
but there must be a guarantee that it is handled and the post conditions
and/or invariants restored. So there's more syntax for "rescue" and "retry"
If you want to do simple pre and post conditions, Python already has assert.
If you want to go full design by contract, there's no law saying that Python
is the only programming language allowed. Instead of trying to graft new
and IMHO alien concepts onto Python, what's wrong with Eiffel?
--
cheers,
Hugh Fisher
Hi,
what about adding recordclass
(https://bitbucket.org/intellimath/recordclass) to the collections module
It is like namedtuple, but elements are writable and it is written in C
and thus much faster.
And for convenience it could be named as namedlist.
Regards,
Martin
Why shouldn't Python be better at implementing Domain Specific Languages?
>From Johnathan Fine:
> I really do wish we could have language that had all of Ruby's
> strengths, and also all of Python's. That would be really nice. Quite
> something indeed.
> Languages do influence each other. Ruby is good at internal Domain
> Specific Languages (DSLs). And there's Perrotta's influential book on
> Ruby Metaprogramming. That's something I think Python could learn
> from.
> But I don't see any need (or even benefit) in adding new language
> features to Python, so it can do better at DSLs.
It would be nice if there was a DSL for describing neural networks (Keras).
The current syntax looks like this:
model.add(Dense(units=64, activation='relu', input_dim=100))
model.add(Dense(units=10, activation='softmax'))
On 2018-08-30 06:39, Neil Girdhar wrote:
> I'd like these to be Fraction(1), Fraction(1), and Fraction(0).
Why? I cannot think of any natural use case why you would want Fractions
for a few special cases on an operation which returns non-Fractions
generically.
I consider it a feature to know in advance the type of the output of an
operation, given the types of the input. Having an unexpected type
suddenly show up because you happen to hit a special case is a recipe
for bugs.
Jeroen.
>
>
> ---------- Forwarded message ----------
> From: Martin Bammer <mrbm74(a)gmail.com>
> To: python-ideas(a)python.org
> Cc:
> Bcc:
> Date: Sat, 1 Sep 2018 09:47:04 +0200
> Subject: [Python-ideas] Add recordlcass to collections module
> Hi,
>
> what about adding recordclass
> (https://bitbucket.org/intellimath/recordclass) to the collections module
>
> It is like namedtuple, but elements are writable and it is written in C
> and thus much faster.
>
> And for convenience it could be named as namedlist.
>
> Regards,
>
> Martin
>
>
There are a problem which prevent you to reach your goals.
As list in Python is already that efficient, a wrapper of this list in C to
supply so-called namedlist interface could not be that efficient.
Member accessing in Python bytecode requires looking up corresponding
attribute in a hashtable, if you want to access a list by attribute,
actually there is an overhead. This is nothing to do with C implementation.
See https://docs.python.org/3/library/dis.html#opcode-LOAD_ATTR
>
> From: "Steven D'Aprano" <steve(a)pearwood.info>
> To: python-ideas(a)python.org
> Cc:
> Bcc:
> Date: Sat, 1 Sep 2018 18:25:21 +1000
> Subject: Re: [Python-ideas] Add recordlcass to collections module
> On Sat, Sep 01, 2018 at 09:47:04AM +0200, Martin Bammer wrote:
> > Hi,
> >
> > what about adding recordclass
> > (https://bitbucket.org/intellimath/recordclass) to the collections
> module
>
> The first thing you need to do is ask the author of that library whether
> or not he or she is willing to donate the library to the Python stdlib,
> which (among other things) means keeping to the same release schedule as
> the rest of the stdlib.
>
>
> > It is like namedtuple, but elements are writable and it is written in C
> > and thus much faster.
>
> Faster than what?
>
>
> > And for convenience it could be named as namedlist.
>
> Why? Is it a list?
>
> How or why is it better than dataclasses?
>
>
> --
> Steve
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas(a)python.org
> https://mail.python.org/mailman/listinfo/python-ideas
It would need to be a list of the members are mutable. As to the other
questions, yes, do we need another module in the standard library?Angus
>
>
