Re: An assessment of the Unicode standard
On Sun, 30 Aug 2009 00:22:00 -0400, Chris Jones wrote: > On Sat, Aug 29, 2009 at 11:07:17PM EDT, Neil Hodgson wrote: >> Benjamin Peterson: > >> > Like Sanskrit or Snowman language? > >> Sanskrit is mostly written in Devanagari these days which is also >> useful for selling things to people who speak Hindi and other Indian >> languages. > > Is the implication that the principal usefulness of such languages as > Hindi and "other Indian languages" is us selling "things" to them..? I > am not from these climes but all the same, I do find you tone of voice > rather offensive, I think Neil's point is that Unicode has succeeded in the wider world, outside of academic circles, because of the commercial need to communicate between cultures using different character sets. I suppose he could have worded it better, but fundamentally he's right: without the commercial need to trade across the world (information as well as physical goods) I doubt Unicode would be anything more than an interesting curiosity of use only to a few academics and linguists. > considering that you are referring to a culture that's > about 3000 years older and 3000 richer than ours and certainly deserves > our respect. Older, certainly, but richer? There's a reason that Indians come to the West rather than Westerners going to India. As Terry Pratchet has written, age is not linked to wisdom -- just because somebody is old, doesn't mean they're wise, perhaps they've just been stupid for a very long time. The same goes for cultures: old doesn't mean better. Indian culture has been responsible for many wonderful things over the millennia, but the cast system is not one of them, and any culture which glorified sati (suttee) as an act of piety is not one we should look up to. Sati was probably rare even at the height of it's popularity, and vanishingly rare now, and arguably could even be defended as the right of an adult to end their own life when they see fit, but dowry-burning is outright murder and is sadly very common across the Indian sub-continent: some estimates suggest that in the mid-1990s there were nearly 6000 such murders a year in India. If we are to be truly non-racist, we must recognise that the West does not have a monopoly on wickedness, ignorance, spite and sheer awfulness. In any case, I'm not sure we should be talking about Indian culture in the singular -- India is about as large as Western Europe, significantly more varied, and the culture has changed over time. The India which treated the Karma Sutra as a holy book is hardly the same India where people literally rioted in the street because Richard Gere gave the actress Shilpa Shetty a couple of rather theatrical and silly kisses on the cheek. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: break unichr instead of fix ord?
> To reiterate, I am not advocating for any change. I > simply want to understand if there is a good reason > for limiting the use of unchr/ord on narrow builds to > a subset of the unicode characters that Python otherwise > supports. So far, it seems not and that unichr/ord > is a poster child for "purity beats practicality". I think that's actually the case. I went back to the discussions, and found that early 2.2 alpha releases did return two-byte strings from unichr, and that this was changed because Marc-Andre Lemburg insisted. Here are a few relevant messages from the archives (search for unichr) http://mail.python.org/pipermail/python-dev/2001-June/015649.html http://mail.python.org/pipermail/python-dev/2001-July/015662.html http://mail.python.org/pipermail/python-dev/2001-July/016110.html http://mail.python.org/pipermail/python-dev/2001-July/016153.html http://mail.python.org/pipermail/python-dev/2001-July/016155.html http://mail.python.org/pipermail/python-dev/2001-July/016186.html Eventually, in r28142, MAL changed it to give it its current state. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: An assessment of the Unicode standard
Chris Jones: > Is the implication that the principal usefulness of such languages as > Hindi and "other Indian languages" is us selling "things" to them..? Unicode was developed by a group of US corporations: Xerox, Apple, Sun, Microsoft, ... The main motivation was to avoid dealing with multiple character set encodings since this was difficult, time consuming and expensive. > I > am not from these climes but all the same, I do find you tone of voice > rather offensive, considering that you are referring to a culture that's > about 3000 years older and 3000 richer than ours and certainly deserves > our respect. Eh? Was Unicode developed in India? China? What precisely is direspectful here? Is there a significant population that regards Unicode as their 'holy patrimony' that will suffer distress due to my post? > Maybe you didn't notice, but our plants shut down many years ago.. They > are selling _us_ their wares. Maybe your plants shut down but some of the plants I have worked at (such as the steelworks at Port Kembla) are still successfully exporting to Asia. Neil -- http://mail.python.org/mailman/listinfo/python-list
Re: An assessment of the Unicode standard
On Sat, 29 Aug 2009 22:14:55 -0700, John Nagle wrote: > It may be a bit much that Unicode supports Cretan Linear B. Thousands of historians who need to discuss Linear B would disagree. Well, hundreds. There are tens of thousands of characters available. If there's room for chess pieces, dingbats with drop shadows and numbers inside circles, there's room for actual characters from real (if extinct) languages. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: An assessment of the Unicode standard
On Sun, 30 Aug 2009 03:07:17 +, Neil Hodgson wrote: >Not sure if you are referring to the ☃ snowman character or Arctic > region languages like Canadian Aboriginal syllabic writing like ᐲᐦᒑᔨᕽ > which were added to Unicode 8 years after the initial version. I'd guess > that was added from political rather than marketing motives. ☃ was > required since it was present in Japanese character sets. If I recall correctly, the snowman was specifically added at the request of Japanese television producers, because it is a standard glyph used for representing snow when showing the weather on TV. Unicode's stated aim is to have a single universal standard for all characters needed for communication. From the Unicode Consortium: [quote] What is Unicode? Unicode provides a unique number for every character, no matter what the platform, no matter what the program, no matter what the language. ... Even for a single language like English no single encoding was adequate for all the letters, punctuation, and technical symbols in common use. These encoding systems also conflict with one another. That is, two encodings can use the same number for two different characters, or use different numbers for the same character. Any given computer (especially servers) needs to support many different encodings; yet whenever data is passed between different encodings or platforms, that data always runs the risk of corruption. Unicode is changing all that! Unicode provides a unique number for every character, no matter what the platform, no matter what the program, no matter what the language. [end quote] And from the FAQs: [quote] Unicode covers all the characters for all the writing systems of the world, modern and ancient. It also includes technical symbols, punctuations, and many other characters used in writing text. [end quote] It's not just about supporting languages used by foreigners too stupid to speak English (sarcasm!). It's about supporting business users who want a standard way of referring to dingbats and pictographs, historians who need to deal with ancient writings and obsolete characters, scientists and mathematicians who want to use mathematical symbols, editors and book publishers who want to use their own typographic symbols, including Braille, musical symbols, and even TV producers who want to include snowmen on their weather charts. The Unicode system replaces dozens of incompatible, clashing systems with a single universal, extensible system. Why would anyone want to go back to the Bad Old Days where you couldn't transfer data from one OS to another, or even from one application to another, without quote marks turning into mathematical symbols or boxes? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: What python can NOT do?
exar...@twistedmatrix.com wrote: For my part, I will agree with John. I feel like Python's big shortcomings stem from the areas he mentioned. They're related to each other as well - the lack of a standard hampers the development of a less naive interpreter (either one based on CPython or another one). The reference manual is *intended* to define the 'standard' Python language. > It doesn't completely prevent such development (obviously, as CPython continues to undergo development, and there are a number of alternate runtimes for Python-like languages), but there's clearly a cost associated with the fact that in order to do this development, a lot of time has to be spent figuring out what Python *is*. This is the kind of thing that a standard would help with. Such developers occasionally raise questions about ambiguities in the ref manual on the pydev list. This is part of the editing process. There is an effort underway to separate the CPython test suite into two parts: test of standard Python behavior, which all implementations should pass, and tests of the CPython implementation, which other implementations need not pass. It will move as fast as volunteer effort moves it. tjr -- http://mail.python.org/mailman/listinfo/python-list
Re: An assessment of the Unicode standard
On 08/30/2009 04:16 AM, r wrote: I was reading the thread here... http://groups.google.com/group/comp.lang.python/browse_thread/thread/db90a9629b92aab0/b0385050b4c6c84e?hl=en&lnk=raot#b0385050b4c6c84e ... ... It's called evolution people! Ever heard of science? So ditch the useless Unicode and save us all a few keystrokes and bottles of aspirin for the persistent headaches! Simplicity is beautiful!! You are right ! In the same vein, we should all also standardize on using the Java language for programming, after all /everybody/ writes code in Java. cheers, - steve -- random non tech spiel: http://lonetwin.blogspot.com/ tech randomness: http://lonehacks.blogspot.com/ what i'm stumbling into: http://lonetwin.stumbleupon.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: An assessment of the Unicode standard
r wrote: natural languages and Unicode. Which IMO * Unicode* is simply a monkey patch for this soup of multiple languages we have to deal with in programming and communication. A somewhat fair charactierization. [snip] everyone happy? A sort of Utopian free-language-love-fest-kinda- thing? Not utopian, but pragmatically political. Before unicode, and still today, we had and have multiple codes. Multiple ascii extenstions for European languages and even multiple codes just for Japanese. To get people in the major computing countries, including Japan, to agree to eventually replace their national codes with one worldwide code, some kludgy compromises were made. language. The A-Z char set is flawless! Hardly. There are too few characters. A basic set should have at least 50. The international phonetic alphabet (IPA) has about 150. Here is a true Utopian proposal for you (from a non-CS major ;-): develop an extended IPA 256-character set with just a few control chars (rather than 32) and punctuation and other markers. Then develop dictionaries to translate texts in every languange and char set into and back out of this universal character set. Fat chance of approval, even if techical issues were resolved. Some may say well how can we possibly force countries/people to speak/ code in a uniform manner? Well that's simple, you just stop supporting their cryptic languages by dumping Unicode and returning to the beautiful ASCII But most everyone outside the US was not using ascii precisely because it did not support their language. Get over the imperfections of unicode. It improves on the prior status quo. Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: An assessment of the Unicode standard
r wrote: I was reading the thread here... http://groups.google.com/group/comp.lang.python/browse_thread/thread/db90a9629b92aab0/b0385050b4c6c84e?hl=en&lnk=raot#b0385050b4c6c84e and it raised some fundamental philophosical questions Rant ignored. Actually, Python 3.x seems finally to have character sets right. There's "bytes", for uninterpreted binary data, Unicode, and proper ASCII, 0..127. Within Python, we finally got rid of "upper code pages". (I wish the HTML standards people would do the same. HTML 5 should have been ASCII only (with the "&" escapes if desired) or Unicode. No "Latin-1", no upper code pages, no JIS, etc.) [nested thoughts] A few months ago i was watching some tear-jerking documentary called something like "Save the Languages" or "The dying languages" blah! It may be a bit much that Unicode supports Cretan Linear B. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does this group have so much spam?
"casebash" wrote in message news:7294bf8b-9819-4b6d-92b2-afc1c8042...@x6g2000prc.googlegroups.com... > So much of it could be removed even by simple keyword filtering. Assuming this is a serious question: 1. comp.lang.python has relatively little spam, compared to others. 2. The spam posters aren't looking for responses within the individual NGs, they're just hoping you'll click through to the link within the post. It's a version of "fire and forget" 3. Simple keyword filtering /by whom/? There is no central NG governing authority. The best response is to ignore[1] the spam posts; they'll eventually expire and disappear from your newsreader. [1] Although if they're egregiously stupid, you may find yourself mocking the OP. Realize that as witty and urbane as your response may be, the OP ain't listening. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: break unichr instead of fix ord?
"Martin v. Löwis" writes on Fri, 28 Aug 2009 10:12:34 +0200: > > The PEP says: > > * unichr(i) for 0 <= i < 2**16 (0x1) always returns a > >length-one string. > > > > * unichr(i) for 2**16 <= i <= TOPCHAR will return a > >length-one string on wide Python builds. On narrow > >builds it will raise ValueError. > > and > > * ord() is always the inverse of unichr() > > > > which of course we know; that is the current behavior. But > > there is no reason given for that behavior. > > Sure there is, right above the list: > > "Most things will behave identically in the wide and narrow worlds." > > That's the reason: scripts should work the same as much as possible > in wide and narrow builds. > > What you propose would break the property "unichr(i) always returns > a string of length one, if it returns anything at all". But getting a "ValueError" in some builds (and not in others) is rather worse than getting unicode strings of different length > >1) Should surrogate pairs be disallowed on narrow builds? > > That appears to have been answered in the negative and is > > not relevant to my question. > > It is, as it does lead to inconsistencies between wide and narrow > builds. OTOH, it also allows the same source code to work on both > versions, so it also preserves the uniformity in a different way. Do you not have the inconsistencies in any case? ... "ValueError" in some builds and not in others ... -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Noob - gui module, book, annoying questions
On Aug 29, 3:20 am, Pherdnut wrote: > I want to write cross-platform stuff. Any opinions on the best GUI > module for that? > > I like a good juicy, but concise book for reading on my commute > downtown. I was thinking of checking Python in a Nutshell. Good? Bad? > Better? > > Is 3.0+ more object based? I'm actually an FED and one of the things I > love about JS is the consistency of the language. I love Python 2.6 so > far so I'm not knocking it. But I'm not really taking advantage of the > non-core libraries as much right now anyway since I'm learning it. > > What do you guys like in Reg Ex books/sites? I'd like to become more > fluent in some of the less commonly used stuff. Also wxPython. It's cross platform, but it does require occasional platform-dependent tweaks, since it mostly uses native controls and sometimes the native controls' requirements are different. You might want to consider that it's going to be some time before the 3rd party libraries catch up to Python 3. I'd recommend 2.5 or 2.6 for learning now if you plan on using them. -- http://mail.python.org/mailman/listinfo/python-list
Re: What python can NOT do?
qwe rty wrote: > On Aug 29, 5:11 am, Nobody wrote: >> On Fri, 28 Aug 2009 17:26:06 -0700, qwe rty wrote: >>> if you don't know the answer please don't reply >> If you don't understand the question, don't post it in the first place. > > don't be so angry ,not good for your health You forgot your smiley emoticon! Since everyone else is posting in a light-hearted manner (not "angry" as you say), I choose to read your post in this light as well. What Nobody was really trying to say, is ask your question in a better way and you'll get a better answer. -- http://mail.python.org/mailman/listinfo/python-list
Re: What python can NOT do?
On Aug 28, 6:37 pm, qwe rty wrote: > i know that an interpreted language like python can't be used to make > an operating system or system drivers. > > what else can NOT be done in python? what are the limitations of the > language? Now that you have some good answers, may I ask what what your reason was for posting this question? -- http://mail.python.org/mailman/listinfo/python-list
Re: IDE for python similar to visual basic
On Aug 28, 6:19 pm, qwe rty wrote: > i have been searching for am IDE for python that is similar to Visual > Basic but had no luck.shall you help me please? Boa Constructor. IDE/visual GUI-builder/sizer support, lots of other goodies. Not actively maintained, though, and some issues on Linux, in my experience. But I like it a lot. -- http://mail.python.org/mailman/listinfo/python-list
Re: An assessment of the Unicode standard
On Sat, Aug 29, 2009 at 11:07:17PM EDT, Neil Hodgson wrote: > Benjamin Peterson: > > Like Sanskrit or Snowman language? > Sanskrit is mostly written in Devanagari these days which is also > useful for selling things to people who speak Hindi and other Indian > languages. Is the implication that the principal usefulness of such languages as Hindi and "other Indian languages" is us selling "things" to them..? I am not from these climes but all the same, I do find you tone of voice rather offensive, considering that you are referring to a culture that's about 3000 years older and 3000 richer than ours and certainly deserves our respect. Maybe you didn't notice, but our plants shut down many years ago.. They are selling _us_ their wares. > Not sure if you are referring to the snowman character or Arctic > region languages like Canadian Aboriginal syllabic writing like ᐲᐦᒑᔨᕽ > which were added to Unicode 8 years after the initial version. I'd > guess that was added from political rather than marketing motives. ☃ > was required since it was present in Japanese character sets. Oh.. so.. now Unicode is not only about marketing.. there is also a political "aspect".. polytonic Greek, Runic, Shavian, Glagolitic, Carian, Phoenician, Lydian, Cuneiform, not to mention Mathematical symbols, Braille, Domino Tiles, the IPA..? What was I thinking..? Nothing personal, I assure you.. maybe I misunderstood what you were saying. In any event, you shouldn't feed the troll, even if he's teething. CJ -- http://mail.python.org/mailman/listinfo/python-list
Re: why python got less developers ?
On Aug 29, 6:16 am, paul wrote: > Deep_Feelings schrieb:> python got relatively fewer numbers of developers > than other high > > level languages like .NET , java .. etc why ? > > Besides the marketing argument, python never had a "hype". > > Both PHP and ruby(Rails to be precise) got widespread because they could > at one point do "one" thing better than the competition. From there > on, they had more ressources (developer time) and grew fast and beyond > the original problem domain. Now you can write GUI apps in PHP, great! > > cheers > Paul You guys can say anything you'd like it to be in this thread, but the actual reason comes down to 1. No marketing. Seriously, if Microsoft was pushing Python it would obviously be a lot bigger in terms of developers. 2. No certification. Millions go to college to get degrees in computer related study. Do the math. Also, really guys? This crap about speed? People have been saying this for years, and yet they still don't realize that there are plenty solutions to take care of that one problem. Just be happy that you've stumbled upon Python, just because it's not the most widespread language in the world certainly doesn't mean it's not a worthy language. Quite the opposite. -- http://mail.python.org/mailman/listinfo/python-list
Re: An assessment of the Unicode standard
r wrote: > Of the many > things that divide us such as race, color, religion, geography, blah, > the most perplexing and devastating seems to be why have we not > accepted a single global language for all to speak. I agree 1000% and obviously we should make Klingon that global language. Or possibly the Black Tongue of the Mordor Orcs, which is much better for cursing. I haven't decided yet. > Take for instance the Chinese language with it's thousands of > characters and BS, it's more of an art than a language. Why do we > need such complicated languages in this day and time. Many languages > have been perfected, (although not perfect) far beyond that of Chinese > language. The A-Z char set is flawless! How do we distinguish resume from résumé without accents? Even when we succeed in banning all languages that can't be written using A-Z, what do we do about the vast number of legacy documents? How do we write about obsolete English letters like Ð and Þ without Unicode? How do we write mathematical and scientific documents without characters like Δ → λ ∫ and ∞ ? What do we use to replace typographic symbols and dingbats like † without Unicode? > Some may say well how can we possibly force countries/people to speak/ > code in a uniform manner? Well that's simple, you just stop supporting > their cryptic languages by dumping Unicode and returning to the > beautiful ASCII and adopting English as the universal world language. > Why English? Well because it is so widely spoken. World population: 6.7 billion Number of native Mandarin speakers: 873 million Number of native Hindi speakers: 370 million Number of native Spanish speakers: 350 million Number of native English speakers: 340 million Total number of Mandarin speakers: 1051 million Total number of English speakers: 510 million http://www.vistawide.com/languages/top_30_languages.htm Whichever way you look at it, we should all convert to Mandarin, not English. Looks like we still need Unicode. Besides, given that the US would be bankrupt if not for Chinese loans, do you really want to upset them by suggesting their language sucks? > But whatever we > choose just choose one language and stick with it, perfect it, and > maintain it. Just ask the Academie Francaise how well that works! Why stop with A-Z? We can improve on 26 letters. In the first year we should replace the soft 'c' with 's'. Any sivilized language will sertainly be better off with this change. The hard 'c' will be dropped in favour of 'k', which will klear up much konfusion and allow one key less on keyboards. In the sekond year I expect publik enthusiasm to grow, allowing us to replace the troublesome 'ph' with 'f', which will make words like 'fotograf' twenty persent shorter. In the third year, publik akseptanse of the new spelling kan be expekted to permit more komplikated changes. We will enkourage the removal of double leters which have always ben a deterent to akurate speling. Also, al wil agre that the horible mes of the silent 'e' is disgrasful. By the fourth yer, peopl wil be reseptiv to replasing 'th' with 'z' and 'w' with 'v'. Zis vil be a grat improvment. During ze fifz yer, ze unesesary 'o' kan be dropd from vords kontaining 'ou' and similar changes vud of kors be aplid to ozer kombinations of leters. After zis fifz yer, ve vil hav a reli sensibl riten styl. Zer vil be no mor trubls or difikultis and everivun vil find it ezi to understand ech ozer. ZE DREM VIL FINALI COM TRU! > IMO Multiple languages are barriers to communication, collaboration, > and the continuation of our future evolution as intelligent Human > beings and this language multiplicity will comprise our future until > it is reigned in and utterly destroyed. Yes, because language differences have utterly destroyed us so many times in the past! Have you thought about the difference between China, with one culture and one spoken language for thousands of years, and Europe, with dozens of competing cultures, competing governments, and alternate languages for just as long? If multiple languages are so harmful, why was it the British, French, Japanese, Russians, Germans, Italians, Austrians, Hungarians and Americans who were occupying China during the Opium Wars and the Boxer Rebellion, instead of the other way around? Strength comes from diversity, not monoculture. -- http://mail.python.org/mailman/listinfo/python-list
Re: Permanently adding to the Python path in Ubuntu
On Aug 29, 5:39 pm, Chris Colbert wrote: > I'm having an issue with sys.path on Ubuntu. I want some of my home > built packages to overshadow the system packages. Namely, I have built > numpy 1.3.0 from source with atlas support, and I need it to > overshadow the system numpy 1.2.1 which I had to drag along as a > dependency for other stuff. I have numpy 1.3.0 installed into > /usr/local/lib/python2.6/dist-packages/. The issue is that this > directory is added to the path after the > /usr/lib/python2.6/dist-packages/ is added, so python doesnt see my > version of numpy. > > I have been combating this with a line in my .bashrc file: > > export PYTHONPATH=/usr/local/lib/python2.6/dist-packages > > So when I start python from the shell, everything works fine. > > Problems show up when python is not executed from the shell, and thus > the path variable is never exported. This can occur when I have > launcher in the gnome panel or i'm executing from within wing-ide. > > Is there a way to fix this so that the local dist-packages is added to > sys.path before the system directory ALWAYS? I can do this by editing > site.py but I think it's kind of bad form to do it this way. I feel > there has to be a way to do this without root privileges. > > Any ideas? > > Cheers, > > Chris I think you can modify sys.path inside your application. Maybe this will work (at the top of your script): import sys sys.path[0] = "/usr/local/lib/python2.6/dist-packages" import numpy PS. Say hi to Steven for me! ~Sean -- http://mail.python.org/mailman/listinfo/python-list
Re: Sqlite format string
On 29Aug2009 17:27, Sergio Charpinel Jr. wrote:
| Hi,
| I have this statement cursor.execute("SELECT * from session_attribute WHERE
| sid=%s", ( user ))
| and I'm receiving this error :
|
| TypeError: not all arguments converted during string formatting
|
| What is wrong ?
This:
( user )
is not a tuple containing the element user. It's just user.
This:
( user, )
is what you want.
--
Cameron Simpson DoD#743
http://www.cskk.ezoshosting.com/cs/
[Alain] had been looking at his dashboard, and had not seen me, so I
ran into him. - Jean Alesi on his qualifying prang at Imola '93
--
http://mail.python.org/mailman/listinfo/python-list
Re: An assessment of the Unicode standard
Benjamin Peterson: > Like Sanskrit or Snowman language? Sanskrit is mostly written in Devanagari these days which is also useful for selling things to people who speak Hindi and other Indian languages. Not sure if you are referring to the ☃ snowman character or Arctic region languages like Canadian Aboriginal syllabic writing like ᐲᐦᒑᔨᕽ which were added to Unicode 8 years after the initial version. I'd guess that was added from political rather than marketing motives. ☃ was required since it was present in Japanese character sets. Neil -- http://mail.python.org/mailman/listinfo/python-list
Re: (Simple?) Unicode Question
On Sat, 29 Aug 2009 20:09:12 +0100, Nobody wrote:
> On Sat, 29 Aug 2009 08:26:54 +, Steven D'Aprano wrote:
>
>> Python only needs to know when you convert the text to or from bytes. I
>> can do this:
>>
> s = "hello"
> t = "world"
> print(' '.join([s, t]))
>> hello world
>>
>> and not need to care anything about encodings.
>>
>> So long as your terminal has a sensible encoding, and you have a good
>> quality font, you should be able to print any string you can create.
>
> UTF-8 isn't a particularly sensible encoding for terminals.
Did I mention UTF-8?
Out of curiosity, why do you say that UTF-8 isn't sensible for terminals?
> And "Unicode font" is an oxymoron. You can merge a whole bunch of fonts
> together and stuff them into a TTF file; that doesn't make them "a
> font", though.
I never mentioned "Unicode font" either. In any case, there's no reason
why a skillful designer can't make a single font which covers the entire
Unicode range in a consistent style.
I may be wrong, but I believe that's part of the idea between
separation of string and bytes types in Python 3.x. I believe, if you
are using Python 3.x, you don't need the character encoding mumbo
jumbo at all ;-)
>>>
>>> Nothing has changed in that regard. You still need to decode and
>>> encode text and for that you have to know the encoding.
>>
>> You only need to worry about encoding when you convert from bytes to
>> text, and visa versa. Admittedly, the most common time you need to do
>> that is when reading input from files, but if all your text strings are
>> generated by Python, and not output anywhere, you shouldn't need to
>> care about encodings.
>
> Why would you generate text strings and not output them anywhere?
Who knows? It doesn't matter -- the point is that you can if you want to.
You only need to worry about encodings at input and output, therefore
logically if you don't do I/O you can process strings all day long and
never worry about encodings at all.
> The main advantage of using Unicode internally is that you can associate
> encodings with the specific points where data needs to be converted
> to/from bytes, rather than having to carry the encoding details around
> the program.
Surely the main advantage of Unicode is that it gives you a full and
consistent range of characters not limited to the 128 characters provided
by ASCII?
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: copy construtor question
28-08-2009 o 20:38:30 xiaosong xia wrote:
I am trying to define a class with copy constructor as following:
class test:
def __init__(self, s=None):
self=s
x=[1,2]
y=test(x)
print y.__dict__
it gives
{}
The above code doesn't work.
And cannot, as Chris has already written. But it is possible to
customize construction of objects of your class -- using __new__():
[see: http://docs.python.org/reference/datamodel.html#object.__new__ ]
import copy
# in Python 2.x you must explicitly inherit from 'object' type
class Test(object):
"Not tested"
def __new__(cls, s, way=None):
if s is None:
# a new object of 'Test' class
return super(currentclass, cls).__new__(cls, *args)
else:
if way == 'alias':
return s
elif way == 'shallow':
return copy.copy(s)
elif way == 'deep':
return copy.deepcopy(s)
else:
raise ValueError("'way' must be 'alias', "
"'shallow' or 'deepcopy'")
...but in such cases as copying existing objects it is usualy better
(though less romantic :-)) to use an ordinary function (e.g. simply
copy.copy() or copy.deepcopy(), as Gabriel has pointed).
Regards,
*j
--
Jan Kaliszewski (zuo)
--
http://mail.python.org/mailman/listinfo/python-list
Re: What python can NOT do?
On Aug 28, 7:05 pm, Tim Chase wrote: > qwe rty wrote: > > i know that an interpreted language like python can't be used to make > > an operating system or system drivers. > > As long as you are willing to write the OS hooks in C, you can > write the userspace device drivers in Python: Writing your OS hooks in C isn't a problem because you could write a C compiler in Python ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: An assessment of the Unicode standard
Neil Hodgson gmail.com> writes: \\ > > Unicode was > developed by corporations from the US left coast in order to sell their > products in foreign markets at minimal cost. Like Sanskrit or Snowman language? -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does this group have so much spam?
On Aug 29, 7:18 pm, casebash wrote: > So much of it could be removed even by simple keyword filtering. A more interesting question is what morons are responding to this spam and enticing the spammers to proliferate their garbage? Do people actually see a spam like "Phallus enlargement pills" and say to themself "Alright!, just what i been looking for!". I guess i just can't understand foolishness... Yes i agree, far to much spam is getting through. -- http://mail.python.org/mailman/listinfo/python-list
Re: An assessment of the Unicode standard
On Aug 29, 7:20 pm, John Machin wrote:
> On Aug 30, 8:46 am, r wrote:
> The Chinese language is more widely spoken than English, is quite
> capable of expression in ASCII ("r tongzhi shi sha gua") and doesn't
> have those pesky it's/its problems.
Oh yes of course it is the most widely spoken amongst Chinese people
since one in every five people on this earth are Chinese. What i meant
to say was that English language is more widespread outside of
"normal" English speaking countries -- of course as a result of
colonialism, and arguably, imperialism. ;)
--
http://mail.python.org/mailman/listinfo/python-list
Permanently adding to the Python path in Ubuntu
I'm having an issue with sys.path on Ubuntu. I want some of my home built packages to overshadow the system packages. Namely, I have built numpy 1.3.0 from source with atlas support, and I need it to overshadow the system numpy 1.2.1 which I had to drag along as a dependency for other stuff. I have numpy 1.3.0 installed into /usr/local/lib/python2.6/dist-packages/. The issue is that this directory is added to the path after the /usr/lib/python2.6/dist-packages/ is added, so python doesnt see my version of numpy. I have been combating this with a line in my .bashrc file: export PYTHONPATH=/usr/local/lib/python2.6/dist-packages So when I start python from the shell, everything works fine. Problems show up when python is not executed from the shell, and thus the path variable is never exported. This can occur when I have launcher in the gnome panel or i'm executing from within wing-ide. Is there a way to fix this so that the local dist-packages is added to sys.path before the system directory ALWAYS? I can do this by editing site.py but I think it's kind of bad form to do it this way. I feel there has to be a way to do this without root privileges. Any ideas? Cheers, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Determining the metaclass
On Aug 29, 5:12 pm, casebash wrote: > Hi all, > > I cannot determine if a class is an instance of a particular > metaclass. Here is my best attempt > > >>> class tmp(type): > > ... pass > ...>>> def c(metaclass=tmp): > > ... pass > ...>>> isinstance(c, tmp) > False > >>> isinstance(c.__class__, tmp) > > False > > Can anyone explain why this fails? You're gonna kick yourself. It's because you used "def" and not "class" to define c. If you'd used "class" then then first test would have worked. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: An assessment of the Unicode standard
r: > Unicode (*puke*) seems nothing more than a brain fart of morons. And > sadly it was created by CS majors who i assumed used logic and > deductive reasoning but i must be wrong. Why should the larger world > keep supporting such antiquated languages and character sets through > Unicode? What purpose does this serve? Are we merely trying to make > everyone happy? A sort of Utopian free-language-love-fest-kinda- > thing? Wow, I like this world you live in: all that altruism! Unicode was developed by corporations from the US left coast in order to sell their products in foreign markets at minimal cost. Neil -- http://mail.python.org/mailman/listinfo/python-list
Re: An assessment of the Unicode standard
On Aug 30, 8:46 am, r wrote:
>
> Take for instance the Chinese language with it's thousands of
> characters and BS, it's more of an art than a language. Why do we
> need such complicated languages in this day and time. Many languages
> have been perfected, (although not perfect) far beyond that of Chinese
> language.
The Chinese language is more widely spoken than English, is quite
capable of expression in ASCII ("r tongzhi shi sha gua") and doesn't
have those pesky it's/its problems.
> The A-Z char set is flawless!
... for expressing the sounds of a very limited number of languages,
and English is *NOT* one of those.
--
http://mail.python.org/mailman/listinfo/python-list
Re: break unichr instead of fix ord?
On 08/29/2009 01:43 PM, Vlastimil Brom wrote:
> > 2009/8/29:
>> >> On 08/28/2009 02:12 AM, "Martin v. Löwis" wrote:
>> >>
>> >> So far, it seems not and that unichr/ord
>> >> is a poster child for "purity beats practicality".
>> >> --
>> >> http://mail.python.org/mailman/listinfo/python-list
>> >>
> >
> > As Mark Tolonen pointed out earlier in this thread, in Python 3 the
> > practicality apparently beat purity in this aspect:
> >
> > Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit
> > (Intel)] on win32
> > Type "copyright", "credits" or "license()" for more information.
> >
goth_urus_1 = '\U0001033f'
list(goth_urus_1)
> > ['\ud800', '\udf3f']
len(goth_urus_1)
> > 2
ord(goth_urus_1)
> > 66367
goth_urus_2 = chr(66367)
len(goth_urus_2)
> > 2
import unicodedata
unicodedata.name(goth_urus_1)
> > 'GOTHIC LETTER URUS'
goth_urus_3 = unicodedata.lookup("GOTHIC LETTER URUS")
goth_urus_4 = "\N{GOTHIC LETTER URUS}"
goth_urus_1 == goth_urus_2 == goth_urus_3 == goth_urus_4
> > True
Yes, that certainly seems like much more sensible behavior.
> > As for the behaviour in python 2.x, it's probably good enough, that
> > the surrogates aren't prohibited and the eventually needed behaviour
> > can be easily added via custom functions.
Yes, I agree that given the current behavior is well documented
and further, is fixed in python 3, it can't be changed.
I would a nit though with "can be easily added via custom
functions."
I don't think that is a good criterion for rejection of functionality
from the library because it is not sufficient; their are many
functions
in the library that fail that test. I think the criterion should
be more like a ratio: (how often needed) / (ease of writing).
[where "ease" is not just the line count but also the obviousness
to someone who is not a python expert yet.]
And I would also dispute that the generalized unichr/ord functions
are "easily" added. When I ran into the TypeError in ord(), I
thought "surrogate pairs" were something used in sex therapy. :-)
It took a lot of reading and research before I was able to write
a generalized ord() function.
--
http://mail.python.org/mailman/listinfo/python-list
Determining the metaclass
Hi all, I cannot determine if a class is an instance of a particular metaclass. Here is my best attempt >>> class tmp(type): ... pass ... >>> def c(metaclass=tmp): ... pass ... >>> isinstance(c, tmp) False >>> isinstance(c.__class__, tmp) False Can anyone explain why this fails? Thanks very much, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: break unichr instead of fix ord?
On 08/29/2009 12:06 PM, Steven D'Aprano wrote: [...] >> The reasons for the current behavior so far: >> >> 1. >>> What you propose would break the property "unichr(i) always returns a >>> string of length one, if it returns anything at all". >> >> Yes. And i don't see the problem with that. Why is that property more >> desirable than the non-existent property that a Unicode literal always >> produces one python character? > > What do you mean? Unicode literals don't always produce one character, > e.g. u'abcd' is a Unicode literal with four characters. I'm sorry, I should have been clearer. I meant the literal representation of a *single* unicode character. u'\u4000' which results in a string of length 1, vs u'\U00010040' which results in a string of length 2. In both case the literal represents a single unicode code point. > I think it's fairly self-evident that a function called uniCHR [emphasis > added] should return a single character (technically a single code > point). There are two concepts of characters here, the 16-bit things that encodes a character in a Python unicode string (in a narrow build Python), and a character in the sense of one of the ~2**10 unicode characters. Python has chosen to represent the latter (when outside the BMP) as a pair of surrogate characters from the former. I don't see why one would assume that CHR would mean the python 16-bit character concept rather than the full unicode character concept. In fact, rather the opposite. > But even if you can come up with a reason for unichr() to return > two or more characters, I've given a number of reasons why it should return a two character representation of a non-BMP character, one of which is that that is how Python has chosen to represent such characters internally. I won't repeat the other reasons again. I'm not sure why you think more than two characters would ever be possible. > this would break code that relies on the > documented promise that the length of the output of unichr() is always > one. Ah, OK. This is the good reason I was looking for. I did not realize (until prompted by your remark to go back and look at the early docs) that unichr had been documented to return a single character since 2.0 and that wide character support was added in 2.2. Martin v. Loewis also implied that, I now see, although the implication was too deep for me to pick up. So although it leads to a suboptimal situation, I agree that maintaining the documented behavior was necessary. [...] > I would much rather see a pair of new functions, wideord() and > widechr() used for converting between surrogate pairs and numbers. I guess if it were still 2001 and Python 2.2 was coming out I would be in favor of this too. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: An assessment of the Unicode standard
On Sat, Aug 29, 2009 at 07:12:26PM EDT, Stephen Hansen wrote: > > > > Unicode (*puke*) seems nothing more than a brain fart of morons. And > > sadly it was created by CS majors who i assumed used logic and > > deductive reasoning but i must be wrong. Why should the larger world > > keep supporting such antiquated languages and character sets through > > Unicode? What purpose does this serve? Are we merely trying to make > > everyone happy? A sort of Utopian free-language-love-fest-kinda- > > thing? > > > > One really shouldn't consider Xah Lee a role model and seek to imitate > (poorly) his rants. :-) CJ -- http://mail.python.org/mailman/listinfo/python-list
Re: how to edit .wsgi file extebtions with IDLE on windows
On Aug 29, 11:16 pm, "Gabriel Genellina"
wrote:
> En Sat, 29 Aug 2009 17:14:14 -0300, gert escribió:
>
> > On Aug 29, 9:31 pm, Chris Rebert wrote:
> >> On Sat, Aug 29, 2009 at 5:40 AM, gert wrote:
> >> > On Aug 29, 6:43 am, "Gabriel Genellina"
> >> > wrote:
> >> >> En Fri, 28 Aug 2009 15:31:31 -0300, gert
> >> escribió:
>
> >> >> > I can't figure out how to enable the .py shell and syntax
> >> highlighting
> >> >> > for .wsgi file extensions using IDLE for windows ?
>
> >> >> That's a Windows question, not a Python one. You have to associate
> >> the
> >> >> .wsgi extension with the Python.File file type (the one used for .py
> >> >> files):
>
> >> >> D:\USERDATA\Gabriel>assoc .py
> >> >> .py=Python.File
>
> >> >> D:\USERDATA\Gabriel>assoc .wsgi=Python.File
> >> >> .wsgi=Python.File
>
> >> > Thanks that does make it open exactly like a .py file, expect that
> >> > there is no syntax highlighting. Don't know if this is also a windows
> >> > issue or a IDLE issue ?
>
> >> That's an IDLE issue; it only highlights files with .py (and possibly
> >> .pyw) extensions.
>
> > Any chance they would make a highlight option in the menu ?
>
> Two alternatives:
>
> a) Ensure your scripts contain a shebang - no purpose on Windows, but IDLE
> recognizes the file as a Python file. That is, make sure the very first
> line is like this:
>
> #!c:\python26\python.exe
>
> (it must start with #! and contain the word "python" somewhere)
>
> b) Edit IDLE sources:
>
> - Locate the file EditorWindow.py in the idlelib package.
>
> - Add this line near the top:
> import _winreg
>
> - Modify function ispythonsource near line 580 as follows:
>
> def ispythonsource(self, filename):
> if not filename or os.path.isdir(filename):
> return True
> base, ext = os.path.splitext(os.path.basename(filename))
> if os.path.normcase(ext) in (".py", ".pyw"):
> return True
> ### add these 4 lines ###
> with _winreg.OpenKey(_winreg.HKEY_CLASSES_ROOT, ext) as key:
> ftype = _winreg.QueryValueEx(key, None)[0]
> if ftype.lower() in ("python.file","python.noconfile"):
> return True
> ### end ###
> try:
> f = open(filename)
> line = f.readline()
> f.close()
> except IOError:
> return False
> return line.startswith('#!') and line.find('python') >= 0
>
Thanks. Can you make a ispythonsource menu option in the next
python3.x release? There are many examples of txt, xml or wsgi files
having python parts in them.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Object's nesting scope
En Sat, 29 Aug 2009 04:34:48 -0300, zaur escribió: On 29 авг, 08:37, "Gabriel Genellina" wrote: En Fri, 28 Aug 2009 15:25:55 -0300, zaur escribió: > On 28 авг, 16:07, Bruno Desthuilliers 42.desthuilli...@websiteburo.invalid> wrote: >> zaur a écrit : >> > Ok. Here is a use case: object initialization. >> Err... Looks like you really should read the FineManual(tm) - >> specifically, the parts on the __init__ method. > What are you doing if 1) classes Person and Address imported from > foreign module 2) __init__ method is not defined as you want? Welcome to dynamic languages! It doesn't matter *where* the class was defined. You may add new attributes to the instance (even methods to the class) at any time. [...4 examples...] I know about these ways of object initializing. What I said is about using object's dictionary as nested scope in code block. Object initialization is just one use case. So we say about different things. Well, you asked how to proceed in certain cases and I showed several ways it can be done right now, without requiring a new scope. You'll have to think of another use case. Attribute lookup is explicit in Python, and that's a very good thing. If you follow the python-ideas thread posted earlier, you'll see the kind of problems an implicit attribute lookup would cause. The "with" statement is necesary (and a good thing) in Pascal, but not in Python. Zope2 departs from this explicitness: it has a construct (similar to what you propose), and I hate it profoundly every time I have to edit a DTML file - I can never tell *where* an attribute comes from. Another related "feature" is acquisition, a stack of namespaces where objects "inherit" attributes from their containers. Same thing, a complete waste of time every time I have to track a bug. Unless you can find a very compeling use case, I don't think this feature will become part of the language anytime soon... -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: An assessment of the Unicode standard
> > Unicode (*puke*) seems nothing more than a brain fart of morons. And > sadly it was created by CS majors who i assumed used logic and > deductive reasoning but i must be wrong. Why should the larger world > keep supporting such antiquated languages and character sets through > Unicode? What purpose does this serve? Are we merely trying to make > everyone happy? A sort of Utopian free-language-love-fest-kinda- > thing? > One really shouldn't consider Xah Lee a role model and seek to imitate (poorly) his rants. The Real World isn't going away just because you think we should stick our heads in the sand and pretend it's not there. There are billions of people out there who are quite happy with their language, and I'd rather keep them as a customer, thanks. --S -- http://mail.python.org/mailman/listinfo/python-list
Re: What python can NOT do?
On 10:23 pm, a...@pythoncraft.com wrote: In article <4a998465$0$1637$742ec...@news.sonic.net>, John Nagle wrote: Personally, I consider Python to be a good language held back by too-close ties to a naive interpreter implementation and the lack of a formal standard for the language. Name one language under active development that has not been harmed by a formal standard. (I think C doesn't count -- there was relatively little development of C after the standards process started.) I think you must mean "harmed by a formal standard more than it has been helped", since that's clearly the interesting thing. And it's a pretty difficult question to answer. How do you quantify the harm done to a language by a standarization process? How do you quantify the help? These are extremely difficult things to measure objectively. For my part, I will agree with John. I feel like Python's big shortcomings stem from the areas he mentioned. They're related to each other as well - the lack of a standard hampers the development of a less naive interpreter (either one based on CPython or another one). It doesn't completely prevent such development (obviously, as CPython continues to undergo development, and there are a number of alternate runtimes for Python-like languages), but there's clearly a cost associated with the fact that in order to do this development, a lot of time has to be spent figuring out what Python *is*. This is the kind of thing that a standard would help with. Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
An assessment of the Unicode standard
I was reading the thread here... http://groups.google.com/group/comp.lang.python/browse_thread/thread/db90a9629b92aab0/b0385050b4c6c84e?hl=en&lnk=raot#b0385050b4c6c84e and it raised some fundamental philophosical questions to me about natural languages and Unicode. Which IMO * Unicode* is simply a monkey patch for this soup of multiple languages we have to deal with in programming and communication. Unicode (*puke*) seems nothing more than a brain fart of morons. And sadly it was created by CS majors who i assumed used logic and deductive reasoning but i must be wrong. Why should the larger world keep supporting such antiquated languages and character sets through Unicode? What purpose does this serve? Are we merely trying to make everyone happy? A sort of Utopian free-language-love-fest-kinda- thing? But there is a larger problem that is at the heart of Unicode itself, and it has to do with this multi-language/multi-culture world we live in. Even today in 2009 AD with all our technology and advancements we still live in a dark ages of societal communication. Of the many things that divide us such as race, color, religion, geography, blah, the most perplexing and devastating seems to be why have we not accepted a single global language for all to speak. Take for instance the Chinese language with it's thousands of characters and BS, it's more of an art than a language. Why do we need such complicated languages in this day and time. Many languages have been perfected, (although not perfect) far beyond that of Chinese language. The A-Z char set is flawless! Some may say well how can we possibly force countries/people to speak/ code in a uniform manner? Well that's simple, you just stop supporting their cryptic languages by dumping Unicode and returning to the beautiful ASCII and adopting English as the universal world language. Why English? Well because it is so widely spoken. But whatever we choose just choose one language and stick with it, perfect it, and maintain it. IMO Multiple languages are barriers to communication, collaboration, and the continuation of our future evolution as intelligent Human beings and this language multiplicity will comprise our future until it is reigned in and utterly destroyed. And i think most of you are missing how important this really is to our future. And so these problems bring me to the main subject of this thread "Unicode Sucks" Now you may say to yourself "I am not a sociologist i am a programmer, so why should i give a flying fig about natural languages or Unicode, i just accept things as they are". Well yes you could just go on accepting the status quo that is surely the easy route, but your life would be so much easier if you crusaded for change. BUT STOP!, before i go any further i want to respond to what i know will be condemnation from the sociology nuts out there. Yes multiculturalism is great, yes art is great, but if you can't see how the ability to communicate is severely damperd by multi-languages then you only *feel* with your heart but you apparently have no ability to reason with your mind intelligently. [nested thoughts] A few months ago i was watching some tear-jerking documentary called something like "Save the Languages" or "The dying languages" blah! In the documentary these two bleeding-heart-ivy-leaguers were running all over the world to document some obscure languages that were on the verge of extinction. And at one utterly amazing point in the episode they start crying and moaning for the loss of these languages like their own mother had died a horrible death. I watched all this in much horror and disbelief with jaw-dropped and i am still scared by the thought that people actually buy into this BS! Has the world gone mad? [back on track] The death of a language is as natural as the death of a flower, or a fish, or even the ever long oxidation of aluminum coke can. When a life form dies it brings life to the next generation. With languages, each death compiles upon the last and we are one step closer to the unifying language that we all so disparately need. We should herald the death of the languages like the jazz funerals of New Orleans with much happiness and fanfare for there is no reason to be sad. It's called evolution people! Ever heard of science? So ditch the useless Unicode and save us all a few keystrokes and bottles of aspirin for the persistent headaches! Simplicity is beautiful!! -- http://mail.python.org/mailman/listinfo/python-list
Re:Re: Sqlite format string
29.08.2009 17:26 пользователь Tim Chase
написал:
ivanko@gmail.com wrote:
29.08.2009 15:40 пользователь "Sergio Charpinel Jr."
sergiocharpi...@gmail.com> написал:
Thanks.
Do you know if both of them works for mysql too?
2009/8/29 ivanko@gmail.com>
29.08.2009 15:27 пользователь "Sergio Charpinel Jr."
sergiocharpi...@gmail.com> написал:
Actually, this works for any string (it doesn't depend on anything else).
So you can pass "somestring {0}".format(foo) to any function because the
string will be formatted _first_ and then passed as an argument. The same
goes with "somestring %s" % "foo". Both will work
Bad idea when assembling SQL, unless you _like_ SQL-injection attacks:
sql = "select * from users where name='%s' and password='%s'"
# get some values from an untrusted user:
name = "administrator"
password = "' or 1=1; drop table users; --"
cursor.execute(sql % (name, password))
# uh-oh!
This is why it's so important to use the DB API's own escaping functions.
-tkc
Sergio, Tim Chase is absolutely right! What you can do here is check every
field separately OR you can modify the format() method to automatically do
that. In the second case, you need to create your method first and then
assign it to the str.format method like that: str.format =
your_format_method . Note that there are NO parenthesis. For more details,
look at this recipe: http://code.activestate.com/recipes/92823/ . I think
it will simplify the things for you later, as every time you will call the
str.format method, the values will be checked automatically.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Sqlite format string
ivanko@gmail.com wrote:
29.08.2009 15:40 пользователь "Sergio Charpinel Jr."
написал:
Thanks.
Do you know if both of them works for mysql too?
2009/8/29 ivanko@gmail.com>
29.08.2009 15:27 пользователь "Sergio Charpinel Jr."
sergiocharpi...@gmail.com> написал:
Actually, this works for any string (it doesn't depend on anything else).
So you can pass "somestring {0}".format(foo) to any function because the
string will be formatted _first_ and then passed as an argument. The same
goes with "somestring %s" % "foo". Both will work
Bad idea when assembling SQL, unless you _like_ SQL-injection
attacks:
sql = "select * from users where name='%s' and password='%s'"
# get some values from an untrusted user:
name = "administrator"
password = "' or 1=1; drop table users; --"
cursor.execute(sql % (name, password))
# uh-oh!
This is why it's so important to use the DB API's own escaping
functions.
-tkc
--
http://mail.python.org/mailman/listinfo/python-list
Re: What python can NOT do?
In article <4a998465$0$1637$742ec...@news.sonic.net>, John Nagle wrote: > >Personally, I consider Python to be a good language held back by >too-close ties to a naive interpreter implementation and the lack >of a formal standard for the language. Name one language under active development that has not been harmed by a formal standard. (I think C doesn't count -- there was relatively little development of C after the standards process started.) -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "I support family values -- Addams family values" --www.nancybuttons.com -- http://mail.python.org/mailman/listinfo/python-list
Re:Re: Sqlite format string
29.08.2009 15:40 пользователь "Sergio Charpinel Jr."
написал:
Thanks.
Do you know if both of them works for mysql too?
2009/8/29 ivanko@gmail.com>
29.08.2009 15:27 пользователь "Sergio Charpinel Jr."
sergiocharpi...@gmail.com> написал:
Actually, this works for any string (it doesn't depend on anything else).
So you can pass "somestring {0}".format(foo) to any function because the
string will be formatted _first_ and then passed as an argument. The same
goes with "somestring %s" % "foo". Both will work
--
http://mail.python.org/mailman/listinfo/python-list
Re: weak reference callback
Christian Heimes wrote:
> Paul Pogonyshev wrote:
> > Hi,
> >
> > Is weak reference callback called immediately after the referenced
> > object is deleted or at arbitrary point in time after that? I.e. is
> > it possible to see a dead reference before the callback is called?
> >
> > More formally, will this ever raise?
> >
> > callback_called = False
> > def note_deletion (ref):
> > callback_called = True
> >
> > x = ...
> > ref = weakref.ref (x, note_deletion)
> >
> > ...
> >
> > if ref () is None and not callback_called:
> > raise RuntimeError ("reference is dead, yet callback hasn't been
> > called yet")
>
> Yes, you'll definitely see a RuntimeError because you forgot to declare
> callback_called as a global variable. :)
Thanks. Any useful answers though?
callback_called = False
def note_deletion (ref):
global callback_called
callback_called = True
x = ...
ref = weakref.ref (x, note_deletion)
...
if ref () is None and not callback_called:
raise RuntimeError ("reference is dead, yet callback hasn't been called
yet")
Paul
--
http://mail.python.org/mailman/listinfo/python-list
Re: how to edit .wsgi file extebtions with IDLE on windows
En Sat, 29 Aug 2009 17:14:14 -0300, gert escribió:
On Aug 29, 9:31 pm, Chris Rebert wrote:
On Sat, Aug 29, 2009 at 5:40 AM, gert wrote:
> On Aug 29, 6:43 am, "Gabriel Genellina"
> wrote:
>> En Fri, 28 Aug 2009 15:31:31 -0300, gert
escribió:
>> > I can't figure out how to enable the .py shell and syntax
highlighting
>> > for .wsgi file extensions using IDLE for windows ?
>> That's a Windows question, not a Python one. You have to associate
the
>> .wsgi extension with the Python.File file type (the one used for .py
>> files):
>> D:\USERDATA\Gabriel>assoc .py
>> .py=Python.File
>> D:\USERDATA\Gabriel>assoc .wsgi=Python.File
>> .wsgi=Python.File
> Thanks that does make it open exactly like a .py file, expect that
> there is no syntax highlighting. Don't know if this is also a windows
> issue or a IDLE issue ?
That's an IDLE issue; it only highlights files with .py (and possibly
.pyw) extensions.
Any chance they would make a highlight option in the menu ?
Two alternatives:
a) Ensure your scripts contain a shebang - no purpose on Windows, but IDLE
recognizes the file as a Python file. That is, make sure the very first
line is like this:
#!c:\python26\python.exe
(it must start with #! and contain the word "python" somewhere)
b) Edit IDLE sources:
- Locate the file EditorWindow.py in the idlelib package.
- Add this line near the top:
import _winreg
- Modify function ispythonsource near line 580 as follows:
def ispythonsource(self, filename):
if not filename or os.path.isdir(filename):
return True
base, ext = os.path.splitext(os.path.basename(filename))
if os.path.normcase(ext) in (".py", ".pyw"):
return True
### add these 4 lines ###
with _winreg.OpenKey(_winreg.HKEY_CLASSES_ROOT, ext) as key:
ftype = _winreg.QueryValueEx(key, None)[0]
if ftype.lower() in ("python.file","python.noconfile"):
return True
### end ###
try:
f = open(filename)
line = f.readline()
f.close()
except IOError:
return False
return line.startswith('#!') and line.find('python') >= 0
--
Gabriel Genellina
--
http://mail.python.org/mailman/listinfo/python-list
Re: weak reference callback
Paul Pogonyshev wrote:
> Hi,
>
> Is weak reference callback called immediately after the referenced
> object is deleted or at arbitrary point in time after that? I.e. is
> it possible to see a dead reference before the callback is called?
>
> More formally, will this ever raise?
>
> callback_called = False
> def note_deletion (ref):
> callback_called = True
>
> x = ...
> ref = weakref.ref (x, note_deletion)
>
> ...
>
> if ref () is None and not callback_called:
> raise RuntimeError ("reference is dead, yet callback hasn't been
> called yet")
Yes, you'll definitely see a RuntimeError because you forgot to declare
callback_called as a global variable. :)
Christian
--
http://mail.python.org/mailman/listinfo/python-list
Re: Sqlite format string
I have this statement cursor.execute("SELECT * from session_attribute WHERE
sid=%s", ( user ))
and I'm receiving this error :
TypeError: not all arguments converted during string formatting
Two possibilities occur to me:
1) the 2nd parameter to execute() usually needs to be a tuple (or
maybe a list), so try
cursor.execute("select ...", (user, ))
with the extra comma after "user".
2) More likely, check your sqlite3.paramstyle to see what sqlite
is expecting (it's defined at the module-level):
import sqlite3
print sqlite3.paramstyle
Mine here is set to "qmark" which means that sqlite is expecting
cursor.execute("... WHERE sid=?", (user,))
instead of the "format" style you're using:
cursor.execute("... WHERE sid=%s", (user,))
as defined in http://www.python.org/dev/peps/pep-0249/
Hope this helps,
-tkc
--
http://mail.python.org/mailman/listinfo/python-list
weak reference callback
Hi,
Is weak reference callback called immediately after the referenced
object is deleted or at arbitrary point in time after that? I.e. is
it possible to see a dead reference before the callback is called?
More formally, will this ever raise?
callback_called = False
def note_deletion (ref):
callback_called = True
x = ...
ref = weakref.ref (x, note_deletion)
...
if ref () is None and not callback_called:
raise RuntimeError ("reference is dead, yet callback hasn't been called
yet")
Paul
--
http://mail.python.org/mailman/listinfo/python-list
Re:Re: IDE for python similar to visual basic
29.08.2009 1:32 пользователь Vivian Wang написал: On Aug 29, 6:19 am, qwe rty hkh00...@gmail.com> wrote: > i have been searching for am IDE for python that is similar to Visual > Basic but had no luck.shall you help me please? You can try biform: http://www.bilive.com/download/Setup_BiForm_V2.1_en.msi.zip Demo: http://www.bilive.com/demo/BiForm_EN_demo.htm More demo:(Chinese version) http://www.bilive.com/demo/ BiForm is a form designer,one designed form will deploy as a PFF file. BiReader is a runtime PFF file process engine for end-users. Setup file above include BiForm and BiReader. Main features: *Python as script language,base on QT GUI library *Visible form designer *Internal database access framework *Auto connect database,auto create tables *Supports SQLite/Mssql2000/Sybase ASE,not need write diffrent script for diffrent database at most time *Simple deploy,simple upgrade *Different forms can share same tables,they will auto cooperation with other forms at runtime.If you want to deploy a new function , not need uninstall other forms,deploy the new PFF file is enough . -- http://mail.python.org/mailman/listinfo/python-list You can also try Eclipse + PyDev. It's not the same as Visual Studio, and I am not sure about the GUI builder, but I think it's what you want. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is behavior of += intentional for int?
On Aug 29, 8:08 am, Paul McGuire wrote: > On Aug 29, 7:45 am, zaur wrote: > > > Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39) > > [GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin > > Type "copyright", "credits" or "license()" for more information.>>> a=1 > > >>> x=[a] > > >>> id(a)==id(x[0]) > > True > > >>> a+=1 > > >>> a > > 2 > > >>> x[0] > > > 1 > > > I thought that += should only change the value of the int object. But > > += create new. > > Is this intentional? > > ints are immutable. But your logic works fine with a mutable object, > like a list: Technically, mutability isn't the issue: There's nothing enforcing that a mutable object HAS to have an __iadd__ method that returns the same object. -- http://mail.python.org/mailman/listinfo/python-list
Re:Re: Monitoring stdout in (more or less) real time
29.08.2009 2:21 пользователь Gabriel Genellina написал: En Sat, 29 Aug 2009 03:28:26 -0300, ivanko@gmail.com> escribió: Hello to everyone! I am making a program that will be a GTK+ frontend to ffmpeg. Naturally, one of the main functions is parsing ffmpeg's output. It's pretty simple when I, for example, retrieve information about a file (the program finishes and I read the output). But it also needs to parse working ffmpeg's output (in order to retrieve the percentage, remaining time, etc.). So, actually what I do is Popen ffmpeg, and connect to its stdout. And as stdout is represented by a file object, it needs to be read(). The problem is that read() reads until EOF is reached, which doesn't exist while the program is running (the same goes with communicate()). So my question is: is there a way to retrieve the stdout without waiting the program to finish? You don't have to read the complete output at once - you may process it line by line, I presume. I'd use a second thread to read the pipe and put the lines onto a Queue object; the main thread gets lines from the Queue when available. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list Thanks, Gabriel, but I resolved that problem in another way. thrashold in irc.freenode.net gave me the solution. What i do now is: p = Popen(["cmd","arg"],stdout=PIPE,stderr=STDOUT) fcntl.fcntl(p.stdout.fileno(), fcntl.F_SETFL, os.O_NONBLOCK) p.stdout.read() And in that way p.stdout.read() doesn't wait the program to finish, but gives me instant response. But anyway, thanks! =) -- http://mail.python.org/mailman/listinfo/python-list
Sqlite format string
Hi,
I have this statement cursor.execute("SELECT * from session_attribute WHERE
sid=%s", ( user ))
and I'm receiving this error :
TypeError: not all arguments converted during string formatting
What is wrong ?
--
Sergio Roberto Charpinel Jr.
--
http://mail.python.org/mailman/listinfo/python-list
Re: how to edit .wsgi file extebtions with IDLE on windows
On Aug 29, 9:31 pm, Chris Rebert wrote: > On Sat, Aug 29, 2009 at 5:40 AM, gert wrote: > > On Aug 29, 6:43 am, "Gabriel Genellina" > > wrote: > >> En Fri, 28 Aug 2009 15:31:31 -0300, gert escribió: > > >> > I can't figure out how to enable the .py shell and syntax highlighting > >> > for .wsgi file extensions using IDLE for windows ? > > >> That's a Windows question, not a Python one. You have to associate the > >> .wsgi extension with the Python.File file type (the one used for .py > >> files): > > >> D:\USERDATA\Gabriel>assoc .py > >> .py=Python.File > > >> D:\USERDATA\Gabriel>assoc .wsgi=Python.File > >> .wsgi=Python.File > > > Thanks that does make it open exactly like a .py file, expect that > > there is no syntax highlighting. Don't know if this is also a windows > > issue or a IDLE issue ? > > That's an IDLE issue; it only highlights files with .py (and possibly > .pyw) extensions. > Any chance they would make a highlight option in the menu ? -- http://mail.python.org/mailman/listinfo/python-list
Re:Python Noob - gui module, book, annoying questions
29.08.2009 2:20 пользователь Pherdnut написал: I want to write cross-platform stuff. Any opinions on the best GUI module for that? There are many options for this. For example GTK+ (pygtk), tkinter, QT. GTK+ is a little bit complicated, but you can use glade to make the GUIs. Tkinter is built-in and pretty simple (although not so feature-rich). QT - ok, I haven't used it. Personally I prefer GTK+ (using pygtk module) -- http://mail.python.org/mailman/listinfo/python-list
Re: What python can NOT do?
qwe rty wrote: i know that an interpreted language like python can't be used to make an operating system or system drivers. what else can NOT be done in python? what are the limitations of the language? Speed, basically. CPython is on the slow side. This is not inherent in the language; it's an implementation problem. The Shed Skin compiler is approaching C speeds, but you have to accept some modest restrictions on run-time dynamism. Also, CPython does not use multiple processors well. In fact, multiple cores make CPython performance worse. (There's a long analysis of this that's been discussed here recently.) Personally, I consider Python to be a good language held back by too-close ties to a naive interpreter implementation and the lack of a formal standard for the language. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: break unichr instead of fix ord?
2009/8/29 :
> On 08/28/2009 02:12 AM, "Martin v. Löwis" wrote:
>
> So far, it seems not and that unichr/ord
> is a poster child for "purity beats practicality".
> --
> http://mail.python.org/mailman/listinfo/python-list
>
As Mark Tolonen pointed out earlier in this thread, in Python 3 the
practicality apparently beat purity in this aspect:
Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit
(Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> goth_urus_1 = '\U0001033f'
>>> list(goth_urus_1)
['\ud800', '\udf3f']
>>> len(goth_urus_1)
2
>>> ord(goth_urus_1)
66367
>>> goth_urus_2 = chr(66367)
>>> len(goth_urus_2)
2
>>> import unicodedata
>>> unicodedata.name(goth_urus_1)
'GOTHIC LETTER URUS'
>>> goth_urus_3 = unicodedata.lookup("GOTHIC LETTER URUS")
>>> goth_urus_4 = "\N{GOTHIC LETTER URUS}"
>>> goth_urus_1 == goth_urus_2 == goth_urus_3 == goth_urus_4
True
>>>
As for the behaviour in python 2.x, it's probably good enough, that
the surrogates aren't prohibited and the eventually needed behaviour
can be easily added via custom functions.
vbr
--
http://mail.python.org/mailman/listinfo/python-list
Re: Select column from a list
In article , Anthra Norell wrote: >Vlastimil Brom wrote: >> 2009/8/28 hoffik : >>> >>> I'm quite new in Python and I have one question. I have a 2D matrix of >>> values stored in list (3 columns, many rows). I wonder if I can select one >>> column without having to go through the list with 'for' command. >> >> I guess, it won't be possible without an explicit or implicit loop; >> you may try: >> > from operator import itemgetter > nested_list = [[1, 2, 3], [10, 20, 30], [100, 200, 300]] > map(itemgetter(1), nested_list) >> >> [2, 20, 200] > >How about rotating the list with zip? > >>> zip (*nested_list)[1] >(2, 20, 200) That's an implicit loop, plus it consumes an O(M*N) chunk of memory for the intermediate list. -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "I support family values -- Addams family values" --www.nancybuttons.com -- http://mail.python.org/mailman/listinfo/python-list
Re: how to edit .wsgi file extebtions with IDLE on windows
On Sat, Aug 29, 2009 at 5:40 AM, gert wrote: > On Aug 29, 6:43 am, "Gabriel Genellina" > wrote: >> En Fri, 28 Aug 2009 15:31:31 -0300, gert escribió: >> >> > I can't figure out how to enable the .py shell and syntax highlighting >> > for .wsgi file extensions using IDLE for windows ? >> >> That's a Windows question, not a Python one. You have to associate the >> .wsgi extension with the Python.File file type (the one used for .py >> files): >> >> D:\USERDATA\Gabriel>assoc .py >> .py=Python.File >> >> D:\USERDATA\Gabriel>assoc .wsgi=Python.File >> .wsgi=Python.File >> > > Thanks that does make it open exactly like a .py file, expect that > there is no syntax highlighting. Don't know if this is also a windows > issue or a IDLE issue ? That's an IDLE issue; it only highlights files with .py (and possibly .pyw) extensions. Cheers, Chris -- http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Query screen resolution?
On Fri, 28 Aug 2009 20:15:57 -0700, Warpcat wrote: >> Your question is based upon the notion that "the screen" is a meaningful >> concept. Once you move away from Windows (and systems which intentionally >> try to be like Windows), that's no longer true. > > Good points. Always something I haven't thought of. Ok so... let's > *presume* the user has a measurable screen on win\mac\linux\etc since > on any other OS they wouldn't be running the app If it's a GUI app, you ask the GUI toolkit which you're using. [And if it isn't a GUI app, why would the screen resolution be relevant?] -- http://mail.python.org/mailman/listinfo/python-list
Re: (Simple?) Unicode Question
On Sat, 29 Aug 2009 08:26:54 +, Steven D'Aprano wrote:
> Python only needs to know when you convert the text to or from bytes. I
> can do this:
>
s = "hello"
t = "world"
print(' '.join([s, t]))
> hello world
>
> and not need to care anything about encodings.
>
> So long as your terminal has a sensible encoding, and you have a good
> quality font, you should be able to print any string you can create.
UTF-8 isn't a particularly sensible encoding for terminals.
And "Unicode font" is an oxymoron. You can merge a whole bunch of fonts
together and stuff them into a TTF file; that doesn't make them "a font",
though.
>>> I may be wrong, but I believe that's part of the idea between
>>> separation of string and bytes types in Python 3.x. I believe, if you
>>> are using Python 3.x, you don't need the character encoding mumbo jumbo
>>> at all ;-)
>>
>> Nothing has changed in that regard. You still need to decode and encode
>> text and for that you have to know the encoding.
>
> You only need to worry about encoding when you convert from bytes to
> text, and visa versa. Admittedly, the most common time you need to do
> that is when reading input from files, but if all your text strings are
> generated by Python, and not output anywhere, you shouldn't need to care
> about encodings.
Why would you generate text strings and not output them anywhere?
The main advantage of using Unicode internally is that you can associate
encodings with the specific points where data needs to be converted
to/from bytes, rather than having to carry the encoding details around the
program.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is behavior of += intentional for int?
On Sat, 29 Aug 2009 11:11:43 -0700, zaur wrote: > I thought that int as object will stay the same object after += but with > another integer value. My intuition said me that int object which > represent integer value should behave this way. If it did, then you would have this behaviour: >>> n = 3 # bind the name n to the object 3 >>> saved_id = id(n) # get the id of the object >>> n += 1# add one to the object 3 >>> assert n == 4 # confirm that it has value four >>> assert id(n) == saved_id # confirm that it is the same object >>> m = 3 # bind the name m to the object 3 >>> print m + 1 # but object 3 has been modified 5 This would be pretty disturbing behaviour, and anything but intuitive. Fortunately, Python avoids this behaviour by making ints immutable. You can't change the object 3 to have any other value, it will always have value three, and consequently n+=1 assigns a new object to n. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: IDE for Python
Is IDLE (the editor that comes with Python) good? I'm just starting now, but it looks ok. 2009/8/29 > 29.08.2009 4:14 пользователь "Thangappan.M" > написал: > > Dear all, > > > > > >Please suggest some good IDE for python.I am working in linux > platform. > > > > -- > > Regards, > > Thangappan.M > > > > You can use Eclipse + PyDev or Emacs+PythonMode . Also there are Anjuta and > Code:Blocks, but they are designed mainly for C++ (but still can be used). > -- > http://mail.python.org/mailman/listinfo/python-list > > -- http://mail.python.org/mailman/listinfo/python-list
Re: Combining C and Python programs
On Aug 29, 2009, at 3:54 AM, Sortie wrote: I want to write a program that will use ode for the physics simulation, whose python bindings are outdated. So I'm writing the physics engine in C and want to write the drawing code in Python. What will be the best way of making those two programs work together? THe physics engine won't have to run concurrently with the drawing code. It will only return some position data so they can be drawn. I'd look at ctypes first, as Hendrik suggested. It's pretty simple and part of the standard library. If that doesn't work for you for some reason and you're willing to use something outside of the standard library, you might find Cython useful. Good luck Philip -- http://mail.python.org/mailman/listinfo/python-list
Re: What python can NOT do?
Theoretically a microkernel could be used to do the stuff python directly couldn't do and the rest could be done once an interpreter was loaded in theory. On Fri, Aug 28, 2009 at 4:37 PM, qwe rty wrote: > i know that an interpreted language like python can't be used to make > an operating system or system drivers. > > what else can NOT be done in python? what are the limitations of the > language? > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: What python can NOT do?
On Sat, 29 Aug 2009, Steven D'Aprano wrote: > On Sat, 29 Aug 2009 05:37:34 +0200, Tomasz Rola wrote: > > > My private list of > > things that when implemented in Python would be ugly to the point of > > calling it difficult: > > > > 1. AMB operator - my very favourite. In one sentence, either language > > allows one to do it easily or one would not want to do it (in an ugly > > way). > > > > http://www.randomhacks.net/articles/2005/10/11/amb-operator > > > Fascinating, but I don't exactly see how that's actually *useful*. It > strikes me of combining all the benefits of COME FROM with the potential > performance of Bogosort, but maybe I'm being harsh. Usefullness is totally different thing, I agree. However, amb could still find some following. I guess it is more about personal taste and willingness to look for better idioms in programming. I can imagine when they introduced for and while loops, people were pointing at conditional goto as more practical (I think every control structure can be modeled with it). Id doesn't mean amb is better idiom, but it is something that could be tried - or not. One could write like this: (partially stolcopied from the above link) a = amb 1, 2, 3 b = amb 4, 5, 6 c = amb 7, 8, 9 if a*b + c != 27 : amb print a,b,c or one could write like this: for a in [1, 2, 3]: for b in [4, 5, 6]: for c in [7, 8, 9]: if a*b+c == 27 : print a,b,c break Which one would I choose? Well, amb of course. I consider it to be more readable which is, for me at least, useful. Now, try to imagine the same with ten variables. And longer lists. And some problems do not fit well into numpy (they could be non-numerical in nature). > On the other hand, it sounds rather like Prolog-like declarative > programming. I fear that, like Prolog, it risks massive performance > degradation if you don't apply the constraints in the right order. Of course, but this can be optimised. Either by hand or by a good compiler (whatever this means). Performance degradation is connected with abuse of every other programming technique, too. And besides, I believe one would sometimes trade performance for the ability to clearly express the idea behind the algorithm. Just as is the case with choosing Python rather than Java. For things I use Python for, I wouldn't use Java or C. Even though C is one of my beloved languages. If I ever used Prolog for anything, I wouldn't like to rewrite it in C or Python. I mean, languages should (in theory) be chosen and used with some consideration. > > 2. Changing the language from the inside. > > > > Everybody can change the interpreter, right? But how about doing some > > bigger, maybe even fundamental change to the language by means offered > > by the language itself? > > Like Forth. You need it in Forth, because it has a very sparse set of > language features, and everything is bootstrapped from a small set of > commands, so the ability to re-define the language as you go is (1) > necessary and (2) free. It also leads to writing code in an incredibly expressive manner. I've never done anything big in Forth. I only had a two weeks long exposure to it in times, when you loaded such things from casette recorder ;-/... But from time to time I find some interesting pieces, like a disk driver whose source would fit into a comment of one Python function :-). > But for Python, I don't know... it sounds cool, but in practice? It > sounds like the sort of thing that allows programmers to spend three > hours writing a new control structure which will save them three minutes. It really is not so. Writing something for three hours and using it only once sounds more like programming excercise, less like real life work. To write a function I need to know at least two places in my code where it would be used (well, I am oversimplifying, ok? sometimes one place is sufficient). I think reasonable people would judge language extension by similar criteria. They would possibly stay away from this as long as possible (I have such possibility from some time but I just don't touch macros, which by my own words makes me reasonable, wow :-)... or a coward...). > And of course, for all but the tiniest, one-man-band applications, > readability is important. Sure, you've created a gee-whizz control > structure which combines try, while and if into one keyword, and it > automatically does logging and threading, fantastic. But how will anyone > else be able to maintain it when you're gone? This is comparable to me creating a gee-whizz function library and using it. I cannot see a problem as long as I document (with use cases, tests etc). There is something better in this idea. Suppose I would have invented a better control structure and posted the source code here? Some would have found it amusing, others would have tried it, posted their comments, leading to improvements and further spreading. Finally - who knows
Re: Is behavior of += intentional for int?
On 29 авг, 20:25, "Günther Dietrich" wrote: > Paul McGuire wrote: > >What exactly are you trying to do? > > I think, he wants to kind of dereference the list element. So that he > can write > > >>> a += 1 > > instead of > > >>> long_name_of_a_list_which_contains_data[mnemonic_pointer_name] += 1 > > Regards, > > Günther That's right. I thought that int as object will stay the same object after += but with another integer value. My intuition said me that int object which represent integer value should behave this way. But by design python's integer behave differently. I fond that NumPy's 1-d types behaves as objects with mutable values. >>> from numpy import * >>> a=array([1]) >>> id(a) 10912544 >>> a += 1 >>> id(a) 10912544 >>> a array([2]) -- http://mail.python.org/mailman/listinfo/python-list
Re: break unichr instead of fix ord?
On Sat, 29 Aug 2009 07:38:51 -0700, rurpy wrote: > > Then, the next question is "why is it implemented that way", to which > > the answer is "because the PEP says so". > > Not at all a satisfying answer unless one believes in PEPal > infallibility. :-) Not at all. You don't have to believe that PEPs are infallible to accept the answer, you just have to understand that major changes to Python aren't made arbitrarily, they have to go through a PEP first. Even Guido himself has to write a PEP before making any major changes to the language. But PEPs aren't infallible, they can be challenged, rejected, withdrawn or made obsolete by new PEPs. > The reasons for the current behavior so far: > > 1. >> What you propose would break the property "unichr(i) always returns a >> string of length one, if it returns anything at all". > > Yes. And i don't see the problem with that. Why is that property more > desirable than the non-existent property that a Unicode literal always > produces one python character? What do you mean? Unicode literals don't always produce one character, e.g. u'abcd' is a Unicode literal with four characters. I think it's fairly self-evident that a function called uniCHR [emphasis added] should return a single character (technically a single code point). But even if you can come up with a reason for unichr() to return two or more characters, this would break code that relies on the documented promise that the length of the output of unichr() is always one. > It would only occur on a narrow build > with a unicode character outside of the bmp, exactly the condition a > unicode literal can "behave differently" by producing two python > characters. > 2. >> > But there is no reason given [in the PEP] for that behavior. >> Sure there is, right above the list: >> "Most things will behave identically in the wide and narrow worlds." >> That's the reason: scripts should work the same as much as possible in >> wide and narrow builds. > > So what else would work "differently"? unichr(n) sometimes would return one character and sometimes two; ord(c) would sometimes accept two characters and sometimes raise an exception. That's a fairly major difference. > My point was that extending > unichr/ord to work with all unicode characters reduces differences far > more often than it increase them. I don't see that at all. What differences do you think it would reduce? > 3. >>> * There is a convention in the Unicode world for >>> encoding a 32-bit code point in terms of two 16-bit code >>> points. These are known as "surrogate pairs". Python's codecs >>> will adopt this convention. >>> >>> Is a distinction made between Python and Python codecs with only the >>> latter having any knowledge of surrogate pairs? >> >> No. In the end, the Unicode type represents code units, not code >> points, i.e. half surrogates are individually addressable. Codecs need >> to adjust to that; in particular the UTF-8 and the UTF-32 codec in >> narrow builds, and the UTF-16 codec in wide builds (which didn't exist >> when the PEP was written). > > OK, so that is not a reason either. I think it is a very important reason. Python supports code points, so it has to support surrogate codes individually. Python can't tell if the pair of code points u'\ud800\udc40' represents the single character \U00010040 or a pair of code points \ud800 and \udc40. > 4. > I'll speculate a little. > If surrogate handling was added to ord/unichr, it would be the top of a > slippery slope leading to demands that other string functions also > handle surrogates. > > But this is not true -- there is a strong distinction between ord/unichr > and other string methods. The latter deal with strings of multiple > characters. But the former deals only with single characters (taking a > surrogate pair as a single unicode character.) Strictly speaking, unichr() deals with code points, not characters, although the distinction is very fine. >>> c = unichr(56384) >>> len(c) 1 >>> import unicodedata >>> unicodedata.category(c) 'Cs' Cs is the general category for "Other, Surrogate", so \udc40 is not strictly speaking a character. Nevertheless, Python treats it as one. > To reiterate, I am not advocating for any change. I simply want to > understand if there is a good reason for limiting the use of unchr/ord > on narrow builds to a subset of the unicode characters that Python > otherwise supports. So far, it seems not and that unichr/ord is a > poster child for "purity beats practicality". On the contrary, it seems pretty impractical to me for ord() to sometimes successfully accept strings of length two and sometimes to raise an exception. I would much rather see a pair of new functions, wideord() and widechr() used for converting between surrogate pairs and numbers. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re:IDE for Python
29.08.2009 4:14 пользователь "Thangappan.M" написал: Dear all, Please suggest some good IDE for python.I am working in linux platform. -- Regards, Thangappan.M You can use Eclipse + PyDev or Emacs+PythonMode . Also there are Anjuta and Code:Blocks, but they are designed mainly for C++ (but still can be used). -- http://mail.python.org/mailman/listinfo/python-list
AutoIt/Autohotkey-like library for Linux
Hey, maybe some of you are familiar with the tools "AutoIt" (http://www.autoitscript.com/autoit3/) and "Autohotkey" (http://www.autohotkey.com/) for Windows - I was wondering if you knew about Python libraries which provide similiar functionality for Python programs under Linux. That said, those libraries would have to rely on X11 internally to provide their functionality. Also, yes, I know that there are X11-bindings for Python - but I honestly think that they aren't remotely useable and they are also incomplete. It would be great if you guys had some tips for me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Transforming a str to an operator
r wrote:
On Aug 28, 8:43 pm, Anny Mous wrote:
It isn't irrational to have a healthy caution towards eval.
Ignorance is never an excuse for stupidity. No caution is needed if
you know how to properly use eval. You can't shoot yourself in the
foot without first pulling the trigger.
Apart from the security issues, running code in eval takes a massive
performance hit. Its about ten times slower to run eval("x+1") than to run
x+1 directly.
And the point is...?
eval is only for corner cases. Nobody is suggesting he eval entire
scripts. Performance is the last of my worries. Optimizations can come
later. First understand the problem at hand, code up a working
solution, then tweak and optimize the code to perfection.
What makes you think that learning to program well in Python is a throw-away
exercise of no useful purpose? I'm sure the code itself will be thrown away
and forgotten, but it has a very important purpose: for the OP to learn
good programming skills. Looks like you want him to learn bad skills, then
spend the rest of his life trying to unlearn them.
No i want him to use eval properly .If you think eval is scary well
thats just your opinion. I showed the OP how to successfully pass the
arguments into eval the way he was unsuccesfully struggling to pass
them. Ben's approach is the professional/proper way to handle such
input in the real world (there are other ways too), however the OP
also must know that you don't *have* to go by the book all the time
(python is not Java ya know?).
but serves the very
useful purpose now of establishing an IO between the student and
Python interpretor. I'll bet most your example (albeit a good example)
flew miles above his head into la-la land.
How insulting. Is there anything that gave you the impression the OP was
stupid?
Please quote the line from my post were i called the OP stupid or used
otherwise derogatory comments? And if you can i'll buy you a beer.
Obviously anyone who shows example code as the OP did is a noob and
needs proper training on how to use it and there is nothing wrong with
that. We have all been there, remember?
The OP has plenty of time to learn about malicious input and
protecting against it, right now the fundamentals are well...
fundamental :)
When would you recommend he learns? When his web app is hijacked by
gangsters in Russia and the personal details and financial records of fifty
thousand people stolen? Protecting against malicious input *IS*
fundamental.
If the OP uses eval without inderstanding it and then shoots himself
in the foot, well then i can't think of a better learning experience
for him. I'll bet the next time he will read the docs first or ask on
this list before he goes off on a turkey hunt ;).
Fear is a product of ignorance. Educate yourself and your irrational
fears shall bother you no more.
I think it's a good idea to warn the OP about the dangers of eval. If he
still wants to use it, then that's his choice (and his problem).
--
http://mail.python.org/mailman/listinfo/python-list
Re: Transforming a str to an operator
On Aug 28, 8:43 pm, Anny Mous wrote:
> It isn't irrational to have a healthy caution towards eval.
Ignorance is never an excuse for stupidity. No caution is needed if
you know how to properly use eval. You can't shoot yourself in the
foot without first pulling the trigger.
> Apart from the security issues, running code in eval takes a massive
> performance hit. Its about ten times slower to run eval("x+1") than to run
> x+1 directly.
And the point is...?
eval is only for corner cases. Nobody is suggesting he eval entire
scripts. Performance is the last of my worries. Optimizations can come
later. First understand the problem at hand, code up a working
solution, then tweak and optimize the code to perfection.
> What makes you think that learning to program well in Python is a throw-away
> exercise of no useful purpose? I'm sure the code itself will be thrown away
> and forgotten, but it has a very important purpose: for the OP to learn
> good programming skills. Looks like you want him to learn bad skills, then
> spend the rest of his life trying to unlearn them.
No i want him to use eval properly .If you think eval is scary well
thats just your opinion. I showed the OP how to successfully pass the
arguments into eval the way he was unsuccesfully struggling to pass
them. Ben's approach is the professional/proper way to handle such
input in the real world (there are other ways too), however the OP
also must know that you don't *have* to go by the book all the time
(python is not Java ya know?).
> > but serves the very
> > useful purpose now of establishing an IO between the student and
> > Python interpretor. I'll bet most your example (albeit a good example)
> > flew miles above his head into la-la land.
>
> How insulting. Is there anything that gave you the impression the OP was
> stupid?
Please quote the line from my post were i called the OP stupid or used
otherwise derogatory comments? And if you can i'll buy you a beer.
Obviously anyone who shows example code as the OP did is a noob and
needs proper training on how to use it and there is nothing wrong with
that. We have all been there, remember?
> > The OP has plenty of time to learn about malicious input and
> > protecting against it, right now the fundamentals are well...
> > fundamental :)
>
> When would you recommend he learns? When his web app is hijacked by
> gangsters in Russia and the personal details and financial records of fifty
> thousand people stolen? Protecting against malicious input *IS*
> fundamental.
If the OP uses eval without inderstanding it and then shoots himself
in the foot, well then i can't think of a better learning experience
for him. I'll bet the next time he will read the docs first or ask on
this list before he goes off on a turkey hunt ;).
Fear is a product of ignorance. Educate yourself and your irrational
fears shall bother you no more.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is behavior of += intentional for int?
Paul McGuire wrote: >What exactly are you trying to do? I think, he wants to kind of dereference the list element. So that he can write >>> a += 1 instead of >>> long_name_of_a_list_which_contains_data[mnemonic_pointer_name] += 1 Regards, Günther -- http://mail.python.org/mailman/listinfo/python-list
AutoIt/Autohotkey Python library for Linux
Hey, maybe some of you are familiar with the tools "AutoIt" () and "Autohotkey" () for Windows - I was wondering if you knew about Python libraries which provide similiar functionality for Python programs under Linux. That said, those libraries would have to rely on X11 internally to provide their functionality. Also, yes, I know that there are X11-bindings for Python - but I honestly think that they aren't remotely useable and they are also incomplete. It would be great if you guys had some tips for me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Colors on IDLE
On Aug 29, 1:34 pm, Thorsten Kampe wrote: > * vsoler (Sat, 29 Aug 2009 04:01:46 -0700 (PDT)) > > > On Aug 29, 1:27 am, r wrote: > > > Have you tried saving the files as MYScriptName.py? notice the py > > > extension, very important ;) > > > That was it!!! > > > I see the colors again. Thank you. > > I suggest you start using familiar technical terms. Like "syntax > highlighting" instead of "see colours". That would increase the number > of useful answers you get - at least it will stop people from thinking > you talk about controlled substances. > > Thorsten I'll keep it in mind for next time. Thank you Vicente Soler -- http://mail.python.org/mailman/listinfo/python-list
Re: Is behavior of += intentional for int?
zaur wrote: Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39) [GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin Type "copyright", "credits" or "license()" for more information. a=1 x=[a] id(a)==id(x[0]) True a+=1 a 2 x[0] 1 I thought that += should only change the value of the int object. But += create new. Is this intentional? You don't need the (slight) complexity of += to see this. Straight assignment shows the same behavior. Try this: a=1 print id(a) a=2 print id(a) The different results from the two prints happens because Python stores integers 1 and 2 in different locations and the assignments causes a to refer to one and then the other. Gary Herron -- http://mail.python.org/mailman/listinfo/python-list
Re: What python can NOT do?
On Sat, 29 Aug 2009, Timothy N. Tsvetkov wrote: > On Aug 29, 4:26 am, qwe rty wrote: > > On Aug 29, 3:14 am, Tim Chase wrote: > > > > > >> what else can NOT be done in python? what are the limitations of the > > > >> language? > > [...] > > > I forgot about solving the Spam problem entirely. And answering > > > poorly worded/thought-out questions on the internet... > > > > > I've also been sorely disappointed by Python's ability to make a > > > good chocolate cream silk pie. > > > > > -tkc > > > > if you don't know the answer please don't reply > > If you want to ask a silly question don't ask it. The question the OP asked was not silly. Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_r...@bigfoot.com **-- http://mail.python.org/mailman/listinfo/python-list
Re: Combining C and Python programs
Sortie schrieb: I want to write a program that will use ode for the physics simulation, whose python bindings are outdated. So I'm writing the physics engine in C and want to write the drawing code in Python. What will be the best way of making those two programs work together? THe physics engine won't have to run concurrently with the drawing code. It will only return some position data so they can be drawn. How about you update the ODE-bindings? They shouldn't be hard to enhance to cover the latest features. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: What python can NOT do?
On Aug 29, 4:26 am, qwe rty wrote: > On Aug 29, 3:14 am, Tim Chase wrote: > > > > > > > >> what else can NOT be done in python? what are the limitations of the > > >> language? > > > > I understand there's a little trouble getting Python to prove > > > that P=NP You'll also find that it only comes close to solving > > > the unrestricted three-body problem and the Traveling Salesman > > > problem is still limited to fallible heuristics and searching the > > > entire solution set in better than O(2**n) time. > > > I forgot about solving the Spam problem entirely. And answering > > poorly worded/thought-out questions on the internet... > > > I've also been sorely disappointed by Python's ability to make a > > good chocolate cream silk pie. > > > -tkc > > if you don't know the answer please don't reply If you want to ask a silly question don't ask it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python for professsional Windows GUI apps?
On Aug 27, 2:31 pm, Neuruss wrote: > On 26 ago, 05:29, erikj wrote: > > > > > Hi, > > > You could have a look at Camelot, to see if it fits > > your needs :http://www.conceptive.be/projects/camelot/ > > > it was developed with cross platform business apps in > > mind. when developing Camelot, we tried to build it using > > wxWidgets first (because of the licensing at that time), > > but it turned out that developing with QT proved to be > > much more straightforward. QT is documented very well > > and you seldom encounter 'strange' issues that cost hours > > of time to pinpoint and fix. > > > the datagrid was developed to be able to handle millions > > of database records without glitches and is flexible thanks > > to QT's model-view-delegate framework. > > > we do print barcodes with this app (even directly to > > zebra printers) > > > if you have questions regarding Camelot, please feel free > > to post on our mailing list :http://groups.google.com/group/project-camelot > > > Regards, > > > Erik > > > On Aug 24, 2:08 pm, Gilles Ganault wrote: > > > > Hello > > > > I was wondering if some people in this ng use Python and someGUI > > > toolkit (PyWin32, wxWidgets, QT, etc.) to build professional > > > applications, and if yes, what it's like, the pros and cons, etc. > > > > I'm especially concerned about the lack of controls, the lack of > > > updates (lots of controls in wxWidgets are 1.0 deadware), and problems > > > linked to how to update users' PC remotely when I build a new version > > > using eg. Py2exe. > > > > I need controls for business apps like access to databases, good data > > > grid, printing reports (with or without barcodes), etc. > > > > Thank you. > > Looks interesting, but I wonder if I can use Camelot without its ORM. > I feel that ORMs make easy things easier, but complex things much > harder... > Can I use it with plain old sql? > > Luis Yes and no :) It uses sqlalchemy as it's orm, which is quite flexible and allows the use of plain old sql, but you still have to map the result to objects for the GUI to to handle them. You are right that the ORM makes easy things easier, eg. what we do a lot is to create our core model using the ORM, and then create the different summaries directly as views in the database (since these are usually very complex queries, and those tend to be easier to write/debug in plain old sql). Then we use the ORM again to map those views back to objects and have them visualized. Cheers, Erik -- http://mail.python.org/mailman/listinfo/python-list
Re: break unichr instead of fix ord?
On 08/28/2009 02:12 AM, "Martin v. Löwis" wrote: [I reordered the quotes from your previous post to try and get the responses in a more coherent order. No intent to take anything out of context...] >> Nothing else in the PEP seems remotely relevant. [to providing justification for the behavior of unichr/ord] > > Except for the motivation, of course :-) > > In addition: your original question was "why has this > been changed", to which the answer is "it hasn't". My original interest was two-fold: can unichr/ord be changed to work in a more general and helpful way? That seemed remotely possible until it was pointed out that the two behave consistently, and that behavior is accurately documented. Second, why would they work the way they do when they could have been generalized to cover the full unicode space? An inadequate answer to this would have provided support for the first point but remains interesting to me for the reason below. > Then, the next question is "why is it implemented that > way", to which the answer is "because the PEP says so". Not at all a satisfying answer unless one believes in PEPal infallibility. :-) > Only *then* the question is "what is the rationale for > the PEP specifying things the way it does". The PEP is > relevant so that we can both agree that Python behaves > correctly (in the sense of behaving as specified). But my question had become: why that behavior, when a slightly different behavior would be more general with little apparent downside? To clarify, my interest in the justification for the current behavior is this: I think the best feature of python is not, as commonly stated, the clean syntax, but rather the pretty complete and orthogonal libraries. I often find, after I have written some code, that due to the right library functions being available, it turns out much shorter and concise than I expected. Nevertheless, every now and then, perhaps more than in some other languages (I'm not sure), I run into something that requires what seems to be excessive coding -- I have to do something it seems to me that a library function should have done for me. Sometimes this is because I don't under- stand the reason the library function needs to works the way it does. Other times it is one of the countless trade- off made in the design of the language, which didn't happen to go the way that would have been beneficial to me in a particular coding situation. But sometimes (and it feels too often) it seems as though, zen not withstanding, that purity -- adherence to some philosophic ideal -- beat practicality. unichr/ord seems such as case to me, But I want to be sure I am not missing something. The reasons for the current behavior so far: 1. > What you propose would break the property "unichr(i) always returns > a string of length one, if it returns anything at all". Yes. And i don't see the problem with that. Why is that property more desirable than the non-existent property that a Unicode literal always produces one python character? It would only occur on a narrow build with a unicode character outside of the bmp, exactly the condition a unicode literal can "behave differently" by producing two python characters. 2. > > But there is no reason given [in the PEP] for that behavior. > Sure there is, right above the list: > "Most things will behave identically in the wide and narrow worlds." > That's the reason: scripts should work the same as much as possible > in wide and narrow builds. So what else would work "differently"? My point was that extending unichr/ord to work with all unicode characters reduces differences far more often than it increase them. 3. >> * There is a convention in the Unicode world for >> encoding a 32-bit code point in terms of two >> 16-bit code points. These are known as >> "surrogate pairs". Python's codecs will adopt >> this convention. >> >> Is a distinction made between Python and Python >> codecs with only the latter having any knowledge of >> surrogate pairs? > > No. In the end, the Unicode type represents code units, > not code points, i.e. half surrogates are individually > addressable. Codecs need to adjust to that; in particular > the UTF-8 and the UTF-32 codec in narrow builds, and the > UTF-16 codec in wide builds (which didn't exist when the > PEP was written). OK, so that is not a reason either. 4. I'll speculate a little. If surrogate handling was added to ord/unichr, it would be the top of a slippery slope leading to demands that other string functions also handle surrogates. But this is not true -- there is a strong distinction between ord/unichr and other string methods. The latter deal with strings of multiple characters. But the former deals only with single characters (taking a surrogate pair as a single unicode character.) The behavior of ord/unichr is independent of the other string methods -- if they were changed with regard to surrogate h
Re: csv module and None values
On Aug 25, 8:49 am, Peter Otten <__pete...@web.de> wrote: > JKPeck wrote: > > On Aug 24, 10:43 pm, John Yeung wrote: > >> On Aug 24, 5:00 pm, Peter Otten <__pete...@web.de> wrote: > > >> > If I understand you correctly the csv.writer already does > >> > what you want: > > >> > >>> w.writerow([1,None,2]) > >> > 1,,2 > > >> > just sequential commas, but that is the special treatment. > >> > Without it the None value would be converted to a string > >> > and the line would look like this one: > > >> > 1,None,2 > > >> No, I think he means he is getting > > >> >>> w.writerow([1,None,2]) > > >> 1,"",2 > > >> He evidently wants to quote "all" strings, but doesn't want None to be > >> considered a string. > > >> John > > > Exactly so. The requirement of the receiving program, which is out of > > my control, is that all strings be quoted but a None in a numeric > > field result in the ,, output rather than "". Excel quotes strings > > conditionally, which doesn't do what is needed in this case. For > > QUOTE_NONNUMERIC to quote None values makes some sense, but it gets in > > the way of representing missing values in a numeric field. It would > > be nice to have a choice here in the dialects. > > > I thought of replacing the None values with float(nan), since that has > > a numeric type, but unfortunately that results in writing the string > > (unquoted) nan for the value. So the sentinel approach seems to be > > the best I can do. > > How about: > > >>> import csv, sys > >>> class N(int): > > ... def __str__(self): return "" > ...>>> pseudo_none = N() > >>> w = csv.writer(sys.stdout, quoting=csv.QUOTE_NONNUMERIC) > >>> w.writerow([1, "foo", pseudo_none, "bar"]) > > 1,"foo",,"bar" > > Peter Clever. Thanks, Jon -- http://mail.python.org/mailman/listinfo/python-list
Re: Is behavior of += intentional for int?
zaur wrote: >Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39) >[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin >Type "copyright", "credits" or "license()" for more information. a=1 x=[a] id(a)==id(x[0]) >True a+=1 a >2 x[0] >1 > >I thought that += should only change the value of the int object. But >+= create new. >Is this intentional? An integer variable contains the reference (ID) to an (immutable) integer object; it doesn't contain the value itself. So, when you assign a new value to an integer variable, it will contain the reference to the object containing the new value, afterwards. If you assign an integer variable to a list element, this reference will be written into the list. The assignment of a new value to the integer variable will create a new integer object, containing the new value, and put the reference to it into the integer variable. The reference to the object with the old value, that is stored in the list, won't be touched. In fact, it is a result of integers in python being immutable. Best regards, Günther -- http://mail.python.org/mailman/listinfo/python-list
Re: Blank Line at Program Exit
On Sun, Aug 23, 2009 at 09:07:53PM +0800, Steven Woody wrote: > > Hi, > I am using cywin on XP. > Sorry for the late reply. I've been too busy with some personal matters. It'd seem to me that you're better off taking this issue to the Cygwin mailing lists, since it doesn't seem to be related to Python itself. -- http://mail.python.org/mailman/listinfo/python-list
the best book for learning python !?
-- http://mail.python.org/mailman/listinfo/python-list
Re: Is behavior of += intentional for int?
On Aug 29, 7:45 am, zaur wrote: > Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39) > [GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin > Type "copyright", "credits" or "license()" for more information.>>> a=1 > >>> x=[a] > >>> id(a)==id(x[0]) > True > >>> a+=1 > >>> a > 2 > >>> x[0] > > 1 > > I thought that += should only change the value of the int object. But > += create new. > Is this intentional? ints are immutable. But your logic works fine with a mutable object, like a list: >>> a = [1] >>> x = [a] >>> print id(a) == id(x[0]) True >>> a += [1] >>> print a [1, 1] >>> print x[0] [1, 1] What exactly are you trying to do? -- Paul -- http://mail.python.org/mailman/listinfo/python-list
Is behavior of += intentional for int?
Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39) [GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin Type "copyright", "credits" or "license()" for more information. >>> a=1 >>> x=[a] >>> id(a)==id(x[0]) True >>> a+=1 >>> a 2 >>> x[0] 1 I thought that += should only change the value of the int object. But += create new. Is this intentional? -- http://mail.python.org/mailman/listinfo/python-list
Re: how to edit .wsgi file extebtions with IDLE on windows
On Aug 29, 6:43 am, "Gabriel Genellina" wrote: > En Fri, 28 Aug 2009 15:31:31 -0300, gert escribió: > > > I can't figure out how to enable the .py shell and syntax highlighting > > for .wsgi file extensions using IDLE for windows ? > > That's a Windows question, not a Python one. You have to associate the > .wsgi extension with the Python.File file type (the one used for .py > files): > > D:\USERDATA\Gabriel>assoc .py > .py=Python.File > > D:\USERDATA\Gabriel>assoc .wsgi=Python.File > .wsgi=Python.File > Thanks that does make it open exactly like a .py file, expect that there is no syntax highlighting. Don't know if this is also a windows issue or a IDLE issue ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Annoying octal notation
On 2009-08-28, Neil Hodgson wrote: > Steven D'Aprano: > >> Obviously I can't speak for Ken Thompson's motivation in creating this >> feature, but I'm pretty sure it wasn't to save typing or space on >> punchcards. > >The original implementation of UNIX was on a PDP-7 which was an > 18-bit machine. Octal = 3 bits at a a time which evenly divides an > 18-bit word whereas the 4 bits of hexadecimal do not. Early > implementations of B were (according to Wikipedia) on the PDP-7, PDP-11 > (a 16-bit machine) and Honeywell 36-bit mainframes. > > Octal was widely used on the PDP-11. The PDP-11's 16-bit instruction word consisted mainly of 3-bit fields for destiation-mode, destination-register, source-mode, source-register. So, it was quite easy for the progammer to read/write machine code in octal. -- Grant Edwards grante Yow! I've read SEVEN at MILLION books!! visi.com -- http://mail.python.org/mailman/listinfo/python-list
gettext translate problem
Hi,
I've got the following code in main.py file:
import gettext
import os
t = gettext.translation(__file__.split('.')[0], os.getcwd())
_ = t.lgettext
if __name__=='__main__':
print _("Hello")
then I call: xgettext main.py
and after that I call: msgfmt messages.po
wchich produces the following message:
messages.po: warning: Charset "CHARSET" is not a portable encoding
name.
Message conversion to user's charset might not
work.
then after calling: python main.py
the following output is print:
Traceback (most recent call last):
File "main.py", line 4, in
t = gettext.translation(__file__.split('.')[0], os.getcwd())
File "/usr/lib/python2.5/gettext.py", line 484, in translation
raise IOError(ENOENT, 'No translation file found for domain',
domain)
IOError: [Errno 2] No translation file found for domain: 'main'
How to use gettext translation method properly?
Regards,
Marek
--
http://mail.python.org/mailman/listinfo/python-list
Re: Colors on IDLE
* vsoler (Sat, 29 Aug 2009 04:01:46 -0700 (PDT)) > On Aug 29, 1:27 am, r wrote: > > Have you tried saving the files as MYScriptName.py? notice the py > > extension, very important ;) > > That was it!!! > > I see the colors again. Thank you. I suggest you start using familiar technical terms. Like "syntax highlighting" instead of "see colours". That would increase the number of useful answers you get - at least it will stop people from thinking you talk about controlled substances. Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: why python got less developers ?
Deep_Feelings schrieb: python got relatively fewer numbers of developers than other high level languages like .NET , java .. etc why ? Besides the marketing argument, python never had a "hype". Both PHP and ruby(Rails to be precise) got widespread because they could at one point do "one" thing better than the competition. From there on, they had more ressources (developer time) and grew fast and beyond the original problem domain. Now you can write GUI apps in PHP, great! cheers Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Colors on IDLE
On Aug 29, 1:27 am, r wrote: > Have you tried saving the files as MYScriptName.py? notice the py > extension, very important ;) That was it!!! I see the colors again. Thank you. -- http://mail.python.org/mailman/listinfo/python-list
Re: Overriding iadd for dictionary like objects
On Aug 28, 10:37 pm, Joshua Judson Rosen wrote:
> Carl Banks writes:
>
> > On Aug 28, 2:42 pm, Terry Reedy wrote:
>
> > > Carl Banks wrote:
> > > > I don't think it needs a syntax for that, but I'm not so sure a method
> > > > to modify a value in place with a single key lookup wouldn't
> > > > occasioanally be useful.
>
> > > Augmented assignment does that.
>
> > Internally uses two lookups, one for getting, and one for setting.
>
> > I think this is an unavoidable given Python's semantics. Look at
> > the traceback:
>
> > >>> def x():
> > ... d['a'] += 1
> > ...
> > >>> dis.dis(x)
> > 2 0 LOAD_GLOBAL 0 (d)
> > 3 LOAD_CONST 1 ('a')
> > 6 DUP_TOPX 2
> > 9 BINARY_SUBSCR
>
> OK, there's one lookup, but...
>
> > 10 LOAD_CONST 2 (1)
> > 13 INPLACE_ADD
> > 14 ROT_THREE
> > 15 STORE_SUBSCR
> > 16 LOAD_CONST 0 (None)
> > 19 RETURN_VALUE
>
> ... I don't see anything in there that retrieves the value a second time
STORE_SUBSCR has to look up the position in the hash table to store
the value, hence the second lookup.
> > > > As a workaround, if lookups are expensive,
>
> > > But they are not. Because (C)Python is heavily based on dict name lookup
> > > for builtins and global names and attributes, as well as overt dict
> > > lookup, must effort has gone into optimizing dict lookup.
>
> > The actual lookup algorithm Python dicts use is well-optimized, yes,
> > but the dict could contain keys that have expensive comparison and
> > hash-code calculation, in which case lookup is going to be slow.
>
> I'll like the originator correct me if I've made a mistake, but I read
> "lookup" as actually meaning "lookup", not "value-comparison".
This has nothing to do with value comparison. I was talking about key
comparison, which happens when looking up a position in a hash table.
I was the first person to use the word "lookup" in this thread and I
specifically meant hash-table position lookup.
> At least in part because the question, as it was posed, specifically
> related to a wrapper-class (providing a mapping ("dict like") interface)
> around a database of some sort other than Python's dict class per se.
>
> How do the details of Python's native dict-type's internal (hashtable)
> algorithm matter when they're explicitly /not/ being used?
Well it doesn't apply specifically to the OP's problem. I changed the
topic a bit by making it specific to dicts. Is that ok with you? Was
that not allowed?
The OP can add a method like apply_to_value to his own class, but one
can't do that for dicts. Ergo why something like apply_to_value()
would be useful enough in rare circumstances where lookup is very slow
to merit a moments consideration before being rejected.
(If dict did have a method like that, the OP would at least know which
method to override.)
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
IDE for Python
Dear all, Please suggest some good IDE for python.I am working in linux platform. -- Regards, Thangappan.M -- http://mail.python.org/mailman/listinfo/python-list
SEI Job Opening
SEI is seeking a FT, YR Photovoltaic Technical Manager. If you are a team player with a minimum of 4 years PV installation, curriculum and education development, management experience, the ability to multitask, strong verbal and written communication skills, and a sense of humor, SEI invites you to apply to join our team in Paonia, Colorado. For more details www.technicaledu.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: (Simple?) Unicode Question
On Sat, 29 Aug 2009 09:34:43 +0200, Thorsten Kampe wrote:
> * Rami Chowdhury (Thu, 27 Aug 2009 09:44:41 -0700)
>> > Further, does anything, except a printing device need to know the
>> > encoding of a piece of "text"?
>
> Python needs to know if you are processing the text.
Python only needs to know when you convert the text to or from bytes. I
can do this:
>>> s = "hello"
>>> t = "world"
>>> print(' '.join([s, t]))
hello world
and not need to care anything about encodings.
So long as your terminal has a sensible encoding, and you have a good
quality font, you should be able to print any string you can create.
>> I may be wrong, but I believe that's part of the idea between
>> separation of string and bytes types in Python 3.x. I believe, if you
>> are using Python 3.x, you don't need the character encoding mumbo jumbo
>> at all ;-)
>
> Nothing has changed in that regard. You still need to decode and encode
> text and for that you have to know the encoding.
You only need to worry about encoding when you convert from bytes to
text, and visa versa. Admittedly, the most common time you need to do
that is when reading input from files, but if all your text strings are
generated by Python, and not output anywhere, you shouldn't need to care
about encodings.
If all your text contains nothing but ASCII characters, you should never
need to worry about encodings at all.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Combining C and Python programs
On Saturday 29 August 2009 09:54:15 Sortie wrote: > I want to write a program that will use ode for the physics > simulation, whose python bindings are outdated. So I'm writing > the physics engine in C and want to write the drawing code in > Python. What will be the best way of making those two programs > work together? THe physics engine won't have to run concurrently > with the drawing code. It will only return some position data so > they can be drawn. Have you looked at ctypes? - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: comparison on list yields surprising result
On Sat, 29 Aug 2009 09:36:38 +0200, Hendrik van Rooyen wrote: > On Friday 28 August 2009 21:00:31 Dr. Phillip M. Feldman wrote: >> In [21]: x >> Out[21]: [1, 2, 3, 5] >> >> In [22]: x>6 >> Out[22]: True >> >> Is this a bug? > > No, it is a feature, so that you can use sorted on this: > > [[1,2,3,4,5],6] If it's a feature, it has gone away in Python 3. Python 3.0.1 (r301:69556, Apr 2 2009, 00:41:38) [GCC 4.1.2 20070925 (Red Hat 4.1.2-27)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> [[1,2,3], 5].sort() Traceback (most recent call last): File "", line 1, in TypeError: unorderable types: int() < list() -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Combining C and Python programs
I want to write a program that will use ode for the physics simulation, whose python bindings are outdated. So I'm writing the physics engine in C and want to write the drawing code in Python. What will be the best way of making those two programs work together? THe physics engine won't have to run concurrently with the drawing code. It will only return some position data so they can be drawn. -- http://mail.python.org/mailman/listinfo/python-list
