I get the impression that most Pythonistas aren't as habituated with assert
statements as I am. Is that just a misimpression on my part? If not, is there a
good reason to assert less with Python than other languages?
As far as I can tell, Python supports assert perfectly well. When run with the
On Tue, Nov 11, 2014 at 12:57 PM, TP wing...@gmail.com wrote:
On Tue, Nov 11, 2014 at 11:40 AM, Peter Cacioppi peter.cacio...@gmail.com
wrote:
I think one needs to take care with some basic assert coding - it's not a
substitute for unit tests, it doesn't absolve you of normal exception
Chris said :
I think map is fine if you can use a named function, but if you can't
come up with a descriptive name for what you're doing, a comprehension
is probably better (as it'll have the code right there). Mapping _
across everything tells you nothing about what it's actually doing
OK, this
Sorry, typo, meant to say
To be clear, I was never really intending to keep the
_ = lambda c : lambda x : c(*x)
map(_(P), zip([1,2,3], [6, 5, 4]))
code snippets in my final work product. The purpose of this thread was too fish
around for ideas on what to replace it with...
--
Chris said :
Absolutely! The unfortunate truth, though, is that idioms that
resonate with you _and nobody else_ are just as big a problem as bugs,
because they're unmaintainable. So hopefully what you're doing will
make sense to other people too!
There is some truth in what you say ... but in
Peter Otten said:
_ = lambda c: lambda x: c(*x)
list(map(_(P), zip([1,2,3], [6, 5, 4])))
[Point(x=1, y=6), Point(x=2, y=5), Point(x=3, y=4)]
? While the obvious approach would be
[P(*args) for args in zip([1,2,3], [6, 5, 4])]
[Point(x=1, y=6), Point(x=2, y=5), Point(x=3, y=4)]
I
my fav so far is this
_ = lambda c : lambda x : c(*x)
c can be any calleable and x any iterable, but I tend to use it with a class,
and then map _(class) over the result of a zip.
It must be in the library somewhere, but I haven't found it. I'm never sure
what to call it, so I just reroll it
Chris said:
So... for any given class, it returns a tweaked version that unpacks
an iterable of its arguments instead of taking separate args.
It works with any calleable (not just any class), but otherwise your summary is
spot on.
Interesting, perhaps, but not something that'll be needed in
On Monday, October 28, 2013 10:22:00 PM UTC-7, Steven D'Aprano wrote:
Does anyone here use slices (or range/xrange) with negative strides other
than -1?
Non default positive strides are very handy, but negative strides seem weird to
me. Not the negative striding exactly, but the way
Ian said :
Since the compiler generally can't predict what the types of objects will be,
the bytecode that it generates can't depend on those types.
very nice, the py is strong with you. Thanks, Pete
--
https://mail.python.org/mailman/listinfo/python-list
Python makes it very easy to turn a zero argument member function into a
property (hooray!) by simply adding the @property decorator.
(Meme for well thought py feature - Guido was here)
But the ease with which you can do this makes the zero argument member
function or property discussion
I just said
1- the zero argument function is sort of factory-like. It potentially has
non-trivial run time, or it substitutes calling a class constructor when
building certain objects.
2- it simply retrieves a stored value (perhaps lazily evaluating it first)
so 1 should clearly be a zero
Steve said:
(This isn't Java or Ruby, where data-hiding is compulsory :-) (You could
add C++ and C# to this list).
This is golden nugget for me. The old synapses are pretty well grooved to think
of data hiding as good hygiene. Even though I've read a fair bit of Python text
I still need to
Steve said:
(This isn't Java or Ruby, where data-hiding is compulsory :-)
At the risk of striking a sessile equine, when the attribute shouldn't be
modified directly by client code, then you hide it and use a property to allow
client code access. It is the idiom of allowing client code to
Ian said :
Whereas in Python, an attribute access is just
compiled as an attribute access no matter what the underlying
implementation of that access may end up being at run-time.
Really? Very nice. Have a good link handy for that? I'm compiling a codex of
why py is better?.
--
Mark said :
The White Flag before this also escalates out of control.
This word before ... I don't think it means what you think it means.
This thread has been off the rails for days.
--
https://mail.python.org/mailman/listinfo/python-list
Mark said :
Do I have to raise a PEP to get this stupid language changed so that it
dynamically recognises what I want it to do and acts accordingly?
The printf syntax in C isn't any wonderful thing, and there is no obligation to
provide some Python version of it.
I have to say, there were a
Mark said :
so I can get an extremely large pair of pliers with which I can extract my
tongue from my cheek :)
OK fair enough, and my post was in the same spirit.
Chris said :
Maybe, but it's supported by so many languages that it is of value.
Sure, I suppose someone should make a module
Chris said :
I almost exclusively use C-style formatted strings, even sometimes going to
the extent of using fopen() just so I can use fprintf() rather than fstream.
Also, I often create a class something like this:
Ditto all that, to include the special class I cooked up to handle printf
Chris said :
It does look cool on paper.
Sure, I'll buy that Bjarne designed something intellectually pretty that just
doesn't flow very well in practice. Most of his C++ worked very well both in
theory and practice, so I can forgive him one nerdy overreach, if that's what
it was.
Python is
Steven said
Isn't freedom of choice wonderful?
Didn't somebody once say we're all adults here. I forget who said that.
Eddard Stark? The guy always did keep his head in a crisis.
--
https://mail.python.org/mailman/listinfo/python-list
Nobody (yes, his name is Nobody) said:
If you're sufficiently concerned about performance that you're willing to
trade clarity for it, you shouldn't be using Python in the first place.
I think the correct thing to say here is, IF you know this subroutine is a
bottleneck, THEN probably this
Chris said
If you actually profile and find that something-or-other is a bottleneck,
chances are you can break it out into a function with minimal loss of
clarity, and then reimplement that function in C (maybe wielding
Cython for the main work). That doesn't compromise clarity.
Well, I'm not
Chris said :
Want some examples of what costs no clarity to reimplement in another
language? Check out the Python standard library. Some of that is implemented in
C (in CPython) and some in Python, and you can't tell and needn't care which.
To ME (a consumer of the CPython library) there is
Ben Finney asked
What workflow requires you to know the filename of the module, within
the module?
So what I have is a project utility script in my scripts directory. I have a
distinct file structure that holds my .py source, my test.py unit tests, and
the file based data associated with the
Steven said -
In a very real sense, Python is just a convenience wrapper around a
bunch of C functions to provide OOP idioms, garbage collection, dynamic
typing, runtime introspection, exceptions, and similar.
I can't really disagree with you in a factual sense, but somehow it doesn't
really
Paul Rubin said:
FYI, there is real though imprecise garbage collection for C. Web
search for Boehm garbage collection should find more info
Very interesting. This wasn't around the last time I launched a C/C++ project
from scratch. Thanks for the tip.
I have to admit, off the top of my head
Rusi said:
Users of GG are requested to read and follow these instructions
https://wiki.python.org/moin/GoogleGroupsPython
Yes, I read those instructions and found them fairly opaque. If you want to
instruct children (odd that I find myself categorized that way on a CS forum,
but whatever)
Rusi said :
Please do! If I were in charge I would say Patches welcome!
Well, I don't really know what the GG best practice ought to be here.
What I am doing now (manually copying whatever I need to quote to give some
context) seems to be tolerable to law enforcement (I guess). But I'm
Am I the only one who finds this function super useful?
def _code_file() :
return os.path.abspath(inspect.getsourcefile(_code_file))
I've got one in every script. It's the only one I have to copy around. For my
workflow ... so handy.
I've got os.path.dirname aliased to dn, so its
I'm surprised no-one is mentioning what seems the obvious pattern here -
exception wrapping.
So you define your exception class as containing the root exception.
Then your specific job routines wrap the exceptions they encounter in your
personal exception class. This is where you go add in
On Monday, October 21, 2013 9:29:34 PM UTC-5, Steven D'Aprano wrote:
On Mon, 21 Oct 2013 01:43:52 -0700, Peter Cacioppi wrote:
Challenge: give some examples of things which you can do in Python, but
cannot do *at all* in C, C++, C#, Java?
Please. No exceptions is huge. No garbage collection
Dave said :
Include a quote from whomever you're responding to, and we might
actually take you seriously. And of course, make sure you don't delete
the attribution.
This forum is working for me. One of the more frequent and sophisticated
posters emailed me saying he appreciates my
Chris The Angel said :
I won't flame you, but I will disagree with you :)
good, that's why I'm here ;)
but there are plenty of things you won't get - and the gap will widen with
very Python release.
Yes I skimmed that laundry list before deciding. I still think I made the right
decision.
Angelico said:
Which is why I mentioned those helpful __future__ directives,
OK, thanks, I'll study the __future__.
I will port to 3.x in less than 60 months, or my name isn't Cacioppi. (So, in
the worst case, I might have to backport a change to my name).
--
It's an interesting issue. Back compatibility was broken with 3.x, which is
always a risky move. Even Bill F*ng Gates was reluctant to break back
compatibility, and he basically ruled the world (for about 20 minutes or so,
but still).
Moreover, you get a lot of the good stuff with 2.7. Along
I said
Even Bill F*ng Gates was reluctant to break back compatibility,
Reluctant to do so with his own stuff. Obviously he embraced and extended
other peoples work. Don't get me started, Gates is Bizarro Guido. Good work
with vaccines though.
--
rusi said :
You continue to not attribute quotes.
Sorry, I'll try to be better about this all-important aspect of sharing
knowledge.
--
https://mail.python.org/mailman/listinfo/python-list
I've written a fair bit of code in pure C, C++, C#, Java and now getting there
in Python.
The difference between C# and Java is fairly minor.
The others have large and significant differences between them. Garbage
collectors or not is huge. Exceptions or not is huge. Dynamic or static typing
Specifically the following seems so misguided as to be deliberate trolling.
One of the reasons multiple languages exist is because people find that
useful programming idioms and styles are *hard to use* or ugly in some
languages, so they create new languages with different syntax to make
those
Just because the CPython implementation does something doesn't mean that thing
is something other than risky/tricky/to-be-avoided-if-possible. Python (and
it's implementations) exist so that ordinary people can avoid doing risky stuff.
I'm not critiquing the CPython implementation here, I'm
but it's ugly, by which I mean it is hard to use, error prone, and not
easily maintained.
OK, I see the problem. What you call ugly is really just objectively bad.
Ugliness and beauty are subjective qualities that can't really be debated on a
deep level. Like I mentioned in other post, I find
The use of getattr here seems unfortunate
Unfortunate how? It's a perfect for what I want here ... remember the context
is such that the lazily stored value is always truthy (I assert this elsewhere).
I'm not sure why you want to avoid an __init__ method.
Why do you want to keep it? The
Why not simply have one, and use it to initialize your attributes,
even if it is to None?
Think about it this way. None here really means not yet initialized. It is a
value that cannot occur naturally and thus functions as a not-initialized flag.
But for different contexts, this value could
You certainly don't have to write a constructor for a subclass in C++.
Ahh, this message board is so collectively well informed (once you get past the
trolls)
The C++ project I worked on was religious about always overwriting parent class
constructors. I had assumed this was because the
At the risk of sounding like a fogey, I actually think I did, at one time, know
the distinctions between our projects protocol and the language proper for
C++. I read Scott Meyers books on C++ and STL a couple of times each and helped
design the protocol that kept us reasonably safe.
But this
That sound you here is Roy Smith hitting the nail on the head re: C++ and Scott
Meyers.
--
https://mail.python.org/mailman/listinfo/python-list
That sound you hear is Roy Smith hitting the nail on the head.
--
https://mail.python.org/mailman/listinfo/python-list
Is the following considered poor Python form?
class Foo (object) :
_lazy = None
def foo(self, x) :
_lazy = _lazy or self.get_something(x)
def get_something(self, x) :
# doesn't really matter
I like this idiom for certain situations, just wondering if it will raise the
On Saturday, October 19, 2013 2:44:55 PM UTC-7, Peter Cacioppi wrote:
Is the following considered poor Python form?
class Foo (object) :
_lazy = None
def foo(self, x) :
_lazy = _lazy or self.get_something(x)
def get_something(self, x) :
# doesn't
Yes, I see the light now. My idiom works, but Steven has shown me the droids I
am looking for.
Thanks!
--
https://mail.python.org/mailman/listinfo/python-list
To be clear, my original post had a goof.
So my original, de-goofed, idiom was
class Foo (object) :
_lazy = None
def foo(self, x) :
self._lazy = self._lazy or self.get_something(x)
def get_something(self, x) :
# doesn't really matter, so long as it returns truthy
I think the author goes a little too far to claim that strong
weak are meaningless terms when it comes to type systems
I can live with that, actually.
The important language classifications are more along the lines of static vs.
dynamic typing, procedural vs. functional, no objects vs. object
give me practicality beats purity any day of the week :)
Without some notion of theory you will end up with php instead of python (see
how I looped the thread back around on track ... you're welcome).
If you think php is no worse than python for building reliable, readable code
bases than
I don't know if I want to step into the flames here, but my understanding has
always been that in the absence of polymorphism the best you can do is object
based programming instead of object oriented programming.
Object based programming is a powerful step forward. The insight that by
What you've said here is that without polymorphism, you can't have
polymorphism. :)
Respectfully, no. I refer to the distinction between object based and object
oriented programming. Wikipedia's entry is consistent with my understanding
(not to argue by wiki-authority, but the terminology
The first C++ compilers were just preprocessors that translated into
pure C code ...
I agree with this.
the C code was reasonably clear, not really convoluted, so you would have
been able to write it yourself.
I disagree with this. My sense of C is that IF you are relying on
My bad, Python is dynamically typed, but also strongly typed.
But I still say it has language features that specifically support
polymorphism, which is why true OO can be developed in Python in a readable way.
--
https://mail.python.org/mailman/listinfo/python-list
You know, I'd heard somewhere that Goto was considered harmful trying to
remember exactly where
--
https://mail.python.org/mailman/listinfo/python-list
Cmon, Skip, assuming everyone gets the considered harmful reference falls
under the we're all adults here rubric.
--
https://mail.python.org/mailman/listinfo/python-list
yes it was a joke, apparently not a good one
On Thu, Oct 17, 2013 at 5:39 PM, Skip Montanaro skip.montan...@gmail.comwrote:
On Oct 17, 2013 6:59 PM, Peter Cacioppi peter.cacio...@gmail.com
wrote:
You know, I'd heard somewhere that Goto was considered harmful
trying to remember
On Tuesday, October 15, 2013 11:55:26 PM UTC-7, Harsh Jha wrote:
I've a huge csv file and I want to read stuff from it again and again. Is it
useful to pickle it and keep and then unpickle it whenever I need to use that
data? Is it faster that accessing that file simply by opening it again
only I'm focusing on the importance of design rather than deifying
the person who designed it.
I'm cool with deification here. I'll happily get on my knees and bow towards
Holland while chanting Guido ... I'm not worthy 5 times a day, if that's
part of the cult.
Want an odd and ranty
On Saturday, October 12, 2013 3:37:58 PM UTC-7, Chris Angelico wrote:
On Sat, Oct 12, 2013 at 7:10 AM, Peter Cacioppi
peter.cacio...@gmail.com wrote:
Along with batteries included and we're all adults, I think Python
needs a pithy phrase summarizing how well thought out
I've dome some reading on the difference between __new__ and __init__, and
never really groked it. I just followed the advice that you should almost
always use __init__.
I recently came across a task that required using __new__ and not __init__. I
was a bit intimidated at first, but it was
On Thursday, October 10, 2013 6:51:21 AM UTC-7, Tim wrote:
I've read a couple of articles about this, but still not sure.
When someone talks about a closure in another language (I'm learning Lua on
the side), is that the same concept as a decorator in Python?
It sure looks like it.
Could someone give me a brief thumbnail sketch of the difference between
multi-threaded programming in Java.
I have a fairly sophisticated algorithm that I developed as both a single
threaded and multi-threaded Java application. The multi-threading port was
fairly simple, partly because Java
On Thursday, October 10, 2013 11:01:25 PM UTC-7, Peter Cacioppi wrote:
Could someone give me a brief thumbnail sketch of the difference between
multi-threaded programming in Java.
I have a fairly sophisticated algorithm that I developed as both a single
threaded and multi-threaded Java
On Thursday, October 10, 2013 11:01:25 PM UTC-7, Peter Cacioppi wrote:
Could someone give me a brief thumbnail sketch of the difference between
multi-threaded programming in Java.
I have a fairly sophisticated algorithm that I developed as both a single
threaded and multi-threaded Java
On Wednesday, October 9, 2013 4:54:03 PM UTC-7, Peter Cacioppi wrote:
I really like the logic that Pythons or is not only short-circuit but
non-typed.
So I can say
y = override or default
and y won't necc be True or False. If override boolean evaluates to True
(which
On Wednesday, October 9, 2013 4:54:03 PM UTC-7, Peter Cacioppi wrote:
I really like the logic that Pythons or is not only short-circuit but
non-typed.
So I can say
y = override or default
and y won't necc be True or False. If override boolean evaluates to True
(which
I really like the logic that Pythons or is not only short-circuit but
non-typed.
So I can say
y = override or default
and y won't necc be True or False. If override boolean evaluates to True
(which, for most classes, means not None) than y will be equal to override.
Otherwise it will be
On Saturday, October 5, 2013 9:04:25 PM UTC-7, John Ladasky wrote:
Hi folks,
I'm trying to make some of Python class definitions behave like the ones I
find in professional packages, such as Matplotlib. A Matplotlib class can
often have a very large number of arguments -- some of
On Saturday, October 5, 2013 9:04:25 PM UTC-7, John Ladasky wrote:
Hi folks,
I'm trying to make some of Python class definitions behave like the ones I
find in professional packages, such as Matplotlib. A Matplotlib class can
often have a very large number of arguments -- some of
On Saturday, October 5, 2013 9:04:25 PM UTC-7, John Ladasky wrote:
Hi folks,
I'm trying to make some of Python class definitions behave like the ones I
find in professional packages, such as Matplotlib. A Matplotlib class can
often have a very large number of arguments -- some of
On Thursday, September 26, 2013 7:23:47 AM UTC-7, Neil Cerutti wrote:
On 2013-09-26, Neil Cerutti ne...@norwich.edu wrote:
def flatten(seq):
[1] http://en.wiktionary.org/wiki/bikeshed
In that spirit, it occurs to me that given current Python
nomenclature, 'flattened' would
On Saturday, September 21, 2013 2:43:13 PM UTC-7, Peter Cacioppi wrote:
This is an idea brought over from another post.
When I write Python code I generally have 2 or 3 windows open simultaneously.
1) An editor for the actual code.
2) The interactive interpreter.
3) An editor
On Saturday, September 21, 2013 2:43:13 PM UTC-7, Peter Cacioppi wrote:
This is an idea brought over from another post.
When I write Python code I generally have 2 or 3 windows open simultaneously.
1) An editor for the actual code.
2) The interactive interpreter.
3) An editor
This is an idea brought over from another post.
When I write Python code I generally have 2 or 3 windows open simultaneously.
1) An editor for the actual code.
2) The interactive interpreter.
3) An editor for the unit tests. (Sometimes skipped for quick one-off scripts)
My work flow tends to
On Thursday, March 21, 2002 2:03:23 PM UTC-7, Marc wrote:
I have classes defined in different files and would like to inherit
from a class in file A.py for a class in file B.py but am running into
problems. I'm using Python 1.5.2 on Windows NT
Here's a specific example:
This is a very old topic, but here is a trick for single inheritance. (The
problem you allude to isn't restricted to multiple inheritance).
Any class with a single parent simply defines this function.
def mySuper(self) :
return super(self.__class__, self)
And then any
, September 18, 2013 4:54:00 PM UTC-7, Peter Cacioppi wrote:
This is a very old topic, but here is a trick for single inheritance. (The
problem you allude to isn't restricted to multiple inheritance).
Any class with a single parent simply defines this function.
def mySuper(self
82 matches
Mail list logo
