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
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
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
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,
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
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
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,
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
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
> 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,
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.
`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
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')
```
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
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 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
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(
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
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'
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
> >>>
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 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
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 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
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 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 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 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 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: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 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 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
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
(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
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
35 matches
Mail list logo
