it so, you have my
> sympathy.
You re-enforce the point you're trying to counter beautifully. Thanks
for driving my argument home.
Regards,
Aldo
--
Aldo Cortesi
M: +61 419 492 863
P: +61 1300 887 007
W: www.nullcube.com
--
http://mail.python.org/mailman/listinfo/python-list
by then we'll all be too busy swanning about in our flying cars and
having holidays on Mars to care. ;)
So, no, I don't think inclusion in the standard library should be a
universal ambition, and it's certainly not one I have for Pry.
Regards,
Aldo
--
Aldo Cor
ibe this -
saying that these frameworks support "expanded error reporting for
Python assert statements" might be more accurate.
Regards,
Aldo
--
Aldo Cortesi
M: +61 419 492 863
P: +61 1300 887 007
W: www.nullcube.com
--
http://mail.python.org/mailman/listinfo/python-list
erous
part is converting to assertion-based testing, something that will
improve the clarity and readability of your tests anyway.
Regards,
Aldo
--
Aldo Cortesi
M: +61 419 492 863
P: +61 1300 887 007
W: www.nullcube.com
--
http://mail.python.org/mailman/listinfo/python-list
I might experiment with extending Pry to gather and run
doctests and unittests. At this stage, however, I don't believe the
(significant) effort would be worth it.
Regards,
Aldo
--
Aldo Cortesi
M: +61 419 492 863
P: +61 1300 887 007
W: www.nullcube.com
--
http://mail.python.org/mai
t it is Kay and and indeed you who are temporarily out of
line with the tone of the list. A more impartial re-reading of the
debate so far might make you judge my final, admittedly angry, response
more fairly.
Regards,
Aldo
--
Aldo Cortesi
M: +61 419 492 863
P: +61 1300 887 00
might add. To me, this means the
burden is not worth it. Since I designed and wrote Pry, I get to make
that choice, not you, and the type of feeble, offensive "argument"
you've provided is unlikely to change my mind.
Regards,
Aldo
--
Aldo Cortesi
M: +61 419 492 863
P: +61 1300 887 007
W: www.nullcube.com
--
http://mail.python.org/mailman/listinfo/python-list
;m just going to have to assure you that I do in fact know
what I'm talking about, and leave it at that. Never fear - I will
personally ensure that Pry's vast, fanatical legion of goose-stepping
users does not force you to use it if you don't want to...
Regards,
Aldo
--
Aldo Cor
less, of course,
you were joking and that was precisely the point you were trying to
make... in which case I apologise and you can ignore this... ;)
Regards,
Aldo
--
Aldo Cortesi
M: +61 419 492 863
P: +61 1300 887 007
W: www.nullcube.com
--
http://mail.python.org/mailman/listinfo/python-list
r some reason, that IS a big advantage. If, however, you
plan to use any of nose's advanced features, you will be incompatible
with unittest anyway, and you should feel free to consider competing
suites like test.py and Pry.
Regards,
Aldo
--
Aldo Cortesi
M: +61 419 492 863
P: +61 1300 887 007
W: www.nullcube.com
--
http://mail.python.org/mailman/listinfo/python-list
y and see what you think.
Regards,
Aldo
--
Aldo Cortesi
Managing Director
M: +61 419 492 863
P: +61 1300 887 007
W: www.nullcube.com
--
http://mail.python.org/mailman/listinfo/python-list
use it has Java
> style naming conventions i.e. for bike shading reasons
Do you mean bike shedding, perhaps? At any rate, your impression is
mostly incorrect.
Regards,
Aldo
--
Aldo Cortesi
M: +61 419 492 863
P: +61 1300 887 007
W: www.nullcube.com
--
http://mail.python.org/mailman/listinfo/python-list
omething
you want, maybe you should give Pry another look. If Pry itself is not
to your taste, there are other excellent test frameworks like py.test
that have also chosen not to mindlessly duplicate all of unittest's
inadequacies. Broaden your horizons and explore some of these - your
code wil
letting me know about this. I've just released version
0.2.1 of Pry, which addresses this and a few other Windows
compatibility issues. You can download it here:
http://dev.nullcube.com/download/pry-0.2.1.tar.gz
Regards,
Aldo
--
Aldo Cortesi
M: +61 419 492 863
P: +61 1300 887 007
W: www.nullcube.com
--
http://mail.python.org/mailman/listinfo/python-list
Voila! You have a nice command-line interface, coverage analysis, and
an easy path to saner, better-engineered unit tests.
Internal consistency in this case is much more important than the style
guide, which intends only to standardise naming conventions within the
Python standard library, and even
here you can instantiate a Template once and use it many times
Cubictemp should be very fast.
Regards,
Aldo
--
Aldo Cortesi
M: +61 419 492 863
P: +61 1300 887 007
W: www.nullcube.com
--
http://mail.python.org/mailman/listinfo/python-list
fixture management
* No implicit instantiation of test suits
* Powerful command-line interface
Download: http://dev.nullcube.com
Manual: http://dev.nullcube.com/doc/pry/index.html
--
Aldo Cortesi
M: +61 419 492 863
P: +61 1300 887 007
W: www.nullcube.com
--
http://mail.python.org/mailman
templating systems out there. Cubictemp proves that a templating
sytem can be elegant, powerful, fast and remain compact.
Download: http://dev.nullcube.com
Manual: http://dev.nullcube.com/doc/cubictemp/index.html
--
Aldo Cortesi
M: +61 419 492 863
P: +61 1300 887 007
W: www.nullcube.com
lly "clean" code (say, from a
> submitted patch) with a tool because I can't reliably verify it by eye.
Surely, in context, the meaning is clear? "By eye" here means nothing more nor
less than a literal reading suggests. Taking these sentences to be an arg
the more obvious problems with your technically
illiterate hope that one could homogenize characters so that everything that
looks the same has the same meaning. Fiddle around with your fontsets a bit -
you only have to find one combination where the two glyps look the same to
prove my case...
Regards,
Aldo
--
Aldo Cortesi
[EMAIL PROTECTED]
http://www.nullcube.com
Mob: 0419 492 863
--
http://mail.python.org/mailman/listinfo/python-list
re is no general way to detect homoglyphs and "convert them to
a normal form". Observe:
import unicodedata
print repr(unicodedata.normalize("NFC", u"\u2160"))
print u"\u2160"
print "I"
So, a round 0 for reading comprehension this lesson, I'm afra
fferent from typos in ASCII. There's no doubt that we'll give
> the same answer we've always given for this problem: unit tests, pylint
> and pychecker.
A typo that can't be detected visually is fundamentally different problem from
an ASCII typo, as many people in this thr
ters do. There is no doubt that people will accidentally
introduce mistakes into their code because of this.
> - would you use them if it was possible to do so? in what cases?
No.
Regards,
Aldo
--
Aldo Cortesi
[EMAIL PROTECTED]
http://www.nullcube.com
Mob: 0419 492 863
--
er. Just use "raw_input" instead - it just takes input from a
user without evaluating it as a Python expression, and will bring order and
predictability to whatever it is you want to do.
Cheers,
Aldo
--
Aldo Cortesi
[EMAIL PROTECTED]
http://www.nullcube.com
Mob: 0419 492 863
--
http://mail.python.org/mailman/listinfo/python-list
"Please enter only the number beside your choice"
> print
> x = input("> ")
Well, leaving aside the merits of using "input" (which should be avoided at all
costs), here's one way to do what you want:
while 1:
try:
get. In your case, you probably want
something like:
def __init__(self, folders = None):
if folders is None:
self.folders = []
Cheers,
Aldo
--
Aldo Cortesi
[EMAIL PROTECTED]
http://www.nullcube.com
Off: (02) 9283 1131
Mob: 0419 492 863
--
http://m
co_filename
This will give you the file name and line number. If you want the actual text
of the line, you can simply read the information from the file.
Cheers,
Aldo
--
Aldo Cortesi
[EMAIL PROTECTED]
http://www.nullcube.com
Off: (02) 9283 1131
Mob: 0419 492 863
--
http://mail.python.org/mailman/listinfo/python-list
I'm using Ubuntu Linux 5.04 (Hoary), and
> wrote the script with gedit.
It doesn't have anything to do with Python. I'm pretty sure
you'll find that the file is created by your editor as a
backup or a running store of some kind. Try just editing a
random non-python file with t
ead more, the keyword you're looking for is
"closure" - a quick search on Google for "python closure"
should satisfy your curiosity handily. There is also a neat
recipe for inspecting the values kept in the func_closure
attribute of function objects directly:
http://a
't
do the same thing - rstrip will return a copy of your string
with any number of trailing '/'es removed. If there aren't
any, it will return the string as-is. The string access
method will always chop exactly one character off the end.
Even though the results for y
t;, time.time()-start
if __name__ == "__main__":
main()
Cheers,
Aldo
--
Aldo Cortesi
[EMAIL PROTECTED]
http://www.nullcube.com
Off: (02) 9283 1131
Mob: 0419 492 863
--
http://mail.python.org/mailman/listinfo/python-list
HTTP and FTP) so that it can be
logged, monitored, tracked, and controlled.
This is the strategy I recommend to my clients - the only
sensible one in a world of spyware, worms, insecure web
browsers and corporate espionage...
Cheers,
Aldo
--
Aldo Cortesi
[EMAIL PROTECTED]
http://www.nu
usly logged information. Try append mode
("a") instead.
Cheers,
Aldo
--
Aldo Cortesi
[EMAIL PROTECTED]
http://www.nullcube.com
Off: (02) 9283 1131
Mob: 0419 492 863
--
http://mail.python.org/mailman/listinfo/python-list
33 matches
Mail list logo