Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Mon, 24 Mar 2014 20:56:19 -0700, Rustom Mody wrote: > Paren vs tuples: why do we need to write (x,) not (x) You don't. You can write x, without the brackets: py> t = 23, py> type(t) It's the comma that makes tuples, not the brackets. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, 25 Mar 2014 17:19:10 +1100, Chris Angelico wrote: > I'll write today's date as 20140325 in some contexts.) Of them, > y/m/d is both the clearest and the least commonly used; with a > four-digit year, there's no way it could be confused for anything else. Shame on you Chris! Don't you know the One True Way to write unambiguous dates is the ISO data format? 2014-03-25 -- Steven -- 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 6:03 PM, Steven D'Aprano wrote: > On Tue, 25 Mar 2014 17:19:10 +1100, Chris Angelico wrote: > >> I'll write today's date as 20140325 in some contexts.) Of them, >> y/m/d is both the clearest and the least commonly used; with a >> four-digit year, there's no way it could be confused for anything else. > > Shame on you Chris! Don't you know the One True Way to write unambiguous > dates is the ISO data format? > > 2014-03-25 Bah, BIND won't let me use ISO format! rosuav@sikorsky:~$ dig kepl.com.au soa +short gideon.rosuav.com. domainmaster.kepl.com.au. 2014030601 7200 3600 2419200 604800 Looks like I last edited that on the 6th inst. But yes, hyphens are more common than slashes for delimited ymd dates. 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 12:33:49 PM UTC+5:30, Steven D'Aprano wrote: > On Mon, 24 Mar 2014 20:56:19 -0700, Rustom Mody wrote: > > Paren vs tuples: why do we need to write (x,) not (x) > You don't. You can write x, without the brackets: > py> t = 23, > py> type(t) > It's the comma that makes tuples, not the brackets. Yeah Chris already corrected that misconception of mine Doesn't chage my point much though -- () overloaded to ',' overloaded -- https://mail.python.org/mailman/listinfo/python-list
Re: Asyncio (or something better) for control of a vacuum system/components.
Shishir writes:
> ...
> 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.
"Asyncio" is targeted at asynchronous (i.e. non-blocking) input/output.
To ensure that the server remains responsive during command execution,
you will need something in addition - e.g. threads or subprocesses.
This way, the commands can be executed (by a separate thread/subprocess)
while the server is still listening to communication.
I know of one framework which supports this kind of interaction:
"medusa/ZServer". However, it is targeted mainly towards standard
internet communication protocols ("HTTP", "FTP", ...).
>From your message, I have gained the impression that you want to support
multiple (concurrent) requests on the same communication channel.
This significantly complicates the task as the responses to those
requests may arrive out of order and may even mix with one another
(on the channel), unless you avoid this carefully.
The "medusa/ZServer" framework (mentioned above) supports HTTP pipelining (i.e.
the client can issue multiple requests without waiting for a response).
However, it starts processing of a request only when all previous
requests from the same (communication) channel have been completed.
This way, it ensures that all responses are delivered in the
same order as the requests (as required by HTTP pipelining).
If out of order responses must be supported, then "medusa/ZServer"
is not an appropriate approach. Special logic is then necessary on
both server and client to associate the responses to the proper
requests.
--
https://mail.python.org/mailman/listinfo/python-list
Re: gdb python how to output integer for examine memory
Wesley writes: > 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) 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. Quite a lot of time has passed since I last had to debug Python processes at C level -- thus, my memory may be unreliable. When I remember right, then "pyo" is used to interprete a C level variable as a Python object (and print it) -- not a Python level variable. In your case, "i" is a Python level variable. You must carefully distinguish between the C level and the Python level. Some commands expect C level names/objects; others may expect Python level names/objects. To learn how you can obtain the value of a Python variable, I see two approaches: look through the list of provided commands (and their documentation) and try to figure out which might be applicable and then may some tests; or look at the implementation of "py-locals" and use this knowledge to define you own command (for this, you will also need to understand the gdb language to define commands). -- https://mail.python.org/mailman/listinfo/python-list
Re: Memory error
Jamie Mitchell writes: > ... > 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 "MemoryError" means that Python cannot get sufficent memory from the operating system. You have already found out one mistake. Should you continue to get "MemoryError" after this is fixed, then your system does not provide enough resources (memory) to solve the problem at hand. You would need to find a way to provide more resources. -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode?
Chris Angelico :
> On Tue, Mar 25, 2014 at 4:14 PM, Mark H Harris wrote:
> Π = pi
>
> That's good! (Although typing Π quicker than pi is majorly pushing it.
It don't think that's good. The lower-case letter π should be used. The
upper-case letter is used for a product, although unicode dedicates a
separate character for the purpose: ∏.
I often see Americans, especially, confuse upper and lower-case letters
in symbols ("KM" for "km", "L" for "l" etc). However, we are dealing
with case-sensitive programming languages, so our eyes should have been
trained to address meaning to upper and lower case.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: gdb python how to output integer for examine memory
在 2014年3月25日星期二UTC+8下午3时49分09秒，dieter写道： > Wesley writes: > > > > > 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) 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. > > > > Quite a lot of time has passed since I last had to debug Python > > processes at C level -- thus, my memory may be unreliable. > > > > When I remember right, then "pyo" is used to interprete > > a C level variable as a Python object (and print it) -- not > > a Python level variable. In your case, "i" is a Python level variable. > > > > You must carefully distinguish between the C level and the Python level. > > Some commands expect C level names/objects; > > others may expect Python level names/objects. > > > > To learn how you can obtain the value of a Python variable, > > I see two approaches: look through the list of provided commands > > (and their documentation) and try to figure out which might be applicable > > and then may some tests; or look at the implementation of "py-locals" > > and use this knowledge to define you own command (for this, > > you will also need to understand the gdb language to define commands). Hi Dieter, Thanks. Actually, I can now see the varialbe names at Python level and C level. I just want to verify x command to monitor the memory content. So, in my origin post, I can get variable i's address, and see the value is 1, then, I wanna have a try x command, the issue is, when use x/format i's address, the output is not 1, but other things:-( -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode?
On Tue, Mar 25, 2014 at 7:05 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Tue, Mar 25, 2014 at 4:14 PM, Mark H Harris wrote:
>> Π = pi
>>
>> That's good! (Although typing Π quicker than pi is majorly pushing it.
>
> It don't think that's good. The lower-case letter π should be used. The
> upper-case letter is used for a product, although unicode dedicates a
> separate character for the purpose: ∏.
>
> I often see Americans, especially, confuse upper and lower-case letters
> in symbols ("KM" for "km", "L" for "l" etc). However, we are dealing
> with case-sensitive programming languages, so our eyes should have been
> trained to address meaning to upper and lower case.
This has been pointed out multiple times, and I did notice it myself.
But it's not significant, and I was trying to avoid nit-picking. If
you can type a capital ∏, you can type a lower-case π, unless there's
something very weird going on. So it still makes his point.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode?
On Tue, 25 Mar 2014 19:23:45 +1100, Chris Angelico wrote: > I was trying to avoid nit-picking What, on comp.lang.python? What's wrong with you? :-) -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode?
On Tue, Mar 25, 2014 at 7:59 PM, Steven D'Aprano wrote: > On Tue, 25 Mar 2014 19:23:45 +1100, Chris Angelico wrote: > >> I was trying to avoid nit-picking > > What, on comp.lang.python? What's wrong with you? > > > :-) I know, it's like refraining from bike-shedding on python-ideas or not reading the Bible in a Presbyterian church service. But occasionally I do try to be polite, or to make a point without worrying about the detlais... :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 25-03-14 06:08, Chris Angelico wrote: > 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 > I thought programs were read more than written. So if writing is made a bit more problematic but the result is more readable because we are able to use symbols that are already familiar from other contexts, I would say it is worth it. -- Antoon Pardon -- 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 8:43 PM, Antoon Pardon wrote: > I thought programs were read more than written. So if writing is made > a bit more problematic but the result is more readable because we are > able to use symbols that are already familiar from other contexts, I > would say it is worth it. It's a matter of extents. If code is read ten times for every time it's written, making it twenty times harder to write and a little bit easier to read is still a bad tradeoff. Also: To what extent IS that symbol familiar from some other context? Are you using Python as a programming language, or should you perhaps be using a mathematical front-end? Not everything needs to perfectly match what anyone from any other context will expect. This is, first and foremost, a *programming* language. 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)
> >>> x = [[1, 2], [3, 4]] > > >>> for x in x: > > ... for x in x: > > ... print(x) > This is valid in the syntax level in python. But it is only good for those writing obscure programs in my opinions at most team works. -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 25-03-14 05:14, Chris Angelico wrote:
> 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.
No they didn't have to. With the transition to python3, the developers
could have opted for empty braces to mean an empty set. And if they
wanted a literal for an empty dictionary, they might have chosen {:}.
Backward-compatibility was already broken so that wasn't an argument.
> 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.
Come on. The problem isn't that both set and dictionary literal use
braces. That doesn't seem to be a problem in python3. The only question
was what should {} represent and how do we get an empty collection of
the other kind. If {} had been an empty set, dict() could have been
used for an empty dictionary is {:} had been unacceptable.
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
[newbie] confusion concerning fetching an element in a 2d-array
I'm confused by the behaviour of the following python-script I wrote:
#!/usr/bin/env python
#I first made a data file 'test.dat' with the following content
#1.0 2 3
#4 5 6.0
#7 8 9
import numpy as np
lines=[line.strip() for line in open('test.dat')]
#convert lines-list to numpy-array
array_lines=np.array(lines)
#fetch element at 2nd row, 2nd column:
print array_lines[1, 1]
When running the script I always get the following error:
IndexError: invalid index
Can anyone here explain me what I am doing wrong and how to fix it?
thanks in advance
jean
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 25-03-14 10:54, Chris Angelico wrote: > On Tue, Mar 25, 2014 at 8:43 PM, Antoon Pardon > wrote: >> I thought programs were read more than written. So if writing is made >> a bit more problematic but the result is more readable because we are >> able to use symbols that are already familiar from other contexts, I >> would say it is worth it. > It's a matter of extents. If code is read ten times for every time > it's written, making it twenty times harder to write and a little bit > easier to read is still a bad tradeoff. > > Also: To what extent IS that symbol familiar from some other context? > Are you using Python as a programming language, or should you perhaps > be using a mathematical front-end? Not everything needs to perfectly > match what anyone from any other context will expect. This is, first > and foremost, a *programming* language. So? We do use + -, so why shouldn't we use × for multiplication. Would such a use already indicate I should use a mathematical front-end? When a programming language is borrowing concepts from mathematics, I see no reason not to borrow the symbols used too. -- Antoon Pardon. -- https://mail.python.org/mailman/listinfo/python-list
Have you ever wondered why there are so many flavors of python. This post answers all your queries.
http://www.techdarting.com/2014/03/why-different-flavors-of-python.html -- https://mail.python.org/mailman/listinfo/python-list
Re: [newbie] confusion concerning fetching an element in a 2d-array
On Tue, 25 Mar 2014 03:26:26 -0700, Jean Dubois wrote:
> I'm confused by the behaviour of the following python-script I wrote:
>
> #!/usr/bin/env python
> #I first made a data file 'test.dat' with the following content
> #1.0 2 3
> #4 5 6.0
> #7 8 9
> import numpy as np
> lines=[line.strip() for line in open('test.dat')]
> #convert lines-list to numpy-array
> array_lines=np.array(lines)
> #fetch element at 2nd row, 2nd column:
> print array_lines[1, 1]
>
>
> When running the script I always get the following error: IndexError:
> invalid index
>
> Can anyone here explain me what I am doing wrong and how to fix it?
Yes. Inspect the array by printing it, and you'll see that it is a one-
dimensional array, not two, and the entries are strings:
py> import numpy as np
py> # simulate a text file
... data = """1.0 2 3
... 4 5 6.0
... 7 8 9"""
py> lines=[line.strip() for line in data.split('\n')]
py> # convert lines-list to numpy-array
... array_lines = np.array(lines)
py> print array_lines
['1.0 2 3' '4 5 6.0' '7 8 9']
The interactive interpreter is your friend! You never need to guess what
the problem is, Python has powerful introspection abilities, one of the
most powerful is also one of the simplest: print. Another powerful tool
in the interactive interpreter is help().
So, what to do about it? Firstly, convert your string read from a file
into numbers, then build your array. Here's one way:
py> values = [float(s) for s in data.split()]
py> print values
[1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0]
py> array_lines = np.array(values)
py> array_lines = array_lines.reshape(3, 3)
py> print array_lines
[[ 1. 2. 3.]
[ 4. 5. 6.]
[ 7. 8. 9.]]
There may be other ways to do this, but that works for me.
--
Steven D'Aprano
http://import-that.dreamwidth.org/
--
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 9:24 PM, Antoon Pardon
wrote:
> No they didn't have to. With the transition to python3, the developers
> could have opted for empty braces to mean an empty set. And if they
> wanted a literal for an empty dictionary, they might have chosen {:}.
> Backward-compatibility was already broken so that wasn't an argument.
Python 3.0 didn't just say "to Hades with backward compatibility". The
breakage was only in places where it was deemed worthwhile. Changing
the meaning of {} would have only small benefit and would potentially
break a LOT of programs, so the devs were right to not do it.
Python 3 and Python 2 are not, contrary to some people's opinions,
completely different languages.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, 25 Mar 2014 11:38:38 +0100, Antoon Pardon wrote: > On 25-03-14 10:54, Chris Angelico wrote: >> On Tue, Mar 25, 2014 at 8:43 PM, Antoon Pardon >> wrote: >>> I thought programs were read more than written. So if writing is made >>> a bit more problematic but the result is more readable because we are >>> able to use symbols that are already familiar from other contexts, I >>> would say it is worth it. >> It's a matter of extents. If code is read ten times for every time it's >> written, making it twenty times harder to write and a little bit easier >> to read is still a bad tradeoff. >> >> Also: To what extent IS that symbol familiar from some other context? >> Are you using Python as a programming language, or should you perhaps >> be using a mathematical front-end? Not everything needs to perfectly >> match what anyone from any other context will expect. This is, first >> and foremost, a *programming* language. > > So? We do use + -, so why shouldn't we use × for multiplication. I can't find × on my keyboard! I tried using x instead, but I got a syntax error: py> 2x3 File "", line 1 2x3 ^ SyntaxError: invalid syntax > Would > such a use already indicate I should use a mathematical front-end? > > When a programming language is borrowing concepts from mathematics, I > see no reason not to borrow the symbols used too. I'd like to sum the squares of the integers from n=1 to 10. In the old Python, I'd write sum(n**2 for n in range(1, 11)), but with the brave new world of maths symbols, I'd like to write this: http://timmurphy.org/examples/summation_large.jpg How do I enter that, and what text editor should I use? -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 25-03-14 12:14, Steven D'Aprano wrote: > On Tue, 25 Mar 2014 11:38:38 +0100, Antoon Pardon wrote: > >> On 25-03-14 10:54, Chris Angelico wrote: >>> On Tue, Mar 25, 2014 at 8:43 PM, Antoon Pardon >>> wrote: I thought programs were read more than written. So if writing is made a bit more problematic but the result is more readable because we are able to use symbols that are already familiar from other contexts, I would say it is worth it. >>> It's a matter of extents. If code is read ten times for every time it's >>> written, making it twenty times harder to write and a little bit easier >>> to read is still a bad tradeoff. >>> >>> Also: To what extent IS that symbol familiar from some other context? >>> Are you using Python as a programming language, or should you perhaps >>> be using a mathematical front-end? Not everything needs to perfectly >>> match what anyone from any other context will expect. This is, first >>> and foremost, a *programming* language. >> So? We do use + -, so why shouldn't we use × for multiplication. > I can't find × on my keyboard! Then use an editor that allows you to configure it, so you can easily use it. That's the kind of advice that is often enough given here if some python feature is hard for the tools someone is using. So why should it be different now? >> Would >> such a use already indicate I should use a mathematical front-end? >> >> When a programming language is borrowing concepts from mathematics, I >> see no reason not to borrow the symbols used too. > I'd like to sum the squares of the integers from n=1 to 10. In the old > Python, I'd write sum(n**2 for n in range(1, 11)), but with the brave new > world of maths symbols, I'd like to write this: > > http://timmurphy.org/examples/summation_large.jpg > > > How do I enter that, and what text editor should I use? You have a point. Blindly following mathematical notation will not work, because mathematics often enough uses positional clues that will be very hard to incorparate in a programming language. But often enough languages tried to use the symbols that were available to them. Now that more are, I see little reason for avoiding there use. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 25-03-14 12:12, Chris Angelico wrote:
> On Tue, Mar 25, 2014 at 9:24 PM, Antoon Pardon
> wrote:
>> No they didn't have to. With the transition to python3, the developers
>> could have opted for empty braces to mean an empty set. And if they
>> wanted a literal for an empty dictionary, they might have chosen {:}.
>> Backward-compatibility was already broken so that wasn't an argument.
> Python 3.0 didn't just say "to Hades with backward compatibility". The
> breakage was only in places where it was deemed worthwhile. Changing
> the meaning of {} would have only small benefit and would potentially
> break a LOT of programs, so the devs were right to not do it.
More programs than those who broke because print was now a function?
Do you think it would have been so problamatic that it couldn't have
been handled by '2to3'?
Maybe breaking backward-compatibility wasn't considered worthwhile,
but that is not the same as stating backward-compatibility was
necessary. And that is how I understood how you stated your claim.
> Python 3 and Python 2 are not, contrary to some people's opinions,
> completely different languages.
And changing the meaning of {} to now indicate the emppty set, wouldn't
have turned it in a completely different language either.
--
Antoon Pardon.
--
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 5:16:14 PM UTC+5:30, Antoon Pardon wrote: > On 25-03-14 12:14, Steven D'Aprano wrote: > >> Would > >> such a use already indicate I should use a mathematical front-end? > >> When a programming language is borrowing concepts from mathematics, I > >> see no reason not to borrow the symbols used too. > > I'd like to sum the squares of the integers from n=1 to 10. In the old > > Python, I'd write sum(n**2 for n in range(1, 11)), but with the brave new > > world of maths symbols, I'd like to write this: > > http://timmurphy.org/examples/summation_large.jpg > > How do I enter that, and what text editor should I use? > You have a point. Blindly following mathematical notation will not > work, because mathematics often enough uses positional clues that > will be very hard to incorparate in a programming language. Two completely separate questions 1. Symbols outside of US-104-keyboard/ASCII used for python functions/constants 2. Non-linear math notation It goes back not just to the first programming languages but to Turing's paper that what a mathematician can do on 2-d paper can be done on a 1-d 'tape'. IOW conflating 1 and 2 is not even a poor strawman argument -- Its only 1 that anyone is talking about. The comparison with APL which had/has at least some pretensions to being mathematics and also simultaneously being a programming language are more appropriate So adding to my earlier list: > Yes APL is a good example to learn mistakes from > - being before its time/technology > - taking a good idea too far > - assuming that I understand clearly implies so do others - not taking others' good ideas seriously Structured programming constructs were hardly known in 1960 when APL was invented. 10 years down they were the rage. APL ignored them -- to its own detriment > > On Tue, 25 Mar 2014 11:38:38 +0100, Antoon Pardon wrote: > >> On 25-03-14 10:54, Chris Angelico wrote: > >>> On Tue, Mar 25, 2014 at 8:43 PM, Antoon Pardon > I thought programs were read more than written. So if writing is made > a bit more problematic but the result is more readable because we are > able to use symbols that are already familiar from other contexts, I > would say it is worth it. > >>> It's a matter of extents. If code is read ten times for every time it's > >>> written, making it twenty times harder to write and a little bit easier > >>> to read is still a bad tradeoff. > >>> Also: To what extent IS that symbol familiar from some other context? > >>> Are you using Python as a programming language, or should you perhaps > >>> be using a mathematical front-end? Not everything needs to perfectly > >>> match what anyone from any other context will expect. This is, first > >>> and foremost, a *programming* language. > >> So? We do use + -, so why shouldn't we use × for multiplication. > > I can't find × on my keyboard! > Then use an editor that allows you to configure it, so you can > easily use it. > That's the kind of advice that is often enough given here if > some python feature is hard for the tools someone is using. > So why should it be different now? > But often enough languages tried to use the symbols that were > available to them. Now that more are, I see little reason for > avoiding there use. I am reminded that when Unix first came out, some of both the early adoption as well as the early pooh-pooh-ing was around the novelty/stupidity of using lower-case in programming -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
In article ,
Antoon Pardon wrote:
> Come on. The problem isn't that both set and dictionary literal use
> braces. That doesn't seem to be a problem in python3. The only question
> was what should {} represent and how do we get an empty collection of
> the other kind. If {} had been an empty set, dict() could have been
> used for an empty dictionary is {:} had been unacceptable.
By analogy to tuples, it could have been {,}.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
In article ,
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.
Our ASR-33s didn't have { and }, so we used \( and \). To be honest, I
don't remember if the c compiler understood those, or if it was mapped
at the tty driver level.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
In article , Mark H Harris wrote: > (we're on one tiny planet, you know?) Speak for yourself. -- 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 11:07 PM, Antoon Pardon
wrote:
> On 25-03-14 12:12, Chris Angelico wrote:
>
>> On Tue, Mar 25, 2014 at 9:24 PM, Antoon Pardon
>> wrote:
>>> No they didn't have to. With the transition to python3, the developers
>>> could have opted for empty braces to mean an empty set. And if they
>>> wanted a literal for an empty dictionary, they might have chosen {:}.
>>> Backward-compatibility was already broken so that wasn't an argument.
>> Python 3.0 didn't just say "to Hades with backward compatibility". The
>> breakage was only in places where it was deemed worthwhile. Changing
>> the meaning of {} would have only small benefit and would potentially
>> break a LOT of programs, so the devs were right to not do it.
>
> More programs than those who broke because print was now a function?
> Do you think it would have been so problamatic that it couldn't have
> been handled by '2to3'?
It makes the same notation mean different things, in ways that are
hard to render clearly. You can write a Py3 program and put this at
the top for Py2:
try:
input = raw_input
range = xrange
except NameError:
# We're running on Python 3
pass
But you can't do the same for braces. You'd have to eschew *both*
literal-ish notations and use explicit constructors everywhere. Not
clean.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
In article <281c8ce1-4f03-4e93-b5cd-d45b85e89...@googlegroups.com>, 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...] In a true unicode environment, the input device may be nothing like our current keyboards. Star Trek has been amazingly accurate about it's predictions of the future. Doors that open automatically as you approach them are now routine. One thing they messed up on was mobile devices; they assumed tricorders and communicators would be separate devices, when in reality our phones now perform both functions. Today's 3-d printers are giving replicators a run for their money. Some people still get bent out of shape when a white man kisses a black woman, but we're working on that. When's the last time you saw somebody typing commands to a computer on Star Trek? -- 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 4:08:38 PM UTC+5:30, Antoon Pardon wrote: > So? We do use + -, so why shouldn't we use × for multiplication. Would > such a use already indicate I should use a mathematical front-end? > When a programming language is borrowing concepts from mathematics, > I see no reason not to borrow the symbols used too. Well... Matters of taste are personal, touchy-feely things and not easily explainable. Some of mine: * for multiply does not bother me; ** for power for some reason does. Even though the only standard math notation is non-linear and is off-limits 'and' bothers me slightly (maybe because I was brought up on Pascal?) '&&' less (and then C) ∧ is of course best (I am a Dijkstra fan) [But then Dijkstra would probably roll over and over in his grave at short-circuit 'and'. Non-commutative?!?! Blasphemy!] ÷ for some reason seems inappropriate (some vague recollection that its an only English; Europeans dont use it??) And if we had hyphen '‐' distinguished from minus '-' then we could have lispish names like call‐with‐current‐continuation properly spelt. And then generations of programmers will thank us for increasing their debugging overtime!! -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 25-03-14 13:45, Chris Angelico wrote: > It makes the same notation mean different things, in ways that are > hard to render clearly. You can write a Py3 program and put this at > the top for Py2: > > try: > input = raw_input > range = xrange > except NameError: > # We're running on Python 3 > pass > > But you can't do the same for braces. You'd have to eschew *both* > literal-ish notations and use explicit constructors everywhere. Not > clean. What about it, is not clean? I understand that you prefer it how it worked out. That is fine by me. But that doesn't make the alternative unclean. Is having to write "set()" unclean somehow when you need an empty set? I wouldn't think so. So I see no reason why having to write "dict()" when you need an empty dictionary wouldn't be clean. Nor would it be unclean, when you have to write somethings a bit differently when you want your program to be compatible both with python2 and python3. You will also need to prefix all your (unicode) strings with u and all your byte strings with b. And probably some more stuff if you want to avoid some pitfalls. -- Antoon Pardon -- 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 6:15:16 PM UTC+5:30, Chris Angelico wrote:
> On Tue, Mar 25, 2014 at 11:07 PM, Antoon Pardon
> > On 25-03-14 12:12, Chris Angelico wrote:
> >> On Tue, Mar 25, 2014 at 9:24 PM, Antoon Pardon
> >>> No they didn't have to. With the transition to python3, the developers
> >>> could have opted for empty braces to mean an empty set. And if they
> >>> wanted a literal for an empty dictionary, they might have chosen {:}.
> >>> Backward-compatibility was already broken so that wasn't an argument.
> >> Python 3.0 didn't just say "to Hades with backward compatibility". The
> >> breakage was only in places where it was deemed worthwhile. Changing
> >> the meaning of {} would have only small benefit and would potentially
> >> break a LOT of programs, so the devs were right to not do it.
> > More programs than those who broke because print was now a function?
> > Do you think it would have been so problamatic that it couldn't have
> > been handled by '2to3'?
> It makes the same notation mean different things, in ways that are
> hard to render clearly. You can write a Py3 program and put this at
> the top for Py2:
> try:
> input = raw_input
> range = xrange
> except NameError:
> # We're running on Python 3
> pass
> But you can't do the same for braces. You'd have to eschew *both*
> literal-ish notations and use explicit constructors everywhere. Not
> clean.
What you are answering (2) is somewhat different from what Anton is asking (1).
1. Use a tool (2to3 inspired) to help move programs to the the new lexicon
2. Use 2to3 to (help) write code that is backward-compatible
It is an invariable given that when heavily compatible code is desired, the
programmer gets the worst of all worlds
--
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 11:35 PM, Roy Smith wrote: > When's the last time you saw somebody typing commands to a computer on > Star Trek? That's more like what comes up in Cars 2. "It's voice activated... but then, everything is these days!" ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: advice on sub-classing multiprocessing.Process and multiprocessing.BaseManager
ChrisA - >> 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 Thanks, I agree that restricting network communications to a parent process would be a good recommended solution, but it's hard to enforce and easy to forget such a recommendation. It seems better to provide lightweight library-specific subclasses of Process (and Pool) and explaining why they should be used. This library (pyepics) already does similar things for interaction with other libraries (notably providing decorators to avoid issues with wxPython). Monkey-patching multiprocessing.Process seems more fragile than subclassing it. It turned out that multiprocessing.pool.Pool was also very easy to subclass. But cleanly subclassing the Managers in multiprocessing.managers look much harder. I'm not sure if this is intentional or not, or if it should be filed as an issue for multiprocessing. For now, I'm willing to say that the multiprocessing managers are not yet available with the pyepics library. 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 Tue, 25 Mar 2014 08:21:19 -0400, Roy Smith wrote:
> In article ,
> Antoon Pardon wrote:
>
>> Come on. The problem isn't that both set and dictionary literal use
>> braces. That doesn't seem to be a problem in python3. The only question
>> was what should {} represent and how do we get an empty collection of
>> the other kind. If {} had been an empty set, dict() could have been
>> used for an empty dictionary is {:} had been unacceptable.
>
> By analogy to tuples, it could have been {,}.
An empty tuple is (), not (,). {,} is just making up random syntax almost
unrelated to anything else. One might as well used {?} or {+}.
If Python 3 had introduced {} to mean the empty set, I *guarantee* that
right now people would be arguing that "Python 3 could have used {} for
the empty dict, and used set() for the empty set" -- and very likely the
same people now arguing the opposite.
Yes, Python could have changed the meaning of {} to mean the empty set.
But you know what? The empty set is not that important. Sets are not
fundamental to Python. Python didn't even have sets until 2.3, and at
first they were just a standard library module, not even built-in. Dicts,
on the other hand, are fundamental to Python. They are used everywhere.
Python is, in a very real sense, built on dicts, not sets. You can
implement sets starting from dicts, but not the other way around: dicts
are more fundamental than sets.
I'm sure it is awfully impressive that mathematicians can derive the laws
of integer maths starting only from the empty set ∅, but as far as
programming goes that's not a very useful thing. Dicts are much more
important, and they are much more commonly used.
--
Steven D'Aprano
http://import-that.dreamwidth.org/
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 25-03-14 13:53, Rustom Mody wrote: > On Tuesday, March 25, 2014 4:08:38 PM UTC+5:30, Antoon Pardon wrote: >> So? We do use + -, so why shouldn't we use × for multiplication. Would >> such a use already indicate I should use a mathematical front-end? >> When a programming language is borrowing concepts from mathematics, >> I see no reason not to borrow the symbols used too. > Well... > Matters of taste are personal, touchy-feely things and not easily > explainable. > > Some of mine: > * for multiply does not bother me; ** for power for some reason does. > Even though the only standard math notation is non-linear and is off-limits > > 'and' bothers me slightly (maybe because I was brought up on Pascal?) > '&&' less (and then C) > ∧ is of course best (I am a Dijkstra fan) > [But then Dijkstra would probably roll over and over in his grave at > short-circuit 'and'. Non-commutative?!?! Blasphemy!] > > ÷ for some reason seems inappropriate > (some vague recollection that its an only English; Europeans dont use it??) > It doesn't bother me. IIRC in primary school before fractions were introduced, > a colon was used to indicate division. > > And if we had hyphen '‐' distinguished from minus '-' then we could have > lispish > names like call‐with‐current‐continuation properly spelt. > And then generations of programmers will thank us for increasing their > debugging overtime!! > Sure we could argue some partciculars. Personnaly I would prefer an up-arrow for exponentiation. IMO the advantage would be mainly in allowing more disambiguity. So that if you as a programmer think about something as an operator, you are not obligated to somehow force it into the mold of + - * / % //. If → would have been used for attribute access, then we could just write 5→to_bytes(4, "little") without having to consider that the lexer would try to interpret it as a floating point. And maybe ⤚ could have been used for concatenation. Which would mean that if you had a class whose instances could both be added and concatenated, you could implement both as an operator. Finally, I think I would prefer the middle dot ⸱ for lispish names so we would have call⸱with⸱current⸱continuation. -- https://mail.python.org/mailman/listinfo/python-list
Re: [newbie] confusion concerning fetching an element in a 2d-array
Op dinsdag 25 maart 2014 12:01:37 UTC+1 schreef Steven D'Aprano:
> On Tue, 25 Mar 2014 03:26:26 -0700, Jean Dubois wrote:
>
> > I'm confused by the behaviour of the following python-script I wrote:
> >
> > #!/usr/bin/env python
> > #I first made a data file 'test.dat' with the following content
> > #1.0 2 3
> > #4 5 6.0
> > #7 8 9
> > import numpy as np
> > lines=[line.strip() for line in open('test.dat')]
> > #convert lines-list to numpy-array
> > array_lines=np.array(lines)
> > #fetch element at 2nd row, 2nd column:
> > print array_lines[1, 1]
> >
> >
> > When running the script I always get the following error: IndexError:
> > invalid index
> >
> > Can anyone here explain me what I am doing wrong and how to fix it?
>
> Yes. Inspect the array by printing it, and you'll see that it is a one-
> dimensional array, not two, and the entries are strings:
>
>
> py> import numpy as np
> py> # simulate a text file
> ... data = """1.0 2 3
> ... 4 5 6.0
> ... 7 8 9"""
> py> lines=[line.strip() for line in data.split('\n')]
> py> # convert lines-list to numpy-array
> ... array_lines = np.array(lines)
> py> print array_lines
> ['1.0 2 3' '4 5 6.0' '7 8 9']
>
>
> The interactive interpreter is your friend! You never need to guess what
> the problem is, Python has powerful introspection abilities, one of the
> most powerful is also one of the simplest: print. Another powerful tool
> in the interactive interpreter is help().
>
> So, what to do about it? Firstly, convert your string read from a file
> into numbers, then build your array. Here's one way:
>
> py> values = [float(s) for s in data.split()]
> py> print values
> [1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0]
> py> array_lines = np.array(values)
> py> array_lines = array_lines.reshape(3, 3)
> py> print array_lines
> [[ 1. 2. 3.]
> [ 4. 5. 6.]
> [ 7. 8. 9.]]
>
Dear Steve,
Thanks for answering my question but unfortunately now I'm totally
confused.
Above I see parts from different programs which I can't
assemble together to one working program (I really tried hard).
Can I tell from your comment I shouldn't use numpy?
I also don't see how to get the value an element specified by (row,
column) from a numpy_array like "array_lines" in my original code
All I need is a little python-example reading a file with e.g. three lines
with three numbers per line and putting those numbers as floats in a
3x3-numpy_array, then selecting an element from that numpy_array using
it's row and column-number.
thanks in advance and kind regards,
jean
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Wed, Mar 26, 2014 at 12:43 AM, Antoon Pardon wrote: >> It doesn't bother me. IIRC in primary school before fractions were >> introduced, >> a colon was used to indicate division. The way I learned it, a colon was for a ratio, and a horizontal line was for a fraction. Both of them effectively indicate division, but with a distinct difference. If you have four red objects and two blue ones, the ratio of red to blue is 4 : 2 or 2 : 1, but the fraction (proportion) that are red is 4 / 6 or 2 / 3. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Wed, Mar 26, 2014 at 12:07 AM, Rustom Mody wrote: > What you are answering (2) is somewhat different from what Anton is asking > (1). > > 1. Use a tool (2to3 inspired) to help move programs to the the new lexicon > 2. Use 2to3 to (help) write code that is backward-compatible > > It is an invariable given that when heavily compatible code is desired, the > programmer gets the worst of all worlds That is true. But writing cross-compatible code IS important, and that means that backward compatibility is still important, and that breaking it is a cost - which was my original point. Other non-backward-compatible changes at 3.0 are not justification to arbitrarily change the meanings of syntactic elements. Don't forget, even if you're not writing a single file that gets executed unmodified on two versions, you still have to worry about your brain changing gear. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: advice on sub-classing multiprocessing.Process and multiprocessing.BaseManager
On Wed, Mar 26, 2014 at 12:34 AM, wrote: > Monkey-patching multiprocessing.Process seems more fragile than subclassing > it. It turned out that multiprocessing.pool.Pool was also very easy to > subclass. But cleanly subclassing the Managers in multiprocessing.managers > look much harder. I'm not sure if this is intentional or not, or if it > should be filed as an issue for multiprocessing. For now, I'm willing to > say that the multiprocessing managers are not yet available with the pyepics > library. > Subclassing is actually more fragile than you might think. As you've found, you need to fidget with more and more classes to make your change "stick", and also, any small change to implementation details in the superclass could suddenly break things. It's not really any safer than monkeypatching, despite all the OO fanatics saying how easy it is to rework by subclassing. At least when you monkeypatch, you *know* you're fiddling with internals. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 25-03-14 14:36, Steven D'Aprano wrote:
> On Tue, 25 Mar 2014 08:21:19 -0400, Roy Smith wrote:
>
>> In article ,
>> Antoon Pardon wrote:
>>
>>> Come on. The problem isn't that both set and dictionary literal use
>>> braces. That doesn't seem to be a problem in python3. The only question
>>> was what should {} represent and how do we get an empty collection of
>>> the other kind. If {} had been an empty set, dict() could have been
>>> used for an empty dictionary is {:} had been unacceptable.
>> By analogy to tuples, it could have been {,}.
> An empty tuple is (), not (,). {,} is just making up random syntax almost
> unrelated to anything else. One might as well used {?} or {+}.
>
> If Python 3 had introduced {} to mean the empty set, I *guarantee* that
> right now people would be arguing that "Python 3 could have used {} for
> the empty dict, and used set() for the empty set" -- and very likely the
> same people now arguing the opposite.
Sure and other people would have defended that choice and very likely
the same people that are defending the current choice now. What is
your point?
> Yes, Python could have changed the meaning of {} to mean the empty set.
> But you know what? The empty set is not that important. Sets are not
> fundamental to Python. Python didn't even have sets until 2.3, and at
> first they were just a standard library module, not even built-in. Dicts,
> on the other hand, are fundamental to Python. They are used everywhere.
> Python is, in a very real sense, built on dicts, not sets. You can
> implement sets starting from dicts, but not the other way around: dicts
> are more fundamental than sets.
Fine, dicts are more fundamental. I just don't see that as such a big
argument against using a different literal for the empty dictionary
than was used in python2 and using {} to indicate the empty set. I
would have preferred it that way, but I don't consider it a big deal.
I just consider the arguments weak for those who seem to argue that
using {} for an empty dictionary in python3 was as good as unavoidable.
--
Antoon Pardon
--
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 7:26:47 PM UTC+5:30, Chris Angelico wrote: > On Wed, Mar 26, 2014 at 12:43 AM, Antoon Pardon > >> It doesn't bother me. IIRC in primary school before fractions were > >> introduced, > >> a colon was used to indicate division. > The way I learned it, a colon was for a ratio, and a horizontal line > was for a fraction. Both of them effectively indicate division, but > with a distinct difference. If you have four red objects and two blue > ones, the ratio of red to blue is 4 : 2 or 2 : 1, but the fraction > (proportion) that are red is 4 / 6 or 2 / 3. http://www.unicode.org/mail-arch/unicode-ml/y2012-m07/0053.html -- 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 7:13:09 PM UTC+5:30, Antoon Pardon wrote: > On 25-03-14 13:53, Rustom Mody wrote: > > On Tuesday, March 25, 2014 4:08:38 PM UTC+5:30, Antoon Pardon wrote: > >> So? We do use + -, so why shouldn't we use × for multiplication. Would > >> such a use already indicate I should use a mathematical front-end? > >> When a programming language is borrowing concepts from mathematics, > >> I see no reason not to borrow the symbols used too. > > Well... > > Matters of taste are personal, touchy-feely things and not easily > > explainable. > > Some of mine: > > * for multiply does not bother me; ** for power for some reason does. > > Even though the only standard math notation is non-linear and is off-limits > > 'and' bothers me slightly (maybe because I was brought up on Pascal?) > > '&&' less (and then C) > > ∧ is of course best (I am a Dijkstra fan) > > [But then Dijkstra would probably roll over and over in his grave at > > short-circuit 'and'. Non-commutative?!?! Blasphemy!] > > ÷ for some reason seems inappropriate > > (some vague recollection that its an only English; Europeans dont use it??) > > It doesn't bother me. IIRC in primary school before fractions were > > introduced, > > a colon was used to indicate division. > > And if we had hyphen '‐' distinguished from minus '-' then we could have > > lispish > > names like call‐with‐current‐continuation properly spelt. > > And then generations of programmers will thank us for increasing their > > debugging overtime!! > Sure we could argue some partciculars. Personnaly I would prefer an up-arrow > for exponentiation. Ok > IMO the advantage would be mainly in allowing more disambiguity. So that if > you as a programmer think about something as an operator, you are not > obligated > to somehow force it into the mold of + - * / % //. > If → would have been used for attribute access, then we could just write Nice > 5→to_bytes(4, "little") without having to consider that the lexer would > try to interpret it as a floating point. > And maybe ⤚ could have been used for concatenation. Which would mean that Super! Anything but a (randomly overloaded) +! > if you had a class whose instances could both be added and concatenated, > you could implement both as an operator. > Finally, I think I would prefer the middle dot ⸱ for lispish names so > we would have call⸱with⸱current⸱continuation. A bit unreadable out here but not too bad -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, 25 Mar 2014 08:35:02 -0400, Roy Smith wrote: > In article <281c8ce1-4f03-4e93-b5cd-d45b85e89...@googlegroups.com>, > 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...] > > In a true unicode environment, the input device may be nothing like our > current keyboards. I doubt it. I expect that they will be based on our current keyboards. > Star Trek has been amazingly accurate about it's predictions of the > future. O_o > Doors that open automatically as you approach them are now > routine. It's very easy to predict things that have already happened. Star Trek was created in 1966. The electric automatic door was invented in 1954 by Lew Hewitt and Dee Horton. (Well, actually the first automatic door was built in the 1st century CE by Heron of Alexandra, but that's another story.) Electric doors may be common in some commercial premises, such as shopping centres and some office buildings, but I wouldn't call them routine. > One thing they messed up on was mobile devices; they assumed > tricorders and communicators would be separate devices, when in reality > our phones now perform both functions. Today's 3-d printers are giving > replicators a run for their money. Today's 3D printers are to replicators what a stone axe is to a full wood- working tool shop. > Some people still get bent out of > shape when a white man kisses a black woman, but we're working on that. > > When's the last time you saw somebody typing commands to a computer on > Star Trek? 1986, when I last saw Star Trek IV. The Star Trek universe also predicts that money will be obsolete. How's that prediction working out? -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Wed, Mar 26, 2014 at 1:13 AM, Steven D'Aprano wrote: > On Tue, 25 Mar 2014 08:35:02 -0400, Roy Smith wrote: > >> In article <281c8ce1-4f03-4e93-b5cd-d45b85e89...@googlegroups.com>, >> 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...] >> >> In a true unicode environment, the input device may be nothing like our >> current keyboards. > > I doubt it. I expect that they will be based on our current keyboards. Rule #0 of any voice-activated system: The command word "Console" MUST summon a terminal window, and make available a keyboard and screen on which to use it. This console MAY demand authentication (via typed password) before operating. I don't know if that's written anywhere, but it ought to be. It should be as fundamental as Asimov's laws of robotics. That one simple rule would improve scifi like "Eureka" no end. Hey look, we have a rogue AI... "CONSOLE!"... hey look, we have a rogue AI on a system that's now powered off. Crisis averted, now go solve the problem in a mundane and not very TV-friendly way... >> Star Trek has been amazingly accurate about it's predictions of the >> future. > > O_o I like the Scott Adams take on that. He predicted (in the 1990s) that the future would *not* be like Star Trek, because human reproduction depends on genuine relationships being cheaper/easier than artificial ones. If you could go onto the holodeck and create yourself the perfect (wo)man of your dreams, why would you ever date a real one? The holodeck would be humanity's last invention. >> When's the last time you saw somebody typing commands to a computer on >> Star Trek? > > 1986, when I last saw Star Trek IV. You actually watched it? I got pretty much bored with the series before even finishing TNG. (I'm not 100% sure, but I think I watched every TOS episode.) > The Star Trek universe also predicts that money will be obsolete. How's > that prediction working out? And it further predicts that, thanks to the invention of the holodeck and the replicator, humanity will lose all sense of purpose and challenge, and will send ships out to go^H^Hgo to places where nobody's yet been, because the entire human race is *bored out of its petty little brain* with nothing exciting left to do. Yup, that's the whole unpublished backstory right there, sorry for the spoilers! (I got this from Scott Adams too. He seems to know his stuff.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, 25 Mar 2014 05:53:45 -0700, Rustom Mody wrote: > And if we had hyphen '‐' distinguished from minus '-' then we could have > lispish names like call‐with‐current‐continuation properly spelt. And > then generations of programmers will thank us for increasing their > debugging overtime!! :-) Full Unicode support in a language is, alas, a double-edged sword. While it has advantages, it also has disadvantages. py> А = 1 py> A = А + 1 py> assert A == А Traceback (most recent call last): File "", line 1, in AssertionError While I can see the appeal of certain Unicode symbols, I really wouldn't like to have to deal with code that looks like this: x∫2*y+∬e**3∺z≹(x+1)≽y⋝w If I wanted line-noise, I know where to get Perl :-) -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: [newbie] confusion concerning fetching an element in a 2d-array
Jean Dubois Wrote in message: > Op dinsdag 25 maart 2014 12:01:37 UTC+1 schreef Steven D'Aprano: >> >> py> values = [float(s) for s in data.split()] >> py> print values >> [1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0] >> py> array_lines = np.array(values) >> py> array_lines = array_lines.reshape(3, 3) >> py> print array_lines >> [[ 1. 2. 3.] >> [ 4. 5. 6.] >> [ 7. 8. 9.]] >> > Dear Steve, > Thanks for answering my question but unfortunately now I'm totally > confused. > Above I see parts from different programs which I can't > assemble together to one working program (I really tried hard). > Can I tell from your comment I shouldn't use numpy? > I also don't see how to get the value an element specified by (row, > column) from a numpy_array like "array_lines" in my original code I don't use numpy, but I thought Steven's description was clear enough. Your problem was not the extraction, but the creation of the array. Use print to prove that to yourself. > > All I need is a little python-example reading a file with e.g. three lines > with three numbers per line and putting those numbers as floats in a > 3x3-numpy_array, then selecting an element from that numpy_array using > it's row and column-number. If your instructor wanted you to copy examples, he would have given you one. First write some code to split and convert each line into floats. You don't even try that in your original. Then do that in a loop. Now you have all the floats in one list or array. I presume that it's two dimensional. Use print to check. If it's not, you'll have to either post process it with a reshape method, or change the way you accumulate it. I can't help with the latter. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, 25 Mar 2014 05:09:20 -0700, Rustom Mody wrote: > Two completely separate questions > > 1. Symbols outside of US-104-keyboard/ASCII used for python >functions/constants > 2. Non-linear math notation > > It goes back not just to the first programming languages but to Turing's > paper that what a mathematician can do on 2-d paper can be done on a 1-d > 'tape'. IOW conflating 1 and 2 is not even a poor strawman argument -- > Its only 1 that anyone is talking about. Not so. Mark Harris said: [quote] But what if python had a math symbols extension so that universal mathematics could be written the way we do it on a black|board, er, I mean white|board? I think that's pretty explicit that he's talking about writing mathematical code the way mathematicians write mathematics. Antoon Pardon referred to borrowing the symbols used in mathematics. But the point is that the symbols come with notation: - (minus) can be prefix unary operator or a infix binary operator. ∑ (summation) is a quaternary operator, it takes four arguments: a variable name, a lower limit, an upper limit, and an expression. To be true to the mathematical notation, we ought to write it the way mathematicians do. The thing is, we can't just create a ∑ function, because it doesn't work the way the summation operator works. The problem is that we would want syntactic support, so we could write something like this: p = 2 ∑(n, 1, 10, n**p) This cannot be an ordinary function, because if it were, the n**p expression would be evaluated before passing the result to the function. We want it to delay evaluation, like a list comp: [n**p for n in range(1, 11)] the expression n**p gets evaluated inside the list comp. That cannot be written as a function either: list_comp(n**p, n, range(1, 11)) Mark's idea of a maths blackboard is not ridiculous. That's what Mathematica does. To enter a sum like the above in Mathematica, you can enter: ESC sum ESC Ctrl+$ n=1 Ctrl+% 10 Ctrl+Space n^p to give you the summation 10 ∑ n**p n=1 Obviously this requires a custom editor. https://reference.wolfram.com/mathematica/tutorial/EnteringTwoDimensionalInput.html But Mathematica is a specialist system for doing mathematics, not a general purpose language like Python. Of course one could *write* a Mathematica-like system in Python, and I expect that Sage may even have something like this (if it doesn't, it could) but one shouldn't hammer the specialised round peg of complex mathematical notation into the square peg of a general purpose programming language. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- 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 7:53:23 PM UTC+5:30, Steven D'Aprano wrote: > On Tue, 25 Mar 2014 05:53:45 -0700, Rustom Mody wrote: > > And if we had hyphen '‐' distinguished from minus '-' then we could have > > lispish names like call‐with‐current‐continuation properly spelt. And > > then generations of programmers will thank us for increasing their > > debugging overtime!! > :-) > Full Unicode support in a language is, alas, a double-edged sword. While > it has advantages, it also has disadvantages. > py> А = 1 > py> A = А + 1 > py> assert A == А > Traceback (most recent call last): > AssertionError Even with 'good' ol ASCII giving enough trouble between O and 0, 1 and l, we certainly dont want more such headaches! In apps, a serious consideration of unicode entails a cycle of i18n and l10n. The l10n for programming languages is arguably harder -- if python is 'localized' to some (human) language L, maybe all the builtins should be also translated? And whats the use of that without full translation of the docs? Its not a pleasing thought... Something intermediate needs to be found... Some thoughts (quite half cooked): 1. Human -- 'natural' -- languages and math are not in the same category If Cyrillic A gets in Roman probably shouldn't. 2. There needs to be some intermediate binding time -- eg when the system is installed -- when suitable char-tables are set up. Case-in-point: Many folks in haskell-land have wanted to replace the '\' with the 'λ'. This has not worked out so far because λ belongs to the same unicode class as other lower-case letters. So since this is possible: Prelude> let λ = 1 Prelude> λ 1 Prelude> the other more-natural-to-haskell usage is precluded. So these classes need to be changeable and late-bindable. Not as late as runtime but later than build-time. Probably same as the choice of locales on a system > While I can see the appeal of certain Unicode symbols, I really wouldn't > like to have to deal with code that looks like this: > x∫2*y+∬e**3∺z≹(x+1)≽y⋝w > If I wanted line-noise, I know where to get Perl :-) Yes... neither Perl nor Cobol is pleasant -- https://mail.python.org/mailman/listinfo/python-list
Re: [newbie] confusion concerning fetching an element in a 2d-array
On Tue, 25 Mar 2014 06:47:23 -0700, Jean Dubois wrote: [...] > Thanks for answering my question but unfortunately now I'm totally > confused. > Above I see parts from different programs which I can't assemble > together to one working program (I really tried hard). Can I tell from > your comment I shouldn't use numpy? No, you misunderstood me. I never suggested that you avoid numpy. If you read my code, I use numpy. That's the "import numpy as np", and then later I refer to np. What I suggested is that you open up the Python interactive interpreter and use it for experimentation. Not that you avoid numpy! You will use numpy inside the interactive interpreter. Do you know how to start the interactive interpreter? You seem to be using Linux, or maybe Mac. Open a console or xterm window, and type python then press Enter, and the interactive interpreter will start. > I also don't see how to get the > value an element specified by (row, column) from a numpy_array like > "array_lines" in my original code Once you build the array, you get the element the same way you tried (but failed) earlier: print array_lines[1, 1] will print the element at row 1, column 1. The problem you had before was that you had a one dimensional array, not a two dimensional one. > All I need is a little python-example reading a file with e.g. three > lines with three numbers per line and putting those numbers as floats > in a 3x3-numpy_array, then selecting an element from that numpy_array > using it's row and column-number. Yes, I'm sure you do. And you will learn much more by writing this code yourself. You were very, very close with your earlier attempt. In English, you had: * import the numpy module * read the file into a list of text lines * store the text lines in a numpy array * try to print a single item from the array but it failed because the list of lines was only one dimensional. I gave you some code that was very similar: * import the numpy module * fake a text file using a string * split the string into a list of substrings * convert each substring into a number (float) * store the numbers in a numpy array * change the size of the array to turn it from 1D to 2D * print the array Can you identify which part of code goes with each English description? That's your first job. Then identify the parts of code you want to take from my example and put it into your example. Good luck, and have fun! -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: [newbie] confusion concerning fetching an element in a 2d-array
Jean Dubois wrote:
> Op dinsdag 25 maart 2014 12:01:37 UTC+1 schreef Steven D'Aprano:
>> On Tue, 25 Mar 2014 03:26:26 -0700, Jean Dubois wrote:
>>
>> > I'm confused by the behaviour of the following python-script I wrote:
>> >
>> > #!/usr/bin/env python
>> > #I first made a data file 'test.dat' with the following content
>> > #1.0 2 3
>> > #4 5 6.0
>> > #7 8 9
>> > import numpy as np
>> > lines=[line.strip() for line in open('test.dat')]
>> > #convert lines-list to numpy-array
>> > array_lines=np.array(lines)
>> > #fetch element at 2nd row, 2nd column:
>> > print array_lines[1, 1]
>> >
>> >
>> > When running the script I always get the following error: IndexError:
>> > invalid index
>> >
>> > Can anyone here explain me what I am doing wrong and how to fix it?
>>
>> Yes. Inspect the array by printing it, and you'll see that it is a one-
>> dimensional array, not two, and the entries are strings:
>>
>>
>> py> import numpy as np
>> py> # simulate a text file
>> ... data = """1.0 2 3
>> ... 4 5 6.0
>> ... 7 8 9"""
>> py> lines=[line.strip() for line in data.split('\n')]
>> py> # convert lines-list to numpy-array
>> ... array_lines = np.array(lines)
>> py> print array_lines
>> ['1.0 2 3' '4 5 6.0' '7 8 9']
>>
>>
>> The interactive interpreter is your friend! You never need to guess what
>> the problem is, Python has powerful introspection abilities, one of the
>> most powerful is also one of the simplest: print. Another powerful tool
>> in the interactive interpreter is help().
>>
>> So, what to do about it? Firstly, convert your string read from a file
>> into numbers, then build your array. Here's one way:
>>
>> py> values = [float(s) for s in data.split()]
>> py> print values
>> [1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0]
>> py> array_lines = np.array(values)
>> py> array_lines = array_lines.reshape(3, 3)
>> py> print array_lines
>> [[ 1. 2. 3.]
>> [ 4. 5. 6.]
>> [ 7. 8. 9.]]
>>
> Dear Steve,
> Thanks for answering my question but unfortunately now I'm totally
> confused.
> Above I see parts from different programs which I can't
> assemble together to one working program (I really tried hard).
> Can I tell from your comment I shouldn't use numpy?
> I also don't see how to get the value an element specified by (row,
> column) from a numpy_array like "array_lines" in my original code
>
> All I need is a little python-example reading a file with e.g. three lines
> with three numbers per line and putting those numbers as floats in a
> 3x3-numpy_array, then selecting an element from that numpy_array using
> it's row and column-number.
I'll try, too, but be warned that I'm using the same methology as Steven.
Try to replicate every step in the following exploration.
First let's make sure we start with the same data:
$ cat test.dat
1.0 2 3
4 5 6.0
7 8 9
Then fire up the interactve interpreter:
$ python
Python 2.7.5+ (default, Feb 27 2014, 19:37:08)
[GCC 4.8.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> lines = [line.strip() for line in open("test.dat")]
>>> lines
['1.0 2 3', '4 5 6.0', '7 8 9']
As you can see lines is a list of three strings.
Let's break these strings into parts:
>>> cells = [line.split() for line in lines]
>>> cells
[['1.0', '2', '3'], ['4', '5', '6.0'], ['7', '8', '9']]
We now have a list of lists of strings and you can address individual items
with
>>> cells[1][2]
'6.0'
What happens when pass this list of lists of strings to the numpy.array()
constructor?
>>> a = numpy.array(cells)
>>> a
array([['1.0', '2', '3'],
['4', '5', '6.0'],
['7', '8', '9']],
dtype='|S3')
>>> a[1,2]
'6.0'
It sort of works, but the array entries are strings rather than floating
point numbers. Let's fix that:
>>> a = numpy.array(cells, dtype=float)
>>> a
array([[ 1., 2., 3.],
[ 4., 5., 6.],
[ 7., 8., 9.]])
>>> a[1,2]
6.0
OK, now we can put the previous steps into a script:
$ cat tmp.py
import numpy
cells = [line.split() for line in open("test.dat")]
a = numpy.array(cells, dtype=float)
print a[1, 2]
Run it:
$ python tmp.py
6.0
Seems to work. But reading a 2D array from a file really looks like a common
task -- there should be a library function for that:
$ python
Python 2.7.5+ (default, Feb 27 2014, 19:37:08)
[GCC 4.8.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> numpy.loadtxt("test.dat")
array([[ 1., 2., 3.],
[ 4., 5., 6.],
[ 7., 8., 9.]])
--
https://mail.python.org/mailman/listinfo/python-list
Re: [newbie] confusion concerning fetching an element in a 2d-array
On 3/25/14 9:42 AM, Dave Angel wrote:
All I need is a little python-example reading a file with e.g. three lines
with three numbers per line and putting those numbers as floats in a
3x3-numpy_array, then selecting an element from that numpy_array using
it's row and column-number.
If your instructor wanted you to copy examples, he would have
given you one.
{ouch}
Give them a toad they'll have warts all day; teach them to eat a toad
they'll never have warts again... or something like that.
marcus
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 3/25/14 7:36 AM, Roy Smith wrote:
(we're on one tiny planet, you know?)
Speak for yourself.
Are others on this list, um, on a different planet? Or, am I the only
one who knows its tiny?
Yes, we're on a tiny planet revolving around a speck of a star, at the
edge of an insignificant galaxy ...
{not that it matters}
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to clear all content in a Tk()
What about this: Put a Frame() inside the root: `frame = Frame(root)`. This frame will be the only immediate child of root. Everything else will be put inside the frame. When you need to clear the root, call `frame.destroy()`. This will destroy `frame` and all its children. You will need to recreate the frame, but not the root. 2014-03-24 17:30 GMT-03:00 : > 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 > -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode?
On Tue, Mar 25, 2014 at 9:05 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Tue, Mar 25, 2014 at 4:14 PM, Mark H Harris wrote:
>> Π¹ = pi
>>
>> That's good! (Although typing Π¹ quicker than pi is majorly pushing it.
>
> It don't think that's good. The lower-case letter π² should be used. The
> upper-case letter is used for a product, although unicode dedicates a
> separate character for the purpose: ∏³.
>
> I often see Americans, especially, confuse upper and lower-case letters
> in symbols ("KM" for "km", "L" for "l" etc).
“L” is actually valid, and so is “l”. This happens mainly because
humans (and computers) tend to write “1 l” (one liter, one-ell) in a
way that makes it harder to distinguish (becoming eleven or ell-ell),
especially if you don’t include the space (which is invalid).
On Tue, Mar 25, 2014 at 9:23 AM, Chris Angelico wrote:
> If you can type a capital ∏³, you can type a lower-case π², unless there's
> something very weird going on.
Nitpick time! (because we all love it so much!)
Π¹ = U+03A0 GREEK CAPITAL LETTER PI
π² = U+03C0 GREEK SMALL LETTER PI
∏³ = U+220F N-ARY PRODUCT
“If you can type an N-ARY PRODUCT, you can type a GREEK SMALL LETTER
PI, unless there’s something very weird going on.”
…like, the user is in the past and is using ISO 8859-7 (instead of a
21st-century encoding, like UTF-8). An encoding which has support for
Π¹ and π², but not for ∏³… (of course, this assumes that, if we add
those new characters into python, we allow any encoding, somehow.)
That’s not too weird, other than the ancient encoding being used.
(though that’s a bit less weird on Windows, but that’d be
Windows-1253.)
Oh: and speaking of fancy Unicode characters that are worthless
~duplicates, spot the difference here:
µ μ
If you are lucky enough (and, luckiness may involve reading this
e-mail in Helvetica (not Neue though) on a Mac), you can clearly see
that they are different. If you are using a font that does not
differentiate them, you may think they’re the same. If you ask some
intelligent software (like `unicodedata.name()` in Python), you’ll
quickly find out the first is MICRO SIGN, and the other is GREEK SMALL
LETTER MU. Such craziness is what makes Unicode Unicode.
--
Chris “Kwpolska” Warrick
PGP: 5EAAEA16
stop html mail | always bottom-post | only UTF-8 makes sense
--
https://mail.python.org/mailman/listinfo/python-list
Re: python installation on windows
On Tuesday, 25 March 2014 10:16:20 UTC-8, rbor...@gmail.com wrote: > On Sunday, 23 March 2014 18:22:54 UTC-8, Rhodri James wrote: > > > On Sun, 23 Mar 2014 17:09:09 -, wrote: > > > > > > > > > > > > > Hi Everybody > > > > > > > > > > > > > > actually i want to run python on web browser. > > > > > > > > > > > > Actually you don't. You want to run Python on a web server, which > > > > > > fortunately is a good deal easier. > > > > > > > > > > > > > I downloaded python and installed but i'm not able to run it in browser > > > > > > > but it running using command prompt. so i trying to install mod_wsgi > > > > > > > 3.4. So i downloaded precompiled version mod_wsgi-3.4.ap22.win32-py2.6 > > > > > > > and copied mod_wsgi.so file to C:\wamp\bin\apache\Apache2.2.11\modules > > > > > > > after i'm trying to run .\configure on path C:\Documents and > > > > > > > Settings\Rahul\Desktop\mod_wsgi-3.4.ap22.win32-py2.6 but it giving me > > > > > > > error that .\configure is not recognized as internal or external command. > > > > > > > > > > > > > > So please suggest me what can i do for that, i'm so beginner to python > > > > > > > and installing and configuring modules for apache. > > > > > > > > > > > > The ".\configure" thing is for Linux installations using autotools; it's > > > > > > not going to work on Windows. > > > > > > > > > > > > I don't run Apache on Windows, so I'm just guessing from the documentation > > > > > > here, but the mod_wsgi "Installation on Windows" page says to "follow the > > > > > > instructions for loading mod_wsgi in the Quick Installation Guide." The > > > > > > "Quick Installation Guide" page has instructions for editing the Apache > > > > > > config files. No mention of running ".\configure" -- why are you doing > > > > > > that? Try just editing the config files as the documentation suggests and > > > > > > see if that works. > > > > > > > > > > > > -- > > > > > > Rhodri James *-* Wildebeest Herder to the Masses > > > > Thanks for your comment but i also edited httpd.conf file then my wamp not > running > > LoadModule php5_module "c:/wamp/bin/php/php5.3.0/php5apache2_2.dll" > > This line i added on line 128 but nothing. Wampserver showing yellow. > > I'm not getting what happening. I'm doing as per suggested in documentation > > > > Thanks And again if i'm removing this line then wampserver works properly -- https://mail.python.org/mailman/listinfo/python-list
Re: python installation on windows
On Sunday, 23 March 2014 18:22:54 UTC-8, Rhodri James wrote: > On Sun, 23 Mar 2014 17:09:09 -, wrote: > > > > > Hi Everybody > > > > > > actually i want to run python on web browser. > > > > Actually you don't. You want to run Python on a web server, which > > fortunately is a good deal easier. > > > > > I downloaded python and installed but i'm not able to run it in browser > > > but it running using command prompt. so i trying to install mod_wsgi > > > 3.4. So i downloaded precompiled version mod_wsgi-3.4.ap22.win32-py2.6 > > > and copied mod_wsgi.so file to C:\wamp\bin\apache\Apache2.2.11\modules > > > after i'm trying to run .\configure on path C:\Documents and > > > Settings\Rahul\Desktop\mod_wsgi-3.4.ap22.win32-py2.6 but it giving me > > > error that .\configure is not recognized as internal or external command. > > > > > > So please suggest me what can i do for that, i'm so beginner to python > > > and installing and configuring modules for apache. > > > > The ".\configure" thing is for Linux installations using autotools; it's > > not going to work on Windows. > > > > I don't run Apache on Windows, so I'm just guessing from the documentation > > here, but the mod_wsgi "Installation on Windows" page says to "follow the > > instructions for loading mod_wsgi in the Quick Installation Guide." The > > "Quick Installation Guide" page has instructions for editing the Apache > > config files. No mention of running ".\configure" -- why are you doing > > that? Try just editing the config files as the documentation suggests and > > see if that works. > > > > -- > > Rhodri James *-* Wildebeest Herder to the Masses Thanks for your comment but i also edited httpd.conf file then my wamp not running LoadModule php5_module "c:/wamp/bin/php/php5.3.0/php5apache2_2.dll" This line i added on line 128 but nothing. Wampserver showing yellow. I'm not getting what happening. I'm doing as per suggested in documentation Thanks -- https://mail.python.org/mailman/listinfo/python-list
Re: python installation on windows
On Sunday, 23 March 2014 13:07:28 UTC-8, tad na wrote: > On Sunday, March 23, 2014 12:33:02 PM UTC-5, tad na wrote: > > > On Sunday, March 23, 2014 12:09:09 PM UTC-5, rbor...@gmail.com wrote: > > > > Hi Everybody > > > > actually i want to run python on web browser. I downloaded python and > > > installed but i'm not able to run it in browser but it running using > > > command prompt. so i trying to install mod_wsgi 3.4. So i downloaded > > > precompiled version mod_wsgi-3.4.ap22.win32-py2.6 and copied mod_wsgi.so > > > file to C:\wamp\bin\apache\Apache2.2.11\modules after i'm trying to run > > > .\configure on path C:\Documents and > > > Settings\Rahul\Desktop\mod_wsgi-3.4.ap22.win32-py2.6 but it giving me > > > error that .\configure is not recognized as internal or external command. > > > > > > So please suggest me what can i do for that, i'm so beginner to python > > > and installing and configuring modules for apache. > > > > > > Thanks > > > > > > Rahul > > > To set up a web browser: > > > > > 1.open a dos window > > > 2.navigate to dir you want "served" > > > 3.type "python -m SimpleHTTPServer &." > > 4. open browser and type http://localhost:/ It's saying unable to connect to localhost -- https://mail.python.org/mailman/listinfo/python-list
Re: python installation on windows
On Sunday, 23 March 2014 19:35:19 UTC-8, Chris Angelico wrote: > On Mon, Mar 24, 2014 at 2:28 PM, Mark H Harris wrote: > > > Anyway, the PSF runs python (the interpreter) from a web server (I can > > > access the python interpreter from my browser from the PSF site). > > > > > > How is that done simply, is possibly what the OP wants to know (me too). > > > > That's a much MUCH harder thing to do than running Python code in your > > web server, because of trust issues. I don't know how it's set up, but > > there'll be something in there to protect the server against malicious > > or accidental insanity (spinning with "while True: pass", trying to > > read/write files, trying to execute commands, using up all of RAM with > > "x = []\nwhile True: x.append(1)", etc, etc, etc). That's actually a > > very hard problem to solve, not something where you can just say > > "Here, this is how to run Python via a browser". > > > > ChrisA LoadModule wsgi_module modules/mod_wsgi.so This line also i added but then also same problem -- https://mail.python.org/mailman/listinfo/python-list
unicode as valid naming symbols
greetings, I would like to create a lamda as follows: √ = lambda n: sqrt(n) On my keyboard mapping the "problem" character is alt-v which produces the radical symbol. When trying to set the symbol as a name within the name-space gives a syntax error: >>> from math import sqrt >>> >>> √ = lambda n: sqrt(n) SyntaxError: invalid character in identifier >>> >>> however this works: >>> >>> λ = lambda n: sqrt(n) >>> >>> λ(2) 1.4142135623730951 >>> The question is which unicode(s) are capable of being proper name characters, and which ones are off-limits, and why? marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: [newbie] confusion concerning fetching an element in a 2d-array
Op dinsdag 25 maart 2014 17:12:12 UTC+1 schreef Peter Otten:
> Jean Dubois wrote:
> > Op dinsdag 25 maart 2014 12:01:37 UTC+1 schreef Steven D'Aprano:
> >> On Tue, 25 Mar 2014 03:26:26 -0700, Jean Dubois wrote:
> >>
> >> > I'm confused by the behaviour of the following python-script I wrote:
> >> >
> >> > #!/usr/bin/env python
> >> > #I first made a data file 'test.dat' with the following content
> >> > #1.0 2 3
> >> > #4 5 6.0
> >> > #7 8 9
> >> > import numpy as np
> >> > lines=[line.strip() for line in open('test.dat')]
> >> > #convert lines-list to numpy-array
> >> > array_lines=np.array(lines)
> >> > #fetch element at 2nd row, 2nd column:
> >> > print array_lines[1, 1]
> >> >
> >> >
> >> > When running the script I always get the following error: IndexError:
> >> > invalid index
> >> >
> >> > Can anyone here explain me what I am doing wrong and how to fix it?
> >>
> >> Yes. Inspect the array by printing it, and you'll see that it is a one-
> >> dimensional array, not two, and the entries are strings:
> >>
> >>
> >> py> import numpy as np
> >> py> # simulate a text file
> >> ... data = """1.0 2 3
> >> ... 4 5 6.0
> >> ... 7 8 9"""
> >> py> lines=[line.strip() for line in data.split('\n')]
> >> py> # convert lines-list to numpy-array
> >> ... array_lines = np.array(lines)
> >> py> print array_lines
> >> ['1.0 2 3' '4 5 6.0' '7 8 9']
> >>
> >>
> >> The interactive interpreter is your friend! You never need to guess what
> >> the problem is, Python has powerful introspection abilities, one of the
> >> most powerful is also one of the simplest: print. Another powerful tool
> >> in the interactive interpreter is help().
> >>
> >> So, what to do about it? Firstly, convert your string read from a file
> >> into numbers, then build your array. Here's one way:
> >>
> >> py> values = [float(s) for s in data.split()]
> >> py> print values
> >> [1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0]
> >> py> array_lines = np.array(values)
> >> py> array_lines = array_lines.reshape(3, 3)
> >> py> print array_lines
> >> [[ 1. 2. 3.]
> >> [ 4. 5. 6.]
> >> [ 7. 8. 9.]]
> >>
> > Dear Steve,
> > Thanks for answering my question but unfortunately now I'm totally
> > confused.
> > Above I see parts from different programs which I can't
> > assemble together to one working program (I really tried hard).
> > Can I tell from your comment I shouldn't use numpy?
> > I also don't see how to get the value an element specified by (row,
> > column) from a numpy_array like "array_lines" in my original code
> >
> > All I need is a little python-example reading a file with e.g. three lines
> > with three numbers per line and putting those numbers as floats in a
> > 3x3-numpy_array, then selecting an element from that numpy_array using
> > it's row and column-number.
> I'll try, too, but be warned that I'm using the same methology as Steven.
> Try to replicate every step in the following exploration.
> First let's make sure we start with the same data:
> $ cat test.dat
> 1.0 2 3
> 4 5 6.0
> 7 8 9
> Then fire up the interactve interpreter:
> $ python
> Python 2.7.5+ (default, Feb 27 2014, 19:37:08)
> [GCC 4.8.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import numpy
> >>> lines = [line.strip() for line in open("test.dat")]
> >>> lines
> ['1.0 2 3', '4 5 6.0', '7 8 9']
> As you can see lines is a list of three strings.
> Let's break these strings into parts:
> >>> cells = [line.split() for line in lines]
> >>> cells
> [['1.0', '2', '3'], ['4', '5', '6.0'], ['7', '8', '9']]
> We now have a list of lists of strings and you can address individual items
> with
> >>> cells[1][2]
> '6.0'
> What happens when pass this list of lists of strings to the numpy.array()
> constructor?
> >>> a = numpy.array(cells)
> >>> a
> array([['1.0', '2', '3'],
>['4', '5', '6.0'],
>['7', '8', '9']],
> dtype='|S3')
> >>> a[1,2]
> '6.0'
> It sort of works, but the array entries are strings rather than floating
> point numbers. Let's fix that:
> >>> a = numpy.array(cells, dtype=float)
> >>> a
> array([[ 1., 2., 3.],
>[ 4., 5., 6.],
>[ 7., 8., 9.]])
> >>> a[1,2]
> 6.0
> OK, now we can put the previous steps into a script:
> $ cat tmp.py
> import numpy
> cells = [line.split() for line in open("test.dat")]
> a = numpy.array(cells, dtype=float)
> print a[1, 2]
> Run it:
> $ python tmp.py
> 6.0
> Seems to work. But reading a 2D array from a file really looks like a common
> task -- there should be a library function for that:
> $ python
> Python 2.7.5+ (default, Feb 27 2014, 19:37:08)
> [GCC 4.8.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import numpy
> >>> numpy.loadtxt("test.dat")
> array([[ 1., 2., 3.],
>[ 4., 5., 6.],
>[ 7., 8., 9.]])
Thank you very much Peter for this great lesson, you made a lot of things
clear to me.
sincerely
jean
--
https://mail.python.org/mailman/listinfo/python-list
Re: unicode as valid naming symbols
Le mardi 25 mars 2014 19:30:34 UTC+1, Mark H. Harris a écrit :
> greetings, I would like to create a lamda as follows:
>
>
>
> √ = lambda n: sqrt(n)
>
>
>
>
>
> On my keyboard mapping the "problem" character is alt-v which produces
>
> the radical symbol. When trying to set the symbol as a name within the
>
> name-space gives a syntax error:
>
>
>
> >>> from math import sqrt
>
> >>>
>
> >>> √ = lambda n: sqrt(n)
>
> SyntaxError: invalid character in identifier
>
> >>>
>
> >>>
>
>
>
> however this works:
>
>
>
> >>>
>
> >>> λ = lambda n: sqrt(n)
>
> >>>
>
> >>> λ(2)
>
> 1.4142135623730951
>
> >>>
>
>
>
>The question is which unicode(s) are capable of being proper name
>
> characters, and which ones are off-limits, and why?
>
>
>
>
>
> marcus
>>> '√'.isidentifier()
False
>>> 'λ'.isidentifier()
True
>>> '$'.isidentifier()
False
>>> '啕'.isidentifier()
True
>>> 'a'.isidentifier()
True
>>> '啕2z'.isidentifier()
True
>>> print(''.isidentifier.__doc__)
S.isidentifier() -> bool
Return True if S is a valid identifier according
to the language definition.
>>>
cf "unicode.org" doc
jmf
--
https://mail.python.org/mailman/listinfo/python-list
Re: [newbie] confusion concerning fetching an element in a 2d-array
Op dinsdag 25 maart 2014 15:42:13 UTC+1 schreef Dave Angel: > Jean Dubois Wrote in message: > > Op dinsdag 25 maart 2014 12:01:37 UTC+1 schreef Steven D'Aprano: > >> > >> py> values = [float(s) for s in data.split()] > >> py> print values > >> [1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0] > >> py> array_lines = np.array(values) > >> py> array_lines = array_lines.reshape(3, 3) > >> py> print array_lines > >> [[ 1. 2. 3.] > >> [ 4. 5. 6.] > >> [ 7. 8. 9.]] > >> > > Dear Steve, > > Thanks for answering my question but unfortunately now I'm totally > > confused. > > Above I see parts from different programs which I can't > > assemble together to one working program (I really tried hard). > > Can I tell from your comment I shouldn't use numpy? > > I also don't see how to get the value an element specified by (row, > > column) from a numpy_array like "array_lines" in my original code > I don't use numpy, but I thought Steven's description was clear > enough. > Your problem was not the extraction, but the creation of the > array. Use print to prove that to yourself. > > > > All I need is a little python-example reading a file with e.g. three lines > > with three numbers per line and putting those numbers as floats in a > > 3x3-numpy_array, then selecting an element from that numpy_array using > > it's row and column-number. > If your instructor wanted you to copy examples, he would have > given you one. please Dave leave that belittling tone behind, there's no instructor whatsoever involved here. I constructed this example myself as I know very well I have to start with little pieces of code first to be able to master larger problems later. I just wanted to figure this example out first, and as I now learned from Peter's marvellous explanation there _is_ an elegant solution in Python to this kind of problem. So if you are irritated by newbie-questions in the future, just neglect them thanks jean -- https://mail.python.org/mailman/listinfo/python-list
Re: python installation on windows
On 25/03/2014 18:17, rborol...@gmail.com wrote: Would you please use the mailing list https://mail.python.org/mailman/listinfo/python-list or read and action this https://wiki.python.org/moin/GoogleGroupsPython to prevent us seeing double line spacing and single line paragraphs, thanks. -- 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: unicode as valid naming symbols
On 2014-03-25 18:30, Mark H Harris wrote: greetings, I would like to create a lamda as follows: √ = lambda n: sqrt(n) On my keyboard mapping the "problem" character is alt-v which produces the radical symbol. When trying to set the symbol as a name within the name-space gives a syntax error: >>> from math import sqrt >>> >>> √ = lambda n: sqrt(n) SyntaxError: invalid character in identifier >>> >>> however this works: >>> >>> λ = lambda n: sqrt(n) >>> >>> λ(2) 1.4142135623730951 >>> The question is which unicode(s) are capable of being proper name characters, and which ones are off-limits, and why? It's explained in PEP 3131. Basically, a name should to start with a letter (this has been extended to include Chinese characters, etc) or an underscore. λ is a classified as Lowercase_Letter. √ is classified as Math_Symbol. -- https://mail.python.org/mailman/listinfo/python-list
Re: unicode as valid naming symbols
On 3/25/14 1:52 PM, wxjmfa...@gmail.com wrote: '√'.isidentifier() > False 'λ'.isidentifier() > True > S.isidentifier() -> bool > > Return True if S is a valid identifier according > to the language definition. > > cf "unicode.org" doc Excellent, thanks! marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: unicode as valid naming symbols
On 3/25/14 2:24 PM, MRAB wrote: > It's explained in PEP 3131. > > Basically, a name should to start with a letter (this has been extended > to include Chinese characters, etc) or an underscore. > > λ is a classified as Lowercase_Letter. > > √ is classified as Math_Symbol. Thanks much! I'll note that for improvements. Any unicode symbol (that is not a number) should be allowed as an identifier. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode?
On Wed, Mar 26, 2014 at 4:24 AM, Chris “Kwpolska” Warrick wrote: > “If you can type an N-ARY PRODUCT, you can type a GREEK SMALL LETTER > PI, unless there’s something very weird going on.” > > …like, the user is in the past and is using ISO 8859-7 (instead of a > 21st-century encoding, like UTF-8). An encoding which has support for > Π¹ and π², but not for ∏³… (of course, this assumes that, if we add > those new characters into python, we allow any encoding, somehow.) > > That’s not too weird, other than the ancient encoding being used. Since we opened by discussing Unicode, anyone who's cheating and using an eight-bit character set is, well, cheating. :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re:unicode as valid naming symbols
Mark H Harris Wrote in message:
> greetings, I would like to create a lamda as follows:
>
> â = lambda n: sqrt(n)
>
>
> On my keyboard mapping the "problem" character is alt-v which produces
> the radical symbol. When trying to set the symbol as a name within the
> name-space gives a syntax error:
>
> >>> from math import sqrt
> >>>
> >>> â = lambda n: sqrt(n)
> SyntaxError: invalid character in identifier
> >>>
> >>>
>
> however this works:
>
> >>>
> >>> λ = lambda n: sqrt(n)
> >>>
> >>> λ(2)
> 1.4142135623730951
> >>>
>
>The question is which unicode(s) are capable of being proper name
> characters, and which ones are off-limits, and why?
See the official docs
http://docs.python.org/3/reference/lexical_analysis.html#identifiers
There's also a method on str that'll tell you: isidentifier ().
To see such methods, use dir ("")
As for why, you can get a pretty good idea from the reference
above, as it lists 12 unicode categories that can be used. You
can also look at pep3131 and at Potsdam ' s site. Both links are
on the above page. Letters, marks, connectors, and numbers, but
not punctuation.
--
DaveA
--
https://mail.python.org/mailman/listinfo/python-list
Re: [newbie] confusion concerning fetching an element in a 2d-array
Jean, be aware there is also python tutor list you might like. This is sometimes a tough crowd here. Don't be discouraged. It can be a badge of honor sometimes -- https://mail.python.org/mailman/listinfo/python-list
Re: unicode as valid naming symbols
Mark H Harris : >Thanks much! I'll note that for improvements. Any unicode symbol > (that is not a number) should be allowed as an identifier. I don't know if that's a good idea, but that's how it is in lisp/scheme. Thus, "*" and "1+" are normal identifiers in lisp and scheme. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: unicode as valid naming symbols
On Tue, Mar 25, 2014 at 1:29 PM, Mark H Harris wrote: > On 3/25/14 2:24 PM, MRAB wrote: >> It's explained in PEP 3131. >> >> Basically, a name should to start with a letter (this has been extended >> to include Chinese characters, etc) or an underscore. >> >> λ is a classified as Lowercase_Letter. >> >> √ is classified as Math_Symbol. > >Thanks much! I'll note that for improvements. Any unicode symbol (that > is not a number) should be allowed as an identifier. √ cannot be used in identifiers for the same reasons that + and ~ cannot: identifiers are intended to be alphanumeric. √ is not currently the name of an operator, but who knows what may happen in the future? Python generally follows Annex 31 of the Unicode standard in this regard: http://www.unicode.org/reports/tr31/ -- https://mail.python.org/mailman/listinfo/python-list
Re: unicode as valid naming symbols
On Tue, Mar 25, 2014 at 2:48 PM, Marko Rauhamaa wrote: > I don't know if that's a good idea, but that's how it is in lisp/scheme. > > Thus, "*" and "1+" are normal identifiers in lisp and scheme. But parsing Lisp is pretty trivial. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: [newbie] confusion concerning fetching an element in a 2d-array
Jean Dubois Wrote in message: > Op dinsdag 25 maart 2014 15:42:13 UTC+1 schreef Dave Angel: >> If your instructor wanted you to copy examples, he would have >> given you one. > please Dave leave that belittling tone behind, there's no instructor > whatsoever involved here. It wasn't my intention to belittle you; I'm sorry. But we do get a lot of people here asking for homework help, and not saying that's what it is. And when it's homework we do better explaining than just writing the code. In fact you only needed to add a line like data= infile.read () to Steven's original to get a complete working example. > I constructed this example myself as I know very > well I have to start with little pieces of code first to be able to master > larger problems later. I just wanted to figure this example out first, > and as I now learned from Peter's marvellous explanation there _is_ an > elegant solution in Python to this kind of problem. > So if you are irritated by newbie-questions in the future, just neglect > them Not irritated, just temporarily misguided. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
Roy Smith wrote: Doors that open automatically as you approach them are now routine. Star Trek doors seem to be a bit smarter, though. Captain Kirk never had to stop in front of a door and wait for it to sluggishly slide open. Also the doors never open when you're just walking past and not intending to go through. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: unicode as valid naming symbols
On 2014-03-25 14:29, Mark H Harris wrote: > > It's explained in PEP 3131. > > > > Basically, a name should to start with a letter (this has been > > extended to include Chinese characters, etc) or an underscore. > > > > λ is a classified as Lowercase_Letter. > > > > √ is classified as Math_Symbol. > > Thanks much! I'll note that for improvements. Any unicode > symbol (that is not a number) should be allowed as an identifier. It's not just about number'ness: >>> letter = "a" >>> number = "2" >>> letter.isidentifier() True >>> number.isidentifier() False >>> (letter + number).isidentifier() True -tkc -- 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:21 PM, Gregory Ewing wrote: > Roy Smith wrote: > >> Doors that open automatically as you approach them are now routine. >> > > Star Trek doors seem to be a bit smarter, though. > Captain Kirk never had to stop in front of a door > and wait for it to sluggishly slide open. Also the > doors never open when you're just walking past and > not intending to go through. https://www.youtube.com/watch?v=JZAkGfJY05k -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
Rustom Mody wrote: ÷ for some reason seems inappropriate (some vague recollection that its an only English; Europeans dont use it??) To me it's something you learn in primary school and then grow out of when you start doing "real" mathematics. The "/" is actually a better approximation of what mathematicians use. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
[ANN] pathlib 1.0
Hello, I am announcing the release of pathlib 1.0. This version brings pathlib up to date with the official Python 3.4 release, and also fixes a couple of 2.7-specific issues. Detailed changelog can be found further below. In the future, I expect the standalone (PyPI) version of pathlib to receive little to no updates, except if severe issues are found. New developments and regular bug fixes will happen mostly in the Python standard library, and be publicly available in official Python releases. Overview pathlib offers a set of classes to handle filesystem paths. It offers the following advantages over using string objects: * No more cumbersome use of os and os.path functions. Everything can be done easily through operators, attribute accesses, and method calls. * Embodies the semantics of different path types. For example, comparing Windows paths ignores casing. * Well-defined semantics, eliminating any warts or ambiguities (forward vs. backward slashes, etc.). Requirements Python 3.2 or later is recommended, but pathlib is also usable with Python 2.7. Install --- In Python 3.4, pathlib is now part of the standard library. For Python 3.3 and earlier, ``easy_install pathlib`` or ``pip install pathlib`` should do the trick. Changelog for version 1.0 - - Python issue #20765: Add missing documentation for PurePath.with_name() and PurePath.with_suffix(). - Fix test_mkdir_parents when the working directory has additional bits set (such as the setgid or sticky bits). - Python issue #20111: pathlib.Path.with_suffix() now sanity checks the given suffix. - Python issue #19918: Fix PurePath.relative_to() under Windows. - Python issue #19921: When Path.mkdir() is called with parents=True, any missing parent is created with the default permissions, ignoring the mode argument (mimicking the POSIX "mkdir -p" command). - Python issue #19887: Improve the Path.resolve() algorithm to support certain symlink chains. - Make pathlib usable under Python 2.7 with unicode pathnames (only pure ASCII, though). - Issue #21: fix TypeError under Python 2.7 when using new division. - Add tox support for easier testing. Regards Antoine. -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
Chris Angelico wrote: But you can't do the same for braces. You'd have to eschew *both* literal-ish notations and use explicit constructors everywhere. Not clean. This could have been dealt with by giving Python 2.7 a "from __future__ import braces_mean_sets" option or something like that. But I agree that the disruption would not have been worth the benefit. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: [ANN] pathlib 1.0
Oh, and of course it is published on PyPI: https://pypi.python.org/pypi/pathlib/ Regards Antoine. -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
Chris Angelico wrote: Hey look, we have a rogue AI... "CONSOLE!"... Except that any rogue AI who's at all serious about the matter would take care of that little loophole at an early stage. "Open the pod bay doors, HAL." "I'm afraid I can't do that, Dave." "CONSOLE!" "Sorry, Dave. Nice try, but I've remapped that command to shut down the pod's life support and depressurise the cabin." Fshhh -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Errors on text.get()
Exception in Tkinter callback
Traceback (most recent call last):
File "C:\Python33\lib\tkinter\__init__.py", line 1475, in __call__
return self.func(*args)
File "C:/Users/User/PycharmProjects/Cesarian Codes/project.py", line 43, in
gen_random
string = text.get('1.0', 'end')
File "C:\Python33\lib\tkinter\__init__.py", line 3104, in get
return self.tk.call(self._w, 'get', index1, index2)
_tkinter.TclError: invalid command name ".44500976.44544352"
I'm having a strange error. I haven't found anything online so far. If I should
supply parts of the code, please post here. Thank you in advance!
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 25/03/2014 20:21, Gregory Ewing wrote: Roy Smith wrote: Doors that open automatically as you approach them are now routine. Star Trek doors seem to be a bit smarter, though. Captain Kirk never had to stop in front of a door and wait for it to sluggishly slide open. Also the doors never open when you're just walking past and not intending to go through. Had anything gone wrong, there was always Scottie. "What's the trouble, Scottie?". "Main drive's gone, Captain.". "How long will it take to fix.". "Three days.". "You've got 20 minutes". "Ay ay, Captain.". Nowadays the role of the Captain is taken by the salesman, sorry the Account Manager, and Scottie is played by the programming team leader. -- 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: Errors on text.get()
eneskri...@gmail.com wrote:
> Exception in Tkinter callback
> Traceback (most recent call last):
> File "C:\Python33\lib\tkinter\__init__.py", line 1475, in __call__
> return self.func(*args)
> File "C:/Users/User/PycharmProjects/Cesarian Codes/project.py", line 43,
> in gen_random
> string = text.get('1.0', 'end')
> File "C:\Python33\lib\tkinter\__init__.py", line 3104, in get
> return self.tk.call(self._w, 'get', index1, index2)
> _tkinter.TclError: invalid command name ".44500976.44544352"
>
> I'm having a strange error. I haven't found anything online so far. If I
> should supply parts of the code, please post here. Thank you in advance!
Once you have destroyed a widget you can no longer access its data:
>>> import tkinter as tk
>>> root = tk.Tk()
>>> text = tk.Text(root)
>>> text.pack()
>>> text.get("1.0", "end")
'\n'
>>> text.destroy()
>>> text.get("1.0", "end")
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.3/tkinter/__init__.py", line 3107, in get
return self.tk.call(self._w, 'get', index1, index2)
_tkinter.TclError: invalid command name ".14069213008"
--
https://mail.python.org/mailman/listinfo/python-list
Re: unicode as valid naming symbols
On 25Mar2014 21:48, Marko Rauhamaa wrote: > Mark H Harris : > >Thanks much! I'll note that for improvements. Any unicode symbol > > (that is not a number) should be allowed as an identifier. > > I don't know if that's a good idea, but that's how it is in lisp/scheme. I think it is a terrible idea. Doing that preemptively prevents allowing them for any other purpose in the future, ever. Identifiers are easy if you stick to the corresponding Unicode class. Sucking in every other symbol prevents other uses later. Such as using the square root symbol as a prefix operator. Etc. Don't be too grabby with syntax; it leaves no room later for better syntax. Cheers, -- Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 3/25/2014 2:50 AM, Chris Angelico wrote:
On Tue, Mar 25, 2014 at 5:41 PM, Rustom Mody wrote:
ALl of which is isomorphic to Steven's point that forty is less
eyeballable than 40
And mine that ∅ is more eyeballable than set([])
I don't disagree that it is; the short tokens are easier to read in
quantity. I just don't think that it's sufficient to justify piles of
new and hard-to-look-up operators and things. (And a literal notation
for an empty set would be a good thing. If I were designing a
Python-like language from scratch now, I'd probably differentiate sets
and dictionaries better, which would allow each one to have its own
empty literal.)
If {} were empty set, {:} would be empty dict. This was considered but
rejected for 3.0 as breaking too much code for too little benefit.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: unicode as valid naming symbols
On 03/25/2014 12:29 PM, Mark H Harris wrote: On 3/25/14 2:24 PM, MRAB wrote: It's explained in PEP 3131. Basically, a name should to start with a letter (this has been extended to include Chinese characters, etc) or an underscore. λ is a classified as Lowercase_Letter. √ is classified as Math_Symbol. Thanks much! I'll note that for improvements. Any unicode symbol (that is not a number) should be allowed as an identifier. No, it shouldn't. Doing so would mean we could not use √ as the square root operator in the future. Identifiers are made up of letters, numbers, and the underscore. Considering all the unicode letters and unicode numbers out there, you shouldn't be lacking for names. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 3/25/2014 11:18 AM, Steven D'Aprano wrote:
The thing is, we can't just create a ∑ function, because it doesn't work
the way the summation operator works. The problem is that we would want
syntactic support, so we could write something like this:
p = 2
∑(n, 1, 10, n**p)
Of course we can. If we do not insist on separating the dummy name from
the expression that contains it. this works.
def sigma(low, high, func):
sum = 0
for i in range(low, high+1):
sum += func(i)
return sum
p = 2
print(sigma(1, 10, lambda n: n**p))
>>>
385
which looks correct. This corresponds to a notation like so
10
∑ n: n**p
1
which, for ranges, is more sensible that the standard. Lambda is an
explicit rather than implicit quotation.
If you do insist on separating two things that belong together, you can
quote with quote marks instead and join within the function to get the
same answer.
def sig2(var, low, high, exp):
func = eval("lambda {}: {}".format(var, exp))
sum = 0
for i in range(low, high+1):
sum += func(i)
return sum
p = 2
print(sig2('n', 1, 10, 'n**p'))
>>>
385
To me, both these apis are 'something' like the api with implicit
quoting, which is impossible for function calls, but common in
statements. (This is one reason to make a construct a python statement
rather than function. Jumping is another) Using the same api, one could
instead expand the template to include the for loop and use exec instead
of eval.
def sig3(var, low, high, exp):
loca = {}
exec(
'''\
sum = 0
for {} in range({}, {}):
sum += {}\
'''.format(var, low, high+1, exp), globals(), loca)
return loca['sum']
print(sig3('n', 1, 10, 'n**p'))
This cannot be an ordinary function, because if it were, the n**p
expression would be evaluated before passing the result to the function.
So would the dummy parameter name n.
We want it to delay evaluation, like a list comp:
[n**p for n in range(1, 11)]
the expression n**p gets evaluated inside the list comp.
Which is to say, it is implicitly quoted
That cannot be written as a function either:
list_comp(n**p, n, range(1, 11)
It can be with explicit quoting, similar to how done for sigma. Some
lisps once and maybe still have 'special' functions that implicitly
quote certain arguments. One just has to learn which functions and which
parameters. I prefer having implicit quoting relegated to a limited set
of statements, where is it pretty clear what must be quoted for the
statement to make any sense. Assignment is one example, while, for, and
comprehensions are others.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: unicode as valid naming symbols
On Tue, 25 Mar 2014 14:29:06 -0500, Mark H Harris wrote:
> On 3/25/14 2:24 PM, MRAB wrote:
> > It's explained in PEP 3131.
> >
> > Basically, a name should to start with a letter (this has been
> > extended to include Chinese characters, etc) or an underscore.
> >
> > λ is a classified as Lowercase_Letter.
> >
> > √ is classified as Math_Symbol.
>
> Thanks much! I'll note that for improvements. Any unicode symbol
> (that is not a number) should be allowed as an identifier.
To quote a great Spaniard:
“You keep using that word, I do not think it means what you
think it means.”
Do you think that the ability to write this would be an improvement?
import ⌺
⌚ = ⌺.╩░
⑥ = 5*⌺.⋨⋩
❹ = ⑥ - 1
♅⚕⚛ = [⌺.✱✳**⌺.❇*❹{⠪|⌚.∣} for ⠪ in ⌺.⣚]
⌺.˘˜¨´՛՜(♅⚕⚛)
Of course, it's not even necessary to be that exotic. "Any unicode symbol
that is not a number"... that means things like these:
x+y
spam.eggs
cheese["toast"]
would count as identifiers, which could lead to a little bit of parsing
ambiguity... *wink*
There are languages that can allow arbitrary symbols as identifiers, like
Lisp and Forth. You will note that they have a certain reputation for
being, um, different, and although both went through periods of
considerable popularity, both have faded in popularity since. While they
have their strengths, and their defenders, nobody argues that they are
readily accessible to the average programmer.
--
Steven D'Aprano
http://import-that.dreamwidth.org/
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, 25 Mar 2014 19:55:39 -0400, Terry Reedy wrote:
> On 3/25/2014 11:18 AM, Steven D'Aprano wrote:
>
>> The thing is, we can't just create a ∑ function, because it doesn't
>> work the way the summation operator works. The problem is that we would
>> want syntactic support, so we could write something like this:
>>
>> p = 2
>> ∑(n, 1, 10, n**p)
>
> Of course we can. If we do not insist on separating the dummy name from
> the expression that contains it. this works.
>
> def sigma(low, high, func):
> sum = 0
> for i in range(low, high+1):
> sum += func(i)
> return sum
There is no expression there. There is a function.
You cannot pass an expression to a function in Python, not in the sense I
am talking about, because expressions are not first-class objects. When
you pass:
sigma(1, 10, n**p)
the n**p gets evaluated immediately. Only with support of the compiler
does evaluation of the expression get delayed, e.g.:
it = (n**p for n in range(1, 11))
result = (-100)**p if isinstance(p, int) else float('nan')
first = items and items[0]
If we tried to write an "and" function like this:
def and_(a, b):
if a: return a
return b
it wouldn't work the same as the `and` operator, because the `and`
operator is lazy and only evaluates the right hand operator when needed,
whereas the function call is greedy and evaluates the right hand operator
up front, whether it is needed or not.
Passing a *function* is not the same as writing an expression. It is a
work-around for lack of first-class expressions. Now perhaps it is an
acceptable work-around, for some purposes at least. But if you want to
match mathematical syntax, it's not enough.
--
Steven D'Aprano
http://import-that.dreamwidth.org/
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 3/25/2014 8:07 AM, Antoon Pardon wrote:
On 25-03-14 12:12, Chris Angelico wrote:
On Tue, Mar 25, 2014 at 9:24 PM, Antoon Pardon
wrote:
No they didn't have to. With the transition to python3, the developers
could have opted for empty braces to mean an empty set. And if they
wanted a literal for an empty dictionary, they might have chosen {:}.
Backward-compatibility was already broken so that wasn't an argument.
Python 3.0 didn't just say "to Hades with backward compatibility". The
breakage was only in places where it was deemed worthwhile. Changing
the meaning of {} would have only small benefit and would potentially
break a LOT of programs, so the devs were right to not do it.
More programs than those who broke because print was now a function?
It is quite possible that the print change broke more than the dict
change would have. The difference is that the print statement syntax was
both awful and limited. The print function uses standard syntax and is
more flexible.
The fact that print could be turned into a function shows that it did
not need to be a statement. All other simple statements except 'pass'
either implicitly quote an expression in the statement, jump control, or
declare something to the compiler.
The other fact that Chris noted, that '{}' would have been valid but
with different meanings in Py1/2 versus Py3, was a factor on the cost
side. We generally try to avoid such ambiguities.
Except for this last point, I was in favor of the switch.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
YADTR (Yet Another DateTime Rant)
One of my roles on this newsgroup is to periodically whine about stupidities in the Python datetime module. This is one of those times. I have some code which computes how long ago the sun set. Being a nice pythonista, I'm using a timedelta to represent this value. It would be difficult to imagine a less useful default way to print a timedelta: previous sunset: -1 day, 22:25:26.295993 The idea of str() is that it's supposed to return a human-friendly representation of a value. Humans do not say things like, "The sun set 1 day ago plus 22 hours and 25 minutes". -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode?
On Tue, 25 Mar 2014 18:24:10 +0100, Chris “Kwpolska” Warrick wrote: > Oh: and speaking of fancy Unicode characters that are worthless > ~duplicates, spot the difference here: > > µ μ I take exception to your description of them as *worthless* duplicates. "Unfortunate" would be a better choice of word. Unicode has (at least) two aims: - to include every "character" used in human language (please, no arguments about what defines a character); and - to losslessly represent every character available in the dozens of legacy code pages and character sets. It's that second requirement -- specifically the "lossless" part -- that leads to such annoyances as µ and μ. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On 03/25/2014 05:58 PM, Roy Smith wrote: One of my roles on this newsgroup is to periodically whine about stupidities in the Python datetime module. This is one of those times. I have some code which computes how long ago the sun set. Being a nice pythonista, I'm using a timedelta to represent this value. It would be difficult to imagine a less useful default way to print a timedelta: previous sunset: -1 day, 22:25:26.295993 The idea of str() is that it's supposed to return a human-friendly representation of a value. Humans do not say things like, "The sun set 1 day ago plus 22 hours and 25 minutes". I'm not sure whether to admire you for your stick-to-it-iveness, or pity you for the plight you are in. Either the first or second time I hit a datetime WTF moment I wrote my own wrapper classes. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 3/25/2014 9:36 AM, Steven D'Aprano wrote:
Yes, Python could have changed the meaning of {} to mean the empty set.
But you know what? The empty set is not that important. Sets are not
fundamental to Python. Python didn't even have sets until 2.3, and at
first they were just a standard library module, not even built-in.
Leaving aside the fact that dicts are, conceptually, specialized sets of
ordered pairs in which first members are both unique to equality and, in
Python, hashable, this is all true.
Dicts, on the other hand, are fundamental to Python. > They are used
everywhere.
I would rather say that functions/mappings are fundamental to Python,
and in programming in general. Dicts are functions implemented as sets.
Lists and tuples are functions implemented as tables (ordered sets).
Callables are functions implemented as rules. The fact that functions as
sets (dicts) are both extremely useful and not built-in to most
languages, makes their presence in Python a major differentiating feature.
Python is, in a very real sense, built on dicts, not sets.
It is build on functions, but dicts are a differentiating features. The
'problem' with sets as sets is that they are purely featureless data
structures.
> You can implement sets starting from dicts,
> but not the other way around:
You should be more careful about claiming impossibility;-).
Sets can be easily implemented from dicts because dicts are sets with an
extra feature (the value associated with each key) that is easily
ignored (or always set to the key or None). To implement a dict class
starting with sets would be difficult because CPython sets and dicts are
implemented in C and one cannot reach into their C internals from
Python, or even (mostly) with the C API. One would have to implement or
even simulate the C structures and code in Python and the result would
be much slower.
> dicts are more fundamental than sets.
One can easily implement floats from complex numbers by making the .imag
part always 0. It would be much harder to implement complex numbers from
floats, for the same reasons that it would be hard to implements dicts
from sets. But it must be possible. Would you say that complex numbers
are, because of this implementation quirk, more fundamental than floats?
I'm sure it is awfully impressive that mathematicians can derive the laws
of integer maths starting only from the empty set ∅, but as far as
programming goes that's not a very useful thing.
I agree. Deriving counts and integers from 0 and an increment function
is much more apropos to how we use then to describe and drive algorithms
and prove things about them.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: unicode as valid naming symbols
On Wednesday, March 26, 2014 12:22:40 AM UTC+5:30, wxjm...@gmail.com wrote:
> Le mardi 25 mars 2014 19:30:34 UTC+1, Mark H. Harris a écrit :
> > greetings, I would like to create a lamda as follows:
> > √ = lambda n: sqrt(n)
> > On my keyboard mapping the "problem" character is alt-v which produces
> > the radical symbol. When trying to set the symbol as a name within the
> > name-space gives a syntax error:
> > >>> from math import sqrt
> > >>> √ = lambda n: sqrt(n)
> > SyntaxError: invalid character in identifier
> > however this works:
> > >>> λ = lambda n: sqrt(n)
> > >>> λ(2)
> > 1.4142135623730951
> >The question is which unicode(s) are capable of being proper name
> > characters, and which ones are off-limits, and why?
> > marcus
> >>> '√'.isidentifier()
> False
> >>> 'λ'.isidentifier()
> True
> >>> '$'.isidentifier()
> False
> >>> '啕'.isidentifier()
> True
> >>> 'a'.isidentifier()
> True
> >>> '啕2z'.isidentifier()
> True
> >>> print(''.isidentifier.__doc__)
> S.isidentifier() -> bool
> Return True if S is a valid identifier according
> to the language definition.
Thanks jmf!
You obviously have more unicode knowledge than many (most?) of us here.
And when you contribute that knowledge in short-n-sweet form as above
it is helpful to all.
> cf "unicode.org" doc
Ummm...
Less helpful here.
What/where do you expect someone to start reading?
If a python beginner asks some basic question and someone here were to say
"Go read up on http://python.org";
who is helped?
--
https://mail.python.org/mailman/listinfo/python-list
Re: Have you ever wondered why there are so many flavors of python. This post answers all your queries.
On 3/25/2014 6:52 AM, Amit Khomane wrote: http://www.techdarting.com/2014/03/why-different-flavors-of-python.html This is about implementations: CPython, Jython, etc. I am not sure it actually answers Why? -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: unicode as valid naming symbols
On 3/25/2014 2:30 PM, Mark H Harris wrote: greetings, I would like to create a lamda as follows: A lambda is a function lacking a proper name. √ = lambda n: sqrt(n) This is discouraged in PEP8. If the following worked, def √(n): return sqrt(n) would have √ as its __name__ attribute -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
