Re: loop
Chris Angelico : > On Mon, Mar 24, 2014 at 11:35 AM, wrote: >> I'm trying to create a for loop that starts at 100 and goes to 10Mllion. > > That sounds like a logarithmic scale. How about: for i in [ 100, 1000, 1, 10, 100, 1000, 1 ]: ... Marko -- 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 Mar 23, 2014 11:56 PM, "Mark H Harris" wrote: > > On 3/22/14 4:46 AM, Steven D'Aprano wrote: >> >> On Fri, 21 Mar 2014 23:51:38 -0500, Mark H Harris wrote: >> >>> Lambda is a problem, if only because it causes confusion. What's the >>> problem? Glad you asked. The constructs DO NOT work the way most people >>> would expect them to, having limited knowledge of python! > > >One of the best links for understanding what is wrong with lambda is here, from Guido, (by the way I agree totally with his assessment, there is no point really in writing it out again): > > http://www.artima.com/weblogs/viewpost.jsp?thread=98196 That post doesn't point out anything "wrong" with lambda. The argument boils down to: 1) map and filter are not useful because we have comprehensions; 2) reduce is confusing; 3) if we remove those then lambda is not useful either. > Lambda is a problem of confusion for scientists and other mathematicians (amateur and otherwise) who may be confused because python's lambda does not do precisely what they might expect from other functional programming languages, nor does it match precisely with the lambda calculus. Its also confusing to sophisticated users of all stripes who may not be aware of "lambda" at all. The difference does not really lie in the lambda construct per se but in the binding style of closures. Functional languages tend to go one way here; imperative languages tend to go the other. Python being primarily an imperative language follows the imperative model. Anonymous functions in Python work the same way in this regard as anonymous functions in Lua or ECMAScript or Go -- those other languages merely avoid the cardinal sin of defining their anonymous functions using the keyword "lambda". The result may be more surprising to users accustomed to functional languages, but I claim that it is *less* surprising to users of other imperative languages. >> Python is not a pure functional language, but you can write functional >> code in it. If you want a pure functional language, you know where to >> find one. > > >Yes, that's obvious; but you're missing the point. Python is not a functional language, and implying that it can be used as one is misleading at best (maybe a lie at worst) just because it has a construct for generating a dynamic anonymous function. Oh, give me a break. If you find that you can't write functional code in Python just because closure bindings are slightly inconvenient, then you can't be trying very hard. >Well, number one, I'm not demanding anything. Number two, everyone who uses Haskell (for whatever reason) knows well from the start that its a pure functional programming language. That is the advertisement, and that is the expectation. No one expects anything different. And I would hope that anybody who uses Python is likewise aware from the stay that it *isn't* a purely functional language. >> Python could deprecate many things. It would make Python a worse language. > > >How so? Read Guido's argument above. Another way to answer this question is that I have been programming with Python for almost a decade and I've not used lambda. In fact, I have gone out of my way to NOT use lambda because I am fully aware that the BDFL hates it. If lambda were going to be deprecated and removed then it already would have happened in Python 3, because Guido tried to do precisely that. I'm not sure what the reasons were for keeping it in the end (according to PEP 3099 it was because nobody suggested a suitable replacement), but if he couldn't get rid of it then, he never will. -- https://mail.python.org/mailman/listinfo/python-list
Re: loop
On 24/03/2014 07:47, Marko Rauhamaa wrote: Chris Angelico : On Mon, Mar 24, 2014 at 11:35 AM, wrote: I'm trying to create a for loop that starts at 100 and goes to 10Mllion. That sounds like a logarithmic scale. How about: for i in [ 100, 1000, 1, 10, 100, 1000, 1 ]: ... Why the overhead of creating a list when you could use a tuple? :) -- 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: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Mon, 24 Mar 2014 00:52:52 -0500, Mark H Harris wrote:
> On 3/22/14 4:46 AM, Steven D'Aprano wrote:
>> On Fri, 21 Mar 2014 23:51:38 -0500, Mark H Harris wrote:
>>
>>> Lambda is a problem, if only because it causes confusion. What's the
>>> problem? Glad you asked. The constructs DO NOT work the way most
>>> people would expect them to, having limited knowledge of python!
>
> One of the best links for understanding what is wrong with lambda is
> here, from Guido, (by the way I agree totally with his assessment, there
> is no point really in writing it out again):
>
>http://www.artima.com/weblogs/viewpost.jsp?thread=98196
It's only one paragraph. Here it is:
Why drop lambda? Most Python users are unfamiliar with Lisp or
Scheme, so the name is confusing; also, there is a widespread
misunderstanding that lambda can do things that a nested function
can't -- I still recall Laura Creighton's Aha!-erlebnis after I
showed her there was no difference! Even with a better name, I think
having the two choices side-by-side just requires programmers to
think about making a choice that's irrelevant for their program; not
having the choice streamlines the thought process. Also, once map(),
filter() and reduce() are gone, there aren't a whole lot of places
where you really need to write very short local functions; Tkinter
callbacks come to mind, but I find that more often than not the
callbacks should be methods of some state-carrying object anyway (the
exception being toy programs).
None of map(), filter() or reduce() are gone. reduce() has been pushed
out into a module, but map() and filter() have actually been enhanced.
Any suggestion that lambda is obsolete flounders on that fact.
There's no doubt that lambda is less-often useful than is the def
statement. But not only is it still useful, but there is a continual
stream of people asking for Python to make it *more useful* by allowing
the body of a lambda to be a full block, not just a single statement.
Guido has stated (although I cannot remember where, so cannot paste a
link) that he accepts that in principle, so long as somebody comes up
with acceptable syntax.
In Ruby, anonymous blocks are used *all the time*. Python is not Ruby,
and never will be, but a lightweight way to generate anonymous functions
in expressions is one difference between a modern, powerful language, and
an archaic or toy under-powered language. I'm too lazy to do this the
right way, but there are at least 99 mentions of "lambda" in the 3.3
standard library:
steve@runes:/usr/local/lib/python3.3$ grep lambda *.py | wc -l
99
It's used in calendar, cgitb, configparser, difflib, decimal, functools,
inspect, os, pydoc and others. Python is a programming language aimed at
programmers, not a toy. It should include tools that programmers use,
like threads, closures, first-class functions. And lambda.
>> Why is that a problem? Would you consider it a problem that people who
>> don't understand BASIC can't understand BASIC? ("I don't get the
>> difference between GOTO and GOSUB. {snip}
>>
>> The problem is ignorance, not the calculator, and not lambda.
>
> You're argument, based on analogy, is also a red herring, as well a
> straw man.
Please stop misusing "straw man". It has a specific meaning:
https://yourlogicalfallacyis.com/strawman
> Lambda is a problem of confusion for scientists and other
> mathematicians (amateur and otherwise) who may be confused because
> python's lambda does not do precisely what they might expect from other
> functional programming languages, nor does it match precisely with the
> lambda calculus.
Yes, you've already said that. And my response remains the same: users of
a language should be expected to learn the language, at least to the
point that they can "get by". One doesn't need ten thousand hours
experience and to be an expert. But nor should the confusion of somebody
who doesn't know the language count for much.
Python's ints don't work exactly the same as ints do in some other
languages, nor do Python's strings, nor is Python's object model
precisely the same as that of some other languages. I think that it would
be a ridiculous idea to discard int, str and the entire object system
just because some people are surprised that Python doesn't behave exactly
like some other language. I don't think lambda is any different.
The same argument applies to *any other language*. Ocaml is not precisely
the same as Haskell, Java not precisely the same as C++, Ruby is not
precisely the same as Javascript. Should Ruby discard their anonymous
blocks because they don't work "precisely" the same as Haskell? Or
perhaps Haskell should throw the towel in because it doesn't behave
"precisely" the same as Ruby?
Of course not -- new languages come into existence precisely so that they
will be different from what is already there. Who is to say that there
aren't people w
Asyncio (or something better) for control of a vacuum system/components.
Dear All, I apologise in advance a) if this is not the proper list for asking the question, b) the length of the post. I am writing a software to control and monitor a vacuum furnace+attachments. It has a few mass flow controllers, a butterfly valve, a labjack unit for analog/digital outputs etc. They use RS485, RS232 and USB to communicate with the computer and follow special protocols for commands and response. The response time to execute commands can be from 5 ms to 1 s. To achieve this, I thought of a server which reads commands on a network connections, parses the command and calls methods of appropriate device classes, which then use the corresponding channel protocol to execute the command. The response provided by the devices (flow controllers, valve) is sent back on the network connection. As there can be multiple clients (e.g. for monitoring from several computers), and some commands can take long, the server should not block when getting a command executed. I wanted to use asyncio to achieve this non-blocking behaviour, i.e. when the server calls the method of device classes, a callback is installed and the method returns immediately. When the response is available from the device, the callback writes the response to the client's connection. Some (pseudo)code: class server(Protocol): def connection_made(self, transport): self.transport = transport def data_received(self, data): device, command, args = parse(data) result = yield from device.command(args) self.transport.write(result) class device1(): self.channel = rs232() @asyncio.coroutine def command1(args): r = self.execute(self.channel, 'Cmd1', args) # this can take a while return r # ++ get_event_loop code for running the server forever This doesn't work as I expected. For example, I expected that when command1 is awaiting response from the device, the server can receive another command2 on the same network connection, and get that executed (say on another device). If the response of this command2 is available earlier, it will be written to the network connection. Instead, the data_received call for first command doesn't return till the command1 is completed. If the execute() call is replaced by asyncio.sleep(r) it works as I expect. The problem is that self.execute() blocks and the asyncio framework has no way to know how to reschedule it or bypass it. This can be avoided if I depended on I/O from a file descriptor, on which I can apply poll()/select(). But the channel handler that I have is more generic (rs232() in code above). My question then is: is there a good way to handle the situation? I would like to have following architecture: A server sits on the computer which is connected to the devices via channels (rs232, rs485, usb etc.). A client initiates a network connection to the server and starts sending commands which are numbered. Server asks the device classes for a response of execution of these commands on the devices. The responses it receives (and dispatches to the client) from device classes are not in same sequence, but that doesn't matter as they are numbered by the client. There can be several clients. I also assume that execution of each command on the devices is atomic, i.e. when the device class connects to the device on later's channel, the channel is not relinquished till the device provides a response. To achieve this, the device classes obtain a lock on the channel they need before talking to the device (and release it after they are done). I have looked around the web but couldn't find an easy+flexible framework to do what I have outlined here. Our lab is using a control panel written in labview, which I believe does things sequentially (i.e. by blocking). It works alright, but error handling is poor (crashes on errors and resets the furnace state on a restart!). It is also done in Labview, is not portable or can be addressed over network. I have written/tested python code to control the following if anyone is interested (will put up on bitbucket.org once I am done with the above server): T3Bi throttle valve controller from MKS (RS232 based) GF40 MFCs from Brooks Instruments (RS485 based) CMC & CMX gauges from Brooks Instruments (RS485, but currently controlled by T3Bi) 1179A MFCs from MKS (which is controlled via analog output from a LabJack U6) SMC pneumatic switches (which are controlled via digital ports on LabJack U6 + PS12VDC). The LabJack parts use labjackpython library. Thanks a lot for reading, sid. -- 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)
Ian Kelly : > If lambda were going to be deprecated and removed then it already > would have happened in Python 3, because Guido tried to do precisely > that. I'm not sure what the reasons were for keeping it in the end > (according to PEP 3099 it was because nobody suggested a suitable > replacement), but if he couldn't get rid of it then, he never will. You never *need* (Python's) lambda for anything. Inner functions are more capable and almost always more readable. It doesn't hurt to have lambda, but I don't find any use for it, either. Marko -- 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 24/03/2014 05:52, Mark H Harris wrote: How so? Read Guido's argument above. Another way to answer this question is that I have been programming with Python for almost a decade and I've not used lambda. In fact, I have gone out of my way to NOT use lambda because I am fully aware that the BDFL hates it. Reduce is no longer in the standard library (although you can import it) and there are equally good ways to do what lambda was designed for without the hassle nor confusion. Where do you get reduce from if it's not in the standard library? As for lambda I've no real interest in it, other than when copying examples where it's used to (say) provide a key function. -- 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: loop
Mark Lawrence : > On 24/03/2014 07:47, Marko Rauhamaa wrote: >> for i in [ 100, 1000, 1, 10, 100, 1000, 1 ]: > > Why the overhead of creating a list when you could use a tuple? :) Once in college, we were given assembly programming assignments. The textbook defined an imagined 18-bit CPU and an instruction set. A fellow student was given the task to write a subroutine that calculates the factorial of the argument. He went through the trouble of creating a loop with multiplication etc. I argued (in vain) that his solution is "wrong" from all angles; he should have implemented his subroutine with a simple lookup table since 18 bits can only take a handful of input values (0 through 8). Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Asyncio (or something better) for control of a vacuum system/components.
Shishir : > The problem is that self.execute() blocks and the asyncio framework > has no way to know how to reschedule it or bypass it. This can be > avoided if I depended on I/O from a file descriptor, on which I can > apply poll()/select(). But the channel handler that I have is more > generic (rs232() in code above). Deep down asyncio depends on file descriptors. If your thingy is another kind of object, it needs to go into its own process or thread. > A server sits on the computer which is connected to the devices via > channels (rs232, rs485, usb etc.). [...] Sounds about right. > I have looked around the web but couldn't find an easy+flexible > framework to do what I have outlined here. Asyncio + subprocess should be all you need for a framework. However, some system programming *will* be required. Marko -- https://mail.python.org/mailman/listinfo/python-list
gdb python how to output integer for examine memory
Hi all,
I am trying to use gdb debug python script.
I am using gdb7.7 and python2.7.6, here is my simple test script:
import time
def next(i):
time.sleep(10)
i = 1 - i
i = 1
while True:
next(i)
When this script running, gdb attach to it, and here is snippet:
(gdb) py-bt
#5 Frame 0x201e130, for file test.py, line 6, in next (i=1)
Python Exception (2,
'\xe6\xb2\xa1\xe6\x9c\x89\xe9\x82\xa3\xe4\xb8\xaa\xe6\x96\x87\xe4\xbb\xb6\xe6\x88\x96\xe7\x9b\xae\xe5\xbd\x95',
'test.py'):
Error occurred in Python command: (2,
'\xe6\xb2\xa1\xe6\x9c\x89\xe9\x82\xa3\xe4\xb8\xaa\xe6\x96\x87\xe4\xbb\xb6\xe6\x88\x96\xe7\x9b\xae\xe5\xbd\x95',
'test.py')
(gdb) frame 5
#5 0x004d01a7 in PyEval_EvalFrameEx (f=Frame 0x201e130, for file
test.py, line 6, in next (i=1), throwflag=0) at Python/ceval.c:2666
2666x = call_function(&sp, oparg);
(gdb) py-locals
i = 1
(gdb) pyo i
No symbol "i" in current context.
(gdb)
No symbol "i" in current context.
(gdb) p f->f_localsplus
$1 = {1}
(gdb) p f->f_localsplus[0]
$2 = 1
(gdb) p &(f->f_localsplus[0])
$3 = (PyObject **) 0x201e2b8
(gdb) x/d 0x201e2b8
0x201e2b8: 31304528
(gdb) p sizeof(f->f_localsplus[0])
$4 = 8
(gdb) x/dg 0x201e2b8
0x201e2b8: 31304528
(gdb) x/dw 0x201e2b8
0x201e2b8: 31304528
(gdb)
So, the latter several commands, I wannted to check memory content, but , how
to output integer 1?
Thanks.
Wesley
--
https://mail.python.org/mailman/listinfo/python-list
Re: Writing an OPC client with Python ?
OPC Python Example: Get OPC data into Python http://www.opclabs.com/products/quickopc/languages-and-tools/python -- https://mail.python.org/mailman/listinfo/python-list
Re: Python OPC -wrapper for data collection, anyone seen it ?
What about (our) QuickOPC: http://www.opclabs.com/products/quickopc/languages-and-tools/python -- https://mail.python.org/mailman/listinfo/python-list
Re: OPC for Python ?? (Win32)
QuickOPC: Get OPC data into Python http://www.opclabs.com/products/quickopc/languages-and-tools/python -- https://mail.python.org/mailman/listinfo/python-list
Re: Python in Process Control?
Get OPC data into Python: http://www.opclabs.com/products/quickopc/languages-and-tools/python -- https://mail.python.org/mailman/listinfo/python-list
Re: loop
On Mon, Mar 24, 2014 at 9:04 PM, Marko Rauhamaa wrote: > Once in college, we were given assembly programming assignments. The > textbook defined an imagined 18-bit CPU and an instruction set. > > A fellow student was given the task to write a subroutine that > calculates the factorial of the argument. He went through the trouble of > creating a loop with multiplication etc. I argued (in vain) that his > solution is "wrong" from all angles; he should have implemented his > subroutine with a simple lookup table since 18 bits can only take a > handful of input values (0 through 8). The task was "calculates". If the task was "returns", then the lookup table would be correct. :) 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 Mon, Mar 24, 2014 at 8:49 PM, Steven D'Aprano wrote: > I'm too lazy to do this the > right way, but there are at least 99 mentions of "lambda" in the 3.3 > standard library: > > steve@runes:/usr/local/lib/python3.3$ grep lambda *.py | wc -l > 99 I'm not too lazy to do it the right way, but I don't have 3.3 handy, so I've done it on 3.4 instead. There are 77 instances of lambda nodes in the files you list there - which are the ones that aren't in packages. (Note that two instances of lambda on the same line would count as one in Steven's figure, but as two in mine. Also, his counts comments. Still, his way's a lot easier to calculate, and it's in the right ball-park.) Including all subdirectories raises that figure to, get this, 1230. That's actual uses of the lambda keyword as parsed by Python. This does include the test suite, though. Removing all files with "/test/" in the names cuts that figure to only 273. But that's still two hundred and seventy-three places where the Python standard library uses lambda - a respectable figure. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Memory error
Hello all,
I'm afraid I am new to all this so bear with me...
I am looking to find the statistical significance between two large netCDF data
sets.
Firstly I've loaded the two files into python:
swh=netCDF4.Dataset('/data/cr1/jmitchel/Q0/swh/controlperiod/averages/swh_control_concat.nc',
'r')
swh_2050s=netCDF4.Dataset('/data/cr1/jmitchel/Q0/swh/2050s/averages/swh_2050s_concat.nc',
'r')
I have then isolated the variables I want to perform the pearson correlation on:
hs=swh.variables['hs']
hs_2050s=swh_2050s.variables['hs']
Here is the metadata for those files:
print hs
int16 hs(time, latitude, longitude)
standard_name: significant_height_of_wind_and_swell_waves
long_name: significant_wave_height
units: m
add_offset: 0.0
scale_factor: 0.002
_FillValue: -32767
missing_value: -32767
unlimited dimensions: time
current shape = (86400, 350, 227)
print hs_2050s
int16 hs(time, latitude, longitude)
standard_name: significant_height_of_wind_and_swell_waves
long_name: significant_wave_height
units: m
add_offset: 0.0
scale_factor: 0.002
_FillValue: -32767
missing_value: -32767
unlimited dimensions: time
current shape = (86400, 350, 227)
Then to perform the pearsons correlation:
from scipy.stats.stats import pearsonr
pearsonr(hs,hs_2050s)
I then get a memory error:
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/sci/lib/python2.7/site-packages/scipy/stats/stats.py", line
2409, in pearsonr
x = np.asarray(x)
File "/usr/local/sci/lib/python2.7/site-packages/numpy/core/numeric.py", line
321, in asarray
return array(a, dtype, copy=False, order=order)
MemoryError
This also happens when I try to create numpy arrays from the data.
Does anyone know how I can alleviate theses memory errors?
Cheers,
Jamie
--
https://mail.python.org/mailman/listinfo/python-list
Re: Memory error
On Monday, March 24, 2014 11:32:31 AM UTC, Jamie Mitchell wrote:
> Hello all,
>
>
>
> I'm afraid I am new to all this so bear with me...
>
>
>
> I am looking to find the statistical significance between two large netCDF
> data sets.
>
>
>
> Firstly I've loaded the two files into python:
>
>
>
> swh=netCDF4.Dataset('/data/cr1/jmitchel/Q0/swh/controlperiod/averages/swh_control_concat.nc',
> 'r')
>
>
>
> swh_2050s=netCDF4.Dataset('/data/cr1/jmitchel/Q0/swh/2050s/averages/swh_2050s_concat.nc',
> 'r')
>
>
>
> I have then isolated the variables I want to perform the pearson correlation
> on:
>
>
>
> hs=swh.variables['hs']
>
>
>
> hs_2050s=swh_2050s.variables['hs']
>
>
>
> Here is the metadata for those files:
>
>
>
> print hs
>
>
>
> int16 hs(time, latitude, longitude)
>
> standard_name: significant_height_of_wind_and_swell_waves
>
> long_name: significant_wave_height
>
> units: m
>
> add_offset: 0.0
>
> scale_factor: 0.002
>
> _FillValue: -32767
>
> missing_value: -32767
>
> unlimited dimensions: time
>
> current shape = (86400, 350, 227)
>
>
>
> print hs_2050s
>
>
>
> int16 hs(time, latitude, longitude)
>
> standard_name: significant_height_of_wind_and_swell_waves
>
> long_name: significant_wave_height
>
> units: m
>
> add_offset: 0.0
>
> scale_factor: 0.002
>
> _FillValue: -32767
>
> missing_value: -32767
>
> unlimited dimensions: time
>
> current shape = (86400, 350, 227)
>
>
>
>
>
> Then to perform the pearsons correlation:
>
>
>
> from scipy.stats.stats import pearsonr
>
>
>
> pearsonr(hs,hs_2050s)
>
>
>
> I then get a memory error:
>
>
>
> Traceback (most recent call last):
>
> File "", line 1, in
>
> File "/usr/local/sci/lib/python2.7/site-packages/scipy/stats/stats.py",
> line 2409, in pearsonr
>
> x = np.asarray(x)
>
> File "/usr/local/sci/lib/python2.7/site-packages/numpy/core/numeric.py",
> line 321, in asarray
>
> return array(a, dtype, copy=False, order=order)
>
> MemoryError
>
>
>
> This also happens when I try to create numpy arrays from the data.
>
>
>
> Does anyone know how I can alleviate theses memory errors?
>
>
>
> Cheers,
>
>
>
> Jamie
Just realised that obviously pearson correlation requires two 1D arrays and
mine are 3D, silly mistake!
--
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 Mon, Mar 24, 2014 at 8:55 PM, Marko Rauhamaa wrote: > Ian Kelly : > >> If lambda were going to be deprecated and removed then it already >> would have happened in Python 3, because Guido tried to do precisely >> that. I'm not sure what the reasons were for keeping it in the end >> (according to PEP 3099 it was because nobody suggested a suitable >> replacement), but if he couldn't get rid of it then, he never will. > > You never *need* (Python's) lambda for anything. Inner functions are > more capable and almost always more readable. It doesn't hurt to have > lambda, but I don't find any use for it, either. They're often not more readable. A lot of people seem to equate "verbose" with "readable", possibly by faulty extrapolation from unreadably crunched code with one-letter variables and no line breaks. But which of these is truly more readable? squares = [] for n in range(30): squares.append(n * n) squares = [n * n for n in range(30)] Similarly, there are plenty of cases where a nameless function is MUCH clearer than breaking it out into a separate def and then using the name once. Do you name the function for what it does internally? def get_oneth_element_index(item): return item[1].index L.sort(key=get_oneth_element_index) Or for how you're using it? def keyfunc(item): return item[1].index L.sort(key=keyfunc) Or do you just shortcut the whole thing by inlining it? L.sort(key=lambda item:item[1].index) Hey look, that's weakref.py line 941 right there. (It happens to be the alphabetically last use of lambda in the stdlib. Made a good example, although it'd be more common to have a space after that colon.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re:gdb python how to output integer for examine memory
Wesley Wrote in message: > Hi all, > I am trying to use gdb debug python script. > I am using gdb7.7 and python2.7.6, here is my simple test script: > import time > > def next(i): > time.sleep(10) > i = 1 - i > > i = 1 > while True: > next(i) > When this script running, gdb attach to it, and here is snippet: > I cannot help with gdb, but I can point out that you have two separate variables here. Decrement ing the local has no effect on the global value. The preferred way is to return any values from the function that you want to use after it exits. def next(i): time.sleep(10) i = 1 - i return i i = 1 while True: i =next(i) Another possibility, generally a bad idea, is declaring i global in the function. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: Asyncio (or something better) for control of a vacuum system/components.
Hav you considered the option of a SCADA solution? There are many commercials solutions but also a few open source options such us: http://openscada.org/ http://pvbrowser.de/pvbrowser/index.php You may also ask the vacuum system provider, they should be aware of SCADA solutions supporting their communication protocols -- 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)
Chris Angelico : > Similarly, there are plenty of cases where a nameless function is MUCH > clearer than breaking it out into a separate def and then using the > name once. Do you name the function for what it does internally? > > def get_oneth_element_index(item): > return item[1].index > L.sort(key=get_oneth_element_index) > > Or for how you're using it? > > def keyfunc(item): > return item[1].index > L.sort(key=keyfunc) > > Or do you just shortcut the whole thing by inlining it? > > L.sort(key=lambda item:item[1].index) I still prefer the "def" variant. It even allows you to clarify the meaning of the tuple slot by using a nicer name. Marko -- 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 Mon, Mar 24, 2014 at 11:36 PM, Marko Rauhamaa wrote: >> def get_oneth_element_index(item): >> return item[1].index >> L.sort(key=get_oneth_element_index) >> >> Or do you just shortcut the whole thing by inlining it? >> >> L.sort(key=lambda item:item[1].index) > > I still prefer the "def" variant. It even allows you to clarify the > meaning of the tuple slot by using a nicer name. It's the index of element 1. What more do you need to know? Is it actually any help to give that a name? All you gain is a chance for the name, the purpose, and the functionality to come into disagreement. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: gdb python how to output integer for examine memory
Hi Dave, Thanks for your response. It's just a simple script for test:-) My concern is use gdb to monitor variable in memory within python process. For details, in my origin post, just wanna why cannot output interger value from the address. Maybe here is not right for gdb python question..but seems I cannot post question at another gdb group. So, post here, since it's also related to python,in case anyone knowns this. Sorry for that. Wesley 在 2014年3月24日星期一UTC+8下午8时22分59秒，Dave Angel写道： > Wesley Wrote in message: > > > Hi all, > > > I am trying to use gdb debug python script. > > > I am using gdb7.7 and python2.7.6, here is my simple test script: > > > import time > > > > > > def next(i): > > > time.sleep(10) > > > i = 1 - i > > > > > > i = 1 > > > while True: > > > next(i) > > > When this script running, gdb attach to it, and here is snippet: > > > > > > > I cannot help with gdb, but I can point out that you have two > > separate variables here. Decrement ing the local has no effect on > > the global value. > > > > The preferred way is to return any values from the function that > > you want to use after it exits. > > def next(i): > > time.sleep(10) > > i = 1 - i > > return i > > > > i = 1 > > while True: > > i =next(i) > > > > Another possibility, generally a bad idea, is declaring i global > > in the function. > > > > -- > > DaveA -- 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 Mon, 24 Mar 2014 22:49:38 +1100, Chris Angelico wrote: > On Mon, Mar 24, 2014 at 8:55 PM, Marko Rauhamaa > wrote: >> You never *need* (Python's) lambda for anything. Inner functions are >> more capable and almost always more readable. It doesn't hurt to have >> lambda, but I don't find any use for it, either. Marko has missed an obvious use: lambda is the *only* solution when you need a function embedded in an expression. You simply cannot do so otherwise. It is truly astonishing that two people here who are such keen supporters of functional programming, Marko and Mark Harris, are so dismissive of lambda, and so forced to write declarative code using def. > They're often not more readable. A lot of people seem to equate > "verbose" with "readable", possibly by faulty extrapolation from > unreadably crunched code with one-letter variables and no line breaks. > But which of these is truly more readable? > > squares = [] > for n in range(30): > squares.append(n * n) > > squares = [n * n for n in range(30)] Readable for whom? List comprehension syntax is often completely obscure to beginners. A beginner would say that the explicit for-loop is more readable. Actually, a *real* beginner, whose main programming experience before Python was Pascal, would probably even say that the first example was an unreadable mess. What's range(30)? What's this ".append" business? What does [] mean? I know this because I was this beginner, once. The first few times I tried reading Python code, I couldn't make head or tail of it. "for" I recognised, because it was the same keyword as Pascal and Hypertalk use. Pretty much everything else might as well have been Bulgarian. This was before the public internet, there was no Google, no tutorials I could look up. It was only after a colleague convinced me that it would be a good language to learn that I bought an actual dead tree book and sat down and learned how to read Python. I think that Python's reputation of being "executable pseudo-code" is sometimes harmful. It fools people into thinking that unless Aunt Tilly can understand a language feature, it's somehow a failure. Hence the arguments by Mark against lambda. http://www.catb.org/jargon/html/A/Aunt-Tillie.html But nobody expects Aunt Tilly to read Scheme or C++ or Go without at least a bit of learning -- or even Esperanto or French or Latin. You still need to learn the syntax and the vocabulary, and have some idea of the basic concepts. The same applies to Python. The learning curve may be more gentle, but there is still a learning curve. And that is perfectly fine. So while I agree with you that, to a moderately fluent Python speaker, not a beginner but not an expert either, the list comprehension is more readable, for a beginner (one who has a basic Python vocab but isn't fluent yet) the for-loop will probably be more readable. > Similarly, there are plenty of cases where a nameless function is MUCH > clearer than breaking it out into a separate def and then using the name > once. Do you name the function for what it does internally? > > def get_oneth_element_index(item): > return item[1].index > L.sort(key=get_oneth_element_index) > > Or for how you're using it? > > def keyfunc(item): > return item[1].index > L.sort(key=keyfunc) Why not both?! Don't forget to make it private so some other piece of code doesn't use it. Or better still, delete it when done! def _get_oneth_element_index_to_use_as_keyfunc_when_sorting_L(item): return item[1].index L.sort(key=_get_oneth_element_index_to_use_as_keyfunc_when_sorting_L) del _get_oneth_element_index_to_use_as_keyfunc_when_sorting_L Four lines of code to do what lambda lets you do in one. And people still insist that lambda is pointless. Maybe they're being paid by the line. > Or do you just shortcut the whole thing by inlining it? > > L.sort(key=lambda item:item[1].index) Exactly. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Question about Source Control
On Monday, March 17, 2014 6:36:33 PM UTC+5:30, Frank Millman wrote: > Hi all > I know I *should* be using a Source Control Management system, but at > present I am not. I tried to set up Mercurial a couple of years ago, but I > think I set it up wrongly, as I got myself confused and found it more of a > hindrance than a help. Now I am ready to try again, but I want to avoid my > earlier mistakes. > I understand the concept, and I understand the importance, so I do not need > reminding of those. What I would like help with is the basic setup. I could > subscribe to the Mercurial mailing list and ask there, but I am hoping for a > kick-start here. Here is my setup. > All my source code resides on an old Linux server, which I switch on in the > morning and switch off at night, but otherwise hardly ever look at. It uses > 'samba' to allow sharing with Windows, and 'nfs' to allow sharing with other > Linux machines. > I need to test my program on Windows and on Linux, so I run it from both at > various times. On Windows I have a 'mapped drive' pointing to the source > code. On Linux I use a third machine, running a recent Fedora, using nfs to > mount a directory pointing to the source code. Obviously each machine has > its own version of Python installed. > I do my development on the Windows machine. I use TextPad, a simple text > editor, which works fine for my purposes. It uses the mapped drive to point > to the source code. > So where should I install the SCM, and how should I set it up so that I can > access the latest version from any machine? > Any hints will be appreciated. Seen this?? Yeah may not apply directly to your use-case buts seems worth a read https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html [At command line $ git help -w workflows will give you the same ] -- 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 24/03/2014 12:36, Marko Rauhamaa wrote: Chris Angelico : Similarly, there are plenty of cases where a nameless function is MUCH clearer than breaking it out into a separate def and then using the name once. Do you name the function for what it does internally? def get_oneth_element_index(item): return item[1].index L.sort(key=get_oneth_element_index) Or for how you're using it? def keyfunc(item): return item[1].index L.sort(key=keyfunc) Or do you just shortcut the whole thing by inlining it? L.sort(key=lambda item:item[1].index) I still prefer the "def" variant. It even allows you to clarify the meaning of the tuple slot by using a nicer name. Each to their own. Here give me the lambda version any day of the week. -- 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: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Mon, 24 Mar 2014 23:53:12 +1100, Chris Angelico wrote: > On Mon, Mar 24, 2014 at 11:36 PM, Marko Rauhamaa > wrote: >>> def get_oneth_element_index(item): >>> return item[1].index >>> L.sort(key=get_oneth_element_index) >>> >>> Or do you just shortcut the whole thing by inlining it? >>> >>> L.sort(key=lambda item:item[1].index) >> >> I still prefer the "def" variant. It even allows you to clarify the >> meaning of the tuple slot by using a nicer name. > > It's the index of element 1. What more do you need to know? Is it > actually any help to give that a name? All you gain is a chance for the > name, the purpose, and the functionality to come into disagreement. # Magic constants are wicked. Never use a constant without naming it. ELEMENT_TO_USE_FOR_INDEXING_WHEN_SORTING_L = 1 # # key func used when sorting L, returns item's 1th elem index method # # #_get_oneth_element_index_to_use_as_keyfunc_when_sorting_L # # Steven D'Aprano # 2014-03-25 # 2014-03-25 # 1 # item to be sorted # index method of the oneth element # NameError # FIXME can this fail any other way? def _get_oneth_element_index_to_use_as_keyfunc_when_sorting_L(item): """Private key function for sorting list L. Returns the index method of element 1 of the given item. Example of use: >>> item = (None, '') >>> _get_oneth_element_index_to_use_as_keyfunc_when_sorting_L(item) Relies on global constant ELEMENT_TO_USE_FOR_INDEXING_WHEN_SORTING_L. May raise NameError if that constant is missing. Warning: do not use this for anything else. """ return item[ELEMENT_TO_USE_FOR_INDEXING_WHEN_SORTING_L].index L.sort(key=_get_oneth_element_index_to_use_as_keyfunc_when_sorting_L) del _get_oneth_element_index_to_use_as_keyfunc_when_sorting_L # Better to be safe than sorry. del ELEMENT_TO_USE_FOR_INDEXING_WHEN_SORTING_L Definitely being paid by the line :-) -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
TypeError in HMAC module.
Hi,
I am trying to create a hashed message for authentication for a REST API
call. I have got the key from a keyring as :-
key = keyring.get_password('AWS_keyring','username')
& calculating the signature as :-
signature = hmac(key, message.encode('UTF-8'),
hashlib.sha1).digest().encode('base64')[:-1]
But, while running the script I get the following errors :-
File "/usr/lib64/python2.6/hmac.py", line 133, in new
return HMAC(key, msg, digestmod)
File "/usr/lib64/python2.6/hmac.py", line 72, in __init__
*self.outer.update(key.translate(trans_5C))*
*TypeError: character mapping must return integer, None or unicode*
My python version is :-
# python -V
Python 2.6.9
Can someone please help me as to how I can resolve this issue. Thanks in
advance.
--
*Thanks and Regards*
*Prabir Sarkar*
--
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 24/03/2014 14:39, Steven D'Aprano wrote: On Mon, 24 Mar 2014 23:53:12 +1100, Chris Angelico wrote: On Mon, Mar 24, 2014 at 11:36 PM, Marko Rauhamaa wrote: def get_oneth_element_index(item): return item[1].index L.sort(key=get_oneth_element_index) Or do you just shortcut the whole thing by inlining it? L.sort(key=lambda item:item[1].index) I still prefer the "def" variant. It even allows you to clarify the meaning of the tuple slot by using a nicer name. It's the index of element 1. What more do you need to know? Is it actually any help to give that a name? All you gain is a chance for the name, the purpose, and the functionality to come into disagreement. # Magic constants are wicked. Never use a constant without naming it. ELEMENT_TO_USE_FOR_INDEXING_WHEN_SORTING_L = 1 # # key func used when sorting L, returns item's 1th elem index method # # #_get_oneth_element_index_to_use_as_keyfunc_when_sorting_L # # Steven D'Aprano # 2014-03-25 # 2014-03-25 # 1 # item to be sorted # index method of the oneth element # NameError # FIXME can this fail any other way? def _get_oneth_element_index_to_use_as_keyfunc_when_sorting_L(item): """Private key function for sorting list L. Returns the index method of element 1 of the given item. Example of use: >>> item = (None, '') >>> _get_oneth_element_index_to_use_as_keyfunc_when_sorting_L(item) Relies on global constant ELEMENT_TO_USE_FOR_INDEXING_WHEN_SORTING_L. May raise NameError if that constant is missing. Warning: do not use this for anything else. """ return item[ELEMENT_TO_USE_FOR_INDEXING_WHEN_SORTING_L].index L.sort(key=_get_oneth_element_index_to_use_as_keyfunc_when_sorting_L) del _get_oneth_element_index_to_use_as_keyfunc_when_sorting_L # Better to be safe than sorry. del ELEMENT_TO_USE_FOR_INDEXING_WHEN_SORTING_L Definitely being paid by the line :-) One of the finest examples of extracting the urine I've ever read. Please keep up the good work. Ah but wait, down voted on the grounds that there are no unit tests and, far more importantly, it doesn't fit on one line (unless you use gg that is). There is also no proof that it's been committed to your source control system after going through its code review. -- 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: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Monday, March 24, 2014 7:34:59 PM UTC+5:30, Steven D'Aprano wrote: > On Mon, 24 Mar 2014 22:49:38 +1100, Chris Angelico wrote: > > wrote: > >> You never *need* (Python's) lambda for anything. Inner functions are > >> more capable and almost always more readable. It doesn't hurt to have > >> lambda, but I don't find any use for it, either. > Marko has missed an obvious use: lambda is the *only* solution when you > need a function embedded in an expression. You simply cannot do so > otherwise. It is truly astonishing that two people here who are such keen > supporters of functional programming, Marko and Mark Harris, are so > dismissive of lambda, and so forced to write declarative code using def. > > They're often not more readable. A lot of people seem to equate > > "verbose" with "readable", possibly by faulty extrapolation from > > unreadably crunched code with one-letter variables and no line breaks. > > But which of these is truly more readable? > > squares = [] > > for n in range(30): > > squares.append(n * n) > > squares = [n * n for n in range(30)] > Readable for whom? > List comprehension syntax is often completely obscure to beginners. A > beginner would say that the explicit for-loop is more readable. > Actually, a *real* beginner, whose main programming experience before > Python was Pascal, would probably even say that the first example was an > unreadable mess. What's range(30)? What's this ".append" business? What > does [] mean? I know this because I was this beginner, once. The first > few times I tried reading Python code, I couldn't make head or tail of > it. "for" I recognised, because it was the same keyword as Pascal and > Hypertalk use. Pretty much everything else might as well have been > Bulgarian. > This was before the public internet, there was no Google, no tutorials I > could look up. It was only after a colleague convinced me that it would > be a good language to learn that I bought an actual dead tree book and > sat down and learned how to read Python. > I think that Python's reputation of being "executable pseudo-code" is > sometimes harmful. It fools people into thinking that unless Aunt Tilly > can understand a language feature, it's somehow a failure. Hence the > arguments by Mark against lambda. > http://www.catb.org/jargon/html/A/Aunt-Tillie.html > But nobody expects Aunt Tilly to read Scheme or C++ or Go without at > least a bit of learning -- or even Esperanto or French or Latin. You > still need to learn the syntax and the vocabulary, and have some idea of > the basic concepts. The same applies to Python. The learning curve may be > more gentle, but there is still a learning curve. And that is perfectly > fine. Ok so far > So while I agree with you that, to a moderately fluent Python speaker, > not a beginner but not an expert either, the list comprehension is more > readable, for a beginner (one who has a basic Python vocab but isn't > fluent yet) the for-loop will probably be more readable. And now I wonder... The case you are wanting to make and the case you are ending up making seem to be opposite: If it is so as you say that for "the beginner (one who has a basic Python vocab but isn't fluent yet)" the for-loop is more readable than the for-in-compr it then suggests that those more experienced taking/helping the beginners at 0 to the stage of "basic vocab-but-not-yet fluent" are choosing a sub-optimal route. Remember that you started by reminding that for an absolute beginner, everything is 'Bulgarian' not just list comprehensions. Then how come some things become accessible faster than others? It may be that those things are actually easier (in some objective sense) But it may also reveal a prejudice of the teachers. As for the other argument -- python lambda is BAD -- Ive currently run out of pepper for sprinkling on these flames :-) I'll just make a few points: 1. Miranda the predecessor of Haskell had no lambda. Local defs + curried convention + operator sections was considered more than sufficient for functional programming 2. Lisp was the originator of lambda (in programming languages) and it screwed up the semantics so badly that a. It had to be corrected at high cost 25 years later -- aka scheme and common lisp b. Some doyens of functional programming have suggested that lisp is a major setback for the acceptance of functional programming, eg http://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.pdf 3. One basic tenet of λ calculus foo = λ x . exp is equivalent to the more traditional foo(x) = exp is a little uh-uh in haskell thanks to the notorious monomorphism restriction http://www.haskell.org/haskellwiki/Monomorphism_restriction So if FP = λ calculus, Haskell does not quite make it!! -- https://mail.python.org/mailman/listinfo/python-list
String modifying error, trying to delete data in string
Here is some code:
import socket,sys
s=socket.socket()
port=int(sys.argv[1])
s.bind(("127.0.0.1",port))
s.listen(2)
cls,addr=s.accept()
data=cls.recv(1024)
f=data.pop("Proxy-Connection")
cls.close()
Im trying to delete some headers in the request but get an error saying:
'str' object has no attribute 'pop'
How can I modify data received from the client?
--
https://mail.python.org/mailman/listinfo/python-list
Re: String modifying error, trying to delete data in string
On 24/03/2014 16:20, mikie wrote:
Here is some code:
import socket,sys
s=socket.socket()
port=int(sys.argv[1])
s.bind(("127.0.0.1",port))
s.listen(2)
cls,addr=s.accept()
data=cls.recv(1024)
f=data.pop("Proxy-Connection")
cls.close()
Im trying to delete some headers in the request but get an error saying:
'str' object has no attribute 'pop'
How can I modify data received from the client?
Strings are immutable so you'll need string methods to manipulate your
data see
http://docs.python.org/3/library/stdtypes.html#text-sequence-type-str
--
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: String modifying error, trying to delete data in string
On Mon, 24 Mar 2014 09:20:26 -0700, mikie wrote:
> Im trying to delete some headers in the request but get an error saying:
> 'str' object has no attribute 'pop'
What sort of object is data? What do you expect it to be, and what it is
actually?
Given that you are calling data.pop("Proxy-Connection"), that suggests to
me that you think data is a dict. The error message given tells you that
data is a str.
> How can I modify data received from the client?
The same as any string: make a copy with whatever modifications you want.
Strings have a replace method; you can use the re module to use regexes;
you can slice them with some_string[start:end] syntax, etc. But it looks
to me like you might be better off using a higher-level protocol rather
than using socket. What sort of data are you expecting back?
--
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 Mon, Mar 24, 2014 at 3:55 AM, Marko Rauhamaa wrote: > Ian Kelly : > >> If lambda were going to be deprecated and removed then it already >> would have happened in Python 3, because Guido tried to do precisely >> that. I'm not sure what the reasons were for keeping it in the end >> (according to PEP 3099 it was because nobody suggested a suitable >> replacement), but if he couldn't get rid of it then, he never will. > > You never *need* (Python's) lambda for anything. Inner functions are > more capable and almost always more readable. It doesn't hurt to have > lambda, but I don't find any use for it, either. So what? One might say the same thing about comprehensions -- loops are more capable and almost always more readable. -- https://mail.python.org/mailman/listinfo/python-list
Merge/append CSV files with different headers
I have several csv file I need to append (vertically). They have different
but overlapping headers. For example;
file1 headers ['a', 'b', 'c']
file2 headers ['d', 'e']
file3 headers ['c', 'd']
Is there a better way than this
import csv
def merge_csv(fileList, newFileName):
allHeaders = set([])
for afile in fileList:
with open(afile, 'rb') as csvfilesin:
eachheader = csv.reader(csvfilesin, delimiter=',').next()
allHeaders.update(eachheader)
print(allHeaders)
with open(newFileName, 'wb') as csvfileout:
outfile = csv.DictWriter(csvfileout, allHeaders)
outfile.writeheader()
for afile in fileList:
print('***'+afile)
with open(afile, 'rb') as csvfilesin:
rows = csv.DictReader(csvfilesin, delimiter=',')
for r in rows:
print(allHeaders.issuperset(r.keys()))
outfile.writerow(r)
Vincent Davis
--
https://mail.python.org/mailman/listinfo/python-list
Re: Merge/append CSV files with different headers
On 24/03/2014 17:50, Vincent Davis wrote:
I have several csv file I need to append (vertically). They have
different but overlapping headers. For example;
file1 headers ['a', 'b', 'c']
file2 headers ['d', 'e']
file3 headers ['c', 'd']
Is there a better way than this
import csv
def merge_csv(fileList, newFileName):
allHeaders = set([])
for afile in fileList:
with open(afile, 'rb') as csvfilesin:
eachheader = csv.reader(csvfilesin, delimiter=',').next()
allHeaders.update(eachheader)
print(allHeaders)
with open(newFileName, 'wb') as csvfileout:
outfile = csv.DictWriter(csvfileout, allHeaders)
outfile.writeheader()
for afile in fileList:
print('***'+afile)
with open(afile, 'rb') as csvfilesin:
rows = csv.DictReader(csvfilesin, delimiter=',')
for r in rows:
print(allHeaders.issuperset(r.keys()))
outfile.writerow(r)
Vincent Davis
I haven't looked too hard at your code but guess you could simplify it
by using the fieldnames parameter to the DictReader class or making use
of the Sniffer class. See
http://docs.python.org/3/library/csv.html#module-csv
--
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: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 3/24/14 4:58 AM, Mark Lawrence wrote:
Where do you get reduce from if it's not in the standard library?
That was "a" proposal for 3000. Its there, but its not on the
built-ins; ie., you have to import it. The confusion: why reduce, why
not filter, nor map? {rhetorical}
As for lambda I've no real interest in it, other than when copying examples
where it's used to (say) provide a key function.
This is one of my main points to Steven. In my experience "most" people
do not intend to use lambda for anything; they are trying to sort this
or that and don't quite know how to get the key right and some helpful
somebody gives them a key=lambda yadda yadda . They use it, and it
works, but they are scratching their head saying to themselves, "what it
that, how does it work, how can I understand it and on and on".
That is what we mean by confusing. Or another really great example is
this thread. Somebody asks about a language feature and somebody else
helpfully answers the question by providing them with a similar lambda!!
Its the programmer's equivalent of explanation by reference to a more
complicated analogy; which leaves the OP left with, "Thanks for all the
responses".
marcus
PS You are absolutely right, all the expanding double spaces become
very annoying when viewed on Thunderbird; it is exasperating, genuinely.
--
https://mail.python.org/mailman/listinfo/python-list
Re: TypeError in HMAC module.
On Tue, Mar 25, 2014 at 2:15 AM, Prabir Kr Sarkar
wrote:
> Hi,
>I am trying to create a hashed message for authentication for a REST API
> call. I have got the key from a keyring as :-
>
> key = keyring.get_password('AWS_keyring','username')
>
> & calculating the signature as :-
> signature = hmac(key, message.encode('UTF-8'),
> hashlib.sha1).digest().encode('base64')[:-1]
I can't "import keyring", so either that's a module that isn't in the
Python standard library, or "keyring" is some object you've
instantiated. My crystal ball says this might be something to do with
Amazon Web Services, but it's hard to be sure. Can you please help us
out here by telling us all the dependencies of your code, and also
showing us a complete runnable program?
http://www.sscce.org/
Thanks!
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 Tue, Mar 25, 2014 at 1:04 AM, Steven D'Aprano wrote: >> But which of these is truly more readable? >> >> squares = [] >> for n in range(30): >> squares.append(n * n) >> >> squares = [n * n for n in range(30)] > > Readable for whom? > > List comprehension syntax is often completely obscure to beginners. A > beginner would say that the explicit for-loop is more readable. > > Actually, a *real* beginner, whose main programming experience before > Python was Pascal, would probably even say that the first example was an > unreadable mess. What's range(30)? What's this ".append" business? What > does [] mean? I know this because I was this beginner, once. The first > few times I tried reading Python code, I couldn't make head or tail of > it. "for" I recognised, because it was the same keyword as Pascal and > Hypertalk use. Pretty much everything else might as well have been > Bulgarian. Actually, that's a very good point. Python's for loop is more often called a foreach loop in other languages, and Python completely lacks any concept of a "classic" iteration-over-integer for loop. That is a point of confusion. However, that's going to come up on both branches, so it's not really a mark against either. Incidentally, I've often modified my loop counter, in C or REXX or any other language. About the only situation where I actually miss it in Python, though, is iterating over a list and mutating the list on the way through; and even that can often be done in other ways (maybe a list comp, filtering out some of the elements?). It's amazing how something can be so utterly fundamental (I mean, come ON! Who can imagine a language with no equivalent of the basic "do i=1 to 10" (REXX) or "for (int i=0;i<10;++i)" (C++) loop???) and yet so dispensable. 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 24/03/2014 18:58, Mark H Harris wrote:
On 3/24/14 4:58 AM, Mark Lawrence wrote:
Where do you get reduce from if it's not in the standard library?
That was "a" proposal for 3000. Its there, but its not on the
built-ins; ie., you have to import it. The confusion: why reduce, why
not filter, nor map? {rhetorical}
So it is in the standard library then. And I'm not confused, seeing
this must have been decided years ago as Python 3 was released some five
years ago.
As for lambda I've no real interest in it, other than when copying
examples
where it's used to (say) provide a key function.
This is one of my main points to Steven. In my experience "most" people
do not intend to use lambda for anything; they are trying to sort this
or that and don't quite know how to get the key right and some helpful
somebody gives them a key=lambda yadda yadda . They use it, and it
works, but they are scratching their head saying to themselves, "what it
that, how does it work, how can I understand it and on and on".
More fool them, I write Python as I let it take away the head
scratching, not add to it. If I wanted to start head scratching maybe
I'd go and investigate what line 247 of gcmodule.c does, but funnily
enough I've never been there, and don't intend starting now.
That is what we mean by confusing. Or another really great example is
this thread. Somebody asks about a language feature and somebody else
helpfully answers the question by providing them with a similar lambda!!
One of the joys of this list from my POV, YMMV.
Its the programmer's equivalent of explanation by reference to a more
complicated analogy; which leaves the OP left with, "Thanks for all the
responses".
marcus
PS You are absolutely right, all the expanding double spaces become
very annoying when viewed on Thunderbird; it is exasperating, genuinely.
Yep, but like I said the situation has improved, partly thanks to the
guys who improved the words on the wiki showing how to successfuly use
gg. Thanks fellas :)
--
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: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Mon, Mar 24, 2014 at 12:58 PM, Mark H Harris wrote: > That is what we mean by confusing. Or another really great example is this > thread. Somebody asks about a language feature and somebody else helpfully > answers the question by providing them with a similar lambda!! That is not in fact how the topic of lambda arose in this thread. Rustom Mody brought up the binding behavior in a tangent specifically to complain about it, and that was the first mention of lambda in the thread. -- 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 Tue, Mar 25, 2014 at 5:58 AM, Mark H Harris wrote:
> Its there, but its not on the built-ins; ie., you have to import it. The
> confusion: why reduce, why not filter, nor map? {rhetorical}
In other languages with those three, and without list/array
comprehensions, I've used filter occasionally and map reasonably
often, but I don't remember the last time I used reduce. Actually,
Pike has special syntax that can take the place of map sometimes, so I
might use filter more often than map in Pike code, because these don't
need explicit map calls:
//Suppose that clients is an array of connected clients on some server
clients->sockets->write("System message: blah blah blah\n");
Indexing an array (the -> is like Python's . as Pike's . is resolved
at compile time) produces an array, effectively mapping the elements
through "lambda x: x->sockets" and ditto for "->write". Calling an
array calls all the non-empty elements in it, with the same
argument(s), and produces an array of return values. (In this case, I
don't care about the return values, which will simply be the number of
bytes written to each socket. If there's a problem, it'll throw an
exception.) Huh. Even with that, and the [*] automap syntax, and such,
I still use map far more often than filter... and filter orders of
magnitude more often than reduce.
Aside: You'll often hear people talking about "map-reduce" with big
data. Python supports that. Look!
>>> map.__reduce__
Oh wait, that's nothing to do with reduce()...
*ducks for cover*
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 Mon, Mar 24, 2014 at 1:12 PM, Chris Angelico wrote: > Incidentally, I've often modified my loop counter, in C or REXX or any > other language. About the only situation where I actually miss it in > Python, though, is iterating over a list and mutating the list on the > way through; and even that can often be done in other ways (maybe a > list comp, filtering out some of the elements?). It's amazing how > something can be so utterly fundamental (I mean, come ON! Who can > imagine a language with no equivalent of the basic "do i=1 to 10" > (REXX) or "for (int i=0;i<10;++i)" (C++) loop???) and yet so > dispensable. I'm not sure "fundamental" is the right word. A for loop is just a while loop with some syntactic sugar. For that matter, a while loop is just a structured goto... -- https://mail.python.org/mailman/listinfo/python-list
Re: Merge/append CSV files with different headers
On Tue, Mar 25, 2014 at 4:50 AM, Vincent Davis wrote: > I have several csv file I need to append (vertically). They have different > but overlapping headers. For example; > file1 headers ['a', 'b', 'c'] > file2 headers ['d', 'e'] > file3 headers ['c', 'd'] > > Is there a better way than this Summary of your code: 1) Build up a set of all headers used, by opening each file and reading the headers. 2) Go through each file a second time and write them out. That seems like the best approach, broadly. You might be able to improve it a bit (it might be tidier to open each file once, but since you're using two different CSV readers, it'd probably not be), but by and large, I'd say you have the right technique. Your processing time here is going to be dominated by the actual work of copying. The only thing you might want to consider is order. The headers all have a set order to them, and it'd make sense to have the output come out as ['a', 'b', 'c', 'd', 'e'] - the first three from the first file, then adding in everything from subsequent files in the order they were found. Could be done easily enough by using 'in' and .append() on a list, rather than using a set. But if that doesn't matter to you, or if something simple like "sort the headers alphabetically" will do, then I think you basically have what you want. 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 Tue, Mar 25, 2014 at 6:13 AM, Mark Lawrence wrote:
>> That was "a" proposal for 3000. Its there, but its not on the
>> built-ins; ie., you have to import it. The confusion: why reduce, why
>> not filter, nor map? {rhetorical}
>
>
> So it is in the standard library then. And I'm not confused, seeing this
> must have been decided years ago as Python 3 was released some five years
> ago.
Terminology issue, is all. It's not in the builtins, but it is in the
standard library.
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 3/24/14 4:49 AM, Steven D'Aprano wrote:
There's no doubt that lambda is less-often useful than is the def
statement. But not only is it still useful, but there is a continual
stream of people asking for Python to make it *more useful* by allowing
the body of a lambda to be a full block, not just a single statement.
Guido has stated (although I cannot remember where, so cannot paste a
link) that he accepts that in principle, so long as somebody comes up
with acceptable syntax.
Now, this will seem strange to you, but if lambda were expanded to
include an entire block, well now, I would know two things:
1) python has commitment to lambdaand
2) lambda would become WAY more useful... ie., the only way to have a
"block expression" embedded in an expression ! I'd vote for that. But
as someone else noted, inner functions work as well (now) and are really
more readable, so ...
It's used in calendar, cgitb, configparser, difflib, decimal, functools,
inspect, os, pydoc and others. Python is a programming language aimed at
programmers, not a toy. It should include tools that programmers use,
like threads, closures, first-class functions. And lambda.
This is a valid point (its used a couple of hundred times). It could
be replaced in probably of week of constant programming effort. Neither
here nor there, because nobody at this point is demanding it.
Lambda is a problem of confusion for scientists and other
mathematicians (amateur and otherwise) {snip}
{snip}
But nor should the confusion of somebody
who doesn't know the language count for much.
This is the main disagreement between the two of us on this topic.
It should count for TONS; whole metric TONs. Because someone who
understands python primarily, and after five years of coding (say me)
somebody tells (me) to use lambda in a key clause so that my sort will
work, or work better, or work "their" way; and I have no idea why I need
this nameless function (after I find out that "that" is what it is!)
Its confusing, and please contrast between complicated. I don't mind
complicated, or extensive, or even hard, but when something is
needlessly confusing, then why?
Python's ints don't work exactly the same as ints do in some other
languages, nor do Python's strings, nor is Python's object model
precisely the same as that of some other languages. I think that it would
be a ridiculous idea to discard int, str and the entire object system
just because some people are surprised that Python doesn't behave exactly
like some other language. I don't think lambda is any different.
Your logic is faulty here. Conceptually python's lambda doesn't
work as expected, from contexts that define lambda and where lambda in
functional programming is VERY important. For one thing, why would we
want to "spell out" the word "lambda".( \x y -> x + y ) a b )
If we're going to use lambda, then use it.
Other languages -- not even Lisp -- don't get to be the sole decider as
to what counts as an anonymous function. Python's lambda may be limited,
but it is a perfectly fine lambda for what it is intended to do.
Is that the same as George W. Bush's "decider" ?
I agree, and so does the link I referenced, for what it was designed
to do, its powerful; esp if one needs to embed a function in an
expression; that is what lambda is for.
Its also confusing to sophisticated users of all
stripes who may not be aware of "lambda" at all.
If they're not aware of lambda, how are they confused by it?
See above. They are recommended its use (maybe on this list) and
they just don't get it; because its unnecessarily confusing.
No, not really. I don't understand who your intended audience for Python
is. If I were to try to guess, I suspect that you want to dumb Python
down until it is like Dartmouth BASIC circa 1980 except without the line
numbers and with a slightly different syntax. Perhaps I'm wrong, I
certainly hope I'm wrong, but that's the impression I got from your
comments on the python-ideas list.
Actually it was circa 1964. Actually, it was precisely 1964 (I was
there).
No, I'm not advocating for dumb-down simplicity. Aristotle said that
virtue is found at the mean. Either end of the spectrum is a problem
(overly complicated, towards overly simplified) those end-points we must
flee like the black plague. Normal people with reasonable training
(college education) should be able to use python easily without
confusion and without a computer science degree. Programming should be a
liberal art available to everyone in the set of all "normal" educated
people. Some developers (themselves perhaps with degrees Ph.D. in
mathematics or computer science) forget about the fact that "normal"
educated people want to leverage their computer (maybe with python) for
problem solution without having to become a professional computer
scientist. I am advocating for those people.
You want to remove lambda because
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Tue, Mar 25, 2014 at 6:42 AM, Ian Kelly wrote: > On Mon, Mar 24, 2014 at 1:12 PM, Chris Angelico wrote: >> Incidentally, I've often modified my loop counter, in C or REXX or any >> other language. About the only situation where I actually miss it in >> Python, though, is iterating over a list and mutating the list on the >> way through; and even that can often be done in other ways (maybe a >> list comp, filtering out some of the elements?). It's amazing how >> something can be so utterly fundamental (I mean, come ON! Who can >> imagine a language with no equivalent of the basic "do i=1 to 10" >> (REXX) or "for (int i=0;i<10;++i)" (C++) loop???) and yet so >> dispensable. > > I'm not sure "fundamental" is the right word. A for loop is just a > while loop with some syntactic sugar. For that matter, a while loop > is just a structured goto... Of course, and function calls are just stack operations and gotos too. That's not what makes it fundamental - I'm talking at a source code level. Can you imagine a high level language without a simple notation for variable assignment? Certainly not. [1] Variable assignment, name binding, whatever you call it, is fundamental. Some kind of structured looping is also pretty critical; you don't see languages that force you to use bare goto everywhere and call themselves "high level". [2] Every high level language also needs some way to iterate over numbers. Most of them provide it as an intrinsic; Python happens to do it as a foreach over an easily-constructed iterable. ChrisA [1] DeScribe Macro Language would borderline-fail this test if I called it a HLL. It has "SET something TO somevalue". But DML is about on the level of Python's "dis.dis" output - assembly language for a byte-code interpreter. [2] DML passes this test, even. It has a block IF/ELSE/END IF statement, and a REPEAT/END REPEAT for looping, with the loop condition being provided by a statement "EXIT WHEN condition" that's like Python's "if condition: break". Mind you, it also provides language-level support for message boxes, including prompt boxes (ask the user to provide a string or integer), so it's a bit of an odd duck. -- https://mail.python.org/mailman/listinfo/python-list
advice on sub-classing multiprocessing.Process and multiprocessing.BaseManager
I'm maintaining a python interface to a C library for a distributed control system (EPICS, sort of a SCADA system) that does a large amount of relatively light-weight network I/O. In order to keep many connections open and responsive, and to provide a simple interface, the python library keeps a global store of connection state. This works well for single processes and threads, but not so well for multiprocessing, where the global state causes trouble. The issue is not too difficult to work around (ie, completely clear any such global cache and insist that new connections be established in each process), but easy to forget. To make this easier, I have a function to clear the global cache, def clear_my_cache(): # empty global variables caching network connections return and then subclass of multiprocessing.Process like: class MyProcess(multiprocessing.Process): def __init__(self, **kws): multiprocessing.Process.__init__(self, **kws) def run(self): clear_my_cache() mp.Process.run(self) This works fine. I can subclass multiprocessing.pool.Pool too, as it uses Process as a class variable (removing doc strings): class Pool(object): Process = Process def __init__(self, processes=None, initializer=None, initargs=(), maxtasksperchild=None): and then uses self.Process in its Pool._repopulate_pool(). That makes subclassing Pool is as easy as (removing doc strings): class MyPool(multiprocssing.pool.Pool): def __init__(self, **kws): self.Process = MyProcess mp_pool.Pool.__init__(self, **kws) I'm very pleased to need so little code here! But, I run into trouble when I try to subclass any of the Managers(). It looks like I would have to make a nearly-identical copy of ~30 lines of BaseManager.start() as it calls multiprocessing.Process() to create processes there. In addition, it looks like subclassing multiprocessing.managers.SyncManager would mean making a near-identical copy of a similar amount of code. I'd be willing to do this, but it seems like a bad idea -- I much prefer overwriting self.Process as for Pool. Does anyone have any advice for the best approach here? Should, like Pool, BaseManager also use a class variable (Process = Process)? Thanks in advance for any advice. --Matt -- https://mail.python.org/mailman/listinfo/python-list
How to clear all content in a Tk()
I have this program, and since I want to change stuff dynamically, I want to fully clear the root = Tk(), without deleting it. Is there a way to do so? -- https://mail.python.org/mailman/listinfo/python-list
Re: Memory error
On 03/24/2014 04:32 AM, Jamie Mitchell wrote:
Hello all,
I'm afraid I am new to all this so bear with me...
I am looking to find the statistical significance between two large netCDF data
sets.
Firstly I've loaded the two files into python:
swh=netCDF4.Dataset('/data/cr1/jmitchel/Q0/swh/controlperiod/averages/swh_control_concat.nc',
'r')
swh_2050s=netCDF4.Dataset('/data/cr1/jmitchel/Q0/swh/2050s/averages/swh_2050s_concat.nc',
'r')
I have then isolated the variables I want to perform the pearson correlation on:
hs=swh.variables['hs']
hs_2050s=swh_2050s.variables['hs']
This is not really a Python question. It's a question about netCDF
(whatever that may be), or perhaps it's interface to Python python-netCD4.
You may get an answer here, but you are far more likely to get one
quickly and accurately from a forum dedicated to netCDF, or python-netCD.
Good luck.
Gary Herron
--
https://mail.python.org/mailman/listinfo/python-list
Python developer salary survey - results
PyStreet's February salary survey attracted respondents from 37 countries. Median annual salary in the U.S.: $95,000 Median annual salary worldwide: $50,000 Complete study: http://bit.ly/1dgCw3p -- https://mail.python.org/mailman/listinfo/python-list
Re: Merge/append CSV files with different headers
Thanks for the feedback. Vincent Davis 720-301-3003 On Mon, Mar 24, 2014 at 1:44 PM, Chris Angelico wrote: > On Tue, Mar 25, 2014 at 4:50 AM, Vincent Davis > wrote: > > I have several csv file I need to append (vertically). They have > different > > but overlapping headers. For example; > > file1 headers ['a', 'b', 'c'] > > file2 headers ['d', 'e'] > > file3 headers ['c', 'd'] > > > > Is there a better way than this > > Summary of your code: > > 1) Build up a set of all headers used, by opening each file and > reading the headers. > 2) Go through each file a second time and write them out. > > That seems like the best approach, broadly. You might be able to > improve it a bit (it might be tidier to open each file once, but since > you're using two different CSV readers, it'd probably not be), but by > and large, I'd say you have the right technique. Your processing time > here is going to be dominated by the actual work of copying. > > The only thing you might want to consider is order. The headers all > have a set order to them, and it'd make sense to have the output come > out as ['a', 'b', 'c', 'd', 'e'] - the first three from the first > file, then adding in everything from subsequent files in the order > they were found. Could be done easily enough by using 'in' and > .append() on a list, rather than using a set. But if that doesn't > matter to you, or if something simple like "sort the headers > alphabetically" will do, then I think you basically have what you > want. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list > -- 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/24/14 4:03 AM, Ian Kelly wrote:
The difference does not really lie in the lambda construct per se but in
the binding style of closures. Functional languages tend to go one way
here; imperative languages tend to go the other. {snip}
The result may be more surprising to users accustomed to functional
languages, but I claim that it is *less* surprising to users of other
imperative languages.
Aside from the sin of spelling out "lambda,"
should be ( \x y -> x + y ) a b ) but, neither here nor there...
Yes, its about closures, totally; the most confusing aspect of
lambda in python is not only the syntax but the idea of scope and
closure (for that syntax). Everyone is confused by this initially, not
because its complicated, but because its confusing. An example:
adders= list(range(4))
adders
[0, 1, 2, 3]
for n in adders:
adders[n]=lambda a: a+n
print(adders[1](3))
6
The expected value as perceived by "normal" people is 4.
This comes up on the list over and again year after year in various
flavors, but always because lambda is unnecessarily confusing where it
comes to how does it function; and by that we mean simply, how does
scope and closure work in this context. Once the "normal" person is
introduced to the scope and closure idiosyncrasies of pythons lambda,
well then everything is much smoother. But how to fix? Consider:
adders= list(range(4))
adders
[0, 1, 2, 3]
for n in adders:
adders[n] = (lambda b: lambda a: b + a)(n)
adders[1](3)
4
adders[2](3)
5
Now, here is where I talk about confusion; explaining why the first
lambda above does not work because of scope and closure, and then even
worse, explaining why the second "double" lambda works in the lower
example!
Its a nightmare, really.
And you are correct, its really about closure.
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)
Mark H Harris : >Yes, its about closures, totally; the most confusing aspect of > lambda in python is not only the syntax but the idea of scope and > closure (for that syntax). Everyone is confused by this initially, not > because its complicated, but because its confusing. An example: > > adders= list(range(4)) > for n in adders: >> adders[n]=lambda a: a+n > print(adders[1](3)) >> 6 > >The expected value as perceived by "normal" people is 4. 1. No, I don't think that understanding is automatically natural. 2. It does not concern Python only. For example, what does this scheme expression yield? ((let ((n 3)) (let ((f (lambda () n))) (set! n 7) f))) Answer: 7 3. It doesn't concern lambda only. For example, rewrite your loop like this: for n in range(4): def add(a): return a + n adders[n] = add adders[1](3) => 6 Marko -- 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 Tue, 25 Mar 2014 06:22:28 +1100, Chris Angelico wrote: > Aside: You'll often hear people talking about "map-reduce" with big > data. Python supports that. Look! > map.__reduce__ > > > Oh wait, that's nothing to do with reduce()... > > *ducks for cover* Ha ha, very funny :-P http://code.activestate.com/recipes/577676-dirt-simple-mapreduce/ -- 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 Tue, Mar 25, 2014 at 8:43 AM, Mark H Harris wrote: >> adders[n] = (lambda b: lambda a: b + a)(n) > >Now, here is where I talk about confusion; explaining why the first > lambda above does not work because of scope and closure, and then even > worse, explaining why the second "double" lambda works in the lower example! Easy fix. Use the "explicit capture" notation: adders[n] = lambda a, n=n: a+n And there you are, out of your difficulty at once! 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 Tue, Mar 25, 2014 at 9:58 AM, Steven D'Aprano wrote: > On Tue, 25 Mar 2014 06:22:28 +1100, Chris Angelico wrote: > >> Aside: You'll often hear people talking about "map-reduce" with big >> data. Python supports that. Look! >> > map.__reduce__ >> >> >> Oh wait, that's nothing to do with reduce()... >> >> *ducks for cover* > > Ha ha, very funny :-P > > > http://code.activestate.com/recipes/577676-dirt-simple-mapreduce/ That looks like a more serious map/reduce example. Mine came from a double-take when I was looking at help(map) for some reason; there's a __round__ magic method that helps define the round() function, there's __abs__ for abs(), there's __str__ for str()... look, there's a __reduce__ - it must be to help define reduce()! :) 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 3/24/14 6:01 PM, Chris Angelico wrote: Easy fix. Use the "explicit capture" notation: adders[n] = lambda a, n=n: a+n And there you are, out of your difficulty at once! Yes, yes, yes, and example: adders= list(range(4)) for n in adders: >adders[n] = lambda a, n=n: a+n > > adders[1](3) >4 adders[2](3) >5 But, and this is the big (WHY?) is that necessary? In other words, its not about experts knowing how to make this work, its about "normal" people not understanding in the first place why its a problem, and why the various solutions work to fix it; even though "we" all know that nothing is 'broken'. And in reference to Marko's post, he's right, its not just python, but the issue is not where else is capture and scope a problem for confusion, the issue is whether python's lambda provides a significant opportunity for confusion that in the larger scheme of things (no pun intended) is not warranted. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Reading in cooked mode (was Re: Python MSI not installing, log file showing name of a Viatnemese communist revolutionary)
On 3/24/14 6:30 PM, Dennis Lee Bieber wrote:
{And I recall standard practice was to hit \r, to return the carriage, \n
for next line, and one RUBOUT to provide a delay while the carriage
returned to the left}
Yes, yes... I remember well, there had to be a delay (of some type) to
wait for the horse and carriage to get from the right side of the field
to the left. Aaah, the good 'ol days.
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 Tue, Mar 25, 2014 at 10:44 AM, Mark H Harris wrote: > On 3/24/14 6:01 PM, Chris Angelico wrote: > >> Easy fix. Use the "explicit capture" notation: >> adders[n] = lambda a, n=n: a+n >> And there you are, out of your difficulty at once! >But, and this is the big (WHY?) is that necessary? In other words, its > not about experts knowing how to make this work, its about "normal" people > not understanding in the first place why its a problem, and why the various > solutions work to fix it; even though "we" all know that nothing is > 'broken'. Why is it necessary? For the same reason that this works: def func_pair(): x = 0 def inc(): nonlocal x; x+=1 return x def dec(): nonlocal x; x-=1 return x return inc, dec fooup, foodn = func_pair() barup, bardn = func_pair() >>> fooup(), fooup(), fooup(), foodn() (1, 2, 3, 2) >>> barup(), barup(), bardn(), bardn() (1, 2, 1, 0) When you use the variable x in multiple places, it's the same variable and it has a single value. If you don't want that, you have to make a separate variable. 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 Mon, Mar 24, 2014 at 3:43 PM, Mark H Harris wrote:
> On 3/24/14 4:03 AM, Ian Kelly wrote:
>>
>>
>> The difference does not really lie in the lambda construct per se but in
>> the binding style of closures. Functional languages tend to go one way
>> here; imperative languages tend to go the other. {snip}
>
>
>> The result may be more surprising to users accustomed to functional
>> languages, but I claim that it is *less* surprising to users of other
>> imperative languages.
>
>
>Aside from the sin of spelling out "lambda,"
> should be ( \x y -> x + y ) a b ) but, neither here nor there...
Well no, it *should* be λx y . x + y but apparently some people don't
have that character on their keyboards, so it gets written as lambda
or \ instead. Personally I dislike the \ style; it doesn't really
resemble a λ that closely, and to me the backslash denotes escape
sequences and set differences. Nor is Python alone in spelling out
lambda: Scheme and Common Lisp spell it the same way. As far as I know
the \ for λ is unique to Haskell.
--
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/24/14 5:43 PM, Marko Rauhamaa wrote: Mark H Harris: Yes, its about closures, totally; the most confusing aspect of lambda in python is not only the syntax but the idea of scope and closure (for that syntax). Everyone is confused by this initially, not because its complicated, but because its confusing. An example: adders= list(range(4)) for n in adders: adders[n]=lambda a: a+n print(adders[1](3)) 6 The expected value as perceived by "normal" people is 4. 1. No, I don't think that understanding is automatically natural. It might not seem that way for an expert, but if you Google python lambda function closure(s) you will notice that this is pretty much the natural way of interpreting things. Of course the problem is that the closure grabs the *last* number in the list which is used for each of the adder[] functions created. So, in other words, three (3) is the number added in each of the adder functions. But here is the rub, it is not *ever* clear to people (even experienced python coders, me for instance) that this is how it should work. What is needed is the explicit closure "grab" recommended by ChrisA. But for the normal, that is just as bad (conceptually) because while it works it strays FAR away from expected lambda constructs known to functional programmers, and it is difficult to explain to non functional programmers... a proverbial catch 22. 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 Tue, Mar 25, 2014 at 10:56 AM, Mark H Harris wrote: > What is needed is the explicit closure "grab" recommended by ChrisA. Which does work. You do know why, right? 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 3/24/14 7:11 PM, Chris Angelico wrote: On Tue, Mar 25, 2014 at 10:56 AM, Mark H Harris wrote: What is needed is the explicit closure "grab" recommended by ChrisA. Which does work. You do know why, right? Sure. ... but again, that's not the point. The point is NOT can you explain why it works, the point is that as a lambda construct it is NOT clear why it works, and because the construct does not match what lambda users might expect (naturally) there are *constant* questions about it. So, again, I'll restate that the community might consider (over time) whether the confusion created by lambda in python is worth the time and trouble to maintain the construct in the language. Is the value add worth the cost of confusion. I don't think so; others are bound to disagree. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: advice on sub-classing multiprocessing.Process and multiprocessing.BaseManager
On Tue, Mar 25, 2014 at 7:24 AM, Matt Newville wrote: > I'm maintaining a python interface to a C library for a distributed > control system (EPICS, sort of a SCADA system) that does a large > amount of relatively light-weight network I/O. In order to keep many > connections open and responsive, and to provide a simple interface, > the python library keeps a global store of connection state. > > This works well for single processes and threads, but not so well for > multiprocessing, where the global state causes trouble. >From the sound of things, a single process is probably what you want here. Is there something you can't handle with one process? 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 Tue, Mar 25, 2014 at 11:16 AM, Mark H Harris wrote: > On 3/24/14 7:11 PM, Chris Angelico wrote: >> >> On Tue, Mar 25, 2014 at 10:56 AM, Mark H Harris >> wrote: >>> >>> What is needed is the explicit closure "grab" recommended by ChrisA. >> >> >> Which does work. You do know why, right? > > > Sure. ... but again, that's not the point. The point is NOT can you explain > why it works, the point is that as a lambda construct it is NOT clear why it > works, and because the construct does not match what lambda users might > expect (naturally) there are *constant* questions about it. > > So, again, I'll restate that the community might consider (over time) > whether the confusion created by lambda in python is worth the time and > trouble to maintain the construct in the language. Is the value add worth > the cost of confusion. I don't think so; others are bound to disagree. Pure functional programming, from what I understand, doesn't *have* variables other than function arguments. So the way to implement "x = 1" is to call a subfunction with an argument of 1, which is referred to as x. (Am I right so far?) In that case, the default argument trick is exactly the right way to implement that in Python. 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 25/03/2014 00:16, Mark H Harris wrote: On 3/24/14 7:11 PM, Chris Angelico wrote: On Tue, Mar 25, 2014 at 10:56 AM, Mark H Harris wrote: What is needed is the explicit closure "grab" recommended by ChrisA. Which does work. You do know why, right? Sure. ... but again, that's not the point. The point is NOT can you explain why it works, the point is that as a lambda construct it is NOT clear why it works, and because the construct does not match what lambda users might expect (naturally) there are *constant* questions about it. So, again, I'll restate that the community might consider (over time) whether the confusion created by lambda in python is worth the time and trouble to maintain the construct in the language. Is the value add worth the cost of confusion. I don't think so; others are bound to disagree. marcus I'd vote to have lambda taken out of the language if it meant avoiding tedious threads like this one :( -- 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: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 3/24/14 7:32 PM, Mark Lawrence wrote: marcus I'd vote to have lambda taken out of the language if it meant avoiding tedious threads like this one :( Dude, you remind me of Eeyore; "days, weeks, months, who knows..." Its just a conversation. Don't setup a polling booth yet. Its all in fun and science. 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/24/2014 7:07 PM, Chris Angelico wrote: On Tue, Mar 25, 2014 at 9:58 AM, Steven D'Aprano wrote: On Tue, 25 Mar 2014 06:22:28 +1100, Chris Angelico wrote: Aside: You'll often hear people talking about "map-reduce" with big data. Python supports that. Look! map.__reduce__ Oh wait, that's nothing to do with reduce()... *ducks for cover* Ha ha, very funny :-P http://code.activestate.com/recipes/577676-dirt-simple-mapreduce/ That looks like a more serious map/reduce example. Mine came from a double-take when I was looking at help(map) for some reason; there's a __round__ magic method that helps define the round() function, there's __abs__ for abs(), there's __str__ for str()... look, there's a __reduce__ - it must be to help define reduce()! :) That was my first think also. I believe __pickle__ or __unpickle__ would have been more appropriate. -- Terry Jan Reedy -- 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/24/2014 7:56 PM, Mark H Harris wrote: Of course the problem is that the closure A function is not a closure unless defined within another function. In the examples I remember, there was no nesting. > grabs the *last* number in the list which is used for each of the adder[] functions created. Wrong. Functions look up global and nonlocal names, such as n, when the function is called. >>> adders = list(range(4)) >>> for n in adders: adders[n] = lambda a: a+n >>> n = 1000 >>> adders[1](3) 1003 Same result if the function *is* a closure, making n nonlocal rather than global. def f(): adders = list(range(4)) for n in adders: adders[n] = lambda a: a+n n = 1000 return adders print(f()[1](3)) >>> 1003 The only definition time grabbing is with default arg expressions. This discussion is a bit funny in a way. Some people are puzzled that default arg expressions 'grab' just once, as definition time, rather than with each call. Others (I hope others) are puzzled that body expressions 'grab' with each call, rather than just once, at definition time. That seems to be particularly true when the body is in a lambda expression rather than a def statement. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Python developer salary survey - results
在 2014年3月25日星期二UTC+8上午4时57分49秒，[email protected]写道： > PyStreet's February salary survey attracted respondents from 37 countries. > > > > Median annual salary in the U.S.: $95,000 > > Median annual salary worldwide: $50,000 > > > > Complete study: http://bit.ly/1dgCw3p I am below the worldwide median... -- 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/24/2014 8:28 PM, Chris Angelico wrote: Pure functional programming, from what I understand, doesn't *have* variables other than function arguments. function *parameters*, if in the 'variable = name' camp So the way to implement "x = 1" is to call a subfunction with a parameter named 'x' with an argument of 1 Funny, I was just thinking about that last night. I really learned it when trying to translate python code to the scheme dialect racket. import math as m s = m.sqrt(2) a = m.sin(s) + m.cos(s) del s # to be exactly equivalent to the below, but not needed b = (lambda x: m.sin(x) + m.cos(x))(m.sqrt(2)) print(a,b) >>> 1.14370964075811 1.14370964075811 -- Terry Jan Reedy -- 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 Tue, Mar 25, 2014 at 12:31 PM, Terry Reedy wrote: > On 3/24/2014 8:28 PM, Chris Angelico wrote: > >> Pure functional programming, from what I understand, doesn't *have* >> variables other than function arguments. > > > function *parameters*, if in the 'variable = name' camp > > >> So the way to implement "x = 1" is to call a subfunction > > > with a parameter named 'x' > >> with an argument of 1 Ah, yes, parameter. I tend to use the terms interchangeably, but they do have formal definitions and distinctions. But otherwise, yes; that's how I was seeing that. 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 Mon, 24 Mar 2014 14:47:11 -0500, Mark H Harris wrote:
> On 3/24/14 4:49 AM, Steven D'Aprano wrote:
>> There's no doubt that lambda is less-often useful than is the def
>> statement. But not only is it still useful, but there is a continual
>> stream of people asking for Python to make it *more useful* by allowing
>> the body of a lambda to be a full block, not just a single statement.
>> Guido has stated (although I cannot remember where, so cannot paste a
>> link) that he accepts that in principle, so long as somebody comes up
>> with acceptable syntax.
>
> Now, this will seem strange to you, but if lambda were expanded to
> include an entire block, well now, I would know two things:
>1) python has commitment to lambda
Python has a commitment to lambda. lambda is not going anywhere. There
was some idea chatter five or six years ago about dropping it from the
language. It didn't get dropped, so now it is as much a part of the
language as for-loops, print, classes and import.
>and 2) lambda would become WAY more useful...
Every one agrees that being able to include a full suite of statements in
an expression form would be useful. Unfortunately, due to the constraint
of Python's syntax, it seems to be impossible. People have looked for 20+
years, and nobody has come up with an acceptable syntax.
[...]
>>> Lambda is a problem of confusion for scientists and other
>>> mathematicians (amateur and otherwise) {snip}
>>{snip}
>> But nor should the confusion of somebody who doesn't know the language
>> count for much.
>
> This is the main disagreement between the two of us on this topic.
> It should count for TONS; whole metric TONs. Because someone who
> understands python primarily, and after five years of coding (say me)
> somebody tells (me) to use lambda in a key clause so that my sort will
> work, or work better, or work "their" way; and I have no idea why I need
> this nameless function (after I find out that "that" is what it is!)
Then you don't understand *sorting*. If you don't understand why you need
a key function, the problem is not the syntax used to create the key
function, but your understanding of sort. Time to remove sorting from
Python, yes? No?
It's not lambda that is giving you trouble. That's just syntax. There is
no conceptual difference between:
data.sort(key=lambda item: *magic goes on here*)
and
def key_func(item):
*magic goes on here*
data.sort(key=key_func)
If the first confuses you, so will the second. If you are capable of
learning what the first means, learning the second is no harder.
> Its confusing, and please contrast between complicated. I don't mind
> complicated, or extensive, or even hard, but when something is
> needlessly confusing, then why?
I don't know why you insist it is confusing. Maybe you're just no good at
seeing the correspondence between
lambda x: expression
and
def func(x):
return expression
>> Python's ints don't work exactly the same as ints do in some other
>> languages, nor do Python's strings, nor is Python's object model
>> precisely the same as that of some other languages. I think that it
>> would be a ridiculous idea to discard int, str and the entire object
>> system just because some people are surprised that Python doesn't
>> behave exactly like some other language. I don't think lambda is any
>> different.
>
> Your logic is faulty here. Conceptually python's lambda doesn't
> work as expected, from contexts that define lambda
Python defines lambda too. Why should Python have to bend over to suit
the definition used by other languages? They don't own the concept of
anonymous functions. Anonymous functions are found in all sorts of
languages, with different semantics and different syntax:
Pike: lambda(typ1 para1, typ2, para2, ...) { ... };
Perl: sub { my ($a, $b) = @_; ... }
Smalltalk: [:a :b| ... ]
Haskell: \a b -> ...
Erlang: fun(a, b) -> ... end
Dylan: method(a, b) ... end method
to mention just a few. Ruby even has at least three ways of spelling
lambda, one of which even uses the word lambda:
{|a, b| ... }
lambda {|a, b| ...}
proc {|a, b| ...}
> and where lambda in functional programming is VERY important.
And? Nobody is saying that they have to stop using the term lambda.
Certainly I'm not. I wouldn't be so rude.
> For one thing, why would we
> want to "spell out" the word "lambda".( \x y -> x + y ) a b ) If
> we're going to use lambda, then use it.
So you don't like the syntax of Python's lambda. That's your prerogative.
But frankly, one thing I dislike about Haskell is that it is too terse.
Why would you use lambda without spelling out explicitly that you are
doing so?
>> Other languages -- not even Lisp -- don't get to be the sole decider as
>> to what counts as an anonymous function. Python's lambda may be
>> limited, but it is a perfectly fine lambda for what it is intended to
>> do.
>
> Is that the
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 3/22/14 3:59 PM, vasudevram wrote:
Thanks to all those who answered.
- Vasudev
I am wondering if the question was answered?
x = [[1,2],[3,4],[5,6]]
import ast
ast.dump(ast.parse('[x for x in x for x in x]'))
>
"Module(body=
>
[Expr(value=ListComp(elt=Name(id='x', ctx=Load()),
>
generators=
>
[comprehension(target=Name(id='x', ctx=Store()), iter=Name(id='x', ctx=Load()),
ifs=[]),
>
comprehension(target=Name(id='x', ctx=Store()), iter=Name(id='x', ctx=Load()),
ifs=[])]))])"
This is really, I think, the answer to the OPs question. Knowing how
python is parsing the comprehension of comprehensions is important, yes?
Obviously each x is within a different scope, within a separate
iterator. This seems to unwind from right to left?
I didn't see any ast entries in the thread, so just wondering.
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 25/03/2014 01:45, Steven D'Aprano wrote: (1) People who just want to get the job done, without learning a bunch of theory, *won't care* how their sort key function is written. They're looking for a recipe that they can copy and paste, and whether you write it like this: data.sort(key=lambda item: item[1]) or like this: from operator import itemgetter data.sort(key=itemgetter(1)) or like this: def sort_key(item): return item[1] data.sort(key=sort_key) *they won't care*. In fact, they'll probably prefer the first version, with lambda, because it is fewer lines to copy. I'm firmly in this camp, practicality beats purity and all that. I've used the first and second versions shown above as they happened to be in the recipes I was aquiring, I wouldn't contemplate the third. That's just my mindset, which is what I love about Python, by pure luck it fits me like made to measure clothing. -- 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: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Tue, Mar 25, 2014 at 12:45 PM, Steven D'Aprano wrote: > Programming is a skill, like writing iambic pentameter. Should liberal > arts courses ban the use of iambic pentameter by poets because some > people find it confusing and can't count syllables or tell the difference > between stressed and unstressed? (I know I can't. My wife despairs that I > am so useless at anything like poetry.) Iambic pentameter is hard. I know, I tried writing eight lines of it for my brother's wedding. (Okay, I was writing *acrostic* iambic pentameter, putting his wife's new surname down the left edge of the page, but still, it's pretty restrictive.) It's much more fun, I reckon, to write paragraphs of text roughly eighty characters across. Prosaic, I know 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 3/24/14 8:20 PM, Terry Reedy wrote: On 3/24/2014 7:56 PM, Mark H Harris wrote: the list which is used for each of the adder[] functions created. Wrong. Functions look up global and nonlocal names, such as n, when the function is called. hi Terry, yeah, I know; this is what's *wrong* all at once. Functions "look up global and nonlocal names" such as n, is semantics for "each created function 'grabs' the last number (n) in the list", well, because that (n) is bound at call-time to (3). Your version semantically is detailed and correct; my version semantically is "how it is perceived" by the user, which is also correct. Again, how the function gets the n (grab or lookup) is mute. The user is often confused about how this happens. As you have shown, even experts in this field disagree about how this is described, which is also my secondary point--- the whole thing is VERY difficult to explain to "normal" users. It often takes several sessions and goes on and on, until Mark Lawrence calls it tedious. marcus -- https://mail.python.org/mailman/listinfo/python-list
Time we switched to unicode? (was Explanation of this Python language feature?)
On Tuesday, March 25, 2014 5:28:11 AM UTC+5:30, Ian wrote:
> On Mon, Mar 24, 2014 at 3:43 PM, Mark H Harris wrote:
> > On 3/24/14 4:03 AM, Ian Kelly wrote:
> >> The difference does not really lie in the lambda construct per se but in
> >> the binding style of closures. Functional languages tend to go one way
> >> here; imperative languages tend to go the other. {snip}
> >> The result may be more surprising to users accustomed to functional
> >> languages, but I claim that it is *less* surprising to users of other
> >> imperative languages.
> >Aside from the sin of spelling out "lambda,"
> > should be ( \x y -> x + y ) a b ) but, neither here nor there...
> Well no, it *should* be λx y . x + y but apparently some people don't
> have that character on their keyboards, so it gets written as lambda
> or \ instead. Personally I dislike the \ style; it doesn't really
> resemble a λ that closely, and to me the backslash denotes escape
> sequences and set differences. Nor is Python alone in spelling out
> lambda: Scheme and Common Lisp spell it the same way. As far as I know
> the \ for λ is unique to Haskell.
Yeah: Its 2014 (at least out here)...
About time we started using unicode in earnest dont you think??
Id like to see the following spellings corrected:
lambda to λ
in to ∈
(preferably with the 'in' predicate and the 'in' in 'for' disambiguated)
set([]) to ∅
And some parentheses disambiguation
Internal ambiguity: Is '(...)' a paren? a function? a tuple?
External ambiguity: {} in python vs in set theory
[And now I hand it over to our very dear resident troll to explain the glories
of the FSR]
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, Mar 25, 2014 at 2:00 PM, Rustom Mody wrote:
> Yeah: Its 2014 (at least out here)...
> About time we started using unicode in earnest dont you think??
We do.
> Id like to see the following spellings corrected:
> lambda to λ
> in to ∈
> (preferably with the 'in' predicate and the 'in' in 'for' disambiguated)
> set([]) to ∅
The problems with these is not Unicode or a lack thereof, but keys. I
know how to type "lambda" on any keyboard I reach for; if it's a
full-sized QWERTY variant, I can type it without looking, and if it's
something else then I can peer at the thing and find the appropriate
five letters. (Phone keyboards are notoriously peer-worthy.) How do I
type λ? Do I have to memorize an alt-key sequence? Do I need to keep a
set of "language keywords" in a file somewhere so I can copy and
paste? Does my editor have to provide them?
What is really gained by using the short-hand? It becomes nigh
ungoogleable; yes, you can paste λ into Google and find out that it's
called lambda (and, if Python used that as a keyword, you could type
"λ python" into Google and get to the docs), but how do you figure out
which part of this to search for?
sockets.sort(key=λdata:data[1])
More likely you'd search for "sockets" or "sort" or maybe "key" or
"data", but you wouldn't expect to search for the symbol.
> And some parentheses disambiguation
> Internal ambiguity: Is '(...)' a paren? a function? a tuple?
> External ambiguity: {} in python vs in set theory
I don't know about the difference between {} in set theory and Python,
but the multiple uses of () actually boil down to two:
1) Grouping, which includes tuples; there's a special case whereby
grouping nothing makes a zero-item tuple, but everything else is just
the comma
2) Functions (both definition and call)
Disambiguating them might be of some small value, but since they're
the same in pretty much every language under the sun, it would feel
like syntactic salt: you have to use a different, and hard to type,
form of parenthesis for one (or even both!) of what ought to just be
simple brackets.
And what's the benefit? Shorter code, maybe. A few 2-6 letter
sequences that can become single characters. I can sympathize somewhat
with the set issue (because {} means an empty dict), although set() is
better than set([]); having a short form for that would be of some
advantage. But not if it's hard to type.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 3/24/14 10:00 PM, Rustom Mody wrote:
About time we started using unicode in earnest dont you think??
Id like to see the following spellings corrected:
lambda to λ
great idea!
{snip}
[And now I hand it over to our very dear resident troll to explain the glories
of the FSR]
Now, that's not at all patronizing, ~is it?
!vdrt
marcus :)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 3/24/14 10:17 PM, Chris Angelico wrote: On Tue, Mar 25, 2014 at 2:00 PM, Rustom Mody wrote: Yeah: Its 2014 (at least out here)... About time we started using unicode in earnest dont you think?? We do. Id like to see the following spellings corrected: lambda to λ in to ∈ (preferably with the 'in' predicate and the 'in' in 'for' disambiguated) set([]) to ∅ The problems with these is not Unicode or a lack thereof, but keys. I know how to type "lambda" on any keyboard I reach for; Yeah, its a fit. I found pi -> ∏ ... and here's apple pi -> ∏ but, rats, can't find \ lambda -- https://mail.python.org/mailman/listinfo/python-list
Re: advice on sub-classing multiprocessing.Process and multiprocessing.BaseManager
On Monday, March 24, 2014 7:19:56 PM UTC-5, Chris Angelico wrote: > On Tue, Mar 25, 2014 at 7:24 AM, Matt Newville > > > I'm maintaining a python interface to a C library for a distributed > > control system (EPICS, sort of a SCADA system) that does a large > > amount of relatively light-weight network I/O. In order to keep many > > connections open and responsive, and to provide a simple interface, > > the python library keeps a global store of connection state. > > > > This works well for single processes and threads, but not so well for > > multiprocessing, where the global state causes trouble. > > > From the sound of things, a single process is probably what you want > here. Is there something you can't handle with one process? Thanks for the reply. I find that appreciation is greatly (perhaps infinitely) delayed whenever I reply "X is probably not what you want to do" without further explanation to a question of "can I get some advice on how to do X?". So, I do thank you for your willingness to reply, even such a guaranteed-to-be-under-appreciated reply. There are indeed operations that can't be handled with a single process, such as simultaneously using multiple cores. This is why we want to use multiprocessing instead of (or, in addition to) threading. We're trying to do real-time collection of scientific data from a variety of data sources, generally within a LAN. The data can get largish and fast, and intermediate processing occasionally requires non-trivial computation time. So being able to launch worker processes that can run independently on separate cores would be very helpful. Ideally, we'd like to let sub-processes make calls to the control system too, say, read new data. I wasn't really asking "is multiprocessing appropriate?" but whether there was a cleaner way to subclass multiprocessing.BaseManager() to use a subclass of Process(). I can believe the answer is No, but thought I'd ask. Thanks again, --Matt -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 3/24/14 10:25 PM, Mark H Harris wrote: but, rats, can't find \ lambda Ok, there we go -> λ and ∈ and ∉ and ∀ no problem. -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
In article , Chris Angelico wrote: > On Tue, Mar 25, 2014 at 2:00 PM, Rustom Mody wrote: > > Yeah: Its 2014 (at least out here)... > > About time we started using unicode in earnest dont you think?? > > We do. > > > Id like to see the following spellings corrected: > > lambda to λ > > in to â > > (preferably with the 'in' predicate and the 'in' in 'for' disambiguated) > > set([]) to ? > > The problems with these is not Unicode or a lack thereof, but keys. I > know how to type "lambda" on any keyboard I reach for; if it's a > full-sized QWERTY variant, I can type it without looking, and if it's > something else then I can peer at the thing and find the appropriate > five letters. (Phone keyboards are notoriously peer-worthy.) How do I > type λ? Do I have to memorize an alt-key sequence? Do I need to keep a > set of "language keywords" in a file somewhere so I can copy and > paste? Does my editor have to provide them? I started programming on 029 keypunches and ASR-33 teletypes. If you asked me to type most of the punctuation we take for granted today (not to mention lower case letters), I would have looked at you as if you had asked me to type something in greek. Hardware evolves. I assume that future generations of programmers will have input devices better suited to unicode than the clumsy keyboards we use today. -- https://mail.python.org/mailman/listinfo/python-list
Re: advice on sub-classing multiprocessing.Process and multiprocessing.BaseManager
On Tue, Mar 25, 2014 at 2:27 PM, wrote: > Thanks for the reply. I find that appreciation is greatly (perhaps > infinitely) delayed whenever I reply "X is probably not what you want to do" > without further explanation to a question of "can I get some advice on how to > do X?". So, I do thank you for your willingness to reply, even such a > guaranteed-to-be-under-appreciated reply. > Heh. I do see that side of it, but the problem is that sometimes a question will be asked that implies a completely wrong approach. Take this example: "I'm having trouble passing a global variable to a function, how can I do it?" This exact question came up recently (I may have the wording wrong), and some of the solutions offered were horrendously convoluted messes involving passing the name of a global to the function which then used 'exec' or 'eval'. While technically that answers the question, it's much more helpful to take a step back - no, let's take a step forward - now another step back - and we're cha-cha'ing! - well, unless you're a real genius, just take the step back, and look at what you're actually trying to achieve. I wasn't trying to imply that you absolutely ought to use a single process, but more that the exact reasons for not using one process are significant in your style of coding the multi-process method. > There are indeed operations that can't be handled with a single process, such > as simultaneously using multiple cores. This is why we want to use > multiprocessing instead of (or, in addition to) threading. We're trying to > do real-time collection of scientific data from a variety of data sources, > generally within a LAN. The data can get largish and fast, and intermediate > processing occasionally requires non-trivial computation time. So being able > to launch worker processes that can run independently on separate cores would > be very helpful. Ideally, we'd like to let sub-processes make calls to the > control system too, say, read new data. > > I wasn't really asking "is multiprocessing appropriate?" but whether there > was a cleaner way to subclass multiprocessing.BaseManager() to use a subclass > of Process(). I can believe the answer is No, but thought I'd ask. > I've never subclassed BaseManager like this. It might be simpler to spin off one or more workers and not have them do any network communication at all; that way, you don't need to worry about the cache. Set up a process tree with one at the top doing only networking and process management (so it's always fast), and then use a multiprocessing.Queue or somesuch to pass info to a subprocess and back. Then your global connection state is all stored within the top process, and none of the others need care about it. You might have a bit of extra effort to pass info back to the parent rather than simply writing it to the connection, but that's a common requirement in other areas (eg GUI handling - it's common to push all GUI manipulation onto the main thread), so it's a common enough model. But if subclassing and tweaking is the easiest way, and if you don't mind your solution being potentially fragile (which subclassing like that is), then you could look into monkey-patching Process. Inject your code into it and then use the original. It's not perfect, but it may turn out easier than the "subclass everything" technique. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tuesday, March 25, 2014 8:47:35 AM UTC+5:30, Chris Angelico wrote:
> On Tue, Mar 25, 2014 at 2:00 PM, Rustom Mody wrote:
> > Yeah: Its 2014 (at least out here)...
> > About time we started using unicode in earnest dont you think??
> We do.
> > Id like to see the following spellings corrected:
> > lambda to λ
> > in to ∈
> > (preferably with the 'in' predicate and the 'in' in 'for' disambiguated)
> > set([]) to ∅
> The problems with these is not Unicode or a lack thereof, but keys. I
> know how to type "lambda" on any keyboard I reach for; if it's a
> full-sized QWERTY variant, I can type it without looking, and if it's
> something else then I can peer at the thing and find the appropriate
> five letters. (Phone keyboards are notoriously peer-worthy.) How do I
> type λ? Do I have to memorize an alt-key sequence? Do I need to keep a
> set of "language keywords" in a file somewhere so I can copy and
> paste? Does my editor have to provide them?
> What is really gained by using the short-hand? It becomes nigh
> ungoogleable; yes, you can paste λ into Google and find out that it's
> called lambda (and, if Python used that as a keyword, you could type
> "λ python" into Google and get to the docs), but how do you figure out
> which part of this to search for?
> sockets.sort(key=λdata:data[1])
> More likely you'd search for "sockets" or "sort" or maybe "key" or
> "data", but you wouldn't expect to search for the symbol.
> > And some parentheses disambiguation
> > Internal ambiguity: Is '(...)' a paren? a function? a tuple?
> > External ambiguity: {} in python vs in set theory
> I don't know about the difference between {} in set theory and Python,
> but the multiple uses of () actually boil down to two:
> 1) Grouping, which includes tuples; there's a special case whereby
> grouping nothing makes a zero-item tuple, but everything else is just
> the comma
> 2) Functions (both definition and call)
> Disambiguating them might be of some small value, but since they're
> the same in pretty much every language under the sun, it would feel
> like syntactic salt: you have to use a different, and hard to type,
> form of parenthesis for one (or even both!) of what ought to just be
> simple brackets.
> And what's the benefit? Shorter code, maybe. A few 2-6 letter
> sequences that can become single characters. I can sympathize somewhat
> with the set issue (because {} means an empty dict), although set() is
> better than set([]); having a short form for that would be of some
> advantage. But not if it's hard to type.
> ChrisA
Of all your objections, the 'google-able' one is the most hard-hitting.
Yes its important and I have no answers.
What you are missing is that programmers spend
90% of their time reading code
10% writing code
You may well be in the super-whiz category (not being sarcastic here)
All that will change is upto 70-30. (ecause you rarely make a mistake)
You still have to read oodles of others' code
I find python (as haskell) sweet because they dont force me read
parsing-drudgery like '{}'.
Given that a compiler can parse whitespace (python), or '{}' (C) in microseconds
whereas I take seconds, this is really terrible economics
Increasing the lexical variety of the code is in the same direction
[There is no need implied that overdoing it and becoming APL is good :-) ]
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tuesday, March 25, 2014 12:28:16 AM UTC+5:30, Mark H. Harris wrote:
> On 3/24/14 4:58 AM, Mark Lawrence wrote:
> > Where do you get reduce from if it's not in the standard library?
> That was "a" proposal for 3000. Its there, but its not on the
> built-ins; ie., you have to import it. The confusion: why reduce, why
> not filter, nor map? {rhetorical}
> > As for lambda I've no real interest in it, other than when copying examples
> > where it's used to (say) provide a key function.
> This is one of my main points to Steven. In my experience "most" people
> do not intend to use lambda for anything; they are trying to sort this
> or that and don't quite know how to get the key right and some helpful
> somebody gives them a key=lambda yadda yadda . They use it, and it
> works, but they are scratching their head saying to themselves, "what it
> that, how does it work, how can I understand it and on and on".
Your example backfires more than you perhaps realize
1. Most people who-have-not-heard-of (WHNHO) generators dont intend to use
generators. Somebody shows then a couple of uses and they then find them
useful in other contexts
2. Most programmers coming from C where vararg exists but is really
much too painful to use outside of printf, dont want to use default
arguments. Somebody shows them default arguments then they find nifty uses
for the same
3. Most people WHNHO special methods ...
4. Most people WHNHO slices ...
Just sayin...
> That is what we mean by confusing. Or another really great example is
> this thread. Somebody asks about a language feature and somebody else
> helpfully answers the question by providing them with a similar lambda!!
I am not in pro or anti lambda camp.
My grouses are 3, all re comprehensions
1. Technical: I consider the comprehension binding rules wrong -- not lambda
2. Methodological: Experienced people showing comprehensions
as 'nothing more than' a short-form for a for-loop are being less helpful
to the noob than they know.
3. Pedagogical: Comprehensions are hard, for loops are easy.
To convey comprehensions two contrasting perspectives are needed:
1. The for-loop view
2. The set-theory view
Give only one, and misunderstandings and confusions proliferate
Yes 'only one' can be either one. In the haskell world the pedagogical error
tends to be the opposite to the one out here:
Noobs write: [... x in l, y in m,...]
and wonder why the efficiency is vastly different from
[... y in m, x in l, ...]
Comes from emphasising the declarative (set-theory) view too much, the
imperative (for-loop) view too little
--
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/24/14 8:45 PM, Steven D'Aprano wrote: Your insistence that lambda is confusing is awfully condescending. People are not as dumb as you insist, and they are perfectly capable of learning lambda without a comp sci degree. Like any technical jargon, there is vocabulary and meaning to learn, but the concept is no more difficult than ordinary def functions. This is an Ad Hominem. My opinion that lambda is confusing must not be construed to mean condescension; not coming from my pen. I do not insist that people are dumb, nor do I insist that people cannot learn python without a comp sci degree. Pushing those words into my mouth and then beating me up for saying them is, well, ad hominem. What I am insisting is that *many* people, as point of fact, are confused by the python lambda construct particularly when it is embedded within a for x in and the lambda is supposed to capture the value x (as in my previous examples). This say nothing of their intelligence and says nothing about my supposed motive of condescension. (we my judge actions, but not motives) I am advocating for understanding, among all python users--- novice and expert alike. Especially when I find so many experts who want to "know" (like the OP on this thread) and other experts who (like ecumenical councils) cannot agree (also noticed on this thread). I am not seeking over simplification, and I am not seeking to limit the expert in any way; just advocating for Aristotle's mean, whereat we find virtue. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, Mar 25, 2014 at 2:29 PM, Roy Smith wrote: > I started programming on 029 keypunches and ASR-33 teletypes. If you asked > me to > type most of the punctuation we take for granted today (not to mention lower > case > letters), I would have looked at you as if you had asked me to type something > in greek. > > Hardware evolves. I assume that future generations of programmers will have > input > devices better suited to unicode than the clumsy keyboards we use today. And there you have a circular problem. Until the bulk of programmers have access to such keyboards, programming languages shouldn't use such symbols (because most of their users won't be able to type them); and until programming languages make use of those symbols, there's little reason to put them on keyboards. Supporting both may look tempting, but you effectively create two ways of spelling the exact same thing; it'd be like C's trigraphs. Do you know what ??= is, without looking it up? [1] ChrisA [1] I will accept "An obfuscation tool" as a correct answer here. -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, Mar 25, 2014 at 2:43 PM, Rustom Mody wrote: > What you are missing is that programmers spend > 90% of their time reading code > 10% writing code > > You may well be in the super-whiz category (not being sarcastic here) > All that will change is upto 70-30. (ecause you rarely make a mistake) > You still have to read oodles of others' code No, I'm not missing that. But the human brain is a tokenizer, just as Python is. Once you know what a token means, you comprehend it as that token, and it takes up space in your mind as a single unit. There's not a lot of readability difference between a one-symbol token and a one-word token. Also, since the human brain works largely with words, you're usually going to grok things based on how you would read them aloud: x = y + 1 eggs equals why plus one They take up roughly the same amount of storage space. One of them, being a more compact notation, lends itself well to a superstructure of notation; compare: x += 1 eggs plus-equals one inc eggs You can eyeball the first version and read it as the third, which is a space saving in your brain. But it's not fundamentally different from the second. So the saving from using a one-letter symbol that's read "lambda" rather than the actual word "lambda" is extremely minimal. Unless you can use it in a higher-level construct, which seems unlikely in Python (maybe it's different in Haskell? Maybe you use lambda more and actually do have those supernotations?), you won't really gain anything. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tuesday, March 25, 2014 8:47:35 AM UTC+5:30, Chris Angelico wrote:
> On Tue, Mar 25, 2014 at 2:00 PM, Rustom Mody wrote:
> > Yeah: Its 2014 (at least out here)...
> > About time we started using unicode in earnest dont you think??
> We do.
> > Id like to see the following spellings corrected:
> > lambda to λ
> > in to ∈
> > (preferably with the 'in' predicate and the 'in' in 'for' disambiguated)
> > set([]) to ∅
> The problems with these is not Unicode or a lack thereof, but keys. I
> know how to type "lambda" on any keyboard I reach for; if it's a
> full-sized QWERTY variant, I can type it without looking, and if it's
> something else then I can peer at the thing and find the appropriate
> five letters. (Phone keyboards are notoriously peer-worthy.) How do I
> type λ? Do I have to memorize an alt-key sequence? Do I need to keep a
> set of "language keywords" in a file somewhere so I can copy and
> paste? Does my editor have to provide them?
> What is really gained by using the short-hand? It becomes nigh
> ungoogleable; yes, you can paste λ into Google and find out that it's
> called lambda (and, if Python used that as a keyword, you could type
> "λ python" into Google and get to the docs), but how do you figure out
> which part of this to search for?
> sockets.sort(key=λdata:data[1])
> More likely you'd search for "sockets" or "sort" or maybe "key" or
> "data", but you wouldn't expect to search for the symbol.
> > And some parentheses disambiguation
> > Internal ambiguity: Is '(...)' a paren? a function? a tuple?
> > External ambiguity: {} in python vs in set theory
> I don't know about the difference between {} in set theory and Python,
> but the multiple uses of () actually boil down to two:
In set theory {} makes sets
In python {} makes dictionaries
> 1) Grouping, which includes tuples; there's a special case whereby
> grouping nothing makes a zero-item tuple, but everything else is just
> the comma
> 2) Functions (both definition and call)
> Disambiguating them might be of some small value, but since they're
> the same in pretty much every language under the sun, it would feel
What 'they'?? I dont get: If you are talking of disambiguating function
definition and call -- yeah thats overkill
If you are talking of overlap between tuples parentheses and function (call)
well consider
f(x,y) vs f((x,y)) vs (x,y) vs ((x,y))
Paren vs tuples: why do we need to write (x,) not (x)
All this is because () is doing triple-duty
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 3/24/14 10:51 PM, Chris Angelico wrote:
Supporting both may look tempting, but you effectively create two ways
of spelling the exact same thing; it'd be like C's trigraphs. Do you
know what ??= is,
This was a fit for me, back in the day IBM (system36 & system38). When
we started supporting the C compiler (ha!) and non of our 5250 terminals
could provide the C punctuation we take for granted today--- so we
invented tri-graphs for { and } and others. It was a hoot.
I personally think the answer is extended key maps triggered by meta
keys shift ctrl opt alt command | which call up full alternate mappings
of Greek|Latin|Math|symbols &c which can be chosen by mouse|pointing
device.
The mac calls these keyboard viewer, and character viewer. In that way
the full unicode set can be available from a standard qwerty keyboard
without modifying the hardware right away.
marcus
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tuesday, March 25, 2014 9:29:57 AM UTC+5:30, Mark H. Harris wrote:
> On 3/24/14 10:51 PM, Chris Angelico wrote:
> > Supporting both may look tempting, but you effectively create two ways
> > of spelling the exact same thing; it'd be like C's trigraphs. Do you
> > know what ??= is,
> This was a fit for me, back in the day IBM (system36 & system38). When
> we started supporting the C compiler (ha!) and non of our 5250 terminals
> could provide the C punctuation we take for granted today--- so we
> invented tri-graphs for { and } and others. It was a hoot.
> I personally think the answer is extended key maps triggered by meta
> keys shift ctrl opt alt command | which call up full alternate mappings
> of Greek|Latin|Math|symbols &c which can be chosen by mouse|pointing
> device.
> The mac calls these keyboard viewer, and character viewer. In that way
> the full unicode set can be available from a standard qwerty keyboard
> without modifying the hardware right away.
I think Roy is right in saying that what looks unrealistic with one
technology looks natural with another (out phones are already handling
speech and handwriting)
And Chris is right in (rephrasing) we may have unicode-happy OSes and
languages. We cant reasonably have unicode-happy keyboards.
[What would a million-key keyboard look like? Lets leave the cost aside...]
Problem is that unicode deals with very different sides:
Universality of the math language
Locality of the zillions of human languages
If any character could be a variable, distinguishing the different things that
look like 'A' would be a nightmare
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, Mar 25, 2014 at 2:56 PM, Rustom Mody > I don't know about the difference between {} in set theory and Python,
>> but the multiple uses of () actually boil down to two:
>
> In set theory {} makes sets
> In python {} makes dictionaries
That's a backward-compatibility issue. Braces in Python meant a
dictionary before it acquired a set type (at least, so I learned in
history class - I wasn't using Python back then), so empty braces have
to continue to mean empty dictionary. I sympathize with the confusion,
but short of confusing everyone terribly by changing dicts to use
something other than braces (maybe borrow Pike's mapping notation, ([
])??), I don't really see a solution.
>> 1) Grouping, which includes tuples; there's a special case whereby
>> grouping nothing makes a zero-item tuple, but everything else is just
>> the comma
>
>> 2) Functions (both definition and call)
>
>> Disambiguating them might be of some small value, but since they're
>> the same in pretty much every language under the sun, it would feel
>
> What 'they'?? I dont get: If you are talking of disambiguating function
> definition and call -- yeah thats overkill
No no. Disambiguating grouping and fuction definition/call. There's no
reason to have definition and call of functions differ.
> If you are talking of overlap between tuples parentheses and function (call)
> well consider
> f(x,y) vs f((x,y)) vs (x,y) vs ((x,y))
> Paren vs tuples: why do we need to write (x,) not (x)
>
> All this is because () is doing triple-duty
Tuples don't use parentheses. You only confuse yourself when you
insist on that. The only case with parens that actually makes a tuple
is the special empty tuple; imagine if that were given a name instead,
like "Empty". That would solve that confusion.
There's another minorly special case, and that's that the trailing
comma is mandatory on a one-item tuple. In all others, it's optional,
but the one-item tuple would be ambiguous otherwise.
>>> len((1,2,3,))
3
>>> len((1,2,))
2
>>> len((1,))
1
(By the way, bringing in another discussion: The comma isn't part of
the element, nor is it exactly a separator, nor is it exactly a
terminator. Just like a newline in a text file.)
So the only ambiguity is between function calls and grouping. Tuples
are just part of grouping, in that you need to disambiguate a
one-tuple-arg function call from a multiple-arg function call - as in
the above len() calls. And that's where I think it would be highly
confusing to mandate something different. Suppose we used $( )$ for
function calls, and ^( )^ for grouping:
x = ^(1 + 2)^ * 3
y = range$(x)$
What have we gained by distinguishing them? Not a lot. If an open
parenthesis immediately follows another token, it's calling that
previous token; if it follows an operator, it's grouping. Seems pretty
simple to me.
(Cue the spate of emails pointing out something I've missed that
breaks that rule, in which case call it a rule of thumb.)
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, Mar 25, 2014 at 2:59 PM, Mark H Harris wrote: > I personally think the answer is extended key maps triggered by meta keys > shift ctrl opt alt command | which call up full alternate mappings of > Greek|Latin|Math|symbols &c which can be chosen by mouse|pointing device. > > > The mac calls these keyboard viewer, and character viewer. In that way the > full unicode set can be available from a standard qwerty keyboard without > modifying the hardware right away. I can get up a character map on any platform fairly easily, and if not, I can always Google the name of the character I want and copy and paste from fileformat.info or some other handy site. It's not that hard. But if I want to say "copyright", it's still quicker for me to type nine letters than to hunt down U+00A9 © to paste in somewhere. Even more so with lambda, which is a shorter word and a less common symbol (having an easy way to type A9 isn't uncommon these days, but not many give an easy way to type U+03BB). I'm much more comfortable typing that out. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, Mar 25, 2014 at 3:08 PM, Rustom Mody wrote: > And Chris is right in (rephrasing) we may have unicode-happy OSes and > languages. We cant reasonably have unicode-happy keyboards. > [What would a million-key keyboard look like? Lets leave the cost aside...] Actually, it wouldn't be that bad. Unicode allows for only 1114112 characters (thanks to UTF-16), of which only the first three planes have any actual characters on them (so, a maximum of about 200K characters). All you'd need would be a system that organizes them (using their hex codepoints isn't exactly useful), and you could type any character with a maximum of, say, 6-8 keystrokes; Huffman coded, of course, so the average would be 1.5 keystrokes per character actually used. Add one meta key: Charset. Hold that and press L and you get (say) λ, U+03BB; Charset+Shift+L is Λ, U+039B. Ctrl+Charset+L might give you a Cyrillic л (U+043B), and Ctrl+Charset+Shift+L would then be Л (U+041B), the upper-case version of that. Emacs users would love it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tuesday, March 25, 2014 9:59:48 AM UTC+5:30, Chris Angelico wrote: > On Tue, Mar 25, 2014 at 3:08 PM, Rustom Mody wrote: > > And Chris is right in (rephrasing) we may have unicode-happy OSes and > > languages. We cant reasonably have unicode-happy keyboards. > > [What would a million-key keyboard look like? Lets leave the cost aside...] > Actually, it wouldn't be that bad. Unicode allows for only 1114112 > characters (thanks to UTF-16), of which only the first three planes > have any actual characters on them (so, a maximum of about 200K > characters). All you'd need would be a system that organizes them > (using their hex codepoints isn't exactly useful), and you could type > any character with a maximum of, say, 6-8 keystrokes; Huffman coded, > of course, so the average would be 1.5 keystrokes per character > actually used. Add one meta key: Charset. Hold that and press L and > you get (say) λ, U+03BB; Charset+Shift+L is Λ, U+039B. Ctrl+Charset+L > might give you a Cyrillic л (U+043B), and Ctrl+Charset+Shift+L would > then be Л (U+041B), the upper-case version of that. > Emacs users would love it. Its already there -- and even easier Switch to cyrillic-jis-russian (whatever that is!) and I get л from k Л from K Full layout ++ |１ ！|２ ＠|３ ＃|４ ” |５ ：|６ ，|７ ．|８ ＊|９ （|０ ）| − ＿|＝ ＋| ё Ё | ++ | й Й | ц Ц | у У | к К | е Е | н Н | г Г | ш Ш | щ Щ | з З | х Х | ъ Ъ | ++ | ф Ф | ы Ы | в В | а А | п П | р Р | о О | л Л | д Д | ж Ж | э Э |＼ ｜| +---+ | я Я | ч Ч | с С | м М | и И | т Т | ь Ь | б Б | ю Ю |／ ？| +-+ +-+ | space bar | +-+ The catch is in the claim to huffman coding Huffman coding requires a statistical distribution Whose shall we take And now the discussion is political not technical -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, Mar 25, 2014 at 4:00 PM, Rustom Mody wrote: > Its already there -- and even easier > Switch to cyrillic-jis-russian (whatever that is!) > and I get л from k Л from K How quickly can you switch, type one letter (to generate one Cyrillic character), and switch back? If you can do that more quickly than typing a word, then (for you!) it might be worth using those letters as symbols. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
