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
> 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
> 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
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.
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
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 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
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 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 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 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 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 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.
&
> 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 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
>> 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
>> 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
>>> 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
> 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
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
>>
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 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 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 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
>> 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
>>> 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 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
Logo. It's turtles all the way down.
--
http://mail.python.org/mailman/listinfo/python-list
>> 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
>> 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
>> 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
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
>> 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
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
>> 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
>>> 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
>> 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
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
> 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
> 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
>> 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
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
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 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
>> 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 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
> 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
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
>> 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
> 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(
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
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
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
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
&
>> 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
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
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.
>
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, 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
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 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
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 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
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,
> 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 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
>> 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: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
+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 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 *
>>&
> 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 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
> 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 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.
>
>
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
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
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
> 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
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 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
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 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
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
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
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
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
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
public FooClass(String requiredArgument1, Long requiredArgument2, map
yourOptionalArgumentMap) {
...
}
--
http://mail.python.org/mailman/listinfo/python-list
> Oh yes, I'd rather write lines of that rather than pages of SQL in a Python
> string.
(not to mention, avoid some easy to fall into security flaws, not have
to worry about porting dialect specific SQL code, etc, etc).
Fixed that for you. I can't take the credit for that part though,
that magi
Struqtural makes it easy to get data into a database, and easy to work
with it once it's there. Some of the big features include:
* Automatically generate all tables and relations needed to represent
XML in a database, including one to one, one to many, many to one and
many to many relationships
ue, Jul 13, 2010 at 8:48 PM, Aahz wrote:
> [Original not available on my swerver, responding here]
>
> >On 7/11/10 10:03 PM, Nathan Rice wrote:
> >>
> >> Yeah, I long ago filed the in place place in the same folder as
> >> strings-as-sequences, all() returni
Stephen:
I'm not adverse to being able to do that, but the number of times that I've
wanted to do that is greatly outweighed by the number of times I've had to
pass a function "(somestring,)" or call "if isinstance(foo, basestring):
..." to avoid producing a bug. The more abstract and adaptive th
Yeah, I long ago filed the in place place in the same folder as
strings-as-sequences, all() returning True for an empty iterable and any
returning True rather than the thing which triggered it. Almost always
annoying and worked around, but that's the price you pay for the other nice
stuff :) It j
Do list(reversed(list(reversed([1, 2, 3, 4])) + [[]]))
Though TBH sometimes get annoyed at this behavior myself. There are a lot
of people who are very vocal in support of returning none, and it makes
sense in some ways. Since reversed returns an iterator though, it makes
this code horrible and
I start to look at whether some subset of functions or classes are not
referenced by other subsets of functions or classes in a module when it gets
to about 1K LoC, and if I don't find any by the time it gets to about 1500
LoC, I start to look at ways I can refactor the code in the module to be
les
Expert Python Programming by Tarek Ziade is a fairly good book, covers a lot
of core stuff, though it doesn't really cover gui app development at all.
On Sat, Jul 3, 2010 at 1:48 PM, mo reina wrote:
> an anyone recommend a resource (book,tutorial,etc.) that focuses on
> application development in
I like to think of decorators with arguments as decorator factory functions.
I try and unroll them as much as possible... I have some decorators that
work like so (and please note that the wraps and returns_as_output are
separate so that I can mutate the behavior as needed, if you just wanted a
si
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
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
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
1 - 100 of 109 matches
Mail list logo
