Re: Do not run this code.
On Thu, Mar 5, 2015 at 12:39 AM, Dave Farrance wrote: > Ben Finney wrote: > >>Chris Angelico writes: >> >>> import base64; exec(…) >> >>That's all I need to know. Code with ‘exec()’ calls, I consider unsafe >>by default. > > Indeed. replacing exec with print... > print(base64.b64decode(b"eD0neD0lcjsgZXhlYyh4JSV4KSc7IGV4ZWMoeCV4KQ==")) > x='x=%r; exec(x%%x)'; exec(x%x) > > so, discarding that second exec... > x='x=%r; exec(x%%x)' print(x) > x=%r; exec(x%%x) > > So it recurses, and if that second exec had been left in then it would be > a fork bomb. In order to be a fork bomb, it would have to call fork at some point. This is just a race to see whether you'll run out of memory before the recursion limit is reached. -- https://mail.python.org/mailman/listinfo/python-list
Re: (Still OT) Nationalism, language and monoculture [was Re: Python Worst Practices]
On Thu, 05 Mar 2015 07:19:42 +0200, Marko Rauhamaa wrote: > >Where I work, people do use voice still occasionally to communicate. > Communications skills... the bane of any software developer. Pronunciation is just another obstacle to cross on top of the natural barrier that is transmitting complex computer science ideas through natural language. An ascii file with some code does a much better job at that. Most bugs start in a our mouths, no matter how many times we brush our teeth. In any case, communication is a two-way process. If you can't understand British accent, you should make an effort to do so. It will enrich your communication skills and that is an important skill to have. Might even land you a better job. If instead you prefer to demand british people to speak in your accent, because you are in your country and people should speak with your accent and all that bullshit, and you can't understand them and they should make an effort, waa-waa, that is fine. I'm sure you are otherwise a a friendly and communicative character. -- https://mail.python.org/mailman/listinfo/python-list
Re: Reading all buffered bytes without blocking
In article ,
wrote:
buffer = ('a'*998 + '\u20ac').encode('utf-8')[:1000]
buffer.decode('utf-8')
>Traceback (most recent call last):
> File "", line 1, in
>UnicodeDecodeError: 'utf-8' codec can't decode bytes in position 998-999:
>unexpected end of data
# BOUM
hmm...
>>> import sys as jmr
>>> input = jmr.stdin.fileno()
>>> output = jmr.stdout.fileno()
>>> value = output / input
Traceback (most recent call last):
File "", line 1, in
ZeroDivisionError: integer division or modulo by zero
>>> # BOUM
--
[J|O|R] <- .signature.gz
--
https://mail.python.org/mailman/listinfo/python-list
Re: (Still OT) Nationalism, language and monoculture [was Re: Python Worst Practices]
Mario Figueiredo : > If instead you prefer to demand british people to speak in your > accent, because you are in your country I'm in Finland, mind you. Finnish (the Häme dialect, specifically) is my native language. I'm not suggesting my international coworkers should address me in my language, let alone my home dialect. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Newbie question about text encoding
Rustom Mody wrote: > On Wednesday, March 4, 2015 at 10:25:24 AM UTC+5:30, Chris Angelico wrote: >> On Wed, Mar 4, 2015 at 3:45 PM, Rustom Mody wrote: >> > >> > It lists some examples of software that somehow break/goof going from >> > BMP-only unicode to 7.0 unicode. >> > >> > IOW the suggestion is that the the two-way classification >> > - ASCII >> > - Unicode >> > >> > is less useful and accurate than the 3-way >> > >> > - ASCII >> > - BMP >> > - Unicode >> >> How is that more useful? Aside from storage optimizations (in which >> the significant breaks would be Latin-1, UCS-2, and UCS-4), the BMP is >> not significantly different from the rest of Unicode. > > Sorry... Dont understand. Chris is suggesting that going from BMP to all of Unicode is not the hard part. Going from ASCII to the BMP part of Unicode is the hard part. If you can do that, you can go the rest of the way easily. I mostly agree with Chris. Supporting *just* the BMP is non-trivial in UTF-8 and UTF-32, since that goes against the grain of the system. You would have to program in artificial restrictions that otherwise don't exist. UTF-16 is different, and that's probably why you think supporting all of Unicode is hard. With UTF-16, there really is an obvious distinction between the BMP and the SMP: that's where you jump from a single 2-byte unit to a pair of 2-byte units. But that distinction doesn't exist in UTF-8 or UTF-32: - In UTF-8, about 99.8% of the BMP requires multiple bytes. Whether you support the SMP or not doesn't change the fact that you have to deal with multi-byte characters. - In UTF-32, everything is fixed-width whether it is in the BMP or not. In both cases, supporting the SMPs is no harder than supporting the BMP. It's only UTF-16 that makes the SMP seem hard. Conclusion: faulty implementations of UTF-16 which incorrectly handle surrogate pairs should be replaced by non-faulty implementations, or changed to UTF-8 or UTF-32; incomplete Unicode implementations which assume that Unicode is 16-bit only (e.g. UCS-2) are obsolete and should be upgraded. Wrong conclusion: SMPs are unnecessary and unneeded, and we need a new standard that is just like obsolete Unicode version 1. Unicode version 1 is obsolete for a reason. 16 bits is not enough for even existing languages, let alone all the code points and characters that are used in human communication. >> Also, the expansion from 16-bit was back in Unicode 2.0, not 7.0. Why >> do you keep talking about 7.0 as if it's a recent change? > > It is 2015 as of now. 7.0 is the current standard. > > The need for the adjective 'current' should be pondered upon. What's your point? The UTF encodings have not changed since they were first introduced. They have been stable for at least twenty years: UTF-8 has existed since 1993, and UTF-16 since 1996. Since version 2.0 of Unicode in 1996, the standard has made "stability guarantees" that no code points will be renamed or removed. Consequently, there has only been one version which removed characters, version 1.1. Since then, new versions of the standard have only added characters, never moved, renamed or deleted them. http://unicode.org/policies/stability_policy.html Some highlights in Unicode history: Unicode 1.0 (1991): initial version, defined 7161 code points. In January 1993, Rob Pike and Ken Thompson announced the design and working implementation of the UTF-8 encoding. 1.1 (1993): defined 34233 characters, finalised Han Unification. Removed some characters from the 1.0 set. This is the first and only time any code points have been removed. 2.0 (1996): First version to include code points in the Supplementary Multilingual Planes. Defined 38950 code points. Introduced the UTF-16 encoding. 3.1 (2001): Defined 94205 code points, including 42711 additional Han ideographs, bringing the total number of CJK code points alone to 71793, too many to fit in 16 bits. 2006: The People's Republic Of China mandates support for the GB-18030 character set for all software products sold in the PRC. GB-18030 supports the entire Unicode range, include the SMPs. Since this date, all software sold in China must support the SMPs. 6.0 (2010): The first emoji or emoticons were added to Unicode. 7.0 (2014): 113021 code points defined in total. > In practice, standards change. > However if a standard changes so frequently that that users have to play > catching cook and keep asking: "Which version?" they are justified in > asking "Are the standard-makers doing due diligence?" Since Unicode has stability guarantees, and the encodings have not changed in twenty years and will not change in the future, this argument is bogus. Updating to a new version of the standard means, to a first approximation, merely allocating some new code points which had previously been undefined but are now defined. (Code points can be flagged deprecated, but they will never be removed.) -- Steven -- https://mail.python.org/mailman/listinfo
win32api.LoadKeyboardLayout; any solutions for OSX?
I was looking for a way to change keyboard layouts from within a Python 3 / PyQt4 application. Win32api.LoadKeyboardLayout has come to my rescue on Windows, but is anyone aware of a cross-platform or OSX specific solution for Apple Mac? Thanks for any suggestions. Best regards, Tim -- https://mail.python.org/mailman/listinfo/python-list
Make standalone gui-enabled app for LINUX
Hi I know there are tools like cx_freeze or nuitka for making a linux standalone python app. but i couldn't find a good tutorial about how to making a portable gui-enabled python3 app in linux. by gui-enabled i mean application which use any gui libs like pygobject, qt or wx. I know most of linux distros have python installed(usually version 2) and a package manager to install packages with their dependencies(rpm or deb). but i'm thinking of really portable app with all dependencies included to run easily almost on every linux OSs with no trouble even for new or less experienced linux users. So again how can i make a portable python3 + gui(pygobject, qt, wx) for linux? I found some helpful guide for windows, but what about linux? Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: Make standalone gui-enabled app for LINUX
On 05/03/2015 5:31 pm, Mehdi wrote: Hi I know there are tools like cx_freeze or nuitka for making a linux standalone python app. but i couldn't find a good tutorial about how to making a portable gui-enabled python3 app in linux. by gui-enabled i mean application which use any gui libs like pygobject, qt or wx. I know most of linux distros have python installed(usually version 2) and a package manager to install packages with their dependencies(rpm or deb). but i'm thinking of really portable app with all dependencies included to run easily almost on every linux OSs with no trouble even for new or less experienced linux users. So again how can i make a portable python3 + gui(pygobject, qt, wx) for linux? I found some helpful guide for windows, but what about linux? I haven't announced this on the list yet, but... http://pyqt.sourceforge.net/Docs/pyqtdeploy/ Phil -- https://mail.python.org/mailman/listinfo/python-list
Re: HELP!! How to ask a girl out with a simple witty Python code??
On Wednesday, March 4, 2015 at 7:08:34 PM UTC-8, Chris Angelico wrote: > On Thu, Mar 5, 2015 at 1:50 PM, wrote: > > On Wednesday, March 4, 2015 at 5:34:16 PM UTC-8, Xrrific wrote: > >> Guys, please Help!!! > >> > >> I am trying to impress a girl who is learning python and want ask her out > >> at the same time. > >> > >> Could you please come up with something witty incorporating a simple > >> python line like If...then... but..etc. > >> > >> You will make me a very happy man!!! > >> > >> Thank you very much!!! > > > > You're asking a bunch of nerds for dating advice? > > Some of these nerds are married, others have at least had a successful > romantic life. Granted, dating advice isn't _quite_ on-topic for > python-list, but still, I'm sure there are plenty of people here who > are not the stereotypical nerd "all brains, no ..." that Chris Knight > didn't want to appear as. > > ChrisA I should have known better than to make a joke on this mailing list. Someone is bound to get their panties all up in a bunch. -- https://mail.python.org/mailman/listinfo/python-list
Re: http: connection reset by peer
On 03/04/2015 01:26 AM, Chris Angelico wrote: > Do you have Mozilla Firebug, and if so, can you try the file > attachment with Firebug active? At very least, you should be able to > see exactly what request is getting reset, and then you could try to > simulate that exact request with a simpler harness (like a Python > program - see, on-topic now!). "The connection to the server was reset while the page was loading." After mucking about with it with no results, I went on to another job -- when I came back to this one it was working. -- ~Ethan~ signature.asc Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
Re: HELP!! How to ask a girl out with a simple witty Python code??
sohcahto...@gmail.com writes: > I should have known better than to make a joke on this mailing list. > Someone is bound to get their panties all up in a bunch. You should have known better than to make gendered slurs. Claiming “it was a joke” doesn't alter the sexism of your remarks. Cut that out. -- \ “True greatness is measured by how much freedom you give to | `\ others, not by how much you can coerce others to do what you | _o__) want.” —Larry Wall | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: (Still OT) Nationalism, language and monoculture [was Re: Python Worst Practices]
On Wed, 04 Mar 2015 21:33:01 +0200, Marko Rauhamaa wrote: >Steven D'Aprano : > >> Care to enlighten us then? Because your anecdote doesn't appear to >> have even the most tenuous relationship to this discussion. > >English-speaker, when you name things in your Python programs, you had >better stick to American spellings. > >Even more important, when you talk about Python or other computer stuff >to a non-English-speaker, try to emulate the accent most people around >the world are most familiar with, American English. If you find that >overwhelming, try to speak like a BBC newsreader. Your native accent can >be very difficult to understand. Are things named in Python named with an accent? Can you tell what my accent is like when I write in this newsgroup? -- Steve Hayes from Tshwane, South Africa Web: http://www.khanya.org.za/stevesig.htm Blog: http://khanya.wordpress.com E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk -- https://mail.python.org/mailman/listinfo/python-list
Re: Newbie question about text encoding
On Thu, Mar 5, 2015, at 09:06, Steven D'Aprano wrote: > I mostly agree with Chris. Supporting *just* the BMP is non-trivial in > UTF-8 > and UTF-32, since that goes against the grain of the system. You would > have > to program in artificial restrictions that otherwise don't exist. UTF-8 is already restricted from representing values above 0x10, whereas UTF-8 can "naturally" represent values up to 0x1F in four bytes, up to 0x3FF in five bytes, and 0x7FFF in six bytes. If anything, the BMP represents a natural boundary, since it coincides with values that can be represented in three bytes. Likewise, UTF-32 can obviously represent values up to 0x. You're programming in artificial restrictions either way, it's just a question of what those restrictions are. -- https://mail.python.org/mailman/listinfo/python-list
Re: (Still OT) Nationalism, language and monoculture [was Re: Python Worst Practices]
Steve Hayes : > On Wed, 04 Mar 2015 21:33:01 +0200, Marko Rauhamaa >>English-speaker, when you name things in your Python programs, you had >>better stick to American spellings. >> >>Even more important, when you talk about Python or other computer stuff >>to a non-English-speaker, try to emulate the accent most people around >>the world are most familiar with, American English. If you find that >>overwhelming, try to speak like a BBC newsreader. Your native accent can >>be very difficult to understand. > > Are things named in Python named with an accent? > > Can you tell what my accent is like when I write in this newsgroup? It's clear my accent is clouding my message. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: http: connection reset by peer
On Fri, Mar 6, 2015 at 5:37 AM, Ethan Furman wrote: > On 03/04/2015 01:26 AM, Chris Angelico wrote: > >> Do you have Mozilla Firebug, and if so, can you try the file >> attachment with Firebug active? At very least, you should be able to >> see exactly what request is getting reset, and then you could try to >> simulate that exact request with a simpler harness (like a Python >> program - see, on-topic now!). > > "The connection to the server was reset while the page was loading." > > After mucking about with it with no results, I went on to another job -- when > I came back to this one it was working. Huh. Well, if it recurs, see what you can find out about it... otherwise, problem solved! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: (Still OT) Nationalism, language and monoculture [was Re: Python Worst Practices]
On 05/03/2015 03:38, Rustom Mody wrote: On Thursday, March 5, 2015 at 1:03:13 AM UTC+5:30, Marko Rauhamaa wrote: Steven D'Aprano: Care to enlighten us then? Because your anecdote doesn't appear to have even the most tenuous relationship to this discussion. Even more important, when you talk about Python or other computer stuff to a non-English-speaker, try to emulate the accent most people around the world are most familiar with, American English. If you find that overwhelming, try to speak like a BBC newsreader. Your native accent can be very difficult to understand. You keep talking of accent. At first I thought you were using the word figuratively or else joking. Im now beginning to wonder if you mean it literally. If so have you patented a new AOIP protocol? If not do you give tuitions¹ in ESP/telepathy/Voodoo? I'll be happy to pay -- ¹GG is red-lining tuitions -- heh! I like the idea of some visitor to Scotland mentioning some speaker's English accent. I'm not so keen on the idea of the said visitor being introduced to the Scottish handshake. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Make standalone gui-enabled app for LINUX
Am 05.03.15 um 18:31 schrieb Mehdi: > Hi > I know there are tools like cx_freeze or nuitka for making a linux standalone > python app. but i couldn't find a good tutorial about how to making a > portable gui-enabled python3 app in linux. by gui-enabled i mean application > which use any gui libs like pygobject, qt or wx. > I know most of linux distros have python installed(usually version 2) and a > package manager to install packages with their dependencies(rpm or deb). but > i'm thinking of really portable app with all dependencies included to run > easily almost on every linux OSs with no trouble even for new or less > experienced linux users. > So again how can i make a portable python3 + gui(pygobject, qt, wx) for linux? > I found some helpful guide for windows, but what about linux? > > Thanks. > Use pyinstaller. It creates a "portable app", i.e. either single file or directory which can be run on (nearly) any system. However the resulting files can be awfully big. I use it with a relatively small program that depends on numpy/matplolib, and that pulls in ~100 MB worth of libraries. Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: what is wrong with d.clear()?
On 12/22/2014 3:54 PM, Rick Johnson wrote: On Monday, December 22, 2014 12:16:03 PM UTC-6, sohca...@gmail.com wrote: On Monday, December 22, 2014 12:16:15 AM UTC-8, shawool wrote: [snip: OP's adolescent accessorizing] @_@ Is there a reason you're composing your messages with a large, colored font Shit's obnoxious, yo. Whilst i don't share shawool's penchant of utilizing the brutish urban vernacular, i must agree that he has a valid point. Please don't be tempted to use large fonts (or very small fonts), typically anything around 12 pts will suffice. Also, using any font color besides black, or background color besides white, should be limited except to *VERY* rare occasions. Posts on this list are supposed to be plain text. Let me decide what font color and size I want for reading. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: HELP!! How to ask a girl out with a simple witty Python code??
Ben Finney wrote: > sohcahto...@gmail.com writes: > >> I should have known better than to make a joke on this mailing list. >> Someone is bound to get their panties all up in a bunch. > > You should have known better than to make gendered slurs. Claiming “it > was a joke” doesn't alter the sexism of your remarks. Cut that out. "You're asking a bunch of nerds for dating advice?" Sohcatoa's lousy joke applies to all sexes equally, whether they are male, female, intersex, or indeed non-gendered advanced alien intelligences. (Possibly not *that* advanced if they are hanging around here...) Sorry to say that the only sexism displayed here is your apparent assumption that nerds are all [fe]male, or that the people on this list are all [fe]males. Both men and women can be nerds too, and I know people of both cis-genders and at least three of trans-genders who are clueless about dating. Funnily enough, all but one of them are nerds of one type or another. Despite the efforts of a lot of neo-Victorian feminists determined to repeat the sins of the past, "sexism" does not mean "anything even vaguely related to sexual activity or the potential for sexual activity". Nor is any mild joke made at the (self-)expense of some random subgroup of people "sexism", whether than joke is based on a stereotype or not. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Is nan in (nan,) correct?
It's been brought up on Stack Overflow that the "in" operator (on tuples, and by my testing on dict and list, as well as dict lookup) uses object identity as a shortcut, and returns true immediately if the object being tested *is* an element of the container. However, the contains operation does not specify whether object identity or equality is to be used. In effect, the built-in container types use a hybrid test: "a is b or a == b". My question is, is this a *correct* implementation of the operator, or are objects "supposed to" use a basis of equality for these tests? -- https://mail.python.org/mailman/listinfo/python-list
Re: Newbie question about text encoding
random...@fastmail.us wrote: > On Thu, Mar 5, 2015, at 09:06, Steven D'Aprano wrote: >> I mostly agree with Chris. Supporting *just* the BMP is non-trivial in >> UTF-8 >> and UTF-32, since that goes against the grain of the system. You would >> have >> to program in artificial restrictions that otherwise don't exist. > > UTF-8 is already restricted from representing values above 0x10, > whereas UTF-8 can "naturally" represent values up to 0x1F in four > bytes, up to 0x3FF in five bytes, and 0x7FFF in six bytes. If > anything, the BMP represents a natural boundary, since it coincides with > values that can be represented in three bytes. Likewise, UTF-32 can > obviously represent values up to 0x. You're programming in > artificial restrictions either way, it's just a question of what those > restrictions are. Good points, but they don't greatly change my conclusion. If you are implementing UTF-8 or UTF-32, it is no harder to deal with code points in the SMP than those in the BMP. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: HELP!! How to ask a girl out with a simple witty Python code??
Steven D'Aprano writes: > Ben Finney wrote: > > > sohcahto...@gmail.com writes: > > > >> I should have known better than to make a joke on this mailing > >> list. Someone is bound to get their panties all up in a bunch. > > > > You should have known better than to make gendered slurs. Claiming > > “it was a joke” doesn't alter the sexism of your remarks. Cut that > > out. > > "You're asking a bunch of nerds for dating advice?" “get their panties all up in a bunch” is a gendered slur. It is implying the person is female, as though the person should feel insulted by that. It uses the female gender as an insult. That's not welcoming to anyone female, and we should all be welcoming to anyone of any gender here — which includes not using any gender as the punch-line of a joke. -- \ “Pinky, are you pondering what I'm pondering?” “I think so, | `\Brain, but Zero Mostel times anything will still give you Zero | _o__) Mostel.” —_Pinky and The Brain_ | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: HELP!! How to ask a girl out with a simple witty Python code??
On 05/03/2015 22:59, Ben Finney wrote: Steven D'Aprano writes: Ben Finney wrote: sohcahto...@gmail.com writes: I should have known better than to make a joke on this mailing list. Someone is bound to get their panties all up in a bunch. You should have known better than to make gendered slurs. Claiming “it was a joke” doesn't alter the sexism of your remarks. Cut that out. "You're asking a bunch of nerds for dating advice?" “get their panties all up in a bunch” is a gendered slur. It is implying the person is female, as though the person should feel insulted by that. It uses the female gender as an insult. That's not welcoming to anyone female, and we should all be welcoming to anyone of any gender here — which includes not using any gender as the punch-line of a joke. I just wish this kind of approach was used consistently across the board. That way we wouldn't have had to put up with the appalling slurs from our RUE (Resident Unicode Expert) for perhaps two years. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
[OT]Re: what is wrong with d.clear()?
W dniu 23.12.2014 o 11:25, Steve Hayes pisze: >[1] Or worse, one of those shitty messages that include a plain text part >that says "Your mail program cannot read this email. Please upgrade to a >better mail program." I usually reply to those saying "So why did you send it to me?" I suspect that in most cases the senders do not know that that is what their mail program is sending, and do it to let them know that their mesdsage could not be read. I suspect that in most cases sender don't understand what do you mean saying "So why did you send it to me?". p. m. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is nan in (nan,) correct?
On Thursday, March 5, 2015 at 2:27:12 PM UTC-8, rand...@fastmail.us wrote: > It's been brought up on Stack Overflow that the "in" operator (on > tuples, and by my testing on dict and list, as well as dict lookup) uses > object identity as a shortcut, and returns true immediately if the > object being tested *is* an element of the container. However, the > contains operation does not specify whether object identity or equality > is to be used. In effect, the built-in container types use a hybrid > test: "a is b or a == b". > > My question is, is this a *correct* implementation of the operator, or > are objects "supposed to" use a basis of equality for these tests? I would argue that if `a is b` then it is obvious that `a == b`, so if all you care about is whether or not `a == b`, then it shouldn't matter if `a is b` is checked first. It could greatly speed up comparisons for objects that are expensive to compare. I would also argue that the "in" operator *SHOULD* be using equality of value. Otherwise, if it only used equality of identity, testing if user input is valid by seeing if it is "in" a list of valid inputs wouldn't work. Testing identity in this case would *never* be true unless you were dealing with a select number of integers. >>> i = input() 5 >>> i is 5 True >>> i = intput() 99 >>> i is 99 False >>> i in [1, 2, 3, 99] True -- https://mail.python.org/mailman/listinfo/python-list
Re: Is nan in (nan,) correct?
sohcahto...@gmail.com writes: > I would argue that if `a is b` then it is obvious that `a == b` It may be obvious, but it's not necessarily true. Some commonly-used values – for example, an “null” – are not equal to themselves, by definition. It is fine to define such a type in Python, because ‘is’ does not necessarily imply ‘==’. > I would also argue that the "in" operator *SHOULD* be using equality > of value. Hopefully you can see how that argument is incorrect. -- \ “Yesterday I told a chicken to cross the road. It said, ‘What | `\ for?’” —Steven Wright | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Is nan in (nan,) correct?
On Fri, Mar 6, 2015 at 10:11 AM, wrote:
> I would argue that if `a is b` then it is obvious that `a == b`
This is not true for float("nan"), though. The question is, is your
above statement a valid optimization for the 'in' operator, or not?
And no, it isn't, because it's not perfectly safe. However, there are
other invariants that mean that 'in' has to allow object identity to
count; for instance:
for elem in collection:
assert elem in collection
should never assert-fail.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Is nan in (nan,) correct?
On Thursday, March 5, 2015 at 3:20:16 PM UTC-8, Ben Finney wrote: > sohcahto...@gmail.com writes: > > > I would argue that if `a is b` then it is obvious that `a == b` > > It may be obvious, but it's not necessarily true. Some commonly-used > values - for example, an "null" - are not equal to themselves, by > definition. > > It is fine to define such a type in Python, because 'is' does not > necessarily imply '=='. > > > I would also argue that the "in" operator *SHOULD* be using equality > > of value. > > Hopefully you can see how that argument is incorrect. > > -- > \ "Yesterday I told a chicken to cross the road. It said, 'What | > `\ for?'" --Steven Wright | > _o__) | > Ben Finney Do you have an example of where `a is b` but `a != b` in Python? `None == None` is True. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is nan in (nan,) correct?
sohcahto...@gmail.com writes:
> On Thursday, March 5, 2015 at 3:20:16 PM UTC-8, Ben Finney wrote:
> > It is fine to define such a type in Python, because 'is' does not
> > necessarily imply '=='.
>
> Do you have an example of where `a is b` but `a != b` in Python?
Maybe I misunderstand your question, but you've already been discussing
such an example. Here it is for clarity::
>>> nan = float("NaN")
>>> (nan is nan) == (nan == nan)
False
>>> nan is nan
True
>>> nan == nan
False
> `None == None` is True.
Right, the Python `None` is not the null I was describing. Python does
allow for a null with the semantics I described, because ‘is’ does not
imply ‘==’.
--
\ “We suffer primarily not from our vices or our weaknesses, but |
`\from our illusions.” —Daniel J. Boorstin, historian, 1914–2004 |
_o__) |
Ben Finney
--
https://mail.python.org/mailman/listinfo/python-list
Re: Is nan in (nan,) correct?
On Fri, Mar 6, 2015 at 10:27 AM, wrote:
> Do you have an example of where `a is b` but `a != b` in Python? `None ==
> None` is True.
Check out the subject line.
>>> nan = float("nan")
>>> nan is nan # obviously
True
>>> nan != nan # IEEE 754 mandates
True
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
[Python 3.4] Rationale for readonly slice data attributes
What is the rationale behind making the slice class data attributes readonly? I've built a __getitem__ method for a Map class that contains a list of Cell instance objects. __getitem__ maps this list into a matrix:: # get cell at cartesian coordinates 12, 4 # will map to the 1048th position in the cells list mmap = Map() print(mmap[12, 4]) All is working well and it even supports slicing:: # return all cells with x between 3 and 6 and y up until 4 mmap = Map() [print(cell) for cell in mmap(3:6, :4)] This last example is one case in which I missed the ability to change the the `start` and `stop` attributes of the slice class in order for the maping to occur that allows a 2-dimensions access to a 1-dimension list. It was solved by taking another turn, but it proved to me that the slice data attributes are more useful if they are writable, and this clashes tremendously with the principles of data encapsulation that underline the requirements for a readonly property. In other words, if it needs to be accessed, don't hide it. If it needs to be written, don't lock it. Now, normally I take these things for granted. Rules are rules and their reasons are often fairly obvious. But in this case I'm at loss. I can't find a reason for this class attributes to have been made into readonly properties. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is nan in (nan,) correct?
Nothing about nans is 'correct'. They are a CS invention On 3/5/2015 5:26 PM, random...@fastmail.us wrote: It's been brought up on Stack Overflow that the "in" operator (on tuples, and by my testing on dict and list, as well as dict lookup) uses object identity as a shortcut, and returns true immediately if the object being tested *is* an element of the container. However, the contains operation does not specify whether object identity or equality is to be used. In effect, the built-in container types use a hybrid test: "a is b or a == b". My question is, is this a *correct* implementation of the operator, The current implementation of 'in' is 'correct' in that it reflects the intentions of GvR and other core developers. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Is nan in (nan,) correct?
random...@fastmail.us wrote: > It's been brought up on Stack Overflow that the "in" operator (on > tuples, and by my testing on dict and list, as well as dict lookup) uses > object identity as a shortcut, and returns true immediately if the > object being tested *is* an element of the container. However, the > contains operation does not specify whether object identity or equality > is to be used. In effect, the built-in container types use a hybrid > test: "a is b or a == b". > > My question is, is this a *correct* implementation of the operator, or > are objects "supposed to" use a basis of equality for these tests? This has been discussed multiple times on the python-dev mailing list, and each time the conclusion is the same: Using `is` to optimize the `in` operator is perfectly acceptable for the vast bulk of values in Python. There are only a few, like floating point NANs, where `a is b` does not imply `a == b`, and it is acceptable for container-types like tuple and list to assume reflexivity (that x == x). Since reflexivity is *almost* universal, and using object identity permits very substantial optimizations, the core developers agreed that built-in contain types may assume that `x is y` implies `x == y`. Users of NANs and other non-reflexive types can subclass or define their own membership function. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: HELP!! How to ask a girl out with a simple witty Python code??
Ben Finney wrote: > Steven D'Aprano writes: > >> Ben Finney wrote: >> >> > sohcahto...@gmail.com writes: >> > >> >> I should have known better than to make a joke on this mailing >> >> list. Someone is bound to get their panties all up in a bunch. >> > >> > You should have known better than to make gendered slurs. Claiming >> > “it was a joke” doesn't alter the sexism of your remarks. Cut that >> > out. >> >> "You're asking a bunch of nerds for dating advice?" > > “get their panties all up in a bunch” is a gendered slur. Ah, sorry about misunderstanding you. It wasn't clear to me that you were referring to that specific comment rather than the original comment. > It is implying > the person is female, as though the person should feel insulted by that. > It uses the female gender as an insult. Why do you interpret that as insulting to women merely on the basis of being *female*? Wearing panties/knickers is something anyone can do, of any gender and sexual orientation. "Panties in a bunch" (or "knickers in a twist") is a put-down on the basis of excessive sensitivity, not femaleness. It seems to me that far from challenging sexual stereotypes, mainstream feminist thought actually *reinforces* it: as evidence, you assumed that only women wear panties, therefore any reference to panty-wearing is therefore a slur on women. It's only gender specific if you accept the sexist gendered stereotype that all women are by definition thin-skinned and excessively sensitive. The women I know are nothing like that, and consequently most of them are quite happy to use "knickers in a twist" as a *non-gendered* put-down on the basis of perceived behaviour, not sex. It seems to my wife, and I agree with her, that mainstream feminism has lost its way and is no longer about gender equality, but is now about enforcing a neo-Victorian pseudo-politeness where nobody ever has to be exposed to anything uncomfortable or that threatens to disturb them out of their comfort zone. Hence the focus on codes of conduct, so-called "safe places", trigger warnings and the like. Once upon a time, a safe place meant somewhere where a battered woman could take shelter from her batterer. Now, it apparently means a way to ostracise an actor for his personal religious beliefs. (I'm referring to the Internet storm-in-a-teacup over Adam Baldwin at Supanova.) I do not buy into that philosophy, and neither do most of the woman I know. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Is nan in (nan,) correct?
Steven D'Aprano writes: > Since reflexivity is *almost* universal, and using object identity > permits very substantial optimizations, the core developers agreed > that built-in contain types may assume that `x is y` implies `x == y`. > Users of NANs and other non-reflexive types can subclass or define > their own membership function. On a type (such as a hypothetical SQL NULL type) which does not have reflexivity – i.e. that ‘(x is x) == (x == x)’ may be False – which method needs to be implemented so items *containing* values of that type will have the expected semantics? I can only think of ‘footype.__contains__’, but that's a method of the *container* type, and the ‘in’ operator doesn't consult that method of the items themselves. So, given the hypothetical NullType:: class NullType(object): """ A type whose value never equals any other. This type's values will behave correctly when tested for membership in a collection:: >>> foo = NullType() >>> bar = NullType() >>> foo is foo True >>> foo is bar False >>> foo == foo False >>> foo == bar False >>> quux = [foo, "spam"] >>> "spam" in quux True >>> foo in quux True >>> bar in quux False """ def __eq__(self, value): return False def __method_which_the_in_operator_interrogates__(self, collection): """ Method which the ‘is’ operator interrogates for membership. """ return is_a_member_of(container, self) What method of NullType replaces the hypothetical ‘__method_which_the_in_operator_interrogates__’, which I've implemented to as you describe “define their own membership function”, in order to get the correct behaviour in the doctest above? -- \ “Why am I an atheist? I ask you: Why is anybody not an atheist? | `\ Everyone starts out being an atheist.” —Andy Rooney, _Boston | _o__)Globe_ 1982-05-30 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Is nan in (nan,) correct?
On 03/05/2015 06:55 PM, Ben Finney wrote: > class NullType(object): > """ A type whose value never equals any other. > > This type's values will behave correctly when tested for > membership in a collection:: > > >>> foo = NullType() > >>> bar = NullType() > >>> foo is foo > True > >>> foo is bar > False > >>> foo == foo > False > >>> foo == bar > False > >>> quux = [foo, "spam"] > >>> "spam" in quux > True > >>> foo in quux > True Did you mean False here? Because True is current behavior. -- ~Ethan~ signature.asc Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
Re: HELP!! How to ask a girl out with a simple witty Python code??
Steven D'Aprano writes: > Ben Finney wrote: > > > “get their panties all up in a bunch” is a gendered slur. > > Why do you interpret that as insulting to women merely on the basis of > being *female*? I think your question is in bad faith. You know as well as I do, and I'm confident the person who wrote the slur knows, that “panties” strongly connotes *female* underwear. > It seems to me that far from challenging sexual stereotypes, > mainstream feminist thought actually *reinforces* it: as evidence, you > assumed that only women wear panties, therefore any reference to > panty-wearing is therefore a slur on women. No. I'm saying that it's clear the person saying “get their panties all up in a bunch” fully intends to convey specifically *female* underwear, and thereby to use implied femininity as an insult. Yes, of course I know some people who aren't female wear panties. Yes, of course I know some women wear underwear that isn't panties. Don't try to change the topic with absurd logical extremes that I didn't raise. I'm talking about the implication of the comment as a gendered insult. > It's only gender specific if you accept the sexist gendered stereotype > that all women are by definition thin-skinned and excessively > sensitive. Bullshit. I said nothing about the sensitivity of anyone. Individual women you may know – even *all* women, everywhere – could be as tough as nails, and it doesn't address the point I'm raising. Whether any particular woman is targeted or not, the comment I'm responding to invokes female gender as an implied insult. That's unwelcoming to women, and I don't want such unwelcoming attitudes in this community. -- \ “Too many pieces of music finish too long after the end.” —Igor | `\ Stravinskey | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Is nan in (nan,) correct?
Ethan Furman writes: > On 03/05/2015 06:55 PM, Ben Finney wrote: > > > class NullType(object): > > """ A type whose value never equals any other. > > > > This type's values will behave correctly when tested for > > membership in a collection:: > > > > >>> foo = NullType() > > >>> bar = NullType() > > >>> foo is foo > > True > > >>> foo is bar > > False > > >>> foo == foo > > False > > >>> foo == bar > > False > > >>> quux = [foo, "spam"] > > >>> "spam" in quux > > True > > >>> foo in quux > > True > > Did you mean False here? Because True is current behavior. Isn't the point at issue that the Python interpreter *may* optimise by assuming ‘is implies equality’, so the ‘in’ operator can fail if that assumption is false? I thought the problem was that types with custom behaviour, as with the ‘NullType’ example, needed to deal specially with the ‘is implies equality’ optimisation Steven explained. If that's the correct behaviour, and we can *depend* on it being correct, then I don't see what the problem is. -- \ “What I have to do is see, at any rate, that I do not lend | `\ myself to the wrong which I condemn.” —Henry Thoreau, _Civil | _o__)Disobedience_ | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: HELP!! How to ask a girl out with a simple witty Python code??
On Fri, Mar 6, 2015 at 2:23 PM, Ben Finney wrote:
> Steven D'Aprano writes:
>
>> Ben Finney wrote:
>>
>> > “get their panties all up in a bunch” is a gendered slur.
>>
>> Why do you interpret that as insulting to women merely on the basis of
>> being *female*?
>
> I think your question is in bad faith. You know as well as I do, and I'm
> confident the person who wrote the slur knows, that “panties” strongly
> connotes *female* underwear.
Allow me to summarize this subthread:
* sohcahtoa makes a comment implying that this list is full of nerds
who know nothing about dating. Gender-nonspecific and most likely
self-deprecating as much as insulting.
* I responded with a reference to a nerdy movie ("Real Genius", and if
you haven't seen it, go grab it - it's funny), which perhaps was not
recognized, leading to the post in which:
* sohcahtoa misunderstands me and thinks I was offended at his post
(which I wasn't), and gets his hackles up, thinking the original
nerd-dating-advice comment shouldn't have been offensive
* Two people then go back and forth about whether or not the previous
three posts were offensive.
The whole field of getting vicariously offended is a mess. It's
virtually impossible to judge what will and what will not cause
offense (sure, there are some easy cases, and if you use a six-letter
word beginning with "n" to refer to someone with more skin melanin
than yourself, then you will be very rightly shouted down - but most
cases aren't anything like that clear, and even that word wasn't
originally offensive in itself), and we have interminable debates
about what should and shouldn't be said. Can we please keep these
sub-threads short? Once it's gone through a couple of rounds of
response, it's not going to get anywhere new. All we have is people
getting annoyed on behalf of an unspecified person or group of people,
and offense being given and taken and regifted like Christmas presents
from your distant relatives. I'm sure there's something more
interesting to talk about... like the rate at which the grass is
growing.
Thanks!
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Is nan in (nan,) correct?
On 03/05/2015 07:26 PM, Ben Finney wrote: > Ethan Furman writes: > >> On 03/05/2015 06:55 PM, Ben Finney wrote: >> >>> class NullType(object): >>> """ A type whose value never equals any other. >>> >>> This type's values will behave correctly when tested for >>> membership in a collection:: >>> >>> >>> foo = NullType() >>> >>> bar = NullType() >>> >>> foo is foo >>> True >>> >>> foo is bar >>> False >>> >>> foo == foo >>> False >>> >>> foo == bar >>> False >>> >>> quux = [foo, "spam"] >>> >>> "spam" in quux >>> True >>> >>> foo in quux >>> True >> >> Did you mean False here? Because True is current behavior. > > Isn't the point at issue that the Python interpreter *may* optimise by > assuming ‘is implies equality’, so the ‘in’ operator can fail if that > assumption is false? No, it's not a /may/, it's a /does/, and that it can be optimized is a bonus. > I thought the problem was that types with custom behaviour, as with the > ‘NullType’ example, needed to deal specially with the ‘is implies > equality’ optimisation Steven explained. The NaN-type objects cannot deal with it directly, as that behavior is in the container. > If that's the correct behaviour, and we can *depend* on it being > correct, then I don't see what the problem is. Well, we can depend on it for native Python types -- but if you write your own container, along with your own __contains__, then you might unwittingly do `for item in self.container: if item == target: return True` and then NaN (or NullType, or what-have-you) would not work "correctly" [1] for your container. -- ~Ethan~ [1] Otherwise known as: how Python does it. signature.asc Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Is nan in (nan,) correct?
On Fri, Mar 6, 2015 at 2:26 PM, Ben Finney wrote: > Isn't the point at issue that the Python interpreter *may* optimise by > assuming ‘is implies equality’, so the ‘in’ operator can fail if that > assumption is false? > > I thought the problem was that types with custom behaviour, as with the > ‘NullType’ example, needed to deal specially with the ‘is implies > equality’ optimisation Steven explained. > > If that's the correct behaviour, and we can *depend* on it being > correct, then I don't see what the problem is. I'm not sure it's just an optimization. Compare this post from python-dev, where Nick Coghlan discusses the same topic: https://mail.python.org/pipermail/python-dev/2014-July/135476.html ChrisA -- https://mail.python.org/mailman/listinfo/python-list
How fast does your grass grow? [was Re: HELP!! How to ask a girl out with a simple witty Python code??]
On 03/05/2015 07:37 PM, Chris Angelico wrote: > I'm sure there's something more interesting to talk about... like the > rate at which the grass is growing. My grass doesn't grow -- I ripped it all out and put down pea-gravel and planter boxes. Oh, wait, I have some bamboo in the back -- that's a grass, isn't it? Hmmm, well, it grows fast enough that my dogs haven't managed to eat it gone yet. :) -- ~Ethan~ signature.asc Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
Re: HELP!! How to ask a girl out with a simple witty Python code??
On 06/03/2015 03:23, Ben Finney wrote: Steven D'Aprano writes: Ben Finney wrote: “get their panties all up in a bunch” is a gendered slur. Why do you interpret that as insulting to women merely on the basis of being *female*? I think your question is in bad faith. You know as well as I do, and I'm confident the person who wrote the slur knows, that “panties” strongly connotes *female* underwear. It seems to me that far from challenging sexual stereotypes, mainstream feminist thought actually *reinforces* it: as evidence, you assumed that only women wear panties, therefore any reference to panty-wearing is therefore a slur on women. No. I'm saying that it's clear the person saying “get their panties all up in a bunch” fully intends to convey specifically *female* underwear, and thereby to use implied femininity as an insult. Yes, of course I know some people who aren't female wear panties. Yes, of course I know some women wear underwear that isn't panties. Don't try to change the topic with absurd logical extremes that I didn't raise. I'm talking about the implication of the comment as a gendered insult. It's only gender specific if you accept the sexist gendered stereotype that all women are by definition thin-skinned and excessively sensitive. Bullshit. I said nothing about the sensitivity of anyone. Individual women you may know – even *all* women, everywhere – could be as tough as nails, and it doesn't address the point I'm raising. Whether any particular woman is targeted or not, the comment I'm responding to invokes female gender as an implied insult. That's unwelcoming to women, and I don't want such unwelcoming attitudes in this community. I'd rather be reading about the 4,773 open issues on the bug tracker. As I consider this rather more important than some completely tangential load of cobblers, would you and MR D'Aprano be kind enough to go and have your 12, 3 minute rounds elsewhere, thanks? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Is nan in (nan,) correct?
On Thu, Mar 5, 2015, at 22:49, Chris Angelico wrote: > I'm not sure it's just an optimization. Compare this post from > python-dev, where Nick Coghlan discusses the same topic: > > https://mail.python.org/pipermail/python-dev/2014-July/135476.html If it is a bug for NaN to "infect" containers' behavior, we need to take a serious look at sort(). -- https://mail.python.org/mailman/listinfo/python-list
Re: Is nan in (nan,) correct?
On 06/03/2015 04:37, random...@fastmail.us wrote: On Thu, Mar 5, 2015, at 22:49, Chris Angelico wrote: I'm not sure it's just an optimization. Compare this post from python-dev, where Nick Coghlan discusses the same topic: https://mail.python.org/pipermail/python-dev/2014-July/135476.html If it is a bug for NaN to "infect" containers' behavior, we need to take a serious look at sort(). I entirely agree. With the extremely serious bug that was reported (and fixed) just a few days ago in the Python sorting algorithm and/or code, it is quite clear to me that it probably needs a major rethink. After you :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Newbie question about text encoding
On Thursday, March 5, 2015 at 7:36:32 PM UTC+5:30, Steven D'Aprano wrote: > Rustom Mody wrote: > > > On Wednesday, March 4, 2015 at 10:25:24 AM UTC+5:30, Chris Angelico wrote: > >> On Wed, Mar 4, 2015 at 3:45 PM, Rustom Mody wrote: > >> > > >> > It lists some examples of software that somehow break/goof going from > >> > BMP-only unicode to 7.0 unicode. > >> > > >> > IOW the suggestion is that the the two-way classification > >> > - ASCII > >> > - Unicode > >> > > >> > is less useful and accurate than the 3-way > >> > > >> > - ASCII > >> > - BMP > >> > - Unicode > >> > >> How is that more useful? Aside from storage optimizations (in which > >> the significant breaks would be Latin-1, UCS-2, and UCS-4), the BMP is > >> not significantly different from the rest of Unicode. > > > > Sorry... Dont understand. > > Chris is suggesting that going from BMP to all of Unicode is not the hard > part. Going from ASCII to the BMP part of Unicode is the hard part. If you > can do that, you can go the rest of the way easily. Depends where the going is starting from. I specifically names Java, Javascript, Windows... among others. Here's some quotes from the supplementary chars doc of Java http://www.oracle.com/technetwork/articles/javase/supplementary-142654.html | Supplementary characters are characters in the Unicode standard whose code | points are above U+, and which therefore cannot be described as single | 16-bit entities such as the char data type in the Java programming language. | Such characters are generally rare, but some are used, for example, as part | of Chinese and Japanese personal names, and so support for them is commonly | required for government applications in East Asian countries... | The introduction of supplementary characters unfortunately makes the | character model quite a bit more complicated. | Unicode was originally designed as a fixed-width 16-bit character encoding. | The primitive data type char in the Java programming language was intended to | take advantage of this design by providing a simple data type that could hold | any character Version 5.0 of the J2SE is required to support version 4.0 | of the Unicode standard, so it has to support supplementary characters. My conclusion: Early adopters of unicode -- Windows and Java -- were punished for their early adoption. You can blame the unicode consortium, you can blame the babel of human languages, particularly that some use characters and some only (the equivalent of) what we call words. Or you can skip the blame-game and simply note the fact that large segments of extant code-bases are currently in bug-prone or plain buggy state. This includes not just bug-prone-system code such as Java and Windows but seemingly working code such as python 3. > > I mostly agree with Chris. Supporting *just* the BMP is non-trivial in UTF-8 > and UTF-32, since that goes against the grain of the system. You would have > to program in artificial restrictions that otherwise don't exist. Yes UTF-8 and UTF-32 make most of the objections to unicode 7.0 irrelevant. Large segments of the > > UTF-16 is different, and that's probably why you think supporting all of > Unicode is hard. With UTF-16, there really is an obvious distinction > between the BMP and the SMP: that's where you jump from a single 2-byte > unit to a pair of 2-byte units. But that distinction doesn't exist in UTF-8 > or UTF-32: > > - In UTF-8, about 99.8% of the BMP requires multiple bytes. Whether you > support the SMP or not doesn't change the fact that you have to deal > with multi-byte characters. > > - In UTF-32, everything is fixed-width whether it is in the BMP or not. > > In both cases, supporting the SMPs is no harder than supporting the BMP. > It's only UTF-16 that makes the SMP seem hard. > > Conclusion: faulty implementations of UTF-16 which incorrectly handle > surrogate pairs should be replaced by non-faulty implementations, or > changed to UTF-8 or UTF-32; incomplete Unicode implementations which assume > that Unicode is 16-bit only (e.g. UCS-2) are obsolete and should be > upgraded. Imagine for a moment a thought experiment -- we are not on a python but a java forum and please rewrite the above para. Are you addressing the vanilla java programmer? Language implementer? Designer? The Java-funders -- earlier Sun, now Oracle? > > Wrong conclusion: SMPs are unnecessary and unneeded, and we need a new > standard that is just like obsolete Unicode version 1. > > Unicode version 1 is obsolete for a reason. 16 bits is not enough for even > existing languages, let alone all the code points and characters that are > used in human communication. > > > >> Also, the expansion from 16-bit was back in Unicode 2.0, not 7.0. Why > >> do you keep talking about 7.0 as if it's a recent change? > > > > It is 2015 as of now. 7.0 is the current standard. > > > > The need for the adjective 'current' should be pondered upon. > > What's your point? >
Re: Newbie question about text encoding
On Fri, Mar 6, 2015 at 3:53 PM, Rustom Mody wrote: > My conclusion: Early adopters of unicode -- Windows and Java -- were punished > for their early adoption. You can blame the unicode consortium, you can > blame the babel of human languages, particularly that some use characters > and some only (the equivalent of) what we call words. > > Or you can skip the blame-game and simply note the fact that large segments of > extant code-bases are currently in bug-prone or plain buggy state. For most of the 1990s, I was writing code in REXX, on OS/2. An even earlier adopter, REXX didn't have Unicode support _at all_, but instead had facilities for working with DBCS strings. You can't get everything right AND be the first to produce anything. Python didn't make Unicode strings the default until 3.0, but that's not Unicode's fault. > This includes not just bug-prone-system code such as Java and Windows but > seemingly working code such as python 3. > > Here is Roy's Smith post that first started me thinking that something may > be wrong with SMP > https://groups.google.com/d/msg/comp.lang.python/loYWMJnPtos/GHMC0cX_hfgJ > > Some parts are here some earlier and from my memory. > If details wrong please correct: > - 200 million records > - Containing 4 strings with SMP characters > - System made with python and mysql. SMP works with python, breaks mysql. > So whole system broke due to those 4 in 200,000,000 records > > I know enough (or not enough) of unicode to be chary of statistical > conclusions > from the above. > My conclusion is essentially an 'existence-proof': Hang on hang on. Why are you blaming Python or SMP characters for this? The problem here is MySQL, which doesn't adequately cope with the full Unicode range. (Or, didn't then, or doesn't with its default settings. I believe you can configure current versions of MySQL to work correctly, though I haven't actually checked. PostgreSQL gets it right, that's good enough for me.) > SMP-chars can break systems. > The breakage is costly-fied by the combination > - layman statistical assumptions > - BMP → SMP exercises different code-paths Broken systems can be shown up by anything. Suppose you have a program that breaks when it gets a NUL character (not unknown in C code); is the fault with the Unicode consortium for allocating something at codepoint 0, or the code that can't cope with a perfectly normal character? > You could also choose do with "astral crap" (Roy's words) what we all do with > crap -- throw it out as early as possible. There's only one character that fits that description, and that's 1F4A9. Everything else is just "astral characters", and you shouldn't have any difficulties with them. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: [Python 3.4] Rationale for readonly slice data attributes
On Thu, Mar 5, 2015 at 4:57 PM, Mario Figueiredo wrote: > What is the rationale behind making the slice class data attributes > readonly? > > I've built a __getitem__ method for a Map class that contains a list > of Cell instance objects. __getitem__ maps this list into a matrix:: > > # get cell at cartesian coordinates 12, 4 > # will map to the 1048th position in the cells list > mmap = Map() > print(mmap[12, 4]) > > All is working well and it even supports slicing:: > > # return all cells with x between 3 and 6 and y up until 4 > mmap = Map() > [print(cell) for cell in mmap(3:6, :4)] > > This last example is one case in which I missed the ability to change > the the `start` and `stop` attributes of the slice class in order for > the maping to occur that allows a 2-dimensions access to a 1-dimension > list. I'm not following what it is that you want to accomplish in this example by modifying the slice object. > It was solved by taking another turn, but it proved to me that the > slice data attributes are more useful if they are writable, and this > clashes tremendously with the principles of data encapsulation that > underline the requirements for a readonly property. In other words, if > it needs to be accessed, don't hide it. If it needs to be written, > don't lock it. > > Now, normally I take these things for granted. Rules are rules and > their reasons are often fairly obvious. But in this case I'm at loss. > I can't find a reason for this class attributes to have been made into > readonly properties. You also can't mutate bound methods, range objects, or ints. Do any of those bother you? Immutable types are often desirable because they're easier to reason about, especially when concurrency enters the picture. As an example, suppose I'm iterating over a view constructed by slicing some collection. What should happen if the slice is suddenly altered in mid-iteration? Because slice objects are immutable, this is a question that doesn't even need an answer. slice is about as light-weight a class as they come. If you need to modify a slice, is there any reason you can't just construct a new one? Lastly, if you really want a mutable "slice", you can work around this by using a 3-element list and construct a slice from it on demand. -- https://mail.python.org/mailman/listinfo/python-list
Speeding up permutations generation
Hi all, Is there a way to generate permutations of large arrays of sizes say,in the hundreds, faster than in the time itertools.permutations() can return? -Abhiram.R *~Never give up* -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
On 01.03.2015 03:43, Chris Angelico wrote: > Imagine if all > your Python code ran twice as fast (that's slightly better than the > IronPython figure quoted!), but worked only on BSD Unix and Mac OS. Is > that something that'll make a fledgling language succeed? I heard that Swift and Objective-C are quite popular these days. regards, jwi -- https://mail.python.org/mailman/listinfo/python-list
Re: HELP!! How to ask a girl out with a simple witty Python code??
Chris Angelico writes: > * Two people then go back and forth about whether or not the previous > three posts were offensive. I called out a specific gendered slur as such. Nothing to do with “offense”, and I made no such claim. > The whole field of getting vicariously offended is a mess. It's a good thing I was not doing that, then. I was calling out an anti-female slur where I saw it. > All we have is people getting annoyed on behalf of an unspecified > person or group of people If you missed the specified group, I'll say it again: Anyone who is female had their gender used as though it were an insult. That's not welcoming to women, and if it goes unchallenged then we give the perception it is acceptable. It is not, so we must say so as clearly as we can. Where people have further misrepresented my complaint or my position, I've necessarily corrected them. Hopefully I've been clear enough that no-one needs to once more impute words or motivations to me that I never expressed. -- \“The number of UNIX installations has grown to 10, with more | `\ expected.” —Unix Programmer's Manual, 2nd Ed., 1972-06-12 | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
