On 09/01/2016 02:04 PM, Paul Moore wrote:
Thanks. That's a nice example of how the proposal might help. But you
could of course have written your original code as
def update(names, value):
(dbsession.query(Table1)
.filter(Table1.name.in_(names))
.update({'valu
On 09/01/2016 01:24 PM, Brendan Barnwell wrote:
I sometimes write similar code with a sequence of pandas
operations. I think you can get a lot of mileage out of accepting the
loss in precious vertical space and just putting the closing parenthesis
on its own line, indented to the same level
On 1 September 2016 at 19:44, Shane Hathaway wrote:
> Sometimes I fix unbalanced parentheses incorrectly. Here's something I
> might type. There should be another closing parenthesis in the middle:
>
> def update(names, value):
> (dbsession.query(Table1)
> .filter(Table1.nam
On 2016-08-31 14:46, Shane Hathaway wrote:
Hi,
I write a lot of SQLAlchemy code that looks more or less like this:
rows = (
dbsession.query(Table1)
.join(
Table2, Table2.y = Table1.y)
.filter(Table1.x = xx)
.all())
The expressions get very long and nearly alwa
On 09/01/2016 09:35 AM, Steven D'Aprano wrote:
On Wed, Aug 31, 2016 at 03:46:13PM -0600, Shane Hathaway wrote:
Cons:
- Extra parentheses are required.
You have to have extra *something* no matter how you do it. An extra
semi-colon at the end of the statement, in semi-colon language. An extra
On Thu, Sep 01, 2016 at 10:04:12AM -0500, Ryan Hiebert wrote:
>
> > On Sep 1, 2016, at 1:40 AM, Greg Ewing wrote:
> >
> > Guido van Rossum wrote:
> >> Would this be enforced in the grammar or by the lexer? Since you say
> >> you expect the indentation to be enforced, that suggests it would be
>
On Wed, Aug 31, 2016 at 03:46:13PM -0600, Shane Hathaway wrote:
> Cons:
>
> - Extra parentheses are required.
You have to have extra *something* no matter how you do it. An extra
semi-colon at the end of the statement, in semi-colon language. An extra
backslash at the end of the line. An extra
> On Sep 1, 2016, at 1:40 AM, Greg Ewing wrote:
>
> Guido van Rossum wrote:
>> Would this be enforced in the grammar or by the lexer? Since you say
>> you expect the indentation to be enforced, that suggests it would be
>> done by the grammar,
>
> I think it could be done by having the lexer en
On Thu, Sep 01, 2016 at 01:38:19PM +0300, Joonas Liik wrote:
> On 1 September 2016 at 11:10, Sjoerd Job Postmus
> wrote:
> > On Thu, Sep 01, 2016 at 10:43:17AM +0300, Joonas Liik wrote:
> >> Not sure if this is a good idea but it might also make some sense to
> >> in stead have an operator at the
On 1 September 2016 at 11:10, Sjoerd Job Postmus
wrote:
> On Thu, Sep 01, 2016 at 10:43:17AM +0300, Joonas Liik wrote:
>> Not sure if this is a good idea but it might also make some sense to
>> in stead have an operator at the beginning of the line
>>
>> for example some languages have a chainging
On Thu, Sep 01, 2016 at 10:43:17AM +0300, Joonas Liik wrote:
> Not sure if this is a good idea but it might also make some sense to
> in stead have an operator at the beginning of the line
>
> for example some languages have a chainging operator for method calls:
>
> my_object.m1()
> ..m2()
>
On 1 September 2016 at 09:40, Greg Ewing wrote:
> Guido van Rossum wrote:
>>
>> Would this be enforced in the grammar or by the lexer? Since you say
>> you expect the indentation to be enforced, that suggests it would be
>> done by the grammar,
>
>
> I think it could be done by having the lexer en
Guido van Rossum wrote:
Would this be enforced in the grammar or by the lexer? Since you say
you expect the indentation to be enforced, that suggests it would be
done by the grammar,
I think it could be done by having the lexer enter a mode
where it swallows a newline that is followed by an ind
On 08/31/2016 07:25 PM, Guido van Rossum wrote:
On Wed, Aug 31, 2016 at 2:46 PM, Shane Hathaway wrote:
[...]
I'd like to suggest a small change to the Python parser that would make long
expressions read better:
rows = dbsession.query(Table1) ...
.join(
Table2, Table2.y = Table1.y)
Chris Kaynor writes:
> Guido's time machine strikes again, though using a slash (\) rather than
> elipse:
>
> >>> '.'\
> ... .join(
> ... (
> ... '1',
> ... '2',
> ... )
> ... )
> '1.2'
>
> This is from Python 2.7.10 (what I have on the machine I am cu
On Wed, Aug 31, 2016 at 2:46 PM, Shane Hathaway wrote:
[...]
> I'd like to suggest a small change to the Python parser that would make long
> expressions read better:
>
> rows = dbsession.query(Table1) ...
> .join(
> Table2, Table2.y = Table1.y)
> .filter(Table1.x = xx)
> .all(
On Aug 31, 2016 7:22 PM, "Chris Kaynor" wrote:
>
> Guido's time machine strikes again,
GAH! We should've just used that for PEPs 484 and 526; instead of trying to
prove type hints are useful, Guido could've just:
1. Go 50 years into the future.
2. Make note of the Python's world domination (Perl
Guido's time machine strikes again, though using a slash (\) rather than
elipse:
>>> '.'\
... .join(
... (
... '1',
... '2',
... )
... )
'1.2'
This is from Python 2.7.10 (what I have on the machine I am currently on),
though I'm fairly sure it has worked for quite
Hi,
I write a lot of SQLAlchemy code that looks more or less like this:
rows = (
dbsession.query(Table1)
.join(
Table2, Table2.y = Table1.y)
.filter(Table1.x = xx)
.all())
The expressions get very long and nearly always need to be spread to
multiple lines. I've tried va
19 matches
Mail list logo
