Re: [Tutor] checking if a variable is an integer?

[Válas Péter]

Hi guys, do you think, Hans, who wants to write his first prime number
program, still understands what we are talking about? :-)
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] __init__.py question

[Válas Péter]

I think it means that you may have a subdirectory named "string" in your
actual directory where you store e.g. your string-related scripts, and you
have a Python package named "string" _somewhere_else_, but in the module
search path. The subdirectory of the actual directory will have priority
bacause of its place, and will prevent you of importing the string package.

2011/6/1 Marilyn Davis 

> I don't really understand why __init__.py is necessary -- except that it
> makes the packaging scheme work.
>
> The Python Manual by Guido van Rossum and Fred L. Drake says:
>
> ... this is done to prevent directories with a common name, such as
> string, from unintentionally hiding valid modules that occur later on in
> the module search path.
>
> An example would probably set me straight.  Can anyone help with that?
>
> Marilyn Davis
>
> ___
> Tutor maillist  -  Tutor@python.org
> To unsubscribe or change subscription options:
> http://mail.python.org/mailman/listinfo/tutor
>
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] __init__.py question

[Marilyn Davis]

Thank you Válas Péter.  I still don't get it, or how __init__.py alters
the scenario you describe.

I know that sometimes I'm really dense so please be patient with me.

If I have a string.py in my local directory, it will be imported when I
"import string" because the search path, sys.path, (which I have control
of), has my local directory as the first place to search by default, and
no __init__.py is involved.  If my string is not a .py but
package/directory itself, it will be imported and searched into if it has
a __init__.py.  In either case, how can I get to the system's string.py by
putting __init__.py somewhere?

If my string.py is in a package, I have to put its parent directory on my
sys.path for it to be found, and the parent directory won't need an
__init__.py

There's something I'm missing because I think you simply can't call
something string.py unless you are willing to give up the library
string.py.

I can see that a person could have a local string directory that they
don't want imported because it has some non-code in it, or something.  But
the __init__.py facility is a big deal to be there for the purpose of
allowing this when it is, IMHO, an architectural mistake.

There must be something I'm missing or some wrong thinking described here
because Guido is so smart, and it's still in 3.x.

If anyone has an insight, I would really appreciate some help on this
point, which has bothered me a bit for years.

Marilyn Davis









On Wed, June 1, 2011 12:26 am, Válas Péter wrote:

> I think it means that you may have a subdirectory named "string" in your
> actual directory where you store e.g. your string-related scripts, and you
>  have a Python package named "string" _somewhere_else_, but in the module
>  search path. The subdirectory of the actual directory will have priority
>  bacause of its place, and will prevent you of importing the string
> package.
>
> 2011/6/1 Marilyn Davis 
>
>
>> I don't really understand why __init__.py is necessary -- except that
>> it makes the packaging scheme work.
>>
>> The Python Manual by Guido van Rossum and Fred L. Drake says:
>>
>>
>> ... this is done to prevent directories with a common name, such as
>> string, from unintentionally hiding valid modules that occur later on in
>>  the module search path.
>>
>> An example would probably set me straight.  Can anyone help with that?
>>
>>
>> Marilyn Davis
>>
>>
>> ___
>> Tutor maillist  -  Tutor@python.org
>> To unsubscribe or change subscription options:
>> http://mail.python.org/mailman/listinfo/tutor
>>


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

Re: [Tutor] __init__.py question

[Prasad, Ramit]

I wonder if this is so that it can ignore directories on sys.path. I assume 
that the path passed to python can be quite verbose depending on the OS's 
handling of path and environment variables.

This is also a way to have Python ignore Python scripts in directories on the 
path that are not meant to be imported but run from command-line (like a bash 
script). 

To be honest, I am just stabbing at possible solutions because I am not sure 
myself. If you do find the definitive reason (that makes more sense than the 
excerpt included in this thread) do post on here for the rest of us. :)


Ramit



Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology
712 Main Street | Houston, TX 77002
work phone: 713 - 216 - 5423


This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.

This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.

Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to European legal entities.
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] __init__.py question

[Alexandre Conrad]

2011/5/31 Marilyn Davis :
> I don't really understand why __init__.py is necessary -- except that it
> makes the packaging scheme work.
>
> The Python Manual by Guido van Rossum and Fred L. Drake says:
>
> ... this is done to prevent directories with a common name, such as
> string, from unintentionally hiding valid modules that occur later on in
> the module search path.

I think it is just to avoids unexpected conflicting namespaces that
could happen by accidentally importing non-Python directories. By
explicitly putting a __init__.py module in your directory, you are
telling Python you want your directory to be considered as a Python
package and to be imported in your namespace. If you have a
conflicting namespace, it means you explicitly wanted this to happen,
then you have to deal with it (or fix it if unintended).

-- 
Alex | twitter.com/alexconrad
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] __init__.py question

[Alexandre Conrad]

As a side note, remember that imported modules are cached under
sys.modules. If you import something, it will be looked up in
sys.modules and use the one in memory if it exists. If it doesn't
exist, it will iterate over sys.path and look for your module/package.
If it doesn't find it, you will get an ImportError. If it finds it, it
will add it to sys.modules. So any future imports for the same
namespace won't be re-imported from disk, it's already here in memory.

Say I *do* have a local package called string. After I import it, say
I want to import the "logging" module. Well, it will break:

$ python
Python 2.6.6 (r266:84292, Sep 15 2010, 16:22:56)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import string  # my local string package
>>> print string

>>> import logging
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.6/logging/__init__.py", line 62, in 
elif string.lower(__file__[-4:]) in ['.pyc', '.pyo']:
AttributeError: 'module' object has no attribute 'lower'

When "logging" is being imported, internally it also imports standard
Python "string" module, which is *already* in sys.modules (your own).

So imagine if Python also imported any directory without a __init__.py
file, system wide, you might have random surprises.


2011/6/1 Alexandre Conrad :
> 2011/5/31 Marilyn Davis :
>> I don't really understand why __init__.py is necessary -- except that it
>> makes the packaging scheme work.
>>
>> The Python Manual by Guido van Rossum and Fred L. Drake says:
>>
>> ... this is done to prevent directories with a common name, such as
>> string, from unintentionally hiding valid modules that occur later on in
>> the module search path.
>
> I think it is just to avoids unexpected conflicting namespaces that
> could happen by accidentally importing non-Python directories. By
> explicitly putting a __init__.py module in your directory, you are
> telling Python you want your directory to be considered as a Python
> package and to be imported in your namespace. If you have a
> conflicting namespace, it means you explicitly wanted this to happen,
> then you have to deal with it (or fix it if unintended).
>
> --
> Alex | twitter.com/alexconrad
>



-- 
Alex | twitter.com/alexconrad
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] __init__.py question

[Marilyn Davis]

Maybe I'm getting what you say, Alexandre and Ramit.

When you import logging, it imports string, but it won't if you have a
string of your own already imported.

So, when logging depends on string, it'll get mine and crash.

But __init__.py helps what in this scenario?

The only scenario it helps, that I can understand so far, is if I make a
string directory that isn't part of a package that I'm making, but is in
its directory structure, accidentally using a library name that I want.

I guess I don't feel very satisfied because I would be happy with the
crash so that I can fix up my naming/architecture mistake rather than
depend on, and struggle with, the __init__.py scheme.

I teach Python and this is always a hard part for people.  It might help
if I understand it better.

Marilyn Davis




On Wed, June 1, 2011 11:52 am, Alexandre Conrad wrote:

> As a side note, remember that imported modules are cached under
> sys.modules. If you import something, it will be looked up in sys.modules
> and use the one in memory if it exists. If it doesn't exist, it will
> iterate over sys.path and look for your module/package. If it doesn't find
> it, you will get an ImportError. If it finds it, it will add it to
> sys.modules. So any future imports for the same namespace won't be
> re-imported from disk, it's already here in memory.
>
> Say I *do* have a local package called string. After I import it, say
> I want to import the "logging" module. Well, it will break:
>
>
> $ python
> Python 2.6.6 (r266:84292, Sep 15 2010, 16:22:56)
> [GCC 4.4.5] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>
 import string  # my local string package print string
> 
>
 import logging
> Traceback (most recent call last):
> File "", line 1, in 
> File "/usr/lib/python2.6/logging/__init__.py", line 62, in 
> elif string.lower(__file__[-4:]) in ['.pyc', '.pyo']: AttributeError:
> 'module' object has no attribute 'lower'
>
>
> When "logging" is being imported, internally it also imports standard
> Python "string" module, which is *already* in sys.modules (your own).
>
>
> So imagine if Python also imported any directory without a __init__.py
> file, system wide, you might have random surprises.
>
>
> 2011/6/1 Alexandre Conrad :
>
>> 2011/5/31 Marilyn Davis :
>>
>>> I don't really understand why __init__.py is necessary -- except that
>>> it makes the packaging scheme work.
>>>
>>> The Python Manual by Guido van Rossum and Fred L. Drake says:
>>>
>>>
>>> ... this is done to prevent directories with a common name, such as
>>> string, from unintentionally hiding valid modules that occur later on
>>> in the module search path.
>>
>> I think it is just to avoids unexpected conflicting namespaces that
>> could happen by accidentally importing non-Python directories. By
>> explicitly putting a __init__.py module in your directory, you are
>> telling Python you want your directory to be considered as a Python
>> package and to be imported in your namespace. If you have a conflicting
>> namespace, it means you explicitly wanted this to happen, then you have
>> to deal with it (or fix it if unintended).
>>
>> --
>> Alex | twitter.com/alexconrad
>>
>>
>
>
>
> --
> Alex | twitter.com/alexconrad



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

Re: [Tutor] Python Extensions in C

[James Reynolds]

So I've been continuing with my experiment above, and I've made some good
progress and learned some new things as I've been going. I've expanded it
out a little bit, and you can see the code here:

http://pastebin.com/gnW4xQNv

I've tried to incorporate most of your
suggestions (although, the code itself looks more condensed in my editor
than what it appears there).

Unfortunately, I am stuck and I have no clue how to free myself from the
mud.


On line 370, you will notice I have "*return_varp" as the return value and
not "skew". This is because I am trying to figure out why the variance
function is not working properly from this function call.

Earlier today it was working fine, so I know it works at least in theory.

When variance is called from stats.var it works just fine and the output is
as expected.

so for example,

a = [1,2,3,4,4,5]
stats.var(a) = 2.16 (correct)

stats.skew(a) = -0.74 (not correct)

Again, for this I have the return value of skew set to show me the the
second moment. Skew is calling the same exact function as var and with the
same exact same inputs as var(), or should be.

I've looked at every single variable in variance to see what is going on and
here is what I know for now:

1. sumall is adding up to the wrong number when called from skew (or kurt).
2. avg, count, and moment all are what they should be.
3. The sequence passed is always the same from Python (a = [1,2,3,4,4,5])

I'm guessing this is some nuance of C code dealing static variables or
something to do with memory, but again, I no even less about C than I do
about Python (which is my objective here - learning some of this should make
me better at both, hopefully)

A couple other points: There are three parameters now, not one. The later
two are optional. they are (list, avg, and sample) sample is True by
default.

So you can pass it an average already.

Lastly, any other pointers would be greatly appreciated.

James















On Thu, May 26, 2011 at 7:50 PM, Alan Gauld wrote:

>
> "James Reynolds"  wrote
>
>
>  As far as the null point goes, it shouldn't be null at all once it gets to
>> the point Alan pointed out. The pointer is set in (for example) stat_avg
>>
>>   seq = PySequence_Fast(obj, "Expected a Sequence");
>>
>
> Can the function fail? If so what does it return? That was
> my point. Can seq ever still be NULL after the function call?
> For example if the function is allocating memory it could fail
> to grab enough and then return a NULL
>
> But it depends on how reliable the Python function is in
> its return value...
>
>
>  But maybe I am missing something that you have seen?
>>
>
> Don't rely on functio  returns being valid values.
> It is common practice in industrial strength C to return a NULL
> and expect the user to check. Manyb of the standard library
> functions work that way too.
>
> So you often see code like
>
> if (foo = someFunction() ){   // notice it is an assignment not equality
> test
> process(foo);
> }
>
> HTH,
>
>
> --
> Alan Gauld
> 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:
> http://mail.python.org/mailman/listinfo/tutor
>
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] __init__.py question

[Alexandre Conrad]

2011/6/1 Marilyn Davis :
> Maybe I'm getting what you say, Alexandre and Ramit.
>
> When you import logging, it imports string, but it won't if you have a
> string of your own already imported.
>
> So, when logging depends on string, it'll get mine and crash.
>
> But __init__.py helps what in this scenario?

Nothing directly. I started my email with "As a side note" :)

> The only scenario it helps, that I can understand so far, is if I make a
> string directory that isn't part of a package that I'm making, but is in
> its directory structure, accidentally using a library name that I want.

Correct.

> I guess I don't feel very satisfied because I would be happy with the
> crash so that I can fix up my naming/architecture mistake rather than
> depend on, and struggle with, the __init__.py scheme.
>
> I teach Python and this is always a hard part for people.  It might help
> if I understand it better.

Don't try to over-understand! :)

If an __init__.py file is present in your directory, it will be
considered by Python as a package. __init__.py also avoids non-Python
directories to potentially pollute/conflict with your namespace.
That's pretty much it.

Additionally, when importing a package, anything in the __init__.py
module will be executed during import. Just as you can see from the
previous "logging" traceback I sent.

-- 
Alex | twitter.com/alexconrad
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Strategy to read a redirecting html page

[Karim]

On 06/01/2011 01:41 AM, Alexandre Conrad wrote:

Hi Karim,

When you hit the page and you get an HTTP redirect code back (say,
302), you will need to make another call to the URL specified in the
"Location" parameter in the response headers. Then you retrieve that
new page and you can check you got an acceptable HTTP response code
(such as 200) and read the page's body (or whatever you want to do
with it). Otherwise, keep looping until you get an expected HTTP
response code.

Note: you may get stuck in an infinite loop if two URLs redirect to each other.

You might want to take a look at the higher level httplib module:
http://docs.python.org/library/httplib.html

Although I don't think it can automatically follow redirects for you.
You'll have to implement the loop yourself.

If you can rely on 3rd party packages (not part of the standard Python
library), take a look at httplib2:
https://httplib2.googlecode.com/hg/doc/html/libhttplib2.html

This one can follow redirects.

HTH,

2011/5/31 Karim:

Hello,

I am having issue in reading a html page which is redirected to a new page.
I get the first warning/error message page and not the redirection one.
Should I request a second time the same url page or Should I loop forever
until the
page content is the correct (by parsing it) one?
Do you have a better strategy or perhaps some modules deal w/ that issue?
I am using python 2.7.1 on Linux ubuntu 11.04 and the modules urllib2,
urllib, etc...
The webpage is secured but I registered a password manager.

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



Alex, Ian, Hugo,

Thanks a THOUSAND TIMES!
With all the hints and weapons 'I will survive' ;o)

I have to use python standard but 'libhttplib2' 3rd party module, I will 
have a look.


Many many thanks
Cheers
Karim
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] checking if a variable is an integer?

[Steven D'Aprano]

Válas Péter wrote:

Hi guys, do you think, Hans, who wants to write his first prime number
program, still understands what we are talking about? :-)



If not, he can google the bits he doesn't understand, or ask. We won't bite!



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

Re: [Tutor] __init__.py question

[Steven D'Aprano]

Marilyn Davis wrote:
[...]

There's something I'm missing because I think you simply can't call
something string.py unless you are willing to give up the library
string.py.


No, you're right about that. Python's search path is "first match wins". 
Whether it's a package or a module, it will match before the library 
string.py. Adding __init__.py doesn't change that.


(Unless you re-arrange sys.path so that library modules come first.)

However, you can have a directory called "string", containing arbitrary 
.py files. So you could drop this in your path:



string/
+-- a.py
+-- b.py

and add string to the path so that the directory is searched, and still 
get the standard string.py. (I haven't actually tried this, but it 
should work.)


Only if you put a file __init__.py into the directory will it shadow the 
standard library string.py.


Personally, I think the emphasis given in the docs about shadowing 
standard library files is misplaced. I think that is actually 
irrelevant. I think a more useful explanation for the need for 
__init__.py is simple: how else could Python distinguish a package from 
a mere directory containing Python files?


A mere directory is not searched unless it is explicitly added to the 
path; a mere directory cannot be imported. A package can be. But since a 
package *is* a directory at the file system level, how should Python 
distinguish them?


I suppose Python could have the rule "the directory must end in .py to 
be considered a package". But then, when you import the main package 
instead of a submodule, which file should Python read? There needs to be 
a standard naming convention for the file to be treated as the top-level 
module. But since you have such a file, there's no longer any need for 
adding a .py to the end of the directory name, since the standard file 
is sufficient to determine that the directory is a package.


That file could have been called anything, __init__.py was chosen by 
analogy with __init__ methods in classes and because it's unlikely to 
clash with any name package authors might choose for their own use.




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

Re: [Tutor] Python Extensions in C

[ALAN GAULD]

OK, It seems to have grown a bit! :-)

Your use of static seems a little odd. In particular the definition of avg as a 
static double.
You then never use avg except here:


1. avg = *return_avgp;
2. samp = 0;
3. return_varp = var(seq, count, &avg, samp, 2);
4. third_moment = var(seq, count, &avg, 0, 3);You 
assign the 
content of a pointer to avg then take use address 

of avg in var() - effectively making avg back into a pointer?

Why not just use *return_avgp inside the var() function?
And why is avg static? - do you understand what static is doing?
And the side effects of that? Is there a reason to use static? 
If so its a bit too subtle for me...

BTW, On style issues:
While I prefer the braces style you have made the mistake of mixing styles, 
particularly confusing when done inside a single function as in the middle of 
stat_kurt()

And I don't personally like variables being declared in the middle of code. 
(eg lines 365 and 430) I can just about accept at the start of a block, 
but I prefer at the start of the function. It's just easier to find if they 
are all together.

Other than that I can't see the error, but its late and thats 
quite a lot of code for a Python programmer to wade through! :-)


Alan Gauld
Author of the Learn To Program website
http://www.alan-g.me.uk/






From: James Reynolds 
To: Alan Gauld 
Cc: tutor@python.org
Sent: Wednesday, 1 June, 2011 20:49:44
Subject: Re: [Tutor] Python Extensions in C

So I've been continuing with my experiment above, and I've made some good 
progress and learned some new things as I've been going. I've expanded it out a 
little bit, and you can see the code here:

http://pastebin.com/gnW4xQNv

I've tried to incorporate most of your suggestions (although, the code itself 
looks more condensed in my editor than what it appears there).

Unfortunately, I am stuck and I have no clue how to free myself from the mud.



On line 370, you will notice I have "*return_varp" as the return value and not 
"skew". This is because I am trying to figure out why the variance function is 
not working properly from this function call.

Earlier today it was working fine, so I know it works at least in theory.

When variance is called from stats.var it works just fine and the output is as 
expected.

so for example,

a = [1,2,3,4,4,5]
stats.var(a) = 2.16 (correct)

stats.skew(a) = -0.74 (not correct)

Again, for this I have the return value of skew set to show me the the second 
moment. Skew is calling the same exact function as var and with the same exact 
same inputs as var(), or should be.

I've looked at every single variable in variance to see what is going on and 
here is what I know for now:

1. sumall is adding up to the wrong number when called from skew (or kurt).
2. avg, count, and moment all are what they should be.
3. The sequence passed is always the same from Python (a = [1,2,3,4,4,5])

I'm guessing this is some nuance of C code dealing static variables or 
something 
to do with memory, but again, I no even less about C than I do about Python 
(which is my objective here - learning some of this should make me better at 
both, hopefully)

A couple other points: There are three parameters now, not one. The later two 
are optional. they are (list, avg, and sample) sample is True by default.

So you can pass it an average already.

Lastly, any other pointers would be greatly appreciated.

James
















On Thu, May 26, 2011 at 7:50 PM, Alan Gauld  wrote:


>"James Reynolds"  wrote
>
>
>
>As far as the null point goes, it shouldn't be null at all once it gets to
>>the point Alan pointed out. The pointer is set in (for example) stat_avg
>>
>>  seq = PySequence_Fast(obj, "Expected a Sequence");
>>

Can the function fail? If so what does it return? That was
>my point. Can seq ever still be NULL after the function call?
>For example if the function is allocating memory it could fail
>to grab enough and then return a NULL
>
>But it depends on how reliable the Python function is in
>its return value...
>
>
>
>But maybe I am missing something that you have seen?
>>

Don't rely on functio  returns being valid values.
>It is common practice in industrial strength C to return a NULL
>and expect the user to check. Manyb of the standard library
>functions work that way too.
>
>So you often see code like
>
>if (foo = someFunction() ){   // notice it is an assignment not equality test
>process(foo);
>}
>
>HTH,
>
>
>-- 
>Alan Gauld
>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:
>http://mail.python.org/mailman/listinfo/tutor
>
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org