Re: Flatten a list/tuple and Call a function with tuples
def flatten(listOfLists): return list(chain(*listOfLists)) >From http://www.python.org/doc/2.4/lib/itertools-recipes.html -- EduardoOPadoan (eopadoan->altavix::com) Bookmarks: http://del.icio.us/edcrypt -- http://mail.python.org/mailman/listinfo/python-list
Re: Pickled objects over the network
On 7/18/07, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: > On Tue, 17 Jul 2007 14:57:16 -0700, Walker Lindley <[EMAIL PROTECTED]> wrote: [...] > The obvious thing you're doing wrong is using pickle over a network. ;) > > http://jcalderone.livejournal.com/15864.html Ok, maybe not the best tools to the job, but there are some more secure alternatives: http://trustedpickle.sourceforge.net/ http://home.gna.org/oomadness/en/cerealizer/index.html -- EduardoOPadoan (eopadoan->altavix::com) Bookmarks: http://del.icio.us/edcrypt -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3107 and stronger typing (note: probably a newbie question)
On 7/4/07, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: > On 6/22/07, Eduardo EdCrypt O. Padoan <[EMAIL PROTECTED]> wrote: > > Remember that pure CPython has no different "compile time" and > > runtiime. But Psyco and ShedSkin could use the annotations the way > > they want. > . > > def compile(source: "something compilable", > >filename: "where the compilable thing comes from", > >mode: "is this a single statement or a suite?"): > > I think the above would make an annotation-enhanced Psyco or ShedSkin > very confused. This example was to show that annotations are for documentation too, not only type checking or optimization. It is from the PEP. EduardoOPadoan (eopadoan->altavix::com) Bookmarks: http://del.icio.us/edcrypt -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3107 and stronger typing (note: probably a newbie question)
On 6/30/07, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote: > Eduardo "EdCrypt" O. Padoan a écrit : > > Remember that pure CPython has no different "compile time" and > > runtiime. > > Oh yes ? So what's the compiler doing, and what are those .pyc files ? > (hint: read the doc) Sorry, I surely know that Python has a compile time, I wanted to say somthing like "compile time checks except from syntax". My intention was to show that a *huge* change in the Python interpretation model would be needed to allow what he wanted, but I finished my email too early :P And yes, I readed the docs :) -- EduardoOPadoan (eopadoan->altavix::com) Bookmarks: http://del.icio.us/edcrypt -- http://mail.python.org/mailman/listinfo/python-list
Re: Voluntary Abstract Base Classes
On 6/29/07, Daniel Nogradi <[EMAIL PROTECTED]> wrote: > Hi list, > > Well, the short question is: what are they? I've read Guido's python > 3000 status report on > http://www.artima.com/weblogs/viewpost.jsp?thread=208549 where he > mentions ABC's but don't quite understand what the whole story is > about. The story is at PEP 3119: http://www.python.org/dev/peps/pep-3119/ > Anyone has good use cases? The Rationale in the PEP may help you to imagine one. -- EduardoOPadoan (eopadoan->altavix::com) Bookmarks: http://del.icio.us/edcrypt -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3107 and stronger typing (note: probably a newbie question)
On 6/27/07, Stephen R Laniel <[EMAIL PROTECTED]> wrote: > On Thu, Jun 28, 2007 at 09:08:16AM +0200, Bruno Desthuilliers wrote: > > You said ? > > I could link again to Mark-Jason Dominus, who writes that > people often make the following inference: > > 1) C is strongly typed. > 2) C's typing sucks. > 3) Hence strong typing sucks. AFAIK, Python type system is "stronger" than C. C is just *static* typed. > But I won't. > > It doesn't need to be a religious war. Why can't people just > say "When strong typing is done and used well, it's a > useful tool; when it's not, it's not"? True, why this need to be a religious war instead of everybody agreeing with you? :P -- EduardoOPadoan (eopadoan->altavix::com) Bookmarks: http://del.icio.us/edcrypt -- http://mail.python.org/mailman/listinfo/python-list
Re: Collections of non-arbitrary objects ?
> I don't think there is anything wrong with the data structures that > exist in python. I was just wondering if there was a structure that > would restrict a collection to only allow certain types. The > "restrictedlist" class discussed in another thread may be the sort of > thing I was looking for. Just remenber that if you write a library using such a thing, your (consenting adults) users will not be able to store objects in your list that implement (part of) the interface of the type that you restricted. -- EduardoOPadoan (eopadoan->altavix::com) Bookmarks: http://del.icio.us/edcrypt -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3107 and stronger typing (note: probably a newbie question)
On 6/22/07, John Nagle <[EMAIL PROTECTED]> wrote:
> Paul Boddie wrote:
> > P.S. I agree with the sentiment that the annotations feature of Python
> > 3000 seems like a lot of baggage. Aside from some benefits around
> > writing C/C++/Java wrappers, it's the lowest common denominator type
> > annotation dialect that dare not be known as such, resulting from a
> > lack of consensus about what such a dialect should really do, haunted
> > by a justified fear of restrictive side-effects imposed by a more
> > ambitious dialect (eg. stuff you get in functional languages) on
> > dynamically-typed code. I don't think the language should be modified
> > in ways that only provide partial, speculative answers to certain
> > problems when there's plenty of related activity going on elsewhere
> > that's likely to provide more complete, proven answers to those
> > problems.
>
> I agree. It's a wierd addition to the language. It looks like
> a compromise between the "no declarations" position and the "make
> the language strongly typed" position. But it's so ill-defined that
> it's not helpful, and worse than either extreme. The whole
> approach is antithetical to the "only one way to do it" concept.
> This could lead to misery when different libraries use
> incompatible type annotation systems, which is not going to be fun.
>
> Python made it this far without declarations, and programmers
> seem to like that. We need to get Python performance up, and
> the ShedSkin/Psyco restrictions seem to be enough to allow that.
> Type annotations don't seem to solve any problem that really needs
> to be solved.
>
> The main advantage of strongly typed systems is that more errors
> are detected at compile time. You pay for this in additional language
> baggage. PEP 3107 adds the excess baggage without providing the benefit
> of compile time checks.
Remember that pure CPython has no different "compile time" and
runtiime. But Psyco and ShedSkin could use the annotations the way
they want.
Function annotations, as PEP 3107 says, just adds "arbitrary metadata
annotations to Python functions" - If you follow the py-dev discutions
about it, it was only accepted because it have more possible uses then
just type checking. Also, there are many approches and different needs
for type checking/restrictions ("safety", IDEs autocompletion hints,
performance... )
So the annotations will be more a "signature documentation", so
different libraries can do whatever it want of it - I problably will
use only as documentation, like in:
def compile(source: "something compilable",
filename: "where the compilable thing comes from",
mode: "is this a single statement or a suite?"):
--
EduardoOPadoan (eopadoan->altavix::com)
Bookmarks: http://del.icio.us/edcrypt
--
http://mail.python.org/mailman/listinfo/python-list
Re: Should: "for k,v in **dictionary_instance" work?
> Actually since you asked, I had to try this out > > x = range(10) > a, *b = x PEP 3132: Extended Iterable Unpacking http://www.python.org/dev/peps/pep-3132/ -- EduardoOPadoan (eopadoan->altavix::com) Bookmarks: http://del.icio.us/edcrypt -- http://mail.python.org/mailman/listinfo/python-list
Re: strange PyLint configuration (was: PEP 8 style enforcing program)
On 5/31/07, Bjoern Schliessmann
<[EMAIL PROTECTED]> wrote:
> Alexander Eisenhuth wrote:
>
> > Pylint is one of them (http://www.logilab.org/857)
>
> BTW: Why does pylint want all names with underscores? I tested it
> and it complains about malformed names in e.g. the following cases
> that are conformant to PEP 8:
>
> - single letter as parameter
This seems to be an Logilab internal restriction.
> - firstLowerCamelCase names for instances and instance methods in
> class declarations ("should match [a-z_][a-z0-9_]{2,30}$")
> - all lowercase method names in class declarations
>
No. Quoting PEP 8:
Functions:
"""
mixedCase is allowed only in contexts where that's already the
prevailing style (e.g. threading.py), to retain backwards compatibility.
"""
Methods and instances:
"""
Use the function naming rules: lowercase with words separated by
underscores as necessary to improve readability.
"""
> Those policies are barely usable, IMHO, and neither practical.
I Desagree.
--
EduardoOPadoan (eopadoan->altavix::com)
Bookmarks: http://del.icio.us/edcrypt
--
http://mail.python.org/mailman/listinfo/python-list
Re: NEWBIE: Extending a For Statement.
> > Perhaps you meant that second one to be: > > (key, mydict[key] for key in mydict if key in xrange(60, 69) or key == > > 3) > > > Clearly not! Its called *list*-comprehension, not tuple-comprehension. ;) With () instead of [], it is a generator expression. http://docs.python.org/ref/genexpr.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Feature Request: Explicit variable declarations
> The thoughts of the inventor of Python on "Adding Optional Static > Typing to Python" are at > http://www.artima.com/weblogs/viewpost.jsp?thread=86641 > . I wonder if the idea will be implemented in Python 3.0. No. He says it in another newer post and in PEP 3099, AFAIK. -- EduardoOPadoan (eopadoan->altavix::com) Bookmarks: http://del.icio.us/edcrypt -- http://mail.python.org/mailman/listinfo/python-list
Re: why I don't like range/xrange
> But this long int => int issue should not exist in a future python > version any more, IIRC int and long int is scheduled to be merged > somehow. (Or isn't it?) It is done. http://mail.python.org/pipermail/python-3000-checkins/2007-January/000251.html -- EduardoOPadoan (eopadoan->altavix::com) Bookmarks: http://del.icio.us/edcrypt -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
On 2/15/07, Edward K Ream <[EMAIL PROTECTED]> wrote: > > Isn't the very concept of major releases (1.x, 2.x, 3.x) that they *can* > > be not backwards-compatible with previous releases? > > Not at all. [...] It is the only intent of Python 3.0: be free of backward compatibity constraints. There are a tool called "2to3" that translates things like "print foo" to print(foo). -- EduardoOPadoan (eopadoan->altavix::com) Bookmarks: http://del.icio.us/edcrypt -- http://mail.python.org/mailman/listinfo/python-list
Re: The Python interactive interpreter has no command history
> Hello, > > How to configure Python2.5's interactive interpreter to get command > history ? > > I always got ^[[A and ^[[B . > Are you using Ubuntu? The last comes with 2.4.x and 2.5. This only occurs on 2.5. This happens when you compile Python with libreadline installed, AFAIK. FIll a bug in the Ubuntu launchpad. You can install libreadline (and build-essential), download the 2.5 source and compile yourself. -- EduardoOPadoan (eopadoan->altavix::com) Bookmarks: http://del.icio.us/edcrypt -- http://mail.python.org/mailman/listinfo/python-list
Re: idea for testing tools
> That's hardly desirable. If one is writing a test library that goes as > far as reparsing the assert statements, I can't see the point of > requiring the user to clutter his test suite with such spurious print > statements. After all, that's one of the main points of test suites in > the first place (that's why there is assertEqual). It will be only be printed when the test fails, along with the rest of the info. The tests will not be "cluttered" by this litle print. -- EduardoOPadoan (eopadoan->altavix::com) Bookmarks: http://del.icio.us/edcrypt -- http://mail.python.org/mailman/listinfo/python-list
Re: idea for testing tools
> #!/usr/bin/python > > a = 1 > b = 2 > > def test_some(): > assert a == b > > didn't reveal the values for a and b, though some more complex cases > showed something. def test_some(): print 'a:', a, 'b:', b assert a == b http://codespeak.net/py/current/doc/test.html#debug-with-the-print-statement -- EduardoOPadoan (eopadoan->altavix::com) Bookmarks: http://del.icio.us/edcrypt Blog: http://edcrypt.blogspot.com Jabber: edcrypt at jabber dot org ICQ: 161480283 GTalk: eduardo dot padoan at gmail dot com MSN: eopadoan at altavix dot com -- http://mail.python.org/mailman/listinfo/python-list
Re: Object type check
> Of cource i restrict them to particular types! In C# you cannot pass > something bad > this way because the compiler will just catch it! And you cant pass something 'good' that immitates another object interface (a file-like object for example) > I see what you mean by "duck typing". So you suggest the "do nothing > at all" direction, > better document my code so other can see what is expected, right ? I would add UnitTests to it. -- EduardoOPadoan (eopadoan->altavix::com) -- http://mail.python.org/mailman/listinfo/python-list
Re: lambda functions ?
> This means that "f" is not a pointer to make_incrementor but rather to > the internal (copied?) function. "returned" function isthe right here. As any returned object from a function. > > > This style is very common in Scheme programming so you might read a > > Scheme book if you want to understand it. The classic: > > > > http://mitpress.mit.edu/sicp/ > > > > I might just well do that. A nice read indeed, but understand this concept first: http://en.wikipedia.org/wiki/First-class_function -- EduardoOPadoan (eopadoan->altavix::com) Bookmarks: http://del.icio.us/edcrypt Blog: http://edcrypt.blogspot.com Jabber: edcrypt at jabber dot org ICQ: 161480283 GTalk: eduardo dot padoan at gmail dot com MSN: eopadoan at altavix dot com -- http://mail.python.org/mailman/listinfo/python-list
re: compound statement from C "?:"
http://effbot.org/pyfaq/is-there-an-equivalent-of-c-s-ternary-operator.htm -- EduardoOPadoan (eopadoan->altavix::com) Bookmarks: http://del.icio.us/edcrypt Blog: http://edcrypt.blogspot.com Jabber: edcrypt at jabber dot org ICQ: 161480283 GTalk: eduardo dot padoan at gmail dot com MSN: eopadoan at altavix dot com -- http://mail.python.org/mailman/listinfo/python-list
Re: File system API
On 2/2/07, Tal Einat <[EMAIL PROTECTED]> wrote: > > I think that there aready exists a proposal for an Abstract FS Layer > > for Python somewere. > > I haven't been able to find any mention of it. Maybe you could point me in > the right direction? > > - Tal > http://wiki.python.org/moin/CodingProjectIdeas/FileSystemVirtualization Another related reference is the recently announced UniPath module: http://sluggo.scrapping.cc/python/unipath/Unipath-current/README.html -- EduardoOPadoan (eopadoan->altavix::com) Bookmarks: http://del.icio.us/edcrypt Blog: http://edcrypt.blogspot.com Jabber: edcrypt at jabber dot org ICQ: 161480283 GTalk: eduardo dot padoan at gmail dot com MSN: eopadoan at altavix dot com -- http://mail.python.org/mailman/listinfo/python-list
re: Inconsistent list/pointer problem
> Won't do for the OP's needs - he wants to modify the objects contained > in listB without impacting the ones in listA (or at least that's what I > understand). Sorry. That is true - the items referenced on the [:] copy are the same as in the original. Rereading what the OP msg, I think we agree. -- http://mail.python.org/mailman/listinfo/python-list
Inconsistent list/pointer problem
> def myFunc(listA): > listB = listA > work on & modify listB > return(listB) def my_func(listA): listB = listA[:] #work on & modify listB return listB Attribution makes the name t the left 'point' to the result of the expression at the right. In your myFunc the expersion at the right is the name listA, at it willl eval to the list that this references. So you will end with to references. In my my_func, the expression at the right is a slicing of the list, from begin to end (listA[:]). Slicing returns a new list, in this example, with the same items of the original list. So you end with two lists, as you wanted. -- EduardoOPadoan (eopadoan->altavix::com) Bookmarks: http://del.icio.us/edcrypt Blog: http://edcrypt.blogspot.com Jabber: edcrypt at jabber dot org ICQ: 161480283 GTalk: eduardo dot padoan at gmail dot com MSN: eopadoan at altavix dot com -- EduardoOPadoan (eopadoan->altavix::com) Bookmarks: http://del.icio.us/edcrypt Blog: http://edcrypt.blogspot.com Jabber: edcrypt at jabber dot org ICQ: 161480283 GTalk: eduardo dot padoan at gmail dot com MSN: eopadoan at altavix dot com -- http://mail.python.org/mailman/listinfo/python-list
Re: How to detect what type a variable is?
> > One might prefer to check for string-ness, as strings can > duck-type somewhat like lists: > > my_list = ['my', 'brain', 'hurts'] > my_string = 'Are you the brain specialist?' > > for test in [my_list, my_string]: > try: > for thing in test: > process_list_item(thing) > except Exception: #whatever flavor you want The exception should be the one that process_list_item raises when it receives a string instead of a list. if you want to treat strings and list in different ways, maybe it means that you are doing different operations on then, like appendind things to the list or whatever. If not, than you maybe want to test the types. > process_string(thing) # not called because > #strings are iterable What if you invert your code? for test in [my_string, my_list]: try: process_string_item(thing) #suppose process_string_item does some string operation on a list and gets this # exception - because if not, I see no meanning in distinguishing then except ValueError: for thing in test: process_list_item(thing) But maybe you have a reason to do things to a string that could be done to a list without raising an exception, but you dont want to do this to *that* list. My sugestion was to think if there is another way, and maybe you are right. -- EduardoOPadoan (eopadoan->altavix::com) Bookmarks: http://del.icio.us/edcrypt Blog: http://edcrypt.blogspot.com Jabber: edcrypt at jabber dot org ICQ: 161480283 GTalk: eduardo dot padoan at gmail dot com MSN: eopadoan at altavix dot com -- http://mail.python.org/mailman/listinfo/python-list
