Re: Using non-dict namespaces in functions
Steven D'Aprano wrote: > On Sat, 17 Mar 2012 11:42:49 -0700, Eric Snow wrote: > >> On Sat, Mar 17, 2012 at 4:18 AM, Steven D'Aprano >> wrote: >>> Note that it is important for my purposes that MockChainMap does not >>> inherit from dict. >> >> Care to elaborate? > > I want to use collections.ChainMap, or something very like it, and I > don't want to be forced into an unnatural is-a relationship with dict if > I don't have to. > > > [...] >> Regardless, you could also implement __call__() on a function look-alike >> class to get what you're after. It may not be as performant though. > > I don't think that can work, because __call__ itself is a function, and I > would need to change *its* globals. Which brings me back exactly where I > started, trying to change globals in a function to a non-dict. The key lookup code in ceval.c is inlined, so even subclassing dict and overriding __getitem__() won't help. Instead of def f(a): return a + b # b taken from some custom namespace you have to resort to the conventional approach def f(a, ns=magic()): return a + ns["b"] or def f(self, a): return a + self.b -- http://mail.python.org/mailman/listinfo/python-list
Re: How to get a reference of the 'owner' class to which a method belongs in Python 3.X?
I think I got the way to handle it but with small problem and probably at
unnecessary performance cost. If you're going to use it, be sure rewrite the
code and remove the lines which you don't need. Ad, test them, the code
below is only tested on py3.2, and may contains a lot of bugs even in py3.2.
You don't need it in py2.X, really.
--BEGIN PYTHON--
from functools import wraps
from types import FunctionType
CLASS_REF = 'im_class'
class Py2Type(type):
def __init__(cls, name, bases, dict_):
for k, v in dict_.items(): #ref3
if isinstance(v, FunctionType):
setattr(v, CLASS_REF, cls)
for base in bases:
for k, v in base.__dict__.items():
if isinstance(v, FunctionType) and k not in dict_:
@wraps(v)
def wrapper(*args, **kwargs):
return v(*args, **kwargs)
setattr(wrapper, CLASS_REF, cls)
dict_[k] = wrapper
setattr(cls, k, wrapper) #ref1
type.__init__(cls, name, bases, dict_) #ref2
Py2TypeBase = Py2Type('Py2TypeBase', (object, ), {})
---END PYTHON---
And any class inherit(directly or indirectly) from Py2TypeBase can have them
unbound method has a 'im_class' attribute reference to the owner class.
Usage:
Just subclass Py2TypeBase and write anything you want.
--BEGIN PYTHON--
class Foo(Py2TypeBase):
def get(self): pass
def set(self): pass
class Bar(Foo):
def get(self): pass
assert Foo.get.im_class is Foo
assert Foo.set.im_class is Foo
assert Bar.get.im_class is Bar
assert Bar.set.im_class is Bar
# the code above works, but only the explicitly defined will has the
# im_class attribute, so
assert Foo.__init__.im_class is Foo # this doesn't work.
---END PYTHON---
But it seems that the last line(#ref2) in the Py2Type.__init__ does not work at
all. It seems really weird, 'type' is an instance of 'type' itself, I'm not sure
if I'm calling the unbound method __init__ or bound method __init__.
And the original code does not have the line(#ref1), but because line(#ref2)
does not work, I added them.
It seems type.__new__ calls type.__init__ before it calls Py2Type.__init__,
because dict_ is already copied to cls.__dict__ at line(#ref3).
But 'type' is written in C or some other, it's beyond my ability to read the
code. Can anyone tell me what python does when a class block is fully evaluated
kindly?
Regards,
Cosmia
--
http://mail.python.org/mailman/listinfo/python-list
Re: Programming D. E. Knuth in Python with the Deterministic Finite Automaton construct
In article <4f654042$0$29981$c3e8da3$54964...@news.astraweb.com>, Steven D'Aprano wrote: >On Sat, 17 Mar 2012 17:28:38 -0600, Michael Torrie wrote: > >> Thank you. Your example makes more clear your assertion about "labels" >> and how really A1 and A5 were the only real labels in the example. >> Though I still do not really see why "states" is not a good equivalence >> for labels in this case. > >Program labels are states. > >You can treat every line of code as being invisibly labelled with the >line number. (Or visibly, if you are using BASIC back in 1975.) Clearly >"the interpreter is executing at line 42" is a state distinct from "the >interpreter is executing line 23", but that state *alone* is not >sufficient to know the overall state of the program. This is the idea of the original (not universal, hard coded) Turing machine with cards. Of course you then still need the infinite tape to store calculation input and output. > >Adding an explicit GOTO label does not change this. > >But this refers to the state of the interpreter, not the state of the >program being executed, and either way, is not a state in the sense of a >finite state machine. I hope the reference to the Turing machine makes this clearer. Turing Machines and Finite State Machines are different constructions in automaton theory. Remember those definitions are like A Turing machine is a set S the set of symbols T a mapping of S onto IZ (natural numbers) ... F is a mapping from SxT into G .. Some such. (A FSM is just different with different mappings ) The memory of the Turing machine is T , the tape, time dependant. The program of the Turing is e.g. F, to be thought of as hard wiring. A Turing machine is *not* a stored program computer! The universal Turing machine is, it contains a hardwired program to execute a stored program on the tape. > >-- >Steven Groetjes Albert -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst -- http://mail.python.org/mailman/listinfo/python-list
Re: Programming D. E. Knuth in Python with the Deterministic Finite Automaton construct
In article , 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. > > > >I. e. they look like the following, purely invented, example: (Knuth is >being clearer than me below.) > > > >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. I can rewrite this into Python in my sleep, without resorting to formal techniques. Instead try one of the harder algorithms like T (Toom Cook) that must be translated to recursive functions that pass data down. That took me quite a wile. The correct answer is, it is just labour. Deal with it. Note that if you want to translate it to assembler, it is relatively easy. > >kind regards, Antti J Ylikoski >Helsinki, Finland, the EU Groetjes Albert -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst -- http://mail.python.org/mailman/listinfo/python-list
dpkg status
Hi, anyone know what library i have to use to manage /var/lib/dpkg/status file to get url of packages ? thanks lewis -- Linux Server, Microsoft Windows 2003/2008 Server, Exchange 2007 http://predellino.blogspot.com/ -- http://mail.python.org/mailman/listinfo/python-list
Unittest2 on python 2.6
Suppose we want to use the unittest from Python 2.7, but also want to
support Python 2.6,
what is the best way to do it?
The solution used now is to have in setup.py
if sys.version < '2.7':
tests_require.append('unittest2')
and then in every test file
try:
import unittest2 as unittest
except ImportError:
import unittest
and it should work just fine, but it's a bit verbose to have this
try/except dance everywhere..
Any ideas?
--
http://mail.python.org/mailman/listinfo/python-list
Re: dpkg status
Le 18/03/12 13:03, admin lewis a écrit : Hi, anyone know what library i have to use to manage /var/lib/dpkg/status file to get url of packages ? thanks lewis Hi, What url ?, Sources, maintainer? You can use "apt-cache search 'keyword'" to find a package. -- Vincent V.V. Oqapy . Qarte+7 . PaQager -- http://mail.python.org/mailman/listinfo/python-list
Re: dpkg status
2012/3/18 Vincent Vande Vyvre : > Le 18/03/12 13:03, admin lewis a écrit : > > Hi, > > What url ?, Sources, maintainer? > No, I need of to open /var/lib/dpkg/status and extract the packages and its url to download it... I know that there is python-apt http://apt.alioth.debian.org/python-apt-doc/library/index.html but I dont understand how it works.. -- Linux Server, Microsoft Windows 2003/2008 Server, Exchange 2007 http://predellino.blogspot.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: dpkg status
Le 18/03/12 15:54, admin lewis a écrit : 2012/3/18 Vincent Vande Vyvre : Le 18/03/12 13:03, admin lewis a écrit : Hi, What url ?, Sources, maintainer? No, I need of to open /var/lib/dpkg/status and extract the packages and its url to download it... I know that there is python-apt http://apt.alioth.debian.org/python-apt-doc/library/index.html but I dont understand how it works.. OK, you know apt, I see (your blog). But packages have no url, just repositery. I see your link python-apt, this doc is very minimalistic, maybe you can find repositeries infos of packages with aptsources.distinfo, but methods are not documented. http://apt.alioth.debian.org/python-apt-doc/library/aptsources.distinfo.html#module-aptsources.distinfo -- Vincent V.V. Oqapy . Qarte+7 . PaQager -- http://mail.python.org/mailman/listinfo/python-list
Re: Unittest2 on python 2.6
On 3/18/2012 9:31 AM, Andrea Crotti wrote:
Suppose we want to use the unittest from Python 2.7, but also want to
support Python 2.6,
what is the best way to do it?
The solution used now is to have in setup.py
if sys.version < '2.7':
tests_require.append('unittest2')
and then in every test file
try:
import unittest2 as unittest
except ImportError:
import unittest
and it should work just fine, but it's a bit verbose to have this
try/except dance everywhere..
Any ideas?
1. If the difference between unittest and unittest2 is strictly a matter
of deletions and addition, replace unittest with the union of the two.
2. Put the try/except dance in a compat file. Then everywhere else 'from
compat import unittest'. This idea is one of those used to write code
that will run on both 2.x and 3.x
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to get a reference of the 'owner' class to which a method belongs in Python 3.X?
On Sun, Mar 18, 2012 at 3:42 AM, Cosmia Luna wrote: > But it seems that the last line(#ref2) in the Py2Type.__init__ does not work > at > all. I'm not sure what you're expecting it to do, but type.__init__ does not actually do anything > It seems really weird, 'type' is an instance of 'type' itself, I'm not sure > if I'm calling the unbound method __init__ or bound method __init__. type.__init__ is never bound. > It seems type.__new__ calls type.__init__ before it calls Py2Type.__init__, > because dict_ is already copied to cls.__dict__ at line(#ref3). No, type.__new__ does not call type.__init__ at all. Rather, it is type.__new__ that is responsible for copying the dict, not type.__init__. For this reason you should override type.__new__ in your metaclass, not type.__init__. Cheers, Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: dpkg status
2012/3/18 Vincent Vande Vyvre :
>
>
> OK, you know apt, I see (your blog).
>
> But packages have no url, just repositery.
>
> I see your link python-apt, this doc is very minimalistic, maybe you can
> find repositeries infos of packages with aptsources.distinfo, but methods
> are not documented.
>
> http://apt.alioth.debian.org/python-apt-doc/library/aptsources.distinfo.html#module-aptsources.distinfo
>
Well no, I need something like the following:
import apt_pkg
tagf = apt_pkg.TagFile(open('/home/lightbox/status'))
for section in tagf:
indirizzo="http://it.archive.ubuntu.com/ubuntu/pool/main/"+section['Package'][0]+'/'+section['Package']+'/'+section['Package']+'_'+section['Version']+'_'+section['Architecture']+'.deb'+'\n'
print indirizzo
with the following output:
http://it.archive.ubuntu.com/ubuntu/pool/main/t/texlive-lang-all/texlive-lang-all_2009-3_all.deb
http://it.archive.ubuntu.com/ubuntu/pool/main/x/xserver-xorg-input-vmmouse/xserver-xorg-input-vmmouse_1:12.7.0-2_i386.deb
http://it.archive.ubuntu.com/ubuntu/pool/main/l/libmono-system-data4.0-cil/libmono-system-data4.0-cil_2.10.5-1_all.deb
but the best sould be that the script make the download of deb automatically..
infact if u see the output u will see that is not correct.. because the section
texlive-lang-all doesn't exist and the correct one is texlive-lang
I dont know if i have to connect to the cache of apt or simply i need
of source.list..
thanks for any help
luigi
P.S. the /home/lightbox/status is a partial file of /var/lib/dpkg/status
--
Linux Server, Microsoft Windows 2003/2008 Server, Exchange 2007
http://predellino.blogspot.com/
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python is readable
On Thu, 15 Mar 2012 00:34:47 +0100, Kiuhnm wrote:
> I've just started to read
>The Quick Python Book (2nd ed.)
> The author claims that Python code is more readable than Perl code and
> provides this example:
>
> --- Perl ---
> sub pairwise_sum {
> my($arg1, $arg2) = @_;
> my(@result) = ();
> @list1 = @$arg1;
> @list2 = @$arg2;
> for($i=0; $i < length(@list1); $i++) {
> push(@result, $list1[$i] + $list2[$i]);
> }
> return(\@result);
> }
>
> --- Python ---
> def pairwise_sum(list1, list2):
> result = []
> for i in range(len(list1)):
> result.append(list1[i] + list2[i])
> return result
> --- ---
>
> It's quite clear that he knows little about Perl.
> Here's what I would've written:
>
> sub pairwise_sum {
> my ($list1, $list2) = @_;
> my @result;
> push @result, $list1->[$_] + $list2->[$_] for (0..@$list1-1);
> \@result;
> }
>
> Having said that, the Python code is still more readable, so there's no
> need to misrepresent Perl that way.
> Now I'm wondering whether the author will show me "good" or "bad" Python
> code throughout the book. Should I keep reading?
>
> Kiuhnm
I have a simple experience which to me demonstrates python must be fairly
readable.
I gave a copy of a small utility to a friend of mine, whilst running it
he found an obscure case that would cause a crash, he has only limited
programming experience of any sort but from the python trace-back he was
able to read my code & made a suggestion of what he thought would fix the
issue, this suggestion was spot on.
--
Necessity is a mother.
--
http://mail.python.org/mailman/listinfo/python-list
Benchmarking stripping of Unicode characters which are invalid XML
Last week I was surprised to discover that there are Unicode characters that
aren't valid in an XML document. That is regardless of escaping (e.g. �)
and unicode encoding (e.g. UTF-8) - not every Unicode string can be stored in
XML. The valid characters are (as of XML 1.0) #x9 | #xA | #xD | [#x20-#xD7FF] |
[#xE000-#xFFFD] | [#x1-#x10]. Others such as #x13 must be stripped,
replaced or placed inside a wrapper such as base64.
I didn't find an existing function to strip these so I wrote some and
benchmarked them. I'd be interested for thoughts, suggestions and improvements.
regsub_p2 was the fastest on a string containing mostly printable-ascii.
regsub_p1 0.422097921371 True
regsub_p2 0.353546857834 True
regsub_p3 0.697242021561 True
regsub_p4 0.677567005157 True
genexp_p1 6.43633103371 True
genexp_p2 6.43329787254 True
genexp_p3 6.80837488174 True
genexp_p4 6.81470417976 True
filter_p1 7.2116046 True
filter_p2 7.46805095673 True
filter_p3 7.37018704414 True
filter_p4 7.03261303902 True
genexp_f1 12.8470640182 True
genexp_f2 5.43630099297 True
genexp_f3 4.9708840847 True
genexp_f4 12.2384109497 True
genexp_f5 6.95861411095 True
genexp_f6 4.7168610096 True
genexp_f7 20.2065701485 True
genexp_f8 21.1112251282 True
Regards, Alex
#!/usr/bin/python
# Valid XML 1.0 characters are
# #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x1-#x10]
# http://www.w3.org/TR/2008/PER-xml-20080205/#charsets
#
# Before passing an arbitrary unicode string to an XML encoder invalid
characters
# must be stripped or replaced. Escaping them doesn't help - they're simply not
# allowed in a well formed XML 1.0 document.
# The following script banchmarks several functions that strip them
import re
import string
import timeit
p1 = re.compile(u'[^\x09\x0A\x0D\u0020-\uD7FF'
u'\uE000-\uFFFD\U0001-\U0010]', re.U)
p2 = re.compile(u'[^\u0020-\uD7FF\x09\x0A\x0D'
u'\uE000-\uFFFD\U0001-\U0010]', re.U)
p3 = re.compile(p1.pattern + u'+', re.U)
p4 = re.compile(p2.pattern + u'+', re.U)
def regsub_p1(s): return p1.sub(u'', s)
def regsub_p2(s): return p2.sub(u'', s)
def regsub_p3(s): return p3.sub(u'', s)
def regsub_p4(s): return p4.sub(u'', s)
def genexp_p1(s): return u''.join(c for c in s if not p1.match(c))
def genexp_p2(s): return u''.join(c for c in s if not p2.match(c))
def genexp_p3(s): return u''.join(c for c in s if not p3.match(c))
def genexp_p4(s): return u''.join(c for c in s if not p4.match(c))
def filter_p1(s): return u''.join(filter(lambda c: not p1.match(c), s))
def filter_p2(s): return u''.join(filter(lambda c: not p2.match(c), s))
def filter_p3(s): return u''.join(filter(lambda c: not p3.match(c), s))
def filter_p4(s): return u''.join(filter(lambda c: not p4.match(c), s))
def f1(c):
i = ord(c)
return (i in set([0x09, 0x0A, 0x0D]) or 0x0020 <= i <= 0xD7FF
or 0xE000 <= i <= 0xFFFD or 0x0001 <= i <= 0x0010)
def f2(c):
i = ord(c)
return (0x0020 <= i <= 0xD7FF or i in set([0x09, 0x0A, 0x0D])
or 0xE000 <= i <= 0xFFFD or 0x0001 <= i <= 0x0010)
def f3(c):
return (u'\u0020' <= c <= u'\uD7FF' or c in set([u'\x09', u'\x0A', u'\x0D'])
or u'\uE000' <= c <= u'\uFFFD' or u'\U0001' <= c <=
u'\U0010')
def f4(c):
return (c in set([u'\x09', u'\x0A', u'\x0D']) or u'\u0020' <= c <= u'\uD7FF'
or u'\uE000' <= c <= u'\uFFFD' or u'\U0001' <= c <=
u'\U0010')
def f5(c):
return (c == u'\x09' or c == u'\x0A' or c == u'\x0D' or u'\u0020' <= c <=
u'\uD7FF'
or u'\uE000' <= c <= u'\uFFFD' or u'\U0001' <= c <=
u'\U0010')
def f6(c):
return (u'\u0020' <= c <= u'\uD7FF' or c == u'\x09' or c == u'\x0A' or c ==
u'\x0D'
or u'\uE000' <= c <= u'\uFFFD' or u'\U0001' <= c <=
u'\U0010')
every_8bit = u''.join(unichr(i) for i in range(256))
valid_8bit = u''.join(c for c in every_8bit if f1(c))
invalid_8bit = u''.join(c for c in every_8bit if not f1(c))
invalid_8bit_iso88591 = invalid_8bit.encode('iso-8859-1')
translator = string.maketrans(invalid_8bit_iso88591,
'\x00' * len(invalid_8bit_iso88591))
def f7(c):
return ((c <= u'\xff' and ord(string.translate(c.encode('iso-8859-1'),
translator)))
or u'\uE000' <= c <= u'\uFFFD' or u'\U0001' <= c <=
u'\U0010')
def f8(c):
return ((c <= u'\xff' and string.translate(c.encode('iso-8859-1'), None,
invalid_8bit_iso88591))
or u'\uE000' <= c <= u'\uFFFD' or u'\U0001' <= c <=
u'\U0010')
def genexp_f1(s): return u''.join(c for c in s if f1(c))
def genexp_f2(s): return u''.join(c for c in s if f2(c))
def genexp_f3(s): return u''.join(c for c in s if f3(c))
def genexp_f4(s): return u''.join(c for c in s if f4(c))
def genexp_f5(s): return u''.join(c for c in s if f5(c))
def genexp_f6(s): return u''.join(c for c in s if f6(c))
def genexp_f7(s): return u''.join(c for c in s if f7(c))
def genexp_f8(s): return u''.joi
Re: Unittest2 on python 2.6
On 03/18/2012 03:46 PM, Terry Reedy wrote: 1. If the difference between unittest and unittest2 is strictly a matter of deletions and addition, replace unittest with the union of the two. 2. Put the try/except dance in a compat file. Then everywhere else 'from compat import unittest'. This idea is one of those used to write code that will run on both 2.x and 3.x 1. I think that unittest2 is a simple superset of unittest, but unittest2 is a backport of unittest module in Python 2.7, that's the point, so I don't see how I should replace it with the union.. 2. good idea thanks -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is readable
On Mar 14, 11:23 pm, alex23 wrote: > The idea that Python code has to be obvious to non-programmers is an > incorrect and dangerous one. Incorrect? Probably. Dangerous? You'll have to explain what you mean. What I would say is that, when PROGRAMMERS look at Python code for the first time, they will understand what it does more readily than they would understand other unfamiliar programming languages. That has value. -- http://mail.python.org/mailman/listinfo/python-list
Re: Unittest2 on python 2.6
On 3/18/2012 4:55 PM, Andrea Crotti wrote: On 03/18/2012 03:46 PM, Terry Reedy wrote: 1. If the difference between unittest and unittest2 is strictly a matter of deletions and addition, replace unittest with the union of the two. 2. Put the try/except dance in a compat file. Then everywhere else 'from compat import unittest'. This idea is one of those used to write code that will run on both 2.x and 3.x 1. I think that unittest2 is a simple superset of unittest, but unittest2 is a backport of unittest module in Python 2.7, that's the point, so I don't see how I should replace it with the union. If set A contains set B, then A is the union of the two. The danger of replacing unittest with unittest2 in a 2.6 installation is that 2.6 code that used the new features will not run in a 'normal' 2.6 installation. Whether that is a potential problem depends on whether you ever expect the code to escape from the altered environment. I said 'union' because I was not familiar with its details. I was allowing for the possibility that features were both deleted and added, in which case the union would include all features and work with multiple versions. That is moot for this case but not some others. 2. good idea thanks The advantage of even one explicit unittest2 import, even if hidden away, is that you get a proper error message if you run the code where unittest2 is not present. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is readable
On Mon, Mar 19, 2012 at 8:30 AM, John Ladasky wrote: > What I would say is that, when PROGRAMMERS look at Python code for the > first time, they will understand what it does more readily than they > would understand other unfamiliar programming languages. That has > value. This is something that's never truly defined. Everyone talks of how this language or that language is readable, but if you mean that you can look at a line of code and know what *that line* does, then Python suffers badly and assembly language wins out; but if you mean that you should be able to glance over an entire function and comprehend its algorithm, then I have yet to see any language in which it's not plainly easy to write bad code. Even with good code, anything more than trivial can't be eyeballed in that way - if you could, what would docstrings be for? Really, the metric MUST be Python programmers. Intuitiveness is of value, but readability among experienced programmers is far more useful. If I write a whole lot of code today, and next year I'm dead and someone else has replaced me, I frankly don't mind if he has to learn the language before he can grok my code. I _do_ mind if, even after he's learned the language, he can't figure out what my code's doing; and that's where Python's placed itself at about the right level - not so high that it's all in airy-fairy conceptual work, but not so low that it gets bogged down. There's a handful of other languages that are similarly placed, and they're the languages that I would call "readable". Here's an analogy: One statement (aka line of code, etc) corresponds to one sentence in English. Massive one-liners are like some of the sentences in Paul's epistles; assembly language is like "The cat sat on the mat". Both are valid; both are hard to read. There, have fun tearing thaat to shreds :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Problem with special characters in the password field (urllib)
Hi, I'm having problems getting a script that I wrote to check the unread Gmail feed work (http://pastebin.com/FAGyedH0). The script fetches the unread mail feed (https://mail.google.com/mail/feed/atom/) and then parses it using python-feedparser. The script seems to work fine if I'm not using any special characters like !@#$%^&*() in the password. I tried some pretty basic debugging and saw that the execution stops beyond line 35 which is where the authentication happens. So I figured that this has got to do something with urrllib and special characters in the password field. I've also tried prefixing the string with 'r' without any success. Any help is appreciated. Cheers! Bernhard. -- http://mail.python.org/mailman/listinfo/python-list
Re: Currying in Python
On 3/17/2012 2:21, Kiuhnm wrote: Here we go. I wrote an article about my approach to currying: http://mtomassoli.wordpress.com/2012/03/18/currying-in-python/ Beginners should be able to understand it as well. Experienced programmers will probably want to skip some sections. Kiuhnm -- http://mail.python.org/mailman/listinfo/python-list
Re: Programming D. E. Knuth in Python with the Deterministic Finite Automaton construct
On 3/18/2012 0:28, Michael Torrie wrote: I am familiar with how one might implement a decompiler, as well as a compiler (having written a simple one in the past), but even now I don't see a connection between a decompiler and the process of converting a knuth algorithm into a python python implementation. I was hoping you would shed some light on that. But alas, I'm not really as much of an "interested reader" as you would like me to be. Many ASM languages don't have structured control flow statements but only jmps, which are roughly equivalent to gotos. A good decompiler will need to analize the net of jmps and try to rewrite the code using structured control flow statements. The idea is to maximize readability, of course. Here's an example of rewriting: Thank you. Your example makes more clear your assertion about "labels" and how really A1 and A5 were the only real labels in the example. Though I still do not really see why "states" is not a good equivalence for labels in this case. As well, Roy's idea for doing the state machines, which works equally well as the nested if statements, is more pythonic, which is generally preferred in Python. What I don't like about the entire issue is that (pseudo-)code shouldn't be cut and pasted or blindly ported to another language. Python is a very expressive language. I don't think you like it when someone writes C code in Python. Now we're writing ASM code in Python! If you want to emulate a DFA, do it, but if you want to implement an algorithm whose pseudo-code happens to use labels and gotos, please use higher-level control flow statements (unless you're pressed on time and you need it done yesterday, of course). Regarding labels and state, I simply meant that they're completely different things, in fact this program has two labels but infinitely many states: A1: cur = cur + 1 A2: goto A1 I was being pedantic, to say it your way ;) Kiuhnm -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is readable
On Mon, 19 Mar 2012 09:02:06 +1100, Chris Angelico wrote: > On Mon, Mar 19, 2012 at 8:30 AM, John Ladasky > wrote: >> What I would say is that, when PROGRAMMERS look at Python code for the >> first time, they will understand what it does more readily than they >> would understand other unfamiliar programming languages. That has >> value. > > This is something that's never truly defined. I'm sorry, I don't understand what part of John's sentence you mean by "this". "Programmers"? "Value"? "Understand"? > Everyone talks of how this > language or that language is readable, but if you mean that you can look > at a line of code and know what *that line* does then Python suffers > badly and assembly language wins out; This is at least the second time you've alleged that assembly language is more readable than Python. I think you're a raving nutter, no offence Chris :-) Assignment (name binding) is close to the absolute simplest thing you can do in a programming language. In Python, the syntax is intuitive to anyone who has gone through high school, or possibly even primary school, and been introduced to the equals sign. x = 1234 y = "Hello" In assembly language, not so much. I wouldn't even have begun to guess how to assign variables in assembly, or even whether such a thing is possible, but a few minutes of googling gave me this: # 8086 assembly x dw 1234 y db 'Hello', 0 # MIPS assembly x: .word 1234 y: .asciiz "Hello" I don't know about anyone else, but I wouldn't have guessed that the way to get x=1234 was with "x dw 1234". What's more, with Python, one example hints on how to do other examples. Having seen x=1234, most people would guess that x=1.234 would also work. I'm pretty sure that "x dw 1.234" will do something surprising, although I don't know what, but it certainly won't be to assign the float 1.234 to a variable x. So there we have another measure of "readability" -- discoverability. Having seen one example, how easy is it to predict slightly modified examples? In assembly's case, not very predictable. What's the difference between these two lines? a db 127 b db 327 For that matter, what will the second line actually do? The thing is, these aren't "advanced features" of assembly language. It's not like trying to understand metaclasses in Python. These are the basic foundations. You can read vast swathes of simple Python code without needing to learn the gory details of Python's data model (name binding of objects, everything is an object), but you can't even *begin* reading assembly language without a good grasp of the data model and jargon. Assembly has a very steep learning curve. Python has a shallow curve. Here's another indication of readability. There have been occasional suggestions on Wikipedia that they standardize on Python as "executable pseudo-code" for code samples. Now replace "Python" with assembly language. Unless you're Donald Knuth, the idea is ridiculous. Another factor related to readability is the primitiveness of the toolset. Assembly has a very low-level, primitive toolset. How would you write this in assembly? print(sorted(somelist)) If all you have is a hammer, the instructions you get are easy to understand because there's not much you can do with it. How complicated can "hit the nail with the hammer" get? But the right measure is not the simplicity of the tasks you *can* do, but the comprehensibility of the tasks you *want* to do. "How do I build a tree house using nothing but a hammer?" I'm sure that, given sufficient ingenuity, you could build a tree house with nothing but a hammer, lumber and nails, but the detailed instructions would be complicated and difficult. How much simpler it becomes with a more powerful set of tools. Assembly is simple, like a hammer. (Well, perhaps not *quite* as simple as a hammer.) > but if you mean that you should be > able to glance over an entire function and comprehend its algorithm, > then I have yet to see any language in which it's not plainly easy to > write bad code. Even with good code, anything more than trivial can't be > eyeballed in that way - if you could, what would docstrings be for? The measure of the readability of a language should not be obfuscated or badly written code, but good, idiomatic code written by an experienced practitioner in the art. Note that there is a deliberate asymmetry there: when judging "readability" (comprehensibility), we take idiomatic code written by somebody who knows the language well, and give it to a novice to interpret it. On this measure, Python has actually become *less* readable in recent years, with the addition of powerful new idioms such as generators, list comprehensions, with statement, etc. They are very expressive, and Python is much better off with them, but they are less readable in the sense I am talking about: readable to somebody who is not an expert in the language. For this reas
[RELEASED] Second release candidates for Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3
We're chuffed to announce the immediate availability of the second release candidates for Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3. The only change from the first release candidates is the patching of an additional security hole. The security issue fixed in the second release candidates is in the expat XML parsing library. expat had the same hash security issue detailed below as Python's core types. The hashing algorithm used in the expat library is now randomized. A more thorough explanation of the "hash attack" security hole follows. The main impetus for these releases is fixing a security issue in Python's hash based types, dict and set, as described below. Python 2.7.3 and 3.2.3 include the security patch and the normal set of bug fixes. Since Python 2.6 and 3.1 are maintained only for security issues, 2.6.8 and 3.1.5 contain only various security patches. The security issue exploits Python's dict and set implementations. Carefully crafted input can lead to extremely long computation times and denials of service. [1] Python dict and set types use hash tables to provide amortized constant time operations. Hash tables require a well-distributed hash function to spread data evenly across the hash table. The security issue is that an attacker could compute thousands of keys with colliding hashes; this causes quadratic algorithmic complexity when the hash table is constructed. To alleviate the problem, the new releases add randomization to the hashing of Python's string types (bytes/str in Python 3 and str/unicode in Python 2), datetime.date, and datetime.datetime. This prevents an attacker from computing colliding keys of these types without access to the Python process. Hash randomization causes the iteration order of dicts and sets to be unpredictable and differ across Python runs. Python has never guaranteed iteration order of keys in a dict or set, and applications are advised to never rely on it. Historically, dict iteration order has not changed very often across releases and has always remained consistent between successive executions of Python. Thus, some existing applications may be relying on dict or set ordering. Because of this and the fact that many Python applications which don't accept untrusted input are not vulnerable to this attack, in all stable Python releases mentioned here, HASH RANDOMIZATION IS DISABLED BY DEFAULT. There are two ways to enable it. The -R commandline option can be passed to the python executable. It can also be enabled by setting an environmental variable PYTHONHASHSEED to "random". (Other values are accepted, too; pass -h to python for complete description.) More details about the issue and the patch can be found in the oCERT advisory [1] and the Python bug tracker [2]. These releases are releases candidates and thus not recommended for production use. Please test your applications and libraries with them, and report any bugs you encounter. We are especially interested in any buggy behavior observed using hash randomization. Excepting major calamity, final versions should appear after several weeks. Downloads are at http://python.org/download/releases/2.6.8/ http://python.org/download/releases/2.7.3/ http://python.org/download/releases/3.1.5/ http://python.org/download/releases/3.2.3/ Please test these candidates and report bugs to http://bugs.python.org/ With regards, The Python release team Barry Warsaw (2.6), Georg Brandl (3.2), Benjamin Peterson (2.7 and 3.1) [1] http://www.ocert.org/advisories/ocert-2011-003.html [2] http://bugs.python.org/issue13703 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is readable
John Ladasky wrote: > > The idea that Python code has to be obvious to non-programmers is an > > incorrect and dangerous one. > > Incorrect? Probably. Dangerous? You'll have to explain what you > mean. The classic "obvious" behaviour to new Python programmers that causes problems would be mutable default arguments. At this point you have two options: improve the "readability" to new users so their expectations are met, or ask them to modify those expectations and understand what's really happening under the surface. As it stands, you tend to hit this problem pretty early on, learn about it, and walk away with a deeper knowledge of Python's mechanics. The danger, I feel, is that changing it to better fit the mind-set that non-Python programmers bring with them could mask that necessary understanding for longer. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is readable
On Sun, Mar 18, 2012 at 8:15 PM, alex23 wrote: > John Ladasky wrote: >> > The idea that Python code has to be obvious to non-programmers is an >> > incorrect and dangerous one. >> >> Incorrect? Probably. Dangerous? You'll have to explain what you >> mean. > > The classic "obvious" behaviour to new Python programmers that causes > problems would be mutable default arguments. At this point you have > two options: improve the "readability" to new users so their > expectations are met, or ask them to modify those expectations and > understand what's really happening under the surface. As it stands, > you tend to hit this problem pretty early on, learn about it, and walk > away with a deeper knowledge of Python's mechanics. The mechanics of default arguments maybe, but that's tautological. If you mean call-by-object, any time you pass both mutable and immutable things around, you will learn the same lesson. If you mean the more general principle that "Python doesn't ever copy things unless you explicitly ask", working with lists (and particularly their multiplication operator) again tends to also teach that lesson. > The danger, I > feel, is that changing it to better fit the mind-set that non-Python > programmers bring with them could mask that necessary understanding > for longer. I disagree. Just add a keyword for each default argument evaluation behavior (evaluate-once-at-definition-time [e.g. "once", "static"] and evaluate-at-call-time [e.g. "fresh"]) and don't have there be a default behavior; make the choice explicit. They'll be confronted with the issue as soon as they're shown default arguments, and keywords are easy to look up the meaning of. And as I said previously, there are other common ways to learn any of the "lessons" that default arguments might "teach". If-I-had-my-druthers-ly yours, Chris (R.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is readable
On Mon, Mar 19, 2012 at 12:23 PM, Steven D'Aprano
wrote:
> On Mon, 19 Mar 2012 09:02:06 +1100, Chris Angelico wrote:
>
>> On Mon, Mar 19, 2012 at 8:30 AM, John Ladasky
>> wrote:
>>> What I would say is that, when PROGRAMMERS look at Python code for the
>>> first time, they will understand what it does more readily than they
>>> would understand other unfamiliar programming languages. That has
>>> value.
>>
>> This is something that's never truly defined.
>
> I'm sorry, I don't understand what part of John's sentence you mean by
> "this". "Programmers"? "Value"? "Understand"?
I should have rewritten that into the next paragraph. Anyhow. Further
explanation below.
>> Everyone talks of how this
>> language or that language is readable, but if you mean that you can look
>> at a line of code and know what *that line* does then Python suffers
>> badly and assembly language wins out;
>
> This is at least the second time you've alleged that assembly language is
> more readable than Python. I think you're a raving nutter, no offence
> Chris :-)
None taken; guilty as charged. And unashamedly so. With that dealt
with, though: My calling assembly "readable" is a form of argument by
drawing to logical, but absurd, conclusion - by the given definition
of readability, assembly is readable, ergo the definition sucks.
(That's a term all logicians use, you know. Proper and formal jargon.)
> Assignment (name binding) is close to the absolute simplest thing you can
> do in a programming language. In Python, the syntax is intuitive to
> anyone who has gone through high school, or possibly even primary school,
> and been introduced to the equals sign.
>
> x = 1234
> y = "Hello"
Not quite. In mathematics, "x = 1234" is either a declaration of fact,
or a statement that can be either true or false. In mathematics, "x =
x + 1" is absurd and/or simply false. That's why Pascal has its :=
operator, supposed to be read as "becomes" and not "equals". IMHO this
is simply proof of one of the differences between programming and
mathematics.
> I don't know about anyone else, but I wouldn't have guessed that the way
> to get x=1234 was with "x dw 1234".
Except that it's not quite the same thing. That 8086 Assembly
statement is more like the C statement:
int x=1234;
The nearest equivalent of assignment is:
mov x,1234
although that differs slightly from assembler to assembler (NASM, if I
recall correctly, calls for "mov [x],1234"). You're right, though,
that it's nothing like as clear.
> What's more, with Python, one example hints on how to do other examples.
> Having seen x=1234, most people would guess that x=1.234 would also work.
Yes, which brings up the old favorite arguments about whether
computers work with integers, floats, rationals, Real Numbers, or
Numbers. But, that aside...
> I'm pretty sure that "x dw 1.234" will do something surprising, although
> I don't know what, but it certainly won't be to assign the float 1.234 to
> a variable x.
Perhaps not usefully, but "x dd 1.234" ought to work. You just can't
fit a float into a dw. (NASM does support "half precision", but most
operations want a doubleword for a float.) Assembly language requires
variable sizes to be declared.
Of course, what it *really* does is declare a doubleword-sized patch
of memory, initializes it to the IEEE representation of the nearest
possible float to the real number 1.234, and assigns the label 'x' to
point to the lowest memory address used by that doubleword... but
mostly you don't need to care about that.
> So there we have another measure of "readability" -- discoverability.
> Having seen one example, how easy is it to predict slightly modified
> examples?
>
> In assembly's case, not very predictable. What's the difference between
> these two lines?
>
> a db 127
> b db 327
>
> For that matter, what will the second line actually do?
I'm not 100% sure, but since assembly is much stricter than most HLLs
with data sizes, it's a concern that you don't have with Python's long
ints. But the same thing can come up in a HLL - struct.pack("i") can't
handle a long int, because, like an assembler, it's concerned about
exact byte sizes.
> Assembly has a very steep learning curve. Python has a shallow curve.
Of course. But computer programming generally has a fairly stiff
learning curve; you have to get your head around all sorts of concepts
that simply do not exist anywhere else.
> Here's another indication of readability. There have been occasional
> suggestions on Wikipedia that they standardize on Python as "executable
> pseudo-code" for code samples. Now replace "Python" with assembly
> language. Unless you're Donald Knuth, the idea is ridiculous.
I am not, and it is. But I could make you a set of NASM macros that
allow you to write assembly code that looks like pseudo-code. Does
that make assembly code readable? Maybe. Does it make it worth using
as a HLL? No.
> If all you have is a hammer, the instructions you get are easy to
> understand
ANN: cmd2, an extenstion of cmd that parses its argument line
Dear all, I would like to announce the first public release of cmd2, an extension of the standard library's cmd with argument parsing, here: https://github.com/anntzer/cmd2. Cmd2 is an extension built around the excellent cmd module of the standard library. Cmd allows one to build simple custom shells using ``do_*`` methods, taking care in particular of the REPL loop and the interactive help. However, no facility is given for parsing the argument line (do_* methods are passed the rest of the line as a single string argument). With Cmd2, ``do_*`` methods are type-annotated, either using Python 3's function annotation syntax, or with an ad-hoc ``annotate`` decorator, allowing the dispatcher to parse the argument list for them. Antony Lee -- http://mail.python.org/mailman/listinfo/python-list
New learner of Python--any suggestion on studying it?
Hello all, I'm a new learning of Python. Can someone give me some suggestion about it? thanks xianming -- http://mail.python.org/mailman/listinfo/python-list
