Re: Python Unicode handling wins again -- mostly
On 30/11/2013 02:08, Roy Smith wrote: In article <[email protected]>, Steven D'Aprano wrote: (8) What's the uppercase of "baffle" spelled with an ffl ligature? Like most other languages, Python 3.2 fails: py> 'baffle'.upper() 'BAfflE' but Python 3.3 passes: py> 'baffle'.upper() 'BAFFLE' I disagree. The whole idea of ligatures like fi is purely typographic. The crossbar on the "f" (at least in some fonts) runs into the dot on the "i". Likewise, the top curl on an "f" run into the serif on top of the "l" (and similarly for ffl). There is no such thing as a "FFL" ligature, because the upper case letterforms don't run into each other like the lower case ones do. Thus, I would argue that it's wrong to say that calling upper() on an ffl ligature should yield FFL. I would certainly expect, x.lower() == x.upper().lower(), to be True for all values of x over the set of valid unicode codepoints. Having u"\uFB04".upper() ==> "FFL" breaks that. I would also expect len(x) == len(x.upper()) to be True. http://bugs.python.org/issue19819 talks about these beasties. Please don't come back to me as I haven't got a clue!!! -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Managing Google Groups headaches
Dennis Lee Bieber writes: > [NNTP] clients provide full-fledged editors and conversely full-fledged editors provide NNTP clients -- https://mail.python.org/mailman/listinfo/python-list
any lib to convert 3200+ pic to animated gif?
I want to make an animated GIF from 3200+ png
I searched and found http://code.google.com/p/visvis/source/browse/#hg/vvmovie
and I wrote:
[code]
allPic=glob.glob('*.png')
allPic.sort()
allPic=[Image.open(i) for i in allPic]
writeGif('lala3.gif',allPic, duration=0.5, dither=0)
[/code]
However I got
[quote]
allPic=[Image.open(i) for i in allPic]
File "e:\prg\py\python-2.7.3\lib\site-packages\PIL\Image.py", line
1952, in open
fp = __builtin__.open(fp, "rb")
IOError: [Errno 24] Too many open files: 'out0572.png'
[/quote]
Is there other lib for py? thanks
--
https://mail.python.org/mailman/listinfo/python-list
Re: any lib to convert 3200+ pic to animated gif?
On Sun, Dec 1, 2013 at 1:21 AM, oyster wrote:
> I want to make an animated GIF from 3200+ png
> I searched and found http://code.google.com/p/visvis/source/browse/#hg/vvmovie
> and I wrote:
> allPic=glob.glob('*.png')
> allPic.sort()
> allPic=[Image.open(i) for i in allPic]
> writeGif('lala3.gif',allPic, duration=0.5, dither=0)
>
> However I got
> IOError: [Errno 24] Too many open files: 'out0572.png'
Yes, trying to open 3200 files is likely to be a problem!
The question is, how can you load them into memory one by one, and
keep closing them? I'm not very familiar with PIL, but a glance at the
code suggests that the Image.open() calls will create, but possibly
not verify, the images. Does this work?
images = []
for pic in allPic:
img = Image.open(pic)
img.verify()
images.append(img)
allPic = images
Use that instead of your list comprehension. In theory, at least, that
should abandon the file objects (not explicitly closing them, alas,
but abandoning them should result in them being closed in CPython), so
you ought to get them all opened and read.
Otherwise, someone with more knowledge of PIL may be able to help.
According to the PIL docs, this list may be more focussed on what
you're trying to do, so if you don't get a response here, try there:
https://mail.python.org/mailman/listinfo/image-sig
Hope that helps!
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python Unicode handling wins again -- mostly
Le samedi 30 novembre 2013 03:08:49 UTC+1, Roy Smith a écrit : > > > > The whole idea of ligatures like fi is purely typographic. The crossbar > > on the "f" (at least in some fonts) runs into the dot on the "i". > > Likewise, the top curl on an "f" run into the serif on top of the "l" > > (and similarly for ffl). > And do you know the origin of this typographical feature? Because, mechanically, the dot of the "i" broke too often. I cann't proof that's the truth, I read this many times in the literature speaking about typography and about unicode. In my opinion, a very plausible explanation. jmf -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Unicode handling wins again -- mostly
[email protected] wrote: And do you know the origin of this typographical feature? Because, mechanically, the dot of the "i" broke too often. In my opinion, a very plausible explanation. It doesn't sound very plausible to me, because there are a lot more stand-alone 'i's in English text than there are ones following an f. What is there to stop them from breaking? It's more likely to be simply a kerning issue. You want to get the stems of the f and the i close together, and the only practical way to do that with mechanical type is to merge them into one piece of metal. Which makes it even sillier to have an 'ffi' character in this day and age, when you can simply space the characters so that they overlap. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Unicode handling wins again -- mostly
Steven D'Aprano wrote: On Sat, 30 Nov 2013 00:37:17 -0500, Roy Smith wrote: So, who am I to argue with the people who decided that I needed to be able to type a "PILE OF POO" character. Blame the Japanese for that. Apparently some of the biggest users of Unicode are the various Japanese mobile phone manufacturers, TV stations, map makers and similar. Also there's apparently a pun in Japanese involving the words for 'poo' and 'luck'. So putting a poo symbol in your text message means 'good luck'. Given that, it's not *quite* as silly as it seems. -- Best of poo, Greg -- https://mail.python.org/mailman/listinfo/python-list
Change a file type in Python?
When opening a file, you'd say whether you want to read or write to a file. This is fine, but say for example later on in the program I change my mind and I want to write to a file instead of reading it. Yes, I could just say 'r+w' when opening the file, but what if I don't know if I'm going to do both? What if I have the user decide, and then later on I let the user change this. Is it possible to do so without opening the file again and using the same file object? Thanks! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Unicode handling wins again -- mostly
On 11/30/13 5:37 PM, Gregory Ewing wrote: [email protected] wrote: And do you know the origin of this typographical feature? Because, mechanically, the dot of the "i" broke too often. In my opinion, a very plausible explanation. It doesn't sound very plausible to me, because there are a lot more stand-alone 'i's in English text than there are ones following an f. What is there to stop them from breaking? It's more likely to be simply a kerning issue. You want to get the stems of the f and the i close together, and the only practical way to do that with mechanical type is to merge them into one piece of metal. Which makes it even sillier to have an 'ffi' character in this day and age, when you can simply space the characters so that they overlap. The fi ligature was created because visually, an f and i wouldn't work well together: the crossbar of the f was near, but not connected to the serif of the i, and the terminal bulb of the f was close to, but not coincident, with the dot of the i. This article goes into great detail, and has a good illustration of how an f and i can clash, and how an fi ligature can fix the problem: http://opentype.info/blog/2012/11/20/whats-a-ligature/ . Note the second fi illustration, which demonstrates using a ligature to make the letters appear *less* connected than they would individually! This is also why "simply spacing the characters" isn't a solution: a specially designed ligature looks better than a separate f and i, no matter how minutely kerned. It's unfortunate that Unicode includes presentation alternatives like the fi (and ff, fl, ffi, and fl) ligatures. It was done to be a superset of existing encodings. Many typefaces have other non-encoded ligatures as well, especially display faces, which also have alternate glyphs. Unicode is a funny mix in that it includes some forms of alternates, but can't include all of them, so we have to put up with both an ad-hoc Unicode that includes presentational variants, and also some other way to specify variants because Unicode can't include all of them. --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: Change a file type in Python?
On Sun, Dec 1, 2013 at 9:45 AM, Eamonn Rea wrote: > Is it possible to do so without opening the file again and using the same > file object? In the general sense, no, but you may be able to abuse things terribly by calling __init__ on an existing object. The only advantage of that would be if you have multiple references to the file object, so normally don't - just close it and reopen. You can't change access/share mode on the file system without closing and reopening, so ultimately that's going to have to happen. As a separate point, can you please use a better client than Google Groups? It's buggy and your posts come out looking ugly. There are other news clients, or you can sign up for the email list here: https://mail.python.org/mailman/listinfo/python-list ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Change a file type in Python?
Thanks for the help! Ok, I'll look into the mailing list. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Unicode handling wins again -- mostly
On Sun, 01 Dec 2013 11:37:30 +1300, Gregory Ewing wrote: > Which makes it even sillier to have an 'ffi' character in this day and > age, when you can simply space the characters so that they overlap. It's in Unicode to support legacy character sets that included it[1]. There are a bunch of similar cases: * LATIN CAPITAL LETTER A WITH RING ABOVE versus ANGSTROM SIGN * KELVIN SIGN versus LATIN CAPITAL LETTER A * DEGREE CELSIUS and DEGREE FAHRENHEIT * the whole set of full-width and half-width forms On the other hand, there are cases which to a naive reader might look like needless duplication but actually aren't. For example, there are a bunch of visually indistinguishable characters[2] in European languages, like AΑА and BΒВ. The reason for this becomes more obvious[3] when you lowercase them: py> 'AΑА BΒВ'.lower() 'aαа bβв' Sorting and case-conversion rules would become insanely complicated, and context-sensitive, if Unicode only included a single code point per thing- that-looks-the-same. The rules for deciding what is and what isn't a distinct character can be quite complex, and often politically charged. There's a lot of opposition to Unicode in East Asian countries because it unifies Han ideograms that look and behave the same in Chinese, Japanese and Korean. The reason they do this is for the same reason that Unicode doesn't distinguish between (say) English A, German A and French A. One reason some East Asians want it to is for the same reason you or I might wish to flag a section of text as English and another section of text as German, and have them displayed in slightly different typefaces and spell-checked with a different dictionary. The Unicode Consortium's answer to that is, this is beyond the remit of the character set, and is best handled by markup or higher-level formatting. (Another reason for opposing Han unification is, let's be frank, pure nationalism.) [1] As far as I can tell, the only character supported by legacy character sets which is not included in Unicode is the Apple logo from Mac charsets. [2] The actual glyphs depends on the typeface used. [3] Again, modulo the typeface you're using to view them. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Unicode handling wins again -- mostly
On 2013-12-01 00:22, Steven D'Aprano wrote: > * KELVIN SIGN versus LATIN CAPITAL LETTER A I should hope so ;-) -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Change a file type in Python?
On Sat, 30 Nov 2013 14:45:18 -0800, Eamonn Rea wrote: > When opening a file, you'd say whether you want to read or write to a > file. This is fine, but say for example later on in the program I change > my mind and I want to write to a file instead of reading it. Yes, I > could just say 'r+w' when opening the file, but what if I don't know if > I'm going to do both? What if I have the user decide, and then later on > I let the user change this. I'd say if you're worried about this, your program needs to be redesigned. In general, with the exception of special purpose files like databases (and you're not inventing your own database, I hope) it is good clean programming practice to keep files open only so long as you really need them to be open. - It's only possible to have open some number of files open at a time. That number is typically quite large, but not *that* large. Every time you open a file and keep it open, it impacts other programs and the operating system by a small amount. - Particularly on Windows, once you open a file, nothing else can open it. That means it can't be backed up, scanned for viruses, opened by other programs, deleted or renamed. - When you open a file for writing, and keep it open, the changes you make aren't guaranteed to be written to disk until you actually close the file. You can call the sync method, the longer you keep it open the more likely the risk of data-loss in the case of sudden crash or power interruption. - To avoid data loss, you should try to avoid updating files in place. If the program crashes, you could leave the file in a messed up state. With very few exceptions, I recommend that you avoid this approach: # Don't do this. open file read data process in memory write changes to file more processing write changes to file more processing write changes to file close file exit in favour of this approach: open file; read data; close file process in memory open file; write to file; close file more processing open file; write to file; close file more processing open file; write to file; close file exit > Is it possible to do so without opening the file again and using the > same file object? No. You cannot even re-open a file object using the same file mode. Why do you care? It isn't difficult to throw away the file object and create a new one. That part is cheap. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Unicode handling wins again -- mostly
On Sat, 30 Nov 2013 18:52:48 -0600, Tim Chase wrote: > On 2013-12-01 00:22, Steven D'Aprano wrote: >> * KELVIN SIGN versus LATIN CAPITAL LETTER A > > I should hope so ;-) I blame my keyboard, where letters A and K are practically right next to each other, only seven letters apart. An easy typo to make. -- Stpvpn -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Unicode handling wins again -- mostly
On 2013-12-01 00:54, Steven D'Aprano wrote: > On Sat, 30 Nov 2013 18:52:48 -0600, Tim Chase wrote: > > > On 2013-12-01 00:22, Steven D'Aprano wrote: > >> * KELVIN SIGN versus LATIN CAPITAL LETTER A > > > > I should hope so ;-) > > > I blame my keyboard, where letters A and K are practically right > next to each other, only seven letters apart. An easy typo to make. > > > > -- > Stpvpn I suppose I should have modified my attribution-quote to read "Steven D'Kprano wrote" then :-) -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Unicode handling wins again -- mostly
On Sun, Dec 1, 2013 at 11:54 AM, Steven D'Aprano wrote: > On Sat, 30 Nov 2013 18:52:48 -0600, Tim Chase wrote: > >> On 2013-12-01 00:22, Steven D'Aprano wrote: >>> * KELVIN SIGN versus LATIN CAPITAL LETTER A >> >> I should hope so ;-) > > > I blame my keyboard, where letters A and K are practically right next to > each other, only seven letters apart. An easy typo to make. “It’s an easy mistake to make” the PFY concurs “Many’s the time I’ve picked up a cattle prod thinking it was a lint remover as I’ve helped groom one of your predecessors before an important board meeting about slashing the IT budget.” http://www.theregister.co.uk/2010/11/26/bofh_2010_episode_18/ ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Unicode handling wins again -- mostly
In article , Chris Angelico wrote: > On Sun, Dec 1, 2013 at 11:54 AM, Steven D'Aprano > wrote: > > On Sat, 30 Nov 2013 18:52:48 -0600, Tim Chase wrote: > > > >> On 2013-12-01 00:22, Steven D'Aprano wrote: > >>> * KELVIN SIGN versus LATIN CAPITAL LETTER A > >> > >> I should hope so ;-) > > > > > > I blame my keyboard, where letters A and K are practically right next to > > each other, only seven letters apart. An easy typo to make. > > âItâs an easy mistake to makeâ the PFY concurs âManyâs the time > Iâve > picked up a cattle prod thinking it was a lint remover as Iâve helped > groom one of your predecessors before an important board meeting about > slashing the IT budget.â > > http://www.theregister.co.uk/2010/11/26/bofh_2010_episode_18/ > > ChrisA What means "PFY"? The only thing I can think of is "Poor F---ing Yankee" :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Unicode handling wins again -- mostly
On Sun, Dec 1, 2013 at 12:27 PM, Roy Smith wrote: >> http://www.theregister.co.uk/2010/11/26/bofh_2010_episode_18/ >> >> ChrisA > > What means "PFY"? The only thing I can think of is "Poor F---ing > Yankee" :-) In the context of the BOFH, it stands for Pimply-Faced Youth and means BOFH's assistant. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python project
> To be perfectly honest, this is much too large a project for you. First > read some python tutorials and learn how to code in python. If you work it > every day, maybe you can kind of understand what its about in a very > superficial sense in a month. However, if you are having fun learning, then > add a new small piece to learn. Joel may be too pessimistic. The OP (Richard) says he wants to create an "online city guide start with my own city". I could see that as being anything from a few simple HTML pages all the way to a database-backed Django site. Is there an example of a guide to someone else's city that you are trying to emulate? If yes, reply with the link/s. If no, and because you know HTML, can you create a mock-up of what you would like your end result to look like, and then share those links with us? -- https://mail.python.org/mailman/listinfo/python-list
Re: Change a file type in Python?
On Sunday, December 1, 2013 5:34:11 AM UTC+5:30, Eamonn Rea wrote:
> Thanks for the help!
>
> Ok, I'll look into the mailing list.
[Assuming you are using GG with firefox on linux]
All you need to do is
1. Install 'Its all text' FF addon
2. Point the 'editor' of 'Its all text' to the below python script
After that, a small new edit button will appear outside the text-box and its
one-click solution
-Python Script--
#!/usr/bin/env python3
# As far as I know both python2 and 3 work
# Windows/Mac no idea :-)
# A script to drop-in as an editor for firefox addon "Its all text"
# It cleans up two google-group nuisances:
# 1. Useless blank lines
# 2. Excessively long lines
# No efforts at error reporting as stderr is not available in any
# easy way (I know) to firefox (other browsers?)
# To test separately:
# Compose a mail (preferably reply) in GG
# Copy-paste the stuff (maybe with some long lines added without the >)
# Run this script with that filename as argv[1]
from sys import argv
from re import sub
import re
# Clean double spacing
def cleands(s):
# Assumption: ASCII 025 (NAK) never occurs in input
s1 = sub("^> *\n> *$", "\025" , s , flags=re.M)
s2 = sub("^> *\n", "" , s1, flags=re.M)
s3 = sub("\025\n", ">\n" , s2, flags=re.M)
return s3
# Maximum length that (new) lines should attain
Maxlen = 75
# clean all long lines, s is the whole file/text
def cleanall_ll(s):
lines = (cleanll(l) for l in s.split("\n"))
return "\n".join(lines)
# clean one long line
def cleanll(line):
return ( line if line.startswith(">") else cleanll_rec(line) )
def cleanll_rec(line):
if len(line) <= Maxlen : return line
pos = line.rfind(" ", 0, Maxlen)
if pos == -1 : #Failed due to no spaces
return line
return line[0:pos] + "\n" + cleanll_rec(line[pos+1: ])
def clean(s):
return cleanall_ll(cleands(s))
def main():
with open(argv[1]) as f: s = f.read()
with open(argv[1], "w") as f: f.write(clean(s))
if __name__ == '__main__' :
main()
--
https://mail.python.org/mailman/listinfo/python-list
Re: Change a file type in Python?
On Sun, Dec 1, 2013 at 2:02 PM, rusi wrote: > On Sunday, December 1, 2013 5:34:11 AM UTC+5:30, Eamonn Rea wrote: >> Thanks for the help! >> >> Ok, I'll look into the mailing list. > > [Assuming you are using GG with firefox on linux] > > All you need to do is > 1. Install 'Its all text' FF addon > 2. Point the 'editor' of 'Its all text' to the below python script > > After that, a small new edit button will appear outside the text-box and its > one-click solution Yeah I still think it's a lot easier to switch to a properly-working system. What you're suggesting still doesn't wrap text properly, as evidenced by your above over-long line. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Change a file type in Python?
On Sunday, December 1, 2013 8:52:03 AM UTC+5:30, Chris Angelico wrote: > On Sun, Dec 1, 2013 at 2:02 PM, rusi wrote: > > On Sunday, December 1, 2013 5:34:11 AM UTC+5:30, Eamonn Rea wrote: > >> Thanks for the help! > >> > >> Ok, I'll look into the mailing list. > > > > [Assuming you are using GG with firefox on linux] > > > > All you need to do is > > 1. Install 'Its all text' FF addon > > 2. Point the 'editor' of 'Its all text' to the below python script > > > > After that, a small new edit button will appear outside the text-box and > > its one-click solution > > What you're suggesting still doesn't wrap text properly, as > evidenced by your above over-long line. > > ChrisA Ok my bad. I offered a 1-click solution, but did 0 clicks :-) Strictly speaking one needs anywhere between one and two clicks for this to work properly. My profuse apologies for the improper and illegitimate round-down > Yeah I still think it's a lot easier to switch to a properly-working > system. Of course -- if 1.something clicks are too onerous, you are free not to use it :-) More seriously this discussion completely misses the point. I think we are dealing with 3 completely separable problems: [Slightly changing what I earlier wrote…] 1. Undesirable elements -- spam, troll and more exotic 2. Immature noobs -- literally or almost literally kids 3. Stupid technology -- in this case, GG The anti-GG crusade is getting pissed-off with 1 and/or 2 and then attacking 3. -- https://mail.python.org/mailman/listinfo/python-list
Re: Change a file type in Python?
On Sun, Dec 1, 2013 at 3:58 PM, rusi wrote: > I think we are dealing with 3 completely separable problems: > [Slightly changing what I earlier wrote…] > > 1. Undesirable elements -- spam, troll and more exotic > 2. Immature noobs -- literally or almost literally kids > 3. Stupid technology -- in this case, GG > > The anti-GG crusade is getting pissed-off with 1 and/or 2 and then > attacking 3. Most of it is getting annoyed at the results of 3, and then attacking 3. That's what I do, at least. There have been several people who've switched to email as a result of being told that their posts are coming out looking ugly; their posts subsequently are NOT ugly, and they always had useful content in them, so they become productive and highly welcome members of the community without being masked behind buggy technology. Nothing to do with immaturity or spam. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
