RE: Which more Pythonic - self.__class__ or type(self)?

[avi.e.gross]

>>> I think you are over-thinking this, Avi :)

Is overthinking the pythonic way or did I develop such a habit from some
other language?

More seriously, I find in myself that I generally do not overthink. I
overtalk and sort of overwrite, so for now, I think I will drop out of this
possibly non-pythonic topic and go read another book or a few hundred so
when it comes up again ...

-Original Message-
From: Python-list  On
Behalf Of Thomas Passin
Sent: Saturday, March 4, 2023 5:04 PM
To: python-list@python.org
Subject: Re: Which more Pythonic - self.__class__ or type(self)?

On 3/4/2023 4:18 PM, avi.e.gr...@gmail.com wrote:
> I don't know, Thomas. For some simple programs, there is some evolutionary
> benefit by starting with what you know and gradually growing from there.
He
> first time you need to do something that seems to need a loop in python,
> there are loops to choose from.
> 
> But as noted in a recent discussion, things are NOT NECESSARILY the same
> even with something that simple. Did your previous languages retain
> something like the loop variable outside the loop? What are your new
scoping
> rules? Do you really want to keep using global variables, and so on.
> 
> And, another biggie is people who just don't seem aware of what comes
easily
> in the new language. I have seen people from primitive environments set up
> programs with multiple arrays they process the hard way instead of using
> some forms of structure like a named tuple or class arranged in lists or
use
> a multidimensional numpy/pandas kind of data structure.
> 
> So ignoring the word pythonic as too specific, is there a way to say that
> something is the way your current language supports more naturally?
> 
> Yes, there are sort of fingerprints in how people write. Take the python
> concept of truthy and how some people will still typically add a test for
> equality with True. That may not be pythonic to some but is there much
harm
> in being explicit so anyone reading the code better understands what it
doe?
> 
> I have to wonder what others make of my code as my style is likely to be
> considered closer to "eclectic" as I came to python late and found an
> expanding language with way too many ways to do anything and can choose.
But
> I claim that too is pythonic!

I think you are over-thinking this, Avi :)

> 
> -Original Message-
> From: Python-list 
On
> Behalf Of Thomas Passin
> Sent: Saturday, March 4, 2023 1:09 PM
> To: python-list@python.org
> Subject: Re: Which more Pythonic - self.__class__ or type(self)?
> 
> On 3/4/2023 2:47 AM, Peter J. Holzer wrote:
>> Even before Python existed there was the adage "a real programmer
>> can write FORTRAN in any language", indicating that idiomatic usage of a
>> language is not governed by syntax and library alone, but there is a
>> cultural element: People writing code in a specific language also read
>> code by other people in that language, so they start imitating each
>> other, just like speakers of natural languages imitate each other.
>> Someone coming from another language will often write code which is
>> correct but un-idiomatic, and you can often guess which language they
>> come from (they are "writing FORTRAN in Python").
> 
> What Peter didn't say is that this statement is usually used in a
> disparaging sense.  It tends to imply that a person can write (or is
> writing) awkward or inappropriate code anywhere.
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Which more Pythonic - self.__class__ or type(self)?

[Weatherby,Gerard]

Nope. No consensus.

I’d use self.__class__ . Seems more explicit and direct to me.

From: Python-list  on 
behalf of Ian Pilcher 
Date: Thursday, March 2, 2023 at 4:17 PM
To: python-list@python.org 
Subject: Which more Pythonic - self.__class__ or type(self)?
*** Attention: This is an external email. Use caution responding, opening 
attachments or clicking on links. ***

Seems like an FAQ, and I've found a few things on StackOverflow that
discuss the technical differences in edge cases, but I haven't found
anything that talks about which form is considered to be more Pythonic
in those situations where there's no functional difference.

Is there any consensus?

--

Google  Where SkyNet meets Idiocracy

--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!iK8xBvLrRYfAR0KdkDmK-VwyL0ZZUjFJZ9Tj4j-IBz3_B1M0iQFFE3dV-f4bV41DQwnFL_wC2xWRni-0pMUqAw$
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Which more Pythonic - self.__class__ or type(self)?

[Thomas Passin]

On 3/4/2023 4:18 PM, avi.e.gr...@gmail.com wrote:

I don't know, Thomas. For some simple programs, there is some evolutionary
benefit by starting with what you know and gradually growing from there. He
first time you need to do something that seems to need a loop in python,
there are loops to choose from.

But as noted in a recent discussion, things are NOT NECESSARILY the same
even with something that simple. Did your previous languages retain
something like the loop variable outside the loop? What are your new scoping
rules? Do you really want to keep using global variables, and so on.

And, another biggie is people who just don't seem aware of what comes easily
in the new language. I have seen people from primitive environments set up
programs with multiple arrays they process the hard way instead of using
some forms of structure like a named tuple or class arranged in lists or use
a multidimensional numpy/pandas kind of data structure.

So ignoring the word pythonic as too specific, is there a way to say that
something is the way your current language supports more naturally?

Yes, there are sort of fingerprints in how people write. Take the python
concept of truthy and how some people will still typically add a test for
equality with True. That may not be pythonic to some but is there much harm
in being explicit so anyone reading the code better understands what it doe?

I have to wonder what others make of my code as my style is likely to be
considered closer to "eclectic" as I came to python late and found an
expanding language with way too many ways to do anything and can choose. But
I claim that too is pythonic!


I think you are over-thinking this, Avi :)



-Original Message-
From: Python-list  On
Behalf Of Thomas Passin
Sent: Saturday, March 4, 2023 1:09 PM
To: python-list@python.org
Subject: Re: Which more Pythonic - self.__class__ or type(self)?

On 3/4/2023 2:47 AM, Peter J. Holzer wrote:

Even before Python existed there was the adage "a real programmer
can write FORTRAN in any language", indicating that idiomatic usage of a
language is not governed by syntax and library alone, but there is a
cultural element: People writing code in a specific language also read
code by other people in that language, so they start imitating each
other, just like speakers of natural languages imitate each other.
Someone coming from another language will often write code which is
correct but un-idiomatic, and you can often guess which language they
come from (they are "writing FORTRAN in Python").


What Peter didn't say is that this statement is usually used in a
disparaging sense.  It tends to imply that a person can write (or is
writing) awkward or inappropriate code anywhere.



--
https://mail.python.org/mailman/listinfo/python-list

RE: RE: Which more Pythonic - self.__class__ or type(self)?

[avi.e.gross]

Alan,

I got divorced from the C++ crowd decades ago when I left Bell Labs. You are 
making me glad I did!

I do accept your suggestion that you can be idiomatic if you follow the common 
methods of whatever language you use. That will take you quite far as long as 
you are not a total slave to it.

But I note some idioms catch on and some are imposed and some become almost 
moot. I am not sure which aspects of C++ have changed drastically and may go 
re-study the modern version as I was a very early adoptee within AT and saw 
changes even back then. 

But I consider something like the half dozen or so major print variants in 
python and wonder how much longer some of them will be seen as worth using, let 
alone idiomatic. Something like an fstring may dominate for many purposes.

I know in R, that I used to use some convoluted methods to assemble output that 
I often now ignore once a "glue" package gave me something similar to fstring 
abilities where all kinds of variables and calculations can now be embedded 
withing a string to be dynamically evaluated in your current environment. Some 
of the documents I write now similarly embed parts of programs and also have an 
inline ability to evaluate small amounts of code in one of many languages  that 
inserts directly into the text as it is being typeset.

So I see moving targets where what was formerly at or near the state of the 
art, becomes passé. So much of my early work rapidly became trivial or 
irrelevant or never caught on or became lost in an environment I no longer 
used. To keep going forward often involves leaving things behind.

Some new features in Python will be interesting to watch. I mentioned the match 
statement. I was using a similar construct in a JVM language called SCALA ages 
ago.  There it was a sort of core part of the language and often replaced 
constructs normally used by other languages such as many simple or nested IF 
statements. I am sure someone will point out where they borrowed parts from or 
who did it better, but what I am saying is that I want to see if it becomes an 
exotic addition to Python in a way that loosely melds, or if it becomes the 
PYTHONIC way ...



-Original Message-
From: Alan Gauld  
Sent: Saturday, March 4, 2023 1:38 PM
To: avi.e.gr...@gmail.com; python-list@python.org
Subject: Re: RE: Which more Pythonic - self.__class__ or type(self)?

On 04/03/2023 17:38, avi.e.gr...@gmail.com wrote:
> 
> Of course each language has commonly used idioms 
> 

That's the point, the correct term is probably "idiomatic"
rather than "pythonic" but it is a defacto standard that
idiomatic Python has become known as Pythonic. I don't
think that's a problem. And at least we aren't in the C++
situation where almost everything that was idiomatic up
until 1999 is now deemed an anti-pattern and they have
standard library modules to try and guide you to use the
"correct" idioms!

But being Pythonic is still a much more loose term and
the community less stressed about it than their C++
cousins where it has almost reached a religious fervour!

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos



-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Which more Pythonic - self.__class__ or type(self)?

[avi.e.gross]

Great idea, DN!

A whole series of books can be written such as:

- Python for virgin dummies who never programmed before.
- Python for former BASIC programmers
- Python for former LISP programmers with a forked tongue
- Python for former Ada Programmers
- Python for ...
- Python for those who find a dozen former languages are simply not enough.
- Python for people who really want to mainly  use the modules like pandas
or sklearn ...
- Pythonic upgrades to the methods used in former inferior languages ...
- How to speak with a Pythonese accent and lose you old accent based on your
former native language(s).

I am sure some books along these lines have already been written!

Who wants to collaborate?

-Original Message-
From: Python-list  On
Behalf Of dn via Python-list
Sent: Saturday, March 4, 2023 1:26 PM
To: python-list@python.org
Subject: Re: Which more Pythonic - self.__class__ or type(self)?

On 04/03/2023 20.47, Peter J. Holzer wrote:
> On 2023-03-03 13:51:11 -0500, avi.e.gr...@gmail.com wrote:

...
> No. Even before Python existed there was the adage "a real programmer
> can write FORTRAN in any language", indicating that idiomatic usage of a
> language is not governed by syntax and library alone, but there is a
> cultural element: People writing code in a specific language also read
> code by other people in that language, so they start imitating each
> other, just like speakers of natural languages imitate each other.
> Someone coming from another language will often write code which is
> correct but un-idiomatic, and you can often guess which language they
> come from (they are "writing FORTRAN in Python"). Also quite similar to
> natural languages where you can guess the native language of an L2
> speaker by their accent and phrasing.

With ph agree I do...

or do you want that in a DO-loop with a FORMAT?

-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Which more Pythonic - self.__class__ or type(self)?

[avi.e.gross]

I don't know, Thomas. For some simple programs, there is some evolutionary
benefit by starting with what you know and gradually growing from there. He
first time you need to do something that seems to need a loop in python,
there are loops to choose from. 

But as noted in a recent discussion, things are NOT NECESSARILY the same
even with something that simple. Did your previous languages retain
something like the loop variable outside the loop? What are your new scoping
rules? Do you really want to keep using global variables, and so on.

And, another biggie is people who just don't seem aware of what comes easily
in the new language. I have seen people from primitive environments set up
programs with multiple arrays they process the hard way instead of using
some forms of structure like a named tuple or class arranged in lists or use
a multidimensional numpy/pandas kind of data structure.

So ignoring the word pythonic as too specific, is there a way to say that
something is the way your current language supports more naturally? 

Yes, there are sort of fingerprints in how people write. Take the python
concept of truthy and how some people will still typically add a test for
equality with True. That may not be pythonic to some but is there much harm
in being explicit so anyone reading the code better understands what it doe?

I have to wonder what others make of my code as my style is likely to be
considered closer to "eclectic" as I came to python late and found an
expanding language with way too many ways to do anything and can choose. But
I claim that too is pythonic!

-Original Message-
From: Python-list  On
Behalf Of Thomas Passin
Sent: Saturday, March 4, 2023 1:09 PM
To: python-list@python.org
Subject: Re: Which more Pythonic - self.__class__ or type(self)?

On 3/4/2023 2:47 AM, Peter J. Holzer wrote:
> Even before Python existed there was the adage "a real programmer
> can write FORTRAN in any language", indicating that idiomatic usage of a
> language is not governed by syntax and library alone, but there is a
> cultural element: People writing code in a specific language also read
> code by other people in that language, so they start imitating each
> other, just like speakers of natural languages imitate each other.
> Someone coming from another language will often write code which is
> correct but un-idiomatic, and you can often guess which language they
> come from (they are "writing FORTRAN in Python").

What Peter didn't say is that this statement is usually used in a 
disparaging sense.  It tends to imply that a person can write (or is 
writing) awkward or inappropriate code anywhere.

-- 
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Which more Pythonic - self.__class__ or type(self)?

[Peter J. Holzer]

On 2023-03-04 12:38:22 -0500, avi.e.gr...@gmail.com wrote:
> Of course each language has commonly used idioms as C with pointer
> arithmetic and code like *p++=*q++ but my point is that although I live near
> a  seaway and from where C originated, I am not aware of words like "c-way"
> or "scenic" as compared to the way people keep saying "pythonic".

Oh, you're talking about the term, not the concept? 

You may have something there. I remember lots of discussions about
"idiomatic C" or "idiomatic Perl", but not about "C-nic" (nice pun, btw)
or "Perlish" code. The Python community may be unique in having invented
an adjective for that.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: RE: Which more Pythonic - self.__class__ or type(self)?

[Alan Gauld]

On 04/03/2023 17:38, avi.e.gr...@gmail.com wrote:
> 
> Of course each language has commonly used idioms 
> 

That's the point, the correct term is probably "idiomatic"
rather than "pythonic" but it is a defacto standard that
idiomatic Python has become known as Pythonic. I don't
think that's a problem. And at least we aren't in the C++
situation where almost everything that was idiomatic up
until 1999 is now deemed an anti-pattern and they have
standard library modules to try and guide you to use the
"correct" idioms!

But being Pythonic is still a much more loose term and
the community less stressed about it than their C++
cousins where it has almost reached a religious fervour!

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Which more Pythonic - self.__class__ or type(self)?

[dn via Python-list]

On 04/03/2023 20.47, Peter J. Holzer wrote:

On 2023-03-03 13:51:11 -0500, avi.e.gr...@gmail.com wrote:


...

No. Even before Python existed there was the adage "a real programmer
can write FORTRAN in any language", indicating that idiomatic usage of a
language is not governed by syntax and library alone, but there is a
cultural element: People writing code in a specific language also read
code by other people in that language, so they start imitating each
other, just like speakers of natural languages imitate each other.
Someone coming from another language will often write code which is
correct but un-idiomatic, and you can often guess which language they
come from (they are "writing FORTRAN in Python"). Also quite similar to
natural languages where you can guess the native language of an L2
speaker by their accent and phrasing.


With ph agree I do...

or do you want that in a DO-loop with a FORMAT?

--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: Which more Pythonic - self.__class__ or type(self)?

[Thomas Passin]

On 3/4/2023 2:47 AM, Peter J. Holzer wrote:

Even before Python existed there was the adage "a real programmer
can write FORTRAN in any language", indicating that idiomatic usage of a
language is not governed by syntax and library alone, but there is a
cultural element: People writing code in a specific language also read
code by other people in that language, so they start imitating each
other, just like speakers of natural languages imitate each other.
Someone coming from another language will often write code which is
correct but un-idiomatic, and you can often guess which language they
come from (they are "writing FORTRAN in Python").


What Peter didn't say is that this statement is usually used in a 
disparaging sense.  It tends to imply that a person can write (or is 
writing) awkward or inappropriate code anywhere.


--
https://mail.python.org/mailman/listinfo/python-list

RE: Which more Pythonic - self.__class__ or type(self)?

[avi.e.gross]

Peter,

Of course each language has commonly used idioms as C with pointer
arithmetic and code like *p++=*q++ but my point is that although I live near
a  seaway and from where C originated, I am not aware of words like "c-way"
or "scenic" as compared to the way people keep saying "pythonic".

Yes, languages develop idioms and frankly, many are replaced with time. And,
yes, I am sure I can write FORTRAN style  in any language as I used to teach
it, but WATFOR?

If the question is to show a dozen solutions for a problem written in VALID
python and ask a panel of seasoned python programmers which they would
prefer, then sometimes there is a more pythonic solution by that definition.
Give the same test to newbies who each came from a different language
background and are just getting started, and I am not sure I care how they
vote!

I suggest that given a dozen such choices, several may be reasonable choices
and in some cases, I suggest the non-pythonic choice is the right one such
as when you expect someone to port your code to other languages and you need
to keep it simple.

I am simply saying that for ME, some questions are not as simple as others.
I am more interested in whether others can read and understand my code, and
it runs without problems, and maybe even is slightly efficient, than whether
someone deems it pythonic.


-Original Message-
From: Python-list  On
Behalf Of Peter J. Holzer
Sent: Saturday, March 4, 2023 2:48 AM
To: python-list@python.org
Subject: Re: Which more Pythonic - self.__class__ or type(self)?

On 2023-03-03 13:51:11 -0500, avi.e.gr...@gmail.com wrote:
> I do not buy into any concept about something being pythonic or not.
> 
> Python has grown too vast and innovated quite a  bit, but also borrowed
from
> others and vice versa.
> 
> There generally is no universally pythonic way nor should there be. Is
there
> a C way

Oh, yes. Definitely.

> and then a C++ way and an R way or JavaScript

JavaScript has a quite distinctive style. C++ is a big language (maybe
too big for a single person to grok completely) so there might be
several "dialects". I haven't seen enough R code to form an opinion.

> or does only python a language with a philosophy of what is the
> pythonic way?

No. Even before Python existed there was the adage "a real programmer
can write FORTRAN in any language", indicating that idiomatic usage of a
language is not governed by syntax and library alone, but there is a
cultural element: People writing code in a specific language also read
code by other people in that language, so they start imitating each
other, just like speakers of natural languages imitate each other.
Someone coming from another language will often write code which is
correct but un-idiomatic, and you can often guess which language they
come from (they are "writing FORTRAN in Python"). Also quite similar to
natural languages where you can guess the native language of an L2
speaker by their accent and phrasing.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Which more Pythonic - self.__class__ or type(self)?

[Peter J. Holzer]

On 2023-03-03 13:51:11 -0500, avi.e.gr...@gmail.com wrote:
> I do not buy into any concept about something being pythonic or not.
> 
> Python has grown too vast and innovated quite a  bit, but also borrowed from
> others and vice versa.
> 
> There generally is no universally pythonic way nor should there be. Is there
> a C way

Oh, yes. Definitely.

> and then a C++ way and an R way or JavaScript

JavaScript has a quite distinctive style. C++ is a big language (maybe
too big for a single person to grok completely) so there might be
several "dialects". I haven't seen enough R code to form an opinion.

> or does only python a language with a philosophy of what is the
> pythonic way?

No. Even before Python existed there was the adage "a real programmer
can write FORTRAN in any language", indicating that idiomatic usage of a
language is not governed by syntax and library alone, but there is a
cultural element: People writing code in a specific language also read
code by other people in that language, so they start imitating each
other, just like speakers of natural languages imitate each other.
Someone coming from another language will often write code which is
correct but un-idiomatic, and you can often guess which language they
come from (they are "writing FORTRAN in Python"). Also quite similar to
natural languages where you can guess the native language of an L2
speaker by their accent and phrasing.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Which more Pythonic - self.__class__ or type(self)?

[Greg Ewing via Python-list]

On 4/03/23 7:51 am, avi.e.gr...@gmail.com wrote:


I leave you with the question of the day. Was Voldemort pythonic?


Well, he was fluent in Parseltongue, which is not a good sign.

I hope not, otherwise we'll have to rename Python to "The Language
That Shall Not Be Named" and watch out for horcruxes during code
reviews.

I'll note that he was fluent in Parseltongue, which is not a good
sign.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

RE: Which more Pythonic - self.__class__ or type(self)?

[avi.e.gross]

Alan,

I do not buy into any concept about something being pythonic or not.

Python has grown too vast and innovated quite a  bit, but also borrowed from
others and vice versa.

There generally is no universally pythonic way nor should there be. Is there
a C way and then a C++ way and an R way or JavaScript or does only python a
language with a philosophy of what is the pythonic way?

My vague impression was that the pythonic way was somewhat of a contrast to
the way a programmer did it before coming to python. So some would argue
that although python allows loops, that some things are more naturally done
in python using a list comprehension.

Really?

I suggest that NOW for some people, it is way more natural to import modules
like numpy and pandas and use their tools using a more vectorized approach.
Is that the new pythonic in some situations?

I can also argue that if you were a contestant on Jeopardy and were in a
category for computer languages and were shown some computer code  and asked
to name that language in 4 lines, then the most pythonic would not be one
saying type(var) but the one showing a dunder method! I mean what makes some
languages special is often the underlying details! On the surface, many look
fairly similar.

Some problems not only can be solved many ways in python, but by using
combinations of different programming paradigms. It can be argued by some
that the pythonic way is to use some forms of object-oriented programming
and by others pushing for a more functional approach. Some seem to continue
pushing for efficiency and others relish at using up CPU cycles and prefer
other considerations such as what is easier for the programmer or that is
more self-documenting.

My answer remains, in this case, like yours. The dunder methods are
generally meant to be implementation details mostly visible when creating
new classes or perhaps adjusting an object. They largely implement otherwise
invisible protocols by providing the hooks the protocols invoke, and do it
in a somewhat reserved name space. If the user is writing code that just
uses existing classes, generally no dunderheads should be seen. I think
using them is not only not pythonic, but risks breaking code if some changes
to python are made.  As one example, the iteration protocol now has new
dunder methods added to be used for asynchronous and calling the __iter__()
type methods will not work well and you now need to know to call the new
ones. Or, don't call them at all and use the regular functions provided.

Some things may be clearly more in the spirit of the language and sometimes
who cares. Consider the debate that since python allows you to fail and
catch an exception, why bother using if statements such as checking for
no-zero before dividing. I never understood that. Plan A works. Now you can
also chose plan B. They both work. But has anyone asked some dumb questions
about the data the code is working on? What if you have data full of zeroes
or NA or Inf or other things make a division problematic. What is the cost
of testing for something or a group of things every time versus setting up a
try/catch every time? What about lots of nesting of these things. What can
humans read better or make adjustments to?

In my mind, if the bad thing you want to avoid is rare and the testing is
costly, perhaps the exception method is best. I mean if you are working with
large numbers where primes are not common, then having to test if it is a
prime can be costly while catching a failure may be less so.

But consider how some people act as if pythonic means you should not care
about efficiency! LOL!

I leave you with the question of the day. Was Voldemort pythonic?

Avi


-Original Message-
From: Python-list  On
Behalf Of Alan Gauld
Sent: Friday, March 3, 2023 4:43 AM
To: python-list@python.org
Subject: Re: Which more Pythonic - self.__class__ or type(self)?

On 02/03/2023 20:54, Ian Pilcher wrote:
> Seems like an FAQ, and I've found a few things on StackOverflow that
> discuss the technical differences in edge cases, but I haven't found
> anything that talks about which form is considered to be more Pythonic
> in those situations where there's no functional difference.

I think avoiding dunder methods is generally considered more Pythonic.

But in this specific case using isinstance() is almost always
the better option. Testing for a specific class is likely to break
down in the face of subclasses. And in Python testing for static types
should rarely be necessary since Python uses duck typing
and limiting things to a hard type seriously restricts your code.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


-- 
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Which more Pythonic - self.__class__ or type(self)?

[Ethan Furman]

On 3/3/23 03:32, Chris Angelico wrote:
> On Fri, 3 Mar 2023 at 20:44, Alan Gauld wrote:
>> On 02/03/2023 20:54, Ian Pilcher wrote:

>>> Seems like an FAQ, and I've found a few things on StackOverflow that
>>> discuss the technical differences in edge cases, but I haven't found
>>> anything that talks about which form is considered to be more Pythonic
>>> in those situations where there's no functional difference.
>>
>> I think avoiding dunder methods is generally considered more Pythonic.

Outside of writing dunder methods, I tend to agree.

>> But in this specific case using isinstance() is almost always
>> the better option.

True.  IIRC, the only time I haven't used `isinstance` is in `Enum`, where a particular object has to be exactly a tuple 
(not a namedtuple, for example) to work correctly.


> Using isinstance is very different from querying the type of an object
> though. They're used for different purposes. And obj.__class__ and
> type(obj) are different too, which is why the OP specifically narrowed
> this down to the situations where you know they're the same.

When writing classes and subclasses, I use `obj.__class__`, `isinstance` otherwise, and rarely `type(obj)` (and then 
mostly with `tuple`s, as they're special).


~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

Re: Which more Pythonic - self.__class__ or type(self)?

[Chris Angelico]

On Fri, 3 Mar 2023 at 20:44, Alan Gauld  wrote:
>
> On 02/03/2023 20:54, Ian Pilcher wrote:
> > Seems like an FAQ, and I've found a few things on StackOverflow that
> > discuss the technical differences in edge cases, but I haven't found
> > anything that talks about which form is considered to be more Pythonic
> > in those situations where there's no functional difference.
>
> I think avoiding dunder methods is generally considered more Pythonic.
>
> But in this specific case using isinstance() is almost always
> the better option. Testing for a specific class is likely to break
> down in the face of subclasses. And in Python testing for static types
> should rarely be necessary since Python uses duck typing
> and limiting things to a hard type seriously restricts your code.
>

Using isinstance is very different from querying the type of an object
though. They're used for different purposes. And obj.__class__ and
type(obj) are different too, which is why the OP specifically narrowed
this down to the situations where you know they're the same.

Personally, I'd probably use type(obj) if the distinction doesn't
matter, but that's nothing more than personal preference.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Which more Pythonic - self.__class__ or type(self)?

[Alan Gauld]

On 02/03/2023 20:54, Ian Pilcher wrote:
> Seems like an FAQ, and I've found a few things on StackOverflow that
> discuss the technical differences in edge cases, but I haven't found
> anything that talks about which form is considered to be more Pythonic
> in those situations where there's no functional difference.

I think avoiding dunder methods is generally considered more Pythonic.

But in this specific case using isinstance() is almost always
the better option. Testing for a specific class is likely to break
down in the face of subclasses. And in Python testing for static types
should rarely be necessary since Python uses duck typing
and limiting things to a hard type seriously restricts your code.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Which more Pythonic - self.__class__ or type(self)?

[avi.e.gross]

My understanding is that python created functions like type() and len() as a
general purpose way to get information and ALSO set up a protocol that
classes can follow by creating dunder methods. I think the most pythonic
things is to avoid directly calling the dunder methods with a few exceptions
that mainly happen when you are building or extending classes. I mean some
dunder methods are then called directly to avoid getting into infinite loops
that would be triggered.

And note in many cases, the protocol is more complex. Is a length built-in?
If not, can the object be iterated and you count the results? Calling the
function len() may get you more info as it can leverage such things. And it
means you can sometimes leave out some methods and your code still works.

Be warned that type() is a very special function in python and when called
with more arguments, does many relatively beautiful but unrelated things. It
has a special role in the class or type hierarchy. But used with a single
argument, it harmlessly return a result you want.


-Original Message-
From: Python-list  On
Behalf Of Thomas Passin
Sent: Thursday, March 2, 2023 6:43 PM
To: python-list@python.org
Subject: Re: Which more Pythonic - self.__class__ or type(self)?

On 3/2/2023 5:53 PM, Greg Ewing via Python-list wrote:
> On 3/03/23 9:54 am, Ian Pilcher wrote:
>> I haven't found
>> anything that talks about which form is considered to be more Pythonic
>> in those situations where there's no functional difference.
> 
> In such cases I'd probably go for type(x), because it looks less
> ugly.
> 
> x.__class__ *might* be slightly more efficient, as it avoids a
> global lookup and a function call. But as always, measurement
> would be required to be sure.

Except that we don't know if "efficiency" - whatever that might mean 
here - matters at all.

-- 
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Which more Pythonic - self.__class__ or type(self)?

[Thomas Passin]

On 3/2/2023 5:53 PM, Greg Ewing via Python-list wrote:

On 3/03/23 9:54 am, Ian Pilcher wrote:

I haven't found
anything that talks about which form is considered to be more Pythonic
in those situations where there's no functional difference.


In such cases I'd probably go for type(x), because it looks less
ugly.

x.__class__ *might* be slightly more efficient, as it avoids a
global lookup and a function call. But as always, measurement
would be required to be sure.


Except that we don't know if "efficiency" - whatever that might mean 
here - matters at all.


--
https://mail.python.org/mailman/listinfo/python-list

Re: Which more Pythonic - self.__class__ or type(self)?

[Greg Ewing via Python-list]

On 3/03/23 9:54 am, Ian Pilcher wrote:

I haven't found
anything that talks about which form is considered to be more Pythonic
in those situations where there's no functional difference.


In such cases I'd probably go for type(x), because it looks less
ugly.

x.__class__ *might* be slightly more efficient, as it avoids a
global lookup and a function call. But as always, measurement
would be required to be sure.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Which more Pythonic - self.__class__ or type(self)?

[Thomas Passin]

On 3/2/2023 3:54 PM, Ian Pilcher wrote:

Seems like an FAQ, and I've found a few things on StackOverflow that
discuss the technical differences in edge cases, but I haven't found
anything that talks about which form is considered to be more Pythonic
in those situations where there's no functional difference.

Is there any consensus?


For what purpose do you want to get it?

--
https://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[Marko Rauhamaa]

Chris Angelico :

> On Thu, Nov 24, 2016 at 10:14 PM, Marko Rauhamaa  wrote:
>> When you use threads, you call read(2) in the blocking mode. Then the
>> read(2) operation will block "for ever." There's no clean way to
>> cancel the system call.
>
> Signals will usually interrupt system calls, causing them to return
> EINTR. There are exceptions (the aforementioned uninterruptible calls,
> but they're not available in nonblocking form, so they're the same for
> threads and coroutines), but the bulk of system calls will halt
> cleanly on receipt of a signal. And yes, you CAN send signals to
> specific threads; there are limitations, but for a language like
> Python, there's no difficulty in having a single disposition for (say)
> SIGINT, and then using thread signalling to figure out which thread
> should have KeyboardInterrupt raised in it.

Yes, pthread_kill(3) has been made available in Python-3.3, I'm
noticing.

Also:

   Changed in version 3.5: Python now retries system calls when a
   syscall is interrupted by a signal, except if the signal handler
   raises an exception (see PEP 475 for the rationale), instead of
   raising InterruptedError.

   https://docs.python.org/3/library/exceptions.html#Interrupt
   edError>


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[Chris Angelico]

On Thu, Nov 24, 2016 at 10:14 PM, Marko Rauhamaa  wrote:
> When you use threads, you call read(2) in the blocking mode. Then the
> read(2) operation will block "for ever." There's no clean way to cancel
> the system call.

Signals will usually interrupt system calls, causing them to return
EINTR. There are exceptions (the aforementioned uninterruptible calls,
but they're not available in nonblocking form, so they're the same for
threads and coroutines), but the bulk of system calls will halt
cleanly on receipt of a signal. And yes, you CAN send signals to
specific threads; there are limitations, but for a language like
Python, there's no difficulty in having a single disposition for (say)
SIGINT, and then using thread signalling to figure out which thread
should have KeyboardInterrupt raised in it.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[Marko Rauhamaa]

Chris Angelico :

> On Thu, Nov 24, 2016 at 9:59 PM, Marko Rauhamaa  wrote:
>> Chris Angelico :
>>> A coroutine can be abandoned at an await point, but the
>>> currently-executed call is still going to complete (usually);
>>
>> I don't quite understand. Say you are awaiting on receiving bytes from a
>> socket. That means there has been a nonblocking call to read(2),
>> recvmsg(2) or equivalent that has returned EAGAIN. If you now abandon
>> the coroutine, there is no resumption of the system call but the
>> coroutine can finish instantaneously.
>
> Is the read(2) still going to consume data from the pipe/socket?

Only if the kernel has already buffered data it has received previously.

If there isn't yet any data available in the kernel, read(2) returns
with errno=EAGAIN, and the control is returned to the main loop. The
main loop then goes to sleep in epoll_wait(2) or equivalent.

> If so, the operation is still going to continue, whether you use
> coroutines or threads. If not, it would have been cancelled whether
> you use coroutines or threads.

When you use threads, you call read(2) in the blocking mode. Then the
read(2) operation will block "for ever." There's no clean way to cancel
the system call.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[Chris Angelico]

On Thu, Nov 24, 2016 at 9:59 PM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> On Thu, Nov 24, 2016 at 7:39 PM, Marko Rauhamaa  wrote:
>>>  * Coroutines can be killed, threads cannot.
>>
>> Not strictly true. A coroutine can be abandoned at an await point, but
>> the currently-executed call is still going to complete (usually);
>
> I don't quite understand. Say you are awaiting on receiving bytes from a
> socket. That means there has been a nonblocking call to read(2),
> recvmsg(2) or equivalent that has returned EAGAIN. If you now abandon
> the coroutine, there is no resumption of the system call but the
> coroutine can finish instantaneously.

Is the read(2) still going to consume data from the pipe/socket? If
so, the operation is still going to continue, whether you use
coroutines or threads. If not, it would have been cancelled whether
you use coroutines or threads.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[Marko Rauhamaa]

Chris Angelico :

> On Thu, Nov 24, 2016 at 7:39 PM, Marko Rauhamaa  wrote:
>>  * Coroutines can be killed, threads cannot.
>
> Not strictly true. A coroutine can be abandoned at an await point, but
> the currently-executed call is still going to complete (usually);

I don't quite understand. Say you are awaiting on receiving bytes from a
socket. That means there has been a nonblocking call to read(2),
recvmsg(2) or equivalent that has returned EAGAIN. If you now abandon
the coroutine, there is no resumption of the system call but the
coroutine can finish instantaneously.

> a thread can be killed, but certain non-interruptible operations will
> delay the termination until after that operation. So either way, the
> operation still runs to completion.

There *could* be such noninterruptible operations (which would be a big
shame). They would have to be implemented with the help of a separate
thread. The surface coroutine can never sit in a blocking operation.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[Chris Angelico]

On Thu, Nov 24, 2016 at 7:39 PM, Marko Rauhamaa  wrote:
>  * Coroutines can be killed, threads cannot.
>

Not strictly true. A coroutine can be abandoned at an await point, but
the currently-executed call is still going to complete (usually); a
thread can be killed, but certain non-interruptible operations will
delay the termination until after that operation. So either way, the
operation still runs to completion.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[Marko Rauhamaa]

"Frank Millman" :

> "Steven D'Aprano"  wrote in message
> news:58368358$0$1513$c3e8da3$54964...@news.astraweb.com...

>> I'm a newbie to asyncio, but if I were doing this using threads, [...]
>
> To me, the beauty of asyncio (or I suppose async in general) is that I
> don't have to worry about any of what you describe above.

The programming model for threads and asyncio coroutines is identical.
The differences for the programmer are smallish details:

 * In asyncio, all functions that can potentially block must be tagged
   with "async" and all calls to such functions must be tagged with
   "await".

 * Not all blocking functions have an equivalent coroutine. All
   functions are readily available to threads.

 * Coroutines can be killed, threads cannot.

 * Coroutines can be multiplexed, threads cannot.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[Frank Millman]

"Steven D'Aprano"  wrote in message 
news:58368358$0$1513$c3e8da3$54964...@news.astraweb.com...



On Thursday 24 November 2016 15:55, Frank Millman wrote:

> "Steve D'Aprano"  wrote in message
> news:583653bb$0$1603$c3e8da3$54964...@news.astraweb.com...
>
>> Even if the computation of the memoised value is done asynchronously, 
>> you
>> can easily split the computation off to a separate method (as you 
>> already

>> talked about doing!) and make getval() block until it returns.
>
> Surely that defeats the whole purpose of asyncio. Anything that blocks 
> holds
> up the entire process. I strenuously try to avoid blocking in any shape 
> or

> form.

Perhaps I'm not understanding your task correctly, but surely you have to 
wait
for the computation to occur at some point? Even if that's just you 
hitting

Refresh waiting for the value of the column to eventually show up.

I'm a newbie to asyncio, but if I were doing this using threads, I'd have
getval() set the self._cached_value to "pending..." (say), start the
computation thread running, and then return. The computation thread will
eventually write the true value to _cached_value, and in the meantime the
getval() method (and hence __str__ will happily use the "pending..." 
value. The

only tricky part is to make sure you only start the thread once.



I am not really qualified to answer this - I *use* asyncio, but I don’t 
really understand what goes on under the covers.


With that caveat, here goes.

To me, the beauty of asyncio (or I suppose async in general) is that I don't 
have to worry about any of what you describe above.


I just have to 'await' whatever I am waiting for. There could be a long 
chain of function calls (which I suppose I should call coroutine calls) but 
at some point one of them is actually going to wait for some I/O, and yield 
control back to the event loop.


At that point, the entire chain is suspended, pending return of the value. 
Once received, control passes back down the chain to the originating 
coroutine, which can then carry on exactly where it left off.


Frank


--
https://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[Steven D'Aprano]

On Thursday 24 November 2016 15:55, Frank Millman wrote:

> "Steve D'Aprano"  wrote in message
> news:583653bb$0$1603$c3e8da3$54964...@news.astraweb.com...
> 
>> Even if the computation of the memoised value is done asynchronously, you
>> can easily split the computation off to a separate method (as you already
>> talked about doing!) and make getval() block until it returns.
> 
> Surely that defeats the whole purpose of asyncio. Anything that blocks holds
> up the entire process. I strenuously try to avoid blocking in any shape or
> form.

Perhaps I'm not understanding your task correctly, but surely you have to wait 
for the computation to occur at some point? Even if that's just you hitting 
Refresh waiting for the value of the column to eventually show up.

I'm a newbie to asyncio, but if I were doing this using threads, I'd have 
getval() set the self._cached_value to "pending..." (say), start the 
computation thread running, and then return. The computation thread will 
eventually write the true value to _cached_value, and in the meantime the 
getval() method (and hence __str__ will happily use the "pending..." value. The 
only tricky part is to make sure you only start the thread once.



-- 
Steven
299792.458 km/s — not just a good idea, it’s the law!

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[Frank Millman]

"Steve D'Aprano"  wrote in message 
news:583653bb$0$1603$c3e8da3$54964...@news.astraweb.com...



Even if the computation of the memoised value is done asynchronously, you
can easily split the computation off to a separate method (as you already
talked about doing!) and make getval() block until it returns.


Surely that defeats the whole purpose of asyncio. Anything that blocks holds 
up the entire process. I strenuously try to avoid blocking in any shape or 
form.



> I can say 'print(await obj.__str__())', and it works, but I lose the
> ability to include it in a larger print statement.


Any time you find yourself directly calling dunder methods, you're 
probably

doing it wrong. This is one of those times.


Yes. Having slept on it, I realise I over-reacted.

The __str__() method is convenient for me, but I only use it for testing and 
debugging to see what is going on. It is not part of my app per se.


I now realise that the solution is -

1. Keep the __str__ method, but replace calls to getval() with a direct 
reference to the underlying attribute. It means that any 'computable' 
objects that have not already been computed will return None, but that is ok 
for my purposes.


2. Write a separate method, retaining the calls to getval(), to be called 
independently using 'await' if I ever need to see the full result after 
computation.


Frank


--
https://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[Steve D'Aprano]

On Wed, 23 Nov 2016 10:11 pm, Frank Millman wrote:

> Gah! The law of unintended consequences strikes again!
> 
> As I mentioned, the class in question represents a database column. 

Yes, you mentioned that.

> A 
> separate class represents a database row. I have a __str__() method on the
> 'row' class that prints a nicely formatted representation of the object
> with all of its column objects and their values.

You didn't mention that, but it shouldn't matter.

 
> With the above changes, I had to turn getval() into a coroutine.

You what?

I'm gobsmacked by this assertion. Nobody else seems to have commented on
this, so perhaps I'm missing something, but this strikes me as astonishing.
Nothing in your earlier post even hinted that you were using coroutines or
async, and as sure as the day is long memoisation doesn't force you to
start.

Even if the computation of the memoised value is done asynchronously, you
can easily split the computation off to a separate method (as you already
talked about doing!) and make getval() block until it returns.


[...]
> I can say 'print(await obj.__str__())', and it works, but I lose the
> ability to include it in a larger print statement.

Any time you find yourself directly calling dunder methods, you're probably
doing it wrong. This is one of those times.




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[Steve D'Aprano]

On Wed, 23 Nov 2016 11:27 pm, Frank Millman wrote:

> It is a bit like quantum theory. I have no way of telling whether the
> computation has been carried out without looking at it, but the act of
> looking at it triggers the computation. I can tell, of course, by looking
> at the underlying attribute, but not by using the public methods.

Then give it a public method (or better, a property) to tell.


@property
def needs_computation(self):
return not hasattr(self, '_cached_value')




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[Gregory Ewing]

Frank Millman wrote:
For the time being I will use 'print(await obj.__str__())', as this is a 
good compromise.


It seems more like a very *bad* compromise to me.

I can't see how this gains you anything over just doing
print(await obj.getvalue()), and you lose the ability to
do anything that calls __str__ implicitly.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[Tim Chase]

On 2016-11-23 22:15, Steve D'Aprano wrote:
> On Wed, 23 Nov 2016 08:10 pm, Frank Millman wrote:
> > The class has a getval() method to return the current value.
> > 
> > Usually the value is stored in the instance, and can be returned
> > immediately, but sometimes it has to be computed, incurring
> > further database lookups.  
> 
> This is called memoisation, or caching, and is a perfectly standard
> programming technique. It's not without its traps though: there's a
> famous quote that says there are only two hard problems in
> computing, naming things and cache invalidation.

Fortunately, you can offload some odd edge-cases to the standard
library, no?

  from functools import lru_cache
  # ...
  @lru_cache(maxsize=1)
  def getval(...):
return long_computation()

It doesn't cache across multiple instances of the same class, but
does cache multiple calls to the same instance's function:

  >>> from functools import lru_cache
  >>> class Foo:
  ...   def __init__(self, name):
  ... self.name = name
  ...   @lru_cache(maxsize=1)
  ...   def getval(self):
  ... print("Long process")
  ... return self.name
  ... 
  >>> f1 = Foo("f1")
  >>> f2 = Foo("f2")
  >>> f1.getval()
  Long process
  'f1'
  >>> f1.getval()
  'f1'
  >>> f2.getval()
  Long process
  'f2'
  >>> f2.getval()
  'f2'

-tkc





-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[Frank Millman]

"Chris Angelico"  wrote in message 
news:CAPTjJmqGEwHPVyrR+Ti9bV=S5MsLt3nquF4TvE=xpees188...@mail.gmail.com...


On Wed, Nov 23, 2016 at 11:27 PM, Frank Millman  
wrote:

>
> @Chris
>>
>> This strongly suggests that str(x) is the wrong way to get the
>> information. You shouldn't be doing database requests inside __str__
>> or __repr__.
>
>
> I guess you are right, but still it is a pity. __str__ has been working 
> for
> me beautifully for a long time now. The only change is that, previously, 
> all
> the values had been read in or computed before calling __str__(), now I 
> am

> delaying the computation until requested.
>
> It is a bit like quantum theory. I have no way of telling whether the
> computation has been carried out without looking at it, but the act of
> looking at it triggers the computation. I can tell, of course, by 
> looking at

> the underlying attribute, but not by using the public methods.

That makes sense. What you could do is have __repr__ do something like 
this:


def __repr__(self):
if self.has_data:
return "<%s: %r>" % (self.col_name, self.data)
return "<%s:  >" % self.col_name

I'm not sure that that would be appropriate for __str__, though; maybe
it could return the string of data if it exists, otherwise it could
fall back on __repr__?



Thanks for the ideas. I will have to experiment a bit.

There is a certain irony in all this. When I started using asyncio, I just 
converted the networking functions into coroutines and waited for it to 
stabilise. Then I wanted to extend it, and found that coroutines can only be 
called by other coroutines, and I had some long chains of function calls, so 
I backed off. Then I eventually bit the bullet, converted everything in the 
chain to a coroutine, and let it settle down again. I have done this a few 
times, and each time I sensed an improvement in the way that my entire 
application was beginning to 'flow' in an async manner, which was good. 
However, I have managed to avoid turning getval() into a coroutine, until 
now. Now I am ready to embrace the change, but this time it is Python that 
is tripping me up.


For the time being I will use 'print(await obj.__str__())', as this is a 
good compromise. Of course I don't have to use __str__, I can call it 
anything, so I will probably create a helper function to make it easy to 
call on any object.


One of the things that was deterring me from turning getval() into a 
coroutine was the inability to use a coroutine inside a comprehension. I see 
that Python 3.6 now allows this, so I must download a beta version and try 
it out.


Frank


--
https://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[Chris Angelico]

On Wed, Nov 23, 2016 at 11:27 PM, Frank Millman  wrote:
>
> @Chris
>>
>> This strongly suggests that str(x) is the wrong way to get the
>> information. You shouldn't be doing database requests inside __str__
>> or __repr__.
>
>
> I guess you are right, but still it is a pity. __str__ has been working for
> me beautifully for a long time now. The only change is that, previously, all
> the values had been read in or computed before calling __str__(), now I am
> delaying the computation until requested.
>
> It is a bit like quantum theory. I have no way of telling whether the
> computation has been carried out without looking at it, but the act of
> looking at it triggers the computation. I can tell, of course, by looking at
> the underlying attribute, but not by using the public methods.

That makes sense. What you could do is have __repr__ do something like this:

def __repr__(self):
if self.has_data:
return "<%s: %r>" % (self.col_name, self.data)
return "<%s:  >" % self.col_name

I'm not sure that that would be appropriate for __str__, though; maybe
it could return the string of data if it exists, otherwise it could
fall back on __repr__?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[Frank Millman]

"Frank Millman"  wrote in message news:o13meh$p2g$1...@blaine.gmane.org...


3. When instantiating an object, check if it would need computation -
if computation_required:
self.getval = self._getval_with_comp
else:
self.getval = self._getval

4. In _getval_with_comp, perform the computation, then add the following -
   self.getval = self._getval
return self._getval()

What is the verdict? -1, 0, or +1?



Thanks for the responses. I will reply to them all here -

@Peter

You can also have the method replace itself ...


I like it. Thanks for the suggestion.

@Steve
So this check only happens once, on instantiation? And you're sure that 
once

the instance is created, there will never be any circumstances where you
want to re-calculate the value?


Well, the process that I call 'computation' includes setting up some 
variables that will trigger a recalculation when certain values change.


Part of my motivation was to avoid all of this if the value is never 
accessed.



def __getval_with_comp(self):
value = ... # long computation
self._cached_value = value
self.getval = self._getval
# return value
return self._getval()
# why call the method when you already know the answer?

How are subclasses supposed to override getval?



Two questions there, but the answer is the same.

I don't want subclasses to override the computation part of the process. I 
just want then to 'massage' the result before returning it. Therefore the 
answer to the first question is, to force the subclass to return the result, 
if it has its own _getval(). The answer to the second question is that they 
override _getval(), and therefore they will be invoked when getval() is 
called, provided getval has been set to be equal to _getval.


Hope that makes sense.

@Chris

This strongly suggests that str(x) is the wrong way to get the
information. You shouldn't be doing database requests inside __str__
or __repr__.


I guess you are right, but still it is a pity. __str__ has been working for 
me beautifully for a long time now. The only change is that, previously, all 
the values had been read in or computed before calling __str__(), now I am 
delaying the computation until requested.


It is a bit like quantum theory. I have no way of telling whether the 
computation has been carried out without looking at it, but the act of 
looking at it triggers the computation. I can tell, of course, by looking at 
the underlying attribute, but not by using the public methods.


Frank


--
https://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[Peter Otten]

Frank Millman wrote:

> Hi all
> 
> Sometimes I write something that I think is quite clever, but later on I
> look at it and ask 'What was I thinking?'.
> 
> I have just come up with a 'clever' solution to a problem. Would this
> cause raised eyebrows if you were reviewing this?
> 
> I have a class that represents a single database column - there could be
> hundreds of instances at any time.
> 
> The class has a getval() method to return the current value.
> 
> Usually the value is stored in the instance, and can be returned
> immediately, but sometimes it has to be computed, incurring further
> database lookups.
> 
> In many cases the computed value is never actually requested, so I want to
> delay the computation until the first call to getval().
> 
> I could add an 'if computation_required: ' block to getval(), but I am
> trying to avoid that, partly because this would have to be checked for
> every call to getval() but would only used in a small number of cases, and
> partly because I have a few subclasses where getval() is over-ridden so I
> would have to add the extra code to every one (or call the superclass on
> every one).
> 
> This is what I have come up with.
> 
> 1. Rename all instances of 'getval()' to '_getval()'.
> 
> 2. Add a new method '_getval_with_comp()'.
> 
> 3. When instantiating an object, check if it would need computation -
> if computation_required:
> self.getval = self._getval_with_comp
> else:
> self.getval = self._getval

You can also have the method replace itself:

>>> class Foo:
... def get_val(self):
... print("computing...")
... val = self._val = 42
... self.get_val = self.get_cached_val
... return val
... def get_cached_val(self):
... return self._val
... 
>>> foo = Foo()
>>> foo.get_val()
computing...
42
>>> foo.get_val()
42

 
> 4. In _getval_with_comp, perform the computation, then add the following -
> self.getval = self._getval
> return self._getval()
> 
> What is the verdict? -1, 0, or +1?
> 
> Frank Millman


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[Chris Angelico]

On Wed, Nov 23, 2016 at 10:11 PM, Frank Millman  wrote:
> Gah! The law of unintended consequences strikes again!
>
> As I mentioned, the class in question represents a database column. A
> separate class represents a database row. I have a __str__() method on the
> 'row' class that prints a nicely formatted representation of the object with
> all of its column objects and their values.
>
> With the above changes, I had to turn getval() into a coroutine. My
> __str__() method uses getval() to obtain the values, so I had to prefix
> getval() with 'await', but then I get a syntax error on __str__(). I can add
> 'async' to remove the syntax error, but then print(obj) does not work -
> TypeError: __str__ returned non-string (type coroutine)
>
> I don't think there is an answer to this, but any suggestions will be
> appreciated.
>
> I can say 'print(await obj.__str__())', and it works, but I lose the ability
> to include it in a larger print statement.
>
> Ah well :-(

This strongly suggests that str(x) is the wrong way to get the
information. You shouldn't be doing database requests inside __str__
or __repr__.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[Steve D'Aprano]

On Wed, 23 Nov 2016 08:10 pm, Frank Millman wrote:

[...]
> The class has a getval() method to return the current value.
> 
> Usually the value is stored in the instance, and can be returned
> immediately, but sometimes it has to be computed, incurring further
> database lookups.

This is called memoisation, or caching, and is a perfectly standard
programming technique. It's not without its traps though: there's a famous
quote that says there are only two hard problems in computing, naming
things and cache invalidation. But putting that aside:


def getval(self):
sentinel = object()
value = getattr(self, '_cached_value', sentinel)
if value is sentinel:
# compute the value and store it
value = ...
self._cached_value = value
return value

To invalidate the cache and force a recalculation:

del self._cached_value


Now it's easy to override:

class Subclass(ParentClass):
def getval(self):
value = super(Subclass, self).getval()
return value + 1



> This is what I have come up with.
> 
> 1. Rename all instances of 'getval()' to '_getval()'.
> 
> 2. Add a new method '_getval_with_comp()'.
> 
> 3. When instantiating an object, check if it would need computation -
> if computation_required:
> self.getval = self._getval_with_comp
> else:
> self.getval = self._getval

So this check only happens once, on instantiation? And you're sure that once
the instance is created, there will never be any circumstances where you
want to re-calculate the value?



> 4. In _getval_with_comp, perform the computation, then add the following -
> self.getval = self._getval
> return self._getval()

So you have something like this?

def _getval(self):
return self._cached_value

def __getval_with_comp(self):
value = ... # long computation
self._cached_value = value
self.getval = self._getval
# return value
return self._getval()
# why call the method when you already know the answer?


How are subclasses supposed to override getval?




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[Frank Millman]

"Marko Rauhamaa"  wrote in message news:87inrer0dl@elektro.pacujo.net...

"Frank Millman" :


> 3. When instantiating an object, check if it would need computation -
>if computation_required:
>self.getval = self._getval_with_comp
>else:
>self.getval = self._getval
>
> 4. In _getval_with_comp, perform the computation, then add the 
> following -

>self.getval = self._getval
>return self._getval()
>
> What is the verdict? -1, 0, or +1?

Perfectly cromulent, run-of-the-mill Python code.



Gah! The law of unintended consequences strikes again!

As I mentioned, the class in question represents a database column. A 
separate class represents a database row. I have a __str__() method on the 
'row' class that prints a nicely formatted representation of the object with 
all of its column objects and their values.


With the above changes, I had to turn getval() into a coroutine. My 
__str__() method uses getval() to obtain the values, so I had to prefix 
getval() with 'await', but then I get a syntax error on __str__(). I can add 
'async' to remove the syntax error, but then print(obj) does not work - 
TypeError: __str__ returned non-string (type coroutine)


I don't think there is an answer to this, but any suggestions will be 
appreciated.


I can say 'print(await obj.__str__())', and it works, but I lose the ability 
to include it in a larger print statement.


Ah well :-(

Frank


--
https://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[Frank Millman]

"Marko Rauhamaa"  wrote in message news:87inrer0dl@elektro.pacujo.net...


"Frank Millman" :




> What is the verdict? -1, 0, or +1?

Perfectly cromulent, run-of-the-mill Python code.



A new word to add to my vocabulary - thanks :-)

Frank


--
https://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[Marko Rauhamaa]

"Frank Millman" :

> 3. When instantiating an object, check if it would need computation -
>if computation_required:
>self.getval = self._getval_with_comp
>else:
>self.getval = self._getval
>
> 4. In _getval_with_comp, perform the computation, then add the following -
>self.getval = self._getval
>return self._getval()
>
> What is the verdict? -1, 0, or +1?

Perfectly cromulent, run-of-the-mill Python code.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Creating A Pythonic API Binding

[Steven D'Aprano]

On Wednesday 08 June 2016 12:31, Lawrence D’Oliveiro wrote:

> The wrong way:
[...]

> The right way :

That's quite good.

A few minor issues:

I don't understand why you have a method that returns files called 
"get_children".

And I would expect that if you passed a relative file name to create_folder() 
it should create a folder relative to (1) the current working directory, if the 
Device has such a concept; (2) your home or user directory, if the Device has 
such a concept; or (3) relative to the photos directory. Not relative to the 
root of the Device, that is very surprising.

Also, it would be good if you could make dev a context manager, so that you 
don't have to manually close them:

with mtpy.get_raw_devices()[0].open() as dev:
p = dev.get_descendant_by_path("/DCIM/Camera")
p.get_children()
# dev is automatically closed

But other than that, it looks quite nice. Thank you for posting the link.



-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: to be pythonic: should caller or callee log?

[Gildor Oronar]

El 04/09/13 20:14, Xaxa Urtiz escribió:

and what about something like that :


class AbsctractAccount():
  def transaction(self, amount, target):
  logging.info(Start transaction of %s to %s % (amount, target))
  self.DoTransaction(amount,target)

  def DoTransaction(self,amount,target):
  pass # or raise notimplemented or do not implement this methods in 
the abstract class
  ...

class DebitAccount(AbstractAccount):
  def DoTransaction(self, amount, target):
  ...

class SomeOtherAccount(...)
  
like that you only have to write the logging function once.


Thanks for the hint! This also work well, and has the advantage of being 
specific to this function -- I did use decorator as Ethan suggested, 
which works for most of the case, but there is function (other than 
transaction) needs specialized logging because the function doesn't 
return anything but changes a class variable -- using a special 
decorator for just one function is over-generalizing, and your method 
kicks in.


--
https://mail.python.org/mailman/listinfo/python-list

Re: to be pythonic: should caller or callee log?

[Gildor Oronar]

El 04/09/13 10:26, Ethan Furman escribió:


I would say it is not really the caller's or the callee's job to do the
logging, even though it should be done.  What would be really handy is a
function that sat in between the caller and callee that logged for you
-- you know, a decorator:


Thanks a lot! My knowledge to decorator is so limited to @staticmethod 
that I don't know I can write my own decorator. This is a good lesson to 
learn.


Your example lead me to explore and find this article which addressed 
the case of using decorator to log:


http://simeonfranklin.com/blog/2012/jul/1/python-decorators-in-12-steps/
(To googler who find this post: search 'log' in the above article)
--
https://mail.python.org/mailman/listinfo/python-list

Re: to be pythonic: should caller or callee log?

[Gildor Oronar]

Thanks:

El 04/09/13 05:01, Terry Reedy escribió:


I would expect that every account class has a transaction method.
* If so, just call it, but
assertIsNot(DebitAccount.transaction, AbstractAccount.transaction)
for every subclass in your test suite.
* If not, perhaps you need an abstract subclass TransAccount. Then use
hasattr in production code and the isnot test in test code.


I would assume that you categorize this as a unit test problem, because 
you consider an Acount not implementing Transaction is a bug, right?


There are two occassions an account is intended not having Transaction 
function, both not test-related:


1. The acount doesn't offer this feature. e.g. Certificate of Deposit. 
This can be in TransAccount.


2. The 3rd-party account offer this feature but doesn't qualify the 
software's requirement, e.g. not returning the result in 3 seconds, and 
is avoided when planning the deal (I am writing an auto-trade software). 
This case you cannot categorize those who can into TransAccount, 
beacause 1) that naming imply other accounts don't do transaction but 
they do, just not good enough; 2) when other accounts becomes good 
enough, the change (to inheritance) is a bit too invasive.

--
https://mail.python.org/mailman/listinfo/python-list

Re: to be pythonic: should caller or callee log?

[Xaxa Urtiz]

Le mercredi 4 septembre 2013 09:44:27 UTC+2, Gildor Oronar a écrit :
 Thanks:
 
 
 
 El 04/09/13 05:01, Terry Reedy escribió:
 
 
 
  I would expect that every account class has a transaction method.
 
  * If so, just call it, but
 
  assertIsNot(DebitAccount.transaction, AbstractAccount.transaction)
 
  for every subclass in your test suite.
 
  * If not, perhaps you need an abstract subclass TransAccount. Then use
 
  hasattr in production code and the isnot test in test code.
 
 
 
 I would assume that you categorize this as a unit test problem, because 
 
 you consider an Acount not implementing Transaction is a bug, right?
 
 
 
 There are two occassions an account is intended not having Transaction 
 
 function, both not test-related:
 
 
 
 1. The acount doesn't offer this feature. e.g. Certificate of Deposit. 
 
 This can be in TransAccount.
 
 
 
 2. The 3rd-party account offer this feature but doesn't qualify the 
 
 software's requirement, e.g. not returning the result in 3 seconds, and 
 
 is avoided when planning the deal (I am writing an auto-trade software). 
 
 This case you cannot categorize those who can into TransAccount, 
 
 beacause 1) that naming imply other accounts don't do transaction but 
 
 they do, just not good enough; 2) when other accounts becomes good 
 
 enough, the change (to inheritance) is a bit too invasive.

Hello,
and what about something like that :


class AbsctractAccount():
 def transaction(self, amount, target):
 logging.info(Start transaction of %s to %s % (amount, target))
 self.DoTransaction(amount,target)

 def DoTransaction(self,amount,target):
 pass # or raise notimplemented or do not implement this methods in the 
abstract class
 ...

class DebitAccount(AbstractAccount):
 def DoTransaction(self, amount, target):
 ...

class SomeOtherAccount(...)
  
like that you only have to write the logging function once.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: to be pythonic: should caller or callee log?

[Terry Reedy]

On 9/3/2013 12:07 PM, Gildor Oronar wrote:

What would you choose? Do you put logging routine into caller or callee?
My intuitive answer is callee does the logging, because that's where
action takes place, like this:

class Account():
 def transaction(self, amount, target):
 logging.info(Start transaction of %s to %s % (amount, target))
 ...

if '__name__' == '__main__'
 
 account.transaction(amount, target)


Simple and easy. Put logging code to the caller would be tedious - the
function is called about 20 times in different places.

So far so good, but we grew up to have 10 different account classes:

class AbsctractAccount():

class CreditAccount(AbstractAccount):
 def transaction(self, amount, target):
 logging.info(Start transaction of %s to %s % (amount, target))
 ...

class DebitAccount(AbstractAccount):
 def transaction(self, amount, target):
 logging.info(Start transaction of %s to %s % (amount, target))
 ...

class SomeOtherAccount(...)
 

Then letting the callee do the logging is also tedious now.

What is the best practise here?

If, for the convenience, we define transaction function in
AbstractAccount to just do the logging, and change inherited classes,
like this:

class AbsctractAccount():
 def transaction(self, amount, target):
 logging.info(Start transaction of %s to %s % (amount, target))

class DebitAccount(AbstractAccount):
 def transaction(self, amount, target):
 super().transaction(amount,target)
 

Then we gethered logging code pieces all to one place, but it begets two
other problems.

1. It is a surprise that super().transaction must be called first,


Not to me ;-). That is fairly standard in super examples I have seen posted.

 not last, and that it does only the logging.

If that is the only thing in common ...


2. The code used to check whether transaction is implemented:

  if hasAttr(DebitAccount, 'transaction'): # clear to read

has to be changed to check whether transaction is inherited:
 if not DebitAccount.transaction is AbstractAccount.transaction:

whose purpose is confusing, and whose cause is a little surprise too.


I would expect that every account class has a transaction method.
* If so, just call it, but
assertIsNot(DebitAccount.transaction, AbstractAccount.transaction)
for every subclass in your test suite.
* If not, perhaps you need an abstract subclass TransAccount. Then use 
hasattr in production code and the isnot test in test code.




Also, the pythonic boldly calling and watching for exception stopped
working, because instead of getting AttributeError, we would get a line
of log and nothing more.


This is what test suites are for.

--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: to be pythonic: should caller or callee log?

[Ethan Furman]

On 09/03/2013 09:07 AM, Gildor Oronar wrote:

What would you choose? Do you put logging routine into caller or callee? My 
intuitive answer is callee does the
logging, because that's where action takes place, like this:

class Account():
 def transaction(self, amount, target):
 logging.info(Start transaction of %s to %s % (amount, target))
 ...

So far so good, but we grew up to have 10 different account classes:

class AbsctractAccount():

class CreditAccount(AbstractAccount):
 def transaction(self, amount, target):
 logging.info(Start transaction of %s to %s % (amount, target))
 ...

class DebitAccount(AbstractAccount):
 def transaction(self, amount, target):
 logging.info(Start transaction of %s to %s % (amount, target))
 ...

class SomeOtherAccount(...)
 

Then letting the callee do the logging is also tedious now.

What is the best practise here?

If, for the convenience, we define transaction function in AbstractAccount to 
just do the logging, and change inherited
classes, like this:

class AbsctractAccount():
 def transaction(self, amount, target):
 logging.info(Start transaction of %s to %s % (amount, target))

class DebitAccount(AbstractAccount):
 def transaction(self, amount, target):
 super().transaction(amount,target)
 


In this instance you're not really gaining anything by using inheritance: before you had one line for logging, after you 
have one line to call super(); in either case if you forget the one line you don't get a log entry.


I would say it is not really the caller's or the callee's job to do the logging, even though it should be done.  What 
would be really handy is a function that sat in between the caller and callee that logged for you -- you know, a decorator:


# not tested, but hopefully you get the idea
def log(func):
def wrapper(*args, **kwds):
text = []
if args:
text.append(str(args))
if kwds:
text.append(str(kwds))
text = ', '.join(text)
if text:
logging.info(%s called with %s % (func.__name__, text)
else:
logging.info(%s called % func.__name__)
return func(*args, **kwds)
return wrapper

Then you can say:

 class WhateverAccount:

@log
def transaction(self, amount, target):
...

True, you still one line, but moves the logging concern outside the function, where it doesn't really belong.  It also 
makes it really easy to see if a function will be logged or not.


--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

Re: Designing a Pythonic search DSL for SQL and NoSQL databases

[Roy Smith]

In article mailman.4864.1374236715.3114.python-l...@python.org,
 Alec Taylor alec.tayl...@gmail.com wrote:

 Dear Python community,
 
 I am analysing designing an abstraction layer over a select few NoSQL
 and SQL databases.
 
 Specifically:
 
 - Redis, Neo4j, MongoDB, CouchDB
 - PostgreSQL

This isn't really a Python question.

Before you even begin to think about how to do this in Python, you 
need to think about how to do this at all.  You've got a huge range of 
storage paradigms there.  Redis is basically a key-value store.  Mongo 
does documents.  Postgres does relations.  I'm not familiar with Neo and 
Couch, but I assume they also have their own interesting ways of storing 
things.

You need to figure out what it means to abstract search over such a 
diverse range of technologies.  I honestly don't think it's possible, 
but maybe you've got some good ideas.  In any case, you need to figure 
that part out before you even begin to think about how to implement it 
in any particular language.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Designing a Pythonic search DSL for SQL and NoSQL databases

[Alec Taylor]

Hmm, looking at the capabilities of Redis; you're likely right.

Would welcome discussion on the implementability and usefulness of a
central search abstraction to the other stores mentioned.

One thing could be that using the paradigm the database was made for
is better than any advantages abstracting their differences creates.

On Fri, Jul 19, 2013 at 10:49 PM, Roy Smith r...@panix.com wrote:
 In article mailman.4864.1374236715.3114.python-l...@python.org,
  Alec Taylor alec.tayl...@gmail.com wrote:

 Dear Python community,

 I am analysing designing an abstraction layer over a select few NoSQL
 and SQL databases.

 Specifically:

 - Redis, Neo4j, MongoDB, CouchDB
 - PostgreSQL

 This isn't really a Python question.

 Before you even begin to think about how to do this in Python, you
 need to think about how to do this at all.  You've got a huge range of
 storage paradigms there.  Redis is basically a key-value store.  Mongo
 does documents.  Postgres does relations.  I'm not familiar with Neo and
 Couch, but I assume they also have their own interesting ways of storing
 things.

 You need to figure out what it means to abstract search over such a
 diverse range of technologies.  I honestly don't think it's possible,
 but maybe you've got some good ideas.  In any case, you need to figure
 that part out before you even begin to think about how to implement it
 in any particular language.
 --
 http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Most reliable/pythonic way to tell if an instance comes from a class implemented in C/etc?

[Terry Reedy]

On 5/24/2010 12:56 PM, Nathan Rice wrote:

I'm trying to do some fairly deep introspection and instrumentation of
instances and classes at runtime, and in order for everything to be
properly behaved I need to have radically different behavior in the
event that the thing passed to me is a wrapped class/instance.  Is there
a really good way, given an instance of a class, to determine if it is
wrapped or native?  Currently I check to see if it has __slots__ then
try to setattr a dummy variable but I imagine there is probably a
cleaner way.


I am not sure what you mean by 'wrapped'. Your subject line says 
something different. In any case, is your universe *all* Python objects 
or some subset?


Builtin classes, named or not, do not have dotted names

 1 .__class__
class 'int'
 class C: pass

I believe all others do, including C-coded extension classes.

 C().__class__
class '__main__.C'

tjr

--
http://mail.python.org/mailman/listinfo/python-list

Re: Most reliable/pythonic way to tell if an instance comes from a class implemented in C/etc?

[Duncan Booth]

Terry Reedy tjre...@udel.edu wrote:

 Builtin classes, named or not, do not have dotted names
 
  1 .__class__
class 'int'
  class C: pass
 
 I believe all others do, including C-coded extension classes.
 
  C().__class__
class '__main__.C'
 

Not quite all. Classes created by calling the type constructor directly 
don't have to follow that rule:

 C = type('Fred', (object,), {})
 C.__name__
'Fred'
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Most reliable/pythonic way to tell if an instance comes from a class implemented in C/etc?

[Carl Banks]

[Following up to Terry Reedy's post since I don't see the original]

On May 24, 11:30 am, Terry Reedy tjre...@udel.edu wrote:
 On 5/24/2010 12:56 PM, Nathan Rice wrote:

  I'm trying to do some fairly deep introspection and instrumentation of
  instances and classes at runtime, and in order for everything to be
  properly behaved I need to have radically different behavior in the
  event that the thing passed to me is a wrapped class/instance.  Is there
  a really good way, given an instance of a class, to determine if it is
  wrapped or native?  Currently I check to see if it has __slots__ then
  try to setattr a dummy variable but I imagine there is probably a
  cleaner way.


There is no foolproof way, but the simplest and most reliable way is
to check the __flags__ attribute to see if it's a heap type, which all
Python new-style classes are and almost all C-defined types aren't:

cls.__flags__  512 # Py_TPFLAGS_HEAPTYPE


However, in Python 2.x, old-style classes aren't types and so don't
have a __flags__ attribute, so to cover that case you should check if
it's a classobj.

isinstance(cls,types.ClassType)


So a complete function would look something like this:

def is_probably_python_class(cls):
return isinstance(cls,types.ClassType) \
or (isinstance(cls,type) and cls.__flags__  512)


It's not foolproof for a couple reasons: it's possible to define heap
types in C, and it's possible to define a metatype that does things
differently, but I would suppose these cases are rare.

Incidentally, depending on  your use case, you might find it helpful
also to know whether a type is a base type (meaning that it can be
subclassed).  You can check that with cls.__flags__  1024.  A
complete list of flags is in the include file object.h.  Note that, in
order to be subclassable, a type defined in C has to behave like a
Python class to a certain extent.  Thus you can assume a little bit
more about it.


Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [ANN] regobj - Pythonic object-based access to the Windows Registry

[Glenn Linderman]

On approximately 5/3/2009 7:35 AM, came the following characters from 
the keyboard of Ryan Kelly:

Hi All,

  I've just released the results of a nice Sunday's coding, inspired by
one too many turns at futzing around with the _winreg module.  The
regobj module brings a convenient and clean object-based API for
accessing the Windows Registry.



Sounds very interesting, Ryan.  Just a couple questions about the 
dictionary interface.




If a subkey is assigned a dictionary, the structure of that dictionary
is copied into the subkey.  Scalar values become key values, while
nested  dictionaries create subkeys:

   HKCU.Software.MyTests = {val1:7, stuff:{a:1,c:2,e:3}}
   [v.name for v in HKCU.Software.MyTests.values()]
  ['val1']
   [k.name for k in HKCU.Software.MyTests.subkeys()]
  ['stuff']
   len(HKCU.Software.MyTests.stuff)
  3

Any other value assigned to a subkey will become the default value for
that key (i.e. the value with name ):

   HKCU.Software.MyTests = dead parrot
   HKCU.Software.MyTests[].data
  u'dead parrot'



I could see how you could map  numbers to DWORD, 2.x str/3.x bytes to 
binary, and 2.x unicode/3.x str to REG_SZ.  But you don't document such 
a translation, so it is unclear exactly what you actually do.  This 
would be somewhat weird in 2.x, though, where str commonly would want to 
map to String rather than Binary.


It seems almost necessary to add an explanation of whatever mapping is 
presently done, to have complete documentation.




Thinking more, I wonder if it is possible to create objects of type 
Value to put in the dictionary to allow specification of multistring and 
expandablestring Registry types, but then the dictionary name would have 
to be redundant with the name attribute in the Value object.  Maybe a 
nameless value type could be invented, with just type and data attributes?


Then the dictionary could be populated with numbers (mapped to DWORD) 
str or unicode items (mapped to String), [3.x only] bytes (mapped to 
Binary), or nameless value objects (which map to their internal types).




This would allow a bidirectional conversion between dictionaries and 
registry keys... when asking for the value of a key, one could return a 
dictionary of nameless value types... and allow iterations over that.


Subkeys could be a tuple with the type of key, and the value of a key 
object.



Well, these are just thoughts.  I don't know if they would increase or 
decrease the Pythonicity of your design, which certainly sounds better 
than using _winreg, to me.



--
Glenn -- http://nevcal.com/
===
A protocol is complete when there is nothing left to remove.
-- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking
--
http://mail.python.org/mailman/listinfo/python-list

Re: [ANN] regobj - Pythonic object-based access to the Windows Registry

[Ryan Kelly]

I've just released the results of a nice Sunday's coding, inspired by
  one too many turns at futzing around with the _winreg module.  The
  regobj module brings a convenient and clean object-based API for
  accessing the Windows Registry.

 Sounds very interesting, Ryan.  Just a couple questions about the 
 dictionary interface.

Thanks for you interest and suggestions, a couple of quick points below.

 I could see how you could map  numbers to DWORD, 2.x str/3.x bytes to 
 binary, and 2.x unicode/3.x str to REG_SZ.  But you don't document such 
 a translation, so it is unclear exactly what you actually do.  This 
 would be somewhat weird in 2.x, though, where str commonly would want to 
 map to String rather than Binary.
 
 It seems almost necessary to add an explanation of whatever mapping is 
 presently done, to have complete documentation.

I guess I just ran out of steam on the documentation front :-)

Currently it maps integers to DWORD and anything else to REG_SZ.  The
idea of having a distinct Value class is to allow a more nuanced mapping
to be developed, but I haven't got down to the details of that yet - my
current application only requires REG_SZ.

 Thinking more, I wonder if it is possible to create objects of type 
 Value to put in the dictionary to allow specification of multistring and 
 expandablestring Registry types, but then the dictionary name would have 
 to be redundant with the name attribute in the Value object.  Maybe a 
 nameless value type could be invented, with just type and data attributes?

It certainly is, using syntax like:

  HKCU.foo.bar[key] = Value(%SYSTEMROOT%/mydir,type=REG_EXPAND_SZ)}

Putting a nameless Value() instance in the initialisation dictionary
should also work (but as you note, there's no documentation or tests for
this yet...)


  Cheers,

 Ryan



-- 
Ryan Kelly
http://www.rfk.id.au  |  This message is digitally signed. Please visit
r...@rfk.id.au|  http://www.rfk.id.au/ramblings/gpg/ for details



signature.asc
Description: This is a digitally signed message part
--
http://mail.python.org/mailman/listinfo/python-list

Re: Definition of Pythonic?

[Lawrence D'Oliveiro]

In message 49e30ac0$0$6828$5fc3...@news.tiscali.it, Francesco Bochicchio 
wrote:

 Which is pretty sensible, since good engineering is often based more on
 choosing the right trade-off rather than choosing the One Right Thing to
 do.

Yes, but remember that, too, is a tradeoff. Moderation is fine, but don't 
carry it to extremes. You can never have too much moderation.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Definition of Pythonic?

[Francesco Bochicchio]

John Yeung ha scritto:

On Apr 11, 10:08 am, Emmanuel Surleau emmanuel.surl...@gmail.com
wrote:

Having written a few trivial scripts in Python, I'm curious as
to how you would sum up the Pythonic philosophy of development.


A couple of others have already mentioned the Zen of Python, available
at the Python command prompt.  I would agree with that, but also add
the caveat that none of the principles expressed there are hard-and-
fast rules.  Hopefully that is clear from the quasi-contradictory
nature of the principles, but inevitably there will be some people who
complain that Python breaks this or that rule from the Zen.



I believe the almost-contraddictory nature of the various listed 
principles is on-purpose. My anecdotal knowledge of the Zen tells me
that is based on the balance of two 'opposing forces', the Yin and the 
Yang. So the 'zen of python' attempts to enunciate the various yins and
yangs of software development, leaving to the developers the task of 
finding the right equilibrium among them.


Which is pretty sensible, since good engineering is often based more on 
choosing the right trade-off rather than choosing the One Right Thing to do.


Ciao
-
FB
--
http://mail.python.org/mailman/listinfo/python-list

Re: Definition of Pythonic?

[Lawrence D'Oliveiro]

Pythonic--an acid, capable of reacting with bases to form pythanates?

Would it be an organic or inorganic acid?

Deprive it of a bit of oxygen, and it becomes pythonous, reacting to form 
pythonites.

What do you mean, the fume cupboard's broken down? Honestly I feel fine...

--
http://mail.python.org/mailman/listinfo/python-list

Re: Recommendations on Pythonic tree data structure design techniques

[Gabriel Genellina]

En Thu, 09 Apr 2009 13:18:27 -0300, pyt...@bdurham.com escribió:


Any recommendations on Python based tree data structures that I
can study? I'm working on an application that will model a basic
outline structure (simple tree) and am looking for ideas on
Pythonic implementation techniques.


I'd use ElementTree. An Element is a generic container for hierarchical  
data - doesn't have to be XML.


See http://effbot.org/zone/element-index.htm and  
http://docs.python.org/library/xml.etree.elementtree.html


--
Gabriel Genellina

--
http://mail.python.org/mailman/listinfo/python-list

Re: Definition of Pythonic?

[Gabriel Genellina]

En Sun, 12 Apr 2009 08:16:19 -0300, Lawrence D'Oliveiro  
l...@geek-central.gen.new_zealand escribió:



Pythonic--an acid, capable of reacting with bases to form pythanates?

Would it be an organic or inorganic acid?

Deprive it of a bit of oxygen, and it becomes pythonous, reacting to form
pythonites.

What do you mean, the fume cupboard's broken down?


Definitely!


Honestly I feel fine...


Sure... just don't drive :)

--
Gabriel Genellina

--
http://mail.python.org/mailman/listinfo/python-list

Re: Definition of Pythonic?

[Tim Chase]

Having written a few trivial scripts in Python, I'm curious as to how you 
would sum up the Pythonic philosophy of development. Judging from Python, it 
seems to exclude (mostly) magical variables like '$.'. Is this right? What 
else would you include in this definition?


At the python command-prompt, issue

  import this

which will dump The Zen of Python.  I'd debate flat vs. 
nested depending on context (nested IFs? nested call-graph? 
nested data-structures?), but otherwise this summarizes many of 
the reasons I esteem Python above all the other computer 
languages I've used (pascal and VB came close; ruby  perl were 
so distant from these ideals, I cringe every time I have to touch 
them for anything).


-tkc





--
http://mail.python.org/mailman/listinfo/python-list

Re: Definition of Pythonic?

[skip]

Emm Having written a few trivial scripts in Python, I'm curious as to
Emm how you would sum up the Pythonic philosophy of development.

Try

import this

at your friendly, neighborhood Python prompt.

-- 
Skip Montanaro - s...@pobox.com - http://www.smontanaro.net/
XML sucks, dictionaries rock - Dave Beazley
--
http://mail.python.org/mailman/listinfo/python-list

Re: Definition of Pythonic?

[Aahz]

In article mailman.3700.1239458914.11746.python-l...@python.org,
Emmanuel Surleau  emmanuel.surl...@gmail.com wrote:

Having written a few trivial scripts in Python, I'm curious as to how you 
would sum up the Pythonic philosophy of development. Judging from Python, it 
seems to exclude (mostly) magical variables like '$.'. Is this right? What 
else would you include in this definition?

python -m this
-- 
Aahz (a...@pythoncraft.com)   * http://www.pythoncraft.com/

Why is this newsgroup different from all other newsgroups?
--
http://mail.python.org/mailman/listinfo/python-list

Re: Definition of Pythonic?

[John Yeung]

On Apr 11, 10:08 am, Emmanuel Surleau emmanuel.surl...@gmail.com
wrote:
 Having written a few trivial scripts in Python, I'm curious as
 to how you would sum up the Pythonic philosophy of development.

A couple of others have already mentioned the Zen of Python, available
at the Python command prompt.  I would agree with that, but also add
the caveat that none of the principles expressed there are hard-and-
fast rules.  Hopefully that is clear from the quasi-contradictory
nature of the principles, but inevitably there will be some people who
complain that Python breaks this or that rule from the Zen.

The fact is, it's impossible to satisfy every principle in every
situation.  To me, Python distinguishes itself for how well it
balances all of them.  Compromise is a word that comes up a lot when
talking about the design of Python.  To some, that has a negative
connotation; to me, it's an inevitable consequence of being practical.

John
--
http://mail.python.org/mailman/listinfo/python-list

Re: Definition of Pythonic?

[MRAB]

John Yeung wrote:

On Apr 11, 10:08 am, Emmanuel Surleau emmanuel.surl...@gmail.com
wrote:

Having written a few trivial scripts in Python, I'm curious as
to how you would sum up the Pythonic philosophy of development.


A couple of others have already mentioned the Zen of Python, available
at the Python command prompt.  I would agree with that, but also add
the caveat that none of the principles expressed there are hard-and-
fast rules.


Special cases aren't special enough to break the rules.
Although practicality beats purity.

This also applies to the Zen itself.

 Hopefully that is clear from the quasi-contradictory

nature of the principles, but inevitably there will be some people who
complain that Python breaks this or that rule from the Zen.

The fact is, it's impossible to satisfy every principle in every
situation.  To me, Python distinguishes itself for how well it
balances all of them.  Compromise is a word that comes up a lot when
talking about the design of Python.  To some, that has a negative
connotation; to me, it's an inevitable consequence of being practical.


--
http://mail.python.org/mailman/listinfo/python-list

Re: Definition of Pythonic?

[Emmanuel Surleau]

On Saturday 11 April 2009 18:00:58 John Yeung wrote:
 On Apr 11, 10:08 am, Emmanuel Surleau emmanuel.surl...@gmail.com

 wrote:
  Having written a few trivial scripts in Python, I'm curious as
  to how you would sum up the Pythonic philosophy of development.

 A couple of others have already mentioned the Zen of Python, available
 at the Python command prompt.  I would agree with that, but also add
 the caveat that none of the principles expressed there are hard-and-
 fast rules.  Hopefully that is clear from the quasi-contradictory
 nature of the principles, but inevitably there will be some people who
 complain that Python breaks this or that rule from the Zen.

Thank you all for the nice and prompt replies to what is a typical newbie 
question, which is bound to come back regularly. And no, you can't make 
everybody happy, per definition.

 The fact is, it's impossible to satisfy every principle in every
 situation.  To me, Python distinguishes itself for how well it
 balances all of them.  Compromise is a word that comes up a lot when
 talking about the design of Python.  To some, that has a negative
 connotation; to me, it's an inevitable consequence of being practical.


That's fine with me: after all, you can't do software engineering without 
trade-offs.

Cheers,

Emm
--
http://mail.python.org/mailman/listinfo/python-list

Re: Definition of Pythonic?

[Mark Wooding]

John Yeung gallium.arsen...@gmail.com writes:

 A couple of others have already mentioned the Zen of Python, available
 at the Python command prompt.  I would agree with that, but also add
 the caveat that none of the principles expressed there are hard-and-
 fast rules.

Indeed, I'd suggest that the very lack of hard-and-fast rules is typical
of the Python approach.

 The fact is, it's impossible to satisfy every principle in every
 situation.  To me, Python distinguishes itself for how well it
 balances all of them.  Compromise is a word that comes up a lot when
 talking about the design of Python.  To some, that has a negative
 connotation; to me, it's an inevitable consequence of being practical.

Agreed.  Then again, all language design is a compromise, between
factors like runtime efficiency, simplicity of implementation,
tractability of semantics (for various classes of users), supportability
by tools, and expressive power.  Python inhabits what seems to me to be
a particularly sweet spot on this rather complex landscape.

-- [mdw]
--
http://mail.python.org/mailman/listinfo/python-list

Re: Recommendations on Pythonic tree data structure design techniques

[Daniel Fetchinson]

 Any recommendations on Python based tree data structures that I
 can study? I'm working on an application that will model a basic
 outline structure (simple tree) and am looking for ideas on
 Pythonic implementation techniques. By outline I mean a
 traditional hierarchical document outline (section, chapter,
 sub-chapter, ...). I will be building this structure as I parse
 my customer's internally designed (proprietary) publishing markup
 language.
 My initial thought is to implement a generic node container class
 with attributes for parent, next, previous, and child 'pointers'.
 The node objects will be stored in a dictionary where node
 'pointers' correspond to incrementally assigned numeric keys.


http://www.google.com/search?q=python+tree+data+structure

HTH,
Daniel

-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
--
http://mail.python.org/mailman/listinfo/python-list

Re: Recommendations on Pythonic tree data structure design techniques

[CTO]

I'm writing a Python graph library (called Graphine) that's
pretty easy to use and does what you want. It is pre-alpha
right now, but if you're interested please let me know- I'm
very interested in hearing outside opinions.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Recommendations on Pythonic tree data structure design techniques

[andrew cooke]

pyt...@bdurham.com wrote:
 Any recommendations on Python based tree data structures that I
 can study? I'm working on an application that will model a basic
 outline structure (simple tree) and am looking for ideas on
 Pythonic implementation techniques. By outline I mean a
 traditional hierarchical document outline (section, chapter,
 sub-chapter, ...). I will be building this structure as I parse
 my customer's internally designed (proprietary) publishing markup
 language.
 My initial thought is to implement a generic node container class
 with attributes for parent, next, previous, and child 'pointers'.

That sounds reasonable, but do you need parent?  It creates a reference
loop, which make GC less likely to happen (or at least later), and it also
complicates adding and removing nodes.  Many algorithms don't need it. 
Even if you do need to ascend the tree you may be able to get by with a
path that is a list of nodes from root to the current node and that
indexes the node.

 The node objects will be stored in a dictionary where node
 'pointers' correspond to incrementally assigned numeric keys.

This doesn't make sense to me.  It sounds like you are re-inventing lists
(arrays).

Andrew



--
http://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[Baby Coder]

On 18 déc 2008, 13:51, Jason Scheirer jason.schei...@gmail.com
wrote:

 I'd say it's fine but breaking up the statement once or twice is a
 good idea just because if one of the function calls in this nested
 thing throws an exception, a smaller statement with fewer calls makes
 for a far more readable traceback. And I hope that this whole
 statement all lives inside of a method in the same x class, or is a
 higher-level class that makes use of this behavior? If not, you may
 want to consider doing so.

 class X(object):
   @property
   def todays_filepattern(self):
       return self.match_filename(
               self.determine_filename_pattern(
                    datetime.datetime.now()))
   def validate_todays_files(self):
      return self.validate_output(self.find_text
 (self.todays_filepattern))

Thanks for this lesson in application design. Just what I was looking
for.
--
http://mail.python.org/mailman/listinfo/python-list

Re: is this pythonic?

[Peter Otten]

TP wrote:

 Hi,
 
 Is the following code pythonic:
 
 l=[{title:to, value:2},{title:ti,value:coucou}]
 dict = [ dict for dict in l if dict['title']=='ti']
 l.remove(*dict)
 l
 [{'title': 'to', 'value': 2}]
 
 Precision: I have stored data in the list of dictionaries l, because in my
 application I am sure that title is unique for each record. But perhaps
 it is better to imagine that someday it will not be anymore the case? And
 rather use a data storage as the following?
 
 l = { '001':{title:to, value:2}, '002'
 {title:ti,value:coucou}}
 
 The problem with this storage is that it implies to manipulate some ids
 that have not any meaning for a humain being (001, 002, etc).
 
 Thanks a lot for you opinion,

If you can change the rest of your program to work smoothly with a
dictionary I would suggest the following:

 items = [{title:to, value:2},{title:ti,value:coucou}]
 lookup = dict((item[title], item) for item in items)
 lookup
{'to': {'value': 2, 'title': 'to'}, 'ti':
{'value': 'coucou', 'title': 'ti'}}
 del lookup[ti]
 lookup
{'to': {'value': 2, 'title': 'to'}}

If you later have to accomodate for multiple dictionaries with the same
title use lists of dictionaries as values:

 from collections import defaultdict
 lookup = defaultdict(list)
 for item in items:
... lookup[item[title]].append(item)
...
 lookup
defaultdict(type 'list', {'to': [{'value': 2, 'title': 'to'}], 'ti':
[{'value': 'coucou', 'title': 'ti'}]})
 del lookup[ti] 
 lookup
defaultdict(type 'list', {'to': [{'value': 2, 'title': 'to'}]})

Peter
--
http://mail.python.org/mailman/listinfo/python-list

Re: is this pythonic?

[TP]

Peter Otten wrote:

 If you can change the rest of your program to work smoothly with a
 dictionary I would suggest the following:
[snip]
 from collections import defaultdict
[snip]

Thanks a lot.
I didn't know defaultdict. It is powerful.

I begin to understand that people prefer using dictionaries than lists, so
as to take advantage of their automatic lookup feature.

-- 
python -c print ''.join([chr(154 - ord(c)) for c in '*9(9(18%.\
91+,\'Z4(55l4('])

When a distinguished but elderly scientist states that something is
possible, he is almost certainly right. When he states that something is
impossible, he is very probably wrong. (first law of AC Clarke)
--
http://mail.python.org/mailman/listinfo/python-list

Re: is this pythonic?

[pruebauno]

On Jan 21, 4:23 pm, Scott David Daniels scott.dani...@acm.org wrote:
 prueba...@latinmail.com wrote:
  ... If you have duplicates this will not work. You will have to do
  something like this instead:

  o=[]
  i=0
  ln=len(l)
  while iln:
     if l[i]['title']=='ti':
             o.append(l.pop(i))
             ln-=1
     else:
             i+=1

 Or the following:
      indices = [i for i,d in enumerate(l) if d['title']=='ti']
      for i in reversed(indices): # so del doesn't affect later positions
          del l[i]

 --Scott David Daniels
 scott.dani...@acm.org

Cool. How come I didn't think of that! That means I can create an evil
one liner now :-).

replacecount=len([o.append(l.pop(i)) for i in reversed(xrange(len(l)))
if l[i]['title']=='ti'])
--
http://mail.python.org/mailman/listinfo/python-list

Re: is this pythonic?

[pruebauno]

On Jan 21, 4:23 pm, Scott David Daniels scott.dani...@acm.org wrote:
 prueba...@latinmail.com wrote:
  ... If you have duplicates this will not work. You will have to do
  something like this instead:

  o=[]
  i=0
  ln=len(l)
  while iln:
     if l[i]['title']=='ti':
             o.append(l.pop(i))
             ln-=1
     else:
             i+=1

 Or the following:
      indices = [i for i,d in enumerate(l) if d['title']=='ti']
      for i in reversed(indices): # so del doesn't affect later positions
          del l[i]

 --Scott David Daniels
 scott.dani...@acm.org

Cool. How come I didn't think of that!. Now I can write my evil one
liner :-).

o=[l.pop(i) for i in reversed(xrange(len(l))) if l[i]['title']=='ti']
--
http://mail.python.org/mailman/listinfo/python-list

Re: is this pythonic?

[Peter Pearson]

On Wed, 21 Jan 2009 16:16:32 +0100, TP wrote:

 Is the following code pythonic:

 l=[{title:to, value:2},{title:ti,value:coucou}]
 dict = [ dict for dict in l if dict['title']=='ti']
 l.remove(*dict)
 l
 [{'title': 'to', 'value': 2}]

 Precision: I have stored data in the list of dictionaries l, because in my
 application I am sure that title is unique for each record. But perhaps
 it is better to imagine that someday it will not be anymore the case?
[snip]

1. You probably don't want to use the name dict.

2. I believe this code will fail if the number of dictionaries
   with title=ti is not exactly 1.  It that your intention?
   (You probably answered this question in the last paragraph
   quoted above, but I can't make it out.)

-- 
To email me, substitute nowhere-spamcop, invalid-net.
--
http://mail.python.org/mailman/listinfo/python-list

Re: is this pythonic?

[alex23]

On Jan 22, 1:16 am, TP tribulati...@paralleles.invalid wrote:
 Is the following code pythonic:
  l=[{title:to, value:2},{title:ti,value:coucou}]
  dict = [ dict for dict in l if dict['title']=='ti']
  l.remove(*dict)
  l
 [{'title': 'to', 'value': 2}]

Try not to use 'dict' or the name of any of the other built-in types
as labels.

You're stepping through an entire list just to pass another list to
l.remove to step through and remove items from...in fact, given that
list.remove deletes the -first- occurance of the item, you're asking
it to loop through -again- to find the matching element which you've -
already- detected. A better and cleaner approach would be to step
through the list -once- and remove the item when you find it:

for index, record in enumerate(l):
if record['title'] == 'ti':
l.pop(index)

Or you could just use a list comprehension:

l = [d for d in l if d['title'] == 'ti']

 Precision: I have stored data in the list of dictionaries l, because in my
 application I am sure that title is unique for each record. But perhaps
 it is better to imagine that someday it will not be anymore the case?

It's always better to design for what you know you need, not what you
may possibly need in the future. You say that you are sure that record
titles are unique, so why not use them as the dictionary keys, with
the values as the values:

  records = {'ti': 1, 'to': 2}

This way your code can be replaced with:

  value = records.pop('ti') # if you want to know the value
  del records['ti'] # if you just want to delete the entry

It's a lot simpler to work with and extend.
--
http://mail.python.org/mailman/listinfo/python-list

Re: is this pythonic?

[MRAB]

alex23 wrote:

On Jan 22, 1:16 am, TP tribulati...@paralleles.invalid wrote:

Is the following code pythonic:

l=[{title:to, value:2},{title:ti,value:coucou}]
dict = [ dict for dict in l if dict['title']=='ti']
l.remove(*dict)
l

[{'title': 'to', 'value': 2}]


Try not to use 'dict' or the name of any of the other built-in types
as labels.

You're stepping through an entire list just to pass another list to
l.remove to step through and remove items from...in fact, given that
list.remove deletes the -first- occurance of the item, you're asking
it to loop through -again- to find the matching element which you've -
already- detected. A better and cleaner approach would be to step
through the list -once- and remove the item when you find it:

for index, record in enumerate(l):
if record['title'] == 'ti':
l.pop(index)


[snip]
FYI, you shouldn't modify a list you're iterating over.


Or you could just use a list comprehension:

l = [d for d in l if d['title'] == 'ti']

The for-loop was removing the item where there's a match, so the list 
comprehension in this case should keep the item where there _isn't_ a match:


l = [d for d in l if d['title'] != 'ti']

[remainder snipped]
--
http://mail.python.org/mailman/listinfo/python-list

Re: is this pythonic?

[TP]

alex23 wrote:

 Try not to use 'dict' or the name of any of the other built-in types
 as labels.

Ops... Moreover I know it...

 You're stepping through an entire list just to pass another list to
 l.remove to step through and remove items from...in fact, given that
 list.remove deletes the -first- occurance of the item, you're asking
 it to loop through -again- to find the matching element which you've -
 already- detected. A better and cleaner approach would be to step
 through the list -once- and remove the item when you find it:
 
 for index, record in enumerate(l):
 if record['title'] == 'ti':
 l.pop(index)

Ok, I will use this solution. But it is less pythonic than list
comprehensions.

 Or you could just use a list comprehension:
 
 l = [d for d in l if d['title'] == 'ti']

Perhaps you mean rather:

l = [d for d in l if d['title'] != 'ti']
?

In fact, I cannot use this solution, because I want to get back the
dictionary with title 'ti', for another use (in fact, to add it to another
list, see below).

 Precision: I have stored data in the list of dictionaries l, because in
 my application I am sure that title is unique for each record. But
 perhaps it is better to imagine that someday it will not be anymore the
 case?
 
 It's always better to design for what you know you need, not what you
 may possibly need in the future. You say that you are sure that record
 titles are unique, so why not use them as the dictionary keys, with
 the values as the values:
 
   records = {'ti': 1, 'to': 2}
 
 This way your code can be replaced with:
 
   value = records.pop('ti') # if you want to know the value
   del records['ti'] # if you just want to delete the entry
 
 It's a lot simpler to work with and extend.

In fact, in my case, in cannot use this simple solution, because there are
other fields in each dictionary, not only 2. I was not clear in my post.
So my list is rather:
l=[{title:to, color:blue, value:2}
{title:ti, color:red, value:coucou}]

So, I will rather use your solution:

for index, record in enumerate(l):
if record['title'] == 'ti':
to_add_in_another_list = l.pop(index)
another_list.append(to_add_in_another_list )

 It's always better to design for what you know you need, not what you
 may possibly need in the future.

Ok. Do all the programmers agree with this principle?

-- 
python -c print ''.join([chr(154 - ord(c)) for c in '*9(9(18%.\
91+,\'Z4(55l4('])

When a distinguished but elderly scientist states that something is
possible, he is almost certainly right. When he states that something is
impossible, he is very probably wrong. (first law of AC Clarke)
--
http://mail.python.org/mailman/listinfo/python-list

Re: is this pythonic?

[alex23]

On Jan 22, 3:27 am, MRAB goo...@mrabarnett.plus.com wrote:
 FYI, you shouldn't modify a list you're iterating over.

But I'm not. I'm building a new list and binding it to the same name
as the original, which works perfectly fine (unless I'm missing
something):

 l = range(100)
 l = [d for d in l if not d % 5]
 l
[0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55, 60, 65, 70, 75, 80, 85,
90, 95]

 The for-loop was removing the item where there's a match, so the list
 comprehension in this case should keep the item where there _isn't_ a match:

 l = [d for d in l if d['title'] != 'ti']

Now that's a mistake. Cheers for the catch.
--
http://mail.python.org/mailman/listinfo/python-list

Re: is this pythonic?

[MRAB]

alex23 wrote:

On Jan 22, 3:27 am, MRAB goo...@mrabarnett.plus.com wrote:

FYI, you shouldn't modify a list you're iterating over.


But I'm not. I'm building a new list and binding it to the same name
as the original, which works perfectly fine (unless I'm missing
something):


[snip]
I was referring to the code:

for index, record in enumerate(l):
if record['title'] == 'ti':
l.pop(index)

where you are enumerating and iterating over 'l', but also modifying 'l' 
with 'l.pop(index)'.

--
http://mail.python.org/mailman/listinfo/python-list

Re: is this pythonic?

[alex23]

On Jan 22, 3:34 am, TP tribulati...@paralleles.invalid wrote:
      for index, record in enumerate(l):
          if record['title'] == 'ti':
              l.pop(index)

 Ok, I will use this solution. But it is less pythonic than list
 comprehensions.

Are you asking if it's less pythonic, or asserting? Because you'll
find a lot of disagreement here: list comprehensions are used for
constructing lists, not manipulating them.

 Perhaps you mean rather:

 l = [d for d in l if d['title'] != 'ti']
 ?

You are correct. I should never post past 3am :)

 In fact, in my case, in cannot use this simple solution, because there are
 other fields in each dictionary, not only 2. I was not clear in my post.
 So my list is rather:
 l=[{title:to, color:blue, value:2}
 {title:ti, color:red, value:coucou}]

I still find this a lot simpler:

  records = {'to': {'color': 'blue', 'value': '2'}, 'ti': {'color':
'red', 'value': 'coucou'}}

  It's always better to design for what you know you need, not what you
  may possibly need in the future.

 Ok. Do all the programmers agree with this principle?

Have you seen the size of some of the threads here? It's hard to get
two programmers to agree on variable names... :) But it's a practice
that has served me well and it even has a catchy name[1]. Getting what
you -need- to work is effort enough, if you don't have a definite use
case for a feature then how do you know you've implemented it
correctly? Write it when you need it.

1: http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It
--
http://mail.python.org/mailman/listinfo/python-list

Re: is this pythonic?

[alex23]

On Jan 22, 3:56 am, MRAB goo...@mrabarnett.plus.com wrote:
 I was referring to the code:

      for index, record in enumerate(l):
          if record['title'] == 'ti':
              l.pop(index)

 where you are enumerating and iterating over 'l', but also modifying 'l'
 with 'l.pop(index)'.

Ack, you're absolutely correct.

TP: my mistake, the for loop won't work at all. I'd really recommend
using the dictionary-based solution.

Apologies all around.
--
http://mail.python.org/mailman/listinfo/python-list

Re: is this pythonic?

[pruebauno]

On Jan 21, 12:34 pm, TP tribulati...@paralleles.invalid wrote:
 alex23 wrote:
  Try not to use 'dict' or the name of any of the other built-in types

 So my list is rather:
 l=[{title:to, color:blue, value:2}
 {title:ti, color:red, value:coucou}]

 So, I will rather use your solution:

 for index, record in enumerate(l):
     if record['title'] == 'ti':
         to_add_in_another_list = l.pop(index)
 another_list.append(to_add_in_another_list )

If you have duplicates this will not work. You will have to do
something like this instead:

 o=[]
 i=0
 ln=len(l)
 while iln:
if l[i]['title']=='ti':
o.append(l.pop(i))
ln-=1
else:
i+=1



If you don't have duplicates you can extract the one and exit early:

 for index, record in enumerate(l):
if record['title'] == 'ti':
to_add_in_another_list = l.pop(index)
break

I don't know if these are more pythonic, they should be more efficient
for longer lists though.
--
http://mail.python.org/mailman/listinfo/python-list

Re: is this pythonic?

[Scott David Daniels]

prueba...@latinmail.com wrote:

... If you have duplicates this will not work. You will have to do
something like this instead:


o=[]
i=0
ln=len(l)
while iln:

if l[i]['title']=='ti':
o.append(l.pop(i))
ln-=1
else:
i+=1


Or the following:
indices = [i for i,d in enumerate(l) if d['title']=='ti']
for i in reversed(indices): # so del doesn't affect later positions
del l[i]


--Scott David Daniels
scott.dani...@acm.org
--
http://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[Bruno Desthuilliers]

ipyt...@gmail.com a écrit :

x.validate_output(x.find_text(x.match_filename
(x.determine_filename_pattern(datetime.datetime.now()

Is it even good programming form?


functional programming addicts might say yes. But as far as I'm 
concerned, I find it a bit too nested...

--
http://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[Laszlo Nagy]

ipyt...@gmail.com wrote:

x.validate_output(x.find_text(x.match_filename
(x.determine_filename_pattern(datetime.datetime.now()

Is it even good programming form?
  

You should try LISP. :-)
--
http://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[pruebauno]

On Dec 18, 11:08 am, ipyt...@gmail.com wrote:
 x.validate_output(x.find_text(x.match_filename
 (x.determine_filename_pattern(datetime.datetime.now()

 Is it even good programming form?

Lisp and Scheme programmers love that style. You can tell by the
number of parentheses :-). In Python people usually use an
intermediate variable to break things up a bit but the amount of
acceptable nesting is a matter of personal style.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[Jason Scheirer]

On Dec 18, 8:45 am, prueba...@latinmail.com wrote:
 On Dec 18, 11:08 am, ipyt...@gmail.com wrote:

  x.validate_output(x.find_text(x.match_filename
  (x.determine_filename_pattern(datetime.datetime.now()

  Is it even good programming form?

 Lisp and Scheme programmers love that style. You can tell by the
 number of parentheses :-). In Python people usually use an
 intermediate variable to break things up a bit but the amount of
 acceptable nesting is a matter of personal style.

I'd say it's fine but breaking up the statement once or twice is a
good idea just because if one of the function calls in this nested
thing throws an exception, a smaller statement with fewer calls makes
for a far more readable traceback. And I hope that this whole
statement all lives inside of a method in the same x class, or is a
higher-level class that makes use of this behavior? If not, you may
want to consider doing so.

class X(object):
  @property
  def todays_filepattern(self):
  return self.match_filename(
  self.determine_filename_pattern(
   datetime.datetime.now()))
  def validate_todays_files(self):
 return self.validate_output(self.find_text
(self.todays_filepattern))
--
http://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[Russ P.]

On Dec 18, 8:08 am, ipyt...@gmail.com wrote:
 x.validate_output(x.find_text(x.match_filename
 (x.determine_filename_pattern(datetime.datetime.now()

 Is it even good programming form?

I hope you're kidding.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Is this pythonic?

[Hendrik van Rooyen]

Bruno Desthuilliers bru.@websiteburo.invalid wrote:

ipyt...@gmail.com a écrit :
 x.validate_output(x.find_text(x.match_filename
 (x.determine_filename_pattern(datetime.datetime.now()

 Is it even good programming form?

functional programming addicts might say yes. But as far as I'm
concerned, I find it a bit too nested...

+1

I would call it onionskin programming.

There is of course nothing technically wrong with it,
and you can do the same kind of thing in C, but
every time I see something like it, my reaction is
WTF.

- Hendrik

--
http://mail.python.org/mailman/listinfo/python-list

Re: A more pythonic way of writting

[Mark Tolonen]

eric [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]



def flag(IGNORECASE=False, LOCALE=False, MULTILINE=False,
DOTALL=False, UNICODE=False, VERBOSE=False):
   vals = [IGNORECASE, LOCALE, MULTILINE, DOTALL, UNICODE, VERBOSE]
   filtered = map( lambda m:m[1],filter( lambda m: m[0], 
zip(vals,'iLmsux')))

   return '?'+''.join( filtered  )


   filtered = [c for c,v in zip('iLmsux',vals) if v]

-Mark


--
http://mail.python.org/mailman/listinfo/python-list

Re: A more pythonic way of writting

[Gerard flanagan]

eric wrote:

Hi,

I've got this two pieces of code that works together, and fine

def testit():
for vals in [[imask==mask for mask in [1j for j in range(6)] ]
for i in range(16)]:
print vals, '-',  flag(*vals)

def flag(IGNORECASE=False, LOCALE=False, MULTILINE=False,
DOTALL=False, UNICODE=False, VERBOSE=False):
vals = [IGNORECASE, LOCALE, MULTILINE, DOTALL, UNICODE, VERBOSE]
filtered = map( lambda m:m[1],filter( lambda m: m[0], zip(vals,
'iLmsux')))
return '?'+''.join( filtered  )

testit()

but I'm not proud of the way it is written. I dont find it very
pythonic.
I have to multiplex (using zip) bool and value, filter using only the
bool, and demultiplex later using map

the first simply parses all the possible combination of 6 boolean
(can't hardly be made simpler)

the second function, should simply return a string based on the
boolean value
i,   L,   m,  s,  u, x,
True, False, False, True, True, False
=  ?isu

that's should take only one line, shouldn't it?

any idea ?

--
http://mail.python.org/mailman/listinfo/python-list



#after Paul Rubin (c.l.py)
def hypercube(ndims):
if ndims == 0:
yield ()
return
for h in 1, 0:
for y in hypercube(ndims-1):
yield (h,)+y

#after Mark Tolonen
for item in hypercube(6):
print ''.join(c for c,v in zip('iLmsux', item) if v)


--
http://mail.python.org/mailman/listinfo/python-list

Re: A more pythonic way of writting

[eric]

On Dec 5, 3:44 pm, Mark Tolonen [EMAIL PROTECTED] wrote:
 eric [EMAIL PROTECTED] wrote in message

 news:[EMAIL PROTECTED]

  def flag(IGNORECASE=False, LOCALE=False, MULTILINE=False,
  DOTALL=False, UNICODE=False, VERBOSE=False):
     vals = [IGNORECASE, LOCALE, MULTILINE, DOTALL, UNICODE, VERBOSE]
     filtered = map( lambda m:m[1],filter( lambda m: m[0],
  zip(vals,'iLmsux')))
     return '?'+''.join( filtered  )

     filtered = [c for c,v in zip('iLmsux',vals) if v]

 -Mark

thank you very much ! great !

I can't get used to this late 'if' syntax !

@Gerard
nice hypercube function. But I'll keep with my implementation :
I like to believe that the less the 'debug pointer' stands in the
python code, the fastest the code is (or is potentially)

I keep thinking that
def hypercube(ndims) :
for i in range(1ndims):
yield [imask==mask for mask in [1j for j in range(ndims)] ]

but thanks for you proposition, it's interesting anyway

--
http://mail.python.org/mailman/listinfo/python-list

Re: A more pythonic way of writting

[Steven D'Aprano]

On Fri, 05 Dec 2008 07:44:21 -0800, eric wrote:

 I like to believe that the less the 'debug pointer' stands in the python
 code, the fastest the code is (or is potentially)

What's a debug pointer?

Pre-mature optimization is the root of evil in programming. Unless you 
have actually *measured* the speed of the code, how do you know you 
aren't making it slower instead of faster?

Experience with other languages often is misleading when programming with 
Python. If you are used to programming in C, for example, then you will 
tend to program one way because comparisons are fast and moving records 
is slow. But in Python, comparisons can be slow and moving records is 
fast, so the C programmer's intuitions about fast code are often 
pessimations instead of optimizations. 


-- 
Steven
--
http://mail.python.org/mailman/listinfo/python-list

Re: A more pythonic way of writting

[eric]

On Dec 6, 12:19 am, Steven D'Aprano [EMAIL PROTECTED]
cybersource.com.au wrote:
 On Fri, 05 Dec 2008 07:44:21 -0800, eric wrote:
  I like to believe that the less the 'debug pointer' stands in the python
  code, the fastest the code is (or is potentially)

 What's a debug pointer?

 Pre-mature optimization is the root of evil in programming. Unless you
 have actually *measured* the speed of the code, how do you know you
 aren't making it slower instead of faster?

 Experience with other languages often is misleading when programming with
 Python. If you are used to programming in C, for example, then you will
 tend to program one way because comparisons are fast and moving records
 is slow. But in Python, comparisons can be slow and moving records is
 fast, so the C programmer's intuitions about fast code are often
 pessimations instead of optimizations.

 --
 Steven

you are right about premature optimization. I cannot disagree.

My 'rule of thumb' was more about that:
1/ keep the code the more descriptive and the less procedural as
possible.
2/ the less instructions you write, the more optimization you'll get
from the others

the hypercube function is cool, and I would use it, if I weren't in
charge of maintaining the code.


I've done some 'timeit'

import timeit

t1 = timeit.Timer(

h1 = hypercube(6)
,
def hypercube(ndims):
return [[imask==mask for mask in [1j for j
in range(ndims)] ] for i in range(1ndims)])

t2 = timeit.Timer(

h2 = [h for h in  hypercube(6)]
,
def hypercube(ndims):
 if ndims == 0:
 yield ()
 return
 for h in False,True:
 for y in hypercube(ndims-1):
 yield (h,)+y)

M= 10
array_method = t1.timeit(M)
recursion_method = t2.timeit(M)

print array method %s%array_method
print recursion method %s%recursion_method

print recursion is %s%% slower%( (recursion_method - array_method)/
recursion_method*100)


console result
array method 41.2270488739
recursion method 48.3009829521
recursion is 14.6455281981% slower


well, nothing drastic here.







--
http://mail.python.org/mailman/listinfo/python-list

Re: Understanding the pythonic way: why a.x = 1 is better than a.setX(1) ?

[Terry Reedy]

Marco Bizzarri wrote:


I understand that Python is a balance between different forces (like
any software object around the world) and I'm simply asking some
pointers to the discussion leading to this balance.


The original decisions by Guido were nearly 20 years ago and other 
discussions are scattered through the archive of this and the py-dev 
list.  But here is a pointer.  Why go through the trouble of writing 
functions that will set, get, and delete an attribute and the trouble of 
calling those functions when you can use Python's existing syntax to do 
it directly?  More particularly, why would/should Guido force the 
combersome indirection and time-penalty for writing, reading, and 
execution on *every* Python programmer?


Of course, from my viewpoint, and for my usage,languages that do so 
force are obnoxious.


tjr

--
http://mail.python.org/mailman/listinfo/python-list