Re: [Tutor] Python 2 & 3 and unittest

2013-09-05 Thread Albert-Jan Roskam
- Original Message -
> From: Peter Otten <__pete...@web.de>
> To: tutor@python.org
> Cc: 
> Sent: Thursday, September 5, 2013 8:29 AM
> Subject: Re: [Tutor] Python 2 & 3 and unittest
> 
> Steven D'Aprano wrote:
> 
>> On Thu, Sep 05, 2013 at 09:11:50AM +1000, Steven D'Aprano wrote:
>> 
>>> I don't believe there is a way to make
>>> string literals unicode, you just have to get used to writing 
> u"" and
>>> b"" strings by hand.
>> 
>> Sorry, that is unclear. I meant to say, there is no way to force
>> unprefixed strings "" to be Unicode in 2.x.
> 
> For 2.6 and above there is
> 
> from __future__ import unicode_literals

I can't find the SO page I am looking for, but this is also an intesting one. 
Using the 'future' import may break code. But implicitly concatening 
byte/unicode strings is banned in python3 anyway. I am planning to checkout 
unicodenazi and ascii_with_complaints
http://stackoverflow.com/questions/809796/any-gotchas-using-unicode-literals-in-python-2-6
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor


Re: [Tutor] Python 2 & 3 and unittest

2013-09-05 Thread Albert-Jan Roskam
- Original Message -
> From: Steven D'Aprano 
> To: tutor@python.org
> Cc: 
> Sent: Thursday, September 5, 2013 1:11 AM
> Subject: Re: [Tutor] Python 2 & 3 and unittest
> 
> On Wed, Sep 04, 2013 at 06:30:12AM -0700, Albert-Jan Roskam wrote:
>> Hi,
>> 
>> I am trying to make my app work in Python 2.7 and Python 3.3 (one 
>> codebase) and I might later also try to make it work on Python 2.6 and 
>> Python 3.2 (if I am not too fed up with it ;-). I was very happy to 
>> notice that the 'b' prefix for bytes objects is also supported for 
>> byte strings in Python 2.7. Likewise, I just found out that the 
> "u" 
>> has been re-introduced in Python 3.3 (I believe this is the first 
>> Python 3 version where this re-appears).
>> 
>> I am now cursing myself for having used doctest for my tests. 
> 
> Well that's just silly :-)
> 
> Doc tests and unit tests have completely different purposes, and 
> besides, in general doc tests are easier to make version independent. 
> Many of your doc tests will still continue to work, and those that don't 
> can almost always be adapted to be cross-platform.

Hmm, maybe the page below was exaggerating. I hope so. Given that quite a few 
__repr__ methods have changed (bytes objects, views, ...) I still fear that a 
whole bunch of tests need to be modified.
http://python3porting.com/problems.html: 
"Running doctests - One of the more persistently annoying problems you may 
encounter are doctests. Personally I think doctests are brilliant for testing 
documentation, but there has been a recommendation in some circuits to make as 
many tests as possible doctests. This becomes a problem with Python 3 because 
doctests rely on comparing the output of the code. That means they are 
sensitive to changes in formatting and Python 3 has several of these. This 
means that if you have doctests you will get many, many failures. Don’t 
despair! Most of them are not actual failures, but changes in the output 
formatting. 2to3 handles that change in the code of the doctests, but not in 
the output. 
If you are only porting to Python 3, the solution is simple and boring. Run the 
doctests and look at each failure to see if it is a real failure or a change in 
formatting. This can sometimes be frustrating, as you can sit and stare at a 
failure trying to figure out what actually is different between the expected 
and the actual output. On the other hand, that’s normal with doctests, even 
when you aren’t porting to Python 3, which of course is one of the reasons that 
they aren’t suitable as the main form of testing for a project.
It gets more tricky if you need to continue to support Python 2, since you need 
to write output that works in both versions and that can be difficult and in 
some cases impossible for example when testing for exceptions, see below."
 
>> So I am planning to rewrite everything in unittest.
>> Is the try-except block below the best way to make this test work in 
>> Python 2.6 through 3.3?
>> 
>> import unitttest
>> import blah  # my package
>> 
>> 
>> class test_blah(unittest.TestCase):
>>     def test_someTest(self):
>>     try:
>>             expected = [u"lalala", 1] # Python 2.6>= & 
> Python 3.3>=
>>     except SyntaxError:
>>             expected = ["lalala", 1] # Python 3.0, 3.1, 3.2
> 
> That cannot work. try...except catches *run time* exceptions. 
> SyntaxError occurs at *compile time*, before the try...except gets a 
> chance to run.
> 
> Unfortunately, there is no good way to write version-independent code 
> involving strings across Python 2.x and 3.x. If you just support 3.3 and 
> better, it is simple, but otherwise you're stuck with various nasty work 
> arounds, none of which are ideal.
> 
> Probably the least worst for your purposes is to create a helper 
> function in your unit test:
> 
> if version < '3':
>     def u(astr):
>         return unicode(astr)
> else:
>     def u(astr):
>         return astr
> 
> Then, everywhere you want a Unicode string, use:
> 
> u("something")
> 
> The two problems with this are:
> 
> 1) It is slightly slower, but for testing purposes that doesn't really 
> matter; and
> 
> 2) You cannot write non-ASCII literals in your strings. Or at least not 
> safely.
> 
> 
>> Another, though related question. We have Python 2.7 in the office and 
>> eventually we will move to some Python3 version. The code does not 
>> generally need to remain Python2 compatible. What is the best 
>> strategy: [a] write forward compatible code when using Python 2.7. 
>> (using a 'b' prefix for byte strings, parentheses for the print 
>> *statement*, sys.exc_info()[1] for error messages, etc.). [b] totally 
>> rely on 2to3 script and don't make the Python2 code less reabable and 
>> less idiomatic before the upgrade.
> 
> Option a, but not the way you say it. Start by putting 
> 
> from __future__ import division, print_function

 
Assuming I never use the arguments of the print function, why also import 
print_function? print("somet

Re: [Tutor] Python 2 & 3 and unittest

2013-09-05 Thread Oscar Benjamin
On 5 September 2013 11:20, Albert-Jan Roskam  wrote:
>> from __future__ import division, print_function
>
> Assuming I never use the arguments of the print function, why also import 
> print_function? print("something") works no matter if 'print' is a statement 
> or a function.

The problem is when you want to print more than one thing i.e.

print(a, b)
  vs
print a, b

While the former isn't an error in Python 2.x it prints the tuple (a,
b) with brackets which will break any doctest. The latter form is a
syntax error in 3.x that would be dealt with by the 2to3 fixer except
you're trying to use a single codebase so that won't work for you.


Oscar
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor


Re: [Tutor] Tutor Digest, Vol 114, Issue 73

2013-09-05 Thread I. Alejandro Fleischer
Dear Friends,

I have a set of data to fit to a custom equation, y=a+b*exp(k*x), would you
advice me on the how to, or tutorial?

Thank you


On Thu, Aug 22, 2013 at 10:11 AM,  wrote:

> Send Tutor mailing list submissions to
> tutor@python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.python.org/mailman/listinfo/tutor
> or, via email, send a message with subject or body 'help' to
> tutor-requ...@python.org
>
> You can reach the person managing the list at
> tutor-ow...@python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Tutor digest..."
>
>
> Today's Topics:
>
>1. Re: hi (Oscar Benjamin)
>2. global variables (Matthew Ngaha)
>3. Re: global variables (Chris Down)
>4. Re: global variables (Matthew Ngaha)
>5. Re: global variables (Chris Down)
>6. Re: global variables (Alan Gauld)
>7. Re: global variables (Alan Gauld)
>
>
> --
>
> Message: 1
> Date: Thu, 22 Aug 2013 13:03:10 +0100
> From: Oscar Benjamin 
> To: Vick 
> Cc: "Tutor@python.org" 
> Subject: Re: [Tutor] hi
> Message-ID:
>  on53h...@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 20 August 2013 13:49, Vick  wrote:
> >
> > From: Oscar Benjamin [mailto:oscar.j.benja...@gmail.com]
> >
> >> Well just send me some tutorial on how to build and obtain the
> >> coefficients for the butcher tableau for the RK4 as an example, and
> >> after I've mastered it, I'd give the dopri8 a shot.
> >
> > I am up for it so I'll see if I can find time to write a script that
> shows
> > how to do it.
> >
> > [Vick] Hope you've had the time to code it. I'm waiting for it.
>
> Sorry, I haven't found the time yet. It is still on my todo list though!
>
> > By the way your code for the Adams-Moulton coefficients are actually the
> > Adams-Bashforth ones and so I copied it and modified the copy to have the
> > Adams-Moulton coefficients as well. This means that I have now an
> nth-order
> > predictor-corrector method to solve for ODEs.
>
> Oh sorry. That'll be a cut and paste error. My code lives in a private
> software library that I keep meaning to release on PyPI but it's not
> ready for public consumption in quite a number of ways.
>
> I'm glad that you worked it out though. You''ll probably understand
> what I mean now when I say that the AM or AB integrators need a
> secondary algorithm to bootstrap. The accuracy of the subsequent AM/AB
> method depends on the accuracy of that step. In the worst case you can
> just use rk4 with a very small time-step for this bit though.
>
>
> Oscar
>
>
> --
>
> Message: 2
> Date: Thu, 22 Aug 2013 13:36:24 +0100
> From: Matthew Ngaha 
> To: "tutor@python.org" 
> Subject: [Tutor] global variables
> Message-ID:
>  zo+y3by20vkaumhapt...@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I'm always told to avoid using them. I read discussions on the python
> irc channel about them but honestly i feel there are some times where
> i can't avoid using them. Like where i want to keep track of a state
> variable in many different functions that may or may not alter its
> value and also not wanting any of the functions to return it to the
> caller.
>
> My question is how many global variables did your last decent sized
> program have? Also please share any insight you have about them. I do
> try to avoid them, but is this always possible?
>
>
> --
>
> Message: 3
> Date: Thu, 22 Aug 2013 14:40:34 +0200
> From: Chris Down 
> To: Matthew Ngaha 
> Cc: "tutor@python.org" 
> Subject: Re: [Tutor] global variables
> Message-ID: <20130822124033.gc4...@chrisdown.name>
> Content-Type: text/plain; charset="us-ascii"
>
> On 2013-08-22 13:36, Matthew Ngaha wrote:
> > I'm always told to avoid using them. I read discussions on the python
> > irc channel about them but honestly i feel there are some times where
> > i can't avoid using them. Like where i want to keep track of a state
> > variable in many different functions that may or may not alter its
> > value and also not wanting any of the functions to return it to the
> > caller.
>
> It sounds like you want to use a class.
>
> > My question is how many global variables did your last decent sized
> > program have? Also please share any insight you have about them. I do
> > try to avoid them, but is this always possible?
>
> I don't have any global variables in any of my projects, and I've been
> programming Python in some capacity for almost 8 years now. Why would you
> not
> just use a class if you want to store state?
> -- next part --
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 490 bytes
> Desc: not available
> URL: <
> http://mail.python.org/pipermail/tutor/attachments/20130822/02883212/attachment-0001.sig

[Tutor] equation solving (was: Re: Tutor Digest, Vol 114, Issue 73)

2013-09-05 Thread Alan Gauld

On 05/09/13 20:13, I. Alejandro Fleischer wrote:

Dear Friends,


Hi, please, in future, do not resend the entire digest message
 - it just clutters up inboxes and costs members money on
their bandwidth allowance. Alsao change the subject line
to something relevant (as I've done here).

Also, send new posts direct to tutor@python.org its easier to
work with in threaded readers and archive lists.

Now to your question...


I have a set of data to fit to a custom equation, y=a+b*exp(k*x), would
you advice me on the how to, or tutorial?


Can be be more precise? The more specific you are the easier it is
to give specific answers.

Do you have all of the constants and only want a mapping of x and y 
values? Or do you have a subset of x and y and want to find an arbitrary 
set of constants that will make the equation fit?


There are well known mathematical techniques for doing this kind of 
thing. Are you aware of them and need help implementing them in

Python? Or are you starting with no knowledge of how to solve the problem?

It's difficult to know what kind of help you need until we know more 
about you and the problem


--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor


[Tutor] fit data to equation

2013-09-05 Thread bob gailer

On 9/5/2013 3:13 PM, I. Alejandro Fleischer wrote:

Dear Friends,
Hi and welcome to the tutor list. Since you are new bear with me while I 
offer some important guidelines to effective communication with us.


1 - don't "hijack" some other email as a quick way to get our email address.
2 - when communicating delete all irrelevant text. We don't need to see 
all the digest.

3 - always use a meaningful subject
4 - when starting a new subject start a new email. Otherwise our thread 
trackers bury the (to you new) message.


I have a set of data to fit to a custom equation, y=a+b*exp(k*x), 
would you advice me on the how to, or tutorial?


Curve fitting is not my strength. Perhaps someone else on the list will 
come to your aid.


--
Bob Gailer
919-636-4239
Chapel Hill NC

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor


Re: [Tutor] Python 2 & 3 and unittest

2013-09-05 Thread Albert-Jan Roskam


 Original Message -

> From: Don Jennings 
> To: Albert-Jan Roskam 
> Cc: Python Mailing List 
> Sent: Wednesday, September 4, 2013 4:15 PM
> Subject: Re: [Tutor] Python 2 & 3 and unittest
> 
> 
> On Sep 4, 2013, at 9:30 AM, Albert-Jan Roskam wrote:
> 
>>  Hi,
>> 
>>  I am trying to make my app work in Python 2.7 and Python 3.3 (one codebase) 
> and I might later also try to make it work on Python 2.6 and Python 3.2 (if I 
> am 
> not too fed up with it ;-).
> 
> You might like to read Armin Ronacher's (Flask, Jinja2) take on this topic 
> [1].
> 
> Take care,
> Don
> 
> [1] http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux

*Very* useful page, thanks! Also a cool example of a class decorator on that 
page. Python Modernize also sounds promising. I've downloaded it but did not 
yet try it.
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor