Re: Python dos2unix one liner
Hello, I need to perform a tp on semaphores and shared segments of memory, but I have a bit of trouble with the first notion. In short, we are asked to create 3 programs: The first director, who with the create capacity file argument, will create the museum with the different IPC system objects with the maximum capacity given in argument and the maximum number of visitors in the maximum queue given by the last argument. The open and close arguments will open or close the museum. The delete argument will delete the museum and IPC System 5 objects. Then, the controller program, called without argument, will ensure that the current capacity of the museum does not exceed the maximum capacity. Finally, the visitor program simulates the arrival of a visitor, with the time remaining in the arguments. It is called as many times as there are visitors. A visitor ends if the queue exceeds the limit set at creation, otherwise he asks for permission to enter the museum. We are asked here to use only the IPC system 5 objects that are the shared memory segments and semaphores. So we will have our semaphores as the only synchronization mechanism. So I create my 3 programs, with a shared memory segment for different information (maximum capacity and file) On the other hand, I can not really know how to use semaphores. Should I create a binary semaphore already for the case of open or close museum? Also, I do not really see how to implement everything in the case where we have to share information between 3 programs and suddenly how to implement semaphores of this kind ... thank you in advance -- https://mail.python.org/mailman/listinfo/python-list
Re: ctypes help
On Fri, Nov 17, 2017 at 10:11 PM, Python wrote:
>
> I'm starting to play with ctypes, as I'd like to provide Python
> interfaces to a C/C++ library I have. For now I'm just messing with a
> very simple piece of code to get things sorted out. I'm working with
> this example C++ library, which just wraps a call to stat():
Calling POSIX system functions via ctypes can be difficult if they use
struct layouts that vary with the target platform and architecture.
> class Stat(ctypes.Structure):
> _fields_ = [("st_dev", ctypes.c_ulong),
> ("st_ino", ctypes.c_ulong),
> ("st_mode", ctypes.c_ulong),
> ("st_nlink", ctypes.c_ulong),
> ("st_uid", ctypes.c_ulong),
> ("st_gid", ctypes.c_ulong),
For x64 the above incorrectly uses 64-bit integers for mode, uid, and
gid. Also, it has mode and nlink flipped around in the x86 order
instead of the new x64 order.
> ("st_rdev", ctypes.c_ulong),
> ("st_size", ctypes.c_ulonglong),
> ("st_blksize", ctypes.c_ulonglong),
> ("st_blocks", ctypes.c_ulonglong),
> ("st_atim", Timespec),
> ("st_mtim", Timespec),
> ("st_ctim", Timespec)]
Try to strictly adhere to the defined types. Don't use `long long` for
a `long`, even if it happens to be the same size in a given
architecture. Also, avoid using definitions from docs and man pages.
Use the exact headers that the compiler sees. In this case, you missed
the 3 reserved long-integer fields at the end on x64 builds. Your Stat
struct is 128 bytes overall instead of the required 144 bytes. glibc
will corrupt the heap when it writes to the last 16 bytes. The best
case is that this immediately crashes Python.
Below I've included an example ctypes wrapper for calling stat() on
Linux x64 and x86 systems. I verified the sizes and offsets and tested
in 64-bit Python. From a C test program, I also have the field sizes
and offsets for the two 32-bit cases (with and without large file
support), but I'd need to build 32-bit Python to verify that the
ctypes wrapper is correct. I have no personal use for 32-bit Python,
so I leave that part up to you.
C header definitions from time.h, bits/typesizes.h, bits/types.h, and
bits/stat.h:
#define __DEV_T_TYPE __UQUAD_TYPE
#define __INO_T_TYPE __SYSCALL_ULONG_TYPE
#define __INO64_T_TYPE __UQUAD_TYPE
#ifdef __x86_64__
#define __NLINK_T_TYPE __SYSCALL_ULONG_TYPE
#else
#define __NLINK_T_TYPE __UWORD_TYPE
#endif
#define __MODE_T_TYPE __U32_TYPE
#define __UID_T_TYPE __U32_TYPE
#define __GID_T_TYPE __U32_TYPE
#define __OFF_T_TYPE __SYSCALL_SLONG_TYPE
#define __OFF64_T_TYPE __SQUAD_TYPE
#define __BLKSIZE_T_TYPE __SYSCALL_SLONG_TYPE
#define __BLKCNT_T_TYPE__SYSCALL_SLONG_TYPE
#define __BLKCNT64_T_TYPE __SQUAD_TYPE
#define __TIME_T_TYPE __SYSCALL_SLONG_TYPE
struct timespec
{
__time_t tv_sec;
__syscall_slong_t tv_nsec;
};
struct stat
{
__dev_t st_dev;
#ifndef __x86_64__
unsigned short int __pad1;
#endif
#if defined __x86_64__ || !defined __USE_FILE_OFFSET64
__ino_t st_ino;
#else
__ino_t __st_ino;
#endif
#ifndef __x86_64__
__mode_t st_mode;
__nlink_t st_nlink;
#else
__nlink_t st_nlink;
__mode_t st_mode;
#endif
__uid_t st_uid;
__gid_t st_gid;
#ifdef __x86_64__
int __pad0;
#endif
__dev_t st_rdev;
#ifndef __x86_64__
unsigned short int __pad2;
#endif
#if defined __x86_64__ || !defined __USE_FILE_OFFSET64
__off_t st_size;
#else
__off64_t st_size;
#endif
__blksize_t st_blksize;
#if defined __x86_64__ || !defined __USE_FILE_OFFSET64
__blkcnt_t st_blocks;
#else
__blkcnt64_t st_blocks;
#endif
#ifdef __USE_XOPEN2K8
struct timespec st_atim;
struct timespec st_mtim;
struct timespec st_ctim;
#else
__time_t st_atime;
__syscall_ulong_t st_atimensec;
__time_t st_mtime;
__syscall_ulong_t st_mtimensec;
__time_t st_ctime;
__syscall_ulong_t st_ctimensec;
#endif
#ifdef __x86_64__
__syscall_slong_t __glibc_reserved[3];
#else
#ifndef __USE_FILE_OFFSET64
unsigned long int __glibc_reserved4;
unsigned long int __glibc_reserved5;
#else
__ino64_t st_ino;
#endif
#endif
};
ctypes:
import os
import sys
import ctypes
import ctypes.util
libc = ctypes.CDLL(ctypes.util.find_library('c'), use_errno=True)
def c_errcheck(result, func, args):
if result == -1:
err = ctypes.get_errno()
raise OSError(err, os.strerror(err))
return args
class timespec(ctypes.Structure):
Re: Python dos2unix one liner
On Sat, Nov 18, 2017 at 9:42 PM, wrote: > Hello, > > I need to perform a tp on semaphores and shared segments of memory, but I > have a bit of trouble with the first notion. A tp? Sorry, not something I'm familiar with. > We are asked here to use only the IPC system 5 objects that are the shared > memory segments and semaphores. > > So we will have our semaphores as the only synchronization mechanism. > > So I create my 3 programs, with a shared memory segment for different > information (maximum capacity and file) > > On the other hand, I can not really know how to use semaphores. Okay, sounds like you want to research IPC a bit before you go on. Are you looking for advice on where to start researching? If so, my first question to you is: What platform or platforms do you need this to run on? IPC is notoriously difficult to manage in a truly cross-platform way, particularly if you need performance. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Test - you can ignore
On Saturday, November 18, 2017 at 7:28:56 AM UTC-6, Skip Montanaro wrote:
> This is a test posting from the Usenet side of things. Looking to see if/when
> it turns up in the gate_news logs on mail.python.org...
This is another test, though with a bit more Python content...
(python2) ~% python -c 'import this'
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
#!/usr/bin/env python
from __future__ import print_function
import csv
import glob
import os
import sys
import shutil
rows = csv.DictReader(open("manifest.dump", "rb"),
fieldnames="sha1 domain path flag".split(),
delimiter='|')
for row in rows:
if (row["path"].lower().endswith(".jpg") or
row["path"].lower().endswith(".jpeg")):
src = glob.glob("caa*/*/{}".format(row["sha1"]))
if not src:
print("not found:", row["path"], file=sys.stderr)
continue
dst = os.path.join("iPhone", row["path"])
shutil.copy(src[0], dst)
print(dst)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Test - you can ignore
On Saturday, November 18, 2017 at 7:28:56 AM UTC-6, Skip Montanaro wrote: > This is a test posting from the Usenet side of things. Looking to see if/when > it turns up in the gate_news logs on mail.python.org... > > Skip Yet another test. This time with SpamBayes x-mine_usenet_headers setting enabled... -- https://mail.python.org/mailman/listinfo/python-list
Re: for/ if against dict - one liner
Gentlemen, thank you very much for the replies and help. Vincent's solution worked perfectly for me. Alister - you are correct and for me, i was looking to achieve that - readability and slightly less keystrokes. On Tue, Nov 14, 2017 at 4:59 AM, alister via Python-list < [email protected]> wrote: > On Tue, 14 Nov 2017 00:44:18 -0500, Andrew Z wrote: > > > Hello, > > i wonder how do i get the "for" and "if" to work against a dictionary > > in > > one line? > > > > basically i want to "squeeze": > > dct= [ 1 : "one", 2:"two", 3:"three"] > > for k, val in dct: > >if k >= 2: > > # do magnificent things > > > > Thank you AZ > > why the need to single line it? > is your computer running out of new line & space characters? > it probably could be done with a dictionary comprehension but will that > make things easier or harder to read/understand? > > "Readability counts" > > > > > -- > (Presuming for the sake of argument that it's even *possible* to design > better code in Perl than in C. :-) > -- Larry Wall on core code vs. module code design > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Time travel - how to simplify?
Thank you for your input, gentlemen.
I'm thinking about the following approach:
import datetime
from dateutil import relativedelta
fut_suffix ={ 1 : 'F',
2 : 'G',
3 : 'H',
4 : 'J',
5 : 'K',
6 : 'M',
7 : 'N',
8 : 'Q',
9 : 'U',
10: 'V',
11: 'X',
12: 'Z'
}
endDate = datetime.date.today()
startDate = endDate + relativedelta.relativedelta(months = -6,day = 1)
LocalSmlSuffix = [ suffix for mnth, suffix in fut_suffix.items() if
mnth == startDate.month]
On Tue, Nov 14, 2017 at 5:01 PM, Rick Johnson
wrote:
> On Tuesday, November 14, 2017 at 1:44:17 PM UTC-6, Ben Finney wrote:
> > Andrew Z writes:
> >
> > > Now i want to get certain number of months. Say, i need 3 months
> duration
> > > starting from any month in dict.
> > >
> > > so if i start @ 7th:
> > > my_choice =7
> > > for mnth, value in fut_suffix:
> > > if my_choice >= mnth
> > ># life is great
> > > but if :
> > > my_choice = 12 then my "time travel" becomes pain in the neck..
> >
> > The ‘itertools’ library in the Python standard library
> > https://docs.python.org/3/library/itertools.html> has what you
> > need:
> >
> > import itertools
> >
> > month_values = sorted(list(fut_suffix.keys()))
> > month_cycle = itertools.cycle(month_values)
> >
> > month_choice = 7
> > three_months_starting_at_choice = []
> > while len(three_months_starting_at_choice) < 3:
> > this_month = next(month_cycle)
> > if this_month >= month_choice:
> > three_months_starting_at_choice.append(this_month)
>
> Ben's advice is spot on[1], and exactly what i would do, but
> i believe it's important for you to discover how to
> implement a simple cycling algorithm yourself, _before_
> reaching for the pre-packaged junkfood in the itertools
> module. Can you do it? If not, then do as much as you can
> and then ask for help. Hey, you're only hurting yourself if
> you don't learn how. And it's surprisingly easy!
>
> [1] and it looks as though he included the kitchen sink,
> washcloths, dish soap, and some fine china as well! ಠ_ಠ
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time travel - how to simplify?
Andrew Z wrote:
> well, yeah, it's unidirectional and final destination is always the same
> and have little to do with the question.
>
> Say, i have a dict:
>
> fut_suffix ={ 1 : 'F',
> 2 : 'G',
> 3 : 'H',
> 4 : 'J',
> 5 : 'K',
> 6 : 'M',
> 7 : 'N',
> 8 : 'Q',
> 9 : 'U',
> 10: 'V',
> 11: 'X',
> 12: 'Z'
> }
>
> where key is a month.
> Now i want to get certain number of months. Say, i need 3 months duration
> starting from any month in dict.
>
> so if i start @ 7th:
> my_choice =7
> for mnth, value in fut_suffix:
> if my_choice >= mnth
># life is great
> but if :
> my_choice = 12 then my "time travel" becomes pain in the neck..
>
> And as such - the question is - what is the smart way to deal with cases
> like this?
Make a lookup list that is big enough for your application and then use
slicing:
>>> def months(first, count, lookup=list("FGHJKMNQUVXZ" * 3)):
... start = first - 1
... return lookup[start: start + count]
...
>>> months(3, 3)
['H', 'J', 'K']
>>> months(12, 3)
['Z', 'F', 'G']
--
https://mail.python.org/mailman/listinfo/python-list
Re: ctypes help
Eryk,
Thanks much for the excellent and highly detailed response! That made
a lot of things clear.
On Sat, Nov 18, 2017 at 10:56:27AM +, eryk sun wrote:
> On Fri, Nov 17, 2017 at 10:11 PM, Python wrote:
> >
> > I'm starting to play with ctypes, as I'd like to provide Python
> > interfaces to a C/C++ library I have. For now I'm just messing with a
> > very simple piece of code to get things sorted out. I'm working with
> > this example C++ library, which just wraps a call to stat():
>
> Calling POSIX system functions via ctypes can be difficult if they use
> struct layouts that vary with the target platform and architecture.
>
> > class Stat(ctypes.Structure):
> > _fields_ = [("st_dev", ctypes.c_ulong),
> > ("st_ino", ctypes.c_ulong),
> > ("st_mode", ctypes.c_ulong),
> > ("st_nlink", ctypes.c_ulong),
> > ("st_uid", ctypes.c_ulong),
> > ("st_gid", ctypes.c_ulong),
>
> For x64 the above incorrectly uses 64-bit integers for mode, uid, and
> gid. Also, it has mode and nlink flipped around in the x86 order
> instead of the new x64 order.
>
> > ("st_rdev", ctypes.c_ulong),
> > ("st_size", ctypes.c_ulonglong),
> > ("st_blksize", ctypes.c_ulonglong),
> > ("st_blocks", ctypes.c_ulonglong),
> > ("st_atim", Timespec),
> > ("st_mtim", Timespec),
> > ("st_ctim", Timespec)]
>
> Try to strictly adhere to the defined types. Don't use `long long` for
> a `long`, even if it happens to be the same size in a given
> architecture. Also, avoid using definitions from docs and man pages.
> Use the exact headers that the compiler sees. In this case, you missed
> the 3 reserved long-integer fields at the end on x64 builds. Your Stat
> struct is 128 bytes overall instead of the required 144 bytes. glibc
> will corrupt the heap when it writes to the last 16 bytes. The best
> case is that this immediately crashes Python.
>
> Below I've included an example ctypes wrapper for calling stat() on
> Linux x64 and x86 systems. I verified the sizes and offsets and tested
> in 64-bit Python. From a C test program, I also have the field sizes
> and offsets for the two 32-bit cases (with and without large file
> support), but I'd need to build 32-bit Python to verify that the
> ctypes wrapper is correct. I have no personal use for 32-bit Python,
> so I leave that part up to you.
>
> C header definitions from time.h, bits/typesizes.h, bits/types.h, and
> bits/stat.h:
>
> #define __DEV_T_TYPE __UQUAD_TYPE
> #define __INO_T_TYPE __SYSCALL_ULONG_TYPE
> #define __INO64_T_TYPE __UQUAD_TYPE
> #ifdef __x86_64__
> #define __NLINK_T_TYPE __SYSCALL_ULONG_TYPE
> #else
> #define __NLINK_T_TYPE __UWORD_TYPE
> #endif
> #define __MODE_T_TYPE __U32_TYPE
> #define __UID_T_TYPE __U32_TYPE
> #define __GID_T_TYPE __U32_TYPE
> #define __OFF_T_TYPE __SYSCALL_SLONG_TYPE
> #define __OFF64_T_TYPE __SQUAD_TYPE
> #define __BLKSIZE_T_TYPE __SYSCALL_SLONG_TYPE
> #define __BLKCNT_T_TYPE__SYSCALL_SLONG_TYPE
> #define __BLKCNT64_T_TYPE __SQUAD_TYPE
> #define __TIME_T_TYPE __SYSCALL_SLONG_TYPE
>
> struct timespec
> {
> __time_t tv_sec;
> __syscall_slong_t tv_nsec;
> };
>
> struct stat
> {
> __dev_t st_dev;
> #ifndef __x86_64__
> unsigned short int __pad1;
> #endif
> #if defined __x86_64__ || !defined __USE_FILE_OFFSET64
> __ino_t st_ino;
> #else
> __ino_t __st_ino;
> #endif
> #ifndef __x86_64__
> __mode_t st_mode;
> __nlink_t st_nlink;
> #else
> __nlink_t st_nlink;
> __mode_t st_mode;
> #endif
> __uid_t st_uid;
> __gid_t st_gid;
> #ifdef __x86_64__
> int __pad0;
> #endif
> __dev_t st_rdev;
> #ifndef __x86_64__
> unsigned short int __pad2;
> #endif
> #if defined __x86_64__ || !defined __USE_FILE_OFFSET64
> __off_t st_size;
> #else
> __off64_t st_size;
> #endif
> __blksize_t st_blksize;
> #if defined __x86_64__ || !defined __USE_FILE_OFFSET64
> __blkcnt_t st_blocks;
> #else
> __blkcnt64_t st_blocks;
> #endif
> #ifdef __USE_XOPEN2K8
> struct timespec st_atim;
> struct timespec st_mtim;
> struct timespec st_ctim;
> #else
> __time_t st_atime;
> __syscall_ulong_t st_atimensec;
> __time_t st_mtime;
> __syscall_ulong_t st_mtimensec;
> __time_t st_ctime;
> __syscall_ulong_t st_ctimensec;
> #endif
> #ifdef __x86_64__
> __syscall_slong_t __glibc_reserved[3];
> #else
> #ifndef __USE_FILE_OFFSET64
> unsigned long int __glibc_reserved4;
> unsigned long int __glibc_reserved5;
> #else
Constants In Python (Posting On Python-List Prohibited)
Every (unqualified) name in Python is a variable. Which means its value can be
changed. If you want something that has a value that cannot be changed, you
have to make it an attribute of an object. For example, enums work this way.
You could define an enum for constants, but enums are nominally opaque to some
degree. If you want non-opaque constant definitions, how about this:
def constants(**kwargs) :
"defines an object with attributes that are given read-only" \
" values according to the keyword arguments passed."
class generator_class :
"parent class for generating constant-container instance."
pass
#end generator_class
def gen_constitem(name, val) :
def constitem(self) :
return \
val
#end constitem
#begin gen_constitem
constitem.__name__ = name
return \
property(constitem)
#end gen_constitem
#begin constants
for name in kwargs :
setattr(generator_class, name, gen_constitem(name, kwargs[name]))
#end for
return \
generator_class()
#end constants
Example use:
MY_CONSTS = constants \
(
apple = "fruit",
count = 3,
compound = {"key" : "value"},
)
print(MY_CONSTS.apple)
print(MY_CONSTS.count)
print(MY_CONSTS.compound)
MY_CONSTS.apple = 2.0
print(MY_CONSTS.apple)
produces output:
fruit
3
{'key': 'value'}
---
AttributeErrorTraceback (most recent call last)
in ()
31 print(MY_CONSTS.count)
32 print(MY_CONSTS.compound)
---> 33 MY_CONSTS.apple = 2.0
34 print(MY_CONSTS.apple)
AttributeError: can't set attribute
--
https://mail.python.org/mailman/listinfo/python-list
Re: "help( pi )"
Cameron Simpson wrote: one could change implementations such that applying a docstring to an object _removed_ it from the magic-shared-singleton pool, Is there any need to bother? If another float happened to end up with exactly the same value as pi and got merged with it, the docstring wouldn't be wrong. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: "help( pi )"
On 19Nov2017 11:49, Greg Ewing wrote: Cameron Simpson wrote: one could change implementations such that applying a docstring to an object _removed_ it from the magic-shared-singleton pool, Is there any need to bother? If another float happened to end up with exactly the same value as pi and got merged with it, the docstring wouldn't be wrong. Unless one had a misfortune and wanted another docstring. For pi this might not be so likely, but consider: mod1.py: MAX_BUFSIZE = 8192 MAX_BUFSIZE.__doc__ = 'Size of the hardware buffer used for I/O on this device.' mod2.py DEFAULT_CACHESIZE = 8192 DEFAULT_CACHESIZE.__doc__ = 'Convenient size for the foo cache, not to big or too small.' Cheers, Cameron Simpson (formerly [email protected]) -- https://mail.python.org/mailman/listinfo/python-list
