Re: the best online course
There are a ton of great resources on https://wiki.python.org/moin/BeginnersGuide . The resource I generally recommend to people first is "Learn Python The Hard Way" @ http://learnpythonthehardway.org/ . The course is $29.95 and worth every penny but if you can't afford it the author has made the course available for free. Just scroll to the bottom of the page to find the link. On Wed, Jul 6, 2016 at 12:28 PM, wrote: > Hello, > i am totaly beginner and i want to learn python. > I have see that there is many course in codeacademy, udemy, treehouse etc > but i not know who is the best. > Can you please give me some advice? > I want to be easy and not bored so i can learn python. > Thank you and sorry for my bad english > > -- > https://mail.python.org/mailman/listinfo/python-list > -- "It's quite difficult to remind people that all this stuff was here for a million years before people. So the idea that we are required to manage it is ridiculous. What we are having to manage is us." ...Bill Ballantine. -- https://mail.python.org/mailman/listinfo/python-list
ctypes
Hello, I posted in regard to this in the past but it didn't go very far, no ones fault, but I'm again atempting to make this work and could use some help. I would like to use libraw.dll (http://www.libraw.org/ version 0.10) from python and can access all the functions fine and produce images but there is a structure that holds all the process settings that I cannot access with ctypes. I'm sure it's because I'm going about it the wrong way. I was wondering if there was anyone in this list with experience with this sort of thing that could point me in the right direction. Thanks! jt -- "It's quite difficult to remind people that all this stuff was here for a million years before people. So the idea that we are required to manage it is ridiculous. What we are having to manage is us." ...Bill Ballantine, marine biologist. -- http://mail.python.org/mailman/listinfo/python-list
Re: ctypes
My apologies! I worte the email while doing 3 other things. I haven't really tried anything to access this struct other than trying to find different elements with ctypes.c_int.in_dll(dll, 'symbol') and access the elements in the same way I do in C. I didn't think either of these would work but hoped I would get some type of return that would give me a little more info. I have been using a cli to access the library from python and would just send the image data via stdin and the parameters of the struct as command line args. From C the struct is easily accessible through the class instance (libraw::imgdata) and I tried similar variations with ctypes but just get 'function not found'. Makes sense though. this works: lr = ctypes.cdll.LoadLibrary(libraw) handle = lr.libraw_init(0) lr.libraw_open_buffer(handle, buf, len(buf)) # buf is an image read by python lr.libraw_unpack(handle, buf, len(buf)) # imgdata attampt. returns "function 'imgdata' not found" #lr.imgdata.params.bright(2) lr.libraw_dcraw_process(handle) lr.libraw_dcraw_ppm_tiff_writer(handle,'test.ppm') lr.libraw_close(handle) These are the 'exposed' functions, if that is the right term, and will produce an rgb image. There are a few other functions but they are not important atm. I know I don't know what I'm doing with this but it will be worth it if I can struggle through. Is there a way I can access this struct via python? Alternatively I could also write a new function in libraw that can access this struct and be exposed to ctypes. jt On Thu, Sep 23, 2010 at 12:28 AM, Simon Brunning wrote: > On 22 September 2010 21:13, jay thompson > wrote: > > Hello, > > > > I posted in regard to this in the past but it didn't go very far, no ones > > fault, but I'm again atempting to make this work and could use some help. > > > > I would like to use libraw.dll (http://www.libraw.org/ version 0.10) > from > > python and can access all the functions fine and produce images but there > is > > a structure that holds all the process settings that I cannot access with > > ctypes. I'm sure it's because I'm going about it the wrong way. I was > > wondering if there was anyone in this list with experience with this sort > of > > thing that could point me in the right direction. > > A good start would be to tell us what you've tried, and what goes > wrong when you try it. > > -- > Cheers, > Simon B. > -- "It's quite difficult to remind people that all this stuff was here for a million years before people. So the idea that we are required to manage it is ridiculous. What we are having to manage is us." ...Bill Ballantine, marine biologist. -- "It's quite difficult to remind people that all this stuff was here for a million years before people. So the idea that we are required to manage it is ridiculous. What we are having to manage is us." ...Bill Ballantine, marine biologist. -- http://mail.python.org/mailman/listinfo/python-list
Re: 64 bit offsets?
As nice as it would be to use 64bit offsets I am instead mmapping the file
in 1GB chunks and getting the results I need. I would still be interested in
a 64bit solution though.
jt
On Wed, Oct 6, 2010 at 2:41 PM, jay thompson wrote:
> Hello everyone,
>
> I'm trying to extract some data from a large memory mapped file (the
> largest is ~30GB) with re.finditer() and re.start(). Pythons regular
> expression module is great but the size of re.start() is 32bits (signed so I
> can really only address 2GB). I was wondering if any here had some
> suggestions on how to get the long offsets I need. btw... I can't break up
> the file because the pattern I'm looking for can occur anywhere and on any
> boundry.
>
> Also, is seek() limited to 32bit addresses?
>
> this is what I have in python 2.7 AMD64:
>
>
> with open(file_path, 'r+b') as file:
>
> file_map = mmap.mmap(file.fileno(), 0, access=mmap.ACCESS_READ)
> file_map.seek(0)
>
> pattern = re.compile("pattern")
>
> for iii in re.finditer(pattern, file_map):
>
> offset = iii.start()
>
> write_to_sqlite(offset)
>
>
>
>
>
> --
> "It's quite difficult to remind people that all this stuff was here for a
> million years before people. So the idea that we are required to manage it
> is ridiculous. What we are having to manage is us." ...Bill Ballantine,
> marine biologist.
>
>
--
"It's quite difficult to remind people that all this stuff was here for a
million years before people. So the idea that we are required to manage it
is ridiculous. What we are having to manage is us." ...Bill Ballantine,
marine biologist.
--
http://mail.python.org/mailman/listinfo/python-list
64 bit offsets?
Hello everyone,
I'm trying to extract some data from a large memory mapped file (the largest
is ~30GB) with re.finditer() and re.start(). Pythons regular expression
module is great but the size of re.start() is 32bits (signed so I can really
only address 2GB). I was wondering if any here had some suggestions on how
to get the long offsets I need. btw... I can't break up the file because the
pattern I'm looking for can occur anywhere and on any boundry.
Also, is seek() limited to 32bit addresses?
this is what I have in python 2.7 AMD64:
with open(file_path, 'r+b') as file:
file_map = mmap.mmap(file.fileno(), 0, access=mmap.ACCESS_READ)
file_map.seek(0)
pattern = re.compile("pattern")
for iii in re.finditer(pattern, file_map):
offset = iii.start()
write_to_sqlite(offset)
--
"It's quite difficult to remind people that all this stuff was here for a
million years before people. So the idea that we are required to manage it
is ridiculous. What we are having to manage is us." ...Bill Ballantine,
marine biologist.
--
http://mail.python.org/mailman/listinfo/python-list
Re: 64 bit offsets?
I'm not sure if it is limited to 32 bit addresses or if it's only re.start() that is limited to 'em. jt - "It's quite difficult to remind people that all this stuff was here for a million years before people. So the idea that we are required to manage it is ridiculous. What we are having to manage is us." ...Bill Ballantine, marine biologist. On 2010-10-07 8:42 AM, "MRAB" wrote: On 06/10/2010 22:41, jay thompson wrote: > > Hello everyone, > > I'm trying to extract some data fro... I would've thought that a 64-bit version of Python would have 64-bit offsets. Is that not the case? -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
