global name 'self' is not defined
Hi
I have a short script that makes 2 calls to methods in another script
as follows:
import canPlaces as canp
callOne=canp.addMe(3,5)
callTwo=canp.estocStn()
The 2 methods in the second script are:
def addMe(a,b)
sumAb=a+b
return sumAb
def estocStn():
estoc={'lat':29.15,'lon':-15.667,'place':'ESTOC'}
return estoc
Why is it that the first call works fine, but the second tells me
'global name 'self' is not defined'? What I want is to have the
dictionary 'estoc' available in my calling script.
Thanks, Evan
--
http://mail.python.org/mailman/listinfo/python-list
Re: global name 'self' is not defined
In answer to the 2 replies, I had no references anywhere to 'self'. In order to post my code I rewrote 2 scripts containing just the relevant parts of the problem; these work. However, they are identical to my original code. So I have deleted the 'old' script2 and renamed the new one, and no problem. I don't know why it worked with one and not the other when they are identical, but I have what I want now. Thanks for your replies. -Evan -- http://mail.python.org/mailman/listinfo/python-list
Re: global name 'self' is not defined
The problem seems to be with ipython, which I have been using to run
these scripts. My calling script (call.py) is:
import canaryPlaces_test as canp
sum=canp.addme(3,5)
print sum
estoc=canp.estocStn()
print estoc
The problem script is this one, named canaryPlaces_test.py:
def estocStn():
estoc={'lat':29.15,'lon':-15.667,'place':'ESTOC'}
return estoc
def addme(a,b):
sumAb=a+b
return sumAb
The ok script, named canaryPlaces.py, is identical apart from a comment
at the top of one of them. Here is output from 'diff' for the two of
them:
@suse212:~/python/mapping> diff canaryPlaces_test.py canaryPlaces.py
1c1
<
---
> # canaryPlaces
[EMAIL PROTECTED]:~/python/mapping>
>From the command line I get what I expect calling either
canaryPlaces_test.py or canaryPlaces.py:
@suse212:~/python/mapping> python call.py
8
{'lat': 29.149, 'place': 'ESTOC', 'lon': -15.667}
[EMAIL PROTECTED]:~/python/mapping>
However -> Using ipython and calling canaryPlaces.py is fine, but
calling canaryPlaces_test.py gives:
In [97]: %run call
8
---
exceptions.NameError Traceback (most
recent call last)
/home/evan/python/mapping/call.py
2
3 sum=canp.addme(3,5)
4 print sum
> 5 estoc=canp.estocStn()
6 print estoc
/home/evan/python/mapping/canaryPlaces_test.py in estocStn()
5return estoc
6
7 def addme(a,b):
8sumAb=a+b
9return sumAb
NameError: global name 'self' is not defined
WARNING: Failure executing file:
In [98]:
On my system this error is repeatable.
-Evan
Bjoern Schliessmann wrote:
> Evan wrote:
>
> > So I have deleted the 'old' script2 and renamed the new one, and
> > no problem.
>
> Pity. Next time try using diff (or something similar).
>
> Regards,
>
>
> Björn
>
> --
> BOFH excuse #115:
>
> your keyboard's space bar is generating spurious keycodes.
--
http://mail.python.org/mailman/listinfo/python-list
Re: global name 'self' is not defined
Hi Dennis, to answer your questions: 1) So far as I can see ipython generates .pyc files. 2) This morning I ran the scripts, and got the same problem using ipython as in my earlier post. I then deleted the .pyc file, ran the calling script and this time it works. I then replaced the .pyc file I had deleted, expecting to have the problem again, but no. 3) I've tried your suggestion, and it works fine. A few questions: Why does python use the double underscore (__main__ or if __name__)? I've only been using python for about 3 weeks, and I see this syntax a lot, but haven't found an explanation for it so far? Also, as I understand , the .pyc files should be updated every time you change and run the equivalent .py file? Thanks, Evan -- http://mail.python.org/mailman/listinfo/python-list
remove matching pairs
Is there a simple way to to identify and remove matching pairs from 2 lists? For example: I have a=[2, 5, 3, 4, 7, 2, 2, 4, 8, 1] b=[7, 3, 5, 8, 1, 7, 4, 8, 2, 6] and I want to get this: a=[2, 5, 3, 4, 7, 2, 8, 1] b=[7, 3, 5, 8, 1, 4, 2, 6] There are recurring pairs of (2, 7) and (4, 8), and so I want to remove one of each pair. Many thanks, Evan -- http://mail.python.org/mailman/listinfo/python-list
Re: remove matching pairs
That's great, thank you, the caveats are no matter! -Evan -- http://mail.python.org/mailman/listinfo/python-list
first and last index as in matlab
In matlab I can do the following: >> ind = [3,5,7,2,4,7,8,24] ind = 3 5 7 2 4 7 824 >> ind(1) ans = 3 >> ind(end) ans =24 >> ind([1 end]) ans = 324 but I can't get the last line in python: In [690]: ind = [3,5,7,2,4,7,8,24] In [691]: ind[0]Out[691]: 3 In [692]: ind[-1:] Out[692]: [24] In [693]: ?? How do I pull out multiple indices as in matlab? Thanks, Evan -- http://mail.python.org/mailman/listinfo/python-list
Re: first and last index as in matlab
Thanks for all the replies, it's much clearer now. -Evan -- http://mail.python.org/mailman/listinfo/python-list
What is the difference about "pycap" and "pylibpcap"?
Hi, I'm a new hire with python program, I want to write script for changing/moniter/filter the network packet, it seems there are two extensions in python, pycap and pylibcap. I was confused, what is the difference about pycap and pylibpcap? Differnet user interface only? Thanks, -- http://mail.python.org/mailman/listinfo/python-list
Where can I get a complete user interface about pylibpcap?
A web-link would do, becuase of I don't know how many parameters I need to use in function about pylibpcap. Or what kind of parameters I need to use/transfer? I'm very gratefully if you can help on this question. Thanks, -- http://mail.python.org/mailman/listinfo/python-list
How can I work on VIM for python code such as cscope for C code?
Hi, guys ~~ How can i work on VIM for python code? I use cscope plugin on VIM for C code before, it helps me to different function and search C variable where it is defined. I'm now starting to learn python, and I'd like to know how works on VIM. I saw that the VIM is support python such as syntax highlighting, autocmd,etc. but I really want to know if it can work with TAG. Do I need to downlaod other software/plugin? Thanks, -- http://mail.python.org/mailman/listinfo/python-list
problem with quote and single-quote when using "subprocess"
Hello - i'm trying to call subprocess.popen on the 'command-based' function in linux. When I run the command from the shell, like so: goset -f ' "%s %s" name addr ' file_name it works fine however when I try to do it in python like so: p = subprocess.Popen(["goest",'-f \'\"%s %s\" name addr\' ', 'file_name'], shell=True) It always failed. I also try like so: p = subprocess.Popen(["goest","-f '\"%s %s\" name addr' ", 'file_name'], shell=True) It also failed. Does anybody have a good suggestion for this matter? thanks in advance. Evan -- http://mail.python.org/mailman/listinfo/python-list
problem with single-quote and double-quote when using subprocess.
Hello - i'm trying to call subprocess.popen on the 'command-based' function in linux. When I run the command from the shell, like so: goset -f ' "%s %s" name addr ' file_name it works fine however when I try to do it in python like so: p = subprocess.Popen(["goest",'-f \'\"%s %s\" name addr\' ', 'file_name'], shell=True) It always failed. I also try like so: p = subprocess.Popen(["goest","-f '\"%s %s\" name addr' ", 'file_name'], shell=True) It also failed. Does anybody have a good suggestion for this matter? thanks in advance. Evan -- http://mail.python.org/mailman/listinfo/python-list
how to convert from network to host byte order
Hello ~
I'm new with python, what my problem is, I have a binary file, I want
to read first 2 bytes and convert it to host byte order, then write it
to another file.
I try to use 'socket' and 'struct', but somehow i can not get it
working fine:
for example, totally I'm not sure if my steps is correct or not:
>>> import socket
>>> f=open('a.bin','rb')
>>> f.read(2)
'\x04\x00'
>>> f.seek(0)
>>> st=f.read(2)
>>> e=open('test.bin','w+b')
>>> e.write(socket.ntohs(struct.unpack('H',st[:2])[0]))
Traceback (most recent call last):
File "", line 1, in
TypeError: argument 1 must be string or read-only buffer, not int
+
It failed due to the parameter is 'int', not 'str' in write function.
but how can i do that?
Thanks,
Evan
--
http://mail.python.org/mailman/listinfo/python-list
Re: how to convert from network to host byte order
On Mar 5, 9:50 pm, Philipp Hagemeister wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Evan wrote:
> >>> inp='\x04\x00'
> >>> out = socket.ntohs(struct.unpack('H',inp[:2])[0]))
> > Traceback (most recent call last):
> > File "", line 1, in
> > TypeError: argument 1 must be string or read-only buffer, not int
>
> Your approach is nearly right. First of all, you have to tell
> struct.unpack it should unpack from network order ("!"):
>
> >>> struct.unpack('!H', inp)[0]
>
> 1024
>
> Then you want to repack it in host byte order. Use "=" for that.
>
> >>> out = struct.pack('=H', struct.unpack('!H', inp)[0])
> >>> out
>
> '\x00\x04'
>
> For more information, look for "Size and alignment"
> inhttp://docs.python.org/library/struct.html.
>
> Regards,
>
> Philipp Hagemeister
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEAREKAAYFAkmv2JkACgkQ9eq1gvr7CFymKACghFXMZb9D6pkWZQdapvwTsKJ5
> b0UAn0Uvbcguv/rdxjFKXhMQz22+Notn
> =ZiKx
> -END PGP SIGNATURE-
That's good, thanks Philipp
--
http://mail.python.org/mailman/listinfo/python-list
how to handle/generate pcap file
Hello - I'm trying to decode the pcap file which is packet capture by tcpdump or wireshark. Is there a python module that I can use it for this problem? Can python-libpcap or pycap or dpkt do that? On the other hand, I also generate some packets by dpkt module, can I also dump these packets to a pcap file? such as *.pcap. The problem is I do not want to send these packets, I just want to generate some special packets and then store it in a pcap file (libpcap format), so other guys can check it by tcpdump or wireshark. Thanks, Evan -- http://mail.python.org/mailman/listinfo/python-list
Re: how to handle/generate pcap file
On Apr 2, 6:59 am, "Rhodri James" wrote: > On Wed, 01 Apr 2009 14:53:34 +0100, Evan wrote: > > > Hello - > > > I'm trying to decode thepcapfilewhich is packet capture by tcpdump > > or wireshark. Is there a python module that I can use it for this > > problem? > > > Can python-libpcap or pycap or dpkt do that? > > A quick browse of the pypcap website suggests that yes, it can. > > -- > Rhodri James *-* Wildebeeste Herder to the Masses Yap, I found that dpkt can do this, Thanks all. Evan -- http://mail.python.org/mailman/listinfo/python-list
[SMTPLIB] how to send a "Multiline" mail with smtplib?
Hello -
I'm new with Python, I try to do a mail problem, the code likes below:
+
import smtplib
import mimetypes
from email.Encoders import encode_base64
from email.MIMEAudio import MIMEAudio
from email.MIMEBase import MIMEBase
from email.MIMEImage import MIMEImage
from email.MIMEMultipart import MIMEMultipart
from email.MIMEText import MIMEText
msg = MIMEMultipart()
msg['From'] = '[EMAIL PROTECTED]'
msg['To'] = '[EMAIL PROTECTED]'
msg['Subject'] = 'test subject'
body=MIMEText('hello,\r\n ok',_subtype='html',_charset='windows-1255')
msg.attach(body)
server = smtplib.SMTP('mail.xx.net')
server.sendmail('[EMAIL PROTECTED]', '[EMAIL PROTECTED]', msg.as_string())
server.quit()
+++
I try to use "\r\n" or "\n", but no luck, nothing with them, I still
get a Single-line text in the mail.
hello, ok
So how do I send a multiline mail? such as :
+++
Hello,
1,
2,
ok
+++
I would like to get help from you, thanks so much.
--
http://mail.python.org/mailman/listinfo/python-list
Re: how to send a "Multiline" mail with smtplib?
On Jun 19, 6:12 pm, Lie <[EMAIL PROTECTED]> wrote:
> On Jun 19, 4:02 pm, Justin Ezequiel <[EMAIL PROTECTED]>
> wrote:
>
> > perhaps change html
>
> > body=MIMEText('hello,\r\n
> > ok',_subtype='html',_charset='windows-1255')
>
> > to plain
>
> > body=MIMEText('hello,\r\n
> > ok',_subtype='plain',_charset='windows-1255')
>
> If that was the case, and you needed a line break in html-mode, use
> or tags.
Thanks all,
and yes, if I use "plain" or use HTML tag "", it worked:
(1) HTML:
I use tag "" and " ", and when I reply that mail, I will
see "" tag in mail content, it is not a good option.
thanks,
Evan
--
http://mail.python.org/mailman/listinfo/python-list
what is meaning of "@" in pyhon program.
HI,
When I check example of "cmd2" module (a enhancement of cmd module), I
can not understand all, for example: the character "@",
+
def options(option_list):
..
class cmd(...):
...
@options([make_option('-p', '--piglatin', action="store_true",
help="atinLay")])
+
I do not understand what "@options" does, most time, I know what the
meaning of character "*" and character "**", but I was not use "@"
before.
Thanks for your help.
--
http://mail.python.org/mailman/listinfo/python-list
Re: what is meaning of "@" in pyhon program.
cool, thanks, I will check document. -- http://mail.python.org/mailman/listinfo/python-list
Is there a good way to implement file updating? such as lock, update, reload...
Hello - My script use a DB file which is written by XML, and the user load this DB file (XML tree in memory), and then do some updating about this tree, such as delete element, generate new element or move element. The thing is, my script is a cmd based program (based on module "cmd"), and there are many users would use this script at same time, in a shell style prompt (module "cmd"), so I want to implement a updating after a user update the XML tree, it such as a "signal console", so that all the user can keep same DB, or other user can see update a few seconds later. What I did is, create a new file calling "db_change", and put a number "1" in file, and then update the real "DB" file (by change uid to lock file), other user to check this file and then re-load XML file, but I do not think it is a good idea, the performance is not good. I would like to know if you could help on this matter, I hope I can get inspiration/example from you guys. Thanks, -- http://mail.python.org/mailman/listinfo/python-list
Re: Is there a good way to implement file updating? such as lock, update, reload...
If I get rid of the XML, I have to change my script more and more, it is not easy to do that. :( :( Thanks, -- http://mail.python.org/mailman/listinfo/python-list
Is it possible to create "network conneciton" on windows system?
Hello, one of my PC is window system, and in "control panel -> Network Connections", I can see some network connections such as PPPOE or VPN which I created by click "create a new connection". My question is, is it possible to create a new connection by using Python script? which means I do not want to use Window UI (via "control panel"), if it is possible, I can save so many time to create various network connection when I want to do testing in the lab. Thanks very much. Evan -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to create "network conneciton" on windows system?
On Jul 15, 6:22 am, Larry Bates <[EMAIL PROTECTED]> wrote: > Evan wrote: > > Hello, > > > one of my PC is window system, and in "control panel ->Network > >Connections", I can see somenetworkconnectionssuch as PPPOE or VPN > > which I created by click "create a new connection". > > > My question is, is it possible to create a new connection by using > > Python script? which means I do not want to use Window UI (via > > "control panel"), if it is possible, I can save so many time to > > create variousnetworkconnection when I want to do testing in the > > lab. > > > Thanks very much. > > Evan > > It is very likely that it is possible to do this. Most control panel > applications store the results of their GUI setup in the registry. If you can > determine what registry keys have been added/changed. Here is an open source > registry compare utility that might help: > > https://sourceforge.net/projects/regshot > > You can then use the _winreg module to make such changes on a new machine. > > HTH, > Larry Thanks Larry, The thing is, if I change the registry, I have to reboot the PC for applying new configuration of system. Any idea to apply the changing without reboot after modify registry? Thanks, -- http://mail.python.org/mailman/listinfo/python-list
a question about mysqldb
a simple problem but I do not know why...:(, could anyone help me?
MySQLdb nominally uses just the %s placeholder style, in my script, i
got error if you want to use placeholder(%s) for table name:
+
>>> str="select tID,tNote from %s where tID=1" < check here
>>>
>>> e=["tmp"]
>>> s.dbptr.execute(str,e)
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/site-packages/MySQLdb/cursors.py", line
166, in execute
self.errorhandler(self, exc, value)
File "/usr/lib/python2.4/site-packages/MySQLdb/connections.py", line
35, in defaulterrorhandler
raise errorclass, errorvalue
_mysql_exceptions.ProgrammingError: (1064, "You have an error in your
SQL syntax; check the manual that corresponds to your MySQL server
version for the right syntax to use near ''tmp') where tID=1' at line
1")
>>>
But sql worked but the I got no query result:
>>> str="select tID,tNote from tmp where %s = %s" <--check here
>>> e=["tID",int(1)]
>>> s.dbptr.execute(str,e)
0L<-- check here
>>>
>>> s.dbptr.fetchall()
()
>>>
And then, it worked if I do:
>>> str="select tID,tNote from %s where %s = %s" % ("tmp","tID",1)
>>>
>>> str
'select tID,tNote from tmp where tID = 1'
>>> s.dbptr.execute(str)
1L
>>>
>>> s.dbptr.fetchall()
({'tID': 1L, 'tNote': 'kao'},)
mysql> desc tmp
-> ;
+---+-+--+-+-++
| Field | Type| Null | Key | Default | Extra |
+---+-+--+-+-++
| tID | int(11) | NO | PRI | NULL| auto_increment |
| tDate | date| YES | | NULL||
| tSID | int(11) | NO | | NULL||
| tCom | varchar(15) | YES | | NULL||
| tNote | text| YES | | NULL||
+---+-+--+-+-++
5 rows in set (0.00 sec)
+
mysql>
mysql>
Thanks,
--
http://mail.python.org/mailman/listinfo/python-list
How to make a "command line basd" interactive program?
Hope this hasn't been posted hundreds of times. I'm new for this. Before using python for this kind of script, I was using TCL to write down a "command line based" interactive program. it likes a "tclsh", or "python" command, after that, you can work under a prompt, for example, " - >> ", and then you can execute any commands what you defined in script. Now, in python, are there any common way(class) to finish this work? or does anybody has a example to do that? Thanks, Evan -- http://mail.python.org/mailman/listinfo/python-list
Re: How to make a "command line basd" interactive program?
that's great, a custom shell is what I need. Thanks all Evan -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Is python a interpreted or compiled language?
On 6/20/2012 19:53, Dave Angel wrote: > But since you mention java, I'd like > to point out a few things that are different between the two > environments. He and I are describing CPython; jython and other > implementations don't use .pyc files, and they behave differently. There's one more important difference, which is that the JVM does just-in-time (JIT) compilation of bytecode rather than straight interpretation like CPython does. This basically means that as a program is executing, the JVM will sometimes go through what is a more traditional compilation step and translate its bytecode into machine code rather than just interpret it. It will do this for things it discovers are "hot paths" through the program, where spending some extra time up front (while the program is still executing!) for the compilation and optimization steps is worth it in terms of the speedup. In fact, the JVM may transform a given piece of bytecode several times, applying new optimizations as it discovers that some block is not just important, but *really* important. :-) (Where "important" = "executed a lot.") By my understanding, CPython doesn't do any of this; it always executes the same byte code in the same way, and what it does to the bytecode looks more like an interpreter than a JIT compiler. On the other hand, Jython translates Python to Java bytecode and IronPython translates Python to .Net bytecode (MSIL), so if you use one of those implementations of Python, you are getting a JIT. (Nevertheless my understanding is both tend to be slower than CPython? Not sure about that, and don't know by how much or why.) The new kid on the block is PyPy, which is a JIT engine for Python written in Python itself. But the interesting point is that the (very) old view of "compiled or interpreted" breaks down a lot nowadays; it's closer to a continuum: - pure interpreted - compiled to bytecode, which is then interpreted - JIT compiler (almost always this has a bytecode compilation step though theoretically this isn't necessary) - pure compiled I'd say these categories tend to be qualitative "I know it when I see it" rather than hard divisions. Evan > > java has available a "runtime" environment, for those who don't want or > need the compiler. CPython comes with the compiler and the runtime > bundled together. > > Java's classfile remains stable over a number of compiler versions, > while CPython doesn't seem to worry about that. > > Java's classfile has been targeted by a number of other byte code > compilers, including jython. Code from any of those libraries may use > the java libraries. > > With java, one has to explicitly compile the java code, while with > CPython, the runtime logic compiles imported modules if they're not > already compiled. > signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Þ how can I implement "cd" like shell in Python?
On 6/28/2012 7:28, Alex chen wrote:
> I just want to write a python program,it can be called in the linux
> terminal like the command "cd" to change the directory of the shell terminal
You "can't" do this; a program the shell runs cannot affect the shell's
execution.
What you have to do is have some help from the shell. Have your Python
program output the path to the directory you want to change to. Then you
can run it as follows
cd $(new-directory.py)
or, if has arguments,
cd $(new-directory.py foo blah)
(The $(...) is usually spelled as `...` around the internet. If you're
unfamiliar, what it does is run the command then substitute the *output*
of that command at the command line.)
Eventually you probably want to wrap this up so you don't have to do
that every time. You can use a shell function for this. Assuming you're
using an 'sh' derivative, it will look something like
function my-cd() {
cd $(new-directory.py "$@")
}
I'm not a shell programmer and I always forget the names of the
variables holding the arguments, so check that at first and make sure
it's passing the right thing to the new-directory script, e.g. that it
works with whitespace in the arguments and that it isn't including the
equivalent to argv[0] in the script.
Evan
--
http://mail.python.org/mailman/listinfo/python-list
Re: Re: code review
On 6/30/2012 19:37, Chris Angelico wrote: > On Sun, Jul 1, 2012 at 10:08 AM, Ben Finney > wrote: >> I know of no programming language that >> would give a newcomer to Python that expectation. So where is the norm >> you're referring to? > > C, SQL, REXX, and many other languages. Some others: Lua, Javascript, Ruby, O'Caml. In fact, the only language I can find that uses infix notation (i.e. no Lisp) where it's *not* true that "a < b < c" is equivalent to "(a < b) < c" is Haskell -- and that's because < is not associative and "a < b < c" is a syntax error. (FWIW this is my favorite approach.) You may also want to put Java in there as well, as < is effectively not commutative in that language. (I didn't try C#.) I've been programming in Python for a few years and this is the first time I've seen this. If I had seen that in a program, I'd have assumed it was a bug. Evan signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: code review
On 6/30/2012 23:45, Evan Driscoll wrote: > You may also > want to put Java in there as well, as < is effectively not commutative > in that language. (I didn't try C#.) I guess you could actually put Lua and Ruby into the roughly same category as Java too. But things get a little nastier in ==, as 'false == false == false' evaluates as '(false == false) == false' to 'false' in Java and Lua. (Ruby produces a syntax error for this, roughly the Haskell approach.) But we have Javascript: 1 < 1 < 2 => true false == false == false => false O'Caml: # false == false == false;; - : bool = false # 1 < 2 < true;; - : bool = false Java: System.out.println(false == false == false); (outputs) false Lua: > print(false == false == false) false C and C++: std::cout << (1 < 1 < 3) << "\n"; (outputs) 1 std::cout << (false == false == false) << "\n"; (outputs) 0 Evan signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: code review
On 7/1/2012 4:54, Alister wrote: > On Sat, 30 Jun 2012 23:45:25 -0500, Evan Driscoll wrote: >> If I had seen that in a program, I'd have assumed it was a bug. > > You would? > I have only been using python for 6 - 12 months but in my past I > programmed microcontrollers in assembly. > > as soon as i saw it i understood it & thought great, like a light bulb > going on. It's not a matter of "I wouldn't have understood what the author was trying to do" (with a small caveat), it's a matter of "I'd have assumed that the author didn't understand the language semantics." I'm pretty sure it goes contrary to *every other programming language I've ever used* (and a couple that I haven't). I understand why Python does it, and it certainly is nice in that it matches typical mathematical notation, but the surprise quotient is *very* high in the PL world IMO. Evan -- http://mail.python.org/mailman/listinfo/python-list
Re: 2 + 2 = 5
On 7/4/2012 14:37, Paul Rubin wrote: > I just came across this (https://gist.github.com/1208215): > > import sys > import ctypes > pyint_p = ctypes.POINTER(ctypes.c_byte*sys.getsizeof(5)) > five = ctypes.cast(id(5), pyint_p) > print(2 + 2 == 5) # False > five.contents[five.contents[:].index(5)] = 4 > print(2 + 2 == 5) # True (must be sufficiently large values of 2 there...) > > Heh. The author is apparently anonymous, I guess for good reason. Probably just nostalgic for old Fortran, which, supposedly, allowed you to change the values of literals by passing them to a function by reference and then modifying the value. Evan signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: 2 + 2 = 5
On 01/-10/-28163 01:59 PM, Alexander Blinne wrote: 5+0 is actually 4+0, because 5 == 4, so 5+0 gives 4. 5+1 is actually 4+1, which is 5, but 5 is again 4. 5+2 is 4+2 which is 6. Now all I can think is "Hoory for new math, new-hoo-hoo math" :-) Evan -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Gender, Representativeness and Reputation in StackOverflow
On 01/-10/-28163 01:59 PM, Terry Reedy wrote: This is a deceptive and time-wasting link Leaving aside the point that this is not directly related to Python, my opinion is that if the authors will not make past and future papers freely available, not even an abstract, they should not ask for valuable free data from freely donated time. Leaving aside questions of relevance to the email list and the quality of results from a self-selected survey, the PDF is linked directly from the Google Scholar link in the original post: "[PDF] from tue.nl". Evan -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Objects in Python
On 08/22/2012 12:46 PM, lipska the kat wrote:
> If you can show me a 'type' that cannot be assigned to
>
> a
>
> in the same scope then I would be most interested to know, I haven't
> found one yet.
As other people have said, you've just pointed out the difference
between static typing and dynamic typing -- and how the former types
variables (or "names") and the latter types objects. I just have a few
things to add to your post and others.
First, from some point of view, you're correct. From a type theory point
of view "dynamically typed" is an oxymoron, because *by definition*
(from this point of view) types are a property of variables (and
expressions). For example, Ben Pierce says (in "Types and Programming
Languages"):
The word "static" is sometimes added explicitly...to distinguish
the sorts of compile-time analyses we are considering here from the
dynamic or latent typing found in languages such as Scheme, where
run-time type tags are used to distinguish different kinds of
structures in the heap. Terms like "dynamically typed" are arguably
misnomers and should probably be replaced by "dynamically checked,"
but the usage is standard.
(And the usage is standard because it's just really useful to be able to
say "dynamically-typed" instead of "uni-typed with runtime checks of
things that act like types". (I don't think Pierce's "dynamically
checked" is specific enough. :-))
Second, this concept isn't *so* unfamiliar to you. If I give you the
following Java code:
void foo(Object o) { ... }
and ask what type 'o' is, there are kind of two answers. The first is
that 'o' is an 'Object'. But you can't make an Object -- that's an
abstract class. (IIRC. If it's not then just bear with me; you get the
idea. :-)) So from a strictly static type-theory point of view, 'foo' is
unusable because it takes a type which you can never create. But of
course that's not the case, because in actual Java 'o' has some dynamic
type which is a subclass of 'Object'.
Though I'm sure this statement will be *really* popular with this list
, if it puts your mind at ease a little, you can imagine that
there are no primitive types and Python names all have type 'Object',
but that you can refer to the functions in an object's dynamic type
without explicitly downcasting. (The analogy isn't perfect.)
On 08/22/2012 01:15 PM, Ian Kelly wrote:
> The classic example of weak typing is concatenation of strings and
> numbers, e.g. ("abc" + 123). Weakly typed languages like JavaScript
> will implicitly coerce the number to a string and perform the
> concatenation. Strongly typed languages like Python will raise a
> TypeError instead.
I would also say don't get *too* caught up in categorizing everything
into "strong" and "weak"; that's a spectrum, and where things fall is a
lot more interesting than just "here or there". Really it's even more
complex than just a linear spectrum -- Language A can be stronger than
Language B in one respect but weaker in another.
In particular, it's possible to have rather stronger typing than Python
(especially with respect to Booleans, but in some other respects as well).
Evan
signature.asc
Description: OpenPGP digital signature
--
http://mail.python.org/mailman/listinfo/python-list
Re: Re: Objects in Python
On 08/22/2012 02:45 PM, lipska the kat wrote:
> On 22/08/12 20:03, Evan Driscoll wrote:
>> Second, this concept isn't *so* unfamiliar to you. If I give you the
>> following Java code:
>>
>>void foo(Object o) { ... }
>>
> looking at this method declaration I can see that the method takes an
> argument of type Object (and just FYI class Object is not abstract and
> you can do Object o = new Object()) and does not return a value.
> I know that for the lifetime of this JVM, whatever o turns out to be it
> will always be an Object. I can't assign a primitive to o as ints chars
> floats etc are certainly not Objects. There are certain invariants that
> give me a warm and comfortable feeling inside.
I'm not saying it's nothing, but "can't assign a primitive" isn't much
of an invariant in the broad scheme of things when you can pass items as
diverse as lists, GUI buttons, files, etc. I would say it's more like if
you see 'int x' then *that* imposes a pretty big invariant, but passing
'Object' imposes almost nothing.
This is especially true considering the fact that you actually *can* say
'foo(4)' and Java will go and autobox the 4 into Integer(4) for you.
(BTW, this analogy suggests a way that's actually fairly useful for how
to look at Python coming from the Java perspective: Python just lacks
primitive types and things like integers are always boxed. Thus *all*
Python variables are essentially references.)
Evan
signature.asc
Description: OpenPGP digital signature
--
http://mail.python.org/mailman/listinfo/python-list
Re: Re: Objects in Python
On 8/22/2012 18:58, Ben Finney wrote: > You haven't discovered anything about types; what you have discovered is > that Python name bindings are not variables. > > In fact, Python doesn't have variables – not as C or Java programmers > would understand the term. What it has instead are references to objects > (with names as one kind of reference). OK, I've seen this said a few times, and I have to ask: what do you mean by this? I consider myself pretty decent at Python and other languages, and I really don't get it. Especially the comparison to Java variables. Java programmers are quite used to variables which are references to objects: everything that's not a primitive type is a reference, and it's kinda hard to determine whether primitives are references or actual primitives. And many other languages have reference behavior and still call their bindings "variables", e.g. Scheme. Evan signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Objects in Python
On 08/23/2012 04:19 AM, lipska the kat wrote: > Well we don't want to turn this into a language comparison thread do we, > that might upset too many people but I can't remember ever writing a > method that took an Object as argument, you just can't do that much with > an Object. In the pre-Java-1.5 days, functions that took Objects were *very* common; e.g. every collections class. Even now there are probably lingering cases where either there's some code that hasn't been genericized or is too much work to genericize to make it worthwhile. (I do very little Java programming so can't point to any concrete cases if you would (reasonably) reject the example of java.util.collections being used in their non-generic form.) Anyway, the point wasn't that 'foo(Object o)' is common, just that you've probably seen something which is somewhat comparable. Evan signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Objects in Python
[I have some things to say to a few people so I'm just putting it all in one rather than clutter up your email box even more.] On 08/23/2012 12:33 AM, Chris Angelico wrote: > [Snip discussion on names vs variables] > > Does that sort things out, or just make things more confusing? > > ChrisA I... am not sure. I don't think it really told me anything new. I think it's just that I don't think that any of the distinctions (nor all of them put together) makes it worthwhile to reject a perfectly good term in common use just because the behavior of Python variables is a bit different from the behavior of variables in *some* other languages. For instance, I don't get annoyed that both Java and Python use the terms "class" and "object" for similar but still very different things. And while I think it's worth saying "Python classes and objects are rather different from Java's", I definitely *wouldn't* say "Python classes aren't really classes" -- even though (I assert) Python classes are *far* further from Simula-style (/Java/C++) classes than Python variables are from Java variables. On 08/23/2012 03:59 AM, Jussi Piitulainen wrote: > I would also avoid any distinction between an object and a > "reference" to an object, except as an implementation detail. It's not > helpful. Wh? How would you describe it then? To me, that distinction is absolutely *fundamental* to understanding how languages like Python/Scheme/Java work, because it tells you how to reason about aliasing behavior in an unconvoluted way (which is essential to understanding how they work). How would *you* suggest dealing with that issue? On 08/23/2012 09:43 AM, Jerry Hill wrote: > On Thu, Aug 23, 2012 at 4:59 AM, Jussi Piitulainen wrote: >> I don't get it either. To me the python-has-no-variables campaigners >> seem confused. As far as I can see, Python can be seen in terms of >> variables bound to (locations containing) values perfectly well, in a >> way that should be quite familiar to people who come from Java (or >> Lisp, Scheme like me). > > ... > > Perhaps those that come from the Java and Lisp world don't find the > name/value paradigm as helpful. Still, it seems silly to excoriate > people on the list for trying to explain python fundamentals in > several different ways. Sometimes explaining the same idea in > different words helps people understand the concept better. I agree with this, and I'm happy that people found it useful. *However*, this thread wasn't really prompted by someone just trying to explain variables in different terms -- it was prompted by one of the many comments you see from time-to-time that "Python doesn't have variables – not as C or Java programmers would understand the term". That's a different than saying "here's another way of looking at Python variables", and that instance is even toned down compared to a lot of the instances you'll find (which will often omit the qualification at the end). To me, saying "here's an alternative way to look at variables" is great, but saying "Python doesn't have variables" is, IMO, at least as silly as what Jussi said. To me, dancing around the issue just leads to more confusing terminology and makes things worse. (And this is reinforced by the fact that neither I nor Google seems to have really seen "Python doesn't have classes" ever used, when that statement is at least as true as "Python doesn't have variables".) Evan signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Variables vs names [was: Objects in Python]
On 08/23/2012 12:56 PM, Steven D'Aprano wrote:
> On Thu, 23 Aug 2012 12:17:03 -0500, Evan Driscoll wrote:
>
>> I definitely *wouldn't* say "Python
>> classes aren't really classes" -- even though (I assert) Python classes
>> are *far* further from Simula-style (/Java/C++) classes than Python
>> variables are from Java variables.
>
> Well, Python classes are first-class (pun not intended) objects in their
> own right, and hence are data. Java and C++ classes are not, they are
> instructions to the compiler rather than data.
>
> But other than that, what do you see as the difference between Python
> classes and Simula-style classes?
So first, to some extent that's like saying "these two different things
are different in this important way, but other than that, what's the
difference?" :-)
But there are some other differences. (Not all of these are strictly
with classes per se, but I would say they all have strong interactions
with the object system.)
* Explicit 'self'. OK, this sounds just like a minor syntactic
difference, and in some respect it is. (For some time I considered it
an annoying piece of syntactic salt.) But it has significant
interactions with other things which you can do, such as using a
method as just a normal function ('type(c).f(c)' ~= 'c.f()')
or attaching other functions to an instance or a class (more on that
later).
This is definitely my weakest argument. :-)
* Fields. In Simula-style classes, you can tell easily what fields a
class and its objects contain. In Python, that question from some
point of view doesn't even make sense (in the absence of __slots__).
Fields are a property of the *objects* rather than the class, and
two objects of the same class don't necessarily have the same fields.
Related to this point we have...
* What it means for an object to have a particular class type. With
Simula-style classes, if I have an object 'o' of class 'c', then I
know that 'o' has the functions and fields defined by 'c'. Now, the
virtual functions may have been overriden in base classes and stuff,
and maydbe they'll always fail, but I at least know they're *there*.
In Python, I know... well, nothing basically. As far as I know, it's
possible to make it so that o's only relation to 'c' is what
'type(o)' and 'instanceof' say. (And maybe you can even override
those, I dunno!) You can go through and add/remove/replace functions.
Two different objects of the same class may have completely disjoint
sets of attributes.
> Given:
>
> x = some_object()
> y = x
>
> I could say that x and y are the same object, rather than x and y are
> references to the same object.
Huh, fair enough.
>> To me, saying "here's an alternative way to look at variables" is great,
>> but saying "Python doesn't have variables" is, IMO, at least as silly as
>> what Jussi said. To me, dancing around the issue just leads to more
>> confusing terminology and makes things worse.
>>
>> (And this is reinforced by the fact that neither I nor Google seems to
>> have really seen "Python doesn't have classes" ever used, when that
>> statement is at least as true as "Python doesn't have variables".)
>
> I think you are utterly wrong here.
>
> Python has classes. They are created by the "class" keyword. Whether
> those classes are identical to Java classes is irrelevant -- in Python,
> these whatever-they-are-things are called "classes", and so Python has
> classes.
>
> But Python does not have things called "variables". There is no
> "variable" keyword to create a variable.
OK, let's make a new language. I'll call it 'Python--' because at least
*I* wouldn't want to program in it. :-)
In Python--, any time you use a name, you have to prefix it with the
word 'variable':
variable x = 4
print(variable x)
Does Python-- have variables? Does Python? To me, the answer to those
questions basically has to be the same -- after all, the new 'variable'
keyword didn't really change the language, just have it a slightly
different concrete syntax. Heck, if I wanted to implement Python--, the
only thing I'd have to change in a Python implementation is the lexer!
And if you say "no, Python-- doesn't have variables, it just has
something that it wrongly calls variables", then it's no contradiction
to say "Python doesn't have classes, it just has something that it
wrongly calls classes."
Think of it as duck-typing the term "variable". :-) To me, Python loca
Re: Re: Objects in Python
On 8/23/2012 22:17, alex23 wrote: > But Roy's point was that referring to 'a' as a 'variable' makes no > sense, as it's not an allocated piece of memory. Does the computer just remember what 'a' refers to by keeping notes about it in Narnia? Put it this way. If C removed the & operator -- and thus you couldn't tell what address a variable (or "variable instance", if you prefer) was at -- would "int x;" cease to be a variable? Evan signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Objects in Python
On 08/24/2012 10:04 PM, Steven D'Aprano wrote:
The fact that the end result is the same is hardly surprising -- Python's
VM is built on top of C pointer indirection, so of course you can start
with pointers and end up with Python semantics. But the practice of
coding are very different:
* in C, I care about identifiers ("names") in order to explicitly manage
addresses and pointers as a means to reach the data I actually care about;
* in Python, I care about identifiers in order to reach the data I
actually care about.
So I find this comment very interesting. It makes me wonder if the root
cause of our (pretty minor) disagreement is in some sense related to our
mental models of *C* variables. I'm actually not much of a C programmer
specifically, but I do a lot of C++ stuff. Of those two descriptions,
I'd actually say that the Python description sounds more like how I
think about variables in C++ most of the time.
Obviously there are differences between value and reference semantics
between the two languages, but thinking about some variable being
located at some address in memory is something that I actually do pretty
rarely; I basically think of variables as naming data, and addresses
mostly come into play when thinking about points-to and aliasing
information at a more abstract level, much the same as I do in Python.
Evan
--
http://mail.python.org/mailman/listinfo/python-list
Re: Re: Objects in Python
On 08/24/2012 05:00 AM, Steven D'Aprano wrote: No. The compiler remembers the address of 'a' by keeping notes about it somewhere in memory during the compilation process. When you run the compiled program, there is no longer any reference to the name 'a'. ... The mapping of name:address is part of the *compilation* process -- the compiler knows that variable 'x' corresponds to location 12345678, but the compiled code has no concept of anything called 'x'. It only knows about locations. The source code 'x = 42' is compiled into something like 'store 42 into location 12345678'. (Locations may be absolute or relative.) In languages with name bindings, the compiler doesn't need to track name:address pairs. The compiled application knows about names, but not about addresses. The source code 'x = 42' is compiled into something like 'store 42 into the namespace using key "x"'. What you describe is sorta correct, but it's also not... you're describing implementations rather than the language. And while the language semantics certainly impose restrictions on the implementation, I think in this case the situation is closer than you acknowledge: From the Python side, I suspect that for most functions, you'd be able to create a Python implementation that behaves more like C, and allocates locals in a more traditional fashion. I don't know much about it, but I'd guess that PyPy already does something along this line; someone also mentioned that Cython (admittedly not a full-blown Python implementation, but close for the purpose of this question) tries to do the same thing. On the C side, imagine a function with locals x, y, and z which never takes the address of any of them. (You said later that "Just because the public interface of the language doesn't give you any way to view the fixed locations of variables, doesn't mean that variables cease to have fixed locations.") First, C variables may not even have a memory address. They can disappear completely during compilation, or live in a register for their entire life. Second, it's possible that those variables *don't* occupy a fixed location. If you never explicitly take an address of a variable (&x), then I can't think of any way that the address can be observed without invoking undefined behavior -- and this means the C compiler is free to transform it to anything that is equivalent under the C semantics. In particular, it can split uses of a variable into multiple ones if there are disjoint live ranges. For instance, in: x = 5 print x x = 10 print x there are two live ranges of x, one consisting of lines 1 and 2, and one consisting of lines 3 and 4. These live ranges could have been different variables; I could just of easily have written x = 5 print x y = 10 print y and these pieces of code are observationally equivalent, so the compiler is allowed to generate the same code for both. In particular, it could either compile the second example to share the same memory address for x and y (meaning that a memory address isn't uniquely named by a single variable) or it could compile the first to put the two live ranges of x into different memory addresses (meaning that a variable doesn't uniquely name a memory address). In fact, I'd *expect* an optimizing compiler to share memory for x and y, and I'd also expect to be able to concoct an example where different live ranges of one variable wind up at different addresses. (The latter I'm less sure of though, and I also expect it'd be a little hard, as you'd have to come up with an example where even at the high optimization levels you'd need to see that, both live ranges would wind up in memory.) Third, and more wackily, you could technically create a C implementation that works like Python, where it stores variables (whose addresses aren't taken) in a dict keyed by name, and generates code that on a variable access looks up the value by accessing that dict using the name of the variable. Evan -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Algorithms using Python?
On 09/21/2012 02:45 PM, Dennis Lee Bieber wrote: > On Fri, 21 Sep 2012 14:26:04 +0530, Mayuresh Kathe > declaimed the following in gmane.comp.python.general: > >> Is there a good book on foundational as well as advanced algorithms >> using Python? >> > Depends on what you mean by "foundational"... > > Since Python has dynamic lists and dictionaries, I suspect you won't > find any textbook focusing on linked-list or hashed lookup algorithms > using Python. I wouldn't be so sure; C++ and Java both have standard libraries with dictionaries (and thus are mostly lacking a literal syntax). But it's easy to find books talking about the simple stuff. I'd suggest looking at the books used in MIT's intro classes: 6.000 (Intro to CS and programming): http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-00sc-introduction-to-computer-science-and-programming-spring-2011/Syllabus/ Zelle, John M. Python Programming: An Introduction to Computer Science Budd, Timothy. Exploring Python Shaw, Zed A. Learn Python the Hard Way [online] Swaroop, CH. A Byte of Python 6.006 (Intro to algorithms): http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-006-introduction-to-algorithms-spring-2008/syllabus/ Miller and Ranum. Problem Solving with Algorithms and Data Structures Using Python. [CLRS isn't Python] and see if they have anything to offer. (I didn't actually look.) > You can probably implement them, but they're not going to be very > efficient. (And never "remove" an element from the linked-list > implementation because Python would shift all the other elements, hence > your "links" become invalid). Huh? Evan signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: + in regular expression
On 10/04/2012 04:59 PM, Mark Lawrence wrote:
why the "\s{6}+" is not a regular pattern?
Why are you too lazy to do any research before posting a question?
Errr... what?
I'm only somewhat familiar with the extra stuff that languages provide
in their regexs beyond true regular expressions and simple extensions,
but I was surprised to see the question because I too would have
expected that to work. (And match any sequence of whitespace characters
whose length is a multiple of six.) I reskimmed the documentation of the
re module and didn't see anything that would prohibit it. I looked at
several of the results of a Google search for the multiple repeat error,
and didn't really find any explanation beyond "because you can't do it"
or "here's a regex that works." (Well, OK, I did see a mention of +
being a possessive quantifier which Python doesn't support. But that
still doesn't explain why my expectation isn't what happened.)
In what way is that an unreasonable question?
Evan
--
http://mail.python.org/mailman/listinfo/python-list
Re: Re: + in regular expression
On 10/05/2012 04:23 AM, Duncan Booth wrote:
A regular expression element may be followed by a quantifier.
Quantifiers are '*', '+', '?', '{n}', '{n,m}' (and lazy quantifiers
'*?', '+?', '{n,m}?'). There's nothing in the regex language which says
you can follow an element with two quantifiers.
In fact, *you* did -- the first sentence of that paragraph! :-)
\s is a regex, so you can follow it with a quantifier and get \s{6}.
That's also a regex, so you should be able to follow it with a quantifier.
I can understand that you can create a grammar that excludes it. I'm
actually really interested to know if anyone knows whether this was a
deliberate decision and, if so, what the reason is. (And if not --
should it be considered a (low priority) bug?)
Was it because such patterns often reveal a mistake? Because "\s{6}+"
has other meanings in different regex syntaxes and the designers didn't
want confusion? Because it was simpler to parse that way? Because the
"hey you recognize regular expressions by converting it to a finite
automaton" story is a lie in most real-world regex implementations (in
part because they're not actually regular expressions) and repeated
quantifiers cause problems with the parsing techniques that actually get
used?
Evan
--
http://mail.python.org/mailman/listinfo/python-list
Re: + in regular expression
On 10/05/2012 10:27 AM, Evan Driscoll wrote:
On 10/05/2012 04:23 AM, Duncan Booth wrote:
A regular expression element may be followed by a quantifier.
Quantifiers are '*', '+', '?', '{n}', '{n,m}' (and lazy quantifiers
'*?', '+?', '{n,m}?'). There's nothing in the regex language which says
you can follow an element with two quantifiers.
In fact, *you* did -- the first sentence of that paragraph! :-)
\s is a regex, so you can follow it with a quantifier and get \s{6}.
That's also a regex, so you should be able to follow it with a
quantifier.
OK, I guess this isn't true... you said a "regular expression *element*"
can be followed by a quantifier. I just took what I usually see as part
of a regular expression and read into your post something it didn't
quite say. Still, the rest of mine applies.
Evan
--
http://mail.python.org/mailman/listinfo/python-list
Re: Re: Providing a Python wrapper to a C++ type.
[Stefan gave part of an answer here, but I've got an addition too.] On 10/16/2012 6:46 AM, Marco Nawijn wrote: > I never worked with Cython (but I know it is very powerful and interesting) > but in my mind there are slight differences in usage scenario between e.g. > Boost Python and Cython. For me the idea of Cython is that your main code is > in Python, but you want to improve the performance of specific parts of the > code. In that case, Cython is the way to go. In case of Boost Python, the > scenario for me is that you have a main program/library in C++, but you want > to be able use the functionality from Python. > > Do you agree with this view? Sort of, but sort of not. I've only used Cython a little bit, but it seems to work equally well if you want to write a C module for some reason (e.g. to interface with existing C code) but don't want to deal with the standard CPython C API directly. For instance, I used it to wrap the OS's opendir/readdir (FindFirstFile/FindNextFile) functions: I just wrote a bit of code using Cython's extensions, and I get a module I can import and use as normal. I certainly didn't do it for speed, I did it because it seemed like a reasonable way to get access to those APIs. (ctypes was insufficient for my needs.) So wrapping a C++ class using Cython also seems pretty natural to me, assuming that Cython does OK with C++ and isn't restricted to C (which I have no idea about). Evan -- http://mail.python.org/mailman/listinfo/python-list
Re: A desperate lunge for on-topic-ness
Ooo, a good religious war. How could I resist? :-) Bear in mind that
what I say is relative to layout issues, which in the grand scheme of
things. So even if I say I really disklike something, it's still not so
bad in practice. Except for backslash continuations. :-)
On 10/18/2012 01:06 AM, Zero Piraeus wrote:
> What are people's preferred strategies for dealing with lines that go
> over 79 characters?
My general rules are:
1. I dislike 80 character limits, and basically don't make a
particularly strong attempt adhere to them for, well, basically
any code I write, Python or not. I'll explain a little bit of why
later. (I'd begrudgingly go along if I were working on a different
code base that did of course, but in the meantime I don't have to
deal with corporate style standards or anything like that so can
bend the rules a bit.) 100 about where I start getting
uncomfortable, and my semi-hard limit is 110-120. No doubt that's
because that's about the line length I get with half of my monitor's
width. :-)
Python isn't as bad as C++ though (my main other language), where
80 characters can go by *very* quickly.
2. Backslash continuations are *terrible*. I hate them with a firery
passion. :-) A line could be 1000 characters long and it would be
better than a 120-character line backslash-continued.
3. Using parentheses for continuations is sunshine and rainbows.
4. Extra variables are also great; I suspect I tend to use a
more-than-average amount of extra variables anyway. (Though
probably less so compared with the Python coder community than with
the C++ coder community.)
Hans Mulder said:
> Steven D'Aprano said:
>> some_variable = spam('x') + ham(
>> some_longer_variables, here_and_here,
>> and_here_also)
>
> I would spell that as:
>
> some_variable = spam('x') + ham(
> some_longer_variables,
> here_and_here,
> and_here_also,
> )
Ugh, I hate both. :-) I really dislike the arguments to a function
appearing to the left of the function. I'm fine with either
some_function(foo,
bar,
baz)
or
some_function(
foo,
bar,
baz)
but the two quoted suggestion makes me cringe a bit. (Of my two options,
I think I actually prefer the latter, but tend to use the former because
I'm too lazy to figure out how to make Emacs do the second one.)
So with the above rule I might format that as:
some_variable = spam('x') + ham(some_longer_variables,
here_and_here,
and_here_also)
except that runs afoul of another of my implict formatting "rules",
which is that if I have a multi-argument construct (e.g. an operator
or function call) and one of the arguments is multiple lines, I'd prefer
to see all of the arguments on their own lines. So I'd format
that as:
some_variable = (spam('x')
+ ham(a, b, c))
as my first choice (long var names truncated here, but in real code with
no indent that's only 76 characters with the full ones in so it's fine
-- I'd do it that way even with a couple levels of indent) and
some_variable = (spam('x')
+ ham(some_longer_variables,
here_and_here,
and_here_also))
as my second, even though they require an extra set of parentheses and
even though there is plenty of room on the first line for "foo +
foo(".
The reason I say I dislike the quoted suggestions -- and ultimately why
I really dislike the 80 character limit -- is the following. If you ask
proponents of the 80 character limit, they'll tell you about how there's
only so much horizontal space and stuff like that. But I think that
ignores the benefits you get from intelligently using *vertical* space,
and I think the quoted suggestions do too.
I've taken each of the suggested formattings of the above and turned
them into a graphic, which you can see at
http://pages.cs.wisc.edu/~driscoll/temp/indent.png
I've drawn the boundary of every valid subexpression (except for the RHS
of each assignment) in each of the versions. In my suggestions, the
"ham()" subexpression is always contained within a rectangle -- in
the quoted suggestions, it is not, and is a more complicated shape. It
seems to me that the relationship between the vertical and horizontal
layout in those examples is somewhat haphazard. I can't even come up
with a "rule" for how the quoted examples arose; for mine, I'd say I'm
trying to keep subexpressions together in space (both horizontal and
vertical). I'm not sure that "drawing boxes" is exactly the right thing
to say what I'm doing, but I think it at least serves to illustrate my
point in this case.
Evan
signature.asc
Description: OpenPGP digital signature
--
http://mail.python.org/mailman/listinfo/python-list
Re: The pty module, reading from a pty, and Python 2/3
Oh, and a little more information:
The log.txt file I create has the message that it's "about to execlp",
and the exec() *does* actually happen -- the IOError is raised after the
child process quits.
Evan
On 10/23/2012 09:59 PM, Evan Driscoll wrote:
I have the following program. Everything is sunshine and rainbows when
I run in in Python 2, but when I run it under Python 3 I get an
IOError. 2to3 only reports one dumb suggestion re. a print call (which
I can get rid of by importing __future__'s print_function, and then it
just suggests removing that import).
Can anyone shed any light? I am on Ubuntu Linux with Python 2.7.3 and
3.2.3.
(Just for the record, I figured out that it ran under Python 2 by
accident as I was reducing it for a "why doesn't this run?" email. :-)
I'm not super-familiar with Py3 as I've mostly only worked with 2.)
I'm not 100% sure how this will come through, so I've also put it at
http://pastebin.com/60wjXSF3.
Evan
import sys
import pty
import os
def get_text(filename):
try:
( child_pid, fd ) = pty.fork()# OK
except OSError as e:
print(str(e))
sys.exit(1)
if child_pid == 0:
try:
with open("log.txt", "w") as f:
f.write("about to execlp")
os.execlp("cat", "cat", filename)
except:
with open("log.txt", "w") as f:
f.write("could not spawn process")
print("Could not spawn")
sys.exit(1)
child_pty = os.fdopen(fd)
return child_pty.read()
if __name__ == "__main__":
print(get_text("my-pty-test.py"))
The read error I get is
Traceback (most recent call last):
File "my-pty-test.py", line 28, in
print(get_text("my-pty-test.py"))
File "my-pty-test.py", line 24, in get_text
return child_pty.read()
IOError: [Errno 5] Input/output error
--
http://mail.python.org/mailman/listinfo/python-list
The pty module, reading from a pty, and Python 2/3
I have the following program. Everything is sunshine and rainbows when I
run in in Python 2, but when I run it under Python 3 I get an IOError.
2to3 only reports one dumb suggestion re. a print call (which I can get
rid of by importing __future__'s print_function, and then it just
suggests removing that import).
Can anyone shed any light? I am on Ubuntu Linux with Python 2.7.3 and
3.2.3.
(Just for the record, I figured out that it ran under Python 2 by
accident as I was reducing it for a "why doesn't this run?" email. :-)
I'm not super-familiar with Py3 as I've mostly only worked with 2.)
I'm not 100% sure how this will come through, so I've also put it at
http://pastebin.com/60wjXSF3.
Evan
import sys
import pty
import os
def get_text(filename):
try:
( child_pid, fd ) = pty.fork()# OK
except OSError as e:
print(str(e))
sys.exit(1)
if child_pid == 0:
try:
with open("log.txt", "w") as f:
f.write("about to execlp")
os.execlp("cat", "cat", filename)
except:
with open("log.txt", "w") as f:
f.write("could not spawn process")
print("Could not spawn")
sys.exit(1)
child_pty = os.fdopen(fd)
return child_pty.read()
if __name__ == "__main__":
print(get_text("my-pty-test.py"))
The read error I get is
Traceback (most recent call last):
File "my-pty-test.py", line 28, in
print(get_text("my-pty-test.py"))
File "my-pty-test.py", line 24, in get_text
return child_pty.read()
IOError: [Errno 5] Input/output error
--
http://mail.python.org/mailman/listinfo/python-list
Re: The pty module, reading from a pty, and Python 2/3
OK, one more self-reply. :-)
I found http://bugs.python.org/issue5380 which seems to be relevant.
Sounds like the OS is returning an error, and that's naturally being
propagated through Python. And further testing reveals the problem only
surfaces when the child actually exits -- if the child writes data to
the pipe and is more enthusiastic about living, then the parent can read
it successfully. While it'd be nice if my example worked, for my actual
purpose I think that's good enough (I just won't be able to test *quite*
as easily for a while).
I am still curious if anyone know why it worked in 2 though.
Evan
On 10/23/2012 10:03 PM, Evan Driscoll wrote:
Oh, and a little more information:
The log.txt file I create has the message that it's "about to execlp",
and the exec() *does* actually happen -- the IOError is raised after
the child process quits.
Evan
On 10/23/2012 09:59 PM, Evan Driscoll wrote:
I have the following program. Everything is sunshine and rainbows
when I run in in Python 2, but when I run it under Python 3 I get an
IOError. 2to3 only reports one dumb suggestion re. a print call
(which I can get rid of by importing __future__'s print_function, and
then it just suggests removing that import).
Can anyone shed any light? I am on Ubuntu Linux with Python 2.7.3 and
3.2.3.
(Just for the record, I figured out that it ran under Python 2 by
accident as I was reducing it for a "why doesn't this run?" email.
:-) I'm not super-familiar with Py3 as I've mostly only worked with 2.)
I'm not 100% sure how this will come through, so I've also put it at
http://pastebin.com/60wjXSF3.
Evan
import sys
import pty
import os
def get_text(filename):
try:
( child_pid, fd ) = pty.fork()# OK
except OSError as e:
print(str(e))
sys.exit(1)
if child_pid == 0:
try:
with open("log.txt", "w") as f:
f.write("about to execlp")
os.execlp("cat", "cat", filename)
except:
with open("log.txt", "w") as f:
f.write("could not spawn process")
print("Could not spawn")
sys.exit(1)
child_pty = os.fdopen(fd)
return child_pty.read()
if __name__ == "__main__":
print(get_text("my-pty-test.py"))
The read error I get is
Traceback (most recent call last):
File "my-pty-test.py", line 28, in
print(get_text("my-pty-test.py"))
File "my-pty-test.py", line 24, in get_text
return child_pty.read()
IOError: [Errno 5] Input/output error
--
http://mail.python.org/mailman/listinfo/python-list
Re: Re: while expression feature proposal
On 10/24/2012 05:26 PM, Cameron Simpson wrote: > But I'm still -0 on it, because it supplants the glaringly obvious: > > m = ... > > assignment with the far less in your face: > > possibly-long-expr as m > > and I think it would get quite heavily used, to the detriment of > assignment readability in general. At present the nature of most effects > is at the left. An assignment is obvious on the left, an if/with/while/etc > is visible at the left. In the interest of brainstorming, what about while VAR from EXPR: or something like that? I don't think I like 'from' on a couple counts, but there's probably some word that fits. Evan signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Simple Python question for some
On 10/28/2012 7:18 PM, Chris Rebert wrote: > This is fixed in Python 3, where such nonsensical comparisons will > instead raise TypeError. It's worth pointing out that at least one kind of inequality comparison which some people (e.g. me) would consider nonsensical is still allowed in Python 3, which is between Boolean values and numbers: >>> True < 1 False >>> False < 1 True which is probably because >>> True == 1 True >>> False == 0 True Many people (probably most people, to be honest) disagree with me that this is wrong, but regardless of whether you like it or not you need to know what happens in such cases. On 10/28/2012 7:18 PM, Chris Angelico wrote: > Which means that strings will ALWAYS be compared as strings, and > numbers will ALWAYS be compared as numbers, and ne'er the twain shall > conflict. I can trust Python to compare MD5 hashes reliably: > >>>> "912128034267498495410681495015e0" !=00912128034267498495410681495015" > True > > Of course, I'm not pointing fingers at any other languages here, but > this is a known security hole in one rather widely-used one. If you are PerHaPs talking about the language I think you are, my favorite fact about that is I'm that I think a while back I saw a bug entry about something like that and they weren't sure how or even if it should be fixed. Evan -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Immutability and Python
On 10/29/2012 12:05 PM, andrea crotti wrote: > I meant how do I create new immutables classes myself, I guess that's > possible writing C extensions but I don't see in pure Python.. The short answer is: you don't, not really, except by using NamedTuple if that gives you what you want. The longer answer: You can kinda get it somewhat if you define your own __getattribute__/__setattribute__ functions. __setattribute__ of course should never do anything except raise an error (one way or another you'll need to make an exception for your __init__ function of course). __getattribute__ should make sure no mutable references are returned: e.g. you'll probably want to make it so someone can't side-step your setter by saying someobject.__dict__["foo"] = "bar". (I return a copy of the dict.) It will still be possible to bypass these protections though. To really get true immutability in pure Python, you'll have to inherit from tuple or NamedTuple (which inherits from tuple, I think). You can see some discussion on Stack Overflow and some other places about this; having played around with this a bit, I think it's not worth the hassle and have done the __getattribute__/__setattribute__ thing the couple of times I wanted immutability. Evan signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Managing multiple packages
I have perhaps a bit of a silly question, but I'm interested in what people do for workflow when actively developing multiple Python modules at once (for a single project). Suppose I have packages A-C. In addition to being modules in the Python sense, they are logically distinct, probably sit in different repositories, etc., so there's a directory layout like my_project/ +-- moduleA/ | +-- setup.py | +-- src/ | | +-- A/ | | +-- __init__.py | +-- doc/ | +-- how_to_be_awesome.md +-- moduleB/ | +-- setup.py | +-- src/ | +-- B/ | +-- __init__.py +-- moduleC/ +-- setup.py +-- src/ +-- C/ +-- __init__.py Finally, suppose that you're changing between editing all three modules. How do you deal with this? Do you set PYTHONPATH=my_project/moduleA/src:my_project/moduleB/src:my_project/moduleC/src, adding a new entry to PYTHONPATH for each module you need to use? Install all of the modules to some central location (e.g. my_project/install) and just point PYTHONPATH to there? Put symlinks in some central location and point them at the module directories? Mess with sys.path at the beginning of any scripts you want to run? Some other trick I don't know of? I've sort of tended to do the my_project/install thing, but it's pretty easy to forget to re-install a module after changing something, and possible to accidentally edit the copy of the file in the install directory (which will just be overwritten). Evan signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: 10 sec poll - please reply!
On 11/20/2012 05:46 PM, Alan Meyer wrote: On 11/20/2012 11:29 AM, mherrmann...@gmail.com wrote: > ... generate_keystrokes? ... Not bad. "gen_keystrokes", or even "keystrokes" might also do. I would emphatically vote "no" for "keystrokes". That's a noun, not a verb. What does it do? Tell you if its parameters are keystrokes? (gen_keystrokes is fine, though personally I'd probably stick with generate_keystrokes of the two.) Evan -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: How to get a "screen" length of a multibyte string?
On 11/25/2012 07:48 AM, kobayashi wrote: Encoding is utf-8. I use "screen length" means as that; that of ascii character is 1, and that of character having double width than ascii character is 2. It's not bytes, but drawing width. As you say, it depends font. I'll be considering carefully. Don't forget also that there are combining characters. To wit: >>> "\u00e1" 'á' >>> "\u0061\u0301" 'á' (U+00e1 is an 'a' with acute accent; U+0061 is an unaccented 'a'; U+0301 is an combining acute accent.) So far the discussion has been on single Unicode code points which appear as a double-wide glyph (I did not know about those!); depending on how you want to look at it, combining characters result in sequences of Unicode code points which result in a single glyph, or combining characters are zero-width code points. Evan -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Managing multiple packages
On 11/22/2012 06:22 PM, Thomas Bach wrote: I am using virtual environments and do a python setup.py develop on each package. This just creates a symbolic link to the package and all edits show up immediately. That's awesome; I didn't know about the 'develop' command. Thanks! Is that just a setuptools thing, or can you do it with distutils too? I didn't see anything too promising so I'm not so hopeful, but I figured I'd ask anyway. I'm also pretty confused about the distutils/setuptools/distribute/distutils2 landscape and what the differences are (at least between the first 3) and what their relationships with standard Python are. (I'd prefer to use distutils because (1) it ships with Python as opposed to being something extra to install (2) setuptools annoys me being the only think I can remember that, when you tell it to install to a prefix that doesn't exist, says "you want me to MAKE DIRECTORIES?! what are you, some kind of slave driver?!". Admittedly that second reason is not so rational and very occasionally putting up with that in exchange for development mode is plenty worth it, but being able to shun setuptools would make me feel good. :-)) Evan -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: re.search when used within an if/else fails
On 11/28/2012 01:57 PM, Ian Kelly wrote: > Yes, it's best to use either tabs-only or spaces-only. Quoting from PEP > 8 on the subject: > > Never mix tabs and spaces. > > The most popular way of indenting Python is with spaces only. The > second-most popular way is with tabs only. Code indented with a > mixture of tabs and spaces should be converted to using spaces > exclusively. When invoking the Python command line interpreter with > the -t option, it issues warnings about code that illegally mixes > tabs and spaces. When using -tt these warnings become errors. These > options are highly recommended! > > For new projects, spaces-only are strongly recommended over tabs. > Most editors have features that make this easy to do. > > > I thought the prohibition against mixing tabs and spaces was made more > strict in Python 3, but I can't find any reference to that now. > Probably I was mistaken. I'm only entering this thread now so I'm not really in context, but you're correct; in Python 3, -tt is set by default, which makes illegal mixing an error. However, not all mixing is illegal: what it means by "code that illegally mixes tabs and spaces" is "code whose interpretation differs depending upon the interpretation of the tab width". While I'm not going to go test it, I think that if you, say, indent from the first to the second level with tabs (consistently), indent from the second to third level with spaces (consistently), and indent from the third to fourth level with tabs (consistently), it should not complain. Or perhaps I should say "it should complain that you're a bad person and should feel bad, but it won't." :-) (In fact, you could indent one block at the second level with tabs and another with spaces.) Evan signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Iterating over files of a huge directory
On 12/17/2012 09:52 AM, Oscar Benjamin wrote: > In the last couple of months there has been a lot of discussion (on > python-list or python-dev - not sure) about creating a library to more > efficiently iterate over the files in a directory. The result so far > is this library on github: > https://github.com/benhoyt/betterwalk This is very useful to know about; thanks. I actually wrote something very similar on my own (I wanted to get information about whether each directory entry was a file, directory, symlink, etc. without separate stat() calls). I'm guessing that the library you linked is more mature than mine (I only have a Linux implementation at present, for instance) so I'm happy to see that I could probably switch to something better... and even happier that it sounds like it's aiming for inclusion in the standard library. (Also just for the record and anyone looking for other posts, I'd guess said discussion was on Python-dev. I don't look at even remotely everything on python-list (there's just too much), but I do skim most subject lines and I haven't noticed any discussion on it before now.) Evan signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Iterating over files of a huge directory
On 12/17/2012 01:50 PM, Oscar Benjamin wrote: > On 17 December 2012 18:40, Evan Driscoll wrote: >> On 12/17/2012 09:52 AM, Oscar Benjamin wrote: >>> https://github.com/benhoyt/betterwalk >> >> This is very useful to know about; thanks. >> >> I actually wrote something very similar on my own (I wanted to get >> information about whether each directory entry was a file, directory, >> symlink, etc. without separate stat() calls). > > The initial goal of betterwalk seemed to be the ability to do os.walk > with fewer stat calls. I think the information you want is part of > what betterwalk finds "for free" from the underlying OS iteration > (without the need to call stat()) but I'm not sure. Yes, that's my impression as well. >> (Also just for the record and anyone looking for other posts, I'd guess >> said discussion was on Python-dev. I don't look at even remotely >> everything on python-list (there's just too much), but I do skim most >> subject lines and I haven't noticed any discussion on it before now.) > > Actually, it was python-ideas: > http://thread.gmane.org/gmane.comp.python.ideas/17932 > http://thread.gmane.org/gmane.comp.python.ideas/17757 Thanks again for the pointers; I'll have to go through that thread. It's possible I can contribute something; it sounds like at least at one point the implementation was ctypes-based and is sometimes slower, and I have both a (now-defunct) C implementation and my current Cython module. Ironically I haven't actually benchmarked mine. :-) Evan signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Python lists
On 12/30/2012 4:19 PM, Hans Mulder wrote: > If it's okay to modify the original list, you can simply do: > > l[0] = split(l[0], ", ") > > If modifying the original is not okay, the simple solution would > be to copy it first: > > l2 = l > l2[0] = split(l2[0], ", ") Um, that doesn't copy the list: >>> l = ["C100, C117", "X7R ..."] >>> l2 = l >>> import string >>> l2[0] = string.split(l2[0], ", ") >>> l [['C100', 'C117'], 'X7R ...'] >>> l2 [['C100', 'C117'], 'X7R ...'] To make a copy of a list you can either use slice syntax (l2 = l[:]) or call the list constructor (l2 = list(l)). Evan > > > Hope this helps, > > -- HansM > > -- http://mail.python.org/mailman/listinfo/python-list
Re: wiki.python.org
On 01/09/2013 10:05 AM, Reed, Kevin wrote: > I have been unable to access wiki.python.org for two days. Is there a > problem with the server, or is it me? I can't speak to why, but it appears down for me as well. I also checked http://www.downforeveryoneorjustme.com/ (which is just about the best domain name ever) and it says it's down too. Evan signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Beginner Tutorials
On 1/18/2013 7:25 PM, Rick Johnson wrote: > Well anyone who is just blindly copying code to get through a CS > course is obviously not a "natural" problem solver ,and thus, > /incapable/ of becoming a proficient programmer anyhow. Programming > *IS* problem solving. If you don't get any thrill from the hunt, > you might as well go home and watch Monty python until your eyes > bleed or the next welfare check arrives. I have only skimmed this thread and so am unsure exactly what is being protected against casual copy/paste, but at least on its face I would *vehemently* disagree with your statement. There are at least two significant problems with it. First you ignore short-term pressures. It sounds like the tutorial in question is being used in some kind of course? If so, perhaps an assignment or two are badly timed with other life events (projects from other classes, external pressures, etc.) and, even though a person WOULD enjoy and be competent at solving the problem, those constraints pressure them to take the short-term "out" in the programming course, which also leads to them learning so much. But the bigger problem is that -- while you are right that programming is problem solving -- doing problem solving is probably not why most people got into it. At least personally, I got into it because I liked making stuff. If someone is attracted to the field because they go "oh hey I can program the next video game!" that doesn't automatically mean that they won't be good at it, but it may be that the problem-solving aspect of it is an acquired taste. As an analogy, I've been rock climbing for several years. There are several types of climbing; two of them are top roping, which is roped climbing and what you see most people in a climbing gym doing, and bouldering, which is climbing routes low to the ground (usually under 3 meters or so) without a rope. When I started, I basically exclusively did top roping. Bouldering seemed... dumb to me, like it was missing the point: "the reason you go climbing is to *climb*, and bouldering gives you very little of that." :-) But after I was going for a while, getting high above the ground became less of why I did it and the challenge of figuring out the right movements and such to complete the route started being my primary motivation for liking it. And those are things that bouldering has in fine measures; in some respects, it does that *better* than roped climbing*. (* Arguing about roped climbing vs bouldering might be that community's version of "Emacs is better than Vi". :-)) In other words, why I started climbing is very different from why I continued it. And I feel that the same could be said of programming. Just because you don't enjoy parts of programming when you're starting out doesn't mean that you're a lost cause by ANY means. Evan -- http://mail.python.org/mailman/listinfo/python-list
Re: Arent these snippets equivalent?
On 01/23/2013 03:56 PM, Coolgg wrote:
> Is this:
>
> while True:
> data = fp.read(4096)
> if not data:
> break
> ...
>
> not equivalent to this:
>
> data = fp.read (4096)
> while data:
> ...{handle the chunk here}
> data = fp.read (4096)
>
> Heres the article that sparked this question:
> http://wordaligned.org/articles/pythons-lesser-known-loop-control
There is at least one potentially-critical difference: what happens if
there is a 'continue' statement in the "..." part. The upper loop will
set data again, while the lower one will not.
So if what you mean is "are they equivalent no matter what legal Python
code you put in the ...", no, they aren't.
Evan
signature.asc
Description: OpenPGP digital signature
--
http://mail.python.org/mailman/listinfo/python-list
Re: while True or while 1
On 01/23/2012 11:39 AM, Ian Kelly wrote: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" -- Donald Knuth To play devil's advocate for a moment, if you have the choice between two ways of writing something, A and B, where both are basically the same in terms of difficulty to write, difficulty to maintain, and difficulty to understand, but A is faster than B, even if just by a hair, why NOT write A? It's like 'iter++' vs '++iter' in a C++ for loop. For ints, or for some iterators with optimization, it makes no difference. But the latter will be faster in debug builds, and *might* be faster in release builds if you have a complicated iterator. So why NOT make for(...; ...; ++i) the typical way of writing a for loop? In the Python world, is 'while 1' any harder to understand than 'while True'? I'm about as staunch a supporter as you'll find for the idea that 'while 1' should throw an exception, and even *I* think that 'while 1' is about the least-offensive idiom out there. If 'while 1' throws you off, I'd hate to see what you do when you learn that Python accepts loops like 'while x' where the condition evaluates to true if x is a non-zero integer and false if x is 0. All that said, I like the 'while "stuff to do"' idea. Evan -- http://mail.python.org/mailman/listinfo/python-list
Re: The devolution of English language and slothful c.l.p behaviors exposed!
On 1/23/2012 23:57, Rick Johnson wrote: > Of > course, "used to" and "supposed to" will require people to rethink > there lazy and slothful ways. I'll go repent in the corner, over their. signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Where to put data
I would just like to make a strong plea that you make it possible to install in places other than /usr. Bascially, 'python setup.py install --prefix /some/alternative/place' should work. Evan On 01/25/2012 11:26 AM, bvdp wrote: I'm having a disagreement with a buddy on the packaging of a program we're doing in Python. It's got a number of modules and large number of library files. The library stuff is data, not code. I'd like to put the modules in /usr/lib/pythonX.Y/mymodules or wherever setup.py decides. And the data in /usr/share/lib/myprogram. My buddy says, that it'll be hard to be consistant in the /usr/share/.. when we consider platforms other than linux. So, he wants: /usr/lib/pythonX.Y/myprogram mymodules ... mydata I've got 2 issues with this: 1. I don't know if putting data in the python tree is "legit". 2. I'd have to do a lot of rewritting. My modules currently use: include mymodules.foobar x=mymodules.foobar.func() and I would need to change that to: include myprogram.mymodules.foobar x=myprogram.mymodules.foobar.func() unless there is python way to drop the "myprogram" bit? -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python regular expression syntax is not intuitive.
On 1/25/2012 20:24, Devin Jeanpierre wrote: > If all you're going to change is the parser, maybe it'd be easier to > get things to coexist if parsers were pluggable in the re module. > > It's more generally useful, too. Would let re gain a PyParsing/SNOBOL > like expression "syntax", for example. Or a regular grammar syntax. > Neat for experimentation. I don't know what would be involved in that, but if it could be made to work, that sounds to me like a remarkably good idea to have come out of this thread. (Now it's time for my own troll: "About as good of an idea as no longer calling PCRE-alikes 'regular expressions', because they aren't." Ahhh, got that out of my system. :-)) Evan signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: copy on write
On 01/-10/-28163 01:59 PM, 8 Dihedral wrote: If you're working in C++ and overload your operators so that 'a +=' and 'a = + b' have different observable behaviors (besides perhaps time), then either your implementation is buggy or your design is very bad-mannered. Evan Do you mean the result instances after 'a+= and 'a=a+b' or the actions of behaviors of instances involved in performing 'a+= and 'a=a+b'? I mean "if which operation you called is distinguishable in any way besides the time it takes to run or by tracing it through in a debugger" That means: 1. The value of 'a' should be the same after executing 'a+=b' and 'a=a+b' 2. The actual result of the expression should be the same in both cases (in both cases it should be a reference to a) 3. Any additional side effects performed (ew!) should be the same in both cases Evan -- http://mail.python.org/mailman/listinfo/python-list
frozendict
Hi all, I've been trying for a few days (only a little bit at a time) to come up with a way of implementing a frozendict that doesn't suck. I'm gradually converging to a solution, but I can't help but think that there's some subtlety that I'm probably missing which is why it's not already provided. Does anyone know why Python doesn't already come with a frozendict, or why there seem to only be a couple attempts to write one? Evan signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: frozendict
On 13:59, Nathan Rice wrote: >> Turn the question around: why should there be? >> Python is intentionally parsimonious in adding builtins. > > For the same reason there are frozensets? > > I put dicts in sets all the time. I just tuple the items, but that > means you have to re-dict it on the way out to do anything useful with > it. I am too lazy to write a frozendict or import one, but I would > use it if it was a builtin. I've wanted to do that as well. My current use case is I want to have a dict as an attribute of another object, and I want to use that object as a key in a dictionary. That means that the outer object has to be immutable (an obnoxious enough task on its own, BTW) and that either the dict itself has to be excluded from computing the hash or the dict also has to be immutable. Also, it's not like it has to be a builtin, per se. I know how to spell 'import'. :-) Evan signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: frozendict
On 13:59, Ian Kelly wrote: > > Define "doesn't suck". If I were to hack one up, it would look > something like this: > > > from collections import Mapping, Hashable So part of my objection was that I wanted to make sure I got all of the expected functionality, and that takes a bunch of functions. I didn't know about the ABTs in 'collections' though, so that helps a bit. However, I'd still prefer something that guaranteed immutability better than that. I might just be fighting the language too much at that point though... Evan signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: lang comparison: in-place algorithm for reversing a list in Perl, Python, Lisp
On 2/29/2012 23:05, Dan Stromberg wrote:
>
> On Wed, Feb 29, 2012 at 8:07 PM, Xah Lee <mailto:xah...@gmail.com>> wrote:
>
> This page tells you what's “In-place algorithm”, using {python, perl,
> emacs lisp} code to illustrate.
>
> Aren't in-place reversals rather non-functional?
There is one place where they're reasonably idiomatic in Lispy
languages, at least by my understanding. That occurs when you are
writing a function that returns a list and there is a natural recursive
way to build up the answer -- but backwards. The idiom then is to build
up a temporary list up backwards, then call an in-place reversal
function. (NREVERSE in Common Lisp. I thought there was a reverse! in
Scheme, but apparently not.)
This doesn't break the external view of a pure function because the list
that's being reversed is a fresh, temporary list, which is why this
idiom would even fit in pretty well in Scheme.
Evan
signature.asc
Description: OpenPGP digital signature
--
http://mail.python.org/mailman/listinfo/python-list
Re: RE: What's the best way to write this regular expression?
On 01/-10/-28163 01:59 PM, Prasad, Ramit wrote: gz stands for gzip and is a form of compression (like rar/zip ). tar stands for a tape archive. It is basically a box that holds the files. So you need to "unzip" and then "open the box". Normally programs like WinZip / WinRar / 7-zip will do both in one step so you do not need to. Not sure what program you are using... I'm not sure what 7-zip you're referring to, because I use 7-zip and it's always been a two-step process for me... (Though I can't say I've looked through the preferences dialog for a "extract .tar.gz files in one go" setting.) Evan -- http://mail.python.org/mailman/listinfo/python-list
Re: Programming D. E. Knuth in Python with the Deterministic Finite Automaton construct
On 3/17/2012 9:03, Antti J Ylikoski wrote: > > In his legendary book series The Art of Computer Programming, > Professor Donald E. Knuth presents many of his algorithms in the form > that they have been divided in several individual phases, with > instructions to GOTO to another phase interspersed in the text of the > individual phases. > > > A1. (Do the work of Phase A1.) If then go to Phase A5, > otherwise continue. > > A2. (Do some work.) If go to Phase A4. > > A3. (Some more work.) > > A4. (Do something.) If go to Phase A1. > > A5. (Something more). If then go to Phase A2, otherwise > end. Clearly you just need the goto module (http://entrian.com/goto/): from goto import goto, label label .A1 # do work of phase A1 if : goto .A5 label .A2 # do some work if : goto .A4 # do some more work label .A4 # do something if : goto .A1 label .A5 # something more if : goto .A2 Clearly the best solution of all. (Note: do not actually do this.) Evan signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Python is readable
On 01/-10/-28163 01:59 PM, Steve Howell wrote: Code shouldn't necessarily follow the example of English prose, but it seems that English has had some influence: 1 push(stack, item) # Push on the stack the item 2 push(item, stack) # Push the item on the stack 3 stack.push(item) # On the stack, push the item 4 stack item push # On the stack, take the item and push it 5 item stack push # Take the item and on the stack, push the former. 6 item push stack # Take the item; push it on the stack. The first three ways are the most common ways of arranging the grammar in mainstream programming languages, and they are also the three most natural ways in English (no pronouns required). #1/2 are imperative. #3 is OO. In my opinion, people who make statements such as "#1/2 are imperative, #3 is OO" are missing pretty much the entire point of what OO is. OO is much more about semantics and the way code is structured. The difference between #1/2 (especially #1, of course) and #3 is surface-level syntax only. About the strongest statement you can make along those lines is that #3 will allow you to do dynamic dispatch on the type of 'stack' while #1/2 won't, but even that isn't true of course. For instance, CLOS will let you write '(push stack item)' (which is the direct analogy in that language to #1) and do even more powerful dynamic dispatch than what a language like C++, Java, or Python will let you do. Evan -- http://mail.python.org/mailman/listinfo/python-list
Re: RE: Advise of programming one of my first programs
On 01/-10/-28163 01:59 PM, Prasad, Ramit wrote:
### CODE #
fileread = open('myfile.txt','r')
tbook = eval(fileread.read())
fileread.close()
The use of eval is dangerous if you are not *completely* sure what is
being passed in. Try using pickle instead:
http://docs.python.org/release/2.5.2/lib/pickle-example.html
Um, at least by my understanding, the use of Pickle is also dangerous if
you are not completely sure what is being passed in:
Warning: The pickle module is not intended to be secure
against erroneous or maliciously constructed data. Never
unpickle data received from an untrusted or unauthenticated
source.
- http://docs.python.org/library/pickle.html
Evan
--
http://mail.python.org/mailman/listinfo/python-list
Re: Re: "convert" string to bytes without changing data (encoding)
On 01/-10/-28163 01:59 PM, Ross Ridge wrote: Steven D'Aprano wrote: The right way to convert bytes to strings, and vice versa, is via encoding and decoding operations. If you want to dictate to the original poster the correct way to do things then you don't need to do anything more that. You don't need to pretend like Chris Angelico that there's isn't a direct mapping from the his Python 3 implementation's internal respresentation of strings to bytes in order to label what he's asking for as being "silly". That mapping may as well be: def get_bytes(some_string): import random length = random.randint(len(some_string), 5*len(some_string)) bytes = [0] * length for i in xrange(length): bytes[i] = random.randint(0, 255) return bytes Of course this is hyperbole, but it's essentially about as much guarantee as to what the result is. As many others have said, the encoding isn't defined, and I would guess varies between implementations. (E.g. if Jython and IronPython use their host platforms' native strings, both have 16-bit chars and thus probably use UTF-16 encoding. I am not sure what CPython uses, but I bet it's *not* that.) It's even guaranteed that the byte representation won't change! If something is lazily evaluated or you have a COW string or something, the bytes backing it will differ. So yes, you can say that pretending there's not a mapping of strings to internal representation is silly, because there is. However, there's nothing you can say about that mapping. Evan -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Re: "convert" string to bytes without changing data (encoding)
On 3/28/2012 14:43, Ross Ridge wrote: > Evan Driscoll wrote: >> So yes, you can say that pretending there's not a mapping of strings to >> internal representation is silly, because there is. However, there's >> nothing you can say about that mapping. > > I'm not the one labeling anything as being silly. I'm the one labeling > the things as bullshit, and that's what you're doing here. I can in > fact say what the internal byte string representation of strings is any > given build of Python 3. Just because I can't say what it would be in > an imaginary hypothetical implementation doesn't mean I can never say > anything about it. People like you -- who write to assumptions which are not even remotely guaranteed by the spec -- are part of the reason software sucks. People like you hold back progress, because system implementers aren't free to make changes without breaking backwards compatibility. Enormous amounts of effort are expended to test programs and diagnose problems which are caused by unwarranted assumptions like "the encoding of a string is UTF-8". In the worst case, assumptions like that lead to security fixes that don't go as far as they could, like the recent discussion about hashing. Python is definitely closer to the "willing to break backwards compatibility to improve" end of the spectrum than some other projects (*cough* Windows *cough*), but that still doesn't mean that you can make assumptions like that. This email is a bit harsher than it deserves -- but I feel not by much. Evan -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Re: Re: "convert" string to bytes without changing data (encoding)
On 01/-10/-28163 01:59 PM, Ross Ridge wrote: Evan Driscoll wrote: People like you -- who write to assumptions which are not even remotely guaranteed by the spec -- are part of the reason software sucks. ... This email is a bit harsher than it deserves -- but I feel not by much. I don't see how you could feel the least bit justified. Well meaning, if unhelpful, lies about the nature Python strings in order to try to convince someone to follow what you think are good programming practices is one thing. Maliciously lying about someone else's code that you've never seen is another thing entirely. I'm not even talking about code that you or the OP has written. I'm talking about your suggestion that I can in fact say what the internal byte string representation of strings is any given build of Python 3. Aside from the questionable truth of this assertion (there's no guarantee that an implementation uses one consistent encoding or data structure representation consistently), that's of no consequence because you can't depend on what the representation is. So why even bring it up? Also irrelevant is: In practice the number of ways that CPython (the only Python 3 implementation) represents strings is much more limited. Pretending otherwise really isn't helpful. If you can't depend on CPython's implementation (and, I would argue, your code is broken if you do), then it *is* helpful. Saying that "you can just look at what CPython does" is what is unhelpful. That said, looking again I did misread your post that I sent that harsh reply to; I was looking at it perhaps a bit too much through the lens of the CPython comment I said above, and interpreting it as "I can say what the internal representation is of CPython, so just give me that" and launched into my spiel. If that's not what was intended, I retract my statement. As long as everyone is clear on the fact that Python 3 implementations can use whatever encoding and data structures they want, perhaps even different encodings or data structures for equal strings, and that as a consequence saying "what's the internal representation of this string" is a meaningless question as far as Python itself is concerned, I'm happy. Evan -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: string interpolation for python
On 01/-10/-28163 01:59 PM, Yingjie Lan wrote:
Because of the d"..." format, it won't
affect old ways of doing things one bit.
Allowing dynamic string wouldn't hurt
a bit to anything that is already there.
Why don't you just write a function that does it? I think someone
already suggested this...
import dynamic_strings # write this
d = dynamic_strings.dynamic
x = 5
print(d("x=$x$"))
?
Sure, it's not *quite* as pretty as if you could just say d"x=$x$", and
you might have to do some hacky uglyness in the implementation to get at
the locals of the calling procedure, but it solves a bazillion problems,
such as:
1. YOU can do it, instead of hoping it gets into the mainline
interpreter
2. You can do it NOW, and it will work with "any" version of Python
3. You have the freedom to easily add "eval from *this dictionary* if
you want, which solves Steven D'Aprano's objection that your
suggestion is too weak.
4. Languages changes should be viewed suspiciously in general.
Evan
--
http://mail.python.org/mailman/listinfo/python-list
Re: Re: No os.copy()? Why not?
On 01/-10/-28163 01:59 PM, Tycho Andersen wrote: Note, though, that this reads the whole file into memory. As many others have said, shutil is the most idiomatic option. * most idiomatic * clearest in terms of showing intent * potentially fastest * hardest to screw up (unlike concatenating file names into a 'system' call) * has at least a snowball's chance of persisting metadata associated with the file (even if shutil doesn't now, it could theoretically change) * portable There's basically nothing NOT to like about shutil, and at least one significant problems with all the other suggestions. Evan -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Python Gotcha's?
On 4/5/2012 13:24, Chris Angelico wrote: > I think this example highlights a major point about gotchas: the > difference between an obvious language feature and a gotcha depends on > where you come from. To a PHP programmer, 1 and "1" are in many ways > indistinguishable. To a C programmer, they're utterly incompatible. I think I agree with this. For instance, I'd consider the fact that this works in Python to be a gotcha: >>> 1 < "abc" True But that's because I like more strongly-typed systems. [I'm most decidedly not trying to start up that discussion again...] This is changed in Python 3: >>> 1 < "abc" Traceback (most recent call last): File "", line 1, in TypeError: unorderable types: int() < str() though you can still compare *some* types I consider logically unorderable: >>> 0 < True True I think it also has bearing on the ' vs " issue. For instance, I totally think it's not at all surprising that one can be accepted and the other not, or that they behave differently. (Though I *do* find it surprising in the context of JSON given that JS apparently allows either.) Evan signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Re: Python Gotcha's?
On 4/5/2012 13:44, Michael Hrivnak wrote: > This is not a gotcha, and it's not surprising. As John described, > you're assigning a new value to an index of a tuple, which tuples > don't support. Um, at least for me personally, yes, it is surprising, and yes, it is a gotcha. This goes back to what languages you're used to. I come from a strong C++ background. In C++, something like mytuple[0] += [3] would wind up calling 'operator+=' on the list, that += would mutate the list, and then the expression would be done. The C++ approach doesn't really work with Python because more stuff is immutable, and Python's behavior is arguably the least-bad solution, but it WAS definitely surprising for me (and others!) when I learned about Python's behavior. In particular, the translation of 'a+=b' to 'temp = a + b; a = temp' is *not* a very natural one to me. Evan > > Michael > > On Thu, Apr 5, 2012 at 10:15 AM, John Posner wrote: >> On 4/4/2012 7:32 PM, Chris Angelico wrote: >>> Don't know if it's what's meant on that page by the +=perator, >> >> Yes, it is. >> >>>> a=1],) >>>> a[0].append(2) # This is fine >> >> [In the following, I use the term "name" rather loosely.] >> >> The append() method attempts to modify the object whose name is "a[0]". >> That object is a LIST, so the attempt succeeds. >> >>>> a[0]+=] # This is not. >> >> The assignment attempts to modify the object whose name is "a". That >> object is a TUPLE, so the attempt fails. This might be a surprise, but >> I'm not sure it deserves to be called a wart. >> >> Note the similarity to: >> >> temp =[0] + [3] # succeeds >> a[0] =emp # fails >> >> -John >> >> >> >> >> -- >> http://mail.python.org/mailman/listinfo/python-list > signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Gotcha's?
On 4/5/2012 17:11, Evan Driscoll wrote: > In particular, the translation of 'a+=b' to 'temp = a + b; a = temp' is > *not* a very natural one to me. To expand on this point slightly, because of common C++ idioms guided by efficiency, I would be much more likely to think of 'a + b' as 'temp = a, temp += b, temp' than the Python way: in other words, to the extent that I think of += and + being implemented in terms of each other, I think of + as being implemented via +=. Evan signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Python one-liner?
I have a function 'f' and a list 'l'. I want a dictionary where the keys
are evaluations of 'f(thing from l)' and the values are lists of stuff
from 'l' that matches. So for instance, if 'f = lambda x: x%3' and
'l=range(9)', then I want { 0: [0,3,6], 1:[1,4,7], 2:[2,5,8]}.
I can do that with an explicit loop, or with this suggestion (untested)
d = {}
def appender(e):
d.get(f(e), []).append(e)
map(appender, l)
but I was wondering if there's some prettier way to do it with some
fancy dictionary comprehension or itertools expression or something. At
this point I'm asking mostly out of curiosity and less for some code to
actually use, so either Python 2 or 3 is acceptable (but I'm writing in
3 at the moment).
Evan
signature.asc
Description: OpenPGP digital signature
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python one-liner?
On 4/13/2012 22:33, Evan Driscoll wrote:
> d = {}
> def appender(e):
> d.get(f(e), []).append(e)
> map(appender, l)
Just in case it isn't clear, the above has at least two problems and
won't even come close to working. :-)
Though I might as well ask another question... if I have a dict with
values which are lists, what's a good way to say "append x to the list
at key k, creating a list if it's not there"? dict.setdefault seems
potentially promising but the docs are crappy and don't say how it works.
Evan
signature.asc
Description: OpenPGP digital signature
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python one-liner?
On 4/13/2012 22:42, Evan Driscoll wrote: > Though I might as well ask another question... if I have a dict with > values which are lists, what's a good way to say "append x to the list > at key k, creating a list if it's not there"? dict.setdefault seems > potentially promising but the docs are crappy and don't say how it works. Ha ha, sorry I can't read right now apparently. dict.setdefault does exactly what I wanted. (The name just prompted another interpretation in my mind which doesn't work and I got tunnel vision. I'll stop spamming now, and we return to your regularly scheduled broadcast.) Evan signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: How do you refer to an iterator in docs?
On 4/20/2012 22:01, Roy Smith wrote: > A basket of apples is a basket which contains apples, in the same way a > list contains foos. But an iterator doesn't contain anything. You > wouldn't say, "a spigot of water", because the spigot isn't a container > holding the water. It is simply a mechanism for delivering the water in > a controlled way. You would, however, say "water spigot". If you apply that analogy, maybe "Foo iterator" is reasonable. (I didn't read the whole thread so maybe someone suggested this already, or dismissed it.) Personally though, I'd probably say an iterator *to* Foos. Evan signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: why () is () and [] is [] work in other way?
This thread has already beaten a dead horse enough that the horse came
back as a zombie and was re-killed, but I couldn't help but respond to
this part:
On 01/-10/-28163 01:59 PM, Adam Skutt wrote:
Code that relies on the identity of a temporary object is generally
incorrect. This is why C++ explicitly forbids taking the address
(identity) of temporaries.
Except that C++ *doesn't* really forbid taking the address of a
temporary, at least indirectly:
#include
int const * address_of(int const & x) {
return &x;
}
int main() {
std::cout << address_of(1+2) << "\n";
}
That complies without warning with GCC 4.6 '-Wall -Wextra', MSVC 2010
'/W4', and Comeau's online front end, and I am pretty confident that the
above code is perfectly legal in terms of provoking undefined behavior
(in the technical C++ sense of "your program is now allowed to set your
cat on fire").
Evan
--
http://mail.python.org/mailman/listinfo/python-list
Re: using identifiers before they are defined
On 01/-10/-28163 01:59 PM, Julio Sergio wrote: I know that changing the order of the definitions will work, however there are situations in which referring to an identifier before it is defined is necessary, e.g., in crossed recursion. Mutual recursion isn't a problem: the following strange expression of factorial works fine: def strange_helper(x): return factorial(x) def factorial(x): if x==0: return 1 else: return x * strange_helper(x-1) print factorial(5) The reason is names are never looked up when the parser sees them, but rather only when execution reaches them. So the fact that 'factorial' hasn't been defined yet when the parser is dealing with 'strange_helper' is fine, because when 'strange_helper' is actually *called*, 'factorial' has been defined. Here's another example to illustrate, in a different manner that doesn't use this "undefined" thing: def foo(): print "Inside the first version of foo" def call_foo(): foo() call_foo() def foo(): print "Inside the second version of foo" call_foo() This prints: Inside the first version of foo Inside the second version of foo Evan -- http://mail.python.org/mailman/listinfo/python-list
Re: Mutating an HTML file with BeautifulSoup
I've had much success doing round trips through the lxml.html parser. https://lxml.de/lxmlhtml.html I ditched bs for lxml long ago and never regretted it. If you find that you have a bunch of invalid html that lxml inadvertently "fixes", I would recommend adding a stutter-step to your project: perform a noop roundtrip thru lxml on all files. I'd then analyze any diff by progressively excluding changes via `grep -vP`. Unless I'm mistaken, all such changes should fall into no more than a dozen groups. On Fri, Aug 19, 2022, 1:34 PM Chris Angelico wrote: > What's the best way to precisely reconstruct an HTML file after > parsing it with BeautifulSoup? > > Using the Alice example from the BS4 docs: > > >>> html_doc = """The Dormouse's story > > The Dormouse's story > > Once upon a time there were three little sisters; and > their names were > http://example.com/elsie"; class="sister" id="link1">Elsie, > http://example.com/lacie"; class="sister" id="link2">Lacie and > http://example.com/tillie"; class="sister" id="link3">Tillie; > and they lived at the bottom of a well. > > ... > """ > >>> print(soup) > The Dormouse's story > > The Dormouse's story > Once upon a time there were three little sisters; and > their names were > http://example.com/elsie"; id="link1">Elsie, > http://example.com/lacie"; id="link2">Lacie and > http://example.com/tillie"; id="link3">Tillie; > and they lived at the bottom of a well. > ... > > >>> > > Note two distinct changes: firstly, whitespace has been removed, and > secondly, attributes are reordered (I think alphabetically). There are > other canonicalizations being done, too. > > I'm trying to make some automated changes to a huge number of HTML > files, with minimal diffs so they're easy to validate. That means that > spurious changes like these are very much unwanted. Is there a way to > get BS4 to reconstruct the original precisely? > > The mutation itself would be things like finding an anchor tag and > changing its href attribute. Fairly simple changes, but might alter > the length of the file (eg changing "http://example.com/"; into > "https://example.com/";). I'd like to do them intelligently rather than > falling back on element.sourceline and element.sourcepos, but worst > case, that's what I'll have to do (which would be fiddly). > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On Thu, Feb 11, 2021 at 1:49 PM dn via Python-list wrote: > When I first met it, one of the concepts I found difficult to 'wrap my > head around' was the idea that "open software" allowed folk to fork the > original work and 'do their own thing'. My thinking was (probably) > "surely, the original is the authoritative version". Having other > versions seemed an invitation to confusion and dilution. > > However, as soon as (open) software is made available, other people > start making it 'better' - whatever their own definition of "better". > > Yes, it is both a joy and a complication. > > ... > > Wishing you well. It seems (to (neos-ignorant) me at least) an ambitious > project. There are certainly times when 'execution speed' becomes a > major criteria. Many of us will look forward to (your development of) a > solution. Please let us know when it's ready for use/trials... > Well put! Thank you for this thoughtful and informative message. You obviously put substantial work into it. -- https://mail.python.org/mailman/listinfo/python-list
Explicit vararg values
I started to send this to python-ideas, but I'm having second thoughts.
Does tihs have merit?
---
I stumble on this a lot, and I see it in many python libraries:
def f(*args, **kwargs):
...
f(*[list comprehension])
f(**mydict)
It always seems a shame to carefully build up an object in order to explode
it, just to pack it into a near-identical object.
Today I was fiddling with the new python3.7 inspect.signature functionality
when I ran into this case:
def f(**kwargs): pass
sig = inspect.signature(f)
print(sig.bind(a=1, b=2))
The output is "". I found this a
bit humorous since anyone attempting to bind values in this way, using
f(kwargs={'a': 1, 'b': 2}) will be sorely dissappointed. I also wondered
why BoundArguments didn't print '**kwargs' since that's the __str__ of that
parameter object.
The syntax I'm proposing is:
f(**kwargs={'a': 1, 'b': 2})
as a synonym of f(a=1, b=2) when an appropriate dictionary is already on
hand.
---
I can argue for this another way as well.
1)
When both caller and callee have a known number of values to pass/receive,
that's the usual syntax:
def f(x) and f(1)
2)
When the caller has a fixed set of values, but the callee wants to handle a
variable number: def f(*args) and f(1)
3)
Caller has a variable number of arguments (varargs) but the call-ee is
fixed, that's the splat operator: def f(x) and f(*args)
4)
When case 1 and 3 cross paths, and we have a vararg in both the caller and
callee, right now we're forced to splat both sides: def f(*args) and
f(*args), but I'd like the option of opting-in to passing along my list
as-is with no splat or collection operations involved: def f(*args) and
f(*args=args)
Currently the pattern to handle case 4 neatly is to define two versions of
a vararg function:
def f(*arg, **kwargs):
return _f(args, kwargs)
return _f(args, kwargs):
...
Such that when internal calllers hit case 4, there's a simple and efficient
way forward -- use the internal de-vararg'd definition of f. External
callers have no such option though, without breaking protected api
convention.
My proposal would simplify this implementation as well as allowing users to
make use of a similar calling convention that was only provided privately
before.
Examples:
log(*args) and _log(args) in logging.Logger
format and vformat of strings.Formatter
--
https://mail.python.org/mailman/listinfo/python-list
Re: Explicit vararg values
Received?
On Sun, Sep 16, 2018 at 3:39 PM Buck Evan wrote:
> I started to send this to python-ideas, but I'm having second thoughts.
> Does tihs have merit?
>
> ---
> I stumble on this a lot, and I see it in many python libraries:
>
> def f(*args, **kwargs):
> ...
>
> f(*[list comprehension])
> f(**mydict)
>
> It always seems a shame to carefully build up an object in order to
> explode it, just to pack it into a near-identical object.
>
> Today I was fiddling with the new python3.7 inspect.signature
> functionality when I ran into this case:
>
> def f(**kwargs): pass
> sig = inspect.signature(f)
> print(sig.bind(a=1, b=2))
>
> The output is "". I found this a
> bit humorous since anyone attempting to bind values in this way, using
> f(kwargs={'a': 1, 'b': 2}) will be sorely dissappointed. I also wondered
> why BoundArguments didn't print '**kwargs' since that's the __str__ of that
> parameter object.
>
> The syntax I'm proposing is:
>f(**kwargs={'a': 1, 'b': 2})
>
> as a synonym of f(a=1, b=2) when an appropriate dictionary is already on
> hand.
>
> ---
> I can argue for this another way as well.
>
> 1)
> When both caller and callee have a known number of values to pass/receive,
> that's the usual syntax:
> def f(x) and f(1)
>
> 2)
> When the caller has a fixed set of values, but the callee wants to handle
> a variable number: def f(*args) and f(1)
>
> 3)
> Caller has a variable number of arguments (varargs) but the call-ee is
> fixed, that's the splat operator: def f(x) and f(*args)
>
> 4)
> When case 1 and 3 cross paths, and we have a vararg in both the caller and
> callee, right now we're forced to splat both sides: def f(*args) and
> f(*args), but I'd like the option of opting-in to passing along my list
> as-is with no splat or collection operations involved: def f(*args) and
> f(*args=args)
>
> Currently the pattern to handle case 4 neatly is to define two versions of
> a vararg function:
>
> def f(*arg, **kwargs):
> return _f(args, kwargs)
>
> return _f(args, kwargs):
> ...
>
> Such that when internal calllers hit case 4, there's a simple and
> efficient way forward -- use the internal de-vararg'd definition of f.
> External callers have no such option though, without breaking protected api
> convention.
>
> My proposal would simplify this implementation as well as allowing users
> to make use of a similar calling convention that was only provided
> privately before.
>
> Examples:
>
> log(*args) and _log(args) in logging.Logger
> format and vformat of strings.Formatter
>
--
https://mail.python.org/mailman/listinfo/python-list
Binary Sort on Python List __xor__
I frequently use binary as bool placeholders and find myself filtering lists based on those bools, this seems to have a similar semantic meaning as the bit wise ^ or __xor__ operator and could add syntactic sugar to the base list class. Use Case: Controlling a stepper at half-step has the following cycle steps: CYCLE = [ [1,0,0,0], [1,1,0,0], [0,1,0,0], [0,1,1,0], [0,0,1,0], [0,0,1,1], [0,0,0,1], [1,0,0,1], ] which can be represented as follows: CYCLE = [ 1<<3, 1<<3|1<<2, 1<<2, 1<<2|1<<1, 1<<1, 1<<1|1<<0, 1<<0, 1<<3|1<<0 ] or more cleanly: CYCLE = [8, 12, 4, 6, 2, 3, 1, 9] on a raspberrypi, using (for illustration's sake) GPIO pins 1,2,3,4 I'd like to use the __xor__ method (currently not implemented) to perform the bit-wise filter as follows: class MyList(list): def __init__(self, *args): super().__init__(args) def __xor__(self, num): return [self[i] for i in [-index-1 for index, i in enumerate(bin(num)[:1:-1]) if i !='0']][::-1] PINS = MyList(1,2,3,4) PINS ^ 8 # [1] PINS ^ 12 # [1, 2] PINS ^ 4 # [2] PINS ^ 6 # [2, 3] PINS ^ 2 # [3] PINS ^ 3 # [3, 4] PINS ^ 1 # [4] PINS ^ 9 # [1, 4] The need here isn't strictly pi/stepper related; I've run into this several times in the past when evaluating combinations * permutations of items where a bitwise filter would be useful. -- https://mail.python.org/mailman/listinfo/python-list
