There is a pull request that needs some love at the moment concerning
the gaussian optics module:
https://github.com/sympy/sympy/pull/1226
It was started by @alxpopov and it contains some nice features,
however neither I nor he has got the time to finish it. Just check out
the comments on the pul
Hi all,
My connection will be very patchy for the next 4 or 5 days. I will be
able to continue working from my local repo, however I won't be able
to turn off the bot if there is some new issue, so I am turning it off
now for the next 4 days. I will still be able to check email in case I
need to h
> In [65]: for i in range(3):
>: for j in range(3):
>: if i <= j:
>:for l in range(6):
>:J[k,l] = diff(Y[i,j], vars[l])
>:k=k+1
>:
> IndentationError: expected an indented block
Is the indentation consistent - It see
However the commutator in the diffgeom module is between differential
operators. It is not exactly what you ask for. Actually I do not
understand how "x" acts on anything in your example as it is not a
differential operator (it can be regarded as a hermitian operator as
in quantum mechanics "acting
You can emulate this behavior with the diffgeom module on which I am
working (the version in master is out of date, you can check out the
pull request)
Vector fields are differential operators:
from sympy.diffgeom.Rn import R2 # the R^2 manifold
derivative_wrt_x = R2.e_x # the base vector along t
> However, the point on which I do not agree is that Matthew suggested
> extending something for rewriting **non-atomic** subtrees in the
> expression tree. The precise example (in lisp syntax) was:
>
> (/ (sin x) (cos x)) ---> (tan x) **In replace-like routine, not in a
> simplify-like routine.*
e reliable only for matching
structurally equivalent subtrees, not mathematically equivalent
subtrees. To me this means that it would be a bad idea to extend
replace/subs/match with heuristics concerning equivalence of subtrees.
On 11/08/2012, Joachim Durchholz wrote:
> Am 10.08.2012 15:02,
August 2012 16:02, krastanov.ste...@gmail.com
wrote:
>>> I would guess that it is impossible in general. I think that there is
>>> a theorem saying that in a system including as many mathematical
>>> functions as SymPy has it is impossible to have equality checking - it
&
>> I would guess that it is impossible in general. I think that there is
>> a theorem saying that in a system including as many mathematical
>> functions as SymPy has it is impossible to have equality checking - it
>> will always fail in some corner cases.
>
>
> That's Gödel's incompleteness theore
> But that deals with things like determining mathematical equality.
> Pattern matching should only deal with structural equality (and
> perhaps some mathematical heuristics to make life easier).
Yes, however isn't sin(x)/cos(x) == sin(x)*1/cos(x) the same issue?
And this is a problem when one wan
> I.e. what is necessary to get this working
>
> transform(sin(x)/cos(x) + sin(y)/cos(y),from=sin(z)/cos(z),
> to=tan(z))
>
> to produce
>
> tan(x) + tan(y)
Only the rewrite example does exactly this (meaning that it does not
depend on arguments (z or x)). However it requires simplificatio
> How big a project do you think it would be to get something like the above
> working? Does it just require a better match system? Has there been work on
> this in the past? (match predates my involvement in SymPy).
I would guess that it is impossible in general. I think that there is
a theorem s
Hi all,
It seems that after some recent fixes most of the tests ran by my bot
pass. I suppose that the most obvious of the issues with hash
randomization have been addressed by Chris and Aaron, right?
Does this mean that travisCI can now turn on hash randomization?
Stefan
--
You received this
Thanks for the explanation. At some point I will move all this to the
issues list.
>> - currently it overrides get_segments and get_points. Won't it be
>> cleaner if it overrides only get_points? Why not? (I think it will be
>> cleaner because the base LineSeries class already implements
>> get_s
> Slightly related: does anyone know how to configure github to get the old
> behaviour back - i.e. get all PR announcements, but the discussion only if
> you participate? I'm afraid to disable something and then miss the
> announcements, but I'm also not too happy about being swamped...
I would l
> I'll be happy to change the sympy-patches list to whatever works for
> everybody.
>
> What github settings do you think we should set with regards to sympy-patches?
It does not seem like there is much that can be changed. That is ok,
it can be handled with filters in gmail. I just wanted be sur
> I *think* the problem is that you (by running the bot) are a
> collaborator on all PRs so you get the mail. Otherwise, if you don't
> enter comments in review you only get the initial announcement.
This is true, however in addition *since yesterday* I am getting each
message twice - one addition
I was checking the code again recently and now I have a few new
questions about the adaptive sampling (this is part of a gsoc project,
however the questions are to anybody interested):
- currently there is duplication of code in the sampling method for
line plots and parametric line plots. Is it
After the change in the notification system at github it seems that
sympy-patches receives all discussions concerning a PR and not only
the announcement.
I would like to know whether this is the way that it would be used in
the future in order to set my mail filters accordingly.
--
You received
Hi all,
Recently I got to work some more with the matrices module (rref,
jordan form for the ODE solver and various coordinate related
transformations for the diffgeom module).
The current approach to the issue of Matrix not being a Basic subclass
is to use another class called ImmutableMatrix. T
> I think there may be some 3.3 problems with hash randomization still. For
> example 1462. Also, when running use2to3, there is a problem in some
> docstring, which I think 1463 is trying to address.
My test-runner has randomizations turned on as suggested by Aaron, so
if something is failing in
I am unsure how setup.py works, however it may need to be updated with
the knowledge about my new module (as it is still WIP I have not done
that yet).
I personally just add my git folder to the PATH, so I never install it.
--
You received this message because you are subscribed to the Google Gr
Hello,
I have been playing with implementing jordan forms and generalized
eigenvectors on and off for the last week and a half. It is not
directly related to my gsoc so I have not spent much time on it,
however it will permit extending the ODE system solver which I was
implementing and which is us
> Hi,
>
> As many of you have already noticed, while running the tests, this
> test fails. I would love to help in solving this problem but I am not
> able to find previous discussion on this topic. Has anyone pondered
> about this problem before?
Are you saying that it is failing in master?
This
> 1.) What ode integrator and languages combinations do people commonly use or
> you would want support for.
I would gues that this is one obvious choice: scipy.integrate.odeint
However, whatever you choose, check out all the discussions about
lambdify. It would be certainly nice to have actual c
> 1.) Upon having done the kinematics and subequently developing a lagrangian,
> the user initializes the lagrange object where the lagrangian, L, is the
> argument.
>
> l = Lagrange(L)
What is L? Just an expression?
>
> 2.) The user then supplies a list of generalized coordinates using the
> coor
>>
>> You could implement the Moore-Penrose Pseudoinverse easily by using the
>> currently implemented SVD.
Thanks, I will check this too.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To u
What is irritating is that this is already implemented the solvers
module, however in form that does not permit working with matrices.
On 29 July 2012 17:18, krastanov.ste...@gmail.com
wrote:
> I need it for a calculation of generalized eigenvectors which is
> needed for a calculation
I need it for a calculation of generalized eigenvectors which is
needed for a calculation of the jordan normal form which is needed for
the ode solver when the system is not diagonalizable.
I have almost finished a certain version that projects to a space
orthogonal to the nullspace, however it is
Hi,
Sorry for the late reply.
I think that this person has implemented what you are looking for as
part of his project:
https://github.com/bjodah/mdiosvcor
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@goo
> print(summation(b_i*x(n-i),(i, 0, 4)))
> Error message is: name b_i not defined
There are two issues:
`b_i` has nothing to do with `i`
`x` is not a callable and `x(1)` is unrelated to `x1`
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to t
I am trying to summarize:
- say that sympy will never support "named objects that must have args"
OK, if we give up on obj.func(*obj.args)==obj. We do not want to do it
because it is a useful invariant. Example where doing it may be
harmful is MatrixSymbol(name, dim1, dim2) where we may want to
s
> So the way forward is to choose between (I may be missing alternative
> options):
>
> - say that sympy will never support "named objects that must have args"
> - use Symbol when we need name strings
> - redefine what an atom is and correct each failing algorithm one by one
>
> The first one i
> Symbol is perfectly consistent with sympy's existing object model. Since
> it's an Atom, it doesn't have args and is free to use whatever
> attributes it needs.
>
> OTOH, what MatrixSymbol does is wrong and unsupported. Being an Atom and
> having args is inconsistent and causes problems for algor
> I fell it's necessary to point out that the original purpose of
> constant_renumber was to make the constant numbering come out in order
> in the final printed expression, to as much degree possible. It's use
> as a testing canonicalizer was a secondary use that was not even
> considered in the o
>> could also expand the class structure so that there is a base class to
>> Symbol that is only a string encapsulation, and subclasses for Symbol,
>> and other things like BooleanSymbol.
>
> Having a base class for named objects would be good, but it can only
> work for atoms, as non-atoms can't h
Well, the explanation is mundane. It is just a new change and the fact
that _hashable_content is an expression instead of a tuple just
slipped through.
Here is the fix https://github.com/sympy/sympy/pull/1437
On 22 July 2012 01:06, krastanov.ste...@gmail.com
wrote:
> The problem is that S
The problem is that Subs has wrong _hashable_content()
I will send a pull request with a fix.
However I am still interested to know how this was never before
encountered. What was so special about this expression that it raised
an error?
On 22 July 2012 01:02, krastanov.ste...@gmail.com
wrote
>>> (g(f(x))*Subs(Derivative(1, x), (x,), (1,))).diff(x)
TypeError: object of type 'Derivative' has no len()
Simplifying the expression any further makes the error go away (for
instance removing the call to g).
What perplexes me is how unremarkable the expression is. What can
cause the error? An
Or the other obvious solution is to make it official that objects that
want a name subclass (or contain in their args) an instance of Symbol.
It is much easier as a solution (however rather hackish).
I am just asking the community about what should the "canonical" way
to do it be.
--
You receiv
At least once it was stated that the preferred way to get a named
object is to subclass from Symbol and basically use Symbol as a string
class.
This is so because many recursion algorithms in SymPy assume that
every element of args subclasses Basic. This is a reasonable
requirement for all objects
Just a quick suggestion if someone feels like doing it.
There is a relatively new function in matplotlib that permits plotting
triangular meshes. This is exactly the feature that was blocking the
creation of adaptive sampling methods for the plotting module. If
someone is interested to do it, you
>From the formula provided in wikipedia one can switch (by
rewrite(cos,sin)) to the formula that uses only cos or sin. It is
inefficient, however for general use I would prefer this, because the
other direction (from only cos or sin to an expression in which the
total order is the same) is not poss
> It uses is_Atom for the base case.
Why is is_Atom preferable to (not hasattr(obj, 'args') or not obj.args)?
Is not is_Atom redundant (i.e. mostly the same as args==(,)), and with
limited scope (i.e. breaks when args contain non-Basic)?
--
You received this message because you are subscribed to
I have questions about this:
> In my branch where I'm fixing expand, I've moved the base _eval_expand
> functions to Expr. The result is that for expand to work on an
> object, it must be rebuildable via obj.func(*obj.args).
But how does then Symbol work? Are you just making a special case for
i
> As for the plotting module, i'm trying to settle down with matplotlib.
Good idea. That is why the plotting module actually uses matplotlib.
It just does all the evaluations, etc automatically for you (in a
faster manner than what you get by using .evalf())
--
You received this message because y
And sympy has a new plotting module that may fulfill your needs. Check
it out if you are interested. It is in our git repository.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscrib
This is basically a characteristic of numpy. sympy.Float supports the
interfaces required from a float-like object, namely the __float__
method. Numpy does not look for this, so you should explicitly require
numpy to use the float64 dtype.
In [5]: a = sin(1).evalf(), sin(2).evalf()
In [6]: np_a =
In the diffgeom module there are classes that may have the same names
as classes in other namespaces:
- Point
- Differential
- Commutator
How to implement printing for such classes? I can just override the
_print methods of the classes instead of rely on the methods of the
Printer classes. It is
On 17 July 2012 02:20, Aaron Meurer wrote:
> I can attest from experience that the API of plot as it is now is
> already confusing. I had a hard time in particular in figuring out
> the difference between plotting several equations and plotting a x vs.
> y expression.
This argument mostly convin
On 16 July 2012 16:29, Bharath M R wrote:
>
>> Are you certain that the heuristics will become simpler? For the
>> moment `plot` does only "expression evaluated over range" type of
>> plots, and that falls in this category (2d lines, 3d lines and
>> surfaces and parametric lines and surfaces) requ
I more or less agree, however
> The heuristic might not become simpler. But for a person using it, it
> splits the functionality into simpler blocks. The heuristic will be split
> across the functions, and hence each function won't have a large amount
> of checks.
The only place where one has a l
With all the issues surrounding ordering, hashes and hash
randomization I was left with the impression that we should rewrite
tests in such a way that they test for mathematical correctness but
not for specific ordering of args, etc.
It seems that constant_renumber does two things: renumbers the
c
Are you certain that the heuristics will become simpler? For the
moment `plot` does only "expression evaluated over range" type of
plots, and that falls in this category (2d lines, 3d lines and
surfaces and parametric lines and surfaces) requires the same type of
heuristics. There are no special ca
>> I personally would vote for option a as it would be consistent with
>> functions like sin and cos.
>
> Me too. Most objects do some simpler transformation at this point. Option b)
> is probably an overkill
> in turning off automatic simplification features, compared to the rest of
> sympy.
If i
> a) at construction time
> b) only when calling expand_func
Would option b) provide for this:
simplify(Integral(L(n, x)*L(n+1, x), blah blah))
If yes I may vote for b).
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send ema
About the flags:
To be specific, I think that separating it to "simplify" and
"group_constants" will be useful, at least until the simplification of
constants becomes smarter.
group_constants - the constants simplification routine
simplify - the rest
However, this is a workaround for the problem
As it stands now, I have no workaround for cases where I want to
- use simplify() but not odesimp()
- or solve for the function but not simplify the constants (as the
simplification routine can produce more constants that were actually
put in, which seems like a bug)
Is separating the "simplify"
> and I'd like to substitute "a/b" with "k". I would use "f.subs(a/b, k)",
I would use `f.subs(a, k*b)`. It seems more consistent with the idea
of substituting a *variable* with something else.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post t
>> However, while we can generate Fortran code, compile it and use
>> that for plotting, in many cases it is an overkill and a simple approach
>> 1) or 2) provides enough speed to get the job done.
>
>
> I'm not sure that this is the right kind of overkill we're looking at here.
There is one more
Is there a reason for this?
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this gro
> 6x speedup makes a big difference if you are going to make an
> evaluation thousands or even millions of times.
In fact, if you do the evaluation thousands or millions of times, the
difference will not be noticeable, because what will take long time is
the evaluation of the array inside numpy.si
Slightly off topic, you have already merged contributions, however I
am not sure that you were added to the AUTHORS file.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from t
> Some details at http://tinyurl.com/8y4h9ad
On the same topic, here is a future optional dependency for sympy:
http://anthon.home.xs4all.nl/Python/ordereddict/
An ordered dict module in C. (sorry, don't derail the discussion over
this, I am just leaving it for future reference)
--
You received t
It is mostly my fault that this is stuck. I said that simply using
default named arguments would be a better decision (see discussion on
the pull request page). However if someone else gives a +1 one on this
topic, the PR should be ok for merging.
I would like to implement what I proposed, however
The AST stuff may be interesting and amusing, however before any
actual benchmarking it seems like overly complicated solution.
.evalf() is slow not because it traverses the expression tree (any
evaluation method would do this, closures would not make less function
calls which is the expensive par
> Or, putting it another way: Whatever calls eval() is doing under the hood,
> it should be faster if some Python code iterated over all nodes of the
> expression tree and did the same calls. Actually it should be faster because
> the eval-parse detour is cut out (except one approach might be doing
If I understand correctly the commit logs and the blog posts of the
gsoc student that did this some years ago, sympy's evaluation to
floats is too slow in order to use for plotting. The solution was to
"compile" expressions to standard precision non-symbolic numpy or just
python.math. The horrifyin
> It could be prone to breakage.
> str(expression) might be changed by people who're not aware that lambdify
> depends on things like parseability and adherence to naming conventions in
> str().
>
> A lambdify of whatever variant that traced the object tree directly would be
> much preferrable over
> For an example that does not work in the old lambdify
> lambdify(y, Sum(x**y, (x, 1, oo)))(-2)
It works in the new lambdify, because
1. the namespace for eval() is build step by step out of the current
expression (the old lambdify just dumped a lot of different object in
the namespace and hoped
>> +1 to this. Each function should know how to numerically evaluate
>> itself using numpy or stdlib math (or whatever), and you should be
>> able to just do it directly, like expr.evalf(library=numpy) or
>> something like that. I don't see any reason why that wouldn't work.
>> eval'ing strings f
Two reasons basically:
- the original lambdify has a very convoluted logic and seems hard to
maintain (the new one is not that great either, however it does not
break as easily) (in the commit history one can see how stuff
completely unrelated to the functionality of lambdify was bolted on
it)
-
If there is no particular reason that you prefer to use strings, you
should explicitly create these symbols.
x, y, z = symbols('x y z')
If you work on the console for interactive stuff and do not write
library code you can use the following faster and sloppier command
var('x y z') # x, y and z w
As per Aaron's suggestion I will keep testing with the defaults (with
randomization). I am always doing 3 tests and the first one is in a
version of python that does not support randomization, so you can
check that. If there is interested I can start testing the other
version with both randomized a
A partial solution to the subs printing issue can be seen here
https://github.com/sympy/sympy/pull/1386
It solves the fact that the latex printing of subs is broken, however
it does not make the change towards f'(t-x) type of printing.
--
You received this message because you are subscribed to t
The problem is that Subs is not smart enough to know that it contains
only a derivative. Changing the variables will help as it will remove
the need for Subs (substituting t-x -> y). Maybe it would be
appropriate to file a bug report with this.
Concerning the latex printer, there is a fix currentl
A few days ago it was mentioned that it makes sense for simplify() to
also call doit() internally.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email t
What about switching to the partial derivative sign?
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For mor
> I have been wondering about this. DiagramGrind is really an internal, or
> perhaps typographic, representation of the diagram, and no longer a
> mathematical one. Why should it use Basic as superclass at all? It's not
> like it can be put meaningfully into any kind of expression at all, can it?
> Hm, that sounds like a nice test, in general, thank you. However, I'm
> not sure the class I am currently working on can be a part of an
> expression.
>
...
>
> Well, hopefully, the class I am talking about cannot really be made a
> part of an expression tree.
>From the documentation of your mo
Different parts of sympy have different assumptions about how strict
the content of args should be. Focusing on the most important and what
has not been questioned:
If you have an instance called obj, this should hold:
obj.func(*obj.args) == obj
If you do funny stuff to your args, do not forget t
> How will this scale? I will also have spare machines to dedicate to
> this, once I get my new laptop.
>
> I think the idea behind sympy-bot work is that the app-engine server
> would keep track of what needs to be tested and distribute the work so
> that there is no duplication.
I may be wrong,
> I think it works well. Would you mind posting your current script?
> So that I can set it up on my server as well.
OK, however it will not do much good - what is tested by your server
will not be tested by mine and vice-versa. So running it on two
machines would be useful only if there are too ma
> Can you post your script? If it already implements the above, that
> would of course be great!
> I didn't know about it.
I have posted a version of it some time ago as a pull request:
https://github.com/sympy/sympy-bot/pull/74
The current version is a bit more robust, however this is only a
**t
This will be quite an effort. Is it worth it? There is already
TravisCI for the master branch (and it is capable of testing PR if we
want). There is also the admittedly-very-ugly script that I use for
testing - it fails occasionally, however one rarely waits for more
than half a day to receive 3 te
> I noticed that sometimes the Travis CI buildbot succeeds, and Stefan's
> buildbot fails on the same code.
> I also understand that sometimes the 32bit and 64bit Python versions
> behave differently in tests
> and sometimes also major Python versions like 3.2 vs 2.7, also I think
> 2.4 and 2.5 (or
Just to be clear: `_diff_wrt` should just became
`_diff_notation_abuse` and be removed from Symbol
On 24 June 2012 00:19, krastanov.ste...@gmail.com
wrote:
> I would also like to make `_diff_wrt` an optional argument. As it
> stands it is impossible to make new types of derivatives beca
I would also like to make `_diff_wrt` an optional argument. As it
stands it is impossible to make new types of derivatives because of
this handy but non-rigorous abuse of notation. All that does not have
the _diff_wrt attribute will just be treated as before (that means
that _eval_derivative will a
It is here https://github.com/sympy/sympy/pull/1383
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more
I would need help with the docstring, as it has a bizarre definition
of function that simply needs to be rewritten. For the moment I am
just removing conflicting parts.
On 23 June 2012 21:11, krastanov.ste...@gmail.com
wrote:
> My second mail employed incorrect syntax, so it does not co
My second mail employed incorrect syntax, so it does not count, still
the last one shows a blatant error. I have fixed it and I have
documented it. I will also post comments on the pull request that
introduced it https://github.com/sympy/sympy/pull/460
--
You received this message because you are
Even worse:
f(g(x)).diff(x).subs(g, Lambda(x, 2*x))
raising an error instead of returning a trivial answer
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, se
inconvenient to substitute. It is simply wrong! The
derivative is not 0
On 23 June 2012 20:34, krastanov.ste...@gmail.com
wrote:
> This is unrelated to my previous post about _diff_wrt:
>
> The problem:
>
> In [5]: f(g(x)).diff(x)
> Out[5]: Derivative(f(g(x)), g(x))*Derivative(
This is unrelated to my previous post about _diff_wrt:
The problem:
In [5]: f(g(x)).diff(x)
Out[5]: Derivative(f(g(x)), g(x))*Derivative(g(x), x)
Which according to the rest of SymPy should be
Out[5]: Subs(Derivative(f(_x), _x), (_x,), (g(x),))*Derivative(g(x), x)
It is nice to have _diff_wrt,
Is Perm a Basic object? If so, you should get acquainted with the
requirements about obj.func(*obj.args)==obj. Is it tested in
test_args.py? If it is not a Basic object, why not?
I am asking all this, because it may interfere with your decision to
use some parameters in the constructor.
You shoul
I was saying that they might be useless, because all that the test
does is to copy the logic of the function.
for instance:
a=1
b=2
assert a+b == 1+2
is not a good unit test because all that you do is to exactly copy the
function to be tested.
I feel that this is true for many of the random tes
By the way this works:
In [9]: c = Blah(Symbol('a'))
In [10]: (2*c).diff(c)
Out[10]: 2
So, the question is why does `diff` care about the content of the free
variable (i.e. the args)? Seems very bizarre.
--
You received this message because you are subscribed to the Google Groups
"sympy" gro
> What's the purpose of using precomputed values?
I am not sure how useful it is as a test, however the idea is to check
that the algorithm works correctly without the problems that testing
random numbers brings.
Even if it is actually useless for testing the algorithm, it is still
useful for test
I like the idea of touching just _hashable_content. I hope it is enough.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googl
Hi, I know that some dislike _diff_wrt, however admitting for the
moment that it is a good idea, can somebody help me with making this
work:
In [1]: class Blah(Expr):
...: _diff_wrt = True
In [2]: c = Blah(1,2,3)
In [3]: (2*c).diff(c)
AttributeError: 'int' object has no attribute 'is_numb
1 - 100 of 635 matches
Mail list logo
