distutils_ui 0.1.1 released
For those of you, who like PyQt{4,5} as much as I do, as well as for those who
don't like it that much, because of the poor integration with setuptools
et.al., here's another piece of software to bridge the gap:
A distutils build extension for PyQt{4,5} applications
that makes handling the PyQt tool chain easier than ever:
https://pypi.python.org/pypi/distutils_ui
Ahem, well, it wasn't that easy before. Most of us were using dreaded
Makefiles or other such crutches to generate translation files, .py modules of
forms, and resource modules. Scratch the crutches, here's what you're looking
for.
Feedback welcome.
Enjoy,
Pete
--
https://mail.python.org/mailman/listinfo/python-list
Re: What meaning is "if k in [0, len(n_trials) - 1] else None"?
On 12/3/2016 7:31 PM, Chris Angelico wrote: On Sun, Dec 4, 2016 at 11:10 AM, Terry Reedy wrote: But the expression result isn't even used. So this is better written: matplotlib.pyplot.xlabel sets x-axis scaling, with no documented return value. http://matplotlib.org/api/pyplot_api.html#matplotlib.pyplot.xlabel If, as seems reasonable to assume, it returns None, the value of the expression is 'None if x else None', which is to say, None. Hardly matters what the return value is, given that the code ignores it. I was not clear enough. To me, a 'conditional expression' that has an unconditional value is a bit confusing. So I think the conditional side-effect would be better written the way you did regardless of the use or not of the value. If the unconditional value were not ignored, I think it would be better used by itself. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: What meaning is "if k in [0, len(n_trials) - 1] else None"?
On Mon, Dec 5, 2016 at 6:14 AM, Terry Reedy wrote: > On 12/3/2016 7:31 PM, Chris Angelico wrote: >> >> On Sun, Dec 4, 2016 at 11:10 AM, Terry Reedy wrote: But the expression result isn't even used. So this is better written: >>> >>> >>> matplotlib.pyplot.xlabel sets x-axis scaling, with no documented return >>> value. >>> http://matplotlib.org/api/pyplot_api.html#matplotlib.pyplot.xlabel >>> If, as seems reasonable to assume, it returns None, the value of the >>> expression is 'None if x else None', which is to say, None. >> >> >> Hardly matters what the return value is, given that the code ignores it. > > > I was not clear enough. To me, a 'conditional expression' that has an > unconditional value is a bit confusing. So I think the conditional > side-effect would be better written the way you did regardless of the use or > not of the value. If the unconditional value were not ignored, I think it > would be better used by itself. Fair enough. It's doubly bizarre - the expression result is constant AND it's an expression being used as a statement that has an equivalent statement form. Plus, the statement form takes two lines... but the expression is over two lines anyway. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On 04/12/2016 20:26, DFS wrote: $python program.py column1=2174 and column2='R' Windows (correct) $print sys.argv[3] column2='R' Linux (incorrect) $print sys.argv[3] column2=R It drops the apostrophes, and the subsequent db call throws an error: sqlite3.OperationalError: no such column: R The way it's used in code is: argcnt = len(sys.argv) querystr = ' '.join(sys.argv[1:argcnt]) I tried using dbl-quotes in the command line, and with the join() statement, and neither worked. Edit: I got it to work this way: column2="'R'" but that's bogus, and I don't want users to have to do that. You can put double quotes around the whole thing: "column2='R'" otherwise I don't know what the solution other than for a program be aware of the possibility and allow for either input, if there are no conflicts (for example if both R and 'R' are valid inputs and mean different things). Command parameters /do/ behave differently between Windows and Linux, for example try writing *.* as that third parameter. In Windows, it will print *.*. In Linux, if you have 273 files in the current directory, if will print the name of the first, and there will be /272 further command parameters/, each the name of a file. (I couldn't believe this when I found out; one of my directories recently had 3.4 million files in it, I don't really want *.* expanded to 3.4m arguments. Here, the fix is again to use double quotes: "*.*". But what if the user doesn't do that?) -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Mon, 5 Dec 2016 07:26 am, DFS wrote: > $python program.py column1=2174 and column2='R' Here is a simple script demonstrating the issue: # --- program.py --- import sys print "argv:", sys.argv print ' '.join(sys.argv[1:]) I haven't tested it on Windows, but on Linux it behaves as you describe (and as Linux users will expect): [steve@ando ~]$ python program.py column1=2174 and column2='R' argv: ['program.py', 'column1=2174', 'and', 'column2=R'] column1=2174 and column2=R This is *absolutely normal behaviour* for the most common shell on Linux, bash. I would expect that the other common shells will do the same thing. Quotation marks need to be escaped if you want the shell to pass them through to the program, either like this: column2="'R'" or like this: column2=\'R\' > It drops the apostrophes, and the subsequent db call throws an error: > sqlite3.OperationalError: no such column: R I'm not sure how to interpret this error, so I'm guessing. Please correct me if I'm wrong, but doesn't this mean that your column is called: single quote R single quote that is, literally 'R', which means that if you were using it in Python code, you would have to write the column name as this? "'R'" If so, perhaps the best solution is to get rid of the quotes in the column names, so that all your users, Windows and Linux, just write this: program.py column1=2174 and column2=R (P.S. what happens if they write program.py column1 = 2174 and column2 = R instead?) > The way it's used in code is: > argcnt = len(sys.argv) > querystr = ' '.join(sys.argv[1:argcnt]) You can simplify that to: querystr = ' '.join(sys.argv[1:]) > I tried using dbl-quotes in the command line, and with the join() > statement, and neither worked. By the time you join the arguments, its too late. You have to quote them first. > Edit: I got it to work this way: > column2="'R'" > > but that's bogus, and I don't want users to have to do that. (1) It's not bogus. (2) Linux users will expect that you have to escape quotation marks if you want to pass them through the shell. (3) If my interpretation is correct, what *is* bogus is that that your column names include quotes in them. Get rid of the quotes, and your problem goes away. If that's not the case, then you'll either have to get your users to escape the quotes, or you'll have to add them in yourself. (In case this is not obvious by now, this is not a Python issue. This is entirely due to the behaviour of the shell.) -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Mon, Dec 5, 2016 at 9:19 AM, BartC wrote: > Command parameters /do/ behave differently between Windows and Linux, for > example try writing *.* as that third parameter. > > In Windows, it will print *.*. > > In Linux, if you have 273 files in the current directory, if will print the > name of the first, and there will be /272 further command parameters/, each > the name of a file. (I couldn't believe this when I found out; one of my > directories recently had 3.4 million files in it, I don't really want *.* > expanded to 3.4m arguments. Here, the fix is again to use double quotes: > "*.*". But what if the user doesn't do that?) Technically this isn't a Win/Lin difference, but a shell difference. The behaviours you're referring to are common to many Unix shells (including bash, the most commonly used shell on typical Linux systems). If you want a glob to be processed by the application, rather than the shell, you have to escape it with quotes or backslashes. Most of the time, it's easiest to write your app to accept multiple file names, and let the shell expand them - there's a lot more flexibility than just * and ?, and every program behaves the same way, because it's the same shell parsing them all. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
Steve D'Aprano wrote: On Mon, 5 Dec 2016 07:26 am, DFS wrote: no such column: R doesn't this mean that your column is called: single quote R single quote I think he intends it to be an SQL string literal (which uses single quotes), but since the quotes disappeared, SQL is trying to interpret it as a column name. Edit: I got it to work this way: column2="'R'" but that's bogus, and I don't want users to have to do that. DFS: Is the argument always going to be a literal, or could the user sometimes want to pass a column name? If it's always a literal, your program could add the quotes before passing it to SQL. If it's not always a literal, you'll just have to deal with the fact that the unix shell is a programming language that has its own interpretation of quotes. Either the user will have to escape the quotes, or you'll have to provide another way of distinguishing literals from column names. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Mon, Dec 5, 2016 at 9:52 AM, Steve D'Aprano wrote: > I'm not sure how to interpret this error, so I'm guessing. Please correct me > if I'm wrong, but doesn't this mean that your column is called: > > single quote R single quote > > that is, literally 'R', which means that if you were using it in Python > code, you would have to write the column name as this? > > "'R'" > AIUI this is meant to be a string literal, which in SQL is surrounded by single quotes. This also means that anyone who's using this script needs to be comfortable with writing raw SQL; plus, there's no protection against SQL injection, so anyone using the script has to have full database permission. The best solution might well be to change the protocol somewhat: instead of taking raw SQL on the command line, take "column=value", parse that in Python, and provide the value as a string (or maybe as "int if all digits else string"). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Mon, 5 Dec 2016 09:19 am, BartC wrote: > Command parameters /do/ behave differently between Windows and Linux, > for example try writing *.* as that third parameter. > > In Windows, it will print *.*. > > In Linux, if you have 273 files in the current directory, if will print > the name of the first, and there will be /272 further command > parameters/, each the name of a file. (I couldn't believe this when I > found out; one of my directories recently had 3.4 million files in it, I > don't really want *.* expanded to 3.4m arguments. Here, the fix is again > to use double quotes: "*.*". But what if the user doesn't do that?) If the user doesn't escape the wildcard, then the shell will expand it, exactly as the user would expect. I'm not sure why you were surprised by that. * is a shell wildcard. By using a * you are explicitly telling the shell to expand it to any file that matches. Did you think it was a regular character like 'a' and 'z'? I think it boils down to what the user expects. Linux and Unix users tend to be technically-minded folks who use the command line a lot and demand powerful tools, and they expect that wildcards like * should be expanded. Windows treats the command line as an afterthought, and until a few years ago you were limited to a DOS shell. Today, your options are not as limited: there's Powershell, and bash for Windows. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On 2016-12-04 22:52, Steve D'Aprano wrote: On Mon, 5 Dec 2016 07:26 am, DFS wrote: $python program.py column1=2174 and column2='R' Here is a simple script demonstrating the issue: # --- program.py --- import sys print "argv:", sys.argv print ' '.join(sys.argv[1:]) I haven't tested it on Windows, but on Linux it behaves as you describe (and as Linux users will expect): [steve@ando ~]$ python program.py column1=2174 and column2='R' argv: ['program.py', 'column1=2174', 'and', 'column2=R'] column1=2174 and column2=R [snip] On Windows: py.exe program.py column1=2174 and column2='R' gives: argv: ['program.py', 'column1=2174', 'and', "column2='R'"] column1=2174 and column2='R' and: py.exe program.py column1=2174 and column2="R" gives: argv: ['program.py', 'column1=2174', 'and', 'column2=R'] column1=2174 and column2=R -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Sun, Dec 4, 2016 at 10:19 PM, BartC wrote: > > Command parameters /do/ behave differently between Windows and Linux, for > example try writing *.* as that third parameter. > > In Windows, it will print *.*. In Windows each program parses its own command line. Most C/C++ programs use the CRT's default [w]argv parsing. The CRT defaults to disabling wildcard expansion. Link with [w]setargv.obj to enable this feature: https://msdn.microsoft.com/en-us/library/8bch7bkk The CRT [w]argv parsing doesn't care about single quotes, but literal double quotes need to be escaped. -- https://mail.python.org/mailman/listinfo/python-list
Agile
And you thought Agile development was simple: https://pbs.twimg.com/media/CyjbCtGXcAEhQi8.jpg:large -- Steven "Ever since I learned about confirmation bias, I've been seeing it everywhere." - Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: Agile
On Mon, Dec 5, 2016 at 4:20 PM, Steven D'Aprano wrote: > And you thought Agile development was simple: > > https://pbs.twimg.com/media/CyjbCtGXcAEhQi8.jpg:large > Agile may be complicated to explain, but it's so easy to use. This guy understands it. https://twitter.com/PHP_CEO/status/664237197365796864 ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: variable argument unpacking
Peter Otten wrote:
> Mehrzad Irani wrote:
>
>> Hi All,
>>
>> Consider the situation
>> [cti@iranim-rhel python_cti]$ cat a.py
>> def a(a = 1, b = 2, c = 3, *d, **e):
>> print(a, b, c)
>> print(d)
>> print(e)
>>
>> r = {'e': 7, 'f': 8, 'g': 9}
>>
>>
>> a(**r)
>> a(3, **r)
>>
>> r1 = (4,5,6)
>>
>> a(3,2,1,*r1, **r)
>> a(*r1, **r)
>>
>> r1 = (4,5,6,7)
>> a(*r1, **r)
>>
>> [cti@iranim-rhel python_cti]$
>>
>> The output for this program is as follows:
>> [cti@iranim-rhel python_cti]$ python a.py
>> (1, 2, 3)
>> ()
>> {'e': 7, 'g': 9, 'f': 8}
>> --
>> (3, 2, 3)
>> ()
>> {'e': 7, 'g': 9, 'f': 8}
>> --
>> (3, 2, 1)
>> (4, 5, 6)
>> {'e': 7, 'g': 9, 'f': 8}
>> --
>> (4, 5, 6)
>> ()
>> {'e': 7, 'g': 9, 'f': 8}
>> --
>> (4, 5, 6)
>> (7,)
>> {'e': 7, 'g': 9, 'f': 8}
>>
>> This program shows, that for d to get assigned, I would need to first
>> assign a, b, c even though their default parameters have been set.
>>
>> Also, if I would like to unpack a, b, c using e; I would get a
>> multiple assignment TypeError.
>>
>> Therefore, my question is - is there a way to assign d, without going
>> through the assignments of a, b, c again, since they have already
>> been assigned defaults? (I think I am missing something simple here)
>>
>> Thanks in advance.
>
> Python 3 allows
>
> $ cat b.py
> def a(*d, a=1, b=2, c=3, **e):
> print(a, b, c)
> print(d)
> print(e)
>
> r = {'e': 7, 'f': 8, 'g': 9}
>
>
> a(**r)
> a(3, **r)
>
> r1 = (4,5,6)
>
> a(3,2,1,*r1, **r)
> a(*r1, **r)
>
> r1 = (4,5,6,7)
> a(*r1, **r)
> $ python3 b.py
> 1 2 3
> ()
> {'e': 7, 'f': 8, 'g': 9}
> 1 2 3
> (3,)
> {'e': 7, 'f': 8, 'g': 9}
> 1 2 3
> (3, 2, 1, 4, 5, 6)
> {'e': 7, 'f': 8, 'g': 9}
> 1 2 3
> (4, 5, 6)
> {'e': 7, 'f': 8, 'g': 9}
> 1 2 3
> (4, 5, 6, 7)
> {'e': 7, 'f': 8, 'g': 9}
>
> Perhaps that is more to your liking? I find the output as unreadable
> as of your a.py, so I won't bother to check...
import inspect, linecache
def a(a = 1, b = 2, c = 3, l = 0, *d, **e):
lineno = inspect.currentframe().f_back.f_lineno
print 'line', lineno, linecache.getline(__file__, lineno),\
linecache.getline(__file__, lineno-1)
print(a, b, c)
print(d)
print(e)
print ''
r = {'e': 7, 'f': 8, 'g': 9}
a(**r)
a(3, **r)
r1 = (4,5,6)
a(3,2,1,*r1, **r)
a(*r1, **r)
r1 = (4,5,6,7)
a(*r1, **r)
(thanks to erica on freenode who linked me to:
http://code.activestate.com/recipes/145297-grabbing-the-current-line-number-easily/)
--
https://mail.python.org/mailman/listinfo/python-list
Re: What do you think: good idea to launch a marketplace on python+django?
W dniu piątek, 2 grudnia 2016 21:51:08 UTC+1 użytkownik codew...@gmail.com napisał: > Something like this: https://marketplace.django-cms.org/en/ ? Hey, that's nice solution, good to know that there is site like this :D Thanks -- https://mail.python.org/mailman/listinfo/python-list
