On 2017-04-26 23:29, Erik wrote:
On 26/04/17 19:15, Mike Miller wrote:
As the new syntax ideas piggyback on existing syntax, it doesn't feel
like that its a complete impossibility to have this solved. Could be
another "fixed papercut" to drive Py3 adoption. Taken individually not
a big deal bu
On Wed, Apr 26, 2017 at 6:57 PM, Mike Miller
wrote:
> Yes, I like it too. Removes the triple repetition, and has precedent in
> the other languages.
This discussion has been around how to deal with repetition in object
constructors, and the proposals have been a new assignment statement (patch
Yes, I like it too. Removes the triple repetition, and has precedent in the
other languages.
On 2017-04-26 12:54, Jerry Hill wrote:
On Tue, Apr 25, 2017 at 8:05 PM, Ryan Gonzalez wrote:
def ___init__(self, self.attr):
I'm not a python developer, I'm just a developer that uses python.
That
On 26/04/17 23:28, Paul Moore wrote:
Or to put it another way, if the only
reason for the syntax proposal is performance then show me a case
where performance is so critical that it warrants a language change.
It's the other way around.
The proposal (arguably) makes the code clearer but does n
On 26/04/17 19:15, Mike Miller wrote:
As the new syntax ideas piggyback on existing syntax, it doesn't feel
like that its a complete impossibility to have this solved. Could be
another "fixed papercut" to drive Py3 adoption. Taken individually not
a big deal but they add up.
*sigh* OK, this h
On 26 April 2017 at 22:42, Erik wrote:
> 2) The original proposal, which does belong on -ideas and has to take into
> account the general case, not just my specific use-case.
>
> The post you are responding to is part of (2), and hence reduced performance
> is a consideration.
Ah, OK. I'm discoun
On 26/04/2017 21:50, Chris Angelico wrote:
On Thu, Apr 27, 2017 at 6:24 AM, Erik wrote:
The background is that what I find myself doing a lot of for private
projects is importing data from databases into a structured collection of
objects and then grouping and analyzing the data in different wa
On 26/04/17 22:28, Paul Moore wrote:
On 26 April 2017 at 21:51, Erik wrote:
It doesn't make anything more efficient, however all of the suggestions of
how to do it with current syntax (mostly decorators) _do_ make things less
efficient.
Is instance creation the performance bottleneck in your
On 26 April 2017 at 21:51, Erik wrote:
> It doesn't make anything more efficient, however all of the suggestions of
> how to do it with current syntax (mostly decorators) _do_ make things less
> efficient.
Is instance creation the performance bottleneck in your application?
That seems unusual. I
On 26/04/17 01:39, Nathaniel Smith wrote:
[snip discussion of why current augmented assignment operators are
better for other reasons]
Are there any similar arguments for .=?
It doesn't make anything more efficient, however all of the suggestions
of how to do it with current syntax (mostly
On Thu, Apr 27, 2017 at 6:24 AM, Erik wrote:
> The background is that what I find myself doing a lot of for private
> projects is importing data from databases into a structured collection of
> objects and then grouping and analyzing the data in different ways before
> graphing the results.
>
> So
On 26/04/17 16:10, Nick Timkovich wrote:
I was wondering that if there are so many arguments to a function that
it *looks* ugly, that it might just *be* ugly.
For one, too many required arguments to a function (constructor,
whatever) is already strange. Binding them as attributes of the object,
On Tue, Apr 25, 2017 at 8:05 PM, Ryan Gonzalez wrote:
> def ___init__(self, self.attr):
I'm not a python developer, I'm just a developer that uses python.
That said, I really like this form. It eliminates most of the
redundancy, while still being explicit. It's true that you have to
repeat the
On 26/04/17 18:42, Mike Miller wrote:
I want to be able to say:
def __init__(self, foo, bar, baz, spam):
self .= foo, bar, spam
self.baz = baz * 100
I don't see ALL being set a big problem, and less work than typing
several of them out again.
Because, some of the parameters might be th
On 2017-04-25 15:05, Paul Moore wrote:
It seems to me that the number of people for whom both of the following hold:
1. Writing out the assignments "longhand" is an unacceptable burden.
2. Using a decorator (which can be written directly in your project,
doesn't even need to be an external depe
On 2017-04-26 18:46, Mike Miller wrote:
On 2017-04-26 04:12, Brice PARENT wrote:
Why not simply do this :
class MyClass:
def _set_multiple(self, **kwargs):
for key, value in kwargs.items():
setattr(self, key, value)
def __init__(self, a, b, c):
self._set_mu
On Wed, Apr 26, 2017 at 11:17 AM, Erik wrote:
> I had forgotten that decorators could take parameters. Something like that
> pretty much ticks the boxes for me.
>
There are decorators with "include" and "included" in this SO Q&A:
http://stackoverflow.com/q/3652851/545637
> I'd _prefer_ s
On 2017-04-26 04:12, Brice PARENT wrote:
Why not simply do this :
class MyClass:
def _set_multiple(self, **kwargs):
for key, value in kwargs.items():
setattr(self, key, value)
def __init__(self, a, b, c):
self._set_multiple(a=a, b=b, c=c)
If the goal is to
On 2017-04-25 15:30, Erik wrote:
All of the decorators (or other language tricks that modify the object's dict)
suggested so far assume that ALL of the method's arguments are to be assigned. I
do not want that. I want to be able to say:
def __init__(self, foo, bar, baz, spam):
self .= foo, b
On 26 April 2017 at 16:17, Erik wrote:
> On 26/04/17 08:59, Paul Moore wrote:
>>
>> It should be possible to modify the decorator to take a list
>> of the variable names you want to assign, but I suspect you won't like
>> that
>
>
> Now you're second-guessing me.
Sorry :-)
>> class MyClass:
>>
On 26/04/17 08:59, Paul Moore wrote:
It should be possible to modify the decorator to take a list
of the variable names you want to assign, but I suspect you won't like
that
Now you're second-guessing me.
> class MyClass:
> @auto_args('a', 'b')
> def __init__(self, a, b, c=None):
>
I was wondering that if there are so many arguments to a function that it
*looks* ugly, that it might just *be* ugly.
For one, too many required arguments to a function (constructor, whatever)
is already strange. Binding them as attributes of the object, unmodified in
a constructor also seems to b
On 26/04/17 13:19, Joao S. O. Bueno wrote:
On 25 April 2017 at 19:30, Erik wrote:
decorators don't cut it anyway (at least not those
proposed) because they blindly assign ALL of the arguments. I'm more than
happy to hear of something that solves both of those problems without
needing syntax cha
On Wed, Apr 26, 2017 at 2:02 PM, wrote:
>> On Wed, Apr 26, 2017 at 01:12:14PM +0200, Brice PARENT
>> wrote:
>> > def _set_multiple(self, **kwargs):
>> > for key, value in kwargs.items():
>> > setattr(self, key, value)
>>
>> self.__dict__.update(kwargs)
>
> Touching _
On 25 April 2017 at 19:30, Erik wrote:
> And as I also said above, decorators don't cut it anyway (at least not those
> proposed) because they blindly assign ALL of the arguments. I'm more than
> happy to hear of something that solves both of those problems without
> needing syntax changes though,
> -Original Message-
> From: Python-ideas [mailto:python-ideas-bounces+tritium-
> list=sdamon@python.org] On Behalf Of Oleg Broytman
> Sent: Wednesday, April 26, 2017 7:33 AM
> To: python-ideas@python.org
> Subject: Re: [Python-ideas] Augmented assignment syntax for objects.
>
> On W
On Wed, Apr 26, 2017 at 01:12:14PM +0200, Brice PARENT
wrote:
> def _set_multiple(self, **kwargs):
> for key, value in kwargs.items():
> setattr(self, key, value)
self.__dict__.update(kwargs)
Oleg.
--
Oleg Broytmanhttp://phdru.name/p...@
On 25 April 2017 at 23:30, Erik wrote:
> As I said above, it's not about the effort writing it out. It's about the
> effort (and accuracy) of reading the code after it has been written.
Well, personally I find all of the syntax proposals relatively
unreadable. So that's definitely a matter of opi
28 matches
Mail list logo