The @property.getter and @property.setter decorators are
clever, but they have the disadvantage that you end up
writing the name of the property no less than 5 times,
all of which have to match.
Thinking there must be a better way, I came up with this:
def Property(name, bases, dict):
return
(Not sure why this is on python-ideas - wouldn't python-list be more
appropriate? Keeping it where it is for now though.)
On Thu, Jul 2, 2020 at 5:14 PM Greg Ewing wrote:
>
> The @property.getter and @property.setter decorators are
> clever, but they have the disadvantage that you end up
> writin
02.07.20 10:12, Greg Ewing пише:
The @property.getter and @property.setter decorators are
clever, but they have the disadvantage that you end up
writing the name of the property no less than 5 times,
all of which have to match.
5 times? How is it?
Thinking there must be a better way, I came u
On Thu, Jul 02, 2020 at 11:04:40AM +0300, Serhiy Storchaka wrote:
> 02.07.20 10:12, Greg Ewing пише:
> >The @property.getter and @property.setter decorators are
> >clever, but they have the disadvantage that you end up
> >writing the name of the property no less than 5 times,
> >all of which have t
On Thu, Jul 2, 2020 at 9:34 AM Chris Angelico wrote:
> (Not sure why this is on python-ideas - wouldn't python-list be more
> appropriate? Keeping it where it is for now though.)
>
As someone not familiar with the other lists...why? It's a proposal of an
idea that could use some debate. Isn't th
On Thu, Jul 2, 2020 at 7:04 PM Steven D'Aprano wrote:
> That makes five by my count, however I hardly ever write a deleter so
> three is more common, and only occassionally a setter so one is most
> common :-)
>
Well, if you only want a getter, the most common way is fine. But if
you then go to a
On Thu, Jul 2, 2020 at 7:06 PM Alex Hall wrote:
>
> On Thu, Jul 2, 2020 at 9:34 AM Chris Angelico wrote:
>>
>> (Not sure why this is on python-ideas - wouldn't python-list be more
>> appropriate? Keeping it where it is for now though.)
>
>
> As someone not familiar with the other lists...why? It'
On Thu, Jul 2, 2020 at 7:41 PM Alex Hall wrote:
>
> On Thu, Jul 2, 2020 at 11:33 AM Chris Angelico wrote:
>>
>> What's the idea being discussed? AIUI there's no need or request to
>> change the language/stdlib, but maybe I'm misreading.
>
> Ah, now I understand. I did automatically assume that Gr
On Thu, Jul 2, 2020 at 11:33 AM Chris Angelico wrote:
> On Thu, Jul 2, 2020 at 7:06 PM Alex Hall wrote:
> >
> > On Thu, Jul 2, 2020 at 9:34 AM Chris Angelico wrote:
> >>
> >> (Not sure why this is on python-ideas - wouldn't python-list be more
> >> appropriate? Keeping it where it is for now th
On 2/07/20 8:04 pm, Serhiy Storchaka wrote:
It has a problem with pickling (it is solvable).
Can you elaborate? The end result is a property object just the
same as you would get from using @property or calling property
directly. I don't see how it can have any pickling problems
beyond what pro
On 2/07/20 9:45 pm, Chris Angelico wrote:
On Thu, Jul 2, 2020 at 7:41 PM Alex Hall wrote:
On Thu, Jul 2, 2020 at 11:33 AM Chris Angelico wrote:
What's the idea being discussed? AIUI there's no need or request to
change the language/stdlib, but maybe I'm misreading.
Ah, now I understand. I
On 2/07/20 9:00 pm, Steven D'Aprano wrote:
Perhaps Greg meant to say *up to* rather than "no less".
What I said is true for sufficiently small values of 5. :-)
You're right that it depends on how many operations you
want. For reading and writing it's 3; if you want deleting
as well it's 5.
B
Coincidentally, cython has a custom, deprecated syntax for properties that
is actually pretty similar, and nice:
cdef class Spam:
property cheese:
"A doc string can go here."
def __get__(self):
# This is called when the property is read.
...
On 2/07/20 10:49 pm, Stestagg wrote:
Coincidentally, cython has a custom, deprecated syntax for properties
that is actually pretty similar
Not entirely a coincidence -- I invented that syntax for Pyrex,
and Cython inherited it.
I'm a little disappointed to hear it's been deprecated. :-(
--
Gr
Haha, I had no idea! That's great.
fyi, judicious use of cython allowed our python team to build python
components that far outperformed their java counterparts in some real-time
middle-office financial processing jobs for a really large client. So thank
you.
I can see why using the standard pyt
On Thu, Jul 2, 2020 at 8:38 PM Greg Ewing wrote:
>
> On 2/07/20 9:45 pm, Chris Angelico wrote:
> > On Thu, Jul 2, 2020 at 7:41 PM Alex Hall wrote:
> >>
> >> On Thu, Jul 2, 2020 at 11:33 AM Chris Angelico wrote:
> >>>
> >>> What's the idea being discussed? AIUI there's no need or request to
> >>>
On Thu, Jul 2, 2020, 6:30 AM Greg Ewing wrote:
> On 2/07/20 8:04 pm, Serhiy Storchaka wrote:
> > It has a problem with pickling (it is solvable).
>
> Can you elaborate? The end result is a property object just the
> same as you would get from using @property or calling property
> directly. I don'
Em qua, 1 de jul de 2020 00:56, David Lowry-Duda
escreveu:
> Very similar things could be said about dict.get too, no? It's easy to
> write your own function that does the same thing or to catch an
> exception.
>
> On the other hand, it seems far more likely to miss keys in a dictionary
> than it
Em ter., 30 de jun. de 2020 às 15:49, Alex Hall
escreveu:
> I think I'm missing something. Daniel wants a `list.get` method with
> similar semantics to `dict.get`. So instead of writing:
>
> ```
> try:
> x = lst[i]
> except IndexError:
> x = default
> ```
>
> one could write `x = lst.get(
On Thu, Jul 2, 2020 at 9:33 PM Daniel. wrote:
> Em ter., 30 de jun. de 2020 às 15:49, Alex Hall
> escreveu:
>
>> I think I'm missing something. Daniel wants a `list.get` method with
>> similar semantics to `dict.get`. So instead of writing:
>>
>> ```
>> try:
>> x = lst[i]
>> except IndexErro
The goal as it stands is to make PyObject an opaque type (interpreted to
mean, "incomplete type"), but there is a blocking problem to
accomplishing that.
Functions/Macros like PY_TYPE require a complete PyObject.
There is 3 ways we can solve this problem:
1) Dump to & export from the Python DLL.
On Thu, Jul 2, 2020, at 16:04, William Pickard wrote:
> The goal as it stands is to make PyObject an opaque type (interpreted
> to mean, "incomplete type"), but there is a blocking problem to
> accomplishing that.
>
> Functions/Macros like PY_TYPE require a complete PyObject.
Is it acceptable i
Often, I know that a variable should have one of a set of values, and I want to
determine which one, with an if/elif/else clause. This looks something like
this:
```
if foo == 1:
# do a
elif foo == 2:
# do b
elif foo == 3:
# do c
else:
raise ValueError('foo must be 1, 2 or 3')
```
Assertions aren't guaranteed to be executed and thus should never be used
where raising an error is required.
`else: raise SomeError('reason')` already has the desired effect, and it's
plenty readable.
On Thu, Jul 2, 2020, 7:46 PM Artemis wrote:
> Often, I know that a variable should have one o
To be more specific, if the last `elif` condition permits all remaining
permissible conditions (which I suppose would just be whatever is asserted
by the proposed syntax), then the else block can just be the raising of the
exception.
On Thu, Jul 2, 2020, 7:52 PM Steele Farnsworth
wrote:
> Assert
> Assertions aren't guaranteed to be executed and thus should never be used
where raising an error is required.
Hence *roughly* equivalent to. Perhaps for this reason the second version would
be confusing and should not be used.
> `else: raise SomeError('reason')` already has the desired effect,
My personal feeling: I would love this idea (DRY gets me almost every time)
if it weren't for that awful, terrible `class` keyword hanging out there.
I wouldn't call using class this way "abuse", exactly, but it could be a
potential use for an old idea raised more than once in the past: some kind
Alex Hall writes:
> `dct.get('foo')?.get(0)?.get('bar')`.
>
> I would quite like to have PEP 505, but I don't know how to revive it. And
> I'm not surprised that it's deferred, there's generally reluctance to add
> new syntax, especially symbols.
Bottom line: new use cases or modified seman
Christopher Barker writes:
> On Mon, Jun 29, 2020 at 1:53 AM Stephen J. Turnbull <
> turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> > But if it turns out that somebody *wants* to check "2 is 2.0",
> > this .add_unique can serve both purposes.
> can it though?
Yes.
> (or should it?)
YMMV,
Stestagg writes:
> Having said that, it's a 70-line change, so fixing that up should be
> trivial once the change has some agreement behind it.
I still don't see a plausible use case that isn't well served by
list(view). The OP's "addressing database columns" is superficially
plausible, but th
I do have a plan to solve that problem, it involves adding about 24 more
bytes to PyTypeObject, but it would allow Python to track offset from base
object, total object size and best alignment value.
___
Python-ideas mailing list -- python-ideas@python.or
An alternative way of doing what you need that doesn't add any syntax, is more
readable, runs faster, scales better and has long been used as the reason that
python doesn't need a case statement would be:
# Dictionary of which actions to take for foo
foo_action_dict = {
'a':a,
'b':b,
On Thu, Jul 2, 2020, at 20:39, William Pickard wrote:
> I do have a plan to solve that problem, it involves adding about 24
> more bytes to PyTypeObject, but it would allow Python to track offset
> from base object, total object size and best alignment value.
I'm not sure I'm following how that
On Wed, Jul 1, 2020, at 08:23, Joao S. O. Bueno wrote:
> collections.mixins.SlicedSequence that would override `__delitem__`,
> `__setitem__` and `__getitem__` and
> handle slices could pair up with the "ComparableSequence" - people
> could use these "a la carte", and
> no backwards compatibili
02.07.20 13:26, Greg Ewing пише:
On 2/07/20 8:04 pm, Serhiy Storchaka wrote:
It has a problem with pickling (it is solvable).
Can you elaborate? The end result is a property object just the
same as you would get from using @property or calling property
directly. I don't see how it can have any
35 matches
Mail list logo
