[Tutor] How to print fixed length ascii?
How do I set Python to print fixed length ascii--whereby all characters have the exact same length? Thanks. Alex ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] How to print fixed length ascii?
On 16/05/15 05:11, Fast Primes wrote: How do I set Python to print fixed length ascii--whereby all characters have the exact same length? It's not clear what you mean. Do you mean you want to use the ASCII character set? That limits all characters to 7 bits long. If so we probably need a little bit more context about what you are doing with these characters. And whether they are ASCII to start with or if you need to do some data conversion first. What/how/where you are 'printing' them. Or do you really mean you want a fixed width font so that all characters take up the same amount of screen space? In that case the issue lies with your environment and not with Python. How are you running the program? (OS, Tools, Terminal type etc) Or if you are writing a GUI how you are displaying the text - what kind of widget?. -- 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 ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] How to print fixed length ascii?
On Sat, May 16, 2015 at 04:11:45AM +, Fast Primes wrote: > > How do I set Python to print fixed length ascii--whereby all characters have > the exact same length? Use a fixed-width font, also known as a non-proportional, monospaced or typewriter typeface. E.g. Monaco (Apple Mac), Courier (Windows), Liberation Mono (Linux) etc. Does that answer your question? If not, you will need to give more detail. -- Steve ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Terminology question
On 15 May 2015 at 22:45, Steven D'Aprano wrote:
>
> What does "didn't work" mean? Did your computer crash? Catch fire? A
> completely different error got printed? Something else?
I can see I was marvelously unclear ;') Here is what I meant.
def make_error():
raise ZeroDivisionError('Here I am')
def call_error():
try:
make_error()
except:
print("How do I get the 'Here I am' message to print in the calling
routine?")
>>> call_error()
How do I get the 'Here I am' message to print in the calling routine?
--
Jim
"What a rotten, failed experiment. I'll start over. Maybe dogs instead of
monkeys this time." --God
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Terminology question
On 16/05/15 17:56, Jim Mooney Py3.4.3winXP wrote:
I can see I was marvelously unclear ;') Here is what I meant.
def make_error():
raise ZeroDivisionError('Here I am')
def call_error():
try:
make_error()
except:
print("How do I get the 'Here I am' message to print in the calling
routine?")
call_error()
How do I get the 'Here I am' message to print in the calling routine?
And the remainder of Steven's reply showed you how, using the
args attribute of the error.
--
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
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Terminology question
On Sat, May 16, 2015 at 09:56:33AM -0700, Jim Mooney Py3.4.3winXP wrote:
> def make_error():
> raise ZeroDivisionError('Here I am')
>
> def call_error():
> try:
> make_error()
> except:
> print("How do I get the 'Here I am' message to print in the calling
> routine?")
Okay, here is a hint for you:
Every time you use a bare "except", god kills a puppy. Please, won't you
think of the poor little puppies?
All joking aside, using a bare except is *nearly always* not what you
want, and poor practice. The problem is that it catches too much, and so
masks bugs that should be fixed. You should only catch exceptions that
you know about and that you can recover from. Everything else is an
indication that your code has a bug that needs fixing.
But, having said that, sometimes I'm lazy too, and when experimenting at
the interactive interpreter, I just write "except:" without specifying a
specific exception. Just don't let it become a habit in real code.
> >>> call_error()
> How do I get the 'Here I am' message to print in the calling routine?
The easiest and best way is to just *not* catch the exception and let
Python print a traceback. But if you want to look at the error message
while recovering from the exception, you have to catch and name the
exception. You can specify multiple types by using a tuple of exception
types:
try:
...
except (TypeError, ValueError) as err:
print(err.args[0])
Notice that there is no supported syntax for leaving the exception type
blank while still naming it.
Remember that exceptions are objects too, and the various exception
types are classes. You can subclass them to make your own types:
class MyValueError(ValueError):
pass
raise MyValueError
Also, all exceptions inherit from a single class: BaseException. So you
can say:
except BaseException as error
which is (nearly[1]) the same as a bare except clause, but giving it a
name. Normally, however, that's not what you want, since that will also
catch things like the user typing Ctrl-C to interrupt a infinite loop,
and other exceptions which don't represent errors.
To just catch errors, use "except Exception as error", then inspect
error.args[0].
[1] There is one slight difference. Up to Python 2.5, you could raise
and catch strings as well as exceptions. This turned out to be a bad
idea, and was finally removed in 2.6. But if you are running 2.5 or
older, a bare except clause is the only way to catch string exceptions
unless you know exactly what string it it.
--
Steve
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
[Tutor] Python property()
I came across some code where 'property' is being used for class attributes (or as a decorator @property) name = property(lambda self: getattr(self, '_data')['name']) I think I understand what's going on here. What I don't understand is if/when to use property instead of a normal attribute. 1. Is 'property' used widely? Do you use it? Do you know of a github project where I can look at the code using it? I am looking for more examples. 2. Would you use it only when you need to validate or calculate the value to be assigned to an attribute or is there any other place for 'property()' to be used? 3. If there is value in learning and using property, kindly explain it or point me to a document/writeup/book that I should read to get a better understanding. Thanks d/ ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Python property()
On 16/05/15 20:25, daaku gee wrote: I think I understand what's going on here. What I don't understand is if/when to use property instead of a normal attribute. 1. Is 'property' used widely? Do you use it? No, Yes, occasionally I first came across properties in Borland Delphi (Object Pascal) and found them useful there because there was quite a bit of emphasis on data hiding. After I moved to Python which has a much more open approach to data I find them less useful. 2. Would you use it only when you need to validate or calculate the value to be assigned to an attribute or is there any other place for 'property()' to be used? Those are the main use cases for me. Calculating values can be an important one though, especially if it avoids the need for lots of methods to update some attribute like size. You can calculate it at runtime and expose the method to look like a data item. But that in itself can be done by a method, the real driver to a property is when I'm using the class in a polymorphic relationship with other classes that do have a data attribute and I want mixed access with a common interface. 3. If there is value in learning and using property, kindly explain it or point me to a document/writeup/book that I should read to get a better understanding. Oddly enough I'm currently reviewing a book that addresses this quite well in a chapter on properties. But it won't be published till later in the year so not much help to you just now. Personally I wouldn't worry about them until you think you've found a real use for them. There are plenty other things to be doing first! -- 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 ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Python property()
As Alan and I disagree on this, to a degree, I thought I would follow up to add another perspective. Remember that it is _only_ perspective; Alan's opinions are sound and have good reasons. So are mine:-) We place different values on the costs and benefits here. On 17May2015 00:27, alan.ga...@btinternet.com wrote: On 16/05/15 20:25, daaku gee wrote: I think I understand what's going on here. What I don't understand is if/when to use property instead of a normal attribute. 1. Is 'property' used widely? Do you use it? No, Yes, occasionally For me: somewhat, and yes. [...snip...] 2. Would you use it only when you need to validate or calculate the value to be assigned to an attribute or is there any other place for 'property()' to be used? Those are the main use cases for me. Calculating values can be an important one though, especially if it avoids the need for lots of methods to update some attribute like size. You can calculate it at runtime and expose the method to look like a data item. But that in itself can be done by a method, the real driver to a property is when I'm using the class in a polymorphic relationship with other classes that do have a data attribute and I want mixed access with a common interface. Here we differ, at least in where we draw the line. I am very fond of the "property to calculate a value". It makes for more readable code: foo.volume() + bah.volume() versus foo.volume + bah.volume with less syntactic noise. The "foo" and "bah" objects here might compute their volume from their more basic attributes, perhaps length, height etc. For Alan, using a property here provides no fundamental advantage over a method call, especially since a property _is_ a method call underneath. He feels that it breaks the OO model and as he mentions above, makes polymorphic use harder because different types of objects might readily provide a .volume() method but not a property. For me, when the property such as .volume is (a) a basic thing trivially and _repeatably_ computed from the other attributes and (b) cheap (usually O(1) to compute, not requiring complex and expensive operations) and (c) having no side effects such as creating files etc then I may often choose to use a property. To me, the method/property distinction is in how the value it thought of: A "computed", potentially complex or changing thing. This is a method. A "direct" and simple thing, almost free to compute and (usually) stable. This may be a property. If you need to pass parameters other than "self", obviously it must be a method. 3. If there is value in learning and using property, kindly explain it or point me to a document/writeup/book that I should read to get a better understanding. Oddly enough I'm currently reviewing a book that addresses this quite well in a chapter on properties. But it won't be published till later in the year so not much help to you just now. Personally I wouldn't worry about them until you think you've found a real use for them. There are plenty other things to be doing first! I'm in agreement here. Become comfortable with methods and using them. Until that is second nature you won't have much feel for when you may choose to use a property. Cheers, Cameron Simpson Heavier-than-air flying machines are impossible. --Lord Kelvin, president, Royal Society, 1895. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
