Re: Feeding the trolls
On 21/06/2018 10:05, Anssi Saari wrote: D'Arcy Cain writes: One of these days I will have to figure out how to block replies to the trolls as well. Benefit of reading the mailing list via nntp (i.e. gmane): can easily score down follow-ups to annoying people in addition to their posts. Well, assuming a decent newsreader. I have a decent newsreader (Thunderbird). How do I score down follow-ups to Bart and still see the respondents' other posts? -- https://mail.python.org/mailman/listinfo/python-list
Re: translating foreign data
On 06/21/2018 01:20 PM, Ben Bacarisse wrote: Ethan Furman writes: I need to translate numeric data in a string format into a binary format. I know there are at least two different methods of representing parts less that 1, such as "10.5" and "10,5". The data is encoded using code pages, and can vary depending on the file being read (so I can't rely on current locale settings). I'm sure this is a solved problem, but I'm not finding those solutions. Any pointers? You say "at least two" and give two but not knowing the others will hamper anyone trying to help. (I appreciate that you may not yet know if there are to be any others.) Yes, I don't know if there are others -- I have not studied the various ways different peoples represent decimal numbers. ;) You say in a followup that you don't need to worry about digit grouping marks (like thousands separators) so I'm not sure what the problem is. Can't you just replace ',' with '.' a proceed as if you had only one representation? I could, and that would work right up until a third decimal separator was found. I'd like to solve the problem just once if possible. The code page remark is curious. Will some "code pages" have digits that are not ASCII digits? Good question. I have no idea. I get the appropriate decoder/encoder based on the code page contained in the file, then decode to unicode and go from there. Unfortunately, that doesn't convert the decimal comma to the decimal point. :( So I was hoping to map the code page to a locale that would properly translate the numbers for me, but so far what I have found in my readings suggests that in order to use the locale option I would have to actually change the active locale and potentially mess up every other part of the program when the file in question is opened in a locale that's different from its code page. Worst case scenario is I manually create a map for each code page to decimal separator, but there's more than a few and I'd rather not if there is already a prebuilt solution out there. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Feeding the trolls
What a friendly, welcoming and open-minded group this is! It costs me some genuine effort to make what I believe are relevant and interesting technical posts, and people are discussing not just how to avoid seeing them, but how to screen anyone who wants to reply. Yes my posts are more 'meta' than some would like but that is fitting for such a language. I in the meantime have to wade through reams of Case Solution and Test Bank posts. Guys, get a proper moderated Usenet group then I won't bother with it at all. -- https://mail.python.org/mailman/listinfo/python-list
Re: ironpython not support py3.6
On Thu, 21 Jun 2018 23:44:40 -0700, fantasywangxg wrote: > We have a project implemented with c# and python, iron python is a good > choice for us to integrate these two tech together but iron python not > support python 3.6 yet, any suggest for this? How big is your budget? Could you pay the IronPython developers to build support for 3.6? Probably not... Do you need fully managed .Net code from Python? If not "Python for .Net" may suit: https://pythonnet.github.io/ Either stick to the latest version of IronPython (2.7), or the latest of CPython (3.6). Or maybe you can do both, use IronPython only for the parts that really need C# integration, and use CPython for the rest: C# <--> IronPython 2.7 <--> CPython 3.6 although I suspect that will be even more annoying, complicated and fragile. Have you tried asking this question on an IronPython support forum? -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: Feeding the trolls
On Fri, 22 Jun 2018 01:33:41 -0700, bart4858 wrote: > What a friendly, welcoming and open-minded group this is! You reap what you sow. If you were more interested in appreciating Python for what it is, instead of turning everything into a pissing contest where your personal, private language does it better, your experience might be different. And who knows, you might even learn a thing or two. There's a reason why the Python/Ruby/Lua/Javascript style of languages exists. -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: Feeding the trolls
On 22/06/2018 09:33, [email protected] wrote: It costs me some genuine effort to make what I believe are relevant and interesting technical posts I thank you for at least taking that trouble. But I think that this is probably where the difference lies. This newsgroup/mailing list is primarily for the purpose of asking about or discussing aspects of the Python programming language, not a forum for discussing languages in general. Obviously a genuine enquiry into how or why Python has taken a particular design path can lead to an enlightening discussion on language design. Sometimes as an unexpected spin-off discussion from an original query. But, for the most part Bart, you've failed to understand anyone's design decisions but your own. You've consistently replied in a way that effectively dismisses the various challenges facing this particular language at this particular point in time, and instead have referred to your own design choices and implementations as an exemplar. If you have a genuine interest in how Python is implemented (and not simply in expressing how it is different in some way to your own languages) then please bring it up. If you have a plausible way in which Python could improve then please take it to the Python Ideas list (and be prepared for some robust discussion): https://mail.python.org/mailman/listinfo/python-ideas But if your only goal is to highlight the advantages of your own language and design choices, then please write a blog post, or tweet about it, or take it to some kind of cross-language forum. Thanks TJG -- https://mail.python.org/mailman/listinfo/python-list
Re: translating foreign data
On Fri, 22 Jun 2018 01:43:56 -0700, Ethan Furman wrote: >> You say in a followup that you don't need to worry about digit grouping >> marks (like thousands separators) so I'm not sure what the problem is. >> Can't you just replace ',' with '.' a proceed as if you had only one >> representation? > > I could, and that would work right up until a third decimal separator > was found. I'd like to solve the problem just once if possible. I don't know of any already existing solution, but there's only a limited number of decimal separators in common use around the world. There's probably nothing you can do ahead of time if somebody decides to start using (say) 5 as a decimal separator within Hindi numerals, except cry, but you can probably start by transforming all of the following into decimal points: - interpuct (middle dot) · U+00B7 - comma , - Arabic decimal separator ٫ U+066B https://en.wikipedia.org/wiki/Decimal_separator Those three cover pretty much the whole world, using Hindu-Arabic numerals (1234...) and Eastern Arabic numerals (what the Arabs and Persians use). Other numeral systems seem to have either adopted Arabic numerals, or introduced the decimal point/comma into their own numeral system, or just don't use a decimal place value system. Either way, I expect that the period . plus the three above will cover anything you are likely to find in real data. -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: translating foreign data
Ethan Furman writes: > On 06/21/2018 01:20 PM, Ben Bacarisse wrote: >> You say in a followup that you don't need to worry about digit grouping >> marks (like thousands separators) so I'm not sure what the problem is. >> Can't you just replace ',' with '.' a proceed as if you had only one >> representation? > > I could, and that would work right up until a third decimal separator > was found. I'd like to solve the problem just once if possible. Ah, I see. I took you to mean you knew this won't be an issue. >> The code page remark is curious. Will some "code pages" have digits >> that are not ASCII digits? > > Good question. I have no idea. It's much more of an open question than I thought. My only advice, then, it to ignore problems that *might* arise. Solve the problem you face now and hope that you can extend it as needed. It's good to check if there is an well-known solution ready to use out of the box, but since there really isn't, you might as well get something working now. > I get the appropriate decoder/encoder > based on the code page contained in the file, then decode to unicode > and go from there. It's rather off-topic but what does it mean for the code page to be contained in the file? Are you guessing the character encoding from the rest of the file contents or is there some actual description of the encoding present? > ... I was hoping to map the code page to > a locale that would properly translate the numbers for me, > Worst case scenario is I manually create a map for each code page to > decimal separator, but there's more than a few and I'd rather not if > there is already a prebuilt solution out there. That can't work in general, but you may be lucky with your particular data set. For example, files using one of the "Latin" encodings could have numbers written using the UK convention (0.5) or the French convention (0,5). I do both depending on the audience. -- Ben. -- https://mail.python.org/mailman/listinfo/python-list
Re: Feeding the trolls
On 6/22/18 3:28 AM, Paul St George wrote: > On 21/06/2018 10:05, Anssi Saari wrote: >> D'Arcy Cain writes: >> >>> One of these days I will have to figure out how to block replies to the >>> trolls as well. >> >> Benefit of reading the mailing list via nntp (i.e. gmane): can easily >> score down follow-ups to annoying people in addition to their >> posts. Well, assuming a decent newsreader. >> > > I have a decent newsreader (Thunderbird). How do I score down > follow-ups to Bart and still see the respondents' other posts? First, Thunderbird is really an email program that does Usenet, so actually doesn't quite fall into that catagory, but it can do something like that. Create a filter, the detect side of the filter would be from is Bart, and the filter action would be ignore subthread (that will mark as read any message from Bart and any message that is in reply to one of his). This would actually work from the mailing list too. Many more classically Usenet readers had a 'score' system where you could include various attributes of the usenet message (similar to the Thunderbird filter criteria) and give them a value, and if the filter just used information in the 'overview' of the message (a subset of the headers) and based on the value decide if it wants to download the message. Because Email doesn't provide a similar overview function, email based programs tend not to support this type of filter. It was important for Usenet as it is (or at least was) a much higher volume of information (and noise) system, so it was quite common to pull down only a subset of a group. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: translating foreign data
On Fri, 22 Jun 2018 11:14:59 +0100, Ben Bacarisse wrote: >>> The code page remark is curious. Will some "code pages" have digits >>> that are not ASCII digits? >> >> Good question. I have no idea. > > It's much more of an open question than I thought. Nah, Python already solves that for you: py> s = "১২৩৪৫.৬৭৮৯০" py> for c in s: ... print(unicodedata.name(c)) ... BENGALI DIGIT ONE BENGALI DIGIT TWO BENGALI DIGIT THREE BENGALI DIGIT FOUR BENGALI DIGIT FIVE FULL STOP BENGALI DIGIT SIX BENGALI DIGIT SEVEN BENGALI DIGIT EIGHT BENGALI DIGIT NINE BENGALI DIGIT ZERO py> float(s) 12345.6789 Further to my earlier post, if you call: for sep in ",u\00B7u\066B": mystring = mystring.replace(sep, '.') before passing it to float, that ought to cover just about anything you will find in real-world data regardless of language. If Ethan finds something that isn't covered by those three cases (comma, middle dot and Arabic decimal separator) he'll likely need to consult an expert on that language. Provided Ethan doesn't have to deal with thousands separators as well. Then it gets complicated. -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: translating foreign data
On 6/22/18 4:43 AM, Ethan Furman wrote: > On 06/21/2018 01:20 PM, Ben Bacarisse wrote: > >> The code page remark is curious. Will some "code pages" have digits >> that are not ASCII digits? > > Good question. I have no idea. I get the appropriate decoder/encoder > based on the code page contained in the file, then decode to unicode > and go from there. Unfortunately, that doesn't convert the decimal > comma to the decimal point. :( So I was hoping to map the code page > to a locale that would properly translate the numbers for me, but so > far what I have found in my readings suggests that in order to use the > locale option I would have to actually change the active locale and > potentially mess up every other part of the program when the file in > question is opened in a locale that's different from its code page. > > Worst case scenario is I manually create a map for each code page to > decimal separator, but there's more than a few and I'd rather not if > there is already a prebuilt solution out there. > > -- > ~Ethan~ > One problem is that code page does NOT uniquely define what decimal separator to use (or what locale to use). You can get the decimal separator issue even on files that are pure ASCII, and Latin-1 is full of the issue too. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Feeding the trolls
Steven D'Aprano wrote: == If you were more interested in appreciating Python for what it is, instead of turning everything into a pissing contest where your personal, private language does it better, your experience might be different. And who knows, you might even learn a thing or two. There's a reason why the Python/Ruby/Lua/Javascript style of languages exists. == You're reading too much in my highlighting a number of features from a much smaller language that I believe could be of benefit. Naturally I wouldn't bring up less useful or inferior features. Nor would I bring up the one or two features of Python I've copied. Nor the ones I haven't got round to copying. Nor the ones I can't yet use because they belong in the next category of language. -- Bart -- https://mail.python.org/mailman/listinfo/python-list
Did zip ever used to fail with 0 arguments?
>>> list(zip()) [] I'm not sure why, but I really could've sworn this used to produce something like: TypeError: zip requires at least one argument which is often what I would rather have happen since 0 arguments is a degenerate case. (consider the result of zip(*zip(*args)) for 1+ arguments versus 0 arguments). I looked all through the changelog (including the HISTORY file, which I searched all the way down to the point where zip first became an iterator), but I don't see anything to this effect. Am I crazy? (maybe I am confusing it with another language? But I can hardly even begin to guess how, because Python is more or less the only dynamically-typed language I use!) --- Michael -- https://mail.python.org/mailman/listinfo/python-list
Re: Did zip ever used to fail with 0 arguments?
On Fri, 22 Jun 2018 11:49:15 -0400, Michael Lamparski wrote: list(zip()) > [] > > I'm not sure why, but I really could've sworn this used to produce > something like: > > TypeError: zip requires at least one argument No, you are correct, but you have to go all the way back to Python 2.3 to see that behaviour: https://docs.python.org/2/library/functions.html#zip New in version 2.0. Changed in version 2.4: Formerly, zip() required at least one argument and zip() raised a TypeError instead of returning an empty list. -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
RE: ironpython not support py3.6
Wait. -Original Message- From: [email protected] Sent: Friday, June 22, 2018 2:45 AM To: [email protected] Subject: ironpython not support py3.6 We have a project implemented with c# and python, iron python is a good choice for us to integrate these two tech together but iron python not support python 3.6 yet, any suggest for this? -- https://mail.python.org/mailman/listinfo/python-list
Re: Feeding the trolls
On 22/06/2018 00:51, Steven D'Aprano wrote: On Thu, 21 Jun 2018 21:49:15 +0100, mm0fmf wrote: [snip unnecessary quoting] Design requirements for python newsreader client: 1. Block all top posters I think it would be far more useful to block bottom-posters who don't snip irrelevant quoted text. But the irony of being just as bad a post by quoting all the redundant text would be lost if that was cut and it just bitched about top posting. -- https://mail.python.org/mailman/listinfo/python-list
Re: translating foreign data
Steven D'Aprano writes: > On Fri, 22 Jun 2018 11:14:59 +0100, Ben Bacarisse wrote: > The code page remark is curious. Will some "code pages" have digits that are not ASCII digits? >>> >>> Good question. I have no idea. >> >> It's much more of an open question than I thought. > > Nah, Python already solves that for you: My understanding was that the OP does not (reliably) know the encoding, though that was a guess based on a turn of phrase. Another guess is that the OP does not have Unicode data. The term "code page" hints at an 8-bit encoding or at least a pre-Unicode one. -- Ben. -- https://mail.python.org/mailman/listinfo/python-list
RE: ironpython not support py3.6
Either wait for IronPython 3.6, use COM interop, pythonnet, subprocess, or things like gRPC. Based on PyPy experience, it is probably 1-2 years of sponsored development to get a working IronPython 3.6. -- https://mail.python.org/mailman/listinfo/python-list
Re: translating foreign data
On Fri, 22 Jun 2018 20:06:35 +0100, Ben Bacarisse wrote: > Steven D'Aprano writes: > >> On Fri, 22 Jun 2018 11:14:59 +0100, Ben Bacarisse wrote: >> > The code page remark is curious. Will some "code pages" have digits > that are not ASCII digits? Good question. I have no idea. >>> >>> It's much more of an open question than I thought. >> >> Nah, Python already solves that for you: > > My understanding was that the OP does not (reliably) know the encoding, > though that was a guess based on a turn of phrase. I took it the other way: that Ethan *does* know the encoding, and his problem is that knowing the encoding and/or locale is not enough to recognise whether to use a period or comma as the decimal separator. Which it isn't. If he doesn't know the encoding, he has bigger problems than just converting strings into floats. Without knowing the encoding, he cannot even reliably detect non-ASCII digits at all. > Another guess is that the OP does not have Unicode data. The term "code > page" hints at an 8-bit encoding or at least a pre-Unicode one. Assuming he is using Python 3, or using Python 2 sensibly, once he has specified the encoding and read the data from the file, he has Unicode. Unicode is a superset of (ideally) all code pages. Once you have decoded the data using the appropriate code page, you have a Unicode string, and Python doesn't care where it came from. The point is, once Ethan can get the intended characters out of the file into Python, it doesn't matter what code page they came from. They're now full-fledged Unicode characters, and Python's float() and int() functions can easily deal with non-ASCII digits. So long as he has digits in the first place, float() and int() will deal with them correctly. -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Static variables [was Re: syntax difference]
On Wed, 20 Jun 2018 14:18:19 +1000, Chris Angelico wrote: > Ah. Yeah, that would be a plausible feature to add to Python. But in C, > a static variable is basically the same thing as a global variable, > except that its name is scoped to the function. There is only one of it. > What happens in Python? For instance: > > def f(): > def g(): > static x = 0 > x += 1 > return x > return g > > Does the static variable exist once for each instance of g()? If so, > it'll behave like a closure variable; if not, it'll behave like a > global. Either way, I'm pretty much certain that people will expect the > other. Yes, but given the normal execution model of Python, only one solution is valid. Since the function g is created fresh each time f is called, each one gets a fresh static x. If you want all the g's to share the same x, you would write: def f(): static x = 0 def g(): x += 1 return x return g In this case, every invocation of f shares the same static x, and all the g's refer to that same x, using the ordinary closure mechanism. In the earlier case, each invocation of f creates a brand new g with its own x. Simple and elegant. This could at last get rid of that useful but ugly idiom: def function(real, arguments, len=len, int=int, str=str): ... if we allowed the "static" declaration to access the values from the surrounding scope: def function(real, arguments): static len=len, int=int, str=str But I think nicer than that would be a decorator: @static(len=len, int=int, str=str) def function(real, arguments): ... which adds local variables len, int, str to the function, with the given values, and transforms all the bytecode LOAD_NAME len to LOAD_FAST len (or whatever). (We might need a new bytecode to SET_STATIC.) That would be a nice bytecode hack to prove the usefulness of the concept! -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: Static variables [was Re: syntax difference]
On Sat, Jun 23, 2018 at 1:51 PM, Steven D'Aprano wrote: > On Wed, 20 Jun 2018 14:18:19 +1000, Chris Angelico wrote: > >> Ah. Yeah, that would be a plausible feature to add to Python. But in C, >> a static variable is basically the same thing as a global variable, >> except that its name is scoped to the function. There is only one of it. >> What happens in Python? For instance: >> >> def f(): >> def g(): >> static x = 0 >> x += 1 >> return x >> return g >> >> Does the static variable exist once for each instance of g()? If so, >> it'll behave like a closure variable; if not, it'll behave like a >> global. Either way, I'm pretty much certain that people will expect the >> other. > > Yes, but given the normal execution model of Python, only one solution is > valid. Since the function g is created fresh each time f is called, each > one gets a fresh static x. > > If you want all the g's to share the same x, you would write: > > def f(): > static x = 0 > def g(): > x += 1 > return x > return g > > > In this case, every invocation of f shares the same static x, and all the > g's refer to that same x, using the ordinary closure mechanism. In the > earlier case, each invocation of f creates a brand new g with its own x. > > Simple and elegant. > > This could at last get rid of that useful but ugly idiom: > > def function(real, arguments, len=len, int=int, str=str): > ... > > if we allowed the "static" declaration to access the values from the > surrounding scope: > > def function(real, arguments): > static len=len, int=int, str=str > > But I think nicer than that would be a decorator: > > @static(len=len, int=int, str=str) > def function(real, arguments): > ... > > which adds local variables len, int, str to the function, with the given > values, and transforms all the bytecode LOAD_NAME len to LOAD_FAST len > (or whatever). > > (We might need a new bytecode to SET_STATIC.) > > That would be a nice bytecode hack to prove the usefulness of the concept! > Okay, that makes sense. So in a way, static variables would be like closure variables with an invisible outer function. These would be roughly equivalent: def f(): static x = 0 x += 1 return x def make_f(): x = 0 def f(): nonlocal x x += 1 return x return f f = make_f() I don't think LOAD_FAST is appropriate (those cells get disposed of when the function returns), but transforming those lookups into closure lookups would be a reasonable way to do it I think. For getting rid of the "len=len" trick, though, I would REALLY like to transform those into LOAD_CONST. That'd be a fun bytecode hack all on its own. In fact, I'm gonna have a shot at that. An "early bind these names" decorator. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Static variables [was Re: syntax difference]
On Sat, Jun 23, 2018 at 2:16 PM, Chris Angelico wrote: > For getting rid of the "len=len" trick, though, I would REALLY like to > transform those into LOAD_CONST. That'd be a fun bytecode hack all on > its own. In fact, I'm gonna have a shot at that. An "early bind these > names" decorator. Well, that was easier than I expected. Which almost certainly means I haven't properly solved the problem. https://github.com/Rosuav/shed/blob/master/consts.py Let's start finding all the edge cases that don't work, so I can work on fixing them :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
