Re: compile Py2.6 on SL
Am 16.09.2010 17:34, schrieb moerchendiser2k3: > Hi, > > I have some trouble with Python on Snow Leopard (10.6.3). I compile > Python as a framework(for 32/64bit) without any problems. > But implementing the lib in my C app, I get the following error on > linking: > > Undefined symbols: > "_Py_InitModule4_64", referenced from: > RegisterModule_BPY(char const*, PyMethodDef*, char const*, > _object*, int)in i_moduleobject.o > ld: symbol(s) not found > > I read a lot of stuff about this problem, but nothing helped me. My > app is in 64-bit and I compiled Python for 32/64bit. I'm skeptical that you did - if you really *had* compiled Python for AMD64, this error would not have occured. Please use file/lipo to verify that the Python library really is available as 64-bit code. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Learning inheritance
On Sep 18, 11:15 pm, Jorgen Grahn wrote:
> On Sat, 2010-09-18, Niklasro wrote:
> > Hi
> > How can I make the visibility of a variable across many methods or
> > files? To avoid repeating the same line eg url =
> > os.environ['HTTP_HOST'] if os.environ.get('HTTP_HOST') else
> > os.environ['SERVER_NAME'] I repeat for many methods. So declaring it
> > to a super class and inheriting it is my plan. Do you agree or propose
> > otherwise?
>
> Inheritance is not the main tool for sharing code. Just make it a
> function and place it in one of your modules (files):
>
> def get_host():
> """Return the environment's $HTTP_HOST if
> it exists, otherwise $SERVER_NAME or (if that
> doesn't exist either) None.
> """
> ...
>
> Perhaps you are focusing too much on inheritance in general.
> I personally almost never use it in Python -- it has much fewer
> uses here than in staticaly typed languages.
>
> /Jorgen
>
> --
> // Jorgen Grahn \X/ snipabacken.se> O o .
Thanks for sharing the knowledge. I alternatively think about
declaring the variable in a setting.py file and import it. It doesn't
create many objects but I want to learn more professional code
conventions than same test repeated.
Sincerely,
Niklas R
--
http://mail.python.org/mailman/listinfo/python-list
Re: Learning inheritance
On Sep 19, 2:31 am, alex23 wrote:
> Niklasro wrote:
> > I got 2 files main.py and i18n both with
> > webapp request handlers which I would like access the variable.
>
> I'd probably use a module for this. Create a third file, called
> something like shared.py, containing the line that bruno gave above:
>
> url = os.environ.get("HTTP_HOST", os.environ["SERVER_NAME"])
>
> Then from within both main & i18n you can 'import shared' and access
> the variable as 'shared.url'.
>
> Python only actually executes a module the first time it's imported,
> every other import will be given a reference to the same module
> object. This also lets you share temporary data between modules. Any
> module that imports 'shared' can add an attribute to it ('shared.foo =
> "barbaz"') that will be visible to all other modules that have (or
> will have) imported it.
I try a file setting.py declaring it like this just loose in the file
not knowing much theory about it thinking it's easy and intuitive.
Thanks
Niklas
--
http://mail.python.org/mailman/listinfo/python-list
Re: Learning inheritance
It works but I don't know whether it's formally inheritance or class
variable.
Before code was
url = os.environ['HTTP_HOST'] if os.environ.get('HTTP_HOST') else
os.environ['SERVER_NAME']
if url.find('niklas') > 0:
and now the change saves me from repeating myself!
util.py:
url = os.environ.get("HTTP_HOST", os.environ["SERVER_NAME"]) #declared
as class variable(?)
And viola just test if util.url.find('niklas') > 0:
Exactly what I wanted to do with your experienced guidance.
Many thanks
Happy refactored
--
http://mail.python.org/mailman/listinfo/python-list
Re: Plz comment on this code
fridge wrote: > # bigdigits2.py > > import sys > > zero=["***", >"* *", >"***"] > one=["***", > " * ", > "***"] > digits=[zero,one,zero,one,zero,one,zero,one,zero,one] > > inputted_digit=sys.argv[1] > column_max=len(inputted_digit) > row_max=3 > > r=0 > while r<3: > line="" > c=0 > while c digit_i=int(inputted_digit[c]) > digit=digits[digit_i] > line+=digit[r] > line+=" " > c+=1 > print(line) > r+=1 - Add a docstring at the beginning of the script explaining what it is meant to do. - Use four-space indent; add a space between names and operators. - Replace the while-loops with for-loops. You can iterate over numbers and characters: >>> for i in range(3): ... print(i) ... 0 1 2 >>> for c in "abc": ... print(c) ... a b c Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 2010-09-19, Steven D'Aprano wrote: > Define "unbalanced". I'm not sure that's the word I'd use. I'm not even sure what it would mean here. > Putting aside the over-use of punctuation, The C syntax feels unbalanced > to me. You have: > condition IF true-clause ELSE false-clause > so both clauses follow the test, that is, they're on the same side: ?-- Yes. Just like: if condition: foo else: bar The condition is the primary, the clauses are secondary to it. So I like that form because it matches what I'd write if I were writing things out more verbosely for some reason. > But the Python syntax looks balanced to me: > true-clause IF condition ELSE false-clause > which is not only plain English, but perfectly balanced, with a clause on > either side of the test: -?- It may be balanced, but it requires you to reevaluate what you're reading after you've already read something that seemed to have a clear meaning. Basically, think of what happens as I read each symbol: x = x + 1 if condition else x - 1 Up through the '1', I have a perfectly ordinary assignment of a value. The, suddenly, it retroactively turns out that I have misunderstood everything I've been reading. I am actually reading a conditional, and the things I've been seeing which looked like they were definitely part of the flow of evaluation may in fact be completely skipped. It's even more confusing if I'm familiar with the postfix-if as seen in, say, perl or ruby. > Python's ternary-if puts the emphasis on the true-clause, while C's > ternary-if puts the emphasis on the test. I'm not convinced that this is > necessarily a better choice than Python's. It's a *valid* choice, but > better? I don't think so, but I accept that at least partially boils down > to subjective factors. I would usually think it better, just because most often, the *fact* of there being a test is the first thing you have to know about the expression to make sense of it. If I am given the right framework first, and the information to fill into it second, I don't have to throw away parsing I'd already done. If I'm given information, then later retroactively told to move it into a slot in a framework I didn't even know I was going to need, I have to do a lot of reworking. Consider the following lovely hypothetical syntax: foo bar baz if condition else: blah blah blah And there, at least you have some cue that you're about to see something happen. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 2010-09-19, Steven D'Aprano wrote: > I'm not entirely sure I agree with you here... you can't ignore syntax in > order to understand the meaning of code. No, but the syntax should be invisible. When I read English, I don't have to think about nouns and verbs and such unless something is very badly written. The syntax is handled automatically at a lower level without conscious intervention, as it should be. Calling my conscious attention to it is disruptive. > The term "syntax highlighting" for what editors I've seen do is actually > misleading -- they don't highlight *syntax*, they try to highlight > *semantics*. I've never seen this. I've seen things highlight comments and keywords and operators and constants and identifiers differently. > When your editor highlights the function len() in the > expression "x = len(y) + spam(z)" but not the function spam(), you know > it has nothing to do with syntax. len() is singled out because of its > semantics, namely the fact that it's a built-in. Eww. (I had not yet gotten to the point of finding out that whether something was "built-in" or not substantially affected its semantics.) > In English, the meaning of the some sentences do benefit by syntax > highlighting, and in fact that's partly what punctuation is for: English > partly uses punctuation marks as tags to break the sentence structure > into sub-sentences, clauses and terms (particularly when the sentence > would otherwise be ambiguous). Punctuation is very different from highlighting, IMHO. That said, I find punctuation very effective at being small and discrete, clearly not words, and easy to pick out. Color cues are not nearly as good at being inobtrusive but automatically parsed. > "Woman shoots man with crossbow" > Was it the man armed with a crossbow, or the woman? If we could somehow group > the > clause "with crossbow" with "woman" or "man" by something *other* than > proximity, we could remove the ambiguity. Yes. But syntax highlighting won't help you here -- at least, I've never yet seen any editor that showed precedence relations or anything similar in its coloring. > Bringing it back to Python, that's why punctuation like : are useful. > They're syntax highlighting. I don't think they are, though. I think punctuation is fundamentally different in intent and purpose from colorizing things based on whether they're, say, constants or identifiers or comments or keywords. The punctuation is *itself* part of the syntax -- it's not being highlighted. Syntax highlighting is putting all the punctuation in green so you know it's punctuation. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Learning inheritance
On 2010-09-19 09:22, Niklasro wrote:
> util.py:
> url = os.environ.get("HTTP_HOST", os.environ["SERVER_NAME"]) #declared
> as class variable(?)
>
There is no class here, so this is no class variable, and you're not
inheriting anything. You're simply using a module.
> And viola just test if util.url.find('niklas') > 0:
>
> Exactly what I wanted to do with your experienced guidance.
>
> Many thanks
> Happy refactored
>
--
http://mail.python.org/mailman/listinfo/python-list
Re: Learning inheritance
On Sep 19, 8:12 am, Thomas Jollans wrote:
> On 2010-09-19 09:22, Niklasro wrote:> util.py:
> > url = os.environ.get("HTTP_HOST", os.environ["SERVER_NAME"]) #declared
> > as class variable(?)
>
> There is no class here, so this is no class variable, and you're not
> inheriting anything. You're simply using a module.
>
> > And viola just test if util.url.find('niklas') > 0:
>
> > Exactly what I wanted to do with your experienced guidance.
>
> > Many thanks
> > Happy refactored
>
>
Good to learn what I'm doing :-) since important being able to explain
choices taken farther than "doing it because it works".
I understand the concept of modules may not correspond to java
programming where I come from.
Sincerely with thanks for the help,
Niklas
--
http://mail.python.org/mailman/listinfo/python-list
Re: Plz comment on this code
Your code works (assuming digits gets populated fully), but it's the
absolute bare minimum that would.
To be brutally honest it's:
- unpythonic - you've not used the core features of Python at all,
such as for loops over a sequence
- poorly formatted - Please read the python style guide and follow it
- not reusable - Your code can only be called from the command line,
it should be usable as a module
- not documented - There is no indication what this code does, other
than mentally running it
- Fragile - There is no error checking on user input
There are other ways to write what you have more concisely (e.g. list
comprehensions, iterators) but those can wait for another time. Here
is a start at improving your code wrt to the above points:
#!/usr/bin/env python3
# bigdigits2.py
ZERO = ["***", # NB Constants are by convention ALL_CAPS
"* *",
"***"]
ONE = ["** ",
" * ",
"***"]
# TODO Define and populate digits 2-9
DIGITS = [ZERO, ONE, ZERO, ONE, ZERO, ONE, ZERO, ONE, ZERO, ONE]
def big_digits(str_of_digits):
"""Return a list of lines representing the digits using 3x3 blocks
of "*"
"""
banner = [] # Accumulate results in this
# Loop over the rows/lines of the result
# TODO Replace hard coded block size with global constant or
measured size
for row in range(3):
line_parts = []
# Assemble the current line from the current row of each big
digit
for digit in str_of_digits:
big_digit = DIGITS[int(digit)]
line_parts.append(big_digit[row])
# Create a string for the current row and add it to the result
line = " ".join(line_parts)
banner.append(line)
return banner
def usage():
print("Usage: bigdigit.py ", file=sys.stderr)
sys.exit(1)
if __name__ == "__main__":
import sys
# Check that an argument was passed
# NB This will ignore additional arguments
if len(sys.argv) >= 2:
input_string = sys.argv[1]
else:
usage()
# Check that only digits were passed
if not input_string.isnumeric():
usage()
# All is well, print the output
for line in big_digits(input_string):
print(line)
Here are some suggested further improvements:
- Map directly from a digit to it's big digit with a dictionary,
rather than indexing into a list:
BIG_DIGITS = {
"1": ["** ",
" * ",
"***"],
# ...
}
- Is input_string.isnumeric() the right test? Can you find a character
it would not correctly flag as invalid input?
- What if I wanted to use my own 4x4 big digits? Could the
big_digits() function accept it as an argument?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Plz comment on this code
In message , Alex Willmer wrote: > # NB Constants are by convention ALL_CAPS SAYS_WHO? -- http://mail.python.org/mailman/listinfo/python-list
Re: Plz comment on this code
In message <4c957412$0$3036$afc38...@news.optusnet.com.au>, fridge wrote: > digits=[zero,one,zero,one,zero,one,zero,one,zero,one] digits = [zero, one] * 5 > row_max=3 Defined but never used. > digit_i=int(inputted_digit[c]) > digit=digits[digit_i] > line+=digit[r] > line+=" " Too many intermediate variables only defined and used once. Do this all on one line. -- http://mail.python.org/mailman/listinfo/python-list
Re: Cross Compiling Python for ARM
In message <4c911670$0$41115$e4fe5...@news.xs4all.nl>, Hans Mulder wrote: > The most popular way to get the latter problem is to write the script > on a Windows box and then upload it to Unix box using FTP in binary > mode (or some other transport that doesn't adjust the line endings). I always thought it was a misfeature that the Linux kernel doesn’t recognize all the common conventions for ending the shebang line. All reading of text files should be similarly tolerant. -- http://mail.python.org/mailman/listinfo/python-list
Re: program organization question for web development with python
In message <6102316a-d6e6-4cf2-8a1b-ecc5d3247...@w15g2000pro.googlegroups.com>, Hans wrote: > print """%s""" % > (record[0],table_name,cursor_name,record1) I would recommend avoiding filename extensions in your URLs wherever possible. For executables, in particular, leaving out the “.py” or “.pl” or whatever makes it easier to switch languages, should you need to in future. -- http://mail.python.org/mailman/listinfo/python-list
Re: Plz comment on this code
On Sep 19, 12:20 pm, Lawrence D'Oliveiro wrote: > In message > , Alex > > Willmer wrote: > > # NB Constants are by convention ALL_CAPS > > SAYS_WHO? Says PEP 8: Constants Constants are usually declared on a module level and written in all capital letters with underscores separating words. Examples include MAX_OVERFLOW and TOTAL. -- http://www.python.org/dev/peps/pep-0008/ -- http://mail.python.org/mailman/listinfo/python-list
Re: [DB-SIG] dbf files and compact indices
Ethan Furman wrote: > Carl Karsten wrote: >> On Sat, Sep 18, 2010 at 11:23 PM, Ethan Furman >> wrote: >>> Thanks for the suggestion, but I don't want to be tied to Foxpro, which >>> means I need to be able to parse these files directly. I have the dbf >>> files, now I need the idx and cdx files. >> >> >> >> What do you mean "tied" ? > > I meant having to have Foxpro installed. I just learned from another > reply that I may not have to have Foxpro installed as long as I have the > Foxpro ODBC driver, because then I could use odbc instead of fiddling > with the files directly. > > While I may switch over to odbc in the future, I would still like to > have the idx/cdx components. If you are working on Windows, you can install the MS MDAC package to get a hold of the MS FoxPro ODBC drivers. They are usually already installed in Vista and 7, in XP they comes with MS SQL Server and MS Office as well. mxODBC can then provide Python access on Windows, mxODBC Connect on other platforms. If you want direct files access on other platforms, you can use http://pypi.python.org/pypi/dbf/ or http://dbfpy.sourceforge.net/. If you want to add support for index files (which the above two don't support), you could also have a look at this recipe for some inspiration: http://code.activestate.com/recipes/362715-dbf-reader-and-writer/ -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 19 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ -- http://mail.python.org/mailman/listinfo/python-list
Re: This Is International Don’t-Squawk-Like-A -Parrot Day
On 09/18/10 23:46, Lawrence D'Oliveiro wrote: Do your bit to help stamp out parrocy. Did you send this by mistake? It looks like a parroty-error. I think it's a bit off... -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: ctypes and buffers
On Sunday 19 September 2010, it occurred to Carl Banks to exclaim: > I am creating a ctypes buffer from an existing non-ctypes object that > supports buffer protocol using the following code: > > > from ctypes import * > > PyObject_AsReadBuffer = pythonapi.PyObject_AsReadBuffer > PyObject_AsReadBuffer.argtypes = > [py_object,POINTER(c_void_p),POINTER(c_size_t)] > PyObject_AsReadBuffer.restype = None > > def ctypes_buffer_from_buffer(buf): > cbuf = c_void_p() > size = c_size_t() > PyObject_AsReadBuffer(buf,byref(cbuf),byref(size)) > return cbuf > If I understand what you are doing correctly, you're referencing a Python buffer object and returning a pointer wrapped in some ctypes thingy. hmm. I see some problems in your code: * You're not passing the size along. In the name of sanity, why on earth not?! The pointer cannot be safely used without knowing how long the area of memory referenced is! * You're using the old buffer protocol. You might rather implement this with the one introduced with Python 3.0, and supported in 2.6 as well. > > It works, but is there a standard way to do this in ctypes? I > couldn't find anything in the documentation. Python 2.6 for now. > Thanks. > > > Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: C++ - Python API
In article , Thomas Jollans wrote: >On Wednesday 01 September 2010, it occurred to Markus Kraus to exclaim: >> >> So the feature overview: > >First, the obligatory things you don't want to hear: Have you had >a look at similar efforts? A while ago, Aahz posted something very >similar on this very list. You should be able to find it in any of the >archives without too much trouble. You almost certainly have me confused with someone else -- I wouldn't touch C++ with a ten-meter pole if I could possibly help it. (The last time I dealt with C++ code, about a decade ago, I just rewrote it in C.) -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "The volume of a pizza of thickness 'a' and radius 'z' is given by pi*z*z*a" -- http://mail.python.org/mailman/listinfo/python-list
Re: This Is International Don’t-Squawk-Like-A -Parrot Day
In article , Tim Chase wrote: >On 09/18/10 23:46, Lawrence D'Oliveiro wrote: >> >> Do your bit to help stamp out parrocy. > >Did you send this by mistake? It looks like a parroty-error. I >think it's a bit off... Agh! -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "The volume of a pizza of thickness 'a' and radius 'z' is given by pi*z*z*a" -- http://mail.python.org/mailman/listinfo/python-list
Down with tinyurl! (was Re: importing excel data into a python matrix?)
In article , geremy condra wrote: >On Wed, Sep 1, 2010 at 4:35 PM, patrick mcnameeking > wrote: >> >> I've been working with Python now for about a year using it primarily for >> scripting in the Puredata graphical programming environment. I'm working on >> a project where I have been given a 1000 by 1000 cell excel spreadsheet and >> I would like to be able to access the data using Python. Does anyone know >> of a way that I can do this? > >http://tinyurl.com/2eqqjxv Please don't use tinyurl -- it's opaque and provides zero help to anyone who might later want to look it up (and also no accessibility if tinyurl ever goes down). At the very least, include the original URL for reference. (Yes, I realize this is probably a joke given the smiley I excised, but too many people do just post tinyurl.) -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "The volume of a pizza of thickness 'a' and radius 'z' is given by pi*z*z*a" -- http://mail.python.org/mailman/listinfo/python-list
Re: This Is International Don’t-Squawk-Like-A -Parrot Day
On Sep 19, 2010, at 7:37 AM, Tim Chase wrote: > On 09/18/10 23:46, Lawrence D'Oliveiro wrote: >> Do your bit to help stamp out parrocy. > > Did you send this by mistake? It looks like a parroty-error. I think it's a > bit off... What an wkward thing to say. Are you crackers? -- http://mail.python.org/mailman/listinfo/python-list
Re: C++ - Python API
On Sunday 19 September 2010, it occurred to Aahz to exclaim: > In article , > > Thomas Jollans wrote: > >On Wednesday 01 September 2010, it occurred to Markus Kraus to exclaim: > >> So the feature overview: > >First, the obligatory things you don't want to hear: Have you had > >a look at similar efforts? A while ago, Aahz posted something very > >similar on this very list. You should be able to find it in any of the > >archives without too much trouble. > > You almost certainly have me confused with someone else -- I wouldn't > touch C++ with a ten-meter pole if I could possibly help it. (The last > time I dealt with C++ code, about a decade ago, I just rewrote it in C.) Sorry about that. -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 09/18/2010 11:28 PM, Steven D'Aprano wrote: On Sat, 18 Sep 2010 21:58:58 -0400, AK wrote: I don't understand this. So far as I know, the phrase "speed reading" refers to various methods of reading much faster than most people read, and is real but not exceptionally interesting. Afaik the idea is that you can read a novel at the speed of half a page a second or so and understand it to the same extent as people who'd read at a normal rate. Woody Allen joke: "I learned speed reading and read War&Peace"; - it involves Russia. My wife can read scarily fast. It's very something to watch her reading pages as fast as she can turn them, and a few years ago she read the entire Harry Potter series (to date) in one afternoon, and could gives a blow-by-blow account of the plots, including a detailed critique of the writing style and characters. But then, she feels that reading the Potter series is a chore to be completed as fast as possible, rather than a pleasure to be savored. She'll sometimes drag a new Terry Pratchett or Stephen King novel out for as much as two days. That's pretty impressive. I used to get somewhat close to that speed when, years ago, I'd read a lot of trashy scifi. The way it would work is that I'd sense in advance that there's a passage where the hero with his team is going through a desert area and I'd know that a 30-40 page section will be punctuated by two battles and one friendly encounter. I would be able to read at different speeds depending on what's going on, slowing down a bit where a twist is presented or a crucial plot point is revealed, both would be telegraphed well in advance. In other spots, I'd be able to scan a few words at the top of page, a few in the middle and at the bottom and I'd know what's going on, generally. I would also be able to give a detailed account of the plot and writing style and characters but this would be entirely due to predictability of writing and following tropes. Interestingly, I've also read LoTR in the same way when I was younger because I was interested in battles and skipped the dull parts. I tried a few times to read Potter book 3 but couldn't bear it.. spoiled too much by Barrie and Grahame. When I was reading The book of the new sun, though, I could stop and read a single sentence a few times over and reflect on it for a minute. -ak -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 09/19/2010 03:31 AM, Seebs wrote: On 2010-09-19, Steven D'Aprano wrote: Define "unbalanced". I'm not sure that's the word I'd use. I'm not even sure what it would mean here. Putting aside the over-use of punctuation, The C syntax feels unbalanced to me. You have: condition IF true-clause ELSE false-clause so both clauses follow the test, that is, they're on the same side: ?-- Yes. Just like: if condition: foo else: bar The condition is the primary, the clauses are secondary to it. To me, the problem with C ternary is, why is true condition first and false second? It could just as well be the other way around. With if and else, the meaning is direct, x if y else z, or if y: x; else: z. It may be balanced, but it requires you to reevaluate what you're reading after you've already read something that seemed to have a clear meaning. Basically, think of what happens as I read each symbol: x = x + 1 if condition else x - 1 Up through the '1', I have a perfectly ordinary assignment of a value. The, suddenly, it retroactively turns out that I have misunderstood everything I've been reading. I am actually reading a conditional, and the things I've been seeing which looked like they were definitely part of the flow of evaluation may in fact be completely skipped. That's absolutely not how I read code. For example, if you have a line like: x = x + 1 a...@#$!@$asfa...@#$!@$#adfas...@# Do you read it as "ok, assignment.. x is x + 1.. whoa, what the hell is this?". I would read it like "there's something wrong at the end of line", before I even see it as an assignment. That's where syntax highlighting comes in, as well. What I see, at the same time (i.e. not in sequence): .. = .. if .. else .. The second thing I see is what variable is being assigned to. Of couse, this might change if I'm looking for that particular variable, then I might see: x or x = Consider the following lovely hypothetical syntax: foo bar baz if condition else: blah blah blah And there, at least you have some cue that you're about to see something happen. After some time getting used to it, I'd end up seeing this as: . . . if .. else: . . . at first and then processing everything else. Again, syntax highlighting would help here. The only issue is that it'd be hard to separate the beginning from other code, for me that'd be the primary reason why this is not a good construct. -ak -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 09/19/2010 03:36 AM, Seebs wrote: On 2010-09-19, Steven D'Aprano wrote: I'm not entirely sure I agree with you here... you can't ignore syntax in order to understand the meaning of code. No, but the syntax should be invisible. When I read English, I don't have to think about nouns and verbs and such unless something is very badly written. The syntax is handled automatically at a lower level without conscious intervention, as it should be. Calling my conscious attention to it is disruptive. The interesting thing is that syntax highlight for me *is* handled at a lower level. What you're describing is exactly the same as when I try a highlight scheme with colours that are too strong, or have a background. I would rather use no highlighting at all than a theme with garish colours. When I read code, I filter out colours when I don't need them and filter out non-coloured text when I'm looking for a particular structure. So, with x = y if a else z, I might see . = . if . else . and then immediately see x . y . a . z, already with knowledge of what is the structure surrounding vars. Punctuation is very different from highlighting, IMHO. That said, I find punctuation very effective at being small and discrete, clearly not words, and easy to pick out. Color cues are not nearly as good at being inobtrusive but automatically parsed. Seems like the difference of how you process colours vs. how I do, for me they work precisely in the same way as punctuation might, but adding an additional layer which may be used but never gets in the way. -ak -- http://mail.python.org/mailman/listinfo/python-list
comp.lang.python
http://127760.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Making logging.getLogger() simpler
On Sun, 19 Sep 2010 02:35:15 +1000, Lie Ryan wrote:
> I was expecting this to work:
>
> import logging
> logger = logging.getLogger(__name__)
> logger.warn('this is a warning')
>
> instead it produced the error:
>
> No handlers could be found for logger "__main__"
>
>
> However, if instead I do:
>
> import logging
> logging.warn('creating logger')
> logger = logging.getLogger(__name__)
> logger.warn('this is a warning')
>
> then it does work.
>
> Is there any reason why getLogger()-created logger shouldn't
> automatically create a default handler?
Hello Lie,
Calling logging.warn(), or logging.debug() etc. before handlers
have been assigned to the root logger will result in
logging.basicConfig() being called automatically. By default a
StreamHandler will be created on the root logger and your logger
inherits the StreamHandler. So you can avoid the "No handlers..."
warning by calling logging.basicConfig() before your program
does any logging.
I don't know why getLogger() doesn't so something similar when
it's called. Perhaps so that the logger is explicitly
initialised with basic, file or dictConfig?
Cheers,
Kev
--
http://mail.python.org/mailman/listinfo/python-list
Re: socket.error: [Errno 98] Address already in use
On Sun, 19 Sep 2010 18:42:51 +1200, Lawrence D'Oliveiro wrote: That's why Stevens recommends that all TCP servers use the SO_REUSEADDR socket option. >>> >>> I don’t think I’ve ever used that. It seems to defeat a safety mechanism >>> which was put in for a reason. >> >> It was put in for the benefit of clients, to prevent them from selecting >> a port which they won't be able to use. > > But clients typically don’t care what port they use—they let the > system pick a port for them, so this kind of option is unnecessary. If they use an ephemeral port, the kernel won't pick a port which has any connections in the TIME_WAIT state. However, some clients choose their own source ports. E.g. rlogin/rsh use privileged (low-numbered) ports, and you can't get the kernel to choose a random privileged port for you. If you're writing a server which listens on a known port, you *should* be using SO_REUSEADDR to avoid unnecessary delays in start-up. The kernel will automatically reject packets relating to stale connections, and your server should be accepting any new connections ASAP. -- http://mail.python.org/mailman/listinfo/python-list
newbie: class and __dict__ variable.
Hallo Group Members. From time to time I see in python code following notation that (as I believe) extends namespace of MyClass. class MyClass: def __init__(self): self.__dict__["maci"]=45 myCl2 = MyClass2() print myCl2.maci I am guessing that there must be some difference between the one above and the one below, because otherwise no one would probably use the one above. Do YOu know that difference? class MyClass2: def __init__(self): self.maci=45 myCl = MyClass() print myCl.maci best regards, Pawel -- http://mail.python.org/mailman/listinfo/python-list
develop for Windows on GNU/Linux, using Python
Consider: Can someone do development of programs for use on Windows systems, but developed totally on a GNU/Linux system, using standard, contemporary 32 and / or 64-bit PC hardware? This would be for someone who can not or will not use Windows, but wants to create software for those who do. This might not include the use of VM for developing on GNU/Linux, as that would seem to require a Windows installation disk, which the developer may not be able or willing to obtain and use. Is the correct answer: 1) no. 2) yes. 3) yes, a "Hello World" program will run just fine on the Windows Python interpreter. 4) other. -- http://mail.python.org/mailman/listinfo/python-list
http2https proxy
I'd like to open a ssl connection to a https server, done Create a socket and bind it to a local port, done Connect the two in such a way that everything read or written to the local port is actually read or written to the https server. In other words I want a http2https proxy. ideas? best regards, Seb -- http://mail.python.org/mailman/listinfo/python-list
Re: develop for Windows on GNU/Linux, using Python
On Sun, 19 Sep 2010 12:55:43 -0500, Default User wrote: > Consider: > > Can someone do development of programs for use on Windows systems, but > developed totally on a GNU/Linux system, using standard, contemporary 32 > and / or 64-bit PC hardware? > > This would be for someone who can not or will not use Windows, but wants > to create software for those who do. > > This might not include the use of VM for developing on GNU/Linux, as > that would seem to require a Windows installation disk, which the > developer may not be able or willing to obtain and use. > > Is the correct answer: > 1) no. > 2) yes. > 3) yes, a "Hello World" program will run just fine on the Windows Python > interpreter. > 4) other. Hello, The answer is "it depends", or 4 on your list of responses. You can write pure python on a Linux machine and it will run fine on Windows as long as you've taken care to program in a portable fashion. However, writing the code isn't everything. To be confident that your code is good you need to test it on a Windows box (we all test, right?). If you want to distribute your application to non-developers you'll need to wrap it in a Windows installer; if you have C-extensions in your code you'll need to compile them over Windows. If you want to program against the Windows API you'll need access to a Windows box. So, if you really want to develop code for Windows (or cross-platform code) I think you need to bite the bullet and get access to a Windows (virtual) machine. Cheers, Kev PS - You might be able to get away with using an emulator like WINE, but given the ubiquity of Windows in business/home computing I think you're better of testing on the real thing. -- http://mail.python.org/mailman/listinfo/python-list
Re: [DB-SIG] dbf files and compact indices
M.-A. Lemburg wrote: If you are working on Windows, you can install the MS MDAC package to get a hold of the MS FoxPro ODBC drivers. They are usually already installed in Vista and 7, in XP they comes with MS SQL Server and MS Office as well. mxODBC can then provide Python access on Windows, mxODBC Connect on other platforms. If you want direct files access on other platforms, you can use http://pypi.python.org/pypi/dbf/ ^--- I'm the author if this package :) or http://dbfpy.sourceforge.net/. ^--- from the quick skim of the code, I think mine does more at this point (memos, adding/deleting/renaming fields in existing tables, in-memory indexes, unicode support, export to csv,tab,fixed formats, field access via attribute/dictionary/index style (e.g. table.fullname or table['fullname'] or table[0] if fullname is the first field), very rudimentary sql support, etc.) If you want to add support for index files (which the above two don't support), you could also have a look at this recipe for some inspiration: http://code.activestate.com/recipes/362715-dbf-reader-and-writer/ I didn't see anything regarding the .idx or .cdx files in this recipe. :( Thanks for your time, though! -- ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 2010-09-19, AK wrote: > On 09/19/2010 03:31 AM, Seebs wrote: >> Just like: >> if condition: >> foo >> else: >> bar >> The condition is the primary, the clauses are secondary to it. > To me, the problem with C ternary is, why is true condition first and > false second? It could just as well be the other way around. Again, look at the long-form "if/else" above; it's always "if a then b otherwise c". > With if and > else, the meaning is direct, x if y else z, or if y: x; else: z. The latter still has condition, true, false. >> Basically, think of what happens as I read each symbol: >> >> x = x + 1 if condition else x - 1 >> >> Up through the '1', I have a perfectly ordinary assignment of a value. >> The, suddenly, it retroactively turns out that I have misunderstood >> everything I've been reading. I am actually reading a conditional, and >> the things I've been seeing which looked like they were definitely >> part of the flow of evaluation may in fact be completely skipped. > That's absolutely not how I read code. For example, if you have a line > like: > x = x + 1 a...@#$!@$asfa...@#$!@$#adfas...@# > Do you read it as "ok, assignment.. x is x + 1.. whoa, what the hell is > this?". Not for something that big and visible. But the if/else stuff is just ordinary blocks of text. > That's where syntax highlighting comes in, as well. So basically, if we use syntax highlighting to make up for the legibility problems of a given syntax, then the syntax is okay, but people who don't use syntax highlighting to make up for its legibility problems are wrong. I see. This does seem self-contained; you like syntax highlighting because you like constructs which are hard to read without it. You like those constructs because they let you show off syntax highlighting. > After some time getting used to it, I'd end up seeing this as: > . > . > . > if .. else: > . > . > . > at first and then processing everything else. Assuming that the if/else was on the same page. :) > Again, syntax highlighting > would help here. The only issue is that it'd be hard to separate the > beginning from other code, for me that'd be the primary reason why this > is not a good construct. No matter how long I'd been using that construct, I'd still have the problem that, mechanically, I'm going to see the opening few lines first, and that means that those lines are going to get parsed first. I read largely in order. I do have some lookahead, but no matter how much I use the lookahead, I'm already parsing the first things I see, and that's top-down-left-right. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Making logging.getLogger() simpler
On Sep 18, 5:35 pm, Lie Ryan wrote:
> I was expecting this to work:
>
> importlogging
> logger =logging.getLogger(__name__)
> logger.warn('this is a warning')
>
> instead it produced the error:
>
> No handlers could be found for logger "__main__"
>
> However, if instead I do:
>
> importlogging
> logging.warn('creating logger')
> logger =logging.getLogger(__name__)
> logger.warn('this is a warning')
>
> then it does work.
>
> Is there any reason why getLogger()-created logger shouldn't
> automatically create a default handler?
There is a good reason why a getLogger()-created logger doesn't add a
default handler. Imagine if it did, and the code you were writing was
a library module that was used in an application being written by
another developer. Imagine if there were several other libraries which
also declared loggers (and therefore several default handlers). Then
the result of running the application would be to get a whole bunch of
unexpected messages from those libraries, including yours. This would
annoy the application developer no end, and rightly so.
For simple uses of logging (where you are writing a utility script,
for example, when you are the application developer) you can call
logging.warning() etc. which will (for your convenience) add a handler
to write to the console for you, if there isn't a handler already.
If you are doing something more involved, you will need to configure
logging to do whatever it is you want, and when you run your program
your log will contain messages from your application as well as third-
party libraries you use, all playing well together and with no
unpleasant surprises.
If you are writing a library, you will typically:
1. Add a NullHandler to your top-level logger.
2. If you want to force your users (application developers) to add
handlers explicitly to their loggers, set your top-level logger's
propagate flag to False.
3. If you want to have a specific verbosity on your loggers, which is
different from the default (WARNING), you need to set that level on
your top-level logger, or on individual loggers for which you want
that specific, non-default verbosity.
I hope that helps,
Vinay Sajip
--
http://mail.python.org/mailman/listinfo/python-list
Re: Making logging.getLogger() simpler
On Sep 19, 7:52 pm, Vinay Sajip wrote: > If you are writing a library, you will typically: > 2. If you want to force your users (application developers) to add > handlers explicitly to their loggers, set your top-level logger's > propagate flag to False. Sorry, in the above text, where it says "their loggers" it should say "your loggers" Regards, Vinay Sajip -- http://mail.python.org/mailman/listinfo/python-list
Re: develop for Windows on GNU/Linux, using Python
Kev Dwyer wrote: > On Sun, 19 Sep 2010 12:55:43 -0500, Default User wrote: > >> Consider: >> >> Can someone do development of programs for use on Windows systems, but >> developed totally on a GNU/Linux system, using standard, contemporary 32 >> and / or 64-bit PC hardware? >> >> This would be for someone who can not or will not use Windows, but wants >> to create software for those who do. >> >> This might not include the use of VM for developing on GNU/Linux, as >> that would seem to require a Windows installation disk, which the >> developer may not be able or willing to obtain and use. >> >> Is the correct answer: >> 1) no. >> 2) yes. >> 3) yes, a "Hello World" program will run just fine on the Windows Python >> interpreter. >> 4) other. > > Hello, > > The answer is "it depends", or 4 on your list of responses. > > You can write pure python on a Linux machine and it will run fine on > Windows as long as you've taken care to program in a portable fashion. And not use modules not yet converted to microsoft, seems to happen from time to time. > if you have C-extensions in > your code you'll need to compile them over Windows. If you want to > program against the Windows API you'll need access to a Windows box. You can always cross compile, not only over OS but even CPU architecture, but of course testing will be more difficult, on x86 based Linux you can use wine or similar to test, but can give you some differences to run on a native or virtualized instance. -- //Aho -- http://mail.python.org/mailman/listinfo/python-list
Python and unicode
Hi everybody.
I've played for few hours with encoding in py, but it's still somewhat
confusing to me. So I've written a test file (encoded as utf-8). I've
put everything I think is true in comment at the beginning of script.
Could you check if it's correct (on side note, script does what I
intended it to do).
One more thing, is there some mechanism to avoid writing all the time
'something'.decode('utf-8')? Some sort of function call to tell py
interpreter that id like to do implicit decoding with specified
encoding for all string constants in script?
Here's my script:
---
# vim: set encoding=utf-8 :
"""
- encoding and py -
- 1st (or 2nd) line tells py interpreter encoding of file
- if this line is missing, interpreter assumes 'ascii'
- it's possible to use variations of first line
- the first or second line must match the regular expression
"coding[:=]\s*([-\w.]+)" (PEP-0263)
- some variations:
'''
# coding=
'''
'''
#!/usr/bin/python
# -*- coding: -*-
'''
'''
#!/usr/bin/python
# vim: set fileencoding= :
'''
- this version works for my vim:
'''
# vim: set encoding=utf-8 :
'''
- constants can be given via str.decode() method or via unicode
constructor
- if locale is used, it shouldn't be set to 'LC_ALL' as it changes
encoding
"""
import datetime, locale
#locale.setlocale(locale.LC_ALL,'croatian') # changes encoding
locale.setlocale(locale.LC_TIME,'croatian') # sets correct date
format, but encoding is left alone
print 'default locale:', locale.getdefaultlocale()
s='abcdef ČčĆćĐ𩹮ž'.decode('utf-8')
ss=unicode('ab ČćŠđŽ','utf-8')
# date part of string is decoded as cp1250, because it's default
locale
all=datetime.date(2000,1,6).strftime("'%d.%m.%Y.', %x, %A, %B,
").decode('cp1250')+'%s, %s' % (s, ss)
print all
---
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python and unicode
> One more thing, is there some mechanism to avoid writing all the time
> 'something'.decode('utf-8')?
Yes, use u'something' instead (i.e. put the letter u before the literal,
to make it a unicode literal). Since Python 2.6, you can also put
from __future__ import unicode_literals
at the top of the file to make all string literals Unicode objects.
Since Python 3.0, this is the default (i.e. all string literals
*are* unicode objects).
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 09/19/2010 02:21 PM, Seebs wrote: On 2010-09-19, AK wrote: On 09/19/2010 03:31 AM, Seebs wrote: Just like: if condition: foo else: bar The condition is the primary, the clauses are secondary to it. To me, the problem with C ternary is, why is true condition first and false second? It could just as well be the other way around. Again, look at the long-form "if/else" above; it's always "if a then b otherwise c". Because that's what 'if' and 'else' mean. I have no problem with '?' separating condition from possible outcomes.. The most natural reading of that construct is that depending on condition, there are two possible outcomes, separated by a ':' and you have to remember that first outcome corresponds to true condition. x = y if a else z is much more pythonic because 'else' is explicitly saying what happens on false condition. Explicit is better than implicit. That's absolutely not how I read code. For example, if you have a line like: x = x + 1 a...@#$!@$asfa...@#$!@$#adfas...@# Do you read it as "ok, assignment.. x is x + 1.. whoa, what the hell is this?". Not for something that big and visible. But the if/else stuff is just ordinary blocks of text. Not with syntax highlighting they're not ;) Seriously though, my guess is even without syntax highlighting I'd still prefer it because I do enough look-ahead and in 95% of cases the first 'if' is close enough to the beginning of the line. In fact, most often plain assignments will be much shorter than this construct so you can figure it out by combination of line length and the 'if' keyword. It still has the advantage over the more verbose version that I mentioned before: you can see immediately that there's an assignment to a single variable, and the logic flows like a single sentence in a natural language. That's where syntax highlighting comes in, as well. So basically, if we use syntax highlighting to make up for the legibility problems of a given syntax, then the syntax is okay, but people who don't use syntax highlighting to make up for its legibility problems are wrong. That's not really true, it merely makes a given syntax easier to read even when it's already a preferable syntax. It's like this, if someone gives you five dollars for nothing, and then later gives you three dollars, you don't complain that the latter amount is less than former :). I see. This does seem self-contained; you like syntax highlighting because you like constructs which are hard to read without it. You like those constructs because they let you show off syntax highlighting. Well, you're exaggerating this out of all proportion just to prove a point. I like syntax highlighting in all of python and, in fact, in all languages I've used. Even in crontab files! This is a single construct I can think of, which, being already very readable, explicit, and succinct, *on top of that*, gains even more in readability due to syntax highlight. So, as you can see, I'd like syntax highlight just fine if this construct was not present in Python, and in fact I did. Conversely, I'd prefer it to the longer version if there was no syntax highlight at all. After some time getting used to it, I'd end up seeing this as: . . . if .. else: . . . at first and then processing everything else. Assuming that the if/else was on the same page. :) I'll concede you one point in this case: if the statement 'x = .. if .. else .. ' is split over two pages, I would at least seriously consider the 'if: .. else: ' version. ;) -ak -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 2010-09-19, AK wrote: > Because that's what 'if' and 'else' mean. My point is, I don't want the order of the clauses in if/else to change. If it is sometimes "if else ", then it should *ALWAYS WITHOUT EXCEPTION* be condition first, then true clause, then false clause. If it's sometimes "if condition true-clause else false-clause", and sometimes "true-clause if condition else false-clause", that's a source of extra complexity. > I have no problem with '?' > separating condition from possible outcomes.. The most natural reading > of that construct is that depending on condition, there are two possible > outcomes, separated by a ':' and you have to remember that first outcome > corresponds to true condition. Exactly as it ALWAYS does. That's the point. > x = y if a else z is much more pythonic > because 'else' is explicitly saying what happens on false condition. > Explicit is better than implicit. Is it "more pythonic" to shuffle the orders of clauses in precisely analagous constructs? I'm not arguing against the use of the *words* "if" and "else". I'm arguing that the shuffling of the orders of the clauses creates confusion. > It still has the advantage over the more verbose version that I > mentioned before: you can see immediately that there's an assignment to > a single variable, and the logic flows like a single sentence in a > natural language. I'm getting frustrated here because I really felt my point was pretty clearly expressed, and yet, every time you respond, you respond to things TOTALLY DIFFERENT from what I am saying. The syntax I like for this kind of thing is: x = if condition then true-clause else false-clause This is because it follows the same *ordering* as the multi-line if/else, so it preserves the logical flow. Condition, then true clause, then false clause. Always. The only way in which this is more verbose than the inverted one is the "then", and you don't even need that if you stick with a python-style colon: x = if condition: true-clause else false-clause But this is *always* easier to follow because it follows the same logical structure. Leave poetic inversion to the poets. > That's not really true, it merely makes a given syntax easier to read > even when it's already a preferable syntax. Except that it's *NOT PREFERABLE* to me, because it is BACKWARDS. Have I somehow failed to express this? Is there some magical rule that it is not pythonic for you to react in any way to the actual comparison I'm making, rather than to totally unrelated comparisons? I gave the example of what an if/else statement looks like, not because I think it is always better to use statements and blocks instead of expressions, but to point out the LOGICAL ORDER. You were asking why I preferred the condition to come first. My answer is, because the condition comes first in an if/else statement normally, and I like to preserve the logical flow. Instead, you're off ranting about how that's too long. But that's not my point. My point was *only* that the logical flow is consistent between if/else and the way various languages have done if/else expressions: Condition first, then true clause, then false clause. Doesn't matter whether it's ruby or C or lua or even bourne shell, in every other language I use that lets me use an if/else as part of an expression, it follows the SAME logical flow as the regular if/else statement. In Python, it's inverted. You were arguing that this inversion is better and more intuitive, and that there is no reason to expect the condition to come first. But there is! The condition comes first in regular if/else statements. This establishes a pattern -- if/else things are introduced by their condition, then you get the true clause and then you get the false clause. > Well, you're exaggerating this out of all proportion just to prove a > point. No, I'm not. > This is a single construct I > can think of, which, being already very readable, explicit, and > succinct, *on top of that*, gains even more in readability due to syntax > highlight. But it's *not readable to me*. Because it's backwards. > So, as you can see, I'd like syntax highlight just fine if this > construct was not present in Python, and in fact I did. Conversely, I'd > prefer it to the longer version if there was no syntax highlight at all. And again, NO ONE HAS SUGGESTED THE LONGER VERSION. AT ALL. EVER. I don't understand why you keep contrasting this with the longer version when the only reason that was brought up was to COMPARE it in terms of *logical flow*. I pointed out the *PARALLELS* between conditional expressions and conditional statements. I did not suggest that the longer version should be preferred in all cases, or even in all that many. > I'll concede you one point in this case: if the statement 'x = .. if .. > else .. ' is split over two pages, I would at least seriously consider > the 'if: .. else: ' version. ;) Okay, one more time: I am no
Re: Too much code - slicing
On 19/09/2010 22:32, Seebs wrote: On 2010-09-19, AK wrote: Because that's what 'if' and 'else' mean. My point is, I don't want the order of the clauses in if/else to change. If it is sometimes "ifelse", then it should *ALWAYS WITHOUT EXCEPTION* be condition first, then true clause, then false clause. If it's sometimes "if condition true-clause else false-clause", and sometimes "true-clause if condition else false-clause", that's a source of extra complexity. [snip] Have you read PEP 308? There was a lot of discussion about it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Down with tinyurl! (was Re: importing excel data into a python matrix?)
On Sun, Sep 19, 2010 at 9:16 AM, Aahz wrote: > In article , > geremy condra wrote: >>On Wed, Sep 1, 2010 at 4:35 PM, patrick mcnameeking >> wrote: >>> >>> I've been working with Python now for about a year using it primarily for >>> scripting in the Puredata graphical programming environment. I'm working on >>> a project where I have been given a 1000 by 1000 cell excel spreadsheet and >>> I would like to be able to access the data using Python. Does anyone know >>> of a way that I can do this? >> >>http://tinyurl.com/2eqqjxv > > Please don't use tinyurl -- it's opaque and provides zero help to anyone > who might later want to look it up (and also no accessibility if tinyurl > ever goes down). At the very least, include the original URL for > reference. > > (Yes, I realize this is probably a joke given the smiley I excised, but > too many people do just post tinyurl.) Not that I disagree with you, but you might find this helpful: http://tinyurl.com/preview.php -- http://mail.python.org/mailman/listinfo/python-list
Re: Down with tinyurl! (was Re: importing excel data into a python matrix?)
On 20 September 2010 07:59, Ken Watford > wrote: > > Not that I disagree with you, but you might find this helpful: > http://tinyurl.com/preview.php > -- > http://mail.python.org/mailman/listinfo/python-list > I don't think the OP wants a preview feature. The fact that you still have to go through tinyurl (which by the way, the short link itself in the email has no information on where it is whatsoever), and it makes searching through the archives difficult, too. We don't have a 140 character limit like Twitter. There's no reason we can't post the full link for reference purposes. Cheers, Xav -- http://mail.python.org/mailman/listinfo/python-list
Re: ctypes and buffers
On Sep 19, 5:10 am, Thomas Jollans wrote: > On Sunday 19 September 2010, it occurred to Carl Banks to exclaim: > > I am creating a ctypes buffer from an existing non-ctypes object that > > supports buffer protocol using the following code: > > > from ctypes import * > > > PyObject_AsReadBuffer = pythonapi.PyObject_AsReadBuffer > > PyObject_AsReadBuffer.argtypes = > > [py_object,POINTER(c_void_p),POINTER(c_size_t)] > > PyObject_AsReadBuffer.restype = None > > > def ctypes_buffer_from_buffer(buf): > > cbuf = c_void_p() > > size = c_size_t() > > PyObject_AsReadBuffer(buf,byref(cbuf),byref(size)) > > return cbuf > > If I understand what you are doing correctly, you're referencing a Python > buffer object and returning a pointer wrapped in some ctypes thingy. hmm. I > see some problems in your code: > > * You're not passing the size along. In the name of sanity, why on earth > not?! The pointer cannot be safely used without knowing how long the area > of memory referenced is! How D'Olivero of you to overreact this way. A. No, and B. I already know the size of the object > * You're using the old buffer protocol. You might rather implement this with > the one introduced with Python 3.0, and supported in 2.6 as well. Hmm, I didn't know they got that into 2.6. Maybe I'll do that, thanks. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and unicode
Goran Novosel writes:
> # vim: set encoding=utf-8 :
This will help Vim, but won't help Python. Use the PEP 263 encoding
declaration http://www.python.org/dev/peps/pep-0263/> to let Python
know the encoding of the program source file.
# -*- coding: utf-8 -*-
You can use the bottom of the file for editor hints.
> s='abcdef ČčĆćĐ𩹮ž'.decode('utf-8')
> ss=unicode('ab ČćŠđŽ','utf-8')
In Python 2.x, those string literals are created as byte strings, which
is why you're having to decode them. Instead, tell Python explicitly
that you want a string literal to be a Unicode text string:
s = u'abcdef ČčĆćĐ𩹮ž'
ss = u'ab ČćŠđŽ'
Learn more from the documentation http://docs.python.org/howto/unicode>.
--
\ “He that would make his own liberty secure must guard even his |
`\ enemy from oppression.” —Thomas Paine |
_o__) |
Ben Finney
--
http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
AK wrote: Afaik the idea is that you can read a novel at the speed of half a page a second or so and understand it to the same extent as people who'd read at a normal rate. I've never understood why anyone would *want* to read a novel that fast, though. For me at least, reading a novel is something done for pleasure, so reading it at ten times normal speed would waste 90% of the benefit. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 2010-09-19, MRAB wrote: > On 19/09/2010 22:32, Seebs wrote: >> On 2010-09-19, AK wrote: >>> Because that's what 'if' and 'else' mean. >> My point is, I don't want the order of the clauses in if/else to change. >> If it is sometimes "ifelse", then >> it should *ALWAYS WITHOUT EXCEPTION* be condition first, then true clause, >> then false clause. If it's sometimes "if condition true-clause else >> false-clause", and sometimes "true-clause if condition else false-clause", >> that's a source of extra complexity. > > [snip] > Have you read PEP 308? There was a lot of discussion about it. Interesting, in the historical section we see: The original version of this PEP proposed the following syntax: if else The out-of-order arrangement was found to be too uncomfortable for many of participants in the discussion; especially when is long, it's easy to miss the conditional while skimming. But apparently those objections were either unknown or disregarded when the syntax was later adopted. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 2010-09-19, Gregory Ewing wrote: > AK wrote: >> Afaik the idea is that you can read a novel at the speed of half a page >> a second or so and understand it to the same extent as people who'd read >> at a normal rate. > I've never understood why anyone would *want* to read a > novel that fast, though. For me at least, reading a novel > is something done for pleasure, so reading it at ten times > normal speed would waste 90% of the benefit. I get pleasure from the story, not from the time spent. Reading faster means I get more stories. Same thing, to some extent, with programming. I could easily spend much more time writing some programs by switching to a language ill-suited to them (say, using C for heavy string manipulation, or PHP for anything), but that wouldn't mean I had more fun, it would mean my fun was spread out over a longer period of time, and might well cross over to no-longer-fun. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: socket.error: [Errno 98] Address already in use
In message , Nobody wrote: > However, some clients choose their own source ports. E.g. rlogin/rsh use > privileged (low-numbered) ports, and you can't get the kernel to choose a > random privileged port for you. But nobody uses rlogin/rsh any more, and who would attach any trustworthy meaning to a connection coming from a remote low-numbered source port? > If you're writing a server which listens on a known port, you *should* be > using SO_REUSEADDR to avoid unnecessary delays in start-up. The kernel > will automatically reject packets relating to stale connections, and your > server should be accepting any new connections ASAP. That makes it sound like SO_REUSEADDR should really be a superfluous option. But it’s not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Down with tinyurl! (was Re: importing excel data into a python matrix?)
In message , Aahz wrote: > Please don't use tinyurl -- it's opaque and provides zero help to anyone > who might later want to look it up (and also no accessibility if tinyurl > ever goes down). At the very least, include the original URL for > reference. +1 from someone who has seen URL-shortening used even in reader comments on websites which allow HTML links. -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
AK wrote: > When I was reading The book of the new sun, though, I could stop and > read a single sentence a few times over and reflect on it for a minute. Totally understandable, Wolfe is a far, far greater writer than Rowling :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 09/19/2010 07:18 PM, Gregory Ewing wrote: AK wrote: Afaik the idea is that you can read a novel at the speed of half a page a second or so and understand it to the same extent as people who'd read at a normal rate. I've never understood why anyone would *want* to read a novel that fast, though. For me at least, reading a novel is something done for pleasure, so reading it at ten times normal speed would waste 90% of the benefit. One definite advantage would be that if, say, it takes you 70 pages of a given novel to figure out whether you like it enough to continue, you'd want to read those pages in 2 minutes rather than an hour. Unfortunately, beginning of a novel is where I have to read at the slowest rate because I'm not used to author's style and pacing yet and I don't want to miss something crucial. -ak -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: class and __dict__ variable.
On 9/19/2010 1:37 PM, mafeu...@gmail.com wrote: Hallo Group Members. From time to time I see in python code following notation that (as I believe) extends namespace of MyClass. No, it does not affect MyClass, just the instance dict. class MyClass: def __init__(self): self.__dict__["maci"]=45 Have you seen exactly this usage? myCl2 = MyClass2() print myCl2.maci I am guessing that there must be some difference between the one above and the one below, because otherwise no one would probably use the one above. Do YOu know that difference? class MyClass2: def __init__(self): self.maci=45 If the class has a .__setattr__ method, the first bypasses that method, the second results in it being called. The direct __dict__ access is most useful within a .__setattr__ method to avoid infinite recursion. myCl = MyClass() print myCl.maci -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Down with tinyurl! (was Re: importing excel data into a python matrix?)
On Sep 19, 2010, at 6:05 PM, Xavier Ho wrote: > On 20 September 2010 07:59, Ken Watford > >> wrote: > >> >> Not that I disagree with you, but you might find this helpful: >> http://tinyurl.com/preview.php >> -- >> http://mail.python.org/mailman/listinfo/python-list >> > > I don't think the OP wants a preview feature. The fact that you still have > to go through tinyurl (which by the way, the short link itself in the email > has no information on where it is whatsoever), and it makes searching > through the archives difficult, too. > > We don't have a 140 character limit like Twitter. There's no reason we can't > post the full link for reference purposes. Some email systems still insert hard line breaks around the 72 or 80 column mark and as a result long URLs get broken. I hope anyone on this list would be able to surgically repair a broken URL, but I email plenty of people who can't and tinyurl & friends are really helpful in that context. bye P -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 2010-09-20, alex23 wrote: > AK wrote: >> When I was reading The book of the new sun, though, I could stop and >> read a single sentence a few times over and reflect on it for a minute. > Totally understandable, Wolfe is a far, far greater writer than > Rowling :) Certainly true. On the other hand, I found it frustrating when I *had* to re-read a passage a couple of times to figure out what had just happened. :) ... Not that rereading books is necessarily a bad thing. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
AK writes: > On 09/19/2010 07:18 PM, Gregory Ewing wrote: >> AK wrote: >> >>> Afaik the idea is that you can read a novel at the speed of half a page >>> a second or so and understand it to the same extent as people who'd read >>> at a normal rate. >> >> I've never understood why anyone would *want* to read a >> novel that fast, though. For me at least, reading a novel >> is something done for pleasure, so reading it at ten times >> normal speed would waste 90% of the benefit. >> > > One definite advantage would be that if, say, it takes you 70 pages of a > given novel to figure out whether you like it enough to continue, you'd > want to read those pages in 2 minutes rather than an hour. Heh, to me speed reading those 70 pages in a very short while, concluding that it's a good book, and start over again would be quite the spoiler. Do you fast forward movies as well? I do speed read but not the books I read for pleasure. -- John Bokma j3b Blog: http://johnbokma.com/Facebook: http://www.facebook.com/j.j.j.bokma Freelance Perl & Python Development: http://castleamber.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and unicode
On Sep 19, 4:09 pm, Ben Finney wrote: > Goran Novosel writes: > > # vim: set encoding=utf-8 : > > This will help Vim, but won't help Python. Use the PEP 263 encoding > declaration http://www.python.org/dev/peps/pep-0263/> to let Python > know the encoding of the program source file. That's funny because I went to PEP 263 and the line he used was listed there. Apparently, you're the one that needs to read PEP 263. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 2010-09-20, John Bokma wrote: > Heh, to me speed reading those 70 pages in a very short while, > concluding that it's a good book, and start over again would be quite > the spoiler. I rarely encounter substantive spoilers in the first 70 pages or so of a book. That said, I'm pretty much immune to spoilers; while I'm reading, I'm usually ignoring anything I might have previously known about a story, so it all works even if I've read it before. > Do you fast forward movies as well? Amusingly, I can't generally watch movies at normal speed. They're too boring. Luckily, computers are finally advancing to a point where "1.2x faster, but no chipmunks" is an available setting in some software. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: C++ - Python API
In article , Thomas Jollans wrote: >On Sunday 19 September 2010, it occurred to Aahz to exclaim: >> In article , >> Thomas Jollans wrote: >>>On Wednesday 01 September 2010, it occurred to Markus Kraus to exclaim: So the feature overview: >>> >>>First, the obligatory things you don't want to hear: Have you had >>>a look at similar efforts? A while ago, Aahz posted something very >>>similar on this very list. You should be able to find it in any of the >>>archives without too much trouble. >> >> You almost certainly have me confused with someone else -- I wouldn't >> touch C++ with a ten-meter pole if I could possibly help it. (The last >> time I dealt with C++ code, about a decade ago, I just rewrote it in C.) > >Sorry about that. No biggie, just wanted to prevent further confusion. -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "The volume of a pizza of thickness 'a' and radius 'z' is given by pi*z*z*a" -- http://mail.python.org/mailman/listinfo/python-list
Re: Down with tinyurl! (was Re: importing excel data into a python matrix?)
In article , Philip Semanchuk wrote: > >Some email systems still insert hard line breaks around the 72 or 80 >column mark and as a result long URLs get broken. I hope anyone on this >list would be able to surgically repair a broken URL, but I email plenty >of people who can't and tinyurl & friends are really helpful in that >context. There's no reason you can't cater to that problem by using tinyurl *in* *addition* to the full regular URL. -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "The volume of a pizza of thickness 'a' and radius 'z' is given by pi*z*z*a" -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On Mon, 20 Sep 2010 11:18:57 +1200, Gregory Ewing wrote: > AK wrote: > >> Afaik the idea is that you can read a novel at the speed of half a page >> a second or so and understand it to the same extent as people who'd >> read at a normal rate. > > I've never understood why anyone would *want* to read a novel that fast, > though. For me at least, reading a novel is something done for pleasure, > so reading it at ten times normal speed would waste 90% of the benefit. Or reduce the pain by 90%, depending on the book... -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: SimpleHTTPServer, external CSS, and Google Chrome
On Sep 18, 2:54 am, MrJean1 wrote: > FWIW, > > There is a blue text on a red background in all 4 browsers Google > Chrome 6.0.472.59, Safari 5.0.1 (7533.17.8), FireFox 3.6.9 and IE > 6.0.2900.5512 with Python 2.7 serving that page on my Windows XP > SP 3 machine. > > /Jean > Hmm. Will download and install newer python versions to re-check then. Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and unicode
On Mon, 20 Sep 2010 09:09:31 +1000, Ben Finney wrote: > Goran Novosel writes: > >> # vim: set encoding=utf-8 : > > This will help Vim, but won't help Python. It will actually -- the regex Python uses to detect encoding lines is documented, and Vim-style declarations are allowed as are Emacs style. In fact, something as minimal as: # coding=utf-8 will do the job. > Use the PEP 263 encoding > declaration http://www.python.org/dev/peps/pep-0263/> to let Python > know the encoding of the program source file. While PEPs are valuable, once accepted or rejected they become historical documents. They don't necessarily document the current behaviour of the language. See here for documentation on encoding declarations: http://docs.python.org/reference/lexical_analysis.html#encoding-declarations -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Down with tinyurl! (was Re: importing excel data into a python matrix?)
On Sun, 19 Sep 2010 06:16:49 -0700, Aahz wrote: > Please don't use tinyurl -- it's opaque and provides zero help to anyone > who might later want to look it up (and also no accessibility if tinyurl > ever goes down). At the very least, include the original URL for > reference. Do you have something against tinyurl in particular, or would any URL shortener service also get your ire? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Down with tinyurl! (was Re: importing excel data into a python matrix?)
On 2010-09-20, Steven D'Aprano wrote: > On Sun, 19 Sep 2010 06:16:49 -0700, Aahz wrote: >> Please don't use tinyurl -- it's opaque and provides zero help to anyone >> who might later want to look it up (and also no accessibility if tinyurl >> ever goes down). At the very least, include the original URL for >> reference. > Do you have something against tinyurl in particular, or would any URL > shortener service also get your ire? I'd assume all of them have the same essential problems: * No hint as to what site you'll be getting redirected to. * No cues from URL as to what the link is to. * If the service ever goes away, the links become pure noise. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 09/19/2010 10:32 PM, John Bokma wrote: AK writes: On 09/19/2010 07:18 PM, Gregory Ewing wrote: AK wrote: Afaik the idea is that you can read a novel at the speed of half a page a second or so and understand it to the same extent as people who'd read at a normal rate. I've never understood why anyone would *want* to read a novel that fast, though. For me at least, reading a novel is something done for pleasure, so reading it at ten times normal speed would waste 90% of the benefit. One definite advantage would be that if, say, it takes you 70 pages of a given novel to figure out whether you like it enough to continue, you'd want to read those pages in 2 minutes rather than an hour. Heh, to me speed reading those 70 pages in a very short while, concluding that it's a good book, and start over again would be quite the spoiler. Do you fast forward movies as well? I honestly doubt it would be a spoiler if it's a good book. Generally I find that poor books rely on twists and turns while better ones rely on the fabric of story-telling. Aside from that, though, it's a very interesting question - I'll try to think of good books and see if they'd be spoiled by peeking in the first 70 pages.. Starting with children's books, Peter Pan and Wind in the Willows, I think, would not be. Don quixote would not be. Crime and punishment - maybe if you get as far as the murder? Same author's the Devils, I would say you can read the last 70 pages and it'd be just as good :). -ak -- http://mail.python.org/mailman/listinfo/python-list
www.127760.blogspot.com
www.127760.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
AK writes: > On 09/19/2010 10:32 PM, John Bokma wrote: >> AK writes: >> >>> On 09/19/2010 07:18 PM, Gregory Ewing wrote: AK wrote: > Afaik the idea is that you can read a novel at the speed of half a page > a second or so and understand it to the same extent as people who'd read > at a normal rate. I've never understood why anyone would *want* to read a novel that fast, though. For me at least, reading a novel is something done for pleasure, so reading it at ten times normal speed would waste 90% of the benefit. >>> >>> One definite advantage would be that if, say, it takes you 70 pages of a >>> given novel to figure out whether you like it enough to continue, you'd >>> want to read those pages in 2 minutes rather than an hour. >> >> Heh, to me speed reading those 70 pages in a very short while, >> concluding that it's a good book, and start over again would be quite >> the spoiler. Do you fast forward movies as well? > > I honestly doubt it would be a spoiler if it's a good book. Generally I > find that poor books rely on twists and turns while better ones rely on > the fabric of story-telling. Aside from that, though, it's a very > interesting question - I'll try to think of good books and see if they'd > be spoiled by peeking in the first 70 pages.. Starting with children's > books, Peter Pan and Wind in the Willows, I think, would not be. Don > quixote would not be. Crime and punishment - maybe if you get as far as > the murder? Same author's the Devils, I would say you can read the last > 70 pages and it'd be just as good :). -ak I didn't mean that there are spoilers in the first 70 pages, just that to me the excercise would spoil the book, so, I wouldn't do it. I consider a book like a meal, I wouldn't gobble down food, regurgitate it, and eat it again at a slower pace. Books, movies, family, walks are the things I prefer to do at a normal mudane pace, or even slower, if I can bring myself to it. My favourite books I try to read slow, and enjoy. ;-). Too much of my life is already in overdrive. -- John Bokma j3b Blog: http://johnbokma.com/Facebook: http://www.facebook.com/j.j.j.bokma Freelance Perl & Python Development: http://castleamber.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Down with tinyurl! (was Re: importing excel data into a python matrix?)
On 2010-09-20, Seebs wrote: > On 2010-09-20, Steven D'Aprano wrote: >> On Sun, 19 Sep 2010 06:16:49 -0700, Aahz wrote: >>> Please don't use tinyurl -- it's opaque and provides zero help to anyone >>> who might later want to look it up (and also no accessibility if tinyurl >>> ever goes down). At the very least, include the original URL for >>> reference. > >> Do you have something against tinyurl in particular, or would any URL >> shortener service also get your ire? > > I'd assume all of them have the same essential problems: > > * No hint as to what site you'll be getting redirected to. Tinyurl, in particular, allows you to preview the url if you choose to do so. Other URL shortning services have a similar feature. > * No cues from URL as to what the link is to. Same point as above. Same solution. > * If the service ever goes away, the links become pure noise. This happens a lot on the web anyway. Do you have any idea how many pieces of free software are first hosted on university servers to disappear when the author graduates/moves to another school or free shared host servers that have to be moved due to lack of scalability? Sourceforge solved much of this problem; but, then if sourceforge should ever disappear, all of its links will be pure noise as well. The simple fact is that the Internet changes. It changed before URL shortening services came into the mainstream and it will be true long after they have left. -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 2010-09-20, John Bokma wrote: > I didn't mean that there are spoilers in the first 70 pages, just that > to me the excercise would spoil the book, so, I wouldn't do it. I > consider a book like a meal, I wouldn't gobble down food, regurgitate > it, and eat it again at a slower pace. Books, movies, family, walks are > the things I prefer to do at a normal mudane pace, or even slower, if I > can bring myself to it. My favourite books I try to read slow, and > enjoy. ;-). Too much of my life is already in overdrive. Now that you explain it like this, that makes a fair bit of sense. I often wonder whether reading slowly would be more pleasant. I have no idea how to do it, so the question remains theoretical. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Down with tinyurl! (was Re: importing excel data into a python matrix?)
On 2010-09-20, Tim Harig wrote: > On 2010-09-20, Seebs wrote: >> * No hint as to what site you'll be getting redirected to. > Tinyurl, in particular, allows you to preview the url if you choose to do > so. Other URL shortning services have a similar feature. I have no idea how. If I see a "tinyurl" URL, and I paste it into a browser, last I tried it, I ended up on whatever page it redirected to. >> * No cues from URL as to what the link is to. > Same point as above. Same solution. I'm not reading news in a web browser. I don't want to have to cut and paste and go look at a page in order to determine whether I want to switch to my browser. >> * If the service ever goes away, the links become pure noise. > This happens a lot on the web anyway. True. > Do you have any idea how many > pieces of free software are first hosted on university servers to > disappear when the author graduates/moves to another school or free > shared host servers that have to be moved due to lack of scalability? > Sourceforge solved much of this problem; but, then if sourceforge should > ever disappear, all of its links will be pure noise as well. This is true. But two points of failure strikes me as worse than one. :) > The simple fact is that the Internet changes. It changed before URL > shortening services came into the mainstream and it will be true long > after they have left. Oh, certainly. I'm not particularly convinced that these are *significant* complaints about URL-shorteners. But I will say, of the last couple hundred links I've followed from Usenet posts, precisely zero of them were through URL redirectors. If I can't at least look at the URL to get some initial impression of what it's a link to, I'm not going to the trouble of swapping to a web browser to find out. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: compiling python 3.1.2 with local readline fails to get readline - help!
On Sep 15, 6:41 pm, James Mills wrote: > On Thu, Sep 16, 2010 at 11:10 AM, gavino wrote: > > I am comiling 3.1.2. > > I am not root but a user. > > I compiled readline and it did not complain. > > gdb and zlib and some other modules also were not found. > > Like I said earlier in my previous post, is the readline line that > you compiled and installed to your home directory actually > working and can you actually compile any C programs that > use this custom readline ? > > cheers > James > > -- > -- James Mills > -- > -- "Problems are solved by method" I don't know how to test readline. It compiled without complaint. I guess my questions boils down to how to point the python compile to the readline lib? I don't have root. -- http://mail.python.org/mailman/listinfo/python-list
programming
I am in a computer science class in which I am supposed to be creating a program involving a sine wave and some other functions. I understand the concept of the problem, but I don't understand any of the "lingo" being used. The directions might as well be written in a different language. Is there anyone on here that might be able to help me in understanding what certain things mean? -- http://mail.python.org/mailman/listinfo/python-list
Re: Down with tinyurl! (was Re: importing excel data into a python matrix?)
On 2010-09-20, Seebs wrote: > On 2010-09-20, Tim Harig wrote: >> On 2010-09-20, Seebs wrote: >>> * No hint as to what site you'll be getting redirected to. > >> Tinyurl, in particular, allows you to preview the url if you choose to do >> so. Other URL shortning services have a similar feature. > > I have no idea how. If I see a "tinyurl" URL, and I paste it into > a browser, last I tried it, I ended up on whatever page it redirected > to. 1. Don't bother to manually paste when you can use something like urlview to lauch directly. 2. tinyurl addresses can be previewed by adding the "preview" subdomain to the tinyurl. For example, the address that started this subthread would become: http://preview.tinyurl.com/2eqqjxv If you want this behavior by default, you can easily wrap urlview to automatically add the prefix. >>> * If the service ever goes away, the links become pure noise. > >> This happens a lot on the web anyway. > > True. > >> Do you have any idea how many >> pieces of free software are first hosted on university servers to >> disappear when the author graduates/moves to another school or free >> shared host servers that have to be moved due to lack of scalability? >> Sourceforge solved much of this problem; but, then if sourceforge should >> ever disappear, all of its links will be pure noise as well. > > This is true. > > But two points of failure strikes me as worse than one. :) I question first whether most tinyurl links are really of such an intransient nature that they need to be long lasting. I personally use them most when writing paper notes. They only need to last long enough for me, or whoever I made the note for, to get back to them. In theory, something like this adds the possibilty of adding another level of indirection; which could make the system more robust if used properly. Just think of how much resiliency is gained by using DNS, which can be redirected, as opposed to IP addresses which you cannot take with you if you move. This is academic as tinyurl addresses cannot be changed; but, it does point out that simple logic such as two points of failure must be worse then one isn't always correct. >> The simple fact is that the Internet changes. It changed before URL >> shortening services came into the mainstream and it will be true long >> after they have left. > > I'm not particularly convinced that these are *significant* complaints > about URL-shorteners. But I will say, of the last couple hundred links > I've followed from Usenet posts, precisely zero of them were through > URL redirectors. If I can't at least look at the URL to get some > initial impression of what it's a link to, I'm not going to the trouble > of swapping to a web browser to find out. But why should the rest of us be penalized because you make the choice not to use (or not take full advantage of) all of the tools that are available to you? -- http://mail.python.org/mailman/listinfo/python-list
Re: programming
On Sun, Sep 19, 2010 at 10:46 PM, Jordan Blanton wrote: > I am in a computer science class in which I am supposed to be creating a > program involving a sine wave and some other functions. I understand the > concept of the problem, but I don't understand any of the "lingo" being > used. The directions might as well be written in a different language. Is > there anyone on here that might be able to help me in understanding what > certain things mean? Yes. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
visual studio 2010 question
After running into the error "Setup script exited with error: Unable to find vcvarsall.bat" when trying to use easy_install / setuptools a little digging showed that the MS compiler files in distutils only support up to Studio 2008. Does anyone know if there is a timetable for when Studio 2010 will be supported? I am using python 2.6.5, but web searching seemed to show that 2.7 or 3.X didn't support it yet either. -Ralf Haring -- http://mail.python.org/mailman/listinfo/python-list
Re: programming
On 20 September 2010 15:46, Jordan Blanton wrote: > I am in a computer science class in which I am supposed to be creating a > program involving a sine wave and some other functions. I understand the > concept of the problem, but I don't understand any of the "lingo" being > used. The directions might as well be written in a different language. Is > there anyone on here that might be able to help me in understanding what > certain things mean? > If you can tell us what terms you don't understand, we may be able to provide you some explanations. Cheers, Xav -- http://mail.python.org/mailman/listinfo/python-list
Re: Down with tinyurl! (was Re: importing excel data into a python matrix?)
On 2010-09-20, Tim Harig wrote: > 1. Don't bother to manually paste when you can use something like urlview > to lauch directly. I don't know that this would actually be better than what I currently do, which is grab text and middle-click in another window. > If you want this behavior by default, you can easily wrap urlview > to automatically add the prefix. True, but since my news reading is not on the machine my web browser is on, it seems like it might get annoying. > I question first whether most tinyurl links are really of such an > intransient nature that they need to be long lasting. I personally use > them most when writing paper notes. They only need to last long enough > for me, or whoever I made the note for, to get back to them. By default, I assume that Usenet posts are for the longer term, and a Usenet post which relies for its content on tinyurl is thus somewhat more vulnerable than one which doesn't. In particular, consider things like archive.org; they may well be able to find a long-dead web page, but not a long-dead tinyurl link. > This is academic as tinyurl addresses cannot be changed; but, it > does point out that simple logic such as two points of failure must be > worse then one isn't always correct. Not always correct, but I think it is in this case. > But why should the rest of us be penalized because you make the choice > not to use (or not take full advantage of) all of the tools that are > available to you? For about the same reason that I should be penalized because someone else wanted things done differently. Which is to say, it's a tradeoff, the right choice to make depends on what your goals are. If you want a piece of information to have maximal longevity, something like tinyurl is probably a bad way to transmit it. If you want something small that survives line wrapping, it's probably a good way. FWIW, the browsers I use automatically Do The Right Thing if you paste in a multiline URL. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Down with tinyurl! (was Re: importing excel data into a python matrix?)
On Mon, 20 Sep 2010 05:46:38 +, Tim Harig wrote: >> I'm not particularly convinced that these are *significant* complaints >> about URL-shorteners. But I will say, of the last couple hundred links >> I've followed from Usenet posts, precisely zero of them were through >> URL redirectors. If I can't at least look at the URL to get some >> initial impression of what it's a link to, I'm not going to the trouble >> of swapping to a web browser to find out. > > But why should the rest of us be penalized because you make the choice > not to use (or not take full advantage of) all of the tools that are > available to you? I'm with Aahz... best practice is to post both the full and shortened URL, unless the URL is less that 78 characters, in which case just post the full version. Similarly, if I'm posting a link to some URL that looks like this: http://blah blah blah/link=useful-bit&noise&rubbish&crap&crap&crap&more- crap&lots-more-crap-for-three-more-lines I try editing the URL to http://blah blah blah/link=useful-bit and if the link still works, I just post that. Google search results, I'm looking at you. (Although they're not even *close* to the worst.) Personally, I think that any professional business or government site that exposes URLs filled with parameters, without giving a shortened "permalink" version, is full of Fail. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: SimpleHTTPServer, external CSS, and Google Chrome
LOL. twas http://bugs.python.org/issue839496 -- http://mail.python.org/mailman/listinfo/python-list
[OT] Speed-reading [was Re: Too much code - slicing]
On Sun, 19 Sep 2010 10:29:10 -0400, AK wrote: > On 09/18/2010 11:28 PM, Steven D'Aprano wrote: [...] >> My wife can read scarily fast. It's very something to watch her reading >> pages as fast as she can turn them, and a few years ago she read the >> entire Harry Potter series (to date) in one afternoon, and could gives >> a blow-by-blow account of the plots, including a detailed critique of >> the writing style and characters. But then, she feels that reading the >> Potter series is a chore to be completed as fast as possible, rather >> than a pleasure to be savored. She'll sometimes drag a new Terry >> Pratchett or Stephen King novel out for as much as two days. >> >> >> > That's pretty impressive. I used to get somewhat close to that speed > when, years ago, I'd read a lot of trashy scifi. [...] > In other spots, I'd > be able to scan a few words at the top of page, a few in the middle and > at the bottom and I'd know what's going on, generally. I don't know about how other people speed-read, but I can assure you that when my wife speed-reads, she's not just scanning a few words and interpolating between them. She can give you a detailed summary of what *actually* happened, not just a good guess. Including pointing out any spelling or grammatical errors and clumsy writing. *Especially* the spelling errors, they have about the same effect on her reading speed as a tree trunk lying across a Formula 1 race track. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
[OT] Syntax highlighting [was Re: Too much code - slicing]
On Sun, 19 Sep 2010 07:36:11 +, Seebs wrote:
> On 2010-09-19, Steven D'Aprano
> wrote:
>> I'm not entirely sure I agree with you here... you can't ignore syntax
>> in order to understand the meaning of code.
>
> No, but the syntax should be invisible. When I read English, I don't
> have to think about nouns and verbs and such unless something is very
> badly written.
That's almost certainly because you've been listening to, speaking,
reading and writing English since you were a small child, and the syntax
and grammar of English is buried deep in your brain.
And you certainly do think about nouns and verbs, you just don't
*consciously* think about them. If I write:
"Susan blooged the mobblet."
you will probably recognise "bloog" as the verb and "mobblet" as the
noun, even though you've almost certainly never seen those words before
and have no idea what they mean. But if I write this:
"Susan is mobblet the blooged."
you'll probably give a double-take. The words don't look right for
English grammar and syntax.
I've been reading, writing and thinking in Python for well over a decade.
The syntax and grammar is almost entirely invisible to me too. No
surprise there -- they are relatively close to that of the human
languages I'm used to (English). But if I were a native Chinese or Arabic
speaker, I'd probably find Python much less "natural" and *would* need to
explicitly think about the syntax more.
[...]
>> The term "syntax highlighting" for what editors I've seen do is
>> actually misleading -- they don't highlight *syntax*, they try to
>> highlight *semantics*.
>
> I've never seen this. I've seen things highlight comments and keywords
> and operators and constants and identifiers differently.
Exactly. Things are highlighted because of *what* they are, not because
of the syntax they use or because of the grammatical role they play.
In a Python expression like:
y = none or None
an editor might colour "None" green because it's a known keyword, but
"none" black because it's a variable. If you change the syntax:
y = None if [none][0] is None else {None: none}[None]
the colours remain the same. None is coloured green not because of
*where* it is in the syntax tree, but because of *what* it is. Calling
this "syntax highlighting" is misleading, or at least incomplete.
>> When your editor highlights the function len() in the expression "x =
>> len(y) + spam(z)" but not the function spam(), you know it has nothing
>> to do with syntax. len() is singled out because of its semantics,
>> namely the fact that it's a built-in.
>
> Eww. (I had not yet gotten to the point of finding out that whether
> something was "built-in" or not substantially affected its semantics.)
In some languages, built-in functions truly are special, e.g. they are
reserved words. That's not the case for Python. Nevertheless, the editors
I've used treat built-ins as "pseudo-reserved words" and colourise them.
>> In English, the meaning of the some sentences do benefit by syntax
>> highlighting, and in fact that's partly what punctuation is for:
>> English partly uses punctuation marks as tags to break the sentence
>> structure into sub-sentences, clauses and terms (particularly when the
>> sentence would otherwise be ambiguous).
>
> Punctuation is very different from highlighting, IMHO. That said, I
> find punctuation very effective at being small and discrete, clearly not
> words, and easy to pick out. Color cues are not nearly as good at being
> inobtrusive but automatically parsed.
Well that surely depends on the colour scheme you have. My editor is
fairly restrained -- it uses a handful of colours (although of course you
can customize it and go nuts), and I've made it even more subtle.
To my eyes, the feature of syntax highlighting that alone makes it
worthwhile, its killer feature, is that I can set comments and docstrings
to grey. When I'm scanning code, being able to slide my eyes over greyed-
out comments and docstrings and ignore them with essentially zero effort
is a huge help. That's the thing I most miss, more than anything else,
when using a dumb editor.
>> "Woman shoots man with crossbow"
>
>> Was it the man armed with a crossbow, or the woman? If we could somehow
>> group the clause "with crossbow" with "woman" or "man" by something
>> *other* than proximity, we could remove the ambiguity.
>
> Yes. But syntax highlighting won't help you here -- at least, I've
> never yet seen any editor that showed precedence relations or anything
> similar in its coloring.
Just because nobody has done it yet doesn't mean that some sufficiently
intelligent software in the future couldn't do it :)
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: The trouble with "dynamic attributes".
On Sun, 19 Sep 2010 16:47:26 +1000, Lie Ryan wrote: > On 09/18/10 03:53, Ethan Furman wrote: >> Lie Ryan wrote: >> [snip] >>> And even dict-syntax is not perfect for accessing XML file, e.g.: >>> >>> >>> foo >>> bar >>> >>> >>> should a['b'] be 'foo' or 'bar'? >> >> Attribute style access would also fail in this instance -- how is this >> worked-around? > > By not having multiple b in the first place! Which works just as well for dict access. Given that attribute access is nothing but syntactic sugar for dict access, there is nothing you can do with attribute access that can't be done with dict access. However, the same does not apply in reverse -- there are many things you can't do with attribute access that work fine with dict access. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: programming
On 20 September 2010 16:25, Jordan Blanton wrote: > its not specific terms that i dont understand. its general directions. but > when i dont understand one or two key points in a sentence, its hard to > understand what the directions are telling me to do. Is it possible for you to share the sentence / description with us? My psychic powers have its limits. Cheers, Xav -- http://mail.python.org/mailman/listinfo/python-list
Re: visual studio 2010 question
On Mon, Sep 20, 2010 at 3:08 PM, Ralf Haring wrote: > > After running into the error "Setup script exited with error: Unable > to find vcvarsall.bat" when trying to use easy_install / setuptools a > little digging showed that the MS compiler files in distutils only > support up to Studio 2008. Does anyone know if there is a timetable > for when Studio 2010 will be supported? > > I am using python 2.6.5, but web searching seemed to show that 2.7 or > 3.X didn't support it yet either. You should use VS 2008 - the lack of distutils support is only the first of a long list of issues if you want to use another compiler to build python extensions. Unless you really know what you are doing, you are better off with VS 2008, cheers, David -- http://mail.python.org/mailman/listinfo/python-list
