Re: building c extensions with setuptools that are not tied to python installed on build machine
Ned, thank you for your insight on this problem. I will take your advice and do some more digging. You've been very helpful. Regards, - Matt Taylor OS Community Flag-Bearer Numenta On Wed, Feb 11, 2015 at 4:23 PM, Ned Deily wrote: > In article > , > Matthew Taylor wrote: >> Does this make sense to anyone? I'm still a little new to Python in >> general (especially binary packaging), and it seems like this would be >> a common problem for any projects with C extensions that need broad >> binary distribution. Does anyone have any suggestions? Please take a >> look at our setup.py file [4] and tell me if we're doing something >> egregiously wrong. > > Just taking a quick look at your setup.py there shows a quite > complicated build, including SWIG. One suggestion: keep in mind that > it's normal on OS X for the absolute path of shared libraries and > frameworks to be embedded in the linked binaries, including the C (or > C++) extension module bundles (.so files) built for Python packages. If > any of the .so files or any other binary artifacts (executables, shared > libraries) created by your package are linked to the Python > interpreter's shared library, that may be why you are getting a mixture > of Python instances. One way to check for this is to use: > > otool -L *.so *.dylib > > on all of the directories containing linked binaries in your project and > check for paths like: > /System/Library/Frameworks/Python.framework > > That would be a link to the Apple-supplied system Python. > > A link to /Library/Frameworks/Python.framework or some other path would > be to a third-party Python like from python.org or Homebrew. > > Due to differences in how the various Pythons are built and depending on > what the C or C++ code is doing, it may not be possible to have one > binary wheel that works with different Python instances of the same > version. For many simple projects, it does work. > > You *could* also ask on the PythonMac SIG list. > > https://mail.python.org/mailman/listinfo/pythonmac-sig > > -- > Ned Deily, > n...@acm.org > > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Python discussed in Nature
"Nature", one of the world's premier science journals, has published an excellent article about programming in Python: http://www.nature.com/news/programming-pick-up-python-1.16833 -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: Python discussed in Nature
On 12/02/2015 08:46, Steven D'Aprano wrote: "Nature", one of the world's premier science journals, has published an excellent article about programming in Python: http://www.nature.com/news/programming-pick-up-python-1.16833 Interesting. I'll leave someone more diplomatic than myself to reply to the comment at the end of the article. -- 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: Python discussed in Nature
On 12.02.2015 10:31, wxjmfa...@gmail.com wrote: [some OT stuffs about unicode] ... what a coincidence then that a huge majority of scientists (including me) dont care AT ALL about unicode. But since scientists are not paid to rewrite old code, the scientific world is still stuck to python 2. It's a pitty, given how easy it is to write py2/py3 compatible scientific tools. Thanks for the link to the article steven! Fabien (sorry for the OT & sorry for feeding the t) -- https://mail.python.org/mailman/listinfo/python-list
Re: Python discussed in Nature
Fabien : > ... what a coincidence then that a huge majority of scientists > (including me) dont care AT ALL about unicode. You shouldn't, any more than you care about ASCII or 2's-complement encoding. Things should just work. > But since scientists are not paid to rewrite old code, the scientific > world is still stuck to python 2. It's a pitty, given how easy it is > to write py2/py3 compatible scientific tools. What's a pity is that Python3 chose to ignore the seamless transition path. It would have been nice, for example, to have all Python 3 code explicitly mark its dialect (a .py3 extension, a magic import or something) and then allow legacy Py2 code and Py3 code coexist the same way C and C++ can coexist. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Python discussed in Nature
On 12.02.2015 12:25, Marko Rauhamaa wrote: Fabien: >... what a coincidence then that a huge majority of scientists >(including me) dont care AT ALL about unicode. You shouldn't, any more than you care about ASCII or 2's-complement encoding. Things should just work. And they do! Since almost one year in writing scientific python code, not a single problem. I wouldnt even know about issues if i didnt read some posts here. >But since scientists are not paid to rewrite old code, the scientific >world is still stuck to python 2. It's a pitty, given how easy it is >to write py2/py3 compatible scientific tools. What's a pity is that Python3 chose to ignore the seamless transition path. It would have been nice, for example, to have all Python 3 code explicitly mark its dialect (a .py3 extension, a magic import or something) and then allow legacy Py2 code and Py3 code coexist the same way C and C++ can coexist. But this was exactly my point! Today in 2015 it's incredibly easy to write py2/py3 code for a scientist. The whole SciPy track has done the transition. Not an issue anymore either, for me at least (python youngster ;-) Fabien -- https://mail.python.org/mailman/listinfo/python-list
Bad text appearance in IDLE
Hello Here is how text appears in IDLE window http://www.cjoint.com/data/0BmnEIcxVAx.htm Yesterday evening I had not this trouble. It appears this morning. I restarted my computer with no effect. A windows Vista update has been done this morning, with about 10 fixes. I suspect something gone wrong with this update Has somebody an explanation about that ? thx -- https://mail.python.org/mailman/listinfo/python-list
Group by interval time
Hello there! I`m trying to group by a list of Row() objects in 12days interval and sum(). values. Here is an example of the list [Row(time=datetime.datetime(2013, 1, 1, 0, 0), sum=4676557380615), Row(time=datetime.datetime(2013, 1, 2, 0, 0), sum=6549630855895), Row(time=datetime.datetime(2013, 1, 3, 0, 0), sum=6549630855895), ...] Row() objects has two vars: row.time and row.sum The result that I`m looking for is: [[datetime.datetime(2013, 1, 1, 0, 0), value], [datetime.datetime(2013, 1, 12, 0, 0), value], [datetime.datetime(2013, 1, 24, 0, 0), value] ] Where value is the sum() of all row.sum in that interval. I`m trying to use itertools.groupby by I could not get it to work yet. Thnak you. -- https://mail.python.org/mailman/listinfo/python-list
Random forest and svm for remote sensing in python
Hi Python Users, Good day! I am currently using ENVI for my image processing/remote sensing work, but would love to divert into open source python programming for remote sensing. Can you give me some good sites where I can see practical examples of how python is used for remote sensing specially using random forest and support vector machine algorithms. Thanks, -Leo -- https://mail.python.org/mailman/listinfo/python-list
Re: Group by interval time
On 2015-02-12 12:34, charles.sart...@gmail.com wrote: Hello there! I`m trying to group by a list of Row() objects in 12days interval and sum(). values. Here is an example of the list [Row(time=datetime.datetime(2013, 1, 1, 0, 0), sum=4676557380615), Row(time=datetime.datetime(2013, 1, 2, 0, 0), sum=6549630855895), Row(time=datetime.datetime(2013, 1, 3, 0, 0), sum=6549630855895), ...] Row() objects has two vars: row.time and row.sum The result that I`m looking for is: [[datetime.datetime(2013, 1, 1, 0, 0), value], [datetime.datetime(2013, 1, 12, 0, 0), value], [datetime.datetime(2013, 1, 24, 0, 0), value] ] Where value is the sum() of all row.sum in that interval. I`m trying to use itertools.groupby by I could not get it to work yet. Try grouping by the number of days since datetime.datetime(2013, 1, 1, 0, 0), integer-divided by 12. -- https://mail.python.org/mailman/listinfo/python-list
Re: Group by interval time
On Thu, 12 Feb 2015 04:34:03 -0800, charles.sartori wrote: > Hello there! > > I`m trying to group by a list of Row() objects in 12days interval and > sum(). values. Here is an example of the list > > [Row(time=datetime.datetime(2013, 1, 1, 0, 0), sum=4676557380615), > Row(time=datetime.datetime(2013, 1, 2, 0, 0), sum=6549630855895), > Row(time=datetime.datetime(2013, 1, 3, 0, 0), sum=6549630855895), ...] > > Row() objects has two vars: row.time and row.sum > > > The result that I`m looking for is: > [[datetime.datetime(2013, 1, 1, 0, 0), value], > [datetime.datetime(2013, 1, 12, 0, 0), value], > [datetime.datetime(2013, 1, 24, 0, 0), value] > ] > Where value is the sum() of all row.sum in that interval. > > I`m trying to use itertools.groupby by I could not get it to work yet. > > Thnak you. what is the code you have tried & what errors are you getting? -- life, n.: A whim of several billion cells to be you for a while. -- https://mail.python.org/mailman/listinfo/python-list
Re: Group by interval time
charles.sart...@gmail.com wrote:
> Hello there!
>
> I`m trying to group by a list of Row() objects in 12days interval and
> sum(). values. Here is an example of the list
>
> [Row(time=datetime.datetime(2013, 1, 1, 0, 0), sum=4676557380615),
> [Row(time=datetime.datetime(2013, 1, 2, 0, 0), sum=6549630855895),
> [Row(time=datetime.datetime(2013, 1, 3, 0, 0), sum=6549630855895), ...]
>
> Row() objects has two vars: row.time and row.sum
>
>
> The result that I`m looking for is:
> [[datetime.datetime(2013, 1, 1, 0, 0), value],
> [datetime.datetime(2013, 1, 12, 0, 0), value],
> [datetime.datetime(2013, 1, 24, 0, 0), value]
> ]
> Where value is the sum() of all row.sum in that interval.
>
> I`m trying to use itertools.groupby by I could not get it to work yet.
If the data is sorted by time then you can use groupby, otherwise consider
putting it into a (default)dict. Here is an example for both methods:
import datetime
import random
from itertools import groupby
from collections import defaultdict, namedtuple
BASEDATE = datetime.datetime(2015, 1, 1)
INTERVAL = 12 # time interval in days
DAYS = datetime.timedelta(days=INTERVAL)
def make_sample_rows():
random.seed(42)
Row = namedtuple("Row", "time sum")
return [
Row(BASEDATE + datetime.timedelta(days=random.randrange(-20, 80)),
random.randrange(300))
for i in range(30)]
def get_key(row):
offset = (row.time - BASEDATE).days // INTERVAL
return BASEDATE + datetime.timedelta(days=offset)
def format_time(time):
return time.strftime("%Y-%m-%d")
if __name__ == "__main__":
rows = make_sample_rows()
# with groupby()
for key, group in groupby(sorted(rows), key=get_key):
print("{} - {}".format(format_time(key), format_time(key+DAYS)))
print("-" * 23)
group = list(group)
for row in group:
print("{} {:4}".format(format_time(row.time), row.sum))
print("{:>15}".format(""))
print("{:15}".format(sum(row.sum for row in group)))
print("")
# with defaultdict
d = defaultdict(int)
for row in rows:
d[get_key(row)] += row.sum
for time, sum in sorted(d.items()):
print("{} {:4}".format(format_time(time), sum))
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python discussed in Nature
Fabien : > But this was exactly my point! Today in 2015 it's incredibly easy to > write py2/py3 code for a scientist. The whole SciPy track has done the > transition. Not an issue anymore either, for me at least (python > youngster ;-) I write both Py2 and Py3 code, but I keep the two worlds hermetically separated from each other. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Group by interval time
Thank you Peter, I was doing wrong at get_key function... Thnak you so much! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python discussed in Nature
On Fri, Feb 13, 2015 at 1:39 AM, Marko Rauhamaa wrote: > Fabien : > >> But this was exactly my point! Today in 2015 it's incredibly easy to >> write py2/py3 code for a scientist. The whole SciPy track has done the >> transition. Not an issue anymore either, for me at least (python >> youngster ;-) > > I write both Py2 and Py3 code, but I keep the two worlds hermetically > separated from each other. One of my students wrote some code for Python 3, and when I went to test it, I typed 'python scriptname' out of habit (most of my students use Py2)... and it almost perfectly worked. The only part that didn't was a class definition that didn't explicitly subclass object, and then used @property. Just changing that class declaration would have made his code 2/3 compatible - and he didn't put any effort into it at all. He literally made his code *accidentally* (almost-)Py2-compatible. You don't need to be afraid of the gap. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Alternative to multi-line lambdas: Assign-anywhere def statements
On Wed, Feb 11, 2015 at 8:56 PM, Chris Angelico wrote:
> On Thu, Feb 12, 2015 at 1:57 PM, Ian Kelly wrote:
>> The reason I don't like this replacing def isn't because the name is
>> necessarily lost. It's because the lack of the well-defined def
>> statement encourages more complex usages like
>>
>> functions['f'] = x -> x**2
>>
>> where such implicit transformations won't work.
>
> That's actually where this started. I mean, if a function can be
> called "", why can't it be called "functions['f']"?
If the name isn't an identifier then it will make it harder to look up
the function from the name via introspection. Another thing that might
cause problems is decoration:
say_hello = classmethod(cls -> print("Hello from %s" % cls.__name__))
How would the name say_hello make it all the way onto the function
object here? I suppose there could be a syntax like:
@classmethod
say_hello = cls -> print("Hello from %s" % cls.__name__)
But now the assignment statement has to be treated grammatically as a
special form of assignment, just like a def statement.
--
https://mail.python.org/mailman/listinfo/python-list
Async/Concurrent HTTP Requests
Hi, I'd like to query two (or more) RESTful APIs concurrently. What is the pythonic way of doing so? Is it better to use built in functions or are third-party packages? Thanks. Best, Ari -- https://mail.python.org/mailman/listinfo/python-list
Odd version scheme
I tried using Interactive Python with a PyQt4 console:
"IPython.exe qtconsole"
But got a
"ImportError: IPython requires PyQT4 >= 4.7, found 4.10.4"
Looking at Ipython's check (in site-packages\IPython\external\qt.py):
if QtCore.PYQT_VERSION_STR < '4.7':
raise ImportError("IPython requires PyQt4 >= 4.7, found
%s"%QtCore.PYQT_VERSION_STR)
So even if '4.10' < '4.7', my '4.10' is newer. What odd version scheme is
this really? I just edited that line to read:
if QtCore.PYQT_VERSION_STR < '4.10':
Seems to be working fine now.
--
--gv
--
https://mail.python.org/mailman/listinfo/python-list
Re: Odd version scheme
On Thu, Feb 12, 2015 at 9:45 AM, Gisle Vanem wrote:
> I tried using Interactive Python with a PyQt4 console:
> "IPython.exe qtconsole"
>
> But got a
> "ImportError: IPython requires PyQT4 >= 4.7, found 4.10.4"
>
> Looking at Ipython's check (in site-packages\IPython\external\qt.py):
> if QtCore.PYQT_VERSION_STR < '4.7':
> raise ImportError("IPython requires PyQt4 >= 4.7, found
> %s"%QtCore.PYQT_VERSION_STR)
>
> So even if '4.10' < '4.7', my '4.10' is newer. What odd version scheme is
> this really? I just edited that line to read:
> if QtCore.PYQT_VERSION_STR < '4.10':
>
> Seems to be working fine now.
There's nothing wrong with the version scheme; 4.10 is a greater
version than 4.7. The problem appears to be IPython using a simple
lexicographical string comparison to compare the version numbers and
failing when it gets to a number that isn't a single digit.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Odd version scheme
On Fri, Feb 13, 2015 at 3:45 AM, Gisle Vanem wrote:
> Looking at Ipython's check (in site-packages\IPython\external\qt.py):
> if QtCore.PYQT_VERSION_STR < '4.7':
> raise ImportError("IPython requires PyQt4 >= 4.7, found
> %s"%QtCore.PYQT_VERSION_STR)
>
> So even if '4.10' < '4.7', my '4.10' is newer. What odd version scheme is
> this really? I just edited that line to read:
> if QtCore.PYQT_VERSION_STR < '4.10':
Looks to me like a fault in comparison format. Normally, you'd expect
that 4.10 follows 4.9 - that is, that the version number is a tuple of
integers - but this is attempting a naive string comparison on it.
Check for an ipython bug tracker and report the matter; that ought to
be fixed.
Bear in mind that your change now means that you're accepting too much
- for instance. '4.6' is not less than '4.10', even though it's
supposed to be rejecting that. Presumably this won't be a problem on
your own system, but for upstream, a more reliable fix will be needed.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python discussed in Nature
Chris Angelico : > On Fri, Feb 13, 2015 at 1:39 AM, Marko Rauhamaa wrote: >> I write both Py2 and Py3 code, but I keep the two worlds hermetically >> separated from each other. > > [...] > > You don't need to be afraid of the gap. No problem. When I write Py3, I write Py3. When I write Py2, I write Py2. When I write bash, I write bash. When I write C, I write C. Who's afraid of the Big Bad Wolf: $ python3 Python 3.4.1 (default, Nov 3 2014, 14:38:10) [GCC 4.9.1 20140930 (Red Hat 4.9.1-11)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.path = [ '/usr/lib64/python2.7' ] + sys.path >>> import re Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python2.7/re.py", line 240 raise TypeError, "first argument must be string or compiled pattern" ^ SyntaxError: invalid syntax >>> import xmllib Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python2.7/xmllib.py", line 813 print 'xml: encoding =',encoding,'standalone =',standalone ^ SyntaxError: invalid syntax Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Python discussed in Nature
On Fri, Feb 13, 2015 at 3:56 AM, Marko Rauhamaa wrote: > $ python3 > Python 3.4.1 (default, Nov 3 2014, 14:38:10) > [GCC 4.9.1 20140930 (Red Hat 4.9.1-11)] on linux > Type "help", "copyright", "credits" or "license" for more information. import sys sys.path = [ '/usr/lib64/python2.7' ] + sys.path Interesting for intellectual curiosity, but not particularly significant. All you prove is that the 2.7 stdlib is designed for compatibility with older 2.x Pythons (or, looking the other way, nobody wants pointless code churn in working code). The best way to write 2/3 compatible code is to write 3.x code first. Then just adhere to a few simple rules (eg always subclass object), and the bulk of your code will work just fine. You might need to toss in some explicit __future__ directives (print_function if you don't stick to "exactly one string argument to print", and division if you don't want to have to worry about the differences), and if you do this a lot, you might want to pick up the 'six' library or equivalent, but other than that, there's really not much to deal with. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Odd version scheme
On 2015-02-12 17:45, Gisle Vanem wrote:
> I tried using Interactive Python with a PyQt4 console:
>"IPython.exe qtconsole"
>
> But got a
>"ImportError: IPython requires PyQT4 >= 4.7, found 4.10.4"
>
> Looking at Ipython's check (in
> site-packages\IPython\external\qt.py): if QtCore.PYQT_VERSION_STR <
> '4.7': raise ImportError("IPython requires PyQt4 >= 4.7, found
> %s"%QtCore.PYQT_VERSION_STR)
>
> So even if '4.10' < '4.7', my '4.10' is newer. What odd version
> scheme is this really? I just edited that line to read:
> if QtCore.PYQT_VERSION_STR < '4.10':'
This looks like it's comparing them as strings. It would be wiser if
the program compared them as version-numbers:
from distutils.version import LooseVersion, StrictVersion
qt_ver = QtCore.PYQT_VERSION_STR
target_ver = "4.10"
for t, desc in [
(str, "String"),
(LooseVersion, "Loose"),
(StrictVersion, "Strict"),
]:
a = t(qt_ver)
b = t(target_ver)
print("Using %s comparison, '%r < %r' is %s" % (
desc, qt_ver, target_ver, a < b)
So the test should actually be something like
if LooseVersion(QtCore.PYQT_VERSION_STR) < LooseVersion("4.10"):
balk()
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Odd version scheme
I believe this sort of lexicographical comparison wart is one of the reasons the Python-dev gang decided that there would be no micro versions > 9. There are too many similar assumptions about version numbers out in the real world. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Odd version scheme
On Fri, Feb 13, 2015 at 4:19 AM, Skip Montanaro wrote: > I believe this sort of lexicographical comparison wart is one of the reasons > the Python-dev gang decided that there would be no micro versions > 9. There > are too many similar assumptions about version numbers out in the real > world. I don't think the policy is quite that strong; 2.7.10 has already been scheduled, and there's sufficient resistance to a Python 4.0 that there's likely to be a 3.10; although some people are saying that it might be worth following 3.9 with 4.0, drop only stuff that's been deprecated for a long time (on par with the disallowing of string exceptions during 2.x), and basically dodge the whole issue. But yes, there's a general feeling that two-digit version components cause trouble, and it's usually easy enough to avoid them. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Odd version scheme
On Thu, Feb 12, 2015 at 10:19 AM, Skip Montanaro wrote: > I believe this sort of lexicographical comparison wart is one of the reasons > the Python-dev gang decided that there would be no micro versions > 9. There > are too many similar assumptions about version numbers out in the real > world. It still becomes an issue when we get to Python 10. -- https://mail.python.org/mailman/listinfo/python-list
Re: Odd version scheme
Tim Chase wrote:> So the test should actually be something like
if LooseVersion(QtCore.PYQT_VERSION_STR) < LooseVersion("4.10"):
balk()
That's exactly what they do now in IPython/utils/version.py with
the comment:
Utilities for version comparison
It is a bit ridiculous that we need these.
Not sure why this is "ridiculous".
I had an "old" version of IPython v0.13 installed! I've upgraded
to v2.10 and all is good.
--
--gv
--
https://mail.python.org/mailman/listinfo/python-list
Re: Odd version scheme
On 2015-02-12 18:37, Gisle Vanem wrote:
> Tim Chase wrote:> So the test should actually be something like
>
> >if LooseVersion(QtCore.PYQT_VERSION_STR) <
> > LooseVersion("4.10"): balk()
>
> That's exactly what they do now in IPython/utils/version.py with
> the comment:
>Utilities for version comparison
>It is a bit ridiculous that we need these.
>
> Not sure why this is "ridiculous".
Well, if you're storing them as strings, then duh, you need the
helper utilities. If you store them as comparable tuples, then it's
not a problem. :-/
# library.VERSION = (3, 14, 15)
if library.VERSION < (2, 3, 18):
complain()
It does become harder to mark things as alpha/beta/pre/rc, but
something Enum-like might suffice for that in a fourth field of the
tuple.
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Async/Concurrent HTTP Requests
On Thu, Feb 12, 2015 at 10:37 AM, Ari King wrote: > Hi, > > I'd like to query two (or more) RESTful APIs concurrently. What is the > pythonic way of doing so? Is it better to use built in functions or are > third-party packages? Thanks. Have a look at asyncio (new in Python 3.4, available for 3.3 as the 'tulip' project) and possibly the aiohttp project, available on PyPI. I'm using both for a current project, and they work very well. -- Zach -- https://mail.python.org/mailman/listinfo/python-list
Re: Async/Concurrent HTTP Requests
Ari King writes: > I'd like to query two (or more) RESTful APIs concurrently. What is the > pythonic way of doing so? Is it better to use built in functions or > are third-party packages? Thanks. The two basic approaches are event-based asynchronous i/o (there are various packages for that) and threads. There are holy wars over which is better. Event-driven i/o in Python 2.x was generally done with callback-based packages like Twisted Matrix (www.twistedmatrix.com). In Python 3 there are some nicer mechanisms (coroutines) so the new asyncio package may be easier to use than Twisted. I haven't tried it yet. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python discussed in Nature
On Thursday, February 12, 2015 at 3:08:10 AM UTC-8, Fabien wrote: > ... what a coincidence then that a huge majority of scientists > (including me) dont care AT ALL about unicode. But since scientists are > not paid to rewrite old code, the scientific world is still stuck to > python 2. I'm a scientist. I'm a happy Python 3 user who migrated from Python 2 about two years ago. And I use Unicode in my Python. In implementing some mathematical models which have variables like delta, gamma, and theta, I decided that I didn't like the line lengths I was getting with such variable names. I'm using δ, γ, and θ instead. It works fine, at least on my Ubuntu Linux system (and what scientist doesn't use Linux?). I also have special mathematical symbols, superscripted numbers, etc. in my program comments. It's easier to read 2x³ + 3x² than 2*x**3 + 3*x**2. I am teaching someone Python who is having a few problems with Unicode on his Windows 7 machine. It would appear that Windows shipped with a less-than-complete Unicode font for its command shell. But that's not Python's fault. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python discussed in Nature
On Fri, Feb 13, 2015 at 5:29 AM, John Ladasky wrote: > It works fine, at least on my Ubuntu Linux system (and what scientist doesn't > use Linux?). I also have special mathematical symbols, superscripted > numbers, etc. in my program comments. It's easier to read 2x³ + 3x² than > 2*x**3 + 3*x**2. > > I am teaching someone Python who is having a few problems with Unicode on his > Windows 7 machine. It would appear that Windows shipped with a > less-than-complete Unicode font for its command shell. But that's not > Python's fault. > Yes, Windows's default terminal/console does have issues. If all your text is staying within the BMP, you may be able to run it within IDLE to get somewhat better results; or PowerShell may help. But as you say, that's not Python's fault. Fortunately, it's not difficult to write a GUI program that manipulates Unicode text, or something that works entirely with files and leaves the display up to something else (maybe a good text editor, or a web browser). All your internals are working perfectly, it's just the human interface that's a bit harder. And only on flawed/broken platforms. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python discussed in Nature
On 02/12/2015 12:46 AM, Steven D'Aprano wrote: > > "Nature", one of the world's premier science journals, has published an > excellent article about programming in Python: > > http://www.nature.com/news/programming-pick-up-python-1.16833 That is a very nice article, thanks for sharing! -- ~Ethan~ signature.asc Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Odd version scheme
On 2015-02-12 17:35, Ian Kelly wrote: On Thu, Feb 12, 2015 at 10:19 AM, Skip Montanaro wrote: I believe this sort of lexicographical comparison wart is one of the reasons the Python-dev gang decided that there would be no micro versions > 9. There are too many similar assumptions about version numbers out in the real world. It still becomes an issue when we get to Python 10. Just call it Python X! :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Async/Concurrent HTTP Requests
Paul Rubin : > Event-driven i/o in Python 2.x was generally done with callback-based > packages like Twisted Matrix (www.twistedmatrix.com). In Python 3 > there are some nicer mechanisms (coroutines) so the new asyncio > package may be easier to use than Twisted. I haven't tried it yet. I have successfully done event-driven I/O using select.epoll() and socket.socket(). Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Async/Concurrent HTTP Requests
Marko Rauhamaa writes: > I have successfully done event-driven I/O using select.epoll() and > socket.socket(). Sure, but then you end up writing a lot of low-level machinery that packages like twisted take care of for you. -- https://mail.python.org/mailman/listinfo/python-list
Re: Odd version scheme
On Thu, Feb 12, 2015 at 11:58 AM, MRAB wrote: > On 2015-02-12 17:35, Ian Kelly wrote: >> >> On Thu, Feb 12, 2015 at 10:19 AM, Skip Montanaro >> wrote: >>> >>> I believe this sort of lexicographical comparison wart is one of the >>> reasons >>> the Python-dev gang decided that there would be no micro versions > 9. >>> There >>> are too many similar assumptions about version numbers out in the real >>> world. >> >> >> It still becomes an issue when we get to Python 10. >> > Just call it Python X! :-) Things break down again when we get to Python XIX. >>> 'XVIII' < 'XIX' False -- https://mail.python.org/mailman/listinfo/python-list
Re: Odd version scheme
On 12/02/2015 19:16, Ian Kelly wrote: On Thu, Feb 12, 2015 at 11:58 AM, MRAB wrote: On 2015-02-12 17:35, Ian Kelly wrote: On Thu, Feb 12, 2015 at 10:19 AM, Skip Montanaro wrote: I believe this sort of lexicographical comparison wart is one of the reasons the Python-dev gang decided that there would be no micro versions > 9. There are too many similar assumptions about version numbers out in the real world. It still becomes an issue when we get to Python 10. Just call it Python X! :-) Things break down again when we get to Python XIX. 'XVIII' < 'XIX' False I believe that this could be solved by borrowing from Mark Pilgrim's excellent "Dive Into Python" which uses (or used?) these hex (?) numbers as the basis for a look at unit testing. -- 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: Odd version scheme
On 2015-02-12 12:16, Ian Kelly wrote: > >> It still becomes an issue when we get to Python 10. > >> > > Just call it Python X! :-) > > Things break down again when we get to Python XIX. > > >>> 'XVIII' < 'XIX' > False You know what this sub-thread gives me? The icks. https://www.youtube.com/watch?v=6DzfPcSysAg -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Async/Concurrent HTTP Requests
Paul Rubin : > Marko Rauhamaa writes: >> I have successfully done event-driven I/O using select.epoll() and >> socket.socket(). > > Sure, but then you end up writing a lot of low-level machinery that > packages like twisted take care of for you. Certainly. It would be nice if the stdlib protocol facilities were event-driven and divorced from the low-level I/O. Asyncio does that, of course, but the programming model feels a bit weird. Twisted documentation seems a bit vague on details. For example, what should one make of this: def write(data): Write some data to the physical connection, in sequence, in a non-blocking fashion. If possible, make sure that it is all written. No data will ever be lost, although (obviously) the connection may be closed before it all gets through. https://twistedmatrix.com/documents/15.0.0/api/twisted.intern et.interfaces.ITransport.html#write> So I'm left wondering if the call will block and if not, how is flow control and buffering managed. The API documentation leads me to a maze of twisted passages, all alike. From what I could gather, the write() method is blocking and hence not suitable for serious work. By contrast, the semantics of Python's socket.send() is crisply defined and a pleasure to work with. Marko -- https://mail.python.org/mailman/listinfo/python-list
fuzzysearch: find not exactly what you're looking for!
Hi everyone,
I'd like to introduce a Python library I've been working on for a
while: fuzzysearch. I would love to get as much feedback as possible:
comments, suggestions, bugs and more are all very welcome!
fuzzysearch is useful for searching when you'd like to find
nearly-exact matches. What should be considered a "nearly matching"
sub-string is defined by a maximum allowed Levenshtein distance[1].
This can be further refined by indicating the maximum allowed number
of substitutions, insertions and/or deletions, each separately.
Here is a basic example:
>>> from fuzzysearch import find_near_matches
>>> find_near_matches('PATTERN', 'aaaPATERNaaa', max_l_dist=1)
[Match(start=3, end=9, dist=1)]
The library supports Python 2.6+ and 3.2+ with a single code base. It
is extensively tested with 97% code coverage. There are many
optimizations under the hood, including custom algorithms and C
extensions implemented in C and Cython.
Install as usual:
$ pip install fuzzysearch
The repo is on github:
https://github.com/taleinat/fuzzysearch
Let me know what you think!
- Tal Einat
.. [1]: http://en.wikipedia.org/wiki/Levenshtein_distance
--
https://mail.python.org/mailman/listinfo/python-list
Re: Floating point "g" format not stripping trailing zeros
> > from decimal import Decimal as D
> > x = D(1)/D(999)
> > '{:.15g}'.format(x)
> >>
> >> '0.00100100100100100'
[...]
> > I'd say it's a bug. P is 15, you've got 17 digits after the decimal place
> > and two of those are insignificant trailing zeros.
>
> Actually it's the float version that doesn't match the documentation.
> In the decimal version, sure there are 17 digits after the decimal
> place there, but the first two -- which are leading zeroes -- would
> not normally be considered significant.
{:.15g} is supposed to give 15 digits of precision, but with trailing
zeros removed. For example, '{:.15g}'.format(Decimal('0.5')) should
yield '0.5', not '0.500' -- and, it indeed does. It is
only for some numbers that trailing zeros are not removed, which looks
like a bug. The behavior of floats matches both the documentation and
other languages using the 'g' decimal format, such as C.
> The float version OTOH is only giving you 13 significant digits when
> 15 were requested.
It is giving 15 significant digits if you count the trailing zeros
that have been removed. If those two digits had not been zeros, they
would have been included. This is again analogous to
'{:.15g}'.format(0.5) returning '0.5'.
--
https://mail.python.org/mailman/listinfo/python-list
Re: fuzzysearch: find not exactly what you're looking for!
On 2/12/2015 11:51 AM, Tal Einat wrote: Hi everyone, I'd like to introduce a Python library I've been working on for a while: fuzzysearch. I would love to get as much feedback as possible: comments, suggestions, bugs and more are all very welcome! I adapt difflib's SequenceMatcher for my fuzzy search needs now -- can you provide some perspective on how fuzzysearch compares? Thanks, Emile -- https://mail.python.org/mailman/listinfo/python-list
Re: Odd version scheme
On 2/12/2015 11:16 AM, Ian Kelly wrote: Things break down again when we get to Python XIX. 'XVIII' < 'XIX' False Looks to me like you better check if your PEP313 patch is installed properly. :) Emile -- https://mail.python.org/mailman/listinfo/python-list
Re: Bad text appearance in IDLE
On 2/12/2015 7:26 AM, ast wrote:
Hello
Here is how text appears in IDLE window
http://www.cjoint.com/data/0BmnEIcxVAx.htm
Do you get anything similar when running the console interpreter?
Yesterday evening I had not this trouble. It appears
this morning. I restarted my computer with no effect.
A windows Vista update has been done this morning, with about 10 fixes.
I suspect something gone wrong with this update
Has somebody an explanation about that ?
Assuming not, the difference between them is that Idle writes to the
screen via a tkinter (tk) text widget. You might try something like
this to see if tkinter is generally not working, even when run without Idle.
import tkinter as tk
root = tk.Tk()
text = tk.Text()
text.pack()
text.insert('1.0', 'this is a test eeeccee')
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: Floating point "g" format not stripping trailing zeros
On Thu, Feb 12, 2015 at 1:23 PM, Hrvoje Nikšić wrote:
>> > from decimal import Decimal as D
>> > x = D(1)/D(999)
>> > '{:.15g}'.format(x)
>> >>
>> >> '0.00100100100100100'
> [...]
>> > I'd say it's a bug. P is 15, you've got 17 digits after the decimal place
>> > and two of those are insignificant trailing zeros.
>>
>> Actually it's the float version that doesn't match the documentation.
>> In the decimal version, sure there are 17 digits after the decimal
>> place there, but the first two -- which are leading zeroes -- would
>> not normally be considered significant.
>
> {:.15g} is supposed to give 15 digits of precision, but with trailing
> zeros removed.
The doc says with "insignificant" trailing zeros removed, not all
trailing zeros.
> For example, '{:.15g}'.format(Decimal('0.5')) should
> yield '0.5', not '0.500' -- and, it indeed does. It is
> only for some numbers that trailing zeros are not removed, which looks
> like a bug. The behavior of floats matches both the documentation and
> other languages using the 'g' decimal format, such as C.
Ah, I see now what's going on here. With floats, there is really no
notion of significant digits. The values 0.5 and 0.5 are
completely equivalent. With decimals, that's not exactly true; if you
give the decimal a trailing zero then you are telling it that the zero
is significant.
>>> Decimal('0.5')
Decimal('0.5')
>>> Decimal('0.5')
Decimal('0.5')
>>> Decimal('0.5').as_tuple()
DecimalTuple(sign=0, digits=(5,), exponent=-1)
>>> Decimal('0.5').as_tuple()
DecimalTuple(sign=0, digits=(5, 0, 0, 0, 0), exponent=-5)
These are distinct; the decimal knows how many significant digits you
passed it. As a result, these are also distinct:
>>> '{:.4g}'.format(Decimal('0.5'))
'0.5'
>>> '{:.4g}'.format(Decimal('0.5'))
'0.5000'
Now what happens in your original example of 1/999? The default
decimal context uses 28 digits of precision, so the result of that
calculation will have 28 significant digits in it.
>>> decimal.getcontext().prec
28
>>> Decimal(1) / Decimal(999)
Decimal('0.001001001001001001001001001001')
When you specify the a precision of 15 in your format string, you're
telling it to take the first 15 of those. It doesn't care that the
last couple of those are zeros, because as far as it's concerned,
those digits are significant.
--
https://mail.python.org/mailman/listinfo/python-list
Download multiple xls files using Python
I was wondering if somebody here could help me out creating a script? I have never done something like this before so I have no idea what I'm doing. But I have been reading about it for a couple days now and I'm still not understanding it so I appreciating all help I can get. I'm even willing to pay for your service! Here is an example of my problem. I have for the moment a CSV file named "Stars" saved on my windows desktop containing around 50.000 different links that directly starts downloading a xls file when pressed. Each row contains one of these links. I would want with your help create some kind of script for this that will make some kind of loop thru each row and visit this different links so it can download these 50.000 different files. Thank you all for taking time to read this / Sarah -- https://mail.python.org/mailman/listinfo/python-list
Download multiple xls files using Python
I was wondering if somebody here could help me out creating a script? I have never done something like this before so I have no idea what I'm doing. But I have been reading about it for a couple days now and I'm still not understanding it so I appreciating all help I can get. I'm even willing to pay for your service! Here is an example of my problem. I have for the moment a CSV file named "Stars" saved on my windows desktop containing around 50.000 different links that directly starts downloading a xls file when pressed. Each row contains one of these links. I would want with your help create some kind of script for this that will make some kind of loop thru each row and visit this different links so it can download these 50.000 different files. Thank you all for taking time to read this / Sarah -- https://mail.python.org/mailman/listinfo/python-list
Re: Download multiple xls files using Python
On Fri, Feb 13, 2015 at 11:07 AM, wrote: > Here is an example of my problem. I have for the moment a CSV file named > "Stars" saved on my windows desktop containing around 50.000 different links > that directly starts downloading a xls file when pressed. Each row contains > one of these links. I would want with your help create some kind of script > for this that will make some kind of loop thru each row and visit this > different links so it can download these 50.000 different files. > Let's break that down into pieces. 1) You have a CSV file, from which you'd like to extract specific data (URLs). 2) You have a series of URLs, which you would like to download. Python can do both of these jobs! The first is best handled by the csv module, and the second by the requests module (which you'd have to get off PyPI). https://docs.python.org/3/library/csv.html http://docs.python-requests.org/en/latest/ In short: Loop over the lines in the file, as returned by the CSV reader, and for each line, fire off a request to fetch its XLS file, and save it to disk. Given that you're working with 50K distinct URLs, you'll want to have some kind of check to see if you already have the file, so you can restart the downloader script. Have fun! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Download multiple xls files using Python
On 2015-02-13 11:19, Chris Angelico wrote: > On Fri, Feb 13, 2015 at 11:07 AM, wrote: > > Here is an example of my problem. I have for the moment a CSV > > file named "Stars" saved on my windows desktop containing around > > 50.000 different links that directly starts downloading a xls > > file when pressed. Each row contains one of these links. I would > > want with your help create some kind of script for this that will > > make some kind of loop thru each row and visit this different > > links so it can download these 50.000 different files. > > In short: Loop over the lines in the file, as returned by the CSV > reader, and for each line, fire off a request to fetch its XLS file, Alternatively, unless you're wed to Python, downloading tools like "wget" are your friend and make quick work of this. Just extract the column of URLs into a file (which can be done in Excel or with any number of utilities such as "cut") and then use "wget" to pull them all down: cut -d, -f3 < data.csv > urls.txt wget -i urls.txt (the above assumes that column #3 contains the URLs) -tkc -- https://mail.python.org/mailman/listinfo/python-list
Parsing and comparing version strings (was: Odd version scheme)
Gisle Vanem writes: > That's exactly what they do now in IPython/utils/version.py with > the comment: > Utilities for version comparison > It is a bit ridiculous that we need these. > > Not sure why this is "ridiculous". Right, versions are effectively a special type [0], specifically *because* they intentionally don't compare as scalar numbers or strings. It's not “ridiculous” to need custom comparisons when that's the case. Python even comes with support for version parsing and comparison in the standard library [1]. So if anything's “ridiculous”, it's the act of re-implementing that and getting it wrong. (Or maybe that such an important part of the standard library is largely undocumented.) [0] https://wiki.python.org/moin/Distutils/VersionComparison> [1] Unfortunately undocumented, like much of the Distutils API. Try http://epydoc.sourceforge.net/stdlib/distutils.version.StrictVersion-class.html>. -- \ “Programs must be written for people to read, and only | `\incidentally for machines to execute.” —Abelson & Sussman, | _o__) _Structure and Interpretation of Computer Programs_ | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Parsing and comparing version strings (was: Odd version scheme)
On 2015-02-13 12:20, Ben Finney wrote:
> > Not sure why this is "ridiculous".
>
> Right, versions are effectively a special type [0], specifically
> *because* they intentionally don't compare as scalar numbers or
> strings. It's not “ridiculous” to need custom comparisons when
> that's the case.
>
> Python even comes with support for version parsing and comparison
> in the standard library [1]. So if anything's “ridiculous”, it's
> the act of re-implementing that and getting it wrong.
>
> (Or maybe that such an important part of the standard library is
> largely undocumented.)
I was surprised (pleasantly) to learn of that corner of distutils,
but can never remember where it is in the stdlib or what it's
called. So it's pretty standard for my process to be something like
- Hmm, I need to compare version-strings
- search the web for "python compare version number"
- note the top-ranked Stack Overflow answer
- spot that it uses distutils.version.{LooseVersion,StrictVersion}
- use that in my code, optionally searching to get full docs with
"site:python.org LooseVersion StrictVersion", only to be
surprised when something like
https://docs.python.org/2/library/{module}
isn't anywhere in the top umpteen hits.
"largely undocumented" is an understatement :-)
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python discussed in Nature
Marko Rauhamaa wrote: > Chris Angelico : > >> On Fri, Feb 13, 2015 at 1:39 AM, Marko Rauhamaa wrote: >>> I write both Py2 and Py3 code, but I keep the two worlds hermetically >>> separated from each other. >> >> [...] >> >> You don't need to be afraid of the gap. > > No problem. When I write Py3, I write Py3. When I write Py2, I write > Py2. When I write bash, I write bash. When I write C, I write C. Do you get confused by the difference between talking to Americans and talking to Britons? The differences between American and British English is a better analogy for the differences between Python 2 and 3 than the differences between C and bash. Especially if you target 2.7 and 3.3+, it is almost trivially easy to write multi-dialect Python 2 and 3 code in the same code base. The trickiest part is not a language change at all, but remembering that the names of some standard library modules have changed. Nobody here is suggesting that there are no differences between Python 2 and 3, but suggesting that those differences are of the same order of magnitude as those between bash and C is ridiculous. The common subset of the Python language is far greater than the differences between the versions. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python discussed in Nature
John Ladasky wrote: > And I use Unicode in my Python. In implementing some mathematical models > which have variables like delta, gamma, and theta, I decided that I didn't > like the line lengths I was getting with such variable names. I'm using > δ, γ, and θ instead. It works fine, at least on my Ubuntu Linux system > (and what scientist doesn't use Linux?). I also have special mathematical > symbols, superscripted numbers, etc. in my program comments. It's easier > to read 2x³ + 3x² than 2*x**3 + 3*x**2. Oooh! What is your font of choice for this? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Odd version scheme
Skip Montanaro wrote: > I believe this sort of lexicographical comparison wart is one of the > reasons the Python-dev gang decided that there would be no micro versions > > 9. There are too many similar assumptions about version numbers out in > the real world. Which is why there will be no Windows 9. Too many bad programmers that test for Windows 95 or 98 by checking the version string and doing a prefix test for "Windows 9". -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python discussed in Nature
On Thursday, February 12, 2015 at 11:59:55 PM UTC+5:30, John Ladasky wrote: > On Thursday, February 12, 2015 at 3:08:10 AM UTC-8, Fabien wrote: > > > ... what a coincidence then that a huge majority of scientists > > (including me) dont care AT ALL about unicode. But since scientists are > > not paid to rewrite old code, the scientific world is still stuck to > > python 2. > > I'm a scientist. I'm a happy Python 3 user who migrated from Python 2 about > two years ago. > > And I use Unicode in my Python. In implementing some mathematical models > which have variables like delta, gamma, and theta, I decided that I didn't > like the line lengths I was getting with such variable names. I'm using δ, > γ, and θ instead. It works fine, at least on my Ubuntu Linux system (and > what scientist doesn't use Linux?). I also have special mathematical > symbols, superscripted numbers, etc. in my program comments. It's easier to > read 2x³ + 3x² than 2*x**3 + 3*x**2. > > I am teaching someone Python who is having a few problems with Unicode on his > Windows 7 machine. It would appear that Windows shipped with a > less-than-complete Unicode font for its command shell. But that's not > Python's fault. Haskell is a bit ahead of python in this respect: Prelude> let (x₁ , x₂) = (1,2) Prelude> (x₁ , x₂) (1,2) >>> (x₁ , x₂) = (1,2) File "", line 1 (x₁ , x₂) = (1,2) ^ SyntaxError: invalid character in identifier But python is ahead in another (arguably more) important aspect: Haskell gets confused by ligatures in identifiers; python gets them right >>> flag = 1 >>> flag 1 Prelude> let flag = 1 Prelude> flag :4:1: Not in scope: `flag' Hopefully python will widen its identifier-chars also -- https://mail.python.org/mailman/listinfo/python-list
Re: Bad text appearance in IDLE
"ast" wrote in message news:54dc9bee$0$3046$426a3...@news.free.fr... > Hello > > Here is how text appears in IDLE window > http://www.cjoint.com/data/0BmnEIcxVAx.htm > > Yesterday evening I had not this trouble. It appears > this morning. I restarted my computer with no effect. > > A windows Vista update has been done this morning, with about 10 fixes. I > suspect something gone wrong with this update > > Has somebody an explanation about that ? > > thx > I use Windows Server 2003. It also ran an automatic update yesterday. Something seems to have gone wrong with the system font. I don't use IDLE, but I use OutlookExpress and Textpad, and they both show a similar effect. I can live with it for now. I am hoping (with fingers crossed) that enough people will complain to Microsoft that they will issue a fix shortly. Frank Millman -- https://mail.python.org/mailman/listinfo/python-list
Re: Python discussed in Nature
On 2/12/2015 11:07 PM, Rustom Mody wrote: On Thursday, February 12, 2015 at 11:59:55 PM UTC+5:30, John Ladasky wrote: On Thursday, February 12, 2015 at 3:08:10 AM UTC-8, Fabien wrote: ... what a coincidence then that a huge majority of scientists (including me) dont care AT ALL about unicode. But since scientists are not paid to rewrite old code, the scientific world is still stuck to python 2. I'm a scientist. I'm a happy Python 3 user who migrated from Python 2 about two years ago. And I use Unicode in my Python. In implementing some mathematical models which have variables like delta, gamma, and theta, I decided that I didn't like the line lengths I was getting with such variable names. I'm using δ, γ, and θ instead. It works fine, at least on my Ubuntu Linux system (and what scientist doesn't use Linux?). I also have special mathematical symbols, superscripted numbers, etc. in my program comments. It's easier to read 2x³ + 3x² than 2*x**3 + 3*x**2. I am teaching someone Python who is having a few problems with Unicode on his Windows 7 machine. It would appear that Windows shipped with a less-than-complete Unicode font for its command shell. But that's not Python's fault. Haskell is a bit ahead of python in this respect: Prelude> let (x₁ , x₂) = (1,2) Prelude> (x₁ , x₂) (1,2) (x₁ , x₂) = (1,2) File "", line 1 (x₁ , x₂) = (1,2) ^ SyntaxError: invalid character in identifier But python is ahead in another (arguably more) important aspect: Haskell gets confused by ligatures in identifiers; python gets them right flag = 1 flag 1 Prelude> let flag = 1 Prelude> flag :4:1: Not in scope: `flag' Hopefully python will widen its identifier-chars also Python (supposedly) follows the Unicode definition based on character classes, as documented. If the Unicode definition in fact allows subscripts, then Python should also. If you want Python to broaden its definition beyond unicode, you will have to advocate and persuade. It will not 'just happen'. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
