Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #61205 > unrolled thread

Re: One liners

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: One liners Joel Goldstick <joel.goldstick@gmail.com> - 2013-12-06 19:39 -0500
    Re: One liners Roy Smith <roy@panix.com> - 2013-12-06 19:56 -0500

#61205 — Re: One liners

[Multipart message — attachments visible in raw view] — view raw

On Fri, Dec 6, 2013 at 7:20 PM, Michael Torrie <torriem@gmail.com> wrote:

> On 12/06/2013 05:14 PM, Dan Stromberg wrote:
> > I'm thinking mostly of stackoverflow, but here's an example I ran into (a
> > lot of) on a job:
> >
> > somevar = some_complicated_thing(somevar) if
> > some_other_complicated_thing(somevar) else somevar
> >
> > Would it really be so bad to just use an if statement?  Why are we
> > assigning somevar to itself?  This sort of thing was strewn across 3 or 4
> > physical lines at a time.
>
> You're right that a conventional "if" block is not only more readable,
> but also faster and more efficient code.  Sorry you have to deal with
> code written like that!  That'd frustrate any sane programmer.  It might
> bother me enough to write code to reformat the program to convert that
> style to something sane!  There are times when the ternary (did I get
> that right?) operator is useful and clear.
> --
> https://mail.python.org/mailman/listinfo/python-list
>

While it seems to be a higher status in the team to write new code as
compared to fixing old code, so much can be learned by having to plough
through old code.  To learn others coding style, pick up new understanding,
and most importantly totally disabuse yourself of trying to be cute with
code.  Code is read by the machine and by the programmer.  The programmer
is the one who should be deferred to, imo.  You buy the machine, you rent
the programmer by the hour!

Aside from django urls, I am not sure I ever wrote regexes in python.  For
some reason they must seem awfully sexy to quite a few people.  Back to my
point above -- ever try to figure out a complicated regex written by
someone else?



-- 
Joel Goldstick
http://joelgoldstick.com

[toc] | [next] | [standalone]

#61208

In article <mailman.3682.1386376799.18130.python-list@python.org>,
 Joel Goldstick <joel.goldstick@gmail.com> wrote:

> Aside from django urls, I am not sure I ever wrote regexes in python.  For
> some reason they must seem awfully sexy to quite a few people.  Back to my
> point above -- ever try to figure out a complicated regex written by
> someone else?

Regex has a bad rap in the Python community.  To be sure, you can abuse 
them, and write horrible monstrosities.  On the other hand, stuff like 
this (slightly reformatted for posting):

pattern = re.compile(
        r'haproxy\[(?P<pid>\d+)]: '
        r'(?P<client_ip>(\d{1,3}\.){3}\d{1,3}):'
        r'(?P<client_port>\d{1,5}) '
        r'\[(?P<accept_date>\d{2}/\w{3}/\d{4}(:\d{2}){3}\.\d{3})] '
        r'(?P<frontend_name>\S+) '
        r'(?P<backend_name>\S+)/'
        r'(?P<server_name>\S+) '
        r'(?P<Tq>(-1|\d+))/'
        r'(?P<Tw>(-1|\d+))/'
        r'(?P<Tc>(-1|\d+))/'
        r'(?P<Tr>(-1|\d+))/'
        r'(?P<Tt>\+?\d+) '
        r'(?P<status_code>\d{3}) '
        r'(?P<bytes_read>\d+) '
        r'(?P<captured_request_cookie>\S+) '
        r'(?P<captured_response_cookie>\S+) '
        r'(?P<termination_state>[\w-]{4}) '
        r'(?P<actconn>\d+)/'
        r'(?P<feconn>\d+)/'
        r'(?P<beconn>\d+)/'
        r'(?P<srv_conn>\d+)/'
        r'(?P<retries>\d+) '
        r'(?P<srv_queue>\d+)/'
        r'(?P<backend_queue>\d+) '
        r'(\{(?P<request_id>.*?)\} )?'   # Comment out for stock haproxy
        r'(\{(?P<captured_request_headers>.*?)\} )?'
        r'(\{(?P<captured_response_headers>.*?)\} )?'
        r'"(?P<http_request>.+)"'
        )

while intimidating at first glance, really isn't that hard to 
understand.  Python's raw string literals, adjacent string literal 
catenation, and automatic line continuation team up to eliminate a lot 
of extra fluff.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web