Re: Python language hack for C-style programmers [DO NOT USE!] :-)
Chris Angelico wrote:
> On Fri, Mar 28, 2014 at 12:44 PM, Dave Angel wrote:
>>> if (array m = Regexp.split2(some_pattern, some_string))
>>> do_something(m);
>>>
>>
>> I don't know for certain about if, but you can declare (in C++) a
>> new variable in for, which is a superset of if. Scope ends when
>> the for does.
>
> Yeah, but only a for, AFAIK. Not an if or a while.
Why would you guess if you can check? Just fire up the interactive
interpreter^W^W compiler:
$ cat ifdecl.c
#include
int main()
{
if(int i=42)
printf("%d\n", i);
}
$ gcc ifdecl.c
ifdecl.c: In function ‘main’:
ifdecl.c:5:6: error: expected expression before ‘int’
if(int i=42)
^
ifdecl.c:6:20: error: ‘i’ undeclared (first use in this function)
printf("%d\n", i);
^
ifdecl.c:6:20: note: each undeclared identifier is reported only once for
each function it appears in
$ g++ ifdecl.c
$ ./a.out
42
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python language hack for C-style programmers [DO NOT USE!] :-)
On Fri, Mar 28, 2014 at 6:46 PM, Peter Otten <__pete...@web.de> wrote: > Why would you guess if you can check? Just fire up the interactive > interpreter^W^W compiler: Partly because there's a difference between valid C++ and valid input to the G++ compiler :) Knowing that it works with g++ doesn't tell me that it's actually valid, and I don't feel like digging into the specs to find out where you're guaranteed to be allowed to do that. (I could probably test it with one of the language spec options, but then it still depends on the exact version of GCC and the exact spec chosen.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python language hack for C-style programmers [DO NOT USE!] :-)
Chris Angelico wrote:
> On Fri, Mar 28, 2014 at 6:46 PM, Peter Otten <__pete...@web.de> wrote:
>> Why would you guess if you can check? Just fire up the interactive
>> interpreter^W^W compiler:
>
> Partly because there's a difference between valid C++ and valid input
> to the G++ compiler :) Knowing that it works with g++ doesn't tell me
> that it's actually valid, and I don't feel like digging into the specs
> to find out where you're guaranteed to be allowed to do that. (I could
> probably test it with one of the language spec options, but then it
> still depends on the exact version of GCC and the exact spec chosen.)
I don't have the spec handy, only an old copy of "The C++ Programming
Language" which has
"""
To avoid accidental misuse of a variable, it is usually a good idea to
introduce the variable into the smallest scope possible [and] to delay the
definition of a local variable until one can give it an initial value.
[...] One of the most elegant applications of these two principles is to
declare a variable in a condition. Consider:
if (double d = prim(true)) {
left /= d;
break;
}
"""
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python language hack for C-style programmers [DO NOT USE!] :-)
On Fri, Mar 28, 2014 at 7:26 PM, Peter Otten <__pete...@web.de> wrote:
> One of the most elegant applications of these two principles is to
> declare a variable in a condition. Consider:
>
> if (double d = prim(true)) {
> left /= d;
> break;
> }
Okay! Then I withdraw the "or, to my knowledge, C++" part of my
original statement. It's a useful feature, if not a unique one.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Using query parameters subtitution outside of execute()
Hi to all. I'm using sqlite3 with python 2.7 on windows.
I use the query substitution parameters in my query but I need to pass
part of the query to a function, something like (it's not the real
examples, just to clarify the question):
def loadAll(cursor, id, queryAdd = None):
if queryAdd is None:
qry = 'select * from files where catalog = ?'
else:
qry = 'select * from files where catalog = ? and %s' % (queryAdd))
cursor.execute(qry, (id, ))
...
I would like to use the query substitution even when I create, in
another piece of code, the queryAdd part, something like:
queryAdd = cursor.querySubst('enabled = ? and hide = ? and data > ?',
(enabled, hidden, min_date, ))
when the function take care of the date format, quoting the parameter
and so on
It's possible or not ?
Thanks in advance
Daniele Forghieri
--
https://mail.python.org/mailman/listinfo/python-list
Re: meta language to define forms
On Fri, 28 Mar 2014 14:57:11 +1100, Chris Angelico wrote: > On Fri, Mar 28, 2014 at 2:44 PM, Rustom Mody > wrote: >> [BTW I consider the windows registry cleaner than the linux /etc for >> the same reason] > > And if I felt like trolling, I'd point out that there are a lot more > search engine hits for "windows registry cleaner" than "linux etc > cleaner". :) > > ChrisA Not to mention that the windows registry is a Single Point of failure. if it gets corrupt (by 1 minor program crashing whilst writing to it)the chances are your OS is broken to the point of being unfixable. at least with the Linux system (& the multiple config files of windows 3 & earlier) it can normaly be fixed with a simple text editor. -- https://mail.python.org/mailman/listinfo/python-list
Re: Using query parameters subtitution outside of execute()
Daniele Forghieri wrote:
> Hi to all. I'm using sqlite3 with python 2.7 on windows.
>
> I use the query substitution parameters in my query but I need to pass
> part of the query to a function, something like (it's not the real
> examples, just to clarify the question):
>
> def loadAll(cursor, id, queryAdd = None):
> if queryAdd is None:
> qry = 'select * from files where catalog = ?'
> else:
> qry = 'select * from files where catalog = ? and %s' %
> (queryAdd))
>
> cursor.execute(qry, (id, ))
> ...
>
> I would like to use the query substitution even when I create, in
> another piece of code, the queryAdd part, something like:
>
> queryAdd = cursor.querySubst('enabled = ? and hide = ? and data > ?',
> (enabled, hidden, min_date, ))
>
> when the function take care of the date format, quoting the parameter
> and so on
>
> It's possible or not ?
You can use named parameters
http://docs.python.org/dev/library/sqlite3.html#cursor-objects
Your function might become (untested)
def load_all(cursor, parameters, condition="catalog = :id"):
query = 'select * from files where ' + condition
cursor.execute(query, parameters)
...
load_all(
cursor, dict(id=42, fromdate=datetime.date.today()),
condition="catalog = :id and date >= :fromdate")
--
https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On Thu, 27 Mar 2014 20:29:17 -0400, Roy Smith wrote: > In article <5334b747$0$29994$c3e8da3$54964...@news.astraweb.com>, > Steven D'Aprano wrote: > >> On Thu, 27 Mar 2014 08:52:24 -0400, Roy Smith wrote: >> >> > In article , >> > Chris Angelico wrote: >> >> It's not "equally braindead", it follows a simple and logical rule: >> >> Only the day portion is negative. >> > >> > Simple and logical, yes. But also entirely braindead. >> >> Do you think it is "braindead" for __str__ to return something which >> follows the internal representation of the object? > > Yes. The whole idea of OOD is to decouple internal representation from > external behavior. The *whole* idea? You don't think that encapsulation and inheritance might also be involved? *wink* Besides, there's a difference between internal _representation_ and internal _implementation_. I don't always choose my words carefully, but this was one of those times :-) A timedelta object *represents* a delta as (days + seconds + microseconds). That is part of the interface, not implementation. How it is actually implemented is irrelevant. (If I were to take a wild guess, I'd predict that timedeltas record the total number of seconds.) >> > Give ma a real-life situation where you would want such behavior. >> >> Easy -- I'm debugging timedelta routines, and I want to easily see that >> the timedeltas calculated match what I expect them to be when I print >> them. The quickest, easiest and simplest way is for str(timedelta) to >> follow the internal representation. > > That's what __repr__() is for. Actually, __repr__ should, if practical, match the constructor for the object: py> import datetime py> t = datetime.timedelta(2, 3) py> eval(repr(t)) == t True >> Oh look, that's exactly what the docs say: >> >> "String representations of timedelta objects are normalized similarly >> to their internal representation. This leads to somewhat unusual >> results for negative timedeltas." > > Yes, I know that's what the docs say. That's why it's not an > implementation bug. It's a design bug :-) I don't think it is. Given a timedelta object with D days, S seconds and M microseconds, I think that it is a very useful property if the string also says it has D days, S seconds and M microseconds. Would you not agree? I think that this would be silly: str(timedelta(1, 0, 0)) => '0 day, 24:01:-5184000.0' even though it would be correct. So we can dismiss the idea that the str of a timedelta should be free to arbitrarily vary from the internal representation. I consider this to be a useful constraint on timedelta's internal representation (not implementation): the seconds and microseconds should be normalised to the half-open intervals, 0 to 86400 for seconds and 0 to 100 for microseconds. Given that constraint, and the previous constraint that strings should show the same number of days etc., and we have the current behaviour. Both constraints are reasonable. You have to weaken one, or the other, in order to get the result you want. That's not necessarily unreasonable, but neither is it a given. Python-Dev is not normally "braindead", so at least given them the benefit of the doubt that *maybe* there's some good reason we haven't thought of. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Using query parameters subtitution outside of execute()
Il 28/03/2014 10:16, Peter Otten ha scritto:
Daniele Forghieri wrote:
Hi to all. I'm using sqlite3 with python 2.7 on windows.
I use the query substitution parameters in my query but I need to pass
part of the query to a function, something like (it's not the real
examples, just to clarify the question):
def loadAll(cursor, id, queryAdd = None):
if queryAdd is None:
qry = 'select * from files where catalog = ?'
else:
qry = 'select * from files where catalog = ? and %s' %
(queryAdd))
cursor.execute(qry, (id, ))
...
I would like to use the query substitution even when I create, in
another piece of code, the queryAdd part, something like:
queryAdd = cursor.querySubst('enabled = ? and hide = ? and data > ?',
(enabled, hidden, min_date, ))
when the function take care of the date format, quoting the parameter
and so on
It's possible or not ?
You can use named parameters
http://docs.python.org/dev/library/sqlite3.html#cursor-objects
Your function might become (untested)
def load_all(cursor, parameters, condition="catalog = :id"):
query = 'select * from files where ' + condition
cursor.execute(query, parameters)
...
load_all(
cursor, dict(id=42, fromdate=datetime.date.today()),
condition="catalog = :id and date >= :fromdate")
Thank. With this I can solve the problem but I have to specify the
query twice and if I have to change something I need to made it
everywhere I use the function and is something I would like to avoid.
I also don't like very mush to pass or create a dict for a function
call but that's probably me coming from old plain C ;)
Daniele Forghieri
--
https://mail.python.org/mailman/listinfo/python-list
Re: meta language to define forms
On Friday, March 28, 2014 2:34:07 PM UTC+5:30, alister wrote: > On Fri, 28 Mar 2014 14:57:11 +1100, Chris Angelico wrote: > > wrote: > >> [BTW I consider the windows registry cleaner than the linux /etc for > >> the same reason] > > And if I felt like trolling, I'd point out that there are a lot more > > search engine hits for "windows registry cleaner" than "linux etc > > cleaner". :) > > ChrisA > Not to mention that the windows registry is a Single Point of failure. > if it gets corrupt (by 1 minor program crashing whilst writing to it)the > chances are your OS is broken to the point of being unfixable. > at least with the Linux system (& the multiple config files of windows 3 > & earlier) it can normaly be fixed with a simple text editor. This sure used to be true in the windows 95-98 era. I dont believe its been this way for more than a decade. XP onwards there's enough redundancy+fallback+checkpointing so that we rarely really hear of this any more [But Im not a windows guy :-)] On the other hand in linux I find that when something is upgraded and needs to upgrade *its own* config files in /etc it can often have trouble. I trace this to the fact that what is needed is mostly a simple key-value store holding some config parameters. What is stored is usually a general script. As a result http://www.w3.org/2001/tag/doc/leastPower.html kicks in. -- https://mail.python.org/mailman/listinfo/python-list
Re: meta language to define forms
Rustom Mody : > On the other hand in linux I find that when something is upgraded and > needs to upgrade *its own* config files in /etc it can often have > trouble. Linux (service) configuration has given me a lot of grief as well. However, I don't thing anything should need to upgrade config files. The packaging tools leave the old config file in place, which is the right thing. The service had better support the old config file format with no interpretation changes. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: meta language to define forms
On Friday, March 28, 2014 5:44:48 PM UTC+5:30, Marko Rauhamaa wrote: > Rustom Mody wrote: > > On the other hand in linux I find that when something is upgraded and > > needs to upgrade *its own* config files in /etc it can often have > > trouble. > Linux (service) configuration has given me a lot of grief as well. > However, I don't thing anything should need to upgrade config files. Strange thing to say. There may be new config options. The defaults may be altered with good reason. This needs a new file OTOH the user may have his own old altered defaults. So integrating the two is not exactly an easy problem. And what apt does in this case is to drop you into some half-assed interactive (so-called) mode saying some file has changed -- Do you want to keep old, choose new, drop into a shell, or some other half-baked options > The packaging tools leave the old config file in place, which is the > right thing. They dont exactly do that -- see above -- https://mail.python.org/mailman/listinfo/python-list
Re: meta language to define forms
On 3/27/2014 4:56 PM, Sells, Fred wrote: I'm trying to use python classes and members to define complex data entry forms as a meta language The idea is to use a nice clean syntax like Python to define form content, then render it as HTML but only as a review tool for users, The actual rendering would go into a database to let a vendor's tool generate the form in a totally non-standard syntax that's really clunky. I've run into a similar problem when building a framework for programming by speech and web application development. Although, my goals were different. I want to something you can create with speech recognition without too much of a vocal load or requiring extensive/specialized editor changes. One could say I was trying to make it possible to develop web apps in Microsoft Word. :-) The first attempt was a bracketed notation that was in effect a very high level domain specific notation. The next attempt is trying to eliminate the use of bracketing notation to specify scope and said use indentation. Like you, the environment consists of little bits of Python that takes what you want in the form/user interface and generates the HTML and JavaScript for presentation in action. To use your example, my notation would look something like this : Form uses section_title; Enter Patient Vital Signs uses number_question; 3, Enter pulse rate : drop_down_list uses title; Enter current status uses choices; 1, alive and kicking uses choices; 2, comatose uses choices; 3, there's another dead Bishop on the landing The: names refer to the methods that generate the code using the arguments provided by the statements within the: name definition. as refine what is your trying to do, you can make the: names more and more meta-and less and less implementation details. For example, one of the experiences that told me the bracketed notation was not going to fly was when I created a storefront for telescope shop. I created notation that expressed the work of the store not the display of the store information. Obviously the output of the notation was the display data but it operated in a way that the storekeeper understood and could take care of himself which was impossible with ordinary HTML and completely impossible if you added something like bootstrap. And before somebody kicks up a fuss About the notation, let me say that this was aimed at disabled developers who cannot type anymore or who want to listen because they cannot see. What I have created is far more productive and speakable than any of the other systems out there. --- eric -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
In article <533558fa$0$29994$c3e8da3$54964...@news.astraweb.com>, Steven D'Aprano wrote: > > Yes. The whole idea of OOD is to decouple internal representation from > > external behavior. > > The *whole* idea? You don't think that encapsulation and inheritance > might also be involved? *wink* I'm not sure how "decoupling internal representation from external behavior" is substantially different from encapsulation. And, no, I don't think inheritance is a fundamental characteristic of OOD, nudge nudge. -- https://mail.python.org/mailman/listinfo/python-list
Re: meta language to define forms
Rustom Mody : > On Friday, March 28, 2014 5:44:48 PM UTC+5:30, Marko Rauhamaa wrote: >> I don't thing anything should need to upgrade config files. > > Strange thing to say. > There may be new config options. The missing options should default to the old behavior. > The defaults may be altered with good reason. Occasionally, but the reason had better be *really* good. It is like changing a programming API. You live with your bad decisions. > And what apt does in this case is to drop you into some half-assed > interactive (so-called) mode saying some file has changed -- Do you > want to keep old, choose new, drop into a shell, or some other > half-baked options RPM won't overwrite modified config files but just places the new version there next to the old one under a different name (and gives a warning). RPM isn't perfect, but that is the sane thing to do. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
In article , Chris Angelico wrote: > On Sat, Mar 29, 2014 at 12:10 AM, Marko Rauhamaa wrote: > > If encapsulation exists outside OO and inheritance is not key to it, > > what is OO then, a marketing term? > > > > Yep, OO is a marketing term. So's programming - after all, it's just > flipping bits in memory... we only pretend it means anything. Do I > really exist, or do I just think I do? > > ChrisA The real question is, what does this print: c1 = ChrisA() c2 = ChrisA() print c1 == c2 print c2 is c2 -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On Sat, Mar 29, 2014 at 12:22 AM, Roy Smith wrote: > In article , > Chris Angelico wrote: > >> On Sat, Mar 29, 2014 at 12:10 AM, Marko Rauhamaa wrote: >> > If encapsulation exists outside OO and inheritance is not key to it, >> > what is OO then, a marketing term? >> > >> >> Yep, OO is a marketing term. So's programming - after all, it's just >> flipping bits in memory... we only pretend it means anything. Do I >> really exist, or do I just think I do? >> >> ChrisA > > The real question is, what does this print: > > c1 = ChrisA() > c2 = ChrisA() > print c1 == c2 > print c2 is c2 And if you could answer that, you would know whether my mother was right when, in exasperation, she would say "Your design follows the singleton principle!". Okay, so she actually was more likely to say "You are one of a kind!", but it comes to the same thing... ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: implementing download using a url call
Hey Sorry, I should make it more clear. We had a 3rd party that was serving stub builds and they have their URLs on various pages(random sites). We control the sub-domain, so i can send that traffic to wherever I want. I am looking to create logic that takes that incoming parameter and serves an exe file. With the logic I posted, the user gets the file, but also gets a new blank page. I would like to keep the user on the 3rd part website. Hope this clarifies. Thanks -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
In article <871txmwjt4@elektro.pacujo.net>, Marko Rauhamaa wrote: > what is OO then, a marketing term? Sometimes, I think it must be :-) > (It's a different thing, then, that encapsulation and inheritance are > mutually exclusive principles.) There're certainly not mutually exclusive. Mutually exclusive means if you have one, you can't have the other. I think the phrase you're looking for is "orthogonal concepts". You can have either, or both, or neither, and the existence of one doesn't imply anything about the existence of the other. -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On Friday, March 28, 2014 6:52:15 PM UTC+5:30, Roy Smith wrote: > Chris Angelico wrote: > > On Sat, Mar 29, 2014 at 12:10 AM, Marko Rauhamaa wrote: > > > If encapsulation exists outside OO and inheritance is not key to it, > > > what is OO then, a marketing term? > > Yep, OO is a marketing term. So's programming - after all, it's just > > flipping bits in memory... we only pretend it means anything. Do I > > really exist, or do I just think I do? > > ChrisA > The real question is, what does this print: > c1 = ChrisA() > c2 = ChrisA() > print c1 == c2 > print c2 is c2 OO is of course a marketing term Unicode OTOH is the real cure for all diseases Proof by example: Replace the last with print c2 ≡ c2 or even better print c2 ≣ c2 No confusion any more... See? We all know now who (what?) Chris is! -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On Sat, Mar 29, 2014 at 1:35 AM, Steven D'Aprano wrote: > It's difficult to pin-point exactly what characteristics of OOP are > fundamental, but inheritance is surely one of them. I've always understood OOP to be all about binding code and data together (methods as part of an object, rather than functions operating on data) - ie polymorphism, such that you say "do this" and the object knows how its "do this" should be done. That's at least as important as inheritance IMO. But yes, it is very hard to pin it down. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
Roy Smith : > There're certainly not mutually exclusive. Mutually exclusive means if > you have one, you can't have the other. Correct. The classic inheritance diamond: class A(B, C): def add_bean(self): ??? # how to implement class B(D): pass class C(D): pass class D: def __init__(self): self.beans = 0 def add_bean(self): self.beans += 1 def bean_count(self): return self.beans cannot be dealt with without A addressing the common base class D. And once it deals with it, A can be broken by reimplementing C without inheriting it from D: class C: def __init__(self): self.beans = "" def add_bean(self): self.beans += "o" def bean_count(self): return len(self.beans) thus violating encapsulation. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Using query parameters subtitution outside of execute()
Il 28/03/2014 14:53, Peter Otten ha scritto:
Daniele Forghieri wrote:
Il 28/03/2014 10:16, Peter Otten ha scritto:
Daniele Forghieri wrote:
Hi to all. I'm using sqlite3 with python 2.7 on windows.
I use the query substitution parameters in my query but I need to pass
part of the query to a function, something like (it's not the real
examples, just to clarify the question):
def loadAll(cursor, id, queryAdd = None):
if queryAdd is None:
qry = 'select * from files where catalog = ?'
else:
qry = 'select * from files where catalog = ? and %s' %
(queryAdd))
cursor.execute(qry, (id, ))
...
I would like to use the query substitution even when I create, in
another piece of code, the queryAdd part, something like:
queryAdd = cursor.querySubst('enabled = ? and hide = ? and data > ?',
(enabled, hidden, min_date, ))
when the function take care of the date format, quoting the parameter
and so on
It's possible or not ?
You can use named parameters
http://docs.python.org/dev/library/sqlite3.html#cursor-objects
Your function might become (untested)
def load_all(cursor, parameters, condition="catalog = :id"):
query = 'select * from files where ' + condition
cursor.execute(query, parameters)
...
load_all(
cursor, dict(id=42, fromdate=datetime.date.today()),
condition="catalog = :id and date >= :fromdate")
Thank. With this I can solve the problem but I have to specify the
query twice and if I have to change something I need to made it
everywhere I use the function and is something I would like to avoid.
How about that one:
def query_subst(sql, parameters):
return sql, parameters
def load_all(cursor, id, query_add=None):
query = 'select * from files where catalog = ?'
parameters = (id,)
if query_add is not None:
query += " and " + query_add[0]
parameters += query_add[1]
cursor.execute(query, parameters)
...
enabled = True
hidden = False
min_date = datetime.date.today()
query_add = query_subst(
'enabled = ? and hide = ? and date > ?',
(enabled, hidden, min_date))
load_all(cs, 42, query_add)
This one is, IMHO, cleaner and more manageable!
Thank you very very much, I really appreciate your help.
I also don't like very mush to pass or create a dict for a function
call but that's probably me coming from old plain C ;)
Get over it ;)
I'm trying but the old habits comes out, the first time I need
to parse a string I do it like in C, looking at every single char using
a couple of help function: the performance were really horrible, the
memory used was huge than I change the way I do things (and start to use
sqlite3 to store my data instead of using text files, parsed by a
proprietary lib).
The worse is the contrary, when I must use C and I think 'Here
I use a dictionary, at the end convert it in a list that I sort with
that key ...' only to realize that I don't have dictionary and the list
I can use are very less manageable that the ones I used in Python ...
It seems to me that going from C to Python you start writing
inefficient code or write more lines than an average Python programmer
but 'something moves' and the result happens. Moving from Python to C I
always feel like I missed something and the first approach, good for
Python, is simply not working in C ;(
Thanks again
Daniele Forghieri
--
https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
Roy Smith : > I'm not sure how "decoupling internal representation from external > behavior" is substantially different from encapsulation. Yes, that's encapsulation. The idea of encapsulation is older than OO. > And, no, I don't think inheritance is a fundamental characteristic of > OOD, nudge nudge. Inheritance was there with Simula so I think it's high up there with OO. If encapsulation exists outside OO and inheritance is not key to it, what is OO then, a marketing term? (It's a different thing, then, that encapsulation and inheritance are mutually exclusive principles.) Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Using query parameters subtitution outside of execute()
On 2014-03-28, Daniele Forghieri wrote: > The worse is the contrary, when I must use C and I think 'Here > I use a dictionary, at the end convert it in a list that I sort > with that key ...' only to realize that I don't have dictionary > and the list I can use are very less manageable that the ones I > used in Python ... C could provide more friendly general purpose containers in its library, but doesn't. There are some good free ones: glib, for example. Cython provides a really nice in-between level. -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
Re: CentOS 6.5 / SPEC file
Michael Torrie schrieb: > I should add, that the only correct way to package Python 3 on RHEL 6 is > by making the package called "python3" or something that won't collide > with the system Python 2.x package. Another option for Fedora and RHEL6: Software Collections http://developerblog.redhat.com/2014/02/18/migrate-to-python3-w-rhscl/ https://fedorahosted.org/SoftwareCollections/ -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On Sat, Mar 29, 2014 at 12:10 AM, Marko Rauhamaa wrote: > If encapsulation exists outside OO and inheritance is not key to it, > what is OO then, a marketing term? > Yep, OO is a marketing term. So's programming - after all, it's just flipping bits in memory... we only pretend it means anything. Do I really exist, or do I just think I do? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On Fri, 28 Mar 2014 08:30:11 -0400, Roy Smith wrote: > In article <533558fa$0$29994$c3e8da3$54964...@news.astraweb.com>, > Steven D'Aprano wrote: > >> > Yes. The whole idea of OOD is to decouple internal representation >> > from external behavior. >> >> The *whole* idea? You don't think that encapsulation and inheritance >> might also be involved? *wink* > > I'm not sure how "decoupling internal representation from external > behavior" is substantially different from encapsulation. They are mostly unrelated. In the first, you're talking about information hiding. The second, encapsulation, relates to the bundling of code and data, optionally in such a way as to restrict or control access to some or all of the encapsulated data. Encapsulation can be used as a mechanism for information hiding, but need not be. https://en.wikipedia.org/wiki/Encapsulation_%28object-oriented_programming%29 > And, no, I > don't think inheritance is a fundamental characteristic of OOD, nudge > nudge. That's not representative of what most people, and specifically most computer scientists, consider fundamental to OOP. https://en.wikipedia.org/wiki/Object-oriented_programming#Fundamental_features_and_concepts It's difficult to pin-point exactly what characteristics of OOP are fundamental, but inheritance is surely one of them. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: unicode as valid naming symbols
On Thu, Mar 27, 2014, at 11:10, Rustom Mody wrote: > Just out of curiosity how do/did you type that? > When I see an exotic denizen from the unicode-universe I paste it into > emacs and ask "Who are you?" > > But with your 'def' my emacs is going a bit crazy! Your emacs probably is using UCS-2 or UTF-16. The former can't handle characters above 65535 at all, the latter stores them as if they were two characters [so code that's not expecting them will handle them incorrectly] -- https://mail.python.org/mailman/listinfo/python-list
Re: Using query parameters subtitution outside of execute()
Daniele Forghieri wrote:
> Il 28/03/2014 10:16, Peter Otten ha scritto:
>> Daniele Forghieri wrote:
>>
>>> Hi to all. I'm using sqlite3 with python 2.7 on windows.
>>>
>>> I use the query substitution parameters in my query but I need to pass
>>> part of the query to a function, something like (it's not the real
>>> examples, just to clarify the question):
>>>
>>> def loadAll(cursor, id, queryAdd = None):
>>> if queryAdd is None:
>>> qry = 'select * from files where catalog = ?'
>>> else:
>>> qry = 'select * from files where catalog = ? and %s' %
>>> (queryAdd))
>>>
>>> cursor.execute(qry, (id, ))
>>> ...
>>>
>>> I would like to use the query substitution even when I create, in
>>> another piece of code, the queryAdd part, something like:
>>>
>>> queryAdd = cursor.querySubst('enabled = ? and hide = ? and data > ?',
>>> (enabled, hidden, min_date, ))
>>>
>>> when the function take care of the date format, quoting the parameter
>>> and so on
>>>
>>> It's possible or not ?
>> You can use named parameters
>>
>> http://docs.python.org/dev/library/sqlite3.html#cursor-objects
>>
>> Your function might become (untested)
>>
>> def load_all(cursor, parameters, condition="catalog = :id"):
>> query = 'select * from files where ' + condition
>> cursor.execute(query, parameters)
>> ...
>>
>> load_all(
>> cursor, dict(id=42, fromdate=datetime.date.today()),
>> condition="catalog = :id and date >= :fromdate")
>>
>
> Thank. With this I can solve the problem but I have to specify the
> query twice and if I have to change something I need to made it
> everywhere I use the function and is something I would like to avoid.
How about that one:
def query_subst(sql, parameters):
return sql, parameters
def load_all(cursor, id, query_add=None):
query = 'select * from files where catalog = ?'
parameters = (id,)
if query_add is not None:
query += " and " + query_add[0]
parameters += query_add[1]
cursor.execute(query, parameters)
...
enabled = True
hidden = False
min_date = datetime.date.today()
query_add = query_subst(
'enabled = ? and hide = ? and date > ?',
(enabled, hidden, min_date))
load_all(cs, 42, query_add)
> I also don't like very mush to pass or create a dict for a function
> call but that's probably me coming from old plain C ;)
Get over it ;)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 3/27/14 7:34 PM, Steven D'Aprano wrote: > As for enormous number of users who will have > difficulty typing √ in their source code, they certainly don't count! > It's good enough that *you* have a solution to that problem, you can type > alt-v, and anyone who can't simply doesn't matter. You have an interesting point here; more interesting perhaps than you know. We have a unicode system [1] capable of zillions of characters, and most of [us] have some qwerty system keyboard [104 keys?] with meta key mappings for a few more. Talk about the cart before the horse. We need a standard input system not controlled by Microsoft where-by everyone in the entire world can enter unicode (with customization) easily and inexpensively. A unicode keyboard would be nice. Why must everyone in the world be stuck with a U.S. Royal typewriter keyboard for two or three hundred years? Dvorak had the right idea; but it didn't stick (although I have a Dvorak key mapping I use (with emacs) just for fun). I do care, Steven. You'll never ever hear me say "screw" somebody, not because I'm holier than thou, but because everyone counts--everyone. Your point about the biologist is fabulous (my point as well), "I didn't study biology for six years to wash test tubes and program computers, but it comes with the territory". Steven, dude, you proved my point with that. Most biologists (academics particularly) are studying systems that require computers these days--- and the scientists in that field DO want to program computers (I didn't say love) and the "want" is powerful. I didn't say that they "liked it" either. Somehow a biologist needs to be able to talk to that goofy machine (which they hate) and be able to do so efficiently and I dare say rapidly. There needs to be a system for them; general, easy, elegant yet comprehensible, flexible yet unified, discrete, simplified (without being oversimplified). wow. Talk development requirements. marcus [1] http://www.unicode.org/standard/where/ -- https://mail.python.org/mailman/listinfo/python-list
Howto flaten a list of lists was (Explanation of this Python language feature)
On Fri, Mar 21, 2014 at 1:42 PM, vasudevram wrote: >> Can anyone - maybe one of the Python language core team, or someone >> with knowledge of the internals of Python - can explain why this >> code works, and whether the different occurrences of the name x in >> the expression, are in different scopes or not? : >> >> x = [[1,2], [3,4], [5,6]] >> [x for x in x for x in x] > I'll give this +1 for playfulness, and -2 for lack of clarity. > I hope no one thinks this sort of thing is good to do in real-life code. No. This has to be a better way to flatten lists: >>> from functools import reduce >>> import operator as λ >>> reduce(λ.add, l) [1, 2, 3, 4, 5, 6, 7, 8, 9] >>> marcus -- https://mail.python.org/mailman/listinfo/python-list
How to flatten a list of lists was (Explanation of this Python language feature?)
On 3/27/14 6:45 PM, Dan Stromberg wrote: On Fri, Mar 21, 2014 at 1:42 PM, vasudevram wrote: Can anyone - maybe one of the Python language core team, or someone with knowledge of the internals of Python - can explain why this code works, and whether the different occurrences of the name x in the expression, are in different scopes or not? : x = [[1,2], [3,4], [5,6]] [x for x in x for x in x] I'll give this +1 for playfulness, and -2 for lack of clarity. I hope no one thinks this sort of thing is good to do in real-life code. You might try this to flatten a list of lists: >>> from functools import reduce >>> import operator >>> import operator as λ >>> reduce(λ.add, l) [1, 2, 3, 4, 5, 6, 7, 8, 9] >>> marcus -- https://mail.python.org/mailman/listinfo/python-list
To flatten a nested list was (Explanation of this Python language feature? [x for x in x for x in x]
On 3/27/14 6:45 PM, Dan Stromberg wrote: x = [[1,2], [3,4], [5,6]] [x for x in x for x in x] I'll give this +1 for playfulness, and -2 for lack of clarity. I hope no one thinks this sort of thing is good to do in real-life code. You might try this to flatten a list of lists: >>> from functools import reduce >>> L = [[1,2,3],[4,5,6],[7],[8,9]] >>> import operator as λ >>> reduce(λ.add, L) [1, 2, 3, 4, 5, 6, 7, 8, 9] >>> marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Howto flaten a list of lists was (Explanation of this Python language feature)
On 28/03/2014 21:56, Mark H Harris wrote: On Fri, Mar 21, 2014 at 1:42 PM, vasudevram wrote: >> Can anyone - maybe one of the Python language core team, or someone >> with knowledge of the internals of Python - can explain why this >> code works, and whether the different occurrences of the name x in >> the expression, are in different scopes or not? : >> >> x = [[1,2], [3,4], [5,6]] >> [x for x in x for x in x] > I'll give this +1 for playfulness, and -2 for lack of clarity. > I hope no one thinks this sort of thing is good to do in real-life code. Strange, I thought Dan Stromberg wrote the above. No. This has to be a better way to flatten lists: >>> from functools import reduce >>> import operator as λ >>> reduce(λ.add, l) [1, 2, 3, 4, 5, 6, 7, 8, 9] Why reinvent yet another way of flattening lists, particulary one that doesn't use the far more sensible:- from operator import add As for the stupid symbol that you're using, real programmers don't give a damn about such things, they prefer writing plain, simple, boring code that is easy to read. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Howto flaten a list of lists was (Explanation of this Python language feature)
On 3/28/14 5:12 PM, Mark Lawrence wrote:
No. This has to be a better way to flatten lists:
>>> from functools import reduce
>>> import operator as λ
>>> reduce(λ.add, l)
[1, 2, 3, 4, 5, 6, 7, 8, 9]
Why reinvent yet another way of flattening lists, particulary one that
doesn't use the far more sensible:-
{ particularly }
from operator import add
As for the stupid symbol that you're using, real programmers don't give
a damn about such things, they prefer writing plain, simple, boring code
that is easy to read.
:-))as RMS would say, "playful hacking, dude, playful hacking..."
--
https://mail.python.org/mailman/listinfo/python-list
Re: To flatten a nested list was (Explanation of this Python language feature? [x for x in x for x in x]
On Fri, 28 Mar 2014 17:05:15 -0500, Mark H Harris wrote: > You might try this to flatten a list of lists: We got that the first four times you posted it. No need for a fifth. > >>> from functools import reduce > >>> L = [[1,2,3],[4,5,6],[7],[8,9]] > >>> import operator as λ Why would you name the operator module the Greek letter l? Why not the Armenian letter Ւ (yiwn)? That's pure obfuscation. The operator module has nothing to do with "l", and nothing to do with Greek lambda. This is exactly the sort of foolish obfuscation that opponents warned about when Python first introduced support for non-ASCII identifiers. > >>> reduce(λ.add, L) > [1, 2, 3, 4, 5, 6, 7, 8, 9] Furthermore, this is a very inefficient way of flattening a nested list. Doubling the size of the list quadruples the time taken; increasing the size by a factor of 10 increases the time by a factor of more than 100: py> from operator import add py> from functools import reduce py> L = [[1]]*1 py> with Stopwatch(): # code for this available on request ... x = reduce(add, L) ... time taken: 0.348851 seconds py> L = [[1]]*10 py> with Stopwatch(): ... x = reduce(add, L) ... time taken: 41.344467 seconds -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Howto flaten a list of lists was (Explanation of this Python language feature)
Mark, please stop posting to the newsgroup comp.lang.python AND the mailing list python-list@python.org. They mirror each other. Your posts are not so important that we need to see everything twice. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Sat, Mar 29, 2014 at 8:18 AM, Mark H Harris wrote: > We have a unicode system [1] capable of zillions of characters, and most of > [us] have some qwerty system keyboard [104 keys?] with meta key mappings for > a few more. Talk about the cart before the horse. > > We need a standard input system not controlled by Microsoft... ... uhh... how does the QWERTY system demonstrate Microsoft's control?? There's more than a hundred years of gap between them, and in the wrong order. By the way, thanks for telling me what a zillion is. It must be 65536, because that's the biggest thing Unicode gives us plural of in number of characters. :) Considering that we have ten fingers, having 1114112 keys would be quite impractical. The smallest number of keys to render that many characters would probably be 21, but it'd be toggling data into a computer, rather than typing; *every* character would require holding down a good number of keys. (Or you could go the other way and have exactly two keys: 1 and 0. Press either 21 times to enter a single character.) You'd probably need a minimum of several hundred keys to get something reasonably logical. Do you really want a keyboard that takes up that much space? Most people can't efficiently use F1 through F12, much less another hundred or two hundred keys. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Howto flaten a list of lists was (Explanation of this Python language feature)
On 3/28/14 9:33 PM, Steven D'Aprano wrote: Mark, please stop posting to the newsgroup comp.lang.python AND the mailing list python-list@python.org. They mirror each other. Your posts are not so important that we need to see everything twice. Its not my fault, Steven. Something goofy is going on. My address says only comp.lang.python I have no idea why some of these messages are being duplicated on the mailing list. I only post to the news group. Anyways, sorry. I'll keep checking this. regards, -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Sat, 29 Mar 2014 13:45:12 +1100, Chris Angelico wrote: > Considering that we have ten fingers, having 1114112 keys would be quite > impractical. The smallest number of keys to render that many characters > would probably be 21, but it'd be toggling data into a computer, rather > than typing; *every* character would require holding down a good number > of keys. (Or you could go the other way and have exactly two keys: 1 and > 0. Press either 21 times to enter a single character.) http://like-a-boss.org/wp-content/uploads/2011/10/supercoder.jpg -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 3/28/14 9:45 PM, Chris Angelico wrote: On Sat, Mar 29, 2014 at 8:18 AM, Mark H Harris wrote: We have a unicode system [1] capable of zillions of characters, and most of [us] have some qwerty system keyboard [104 keys?] with meta key mappings for a few more. Talk about the cart before the horse. We need a standard input system not controlled by Microsoft... ... uhh... how does the QWERTY system demonstrate Microsoft's control?? There's more than a hundred years of gap between them, and in the wrong order. You know the answer to this question. Does your keyboard have the "Windows" emblem|logo on the meta key(s) on lower right, lower left? On a standard keyboard its the meta key between ctrl and alt. Microsoft has controlled that meta section of the keyboard for years, effectively preventing those keys from being used for unicode meta control keys (ironical considering the fact the Microsoft is a major player at the unicode consortium). The meta keyboard on the mac is much more of what I have in mind, but that's mac only for now. By the way, thanks for telling me what a zillion is. It must be 65536, because that's the biggest thing Unicode gives us plural of in number of characters. :) ha! :-)) A zillion is 65536 x(several thousand languages). Actually I used a zillion because the consortium doesn't even put a number on it... because there is a difference between script and language, and there are many languages that use Latin. The point is its a huge number greater than 128 or 256. (or 104) Considering that we have ten fingers, having 1114112 keys would be quite impractical. don't be literal, think meta pages (key mappings) over the actual keyboard, but think "standards". Do you really want a keyboard that takes up that much space? Most people can't efficiently use F1 through F12, much less another hundred or two hundred keys. No, I want a standard unicode keyboard (a standard specification for a unicode keyboard) that facilitates unicode typing with minimal actual keys and standard key maps for alternate sets that may be easily selected without a mouse and without moving the hands from the home row. The mac does a pretty good job of this now, but the mapping editor is not built-in; otherwise, the key mappings are very good, quite easy, and very fast. But, like Steven pointed out, everyone needs to be on the same unicode input device (as standard) before language specs could relay on certain code points for tokens | identifiers. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Howto flaten a list of lists was (Explanation of this Python language feature)
On Sat, Mar 29, 2014 at 2:04 PM, Mark H Harris wrote: > Its not my fault, Steven. Something goofy is going on. My address says only > comp.lang.python Well, something's causing your messages to come out multiple times and with different subject lines :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Howto flaten a list of lists was (Explanation of this Python language feature)
On Saturday, March 29, 2014 8:34:19 AM UTC+5:30, Mark H. Harris wrote: > On 3/28/14 9:33 PM, Steven D'Aprano wrote: > > Mark, please stop posting to the newsgroup comp.lang.python AND the > > mailing list (...). They mirror each other. Your posts > > are not so important that we need to see everything twice. > Its not my fault, Steven. Something goofy is going on. My address says > only comp.lang.python > I have no idea why some of these messages are being duplicated on the > mailing list. I only post to the news group. > Anyways, sorry. I'll keep checking this. > regards, Just use the amazing, fool-safe, fail-proof google-groups. And enjoy bliss. [Uh... And now I need to run... Out of sprinting practice...] -- https://mail.python.org/mailman/listinfo/python-list
Re: To flatten a nested list was (Explanation of this Python language feature? [x for x in x for x in x]
On 3/28/14 9:31 PM, Steven D'Aprano wrote: On Fri, 28 Mar 2014 17:05:15 -0500, Mark H Harris wrote: >>> from functools import reduce >>> L = [[1,2,3],[4,5,6],[7],[8,9]] >>> import operator as λ >>> reduce(λ.add, L) [1, 2, 3, 4, 5, 6, 7, 8, 9] Furthermore, this is a very inefficient way of flattening a nested list. Again, its just another way. Its just playful hacking. The serious point behind it ( I am able to do anything I want with the language ), I mean that is kinda the whole point. For anyone to actually use my little hack they need to know that reduce is in functools (right) then they need to understand 'reduce' which is a nightmare, and then they need to know why chose the symbol λ (which was for no other reason than fun. Lastly, they would want to flatten a list without [x for x in x for x in x] :) The following is a strawman; YOU build it up, to tear it down/ py> from operator import add py> from functools import reduce py> L = [[1]]*1<=== my list didn't have ten thousand items py> with Stopwatch(): # code for this available on request ... x = reduce(add, L) ... time taken: 0.348851 seconds py> L = [[1]]*10<= much less one hundred thousand items py> with Stopwatch(): ... x = reduce(add, L) ... time taken: 41.344467 seconds < time is an illusion, ask Einstein/ (Steven, it was all tongue in cheek, just for fun... ) -- https://mail.python.org/mailman/listinfo/python-list
Re: Howto flaten a list of lists was (Explanation of this Python language feature)
On 3/28/14 10:21 PM, Chris Angelico wrote: Well, something's causing your messages to come out multiple times and with different subject lines :) I changed the subject line ( which I did twice because the first post said it had an error and did not post; which apparently was a lie). Then I posted again (this time it went without error, but came back duplicated. In any case ONLY the news group was in the to: field. Very strange. All of this crap started happening a couple of days back when Thunderbird updated their client (I should know better than to accept that). Anyway, things were supposed to be better once I switched from gg. uh, huh. Well, at least the line wrapping thing is fixed. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Sat, Mar 29, 2014 at 2:18 PM, Mark H Harris wrote: > On 3/28/14 9:45 PM, Chris Angelico wrote: >> ... uhh... how does the QWERTY system demonstrate Microsoft's >> control?? There's more than a hundred years of gap between them, and >> in the wrong order. > > >You know the answer to this question. Does your keyboard have the > "Windows" emblem|logo on the meta key(s) on lower right, lower left? On a > standard keyboard its the meta key between ctrl and alt. Microsoft has > controlled that meta section of the keyboard for years, effectively > preventing those keys from being used for unicode meta control keys > (ironical considering the fact the Microsoft is a major player at the > unicode consortium). The meta keyboard on the mac is much more of what I > have in mind, but that's mac only for now. No, actually. A lot of my keyboards don't have those, and even those that do aren't controlled by Microsoft. We've been using those for other purposes since they first came out. To claim that they indicate MS control is just as ridiculous as claiming that the Backspace key indicates control from the Remington Typewriter Company. >> By the way, thanks for telling me what a zillion is. It must be 65536, >> because that's the biggest thing Unicode gives us plural of in number >> of characters. :) > > >ha! :-)) A zillion is 65536 x(several thousand languages). Actually I > used a zillion because the consortium doesn't even put a number on it... > because there is a difference between script and language, and there are > many languages that use Latin. The point is its a huge number greater than > 128 or 256. (or 104) > >> >> Considering that we have ten fingers, having 1114112 keys would be >> quite impractical. > > >don't be literal, think meta pages (key mappings) over the actual > keyboard, but think "standards". The Unicode standard specifies only 1114112 possible codepoints, of which only roughly 200K are currently allocated. (And those figures include non-character codepoints, like the U+D800 to U+DFFF range used to encode non-BMP codepoints into UTF-16.) So you can't possibly need any more than that - just over a million - for full Unicode support. That's standards for you. >> Do you really want a keyboard that takes up that much space? Most >> people can't efficiently use F1 through F12, much less another hundred >> or two hundred keys. > >No, I want a standard unicode keyboard (a standard specification for a > unicode keyboard) that facilitates unicode typing with minimal actual keys > and standard key maps for alternate sets that may be easily selected without > a mouse and without moving the hands from the home row. Minimal actual keys. Steven almost got it with the link he posted above, but I can cut one more key off it: if you always press exactly 21 keys to enter one codepoint, you don't need a "Done" key. (But the "Done" key would allow you to type some characters much more quickly. You can send a spew of U+ just by holding Done, for instance; and what an accomplishment THAT is in a family man! [1]) >The mac does a pretty good job of this now, but the mapping editor is not > built-in; otherwise, the key mappings are very good, quite easy, and very > fast. But, like Steven pointed out, everyone needs to be on the same unicode > input device (as standard) before language specs could relay on certain code > points for tokens | identifiers. If that idealized Unicode keyboard were worth doing, it would have been done by now. There are myriad keyboard designs to choose from, like these: http://www.thinkgeek.com/brain/whereisit.cgi?t=keyboard None has the hundreds of keys needed for rapid entry of arbitrary Unicode codepoints or characters (in theory you could have a key that creates a full CCS). Why? Because there's no demand for it. ChrisA [1] Look up Gilbert & Sullivan's "Ruddigore" for a very similar line of argument regarding a sailor. -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Fri, 28 Mar 2014 16:18:25 -0500, Mark H Harris wrote: > We need a standard input system not controlled by Microsoft where-by > everyone in the entire world can enter unicode (with customization) > easily and inexpensively. A unicode keyboard would be nice. Under what circumstances do you see yourself needing a keyboard capable of typing Hindi? I don't wish to pay for a keyboard for entering Arabic when I'm never going to enter more than two or three Arabic characters at a time. If I need to enter an Arabic character, I can use one of many existing virtual keyboards. If I decide to learn Arabic, I will use my current keyboard (perhaps with new keycaps) and switch to a different keyboard layout. I don't think that an English-speaker who needs to occasionally enter a few characters like © ¢ or £, a mathematician who knows TeX, a Russian wanting to type in Cyrillic, and a Japanese writer who needs to swap between four different writing systems (Kanji, Hiragana, Katakana, and Rōmaji) are all going to be well-suited by any one system. I expect that it will end up being one-size-fits-none. > Why must > everyone in the world be stuck with a U.S. Royal typewriter keyboard for > two or three hundred years? You are being patronising to the 94% of the world that is not from the USA. Do you honestly think that people all over the world have been using computers for 30 or 40 years without any way to enter their native language? Before trying to speak for everyone in the world, it would be a good idea to learn something about their situation first. People are not stuck with the US Royal typewriter keyboard. Keyboards are localised all over the world. I'm not just talking about European keyboards mostly similar to US keyboards but with a few customizations. I'm talking about keyboards for entering Chinese and Japanese: http://www.keysourcechina.com/chinese-keyboard.html http://www.stanford.edu/class/cs140/projects/pintos/specs/kbd/jp106.jpg although I'm pretty sure this is a joke: http://propelsteps.boards.net/thread/27/creative-chinese-keyboard-2000-symbols When you install Linux, one of the first things the installer asks you to do is choose a keyboard layout. The choices are *not* just: US Qwerty US Dvorak but one of a large variety of keyboard layouts. On my system, there are a least 95: [root@ando ~]# ls /usr/share/X11/xkb/symbols | wc -l 95 Likely many more, as most of the files contain more than one layout; e.g. the ru file contains 5, the fr file contains 7. On Mac and Windows, locally-bought systems will come pre-configured for the local national language. You can even buy keycaps for some pretty niche use-cases: http://www.maxkeyboard.com/r4-1x1-cherry-mx-chinese-astrology-animal-sign-keycap-set.html although I expect that's more for novelty reasons than anything else. Most languages work quite well with the standard keyboard layout of four rows of keys, plus modifiers and special keys. Japanese and Chinese are probably the two hardest cases (apart from languages that don't even have a writing system!), and even they have solutions to the problem of computer input. (In Japan, many people don't even use Unicode, at least not yet, so your hypothetical solution wouldn't help them one bit.) Virtually all keyboards today have standardized on a similar layout, one with at least three modifier keys (and more commonly four). People with specialized needs can configure their keyboard the way it suits them. There's no need for some dictator or committee to declare that everyone will use this system or that. Historians who need to enter Phoenician characters can do so, the rest of us don't need to worry about them. Relevant: https://en.wikipedia.org/wiki/Space-cadet_keyboard > Dvorak had the right idea; but it didn't > stick (although I have a Dvorak key mapping I use (with emacs) just for > fun). Dvorak is an American English system. There are modified versions to suit other languages with additional characters, but it is essentially *identical* to Qwerty except for the order that the keys appear. Shuffling the order that Latin letters ABC...Z appear on the keyboard is not in any way "the right idea" for entering non-Latin languages, nor does a Dvorak language help enter arbitrary Unicode characters. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 3/28/14 10:51 PM, Steven D'Aprano wrote: Why must everyone in the world be stuck with a U.S. Royal typewriter keyboard for two or three hundred years? You are being patronising to the 94% of the world that is not from the USA. Do you honestly think that people all over the world have been using computers for 30 or 40 years without any way to enter their native language? You think ~sooo three dimensionally. Picture this ~a unicode keyboard with morphing keytops (digital ink, light emitting); a standard layout of keys that are touch sensitive, are meta operative, and are able to input *every* language on earth (as well any symbol). The keyboard may emit light, but not necessarily. The keys may be raised, but not necessarily; they have a glassy feel, soft, sensual, and completely programmable. Code point pages (key top mappings literally) are selectable on|off screen. The keyboard is obviously wireless, and the entire keytopsection is mouse-able; the whole keyboard is a pinting device, with diff sections for scrolling &c. This keyboard will be standard in about 25 years... none exist today. One of the things I do is biblical and classical language support and translation (Latin, Hebrew, and Greek). I do translation work as well as papers, research, &c; I need four full keyboards. I'm getting by fairly well with the macs key mappings, but what I'm really after is the 21st century keyboard I'm dreaming about above. Think, virtual keyboard, on a keytoplayout... but separate from any touchable screen. And, think mac keytops (or flatter) not the plastic IBM typewriter like keyboards of today. Think beyond. marcus -- https://mail.python.org/mailman/listinfo/python-list
Keyboard standards (was: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list))
Mark H Harris writes: > > On Sat, Mar 29, 2014 at 8:18 AM, Mark H Harris > > wrote: > >> We need a standard input system not controlled by Microsoft... > > […] Does your keyboard have the "Windows" emblem|logo on the meta > key(s) on lower right, lower left? No, mine has a Tux logo, because it was shipped that way from Think Penguin https://www.thinkpenguin.com/> and the key you're referring to operates as the “Super” key in GNU+Linux. Quite useful. My desktop keyboard is constructed from the Model M buckling-spring design https://en.wikipedia.org/wiki/IBM_Model_M_keyboard>. That means, among other advantages, that the key caps are designed to be easily replaceable with parts from different manufacturers. Model M keyboards are now manufactured in Lexington, USA by Unicomp http://pckeyboard.com/page/category/UKBD>. They ship internationally, which is how I got mine. Unicomp will happily sell you one in various layouts without the Windows logo. They can even do a key set with the Ctrl and Caps Lock keys swapped to where they should be, and the Super key printed with a “Tux” logo http://pckeyboard.com/page/product/LinTuxSet>. On the inexpensive end, Think Penguin will also happily ship Tux logo stickers to go on top of the Super key https://www.thinkpenguin.com/gnu-linux/tux-super-key-keyboard-sticker>. (I have no affiliation with Think Penguin nor Unicomp, except as a happy repeat customer.) >No, I want a standard unicode keyboard (a standard specification > for a unicode keyboard) that facilitates unicode typing with minimal > actual keys and standard key maps for alternate sets that may be > easily selected without a mouse and without moving the hands from the > home row. I can't help you with that, exactly. However, I type unicode characters with an Input Method engine called IBus https://code.google.com/p/ibus/>, which is now in Gnome https://help.gnome.org/misc/release-notes/3.6/i18n-ibus.html.en> as a standard part of the interface. I can select various IBus input methods depending on the purpose or language for which I'm writing, and they make it predictable and memorable to get the right characters. -- \ “I have yet to see any problem, however complicated, which, | `\ when you looked at it in the right way, did not become still | _o__)more complicated.” —Paul Anderson | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 3/28/14 11:07 PM, Mark H Harris wrote: Think, virtual keyboard, on a keytoplayout... but separate from any touchable screen. And, think mac keytops (or flatter) not the plastic IBM typewriter like keyboards of today. Think beyond. What if~ when I select my UK standard keytop mappings (from my US custom keytop mappings) what if the actual keytops on the keyboard "morphed" into UK tops? Better yes, what if the whole keytopsection could morph into Greek tops? I am able to type in Greek, well I've been doing it for about 12 years, but it would be s much better if the keytopsection actually morphed. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 3/28/14 11:16 PM, Mark H Harris wrote:
I am able to type in Greek, well I've been doing it for about 12 years,
but it would be s much better if the keytopsection actually morphed.
What if, when you opened your new computer in Botswana, and you selected
your language in gnu/linux lang setup, and your standard unicode
keyboard morphed into your favorite Tswana or Setswana { whatever } and
only ONE keyboard needed to be manufactured ?
re THINK
--
https://mail.python.org/mailman/listinfo/python-list
Re: Keyboard standards
On 3/28/14 11:18 PM, Ben Finney wrote: On the inexpensive end, Think Penguin will also happily ship Tux logo stickers to go on top of the Super key https://www.thinkpenguin.com/gnu-linux/tux-super-key-keyboard-sticker>. That's ~cool. I can now remove that nasty M$ meta key. Actually, I got so sick of looking at that goofy little warped window that I grabbed myself a magic marker and blacked it out. :) marcus PS Thunderbird puts *both* the list and the news group addys in the to: header field on reply-to-list. ~nice, huh. -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 3/28/14 10:51 PM, Steven D'Aprano wrote: You are being patronising to the 94% of the world that is not from the USA. Do you honestly think that people all over the world have been using computers for 30 or 40 years without any way to enter their native language? uh, pretty much. That's why they called it ASCII American Standard Code for Information Interchange... yup, pretty much. Worked pretty well too, for many many years, because so many languages derive from Latin, and most non third world countries use Latin derived character sets; yes, although missing dieresis and grave and acute accents, &c. Specialized keytops are made now, but what if... Dream -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Sat, Mar 29, 2014 at 3:07 PM, Mark H Harris wrote:
> You think ~sooo three dimensionally.
Yeah Doc, I have a real problem with that. -- Marty McFly
> Picture this ~a unicode keyboard with morphing keytops (digital ink, light
> emitting); a standard layout of keys that are touch sensitive, are meta
> operative, and are able to input *every* language on earth (as well any
> symbol). The keyboard may emit light, but not necessarily. The keys may be
> raised, but not necessarily; they have a glassy feel, soft, sensual, and
> completely programmable. Code point pages (key top mappings literally) are
> selectable on|off screen. The keyboard is obviously wireless, and the entire
> keytopsection is mouse-able; the whole keyboard is a pinting device, with
> diff sections for scrolling &c.
>
> This keyboard will be standard in about 25 years... none exist today.
Wrong. You just have to be willing to pay for it.
http://www.thinkgeek.com/product/181d/?srp=14
Or you could just get a blank keytops keyboard and reprogram it how
you like. But hey, have you noticed something? NOT ONE of these ideas
actually makes it easy to write Python code with occasional non-ASCII
characters in it. Switching keyboard mode for a single character is
horribly inefficient, especially if you have to remember a whole lot
of different modes for different characters ("lambda is
meta-butterfly-greek L meta-ctrl-space, and equality is
meta-mathematics 5 meta-ctrl-space"). Putting everything onto a single
keyboard is unworkable. Requiring you to press long key sequences to
generate single characters is useless. (You may as well just press
L-A-M-B-D-A and have it come out as "lambda".) Even with an ideal
keyboard, the creature of your fancies, you won't get past that, for
the same reason that we have keyboards that type letters rather than
English words.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: unicode as valid naming symbols
On Saturday, March 29, 2014 12:25:45 AM UTC+5:30, rand...@fastmail.us wrote: > On Thu, Mar 27, 2014, at 11:10, Rustom Mody wrote: > > Just out of curiosity how do/did you type that? > > When I see an exotic denizen from the unicode-universe I paste it into > > emacs and ask "Who are you?" > > But with your 'def' my emacs is going a bit crazy! > Your emacs probably is using UCS-2 or UTF-16. The former can't handle > characters above 65535 at all, the latter stores them as if they were > two characters [so code that's not expecting them will handle them > incorrectly] My current diagnosis (with the help of more knowledgeable folks than myself) is that its a font problem. There simply doesn't exist a font (or more likely I dont know of) that - is readable - is scaleable - spans the whole 17*65536 unicode space At least out here: - gnu-unifont does not cover things outside BMP - dejavu seems to have some bugs -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Sat, Mar 29, 2014 at 3:40 PM, Mark H Harris wrote: > On 3/28/14 10:51 PM, Steven D'Aprano wrote: >> >> You are being patronising to the 94% of the world that is not from the >> USA. Do you honestly think that people all over the world have been using >> computers for 30 or 40 years without any way to enter their native >> language? > > > uh, pretty much. That's why they called it ASCII American Standard Code > for Information Interchange... yup, pretty much. Worked pretty well too, > for many many years, because so many languages derive from Latin, and most > non third world countries use Latin derived character sets; yes, although > missing dieresis and grave and acute accents, &c. ... wow. Okay. History lesson time. http://nedbatchelder.com/text/unipain.html http://en.wikipedia.org/wiki/Code_page Back before I was born, people were using computers to write messages that weren't in English. And they managed it, somehow. Can't imagine how, if all computers work exclusively with seven-bit Latin-derived character sets. "Most non-third-world countries use Latin-derived character sets". Hmm. Let's see. Greece, Russia, China, Japan, Israel, and Egypt are either third-world or just so insignificant that you can ignore them and say "most". Yeah, okay, we'll take that as read. Names are notoriously inaccurate when it comes to internationality. Ever heard of a place called IHOP? I hadn't, until I started talking to Americans. What's the difference between "global" and "universal"? We're clearly taking no notice of Martian languages here, much less anything outside our solar system. (If humans had non-FTL space travel five thousand years ago, there could now be colonies all over the universe, and we wouldn't necessarily even know about them. Those people would speak languages that can't possibly be Latin-derived; most likely they'd be derived from Hebrew or Arabic. In the event that they make contact, we're going to have to allocate some Unicode planes to them.) "Extended ASCII" is as international as Unicode, just less standardized. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: unicode as valid naming symbols
On Sat, Mar 29, 2014 at 4:00 PM, Rustom Mody wrote: > My current diagnosis (with the help of more knowledgeable folks than myself) > is that its a font problem. > > There simply doesn't exist a font (or more likely I dont know of) that > - is readable > - is scaleable > - spans the whole 17*65536 unicode space For my MUDding, I use a font imaginatively named "Monospace", which does most of what I want. There are a handful of characters that come out as the "square with digits inside", but not huge blocks (certainly not "everything non-BMP" or anything like that). It's fairly readable, although I don't know about scaling - I run it at 14pt and nowhere else. Comes with Debian. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Keyboard standards
On Sat, Mar 29, 2014 at 3:26 PM, Mark H Harris wrote: > On 3/28/14 11:18 PM, Ben Finney wrote: > >> On the inexpensive end, Think Penguin will also happily ship Tux logo >> stickers to go on top of the Super key >> >> https://www.thinkpenguin.com/gnu-linux/tux-super-key-keyboard-sticker>. > > > That's ~cool. I can now remove that nasty M$ meta key. Actually, I got so > sick of looking at that goofy little warped window that I grabbed myself a > magic marker and blacked it out. :) If Sharpie can oust Microsoft's dominance over your keyboard, it can't have been very strong dominance to start with... When I first met Windows keys, I just popped 'em off and left a gap. Worked fine. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Saturday, March 29, 2014 10:38:47 AM UTC+5:30, Chris Angelico wrote: > On Sat, Mar 29, 2014 at 3:40 PM, Mark H Harris wrote: > > On 3/28/14 10:51 PM, Steven D'Aprano wrote: > >> You are being patronising to the 94% of the world that is not from the > >> USA. Do you honestly think that people all over the world have been using > >> computers for 30 or 40 years without any way to enter their native > >> language? > > uh, pretty much. That's why they called it ASCII American Standard Code > > for Information Interchange... yup, pretty much. Worked pretty well too, > > for many many years, because so many languages derive from Latin, and most > > non third world countries use Latin derived character sets; yes, although > > missing dieresis and grave and acute accents, &c. > ... wow. > Okay. History lesson time. > http://nedbatchelder.com/text/unipain.html > http://en.wikipedia.org/wiki/Code_page > Back before I was born, people were using computers to write messages > that weren't in English. And they managed it, somehow. Can't imagine > how, if all computers work exclusively with seven-bit Latin-derived > character sets. > "Most non-third-world countries use Latin-derived character sets". > Hmm. Let's see. Greece, Russia, China, Japan, Israel, and Egypt are > either third-world or just so insignificant that you can ignore them > and say "most". Yeah, okay, we'll take that as read. > Names are notoriously inaccurate when it comes to internationality. > Ever heard of a place called IHOP? I hadn't, until I started talking > to Americans. What's the difference between "global" and "universal"? > We're clearly taking no notice of Martian languages here, much less > anything outside our solar system. (If humans had non-FTL space travel > five thousand years ago, there could now be colonies all over the > universe, and we wouldn't necessarily even know about them. Those > people would speak languages that can't possibly be Latin-derived; > most likely they'd be derived from Hebrew or Arabic. In the event that > they make contact, we're going to have to allocate some Unicode planes > to them.) "Extended ASCII" is as international as Unicode, just less > standardized. > ChrisA For Indian languages there is usually a specific fully localized layout and a latin-derived one. In particular for devanagari, which is directly used (Hindi, Marathi) or close relative used (Gujarati, Bengali) there is inscript and itrans https://fedoraproject.org/wiki/I18N/Indic/HindiKeyboardLayouts itrans is the latin-derived layout, inscript is the fully-localized, no-relation-to-US-104 one. I would not be able to use the inscript if I tried and this is true for most of the people I know even though in some theoretically ergonomic sense its more efficient. So in the sphere I am familiar with Mark seems to be right that ASCII == US-104 rules the planet. To go from this small-sample data to vast generalizations... I'll leave to others -- https://mail.python.org/mailman/listinfo/python-list
Re: unicode as valid naming symbols
Rustom Mody writes: > At least out here: > - gnu-unifont does not cover things outside BMP That implies the GNU Unifont contains no characters from outside the BMP, which is untrue. Rather, the GNU Unifont's claim to fame is that it covers all characters in the BMP. But it does contain many characters outside the BMP. http://www.unifoundry.com/unifont.html> So, I'd re-phrase the above caution more accurately as: The GNU Unifont has complete coverage of the BMP, and incomplete coverage outside the BMP. -- \ “People always ask me, ‘Where were you when Kennedy was shot?’ | `\Well, I don't have an alibi.” —Emo Philips | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Keyboard standards
On 3/29/14 12:13 AM, Chris Angelico wrote: When I first met Windows keys, I just popped 'em off and left a gap. Worked fine. ha! see.. it popped you off too! :-)) I found it arrogant to the max to place their stupid logo on (my) keyboard. What if every company out there wanted "their" own keytop too? geeze :) -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 3/29/14 12:08 AM, Chris Angelico wrote: Okay. History lesson time. Tell me what is the lingua franka today? Is it, E n g l i s h ? For many many many years people all over the earth were using English and ASCII to communicate with early computers... they still are. Almost every post on every site is English, and nearly every post on every site is a Latin character derivative. Kanji and Cyrillic , and Arabic are obvious exceptions to that today, mostly because of unicode; NOT extend ASCII. Back before I was born, people were using computers to write messages that weren't in English. No, they weren't... not most... some. And they managed it, somehow. Can't imagine how, if all computers work exclusively with seven-bit Latin-derived character sets. Unicode. Shoot, most of the world didn't even have computers until just a few years ago; none of the third world did, back in the day, and the ones who did communicated in ASCII and English (or some broken variant of it). "Most non-third-world countries use Latin-derived character sets". See this quote from the consortium FAQ: > So, for example, there is only one set of Latin characters > defined, despite the fact that the Latin script > is used for the alphabets of thousands of different languages. http://www.unicode.org/faq/basic_q.html#3 marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Sat, Mar 29, 2014 at 4:51 PM, Mark H Harris wrote: > On 3/29/14 12:08 AM, Chris Angelico wrote: > >> >> Okay. History lesson time. >> > >Tell me what is the lingua franka today? > >Is it, E n g l i s h ? > >For many many many years people all over the earth were using English and > ASCII to communicate with early computers... they still are. Almost every > post on every site is English, and nearly every post on every site is a > Latin character derivative. http://forum.ecomstation.ru/ Prominent discussion forum, although that strives to be at least partially bilingual in deference to those of us who are so backward as to speak only English. >Kanji and Cyrillic , and Arabic are obvious exceptions to that today, > mostly because of unicode; NOT extend ASCII. > >> Back before I was born, people were using computers to write messages >> that weren't in English. > > >No, they weren't... not most... some. So, pre-Unicode, people didn't use any of those languages or writing systems with computers, is that what you're saying? That code pages 86x are a total myth? >> And they managed it, somehow. Can't imagine >> how, if all computers work exclusively with seven-bit Latin-derived >> character sets. > > >Unicode. Shoot, most of the world didn't even have computers until just a > few years ago; none of the third world did, back in the day, and the ones > who did communicated in ASCII and English (or some broken variant of it). Unicode didn't even begin to exist until 1987, and the first version of the standard wasn't published until 1991. You're seriously saying that until 1991 (plus however long it took to get implementations into people's hands) everyone spoke English with computers?!? >> "Most non-third-world countries use Latin-derived character sets". > > >See this quote from the consortium FAQ: > >> So, for example, there is only one set of Latin characters >> defined, despite the fact that the Latin script >> is used for the alphabets of thousands of different languages. > > http://www.unicode.org/faq/basic_q.html#3 Huh? I'm not sure whether you're trolling or genuinely ignorant of all history and other languages. Please clarify. If you really are just trolling, say so, and I'll start ignoring all your posts. You'll make yourself look less of a fool that way. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Saturday, March 29, 2014 11:21:17 AM UTC+5:30, Mark H. Harris wrote: > On 3/29/14 12:08 AM, Chris Angelico wrote: > > Okay. History lesson time. > Tell me what is the lingua franka today? > Is it, E n g l i s h ? I wonder Mark, if because you are communicating with your mailing software in ＥＮＧＬＩＳＨ and its expecting unicode (or Kanji)... you are posting once and we are seeing it twice, thrice... -- https://mail.python.org/mailman/listinfo/python-list
