Am 24.07.2013 20:44, schrieb Joachim Durchholz:
Oh, I can run the tests no problem.
The issue is that whenever I do a cross-cutting change, I need to run
the full test suite, and I won't know whether I broke anything until a
full day later. That's going to slow down progress quite a bit.
But if 4
Hi,
I am developing a Package under PyDy, for GSoC.
This is my directory structure.
pydy/
- __init__.py
-pydy_viz/
-__init__.py
--shapes.py
--tests\
Have you tried? I assure you, you can create classes with constructors
which signature differs from the signature of the superclass constructor.
Anyway, even if you prefer to use `__new__`, you still need to pay
attention to the `args` attribute.
Also, keep in mind that what you are doing mixes t
Great work!
On Jul 26, 2013 1:52 AM, "Ondřej Čertík" wrote:
> On Thu, Jul 25, 2013 at 10:01 AM, Mary Clark
> wrote:
> > I've fixed up PR 2259 (https://github.com/sympy/sympy/pull/2259) and all
> > tests on travis pass (except for some timeouts)
> > https://travis-ci.org/sympy/sympy/builds/947684
Hi,
On Thu, Jul 25, 2013 at 8:40 AM, Ondřej Čertík wrote:
> On Thu, Jul 25, 2013 at 8:45 AM, Aaron Meurer wrote:
>> I'll ask here what I asked on the pull request. Can you give a list of
>> the things that we would have to do to support both. I'm concerned
>> about the annoyance factor here. Obv
On Thu, Jul 25, 2013 at 10:51 AM, Aaron Meurer wrote:
> On Thu, Jul 25, 2013 at 10:54 AM, Ondřej Čertík
> wrote:
>> On Thu, Jul 25, 2013 at 9:41 AM, Sean Vig wrote:
>>> Most of the things in compatibility aren't too annoying, things that moved
>>> or are renamed, but otherwise function exactly
On Thu, Jul 25, 2013 at 10:01 AM, Mary Clark wrote:
> I've fixed up PR 2259 (https://github.com/sympy/sympy/pull/2259) and all
> tests on travis pass (except for some timeouts)
> https://travis-ci.org/sympy/sympy/builds/9476843 so I think that PR is
> probably ready to be merged as well.
Awesome!
On Thu, Jul 25, 2013 at 10:54 AM, Ondřej Čertík wrote:
> On Thu, Jul 25, 2013 at 9:41 AM, Sean Vig wrote:
>> Most of the things in compatibility aren't too annoying, things that moved
>> or are renamed, but otherwise function exactly the same.
>>
>> One big annoyance was working with unicode stri
Okay. So, this is what happens if I use __init__:
Symbol.__new__ is called. Here's the definition:
def __new__(cls, name, **assumptions):
"""Symbols are identified by name and assumptions::
As you can see, the method expects 2 positional arguments and rest are
keyword arguments (the assu
> But, that's what's happening right now as well. Symbol.__new__ is called
and it is cached. Therefore, the problem persists.
Except that you will probably have the correct `args`. Check this first.
I do not understand what is the issue with Symbol's __new__ could you show
the code that actually
@Stefan : Let us say I use __init__ instead. When I initialize a
BaseScalar, since a __new__ method isn't defined, that means the __new__ of
superclass (Symbol) will be called.
But, that's what's happening right now as well. Symbol.__new__ is called
and it is cached. Therefore, the problem pers
On Thu, Jul 25, 2013 at 10:41 AM, Sean Vig wrote:
> Most of the things in compatibility aren't too annoying, things that moved
> or are renamed, but otherwise function exactly the same.
>
> One big annoyance was working with unicode strings and checking unicode
> string output. The u'string' synta
I've fixed up PR 2259 (https://github.com/sympy/sympy/pull/2259) and all
tests on travis pass (except for some timeouts)
https://travis-ci.org/sympy/sympy/builds/9476843 so I think that PR is
probably ready to be merged as well.
--
You received this message because you are subscribed to the Go
On Thu, Jul 25, 2013 at 9:41 AM, Sean Vig wrote:
> Most of the things in compatibility aren't too annoying, things that moved
> or are renamed, but otherwise function exactly the same.
>
> One big annoyance was working with unicode strings and checking unicode
> string output. The u'string' syntax
I'm also impressed by this work. I don't have thoughts on whether or not
it should be included but am happy to also contribute a beer :-)
On Thu, Jul 25, 2013 at 10:40 AM, Ondřej Čertík wrote:
> On Thu, Jul 25, 2013 at 8:45 AM, Aaron Meurer wrote:
> > I'll ask here what I asked on the pull req
Most of the things in compatibility aren't too annoying, things that moved
or are renamed, but otherwise function exactly the same.
One big annoyance was working with unicode strings and checking unicode
string output. The u'string' syntax doesn't work in 3.2 (though it was
re-introduced in 3.3),
On Thu, Jul 25, 2013 at 8:45 AM, Aaron Meurer wrote:
> I'll ask here what I asked on the pull request. Can you give a list of
> the things that we would have to do to support both. I'm concerned
> about the annoyance factor here. Obviously, we've had a compatibility
> file for some time, so we are
Yes, this probably wasn't clear enough in my previous responses, but
the sets module is very descriptive and well-developed (OK, there's
still work that needs to be done, but it's coming along nicely). If
you just want to represent a set, you can probably do it.
Aaron Meurer
On Thu, Jul 25, 2013
Ah, that *might* be considered a bug. Our assumptions system(s) don't
really have a clear distinction between real numbers and extended real
numbers, unfortunately.
Aaron Meurer
On Wed, Jul 24, 2013 at 9:27 PM, Ben Lucato wrote:
> Yeah I initially thought of doing this - but say I want to do:
>
I don't understand your reasoning for needing multiple objects with
the same name.
If these objects are supposed to be different, they should be made so
by including all the identifying information in .args (or if that
doesn't make sense, by overriding __eq__ and _hashable_content).
By the way, u
You almost never want to generate a symbol yourself (in library code)
because you never know whether the user is using a the same name (pretty
much the whole point of symbols are that they are "things" identified only
by name).
So you have two options:
1. use Dummy
2. appropriately add additional
I have subclassed Symbol, like so:
class BaseScalar(Symbol):
"""
BaseScalar instances are used to express coordinate variables for field.
Not to be instantiated by the user.
"""
def __new__(cls, name, coord_sys, position, **assumptions):
if (position not in ['1', '2', '
I'll ask here what I asked on the pull request. Can you give a list of
the things that we would have to do to support both. I'm concerned
about the annoyance factor here. Obviously, we've had a compatibility
file for some time, so we are no strangers to such things, but I'd
like to know what we'd b
For anyone that's interested, I have a WIP branch up [1] that has supports
both Python 2 and 3 from a single codebase. All the tests and doctests are
passing, but there are a couple things that still need to be worked out
before it would be ready to go.
Sean
[1] https://github.com/sympy/sympy/pul
Oh sick - intervals are exactly what I'm looking for. Thanks!
On Thursday, 25 July 2013 22:39:36 UTC+10, Matthew wrote:
>
>
> Since it's for my own purposes I really could represent it with nested
>> lists/tuples, using booleans to include a value or not:
>>
>> [[(-sympy.oo, False), (-1, True)],
Feel free to update me on an incomplete implementation as well. I'm happy
to provide feedback on a half-complete pull request. That will probably
save you some work.
On Thu, Jul 25, 2013 at 5:35 AM, Sreeraj Rajendran wrote:
> Hi Matthew,
>
> Thank you for the crystal clear explanation. Will up
> Since it's for my own purposes I really could represent it with nested
> lists/tuples, using booleans to include a value or not:
>
> [[(-sympy.oo, False), (-1, True)], [(0, False), (sympy.oo, True)]]
>
> which represents (-inf, -1] U (0, inf)
>
For this all you need is sets. Note that they use
Hi Matthew,
Thank you for the crystal clear explanation. Will update you once my
implementation is complete.
-Sreeraj
On Wednesday, July 24, 2013 7:15:31 PM UTC+5:30, Matthew wrote:
>
> Hi Sreeraj
>
> Stefan is correct that you should not expect operations from sympy.physics
> to interoperate
28 matches
Mail list logo
