PyPi name: constraintslib (you'll be dissapointed if you get
constraints by accident)
Docs: http://packages.python.org/constraintslib/
Github: https://github.com/nathan-rice/Constraints
>From the docs:
Constraints - Sleek contract-style validati
On Thu, Jan 26, 2012 at 2:51 PM, Devin Jeanpierre
wrote:
> Ooh, runtime turing-complete dependent-types. :)
>
> I'm not sure if you're aware of the literature on this sort of thing.
> It's nice reading. A library such as this that's designed for it could
> be used for static checks as well.
Actua
> May I suggest a look at languages such as ATS and Epigram? They use
> types that constrain values specifically to prove things about your
> program. Haskell is a step, but as far as proving goes, it's less
> powerful than it could be. ATS allows you to, at compile-time, declare
> that isinstance(
>> Mm I don't think it's what the OP is asking (unless I misunderstood...).
>> I think he wants to compile some syntax TO Python.
>> But I don't really see why you would something like this (if not for fun).
>
> Maybe because you think that Python syntax could be improved upon --
> for instance, Py
As a user:
* Finding the right module in PyPi is a pain because there is limited,
low quality semantic information, and there is no code indexing.
* I have to install the module to examine it; I don't need to look at
docs all the time, sometimes I just want a
package/class/function/method breakdow
> 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 a
On Thu, Feb 9, 2012 at 5:33 AM, Duncan Booth
wrote:
> Nathan Rice wrote:
>
>> 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
>> Two dicts created from the same inputs will return items in the same
>> arbitrary order. As long as you don't insert or delete a key you're
>> fine.
>>
> Two dicts that contain the same keys and values may or may not return them
> in the same order:
>
dict.fromkeys('ia')
> {'i': None, 'a':
On Thu, Feb 9, 2012 at 11:35 AM, Ian Kelly wrote:
> On Thu, Feb 9, 2012 at 8:19 AM, Nathan Rice
> wrote:
>> As I said, two dictionaries created from the same input will be the
>> same...
>
> That's an implementation detail, not a guarantee. It will hold for
> cur
On Thu, Feb 9, 2012 at 8:24 PM, Steven D'Aprano
wrote:
> On Thu, 09 Feb 2012 09:35:52 -0700, Ian Kelly wrote:
>
>> On Thu, Feb 9, 2012 at 8:19 AM, Nathan Rice
>> wrote:
>>> As I said, two dictionaries created from the same input will be the
>>> same...
&
On Fri, Feb 10, 2012 at 5:08 AM, Chris Angelico wrote:
> On Fri, Feb 10, 2012 at 1:30 PM, Nathan Rice
> wrote:
>> The only thing needed to avoid the hash collision is that your hash
>> function is not not 100% predictable just by looking at the python
>> source code. I
>> Lets also not forget that knowing an object is immutable lets you do a
>> lot of optimizations; it can be inlined, it is safe to convert to a
>> contiguous block of memory and stuff in cache, etc. If you know the
>> input to a function is guaranteed to be frozen you can just go crazy.
>> Being
> And I'll take this opportunity to plug my dualmethod descriptor:
>
> http://code.activestate.com/recipes/577030-dualmethod-descriptor/
I use an analogous pattern in SQL Alchemy all the time (it's called
hybridmethod/hybridproperty there).
+1 to dualmethod, that pattern is great when you want a
> Hopefully soon crate.io will be useful for finding modules ;) I have plans
> for it to try and, encourage people to host their code and encourage
> following packaging standards. I'm currently focused mostly on the backend
> stability (e.g. getting it stable) but emphasizing things that are gener
Just to troll the discussion a little bit more...
On Sun, Mar 18, 2012 at 6:02 PM, 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
>> This is one of my gripes with the dogmatic application of the "break it
>> into multiple statements" mantra of Python.
>
> I must admit I don't recognise that one, unless you're talking about "not
> everything needs to be a one liner".
> ...
> Perhaps you could give some examples (actual or cont
>>> The fact that scientific journal articles start with a documentation
>>> string
>>> called an abstract does not indicate that scientific English fails as a
>>> human communication medium. Function docstrings say what the function
>>> does
>>> and how to use it without reading the code. They can
>> One example is performing a series of transformations on a collection of
>> data, with the intent of finding an element of that collection that
>> satisfies a particular criterion. If you separate out the individual
>> transformations, you need to understand generators or you will waste
>> spac
MOAR TROLLING...
>> 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
>> If I'm reading you correctly, you're expressing frustration with the
>> state of language syntax unification in 2012. You mention language in a
>> broad sense (not just programming languages, but also English, math,
>> logic, etc.), but even in the narrow context of programming languages,
>> th
On Thu, Mar 22, 2012 at 9:17 AM, Chris Angelico wrote:
> On Thu, Mar 22, 2012 at 11:47 PM, Nathan Rice
> wrote:
>> Having one core language with
>> many DSLs that can interoperate is infinitely better than having many
>> languages that cannot. A language designed
>> There is a concept in statistical/mathematical modeling called minimum
>> message length (a close analog is minimum description length), which
>> asserts that the optimum model for some set of information is the one
>> that minimizes the sum of the length of the model and the length of the
>> se
>> For example, your ability to reason about the behavior of the system
>> you posited as a whole is limited. Are there parts of the different
>> modules that can execute concurrently? Is the output of module1
>> guaranteed to be acceptable as the input for module2? Is part of
>> module3 redunda
>> Do you think we'll always have a huge number of incompatible
>> programming languages? I agree with you that it's a fact of life in
>> 2012, but will it be a fact of life in 2062?
>
> It will be a fact of life wherever Godels theorem is; which put
> simplistically is: consistency and completene
Logo. It's turtles all the way down.
--
http://mail.python.org/mailman/listinfo/python-list
> I will use "<=>" to mean "is equivalent to". That's not part of the DSL.
> A flow has one or more streams:
> 1 stream:
> [1,2,3]
> 2 streams:
> [1,3,5] | [2,4,6]
> Two flows can be concatenated:
> [1,2,3] + [4,5,6] <=> [1,2,3,4,5,6]
> [0] + ([1,2] | [3,4]) + [10] <=> [0,1,2,10] | [0,3,4
>>> I will use "<=>" to mean "is equivalent to". That's not part of the DSL.
>>> A flow has one or more streams:
>>> 1 stream:
>>> [1,2,3]
>>> 2 streams:
>>> [1,3,5] | [2,4,6]
>>> Two flows can be concatenated:
>>> [1,2,3] + [4,5,6]<=> [1,2,3,4,5,6]
>>> [0] + ([1,2] | [3,4]) + [
>> I understand what
>> you're trying to communicate, so I think you need to be a little more
>> strict and explicit in your definitions.
>
>
> No, I don't think you understand what I meant.
I don't agree. Sorry.
> Yes. I thought that streams as an alternative to functional programming were
> wi
On Wed, Mar 28, 2012 at 9:33 PM, Chris Angelico wrote:
> On Thu, Mar 29, 2012 at 11:59 AM, Rodrick Brown
> wrote:
>> The best skill any developer can have is the ability to pickup languages
>> very quickly and know what tools work well for which task.
>
> Definitely. Not just languages but all
On Thu, Mar 29, 2012 at 10:03 AM, Chris Angelico wrote:
> On Fri, Mar 30, 2012 at 12:44 AM, Nathan Rice
> wrote:
>> We would be better off if all the time that was spent on learning
>> syntax, memorizing library organization and becoming proficient with
>> new tool
On Thu, Mar 29, 2012 at 2:53 PM, Devin Jeanpierre
wrote:
> Agreed with your entire first chunk 100%. Woohoo! High five. :)
Damn, then I'm not trolling hard enough ಠ_ಠ
> On Thu, Mar 29, 2012 at 1:48 PM, Nathan Rice
> wrote:
>> transformations on lists of data are natura
On Thu, Mar 29, 2012 at 9:44 AM, Albert van der Horst
wrote:
> In article ,
> Nathan Rice wrote:
>>>
>>> http://www.joelonsoftware.com/articles/fog18.html
>>
>>I read that article a long time ago, it was bullshit then, it is
>>bullshit now.
On Thu, Mar 29, 2012 at 7:37 PM, Devin Jeanpierre
wrote:
> On Thu, Mar 29, 2012 at 3:50 PM, Nathan Rice
> wrote:
>> Well, a lisp-like language. I would also argue that if you are using
>> macros to do anything, the thing you are trying to do should classify
>>
> He did no such thing. I challenge you to find me one place where Joel has
> *ever* claimed that "the very notion of abstraction" is meaningless or
> without use.
"When great thinkers think about problems, they start to see patterns.
They look at the problem of people sending each other word-proc
>>> He did no such thing. I challenge you to find me one place where Joel
>>> has *ever* claimed that "the very notion of abstraction" is meaningless
>>> or without use.
> [snip quote]
>> To me, this directly indicates he views higher order abstractions
>> skeptically,
>
> Yes he does, and so we al
>> Here's a thought experiment. Imagine that you have a project tree on
>> your file system which includes files written in many different
>> programming languages. Imagine that the files can be assumed to be
>> contiguous for our purposes, so you could view all the files in the
>> project as one
>> Mathematics is all about abstraction. There are theories and structures
>> in mathematics that have probably gone over a hundred years before being
>> applied. As an analogy, just because a spear isn't useful while farming
>> doesn't mean it won't save your life when you venture into the woods
On Fri, Mar 30, 2012 at 12:20 PM, Chris Angelico wrote:
> On Sat, Mar 31, 2012 at 12:46 AM, Nathan Rice
> wrote:
>> I believe in the idea of "things should be as simple as possible, but
>> not simpler". Programming as it currently exists is absolutely
>> c
> This is more a matter of being unable to express themselves
> appropriately. If I allowed them to write an exact process of steps to
> do what's required, those steps would either be grossly insufficient
> for the task, or would BE pseudo-code. There are plenty of people who
> cannot write those
On Fri, Mar 30, 2012 at 4:20 PM, Chris Angelico wrote:
> On Sat, Mar 31, 2012 at 6:55 AM, Nathan Rice
> wrote:
>> I think you'd find that these "non coders" would do very well if given
>> the ability to provide instructions in a natural, interactive way.
&
On Fri, Mar 30, 2012 at 5:45 PM, Chris Angelico wrote:
> On Sat, Mar 31, 2012 at 7:58 AM, Nathan Rice
> wrote:
>> Programming
>> language designers purposefully try to make their language C-like,
>> because not being C-like disqualifies a language from consideration
On Sat, Mar 31, 2012 at 2:15 AM, Lie Ryan wrote:
> On 03/21/2012 03:55 AM, Nathan Rice wrote:
>>
>>
>
> I think you've just described that greedy algorithm can't always find the
> globally optimal solution.
Right. Using gradient descent on an algebraic su
On Sun, Apr 1, 2012 at 11:18 PM, alex23 wrote:
> On Mar 30, 3:37 pm, Nathan Rice
> wrote:
>> We live in a world where the tools that are used are based on
>> tradition (read that as backwards compatibility if it makes you feel
>> better) and as a mechanism for deriving
On Tue, Apr 3, 2012 at 1:40 AM, alex23 wrote:
> On Apr 3, 2:55 pm, Nathan Rice
> wrote:
>> I don't care what people do related to legacy systems.
>
> And that's what earns you the label 'architecture astronaut'. Legacy
> systems are _part_ of the pro
On Tue, Apr 3, 2012 at 9:51 AM, rusi wrote:
> On Apr 3, 5:39 pm, Nathan Rice
> wrote:
>>
>> Don't think "underlying", instead think "canonical".
>>
>> Ultimately, the answers to your questions exist in the world for you
>> to see.
On Tue, Apr 3, 2012 at 11:01 AM, Ian Kelly wrote:
> On Tue, Apr 3, 2012 at 6:39 AM, Nathan Rice
> wrote:
>> Did you miss the part where I said that most people who learn to
>> program are fascinated by computers and highly motivated to do so?
>> I've never met a BRO
pes are a tool that astronomers use to view the stars.
On Tue, Apr 3, 2012 at 1:25 PM, rusi wrote:
> All this futuristic grandiloquence:
>
> On Apr 3, 10:17 pm, Nathan Rice
> wrote:
>> The crux of my view is that programming languages exist in part
>> because computers in
On Tue, Apr 3, 2012 at 4:20 PM, Terry Reedy wrote:
> On 4/3/2012 8:39 AM, Nathan Rice wrote:
>
>> Ultimately, the answers to your questions exist in the world for you
>> to see. How does a surgeon describe a surgical procedure? How does a
>> chef describe a recip
On Wed, Apr 4, 2012 at 1:49 AM, Steven D'Aprano
wrote:
> On Tue, 03 Apr 2012 13:17:18 -0400, Nathan Rice wrote:
>
>> I have never met a programmer that was not completely into computers.
>> That leaves a lot unspecified though.
>
> You haven't looked hard enough.
> Long personal note ahead.
> tl;dr version: Computers are such a large shift for human civilization
> that generally we dont get what that shift is about or towards.
Another option: since *computers* are such a general device, there
isn't just one notion.
> In the long run I expect computing sci
> The "building cabinets" problem is interesting:
>
> 1. To actually build a cabinet, there's a lot of domain knowledge
> that's probably implicit in most circumstances. A carpenter might
> tell another carpenter which hinge to use, but they won't have to talk
> about why doors need hinges or how
Re-trolling.
On Wed, Apr 4, 2012 at 1:49 AM, Steven D'Aprano
wrote:
>> As part of my troll-outreach effort, I will indulge here. I was
>> specifically thinking about some earlier claims that programming
>> languages as they currently exist are somehow inherently superior to a
>> formalized natur
public FooClass(String requiredArgument1, Long requiredArgument2, map
yourOptionalArgumentMap) {
...
}
--
http://mail.python.org/mailman/listinfo/python-list
Since this happily went off to the wrong recipient the first time...
The python json module/simpljson are badly in need of an architecture
update. The fact that you can't override the encode method of
JSONEncoder and have it work reliably without monkey patching the pure
python encoder is a sign
Just a random note, I actually set about the task of re-implementing a
json encoder which can be subclassed, is highly extensible, and uses
(mostly) sane coding techniques (those of you who've looked at
simplejson's code will know why this is a good thing). So far
preliminary tests show the json o
shoots down my patch for contrived reasons. I don't know what the
python committers are like but I guess you could say I'm once bitten
twice shy.
Nathan
On Fri, Oct 28, 2011 at 4:52 PM, Terry Reedy wrote:
> On 10/28/2011 1:20 PM, Nathan Rice wrote:
>>
>> Just a random n
For now, get started in Python 2.7. Write code with an eye to 3.x
portability, and you will be fine. You probably won't see 3.x
overtake 2.x for at least 3-4 years, and a decent amount of stuff is
still 2.x only. Since it sounds like you are a windows/net shop, go
ahead and use Iron Python.
SQL
Nose is absolutely the way to go for your testing needs. You can put
"__test__ = False" in modules or classes to stop test collection.
On Mon, Dec 12, 2011 at 5:44 AM, Thomas Bach wrote:
> Gelonida N writes:
>
>> Do I loose anything if using nose. or example can all unit tests / doc
>> tests st
I just ran into this yesterday, and I am curious if there is a
rational behind it...
I have a class that uses a dictionary to dispatch from other classes
(k) to functions for those classes (v). I recently ran into a bug
where the dictionary would report that a class which was clearly in
the dicti
reintroduce the bug.
Can I get confirmation that this is not expected behavior? I will go
ahead and file a bug report it that is the case.
Nathan
On Thu, Dec 15, 2011 at 10:08 AM, Dave Angel wrote:
> On 12/15/2011 09:34 AM, Nathan Rice wrote:
>>
>> I just ran into this yest
I realize this has been discussed in the past, I hope that I am
presenting a slightly different take on the subject that will prove
interesting. This is primarily motivated by my annoyance with using
comprehensions in certain circumstances.
Currently, if you want to perform successive transformat
unless you explicitly wrap the return value, which
entirely defeats the point.
On Fri, Dec 16, 2011 at 1:23 PM, Stefan Behnel wrote:
> Nathan Rice, 16.12.2011 18:48:
>
>> I realize this has been discussed in the past, I hope that I am
>> presenting a slightly different take on the
> I think there are two aspects to your idea:
> 1. collections that share a single type
> 2. accessing multiple elements via a common interface
You are correct, and I now regret posing them in a coupled manner.
> Both are things that should be considered and I think both are useful in
> some cont
per support of things like bool()
and int(), which refuse to return things that are not of the correct
type.
Get it:
PyPi: http://pypi.python.org/pypi/elementwise/0.111220
GitHub: https://github.com/nathan-rice/Elementwise
This was developed as a proof of concept for expanding the role
If you take a moment and examine the version number, you will notice
that it is a date code. In my opinion that is far more informative
than an arbitrary number. I use the major version number to
signify... Wait for it... Major changes :)
--
http://mail.python.org/mailman/listinfo/python-list
On Tue, Dec 20, 2011 at 4:00 PM, Steven D'Aprano
wrote:
> On Tue, 20 Dec 2011 15:45:07 -0500, Nathan Rice wrote:
>
>> If you take a moment and examine the version number, you will notice
>> that it is a date code.
>
> Not any date code I'm familiar with. 0.111
On Tue, Dec 20, 2011 at 7:03 PM, Ian Kelly wrote:
> On Tue, Dec 20, 2011 at 12:45 PM, Nathan Rice
> wrote:
>> There are still some issues with proper support of things like bool()
>> and int(), which refuse to return things that are not of the correct
>> type.
>
>
> efoo2 = ElementwiseProxy(["one", "two", "three", "four"])
>
> efoo_res = ((efoo2.capitalize() + " little indian").split("
> ").apply(reversed) * 2).apply("_".join) # note that you could do
> reversed(...) instead, I just like to read left to right
> efoo_res.parent.parent.parent # same as ((efoo2
On Tue, Dec 20, 2011 at 8:37 PM, Joshua Landau
wrote:
> On 21 December 2011 00:24, Nathan Rice
> wrote:
>> efoo_res = ((efoo2.capitalize() + " little indian").split("
>> ").apply(reversed) * 2).apply("_".join) # note that you could do
>> re
> Have you seen PyLINQ? It has a similar approach to operating on
> collections, returning a PyLINQ object after each call to facilitate
> chaining. https://github.com/kalessin/PyLINQ/blob/master/pylinq/linq.py
I hadn't seen it previously. I am a VERY heavy user of SQL Alchemy
though, and I am su
On Wed, Dec 21, 2011 at 11:29 AM, Robert Kern wrote:
> On 12/21/11 3:15 PM, Nathan Rice wrote:
>
>>> Incidentally, displaying an ElementwiseProxy instance doesn't go down
>>> well with iPython:
>>>
>>> In [1]: from elementwise import *
>>&
+1 for IPython/%edit using the simplest editor that supports syntax
highlighting and line numbers. I have found that
Exploring/Prototyping in the interpreter has the highest ROI of
anything I teach people.
Nathan
--
http://mail.python.org/mailman/listinfo/python-list
On Wed, Dec 21, 2011 at 12:07 PM, Paul Dubois wrote:
> You're reinventing Numeric Python.
I prefer to think of it in terms of paying homage to NumPy (and
functional programming). A big part of the motivation for this was
bringing the elegance of NumPy to other areas of python besides
numerical/s
>> On Tue, Dec 20, 2011 at 8:37 PM, Joshua Landau
>> wrote:
>> > On 21 December 2011 00:24, Nathan Rice
>> > wrote:
>> >> efoo_res = ((efoo2.capitalize() + " little indian").split("
>> >> ").apply(reversed) * 2).apply(&quo
On Wed, Dec 21, 2011 at 12:53 PM, Arnaud Delobelle wrote:
>
> You can already do:
>
> efoo2 = ["one", "two", "three", "four"]
> ["_".join(reversed((x.capitalize() + " little indian").split(" ")) * 2)
> for x in efoo2]
>
> Note 1: I've ignored the fact that reversed(...)*2 is erroneous
> Note 2
> It doesn't seem to work correctly when both operands are Elementwise:
>
numerator = ElementwiseProxy(range(5))
denominator = ElementwiseProxy([2, 2, 3, 3, 3])
remainder = numerator % denominator
print remainder
> Traceback (most recent call last):
> File "", line 1, in
> Fi
On Wed, Dec 21, 2011 at 1:24 PM, Joshua Landau
wrote:
> I was under the impression that these were meant to be interchangeable. This
> is because functions are just wrappers to non-functions, really.
>
from elementwise import ElementwiseProxy as P
(lambda x:x+[1])(P([[0],[0],[0]]))
> [0,
On Wed, Dec 21, 2011 at 1:41 PM, Ian Kelly wrote:
>
> I expected the equivalent of:
>
> remainder = [n % d for (n, d) in zip(numerator, denominator)]
>
> which is what numpy does.
I do want to come up with a nice way to do that... However:
if numerator and denominator are plain lists that magica
Just because the default python version on a server is 2.4 doesn't
mean you can't install 2.7.2... If the admins that run the machine are
too lazy/stupid to install a second copy of Python let them rot.
Of course, if by some nightmare scenario you have code that can't be
upgraded for whatever reas
On Mon, Dec 26, 2011 at 9:52 AM, Rick Johnson
wrote:
> On Dec 25, 9:27 pm, Chris Angelico wrote:
>> On Mon, Dec 26, 2011 at 4:44 AM, Rick Johnson
>> > [...]
>> Conversely, why write an IDE into IDLE when perfectly-good IDEs
>> already exist? I don't use IDLE for development per se; it's for
>> in
Quotes are obnoxious in the nesting sense because everyone uses quotes
for string delimiters. By the same token, quotes are wonderful
because not only are they intuitive to programmers, but they are
intuitive in general. Parenthesis are pretty much in the same boat...
I *HATE* them nested, but th
On Wed, Dec 28, 2011 at 4:42 PM, Chris Angelico wrote:
> On Thu, Dec 29, 2011 at 8:24 AM, Nathan Rice
> wrote:
>> Quotes are obnoxious in the nesting sense because everyone uses quotes
>> for string delimiters. By the same token, quotes are wonderful
>> because not on
On Tue, Jan 3, 2012 at 1:13 PM, Sean Wolfe wrote:
> Hello everybody, I'm a happy pythonista newly subscribed to the group.
> How is it going?
> I have a theoretical / philosophical question regarding strong vs duck
> typing in Python. Let's say we wanted to type strongly in Python and
> were willi
On Wed, Jan 11, 2012 at 4:38 PM, Emeka wrote:
> Hello All,
>
> I just made something pretty simple that I intend to use while creating
> database tables. It is still in the basic form, and much needs to be added.
> However, I use introspection to make it a bit easier and less work on the
> user.
>
Greetings,
I have been writing a lot of code lately that involves creating
symbolic expressions of one form or another, which are then fully
evaluated at a later time. Examples of this include Elementwise,
where I create expressions that act on every member of an iterable
(there is a much improve
>> I have been writing a lot of code lately that involves creating
>> symbolic expressions of one form or another, which are then fully
>> evaluated at a later time. Examples of this include Elementwise,
>
>
> Python is designed for concrete, rather than symbolic computation. But the
> latter has
On Fri, Jan 13, 2012 at 8:45 AM, Devin Jeanpierre
wrote:
> On Thu, Jan 12, 2012 at 3:45 PM, Nathan Rice
> wrote:
>> I'm interested in fixing both issues. I believe both issues I've had
>> could be solved by having a robust "symbolic object". These objects
&
Elementwise provides helpful proxy objects which let you perform a
series of computations on every element of an iterable or graph, in a
lazy manner.
Docs: http://packages.python.org/elementwise/
GitHub: https://github.com/nathan-rice/Elementwise
Examples:
The standard ElementwiseProxy
I was just wondering, why the list/generator and standard "for" have
disparities?
It would be really nice to be able to do:
for x in y if foo:
...
rather than:
for x in (x for x in y if foo):
...
Also, from a style standpoint, I prefer to extract the loop logic into a
function if it's
itertools is also written in c, so if you're working with a big nested list
is long it will be a lot faster.
On Sat, May 8, 2010 at 5:40 PM, Tycho Andersen wrote:
> On Sat, May 8, 2010 at 4:09 PM, Günther Dietrich
> wrote:
> [snip]
> > Too simple?
>
> No, not at all. I really only intended to p
This is precisely the situation mmap was made for :) It has almost the same
methods as a file so it should be an easy replacement.
On Sat, May 15, 2010 at 10:05 AM, Nobody wrote:
> On Fri, 14 May 2010 18:38:55 -0400, J wrote:
>
> >>> someone smarter than me can correct me, but file.write() will
I'm trying to do some fairly deep introspection and instrumentation of
instances and classes at runtime, and in order for everything to be properly
behaved I need to have radically different behavior in the event that the
thing passed to me is a wrapped class/instance. Is there a really good way,
I prefer to just break such things into multiple lines. You're doing that
already anyhow, it's not much of a speed hit, and it makes exactly what
you're testing explicit. If I break a statement onto multiple lines I only
use parenthesis, and that is as a last resort. In my opinion there's almost
My apologies if someone already mentioned this and I missed it but...
class.__instancecheck__(self, instance) - Return true if instance
should be considered a (direct or indirect) instance of class. If
defined, called to implement isinstance(instance, class).
class.__subclasscheck__(self, subclas
I've been running into a problem lately where I have an architecture like so:
Main class -> facade/configuration class -> low level logic class.
The main class is what the user interacts with.
The facade/config class is responsible for loading and managing the
lower level classes and providing a
It really depends on what you want to do. Ruby and Python are both highly
expressive languages. Python syntax seems "nicer" to me but that is
subjective.
As far as community support, Python has 4342 packages listed in sourceforge,
Ruby has 705. Python is listed in ~0.4% of jobs at indeed.com's
As others have mentioned when you would like to encapsulate data and
functions together, they're useful.
Also, if you find yourself passing lists/tuples/dictionaries around
frequently, you might benefit from converting them into classes. This tends
to make the code clearer and more readable, you
You are thinking like a C programmer
Why do you want the language to tie your hands? I want a language to give
me the tools I need and get out of the way. The more assumptions that are
baked into a language the more opportunities it has to be wrong.
Furthermore, object oriented design is a
I solve optimization problems like this all the time using branch and bound.
Just arrange the possible scenarios into a state space tree, (ideally
ordered by lowest average cost supplier) then prune any branch where the
best case scenario given supplier cost plus shipping cost summed over all
remai
Add the parent directory to your sys.path...
On Fri, Jun 25, 2010 at 5:20 PM, Nathan Huesken wrote:
> Hi,
>
> Is it somehow possible to import modules from *.py files in a higher
> level directory?
> Intuitively I would do
>
> import ../module
>
> but that does not work.
> How does it work?
>
> T
1 - 100 of 109 matches
Mail list logo
